UML与软件建模实验报告
姓 名：孙冬生
专 业：软件工程
学 号：081842154
指导老师：胡增涛
目录
实验一：用例建模... 3
实验2 分析建模... 6
实验3 设计建模（1）... 9
实验4 设计建模（2）... 11
用例附件：... 13
内容：用例建模、 分析建模、设计建模（1）、设计建模（2）
实验一：用例建模
[ 实验目的] ·掌握客户需求分析的方法和步骤
·了解以用例驱动的软件开发方法
·识别并编写用例
·掌握用Rose 进行用例建模的具体方法和步骤
[ 实验内容] 要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”
[ 实验原理和步骤] 建模原理：
(1) 需求获取。以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。
(2) 用例分析。确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）
（3）用例描述。分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：
（1）需求获取。自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。
（2）用例分析。确定系统范围和边界、确定参与者、确定用例。
（3）用例描述。分层绘制用例图、描述用例。
画图原理：
采用Rose 软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。
步骤：
（1）分层绘制用例图，每层采用“包”进行管理。
（2）以“企业综合信息管理系统” -> “进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”为主线，完成附录2 中的操作过程（亦可选择“企业综合信息管理系统” -> “进销存管理”子系统-> “库存管理” -> “原材料出库” ->“领料单处理”主线）
[ 实验结果] 
[ 实验总结] ①各层用例图之间相互关联，对用例图画法和建立要清楚的熟悉操作信息流程，否则很容易搞混；
② 用例图的画法步骤不是很熟悉，对工具的使用陌生，不能正确的画出和表达用例，缺乏实践。。
③了解了各层用例之间的关系，以及用例图的画法，熟悉了工具的使用，对以后的实验帮助很大。。
实验2 分析建模
[ 实验目的]
(1) 理解面向对象系统分析和对象类建模(概念建模)的概念
(2)了解和掌握面向对象系统分析的方法和步骤
(3)了解和掌握寻找待开发系统中类(概念)的方法和技巧
(4) 掌握使用ROSE 绘制概念模型的方法
[ 实验内容]
在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型。
[ 实验原理和步骤]
建模原理：
(1) 使用概念目录列表（见下图）和非正式分析法（识别出问题域的文本描述中的名词短语，然后将其作为概念或属性的候选对象。）相结合的方法识别概念。因此，待开发用例的文字描述中，名词可能成为概念或属性的候选对象；表示行为的动词词组有可能成为事务型或过程型对象；形容词词组有可能对应抽象的名词型概念。
采用的技术基本上就是：ER 图+纯行为+OO 的聚合、泛化。
（2）最终关联的数量介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型（从通用关联列表中派生出
的，见下图）】之间。
步骤：
（1） 识别关键用例作为第一个迭代周期的开发目标（一般是在用例图中被依赖得比较多的用例）。可以选“企业综合信息管理系统” -> “进销存管理”子系统-> “库存管理” -> “原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” -> “进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。（其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一切工作就以销售管理为中心。即便如此，首选“增加合同”用例也更为合适。）
（2）识别概念和重要属性。
（3）建立概念间的关联。
画图原理：
（1） 可以采用“逻辑视图”下的类图描述概念模型，只不过每个类中只有类名和属性，没有方法。在概念建模
阶段也没有必要确定属性的类型和访问属性。
（2） 概念间的关联可以采用一般关联（无方向实线），当然，对于聚合和泛化，应采用相应的连线（组合：实心菱形+实线；聚合：空心菱形+实线；泛化：空三角形+实线）
步骤：
（0）前提条件：第一个迭代周期可以选“企业综合信息管理系统” -> “进销存管理”子系统-> “库存管理” ->“原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” ->“进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。做好与此用例相关的概念模型
（1）建立相关的概念模型的基础上，在“逻辑视图”下的类图中描述概念模型，可以直接在类图main 中绘制，也可采用类似用例图中用过的分包机制
(2）绘制概念和重要属性。
（3）绘制概念间的关联。
[ 实验结果] 
[ 实验总结]
① 实验中类图的画法对程序的编制很重要，各类之间的关系对以后程序中的类继承和多态有指导意义；
② 对类图的不了解，以及不知道如何去辨别分析类与类之间的关系，在者还是开发工具不是很熟悉，缺乏实践动手能力。
③ 进一步了解UML分析建模的流程和重要性，对以后从事工作有很大帮助，看懂了类图和用例图对以后编程有重要作用。
实验3 设计建模（1）
[ 实验目的]
(1) 理解顺序图的基本概念
（2）了解和掌握软件工程中用例逻辑时序的分析方法
（3）掌握使用ROSE 创建顺序图的方法
[ 实验内容]
在用例模型和概念模型的基础上，对首选的用例进行事件分解，识别出系统事件（系统操作），（并写出契约的后置条件）；为每个系统事件画顺序图，为对象分配职责。
[ 实验原理和步骤]
原理：
(1) 在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。
(2) 系统事件是由某参与者发起的指向系统的输入事件。一个事件的发生能够触发一个响应操作的执行。
(3) 请仔细研究下图,考察它是如何从左边的"购买商品"用例的文字描述中分解出3 个系统事件的。
（4）参照用例模型和概念模型，为每个系统操作估计后置条件。（实例创建、形成关联、属性修改）
（5）按照设计模式为对象分配职责。
步骤：
（1） 分析首选用例的文字描述，按事件进行分解，识别出系统事件。（下面以“企业综合信息管理系统” -> “进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”主线中的“收款单处理”用例为例）。
我们暂不考虑批处理。第一个核对，因为要将“货款金额填写到合同中”。后置条件显然有“销售合同”的属性修改。此合同显然已经存在，不需要创建，但需要根据合同编号find，然后形成关联。第二个核对需要根据合同明细到仓库的“存货明细”（概念模型中还没有）中去查。此核对发生前虽然敲了一下键盘，但随后并没有新的消息穿越系统边界，因此这仍然是同一个系统事件。先考虑成功场景，应该向库存系统发提货单（概念模型中还没有）就结束了。后续的削减库存（核销）、预警显然不是销售管理员的职权，并且真正的核销必须由仓库的发货人执行，才能保证货帐一致。并且“生产厂家”与“邮购公司”的运作方式不同，后者是自己的员工取货并邮寄，而前者还有可能是来人来车取货，这时仓库收到取货单后并不能立即自动处理（开发货单），必须等取货人到达才能处理。
根据题意，本项目应该是“生产厂家”模式。这又存在一个问题，如果在开出提货单后不修改库存，可能影响并发用户和后续付款单的处理。所以有必要设计一个“临时存货明细”（概念模型中还没有）（不是真实的“存货明细”）供修改，何时按存货明细”进行刷新应该是库存管理系统的事（比如每天夜里刷新，但因为雨雪天气，取货
人迟迟不提货，是提货单作废（相当于退回销售系统，付款单变为未处理）还是就强行刷新（此时有冲突危险）？）失败场景。向“生产调度部门”发送“产品生产申请单”。如果是专门为此单进行生产，那么还应该有库存系统发来的“产品入库通知处理”用例来调用本用例进行发货。本题显然一概根据付款单运作，因此如果失败，就不处
理付款单，但按日期把它排在待处理付款单的前面。从前面的分析来看，就一个系统事件，我们就命名为“付款单处理(pb:付款单)”
（2） 为每个系统事件估计后置条件。(以上已做了部分分析)
（3） 按设计模式进行设计。
首先考虑控制者,领域控制者选参与者角色，即“销售人员”。为了避免使用FORM,窗口等表示层对象,我们人造一
个类”应用协调者”向控制者发送消息。
[ 实验结果] 
[ 实验总结]
① 对重点实验结果进行分析，了解顺序图的创建步骤和方法，并结合案例，分析事件的发生时序，使人一目了然；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：学会了顺序图的创建方法，重点是其中事件发生的时序顺序，清楚表达用例。
实验4 设计建模（2）
[ 实验目的]
(1)理解面向对象类之间关联关系的概念
(2)了解和掌握分析类之间的关联关系的方法
(3)了解和掌握待开发系统中类之间关联关系的分析方法
(4)完善设计类图，掌握使用ROSE 对关联进行建模的过程
[ 实验内容]
根据设计建模（1）中的交互分析，进一步设计关联和对象可见性（补上遗漏的关联）,完善设计类图。
[ 实验原理和步骤]
建模原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关
联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。可以使用下列的指导方针列出暂时性的关系：
(1)存在两个或两个以上的类相互之间就可能有关联。
(2)类的操怍(成员函数)的参数列表里出现其他类的对象。
(3)一个类包含另一个类的对象(对象成员)。
(4)根据一般常识可能会出现的关联。
步骤：
（1） 分析已建立的设计类图和交互图，进一步设计关联和对象可见性（补上遗漏的关联）。（下面以“企业综合
信息管理系统” -> “进销存管理”子系统-> “销售管理” -> “合同管理” ->“收款单处理”主线中
的“收款单处理”用例为例）。
在销售管理子系统中，定义的各个类之间一般都有关系发生。销售人员和客户(大客户)共同签署销售合同，
销售合同中涉及到多种可以销售的产品，合同经公司经理审查并签字后该合同才能生效，付款单需要客户付款，
销售人员签发催款单向客户催缴欠款，销售人员制定销售计划，销售人员要检查督促执行期合同按合同执行、履
约，履约后的合同转到履约合同数据库存档备查等等。
例如：
（a） 销售人员与客户：一般关联，多对多
（b） 销售合同与合同明细，销售计划与计划明细：组合。
（c） 付款单与客户：依赖关系。《如果付款单类中有“统计付款金额(客户类客户对象)”操作的话，付款
单类就依赖客户类》
（2）完善设计类图
画图原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关
联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。
步骤：
（1） 在关联和对象可见性分析的基础上，补充一般关联、组合，泛化、依赖
（a）一般关联关系要注意关联的命名以及哪个是role A 哪个是role B。
(b)一般关联选中role B detail 中的aggregate，就变成聚合；再选中by value 就变成组合。
(c)依赖画虚线箭头。
（2）完善设计类图
[ 实验结果] 
[ 实验总结]
① 各个类之间的依赖关系，以及泛化聚合等关系，需清楚的表达；
② 实验中不能正确处理类之间的关系，常常搞反，类之间的关系对于正确的编制程序用处很大，因此很重要。
③ 动手能力增加，了解了类之间的关系的表达，以及在ratioanl rose 中的线条形式。
实验心得体会：通过实验了解UML的建模的步骤和方法，了解用例图和类图等的画法，了解系统的分析和建模方法。增加动手和思维能力，使自己更加的了解软件系统前期开发的软件定义和分析方法。
用例附件：
用例编号：uc05000000（共有4层用例图结构，采用8位编码，每层用2位数字）
用例名：管理进销存管理
执行者：人执行者：企业员工、客户、公司经理，
目的：“管理进销存”用例管理企业与客户签订采购/销售合同，并督促合同的执行和履约，提供售后服务。对库存产品和物料进行出/入库的有效管理，即使盘点并提出低于库存预警线而需要采购的物料清单和各种库存统计报表。
类型：端点、主要的、基本的。
级别：1级
典型事件描述：该用例包含“管理销售”、“管理采购”和“管理仓库”3个用例。
1. 管理3个子系统的企业员工输入标识码（ID），由系统识别标识码的有效性。
2. 分别进入系统，进行“销售”、“采购”和“仓库”管理。
3. 退出系统。
与其他用例的关联：依赖“管理财务”和“综合支持”用例，为“经理查询”和“调度生产”用例提供支持。
异常事件流处理：
1.标识码有效性检查失败：系统检测标识码有效性失败，允许重新输入。
用例编号：05010000 (共有4 层用例图结构，采用8 位编码，每层用2 位数字)
用例名：管理销售
执行者：人执行者：企业员工、客户、公司经理，
系统执行者：“财务管理”于系统、“生产调度管理”子系统和“综合支持管理”子系统。
目的：制定销售计划，与客户签订销售合同，井将其详细内容录入管理系统。监控正在履约的合同，检查客户是否按
时付款，对付款的客户发货。
类型：端点、主要的、基本的
级别：2 级
典型事件描述：
1．企业员工输入标识码(ID)，系统识别标识码的有效性。
2．输入一个新的具有唯一合同编号的销售合同的详细内容。
3．监督执行期合同是否履约(客户是否付款，决定是否发货)。
4．对履约的合同设置履约标志。
5．退出系统。
与其他用例的关联：过程描述1 中包含身份验证用例；3 中涉及“管理财务”、“调度生产”和“管理仓库”用例。
异常事件流处理：
1．标识码有效性检查失败：系统检测标识码有效性失败，允许重新输入。
用例编号：05010300(共有4 层用例图结构，采用8 位编码，每层用2 位数字)
用例编号：05010303 (共有4 层用例图结构，采用8 位编码，每层用2 位数字)
用例名：收款单处理
执行者：人执行者：销售合同管理员、客户、公司经理，
系统执行者：“财务管理”子系统、“仓库管理子系统”、“生产调度管理”子系统。
目的：对于已签订生效的销售合同，财务管理部门负责收取客户货款，并开具收款单。“收款单处理”用例要做的工作
是：核查收款单并从仓库提取客户订购的产品，核查并发货给客户。
类型：主要的、基本的
级别：4 级
典型事件描述：
1．核对“收款单”：以批处理方式对财务部门传送过来的收款单(客户的付款证明)，根据收款单上的合同编号自动
找到对应的销售合同，将收到的货款金额填写到合同中；
2．核对“货物清单”：系统根据客户付款金额和合同上标明的货物种类、数量和单价，与仓库库存货物清单进行
核对。
3．如果仓库中有合同规定数量的货物，从仓库提取客户订购的产品，核查并发货给客户。转到5 执行。
4. 如果仓库中现存的货物少于合同规定的数量，应向“生产调度部门”发送“产品生产申请单”，要求立即组织生
产。当所要的产品生产出来并入库后，转到步骤2 执行。
5．将发送货物的数量填写到相应销售合同中。
6.退出系统。
与其他用例的关联：该用例有异步的多进程操作，涉及到“生产调度部门”和“仓库管理部门”的用例。
异常事件流处理：
1．过程描述1 中如果出现“收款单”找不到相应的“执行期采购合同”(合同编号不能匹配)时，显示警告提示用
户。并将该“收款单”作出标记退回“财务部门”。