博客园_柳晛

同事给的一个定时器方法。

2011-08-02T02:11:00Z

        private static void TimeEvent(object source, System.Timers.ElapsedEventArgs e)
        {
            int intHour = e.SignalTime.Hour;
            int intMinute = e.SignalTime.Minute;
            int intSecond = e.SignalTime.Second;
            int iHour = 10;
            int iMinute = 30;
            int iSecond = 00;
            // 设置　每秒钟的开始执行一次
            if (intSecond == iSecond)
            {
                Console.WriteLine("每秒钟的开始执行一次！");
            }
            // 设置　每个小时的３０分钟开始执行
            if (intMinute == iMinute && intSecond == iSecond)
            {
                Console.WriteLine("每个小时的３０分钟开始执行一次！");
            }

            // 设置　每天的１０：３０：００开始执行程序
            if (intHour == iHour && intMinute == iMinute && intSecond == iSecond)
            {
                Console.WriteLine("在每天１０点３０分开始执行！");
            }
        }

本文链接

360，你若称帝，谁能治你。

2010-10-29T05:49:00Z

迷迷糊糊，360和腾讯之间的争斗已经持续了十多天了，用户该用什么还是用什么，不可能因为谁多骂了谁几句就能让对方倒闭的，无非是看看笑话。

虽然用户不变，但这个战局发生了历史上最大的变化。

腾讯和360都有用户量，但腾讯偏多，而且腾讯比360有钱得很，真不是一个等级的。

但是360很有智慧，当年网民需要3721时，他就做3721；当网民不需要3721时，他就不做3721；雅虎中途打个小算盘没玩明白，收了3721网民就开始骂了，把老本都搭进去了；最终360还是顺应网民的意愿，做360灭3721；他每次都是顺应自然，站在网民这一方挖掘市场。

尤其近几年的免费杀毒软件之争，每次360都是蚂蚁吃大象，这次对腾讯360是主动出手的，所以我认为凭借他的智慧，小胜一筹没有问题。

可事情并没有我前几天想得那么简单。

回想这几年，腾讯靠着庞大客户群，抄袭互联网有钱途的经营模块，把它做得更人性化，遍地捡钱，强行抢占了人家的市场。

360这次出击，无形之间表达了360要对战腾讯的决心，以前被腾讯欺负过的公司原本是一盘散沙，落日余晖，被360这么一刺激，瞬间拧成一股绳。

想想看，腾讯模仿他们的东西，反过来说腾讯能做的，他们也都能做，如果他们能合纵联横，加上360的战略指导，将是多么强大。

可以说360的产品比较少，无法和腾讯抗衡，但是他号召起来的那些集团大军，完全可以再造一个腾讯，其用户量加起来也远远超过腾讯，若能联合，他们每一个团队都是自己领域当中最专业的，而腾讯只是一个山寨而已。

腾讯为什么粘性那么大，因为我们的朋友都用它，但是，最亲密的朋友、最重要的伙伴，不用腾讯也能联系，这表明腾讯并不是必要的。

只要腾讯近期灭不了360，360必将鼓舞反腾讯阵营复仇之心，同仇敌忾共同抗击。

360也有仇家，但是360市场小，这也是他的优势，他的仇家只有浏览器和杀毒软件两个领域，和腾讯的仇家相比，真不是一个等级的。

战国交戎变成楚汉相争，成也抄袭，败也抄袭，做老板的，四面触敌走投无路的时候，反思一下自己是不是当年做得太过份了，这些债积攒到一起的时候就该吃报应了。

寡助之至，亲戚畔之。多助之至，天下顺之。以天下之所顺，攻亲戚之所畔，故君子有不战，战必胜矣。

本文链接

系统架构师学习笔记_第二十一章_连载

2010-09-06T01:20:00Z

第二十一章案例研究

21.1 价值驱动的体系结构：连接产品策略与体系结构

系统的存在是为了为利益相关方创造价值。

价值模型、体系结构策略。

定义完善的价值模型可以为提高折中方案的质量提供指导。

21.1.1 价值模型概述

这些利益相关者在其他系统中扮演着重要角色。

这些其他系统也是为了为其利益相关者创造价值。

系统的这种递归特性是分析和了解价值流的一个关键。

价格模型核心的特征三种基本形式：

1、价值期望值：表示对某一特定功能的需求，内容（功能）、满意度（质量）。

2、反作用力：系统部署实际环境中，实现某种价值期望值的难度。

3、变革催化剂：环境中导致价值期望值发生变化的某种事件，或者是导致不同结果的限制因素。

反作用力和变革催化剂称为限制因素，把这三个统称为价值驱动因素。

传统方法，都是通过聚焦于系统进行交互的参与者的类型开始的。

有如下几个突出的局限性：

1、对参与者的行为模型关注较多，而对其中目标关注较少。

2、往往将参与者固定化分成几种角色，其中每个角色所在的个体在本质上都是相同的。

3、往往忽略限制因素之间的差别。

4、结果简单。要求得到满足或未得到满足，用例成功完成或未成功完成。

这种方法使用顺序推理和分类逻辑，因此易于教授和讲解，并能生成一组易于验证的结果。

效用曲线用于将每一个可选方案所得出的定量测量值映射到其对应值。然后，值级别用期望优先级加权，并进行叠加。

叠加值越高，方案越可取，该方法可能比较主观。

21.1.2 体系结构挑战

体系结构挑战是因为一个或多个限制因素使得满足一个或多个期望值变得更困难。

在任何环境中，识别体系结构挑战都涉及评估。

1、哪些限制因素影响一个或多个期望值？

2、如果知道了影响，它们满足期望值更容易（积极影响）还是更困难（消极影响）？

3、影响程度如何？简单的低、中、高三个等级通常就已经够用了。

制订系统的体系结构策略始于：

1、识别合适的价值背景并对其进行优先化。

2、在每一背景中定义效用曲线和优先化期望值。

3、识别和分析每一背景中的反作用力和变革催化剂。

4、检测限制因素使满足期望值变难的领域。

建议对以下几点进行权衡：

重要性。

程度。

后果：大概多少种方案可供选择？难度或有效性是否有很大差异？

隔离：对最现实的方案的隔离情况如何？影响越广，该因素的重要性就越高。

尽管体系结构样式和模式技术非常有用，不过在该领域，在问题和解决方案领域的身后，经验仍具有无法估量的价值。

21.1.3 结论

价值模型有助于了解和传达关于价值来源的重要信息。

如价值如何流动，期望值和外部因素存在的相似性和区别，要实现这些价值有哪些子集。

21.2 使用 RUP 和 UML 开发联邦企业体系结构框架

联邦企业体系结构框架（Federal Enterprise Architecture Framework，FEAF）

21.2.1 联邦企业体系结构框架概述

它把企业体系结构划分为 4部分：业务、数据、应用程序、技术。

FEAF 确定了开发和维护联邦企业体系结构所需的 8 中构件。这八种构件的分解进一步细化了 FEAF 的 4个层次。

第一层是联邦企业体系结构框架的最高层，它引入了开发和维护联邦企业体系结构所需要的 8种构件。

1、体系结构推动者（Architecture Drivers）

2、战略方向（Strategic Direction）

3、当前体系结构（Current Architecture）

4、目标体系结构（Target Architecture）

5、过程转换（Transitional Processes）

6、体系结构片段（Architectural Segments）

7、体系结构模型（Architectural Models）

8、标准（Standards）

第二层在更详细的层次上说明了联邦企业体系结构的业务和设计方面以及两者之间的关联。

业务体系结构和设计体系结构之间的关系是推/拉关系——业务推动设计以满足自身的需要，设计（既新开发的数据、应用程序和技术）通过支持业务运作来拉动业务到新的服务交付水平。

第三层展开了框架设计部分，显示三种设计体系结构：数据、应用程序、技术。

第四层（最详细视图）三种设计体系结构如何支持业务体系结构开始逐渐明确起来。

21.2.2 FEAF 矩阵概述

36个单元的矩阵，涵盖了企业中的谁（who）、什么（what）、何处（where）、何时（when）、为何（why）、如何（how）。

21.3 Web 服务在 HL7 上的应用——Web 服务基础实现框架

Health Level Seven（HL7）是美国国家标准化协会（ANSI）认可的标准化开发组织中的一个，它正在全世界保健行业里运行着（Level Seven 引用了开放系统互联模型 OSI 的最高层——应用层）。

21.3.1 HL7 模型概念

1、参考信息模型

2、消息结构

所有的 HL7 消息都被放在 Transmission Wrapper，Wrapper 的目的是支持应用软件之间消息的传输（和确认）。

3、交互

4、应用程序角色

一个角色就体现了应用程序的职责。

5、Storyboard

一个 Storyboard 是由一小段记叙了它本身的目的及交互作用图表的描述所组成的（在应用层）应用程序角色间相互作用的级数。

21.3.3 开发 HL7 Web 服务适配器

为了高效地开发 HL7 Web 服务适配器，需要按如下步骤来做。

1、消息和数据类型的设计。

2、适配器模式的选择。

3、HL7 Web 服务契约开发。

4、生产 Web服务 Stub 和代理的实现。

5、开发适配器业务逻辑。

本文链接

系统架构师学习笔记_第二十章_连载

2010-09-05T07:03:00Z

第二十章面向服务的架构

服务是一个由服务提供者提供的，用于满足使用者请求的业务单元。

在 SOA中，服务的概念有了延伸，泛指系统对外提供的功能集。

20.1 SOA 的相关概念

20.1.1 SOA 的定义

面向服务的体系结构（Service-Oriented Architecture，SOA）

从应用的角度定义：是一种应用框架，着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。

从软件的基本原理定义：是一个组件模型，将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

20.1.2 业务流程与 BPEL

