软考笔记

商业智能：
	组成成分：
		数据仓库
		联机分析处理
		数据挖掘
		数据备份
		恢复
	处理过程：
		数据预处理
			数据抽取
			转换
			装载
		建立数据仓库
			处理海量数据的基础
		数据分析
			OLAP和数据挖掘技术
			联机处理分析 
				对数据汇总/聚集 同时提供切片、切块、下钻和旋转灯数据分析功能
		数据展现
	
数据转储
	静态转储
		在转储期间不允许对数据库进行任何存取修改操作
	动态转储
		转储期间允许对数据库进行存取、修改操作，故转储和用户事务可并发执行
	海量转储
		每次转储全部数据
	增量转储
		每次只转储上次转储更新后的数据
		
存储
	开放系统的直连式存储（DAS）
		在服务器上外挂一组大容量硬盘，存储设备与服务器主机之间采用SCSI通道连接，带宽为10MB/s、20MB/s、40MB/s和80MB/s等
		缺点：
			难以扩容
			不支持数据容错
			当服务器异常会数据丢失
	网络接入存储（NAS）
		将存储设备连接到现有网络上，提供数据存储和文件访问服务的设备
		NAS服务器在专用主机上安装简化了的瘦操作系统（只具有访问权限控制、数据保护和恢复等功能）的文件服务器

架构模式：
    软件设计中的高层决策
    反映了开发软件系统过程中所作为的基本设计决策
设计模式：
    关注软件系统的设计，与实现具体语言无关
惯用法则：
    实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。
    eg：引用计数

ATAM：
    一种软件架构评估方法。主要对软件体系结构的设计结果进行评估。
    评估是软件系统详细设计、实现和测试之前的阶段工作。不涉及系统的实现代码和测试。

敏感点：
    一个或多个构件（或之间的关系）的特性
权衡点：
    影响多个质量属性的特性，是多个质量属性的敏感点。

企业门库：
    企业信息门户：
        请问结构数据和无结构数据提供统一入口，实现搜集、访问、管理和无缝集成
    企业知识门户：
        提供创建、搜集和传播企业知识的平台，通过企业知识门户，员工可以与工作团队的其它成员取得联系，寻找能够提供帮助的专家
    企业应用门户：
        用来提高企业的集中贸易能力、协同能力和信息管理能力的平台
   

软件架构设计：
    包括提出架构模型、产生架构和进行设计评审等活动，是一个迭代的过程
    初期：一般选择一个合适的架构风格，将架构分析阶段已标识的构件映射到架构中，并分析这些构件的关系，一旦得到详细的架构设计，需要邀请独立于系统开发的外部人员进行评审。
    一般来说，软件架构设计活动将已标识构建继承到软件架构中，设计这些构件，但不予实现。

基于场景的架构分析方法(SAAM)
    主要输入：
        问题描述
        需求说明
        架构描述文档
    分析过程主要包括：
        场景开发
        架构描述
        单个场景评估
        场景交互
        总体评估
		
企业信息集成：
    技术平台集成
    数据集成
    应用系统集成
        实现不同系统之间的互相操作，使得不同应用系统之间能够实现数据和方法的共享
    业务集成
        使得在不同应用系统中的流程能够无缝连接，实现流程的协调运作和流程信息的充分共享

软件系统架构
    关于软件系统的结构、行为和属性的高级抽象
    不仅指定了软件系统的组织和拓扑结构，而且显示了系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理
    在描述阶段，细致的描述组件的交互关系

DSSA(特定领域软件架构)
    3个层次的系统模型    
        领域开发环境
        领域特定应用开发环境
        应用执行环境
            应用开发工程师只在领域特定应用开发环境工作

mvc架构：
    模型：
        模型是应用程序的主体部分。模型标识业务数据和业务逻辑。
        一个模型能为多个视图提供数据。
    控制器：
        控制器接收用户的输入并调用模型和视图去完成用户的需求。
        该部分是用户界面与Model的接口。
        一方面他的解释来自于视图的输入，将其解释成为系统能够理解的对象，同时他也识别用户动作，并将其解释为对模型特定方法的调用；
        另一方面，他处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。

    视图：
        用户看到并与之交互的界面
        视图向用户显示相关的数据，并能接收用户的输入数据，但他不进行任何实际的业务处理。


