1. 各种性能指标的定义及如何到达各种性能指标的方法
2. 软件性能指标主要有哪几种 三种
- 吞吐量
Throughput- 定义：单位时间内成功地传送数据的数量
- 实现：Average 平均，Peak 峰值
- 响应时间
Response Time- 定义：应用程序在处理请求时显示延迟的时间
- 实现：Guaranteed time 最大响应时间 Average time 平均响应时间
- 最后期限
Deadlines- 定义：有些事情必须在指定的时间之前完成
- 实现：最后期限通常与IT系统中的批处理作业相关。
3. 响应时间的度量 两种
- 最大响应时间
- 平均响应时间
4. 常用的中间件有那几种类型 四种
- 业务流程协调器
Business Process Orchestrators - 消息代理
Message Brokers - 应用服务器
Application Servers - 传输
Transport
5. 应用的集成策略
- 数据：公开应用程序数据以供其他组件访问
- API：提供通过抽象接口读取/写入应用程序数据的服务
6. 有那些常见架构风格
7. 各种架构风格的组件和连接器是什么
- 管道和过滤器
Pipe and Filter- 组件：过滤器，对其输入流应用本地转换，并经常以增量方式进行计算，以便在使用所有输入之前开始输出。
- 连接器：管道，用作流的管道，将一个过滤器的输出传输到另一个过滤器的输入。
- 面向对象
Object-Oriented- 组件：对象
- 连接器：是函数和过程的调用（方法）。
- 隐式调用
Implicit Invocation- 组件可以宣布（或广播）一个或多个事件。系统中的其他组件可以通过将过程与事件相关联来注册对事件的兴趣。
- 宣布事件后，广播系统（连接器）本身会调用已为该事件注册的所有过程。
- 客户 - 服务器
client-Server Style- 组件：
- 服务器：提供特定服务（如打印，数据管理等）的独立组件。
- 客户端：调用服务器提供的服务的组件。
- 连接器：允许客户端访问远程服务器的网络。
- 组件：
- 分层
Layered Style- 组件：通常是程序的集合。
- 连接器：通常是在可见性受限的情况下进行的过程调用。
- 仓库
Repository Style- 组件：代表系统正确状态的中央数据结构。在中央数据结构上运行的独立组件的集合。
- 连接器：通常是过程调用或直接内存访问。
- 解释程序
Interpreter Style- 组件：
- 用于执行引擎的状态机
- 三个内存 执行引擎的当前状态，正在解释的程序，正在解释程序的当前状态
- 连接器：程序调用，直接内存访问。
- 组件：
- 过程控制风格
Process-Control Style- 组件：过程（包括用于处理某些流程变量的机制）。决定如何操作过程变量的控制算法。
- 连接器：是以下数据流的关系
- 过程变量
- 设定点
- 传感器
8. 架构师需要的核心技能是什么
- 团队交流
Liaison with stakeholders - 技术知识
Technology knowledge - 软件工程学
Software engineering - 风险管理
Risk managements
9. 什么是软件架构
- 结构
- 元素
- 关系
- 接口
软件架构是软件设计过程的一部分。
- 所有的架构都是软件设计，但不是所有的设计都是软件架构
- 设计过程的一部分
体系结构是一个系统的基本组织，体现在它的组件、它们彼此之间的关系和环境中，以及控制它的设计和演进的原则中。
程序或计算系统的软件架构是系统的一个或多个结构，它包括软件元素、这些元素的外部可见属性,以及它们之间的关系。
软件体系结构超越计算的算法和数据结构；
设计和指定总体系统结构是一种新的问题。结构性问题包括：
- 总体组织和全球控制结构
- 通信，同步和数据访问协议
- 将功能分配给设计元素
- 物流
- 设计元素的组成
- 扩展和性能
以及在设计方案中进行选择
10. 架构设计分几个层次
- 架构设计
Architectural design - 详细设计
Detailed design - 实施 可执行设计
Implementation
11. 软件架构主要关注哪些问题
一旦系统建立后就很难或是不可能改变的问题
issues that will be difficult/impossible to change once the system is built
- 质量属性
Quality attributes - 非功能性需求
Non-functional requirements
12. 什么是架构风格
架构风格根据结构组织的模式定义了一系列系统。它确定了可以在该样式的实例中使用的组件和连接器的词汇和关于如何组合它们的一组约束。
13. 什么是架构视图
表示复杂的设计工件的软件体系结构
14. 软件系统中的复杂性有哪些种类
- 架构设计
- 技术选择
- 应用和业务集成
15. 非功能需求 NFRs(Non-functional requirements) 包括哪些 三种
- 技术约束
Technical constraints - 业务约束
Business constraints - 质量属性
Quality attributes
16. 软件架构过程 三个迭代步骤
- 确定架构需求：架构上重要的需求（结构用例）
基本的质量和系统的非功能性需求 - 架构设计：迭代的设计步骤
风险识别是一个重要的输出设计 - 结构验证：验证阶段
验证阶段的目的是增加信心的设计团队的架构是适合的目的
17. 软件质量属性主要包括哪些 五种
- 可靠性
Reliability - 可用性
Availability - 可移植性
Portability - 可伸缩性
Scalability - 性能
Performance
18. 软件可用性取决于 三种时间
- 故障检测时间
Time to detect failure - 纠正失败时间
Time to correct failure - 重新启动应用程序时间
Time to restart application
19. 伸缩性涉及那些方面 四种
- 请求负载
Request load - 链接
Connections - 数据大小
Data size - 部署
Deployments
20. 吞吐率指标
- 每秒事务数
- 每分钟的信息
- 每秒的信息
msp - 最大可持续吞吐量
MST
21. 安全性质量指标主要有哪几种 五种
- 身份验证
Authentication - 授权
Authorization - 加密
Encryption - 完整性
Integrity - 不可否认性
Non-repudiation
22. 实现高可用性的策略 三种
- 消除单点故障
- 复制和故障转移
- 自动监测和重新启动
23. 信息隐藏原理
- 信息隐藏（封装）主要是为了提高软件的可重用性和可维护性。
- 涉及：信息嵌入算法和信息提取算法
- 信息隐藏原理是指模块被赋予“秘密”的设计原则。
- 一个模块的秘密通常是一个设计决策。
- 我们经常隐藏，例如
- 数据表示
- 算法的选择
- 外部实体(如数据库、硬件)的接口细节/访问机制
- 目标：客户“看不见”的特定设计选择
- 在编程语言级别可能支持信息隐藏，也可能不支持。
Design principle by which a module is assigned a "secret".
A module’s secret is usually -- A design decision.
24. 什么是关注点，关注点的类型，关注点分离
SoC Separation of Concerns 是将软件分解为不同功能的过程，这些功能封装了可被其他类使用的独特行为和数据。 通常，关注点表示类的功能或行为。
在软件系统中，有两种主要的关注点类型：
- 核心关注点
Core concern：它代表了系统基本的功能，并且是编写软件的主要原因。 - 横切关注点
Cross-cutting concern：这是应用程序中依赖并影响其他关注点的一个方面。
25. 什么是职责驱动的设计
通常从以下 隐喻 的角度完成详细的对象设计：对象有责任，对象协作
责任是一种抽象。
- 坚持不懈的责任 -- 大粒度的责任。
- 负责营业税的计算 -- 更细粒度的责任。
26. 架构元素的通信包括哪些
数据传递机制
函数调用、远程方法调用、异步消息控制流
组件之间的消息流来实现需要的功能、顺序、并发/并行、同步同步通信
Synchronous communications异步通信
Asynchronous communications灵活通信
Flexible communications
27. 4+1视图
- 逻辑视图：系统的对象模型
- 过程视图：系统的行为模型
- 实现视图：软件组件、库、包等
- 展开视图：软件如何映射到硬件
-
用例视图：系统场景，将所有视图在一起（允许跟踪其他视图以进行验证），方案可以涵盖非功能性需求
28. 什么是抽象，封装
- 封装
Encapsulation
阻止你知道，封装帮助控制偶然复杂性，尽可能地隐藏实现细节。封装意味着我们永远不希望客户端开发人员知道一个调用的操作是如何实现的。 - 抽象
Abstraction- 忽视一个问题中与当前目的无关的那些方面的原则，以便只集中注意与当前目的有关的那些方面。
- 允许忽略
29. GRASP 模式的具体内容，各种模式的定义，解决的什么问题
-
创造者
Creator
问题：应该由谁来创建某类的实例
解决方案：如果 B 聚合了A 对象，则将创建A 类实例的责任分配给B 类。- B 记录 A 对象的实例
- B 包含 A 的对象
- B 紧密地使用 A 的对象
- B 有初始化数据，创建时将传递给A。
信息专家
Information Expert
问题：给对象分配职责的基本原则是什么？
解决方案：把职责分配给具有完成职责所需信息的类。-
控制器
Controller
问题：在UI 层之上首先接收和协调系统操作的第一个对象是什么？
方案：控制器职责分配给以下之一：- 代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些是“外观控制器”的所有变体
- 代表用例场景
- 对于同一用例场景的所有系统事件使用相同的控制器。
低耦合
Low Coupling
问题：怎样降低依赖性，减少变化带来的影响，提高重用性
方案：头脑风暴:-给出产生耦合的代码的例子。高内聚
High Cohesion
问题：怎样保持对象是有重点、可理解的、可管理的，并且能够保持低耦合
方案：利用高内聚评估候选方案多态性
Polymorphism
问题：如何处理基于类型的选择？如何创建可插拔的软件构件？
解决方案：当相关选择或行为随类型有所不同时，使用多态操作为变化的行为类型分配职责。纯虚构
Pure Fabrication
问题：当你并不想违背高内聚和低耦合或其他目标，但是信息专家所提供的方案又不合适时，哪些对象应该承担这一职责？
方案：捏造一个新对象来承担责任间接性
Indirection
问题：如何分配责任以避免直接耦合？如何使对象解耦？
方案：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性。变化预防
Protected Variations
问题：如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其他元素产生不良影响
方案：识别预计变化或不稳定支出，分配职责用以在这些变化之外创建稳定接口。
30. OO 设计的五个基本原则 S.O.L.I.D 及课件中讲述的其它软件原理
- 单一职责原则 SPR
Single Responsibility Principle
每一个目标都应该只有一个改变的理由和单一的责任重点。通过依附这个原则，你避免了庞大的类的设计问题 - 开闭原则 OCP
Open-Closed Principle
类应该对扩展开放，对修改关闭，那样就能够添加新功能并扩展类而不用改变其内部的行为。该原则致力于避免破坏现有的类以及依赖于该类的其他类，这将在整个应用程序中造成错误和错误的连锁效应。 - Liskov 替换原则 LSP
Liskov Substitution Principle
Liskov 替换原则要求，能够使用任何派生类代替父类，并使其以相同的方式运行而无需修改。这个原则与开闭原则一致，它保证了派生类不影响父类的行为，或者说，派生类必须能够被它们的基类替代。 - 接口分离原则 ISP
Interface Segregation Principle
ISP 就是将抽象的方法分为几组责任，并为这些组分配接口，以防止客户端需要实现一个大接口，这个接口容纳了许多他们不使用的方法。 这样做的目的是使使用相同接口的类仅需要实现一组特定的方法，
而不是方法的整体接口。 - 依赖倒置原则 DIP
Dependency Inversion Principle
DIP 就是将您的类与具体实现隔离开来，并使它们依赖于抽象类或接口。它促进了对接口而不是实现的编码方式，通过确保对实现的低耦合，从而增加了系统内的灵活性。 依赖注入Denpendency Injection和控制反转Inversion of Control
31.组合，继承，针对接口编程，黑盒，白盒、重用 JavaReviewP42、P44、P65
组合 Combination
- 组成可以是：
- 引用
- 价值
- 优点：
- 包含类仅通过它们的接口访问包含的对象
- “黑匣子”重用，因为看不见包含对象的内部细节
- 良好的封装
- 更少的实现依赖关系
- 每个类仅专注于一项任务
- 可以在运行时通过对象获取对相同类型其他对象的引用来动态定义组合
- 缺点：
- 结果系统倾向于具有更多对象
- 必须谨慎定义接口，以便使用许多不同的对象作为组合块
继承 Inheritance
- 通过扩展现有对象的实现来获得新功能的重用方法；概化类(超类)显式地捕获公共属性和方法；专门化类(子类)使用附加属性和方法扩展实现
- 优点：
- 由于新实现大部分都是继承的，因此很容易实现
- 易于修改或扩展可重复使用的实现
- 缺点：
- 破坏了封装，因为它向其超类的实现细节公开了一个子类
- “白盒”复用 ，因为超类的内部详细信息通常对子类可见
- 如果超类的实现发生更改，则必须更改子类
- 从超类继承的实现在运行时无法更改
（优先选择组合而不是继承）
针对接口编程 面向接口编程
- 接口是一个对象知道它可以在另一个对象上调用的一组方法；一个对象可以有很多接口
(本质上，接口是对象实现的所有方法的子集); - 优点：
- 客户不知道他们正在使用的对象的特定类别
- 一个对象可以很容易地被另一个对象替换
- 不需要将对象连接硬连线到特定类别的对象，从而提高了灵活性
- 松散耦合
- 增加了可能性 重用
- 由于包含的对象可以是实现特定接口的任何类，因此增加了组合的机会
- 缺点：
- 设计复杂性适度增加
白盒复用 "White-box" reuse
-
源代码可见，可修改和扩展
- 复制已有代码为正在开发的系统，进行修改
- 可定制化程度高
- 对其修改增加了软件的复杂度，且需要对其内部充分的了解
“白盒”重用，超类的内部细节对子类通常是可见的
黑盒复用 "Black-box" reuse
-
源代码不可见，不能修改
- 只能通过API 接口来使用，无法修改代码
- 简单，清晰
- 适应性差些
黑盒重用：包含对象的内部细节不可见
32.企业应用架构有那三层，各层主要做什么。在各层有那些主要的模式，各层的各种模式的定义和结构内容（展现层，领域层，数据源层）
- 三层架构
- 表现层实现用户界面
- 领域层实现领域逻辑
- 数据源层存取数据
- 三层的关系
- 领域层是核心
- 表现层是系统对外提供服务的外部接口
- 数据源层是系统使用外部服务的接口
- 表现层
Presentation
提供服务、显示信息（如在WINDOWS 或HTML 页面中，处理用户请求，HTTP 请求，命令行调用，批处理API） 表现逻辑处理用户与软件间的交互。主要职责是：- 向用户显示信息
- 把从用户那里获得的信息解释成领域层或数据源层上的各种动作。
- 领域层
Domain
领域逻辑，系统中真正的核心。也称为业务逻辑，它就是应用程序必须做的所有领域相关工作：包括根据输入数据或者已有数据进行计算，对从表现层输入的数据进行验证，以及根据从表现层接收的命令来确定应该调试哪些数据源逻辑。 领域逻辑（业务逻辑），它就是应用必须做的所有领域相关的工作：- 根据输入数据或已有数据进行计算
- 对从表现层输入的数据进行验证
- 根据从表现层接收的命令来确定应该调度哪些数据源逻辑。
- 数据源层
Data Source
与数据库、系统消息系统、事务管理器及其他软件包通信。最主要的数据源逻辑就是数据库，主要责任是存储持久数据。数据源逻辑主要关注与其他系统的交互，这些系统将代表应邀完成相关的任务。主要的数据源逻辑就是数据库，它的主要职责是存储持久数据。
33.MVC 模式
模型 Model：维护应用程序的状态和数据的XML 文档
- “模型”包含数据
- 具有访问和更新其内容的方法。
- 通常，它实现一个接口来定义允许的模型交互。
- 实现一个接口，可以无需进行编程更改即可退出和替换模型。
视图 View：XML 文档的呈现
- 视图提供了模型的可视化表示。
- 一次可以有多个视图显示模型。
- 更新模型时，将通知所有视图并为其提供更新的机会。
控制器 Controller：显示给用户以操作应用程序的用户界面
- 用户与控制器进行交互。
- 它解释鼠标的移动，点击按键等
- 将活动传达给模型，例如删除行，插入行等
- 它的模型交互间接导致视图更新