由于业务流程来源于现实世界，传统上是通过复杂的语言进行描述。

BPEL（Bussess Process Execution Language For Web Services）面向Web服务的业务流程执行语言。

提供了一种相对简单易懂的方法，可将多个Web服务组合到一个新的服务服务（称作业务流程）中。

将现有的 Web Services 按照要求的业务流程整理成为一个新的 Web Services，形成一个从外界看来和单个 Service 一样的 Service。

20.2 SOA 的发展历史

为了能够将公司的业务打包成独立的、具有很强伸缩性的基于因特网的服务，人们提出了 Web服务的概念，这可以说是 SOA 的起源。

1、萌芽阶段

以 XML 技术为标志，XML 的出现无疑为 SOA 的兴起奠定了稳固的基石。

2、标准化阶段

2000年以后，出现了三个著名的 Web 服务标准和规范：简单对象访问协议（Simple Object Access Protocal，SOAP）、Web 服务描述语言（Web Services Descriptin Language，WSDL）、通用服务发现和集成协议（Universal Discovery Description and Integration，UDDI）。

Web 服务也是因特网 Web 2.0 时代的一项重要特征。

3、成熟阶段

从2005年开始，体现在三个重量级规范上：SCA/SDO/WS-Policy，标志着 SOA进入了实施阶段。

美国实现 SOA 架构的关键任务是：对已有系统中的功能进行提取和包装，形成标准的“服务”。

大量“服务”需要全新构造才是中国 SOA 的主要任务。

20.3 SOA 的参考架构

以服务为中心的企业集成采用“关注分离（Separation of Concern）”的方法规划企业集成中的各种架构元素。

从服务为中心的角度来看，企业集成的架构分为 6大类：

1、业务逻辑服务（Business Logic Service）

2、控制服务（Control Service）

3、连接服务（Connectivity Service）

4、业务创新和优化服务（Business Innovation and Optimization Service）

5、开发服务（Development Service）

6、IT 服务管理（IT Service Management）

1、连接服务——企业服务总线（Enterprise Service Bus，ESB）

采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构。

2、业务逻辑服务

1. 整合已有应用——应用和信息访问服务

2. 整合新开发的应用——业务应用服务

3. 整合客户和业务伙伴（B2C/B2B）——伙伴服务

3、控制服务

1. 数据整合——信息服务

2. 流程整合——流程服务

3. 用户访问整合——交互服务

4、开发支持

企业集成的开发工具需要有标准的工具框架，这些工具能够以即插即用方式支持来自多家厂商的开发工具，支持整个软件开发周期，以提高开发过程中各种角色的生产力。

5、业务创新和优化

业务创新和优化服务以业务性能管理（Business Process Management，BPM）技术为核心提供业务事件发布、收集、关键业务指标监控能力。

业务创新和优化服务与开发服务是紧密相连的。

6、管理支持

20.4 SOA 主要技术和标准

Web 服务作为实现 SOA 中服务的最主要手段。

20.4.1 UDDI 协议

UDDI（统一描述、发现和集成协议）计划是一个广泛的、开放的行业计划，它使得商业实体能够彼此发现；定义它们怎样在 Internet 上互相作用，并在一个全球的注册体系架构中共享信息。

UDDI 规范利用了 W3C 和 Internet 工程任务组织的很多标准作为其实现基础，如 XML、HTTP、DNS 等协议。

20.4.2 WSDL 规范

WSDL（Web Services Description Language，Web 服务描述语言），用来描述 Web 服务和说明如何与 Web服务通信的 XML 语言。

通过 WSDL，可描述的三个基本属性：

1、服务做些什么

2、如何访问服务

3、服务位于何处

WSDL 文档被分为两种类型：服务接口（Service Interface）和服务实现（Service Implementations）

20.4.3 SOAP 协议

SOAP 是在分散或分布式的环境中交换信息的简单的协议，是一个基于 XML 的协议。

20.5 SOA 的特性

20.5.1 文档标准化

20.5.2 通信协议标准

20.5.3 应用程序统一登记与集成

20.5.4 服务品质（Quality of Service，QoS）

关键元素有：安全需求（例如认证和授权）、可靠通信。

1、可靠性

仅且仅仅传送一次（Once-and-only-once Delivery）

最多传送一次（At-most-once Delivery）

重复消息过滤（Duplicate Message Elimination）

保证消息传送（Guaranteed Message Delivery）

2、安全性

认证交换、消息完整性、消息保密性，它借助现有的安全标准。

3、策略

服务提供者有时候会要求服务消费者与某种策略通信。

这些要求被定义为策略断言（Policy Assertions），一项策略可能会包含多个断言。

4、控制

整合应用意味着像异步通信、并行处理、数据转换，以及校正等进程请求必须被标准化。

5、管理

随着企业服务端增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有，运行在多种环境下的服务的管理系统就显得尤为重要。

20.6 SOA 的作用

在一个企业内部，可能存在不同的应用系统，由于开发的时间不同，开发工具不同，这些已有应用系统是孤立的，也就是我们常说的“信息孤岛”。

从头建立一个新的基础环境是不可能的。

SOA 凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要。

在 SOA 得以普及之前，解决企业内部信息系统“信息孤岛”的问题通常采用 EAI（企业应用整合）的方式。

EAI Server 就好像一个“翻译”，让每两个应用之间可以对话，会带来 EAI Server 呈几何倍数的增长。

SOA 对实现企业资源共享，打破“信息孤岛”的步骤如下：

1、把应用和资源转换成服务。

2、把这些服务变成标准的服务，形成资源的共享。

SOA 不仅仅是一个技术，而是一个软件架构。

20.7 SOA 设计原则

SOA 架构中，继承了来自对象和组件设计的各种原则，如封装、自我包含等。保证服务的灵活性、松散耦合、重用能力的设计原则。

常见和讨论的设计原则如下：

1、无状态。以避免服务请求着依赖与服务提供者的状态。

2、单一实例。避免功能冗余。

3、明确定义的接口。服务的接口由 WSDL 定义，用于指明服务的公共接口与其内部专用实现之间的界限。

XML 模式（Schema）用于定义所交换的消息格式（即服务的公共数据）。服务定义必须长时间稳定，一旦发布，不能随意更改，服务的定义应尽可能明确，减少使用者的不适当使用。

4、自动包含和模块化。封装了那些业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的。

5、粗粒度。服务数量不应该太大。

6、服务之间的松耦合性。其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。

7、重用能力。

8、互操作性、兼容和策略声明。

20.8 SOA 的设计模式

20.8.1 服务注册表模式

服务注册表（Service Registry）主要在 SOA 设计时段使用，虽然它们常常也具有运行时段的功能。

注册表支持驱动 SOA 治理的服务合同、策略、元数据的开发、发布、管理。

因此，他们提供一个主控制点，或者称为策略执行点（Policy Enforcement Point，PEP）。在这个点上，服务可以在 SOA 中注册和发现。

注册表可以包括有关服务和相关软件组件的配置、遵从性和约束配置文件。任何帮助注册、发现和检索服务合同、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。

主要的服务注册厂商：

一个阵营是提供服务、策略、元数据注册表及信息库的纯 SOA 厂商。

另一个阵营是 SOA 平台厂商，这些厂商将注册表作为集成产品套件的一个组件。

1、注册服务：应用开发者，也叫服务提供者，向注册表公布他们的功能。

2、服务位置：也就是服务应用开发者，帮助他们查询注册服务，寻找符合自身要求的服务。

3、服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发代码将与注册的服务绑定、调用注册的服务以及与他们实现互动。

20.8.2 企业服务总线模式

采用点对点的集成方式存在着复杂度高，可管理性差，复用度差，系统脆弱等问题。

企业服务总线（Enterprise Service Bus，ESB）提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入”到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互。

支持异构环境中的服务以基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。

本质上是以中间件形式支持服务单元之间进行交互的软件平台。

这种交互过程不再是点对点的直接交互模式，而是由事件驱动的消息交互模式。

ESB最大限度上解耦了组件之间的依赖关系，降低了软件系统互联的复杂性。

ESB 以中间件的方式，提供服务容错、负载均衡、QoS保障和可管理功能。

ESB 的核心功能如下：

1、提供位置透明性的消息路由和寻址服务。

2、提供服务注册和命名的管理功能。

3、支持多种消息传递泛型（如响应/请求、发布/订阅等）。

4、支持多种可以广泛使用的传输协议。

5、支持多种数据格式及其相互转换。

6、提供日志和监控功能。

由于采用了基于标准的互联技术，ESP 使得企业内部以及外部系统之间可以很容易地进行异步或同步交互。具有很强的灵活性和扩展性。

服务总线层为整个 EAI 应用环境提供底层支持。

20.9 构建 SOA 架构时应该注意的问题

20.9.1 原有系统架构中的集成需求

一定要注意对原有系统架构中集成需求进行细致的分析和整理。

可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发的成本和风险。

因此，当SOA 架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统。

当 SOA 架构师分析原有系统中的集成需求时，不应该只限定为基于组件构建的已有应用程序的集成，必须考虑一些更加具体的集成的类型，主要包括：

应用程序集成的需求；终端用户界面集成的需求；流程集成的需求；已有系统信息集成的需求。

因而，SOA 架构师在着手设计新的体系结构框架时，必须要全面地考虑所有可能的集成需求。

20.9.2 服务粒度的控制以及无状态服务的设计

构建一个企业级的 SOA 系统架构时，关于系统中最重要的元素，首先是：服务粒度的控制；其次是：无状态服务的设计。

1、服务粒度的控制

通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。

粗粒度服务接口保证了服务请求着将以一致的方式使用系统中所暴露出的服务。

2、无状态服务的设计

SOA 系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态。

