UML实验报告

《软件建模原理》实验报告 学院：  计算机学院 班级：  姓名： 学号：   授课老师： 实验一：用例建模 [ 实验日期 ]  2011年  6月 22 日 [ 实验目的 ] ·掌握客户需求 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 的 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 和步骤 ·了解以用例驱动的软件开发方法 ·识别并编写用例 ·掌握用 Rose 进行用例建模的具体方法和步骤 [ 实验内容 ] 要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统” (参见“项目背景及简要分析”)。 [ 实验原理和步骤] 建模原理： (1) 需求获取。以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。 (2) 用例分析。确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）  （3）用例描述。分层绘制用例图，撰写用例的文字描述（采用单栏格式） 。    步骤： （1）分层绘制用例图，每层采用“包”进行管理。 （2）以“企业综合信息管理系统” -> “进销存管理”子系统 -> “销售管理” -> “合同管理” ->“收款单处 理”为主线，完成附录 2 中的操作过程（亦可选择“企业综合信息管理系统” -> “进销存管理”子系统 -> “库存管 理” -> “原 材料 关于××同志的政审材料调查表环保先进个人材料国家普通话测试材料农民专业合作社注销四查四问剖析材料 出库” ->“领料单处理”主线） [ 实验结果] 综合支持的类图 [ 实验总结 ] 第一次运用rose进行用例建模。熟悉了rose中的控件的意义，对UML有了更加深刻的了解，学会了建立2级例图。但目前运用rose来建模还是非常的生硬，仅仅知道跟着指导书来进行建立模型。 收获与体会：用例建模主要是要了解各个图形所代表的意义，  知道用例还可以进行下一级的描述，进行下一步的深化。 实验 2 分析建模 [ 实验日期 ]    2011年  6  月  23  日 [ 实验目的 ] (1) 理解面向对象系统分析和对象类建模(概念建模)的概念 （2）了解和掌握面向对象系统分析的方法和步骤 (3)了解和掌握寻找待开发系统中类(概念)的方法和技巧 (4) 掌握使用 ROSE 绘制概念模型的方法 [ 实验内容 ] 在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型。 [ 实验原理和步骤] 建模原理： (1) 使用概念目录列表（见下图）和非正式分析法（识别出问题域的文本描述中的名词短语，然后将其作为概念或属性的候选对象。 ）相结合的方法识别概念。因此，待开发用例的文字描述中，名词可能成为概念或属性的候选对象；表示行为的动词词组有可能成为事务型或过程型对象；形容词词组有可能对应抽象的名词型概念。 采用的技术基本上就是：ER 图+纯行为+OO 的聚合、泛化。 （2）最终关联的数量介于“需要知道”型关联与【 “需要知道”型关联+“需要理解”型（从通用关联列表中派生出 的，见下图） 】之间。    步骤： （1） 识别关键用例作为第一个迭代周期的开发目标（一般是在用例图中被依赖得比较多的用例） 。 （一般是在用例图中被依赖得比较多的用例） 。 可以选“企业综合信息管理系统” -> “进销存管理”子系统 -> “库存管理” -> “原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” -> “进销存管理”子系统 -> “销售管理” -> “合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。 （其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一 切工作就以销售管理为中心。即便如此，首选“增加合同”用例也更为合适。 其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一切工作就以销售管理为中心。即便如此，首选“增加合同”用例也更为合适。 ） （2）识别概念和重要属性。 （3）建立概念间的关联。 画图原理： （1） 可以采用“逻辑视图”下的类图描述概念模型，只不过每个类中只有类名和属性，没有方法。在概念建模 阶段也没有必要确定属性的类型和访问属性。 （2） 概念间的关联可以采用一般关联（无方向实线） ，当然，对于聚合和泛化，应采用相应的连线（组合：实 心菱形+实线；聚合：空心菱形+实线；泛化：空三角形+实线） 步骤： （0）前提条件：第一个迭代周期可以选“企业综合信息管理系统” -> “进销存管理”子系统 -> “库存管理” -> “原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” -> “进销存管理”子系统 -> “销售管理” -> “合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。做好与此用例相关的概念模型 （1） 建立相关的概念模型的基础上，在“逻辑视图”下的类图中描述概念模型，可以直接在类图 main 中绘制， 也可采用类似用例图中用过的分包机制 （2）绘制概念和重要属性。 （3）绘制概念间的关联。 [ 实验结果] 采用 ROSE 绘制的，与待开发用例相关的概念模型。 销售管理系统概念模型 [ 实验总结 ] ② 实验中的问题和提高：对自己的分析或 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 进行评价，指出合理和不足之处，提出改进的方案。  ③ 收获与体会：筛选概念的要点；区分概念与属性的要点；关联取舍的要点；画图时如何防止关联重名。  实验 3 设计建模 [ 实验日期 ]        2011年 6  月24    日 [ 实验目的 ] (1) 理解顺序图的基本概念 （2）了解和掌握软件工程中用例逻辑时序的分析方法 （3）掌握使用 ROSE 创建顺序图的方法 [ 实验内容 ] 在用例模型和概念模型的基础上，对首选的用例进行事件分解，识别出系统事件（系统操作） ， （并写出契约的后置条件） ；为每个系统事件画顺序图，为对象分配职责。 [实验原理和步骤 ] 原理： (1) 在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。 (2) 系统事件是由某参与者发起的指向系统的输入事件。一个事件的发生能够触发一个响应操作的执行。 (3) 请仔细研究下图,考察它是如何从左边的"购买商品"用例的文字描述中分解出 3 个系统事件的。 （4）参照用例模型和概念模型，为每个系统操作估计后置条件。 （实例创建、形成关联、属性修改） （5）按照设计模式为对象分配职责。    步骤： （1） 分析首选用例的文字描述， 按事件进行分解， 识别出系统事件。 （下面以 “企业综合信息管理系统”  -> “进销存管理”子系统 -> “销售管理” -> “合同管理” ->“收款单处理”主线中的“收款单处理”用例为例） 。 我们暂不考虑批处理。第一个核对，因为要将“货款金额填写到合同中” 。后置条件显然有“销售合同”的属性修 改。此合同显然已经存在，不需要创建，但需要根据合同编号 find，然后形成关联。第二个核对需要根据合同明 细到仓库的“存货明细” （概念模型中还没有）中去查。此核对发生前虽然敲了一下键盘，但随后并没有新的消息 穿越系统边界，因此这仍然是同一个系统事件。先考虑成功场景，应该向库存系统发提货单 提货单（概念模型中还没有） 就结束了。后续的削减库存（核销） 、预警显然不是销售管理员的职权，并且真正的核销必须由仓库的发货人执行， 才能保证货帐一致。并且“生产厂家”与“邮购公司”的运作方式不同，后者是自己的员工取货并邮寄，而前者 还有可能是来人来车取货， 这时仓库收到取货单后并不能立即自动处理 （开发货单） ， 必须等取货人到达才能处理。 根据题意，本项目应该是“生产厂家”模式。这又存在一个问题，如果在开出提货单后不修改库存，可能影响并 发用户和后续付款单的处理。所以有必要设计一个“临时存货明细 临时存货明细” （概念模型中还没有） （不是真实的“存货明 细” ）供修改，何时按存货明细”进行刷新应该是库存管理系统的事（比如每天夜里刷新，但因为雨雪天气，取货人迟迟不提货，是提货单作废 （相当于退回销售系统， 付款单变为未处理） 还是就强行刷新 （此时有冲突危险）？）  失败场景。向“生产调度部门”发送“产品生产申请单” 。如果是专门为此单进行生产，那么还应该有库存系统发来的“产品入库通知处理”用例来调用本用例进行发货。本题显然一概根据付款单运作，因此如果失败，就不处理付款单，但按日期把它排在待处理付款单的前面。从前面的分析来看，就一个系统事件，我们就命名为“付款单处理(pb:付款单)” （2） 为每个系统事件估计后置条件。(以上已做了部分分析) （3） 按设计模式进行设计。 首先考虑控制者,领域控制者选参与者角色，即“销售人员” 。为了避免使用 FORM,窗口等表示层对象,我们人造一 个类”应用协调者”向控制者发送消息。 [ 实验结果] [ 实验总结 ] ① 对重点实验结果进行分析； ② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。  ③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。 实验 4 设计建模 [ 实验日期 ]      2011  年  6 月  25 日 [ 实验目的 ] (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）完善设计类图  [ 实验结果] [ 实验总结 ] ① 对重点实验结果进行分析； ② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。  ③ 收获与体会：分析依赖关系的要点，绘制关联的要点。