一、质量属性定义
1、性能
定义：指系统的相应能力，即要经过多长时间才能对某个事件做出响应，或在某段时间内系统所能处理的事件个数。如响应时间、吞吐量
设计策略：优先级队列、资源调度
2、可用性
定义：指系统能能够正常运行的事件比例，经过两次故障之间的时间长度或在出现故障的时系统能够恢复正常的速度表示。
设计策略：心跳、ping/Echo、冗余、选举
3、安全性
定义：指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
设计策略：入侵检测、用户认证、用户授权、追踪审计
4、可修改性
定义：指能够快速的以较高的性价比对系统进行变更的能力。
设计策略：接口-实现分类、抽象、信息隐藏
架构风险：在架构设计中潜在的，存在问题的架构决策所带来的隐患。
敏感点：为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
二、系统架构风格对比
1、考试真题对比
| 质量属性 | 面向对象风格 | 解释器风格 |
|---|---|---|
| 可修改性 | 面向对象相对固定，有变化的时候需要修改具体的类 | 解释器的规则是独立的语法规则，由解释器可对变化的规则进行解析，修改更容易 |
| 灵活性 | 面向对象相对固定，将规则封装成对象，在启动时加载，灵活性差 | 解释器可以根据用户灵活解释执行规则，做到千人千面 |
| 性能 | 规则已经在系统内，可直接运行，性能较高 | 需要对规则实时解释，性能较差 |
| 质量属性 | 面向对象风格 | 基于规则 |
|---|---|---|
| 可扩展性 | 架构新的规则需要i重新定义新的对象，并需要重启系统 | 只需要定义新的规则，解释规则即可进行阔扩展 |
| 灵活性 | 面向对象相对固定，将规则封装成对象，在启动时加载，灵活性差 | 解释器可以根据用户灵活解释执行规则，做到千人千面 |
| 性能 | 规则已经在系统内，可直接运行，性能较高 | 需要对规则实时解释，性能较差 |
| 质量属性 | 管道过滤器 | 仓库风格 |
|---|---|---|
| 数据处理方式 | 数据驱动机制，处理流程事先确定，交互性差 | 数据存储在中心仓库，处理流程独立，支持交互式处理 |
| 可扩展性 | 数据与处理紧密关联，调整处理流程需要重新启动 | 数据与处理解耦合，可动态添加和删除处理组件 |
| 性能 | 劣势：需要数据格式转换，性能降低；优势：支持过滤器并发调用，性能提升 | 劣势：数据与处理分离，需要加载数据，性能降低；优势：数据处理组件之间一般无依赖关系，可并发调用，提高性能 |
| 质量属性 | 管道过滤器 | 仓库风格 |
|---|---|---|
| 交互方式 | 顺序结构或有限的循环结构 | 星型结构 |
| 数据结构 | 数据流 | 文件或模型 |
| 控制方法 | 数据流驱动 | 业务功能驱动 |
| 扩展方法 | 接口适配 | 模型适配 |
| 质量属性 | 管道过滤器风格 | 解释器风格 | 隐式调用风格 |
|---|---|---|---|
| 可扩展性 | 因为管道过滤器是把数据处理职能做成过滤器，把数据传递做成管道，此时如果流程不发生变化，是可以通过这种方式实现的，但一旦流程变化，或是扩展功能，需要对过滤器进行修改调整，或是流程在程序层面重建，此时必须修改代码完成任务。 | 因为解释器风格可以通过自定义流程规则及配套流程解释引擎开发，做到用户层面的流程完全定义，而不需要修改代码，所以无论是修改已有的业务流程，还是要扩展不同的角色，创建新角色的流程都非常便利。 | 隐式调用强调的是通过间接方式进行调用，不同模块之间可以通过事件解耦，使得它们可以独立地进行开发和测试。这种解耦方式有助于提高系统的灵活性和可扩展性。同时，通过使用事件，程序可以更加灵活地响应用户的操作和外部的变化。，本题中可把角色执行业务的流程用事件触发。这种做法比管道过滤器强，但弱于完全自定义的解释器。 |
| 灵活性 | 同上 | 同上 | 同上 |
2、架构风格定义
3、常见架构风格对比
三、MVC架构风格介绍
MVC三大模块
控制器：是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
模型：是应用程序中用于处理应用程序数据逻辑的部分，通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。
视图：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但它并不进行任何实际的业务处理。
EJB三种Bean
Session Bean:维护一次临时的会话
Entity Bean：持维护持久稳固的数据
message-dirver Bean：异步接受消息
四、面向服务架构SOA
SOA定义
SOA是一种设计理念，其中包含多个服务，服务与服务之间相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。
ESB特点
- SOA的一种实现方式，ESB在面向服务的架构中起到总线的作用，将各个服务进行连接与整合。
- 描述服务的元数据与服务的注册管理
- 在服务的请求者和提供者之间传递数据，以及对这些数据进行转换的能力。
- 发现、路由、匹配、选择的能力。以支持服务之间的动态调用。高级特性有安全的支持、服务质量保证、可管理性、负载均衡
ESB功能
- 服务位置透明
- 传输协议转换
- 消息格式转换
- 消息路由
- 消息增强
- 安全性
- 监控与管理
五、结构化分析与面向对象分析
1、结构化分析
①、数据流图（功能模型）
基本元素
- 外部实体：指存在于软件系统之外的人员、物或其他软件系统。
- 加工：描述了输入数据到输出数据之间的变换。
- 数据存储：用来存储数据，表示信息的静态存储，可以是文件、数据库。
- 数据流：由一组固定成分的数据组成，表示数据的流向。
分层细化遵循的平衡原则
- 子图与父图之间的平衡：
父图与子图之间的平衡是指任何一张数据流图子图边界上的输入/输出数据流必须与其父图对应加工的输入/输出数据流保持一致。
如果父图中某个加工的一条数据流对应于子图中的几条数据流，而子图中组成这些数据流的数据项全体正好等于父图中的这条数据流，那么他们仍然是平衡的。 - 子图内部：加工的输入和输出需要平衡
数据流图和数据字典在需求分析和设计阶段的作用
| 数据流图 | 数据字典 | |
|---|---|---|
| 分析阶段 | 建立系统的功能模型，从而完成需求分析 | 主要描述数据流图中各个成分的具体含义，以及给出详细的定义和说明 |
| 设计阶段 | 为模块划分于模块之间的接口设计提供依据 | 为系统设计提供详细的数据定义和说明，有助于保证系统的数据一致性和完整性 |
数据流图和系统流程图之间的区别
- 数据流图中的处理可以并行；系统流程图在某个时间节点智能处于一个处理过程。
- 数据流图展现系统的数据流；系统流程图展现系统的控制流
- 数据流图展现全局的处理过程，过程之间遵循不同的计时标准；系统流程图中处理过程遵循一致的计时标准
②、状态转换图（行为模型）
③、E-R图（数据模型）
④、数据字典
2、面向对象分析
①、面向对象设计原则
- 单一职责：
- 开闭原则：
- 里氏替换原则：
- 依赖倒置原则：
- 接口分离原则：
②、UML图
- 类图：静态图，为系统的静态设计视图，展现一组对象、接口、协作和他们之间的关系。
- 对象图：静态图，展现某一时刻一组对象及他们之间的关系，为类图的某一快照。
- 用例图：静态图，展现了一组用例、参与者以及他们之间的关系。用例是参与者完成一系列的操作。关系有：扩展、包含、泛化
- 部署图：静态图，为系统静态部署视图，部署图物理模块的节点分布。
- 构件图：静态图，为系统静态实现视图，展现了一组构件之间的组织和依赖
- 顺序图（序列图）：动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。
- 通信图（协作图）：动态图，强调参加交互对象的组织，强调通信方式。
- 状态图：动态图，主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件，以及因状态转移而伴随的动作。
- 活动图：动态图，用户描述系统的工作流程和并发行为。活动图可以看作状态图的特殊形式，活动图中一个活动结束将立即进入下一个活动。
10.状态图与活动图的区别：状态图侧重描述行为的结果，活动图侧重描述行为的动作。其次活动图可以描述并发行为，状态图不行。
③、实体和类的区别
实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作
④、抽象用例和基础用例区别
基础用例是实实在在与用户需求由对应关系的用例，是从用户需求获取的渠道得到的。而抽象用例是从基础用例中抽取的用例的公共部分，为了避免重复工作，优化结构而提出的用例。
⑤、对象模型、动态模型、功能模型
对象模型：描述系统中对象的静态结构、对象之间的关系、属性和操作，主要用对象图来实现。
动态模型：描述与时间和操作顺序有关的系统特征，主要用状态图实现
功能模型：描述一个计算如何从输入值得到输出值，他不考虑计算次序，主要用数据流图实现
六、设计模式
| 创建型模式 | 定义 | 关键字 |
|---|---|---|
| 抽象工厂模式 | 提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定他们具体的类 | 抽象接口 |
| 工厂模式 | 定义一个创建对象的接口，但是由子类决定需要实例化哪一个类。是的子类实例化推迟 | 子列决定实例化 |
| 构建器模式builder | 将一个复杂类的表示与其构造相分离，使得相同的构件过程能够得出不同的表示 | 类和构造分离 |
| 原型模式prototype | 用原型实例指定创建对象的类型，并通过拷贝这个原型来创建新的对象 | 原型实例，拷贝 |
| 单例模式 | 保证一个类只有一个实例，并提供一个访问它的全局访问点 |
| 结构型模式 | 定义 | 关键字 |
|---|---|---|
| 适配器模式 | 将一个类的接口转换成用户希望得到的另一种接口。它使原本不相容的接口得以协同工作 | 转换，接口兼容 |
| 桥接模式Bride | 将类的抽象部分和它实现部分分离开来，使他们可以独立的变化 | 抽象和实现分离 |
| 组合模式Composite | 将对象组合成树形结构以表示整体-部分的层次结构，使得用户对单个对象和组合对象的使用具有一致性 | 整体-部分，树形结构 |
| 装饰模式Decorator | 动态的给一个对象添加一些额外的职责。他提供了用子类扩展功能的一个灵活替代。比派生一个子类更加灵活 | 附加职责 |
| 外观模式Facade | 定义一个高层接口，为子系统中的一组接口提供一个一致的外观，从而简化该子系统的使用 | 对外统一接口 |
| 享元模式Flyweight | 提供支持大量细粒度对象共享的有效方法 | 细粒度，共享 |
| 代理模式Proxy | 为其他对象提供一种代理以控制这个对象的访问 | 代理控制 |
