软考高级《系统架构设计师》知识点（十一）

面向对象技术

面向对象基础概念

对象：由数据及其操作所构成的封装体，是系统中用来描述客观事务的一个实体，是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。

类：现实世界中实体的形式化描述，类将该实体的属性(数据)和操作(函数)封装在一起。对象是类的实例，类是对象的模板。

类可以分为三种：实体类、接口类(边界类)和控制类。实体类的对象表示现实世界中真实的实体，如人、物等。接口类(边界类)的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其中人的接口可以是显示屏、窗口、Web窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。控制类的对象用来控制活动流，充当协调者。

抽象：通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征，忽略次要特征。一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。

封装：是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外提供的接口进行。

继承：表示类之间的层次关系(父类与子类),这种关系使得某类对象可以继承另外一类对象的特征，又可分为单继承和多继承。

多态：不同的对象收到同一个消息时产生完全不同的结果。包括参数多态(不同类型参数多种结构类型)、包含多态(父子类型关系)、过载多态(类似于重载，一个名字不同含义)、强制多态(强制类型转换)四种类型。多态由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在低层。

接口：描述对操作规范的说明，其只说明操作应该做什么,并没有定义操作如何做。

消息：体现对象间的交互，通过它向目标对象发送操作请求。

覆盖：子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法。

函数重载：与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。

绑定：是一个把过程调用和响应调用所需要执行的代码加以结合的过程。在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。

面向对象的分析：是为了确定问题域，理解问题。包含五个活动：认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。

面向对象的设计：是设计分析模型和实现相应源代码，设计问题域的解决方案，与技术相关。OOD同样应遵循抽象、信息隐蔽、功能独立、模块化等设计准则。

面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

面向对象的设计原则（面向对象方法中的五大原则）：

• 单一责任原则。就一个类而言，应该仅有一个引起它变化的原因。即，当需要修改某个类的时候原因有且只有一个，让一个类只做一种类型责任。
• 开放一封闭原则。软件实体(类、模块、函数等)应该是可以扩展的，即开放的；但是不可修改的，即封闭的。
• 里氏替换原则。子类型必须能够替换掉他们的基类型。即，在任何父类可以出现的地方，都可以用子类的实例来赋值给父类型的引用。
• 依赖倒置原则。抽象不应该依赖于细节，细节应该依赖于抽象。即，高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
• 接口分离原则。不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。即：依赖于抽象，不要依赖于具体，同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。

除了面向对象方法中的五大原则之外，RobertC.Martin提出的面向对象设计原则还包括以下几个：

• 重用发布等价原则。重用的粒度就是发布的粒度。
• 共同封闭原则。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
• 共同重用原则。一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
• 无环依赖原则。在包的依赖关系图中不允许存在环，即包之间的结构必须是一个直接的五环图形。
• 稳定依赖原则。朝着稳定的方向进行依赖。
• 稳定抽象原则。包的抽象程度应该和其稳定程度一致。

面向对象的测试，一般来说，对面向对象软件的测试可分为下列4个层次进行。

1. 算法层。测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试。
2. 类层。测试封装在同一个类中的所有方法与属性之间的相互作用。在向面对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块测试。
3. 模板层。测试一组协同工作的类之间的相互作用，大体上相当于传统软件测试中的集成测试，但是也有面向对象软件的特点(例如，对象之间通过发送消息相互作用)。
4. 系统层。把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。

UML

UML(统一建模语言)：是一种可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发的全过程。

从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

• 构造块。UML有三种基本的构造块，分别是事物(thing)、关系(relationship)和图(diagram)。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
• 公共机制。公共机制是指达到特定目标的公共UML方法。
• 规则。规则是构造块如何放在一起的规定。

结构事物：模型的静态部分，如类、接口、用例、构件等；

行为事物：模型的动态部分，如交互、活动、状态机；

分组事物：模型的组织部分，如包；

注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。

依赖：一个事物的语义依赖于另一个事物的语义的变化而变化。

关联：是一种结构关系，描述了一组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。

泛化：一般/特殊的关系，子类和父类之间的关系

实现：一个类元指定了另一个类元保证执行的契约。

类图：静态图，为系统的静态设计视图，展现一组对象、接口、协作和它们之间的关系。

对象图：静态图，展现某一时刻一组对象及它们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图。

用例图：静态图，展现了一组用例、参与者以及它们之、间的关系。用例图中的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一系列操作，用例之间的关系有扩展、包含、泛化。

序列图：即顺序图，动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。有同步消息(进行阻塞调用，调用者中止执行，等待控制权返回，需要等待返回消息，用实心三角箭头表示),异步消息(发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示)、返回消息(由从右到左的虚线箭头表示)三种。

通信图：动态图，即协作图，强调参加交互的对象的组织。

状态图：动态图，展现了一个状态机，描述单个对象在多个用例中的行为，包括简单状态和组合状态。转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。状态图中转换和状态是两个独立的概念。

