软件体系结构与设计模式笔记

第1章软件体系结构概述✓SEI软件体系结构讨论群定义如下：一个程序/系统构件的结构，它们之间的相互关系，以及在设计和交付的整个过程中的原则和指导方针。

✓Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述，设计元素的交互，设计元素组合的模式，以及在这些模式中的约束。

✓软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。

✓国内普遍接受的定义：软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。

✓构件是可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元✓连接件也是可预制和可重用的软件部件，是构件之间的连接单元✓构件和连接件之间的关系用约束来描述✓软件体系结构= 构件+ 连接件+ 约束软件体系结构的优势容易理解、重用、控制成本、可分析性第2章软件体系结构风格♦软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

♦体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。

词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

♦体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

♦数据流风格: 批处理序列; 管道/过滤器。

♦调用/返回风格：主程序/子程序；面向对象风格；层次结构。

♦独立构件风格：进程通讯；事件系统。

♦虚拟机风格：解释器；基于规则的系统。

♦仓库风格：数据库系统；超文本系统；黑板系统。

♦过程控制环路♦C/S风格体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。

♦B/S风格浏览器/Web服务器/数据库服务器。

优点：C/S体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。

将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

缺点：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一，使用繁杂不利于推广使用、软件移植困难、软件维护和升级困难、新技术不能轻易应用优点：基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。

缺点：B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。

B/S体系结构的系统扩展能力差，安全性难以控制。

采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远低于C/S体系结构。

B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。

第3章软件需求与架构♦需求的基本概念✓IEEE (1997)➢(1) 用户解决问题或达到目标所需的条件或能力➢(2) 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力➢(3) 一种反映上面（1）或（2）所描述的条件或能力的文档说明♦业务需求✓反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求♦用户需求✓描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。

♦系统需求✓从系统的角度来说明软件的需求，包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束等。

♦非功能需求✓指产品必须具备的属性或品质，如正确性、可靠性、性能、容错性和可扩展性等。

♦功能需求✓需求的主体，需求的本质✓功能需求定义：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作♦设计约束♦获取需求的方法✓面谈（访谈）✓问卷调查✓会议（需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会）✓文档研究✓任务示范（观察）✓用例与角色扮演✓原型设计（小规模试验）研究类似公司♦需求的层次化✓业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。

✓用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？✓开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？♦需求分类✓功能需求：更多体现各级直接目标要求✓质量属性：运行期质量+ 开发期质量✓约束需求：业务环境因素+ 使用环境因素+ 构建环境因素+ 技术环境因素✓功能模型——如UC✓业务流程模型——如DFD✓数据建模模型——如ER♦用例建模（Use Case Modeling）是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。

♦粒度原则：♦用例要有路径，路径要有步骤。

而这一切都是“可观测”的。

✓需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。

♦外部质量对于用户而言是可见的包括正确性、健壮性、可靠性、性能、安全性、易用性、兼容性等。

♦内部质量只有开发人员关心它们可以帮助开发人员实现外部质量包括易理解性、可测试性、可维护性、可扩展性、可移植性、可复用性等✓依赖注入♦构造注入(Constructor Injection)：通过构造函数注入实例变量。

♦设值注入(Setter Injection)：通过Setter方法注入实例变量。

♦接口注入(Interface Injection)：通过接口方法注入实例变量。

1.用例文档♦用例编号♦用例名♦执行者♦前置条件♦后置条件♦涉众利益♦基本路径✓1…..××××✓2……××××✓3…..××××2.需求规格说明书第1章_统一建模语言基础知识a)视图(View)i.用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。

ii.结构视图：表示系统的静态行为，描述系统的静态元素，如包、类与对象，以及它们之间的关系。

iii.行为视图：表示系统的动态行为，描述系统的组成元素如对象在系统运行时的交互关系。

iv.实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。

v.环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。

用例图(Use Case Diagram): 又称为用况图，对应于用户视图。

在用例图中，使用用例来表示系统的功能需求，用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。

用例图与用例说明文档(Use Case Specification)是常用的需求建模工具，也称之为用例建模。

类图(Class Diagram)：对应于结构视图。

类图使用类来描述系统的静态结构，类图包含类和它们之间的关系，它描述系统内所声明的类，但它没有描述系统运行时类的行为。

♦类之间的关系✓关联关系•关联关系(Association)是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。

•双向关联•单向关联•自关联•重数性关联✓聚合关系•聚合关系(Aggregation)表示一个整体与部分的关系。

通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。

✓组合关系•组合关系(Composition)也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。

一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。

✓依赖关系•依赖关系(Dependency)是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。

大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。

✓泛化关系•泛化关系(Generalization)也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。

在UML中，泛化关系用带空心三角形的直线来表示。

✓接口与实现关系•接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系(Realization)，在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。

在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。

♦顺序图定义✓顺序图(Sequence Diagram)是一种强调对象间消息传递次序的交互图，又称为时序图或序列图。

♦状态图定义✓状态图(Statechart Diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。

第2章_面向对象设计原则♦单一职责原则要求在软件系统中，一个类只负责一个功能领域中的相应职责。

♦开闭原则要求一个软件实体应当对扩展开放，对修改关闭，即在不修改源代码的基础上扩展一个系统的行为。

♦里氏代换原则可以通俗表述为在软件中如果能够使用基类对象，那么一定能够使用其子类对象。

♦依赖倒转原则要求抽象不应该依赖于细节，细节应该依赖于抽象；要针对接口编程，不要针对实现编程。

♦接口隔离原则要求客户端不应该依赖那些它不需要的接口，即将一些大的接口细化成一些小的接口供客户端使用。

♦合成复用原则要求复用时尽量使用对象组合，而不使用继承。

♦迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。

第3章_设计模式概述♦设计模式的定义✓设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

✓设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式，其中的关键元素包括以下四个方面：♦模式名称(Pattern name)♦问题(Problem)♦解决方案(Solution)♦效果(Consequences)第4章_简单工厂模式✓简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。

在简单工厂模式中，可以根据参数的不同返回不同类的实例。

简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

✓重构后的代码：public abstract class AbstractPay{public abstract void pay();}public class CashPay extends AbstractPay{public void pay(){//现金支付处理代码}}public class PayMethodFactory{public static AbstractPay getPayMethod(String type){if(type.equalsIgnoreCase("cash")){return new CashPay(); //根据参数创建具体产品}else if(type.equalsIgnoreCase("creditcard")){return new CreditcardPay(); //根据参数创建具体产品}……}}✓简单工厂模式最大的缺点是当有新产品要加入到系统中时，必须修改工厂类，加入必要的处理逻辑，这违背了“开闭原则”。