软件体系结构复习

软件体系结构风格

软件体系结构包括 构件（Component) 连接件（Connector）和约束（Constraint)或配置（Configuration)
他是可预制和可重构对的软件框架结构
常见风格：
数据流风格
调用返回风格
独立构件风格
虚拟机风格
仓库风格
过程控制环路
C/S风格：三个重要组成部分：数据库服务器，客户应用程序和网络
优点：具有强大的数据操作和事物处理能力，模型思想简单，易于人们理解接受
对硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小
将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节省大量费用
缺点：
开发成本高
客户端设计复杂
信息内容和形式单一
用户界面风格不一，使用复杂，不利于推广
软件移植困难

B/S风格

B/S优点

基于B/S体系结构的软件，系统安装，修改和维护全在服务器端解决，用户在使用系统时，仅仅需要一个浏览器就可以运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
B/S体系结构还提供了异种机，异构网，异种应用服务器的联机，联网，统一服务的最现实的开放性基础。
B/S缺点
B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能
B/S体系结构的系统扩展能力差，安全性难以控制
采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远低于C/S系统结构
B/S体系结构数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理的应用。

软件质量属性

性能（Performance）、可用性（Availability）、可靠性（Reliability）、健壮性（Robustness）、安全性（Security）、可修改性（Modification）、可变性（Changeability）、易用性（Usability）、可测试性（Testability）、功能性（Functionality）和互操作性（Inter-operation）

统一建模语言

用例建模（Use Case Modeling)

用例建模使用

1. 用例建模包括 用例图（Use Case Diagram) 和 用例描述文档（Use Case Specification)
2. 执行者（Actor）：在系统之外，通过系统边界与系统进行有意义交互的任何事物。（引入执行者就是为了帮助确定系统边界）
3. 用例(User Case):用例是在系统执行中的一系列动作，这些动作将生成特定的执行者课见的简直成果。一个用例定义一组用例实例。

状态图（State Diagram)

用域描述一个特定对象所有可能状态及其引起状态转移的事。

活动图（Activity Diagram)

用来描述系统中各种活动的次序，他的应用非常广泛，既可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。
活动图由 起始活动（Start Activity),终止活动（End Activity),活动（Activity)
转移（Transition)或流（Flow）、决策（Decision)、守护条件（Condition)、
同步条（Synchronization)和泳道（Swimlane)组成

顺序图（Sequence Diagram)

顺序图一般用于确定和丰富一个使用场景的逻辑

类图（Class Diagram)

包图（Package Diagram)

包图用来描述包与包之间的关系，包的图标是一个带标签的文件夹
包之间的关系：引入关系，泛化关系，嵌套关系

组件图（Component Diagram）

组件图可以用来显示编译，链接或执行时组件之间的依赖关系，以及组件的接口和调用关系
组件图的关系有：泛化和依赖

部署图（Deployment Diagram)

部署图描述系统硬件的

对象图（Object Diagram)

组合结构图（Composite Structure Diagram)

组合结构图将每个类放在一个整体中，从类的内部结构来审视这个类

通信图（Communication Diagram)

通信图清晰的显示了对象的关系和时间次序

定时图（Timing Diagram)

定时图用于表示不同对象上状态改变之间的定时约束，如果需要对交互时间进行控制，可使用定时图。

交互概览图（Interaction Overview Diagram)

交互概览图是交互图和活动图的混合无，可以把交互概览图理解成细化的活动图。

面向对象设计原则

单一职责原则（Single Responsibility Principle）

一个对象应该只包含单一的职责，并且该职责被完整的封装到一个类中

开闭原则（Open-Closed Principle)

软件实体应该对扩展开发，对修改关闭

里氏代换原则（Liskov Substitution Principle)

所有引用基类的地方必须能够透明的使用其子类的对象

依赖倒转原则（Dependence Inversion Principle)

高层模块不应该依赖低层模块，他们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象

接口隔离原则（interface Segregation Principle)

客户端不应依赖于那些它不需要的接口

合成复用原则（Composite Reuse Principle)

优先使用对象组合，而不是继承来达到复用目的

迪米特法则（Law Of Demeter)

每一个软件单位对其他单位都 局限于那些与本单位密切相关的软件单位）

设计模式

简单工厂模式

工厂方法模式（Factory)

定义一个用于创建对象的接口，但是IOOOOOOOOOOOO4-P-P-P-P让子类决定将哪个类实例化。工厂方法模式让一个类的实例化延迟到其子类。

抽象工厂模式（Abstract Factory)

提供一个创建一系列相关或者相互依赖对象的接口，而无需指定它们的具体的类。
增加新的产品组，不需要修改源代码，符合开闭原则。
增加新的产品等级结构，所有工厂类都要修改，不符合开闭原则

原型模式（Prototype)

使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。
深克隆：
浅克隆：
单例模式（Singleton)

适配器模式（Adapter)
桥接模式（Bridge）
组合模式（Composite)
外观模式（Facade)
代理模式（Proxy)

职责链模式（Chain of Responsibility)
命令模式（Command)
观察者模式（Observer)
策略模式（Strategy)
模板方法模式（Template Method)