POSA1第六章 模式与软件架构
6.1.2 组件
定义： 组件是被封装起来的软件系统的一部分，包含一个借口。组件是用于打造系统的构件。在编程语言层面，组件可能由模块、类、对象或一组相关的函数表示。
[PW92]将组件分为三类，并称之为元素：
- 处理元素
- 数据元素
- 连接元素
面向对象编程范式中采用了另一种分类方案，将组件分为如下几类：
- 控制组件
- 协调组件
- 接口组件
- 服务提供组件
- 信息存储组件
- 组织组件
这一节中描述了组件是什么，组件的外在表现形式是什么，以及组件的分类。其中对于第二种分类法，作者并没有提供出处。【待查明】
个人理解：尽管分类这个东西对于学术界意义更大，但是对我等开发设计人员来说也具有积极的指导意义。明确了我们要分解或者设计的组件是什么类型，能够帮助我们设计更加高内聚的组件。
（吐槽）常常看见产品里边的代码凌乱不堪，各种不同抽象层次的东西乱入，想改都不知从何下手。。。。。。
6.1.3 关系
关系指的是组件之间的联系，可以是静态的例如子类和父类之间的继承关系，也可以是动态关系例如publisher-subscriber之间的关系，容器和元素之间的动态关系。
通过各种组件间的关系，组件一起合成系统或者更大的逻辑单元。对于组件之间关系建模的好坏，决定了软件系统的可修改性。有实际项目经验的开发者，大概都见过修改某一个类或模块，影响到许多想关的类或模块的情况吧。
6.1.4 视图(View)
视图呈现软件架构的某个方面，展示软件系统的某些具体特征。组件的状态图，组件的协作图，组件部署图等等都是视图的例子。
著名的4+1架构视图模型中用四种视图来描绘架构。
- 逻辑视图：设计方案的对象模型或通信模型，如实体关系图
- 流程视图：并发性和同步方面
- 物理视图：软件与硬件的对应关系以及分布
- 开发视图：软件在开发环境中的静态组织结构
6.1.5 功能特征和非功能特征
Q: 设计软件架构时，为什么非功能特征很重要？
A: 首先，软件系统将随时间演化，它们必须应对不断变化的技术、需求和系统环境。因此，仅以合适的方式对应用程序面临的怎个任务进行分解还不够，系统还必须为应对变化、扩展和修改做好准备。否则，软件系统维护起来既困难又需付出高昂的代价，在其生命周期较长时尤其如此。其次，软件系统的功能常常需要满足某些通用需求，如总体可操作性、可靠性或效率。为此，必须妥善地设计其软件架构。
6.1.6 软件设计
软件设计指的是软件开发人员根据给定的功能和非功能特征，确定软件系统的组件以及组件之间关系的活动，其成果为系统的软件架构。
传统上，将系统高级结构分解称为“软件架构”、“软件架构设计”或者“粗粒度设计”，而将更详细的规划称为“设计”或者“详细设计”。
6.2.1 开发方法
这里所说的开发方法，指的是80年代末90年代初红极一时的OOA和OOD的方法，代表人物是后来建立UML和UP的三个老头。
作者论述了开发方法与模式的相似之处：它们都被寄予厚望，有点开发人员把它们当做方之四海皆准的银弹，这个想法是错误的。
作者希望人们降低对开发方法和模式的期望，认为这样能够更好地利用它们。
6.2.2 开发流程
地毯式的运用开发方法常常会导致严重的流程问题；明确的流程有优点，但是如果它带来了组织开销或采取的工作方式与项目目标格格不入，就会成为负担。
作者的观点：不应严格按照任何方法或流程进行设计和实现。
Q: 那么模式对于开发流程有什么帮助呢？
A: 增量交付过程和面向对象分析与设计的方法使得不同开发阶段之间的界限模糊。通过使用模式，我们可以让这种循序渐进甚至循环往复的工作方式更具有可预见性。