实验指导书一第周Word文件下载.docx

实验指导书一第周Word文件下载.docx

《实验指导书一第周Word文件下载.docx》由会员分享，可在线阅读，更多相关《实验指导书一第周Word文件下载.docx（12页珍藏版）》请在冰豆网上搜索。

一、超市进销存管理系统的需求分析

1、系统功能需求

超市进销存管理系统要求能对超市的进、销、存行为进行管理，并且能根据不同权限的系统用户的需求进行报表的生成和查询，为超市管理者的决策提供协助。

（1）营业管理

1）营业员接收顾客订购，输入顾客购买的商品，计算总价；

2）顾客选择现金或者信用卡付款；

3）营业员保存顾客购买的商品的记录；

4）营业员打印销货清单给顾客。

（2）库存管理

1）库存管理员每天进行盘点（统计）一次；

2）库存管理员当发现库存商品有损坏时，及时到相关部门报损；

3）在商品到货时，库存管理员检验商品是否合格，并对合格的商品进行验收入库，退回不合格的商品；

（3）进货管理

1）进货员用新商品供应商信息更新供应商数据库的信息；

2）进货员统计库存商品是否低于库存下限，然后制作订货单；

3）进货员订购货物，并接收货物，同时协助货物入库。

（4）会计活动

1）会计人员根据订货单支付货款；

2）会计人员根据所有营业数据结收营业金额，并收取现金；

3）会计人员定期进行所有数据统计，并制作统计报表；

（5）经理管理

1）经理对日常流程进行审核，包括审核订货单、审核会计报表、审核汇总订单表；

2）经理对各类员工进行人事调动等人事管理；

3）经理在促销期间或节日期间，注明相关商品的促销价格和促销时段；

4）经理按市场情况经常变动商品价格。

2.设计方法、思路和主要技术

RUP开发过程是“用例驱动”的开发过程，在RUP开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型；

然后对需求模型进行分析、整理、验证，建立分析模型；

最后以分析模型为基础，设计系统，来满足这些用例模型的要求。

因此，软件的整个开发过程，就是建立模型的过程，从建立用例模型开始，其次是分析模型，接着是设计模型和实现模型，在建立了这些模型之后，还将根据用例模型设计出测试模型来对系统进行验证。

所有模型的建立过程不是线性转变的，而是是一个迭代、增量的开发过程。

也就是在整个项目开发周期中，将会多次经过这五个模型的迭代、修改、删除、优化、精化的过程。

下面是对5个模型的定义：

●用例模型：

能够有效地帮助开发人员发现真正的功能需求，并用UML设计语言来描述需求，如，用例图。

●分析模型：

通过协作图来描述用例，检验、验证用例的一致性、正确性、完备性、可行性。

分析的结果表示为类图、包图。

●设计模型：

在分析模型的基础上，把分析阶段的类分解为语言能实现的软件类，利用各种实现技术构造系统、子系统；

并把设计类进行分组，打包、定义子系统和类的接口。

这一阶段的产品有：

（类图、对象图、包图、构件图）

●部署模型：

定义可计算节点系统的物理结构，并验证运行在这些节点上的构件想法是否实现了用例。

（构件图、部署图）

●测试模型：

根据用例中所描述的功能来构建测试模型。

采用用例技术的优点有2点：

一是，用例表达了用户对软件的目标要求，用例是系统向其用户提供的增值功能。

二是，用例很直观，用户和客户根本无法了解复杂符号，而用例这种简单、自然的表述法可以使其易于阅读，并提出修改意见。

根据以上确定的设计方法，我们使用RationalRose2003进行建模及设计，确定设计思路如下：

1．在UseCaseView中建立三个层次模型，逐步分析出用例图，建层如下图：

2．在LogicalView中也建立三个层次模型，该层内容是在UseCaseView分析的基础上逐步设计出具体的类及其类关系，数据结构，并根据需要确定时序图、协作图、活动图、状态图等，建层如下图：

二、系统的UML建模

1、系统的用例图

先学习一下用例分析的方法。

用例图是描述用例、参与者及其关系的图。

与所有UML的其它图一样，用例图可以包括注释、约束。

下图是棋牌管理系统对应的用例图。

图中的元素包括：

参与者、用例、一个方框和一些表示关系的连接线，所有的用例都位于方框之内，该方框称为“系统边界”。

方框内是棋牌管理系统的多个用例，方框外是外部参与者。

用例的表示

用例是对一组场景共同特征的抽象，即，用例是对一组场景共同行为的抽象，场景就是用例的一次完整的、具体的执行过程。

用例与场景的关系，如同类与对象的关系，用例应该给参与者带来可见的价值。

1．场景

在系统中，按照某个顺序执行的一系列相关的动作后，实现了某种功能，把完成了这一功能的操作的集合称为场景。

“场景”就是用户使用系统的一个实际的、特定的场面。

下面列举一个场景例子。

开发者与用户、客户进行交流，构建场景和用例规格描述。

一个场景就是描述用户与系统之间的一系列交互活动，描述了系统一次具体执行的行为路径，即，一次完整的事件流。

如，小刘通过银行柜员机（ATM系统）取款3000元的场景，如下图所示。

开发者获取需求的步骤是：

第一步，开发者首先将用户的工作流程表示为场景，然后，将同一类场景抽象为用例，以描述系统的功能；

第二步，客户和用户通过审查场景，并测试开发者提供的原型系统，以验证和确认需求规格说明书。

