UML实验报告.docx
- 文档编号:2258162
- 上传时间:2022-10-28
- 格式:DOCX
- 页数:14
- 大小:560.69KB
UML实验报告.docx
《UML实验报告.docx》由会员分享,可在线阅读,更多相关《UML实验报告.docx(14页珍藏版)》请在冰豆网上搜索。
UML实验报告
《软件建模原理》实验报告
学院:
计算机学院
班级:
姓名:
学号:
授课老师:
实验一:
用例建模
[实验日期]2011年6月22日
[实验目的]
·掌握客户需求分析的方法和步骤
·了解以用例驱动的软件开发方法
·识别并编写用例
·掌握用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绘制的,与待开发用例相关的概念模型。
销售管理系统概念模型
[实验总结]
②实验中的问题和提高:
对自己的分析或设计进行评价,指出合理和不足之处,提出改进的方案。
③收获与体会:
筛选概念的要点;区分概念与属性的要点;关联取舍的要点;画图时如何防止关联重名。
实验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
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 实验 报告
![提示](https://static.bdocx.com/images/bang_tan.gif)