面向对象需求分析

1. 面向对象分析概述

1.1 面向对象基本概念

以对象为中心，以类为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。

1.2 UML统一建模语言

为什么要使用UML

UML基本概念

统一建模语言（UML）是一个支持模型化和软件系统开发的图形化语言，简单、统一，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。

如下图UML模型可作为客户、需求分析员、开发人员、测试人员等沟通的标准。

1.3 面向对象分析与UML

面向对象分析中分为功能模型、对象模型、动态模型，分别与UML图例对应关系如下所示：

2. 功能模型

2.1 功能模型概述

功能模型描述所有参与者使用系统功能的情况。

以用例为建立功能模型的基本单位，通过可视化的用例图展示参与者与系统交互的情况。

2.2 用例图概述

用例图从用户的观点描述系统的功能，是用户所能观察到的系统功能的模型图，由参与者、用例以及它们之间关系所组成。

参与者（Actor）

参与者是与系统交互的外部实体（使用系统的用户、组织机构、外部系统或硬件设备），在UML中用下面带有名字的小人来标示。

用例（Use Case）

用例是从用户角度描述系统的行为，主要说明软件系统的功能，在UML中用椭圆标示。

关联关系

描述参与者与用例之间的关系，在UML中用箭头标示。

2.3 用例建模的步骤

（1）确定业务参与者

业务参与者是与系统交互的外部实体（使用系统的用户、组织机构、外部系统或硬件设备）。

谁使用该系统；
谁改变系统的数据；
谁从系统获取信息；
谁需要系统的支持以完成日常工作任务；
谁负责维护、管理并保持系统正常运行。

（2）确定业务需求用例

用例是从用户角度描述系统的行为，向参与者提出问题获取用例。

参与者需获取何种功能，需要做什么；
参与者需读取、产生、删除、修改或存储系统中何种信息；
系统发生事件和参与者间的通信；
每个用例应该是系统的一个功能，如果功能很大，需分解为几个独立功能。

（3）创建用例模型

创建用例模型即画出用例图。用例图围绕参与者创建，对于系统的每一个参与者可创建一个分用例图，最后组合成一个或多个用例图。

2.4 用例之间的关系

（1）包含关系

表示一个用例的行为包含了另一个用例的行为，这种关系用虚线箭头和《includ》字样表示，箭头指向被包含的用例。

（2）扩展关系

对于用例的异常行为或不同分支的选择行为抽象为一个扩展用例，这样扩展用例与基础用例之间构成了扩展关系，用虚线箭头和《extend》字样表示，箭头指向被扩展的用例（即基础用例）。

（3）泛化关系

表示一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。这种关系用带空心箭头的实线表示，箭头指向被泛化（被继承）的用例，即父用例。

由于子用例继承父用例的动作会导致高耦合的产生，因此要谨慎使用泛化关系。

2.5 高校图书借阅系统用例建模案例

高校图书借阅系统的业务流程

管理员可以通过此系统对图书和读者信息进行查询、增加、修改和删除，查询读者借阅情况；管理员还可以查询借阅超期的信息；
读者可以通过此系统借书、归还图书，查询个人现在和历史借阅情况，若有图书超期则需支付罚款并归还后才可继续借书；
读者可以查询书籍信息、个人基本信息、个人借阅及超期罚款信息等；
管理员和读者都可以修改个人密码。

（1）确定业务参与者

管理员、读者

（2）确定业务需求用例

管理员用例：图书信息维护、读者信息维护、信息查询、修改个人密码。

读者用例：借书、还书、续借、信息查询、修改个人密码。

（3）确定用例模型

2.6 机票预定系统用例建模案例

机票预定系统的业务流程

航空公司操作员录入航班信息并对其维护，可以查询、统计旅客信息、订单信息以及航班信息。旅客首次进入系统需要注册，在此系统中订票、取票和退票，系统对订票、取票和退票信息进行审核，旅客接收订票成功通知、机票和退票成功通知。旅客还可以查询航班信息，查询和修改个人基本信息，查询个人订单。另外系统时钟在旅客行程当日发送行程通知，提醒旅客有预订航班几点起飞，以免忘记行程。
航空公司操作员在旅客已取票情况下，可以在期限范围内为旅客完成退票，操作流程与旅客退票流程基本相同。

（1）确定业务参与者

操作员、旅客、时钟

（2）确定业务需求用例

操作员用例：航班信息维护、信息查询、退票。

旅客用例：旅客信息维护、订票、取票、退票、信息查询。

