面向对象的软件工程－规划阶段

                                                                                                                                                  规划阶段

第1节 概述

1.1 简介

规划阶段是指从产品包需求和产品概念开始到产品业务规划和技术规划完成的过程。该阶段的重点是进一步完善产品概念的定义，由产品包需求推导出一个系统的、一致的、完整的产品功能需求（设计需求）。

在规划阶段包括两个核心活动，业务架构设计和技术架构设计。业务架构设计的输入是产品包需求和产品概念，其输出是产品的设计需求；技术架构设计的输入是产品设计需求，其它输出是产品的技术架构。

本阶段包括两个技术评审点，即TR2和TR3。TR2的重点在于评审产品的业务规划是否完整、一致，而且是否符合相关的包需求定义；TR3的重点在于评审产品的技术架构是否完整，是否能满足系统的功能需求、性能需求和约束条件。

本阶段包括一个决策评审点，即DP2。DP2的重点在于审核当前项目的业务规划、技术规划是否可行，其资源计划、财务计划和开发计划是否可行，是否可以进入下一阶段或是否需要终止计划。

1.2 流程图

第2节 流程介绍

2.1 业务架构设计

2.1.1 定义操作场景

包需求是从用户角度提出的产品需求，具有不系统、不完整、不一致等特点。为了确保最后的系统是满足用户需求的，需要从包需求出发，识别每个包需求所涉及的业务操作场景。

业务操作场景指的是在给定的上下文环境中，用户操作系统功能以完成预定目标。一个包需求可能涉及多个操作场景，一个操作场景可能包含多个包需求。

定义操作场景的目的是使得所有的包需求都是有依据的，而且为后续推导系统功能提供一个起点。

2.1.2 识别功能需求

在操作场景识别的基础上，描述用户和系统的交互状况，从而识别出系统为特定用户提供的功能响应，这样的功能响应即是系统的功能需求单元。

功能需求是从系统用户角度出发的所看见的系统功能单元，它为进一步进行业务规划提供了一个依据。

备注，这里功能需求只是比包需求的描述一致性强一些，但是缺乏系统性特征。

2.1.3 业务建模

将操作场景定义和功能识别过程中所产生的对象元素按照一种一致的方法组织起来，形成系统、完整、一致的业务功能描述，这就是业务建模。

①业务组织建模

业务组织建模是对目标系统用户角色的一致性定义，是需求分析的依据，也是系统授权管理的依据。

②业务用例建模

业务用例建模是将系统功能按照功能的依赖关系分配到不同的业务模块和业务流程中。业务用例是业务流程的建模元素，业务流程是系统功能单元的载体。

③业务对象建模

业务对象指的是参与到系统业务流程中的业务实体对象，业务实体用作业务流程活动节点的输入对象或输出对象。

2.1.4 完善产品概念

产品概念在概念阶段已经形成，但是在概念阶段形成的产品概念是关于系统比较高层的描述，随着对产品需求了解的深入。描述产品概念的角色、业务功能、模块组织结构也逐步细化，这时的产品概念也需要随时更新。

2.1.5 业务功能定义

①业务流程定义

业务用例是以业务目标为作为管理单元的建模元素，它牵涉到一个或多个角色、一个或多个业务活动，业务用例的具体涵义可以用业务流程来表达，系统功能是业务流程的活动节点。

以业务用例为单位，逐个描述每个业务用例的参与者、活动节点、输入输出对象、对象状态演变以及他们之间的关系，这就是业务流程。

②定义性能需求

在概念阶段提出的性能需求是对系统笼统的性能指标说明，本任务将系统的性能指标具体分配到业务流程的具体功能环节中，使得系统的性能指标在功能实现设计时可以得到相应保障。

备注：如果一个系统的性能指标对所有功能或对某些类型的功能要求是一样的，那么可以提取出来作为公共部分描述。

③定义设计约束

在概念阶段提出的设计约束是对系统笼统的约束说明，本任务将系统约束具体分配到业务流程的具体功能环节中，使得系统约束在功能实现设计时可以得到相应保障。

