基于.NET的医药进销存管理系统(三)

图2-8用户关联图

图2-9 三元关联

2.2.2.3  构建系统类图
 在完成了初步类图的构建之后，需要建立和标记出类之间的关联。具体的表述关联的方法策略是：先从几个类开始，找出与这个类存在关联的其他类，然后再寻找另外一组类与其他类的关联，直到穷尽了所有的类为止。
 下面先介绍一下类之间常用的几种关系以及他们的概念：
 关联关系：关联(Association)表示两个类之间存在某种语义上的联系。
 角色：关联两头的类以某种角色参与关联。
 关联类：一个关联可能要记录一些信息,可以引入一个关联类来记录。
 聚集和组成：聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。
 继承关系：人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。继承(Generalization)定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。如图2-8中,将User进一步分为common user, administrator和business user,使用的就是继承关系。
 依赖关系： 有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。
 经过以上的分析之后，可以得出一个药品管理系统的初步类图，如图2-10所示：

 
 图2-10 药品管理系统类图
 
 
2.3 系统需求研究
2.3.1 收集系统需求
 在对一个系统的开发中，必须集中考虑用户的需求，这个步骤需要开发出系统的功能包图，每个包应代表系统的一个功能模块。
 包：将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。UML中这种分组机制叫包(Package)。
 任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。
2.3.2开发系统功能包图
 现在可以开发出系统功能包图如图2-11。在图2-11中,“系统”包由“界面”包和“单据”包和“使用者”包组成。这里称它们为"系统"包的内容。当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。
 
 图2-11系统功能包图
3  系统分析与设计
3.1 开发系统用例模型
 用例能够帮助系统开发者理解系统的预期行为，因而是一个强有力的工具，它能够帮助开发者从用户的观点收集需求。
 用例是一个强有力的工具，当使用UML可视化的表达出这些概念后，用例甚至会变得更加强大。可视化可以向用户显示用例，他们可以提供更多的信息。实际生活中用户常常知道的比他们清楚表达出来的要多：用例能够帮助用户解决这个问题。另外，可视化的表达形式允许将用例图和其他种类的图结合起来。
 系统分析过程中的一个目标是产生一组用例。此想法是要对用例进行分类整理，以便于引用。这些用例代表着用户对系统的观点。当要对系统升级时，用例目录可以作为进一步收集升级需求的基础。
3.1.1分析与充实用例
  在这个阶段，开发者正在从理解领域逐步走向对实际系统的理解。用例是两者之间的桥梁。
    在之前开发出来的初步用例图中，每个用例是一组场景的集合，每个场景又由一系列步骤组成。对于每个用例中的每个场景，需要说明的内容有：
场景的简单陈述
关于场景的假设条件
场景的前置条件
用例的发起参与者
场景中与系统相关的步骤序列
场景完成后的后置条件
用例的收益参与者
 当然，用例分析的方法也是多种多样的，现在所使用到的条目在通常情况下能够完整地说明一个用例。与系统相关的步骤序列在场景中极其重要。它说明了系统的预期工作方式。也就是说，系统开发项目是由“用例驱动”的，用例是构造系统的途径。
 
 

3.1.2开发详细用例图

图3-1 系统总详细用例图
 之后，根据需求收集阶段对系统的分析，对应系统应有的功能，可以确定系统业务角色与系统用例之间的关系。随后，细化每一个用例，如图3-1所示的系统总用例图：
3.2  静态对象设计
3.2.1  细化类图
 经过对第2部分开发出来的主要类的细化，可以得出以下的类图：

图3.2细化后的类图
3.2.2  开发系统详细类图
细化后的系统类图为：

图3-3  细化后的系统类图
3.3  详细对象设计
 根据已经开发出来的类图，可以产生一些必要的对象图，对应的检查每个操作，进而充实对象图，并构建出对象间的交互。
3.3.1 分析对象状态变化
 分析系统离不开分析对象的交互，在UML中，有两种表示交互状态的图：顺序图和协作图。对象图、对象和链，UML中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类的实例;对象之间的链(Link)是类之间的关联的实例。对象与类的图形表示相似,均为划分成两个格子的长
 方形(下面的格子可省略)。上面的格子是对象名,对象名下有下划线;下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂的类图的一个实例。
3.3.1.1 分析对象——顺序图
 顺序图(sequence diagram)由采用通常方式表示的对象构成：对象用矩形框表示，其中是带下划线的对象名；消息用带箭头的实线表示；时间用垂直的虚线表示。对象图可以反映随时间对象之间的动态协作关系 ，反映对象之间已发送消息的先后顺序 ，说明对象之间的交互过程以及在某一具体位置有何事件发生。本系统的顺序图可以表示为如图3-4。

 图3-4药品管理系统顺序图
 

