体系结构资料：太君的软件架构.docx

设计的5个准则
准则1：用“美”的方式实现功能，是设计的价值
准则2：设计的复杂度 = 事物复杂度 + 载体与事物的适配复杂度
准则3：设计重在内部结构，而不是外在表现
内部结构：为了实现外部的功能，进行的内部的安排，主要关注质量
views and evaluators
consider: system consistency, validity
help architect during the architecture design
help illustrate and validate the document
OO 协作与协作设计（理解）
What’s Collaboration
An application can be broken down into a set of many different behaviors. 
Each such behavior is implemented by a distinct collaboration between the objects of the application
Every collaboration, no matter how small or large, always implements a behavior of the application
Imagine an object-oriented application as a network of objects connected by relationships. Collaborations are the patterns of messages that play through that network in pursuit of a particular behavior. The collaboration is distributed across the network of objects, and so does not exist in any one place
Collaboration Design
Identify collaboration:
system behavior from use-case
from software architecture design(Module interface and Process communication)
Design collaboration(of system behaviors: control structures):
two ways: Dispersed and Centralized
Dispersed: Logics of a system behavior is spread widely through the objects network
Centralized: One extra controller record all logics of a system behavior
Control Styles: Dispersed, Centralized, Delegated
Centralized Control:
Easy to find where the decision are made
Easy to see how decision are made and to alter the decision-making process
Controllers may become bloated (large, complex and hard to understand, maintain, test)
Controller may treat other components as data repositories
Increase coupling destroys information hiding
Delegated Control:
Controller are coupled to fewer components, reducing coupling
Information is hidden better
easier to divide into layers
Delegated control is the preferred control style
Dispersed Control:
having many components holding little data and having few responsibilities