软件工程与计算II重点整理(第6-7章)

第六章需求分析方法

1.建立用例图

参与者是与开发的系统进行交互的用户或其他系统等角色

用例图中一个单一的参与者可以代表多个用户（或系统）

一个单一的用户（或系统）可能扮演多种角色

参与者不一定是人，例如，需要从当前系统获取信息的外部系统也是参与者

步骤：1）目标分析与解决方向确定 2）寻找参与者 3）寻找用例 4）细化用例

【示例1】

×××连锁商店是一家刚刚发展起来的小型连锁商店，其前身是一家独立的小百货门面店。

首先是随着商店规模的扩大，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重，导致流失客源。其次是商店的商品品种增多，无法准确掌握库存，商品积压、缺货和报废的现象上升明显。再次是商店面临的竞争比以前更大，希望在降低成本，吸引顾客，增强竞争力的同时，保持盈利水平。

BR1：在系统使用6个月后，商品积压、缺货和报废的现象要减少50%

BR2：在系统使用3个月后，销售人员工作效率提高50%

BR3：在系统使用6个月后，运营成本要降低15%

范围：人力成本和库存成本，度量：检查平均员工数量和平均每10,000元销售额的库存成本

BR4：在系统使用6个月后，销售额度要提高20%，最好情况：40%，最可能情况：20%，最坏情况：10%

SF1：分析商品库存，发现可能的商品积压、缺货和报废现象

SF2：根据市场变化调整销售的商品

SF3：制定促销手段，处理积压商品

SF4：与生产厂家联合进行商品促销

SF5：制定促销手段进行销售竞争

SF6：掌握员工变动和授权情况

SF7：处理商品入库与出库

SF8：发展会员，提高顾客回头率

SF9：允许积分兑换商品和赠送吸引会员的礼品，提高会员满意度

SF10：帮助收银员处理销售与退货任务

从上述特性可以发现涉及的用户类别：总经理，客户经理，收银员，管理员

总经理的目标有：产品调整（增删改产品信息），特价策略制定（增删改特价策略），赠送策略制定（增删改赠送策略），库存分析；（分析可能的商品积压）

客户经理的目标有：会员管理；（会员发展、礼品赠送），库存管理；（商品入库、出库和库存分析）

收银员的目标有：销售处理（销售），退货；（退货）

管理员的目标有：用户管理（增删改用户信息）

如果用例的粒度不合适就需要进行细化和调整。判断标准是：用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务。
不要将没有业务价值（而是技术实现需要）的事件作为用例（例如，登录（安全性需求）、输入/输入数据检查（数据需求或者业务规则）、连接数据库、网络传输等等）
不要将没有独立业务价值的单个操作（仅仅是技术实现上独立）作为用例，例如删除、增加、修改、保存

总经理的目标有：特价策略制定、赠送策略制定两个用例的业务目的、发起源和过程基本相同，仅仅是业务数据不同，所以可以合并为一个用例销售策略制定。

客户经理的目标有：会员管理用例有两个明显不同的业务事件，可以被细化为发展会员和礼品赠送2个更细粒度的用例。

客户经理的库存管理用例也有三个不同的业务目标：出库、入库和库存分析，所以也应该细化为三个用例商品出库、商品入库和库存分析，其中库存分析用例与总经理的库存分析用例相同。

【常见错误】

不要将用例细化为单个操作

不要将单个步骤细化为用例

不要将片面的一个方面细化为用例

不要将“登录”、“数据验证”、“连接数据库”等没有业务价值的内容作为用例

【示例2】

网上书店系统（OBS）是一个基于web的应用程序，允许用户浏览和购买网上产品。该应用程序支持网上购物车的概念，类似于其他网上零售商，如Amazon.com,。该系统的结账功能将集成信用卡交易处理以及内部计费系统。该系统还提供管理员视图，允许授权的员工查看和管理产品、用户和订单。

用户：购买、浏览

员工：查看用户、订单、产品管理

管理员：授权

信用卡：结账

内部计费：结账

注意：内部计费指的是单位内部，而不是系统内部

2.建立分析类图（概念类图／领域模型）

注意：与设计类图有所不同，分析类图关注现实世界问题域，而不是软件系统的内部构造机制；
类型、方法、可见性等复杂的软件构造细节不会在概念类图中，不允许出现与现实无关的内容

对象：标识（对象自治、对象请求协作）、状态（存储数据，如密码、名称……）、行为（利用数据做什么）

链接：对象间交互的路径（a拥有b的引用——a拥有b的可见性——a可以导航到b）

类：对象的集合

关联：潜在的链接抽象

要写出分析的步骤：

1）识别候选类（名词分析法）

2）确定概念类（看是否满足既有状态又有行为）
既需要维持一定的状态，又需要依据状态表现一定的行为——确定为一个概念类

如只需要维护状态，不需要表现行为——其他概念类的属性

