软件架构设计 温昱著 – 读书笔记

 

 

#读后感#一本实用性很强的架构入门书籍。内容有深有浅，涉及面广，帮我们树立一个架构设计的全局观。 

本书已读完，把读后感放在最前面，以下是详细的读书笔记。

 

#读书笔记# 我们将软件架构概念分为两大流派：组成派和决策派。

#读书笔记# 组成派：软件系统的架构将系统描述为计算组件及组件之间的交互。

#读书笔记# 决策派：软件架构包含了关于以下问题的重要决策：软件系统的组织；选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；如何组合这些元素，使它们逐渐合成为更大的子系统；用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合。——1

#读书笔记# 决策派：软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。——2

#读书笔记# “架构决策是分层次依次展开的”还表现在：决策制定的顺序往往是先制定技术无关的决策，后制定技术相关的决策，后者在前者的指导下进行。

#读书笔记# 两个流派的观点可以简单概括成：组成派“架构 = 组件 + 交互”，决策派“架构 = 重要决策集”。它们虽然角度不同，但却相辅相成。

 

#读书笔记# 框架是软件，架构不是软件。框架是系统或子系统的半成品。软件架构不是软件，而是关于软件如何设计的重要决策。软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。

 

#读书笔记# 产品线架构一定要文档化是有道理的。

 

#读书笔记# 软件架构师必须牢记：关注“软件运行期质量属性”，为开发人员而设计。

 

#读书笔记# Philippe Kruchten在其著作《Rational统一过程引论》中写道：一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。

 

#读书笔记# 软件架构的每个视图分别关注不同的方面，针对不同的目标和用途。

  

#读书笔记# 从概念性架构到实际架构，先设计概念性架构，构思关键问题的解决策略；再进行实际架构的设计，以保证为开发提供足够的指导和限制……这符合人类解决问题的规律，因此被广泛采用。

 

#读书笔记# 易用性、性能、可伸缩性、持续可用性、鲁棒性、安全性、可扩展性、可重用性、可移植性、易理解性和易测试性等都可能是软件的质量属性需求。这些质量属性之间存在一定的相互矛盾的情况。

 

#读书笔记# 制定软件架构设计策略：策略一，全面认识需求；策略二，关键需求决定架构；策略三，多视图探寻架构；策略四，尽早验证架构。

 

#读书笔记# 高来高去式的架构设计大致有如下三种表现：症状一，缺失重要架构视图；症状二，浅尝辄止、不够深入；症状三，名不副实的分层架构。

 

#读书笔记# 关于软件架构到底要设计到什么程度，可以归纳为两句话：由于项目的不同、开发团队情况的不同，软件架构的设计程度会有不同；软件架构应当为开发人员提供足够的指导和限制。

 

#读书笔记# 囫囵吞枣地认为“需求就是用户的要求”绝对是不够的。

 

#读书笔记# 需求分析致力于搞清楚软件系统要“做什么”，而系统分析更关注“怎么做”的问题。

 

#读书笔记# 功能需求影响架构，而架构必须适应功能需求。但功能需求并不能决定架构，这是显而易见的。

 

#读书笔记# 约束性需求最为特殊，它可能产生的影响有3种：（1）作为架构设计时必须遵守的限制条件；（2）导致软件系统必须提供某些功能需求；（3）导致软件系统必须满足某些约束性需求。（参见图10-8）

 

#读书笔记# 用例的名称应该从参与者的角度进行描述，并以动词开头，这样一来通过“读图”可以清晰地获得用例图的语义。

 

 

#读书笔记# 用例图最重要的元素是参与者（Actor）和用例（Use Case）。

 

#读书笔记# 用例简述，就是通过简短的文字对用例的功能进行描述；一般而言，用例简述都应包含成功场景的简单描述。

 

#读书笔记# 用例规约是对用例的详细描述，一般包括简要说明、主事件流、备选事件流、前置条件、后置条件和优先级等。用例规约的主要目的是界定软件系统的行为需求。

 

#读书笔记# 用例图从总体上反映了用户需求，而用例简述和用例规约分别是行为需求的简化描述和详细描述。至于用例实现，已属于设计范畴了。

 

