软考高级知识点积累（一）
最近在准备软考高级，上半年以一分之差失之交臂。不看还是不行啊，潦草的看看吧。
以下知识点是在做真题的过程中牵连出来的我需要再看看的知识点。内容大部分来自网络。我作为搬运工，恬不知耻的发了原创。哈哈哈哈。
全篇没有逻辑，看到啥就记录啥。所以只能自己看，对别人应该帮助不大。
好了，废话说了一堆，开始上正文。
一、信息系统的生命周期可以分为4个阶段：立项、开发、运维、消亡。
1．立项阶段
即其概念阶段或需求阶段，这一阶段分为两个过程：一是概念的形成过程，根据用户单位业务发展和经营管理的需要，提出建设信息系统的初步构想；二是需求分析过程，即对企业信息系统的需求进行深入调研和分析，形成《需求规范说明书》，经评审、批准后立项。
2．开发阶段
该阶段又可分为以下阶段。
(1)总体规划阶段：是系统开发的起始阶段，以立项阶段所做的需求分析为基础，明确信息系统在企业经营战略中的作用和地位，指导信息系统的开发，优化配置并利用各种资源，包括内部资源和外部资源，通过规划过程规范或完善用户单位的业务流程。一个比较完整的总体规划应当包括信息系统的开发目标、总体结构、组织结构、管理流程、实施计划、技术规范。
(2)系统分析阶段：目标是为系统设计阶段提供系统的逻辑模型，内容包括组织结构及功能分析、业务流程分析、数据和数据流程分析及系统初步方案。
(3)系统设计阶段：根据系统分析的结果设计出信息系统的实施方案，主要内容包括系统架构设计、数据库设计、处理流程设计、功能模块设计、安全控制方案设计、系统组织和队伍设计及系统管理流程设计。
(4)系统实施阶段：是将设计阶段的成果在计算机和网络上具体实现，即将设计文本变成能在计算机上运行的软件系统。由于系统实施阶段是对以前全部工作的检验，因此用户的参与特别重要。
(5)系统验收阶段：通过试运行，系统性能的优劣及其他各种问题都会暴露在用户面前，即进入了系统验收阶段。
3．运维阶段
信息系统通过验收，正式移交给用户以后，就进入运维阶段，系统长时间的有效运行是检验系统质量的试金石。要保障系统正常运行，系统维护是不可缺少的工作。维护可分为4种类型：排错性维护、适应性维护、完善性维护、预防性维护。
4．消亡阶段
开发一个信息系统并希望它一劳永逸地运行下去是不现实的。企业的信息系统经常不可避免地会遇到系统更新改造、功能扩展，甚至报废重建等情况。对此，用户单位应当在信息系统建设的初期就注意系统消亡条件和时机，以及由此而花费的成本。
二、完整的需求分析应包括：获取用户需求、分析用户需求、编写需求说明书、需求评审
三、病毒，木马，蠕虫区别：
首先病毒，木马，蠕虫统称为电脑病毒。病毒（包含蠕虫）的共同特征是自我复制、传播、破坏电脑文件，对电脑造成数据上不可逆转的损坏。而木马独有特征是伪装成正常应用骗取用户信任而入侵，潜伏在电脑中盗取用户资料与信息。
什么是病毒：是编制者在计算机程序中插入的破坏计算机功能或者数据的代码，能影响计算机使用，能自我复制的一组计算机指令或者程序代码。
什么是木马：也称木马病毒，是指通过特定的程序来控制另一台计算机。与一般的病毒不同，它不会自我繁殖，也并不“刻意”地去感染其他文件，它通过将自身伪装吸引用户下载执行，向施种木马者提供打开被种主机的门户，使施种者可以任意毁坏、窃取被种者的文件，甚至远程操控被种主机。
什么是蠕虫病毒：一种能够利用系统漏洞通过网络进行自我传播的恶意程序。它不需要附着在其他程序上，而是独立存在的。当形成规模、传播速度过快时会极大地消耗网络资源导致大面积网络拥塞甚至瘫痪。
四、UML的9种图
UML图包括九种：用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、配置图。
类图：类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图——专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和操作。
对象图：对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。
用例图：用例图展现了一组用例、参与者以及它们间的关系。可以用用例图描述系统的静态使用情况。在对系统行为组织和建模方面，用例图的是相当重要的。
交互图：交互图展现了按一定的目的进行的一种交互，它由在一个上下文中的一组对象及它们间交互的信息组成。交互图也可用于描述一个用例的行为。顺序图和协作图都是交互图，顺序图和协作图可以相互转换。
顺序图：展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。用顺序图说明系统的动态视图。
协作图：展现了一组对象，这组对象间的连接以及这组对象收发的消息。它强调收发消息的对象的结构组织，按组织结构对控制流建模。
状态图：展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用例实例的生命周期。
活动图：活动图是一种特殊的状态图，描述需要做的活动、执行这些活动的顺序（多为并行的）以及工作流（完成工作所需要的步骤）。它对于系统的功能建模特别重要，强调对象间的控制流程。
高层活动图用于表示需要完成的一些任务，即用于分析用例，理解涉及多个用例的工作流、多线程及并行，显示相互联系的行为整体，还可用于对企业过程建模，对系统的功能建模。低层活动图用于表示类的方法。但活动图不适用于描述动作与对象间的关系，显示对象间的合作以及显示对象在生命周期内的运转情况。
构件图：构件图展现了一组构件之间的组织和依赖，用于对原代码、可执行的发布、物理数据库和可调整的系统建模。
部署图：部署图展现了对运行时处理节点以及其中构件的配署。它描述系统硬件的物理拓扑结构(包括网络布局和构件在网络上的位置)，以及在此结构上执行的软件（即运行时软构件在节点中的分布情况）。用部署图说明系统结构的静态部署视图，即说明分布、交付和安装的物理系统
五、UML 中类图实例说明
接口：空心圆+直线（唐老鸭类实现了‘讲人话’）；
依赖：虚线+箭头（动物和空气的关系）；
关联：实线+箭头（企鹅需要知道气候才迁移）；
聚合：空心四边形+实线+箭头（雁群和大雁的关系）；
合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；
泛化/继承：空心三角形+实线（动物和鸟的继承关系）；
实现：空心三角形+虚线（实现大雁飞翔的接口）；
解释UML类图：
1.首先看“动物”矩形框，它代表一个类。该类图分为三层，第一层显示类的名称，如果是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。
注意前面的符号，‘+’表示public, ‘—’表示private, ‘#’表示protected.
2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显示，第一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。
interfaceIFly interfaceIlanguage
{ {
voidFly(); voidSpeak();
} }
3.动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实现来表示。
4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表示。（注：下面的图中应为空心三角形）
classBird:Animal
classWideGoose:IFly
{ {
//继承动物类
//实现飞翔接口
} }
5.企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。当一个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。
classPenguin :Bird
{
privateClimate climate;//在企鹅Penguin中，引用到气候Climate对象
}
6. “大雁”和“雁群”这两个类。大雁是群居动物，每只大雁都属于一个雁群，一个雁群可以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。聚合关系用空心的菱形+实线箭头表示。
classWideGooseAggregate
{
privateWideGoose[] arrayWideGoose;
//在雁群WideGooseAggregate类中，有大雁数组对象arrayWideGoose
}
7. “鸟”和“翅膀”这两个类。鸟和翅膀似整体和部分的关系，并且翅膀和鸟的生命周期是相同的，在这里鸟和其翅膀就是合成关系。合成(composition)是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。合成关系用实心的的菱形+实线箭头来表示。另外，合成关系的连线两端还有一个数字“1”和数字“2”，，这被称为基数。表明这一端的类可以有几个实例，很显然，一个鸟应该有两支翅膀。如果一个类可能有无数个实例，则就用“n”来表示。关联关系，聚合关系也可以有基数的。
classBird
{
privateWing wing;
publicBird()
{
wing=newWing();
//在鸟Bird类中，初始化时，实例化翅膀Wing,它们之间同时生成
}
}
8. “动物”、“氧气”与“水”之间。动物有几大特征，比如有新陈代谢，能繁殖。而动物要有生命，需要氧气，水以及食物等。也就是说动物依赖于氧气和水。它们之间是依赖关系(Dependency),用虚线箭头来表示。
abstract classAnimal
{
publicbolism(Oxygen oxygen,Water water)
{
}
}
六、信息系统集成专业技术知识：SOA 与Web Service
SOA（Service-OrientedArchitecture，面向服务的体系结构）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S 模型、XML/Web Service技术之后的自然延伸。Web Service 即Web服务。
在理解SOA 和Web 服务的关系上，经常发生混淆。Web服务是技术规范，而SOA是设计原则。特别是Web 服务中的WSDL（Web ServicesDescription Language，Web服务描述语言），是一个SOA配套的接口定义标准，这是Web 服务和SOA 的根本联系。从本质上来说，SOA是一种架构模式，而Web 服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用Web 服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。
Web Service是解决应用程序之间相互通信的一项技术。严格地说，Web Service是描述一系列操作的接口。它使用标准的、规范的XML描述接口。这一描述中包括与服务进行交互所需要的全部细节，包括消息格式、传输协议和服务位置。而在对外的接口中隐藏了服务实现的细节，仅提供一系列可执行的操作，这些操作独立于软、硬件平台和编写服务所用的编程语言。Web Service既可单独使用，也可同其他Web Service一起，实现复杂的业务功能。
在Web Service 模型的解决方案*有三种工作角色，其中服务提供者（服务器）和服务请求者（客户端）是必需的，服务注册中心是一个可选的角色。它们之间的交互和操作（如图1-4-11 所示）构成了Web Service的体系结构。服务提供者定义并实现Web Service，然后将服务描述发布到服务请求者或服务注册中心；服务请求者使用查找操作从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定并调用Web Service。
与Web Service 有关的协议和术语还有SOAP、XML、UDDI、XSD、WSDL 等。
XML（Extensible Markup Language，可扩展标记语言）规定了服务之间以及服务内部数据交换的格式和结构，通过XML 可以将任何文档转换成XML 格式，然后跨越因特网协议传输。XML 是Web service 表示数据的基本格式。除了易于建立和易于分析外，XML 主要的优点在于它既是平台无关的，又是厂商无关的。
XML 解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16 位，32 位，还是64 位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service就是用XSD来作为其数据类型系统的。
Web service建好以后，你或者其他人就会去调用它。SOAP（Simple Object Access Protocol，简单对象访问协议）提供了标准的RPC方法来调用Webservice。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。
Web Service有什么功能，调用的函数参数数据类型是什么，有几个参数等等，这些描述就需要一种语言，这就是WSDL（Web Services Description Language，Web服务描述语言）了。WSDL本身其实就是一个标准的XML文档，用于描述Webservice及其函数、参数和返回值。 UDDI（Universal Description, Discovery and Integration，通用描述、发现与集成服务）是一种目录服务，可以使用它对 Web services 进行注册和搜索。
UDDI是一个分布式的互联网服务***制，它集描述、检索与集成为一体，其核心是***制。UDDI实现了一组可公开访问的接口，通过这些接口，网络服务可以向服务信息库注册其服务信息、服务需求者可以找到分散在世界各地的网络服务。