不需要维护状态，却需要表现行为——首先重新审视需求是否有遗漏，因为没有状态支持的对象无法表现行为；如果确定没有需求的遗漏，就需要剔除该候选类，并将行为转交给具备状态支持能力的其他概念类

既不需要维护状态，又不需要表现行为——应该被完全剔除

3）识别关联（文本中提取出“名词＋动词＋名词”的结构）

第一标准是满足需求的要求，第二标准是现实状况

4）识别重要属性

概念类图只需要用到四种关系线：

聚合关系不必可以使用，但是组合关系要适当的使用

继承关系、组合关系、聚合关系、普通关联

【示例1】

1、如果是会员，收银员输入客户编号（属性、无行为）

2、系统显示会员信息（就是会员），包括姓名（属性、无行为）与积分（属性、无行为）

3、收银员输入商品标识（商品属性、无行为）

4、系统记录并显示商品信息（有状态、有行为），商品信息包括商品标识、描述、数量、价格、特价（如果有商品特价策略的话）和本项商品总价（商品属性）

5、系统显示已购入的商品清单（有状态、有行为），商品清单包括商品标识、描述、数量、价格、特价、各项商品总价和所有品总价（商品属性）

收银员重复3-5步，直到完成所有商品的输入

6、收银员结束输入，系统计算并显示总价（存储在账单中，有行为），计算根据总额特价策略（有状态、有行为）进行

7、系统根据商品赠送策略和总额赠送策略计算并显示赠品清单（要），赠品清单包括各项赠品的标识、描述与数量（不要）

8、收银员请顾客（就是会员）支付账单（有状态、有行为）

9、顾客支付，收银员输入收取的现金数额（有属性、无行为、不要）

10、系统给出应找的余额（有属性、无行为、不要），收银员找零

11、收银员结束销售，系统记录销售信息（有状态、有行为）、商品清单、赠品清单和账单信息，并更新库存（有状态、有行为）

12、系统打印收据（根据需求，如果是一次性就无状态无行为，如果是丢了还可以打印就有状态有行为）

注意：一切看需求。

（1）若商品ID必须符合标准，则ID有状态、有行为

（2）若商品数量单位不同，则单位换算的职责交给数量，有状态、有行为

（3）若商品价格按照国际汇率有不同定位，则价格有状态、有行为

【示例2】

ATM系统通过显示屏，输入键盘（有数字和特殊输入按键），银行卡读卡器，存款插槽，收据打印机等与用户交互。客户使用ATM机存款，取款，余额查询，对账户的更新交由账户系统的一个接口来处理。安全系统将为每个客户分配一个PIN码和安全级别。每次事物执行之前都需要验证PIN码。将来，银行计划使用ATM机支持一些常规操作，例如使用地址和电话号码修改。

分析：显示器、按键、读卡器、存款插槽、收据打印机不属于现实世界

客户：属性：PIN、地址、电话号码、安全级别

账户：余额

交易

【示例3】

顾客向系统提起查询请求

系统根据请求为顾客提供一个CD的推荐列表

顾客在推荐列表中选定一个CD，然后要求查看更详细的信息

系统为顾客提供选定CD的详细信息

顾客购买选定CD.

顾客离开

分析：

查询请求：有状态、有行为

顾客和CD：看戏球，不确定是否存储详细信息

推荐列表：有状态、有行为（增删改）

3.建立系统顺序图（交互图）

步骤：1）确定上下文环境 2）根据用例描述找到交互对象 3）按照用例描述中的流程顺序逐步添加消息

同步消息、异步消息、返回消息

注意：

（1）异步消息的箭头无论是从用户到系统还是从系统到用户都是一样的

（2）opt标签表示可选；loop标签表示循环，要在旁边用［］内写循环条件；alt标签表示候选（基本上只会放一次返回消息），每一种可选分支之间要用虚线分割，而且在表示执行态的圆柱上面要写监护条件，放在［］里面。

4.建立状态图

状态: 一组观察到的情况，在一个给定的时间描述系统行为

状态转换: 从一个状态到另一个状态的转移

事件: 导致系统表现出可预测行为的事件

活动: 作为产生转换的结果而发生的过程

步骤：1）确定上下文环境 2）识别状态 3）建立状态转换 4）补充详细信息，完善状态图

注意：并不是所有的状态图都有开始态和结束态，开始态通常只有一个，结束态可以有多个

【示例】明确状态图的主体：用例UC1销售处理。

空闲状态（开始状态）：收银员已经登录和获得授权，但并没有请求开始销售工作的状态；

销售开始状态：开始一个新销售事务，系统开始执行一个销售任务的状态；

会员信息显示状态：输入了客户编号，系统显示该会员信息的状态；

商品信息显示状态：刚刚输入了一个物品项，显示该物品（和赠品）描述信息的状态；

列表显示状态：以列表方式显示所有已输入物品项（和赠品）信息的状态；

错误提示状态：输入信息错误的状态；
账单处理状态：输入结束，系统显示账单信息，收银员进行结帐处理的状态。

销售结束状态：更新信息，打印收据的状态。