对象管理组织OMG基于CORBA基础设施定义了4种构件标准
    实体Entity构件需要长期持久化并主要用于事务性行为，由容器持久化。
    加工Process构件同样需要容器管理其持久化，但没有客户端可访问的主键。
    会话Session构件不需要容器管理其持久化，其状态信息必须由构件自己管理。
    服务Service构件是无状态的。

系统规划
    项目可行性分析报告
        用户单位、项目或产品的立项背景、需求来源和目标性的介绍；
        用户的内外部环境、组织机构、现有的 IT 设施情况等；
        用户的业务模型和业务规划；
        预期要建设的技术系统在用户业务中的位置和作用；
        信息化后的用户业务模型、软件应用方式、相关的部署环境、运行规则、管理规范等；
        为实现信息化业务模型，技术系统的产品需求定义（功能、性能、约束）和部署方式等；
        产品或项目的技术框架；
        项目的要点、技术难点、主要实施障碍等；
        项目或产品的可行性研究结果；
        项目可选择的实施方式、组织方式、沟通和协调机制等；
        项目的资源范围和预算（人、财、物、时间等）；
        项目的成本/收益分析

        项目风险及影响评估；
        项目进度计划；
        项目质量计划；
        项目过渡期资金的获得方式、财务计划；
        产品或项目的商务模式、盈利模式论述；
        同类产品或公司的市场调查结果，以及竞争性比较；
        企业成功案例、资质等；
        商务条款或供应商/客户合同；
    可行性研究
        经济可行性
        技术可行性
        法律可行性
        执行可行性
        方案的选择
    成本效益分析
        项目可能涉及的成本项目的成本部分
        项目可能涉及的收益
        效益分析的若干指标和进一步的分析
    可行性分析报告
        项目背景：包括问题描述、实现环境和限制条件；
        管理概要和建议：包括重要的研究结果、说明、建议和影响；
        候选方案：包括候选系统的配置和最终方案的选择标准；
        系统描述：包括系统工作范围的简要说明和被分配系统元素的可行性；
        经济可行性（成本/效益分析）：包括经费概算和预期的经济效益；
        技术可行性（技术风险评价）：包括技术实力、已有工作基础和设备条件；
        法律可行性：包括系统开发可能导致的侵权，违法和责任等；
        用户使用可行性：包括用户单位的行政管理，工作制度和使用人员的素质；
        其他与项目有关的问题：例如，其他方案介绍和未来可能的变化。
    方案的制订和改进
        确定软件架构
        确定实现的各种关键性要素和实现手段关键性的实现要素
        归结目标到最适合的计算体系
系统分析与设计方法









软件架构设计
    架构的模型
        结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。
        框架模型。框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
        动态模型。动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。
        过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
        功能模型。该模型认为架构由一组功能构件按层次组成，且下层向上层提供服务。它可以看作是一种特殊的框架模型。



        “4+1” 视图模型
            逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。
            开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
            进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
            物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。
            场景视图：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。
            逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。
        架构需求与软件质量属性
            软件质量属性
                功能性：适合性、准确性、互操作性、依从性、安全性；
                可靠性：成熟性、容错性、易恢复性；
                易用性：易理解性、易学性、易操作性；
                效率：时间特性、资源特性；
                可维护性：易分析性、易改变性、稳定性、易测试性；
                可移植性：适应性、易安装性、遵循性、易替换性；
            运行期质量属性
                性能：性能是指软件系统及时提供相应服务的能力。包括速度、吞吐量和持续高速性三方面的要求。
                安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
                易用性：指软件系统易于被使用的程度。
                可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
                互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
                可靠性：软件系统在一定的时间内无故障运行的能力。
                持续可用性：指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中。
                鲁棒性：是指软件系统在一些非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力。也称健壮性或容错性。
            开发期质量属性
                易理解性：指设计被开发人员理解的难易程度。
                可扩展性：软件因适应新需求或需求变化而增加新功能的能力。也称为灵活性。
                可重用性：指重用软件系统或某一部分的难易程度。
                可测试性：对软件测试以证明其满足需求规范的难易程度。
                可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度；
                可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
        软件架构风格分类
            数据流风格：批处理序列；管道/过滤器。
            调用/返回风格：主程序/子程序；面向对象风格；层次结构。
            独立构件风格：进程通信；事件系统。
            虚拟机风格：解释器；基于规则的系统。
            仓库风格：数据库系统；超文本系统；黑板系统。
       
            数据流风格架构主要包括两种具体的架构风格：批处理序列和管道-过滤器。
                批处理序列
                批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据传送在步与步之间作为一个整体。（组件为一系列固定顺序的计算单元，组件间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递）批处理的典型应用：
                    经典数据处理；    
                    程序开发；
                    Windows 下的 BAT 程序就是这种应用的典型实例。
                管道和过滤器
                    在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的过滤器必须是独立的实体，它不能与其他的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
                    特点：
                        使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；
                        允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
                        支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都
