WWumL实验Word文件下载.docx
- 文档编号:17233761
- 上传时间:2022-11-29
- 格式:DOCX
- 页数:19
- 大小:190.65KB
WWumL实验Word文件下载.docx
《WWumL实验Word文件下载.docx》由会员分享,可在线阅读,更多相关《WWumL实验Word文件下载.docx(19页珍藏版)》请在冰豆网上搜索。
(也
可采用教师指定的题目:
“企业综合信息管理系统”中的“进销存管理子系统”,但要仔细研读“企业现状”、“系
统目标、范围和功能要求”等文字说明)。
(2)用例分析。
确定系统范围和边界、确定参与者、确定用例。
分层绘制用例图、描述用例。
画图原理:
采用Rose软件进行用例建模必须建立在完好的系统用例分析基础之上.只有做好系统用例分析,系统用例建模才
能这到预期的效果。
(1)分层绘制用例图,每层采用“包”进行管理。
(2)以“企业综合信息管理系统”->
“进销存管理”子系统->
“销售管理”->
“合同管理”->
“收款单处
理”为主线,完成附录2中的操作过程(亦可选择“企业综合信息管理系统”->
“库存管
理”->
“原材料出库”->
“领料单处理”主线)
[实验结果]
采用ROSE绘制的“企业综合信息管理系统”的1级用例图,以及其中的“进销存管理”用例的文字描述。
用例文字
经理查询,调度生产,管理财务,综合支持,管理经销村
《学生填写》
采用ROSE绘制的针对“进销存管理”用例的2级用例图,以及其中的“库存管理”用例的文字描述。
采用ROSE绘制的针对“库存管理”用例的3级用例图,以及其中的“原材料出库”用例的文字描述。
采用ROSE绘制的针对“原材料出库”用例的4级用例图,以及其中的“处理领料单”用例的文字描述。
用例的文字描述:
用例编号:
05010303(共有4层用例图结构,采用8位编码,每层用2位数字)
用例名:
收款单处理
执行者:
人执行者:
销售合同管理员、客户、公司经理,
系统执行者:
“财务管理”子系统、“仓库管理子系统”、“生产调度管理”子系统。
目的:
对于已签订生效的销售合同,财务管理部门负责收取客户货款,并开具收款单。
“收款单处理”用例要做的工作
是:
核查收款单并从仓库提取客户订购的产品,核查并发货给客户。
类型:
主要的、基本的
级别:
4级
典型事件描述:
1.核对“收款单”:
以批处理方式对财务部门传送过来的收款单(客户的付款证明),根据收款单上的合同编号自动
找到对应的销售合同,将收到的货款金额填写到合同中;
2.核对“货物清单”:
系统根据客户付款金额和合同上标明的货物种类、数量和单价,与仓库库存货物清单进行
核对。
3.如果仓库中有合同规定数量的货物,从仓库提取客户订购的产品,核查并发货给客户。
转到5执行。
4.如果仓库中现存的货物少于合同规定的数量,应向“生产调度部门”发送“产品生产申请单”,要求立即组织生
产。
当所要的产品生产出来并入库后,转到步骤2执行。
5.将发送货物的数量填写到相应销售合同中。
6.退出系统。
与其他用例的关联:
该用例有异步的多进程操作,涉及到“生产调度部门”和“仓库管理部门”的用例。
异常事件流处理:
1.过程描述1中如果出现“收款单”找不到相应的“执行期采购合同”(合同编号不能匹配)时,显示警告提示用
户。
并将该“收款单”作出标记退回“财务部门”。
实验2分析建模
[实验日期]2011年5月15日
(1)理解面向对象系统分析和对象类建模(概念建模)的概念
(2)了解和掌握面向对象系统分析的方法和步骤
(3)了解和掌握寻找待开发系统中类(概念)的方法和技巧
(4)掌握使用ROSE绘制概念模型的方法
在用例分析的基础上,选择第一个迭代周期打算开发的用例,建立相关的概念模型。
(1)使用概念目录列表(见下图)和非正式分析法(识别出问题域的文本描述中的名词短语,然后将其作为概念或
属性的候选对象。
)相结合的方法识别概念。
因此,待开发用例的文字描述中,名词可能成为概念或属性的候
选对象;
表示行为的动词词组有可能成为事务型或过程型对象;
形容词词组有可能对应抽象的名词型概念。
采用的技术基本上就是:
ER图+纯行为+OO的聚合、泛化。
(2)最终关联的数量介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型(从通用关联列表中派生出
的,见下图)】之间。
(1)识别关键用例作为第一个迭代周期的开发目标(一般是在用例图中被依赖得比较多的用例)。
可以选“企业综合信息管理系统”->
“库存管理”->
“领料单
处理”主线中的“领料单处理”用例;
也可以选“企业综合信息管理系统”->
“销售
管理”->
“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。
(其实,选“库
存管理”主线更合适;
当然,如果要实现产销一体化,以销售订单指导生产和采购,并实现零库存目标,那么一
切工作就以销售管理为中心。
即便如此,首选“增加合同”用例也更为合适。
)
(2)识别概念和重要属性。
(3)建立概念间的关联。
(1)可以采用“逻辑视图”下的类图描述概念模型,只不过每个类中只有类名和属性,没有方法。
在概念建模
阶段也没有必要确定属性的类型和访问属性。
(2)概念间的关联可以采用一般关联(无方向实线),当然,对于聚合和泛化,应采用相应的连线(组合:
实
心菱形+实线;
聚合:
空心菱形+实线;
泛化:
空三角形+实线)
(0)前提条件:
第一个迭代周期可以选“企业综合信息管理系统”->
“原材料出库”->
“领料单处理”主线中的“领料单处理”用例;
“进销存管理”子系统->
“收款单处理”主线中的“增加销售合同”
或“收款单处理”用例。
做好与此用例相关的概念模型
(1)建立相关的概念模型的基础上,在“逻辑视图”下的类图中描述概念模型,可以直接在类图main中绘制,
也可采用类似用例图中用过的分包机制
(2)绘制概念和重要属性。
(3)绘制概念间的关联。
采用ROSE绘制的,与待开发用例相关的概念模型。
给出上述概念模型建立过程中,概念筛选与关联取舍的详细过程和理由。
使用概念目录列表(见下图)和非正式分析法(识别出问题域的文本描述中的名词短语,然后将其作为概念或属性的候选对象。
因此,待开发用例的文字描述中,名词可能成为概念或属性的候选对象;
《UML与软件建模》实验3设计建模
(1)
[实验日期]2011年5月20日
(1)理解顺序图的基本概念
(2)了解和掌握软件工程中用例逻辑时序的分析方法
(3)掌握使用ROSE创建顺序图的方法
在用例模型和概念模型的基础上,对首选的用例进行事件分解,识别出系统事件(系统操作),(并写出契约
的后置条件);
为每个系统事件画顺序图,为对象分配职责。
原理:
(1)在系统顺序图中,所有的系统都被当成黑盒子看待,顺序图的重点是参与者发起的跨越系统边界的事件。
(2)系统事件是由某参与者发起的指向系统的输入事件。
一个事件的发生能够触发一个响应操作的执行。
(3)请仔细研究下图,考察它是如何从左边的"
购买商品"
用例的文字描述中分解出3个系统事件的。
(4)参照用例模型和概念模型,为每个系统操作估计后置条件。
(实例创建、形成关联、属性修改)
(5)按照设计模式为对象分配职责。
(1)分析首选用例的文字描述,按事件进行分解,识别出系统事件。
(下面以“企业综合信息管理系统”->
“进
销存管理”子系统->
“收款单处理”主线中的“收款单处理”用例为
例)。
我们暂不考虑批处理。
第一个核对,因为要将“货款金额填写到合同中”。
后置条件显然有“销售合同”的属性修
改。
此合同显然已经存在,不需要创建,但需要根据合同编号find,然后形成关联。
第二个核对需要根据合同明
细到仓库的“存货明细”(概念模型中还没有)中去查。
此核对发生前虽然敲了一下键盘,但随后并没有新的消息
穿越系统边界,因此这仍然是同一个系统事件。
先考虑成功场景,应该向库存系统发提货单(概念模型中还没有)
就结束了。
后续的削减库存(核销)、预警显然不是销售管理员的职权,并且真正的核销必须由仓库的发货人执行,
才能保证货帐一致。
并且“生产厂家”与“邮购公司”的运作方式不同,后者是自己的员工取货并邮寄,而前者
还有可能是来人来车取货,这时仓库收到取货单后并不能立即自动处理(开发货单),必须等取货人到达才能处理。
根据题意,本项目应该是“生产厂家”模式。
这又存在一个问题,如果在开出提货单后不修改库存,可能影响并
发用户和后续付款单的处理。
所以有必要设计一个“临时存货明细”(概念模型中还没有)(不是真实的“存货明
细”)供修改,何时按存货明细”进行刷新应该是库存管理系统的事(比如每天夜里刷新,但因为雨雪天气,取货
人迟迟不提货,是提货单作废(相当于退回销售系统,付款单变为未处理)还是就强行刷新(此时有冲突危险)?
失败场景。
向“生产调度部门”发送“产品生产申请单”。
如果是专门为此单进行生产,那么还应该有库存系统发
来的“产品入库通知处理”用例来调用本用例进行发货。
本题显然一概根据付款单运作,因此如果失败,就不处
理付款单,但按日期把它排在待处理付款单的前面。
从前面的分析来看,就一个系统事件,我们就命名为“付款
单处理(pb:
付款单)”
(2)为每个系统事件估计后置条件。
(以上已做了部分分析)
(3)按设计模式进行设计。
首先考虑控制者,领域控制者选参与者角色,即“销售人员”。
为了避免使用FORM,窗口等表示层对象,我们人造一
个类”应用协调者”向控制者发送消息。
采用ROSE绘制的,与待开发用例相关的系统顺序图。
采用ROSE绘制的,每个系统事件对应的顺序图。
给出顺序图建立的详细过程和理由。
1.确定交互和涉及的对象;
2.顺序图排列的原则;
3.消息传递。
合同付款单管理员启动付款单处理用例开始工作,对财务出处传送来的多个付款单依次用相应的销售合同进行核对。
核对无误后,将每个合同约定的销售货物清单与仓库的存货单进行核对,如果品种规格,数量满足要求,在仓库的存货项目中核销销应品种货物的数量。
在核销的同时,仓库对这些货物进行自我检查,是否存货数量少于预警线,若少于,打印预警货物清单。
在2.系统顺序图下new一个用例,命名为“[实现]付款单处理”,版型改为“用例实现”。
在其下再new一个顺序图,命名为“付款单处理”。
在2.系统顺序图下new两个类:
应用协调者和System。
双击顺序图开始绘图。
下面在2.设计模型下绘制顺序图。
仿照下面new一个用例实现,再在下面new一个类图和一个顺序图,后者命名为“付款单处理”;
前者命名为“1.销售管理子系统设计类图”,可以用来画新的类图(设计类图,有别于概念模型),可以将
前面分散在各个地方的类重新建一遍,并加上“[设计]前缀”,如“[设计]付款单”,以下并没有这样做,仍然沿用概念
模型中的类。
进入类图,可以把概念模型中的东西selectall,copy,然后paste过来。
加上新增的类“提货单”,“临时存货明细”。
进入顺序图,开始设计
实验4设计建模
(2)
[实验日期]2011年5月27日
(1)理解面向对象类之间关联关系的概念
(2)了解和掌握分析类之间的关联关系的方法
(3)了解和掌握待开发系统中类之间关联关系的分析方法
(4)完善设计类图,掌握使用ROSE对关联进行建模的过程
根据设计建模
(1)中的交互分析,进一步设计关联和对象可见性(补上遗漏的关联),完善设计类图。
(1)关联关系描绘了给定类的对象个体之间的语义连接,是类与类之间的连接。
关联可以分为一般关联、聚合关
联、组合关联和依赖关联等。
(2)一般关联包括一对类的二元关联及多个类之间的多元关联。
(3)聚合(Aggregation)表示整体和部分之间较强的关联关系,聚合关系的多重性大
于1,则称为共享聚合。
(4)组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系,它们之间是一对一的关系,即同生死
共存亡,组合关系不能共享。
(5)依赖关系是一种使用关系,表现为一个对象仅仅调用了另一个对象的服务。
可以使用下列的指导方针列出暂时性的关系:
(1)存在两个或两个以上的类相互之间就可能有关联。
(2)类的操怍(成员函数)的参数列表里出现其他类的对象。
(3)一个类包含另一个类的对象(对象成员)。
(4)根据一般常识可能会出现的关联。
(1)分析已建立的设计类图和交互图,进一步设计关联和对象可见性(补上遗漏的关联)。
(下面以“企业综合
信息管理系统”->
“收款单处理”主线中
的“收款单处理”用例为例)。
在销售管理子系统中,定义的各个类之间一般都有关系发生。
销售人员和客户(大客户)共同签署销售合同,
销售合同中涉及到多种可以销售的产品,合同经公司经理审查并签字后该合同才能生效,付款单需要客户付款,
销售人员签发催款单向客户催缴欠款,销售人员制定销售计划,销售人员要检查督促执行期合同按合同执行、履
约,履约后的合同转到履约合同数据库存档备查等等。
例如:
(a)销售人员与客户:
一般关联,多对多
(b)销售合同与合同明细,销售计划与计划明细:
组合。
(c)付款单与客户:
依赖关系。
《如果付款单类中有“统计付款金额(客户类客户对象)”操作的话,付款
单类就依赖客户类》
(2)完善设计类图
(3)聚合(Aggregation)表示整体和部分之间较强的关联关系,聚合关系的多重性大于1,则称为共享聚合。
(1)在关联和对象可见性分析的基础上,补充一般关联、组合,泛化、依赖
(a)一般关联关系要注意关联的命名以及哪个是roleA哪个是roleB。
(b)一般关联选中roleBdetail中的aggregate,就变成聚合;
再选中byvalue就变成组合。
(c)依赖画虚线箭头。
完善的设计类图(采用ROSE绘制的设计类图),包括关联的多重性,类中重要属性和方法等。
给出关联分析的详细过程和理由。
分析已建立的设计类图和交互图,进一步设计关联和对象可见性如:
实验总结:
一、规则
命名:
也就是为事物、关系和图起名字。
和任何语言一样,名字都是一个标识符
范围:
与类的作用域相似.
可见性:
Public,Protected,Private,Package
二、UML公共机制
1、规格描述
在图形表示法的每个部分后面都有一个规格描述(也称为详述),它用来对构造块的语法和语义进行文字叙述。
这种构思,也就使可视化视图和文字视图的分离:
2、UML修饰与通用划分
在为了更好的表示这些细节,UML中还提供了一些修饰符号,例如不同可视性的符号、用斜体字表示抽象类
UML通用划分:
1)类与对象的划分:
类是一种抽象,对象是一个具体的实例
2)接口与实现的分离:
接口是一种声明、是一个契约,也是服务的入口;
实现则是负责实施接口提供的契约
3、UML扩展机制
构造型:
在实际的建模过程中,可能会需要定义一些特定于某个领域或某个系统的构造块
标记值则是用来为事物添加新特性的。
标记值的表示方法是用形如“{标记信息}”的字符串
约束是用来增加新的语义或改变已存在规则的一种机制(自由文本和OCL两种表示法)。
约束的表示法和标记值法类似,都是使用花括号括起来的串来表示,不过它是不能够放在元素中的,而是放在相关的元素附近。
4、UML视图和图
类图描述类、类的特性以及类之间的关系
对象图 描述一个时间点上系统中各个对象的一个快照
复合结构图 描述类的运行时刻的分解
构件图 描述构件的结构与连接
部署图 描述在各个节点上的部署
包图描述编译时的层次结构
用例图 描述用户与系统如何交互
活动图 描述过程行为与并行行为
状态机图描述事件如何改变对象生命周期
顺序图 描述对象之间的交互,重点在强调顺序
通信图 描述对象之间的交互,重点在于连接
定时图 描述对象之间的交互,重点在于定时
交互概观图 是一种顺序图与活动图的混合
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WWumL 实验
![提示](https://static.bdocx.com/images/bang_tan.gif)