Elaboration细化迭代一
chapter8 细化迭代一
1、细化阶段的工作
- 对核心、风险的软件架构进行编程和测试 the core and risky software architecture is programmed and tested
- 发现并稳定需求的主体部分 the majority of requriements are discovered and stabilized
- 规避主要风险 the majority of risks are mitigated and retired
Summary: Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources
2、细化阶段的制品
| Artifact | Comment |
|---|---|
| Domain Model | 领域概念的可视化 |
| Design Model | 描述逻辑设计的一组图，包括软件类图、交互图、包图等 |
| Software Architecture Document | |
| Data Model | 数据库方案，对象和非对象之间的映射 |
| Use-case Storyboards, UI Prototypes |
chapter9 领域模型
1、领域模型在OOA中的作用
2、什么是领域模型
A domain model is a visual representation of conceptual classes or realsituation objects，it also been called conceptual models, domain object models, and analysis object models
领域模型是对领域内概念类或者现实中对象的可视化表现，也被称为概念模型、领域对象模型和分析对象模型
领域模型是将现实中的事物概念化、可视化，例如购买这一行为概念化成一个符号Sale，具有属性时间
3、什么是概念类（conceptual classes）
4、为什么创建领域模型
domain model is helpful to understand the key concepts and vocabulary in the real situation.
5、如何创建领域模型
- Find the conceptual classes
- Draw them as classes in a UML class diagram
- Add associations and attributes
如何找到概念类：使用分类列表（对照文档查表寻找概念类）、识别名词短语（从文档中识别名称短语，作为候选的概念类或属性）
领域模型的绘制类似ER图，具体可以查阅书本
chapter10 系统顺序图
1、系统顺序图SSD的目的
- Identify system events
- create it for use-case scenario
2、什么是SSD
表示对用例的某一个场景，外部参与者产生的事件，其顺序和系统之内的事件；
个人理解：SSD是将用例中事件流图形化，以及其中的事件抽象成一个消息(抽象程度高，体现意图而不是实现方法的名称)
chapter11 操作契约
1、操作契约（operationscontract）的目的
定义系统操作，为系统操作创建契约
2、操作契约的内容
- Operation（操作）: Name of operation, and parameters
- Cross References（交叉引用）: Use cases this operation can occur within
- Preconditions（前置条件）: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. These are non-trivial assumptions the reader should be told.
- Post-conditions（后置条件）: This is the most important section. The state of objects in the Domain Model after completion of the operation. Discussed in detail in a following section.
3、后置条件
用过去时表达后置条件，强调它们是由操作引起的状态变化的观察结果
4、如何创建和编写后置条件
软件架构
1、软件架构4+1视图
2、Coupling and cohension 耦合和内聚
3、SOLID准则
更正：L是里氏替换原则，上面的‘接口隔离’是对I的描述
chapter13 逻辑架构
1、什么是逻辑架构
逻辑架构是软件类的宏观组织结构，它将软件类组织成包（命名空间）、子系统和层等
层 ——对类、包或子系统粗粒度的分组；职责：对系统的主要方面进行内聚（cohesion）
外部服务不应该是逻辑架构中的层，例如MySQL数据库不是架构中的一层，提供了数据库访问的层才是（如 DAO层）
chapter15 顺序图
1、顺序图的绘制（没啥好记的就只记录一些特殊的情况）
下面这个metaclass有点绕口，简单说就是java中所有类都是Class类的概念或者实例，所以font类是Class类这个元类的实例（类是元类的实例，即类的类是元类，而元类的类还是元类hhh）。这个画法的作用是当调用类的静态函数时是不需要实例化类的，相当于在给类发消息而非类的对象发，但是你会想一个类怎么接受消息呢？很简单—类是元类的实例，所以可以这样画
通信图估计不考懒得记了
chapter16 类图
1、类图
看书10分钟，贴图半小时，所以还是看书吧
chapter17 GRASP
1、什么是GRASP
General Responsibility Assignment Software Pattern（Principle）
基于职责设计类的一系列模式或者准则，其实就是基于这一套准则结合前面的制品去设计类
2、Creator创造者模式
问题： 谁负责创建某类的新实例？
如果如下条件之一为真，则类B具有创建类A的职责：
- 类B包含/组成聚集A
- B记录A
- B紧密地使用A
- B拥有A的初始化数据，并且创建A时将这些参数传递给A
3、Information Expert信息专家
问题： 给对象分配职责的基本原则是什么？
把职责分配给具有履行职责所需信息的那个类
4、Low Coupling低耦合
问题： 如何降低依赖，减少变化带来的影响，提高复用性？
分配职责，使耦合性尽量降低
5、Contorller控制器
问题： 在UI层上首先接收和协调（控制）系统操作的第一个对象是什么？
使用控制器接收和处理系统操作消息，其实大体上就是MVC中的 C
消息不从UI层直接发给业务对象，而是委派给一个中间人控制器，由控制器再委派给其他业务对象，避免UI层和业务对象直接耦合（UI层包含应用逻辑和处理系统事件）
6、High Cohesion高内聚
问题： 怎么使对象是有重点的、可理解的、可管理的，并且能够支持低耦合？
分配职责使对象保持高内聚，做许多相关的工作
7、Polymorphism多态
问题： 如何处理基于类型的选择（不同类处理同一件事情有不同的操作）？如何创建可拔插的软件构件？
当相关行为/选择随类型（类）有所不同时，使用多态操作为变化的行为类型分配职责；不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择
例如对应不同州有不同的计税方式（足够复杂到需要划分类来实现一种方式），那么我可以让这些不同方式的类实现同一个接口
那么如果我在计价的类Total里面需要调用计税方法getTax，同时将计税对象作为它的成员，我就不需要管拿到的计税的对象是哪一个类的，直接调用方法就好，否则还需要根据不同计税类再在Total里面添加代码或者修改
8、Pure Fabrication纯虚构
问题： 你不想违背「高内聚和低耦合」或其他目标，但是基于专家模式所提供的方案「与之相悖逆时」，哪些对象应该承担这一职责？
优点： 支持高内聚，增加潜在的复用性
9、Indirection间接性
问题： 如何避免两个或多个事物之间直接耦合？
将职责分配给中介对象，使其作为其他构件或服务之间的媒介，避免它们之间的直接耦合
10、 Protected Variations防止变异
问题： 何设计对象，使「其变化/不稳定」不会对「其他元 素 」产生不良影响？
预计」变化或不稳定之处，分配职责用以「在这些变化 之 外」创建稳定接口
chapter19 对可见性进行设计
1、什么是可见性
可见性是对象’看到‘或引用其他对象的能力
- 属性可见性——相对持久，A、B存在即保持
- 参数可见性——相对暂时，只在方法范围内存在
- 局部可见性——相对暂时，只在方法范围内存在
- 全局可见性——相对持久
参考文献
(美)Carig Larman著. UML模式和应用(原书第三版)[M]. 李洋等译. 机械工业出版社, 2006-05