当负载增加时，可以向群集中增加机器。（无状态就可以热插拔）

20.10 SOA 实施的过程

20.10.1 选择 SOA 解决方案

选择最佳的解决方案，是保证 SOA 实施成功的前提条件。

总体来说，必须从以下三个方面进行选择：

1、尽量选择能进行全面规划的方案

既需要选择适当的工具，还需要有专业的技术人才。

2、选择时充分考虑企业自身的需求

必须认识到，用于构建 SOA 项目的前期投资将产生巨大效益。

3、从平台、实施等技术方面进行考察

首先要考虑的是平台的开放性和对标准的支持。

以往的成功经验总结有6个方面：业务战略和流程、基础架构、构件模块、项目和应用、成本和效益、规划和管理。

20.10.2 业务流程分析

1、建立服务模型

1. 自顶向下分解法

自上而下的领域分解方式从业务着手进行分析，选择端到端的业务流程进行逐层分解至业务活动，并对其间涉及的业务活动和业务对象进行变化分析。

2. 业务目标分析法

通过关键性能指标分析来验证已有业务候选者以及发现遗漏的服务候选者，这可以叫做“目标服务建模（Goal Service Modeling）”。

它的思想是：从企业的业务目标触发，目标分解为子目标，子目标再分派给相关的服务来实现，这样就形成了一颗“目标服务树”。

3. 自底向上分析法

利用已有资产来实现服务，已有资产包括已有系统、套装或定制应用、行业规范或业务模型等。

这也叫做“遗留资产分析”，可以方便地发现哪些在不同的系统中被重复实现的功能模块以及可以复用的功能模块。

2、建立业务流程

1. 建立业务对象（Business Object，BO）是对数据进行检索和处理的组件，是简单的真实世界的软件抽象。通常位于中间层或业务逻辑层。

业务对象的分类如下：

a. 实体业务对象。表达了一个人、地点、事物或者概念。

b. 过程业务对象。

c. 事件业务对象。

2. 建立服务接口

服务之间的交换可以为有状态、也可以为无状态。

在构建 SOA 的过程中，将无状态接口视为最好的选择，可以方便地供很多服务者应用程序重用。

3. 建立业务流程

流程是指定的活动顺序，包含明确确定的用于提供业务值的输入和输出。

对流程进行建模应当确保捕获的相关信息的一致性及完整性。

本文链接

系统架构师学习笔记_第十九章_连载

2010-09-03T13:27:00Z

第十九章嵌入式系统设计

19.1 嵌入式系统

19.1.1 嵌入式系统的概念

以应用为中心，以计算机技术为基础，可以适应不同应用对功能、可靠性、成本、体积、功耗等方面的要求，集可配置可裁剪的软件、硬件于一体的专用计算机系统。

存储方案的选择就是在嵌入式Linux系统的可靠性、尺寸、功能、成本之间寻求最佳的平衡点。

19.1.3 嵌入式操作系统

嵌入式操作系统主要由应用程序接口、设备驱动和操作系统内核等几个方面组成。

嵌入式操作系统是一个按时序方式调度执行、管理系统资源并为应用代码提供服务的基础软件。

每个嵌入式操作系统都有一个内核，大多数内核都包含以下三个公共部件：调度器、内核对象、内核服务。

大多数内核支持两种普遍的调度算法：基于优先级的抢占调度、时间轮转调度算法。

19.1.5 嵌入式数据库管理

嵌入式数据库也称为移动数据库或嵌入式移动数据库，主要是解决移动计算机环境下数据的管理问题，移动数据库是移动计算机环境中的分布式数据库。

实际应用中必须解决好数据的一致性（复制性）、高效的事务处理和数据的安全性等问题。

19.1.6 嵌入式网络及其他

现场总线主要有总线型、星型两种拓扑结构。

家庭信息网的拓扑结构有总线型、星型等。

常见的无线网络标准以 IEEE 802.11x 系列为主。

19.2 嵌入式系统的设计

19.2.1 嵌入式系统分析与设计

嵌入式系统的核心技术有三种：处理器技术、IC技术、设计/验证技术。

单用途处理器是设计用于执行特定程序的数字电路，也指协处理器、加速器、外设等。

项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试、运行。

19.2.2 嵌入式软件设计模型

1、状态机模型

有限状态机（FSM）是一种描述系统状态及其状态转换的节点网，包括节点和边，节点表示状态，边表示状态之间的转换关系。

缺乏并发和层次化支持。

2、数据流模型

数据流图允许系统作为操作网进行建模，特别适合于对实现进行分区的系统模型。

布尔数据流、层次化流图、Petri网。

3、并发进程模型

并发进程包括 CSP 与 CCS 等。

CSP模型将输入、输出操作列为程序语言的基本要素，而将实现顺序进程间通信的并行组合作为基本的程序控制结构。

一个程序，就是一组进程，它们通过一个通信网络彼此通信。

面向对象的基本结构可用6个术语来描述，对象、类、属性、消息、操作、关系。

19.2.3 嵌入式系统软件开发环境

交叉平台开发方法（Cross Platform Development），即软件在一个通用平台上开发，而在另一个嵌入式目标平台上运行。

通用平台通常叫做宿主机系统，被开发的嵌入式系统称为目标机系统。

执行环境和开发环境一致时的开发过程称为本地开发（Native Delelopment）。

本文链接

系统架构师学习笔记_第十八章_连载

2010-09-03T11:00:00Z

第十八章面向方面的编程

AOP（Aspect Oriented Programing）面向方面的编程。

18.1 方面编程的概念

18.1.1 AOP 产生的背景

1、面向过程编程面临的问题

面向过程编程是一种自顶向下的编程方法，其实质是对软件进行功能性分解。

2、传统面向对象编程面临的问题

对象模型可以很好地映射到实际领域。

完成某个特定需求的代码分散到各个类中，很难把它们全部找到，这就给程序的健壮性带来了隐患。

将传统的按功能或按对象划分程序模块的方法转化为按系统特征划分程序模块，这就是 AOP的基本思想。

18.1.2 面向方面的编程

某些操作较难实现模块化，称涉及到这些操作的代码是分散的。

方面的定义：一个设计来用于捕捉应用程序横切面功能的程序单位。

方面与类的不同在于它实现了横切程序的功能。

程序中包括类和方面意味着模块性可以在两个因素上实现：类实现基本的功能性（这个因素叫做结构性）；方面实现横切的功能性（这个因素叫做可操作性）。

方面由两个部分组成：切入点和通知代码。

通知代码包括要执行的代码，切入点定义了程序重要执行的代码处的点。

一个服务可以在一个程序中是非功能性的，但在另一个程序中却是功能性的。

18.1.3 AOP 技术

AOP可以说是OOP（Object-Oriented Programming）面向对象编程的补充和完善。

它利用一种称为“横切”的技术，剖开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其命名为Aspect，即方面。

实现 AOP 采用动态代理技术/采用静态织入的方式。

18.1.4 AOP 特性

改善了软件的可扩展性、重用性、易理解性、易维护性。

通过将实现基本功能的组件和特定于应用的系统特性分离，使得组件（包括类或者函数）的重用性得到提高。

本文链接

系统架构师学习笔记_第十七章_连载

2010-09-02T15:46:00Z

第十七章企业集成架构设计

企业集成平台的核心是企业集成架构，包括信息、过程、应用集成的架构。

17.1 企业集成平台

企业集成平台（Enterprise Integration Platform，EIP）目的是：

能够根据业务模型的变化快速地进行信息系统的配置和调整，保证不同系统、应用、服务、操作人员之间顺畅地互操作，进而提高企业适应市场变化的能力，使企业能够在复杂多变的市场环境中生存。

良好的软件支持工具可以帮助企业加快实现企业系统集成，降低实现企业内部的信息孤岛集成的复杂度。

17.1.1 企业集成平台的概念

早起比较简单的集成方式是通过在不同的应用之间开发一对一的专用接口来实现应用之间的数据集成，即采用点到点的集成方式。

优点是比较直观。

问题：工作量大；集成费用高，系统升级和扩展困难；不易于标准化，接口数量过多，给系统管理造成比较大的困难。

为了克服点到点集成方式给企业应用系统集成和维护管理带来的困难，采用集成平台。

企业集成平台是一个支持复杂信息环境下信息系统开发、集成、协同运行的软件支撑环境。

可以使分散的信息系统通过一个单一的接口，可以管理、可重复的方式实现单点集成，使企业内的所有应用都可以通过集成平台进行通信和数据交换。

集成平台是支持企业集成的支持环境，包括硬件、软件、软件工具、系统，基本功能主要如下：

1、通信服务

提供分布环境下透明的同步/异步通信服务功能。

2、信息集成服务

使集成平台上运行的应用、服务、用户端能够以一致的语义和接口实现对数据的访问控制。

3、应用集成服务

通过高层应用编程接口来实现对应应用程序的访问，在无需对原有系统进行修改（不会影响原有系统的功能）的情况下，只要在原有系统的基础上加上相应的访问接口就可以将现有的、用不同的技术实现的系统互联起来。

4、二次开发工具

一组帮助用户开发特定应用程序的支持工具，其目的是简化用户在企业集成平台实施过程中的开发工作。

5、平台运行管理工具

集成平台的运行管理和控制模块。

17.1.2 集成平台的标准化

采用标准化的技术也是提高集成平台系统开放性和软件模块可重用性的重要方法。

标准化内容涉及通信协议、中间件、企业建模、工作流管理系统、Internet环境下的数据交换、产品数据标准和应用系统集成标准等。

17.1.3 实现技术的发展趋势

1、集成的技术实现从2层到n层过度

无论是在服务器端，还是在客户端，由于业务逻辑和应用表示逻辑的紧密捆绑，对系统的升级和扩展都带来了比较大的困难。

