第六章 UML建模与架构文档化

第6.3节 基于UML的软件开发过程

 

根据作者的思路，整理如下：

 

基于UML软件开发过程：
1、 初启
2、 细化
    a) 初步的需求分析
    b) 初步的高层设计
    c) 部分的详细设计
    d) 部分的原型构造
3、 构建
4、 部署

基于UML的需求分析
1、 生成用例
2、 用活动图描述用例
3、 生成用例图
4、 建立顶层架构
    a) UML包图
    b) 顶层架构设计（可以考虑一些模式，如：流程处理模式、客户/服务器模式、分层架构、MVC架构等）
5、 建立概念模型

 

 

 

面向对象的设计方法
1、 设计用例实现方案
 　　a) 提取边界类、控制类、实体类
 　　b) 构造交互图
 　　c) 根据交互图精画类图
2、 设计技术支撑方案
 　　a) 持久化
 　　b) 安全、异常控制
 　　c) 并发与同步控制
 　　d) 分布式通信与事务
3、 设计用户界面
 　　a) 熟悉用户并分类
 　　b) 按用户类别分析工作流程与习惯
 　　c) 设计命令系统
 　　d) 设计用户界面的细节
4、 精化设计模型

 

 

 

系统架构文档化
1、 模型概述
　　a) 逻辑视图（Logical View），设计的对象模型。
　　　　i. 主要是类图、对象图、顺序图、通信图、时序图、交互概况图、组合结构图、状态图。
　　　　ii. 逻辑视图主要描述功能性需求。逻辑视图对主要的类进行抽象、描述。
　　b) 过程视图（process View），捕捉设计的并发和同步特征。
　　　　i. 主要有活动图。
　　　　ii. 过程视图主要考虑非功能性需求，如性能和可用性。它主要解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合结合在一起。
　　c) 物理视图（physicl View），描述软件到硬件的映射，反应了分布特性。
　　　　i. 主要有部署图。
　　　　ii. 物理视图主要关注系统非功能性需求，如可用性、可靠性（容错性）、性能（吞吐量）和可伸缩性。
　　d) 开发视图（development View），描述了开发环境中，软件的静态组织结构。
　　　　i. 主要是组件图、包图。
　　　　ii. 开发架构关注软件开发环境下实际模块的组织。如软件分为模块（子系统），子系统可以组织成分层结构，每个层上定义的接口。开发视图一般要体现输入和输出的关系。完整的开发视图，只有当所有软件元素被标识后才能加以描述。但是，可以列出控制开发视图的规则：分块、分组和可见性。
　　　　e) 用例和场景（use cases and scenarios）。
　　　　　　i. 4种视图的元素通过数量比较少的一组场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。在　　　　某种意义上，场景是最重要的需求抽象，他们的设计使用对象场景图和对象交互图来表示。
　　　　　　ii. 该视图是其他视图的冗余（因此+1），但它起到了两个作用：
　　　　　　　　1. 作为一项驱动因素来发现架构设计过程中的架构元素。
　　　　　　　　2. 作为架构设计结束后的一项验证和说明功能，既以视图的角度说明，有作为架构原型测试的出发点。

 

2、 迭代过程
场景驱动法：
　　a) 开始阶段
　　　　i. 基于风险和重要性为某次迭代选择一些场景。场景可能被归纳为对若干用户需求的抽象。
　　　　ii. 形成“稻草人式的架构”。然后对场景进行描述，以识别主要的抽象（类、机制、过程、子系统）。
　　　　iii. 所发现的元素分布到4个蓝图中，即逻辑蓝图、进程蓝图、开发蓝图、部署蓝图。
　　　　iv. 然后实施、测试、度量该架构，这项分析可能检测到一些缺点和潜在性的增强要求。
　　　　v. 捕获经验教训。
　　b) 循环阶段
　　　　i. 下一个迭代过程开始进行。
　　　　ii. 重新评估风险。
　　　　iii. 扩展考虑的场景。
　　　　iv. 选择能减轻风险或提高结构覆盖的额外的少量场景。
　　　　v. 然后试着在原来的架构中描述这些场景。
　　　　vi. 发现额外的架构元素，或有时还需要找出适应这些场景所需的重要架构变更。
　　　　vii. 更新4视图。

　　　　viii. 根据变更修复现有的场景。
　　　　ix. 升级实现工具（架构原型）来支持新的、扩展了的场景集合。
　　　　x. 测试。如果可能的话，在实际的目标环境和负载下进行测试。
　　　　xi. 然后评审这4+1视图，来检测简洁性、可重用性和通用性的潜在问题。
　　　　xii. 跟新设计准则和基本原理。
　　　　xiii. 捕获经验教训。
　　　　xiv. 终止循环。

 

 

 

 

 

 

 

/*

在我的团队中，采用的是面向对象的设计方法。

1、领域专家与需求分析人员进行领域分析并建模，从原始需求中寻找领域对象，建立领域模型，明确领域对象之间的关系。

2、对领域对象进行说明描述，输出数据词典。（名词解释、重要的领域规约、粗粒度的使用场景）

3、寻找领域的状态，并且描述出引起状态变化的原因。

4、对于复杂的领域，使用活动图描述其流程；对于复杂的交互，使用顺序图描述其交互。这一步是可选的。

此刻，领域分析完成，开始进行应用分析。

5、根据领域分析模型和相关分析文档寻找边界，确定用户；寻找操作，确定功能性要求。输出用例图，用例活动图。

6、根据以上文档寻找领域的协作关系，得出领域协作图，明确领域之间所有重要的操作。

7、根据6，参考其他相关文档寻找边界类、控制类、实体类，并明确类的属性、方法，输入应用分析类模型。

8、根据6,7，绘制用户界面。

此刻，应用分析完毕，开始进入架构设计

9、根据系统的特点（客户分布情况、业务规则）进行高层架构，主要考虑分层架构模式（水平和垂直分割）、表模式模式、领域模型模式、管道等。

10、根据系统的特点，考虑异常处理、安全、通信、持久化等构件的设计。

11、对重要并具有代表性的功能进行详细设计，用作设计师工作的范本。

12、完成9,10中的框架以及构件的实现。

此刻架构设计完成，进入详细设计阶段。

13、应用分析模式以及架构设计模型，对选取的迭代功能进行分析，得出类图、顺序图、重要或具有难度功能的算法描述。

14、对于复杂的调用，使用对象图描述对象的组织情况。这一步是可选的。

此刻，详细设计完成，开始进入实现阶段。

15、编码、自测

……

整个开发过程，采用UML和4+1视图进行驱动。 

 

在整个开发过程中，还有不少地方值得改进。例如：

1、在领域分析初期，应该在添加交互模型，如业务活动图。

2、在应用分析阶段初期，应该添加用例概况图。（可恶的EA不支持整个图，得通过其他的方式来代替）

3、在实现阶段，应该对重要的功能先编写单元测试代码。

 

相对于教材上的流程，我们把能和用户交流确认的内容放到了前面，把属于自己埋头苦干的内容放在架构设计的最后面。

*/