WWumL实验Word文件下载.docx

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视图和图

类图描述类、类的特性以及类之间的关系

对象图　描述一个时间点上系统中各个对象的一个快照 

复合结构图　描述类的运行时刻的分解

构件图　描述构件的结构与连接

部署图　描述在各个节点上的部署　

包图描述编译时的层次结构

用例图　描述用户与系统如何交互

活动图　描述过程行为与并行行为

状态机图描述事件如何改变对象生命周期

顺序图　描述对象之间的交互，重点在强调顺序　

通信图　描述对象之间的交互，重点在于连接

定时图　描述对象之间的交互，重点在于定时

交互概观图　是一种顺序图与活动图的混合