时钟用例：行程提醒。

（3）确定用例模型

3. 对象模型

3.1 对象模型概述

什么是对象模型呢？对象模型（类图）是模型的静态结构，表示软件要处理的数据，它描述了系统逻辑设计中存在的包、类以及它们之间的关系。

3.2 对象建模的步骤

（1）划分主题

对于小型系统，可以跳过此步骤直接开始确定系统的类和对象。

对于稍大型的系统，为了简化对象模型创建过程，可将一个大问题划分为若干主题，再针对各个主题建立类图，最后合并为一个整体。

划分主题的原则：

每个主题的规模应当适中，含有6个左右的类为宜。
每个主题的功能应具有独立性和完整性，与其它主题有最少的联系。

（2）确定类和对象

系统分析员根据获取的需求和用例模型分析出类和对象。

在UML建模的类图中，每个类表示为一个矩形，矩形的上部为类名，中间为类的所有属性，下部为类的所有操作，除类名外，其他部分可以省略。

类名：是一个字符串，学生。
属性：[可见性]属性名:类型[=默认值]
操作：[可见性]名称(参数列表)[:返回类型]
可见性：+表示public，-：表示private，#表示protected。

（3）确定类与类之间的关系

类和类之间的静态关系包括关联关系、聚合关系和泛化关系。

关联关系：两个或多个类之间的连接关系（最常见）。格式：关联关系用一条无向直线表示，直线两端分别与一个类相连，并在两端标注关联的对象数量。
聚合关系：类和类之间具有明显的组成关系，即两个类之间的对象具有整体和部分的关系，也就是一个类的实例包含另一个类的实例，它是关联关系的一种特殊形式。格式：聚合关系在关联关系直线整体类的一端画一个空心菱形，表示一对多联系。
泛化关系（继承关系）：表示一般与特殊的关系，它指的是子类继承父类的所有属性和行为，子类也可以具有自己独有的属性和行为。格式：泛化关系在关联关系直线一般类的一端画一个空心三角形。

（4）确定类和关联的属性

属性表示类中对象的性质，它既与问题域有关，又与系统要完成的功能有关。

分析和选择属性的方法：

每个类的对象至少要包含一个“id”性质的属性，如学生的学号、商品的编号、订单的编号等等；属性的设置应适合类中所有对象，包括在泛化关系当中对象所继承的属性；系统中所有要存储的数据都必须定义为属性；导出属性即可通过其它属性计算出来的属性应当略去。
错误或不确定的属性应该删除：比如，误把对象或关联当作属性、过于细化的属性、不一致的属性等等。
每个属性的数据类型可在此确定，也可以在面向对象的设计阶段确定。

（5）确定类和关联的操作

类和关联中的对象收到消息后所能执行的操作，有以下两种：

简单的操作。即每一个对象都应具备的操作，包括：建立和初始化一个新对象，建立或切断对象之间的关联，存取对象的属性值，释放或删除一个对象。这些操作在分析时是隐含的，在类图中不必标出，但实现（编码）类和对象时要有定义。
复杂的操作。两种：一是计算操作，就是利用对象的属性值计算，以实现某种功能；二是监控操作，它处理的是外部系统的输入∕输出、对外部设备的控制和数据的存取。

3.3 高校图书借阅系统对象模型案例

高校图书借阅系统的业务流程

管理员可以通过此系统对图书和读者信息进行查询、增加、修改和删除，查询读者借阅情况；管理员还可以查询借阅超期的信息；
读者可以通过此系统借书、归还图书，查询个人现在和历史借阅情况，若有图书超期则需支付罚款并归还后才可继续借书；
读者可以查询书籍信息、个人基本信息、个人借阅及超期罚款信息等；
管理员和读者都可以修改个人密码。

（1）划分主题

分析问题的规模，此系统不需要划分主题。

（2）确定类和对象

根据问题域和用例模型，得到图书借阅系统的类和对象包括图书、单本图书、读者、读者类别、图书存放区域、图书管理员。

（3）确定类与类之间的关系

类与类之间的关系为：

每一个图书有多本，即包含多个单本图书的对象；
每一个图书都只能规定一个存放区域；
每个图书管理员只管理一个区域的图书，每个区域有多名管理员；
每个读者都可以对每个单本图书进行借阅；
每个读者都只属于一个读者类别。

（4）确定类和关联的属性