将业务过程逻辑、业务表示逻辑进行分离，将每层的功能集中在一个特定的角色上，提高集成平台和集成系统的柔性。

2、集成支持的方式从面向信息集成扩充到面向过程集成、服务集成

面向信息的集成主要应用于企业内的数据库和数据源上，其具体的实现方法主要有数据复制、数据捆绑、基于接口的信息集成三种方式。

1. 面向过程的集成：通过工作流引擎对企业内部流程模型的执行来实现业务应用数据或信息在不同应用、子过程、执行任务的人员之间流动。

对业务过程逻辑和应用逻辑进行分离，实现过程建模和数据、功能分离，保持具体功能单元不变的情况下，通过修改过程模型来改变系统功能。

2.面向服务的集成。

服务提供者将应用作为服务部署在web上，通过使用web服务描述语言来描述web服务提供的功能，并通过统一的服务发布与发现协议将其注册到UDDI中心。

只要在原有系统的基础上增加一个对它们进行访问的SOAP接口，就可以完成原有系统到集成平台的集成。

将以前主要在企业内部网络基础上实施的集成扩展到了面向开放网络环境下的集成，从而大大扩展了集成的范围。

具有良好的柔性和开放性，牺牲了性能和网络流量。

3、集成规范的标准化程度不断提高

从数据描述的角度来看，逐渐过渡到具有自描述功能的基于 XML语言的数据表达与存储。

从应用间集成接口的实现与接口表现形式看，发展到更通用的基于 XML语言的web服务几口定义语言（WSDL）的集成接口描述。

从业务过程定义方面来看，如何利用web服务集成架构实现过程集成的基于 XML语言的商业流程模型描述语言。

4、所支持的集成耦合度及集成的粒度的变化

耦合度不断降低，集成范围不断扩大，集成粒度不断缩小。

17.1.4 集成平台的发展趋势

从功能上可以将其划分为企业应用集成和业务到业务的集成（B2B）两种。

其中，EAI主要侧重于企业内部的纵向集成，B2B侧重于支持企业间业务往来的横向集成。

17.2 企业集成平台的实现

17.2.1 数据集成

构建企业集成平台的首要目的是实现数据集成，提供具有完整性、一致性、安全性的数据访问、信息查询、决策支持服务。

具体包括：共享信息管理、共享模型管理、数据操作管理三部分。

共享模型管理则提供数据资源配置管理、集成资源关系管理、资源运行生命周期管理及相应的业务数据协同监控管理等功能。

体系结构与标准化（规范化）程度对数据集成的水平有非常大的影响。

数据集成主要有以下三种模式：数据联邦、数据复制、基于接口的数据集成。

17.2.2 应用集成

功能之间的相互调用和互操作，需要在数据集成的基础上完成。

实现异构应用系统之间语用层次上的互操作。

应用集成最初主要采用点对点的紧耦合方式，缺乏必要的柔性，组件化的系统实现及松耦合的应用集成方式逐渐成为构建企业业务处理系统的主流。

应用集成模式包括：集成适配器、集成信使、集成面板、集成代理 4种。

1、适配器集成模式

通过适配器完成不同的系统间数据格式及访问方式的转换与映射。

2、信使集成模式

系统之间的通信和数据交换通过信使（消息代理）来实现，大大减少了接口数量，将应用之间的交互对通信服务能力的依赖程度降到最低。

3、面板集成模式

集成面板可以为一对多、多对一、多对多等多种应用提供集成接口，为客户端应用与调用服务端应用提供了一种简化的公共接口。

4、代理集成模式

面板集成模式实现了服务器应用交互逻辑的分离。

在代理集成模式中，由于不存在很明显的客户端应用和服务端应用的划分，它仅需要将待集成的应用程序分离出来，并对应用间的交互逻辑进行封装，进而由集成代理来引导多个应用之间的交互。

17.2.3 企业集成

企业应用软件系统从功能逻辑上可以分为：表示、业务逻辑、数据三个层次。

按照这些逻辑功能层次间是否分离和分离的程度，在软件系统具体实现上可以大致分为如下4类：

1、单层结构系统。

2、两层结构系统。

表示层与业务层（胖客户）紧密地耦合在一起，或者将业务逻辑和数据库层紧密地耦合在一起（只将表示层分离出来为瘦客户）。

3、三层结构系统。

表示、业务逻辑、数据三个层次分成独立的模块实现。

各层可以并行开发，各层也可以选择各自最适合的开发环境和编程语言。

4、n层结构系统。

目的是提高系统不同业务功能模块的独立性，可以使系统具有最好的柔性及可扩展能力。

根据企业集成平台功能的支持范围，可以将其分为侧重与支持企业内部集成化运行的 EAI 和侧重于支持企业间业务集成的 B2B。一般来说，EAI 是 B2B 的基础。

从企业集成运行的实现策略上看，EAI主要有如下三种实现模式：

1、前端集成模式

是指 EAI侧重于业务应用系统表示层的集成，单一的用户入口实现多个应用事务的运作。

2、后端集成模式

主要侧重于应用系统数据层面的集成，就像一个方便多个应用系统之间数据自动交互的数据管道。

基于 EAI 服务器提供的存储——转发机制可以方便地实现对合作伙伴企业之间大量业务数据交换（主要指B2B集成）的支持。

3、混合集成模式

是前端集成模式和后端集成模式的组合，主要应用于既需要响应大量服务请求、又需要维护多个数据源的完整性和一致性的情况。

17.3 企业集成的关键应用技术

17.3.1 数据交换格式

企业业务数据可以分为结构化数据（表单）和非结构化数据（文档），一般存储在不同的数据库或文档管理系统中。

不同的应用系统、数据库所处理的文档和数据格式有很大差别，建立各个应用都可以识别的访问通用数据模型及表示规范，是实现不同应用系统之间交互和互操作的最基本方法。

几种数据交换格式如下：

1、EDI（Electronic Data Interchange）电子数据交换

将贸易、运输、保险、银行、海关等行业的信息，用一种国际的公认的标准格式，通过计算机通信网络，供有关部门、公司、企业之间进行数据交换与处理，并完成以贸易为中心的全部业务过程。

目的是将功效上的纸质介质文件等同的电子表单统一的格式进行表示。

按照 UN/EDIFACT 标准，贸易伙伴之间一次交换的内容称为一个交换，交换由交换头/尾、功能组头/尾、报文头/尾、数据段（或断组）和数据元（简单数据元和复合数据元）等组成。

数据段（或段组）、数据元等在文本中都被称为报文项。

2、XML

XML 是国际组织 W3C 定制的一个面向各类信息的数据存储工具和可配置载体的开放式标准。

目的是为了更好地适应web应用的需求，解决HTML在表达能力、扩展性、交互性等方面的缺陷。

具有愈发清晰简单、结构无歧义等优点。

利用一套定义标记的规则将文件的内容和外观进行分离，实现了XML文档的可延伸性及自我描述特性。

它本身并不是一种标记语言，而是一种创建、设计、使用标记语言的根规则集，是一种创建标记语言（如HTML）的元语言。

3、STEP标准（Standard for the Exchange of Product Model Data）是一种描述如何表达和交换数字化产品信息的ISO标准（ISO010303）

目的是提供一种不依赖具体系统的中性模型，并将其用来描述整个生命周期内的产品数据。

4、PDML 是在STEP和XML基础上实现不同系统间产品数据交换和集成的一种新模式。

PDML中主要应用了STEP的集成资源和Express数据规范语言两个部分。

与特定领域词汇表（或数据字典）相应的组件被称为应用事物集（Application Service Set，ATS），与跨多个应用领域的通用词汇表相应的组件被称为集成方案。

PDML 由 7个应用事物集、一个集成大纲、应用事物集和集成大纲间的映射规范、PDML工具集 4部分组成。

17.3.2 分布式应用集成基础框架

大规模计算机网络的重要特性——异构性。

在面向对象技术和分布式计算基础上产生的分布式对象计算（Distributed Object Computing，DOC）。

比较有影响的分布式软件对象（组件）标准有下面4种：

1、CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）解决分布式处理环境中硬件和软件系统的互联而提出的一种标准的面向对象应用程序体系规范。

对象管理参考模型（Object Management Architecture，OMA）把软件作为对象，并通过对象请求代理与其他对象进行通信。

核心是对象请求代理（Object Request Broker，ORB），它支持对象服务、通用设施、领域接口、应用接口之间的交互和通信。

服务完成后又把执行结果或异常情况返回给请求者。

2、COM+

COM组件标准的基础是COM核心，规定了组件对象与客户通过二进制接口标准进行交互的原则。

COM主要由COM接口、COM对象、COM服务器、类工厂和类型库等组成。

每个接口有一个唯一标识（UUID），对COM对象的调用是通过一个指向其接口的指针实现的。

客户对组建对象功能的调用接口一般采用COM IDL来描述。

两类服务器，进程内部服务器、进程外部服务器。

进程内服务器即本机上的DLL，进程外服务器分为两类：一是本机上的exe可执行程序，而是远程机上的dll或exe程序。

进程外的对象必须先调用服务控制机制提供的代理，代理生成服务对象的远程过程调用（Remote Process Call，RPC）。

另外，COM组件标准还包括结构化存储、统一数据传输和智能命名等。

3、J2EE

J2EE很好地融合了Internet技术，有利于企业建立基于web、具有n层结构的分布式应用。

J2EE的基础是核心Java平台或Java2平台的标准版，J2EE将J2SE集成到自己的体系结构中。

各种组件可以通过J2EE配置工具将其部署到相应的J2EE容器中，客户端对各种组件的访问及各种组件之间的调用都通过容器及服务器来完成。

4、Web Service