活动图：动态图，是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。活动的分岔和汇合线是一条水平粗线。牢记下图中并发分岔、并发汇合、监护表达式、分支、流等名词及含义。每个分岔的分支数代表了可同时运行的线程数。活动图中能够并行执行的是在一个分岔粗线下的分支上的活动。

构件图(组件图)：静态图，为系统静态实现视图，展现了一组构件之间的组织和依赖。

部署图：静态图，为系统静态部署视图，部署图物理模块的节点分布。它与构件图相关，通常一个结点包含一个或多个构件。其依赖关系类似于包依赖，因此部署组件之间的依赖是单向的类似于包含关系。

并发与同步结构软件构件到物理结点映射:

• 逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
• 进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
• 实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
• 部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
• 用例视图。用例视图是最基本的需求分析模型。

SysML

SysML是一种通用图形建模语言，用于指定，分析，设计和验证可能包括硬件，软件，信息，人员，程序和设施的复杂系统。特别是，该语言提供了图形表示，其具有用于建模系统需求，行为，结构和参数的语义基础，用于与其他工程分析模型集成。

系统建模语言(SysML)：已成为基于模型的系统工程(MBSE)应用程序的事实上的标准系统架构建模语言。SysML是UML2的一种方言，它扩展了软件密集型应用程序的统一建模语言(UML)标准，使其可以成功应用于系统工程应用程序。

基于模型的系统工程(MBSE):又称基于模型的系统开发(MBSD),是一种系统工程过程范例，强调严格的体系结构建模原则和最佳实践应用于整个系统开发生命周期(SDLC)中的系统工程活动。这些系统工程活动包括但不限于需求分析，功能分析，性能分析，系统设计，贸易研究，系统架构规范以及系统验证和验证。

与UML相比，SysML为系统工程师提供了以下优于指定系统的优势：

• SysML比UML更好地表达系统工程语义(符号解释)。它减少了UML的软件偏差，并为需求管理和性能分析添加了两种新的图表类型：需求图和参数图。
• SysML比UML更小，更容易学习。由于SysML删除了许多以软件为中心和无偿的构造，因此在图表类型(9对13)和总结构中测量的整体语言较小。
• SysML模型管理构造支持模型，视图和视点的规范，这些规范在架构上与IEEE-Std-1471-2000(IEEE推荐的软件密集型系统架构描述实践)保持一致。
• SysML和UML间存在交集，即SysML语言中的部分图是和UML中的相应图是一致的，例如用例图。同时，SysML也有基于UML扩展而来的图，例如活动图。另外，还有一部分图是SysML所特有的，这些图与UML间没有关系，例如需求图。

SysML规定了七个需求关系:

1. 复合关系:复合需求可以包含需求层次结构中的子需求。复合需求可以声明系统应执行A和B,可以将其分解为系统应执行A和系统应进行B的子需求
2. 派生关系：派生的需求通常对应于系统层次结构下一级的需求。一个简单的例子是车辆加速需求，该需求被分析以导出发动机动力等方面的需求
3. 细化关系：细化关系可用于描述如何使用模型元素或元素集进一步细化需求。例如，可以使用用例或活动图来细化基于文本的功能需求
4. 满足关系：满足关系描述了设计或实现模型如何满足一个或多个需求。然后，系统建模者可以指定旨在满足要求的系统设计元素
5. 验证关系：验证关系定义了测试用例或其他模型元素如何验证需求。在SysML中，测试用例或其他元素可以用作表示任何标准检验方法的通用机制，分析，演示或测试。
6. 复制关系：真正需要跨产品系列和项目重用需求。典型的方案是适用于产品和/或产品系列中重复使用的项目和要求的法定法规或合同要求。
7. 追溯关系：追溯关系提供了需求和任何其他模型元素之间的通用关系。追溯关系对于将需求与源文档相关联或在规范树中的规范之间建立关系可能很有用。

模块定义图BDD和内部模块图IBD

创建IBD是为了指定单个模块的内部结构。和BDD—样，IBD是系统或者系统一个组成部分的静态(结构化)视图。和BDD不同的是，IBD不会显示模块，它会显示对模块的使用——也就是在IBD头部命名的模块的组成部分属性和引用属性。

在BDD中也可以显示组成部分属性和引用属性——或者是作为模块分隔框中的字符串，或者是作为关联一端的角色名称。但是IBD可以表达在BDD中无法表达的信息：组成部分属性和引用属性之间的连接；在连接之间流动的事件、能量和数据的类型；以及通过连接提供和请求的服务。

IBD会表达模块的组成部分必须如何组合才能够创建有效实例。它还会显示模块的实例必须如何与外部实体(引用属性)连接，以在整体上创建系统的有效实例。

参数图:SysML参数图是一种特殊的内部块图。和IBD一样，参数图会显示模块的内部结构，但是其关注点在于值属性和约束参数之间的绑定关系。因此，可以说，参数图和块定义图提供了模块的互补视图。