3.3.1.2  分析与协作系统的集成——协作图
 系统分析到现在，还应当考虑到对象与对象之间的动态关联，即对象之间的消息传递。协作图即是为了表示出对象之间的动态协作，显示对象之间的关系。
 图3-5是整个系统的协作图示例：

                        
图3-5 系统协作图

 在药品入库阶段，主要存在着如图3-6的交互：
 
 图3-6   入库协作图

在药品出库阶段，主要存在着如图3-7的协作关系
 
 图3-7出库协作图
 在药品调价阶段，主要存在着如图3-8的协作关系

 
 图3-8 调价协作图
3.4  持久对象设计
 在前面的工作中，已经确定了对象本身以及对象之间的关系，弄清了这些关系也就完成了对象设计，然而，软件在运行过程中构造的对象实例都是顺势或者是暂时的，软件一旦停止运行，这些对象也就不复存在了。因此，要把暂时性的对象永久的保存下来，就必须把对象转换成一定格式的数据，存放在磁盘或者其他媒介。这种可以永久保留，将来可以被提取的对象，被称为“持久对象”（persistent object）。或者说，持久对象是独立于其构造过程的对象代表（representation）。
 此次设计中，我用SQL Server2000建立后台数据库。设计过程中为了对应于编码起见，首先设计对象数据库的根模型，然后通过标准方法把设计映射到具体的数据库模型——即将持久对象映射到表格中。
3.4.1  数据库根设计
 在本管理系统中，药品管理系统（DrugManagement）是一个数据库根,它利用“容器”（Container）来管理User(用户)，Account(账目)，DutDate(过期时间)等类。下面将系统（DrugManagement）的详细对象设计表现为详细对象设计图，如下页图3-9所示。

图3-9  详细对象设计
 
3.4.2  持久对象到表的映射
 以上部分确定了对象本身及对象之间的关系，下一步，就要开始用特定的编程语言实现设计，同时在实现的过程中，要把对象存到数据库中，由于我使用的是SQL Server2000作为后台数据库，所以存储的形式，便是数据库中的表格，这些表格成为了持久对象的代表。
 
 
 
 如以下的供应商到采购员的二元关联到表的映射：

 图3-10  供应商到采购员映射图
 由图3-10推出下列表格：
（1）表1供应商表：Merchant
                              表1 供应商表
别 名 名称  数据类型  大小 空值  默认值
 供应商ID MerchantID Numeric  9(12,0)  
供应商名 Merchantname Varchar  30  √ 
(2)表2 采购员表：Buyer
                              表2 采购员表
别 名 名称 数据类型 大小 空值 默认值
 采购员ID MerchantID Numeric 9(12,0)  
采购员名 Merchantname Varchar  30  √ 
（3）表3 入库表：Enterdepository
                             表3 入库表
别 名 名称  数据类型  大小 空值  默认值
 采购员ID MerchantID Numeric  9(12,0)  
采购员名 Merchantname Varchar  30  √ 
 供应商ID MerchantID Numeric  9(12,0)  
供应商名 Merchantname Varchar  30  √ 
药品产地 Manufacname Varchar  30  √ 
  药品名称 Drugname Varchar  50   
 药品数量 YPSL Nuneric 9(12,4)   
 药品效期 YPXQ Datetime  8   
 发票号码 FPHM Varchar  10  √ 
 批准文号 PZWH Varchar  30  √ 
    
同样，可以得到从三元及多元关联到关系表格的映射。现在，由Merchant, Manufacturer, User的三元类扩充，增加了一个关联类DrugDetail，即药品明细，用来表示药品入库后的存放属性。如图3-11。

                            图3-11药品明细关联类
DrugDetail的属性有Drugnumber（药品型号），Drugname（药品名称），Manufacname（药品产地名称）。这几个类分别映射到四个表格中。如下图所示：

(4) 表4 药品明细表：DrugDetail
                             表4 药品明细表
别 名 名称  数据类型  大小 空值  默认值
药品型号  Drugnumber Numeric 9(12,0)  
  药品名称  Drugname  Varchar  9(12,0)   
 药品产地  Manufacturer  Varchar  30  √ 
进货价格 JHJG Numeric 9(12,4)  

首页 上一页 1 2 3 4 5 6 下一页 尾页 3/6/6