可被连接起来；
                        系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以
被改进的过滤器替换掉；
                        允许对一些如吞吐量、死锁等属性的分析；
                        支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行
执行。
                    不利因素：
                        通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但
它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换；
                        不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重；
                        因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
                批处理序列风格与管道过滤器风格对比
                    共同点：把任务分成一系列固定顺序的计算单元（组件）。组件间只通过数据传递交互。
                    区别：批处理是全部的、高潜伏性的，输入时可随机存取，无合作性、无交互性。而管道过滤器是递增的，数据结果延迟小，输入时处理局部化，有反馈、可交互。批处理强调数据传送在步与步之间作为一个整体，而管理过滤器无此要求。

            调用/返回风格
                调用/返回风格架构主要包括三种具体的架构风格：主程序/子程序；面向对象风格；层次结构。
                主程序/子程序
                    主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性，取决于它调用的子程序的正确性。
                面向对象风格
                    抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍使用面向对象系统。这
种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
                    这种风格的两个重要特征为：
                        （1）对象负责维护其表示的完整性；
                        （2）对象的表示对其他对象而言是隐蔽的。因为一个对象对它的客户隐藏了自己的表示，所以这些对象可以不影响它的客户就能改变其实现方法。
                    优点：
                        （1）因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象；
                        （2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
                    缺点：
                        （1）为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象；
                        （2）必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果 A 使用了对象 B，C 也使用了对象 B，那么，C 对 B 的使用所造成的对 A 的影响可能是料想不到的。
                层次结构风格
                    优点：
                        （1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；
                        （2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；
                        （3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。
                    缺点：
                        （1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
                        （2）很难找到一个合适的、正确的层次抽象方法。
            独立构件风格
                独立构件风格主要包括：进程通讯和事件系统子风格。
                进程通信架构风格进程通信架构风格：构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点到点、异步和同步方式及远过程调用等。
                事件系统风格基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。                     
                隐式调用系统的主要优点有：       
                    （1）为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
                    （2）为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件
的接口。
                隐式调用系统的主要缺点有：
                    （1）构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
                    （2）数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。 
                    （3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问
题。
            虚拟机风格
                虚拟机风格主要包括解释器和规则为中心两种架构风格。
                解释器
                    一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一
个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。其缺点是执行效率较低。典型的例子是专家系统。
                规则为中心
                    基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。
            仓库风格
                在仓库（repository）风格中，有两种不同的构件：中央数据结构说明当前状态，独立
构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化。
                仓库风格包括的子风格有：数据库系统、超文本系统、黑板风格。
                黑板系统是在抽象与总结语言理解系统 HEARSAY-11 的基础上产生的，适合于解决复杂
的非结构化的问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易。黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。
                黑板系统主要由三部分组成：
                    （1）知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成。
                    （2）黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
                    （3）控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
        层次系统架构风格
            二层及三层 C/S 架构风格
                二层C/S 
                    C/S 结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。
                    传统的二层 C/S 结构存在以下几个局限：
                        二层 C/S 结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或 Internet；软、硬件的组合及集成能力有限；服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。
                三层 C/S
                    三层 C/S 结构是将应用功能分成表示层、功能层和数据层三个部分
                    表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从