类与对象	属性
图书	书号，书名，作者，单价，类别，出版社，出版日期
单本图书	条码号，图书状态
读者	读者号，密码，姓名，性别，电话，身份证号
读者类别	类别号，类别名，最大借书天数，最大续借天数，最大借书数量
存放区域	区域名，最大存放数量
图书管理员	编号，姓名，密码，电话
借阅	读者号，图书条码号，借书日期，还书日期，是否归还，续借日期，罚款金额，是否交罚款

（5）确定类和关联的操作

类与对象	操作
读者	修改密码，查询读者信息，查询个人借阅信息
图书	查询图书信息，统计各类别图书借阅情况
单本图书	修改图书状态
借阅	增加读者借阅信息，修改还书日期、是否归还、续借日期、罚款金额、是否交罚款，查询借阅信息，查询超期未还信息
读者类别	查询各类别读者借书量上限、最大借书天数等
图书管理员	修改密码

高校图书借阅系统—对象模型（类图）

3.4 机票预订系统对象模型案例

机票预定系统的业务流程

航空公司操作员录入航班信息并对其维护，可以查询、统计旅客信息、订单信息以及航班信息。旅客首次进入系统需要注册，在此系统中订票、取票和退票，系统对订票、取票和退票信息进行审核，旅客接收订票成功通知、机票和退票成功通知。旅客还可以查询航班信息，查询和修改个人基本信息，查询个人订单。另外系统时钟在旅客行程当日发送行程通知，提醒旅客有预订航班几点起飞，以免忘记行程。
航空公司操作员在旅客已取票情况下，可以在期限范围内为旅客完成退票，操作流程与旅客退票流程基本相同。

（1）划分主题

分析问题的规模，此系统不需要划分主题。

（2）确定类和对象

根据问题域和用例模型，得到机票预订系统的类和对象包括旅客、航班、航班票务、订单和机票。

（3）确定类与类之间的关系

类与类之间的关系为：

每一个航班具有多种不同舱位的机票，即包含多个航班票务的对象；
每个旅客都可以对每种航班票务下订单进行预订；
每个订单会产生一张机票。

（4）确定类和关联的属性

类与对象	属性
旅客	身份证号，密码，姓名，电话
航班	航班号，起飞站，起飞时间，到达站，到达时间，登机时间，登机口
航班票务	航班号，舱位，日期，票价，余票
订单	订单号，折扣，订票时间，订单状态
机票	订单号，座位，机票状态

（5）确定类和关联的操作

类与对象	操作
旅客	注册，个人信息维护，注销
航班	查询航班信息
航班票务	按航班日期查询票务信息，统计航班预订情况
订单	生成订单，改变订单状态，统计订单情况，计算退款金额
机票	生成机票，改变机票状态，统计机票信息

机票预订系统—对象模型（类图）

4. 动态模型

4.1 动态模型概述

交互模型（动态模型）一般是由顺序图、状态图和活动图表示的动态模型，是从需求分析向设计过渡的重要环节。

4.2 顺序图

顺序图概述

用例图中，用例是从用户角度描述系统的行为，它将系统的一个功能描述成一系列事件，用户与用例的交互过程通过事件流进行描述，是一个文本性质的场景描述。

顺序图可以以图形的形式描绘这种场景，其中既具有交互的时间顺序又包含了参与交互的类的对象以及完成功能细节时对象之间要交互的信息，另外这些类的对象还包含用户的某些操作界面，其实例为表单对象（Form）,以及系统服务器对象。

顺序图对参与者与每个用例交互过程的描述更加流畅并更具直观性，既易于用户的理解和交流，又有利于开发者从需求向设计的过渡。

顺序图符号

顺序图中，纵轴从上到下为交互的时间顺序，横轴从左到右为参与交互的参与者对象、对象模型中某些类的对象以及一些操作界面的表单对象和系统服务器对象。

顺序图的基本符号：竖直的虚线，细长的矩形，有向实线，有向虚线。

消息的分类

消息（普通）。图中消息1，它连接到两个不同对象生命线的连接点。此类消息表示一个动作，接收消息的对象(箭头所指的对象)执行这个请求上的动作。消息可包含传给要执行方法的参数。
消息（调用）。图中消息2，消息调用的流程类型是过程调用，即消息调用是过程调用的一部分。
消息（返回）。图中消息3，返回消息是将信息返给对象的消息，一般发生在执行动作之后。返回信息不执行动作，仅返回信息，与普通消息的方法或操作无关。
消息（异步）。图中消息4，异步调用是流程类型被设置为异步的消息。发送对象将消息发送给接收对象，并不等待接收对象的响应。