#读书笔记# 需求变化波及不同需求工件的规律：用例图作为功能需求的泛而不深的总体描述，它是比较稳定的；用例简述不涉及细节，因此也比较稳定；用例规约通过交互序列的方式描述功能需求，受需求变化影响较大。

  

#读书笔记# 必须聪明地应付需求变更：推后用例细化；激发需求变更。

 

#读书笔记# 架构师首要的第一步是做需求分析，涉及到的文档或方法依次有：需求采集卡、愿景与范围文档、特性列表、用例图、用例简述、用例规约、原型启发需求、需求验证、软件需求规格说明书（含非功能需求）。

 

#读书笔记# 领域模型对软件架构乃至整个软件系统开发工作的作用可以归纳为3点：探索复杂问题、固化领域知识；决定功能范围、影响可扩展性；提供交流基础、促进有效沟通。

 

#读书笔记# 关键性的第一步是缩小范围。

 

#读书笔记# 穷兵黩武还是择战而斗

 

#读书笔记# 关键需求决定架构，其余需求验证架构。

  

软件需求的类型

 

 

 

软件质量属性分类方式

 

 

质量属性关系矩阵

 

 

 

调整后的质量属性关系矩阵

 

 

 

确定对软件架构关键需求的步骤

 

 

 

概念性架构设计大致可以分为如下三步：
第一步，鲁棒性分析。
第二步，引入架构模式。
第三步，质量属性分析。

 

 

架构模式现代分类的经典图书《面向模式的软件体系结构》，1996年出版。

  

各层之间的单向依赖又可以分为两种：严格的分层架构要求第n层只能被第n+1层调用，与此相对的是不严格的分层架构，第n层可以被位于其上层的任意一层调用。

 

在概念性架构设计时，功能需求是鲁棒性分析最主要的输入，而质量属性需求是质量属性分析的最主要的输入。

  

“属性——场景——决策”表方法提倡通过一组具体场景将要达到的质量属性需求目标细化，再根据这些实实在在的场景制定架构决策。

 

“属性——场景——决策”表方法使软件架构设计的决策过程从“黑盒”变成了“灰盒”，这样做有以下好处：
1.可操作性强。
2.避免过度设计。
3.便于系统升级时参考。

 

一般而言，逻辑架构的设计应完成下列工作：

• 细化功能单元；
• 发现通用机制；
• 细化领域模型；
• 确定子系统接口和交互机制。

 

机制（Mechanism）是模式的实例。机制必须进一步细化才能成为特定模型中的协作，因此，机制是独特上下文中重复出现的问题的特定解决方案。

 

进程被称为“重量级控制流”，因为它既是处理机资源的分配单位，又是其他计算机资源的分配单位。线程则被称为“轻量级控制流”，它仅仅是处理机资源的分配单位。一个进程内可以包含多个线程，这些线程共享所在进程的资源。

 

 

 

根据开发原型的目的是模拟系统运行时的概貌、还是纵深地验证一个具体的技术问题，可以将原型法分为两类： 水平原型和 垂直原型 。

有些原型用过之后是注定要被抛弃的，而有些原型我们则希望把它们保留下来作为正式开发的基础。我们又可以将原型法分为两类： 抛弃原型和 演进原型。

 

验证架构有两种方法—— 原型法和 框架法。

架构原型对功能性需求的实现非常有限，那么我们“架构验证”要验证什么案是要 验证架构对质量属性需求的支持程度。

 

架构原型所实现的有限的功能需求应经过细心挑选，这些功能要么是用户“最关心的”，要么是架构师“最担心的”。

 

“见继承不是继承”， 在这个阶段的人，脑中的兴奋点是“设计”，是职责分配、接口设计、可重用性、可扩展性、耦合度、聚合度等这些设计层的概念。

 

耦合是依赖的同义词，被定义为“两个元素之间的一种关系，其中一个元素变化，导致另一个元素变化”。

 

混入类的作用在于：它不仅可以提高功能的重用性，减小代码冗余；而且还可以使相关的“行为”集中在一个类中，而不是分布到多个类中，避免了所谓的“代码分散”和“代码交织”问题，提高了可维护性。

 

不会“在实际中”造成危害的依赖关系，都是良性依赖；依赖的“理论危害”不一定成为“实际危害”，反之亦然。这就是良性依赖原则。