3.设计阶段
需求和面向对象分析的重点关注学习做正确的事，设计工作将强调正确的做事。
逻辑架构，包，层
2008年12月3日
17:00
逻辑架构：
部署架构：
软件架构：
使用层的好处
1.可以做到关系分离，高级服务和低级服务分离，特定于应用的服务与一般性服务分离。层可以减少耦合和依赖性，增强内聚性，提供潜在的复用性。
2.封装和分解了相关的复杂性。
3.逻辑划分，有助于团队开发。
领域层与应用逻辑，领域对象。
领域层，是包含软件对象，处理应用逻辑的层。
通过领域对象的启发，创建软件对象，组成领域层，可以获得真实世界和软件设计之间的低表示差异。
模型-视图分离原则
观察者模式是对该原则的合理扩展。
动机为：
1.支持内聚的模型定义。
2.使用户界面和模型没有依赖关系，可以分别开发。
3.降低用户界面对领域层的影响。
4.是用户界面可以方便的变更，已经更简单的支持其他模式，如批处理。
！！从ui层发送到领域层的消息将是ssd中描述的消息。！！
对象模型
2008年12月4日
10:30
职责驱动设计的大型方法的一部分：职责，角色和协作。
软件对象具有职责，对其所作所为的抽象。
职责分为：行为和认知。
- 自身执行一些行为，如创建对象或计算。
- 初始化其他对象的动作。
- 控制和协调其他对象的活动。
- 对私有封装数据的认知。
- 对相关对象的认知。
- 对其能够导出或计算的事物的认知。
低表示差异(LRG)：领域对象对他的属性，有认知的职责，根据LRG原则，对应的软件类也应该有这个认知的职责。
RDD是思考ood的一般性隐喻，把软件对象想象成具有某种职责的人，他要与其他人协作完成工作，RDD使我们把ood，看作是 有职责对象的进行协作的共同体。
GRASP 使用职责进行oo设计的工具
2008年12月4日
11:35
General responsibility assignment software patterns 通用职责分配模式。
分配原则
Creator ：
Information Expert:
Controller：
高级原则
Polymorphism:
Pure Fabrication:
Indirection:
Protected Variations:
衡量原则
Low Coupling:
High Cohesion:
交互图
2008年12月4日
11:36
分配职责的主要工具。
在交互图中分配职责，之后在类图的方法部分，记录下来分配结果，方法是职责的具体实现。
顺序图，重要特征：
在右侧添加新创建的类。
顺序图 和 系统顺序图 的区别要注意。
系统顺序图：描述主要参与者和系统的交互，这个时候系统是一个黑盒。
顺序图：对象之间的交互。
要点！！
1.之前画的图是错误的，因为采用了分层的架构，所以显然在画顺序图时也不应该涉及到别的层的内容。
2.之前，起始消息都是来自参与者，那个是错误的，
创始消息表示没有特定发送者，发送者不明确，或消息源众多的消息。
通信图，重要特征：
对象设计
2008年12月5日
10:48
用例实现：描述某个用例基于协作对象如何在设计模型中实现。
制品关系。
1。用例指出ssd中系统消息。
2。系统操作作为领域层的交互图的控制器的起始消息。
3。领域层的对象交互完成任务。
！每个领域层的交互图，都是从调用领域层的控制器对象的操作开始。
设计思路
将ssd的系统操作，作为交互图的起始消息。
- 起始消息来自 ssd
- 控制器协调，当前场景中的领域层对象开始处理消息。
- 根据契约的后置条件，用例，确定参与的软件对象。
- 根据领域模型，实现这些软件对象。
- 根据交互图，确定这些类的协作。
- 产生相关类图的关联，协作。
通过清晰的陈述职责，来分配职责。
链接UI 与 领域层的方法
1，ui调用控制器的X（），控制器调用领域层的X（）。这样做的话，控制器将变得和臃肿。
2，ui调用控制器的GetY（），获得领域层对象的引用，通过调用领域层对象的X（）方法。
注意在设计方法时不要违反，命令-查询分离原则。
Command-query-separation principle
1.执行动作的方法：具有改变对象状态的副作用。
2.查询方法：想调用者返回对象数据的方法。
不要让一个方法属于这2个类型。
推荐的实践方法，画5分钟交互图，画5分钟 类图，交替进行。