键盘等输入的数据，并显示应用输出的数据。
                    功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。而处理所需的数据
则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。
                    数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅
速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用 SQL 语言。
            B/S 架构风格
                与 C/S 架构相比，B/S 架构也有许多不足之处，例如: 
                    （1）B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
                    （2）采用 B/S 架构的应用系统，在数据查询等响应速度上，要远远地低于 C/S 架构。
                    （3）B/S 架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理（OnLine Transaction Processing，简称 OLTP）应用。
            MVC 架构风格
                MVC 中各个部分的分工与协作是这样的：
                （1）Model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model 接受 Controller 的请求并完成相应的业务处理，在状态改变的时候向 View 发出相应的通知。
                （2）View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
                （3）View 捕获到用户交互操作后会直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。在完成 UI 处理后，Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。
            MVP 架构风格
                MVP 的优点包括：
                （1）模型与视图完全分离，我们可以修改视图而不影响模型。
                （2）可以更高效地使用模型，因为所有的交互都发生在一个地方—Presenter 内部。
                （3）我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
                （4）如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻
辑（单元测试）。
                MVP 的缺点包括：
                由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁。还有一点需要明白，如果 Presenter 过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么 Presenter 也需要变更了。比如说，原本用来呈现 HTML 的 Presenter 现在也需要用于呈现 PDF 了，那么视图很有可能也需要变更。
        面向服务的架构SOA
            SOA概述
                在 SOA 模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。
            SOA 的关键技术
                UDDI
                    在 UDDI 技术规范中，主要包含以下三个部分的内容：
                    （1）数据模型。UDDI 数据模型是一个用于描述业务组织和服务的 XML Schema。
                    （2）API。UDDI API 是一组用于查找或发布 UDDI 数据的方法，UDDI API 基于 SOAP。
                    （3）注册服务。UDDI 注册服务是 SOA 中的一种基础设施，对应着服务注册中心的角
色。
                WSDL
                    WSDL（Web ServiceDescription Language，Web 服务描述语言）是对服务进行描述的语言，它有一套基于 XML 的语法定义。
                    采用抽象接口定义对于提高系统的扩展性很有帮助。服务接口定义就是一种抽象的、可
重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型，服务实现者可以根据这些标准定义来实现具体的服务。
                    服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服
务和端口描述。一个服务往往会包含多个服务访问入口，而每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务访问入口的部署细节，例如，通过哪个地址来访问，应当使用怎样的消息调用模式来访问等。
                SOAP
                    SOAP（Simple ObjectAccess Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC）。
                    SOAP 主要包括以下四个部分：
                    （1）封装
                    （2）编码规则。SOAP 编码规则定义了一种序列化的机制，用于交换系统所定义的数
据类型的实例。
                    （3）RPC 表示。SOAP RPC 表示定义了一个用来表示远程过程调用和应答的协议。
                    （4）绑定。SOAP 绑定定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封
装的约定。   
                    SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请
求/应答的模式。所有的 SOAP 消息都使用 XML 进行编码。
                    SOAP 消息包括以下三个部分：
                    （1）封装（信封）。封装的元素名是 Envelope，在表示消息的 XML 文档中，封装是顶层元素，在 SOAP 消息中必须出现。
                    （2）SOAP 头。SOAP 头的元素名是 Header，提供了向 SOAP 消息中添加关于这条SOAP 消息的某些要素的机制。SOAP 定义了少量的属性用来表明这项要素是否可选以及由谁来处理。SOAP 头在 SOAP 消息中可能出现，也可能不出现。如果出现的话，必须是 SOAP 封装元素的第一个直接子元素。
                    （3）SOAP 体。SOAP 体的元素名是 Body，是包含消息的最终接收者想要的信息的容器。SOAP 体在 SOAP 消息中必须出现且必须是 SOAP 封装元素的直接子元素。如果有头元素，则 SOAP 体必须直接跟在 SOAP 头元素之后；如果没有头元素，则 SOAP 体必须是SOAP 封装元素的第一个直接子元素。
                REST
                    REST（RepresentationalState Transfer，表述性状态转移）是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与 SOAP 很好地隔离开来，REST 从根本上来说只支持几个操作（POST、GET、PUT 和 DELETE），这些操作适用于所有的消息。
                    REST 提出了如下一些设计概念和准则：
                    （1）网络上的所有事物都被抽象为资源。
                    （2）每个资源对应一个唯一的资源标识。
                    （3）通过通用的连接件接口对资源进行操作。
                    （4）对资源的各种操作不会改变资源标识。
                    （5）所有的操作都是无状态的。
            SOA 的实现方法

    
                

                
        
            







