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中的作用
![](https://i-blog.csdnimg.cn/blog_migrate/4d1e465224494ae99642618d32241a1c.png)
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)
![](https://images.cnblogs.com/cnblogs_com/songsongww/1806230/o_200714103054%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20200714183038.png)
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
![](https://i-blog.csdnimg.cn/blog_migrate/572a12d44361f40862d28ce2ece02760.png)
2、什么是SSD
表示对用例的某一个场景,外部参与者产生的事件,其顺序和系统之内的事件;
个人理解:SSD是将用例中事件流图形化,以及其中的事件抽象成一个消息(抽象程度高,体现意图而不是实现方法的名称)
chapter11 操作契约
1、操作契约(operationscontract)的目的
定义系统操作,为系统操作创建契约
![](https://i-blog.csdnimg.cn/blog_migrate/743bf101be366ee13469e7a9f37804e4.png)
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、后置条件
![](https://i-blog.csdnimg.cn/blog_migrate/6045947554f5bc99493b49f1cd5e06c6.png)
用过去时表达后置条件,强调它们是由操作引起的状态变化的观察结果
4、如何创建和编写后置条件
![](https://i-blog.csdnimg.cn/blog_migrate/cdb5ce084b8862318c04802eea0ea9a1.png)
软件架构
1、软件架构4+1视图
![](https://i-blog.csdnimg.cn/blog_migrate/f98e625f66ed247f597f552997dc3778.png)
2、Coupling and cohension 耦合和内聚
![](https://i-blog.csdnimg.cn/blog_migrate/fdc5e99fc463ba56eb99e0d2075e4e5c.png)
![](https://i-blog.csdnimg.cn/blog_migrate/cf5c509722640c4a33dd068fbe9322bc.png)
3、SOLID准则
![](https://i-blog.csdnimg.cn/blog_migrate/8f76d7b0e64d056e6acc3ffdd6d3c724.png)
chapter13 逻辑架构
1、什么是逻辑架构
逻辑架构是软件类的宏观组织结构,它将软件类组织成包(命名空间)、子系统和层等
层 ——对类、包或子系统粗粒度的分组;职责:对系统的主要方面进行内聚(cohesion)
外部服务不应该是逻辑架构中的层,例如MySQL数据库不是架构中的一层,提供了数据库访问的层才是(如 DAO层)
chapter15 顺序图
1、顺序图的绘制(没啥好记的就只记录一些特殊的情况)
下面这个metaclass有点绕口,简单说就是java中所有类都是Class类的概念或者实例,所以font类是Class类这个元类的实例(类是元类的实例,即类的类是元类,而元类的类还是元类hhh)。这个画法的作用是当调用类的静态函数时是不需要实例化类的,相当于在给类发消息而非类的对象发,但是你会想一个类怎么接受消息呢?很简单—类是元类的实例,所以可以这样画
![](https://i-blog.csdnimg.cn/blog_migrate/a6755b4499cad1d949b9d7a5f793bdd1.png)
![](https://i-blog.csdnimg.cn/blog_migrate/275ca2ff1ac667bea798bff6e4218ce8.png)
通信图估计不考懒得记了
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里面添加代码或者修改
![](https://i-blog.csdnimg.cn/blog_migrate/1c91d3ced553dd723ebcaf847da4cf7f.png)
![](https://i-blog.csdnimg.cn/blog_migrate/b913513107dde3286a55d0491d7c4301.png)
8、Pure Fabrication纯虚构
问题: 你不想违背「高内聚和低耦合」或其他目标,但是基于专家模式所提供的方案「与之相悖逆时」,哪些对象应该承担这一职责?
![](https://i-blog.csdnimg.cn/blog_migrate/20bbb7d2cc5e54fe12d1fcf6d6249175.png)
![](https://i-blog.csdnimg.cn/blog_migrate/506634e092ac1da28a71b65b2c909b07.png)
优点: 支持高内聚,增加潜在的复用性
9、Indirection间接性
问题: 如何避免两个或多个事物之间直接耦合?
将职责分配给中介对象,使其作为其他构件或服务之间的媒介,避免它们之间的直接耦合
![](https://i-blog.csdnimg.cn/blog_migrate/6406b13e71ceb04e3c0a416336d55105.png)
10、 Protected Variations防止变异
问题: 何设计对象,使「其变化/不稳定」不会对「其他元 素 」产生不良影响?
预计」变化或不稳定之处,分配职责用以「在这些变化 之 外」创建稳定接口
chapter19 对可见性进行设计
1、什么是可见性
可见性是对象’看到‘或引用其他对象的能力
- 属性可见性——相对持久,A、B存在即保持
- 参数可见性——相对暂时,只在方法范围内存在
- 局部可见性——相对暂时,只在方法范围内存在
- 全局可见性——相对持久
参考文献
(美)Carig Larman著. UML模式和应用(原书第三版)[M]. 李洋等译. 机械工业出版社, 2006-05