和标记类之间的关联，同时填充类的信息。
2.2.1 初步用例模型开发
用例是由参与者发起的，参与者能够从用例的执行中获得有价值的事物。用例模型的图形表示法很直观。用例用一个椭圆形表示，直立人形图表表示参与者。用例的发起参与者在用例图的左侧，接受参与者在用例图的右侧。参与者的名字放在参与者图表的下方，用例的名字可以放在椭圆形里面也可以放在椭圆形下方。关联线连接参与者和用例，并且表示参与者与用例之间有通信关系。关联线是实现，和类之间的关联线类似。 用例分析的一个好处是它能展现出系统和外部世界之间的边界。参与者是典型的系统外部实体，而用例属于系统内部。系统的边界用一个矩形（里面写着系统的名字）来代表。系统的用例装入矩形之内。
参与者、用例和互连线共同组成了用例模型（use case model）. 下图说明了这些符号：
图2-4 用例模型示例
2.2.1.1 开发系统业务角色
首先，需要确定整个系统的业务角色。业务角色，顾名思义，就是与业务交流的人或物，都可以被称为业务角色。在本管理系统中，大体上可以分为生产厂家、供应商、采购员、销售员、基本操作员、系统管理员这六类业务角色。
2.2.1.2 开发初步用例图
接下来，需要对每个业务角色标识业务用例，这些业务用例包括：生产商品、购入商品、批发销售商品、输入商品相关信息、售出商品、管理整个系统流程等等。
这个阶段的任务，就是描述系统用例与系统业务角色之间的关系，如图2-6中所示。
10
图2-6 业务角色与系统用例
2.2.2 开发初步类图
2.2.2.1 系统中的类
类图(Class Diagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上,状态图、合作图等进一步描述了系统其他方面的特性。
对象(Object)与对客观世界的理解相关。通常用对象描述客观世界中某个具体的实体。所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例(Instance)。建立类模型时,应尽量与应用领域的概念保持一致,以使模型更符合客观事实,易修改，易理解和易交流。
类描述一类对象的属性(Attribute)和行为(Behavior)。在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。图1中,\客户\就是一个典型
11
的类。
类的获取和命名：最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析,抽象出领域中的概念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。一般而言,类的名字是名词。
下面分析领域一下类中的动词和名词，其中的一些名词将可能成为模型中的类，另一些名词成为类的属性。而动词或者动词短语则成为类的操作或类之间的关联标记。
系统中涉及到的名词有：
商品（drug），用户（user）, 管理员（administrator）, 普通用户(common user),信息录入员(information recorder)，盘点员，调价员，采购员（buyer），仓库保管员（depository keeper），销售员(seller)，账目(account), 发票(invoice), 账单(bill), 入库单(enter depository bill), 出库单(out depository bill), 调价单(change price bill), 客户（client）,供应商（merchant），等等。
系统中涉及到的动词有：
入库(enter depository ),出库(out depository ),盘点(check)、调价(change price)、付账(pay)、信息录入(information enter)，等等。 2.2.2.2 类之间的关系
在这个阶段，对开发出来的初步类图中的类，根据其意义来分成一些组。 人组成的一组: 用户（user）, 管理员（administrator）, 过期日期（Due date）,普通用户（common user),客户（client）,生产厂家（manufacturer）,供应商（merchant）,销售员（seller）,采购员（Buyer）
物品组成的一组：商品（drug），药库（Depository）
生成的单据组成的一组：账目（account）, 发票(invoice）,Check（支票）,账单（bill）, 入库单（enter depository bill）, 出库单（out depository bill）, 调价单（change price bill）
2.2.2.3 构建系统类图
在完成了初步类图的构建之后，需要建立和标记出类之间的关联。具体的表述关联的方法策略是：先从几个类开始，找出与这个类存在关联的其他类，然后再寻找另外一组类与其他类的关联，直到穷尽了所有的类为止。
12
下面先介绍一下类之间常用的几种关系以及他们的概念：
关联关系：关联(Association)表示两个类之间存在某种语义上的联系。 角色：关联两头的类以某种角色参与关联。
关联类：一个关联可能要记录一些信息,可以引入一个关联类来记录。
聚集和组成：聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。
继承关系：人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。继承(Generalization)定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。如图2-8中,将User进一步分为common user, administrator和business user,使用的就是继承关系。
依赖关系： 有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。
2.3 系统需求研究
2.3.1 收集系统需求
在对一个系统的开发中，必须集中考虑用户的需求，这个步骤需要开发出系统的功能包图，每个包应代表系统的一个功能模块。
包：将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。UML中这种分组机制叫包(Package)。
任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。
2.3.2开发系统功能包图
现在可以开发出系统功能包图如图2-11。在图2-11中,“系统”包由“界面”包和“单据”包和“使用者”包组成。这里称它们为\系统\包的内容。当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。
13
图2-11系统功能包图
14