设计模式
                                    GOF模式
                            创建型              结构型            行为型
        |应用于类    |Factory Method    |Adapter        |Interpreter
    应  |            |                 |               |Template Method
    用  +----------------------------------------------------------------
    范  |应用于对象   |Abstract Factory |Adapter        |Chain of Responsibility    
    围  |            |Builder          |Bridge         |Command
        |            |Prototype        |Composite      |Iterator
        |            |Singleton        |Decorator      |Mediator
        |            |                 |Facade         |Memento
        |            |                 |Flyweight      |Observer 
        |            |                 |Proxy          |State
        |            |                 |               |Strategy
        |            |                 |               |Visitor
    （1）Factory Method 模式。Factory Method 模式提供了一种延迟创建类的方法，使用这个方法可以在运行期由子类决定创建哪一个类的实例。
    （2）Abstract Factory 模式。Abstract Factory 又称为抽象工厂模式，该模式主要为解决复杂系统中对象创建的问题。抽象工厂模式提供了一个一致的对象创建接口来创建一系列具有相似基类或相似接口的对象。抽象工厂模式是一种很有代表性的设计模式，在 9.2 节中将对该模式进行更详细的介绍。
    （3）Builder 模式。Builder 模式与 Abstract Factory 模式非常类似，但 Builder 模式是逐步地构造出一个复杂对象，并在最后返回对象的实例。Builder 模式可以把复杂对象的创建与表示分离，使得同样的创建过程可以创建不同的表示。
    （4）Prototype 模式。Prototype 模式可以根据原型实例制定创建的对象的种类，并通过深复制这个原型来创建新的对象。Prototype 模式有着同 Abstract Factory 模式和 Builder 模式相同的效果，不过当需要实例化的类是在运行期才被指定的而且要避免创建一个与产品曾是平行的工厂类层次时，可以使用 Prototype 模式。使用 Prototype 模式可以在运行时增加或减少原型，比 Abstract Factory 和 Builder 模式更加灵活。
    （5）Singleton 模式。Singleton 模式也是一种很有代表性的模式。使用 Singleton 模式可以保证一个类仅有一个实例，从而可以提供一个单一的全局访问点。将在 9.2 节中对Singleton 作更详细的介绍。
    （6）Adapter 模式。Adapter 模式可以解决系统间接口不相容的问题。通过 Adapter 可以把类的接口转化为客户程序所希望的接口，从而提高复用性。
    （7）Bridge 模式。Bridge 模式把类的抽象部分同实现部分相分离，这样类的抽象和实现都可以独立地变化。
    （8）Composite 模式。Composite 模式提供了一种以树形结构组合对象的方法，使用Composite 可以使单个对象和组合后的对象具有一致性以提高软件的复用性。
    （9）Decorator 模式。Decorator 模式可以动态地为对象的某一个方法增加更多的功能。在很多时候，使用 Decorator 模式可以不必继承出新的子类从而维护简洁的类继承结构。在 9.2 节中将对 Decorator 模式作更详细的介绍。
    （10）Facade 模式。Facade 模式为一组类提供了一致的访问接口。使用 Facade 可以封装内部具有不同接口的类，使其对外提供统一的访问方式。Facade 模式在 J2EE 系统开发中发展为 Session Facade 模式。
    （11）Flyweight 模式。Flyweight 模式可以共享大量的细粒度对象，从而节省创建对象所需要分配的空间，不过在时间上的开销会变大。
    （12）Proxy 模式。顾名思义，Proxy 模式为对象提供了一种访问代理，通过对象 Proxy 可以控制客户程序的访问。例如：访问权限的控制、访问地址的控制、访问方式的控制等，甚至可以通过 Proxy 将开销较大的访问化整为零，提高访问效率。
    （13）Interpreter 模式。定义了一个解释器，来解释遵循给定语言和文法的句子。
    （14）Template Method 模式。定义一个操作的模板，其中的一些步骤会在子类中实现，以适应不同的情况。
    （15）Chain of Responsibility 模式。Chain of Responsibility 模式把可以响应请求的对象组织成一条链，并在这条对象链上传递请求，从而保证多个对象都有机会处理请求而且可以避免请求方和相应方的耦合。
    （16）Command 模式。将请求封装为对象，从而增强请求的能力，如参数化、排队、记录日志等。
    （17）Iterator 模式。Iterator 模式提供了顺序访问一个对象集合中的各元素的方法，使用 Iterator 可以避免暴露集合中对象的耦合关系。
    （18）Mediator 模式。Mediator 模式可以减少系统中对象间的耦合性。Mediator 模式使用中介对象封装其他的对象，从而使这些被封装的对象间的关系就成了松散耦合。
    （19）Memento 模式。Memento 模式提供了一种捕获对象状态的方法，且不会破坏对象的封装。并且可以在对象外部保存对象的状态，并在需要的时候恢复对象状态。
    （20）Observer 模式。Observer 模式提供了将对象的状态广播到一组观察者的方式，从而可以让每个观察者随时可以得到对象更新的通知。
    （21）State 模式。State 模式允许一个对象在其内部状态改变的时候改变它的行为。
    （22）Strategy 模式。使用 Strategy 模式可以让对象中算法的变化独立于客户。
    （23）Visitor 模式。表示对某对象结构中各元素的操作，使用 Visitor 模式可以在不改变各元素类的前提下定义作用于这些元素的新操作。
     Abstract Factory 模式
        模式名称
            Abstract Factory，也经常称之为抽象工厂模式。
        意图解决的问题
            在程序中创建一个对象似乎是不能再简单的事情，其实不然。在大型系统开发中存在以下问题：
            （1）object new ClassName 是最常见的创建对象方法，但这种方法造成类名的硬编码，需要根据不同的运行环境动态加载相同接口但实现不同的类实例，这样的创建方法就需要配合上复杂的判断，实例化为不同的对象。
            （2）为了适用于不同的运行环境，经常使用抽象类定义接口，并在不同的运行环境中实现这个抽象类的子类。普通的创建方式必然造成代码同运行环境的强绑定，软件产品无法移植到其他的运行环境。抽象工厂模式就可以解决这样的问题，根据不同的配置或上下文环境加载具有相同接口的不同类实例。
        模式描述
             |-----------------------------------------Client
             |                                            |
     Abstract Factory                             Avstract Product
     Create Product()                              
        /        \                                     /        \
