软件架构的概念
软件架构的概念：软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。软件架构是指一个系统的基础组织，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。
软件架构的风格
软件架构风格：描述某一特定应用领域中系统组织方式的惯用模式。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
软件架构风格分类：
- 数据流风格：批处理序列；管道/过滤器。
- 调用/返回风格：主程序/子程序；面向对象风格；层次结构。
- 独立构件风格：进程通信；事件系统。
- 虚拟机风格：解释器；基于规则的系统。
- 仓库风格：数据库系统；超文本系统；黑板系统。
特定领域软件架构
特定领域软件架构DSSA：可以看做开发产品线的一个方法（或理论），它的目标就是支持在一个特定领域中有多个应用的生成。
DSSA 的必备特征有：
- 一个严格定义的问题域或解决域。
- 具有普遍性，使其可以用于领域中某个特定应用的开发。
- 对整个领域的合适程度的抽象。
- 具备该领域固定的、典型的在开发过程中的可复用元素。
从功能覆盖的范围角度理解 DSSA 中领域的含义有两种方法：
- 垂直域。定义了一个特定的系统族，导出在该领域中可作为系统的可行解决方案的一个通用软件架构。
- 水平域。定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统（族）的特定部分功能。
DSSA 的活动阶段如下：
- 领域分析：主要目标是获得领域模型。
- 领域设计：目标是获得 DSSA，它是一个能够适应领域多个系统的需求的一个高层次的设计。
- 领域实现：主要目标是依据领域模型和 DSSA 开发与组织可复用信息。
领域模型的主要作用如下：
- 领域模型为需求定义了领域知识和领域词汇，这较之单一的项目需求更有较好的大局观。
- 软件界面的设计往往和领域模型关系密切。
- 领域模型的合理性将严重影响软件系统的可扩展性。
- 在分层架构的指导下，领域模型精化后即成为业务层的骨架。
- 领域模型也是其数据模型的基础。
- 领域模型是团队交流的基础，因为它规定了重要的领域词汇表，并且这些词汇的定义是严格的、大家共同认可的。
基于架构的软件开发方法
基于架构的软件设计ABSD：是一种架构驱动方法。
ABSD有 3 个基础：
- 功能的分解。在功能分解中，ABSD 方法使用已有的基于模块的内聚和耦合技术。
- 通过选择架构风格来实现质量和业务需求。
- 软件模板的使用。软件模板利用了一些软件系统的结构。
ABSD 方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。
ABSD 方法的输入由下列部分组成：
1）抽象功能需求，包括变化的需求和通用的需求；
2）用例（实际功能需求）；
3）抽象的质量和业务需求；
4）质量因素（实际质量和业务需求）；
5）架构选项；
6）约束。
基于架构的软件开发模型：把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等 6 个子过程。
软件架构评估
软件架构评估：在对架构分析、评估的基础上，对架构策略的选取进行决策。
软件架构评估的方法：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
架构的权衡分析法ATAM：从技术角度对软件架构进行评估，旨在通过分析来预见软件的质量；通过分析来创建、选择、评估与比较不同的架构。
成本效益分析法CBAM：是在 ATAM 上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。CBAM 的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目关系人带来一些收益（称为“效用”），CBAM 协助项目关系人根据其投资回报（ROI）选择架构策略。
软件产品线
软件产品线：指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。
软件产品线架构：针对一系列产品而设计的通用架构，并在此基础上，进一步将系列产品共用的模块事先实现，供直接重用；将架构用框架的形式予以实现，供定制使用。这就是通常所说的“平台”。
产品线架构较之单个产品架构，有如下三点特别之处：
- 产品线架构必须考虑一系列明确许可的变化。
- 产品线架构一定要文档化。
- 产品线架构必须提供“产品创建者指南”（开发指南），描述架构的实例化过程。
产品线的软件架构提出应考虑三个方面：确定变化点、支持变化点、对产品线架构的适宜性进行评估。
产品线的开发模型：
- “前瞻性”产品线：利用在应用领域的经验、对市场和技术发展趋势的了解及商业判断力等进行产品线设计，它反映了企业的战略决策。通常是自上而下地采用产品线方法。
- “反应性”模型：企业根据以前的产品构建产品家族，并随着新产品的开发，扩展架构和设计方案，它的核心资产库是根据“已经证明”为共有、而非“预先计划”为共有的元素构建的。通常是自下而上地采用产品线方法。
设计模式
设计模式的概念：设计模式解决的是一类问题。设计模式是一种通用的解决方案，而不是具体的，也不是唯一的。
设计模式的组成：模式名称、问题、解决方案、效果。
设计模式分为三类，分别为创建型、结构型和行为型。
设计原则：单一职责原则、里氏替换原则、接口隔离原则、依赖倒置原则、开闭原则。
GoF 设计模式( 23 个模式统称)：
- 单例模式：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
- 工厂模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
- 抽象工厂模式：为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。
- 模板方法模式：定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
- 建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
- 代理模式：为其他对象提供一种代理以控制对这个对象的访问。
- 原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
- 中介者模式：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
- 命令模式：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
- 责任链模式：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
- 装饰模式：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。
- 策略模式：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换
- 适配器模式：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
- 迭代器模式：它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。
- 组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
- 观察者模式：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
- 门面模式：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。
- 备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
- 访问者模式：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
- 状态模式：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。
- 解释器模式：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
- 享元模式：使用共享对象可有效地支持大量的细粒度的对象。
- 桥梁模式：将抽象和实现解耦，使得两者可以独立地变化。
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