2.2 软件架构设计

软件架构设计是在业务架构设计基础上开展的，其目的为系统设计提供各种静态视图结构和动态视图结构指导。

软件架构不负责完成所有的系统设计，但是在进行软件架构设计时必须提供哪些影响系统架构的关键功能的设计。软件架构提供系统设计时遵循的逻辑视图、开发视图、进程视图、部署视图和数据视图的定义。

2.2.1 关键功能分解

选择影响系统架构（包括影响逻辑视图、开发视图、进程视图、部署视图、数据视图）的功能（这些功能即影响系统架构的关键功能），分析这些功能的不同的业务场景，为每个业务场景定义相关的处理流程。

关键功能分解的目的是为实现设计提供功能描述。

2.2.2 实现设计

在关键功能分解的基础上，在选定软件体系架构（或软件框架基础）上，设计出每个分解后的功能的处理流程，并且在设计时需要考虑性能设计和约束设计的需要。

①功能实现设计

根据选定的软件体系架构（或软件框架），设计出功能实现时需要的界面类、逻辑类及其方法、实体类等。

②性能实现设计

在功能实现设计时，考虑性能需求，为满足性能需求而在系统实现时采用一定的规范或机制。

③约束实现设计

在功能实现设计时，为了遵循系统约束，使得功能实现时采用一定的标准、规范或机制。

2.2.3 视图设计

在功能实现设计过程中，需要体现功能动态特征的设计元素和静态特征的设计元素有机的组合起来，形成系统的、完整的、一致的软件视图。

①逻辑视图设计

逻辑视图属于系统设计的范畴，它表现的是对系统架构实现有重要意义的子系统、包、类、接口、及它们之间的关系。

②开发视图设计

开发视图关注在软件开发环境下代码的模块组织结构，软件打包成小的程序块，它们时程序包或子系统，可以由一位或几位开发人员开发。子系统可以组织成为分层结构，每个层为上一层提供良好定义的接口。

大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制。开发架构视图是各种活动的基础，如：需求分配、团队工作的分配（或团队机构）、成本评估和计划、项目进度的监控、软件重用性、移植性和安全性。它是建立产品线的基础。

③进程视图设计

进程视图以图形方式说明了系统中进程的详细组织结构，它考虑一些非功能性的需求，如性能、可用性、并发性、分布性、系统完整性、容错性等方面，并且它考虑逻辑视图的主要抽象如何与进程结构相配合在一起，即在哪个控制线程上，对象的操作被实际执行。

进程是构成可执行单元任务的分组，进程代表了可以进行策略控制的过程架构的层次（即：开始、恢复、重新配置及关闭），另外，进程可以就处理负载的分布式增强或可用性的提高而不断地被重复。

进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作"processes"）的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过 LAN 或者 WAN 连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。

软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。我们可以区别主要任务、次要任务。主要任务是可以唯一处理的架构元素；次要任务是由于实施原因而引入的局部附加任务（周期性活动、缓冲、暂停等等）。主要任务的通讯途径是良好定义的交互任务通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等。次要任务则以会见或共享内存来通信。在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。消息流、过程负载可以基于进程视图来进行评估，同样可以使用哑负载来实现"中空"的进程架构，并测量在目标系统上的性能

④数据视图设计

数据视图属于设计的范畴，它表示的是系统需要永久性存储的数据对象以及这些对象之间的关系。数据视图包表、视图、存储过程以及表对象之间的关系。

⑤部署视图设计

部署视图主要关注系统非功能性的需求，如可用性、可靠性（容错性）、性能和扩展性。软件在计算机网络或处理节点上运行，被识别的各种元素（子系统、进程/线程、任务和对象）需要被映射至不同的节点。我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

第3节 工件示例

3.1 《设计需求》示例

3.1.1 表示法说明