第三步，当系统需求定义成熟和稳定后，开发者和客户共同对需求规格说明进行确认，包括，系统的功能性需求、非功能需求、用例和场景在内的需求确认。

识别参与者

需求获取的第一步是，标识参与者。

这一服务定义了系统的边界，并从开发者要考虑的系统中，找出所有的观察点。

开发者通过回答下面问题来寻找参与者：

系统支持哪些用户组完成他们的工作？

哪一个用户组执行系统的主要功能？

次要功能由哪一个用户组完成，比如维护或管理？

与该系统进行交互的外部硬件和软件系统是哪些？

在确定具体参与者时，可以通过以下一些常见的问题来帮助分析：

谁使用这个系统、谁安装这个系统、谁启动这个系统、谁维护这个系统、谁关闭这个系统、哪些其他的系统使用这个系统、谁从这个系统获取信息、谁为这个系统提供信息。

是否有事情自动在预计的时间发生（说明有定时器

系统是否需要与外部实体交互以帮助自己完成任务。

一旦参与者被标识出来后，需求获取的下一步活动是，决定每一个参与者将访问的功能。

识别用例

在需求分析时，当标识出了参与者以后，下一步就是识别用例，寻找用例最好的方法是，从参与者的角度看，参与者是如何使用系统的，通过回答以下问题，可以识别用例：

每个参与者希望系统提供什么功能？

系统是否存储和检索信息？

如果是，由哪个参与者触发？

系统改变状态时，是否通知参与者？

哪些外部事件触发系统？

哪个参与者发出事件？

通过回答以上问题，得到一个候选用例列表。

标识用例间的关系

下面以一个“棋牌馆管理系统”的局部用例模型为例，说明用例之间的三种关系：

包含关系、扩展关系、泛化关系

该系统的主要功能是：

以Internet的形式向客户提供座位预订服务，如果暂时无法获取座位信息时，允许客户进入“等候队列”，当有人退订之后将及时通知客户。

另外，该系统还将为总台服务员提供座位安排以及结帐的功能，要求能够支持现金和银行卡两种结帐方式。

在图中可以看到4种元素：

参与者、用例、一个方框和一些表示关系的连接线。

不难知道该图中有客户、总台服务员和银联POS系统3个参与者，还包括预订座位、安排座位、办理结帐等8个用例。

下面我们来理解上图表示的用例图的含义。

这张用例图定义了三个基用例：

预定座位、安排座位和处理结帐。

•1）客户通过Internet启动“预定座位”用例，在“预定座位”用例的执行过程中，将“检查座位信息”（包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。

•2）在客户到棋牌馆时，总台服务员启动“安排座位”用例，在执行过程中，将启动包含用例“检查座位信息”。

•3）当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，后一个用例将通过与外部系统“银联POS系统”交互完成。

对用例的描述有两种方法：

用例图和用例描述。

用例图只能描述了系统的大概功能，是一种视图；

用例描述才能表示系统活动的细节。

用例描述又分为用例概述和用例详述．

用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事。

用例描述模板

为了说明一个用例的行为，描述一个用例的关键要素包括：

用例何时开始（前置条件）、何时结束（后置条件）、参与者何时与用例交互、交互了什么信息，以及用例执行的基本事件流和扩展事件流。

1．事件流

事件流就是用例执行时，由一序列活动组成的控制流。

事件流分为基本事件流和扩展事件流两种．下面是事件流模型，如图下所示．

2．用例描述模板

用例描述有两种格式：

一种是纯文本格式，另一种是表格形式，下表所示就是一个经典的表格式用例描述模板，其中加粗显示的是必须编写的部分。

用例编号

[为用例制定一个唯一的编号，通常格式为UCxx]

用例名称

[应为一个动词短语，让读者一目了然地知道用例的目标]

用例概述

[用例的目标，一个概要性的描述]

范围

[用例的设计范围]

主参与者

[该用例的主Actor，在此列出名称，并简要的描述它]

次要参与者

[该用例的次要Actor，在此列出名称，并简要的描述它]

项目相关人

利益说明

利益

[项目相关人员名称]

[从该用例获取的利益]

……

前置条件

[即启动该用例所应该满足的条件。

]

后置条件

[即该用例完成之后，将执行什么动作。

成功保证

[描述当前目标完成后，环境变化情况。

基本事件流

步骤

活动

1

[在这里写出触发事件到目标完成以及清除的步骤。

2

……（其中可以包含子事件流，以子事件流编号来表示）

扩展事件流

1a

[1a表示是对1的扩展，其中应说明条件和活动]

1b

子事件流

[对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。

规则与约束

[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]

•1）前置条件：

指在用例启动时参与者（actor）与系统应置于什么状态，这个状态应该是系统能检测到的、可观测的。

•2）后置条件：

用例结束时系统应置于什么状态，这个状态也应该是系统能检测到的、可观测的。

•3）基本事件流：

基本事件流是对用例中常规、预期路径的描述，也被称为Happyday场景，这是大部分事件所遇到的场景，它将体现系统的核心价值。

•4）扩展事件流：

主要是对一些异常情况、选择分支进行描述。

用例描述分三个步骤：

第一步，对用例概要描述，第二步，对用例详细描述，第三步，补缺漏。

1、用例概要描述

在最初的迭代中，应该对每个用例都写出概要描述。

概要描述阶段中，在填写各个部分的内容时，应分别注意以下几个要点：

•用例名称：

应该与用例图相符，并写上其相应的编号。

•简要说明：

对该用例对参与者所传递的价