Create Factory1  Create Factory2                Product1      Product2
       |            |                                ^           ^
       L------------+--------------------------------|           |
                    L--------------------------------------------|


        效果
            应用 Abstract Factory 模式可以实现对象可配置的、动态的创建。灵活运用 Abstract Factory 模式可以提高软件产品的移植性，尤其是当软件产品运行于多个平台，或有不同的功能配置版本时，抽象工厂模式可以减轻移植和发布时的压力，提高软件的复用性。
     Singleton 模式
        模式名称
            Singleton，也常称之为单件模式或单根模式。
        意图解决的问题
            在软件开发中，开发人员希望一些服务类有且仅有一个实例供其他程序使用。
        模式描述
    Decorator 模式
        模式名称
            Decorator 模式，又称装饰模式或油漆工模式。
        意图解决的问题
            在开发时，经常会发现为类预先设计的功能并不够强大，需要增强或扩展类的功能。解决这个问题的最简单的办法是继承出一个新的类，并扩展相应的方法。但是这样做会产生大量的子类，让系统中类的层次结构变得复杂且混乱。Decorator 模式通过在原有类的基础上包装一层来解决功能扩展的问题。           
        模式描述
                Compone    
                operation()
                /        \
    ConcreteCompone    DecoratorCompon
    operation()        operation()
                        /        \
           ConcreteDecorator    ConcreteDecorator    
               operation()        operation()
            DecoratorComponent 是 ConcreteComponent 的装饰类，它们继承自同一个抽象类Component，拥有相同的接口。对于 ConcreteComponent 的装饰可能不止一种，因此又继承出ConcreteDecorator1 和 ConcreteDecorator2 来作为具体的装饰类。这个结构在类层次上是很清晰的，比静态继承更具有灵活性。
    Facade/Session Facade 模式
        模式名称
            Facade 模式，又称外观模式，也有人很形象地把它翻译成“门面模式”。
        意图解决的问题
            在程序中，经常会用到其他若干个子系统。在不作任何处理的时候，需要了解每一个子系统的接口，并使用这些接口进行调用。这些调用不但让结构变得混乱，客户程序和各子系统的耦合性也大大增加，扩展与维护都变得相当困难。
        模式描述
                Client
                   |
    +---簇-----------------------------+
    |  +---------Facade-----+---+      |         
    |  |    |               |   |      |
    |子系统 子系统        子系统 子系统  |
    +----------------------------------+    
            Facade 模式通过在原有系统前增加一层的方法，封装这些子系统的接口，对外提供一致的访问接口，解决了上面的问题。
        效果
            Facade 模式屏蔽了子系统的细节，降低了客户程序使用这些子系统的复杂度，同时也降低了客户程序和子系统的耦合程度。这样就从需要让所有的人了解所有的子系统接口变成让个别专家抽象子系统的接口。    
            Facade 模式应用起来非常灵活，也没有特定的实现，其应用的关键就是抽象出合理的Facade 接口。
    Mediator 模式
        模式名称
            Mediator 模式，又称中介者模式。
        意图解决的问题
            在一个复杂系统中会有很多对象，这些对象之间会相互通信，从而造成对象的相互依赖。修改其中一个对象可能会影响到其他若干对象，系统中对象的复杂耦合关系造成系统可维护性的降低，系统显得混乱且难以理解。Mediator 通过封装一组对象间的通信为系统解耦。
        模式描述
            Mediator <-------------------------Colleague
               ^                                /     \
               |                               /       \
         ConcreteMediator------->ConcreteColleague1    ConcreteColleague2
               +-------------------------------------------^
        效果
            Mediator 封装了一组对象间的通信，降低了 Colleague 之间的耦合性，单个 Colleague的变化不会影响到其他的对象。
            不过当 Colleague 比较多，且其中的关系复杂时，中介类 ConcreteMediator 会变得非常复杂，难以维护。
            Mediator 经常会变得非常复杂，不但每一个需要通信的对象都需要知道 Mediator 的存在，而且 Mediator 也需要知道每一个通信的对象的实现。所以，一般仅在较小的范围内使用 Mediator 模式，否则过多的 Colleague 类造成中介类的难以维护会抵消掉该模式带来的优点，反而让系统更难以维护。
    Observer 模式
        模式名称
            Observer 模式，又称观察者模式。
        意图解决的问题
            由于对象封装的特性，一般的，在系统中对象状态的变化都是独立的，即 A 对象状态的变化不会立即反映到 B 对象。但是，在系统中很多对象是相互关联的，例如对于一个股票行情系统，股票状态的变化需要同时反映到多个视图中——实时行情、技术分析图表等。对于这个问题，最简单的解决办法就是硬编码这些关联关系。但是这样会造成系统中对象的紧密耦合，系统难以维护和复用。
        模式描述
            Subject--------------------------->Observer
            Observers                          Update()
            attach(Observer)                 /         \
            Detach(Observer)                /           \
            notify()                       /             \
                ^                         /               \
                |                        /                 \
          ConcreteSubject<--------ConcreteObserver1    ConcreteObserver2
            subjectState            observerState        observerState
            setState()                Update()            Update()
            getState()
                ^
                |

            抽象类 Subject 定义了主题类——也就是被观察者的接口，它的子类 ConcreteSubject的任何状态改变将会通知全部的观察者——ConcreteObserver。为了保持接口的一致性，这些观察者继承自相同的抽象类 Observer。
            抽象类在 Subject 中保存有观察者的列表——observers，并通过 attach 和 detach 方法来动态地添加或移出一个特定的观察者。这种采用订阅方法来添加的观察者并不知道还有其他的观察者，它仅仅能够接收被观察的主题对象的状态改变。在 notify 方法中，主题类将根据目前加入订阅的观察者列表Observers 来向每一个观察者发出状态改变的消息。
            ConcreteSubject 中的 setState()方法表明对象的状态发生了变化，该方法会调用 notify