设计需求的核心内容是对目标系统的业务规划，该业务规划适合采用面向对象软件工程的业务建模方法来表示，一共包括三个视图：业务组织模型、业务用例模型和业务对象模型。

备注：此处省略模板。

3.1.2 例子

①业务组织模型

②业务用例模型

③业务对象模型

3.2 《软件架构》示例

3.2.1 表示法说明

软件架构演化过程模型

软件架构是由最常规的表示法由5＋1视图，我们将软件架构的概念由实现阶段架构扩展到业务阶段和分析阶段，分别称为业务架构、分析架构和实现架构。

¤        业务视图

业务视图，即业务模型，是OOAD的重要组成部分，简单的说，业务模型就是对业务领域问题进行结构化的描述。这个描述将会直接指导最终生成的软件，业务模型是否具有扩展性，业务模型是否能够正确的反映需求，都将影响最终软件的质量。

业务建模的目的在于： 了解并重新组织目标组织（将要在其中部署系统的组织）的结构及协作机制；导出并重构支持目标组织所需的业务需求。

业务建模一般有三种表达手段：业务组织模型、业务用例模型、业务对象模型。

备注：业务需求是组织级别的事务，它由一个或多个角色协调完成一个业务流程，共同实现一个业务目的。业务需求粒度划分的合理性由什么决定呢？职能划分的粒度决定了业务需求的粒度。我们进行业务需求建模，存在两个模型，即旧模型和新模型：旧模型是对现实的业务功能的描述；新模型指的是重新设计的业务功能的描述。

备注：业务对象，也可以称为CBO(Common Business Object)，它是业务分析的核心的对象，该对象在业务用例的流程描述时具有特定的涵义，也是衍生分析对象的基础。业务对象＋分析模式＝分析对象。

备注：业务组织是对组织中能动要素（职能要素）的描述。业务组织模型也区分为旧模型和新模型，旧模型指的是已有的现实的角色划分方法；新模型指的是重新设计的角色划分方法。

¤        分析视图

分析视图是以业务视图为基础，利用OO的建模原理和（分析）用例描述方法，实现对业务视图的精细化描述。

分析视图的目的在于：以独立于实现的方式，从用户角度出发点，对系统功能进行详细描述。

分析视图主要由三个模型进行描述，分析用例模型、分析对象模型、逻辑数据模型。分析用例模型描述的是角色执行的单元功能；分析对象模型描述的是系统的基本组成单位，它是进一步进行系统设计的基础；逻辑数据模型描述的是按照OO的组织原理组织起来的相对稳定的对象模型。

备注：分析用例是对业务用例流程图中的节点的详细描述。它的粒度划分标注是业务活动过程不能再分解成为分时完成的任务。

备注：分析对象模型是分析用例进行细化描述时定义的，分析对象模型中定义了组成系统的边界类、控制类和实体类。边界类是系统对外提供的界面，包括用户界面和系统界面；控制类是系统提供逻辑构件接口，它只是简单的定义了可以重用的逻辑，其实现类在设计阶段设计；实体类定义的是需要持久化存储的对象。

备注：逻辑数据模型是对实体对象类的细化描述，它在实体类的基础上运用OO规则整合产生。

¤        设计视图

设计视图在分析视图的基础上，集合选定技术平台、软件架构、设计模式、软件框架等技术所定义软件的实现框架。

设计视图是利用业界常用的“4+1”视图表达的，所谓4+1视图，包括的内容是：逻辑视图、开发视图、进程视图、部署视图、实现用例视图、物理数据模型（可选）视图。逻辑视图指的是代码对象的逻辑组织结构；开发视图指的是逻辑视图对象在实施编码后的物理文件结构；进程视图指的是系统在运行时为了完成特定的目标，不同进程（或线程）的协同工作状况；部署视图指的是物理视图、进程视图在硬件上的部署状况；实现用例视图指的是逻辑视图、开发视图、进程视图、部署视图、物理数据模型协同工作以实现系统需求的模型；物理数据模型指的是逻辑数据模型的实现方式。

3.2.2 例子

此处略