信息系统架构
软件信息架构考试知识点整理
1． 什么是架构？有哪几种常见的架构？
架构是体现在它的组件中的一个系统的基本组织、他们彼此的关系、与环境的关系及指导它的设计和发展的原则。
常见的架构有逻辑架构、开发架构、进程架构、物理架构、场景架构
2. 架构、框架、模式的区别？
架构、框架、模式是一种从大到小的关系，也是一种组合关系。从复用角度讲，设计模式是代码级复用、框架是模块级复用、架构是系统级复用、平台是应用级复用。
架构一般针对一个行业或一类应用，是技术和应用完美的结合。
框架比架构更具体，框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。 框架是为了解决特定问题而存在的，其它诸如ORM框架、模板框架、缓存框架，框架不能直接使用，需要二次开发。
设计模式就是告诉你针对特定问题如何组织类、对象和接口之间的关系，是前人总结的经验。
设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。
模式：是在给定的上下文中针对一个常见问题的一个常规解决方法。
平台的概念类似框架，但又结合的架构的考虑，它是更高层面上的“框架”，准确说是一种应用。它是针对企业用户，为解决企业业务需要而形成的产品。
3. 架构的元件有哪些？
4.了解一下流程，特别是迭代、敏捷流程（课本P32~P35）
l 流程：软件行业中使用的各种方法之间的许多差异与遵循的流程有关，而不再是角色、工作产品、活动和执行的任务。（此句摘于书中，不准确的定义）
l 迭代的概念？
在每一次迭代的过程中需要经历每一个阶段，包括需求、架构、开发和测试。
迭代是一个明确的、固定时间的活动序列，它们会产生一个可执行产品的（内部或外部）版本。随着项目的推进，这些版本会提供性能方面的逐步改善。
l 迭代特征：
- 迭代有明确的评估标准。
- 迭代要有一个计划的可论证性能。
- 迭代以一个较小的里程碑结束。
- 在迭代过程中，更新工作产品。
- 在迭代过程中，对系统进行集成和测试。
l 阶段的概念？
阶段是一个专门的活动类型，它代表项目中以一个决策点，主要里程碑或一组可交付物借书的一个很重要时期。
l 阶段和迭代的异同点？
阶段提供了定义良好的业务的里程碑，它确保迭代向前推进并汇集在一个解决方案上而不是不确定地重复。迭代具有（固定周期的）固定时间，而阶段以目标位基础。阶段没有固定时间，因为一个阶段的完成是基于项目的装填评定的。
阶段和就迭代共同为迭代开发流程提供了基础。每个阶段的目标通过执行这个阶段内的一个或多个迭代来达到。每个阶段最终给都有一个主要里程碑和去顶这个阶段的目标是否达成的评估。
l 阶段可以分为：起始阶段、细化阶段、构造阶段、移交阶段。起始和细化阶段也可以归纳为制造过程，构造和移交阶段也可以归纳为生产过程。
l 具体每一个阶段的详细任务请见书本P36上部分。
l 敏捷流程（课本内容太少了），只提炼了敏捷流程的基础原则：
- 注重个人及其交互，胜于过程与工具。
- 注重可用的软件，胜于详尽的文档。
- 注重客户协作，胜于七月谈判。
- 注重效应变化，胜于恪守计划。
² 关于软件架构的4+1视图模型（要和UML结合）
准备知识：
l 视点和视图的概念？
构架的视点是用于构建和利用一个视图的常规说明书。它是一个模式或模本，可以利用它确定一个视图的目标和用户及其创建和分析的技术，从而来开发单独的视图。
4+1视图模型
- 逻辑视图是设计的对象模型
- 过程视图获取设计的并发和同步方面的信息
- 开发视图描述的是在团建开发环境中的软件静态组织
- 物理视图描述了软件与硬件之间的映射，还反应了它在分布式方面的信息。
- 一个架构的描述是通过少许挑选使用的用例或者场景来说明的
² 真正理解三层经典架构和MVC架构（见PPT）
准备知识：
层的概念？
l 下层组件负责对上层组件提供服务。
l 上层组件可以使用下层组件定义的服务，但下层组件对上层组件一无所知。
l 层与层之间通常是不透明的，每一层都具有独立的职责 。
l 不同层的软件构件可以分布在多台机器上，也可以部署在同一台机器上 。
l C/S常被称为传统的两层，B/S称为三层
l 分层模式：传统C/S（无明显分层）、两层、三层、四层、多层
l 基本思想：将逻辑功能相似的类封装到一个组件中。
经典的三层结构：
n 表现层：处理用户和信息系统之间的交互。
n 业务逻辑层：也称为领域层或应用层，是信息系统所有和领域相关的工作。
n 数据访问层：一般指与数据库的交互，主要责任是数据库记录的存取。
MVC架构
- 模型视图控制器架构MVC：Model && View && Control
- 模型：即相关的数据，它是对象的内在属性
- 视图：是模型的外在表现形式，一个模型可以对应一个或者多个视图，视图还具有与外界交互的功能
- 控制器：是模型与视图的联系纽带，控制器提取通过视图传输进来的外部信息转化成相应事件，然后由对应的控制器对模型进行更新； 相应的，模型的更新与修改将通过控制器通知视图，保持视图与模型的一致性
5、了解SOA：
SOA，面向服务的体系结构（service-oriented architecture）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
6、画类图和时序图的方法：
画类图的一般步骤：
（1） 识别并筛选名词概念
（2） 识别类之间的关系（关联：特殊的关联——聚合：描述部分和整体的关系，如果一个部分属于某个整体，那么该部分就无法同时属于其他整体，也无法单独存在，则这种聚合关系叫做组合）：
继承：
类图举例：（图书管理系统）
时序图画法：
餐馆中顾客点菜时序图：
7、边界类、控制类、实体类
边界类：
n 边界类的职责是完成系统与其参与者之间的交互。接收来自用户和外部系统的信息与请求、将信息与请求提交给用户和外部系统
n 边界类包括屏幕窗口、通信接口、打印机接口、传感器、终端以及专用API（应用程序编程接口）等软件对象。
实体类：
实体类是一个软件对象，表示了领域对象的信息，以及具有与它所表示的信息有关的复杂行为
边界类仅负责数据的输入和输出，不应承担和数据处理有关的业务逻辑
边界类通过与实体类的交互，获得有关数据处理的结果
控制类：
控制类代表协调、排序、事务处理以及对其他对象的控制，经常用于封装与某个具体用例有关的控制流
第七章 定义需求
简述：这一章主要介绍了组成定义需求的活动
1、需求和架构之间如何发生关系（关联）？
u 需求影响架构。最明显的关系是需求影响解决方案的架构，因为解决方案的元素是按照其是否能够满足规需求来挑选的。
u 定义良好的需求导致高质量的架构。由于需求驱动架构的定义，因此，一组定义良好的需求比粗劣定义需求更能产生高质量的架构。让架构师参与某些特定的需求分析和需求定义的工作，凭他们的经验，往往会得到质量更高的需求。
u 架构的决定影响需求。在定义架构时，架构师经常必须在不同的需求之间进行取舍，如平衡性能和成本。结果，业务分析师会得到这些反馈，从而对需求进行必要的调整。架构中某些特定因素的选取也会约束可实现的需求。第三方商业系统的选择，会对需求使用的术语、所提供的功能和获得的质量产生约束。
u 架构定义了子系统的需求。当架构被分解为各个部分时，需求和架构之间还有另一种不那么明显的关系。实际上，对架构中某一部分的说明已经构成了对那一部分的需求。
2、一个元素出现什么情况，可以认为对架构的意义重大呢？
① 这个元素与系统的关键功能相关，没有它，你将无法得到可用的系统。
② 这个元素与系统的关键质量相关，例如性能，没有它，你将无法得到可用的系统。
③ 这个元素与解决方案的重要约束相关，例如需要和特定的外部系统集成。
④ 这个元素能影响特定的技术风险。
⑤ 这个元素带来特定的架构挑战。
3、名词解释：
1． 功能性需求：描述了支持用户目标、任务和活动的系统的行为（功能或者服务）。
2． 非功能性需求：包括性能需求、质量属性、对外接口和约束，约束是对再提供解决方案时所拥有的自由度的一个限制；质量是利益相关者关心的系统特性和特点，因而影响系统的满意度。
3． 业务规则：业务规则是定义或约束某一方面的声明。其目的是维护业务结构或控制及影响业务行为。
4、质量和质量属性的区别：
ü 软件质量是软件拥有所要求的综合属性的程度。因此，要建立成功的软件系统，系统必须满足各种显式及隐式的要求。系统为满足显式及隐式的要求而需要具备的要素称为质量。
ü 为了度量一个系统的质量，人们通常会选用系统的某些质量要素进行量化处理，建立质量特征，这些特征称为质量属性。软件质量属性包括功能性、可靠性、可用性、效率、可维护性、可移植性。性能、可扩展性和可维护性都是质量属性的例子。
5、在收集需求时通常会出现的缺陷有哪些？
把要求当做需求
购物车式的思维方式
问卷调查过于技术性
要求过于笼统
要求不可测量
和不适当的人讨论
6、在细化一个用例时，需要说明的信息有哪些？
名称
简要描述
主要参与者
次要参与者
主要事件流
可选事件流
特殊需求
先决条件
后置条件
7、细化非功能性需求场景有哪些组成部分？
触发、触发源、触发对象、环境、响应、响应度量、
8、业务规则分类：
（1） 为管理业务行为提供条件和规则
（2） 为判断一个行动是否成功完成提供标准的规则
（3） 规定一个行为成功或失败后可以执行什么或不能执行什么的规则
（4） 指定如何响应对企业有影响的外部事件的规则
（5） 管理各种业务实体之间的关系的规则
9、本章重点：定义需求这项活动的任务：
（1） 收集利益相关者的要求（目的是收集各种利益相关者对系统的要求）（注意要求和需求的区别，要求是对利益相关者想要系统中有什么的一个表述）
（2） 获取常用词汇
（3） 定义系统上下文（目的是确保理解所要开发系统的边界范围，同时还是别于系统交互的用户和外部系统）
（4） 概述功能性需求
（5） 概述非功能性需求
（6） 定义需求优先级（目的是排定需求的优先级以根据需求的优先级来安排迭代）
（7） 详述功能性需求
（8） 详述非功能型需求
（9） 更新软件架构文档
（10） 和利益相关者复审需求
10、每个事件流的详细描述中应包括哪些信息？
（1） 用例何时和如何发起
（2） 用例何时与参与者交互并交互了哪些信息
（3） 何时应用了业务规则
（4） 用例何时结束和如何结束
11、需求定义产生的产品：
术语表、利益相关者要求、系统上下文、功能性需求、非功能性需求和排定优先级的需求列表
第八章：创建逻辑架构
1、逻辑架构和物理架构的比较：
逻辑架构代表从需求通往解决方案的第一步——第一次主要从独立于技术的角度考虑架构。另一方面，物理架构则更为具体——需考虑技术。
2、什么是属性驱动设计：
通过使用满足质量属性场景的架构策略和模式，质量属性用于驱动架构和设计的演化并用于接下来的各级分解中。
3、什么是四门子的4重视图方法：
从整体分析影响架构的因素开始，反复地应用4种视图（概念、运行、模块、代码架构）来确认架构的关键挑战和解决这些挑战的策略。
4、什么是统一过程：
这个方法由对架构有影响的用例、非功能性需求和风险来驱动。在利用解决方案的关键架构元素实现需求之前，每次迭代都考虑这些关键元素。
5、策略：策略是决定如何满足一个功能性需求或如何达到一个质量属性的决策。
6、逻辑架构的价值：
（1）一种帮助尽可能快的把需求变为可用代码实现的物理架构的简单有效方法。
（2）作为战略性资源，当需要更新系统时，逻辑架构可以提供一个系统极好的抽象。
7、可追溯性：可追溯性是用于把一个工作产品中的元素连接到相同或不同工作产品的元素的一种机制。
8、创建逻辑架构活动的任务有哪些？
（1）调查架构资源（2）定义架构概览（3）编写架构决策文档（4）概述功能性元素
（5）概述部署元素（6）检验架构（7）构建架构概念证明（8）细化功能性元素
（9）细化部署元素（10）确认架构（11）更新软件架构文档（12）和利益相关人复审架构
组件的确认是建立在对业务实体模型、功能需求、非功能需求、业务规则、现有IT环境和架构决策等工作产品的分析之上的。
9、组件质量的度量
软件的内聚性和耦合性质量作为降低软件维护和修改的成本的一个方法。
内聚性是组件的职责之间的相关程度的一个度量。
耦合与内聚有关，它表示组件之间关联的强度。
子系统与组件
子系统是一组相关的组件。在业务系统中，组件通常被组合在一起，因为它们有共同支持某一业务领域。
组件是封装自身的内容并在环境中可替换的一个系统模块化部分。一个组件根据提供和要求的接口来定义自己的行为。
第九章 创建物理架构
与物理架构相关的任务可以开始于起始阶段的一个迭代。在细化阶段，当你专心于架构系统的主要元素时，你会把这些任务作为重点，当你进入构造阶段的迭代是，物理架构的任务逐渐减少，焦点转向了根据目前定义的架构完成系统的实现。
影响物理架构的主要因素之一是为处理非功能性需求（包括质量和约束）
2、软件体系结构的“4+1视图”是指什么？是否每个软件系统这5个视图都需要？
答：从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。并非每个系统都必须把5个视图都画出来，而是各有侧重。
1、典型的软件构架样式（architectural styles）有哪些?
答：
o 以数据为中心的构架
数据集成——一个集中式的数据集与多个客户端进行通信
o 数据流构架
成批数据流；管道和过滤器
o 虚拟组织构架
目标：可移植性
模拟对象：模拟硬件不具备的功能或软件环境
实例：java虚拟机(java的平台独立性)
o 调用——返回构架
目标：可更改性和可扩展性
主——子程序（传统）；面向对象（类派生）；层次样式
o 独立组件构架
由独立进程或对象组成，通过消息进行通信
例：C/S模式
o 异质构架
多种构架样式的综合
局部异质/层次异质/并行异质（同时符合几种样式）
3、简单区别软件构架分析方法SAAM与ATAM。
答：
- 涉及的质量属性：ATAM不面向任何具体的质量属性，但据其历史，它更侧重于可修改性，安全性，可靠性和性能；SAAM只要是可修改性和功能
- 分析的对象：ATAM架构方法或样式，阐述过程、数据流、使用、物理或模块试图的架构文档；SAAM架构文档，特别是阐述逻辑或模块视图的部分
- 试用阶段：ATAM在架构设计方法已经选定之后；SAAM在架构已经将功能分配到各个模块中以后
- 采用方法：利用效用树和对场景的集体讨论来搞清楚质量属性需求。通过对架构方法的分析确定出敏感点、权衡点和风险；SAAM利用对场景的集体讨论搞清楚质量属性需求。通过来验证功能或对更改成本做出估计
- 资源需求：一般用3的时间，另外还有预先的准备时间和之后的总结时间。参评人员有客户、架构师、风险承担者和4人评估小组；SAAM一般用2天时间，另外还有之后的总结时间，参评人员有客户、架构师、风险承担者和3人评估小组
4.ATAM的一个方面是架构评价，它遵循以下步骤：
① 介绍ATAM。
② 介绍业务驱动因素。
③ 介绍架构。
④ 确定架构方法。
⑤ 生成质量属性效用树。
⑥ 分析架构方法。
⑦ 进行头脑风暴并定义场景的优先级。
⑧ 分析架构场景。这个步骤等同于第6步，但是不考虑任何新场景。
⑨ 介绍结论
5、理解软件体系结构（Software architecture）, 框架（Framework）和设计模式（Design patterns） 3个概念
理解软件体系结构：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。
框架：框架是一种软件重用技术，它是一个应用软件系统的部分或整体的可重用设计。应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。
框架具体表现为一组抽象类以及其实例（对象）之间的相互作用方式。框架是可被应用开发者定制的应用骨架。框架是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。
设计模式：设计模式 (英语 design pattern)是对面向对象设计中反复出现的问题的解决方案。这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。这个术语的含义目前还存有争议。算法不是设计模式，因为算法致力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。设计模式还为软件重构提供了目标。
6、了解C/S与B/S混合软件架构及其优缺点
o C/S与B/S混合软件体系结构的优点是外部用户不直接访问数据库服务器，能保证企业数据库的相对安全。企业内部用户的交互性较强，数据查询和修改的响应速度较快。
o C/S与B/S混合软件体系结构的缺点是企业外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强。
7、理解面向对象设计的“开—闭”原则
答：“开—闭”原则是指软件实体应当对扩展性开放，对修改关闭。即软件实体应该在不修改的前提下扩展，这个原则实际上为软件设计指明了目标。我们知道软件设计应当充分考虑软件的可维护性，即需求发生变化的时候软件结构能够灵活地适应这种变化。就评价软件的可维护性而言，“开—闭”原则提供了一个依据。实际上，设计模式的应用就是使软件的结构在某种程度上满足“开—闭”原则。
8. 需要确定构架驱动因素。
构架驱动因素：功能，质量，商业需求的某个集合“塑造”了架构，我们把这些塑造架构的需求称为架构的驱动因素。
9、如何确定架构驱动因素？
1） 需要识别优先级最高的业务目标，这样的业务目标应该很少，用质量属性场景或用例来表述这些企业目标。
2） 在需求中，选择对构架影响最大的需求，这些就是构架的驱动因素，应该少于10个。
10、ADD(Attributes Driven Design) ,把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计，以满足质量需求和功能需求。
★ADD（属性驱动设计）
ADD使用大致过程：ADD是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上，它是一个递归的分解过程，其中每个阶段都选择战术和构架模式来满足一组质量属性场景，然后对功能进行分配，以实例化由该模式所提供的模块类型，ADD发生在需求分析之后。
ADD结果：结果是构架的模块分解为视图和其他视图的最初的几个层次，这是设计过程中架构的第一个连接点（articulation）因此肯定是粗粒度的。
ADD步骤：
（1） 选择要分解的模块。
（2） 根据这些步骤对模块进行求精。
（3） 对需要进一步分解的每个模块重复上述步骤。
11、构架模式、参考模型和参考构架的定义及其关系
构架模式是对元素和关系类型以及一组对其使用方式的限制的描述。可以吧构架模式看作是对构架的一组制约条件---即对个元素类型和交互模式的限制条件，而这些制约条件就确定了一组或一系列能满足它们的构架。模式最有用的一个方面就是它们展示了已知的质量属性。选择构架模式通常是设计师做出的第一个主要的涉及决策。
参考模型是一种考虑数据流的功能划分。
参考构架是映射到软件元素(它们相互协作，共同实现在参考模型中定义的功能)以及元素之间数据流上的参考模型。
12、什么是结构和视图？
视图是构架元素内聚集的表示，由系统涉众编写和阅读。它由一个元素集的表示和元素之间的关系组成。(书面语言形式)
结构是元素本身的集合，它们存在于软件或硬件中。(未表示的内在结构)
13、软件架构、架构模式、参考模型、参考架构之间的关系：
14、软件架构的重要性
(1)、架构是涉众进行交流的手段。
(2)、架构是早期设计决策的体现。
(3)、架构是可传递、可重用的模型。
五、软件构架重构
构架重构是一种解释、交互和迭代的过程，涉及许多活动；它不是自动进行的。它需要反向工程专家和设计师具备相关技能并投入精力，这在很大程度上是因为没有在源代码中清楚地表示构架构件。
软件构架重构由以下活动组成，这些活动以迭代的方式进行：
（1） 信息提取。
（2） 数据库构造。
（3） 视图融合。
（4） 重构。
