软件工程--需求分析与用例模型

面向对象分析(ObjectOrientedAnalysis，简称OOA)

分析和理解问题域，找出描述问题域所需的类和对象，分析它们的内部构成和外部关系，建立独立于实现的OOA模型，暂时忽略与系统实现有关的问题。

主要使用UML中的以下几种图描述OOA模型:

• 用例图
• 类图
• 活动图(或泳道图)
• 时序图(或协作图)

用例模型:

概念

• 用例图是显示一组用例、参与者以及它们之间关系的图
• 用例图用来描述用户的需求，他从用户的角度描述系统的功能，并指出各功能的操作者，强调谁在使用系统，系统为参与者完成哪些功能。

■参与者actor(线条人)

• DFD数据流图的外部实体=用例图的参与者（线条人）
• 位于目标系统的外部，指用户在系统中扮演的角色，代表一类使用系统某个功能的人或事。

参与者有三大类:

• 系统用户
• 与建造的系统交互的其它系统

UML中的符号表示:

• 参与者是人，用“小人图”
• 参与者是某个系统时用“方框图”。

■用例(椭圆)
■用例间的关系(用例之间的线)
■系统(方框)--只圈系统功能（可以没有）
 

创建用例建模的步骤:

• 确定系统的范围和边界
• 确定系统的用例和参与者

1. 识别参与者
2. 识别用例

• 用例说明
• 确定用例之间的关系
• 建立用例图并定义用例图的层次结构
• 评审用例模型

如何识别参与者

• 谁使用系统的功能?
• 谁从系统获取信息?
• 谁向系统提供信息?
• 谁来负责维护和管理系统以保证其正常行?
• 系统需要访问哪些外部硬件设备?
• 系统需要与哪些其它软件系统进行交互?

PS.管理员的功能不能全部都连，只连管理

如何识别用例(usecase)

 找到参与者后，据此来确定系统的用例，主要考虑各个参与者需要系统为其提供什么样的服务(或功能)。

• 参与者用系统完成什么任务?
• 参与者是否会在系统中创建、修改、删除、访问、存储数据?若是，参与者又是如何完成这些操作的?
• 参与者是否会将外部的某些事件通知给系统?
• 系统是否会将内部的某些事件通知给参与者?

识别用例的要点

1. 可观测一用例止于系统边界
2. 由参与者观测一业务语言、用户观点
3. 系统执行一用例是有意义的目标
4. 结果值一结果值由系统生成
5. 一组用例实例一用例的粒度

关系

角色和角色之间：泛化关系（继承）：实线＋箭头

三角空箭头

用例和用例之间的关系：包含关系

用例与用例之间的扩展关系:

表示只有在某些特定情况下用例2才会使用到用例1，此时用例1的事件流将被插入到用例2的事件流中。

 用例描述

用例描述

期末考试题库

1.重点

2.

3.

                 

U1：确认处方

U2：药品派送

U3：送药上门

A2：药师

A1：患者

4.

类图是面向对象设计的核心

5.

类图

一个类述了一组对象的集合

√相似属性
√相同操作
V与其他对象共同关系
V共同含义(“语义”)的对象集台

类的实例--对象

类图是表达系统类及其相互联系的图示，它是面向对象设计的核心。类图表示类、接口和它们之间的协作关系。

分析类

分析类是概念层次上的内容。在分析阶段，它直接与系统的应用逻辑和需求相关，而不关注于技术实现。

分析类可划分为三种类型:

• 边界类
• 控制类
• 实体类

实体类(Entity class)

通常对应现实世界中的“事物”息及其相关行为需要在系统中长期存储和管理:。这些“事物”的基本信

比如，校园网上订餐系统中，顾客类(customen)，食物类(food)、订单类(order)等都属于实体类。

控制类(Control class)

描述用例所具有的事件流的执行逻辑。控制类本身井不处理具体的任务，而是调度其他类来完成具体任务，