Web Service（Web 服务）是指服务提供者将应用作为服务部署在web上，通过使用web服务描述语言来描述特定web服务提供的功能。

web服务可以看成是现有应用面向Internet的一个延伸。

目前支持web服务的技术标准主要有：

用于进行数据交换和表达的元语言标准XML，

UDDI（Universal Description，Discovery & Integration），UDDI用于web服务注册和服务查找，

WSDL用于描述web服务的接口和操作功能，

SOAP（Simple Object Access Protocol）为建立web服务和服务请求之间的通信提供支持。

17.4 面向整体解决方案的企业模型

17.4.1 企业模型在整体解决方案中的作用

1、企业模型可以为信息化整体解决方案提供对企业公共一致的、规范的表达和描述。

2、建模和基于模型的分析是企业信息化工作的入手点和建立有效的实施途径的基础。

3、建模可以对信息系统规划方案进行预评估。

4、基于模型的工作流执行可以导航和监控各信息系统之间及信息系统外界的交互。

17.4.2 整体解决方案中的企业模型重用

不同的企业虽然在生产经营诸多方面都有其特殊性，但是他们都是企业系统的实例，具有企业最本质的行为和特征。

可以将构成企业所有要素（无论是物质实体还是抽象过程）分成三类：

一类是最通用的，适用于任何企业。

二类是在一定范围内通用。

三类是某个企业专有的。

通用层、部分通用层、专用层。

企业模型可以采用从零开始的方法建立，周长和建模质量低。

因此，基于参考模型建立企业具体的专用模型是较好的方法。

包括两个阶段：参考模型的选择、参考模型的实例化。

参考模型的选择具体包括以下几个步骤：

1、确定企业建模的目的和基本需求。

2、划定企业建模的范围。

3、提出候选参考模型。

4、确定最终使用的参考模型。

实例化过程在具体操作中可以采用的方法如下：

1、继承。

2、裁剪。

3、细化。

4、扩充。

5、修改。

17.4.3 整体解决方案中企业模型演化

信息系统实施的生命周期可以分为需求分析阶段、系统设计阶段、系统实施阶段、运行维护阶段。

1、需求分析阶段

通过对用户需求的抽象形成需求分析模型，以作为下一个阶段的输入。

需求分析模型应该包含有较高层次上的企业业务流程、资源分配、组织结构和产品结构等信息。

最后还需要确定系统的总体目标和评价标准。

2、系统设计阶段

从未来的信息系统相关的业务模型中抽取出功能模型和信息模型，用它们来设计和构造信息系统。

3、系统实施阶段

实现了企业模型从设计模型向可执行模型的转化。

通过定义具体的操作者、执行器、资源实体、组织单元、应用软件等。

4、运行维护阶段

通过文档管理、版本控制等方法实现对系统的有效管理和监控，并通过集成需求管理软件工具来对运行过程中企业不断提出的新需求进行记录和管理，所积累的需求和文档是下一个生命周期的输入。

一个系统实施后在运行维护阶段搜集的问题和需求又会启动一个新的生命周期。

这个不断循环的生命周期以螺旋式上升的形式实现企业相关状态及行为的改进与发展。

17.4.4 模型驱动的企业集成系统演化

由于这种实施是根据企业当前的市场策略、业务过程规划和当前的信息技术现状进行的，它只能够在当前的企业和市场状态下，通过信息技术支持企业实现其竞争优势。

本文链接

系统架构师学习笔记_第十六章_连载

2010-08-31T16:09:00Z

第十六章层次式架构设计

16.1 体系结构设计

整个软件系统结构的设计与规格说明比算法选择和计算问题的数据结构更为重要。

因此，代码级别的软件复用已经远远不能满足大型软件开发的需求。

软件体系结构可定义为：为软件系统提供了结构、行为、属性的高级抽象，由构成系统的元素描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。

不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理，是构建于软件系统之上的系统级复用。

软件体系结构贯穿于软件研发的整个生命周期，具有重要的影响，主要从以下三个方面进行考察：

1、利益相关人员之间的交流。

2、系统设计的前期决策。

3、可传递的系统级抽象。这种模型可以在多个系统之间传递，应用到具有相似质量属性和功能需求的系统中，并能够促进大规模软件的系统级复用。

分层设计是一种常见的架构设计方法，能有效地使设计简化，清晰，便于提高复用能力和产品维护能力。

16.2 表现层框架设计

16.2.1 使用MVC模式设计表现层

MVC强制性地把输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了控制器、模型、视图三个核心模块。

1、控制器（Conrtrtollert）：接受用户的输入并调用模型和视图去完成用户的需求。是用户界面与Model的接口。

2、模型（Model）：业务数据和业务逻辑，为多个视图提供数据。

3、视图（View）：用户看到并与之交互的界面，不进行任何实际的业务处理，能接受模型发出的数据更新事件。

使用MVC模式来设计表现层，可以有以下优点：

1、允许多种用户界面的扩展，视图与模型没有必然的联系。

2、易于扩展。

3、功能强大的用户界面。

将业务处理与显示分离，增加了应用的可拓展性、强壮性、灵活性。

目前比较先进的web应用框架都是基于MVC设计模式的。

16.2.2 使用 XML 设计表现层，统一 Web Form 与 Windows Form 的外观

XML 标记用于定义数据本身的结构和数据类型，很少采用 XML 作为表现技术。

GUI 主要是由 GUI 空间组成，包含位置信息、类型、绑定事件等。

可以被描述成一个 XML 节点，而控件的那些相关属性都可以描述成这个 XML 节点的 Attribute。

由于 XML 本身就是一种树形结构描述语言，所以可以很好地支持控件之间的层次结构。

在调用显示 GUI 时，不是直接的调用特定的表现技术的 API，而是装载 GUI 对应的 XML 配置文件，然后根据特定的表现技术的解析器解析 XML，得到 GUI 视图实例对象。

16.2.3 表现层中的 UIP设计思想

UIP（User Interface Process Application Block）提供了一个扩展的框架，用于简化用户界面与商业逻辑代码的分离的方法。

将概念上的用户交互流程从实现或者涉及的设备上分离出来，保持内部的事务关联状态。

16.2.4 表现层动态生成设计思想

基于 XML 界面管理技术，包括界面配置、界面动态生成、界面定制三部分。

基于 XML 的界面管理技术实现了用户界面描述信息与功能实现代码的分离，可针对不同用户需求进行界面配置和定制，只需对 XML 文件稍加修改，即可实现系统的移植。

16.3 中间层架构设计

16.3.1 业务逻辑层组件设计

业务逻辑组件分为接口、实现类两个部分。

通常按模块来设计业务逻辑组件，每个模块设计一个业务逻辑组件，控制器无需与具体的业务逻辑组件耦合，而是面向接口编程。

16.3.2 业务逻辑层工作流设计

工作流管理联盟（Workflow Management Coalition）将工作流定义为：

业务流程的全部或部分自动化，在此过程中，文档、信息、任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。

1、Interface 1：过程定义导入/导出接口。转换格式和 API 调用，从而支持过程定义信息间的互相转换。

2、Interface 2：客户端应用程序接口。通过这个接口工作流机可以与任务表处理器交换，代表用户资源来组织任务，然后由任务表处理器负责，从任务表中选择、推行任务项。

3、Interface 3：应用程序调用接口。允许工作流机直接激活一个应用程序，来执行一个活动。

4、Interface 4：工作流机协作接口。定义相关标准，以使不同开发商的工作流系统产品互相间能够进行无缝的任务项传递。

5、Interface 5：管理和监视接口。用户管理、角色管理、审查管理、资源控制、过程管理、过程状态处理器等。

用工作流的思想组织业务逻辑，优点是：将应用逻辑与过程逻辑分离。

16.3.3 业务逻辑实体设计

业务逻辑层实体提供对业务数据及相关功能的状态编程访问。

可以使用具有复杂架构的数据来创建，通常来自数据库的多个相关表。

业务逻辑层实体不直接访问数据库。

将业务逻辑层实体表示为通用 DataSet 的优点如下：

1、灵活性。

2、序列化。

3、数据绑定。

4、排序、过滤。

5、与 XML 的互换性。

6、开放式并发。

7、可扩展性。

将业务逻辑层实体表示为有类型的 DataSet，有类型的 DataSet 是包含具有严格类型的方法、属性、类型定义以公开 DataSet 中的数据和元数据的类。

将业务逻辑层表示为有类型的 DataSet 的优点如下：

1、代码易读。

2、IntelliSense将可用。

3、编译时类型检查。

16.3.4 业务逻辑层框架

业务框架位于系统架构的中间层，是实现系统功能的核心组件。

采用容器的形式，便于系统功能的开发、代码重用、管理。

1、Domain Model 是领域层业务对象，它仅仅包含业务相关的属性。

2、Service 是业务过程实现的的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。

3、Control 服务控制器，是服务之间的纽带。

16.4 数据访问层设计（持久层框架设计）

16.4.2 工厂模式在数据访问层应用

做到数据库无关，需要在实际开发过程中将这些数据库访问类再做一次封装，还可以减少操作数据库的步骤。

工厂模式定义了一个用于创建对象的接口，让子类决定实例化哪一个类。

前提是编写程序时，没有用到特定数据库的特性。

16.4.3 ORM、Hibernate 与 CMP 2.0 设计思想

ORM（Object-Relation Mapping）在关系型数据库和对象之间作一个映射，不需要再去和复杂的 SQL 语句打交道。

ORM 框架把数据库转变成了我们熟悉的对象，只需要了解面向对象的开发就可以实现数据库应用程序的开发，不需要浪费时间在 SQL 上。

同时也减少了代码量，减少数据层出错机会。

通过 Cache 的实现，能够对性能进行调优。