方法对所有的观察者进行更新
        效果
            在 Observer 模式中，实现了具体对象和观察者之间的抽象耦合。虽然 Subject 了解目前有哪些观察者需要捕获自己状态的变化，但它并不了解这些观察者要做什么；而每一个观察者仅仅知道自己捕获到对象的变化，但并不清楚目前有多少观察者在观察对象的状态，也不需要通知其他的观察者。这样，动态的增加和移除观察者是非常简单的。
    Intercepting Filter 模式
        Intercepting Filter 模式，又称筛选器模式。
        意图解决的问题
            在使用 MVC 架构进行 Web 应用开发时，通常需要对来自于客户的请求进行一些预处理，如验证客户身份、验证请求来源、对请求解码等，然后再传递给控制器。如果把这些预处理都交由控制器来完成，将增加控制器的复杂度，而且难以维护和扩展。
        模式描述
            FilterManager--------------------------------->Target
                 |
                 |        
                 |      /-----------Filter1
                 |     /
                 |    /
            FilterChain-------------Filter2
                      \
                       \
                        \-----------Filter3
            FilterManager 负责调度整个 FilterChain，它将在请求到达 Target 前拦截请求，并传递给 FilterChain，由 FilterChain 中的过滤器依次进行预处理。直到请求经过最后一个过滤器后才完成了全部的预处理，然后由 FilterManger 把请求转发给实际的目标。
        效果
            使用 Intercepting Filter 模式使得预处理的逻辑和真正的处理逻辑分离，进行实际处理的 Target 只需要关心具体的逻辑，而同请求相关的预处理都放在 FilterManager 中进行。同时解除了这两类处理的耦合性，扩展、修改预处理过程变得容易，系统具有更好的维护性和扩展性。
        相关讨论
            虽然 Intercepting Filter 作为一种 J2EE 模式出现在有关文献中，但实际上有很广泛的应
