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和腾讯之间的争斗已经持续了十多天了，用户该用什么还是用什么，不可能因为谁多骂了谁几句就能让对方倒闭的，无非是看看笑话。
虽然用户不变，但这个战局发生了历史上最大的变化。
腾讯和360都有用户量，但腾讯偏多，而且腾讯比360有钱得很，真不是一个等级的。
但是360很有智慧，当年网民需要3721时，他就做3721；当网民不需要3721时，他就不做3721；雅虎中途打个小算盘没玩明白，收了3721网民就开始骂了，把老本都搭进去了；最终360还是顺应网民的意愿，做360灭3721；他每次都是顺应自然，站在网民这一方挖掘市场。
尤其近几年的免费杀毒软件之争，每次360都是蚂蚁吃大象，这次对腾讯360是主动出手的，所以我认为凭借他的智慧，小胜一筹没有问题。
可事情并没有我前几天想得那么简单。
回想这几年，腾讯靠着庞大客户群，抄袭互联网有钱途的经营模块，把它做得更人性化，遍地捡钱，强行抢占了人家的市场。
360这次出击，无形之间表达了360要对战腾讯的决心，以前被腾讯欺负过的公司原本是一盘散沙，落日余晖，被360这么一刺激，瞬间拧成一股绳。
想想看，腾讯模仿他们的东西，反过来说腾讯能做的，他们也都能做，如果他们能合纵联横，加上360的战略指导，将是多么强大。
可以说360的产品比较少，无法和腾讯抗衡，但是他号召起来的那些集团大军，完全可以再造一个腾讯，其用户量加起来也远远超过腾讯，若能联合，他们每一个团队都是自己领域当中最专业的，而腾讯只是一个山寨而已。
腾讯为什么粘性那么大，因为我们的朋友都用它，但是，最亲密的朋友、最重要的伙伴，不用腾讯也能联系，这表明腾讯并不是必要的。
只要腾讯近期灭不了360，360必将鼓舞反腾讯阵营复仇之心，同仇敌忾共同抗击。
360也有仇家，但是360市场小，这也是他的优势，他的仇家只有浏览器和杀毒软件两个领域，和腾讯的仇家相比，真不是一个等级的。
战国交戎变成楚汉相争，成也抄袭，败也抄袭，做老板的，四面触敌走投无路的时候，反思一下自己是不是当年做得太过份了，这些债积攒到一起的时候就该吃报应了。
寡助之至，亲戚畔之。多助之至，天下顺之。以天下之所顺，攻亲戚之所畔，故君子有不战，战必胜矣。
第二十一章 案例研究
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、开发适配器业务逻辑。
第二十章 面向服务的架构
服务是一个由服务提供者提供的，用于满足使用者请求的业务单元。
在 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. 建立业务流程
流程是指定的活动顺序，包含明确确定的用于提供业务值的输入和输出。
对流程进行建模应当确保捕获的相关信息的一致性及完整性。
第十九章 嵌入式系统设计
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）。
第十八章 面向方面的编程
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 特性
改善了软件的 可扩展性、重用性、易理解性、易维护性。
通过将实现基本功能的组件和特定于应用的系统特性分离，使得组件（包括类或者函数）的重用性得到提高。