16.4.4 灵活运用 Xml Schema

Xml Schema 用来描述 XML 文档合法结构、内容、限制。

逐步替代 DTDs，成为 XML 体系中正式的类型语言。

Xml Schema 是 Schema 组件的集合，这些组件分为三组：基本组件、组件、帮助组件。

基本组建包括简单类型定义、复杂类型定义、属性声明、元素声明。

组件包括属性组、完整性约束定义、模型组、符号声明。

帮助组件包括注释、模型组、小品词、通配符、属性使用。

Xml Schema 提供了创建 XML 文档的必要的框架，规范由如下三部分组成：

1、Xml Schema Part 0：Primer。

2、Xml Schema Part 1：Structures。

3、Xml Schema Part 2：Datatypes。

Xml Schema支持继承。

16.4.5 事务处理设计

事务是现代数据库理论中的核心概念之一。

原子性（Atomicity）。

一致性（Consistency）。

隔离性（Isolation）。

持久性（Durability）。

事务要尽可能短的时间内完成。

16.4.6 连接对象管理设计

JDBC 的数据库应用开发中，数据库连接的管理是一个难点，因为它是决定该应用性能的一个重要因素。

资源池，解决资源频繁分配、释放所造成的问题。

第一步就是要建立一个静态的连接池，所谓静态，是指池中的连接是在系统初始化时就分配好的，并且不能够随意关闭。

16.4.5 数据架构规划设计

XML 文档的存储方式有两种：基于文件的存储方式、数据库存储方式。

本文链接

系统架构师学习笔记_第十五章_连载

2010-08-30T15:12:00Z

第十五章架构师的管理实践

软件架构师的主要障碍往往在于组织方面而非技术，技术上出色的架构往往由于没有全面地处理好组织管理因素而失效。

15.1 VRAPS 组织管理原则

VRAPS 包括构想、节奏、预见、协作、简化 5个相关联的原则。

受益人是指建立并长期保持架构的价值有重要影响的人或组织。

1、构想原则：描述一副一致的、有约束力和灵活的未来图景。

2、节奏原则：协调程度，根据可预测的速度、内容、质量对制品生产进行检查与规划。

3、预见原则。

4、协作原则：如何识别对架构成功关键的团体，如何确保这些合作伙伴的有效支持。

5、简化原则：理解组织的结构。

所有其他的原则也是彼此之间相互影响的。

15.2 概念框架

用准则、模式、反模式对各项原则进行补充。

准则用于判断每个原则的实施效果如何。

模式描述了常见问题和解决方法。

反模式描述了在实践中可能遇到的陷阱。描述了不该做的事情，或者用在错误背景下的解决方案。

15.3 形成并统一构想

构想描述了架构的未来，提供了架构使用的环境和动机。

必须把它所能提供的价值与客户的约束相对应。

明晰、有约束力、一致、灵活。

15.3.1 形成构想

构想需要维持一致性与协调性。

一致性是指受益人的各种期望之间妥协，以及需求满足程度。

灵活性是指不破坏架构的情况下，完成事先没有预料到的需求的容易程度。

RUP 的 “4+1 架构视图”体现了获得这种一致性的方法，逻辑视图、实现视图、进程视图、部署视图、用例视图，它们根据不同目的表示系统。

架构师可以推荐技术，如何以及即使采用这些技术。

架构师更多地意味着权衡业务、组织运作、使用技术，找出各利益方关注的重点，在一个公共的组织层次上对信息、决策、资源进行协调。

Thompson归纳了架构构想的三步方法：清楚明确地阐述一条迫切的客户价值；将客户价值映射为少数特定的能解决的问题；将以上问题转译成一组特定的约束条件。

成功的架构师用明确的客户价值映射规划未来，架构师必须格外关注产品开发人员和最终的客户。

15.3.2 将构想原则付诸实践

用于检验构想原则是否起作用的准则如下：

1、构想与发起人、用户、最终客户期望实现的目标是否保持一致。

2、实施人员是否信任并使用架构。

3、潜藏知识对其用户（开发团队）是否是可见的、可获得的。

准则1

为获得一致、迫切、灵活的架构，产品线经理、架构师、实施经理等达成共识。如果没有阐明用户价值，会导致构想脱离了重点。

反模式：风险后置。

用最小的妥协、最大的优化规划出一个构件以满足所有冲突利益的需要。往往在理论上可行，但实际运行中出现风险。

模式：前后一致。

一个公共的架构被几个产品共享，已经变得比预期要复杂得多，客户们针对每件产品又提出了以前没有预计到的功能特性。

需要评估架构构想的质量和稳定性，只有当两者都正常时，才能采取进一步行动，如果新特性不属于原来构想的代价范围，就应该放弃。

如果这个特性确实属于一个文档的产品构想，应该在开发组织内核实这种一致性。

准则2

开发人员可能会使架构向许多不同的方向发展。一个良好架构应与构想保持一致，同时又能满足用户的需求。

反模式：墙头草。

因为没有良好的构想，导致架构方向在竞争和客户压力的影响下经常改变。这种构想永远不能达到稳定以便有效地被共享。

以后发布会因需要提供向后兼容而变得更为复杂。

方便变更需求是成功构想的一部分，高级主管要与架构师一起紧密地工作，理解变更的后果并做出正确的权衡。

需要一种固定的机制。

模式：三个臭皮匠。

架构师并非总是架构构想的来源，共同的架构或平台是产品线战略的关键。

抵制创建无所不能的架构诱惑。

高级经理只提供构想、目标、原则。

成功的产品线架构必须能为适应市场变化，能适应和采用新技术，能解决在概念阶段还不知道的但变化场景可预见的问题。

准则3

反模式：一叶障目。

开发人员过份专注于应用，以致不知道其他架构解决同类问题的通用解决方案。

需创造一种分享知识的愿望，如，工程师培训、启用知识管理平台。

模式：轮流工作。

帮教制（Apprenticeship）模式阶段性地轮流交换构件的所有权可以解决上面的问题。

组织和鼓励构件的前任负责人抽出时间帮助新的负责人，轮转周期应该尽可能地与发布进度保持同步。

15.4 节奏：保证节拍、过程、进展

15.4.1 节奏定义

节奏是反复出现的、可预测的工件交换活动。

节奏三个元素：速度、内容、质量。

节奏在团体和组织之间与内部提供一种协调活动的稳定力量，帮助移交管理。

节奏很强时，能培养很强的预见、实施移交、交接的技能。

15.4.2 将节奏原则付诸实践

以下准则出现时，才说明节奏起了作用。

1、经理们定期地再评估、同步、调整架构。

2、架构用户对架构发布的进度和内容具有高度的信心。

3、通过节奏协调明确的活动。

准则1：经理们定期地再评估、同步、调整架构。

必须在稳定的间隙上再评估、同步、调整他们的架构计划。

反模式：一步成功。

过于专注地向市场推出某项功能特性而导致内部节奏遭到破坏。

组织被竞争所蒙蔽，全身心地专注于向市场提供该特性，却削减了质量。

如果在实现关键特性的时候难以保持节奏，说明该特性的风险和复杂度比预计的要大，需要重新规划。

模式：发布委员会。

该模式向经理们介绍了架构发布的最后阶段再评估、同步、调整架构的方法。

在会议中，要复审产品功能特性和优先级的变更，从而使产品文档、市场承诺、公共关系、测试、开发保持一致。

与会人员应该有足够的决定权。

准则2：架构用户对架构发布的进度和内容具有高度的信心。

用户对架构发布的进度和内容缺乏信心是一个警告信号，说明没有设立一个良好的节奏。

反模式：超敏捷。

抄近路以维持稳定的发布节拍，对用户所期望的架构质量和内容进行妥协。

是否已经分配了足够的资源来执行计划中的步骤，经理们是否创建明确的目标来保证对节奏的维持都有非常重要的影响。

模式：舍兵保帅。

把不太重要的特性移到后面的发布周期。

准则3：通过节奏协调明确的活动。

软件架构的受益人分布在许多不同的组织中。

反模式：销售未检验的产品。

由于团队不把编译和测试用例的失败当回事，导致积累下来的问题越来越多，无法按时发布。

对定期建立的流程进行修改，防止在修正失败的建立之前开展新的工作。

模式：同步发布。

如果架构中的一些变化需要互补产品做出重大变更，那么应让这些变化出现在最早的发布中。

15.5 预测、验证、调整

为了使对软件产品线的长期投资能产生回报，必须明确架构满足许多应用的需求。

能够预见变化并对变化做出反映，包括那些在设计架构时还没想到的需求。

能够适应新的技术、标准、市场、竞争对手。

15.5.1 预测、验证、调度的定义

竞争形式运行环境新的组织结构像银行业这样合并、接管司空见惯的领域中，预测不可能总是正确的，所以需要验证。

在架构成型前要对这些假定进行检查和确认。

调整要求具有敏捷性。

15.5.2 将预见原则付诸实践：准则、反模式、模式

1、不断增强架构的影响能力：预见到的风险和架构客户及其客户的需求；市场驱动的标准和演变的技术；战略性业务方向的改变。

2、通过快速复审和开发周期，评估技术和业务上的风险与机会。

3、当认识到关键字的估计或假设有错时，即使调整功能特性、预算。

准则1：不断增强架构的影响能力：预见到的风险和架构客户及其客户的需求；市场驱动的标准和演变的技术；战略性业务方向的改变。

反模式：遗漏细节。

每个人都关注发布的强大新特性，以致忽视了一些用户必不可少的功能。

需要识别关键用户群，和他们一起找出最重要的需求。

模式：示范区。

挑选一个项目初步实现架构。该项目的客户渴望采用新技术，而且也愿意容忍获得该技术时可能存在的不便。

