目录
分类（传统分类）
数据流风格:批处理序列，管道-过滤器。
数据处理，流程一步一步走。
调用/返回风格:主程序/子程序，面向对象，层次结构。
独立构件风格:进程通信，事件驱动系统（隐式调用）
虚拟机风格:解释器，基于规则的系统。强调自定义。
仓库风格:数据库系统，超文本系统，黑板系统
分布式系统开发分为5个逻辑计算层：
服务类别和作用进行介绍:
服务类型:SOA技术参考架构主要描述SOA基础技术平台与辅助工具，同时描述这两部分与其他外围相关元素之间的关系。SOA技术参考架构将服务分为6类，具体描述如下：
1. 连接服务
连接服务又称连通服务，是面向服务架构的骨干，在完成服务的接入，服务间的通信和交互基础上，还提供安全性、可靠性、高性能的服务能力保障。连接服务的一个典型实现就是企业服务总线(Enterprise Service Bus，ESB)。
2. 协作服务
协作服务通常由通信代理和Web服务代理两部分组成。通信代理与连通服务中的通信代理实现内部有效的数据通信，Web服务代理与外部的公共注册中心交互，注册本平台对外开放的Web服务以及查找所需要访问的外部Web服务。协作服务既可以实现组织之间(如供应链的合作伙伴之间)的交互通信，也可以实现组织内部(如跨地域的分支机构之间，并有防火墙进行保护的情况)之间的交互通信。
3. 业务服务
业务服务指为新建服务提供的特定运行支持环境。新建服务包括单个服务以及合成服务，不包括流程化的服务。合成服务一般由应用编码实现，它可以调用其他的服务(包括：单个服务、合成服务和流程化的服务)。业务服务与连通服务相联接，其中的新建服务与其他服务的通信和交互通过连通服务来实现。业务服务的运行信息由运行管理服务保存，业务服务也接受并执行运行管理服务的管理和控制命令。
4. 业务流程服务
流程服务是业务流程的运行环境，提供流程驱动、服务调用、事务管理等功能。流程服务是为业务流程的运行提供的一组标准服务。业务流程是一组服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用。业务流程可以由不同粒度的服务组成，其本身也可视为服务。
5. 交互服务
交互服务实现人与服务之间的交互功能。人可以是服务的消费者，也可以是服务的提供者。人不能直接消费服务，也不能直接提供服务，需要通过相应的程序实现代理操作(即人通过操作程序实现与服务的交互)。交互服务就是需要提供一组完整的功能，以实现人与服务的交互，并能够方便地进行交互。人员需要请求服务时，向连通服务发送消息请求，由连通服务查找服务，并将请求消息传递给服务提供者。
6. 信息服务
信息服务特指为上层应用系统、同层的其他服务等提供数据访问及资源访问服务。其目标是使应用系统能够统一、透明、高效地访问和操纵位于网络环境中的各种分布、异构的数据资源，为实现全局数据访问、加快应用开发、增强网络应用和方便系统管理提供支持。
三、考生需要详细描述所参与的项目是如何以面向服务的架构为指导思想进行实施的，包括如何发现服务、如何对服务进行分类等。可能存在的问题包括如何进行服务规约，包括候选服务的分类与选择，服务编排，服务库的设计等；如何实现服务，包括将服务的实现分配到相应的服务构件中，并决定服务的实现方式。
一、简要叙述所参与管理和开发的软件项目，需要明确指出在其中承担的主要任务和开展的主要工作。
二、应结合自己所熟悉的领域，定义领域范围，确定领域应用需要满足的用户需求; 定义领域特定的元素、领域字典和领域术语；定义领域特定的设计和实现需求约束；在此基础上，定义领域模型，产生该领域的参考架构，并说明构件的语法和语义；最后，产生、搜集可重用的产品单元，为DSSA增加构件，为问题域实现新应用提供支持。这个DSSA的建立过程是并发、递归和反复进行的。
所给出的DSSA应该具备以下4个方面的特征：
(1) 一个严格定义的问题域和/或解决域；
(2) 具有普遍性，使其可以用于领域中某个特定应用的开发；
(3) 对整个领域能有合适程度的抽象；
(4) 具备该领域固定的、典型的在开发过程中的可重用元素。
三、需要结合项目实际，指出在架构设计时使用DSSA的情况，包括领域分析、领域设计和领域实现等活动是如何具体实施的，要给出实际的效果并进行分析。
一、应结合自己参与的信息系统项目，说明在其中所承担的工作。
二、需要较为详细地说明目前各种常见的信息系统建模方法的核心思想，并对每种方法所创建的模型进行简要描述。
(1) 结构化建模方法。
结构化建模方法是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图(DFD)。
(2) 信息工程建模方法(或数据库建模方法)。
信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图(ERD)。
(3) 面向对象建模方法。
面向对象建模方法将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML(统一建模语言)。 UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统。
三、论文中需要结合项目实际工作，详细论述在项目中是如何使用所选定的信息系统建模方法创建系统的逻辑模型和物理模型，并具体说明这些模型对项目开发所产生的影响。
一、论文中要具体介绍项目的总体需求(特别是可靠性需求)、采用的技术等内容和承担的实际工作。
二、影响软件可靠性的主要因素有：运行环境(软件可靠性的定义是相对于运行环境的)：软件规模；软件内部结构(内部结构越复杂，包含的缺陷数就可能越多)；软件的开发方法和开发环境；软件的可靠性投入等。
三、可靠性设计是在常规的软件设计中，应用各种方法和技术使程序设计在兼顾用户功能和性能需求的同时，全面满足软件的可靠性要求。软件可靠性设计技术就是以提高和保障软件的可靠性为目的，在软件设计阶段运用的一种特殊的设计技术。
主要的软件可靠性设计技术包括：
(1) 容错设计技术。对于软件失效后果特别严重的场合，例如宇航器控制系统、空中交通控制和核反应堆控制系统等，可采用容错设计方法。常用的软件容错技术主要有恢复块设计、N版本程序设计和冗余设计。恢复块设计就是选择一组操作作为容错设计单元，从而把普通的程序块变为恢复块。一个恢复块中包含有若干功能相同、设计差异的程序块，每一时刻有一个程序块处于运行状态，一旦某程序块出现故障，则用备份程序块予以替换。N版本程序设计的核心是通过设计出多个模块或不同版本，对于相同初始条件和相同输入的操作结果进行多数表决(防止因其中某一软件模块/版本的故障而提供了错误的服务，以实现软件容错。冗余设计的思路来源于硬件系统，但有所不同。软件冗余设计技术是釆用多种不同路径、不同算法或不同实现方法的模块或系统作为备份，在出现故障时进行替换，维持系统的正常运行。.
(2) 检测技术。在无须在线容错或不能采用冗余设计技术的部分，俾又有较高的可靠性要求时，一般采用检测性设计，在软件出现故障后能及时发现并报警。但其明显的缺点是不能自动解决故障，如果没有人工干预，最终将导致系统不能正常运行。
(3) 降低复杂度设计。软件的复杂性与软件可靠性有密切关系。软件复杂性是产生软件缺陷的重要根源。降低复杂度设计的思想就是在保证实现软件功能基础上，简化软件结构。
二、结合项目实际，论述你在进行软件可靠性设计时遵循的基本原则，你所采用的具体可靠性设计技术的基本内容。
可靠性设计需要遵循的原则有：
1. 软件可靠性设计是软件设计的一部分，必须在软件的总体设计框架中使用，并且不能与其他设计原则相冲突。
2. 软件可靠性设计在满足提高软件质量要求的前提下，以提高和保障软件可靠性为最终目标。
3. 软件可靠性设计应确定软件的可靠性y标，不能无限扩大，并且排在功能、用户需求、开发费用之后考虑。
常见的可靠性设计技术有容错设计、检错设计、降低复杂度设计等技术。
容错设计技术：对于软件失效后果特别严重的场合，如飞机的飞行控制系统、空中交通管制系统等，采用容错设计技术。常见的容错设计技术有三种：恢复块设计、N版本程序设计和冗余设计。
恢复块设计：选择一组软件操作作为容错设计单元，把普通的程序块变成恢飪块。一个恢复块包含有若干个功能相同、设计差异的程序块文本，一个运行文本，多〃、备份文本，构成“动态冗余”，一旦运行文本出现故障，则用备份文本替换。软件容错的恢复块方法就是使软件包含有一系列恢复块。
N版本程序设计：N版本程序的核心是通过设计出多个模块或不同版本，对于相同初始条件和相同输入的操作结果，实现多数表决，防止其中某一软件模块/版本的故障提供错误的服务，以实现软件容错。
冗余设计：在一套完整的软件系统之外，设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份，在出现故障时可以使用冗余的部分进行替换，从而维持软件系统的正常运行。缺点是费用和资源的消耗会有所增加。
检错技术：在软件系统中，无需在线容错的地方，或不能采用冗余设计技术的部分，如果对可靠性要求较高，故障有可能导致严重的后果时，一般采用检错技术，在软件出现故障后能及时发现并报警，其缺点是不能自动解决故障。
降低复杂度设计：软件复杂性与软件可靠性有着密切的关系，是产生软件缺陷的重要根源。在设计时考虑降低软件的复杂性，是提高软件可靠性的有效方法。降低复杂度设计的思想是在保证实现软件功能的基础上，简化软件结构，缩短程序代码，优化软件数据流向，降低软件复杂度，从而提高软件可靠性。
(结合实际工作，具体解释遵循的原则和采用的一种或多种可靠性设计技术)
三、阐述你在具体的可靠性设计工作中，为了分析影响软件可靠性的主要因素，所采用的可靠性分析方法。
在软件可靠性设计之前和软件可靠性设计过程中，都需要采用软件可靠性分析和预测方法，来确定当前系统中的主要可靠性因素和目标。常见的软件可靠性分析方法包括故障树分析方法、失效模式与效应分析方法等。
故障树分析方法：一种自顶向下的软件可靠性分析方法，即从软件系统不希望发生的事件(顶事件)，特别是对人员和设备的安全及可靠性产生重大影响的事件开始，向下逐步追査导致顶事件发生的原因，直至基本事件(底事件)，从而确定软件故障原因的各种可能组合方式和(或)发生概率。基本的步骤是软件故障树的建立、定性分析和定量分析。
失效模式与效应分析方法：在软件开发阶段的早期，通过识别软件失效模弍，分析造成的后果，研究分析各种失效模式产生的原因，寻找消除和减少其有害后果的方法，以便尽早发现潜在的问题，并采取相应的措施，从而提高软件的可靠性和安全性.SFMEA的分析对象可以是开发早期阶段的高层次的子系统、部件，也可以是详细设计阶段的单元、模块。对于不同的分析对象，其软件失效模式是不同的，采用的SFMEA分析方法也不同，前者采用系统级分析方法(system FMEA),后者为详细级分析方法〔detailed FMEA)。其基本的步骤是系统定义、软件失效模式分析、软件失效原因分析、软件失效影响分析、改进措施分析。
(结合实际工作，具体阐述自己所采用的一种或多种可靠性分析方法)
1. 企业集成平台的基本功能包括：
(1) 通信服务
提供分布环境下透明的同步/异步通信服务功能，使用户和应用程序无需关心具体的操作系统和应用程序所处的网络物理位置，而以透明的函数调用或对象服务方式完成它们所需的通信服务要求。
(2) 信息集成服务
为应用提供透明的信息访问服务，通过实现异种数据库系统之间的数据交换、互操作、分布数据管理和共享信息模型定义，使集成平台上运行的应用、服务或客户端能够以一致的语义和接口实现对数据的访问与控制。
(3) 应用集成服务
通过高层应用编程接口来实现对相应应用程序的访问。这些接口以函数或对象服务的方式向平台的组件模型提供信息，用户无需对原有系统进行修改，只要在原有系统的基础上加上相应的访问接口就可以将现有的、用不同技术实现的系统互联起来，通过为 应用提供数据交换和访问操作，使各种不同的系统能够相互协作。
(4) 提供对二次开发的支持
集成平台需要提供一组帮助用户开发特定应用程序的支持工具，简化用户在企业集成平台实施过程中的开发工作。
(5) 平台运行管理
需要提供企业集成平台的运行管理和控制模块，负责企业集成平台系统的静态和动态配置、集成平台应用运行管理和维护、事件管理和出错管理等。通过命名服务、目录服务、平台的动态静态配置，以及其中的关键数据的定期备份等功能来维护整个服务平 台的系统配置及稳定运行。
2. 考生在说明所设计的企业集成平台的架构时，必须结合项目实际。对架构的说明应包括从架构层面上如何支持业务流程编写与管理；如何向用户提供功能与信息服务；如何集成业务伙伴的功能；如何与底层数据库、现有系统等进行交互，等等。
在实现企业集成平台时所使用的关键技术包括：
(1) 数据交换格式
企业集成中常用的数据交换格式有：EDI、XML、STEP、PDML
(2) 分布式集成应用基雌架
主要的有 CORBA、J2EE、Web Service
(3) 实现数据集成的常用模式
数据联邦、数据复制和基于接口的数据集成
(4) 实现应用集成的常用模式
适配器集成、信使集成、面板集成、代理集成模式
三、需要具体说明所设计的企业应用集成平台的使用情况，包括如何采用集成平台为企业应用提供一致的信息访问和交互手段，如何对在平台上运行的应用进行管理，如何为应用提供服务等。针对每种使用场景，需要详细说明最终的实施效果。
一、论文中要具体介绍项目的背景与总体需求、系统所采用的技术路线以及你所承担的实际工作。
二、采用ABSD方法进行软件开发时，需要经历架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化六个阶段。
1. 架构需求阶段需要明确用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。其主要活动包括需求获取、标识构件和架构评审。
(1) 需求获取活动需要定义开发人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足功能需求。与此同时，还要获得软件质量属性，满足一些非功能性需求。
(2) 标识构件活动首先需要获得系统的基本结构，然后对基本结构进行分组，最后将基本结构进行打包成构件。
(3) 架构需求评审活动组织一个由系统涉众(用户、系统分析师、架构师、设计实现人员等)组成的小组，对架构需求及相关构件进行审查。审查的主要内容包括所获取的需求是否真实反映了用户需求，构件合并是否合理等。
2. 架构设计阶段是一个迭代过程，利用架构需求生成并调整架构决策。主要活动包括提出架构模型、将已标识的构件映射到架构中、分析构件之间的相互作用、产生系统架构和架构设计评审。
二、需要结合项目实际情况指出所开发的应用系统的总体架构，特别是架构的层次关系。分层架构设计是一种常见的架构设计方法，能够有效简化设计，使设计fit系统结构清晰，便于提高复用能力和产品维护能力。一般来说，企业应用系统的架构可以分为表现层、中间层和持久层三个层次。
1. 表现层。表现层主要负责接收用户的请求，对用户的输入、输出进行检查与控制，处理客户端的一些动作，包括控制页面跳转等，并向用户呈现最终的结果信息。表现层主要采用MVC结构来实现。控制器负责接收用户的请求，并决定应该调用哪个模型来处理；然后，模型根据用户请求调用中间层进行相应的业务逻辑处理，并返回数据;最后，控制器调用相应的视图来格式化模型返回的数据，并通过视图呈现给用户。
2. 中间层。中间层主要包括业务逻辑层组件、业务逻辑层工作流、业务逻辑层实体和业务逻辑层框架四个方面。业务逻辑层组件分为接口和实现类两个部分，接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法。通常按模块来设计业务逻辑组件，每个模块设计为一个业务逻辑组件，并且每个业务逻辑组件以多个DAO组件作为基础，从而实现对外提供系统的业务逻辑服务。业务逻辑层工作流能够实现在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促进此目标的实现。业务逻辑层实体提供对业务数据及相关功能的状态编程访问，业务逻辑层实体数据可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分I/O参数传递，业务逻辑层的实体是可序列化的，以保持它们的当前状态。业务逻辑层是实现系统功能的核心组件，采用容器的形式，便于系统功能的幵发、代码重用和管理。
3. 持久层。持久层主要负责数据的持久化存储，主要负责将业务数据存储在文件、数据库等持久化存储介质中。持久层的主要功能是为业务逻辑提供透明的数据访问、持久化、加载等能力。
三、考生需要结合项目实际情况，举例说明在设计表现层、中间层和持久层时需要考虑的主要问题，例如：在持久层设计时需要考虑MVC模型中的模型、视图和控制器分别对应哪些组件；在中间层设计时需要考虑框架与业务组件之间的关系；在持久层设计时需要考虑如何支持对多种类型数据的透明访问。
一、简要描述所参与分析和开发的企业应用系统开发项目，并明确指出在其中承担的主要任务和开展的主要工作。
二、需求管理过程中主要包含变更控制、版本控制、需求跟踪和需求状态跟踪四项活动。
1.变更控制活动的主要工作包括以下三项：
(1) 问题分析和变更描述。需要识别和分析需求问题，产生一个明确的需求变更提议。
(2) 变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。
(3) 变更实现。这个过程要求需求文档和系统设计以及实现都要同时修改。
2.版本控制活动主要包括定义需求文档的版本格式、制订需求文档的修改模式和确定需求文档版本等三项工作。
3.需求跟踪活动主要包括定义对其他需求的跟踪能力(联系)链和定义和编制每个需求同系统元素之间的联系文档等两项工作。
4.需求状态跟踪活动主要包括定义需求状态和跟踪需求每一个状态等两项工作。
三、以考生实际参与的软件系统开发项目为基础，描述该项目是如何进行软件需求管理的。考生回答时必须以项目实际的需求管理工作为基础，详细描述如何进行变更控制、版本控制、需求跟踪和需求状态跟踪等四项活动。
1.性能
性能是指系统的响应能力，即需要多长时间才能对某个事件做出响应，或者在某段事件内系统所能处理的事件个数。经常用单位事件内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量表示。
2.可靠性
可靠性是软件系统在应用或者系统错误面前，在意外或者错误使用的情况下维持软件系统的功能特性的基本能力。
3.可用性
可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4.安全性
安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
5.可修改性
可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力，包括可维护性、可扩展性、结构重构、可移植性。
6.功能性
功能性是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7.可变性
可变性是指体系结构经扩充或变更而成为新体系结构的能力。
8.互操作性
互操作性是指作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。如程序和用其他编程语言编写的软件系统的交荽作用就是互操作性的问题。
三、针对作者实际参与的软件系统架构评估，说明所釆用的评估方法，并描述其具体实施过程和效果。
现软件评估中的主要评估方法包括SAAM(Scenarios-based Architecture Analysis Method)和ATAM(Architecture Tradeoff Analysis Method，体系结构权衡分析方法)。作者可选择某种评估方法展开实际项目的系统评估。
二、说明软件系统设计中常用的软件设计模式有哪几类，阐述每种类型的特点及其所包含的设计模式。
常用的软件设计模式主要包括：
1.创建型模式
该类模式是对对象实例化过程的抽象，它通过采用抽象类所定义的接口，封装了系统中对象如何创建、组合等信息。
所包括的模式：Abstract Factory(抽象工厂)、Builder(建造者)、Factory Method(工厂方法)、Prototype(原型)、Singleton(单例)。
2.结构型模式
该类模式主要用于如何组合已有的类和对象以获得更大的结构，一般借鉴封装、代理、继承等概念将一个或多个类或对象进行组合、封装，以提供统一的外部视图或新的功能。
所包括的模式：Adapter(适配器)、Bridge(桥接)、Composite(组合)、Decorator(装饰)、Faqade(外观)、Flyweight(享元)、Proxy(代理)。
3.行为型模式
该类模式主要用于对象之间的职责及其提供的服务的分配，它不仅描述对象或类的模式，还描述它们之间的通信模式，特别是描述一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务。
所包括的模式：Chain of Responsibility(职责链)、Command(命令)、Interpreter(解释器)、Iterator(迭代器)、Mediator(中介者)、Memento(备忘录)、Observer(观察者)、State(状态)、Strategy(策略)、TemplateMethod(模板方法)、Visitor(访问者)。
三、针对作者实际参与的软件系统开发项目，说明所采用的软件设计模式，并描述这些设计模式所产生的实际应用效果。
使用设计模式的作用主要表现在：(1) 简化并加快设计；(2) 方便开发人员之间的通信；(3) 降低风险；(4)有助于转到面向对象技术。
二、需要较为详细地说明目前各种常见的信息系统建模方法的核心思想，并对每种方法所创建的模型进行简要描述。
(1) 结构化建模方法。
结构化建模方法是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图(DFD)。对于流程较为稳定的系统可考虑结构化建模方法。
(2) 信息工程建模方法(或数据库建模方法)。
信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图(ERD)。主要用于数据建模。
二、本文内容的组织可以将问题2与问题3结合起来论述。先说明RUP的四个阶段及RUP的特征，然后再论述每个阶段，作者开展了哪些工作。
RUP中的软件过程在时间上被分解为四个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。
四个阶段的核心任务分别为：
(1) 初始阶段
· 明确地说明项目规模。这涉及了解环境及最重要的需求和约束，以便于可以得出最终产品的验收标准。
· 计划和准备商业理由。评估风险管理、人员配备、项目计划和成本/进度/收益率折中的备选方案。
· 综合考虑备选构架，评估设计和自制/外购/复用方面的折中，从而估算出成本、进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了。该解决方案在细化和构建阶段实现。
· 准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。
(2) 细化阶段
· 快速确定构架，确认构架并为构架建立基线。
· 根据此阶段获得的新信息改进前景，对推动构架和计划决策的最关键用例建立可靠的了解。
·为构建阶段创建详细的迭代计划并为其建立基线。
· 改进开发案例，定位开发环境，包括流程和支持构建团队所需的工具和自动化支持。
· 改进构架并选择构件。评估潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选构架构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。
(3) 构建阶段
· 资源管理、控制和流程优化。
·完成构件开发并根据已定义的评估标准进行测试。
· 根据前景的验收标准对产品发布版进行评估。
(4)产品化阶段(提交阶段)
· 执行部署计划。
·对最终用户支持材料定稿。
·在开发现场测试可交付产品。
·制作产品发布版。
·获得用户反馈。
·基于反馈调整产品。
·使最终用户可以使用产品。
RUP最核心的3个特征是：用例驱动、以架构为中心的、迭代和增量。
制品(Artifact)——what的问题：制品是活动生成、创建或修改的一段信息。也可译为产品、工件等，和制品的意思差不多。
工作流(Workflow)——when 的问题：工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
一、应结合自己参与的信息系统项目，说明在其中所承担的工作。
二、
NoSQL的主要优势：
(1) 避免不必要的复杂性
(2) 高吞吐量
(3) 高水平扩展能力和低端硬件集群
(4)避免了昂贵的对象-关系映射
NoSQL的缺点：
(1) 数据模型和查询语言没有经过数学验证
(2) 不支持ACID特性
(3) 功能简单
(4)没有统一的查询模型
NoSQL数据库的四大分类：
1、键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
2、列存储数据库。
这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak。
HBase：HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
3、文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。
3、文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。
Mongo DB：Mongo DB 是目前在IT行业非常流行的一种非关系型数据库(NoSql),其灵活的数据存储方式备受当前IT从业人员的青睐。Mongo DB很好的实现了面向对象的思想(OO思想),在Mongo DB中 每一条记录都是一个Document对象。Mongo DB最大的优势在于所有的数据持久操作都无需开发人员手动编写SQL语句,直接调用方法就可以轻松的实现CRUD操作。
Sequoia DB：SequoiaDB是一款分布式非关系型文档数据库，可以被用来存取海量非关系型的数据，其底层主要基于分布式，高可用，高性能与动态数据类型设计SequoiaDB可以独立作为一款高性能可扩展的NoSQL数据库使用，也可与当前主流分布式计算框架Hadoop紧密集成。
4、图形(Graph)数据库
图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J, InfoGrid, Infinite Graph.
三、论文中需要结合项目实际工作，详细论述在项目中所采用的noSQL数据库，并详细说明实施效果。
二、详细阐述有哪些不同的软件设计方法，并说明每种方法的适用场景。
软件设计方法：
( )模型驱动设计。
模型驱动设计是一种系统设计方法，强调通过绘制图形化系统模型描述系统的技术和实现。通常从模型驱动分析中开发的逻辑模型导出系统设计模型，最终，系统设计模型将作为构造和实现新系统的蓝图。
( )结构化设计。
结构化设计是一种面向过程的系统设计技术，它将系统过程分解成一个容易实现和维护的计算机程序模块。把—个程序设计成一个自顶向下的模块层次，一个模块就是一组指令：一个程序片段、程序块、子程序或者子过程，这些模块自顶向下按照各种设计规则和设计指南进行开发，模块需要满足高度内聚和松散耦合的特征。
( )信息工程。
信息工程是一种用来计划、分析和设计信息系统的模型驱动的、以数据为中心的但对过程敏感的技术。信息工程模型是一些说明和同步系统的数据和过程的图形。信息工程的主要工具是数据模型图(物理实体关系图)。
( )面向对象设计。
面向对象设计是一种新的设计策略，用于精炼早期面向对象分析阶段确定的对象需求定义，并定义新的与设计相关的对象。面向对象设计是面向对象分析的延伸，有利于消除“数据”和“过程”的分离。
( )快速应用开发。
快速应用开发是一种系统设计方法，是各种结构化技术(特别是数据驱动的信息工程)与原型化技术和联合应用开发技术的结合，用以加速系统开发。快速应用开发要求反复地使用结构化技术和原型化技术来定义用户的需求并设计最终系统。
三、针对作者实际参与的软件系统开发项目，说明使用了哪种软件设计方法，并描述该方法实施后的实际应用效果。
一、概要叙述你所参与管理或开发的软件项目，以及你在其中所承担的主要工作。
二、详细阐述有哪些不同的软件系统架构评估方法，并从评估目标、质量属性和评估活动等方面论述其区别。
常见的系统体系架构分析方法有SAAM和ATAM。
SAAM (Sccnarios-based Architecture Analysis Method)是一种非功能质量属性的体系架构分析方法，最初用于比较不同的体系架构，分析架构的可修改性，后来也用于其他的质量属性,如可移植性、可扩充性等。
( )特定目标：对描述应用程序属性的文档，验证基本体系结构假设和原则。SAAM不仅能够评估体系结构对于特定系统需求的适用能力，也能被用来比较不同的体系结构。
( )评估活动：SAAM的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。
ATAM(Architecture Tradeoff Analysis Method)是在SAAM的棊础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
( )特定目标：在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法，使用该方法确定在多个质量属性之间折中的必要性。
( )评估活动：分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模构造和分析、折中。
三、针对作者实际参与的软件系统架构评估工作，说明所采用的评估方法，并描述其具体实施过程和效果。
常用的架构评估方法有：基于问卷调查的评估方式、基于场景的评估方式和基于度量的 评估方式。
ATAM评估架构的评估经历了描述和介绍阶段、调查和分析阶段、测试阶段和报告阶段四个阶段。下面我分别从这四个 阶段进行介绍。
第一阶段是描述和介绍阶段，首先由架构师向大家介绍什么是ATAM方法，它是一种基于场景的软件架构评估方法，对系统的多个质量属性基于场景进行评估。 通过该评估确认系统存在的风险，并检查各自的非功能性需求是否满足需求。
第二阶段是调查和分析阶段，不同需求方均提出了相关需求，所涉及质量场景。
第三个阶段是测试阶段，根据系统特性，我们首先确定场景优先级，由高到低分别是：性能、可靠性、可修改性、安全性、可用性、易用性。
架构权衡分析方法所谓权衡在此得到了体现，质量属性每个都很重要，但是根据系统特点需要对质量属性有优先级排序，架构设计时需要所有权衡和折中。
确定了优先级之后，我们需要具体阐述针对每个质量属性系统采取了哪些方案，例如提升性能使用了缓存，提升可修改性使用了策略模式，提升可靠性使用了统一异常处理框架等等。
第四个阶段是报告阶段，我们将评估过程和结果都汇总整理成文档，其中包括质量属性效用树、风险点、敏感点、权衡点和每次评估会议纪要，以及最终的架构决策。
其包括的内容包括：架构分析方法文档、架构的不同场景及各自的优先级、质量效应树、风险点决策、非风险点决策及每次的评估会议记录