软件信息架构考试知识点贯通1 什么是架构？有哪几种常见的架构？架构是体现在它的组件中的一个系统的基本组织、他们彼此的关系、与环境的关系及指导它的设计和发展的原则。常见的架构有逻辑架构、开发架构、进程架构、物理架构、场景架构2. 架构、框架、模式的区别？架构、框架、模式是一种从大到小的关系，也是一种组合关系。从复用角度讲，设计模式是代码级复用、框架是模块级复用、架构是系统级复用、平台是应用级复用。架构一般针对一个行业或一类应用，是技术和应用完美的结合。框架比架构更具体，框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。框架是为了解决特定问题而存在的，其它诸如ORM框架、模板框架、缓存框架，框架不能直接使用，需要二次开发。设计模式就是告诉你针对特定问题如何组织类、对象和接口之间的关系，是前人总结的经验。设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。模式：是在给定的上下文中针对一个常见问题的一个常规解决方法。平台的概念类似框架，但又结合的架构的考虑，它是更高层面上的“框架”，准确说是一种应用。它是针对企业用户，为解决企业业务需要而形成的产品。3. 架构的元件有哪些？4.了解一下流程，特别是迭代、敏捷流程（课本P32P35）l 流程：软件行业中使用的各种方法之间的许多差异与遵循的流程有关，而不再是角色、工作产品、活动和执行的任务。（此句摘于书中，不准确的定义）l 迭代的概念？在每一次迭代的过程中需要经历每一个阶段，包括需求、架构、开发和测试。迭代是一个明确的、固定时间的活动序列，它们会产生一个可执行产品的（内部或外部）版本。随着项目的推进，这些版本会提供性能方面的逐步改善。l 迭代特征：1. 迭代有明确的评估标准。2. 迭代要有一个计划的可论证性能。3. 迭代以一个较小的里程碑结束。4. 在迭代过程中，更新工作产品。5. 在迭代过程中，对系统进行集成和测试。l 阶段的概念？阶段是一个专门的活动类型，它代表项目中以一个决策点，主要里程碑或一组可交付物借书的一个很重要时期。l 阶段和迭代的异同点？阶段提供了定义良好的业务的里程碑，它确保迭代向前推进并汇集在一个解决方案上而不是不确定地重复。迭代具有（固定周期的）固定时间，而阶段以目标位基础。阶段没有固定时间，因为一个阶段的完成是基于项目的装填评定的。阶段和就迭代共同为迭代开发流程提供了基础。每个阶段的目标通过执行这个阶段内的一个或多个迭代来达到。每个阶段最终给都有一个主要里程碑和去顶这个阶段的目标是否达成的评估。l 阶段可以分为：起始阶段、细化阶段、构造阶段、移交阶段。起始和细化阶段也可以归纳为制造过程，构造和移交阶段也可以归纳为生产过程。l 具体每一个阶段的详细任务请见书本P36上部分。l 敏捷流程（课本内容太少了），只提炼了敏捷流程的基础原则：6. 注重个人及其交互，胜于过程与工具。7. 注重可用的软件，胜于详尽的文档。8. 注重客户协作，胜于七月谈判。9. 注重效应变化，胜于恪守计划。 关于软件架构的4+1视图模型（要和UML结合）准备知识：l 视点和视图的概念？构架的视点是用于构建和利用一个视图的常规说明书。它是一个模式或模本，可以利用它确定一个视图的目标和用户及其创建和分析的技术，从而来开发单独的视图。4+1视图模型1. 逻辑视图是设计的对象模型2. 过程视图获取设计的并发和同步方面的信息3. 开发视图描述的是在团建开发环境中的软件静态组织4. 物理视图描述了软件与硬件之间的映射，还反应了它在分布式方面的信息。5. 一个架构的描述是通过少许挑选使用的用例或者场景来说明的 真正理解三层经典架构和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（应用程序编程接口）等软件对象。实体类：实体类是一个软件对象，表示了领域对象的信息，以及具有与它所表示的信息有关的复杂行为l 边界类仅负责数据的输入和输出，不应承担和数据处理有关的业务逻辑l 边界类通过与实体类的交互，获得有关数据处理的结果控制类：控制类代表协调、排序、事务处理以及对其他对象的控制，经常用于封装与某个具体用例有关的控制流第七章 定义需求简述：这一章主要介绍了组成定义需求的活动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重视图方法：从整体分析影响架构的因素开始，反复地应用