在架构大范围应用之前，缺陷将被发现并解决，修订后兼容问题的约束较小。

准则2：通过快速复审和开发周期，评估技术和业务上的风险与机会。

反模式：品尝未成熟的果实。

被以前的换代或升级害苦了的客户对关于未成熟技术的承诺极度不信任。

要审慎地选择引入新技术的正确场所，要为最初用户提供额外的支持。

不要假定一个未经验证的架构能够实现所有的承诺，应该分别在开发人员和产品用户的特定环境下测试你的解决方案。

模式：架构复审。

对开发中的架构组织执行一次有重点的专家评估，有重大影响的问题和机遇。

在开发周期的关键时刻成立一个架构复审委员会以检查架构。

需求基线初步确定首次复审，有经验的架构师、架构小组成员，客户。

注意让这些复审保持重点。

早起发现缺陷，及时修正，能发现取代新的开发活动的构件，还增强了客户对架构提供已承诺能力的信心。

准则3：当认识到关键字的估计或假设有错时，即使调整功能特性、预算。

反模式：创造奇迹。

解决方法分为如下两个部分：

1. 找到架构的基础假设并积极努力测试这些假设。

2. 一旦发现错误的估计或假设，必须准备好对此采取行动。

无论何种情况，都应该确保把足够的资源编入预算计划，使得当不可避免的意外发生时，有可分配的进度和人员。

模式：外包。

合适及怎样选择一个已有的第三方构件，或者与提供者合作。

要确定潜在的合作伙伴是否把你需要的构件视为其主营业务的一部分。

他们必须为你做的专门开发越多，信任程度要求越高。类似地，信任度越低，你面临的进度和财政风险就就越高。

15.6 协作：建立合作型组织

每一个对架构关键的团体必须知道如何使用、努力改进架构从而为自己的利益服务。

如何识别对架构成功起关键作用的团体，如何确保这些合作伙伴的支持。

15.6.1 协作定义

协作是指架构受益人保持明确的、合作的角色并将所提供和获得的价值最大化的程度。

合作是指受益人彼此之间存在一些共享的预期，应该明确表示出达到或未达到预期会有哪些奖励和惩罚。

15.6.2 将协作原则付诸实践：准则、反模式、模式

正式定义的协作网络与非正式协作网络决定了一个软件架构能否成功。当出现以下几种情况时，说明协作是有效的。

1、架构师不断地努力了解谁是最关键的受益人，他们如何贡献价值，以及他们需要什么。

2、受益人之间达成明确和强制性的契约。

3、通过社会行为制度和非正式规范强化合作。

准则1：架构师不断地努力了解谁是最关键的受益人，他们如何贡献价值，以及他们需要什么。

挑选一批集中的首要客户，找出保证他们参与需要做些什么，然后交付这些内容，这样做可以增大成功的机会。

反模式：光说不做。

架构师知道了用户的需求却遗漏了为了向他们提供有价值的的东西所应该做的事情。

架构师忙于其他事务，没有与开发人员进行稳定的交流，各产品团队按照自己的理解开发并升级了产品，放弃了原来同意的清晰的接口。

模式：了解你的受益人。

利用价值链来识别关键受益人，积极听取他们的一键并获得承诺与支持。

在初步阐明构想之后，确定潜在的合作伙伴以及他们的能力和利益如何与构想保持一致。

准则2：受益人之间达成明确和强制性的契约。

反模式：不记录讨论结果。

不记录讨论结果说明了当一个架构团队回避采取必要的行动与其最直接的用户达成明确的契约时会发生什么情况。

要确保取得对关键受益人的利益与职责的明确理解，当互动变得消极或者缺乏建设性时，可以求助于这些文件。

模式：互惠互利。

互惠互利要求在合作伙伴之间进行公平、主动的价值交换。

应该对正式和非正式的契约复审以保证公平的交换。预算中应该包括代码负责人响应其他团体请求所花的时间。

准则3：通过社会行为制度和非正式规范强化合作。

反模式：非正式时间做正式工作。

让工程师利用业余时间修改，架构师就失去了控制其过程和结果的能力，甚至连测试也有可能被删除或完全忽略。

如果这种产品加入到其他团队的工件中，这位工程师在需要完成日常任务同时，还接到大量要求提供支持的请求，导致工程师精疲力竭。

要制订计划奖励工程师花在共享构件上的时间，尽早兑现奖励能减少工作量和大量压力。

把员工用于开发、维护被团体或项目外部所共享的解决方案的时间编入预算，预防工程师在利用非正式时间做正式工作。

模式：杜绝意外。

要尽早提醒用户注意变更，及时协商解决方案。

模式：和HR密切合作。

大部分高级技术岗位要求能迅速获得广泛的潜信息。有着广泛的非正式人际网的工程师比没有这种网络的工程师能获得质量更好的信息。

经理们应该避免破坏非正式人际网。

15.7 简化：澄清与最小化。

确定关键价值是不容易的，尤其是当新客户和新产品的加入使架构偏离原来的方向时，困难会显著增加。

简化软件架构的原则概念上看似简单，而实践中它要求对价值非常坚定地专注，以及对架构所生存的组织理解和支持。

15.7.1 简化定义

在决定简化架构时，应当留意组织的结构；否则，你会发现你所做的改变只是暂时的。因此在简化架构之前，必须澄清组织和架构。

澄清组织意味着真实地理解你计划部署架构于其中的组织结构及其影响力（Force）

架构对架构团队和客户都必须是清晰的，简化架构之前，必须准确地知道架构被期望做什么、如何完成这些任务。

澄清架构就是提供用户所需要的细节。

如果一个组织具备简化、协作、节奏等技能，长期共享架构就能最小化代码、文档、过程。

不好的组织情况下，共享可能导致架构膨胀。

15.7.2 将简化原则付诸实践：准则、反模式、模式

当以下准则都满足时，说明简化原则起作用了。

1、开发人员长期使用架构，减少了总成本和复杂性。

2、架构小组明确理解关键最小需求，并且将其构造成多个应用共享的核心元素。

3、通过长期的预算和行动确保相当关元素没有被共享、增加了不必要的复杂性时，或者是因为有明确的业务理由时，把相关元素从核心移走。

准则1：开发人员长期使用架构，减少了总成本和复杂性。

反模式：简单复制并修改。

不与构件负责人协商变更就复制并修改架构的部分代码，通常会带来深远的后果。

模式：由慢而快。

开发人员为了跟上进度，拒绝使用架构，解决方法是：放宽进度，加强过程。

指导开发人员逐步采用架构。

准则2：架构小组明确理解关键最小需求，并且将其构造成多个应用共享的核心元素。

反模式：缺乏有效抽象。

由于没有被一个共享平台强力支持，每一个分离产品都要求自己的支撑结构。

通过框架团队来建立一个共享平台，防止产品专有特性进入平台。

模式：迁移途径。

准则3：通过长期的预算和行动确保相当关元素没有被共享、增加了不必要的复杂性时，或者是因为有明确的业务理由时，把相关元素从核心移走。

把架构师拉去参加一个紧急项目以实现一个新特性，而使架构无人照看。

反模式：编码大于架构。

要防止架构师成为实现者，否则问题越来越多。

应该把首席架构师的时间合理分配给实现新特性和调整架构两个renwu

模式：统计构件变更。

通过观察不稳定程度来挑选需要调整的架构构件的方法。

重组（Refractor）通过长期观测每个构件或子系统不稳定的程度，那些最不稳定的构件就是重组的候选者。

本文链接

系统架构师学习笔记_第十四章_连载

2010-08-25T15:12:00Z

第十四章基于ODP的架构师实践

14.1 基于ODP的架构开发过程

系统架构反映了功能在系统系统构件中的分布、基础设施相关技术、架构设计模式等，它包含了架构的原则和方法、构件关系与约束，并能支持迭加或增量开发。

以软件架构为中心的开发过程是以质量和风险驱动的，最终提供一个稳定、低风险的系统架构，并满足客户的需求（包含潜在需求）。

开放分布进程的参考模型（RM-ODP）是一个ISO标准，定义了分布系统的重要性质：

开放性、整体性、灵活性、可塑性、联合性、可操作管理性、优质服务、安全性、透明性。

RM-ODP定义的 5个观点：

1、企业视点：商业需求和策略、系统的范围和目的。可能会影响系统中的与企业相关的信息，如组织结构等。

2、信息视点。

3、计算视点。

4、工程视点。

5、技术视点。

每一个观点有具体的建模目标和系统相关者。

分层子系统视图提供了一个所有子系统高度抽象的视图。

14.2 系统构想

14.2.1 系统构想的定义

系统构想是开发人员与用户之间共同的协议。

按照该协议，开发人员需要在特定的时间内完成系统用户的需求，系统构想必须简短而切中要点。

高度概括了业务架构的核心内容。

14.2.2 架构师的作用

系统构想有助于各方明了系统的目标和范围。

确保系统开发的计划、设计等阶段能依次有序地展开。

系统构想阶段，架构师合理的介入，有以下好处：

1、有利于使系统架构师本身对系统的看法更加全面、准确。

2、统一系统开发人员对系统的看法。

3、正确确定需求的优先次序。

4、最大程度上提高客户对设计等过程的参与程度，更好地与客户沟通。

14.2.3 系统构想面临的挑战

架构师对其控制能力之外的因素通常无能为力，可以通过有效地评估，以及高级经理和架构师之间保持紧密的联系克服这些困难。

还必须面对以下几种情况：

1、很多架构师把架构看成是他们独自的创造，只要他们认为合适的就进行修改。

2、有些人不是拥有产品线构想的高级经理，却总是由这些人决定雇佣谁来做架构师。

14.3 需求分析

14.3.1 架构师的工作

