<<Applying UML and Patterns>>的中文版<<UML和模式应用>>读书笔记。

在众多成功的软件设计与实现的经验中，最突出的两条，一是注重系统架构的开发，一是注重过程的迭代和递增性。尽管UML本身没有对过程有任何定义，但UML对任何使用它的方法（或过程）提出的要求是：支持用例驱动(use-case driven),以架构为中心(architecture-centric)以及递增(incremental)和迭代(iterative)地开发。

requirements analysis : may include stories or scenarios of how people use the application; these can be written as use cases.
object-oriented analysis : finding and describing the objectsor conceptsin the problem domain.
object-oriented design : there is an emphasis on defining software objects and how they collaborate to fulfill the requirements

Define Use Cases -> Define a Domain Model -> Assign Object Responsibilities and Draw Interaction Diagrams -> Define Design Class Diagrams

Use case diagram, class diagram, object diagram, sequence diagram, collaboration diagram, state diagram

Logical View 用来显示系统内部的功能是怎样设计的，利用系统的静态结构和动态行为来刻画系统功能。
静态结构在类图和对象图中描述，动态建模用状态图，序列图，协作图和活动图描述

01 面向对象分析和设计

在OO开发中，至关重要的能力是熟练地为 软件对象 分配职责。

职责分配 是一项涉及大量需要 权衡和抉择 的问题。

分析(analysis)强调的是对问题和需求的 调查研究，而不是解决方案。
分析 一词含义广泛，最好加以限制，如需求分析(对需求的调查研究)或面向对象分析(对领域对象的调查研究)

设计(design)强调的是满足需求的 概念上的解决方案，而不是其实现。

有益的分析和设计可以概括为: do right thing(分析)和 do thing right(设计)

在OOA中，强调的是在问题域内发现和描述对象。
在OOD中，强调的是定义软件对象以及它们如何协作以实现需求。

定义用例 定义领域模型 定义交互图 定义设计类图
OOA关注从对象的角度创建领域描述，其结果表示为领域模型。领域模型不是对软件对象的描述，它是真实世界领域中的概念和想象可视化。

OOD关注软件对象的定义—它们的职责和协作。(主要用顺序图sequence和类图(class)来描述)

概念类(conceptual class)——–现实世界中的概念或事物。
软件类(software class) —— 无论在过程或方法中，都表示软件构件在规格说明或实现透视图中的类。
实现类(implementation class) —– 特定OO语言(如JAVA)中的类。

02 迭代，进化和敏捷

迭代开发是OOAD成为最佳实践的核心。相对于顺序或瀑布生命周期，迭代和增量开发对部分系统及早地引入了编程和测试，并重复这一循环。

在迭代开发中，我们依赖于短时快速的开发步骤，反馈和改写来不断明确需求和设计。
一直以来，成功/失败的研究表明，瀑布模型和软件项目高失败率具有极大关系，对它的推广源于信念和风闻，而不是具有统计意义的数据。研究证实，迭代方法与较高的成功率，生成率和低缺陷率具有关系。

在UP项目中可以引入XP的测试驱动开发(test-driven development)，重构(refactoring)和持续集成(continuous integration)

软件开发过程(process)描述了构造，部署以及维护软件的方式。

UP, XP, SCUM, Lean Development, DSDM, Feature-Driver Development, Adaptive Software Development

DSDM(Dynamic System Development Methodology) 适用于时间要求紧的项目，其基本观点是，任何事情都不可能一次性的圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。

迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期(如三个星期)小项目，称为迭代；每次迭代都产生经过测试，集成并可执行的局部系统。每次迭代都具有各自的需求分析，设计，实现和测试活动。

迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。随着时间和一次又一次迭代的递进，系统增量式的发展完善，因此该方法也被称为迭代和增量式开发。

大部分迭代方法建议迭代时间在2~6周之间。小步骤，快速反馈和调整是迭代开发的主要思想。迭代的一个关键思想是时间定量(timeboxed)。例如，假设选择下一次迭代时间为3周，则必须依照时间表来集成，测试和稳定局部系统—-推迟时间则违约。如果看起来难以满足期限要求，那么建议从本次迭代中除去一些任务或需求，并将其分配在将来的迭代中，而不是推迟完成时间。