用。不仅应用 J2EE 的开发可以使用该模式分离预处理过程，使用.Net 框架等其他的 Web 应用时也可以使用 Intercepting Filter。仔细观察 Intercepting Filter 模式就可以发现，它与 Decorator 模式有些类似，都是在真正的处理对象前增加一层扩展对象的操作。只不过实现起来有很大的差别。
        

























开发管理
    项目的范围、时间与成本
        项目范围管理
        项目成本管理
            资源计划编制
            成本估算
            成本预算
            成本控制
        项目时间管理
            活动定义是对 WBS 中规定的可交付成果或半成品的产生所必须进行的具体活动进行定义，并形成文档。
            活动排序是确定各活动之间的依赖关系，并形成文档。
            项目活动历时估算是根据项目范围和资源的相关信息为进度表设定历时输入的过程。
            制订进度计划要决定项目活动的开始和结束日期。若开始和结束日期是不现实的，项目就不可能按计划完成。进度计划、历时估算、成本估算等过程交织在一起，这些过程反复多次，最后才能确定项目进度计划。
            进度控制对造成进度变更的因素施加影响，以确保这些变更得到一致认可；确定进度变更是否已经发生；当变更发生时对实际变更进行管理。
    配置管理与文档管理
        软件配置管理SCM
            版本管理
            问题跟踪
            建立管理
    软件需求管理
        需求变更
        需求跟踪
    软件开发的质量与风险
    人力资源管理
    软件过程改进