软件体系结构——第四章<业务建模>

一、分析设计过程简介

UML分析设计过程解析：

• 业务建模：用软件建模方法描述业务流程；其目的是认识业务本质——用例建模的基础；

• 用例建模：采用UML用例建模技术描述软件需求——为用例分析提供输入；

• 用例分析：采用UML用例分析技术分析软件需求——建立软件系统的分析模型；

• 架构设计：在系统的全局范围内，以分析模型为基础——设计系统的架构；

• 构件设计：根据架构设计的成果，将分析模型细化——设计系统构件的实现细节；

• 代码实现：将系统构件映射到目标编程语言上——正向工程。

二、业务建模基础

2.1、业务及业务领域

业务(business)是指某个组织或者组织单元完成的工作。可以看作是一种包含了人、机器、资源的“系统”，特点是具有工作流程存在。

业务建模：利用OO软件思想(用例、对象)描述业务的过程。其特点主要有：

• 业务建模只是辅助环节，是为了搞清楚业务的本质

• 不是所有项目都需要

• 也不一定和软件开发(实现)相关

业务建模的目的(RUP)

• 理解将要实施的系统的组织结构和动态特性

• 理解当前业务在组织中的问题，并明确改进的潜力

• 确保客户、最终用户和开发人员（统称为项目干系人员——涉众）对目标组织有统一的理解

• 获取用于支持目标组织的系统实际真实需求

业务建模关注的内容

• 机构的核心价值、边界、参与者（角色与职责）

• 机构中的工作流及如何优化

• 业务用例与业务对象——做什么？谁来参与？

2.2、分析的基本原则

经验法则-1

分析模型总是使用业务语言

• 分析模型中的抽象应该是业务领域词汇的部分

创建“讲故事”的模型

• 每幅产生的图应该阐明系统期望行为的一些重要部分

注重于捕获大的场面(做什么)

• 不限于系统将如何工作的细节（这是设计的工作）

要清晰地区分问题域（业务需求）和求解域（详细的设计考虑）

• 总是关注存在于问题域的抽象

经验法则-2

总是尽力最小化耦合

• 类之间的每个关联都是在它们之间建立耦合

继承关系

• 继承是类间耦合的最强形式（最好不用）

• 如果看起来存在自然的、强迫的抽象层次，则可探索继承关系

• 分析中，永远不要仅为了复用代码而使用继承

2.3、业务建模方法

研究对象

• 明确软件对现实业务需要改进的业务单元

研究目标

• 定义业务本质，目的是搞清业务的本质工作

研究方法

• 用例观点：把任何业务看成是对外提供价值的价值流——做什么、起什么作用

三、业务用例模型

业务用例模型是说明业务预期功能的模型，是业务建模阶段的核心模型，用来确定业务组织的各个角色和可开展工作的操作序列(业务处理过程)

• 识别业务参与者，找出业务活动的服务对象；

• 识别业务用例，业务活动的操作序列；

• 详述业务用例，撰写用例文档、建立UML模型；

3.1、业务参与者

识别业务参与者

• 在业务之外，与业务进行交互的任何人或组织等服务对象

区分业务工人

• 业务参与者在业务外面
• 业务工人在业务里面

区分业务实体

• 对每个业务参与者至少要设计一个业务用例

注意：业务参与者的角色和职责，一个业务参与者可能有多个角色

3.2、业务用例

识别业务用例

• 业务为业务参与者提供的价值

• 体现了企业业务本质，是有意义的目标（执行的一系列动作）

• 是现实业务为客户提供的有价值的服务

识别业务用例与业务参与者

• 用例命名规范：简单明了、易于理解

识别业务用例的方法

• 直接获得：从业务参与者的角度，从外部推导出来
• 拼装：从业务里面往外面看，内部业务流程的目标是什么

识别业务用例-支撑性事件

• 人员的发展与维护
• 办公室的设立与维护
• 安全性
• 法律活动

3.3、详述业务用例

业务用例是对业务流程的封装。因此，在业务建模过程中需要对每个用例逐一描述其内部工作细节，即详述业务用例。

目的：

• 详细说明业务用例的工作处理流程

• 便于项目干系人员（涉众）的理解

技术支持：（建议：文字、图、表结合）

食客吃饭业务流程活动图：

四、业务对象模型

业务对象模型(Business Object Model包)，描绘现实业务关系中的人、事物、设备、资源以及它们之间的关系，即业务工人和业务实体之间的静态关系。

核心元素：

• 业务工人(Business Worker)：承担一系列职责的人，如现实业务中的参与者；

• 业务实体(Business Entity)：业务内部所访问和操纵的事物，如饭店业务中厨师所作的菜肴；

• 业务用例实现(Business Use Case Realization)：从实现角度来展示业务用例如何得到满足，表现为业务工人与业务实体之间的交互过程——建立业务静态结构、动态行为模型；

分类：

• 静态模型：关注业务工人与业务实体之间的关系，此模型构建时主要考虑关联、聚合和泛化三种关系

• 动态模型：对用例的具体实现与细化（构建活动图（业务建模）、交互图（用例建模））

餐馆的业务对象模型（静态类图）：

作用：

• 作为一个纽带，用于对业务关系进行清晰的表述，使得后续分析工作更加简单；

• 探索业务领域知识的本质，便于业务模型到系统模型的过渡；

• 领域需求，是一种准确确定需求的方法；

• 确定业务对象、对象间关系等过程，使开发人员能够以一种能被业务领域专家所能理解和验证的精确方式来表达业务领域知识。

五、业务建模实践

研究对象：某酒店

业务现状分析：

• 某旅店可对外开放50个双人间和20个单人间，房间费用视情况按季节调整，但周一到周五提供半价（周末全价）折扣

• 旅客可以直接入住房间(如果有空房)，也可提前预订；入住和预订都需要登记个人信息

• 旅客提前预订房间时，需提交一定的订金；入住时间24小时之外的旅客可以取消预订，并退回所有订金，24小时以内则不退还订金

• 退房时缴纳全部的住宿费用

• 服务员每月为经理提供房间的预订情况和入住情况的详细信息

业务用例模型：

• 业务观点：旅店的本质就是为旅客提供住宿服务，其它的只是为达到这个目标而采用的手段

• 用例观点：把业务看成对外提供价值的价值流

住宿业务用例活动图：

业务对象模型：

业务建模的重点：

• 业务用例模型关注业务对外所提供的价值；

• 业务对象模型关注业务内部的实现机制；

• 建模时，应将两种模型有机的结合起来，才能有效地完成业务建模过程。

六、从业务模型到系统模型

映射关系（并非一一对应）：

• 业务用例→系统(子系统)

• 业务参与者→系统参与者

• 业务工人→系统参与者

• 业务工人的操作(活动)→系统用例

• 业务实体、属性→实体类

• 业务实体之间的关系→实体类之间的关系