变更对于软件项目来说是永恒的。

在实际项目中，我们应该首先处理困难的和具有风险的事物。

敏捷宣言和原则：
宣言：
个体和迭代，超越过程和工具
工作的软件，超越完整的文档
客户协作，超越合同谈判
响应变更，超越履行几乎

敏捷原则：

1. 优先级最高的是，通过早期和持续交付有价值的软件来满足客户。
2. 欢迎变更需求，即使在开封的后期提出。敏捷过程为客户的竞争优势而控制变更。
3. 以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间定量。
4. 在整个项目过程中，每一天开发人员都要和业务人员合作。
5. 由个体推动项目的建设，为个体提供所需的环境，支持和信任。
6. 在开发团队中或开发团队间传递信息的最为有效和高效的方法是 面对面交谈。
7. 衡量进展的重要尺度是可运行的软件。
8. 敏捷过程提倡可持续的开发。
9. 发起人，开发者和用户应该步调一致。
10. 不断地关注技术上优越的设计会提高敏捷性。
11. 简洁是最重要的，简洁就是尽量减少工作量的艺术。
12. 最佳的架构，需求和设计来自于自组织的团队。
13. 团队要定期反省如何使工作更有效，然后相应地调整行为。

敏捷建模 包含如下许多实践和价值：

• 建模的目的主要是用于理解和沟通，而不是构建文档。
• 不要对所有或大多数软件设计建模或应用UML。可以将简单的设计问题推延到编程阶段，在编程和测试过程中解决这些问题。只需对设计空间中不常见，困难和棘手的一部分问题建模和应用UML.
• 不要单独建模，而是结对(或三个人)在白板上建模，同时要记住建模的目的是发现，理解和共享大家的理解。小组成员要轮流画草图，以使每个人都参与其中。

04 初始不是需求阶段

至善者乃善之敌也。
— 伏尔泰(Voltaire)
初始阶段是建立项目共同愿景和基本范围的比较简短的起始步骤。

在即将进行作战的时候，我经常发现之前制定的计划根本排不上用场，但制定计划这项工作却是必不可少的
— 艾森豪威尔

05 进化式需求

据统计，软件项目的平均需求变更率为25%。任何试图在开始就固定或定义所有需求的方法都具有本质上的缺陷，这些方法基于错误假设，因而只能拒绝或沉溺于不可避免的变更。

06 用例

用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。
用例作为行为的契约，专门和完整第捕获与满足涉众关注点相关的行为。

07 迭代1—基础

领域模型： 领域概念的可视化，类似于领域实体的静态信息模型。
设计模型： 描述逻辑设计的一组图，包括软件类图，对象交互图，包图等。

09 领域模型

领域模型是OOA中最重要和经典的模型。确定一组概念类是OOA的核心。
在UP中，领域模型是现实世界中对象的概念透视图。

如何创建领域模型：

1. 寻找概念类
   a. 重用和修改现有的模型
   b. 使用分类列表
   c. 确定名词短语
2. 将其绘制为UML类图中的类
3. 添加关联和属性

10 系统顺序图

用例描述外部参与者是如何与我们所希望创建的系统进行交互的。
系统顺序图 表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件。所谓系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。

应为每个用例的主成功场景，以及频繁发生的或者负责的扩展场景绘制SSD。

13 逻辑架构和UML包图

逻辑架构 是软件类的宏观组织结构，它将软件类组成为包，子系统和层等。

14 迈向对象设计

对象模型有两种类型：动态和静态。静态和动态建模之间具有关系，敏捷建模对此的实践是并行创建模型：花费较短的时间创建交互图(动态)，然后转到对应的类图(静态)，交替进行。
应该把时间花费在交互图(顺序图或通讯图)，而不仅仅是类图上。

基本的对象设计需要了解的是：

• 职责分配原则
• 设计模式

15 UML交互图

交互图有两种类型：顺序图(sequence diagram)和通信图(communication diagram)

