3.1 信息系统集成简述
1.信息系统集成概念
系统集成是指将计算机软件、硬件、网络通信等技术和产品集成为能够满足用户特定需求的信息系统，包括总体策划、设计、开发、实施、服务及保障。
2.信息系统集成分类
系统集成主要包括设备系统集成和应用系统集成。
1）设备系统集成
设备系统集成，也可称为硬件系统集成，在大多数场合简称系统集成，或称为弱电系统集成，以区分于机电设备安装类的强电集成。设备系统集成也可分为智能建筑系统集成、计算机网络系统集成、安防系统集成。
（1）智能建筑系统集成（Intelligent Building System Integration）
（2）计算机网络系统集成（Computer Network System Integration）
（3）安防系统集成（Security System Integration）
2）应用系统集成
应用系统集成（Application System Integration），从系统的高度提供符合客户需求的应用系统模式并实现该系统模式的具体技术解决方案和运维方案，即为用户提供一个全面的系统解决方案。应用系统集成又称为行业信息化解决方案集成。
3.2 信息系统建设
3.2.1 信息系统的生命周期
信息系统的生命周期可以分为四个阶段：立项、开发、运维、消亡。
1.立项阶段
即其概念阶段或需求阶段
2.开发阶段
该阶段又可分为以下阶段。
（1）总体规划阶段：
（2）系统分析阶段：为系统设计阶段提供系统的逻辑模型。
（3）系统设计阶段：
（4）系统实施阶段：是将设计阶段的成功在计算机和网络上的具体实现，即将设计的文本变成能在计算机上运行的软件系统。
（5）系统验收阶段：
3.运维阶段
4.消亡阶段
3.2.2 信息系统开发方法
常用的开发方法有：结构化方法、原型法、面向对象法。
1.结构化方法
结构化方法具有如下特点：
（1）遵循用户至上原则
（2）严格区分工作阶段，每个阶段有明确的任务和取得的成果
（3）强调系统开发过程的整体性和全局性
（4）系统开发过程工程化，文档资料标准化
2.原型法
原型应当具备的特点如下：
（1）实际可行
（2）具有最终系统的基本特征
（3）构造方便、快速、造价低
可将原型分类如下：
（1）抛弃型原型（Throw-It-Away Prototype），此类原型在系统真正实现以后就放弃不用了。
（2）进化型原型（Evolutionary Prototype），此类原型的构造从目标系统的一个或几个基本需求出发，通过修改和追加功能的过程逐渐丰富，演化成最终系统。
3.面向对象方法（Object Oriented，OO）
3.3 软件工程
3.3.1 软件需求分析与定义
软件需求是一个为解决一个特定问题而必须由被开发或被修改的软件展示的特性。
所有软件需求的一个基本特性就是可验证性。
3.3.2 软件设计、测试和维护
1.软件设计
软件设计是“定义一个系统或组件的架构、组件、接口和其他特征的过程”，并得到“这个过程的结果”。
软件设计由两个处于软件需求和软件构造之间的活动组成。
1）软件架构设计（有时叫做高层设计）：描述软件的结构和组织，标识各种不同的组件
2）软件详细设计：详细地描述各个组件，使之能被构造。
软件架构是“一个描述软件系统的子系统和组件，以及它们之间相互关系的学科”。
模式提供了架构设计的某些方法。模式是“给定上下文中普遍问题的普遍解决方案”，主要涉及设计模式（微观架构模式）和架构模式（宏观架构）。
2.软件测试
测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。
软件测试是针对一个程序的行为，在有限测试用例集合上，动态验证是否达到预期的行为，需要选取适当的测试用例。
3.软件维护
软件维护包括如下类型：
（1）更正性维护：软件产品交付后进行的修改，以更正发现的问题。
（2）适应性维护：软件产品交付后进行的修改，以保持软件产品能在变化后或变化中的环境中可以继续使用。
（3）完善性维护：软件产品交付后进行的修改，以改进性能和可维护性。
（4）预防性维护：软件产品交付后进行的修改，以在软件产品中的潜在错误称为实际错误前，检测和更正它们。
3.3.3 软件复用
软件复用使之利用已有软件的各种有关知识构造新的软件，以缩减软件开发和维护的费用。
软件制品的复用，按照抽象程度的高低，可以划分为如下复用级别：代码的复用、设计的复用、分析的复用、测试信息的复用等。
3.3.4 软件质量保证及质量评价
软件需求定义了软件质量特性，并影响评价这些特性的度量方法和接收准则。
软件质量管理过程包括：质量保证过程、验证过程、确认过程、评审过程、审计过程等。
1.软件质量保证
软件质量保证过程通过计划制订、实施和完成一组活动提供保证，这些活动保证项目生命周期中的软件产品和过程符号其规定的需求。
2.验证与确认
验证与确认过程使用能够定位缺陷并便于以后改正的测试技术直接处理软件产品质量问题。
3.评审与审计
评审与审计过程包括：管理评审、技术评审、检查、走查、审计等。
软件审计的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。审计是正式组织的活动，识别违例情况，并产生一个报告，采取更正性行动。
3.3.5 软件配置管理
软件配置管理是有益于项目管理、开发和维护活动。
软件配置管理活动有：软件配置管理过程的管理和计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付。
1.软件配置管理过程的管理和计划
软件配置管理通过标识产品的元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的进化和完整性。
2.软件配置标识
软件配置标识活动标识要控制的项，为这些项及其版本建立标识模式，安装获取和关联受控项时使用的工具。
3.软件配置控制
软件配置控制关注管理软件生命周期中的变更，它覆盖确定要作什么样的变更的过程、批准某些变更的权利职权、支持这些变更的实现，以及与项目需求偏离和放弃这些偏离的概念。
4.软件配置状态记录
软件配置状态记录要记录和报告进行有效的软件配置管理需要的信息。
5.软件配置审计
软件设计是独立评价软件产品和过程十分遵从已有的规则、标准、指南、计划和流程而进行的活动。
6.软件发布管理和交付
3.3.6 软件开发环境
3.3.7 软件过程管理
3.4 面向对象系统分析与设计
3.4.1 面向对象的基本概念
1.对象
对象是由数据及其操作所构成的封装体，是系统中用来描述客观事物的一个封装，是构成系统的基本单位，采用计算机语言描述，对象是由一组属性和对这组属性进行操作的一组服务构成。
对象包含三个基本要素，分别是对象标识、对象状态和对象行为。
每一个对象必须有一个名字用以区别于其他对象，这就是对象表示；状态用来描述对象的某些特征；对象行为用来封装对象所拥有的业务操作。
2.类
类是现实世界中实体的形式化描述，类将该实体的数据和函数封装在一起。类的数据也叫属性、状态或特征，它表现类静态的一面。类的函数也叫功能、操作或服务，它表现类动态的一面。
3.类和对象的关系
类和对象的关系可以总结为：
（1）每一个对象都是某一个类的实例
（2）每一个类在某一时刻都有零或更多的实例
（3）类是静态的，它们的存在、语义和关系在程序执行前就已经定义好了，对象是动态的，它们在程序执行时可以被创建和删除。
（4）类是生成对象的模板。
4.抽象
抽象是通过特定的实例抽取共同的特征以后形成概念的过程。
5.封装
封装是将相关的概念组成一个单元，然后通过一个名称来引用它。
6.继承
继承表示类之间的层次关系，这种关系使得某类对象可以继承另外一类对象的特征（attributes）和能力(operations)。
7.多态
多态是一种方法，这种方法使得在多个类中可以定义同一个操作或属性名，并在每个类中可以有不同的实现。
8.接口
所谓接口就是对操作规范的说明。
9.消息
消息（Message）是对象间交互的手段。
10.组件
组件时软件系统可替换的、物理的组成部分，它封装了实现体（实现某个职能），并提供了一组接口的实现方法。
11.模式
模式是一条有三部分组成的规则，它表示了一个特定的环境、一个问题和一个解决方案之间的关系。
12.复用
软件复用是指将已有的软件及其有效成分用于构造新的软件或系统。组件技术是软件复用实现的关键。
3.4.2 可视化建模与统一建模语言
1.统一建模语言
1）统一建模语言的概念
统一建模语言（Unified Modeling Language，UML）是一个通用的可视化建模语言，它是面向对象分析和设计的一种标准化表示，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。
2）统一建模语言的特征
3）UML的发展历史
2.UML的设计目标
3.UML视图
视图只是表达系统某一方面特征的UML建模组件的子集。
在最上一层，视图被划分成三个视图域：结构、动态行为和模型管理。
3.4.3 使用面向对象技术进行软件开发的最佳实践——RUP
RUP的6个基本最佳实践经验如下：
（1）迭代式开发。
（2）需求管理
（3）使用以组件为中心的软件架构
（4）可视化软件建模
（5）验证软件质量
（6）控制软件变更
3.4.4 面向对象系统分析
1.面向对象的分析模型
面向对象分析模型由用例模型、类-对象模型、对象-关系模型和对象-行为模型组成。
2.面向对象的分析方法
面向对象分析的主要目标如下：
（1）描述用户需要
（2）建立创建软件设计的基础
（3）定义软件完成后可被确认的一组需求
3.面向对象分析的步骤
（1）发现角色/参与者
（2）发现用例
（3）建立用例模型（user case model）
（4）进行领域分析
（5）建立对象-关系模型
（6）建立对象-行为模型
（7）建立功能模型
3.4.5 面向对象系统设计
1.用例设计
2.类设计
类是设计工作的核心，系统的实际工作其实也是由类执行的。
3.子系统设计
子系统是一种模型元素，它具有包（可包含其他模型元素）和类（具有行为）的语义。
3.5 软件架构
3.5.1 软件架构定义
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，并由构成系统的原始的描述及元素的相互作用、元素集成的模式以及这些模式的约束组成。
3.5.2 典型架构
1.管道/过滤器模式
在管道/过滤器架构模式中，每个构件都有一组输入/输出，构件读取输入的数据流，经过内部处理后，产生输出数据流，该过程主要完成输入流的变换及增量计算。通常，将这里的构件称为过滤器，其中的连接器就像是数据流传输的管道，将一个过滤器的输出传送到另一过滤器的输入。管道/过滤器输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
2.面向对象模式
3.事件驱动模式
事件驱动模式的基本原理是构件并不直接调用过程，而是触发一个或多个事件。系统中的其他构件可以注册相关的事件，触发一个事件时，系统会自动调用注册了该事件的构件过程，即触发事件会导致另一构件中过程的调用。
4.分层模式
分层模式采用层次化的组织方式，每一层都是为上一层提供服务，并使用下一层提供的功能。
分层模式的典型应用时分层通信协议，如ISO/OSI的七层网络模型。
5.知识库模式
知识库模式采用两种不同的构件：中央数据结构构件说明当前状态，独立构件在中央数据存储上执行，中央数据构件与独立的外部构件间的相互作用是系统的主要问题。
知识库模式有两种不同的控制策略：如果输入流触发进程执行的选择，则为基于传统数据库模型的知识库模式；如果中央数据结构的当前状态触发进程执行的选择，则为基于黑板系统的知识库模式。
黑板系统的典型应用时信号处理领域，如语音和模式识别。
黑板系统主要由以下三部分组成。
（1）知识源：包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
（2）黑板数据结构：按照与应用程序相关的层次来组织并解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
（3）控制：完全由黑板的状态驱动，黑板状态的改变决定了需要使用的特定知识。
6.客户机/服务器模式
<!--EndFragment-->