需求一般定义系统的外部行为和外观以及用户信息，而不用设计系统的内部结构。

对需求分析通常考察以下 6个方面的内容：

1、系统范围对象关系图。

2、用户接口原型，用户操作的一个雏形。

3、需求的适用性，该用什么技术解决，性能怎么样，是否与其他需求相重合或矛盾，需求分析应注意需求本身的实用或适用，而不必考虑其实现。

4、确定需求的优先级。

5、为需求建立功能结构模型，组件图，实体数据对象图。

6、使用质量功能分配（Quality Function Deploymen，QFD）发现隐藏质量需求，建立相关质量场景，先期预测需求风险。

有效地捕捉行为需求的方法是分析用例（Use Case）

用例包含图和文字描述，符号简单、抽象，保证表述需求时简单性和清晰度。

14.3.2 需求分析的任务

1、需求分析的目的

完整、准确地描述用户对系统的需求，跟踪用户需求的变化，准确地反映到系统架构和设计中，设计和用户的需求保持一致。

具有决策性、方向性、策略性的作用。

2、需求分析的特点

追求系统需求的完整性、一致性、验证性。

保持和用户要求同步，

保持需求分析各侧面之间的一致，

保持需求和系统设计间的同步。

14.3.3 需求文档与架构

每个用例都有一个相关需求的文字描述，定义用例应该和领域专家一起进行，如果没有领域专家的长期参与，只能是一种“伪分析”。

用例为定义架构提供了一个系统的领域行为模型。

界面的外观、功能、导航同用例紧密相连，有效定义屏幕的方法叫低保真度原型（Low-fidelity Prototyping），领域专家也始终参与到屏幕定义中去。

需求分析的项目词汇表，也将在架构规划中被扩展。

14.4 系统架构设计

系统架构沟通了需求和软件之间巨大的语义上的鸿沟。

系统架构的第一个任务就是定义这两个极端之间的映射。

开放分布式处理（Open Distributed Processing，ODP）包括企业、逻辑信息、计算接口、分布式工程、技术选择。

对每个观点，确认架构需求的一致性是非常重要的。

14.4.1 企业业务架构

企业业务架构从IT角度，对企业的业务结构、企业机构、业务的关系、内部的关系、与外部机构的关系进行整理定义。

包含如下内容：

1、企业的业务和战略目标，近期、中期、长远目标。

2、企业的组织结构。

3、业务的分类。

4、各类业务之间的关系。

5、组织机构与业务的关系。

6、企业与外部机构的关系。

这些业务对象模型标识出系统的关键性约束，包括系统目标和重要的系统策略。

策略包含如下三类明确的表达方式：

责任：业务对象必须做什么。

许可：业务对象可以做什么。

禁止：业务对象不可以做什么。

对业务问题进行分析时，要考虑企业业务的发展，如新的服务或产品推出、考虑组织机构的改变等。

所有这些可能的变化（易变场景）都应该提现在企业业务架构中。

通过对企业业务架构的定义，很清楚地知道由于企业业务特点、业务的流程特点、企业的组织机构等原因对IT系统所带来的自然分块和各个分块之间的边界关系。

企业业务架构的维护是一个长期而反复的工作。

测试结果报告系统（Test Results Reporting System，TRRS）。

对象约束语言（Object Constraint Language，OCL）来定义企业活动者的这些策略（如许可、禁止、义务等）。

14.4.2 逻辑信息架构

逻辑信息架构（信息视点）标识出系统必须知道什么。

强调定义系统状态的属性。

开放分布式处理是一种面向对象的方法，模型包含了关键信息的处理，如传统的对象概念。

软件架构对象并不是编程的对象，它表示对系统的约束和依赖，这些约束能够消除把需求翻译成软件过程中的许多猜测性工作。

架构师应该把他们的建模集中于有高风险、高复杂性、模糊性的关键方面。

14.4.3 计算接口架构

计算接口对系统架构非常有帮助，但是它常常被架构师所忽略。

消除多个开发者和小组的主要设计争端，这些接口的架构控制对于一个支持变化和控制复杂性的稳定的系统结构来说，是非常重要的。

接口定义语言（IDL），完全独立于编程语言和操作系统。

14.4.4 分布式工程架构

分布式工程架构定义了底层结构的需求，独立于所选择的技术，解决了最复杂的系统策略，包括物理位置、系统规模可变性、通信服务质量。

ODP的一个最大好处是关注点分离。

14.4.5 技术选择架构

大多数架构是独立的。

基于对候选者的初始选择，根据产品价格、培训要求、维护风险之类的项目因素而反复进行。

14.5 实现模型

最终用户和架构师应在一起审查并贯穿于用例，始终来证实需求的有效。

对产品设计的可行性做出准确地评估、论证。

14.6 架构原型

架构原型是很好的需求验证工具，作为改进设计的手段，确保与工程约束相一致。

下面是一些架构师可以在架构原型中寻求解答的具体问题：

1、主要组件是否得到了良好的定义？是否恰当？

2、主要组件间的协作是否得到了良好的定义？

3、耦合是否得意最小化？

4、我们能否确定重用的潜在来源？

5、接口定义和各项约束是否可以接受？

6、每个模块是否能访问到其所需要的数据？

经过2次或3次迭代之后，架构变得稳定。主要的抽象对象都已找到，子系统和过程都已经完成，所有的接口都已明确定义。

利用架构原型，几个好处：

1、落实之前，让团队成员能自由发表他们自己的看法。

2、统一团队之间的思想看法，提高系统开发的成功率。

3、对系统内部的结构分析与设计也有帮助。

14.7 项目规划

项目规划是通过批准的正式文档，以它为基准跟踪和控制项目，行动方案和资源分配，引导项目实施。

主要作用是将指定规划的假设和决定批准的范围、成本、进度的基线等用正式的文档记录保存。

估算是项目规划的核心。

随着项目的进展，估算会不断校正并逐渐地接近实际。

项目管理者通过计划与规划的差异，不断优化和更新计划策略，使项目按规划的要求得以实现，计划的变更是可管理和可受控的。

规划包括：

1、项目的目的、范围、目标、对象。

2、软件生存周期的选择。

3、精选的规程、方法、标准。

4、待开发的软件工作产品。

5、规模估计、软件项目的工作量和成本估计。

6、关键计算机资源的估计；项目的里程碑。

7、风险的识别和评估。

8、工程实施和支持工具计划。

软件项目计划的目标有：软件估计被文档化，活动和约定形成文档，受影响的组和个人认同与软件项目规划的约定。

14.8 并行开发

14.8.1 软件并行开发的内容及意义

提高软件生产率，改善软件质量，有效地组织可以重复的资源。

并行开发研究的内容主要如下：

1、软件过程及其模型。

2、并行分成划分。

3、并行控制。

4、支持环境。

5、交互机制与集成技术。

14.8.2 并行开发的过程

把软件系统的开发过程划分为若干个可以并行的成分，这个成分称之为子开发过程。

子开发过程 = 开发小组 + 软件对象 + 对软件对象的开发活动。

并行开发活动，称为并行开发系统，实体是个开发小组，实体属性是被开发的软件对象，行为是开发软件对象的活动。

行为模块的划分是并行开发中的核心问题，模块独立性是衡量软件设计质量的关键。

系统划分方法：

1、基于 Petri网系统模型的动态划分方法。

2、基于脚本的系统划分方法。

软件过程并行控制是一个非常重要的问题。

就是要用正确的方式调度并行操作，避免造成不一致性，使一个操作的执行不受其他系统的干扰。

保证一致性、相容性、正确性、可靠性，手段有加锁、时间戳、管程、Petri 网、PV 操作等。

继承和测试被分为两个阶段，如果不考虑硬件或软件的集成，两个阶段并没有明显的界限，所以，软件集成的主要问题是集成测试技术。

14.9 系统转换

系统转换是指运用某一种方式由新的系统代替旧的系统的过程，也就是系统设备、数据、人员等方面的转换。

14.9.1 系统转换的准备

转换前，必须认真做好准备。

还需测试试运行这项工作。

注意如下两个问题：

1、系统试运行工作的代表性。

2、系统试运行中错误的修正。

14.9.2 系统转换的方式

直接转换、平行转换、分段转换、分批转换。

14.9.3 系统转换的注意事项

1、大量的基础数据，录入工作量很大，应及早准备，尽快完成。

2、应提前做好人员的培训工作。

3、出现一些局部性的问题，应有足够的准备，并做好记录。如果出现致命问题，要重新设计。

14.10 操作与维护

14.10.1 操作与维护的内容

数据管理与维护。

设备管理与维护。

软件的管理与维护工作。

14.10.2 系统维护与架构

系统架构的好坏，可维护性是一个重要方面，维护人员应参与架构的审评。

可维护性可以定性地定义为：维护人员理解、改正、改动、改进的难易程度。

可维护性有如下几个评价指标：

可理解性。

可测试性。

可修改性。

系统维护工作可以分为以下 4种类型：

更正性维护。

适应性维护。

完善性维护。

预防性维护。

维护人员必须先理解要维护的系统，然后建立一个维护方案。

由于某处修改很可能会影响其他模块程序，所以考虑的重要问题是修改的影响范围和波及面的大小。

必须强调的是，维护是对整个系统而言的，必须同时修改涉及的所有文档。

14.11 系统移植

14.11.1 系统移植的方式

不修改已有的软件。

修改软件。

重新编软件。

14.11.2 系统移植的工作阶段划分

计划阶段。

准备阶段，准备转换所需的材料。

转换阶段。

测试阶段。

验证阶段。

使系统移植工作标准化，工具实现自动化。

14.11.3 系统移植工具

系列化、标准化、文档化，使任何人都能以相同的顺序开展工作，提高效率。

本文链接