为了支持有条件和循环的构造，UML使用了图框(frame)。
ALT图框放置与互斥的可选条件周围。
在UML中，在生命线框图的两侧加双竖线来表示主动对象。

16 UML类图

UML用类图表示类，接口及其关联。类图用于静态对象建模。
在类图中，使用依赖线描述对象之间的全局变量，参数变量，局部变量和静态方法的依赖。
聚合(aggregation)是UML种一种模糊的关联，其不精确地暗示了整体-部分关系。
组合(composition)是一种很强的整体-部分聚合关系。

17 GRASP 基于职责设计对象

GRASP(General Responsibility Assignment Software Patterns)包括如下9个模式:
Creator, Controller, Pure Fabrication
Information Expert, High Cohesion, Indirection
Low Coupling, Polymorphism, Protected Variations

控制器(Controller)是UI层之上的第一个对象，它负责接收和处理系统操作消息。
正常情况下，控制器应当把需要完成的工作委派给其他的对象。控制器只是协调或控制这些活动，本身并不完成大量工作。

控制器模式的重要推论是，UI对象和UI层不应具有处理系统事件的职责。

28 UML活动图及其建模

一个UML活动图表示一个过程中的多个顺序活动和并行活动。这些活动图有助于对业务过程，工作流，数据流和复杂算法进行建模。

UML活动图包括动作(action)，分区(partition)，分叉点(fork)，连接点(join)和对象节点(object node)

活动图能够既表示控制流又表示数据流。

29 UML状态机图和建模

状态机图描述了某个对象的状态和感兴趣的事件以及对象响应该事件的行为。

在过程控制，设备控制，协议处理和通信等领域通常有许多的状态依赖对象。在这些领域工作，应该熟悉和考虑使用状态机建模。

33 架构分析

架构分析的本质是要识别影响架构的因素，理解这些因素的可变性和优先级，并且解决这些问题。

决定在何处花费精力进行必要的设计，预防将来可能的变化，这是架构设计师的艺术。

架构分析特别关注非功能性需求。架构分析涉及系统级别的，大尺度，涉及面广的问题，解决这些问题通常涉及大尺度的或者基础的设计决策。权衡

架构分析指的是在功能性需求的语境中识别和解决非功能性需求。

35 包的设计

包在水平和垂直划分上的功能性内聚
由一族接口组成的包
用于正式工作的包和用于聚集不稳定类的包
职责越多的包越需要稳定
将不相关的类型分离出去
使用工厂模式减少对具体包的依赖
包之间没有循环依赖

39 架构的文档化：UML和N+1视图模型

一旦架构初具雏形，将它记录下来是有益的。在UP中，描述软件架构的文档称为”软件架构文档(SAD)”
在UP设计模型中，除了UML包图，类图和交互图之外，SAD是另外一个重要制品。

N+1 : 逻辑，进程，部署，数据 用例视图

40 架构的文档化：UML和N+1视图模型

如何计划一次迭代：

1. 第一步应确定迭代的时间长度；常见的时间长度为2~6周。迭代的结束时间一旦确定就不应改变—-这是时间定量的实践。可以通过减小本次迭代的工作范围来满足该结束时间。
2. 第二步是召集迭代计划会议。
3. 列出本次迭代的潜在目标(新特性，缺陷等)，并标记优先级。
4. 团队的每个成员应为本次迭代编制个人资源预算(以小时或天为单位)。所有的资源预算应当被汇总起来。

在“敏捷项目管理”方法中，开发人员积极参与计划和评估过程，而不是由项目管理者随意确定目标，评估和最后期限等。

迭代开发的重要思想之一就是根据反馈不断改进，而不是试图详细预测和计划整个项目。因此在UP中，只应为下一次迭代创建迭代计划。

可以让外部涉众看到一个宏观计划(如以三个月为时间粒度)，开发团队对此做出承诺。

在初始阶段的预计不是用来对项目持续时间和工作量进行承诺。相反，这些预计只为决策是否值得继续在细化阶段进行实际调查提供了参考。

在两次细化迭代之后，并且更接近细化阶段结束时，才会有充足的实际调查来对整个项目所需的工作量和持续时间进行承诺。