【软考系统架构设计师】面向对象的分析与设计(1)-基本概念

【软考系统架构设计师】面向对象的分析与设计

1、面向对象的基本概念

1.1、对象和类

对象是系统中用来描述客观事物的一个实体，它由==对象标识（名称）、属性和服务（操作、行为、方法）==三个要素组成，他们被封装为一个整体，以接口的形式对外提供服务。
类是对具有相同属性和服务的一个或一组对象的抽象，类与对象是抽象描述和具体实例的关系，一个具有的对象被称为类的一个实例。在系统设计过程中，类可以分为三种类型，==分别为实体类、边界类、控制类。

• 实体类：实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。
  实体类是对用户来说最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型的转化中，一个参与者一般对应于实体类。通常可以从SRS 中的那些与数据库表（需要持久存储）对应的名词着手来找寻实体类。通常情况下，实体类一定有属性，但不一定由操作。
• 控制类：控制类是用于控制用例工作的类，一般是由动宾结构的短语 （“动词+名词”或“名词+动词”）转化来的名词，例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象（控制类的实例）通常控制其他对象，因此，它们的行为具有协调性。
  控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡通常情况下，控制类没有属性，但一定有方法。
• 边界类： 边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。边界类是一种用于对系统外部环境与其内部运作之间的交互
  进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。
  边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更（例如，与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。

1.2、继承与泛化

继承是面向对象方法中重要的概念，用来说明特殊类（子类）与一般类（父类）的关系，而通常用泛化来说明一般类与特殊类的关系，也就是说它们是一对多关系。
如图所示，“交通工具”是“自行车”和“小轿车”的泛化；“自行车”和“小轿
车”从“交通工具”中继承。

1.3、多态与重载

多态（即多种形式）性是指一般类中定义的属性或服务被特殊类继承后，可以具有不同的数据类型或表现出不同的行为，通常是使用重载和改写两项技术来实现的。一般有4种不
同形式的多态，如表所示。

• 注1：重载也称为过载、重置；
• 注2：参数多态和包含多态称为通用多态，重载多态和强制多态称为特定多态。
  ** TIPS：**虽然重载和改写都是在多种潜在的函数体中，选择和调用某一个函数或方法并对其进行执行，但它们的本质区别在于：重载是编译时执行的 （静态绑定），而改写则是运行时选择的 （动态绑定）

1.4、模板类

也称为类属类，它用来实现参数多态机制。一个类属类是关于一组类的一个特性抽象，它强调的是这些类的成员特征中与具体类型无关的那些部分，而用变元来表示与具体类型有关的那些部分。

1.5、消息和消息通信

==消息就是向对象发出的服务请求，它通常包括提供服务的对象标识、消息名、输入信息和回答信息。==消息通信则是面向对象方法学中的一个重要原则，它与对象的封装原则密不可分，为对象间提供了唯一合法的动态联系的途径。

2、面向对象分析

面向对象分析的目标是开发一系列模型，这些模型描述计算机软件，当它工作时以满足一组客户定义的需求。对象技术的流行，演化出了数十种不同的OOA方法，每个方法都引入了一个产品或系统分析的过程、一组过程演化的模型及使软件工程师能够以一致的方式创建每个模型的符号体系。其中比较流行的方法包括OMT、OOA、OOSE、Booch方法等，而OMT、0OSE、Booch最后则统一成为UML。

2.1、00A/OOD方法

这是由Peteroad和EdwardYourdon提出的，OOA模型中包括主题、对象类、结构、属性和服务5个层次，需经过标识对象类、标识结构与关联（包括继承、聚合、组合、实例化等）、划分主题、定义属性、定义服务5个步骤来完成整个分析工作。
0OD中将继续贯穿OOA中的5个层次和5个活动，它由人机交互部件、问题域部件、任务管理部件、数据管理部件4个部分组成，其主要的活动就是这4个部件的设计工作。设计问题域部分：0OA的结果恰好是OOD的问题域部件，分析的结果在OOD中可以被改动或增补，但基于问题域的总体组织框架是长时间稳定的；
设计人机交互部件：人机交互部件在上述结果中加入人机交互的设计和交互的细节，包括窗口和输出报告的设计。可以用原型来帮助实际交互机制进行开发和选择；
设计任务管理部分：这部分主要是识别事件驱动任务，识别时钟驱动任务，识别优先任务和关键任务，识别协调者，审查每个任务并定义每个任务。
设计数据管理部分：数据管理部分提供了在数据管理系统中存储和检索对象的基本结构，其目的是隔离数据管理方法对其他部分的影响。

2.2、Booch方法

Booch认为软件开发是一个螺旋上升的过程，每个周期中包括标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现4个步骤。它的模型中主要包括如表所示的几种图形。

Booch方法的开发过程是一个代的、渐进式的系统开发过程，它可以分为宏过程和微过程两类。宏过程用于控制微过程，是役盖几个月或几周所进行的活动，它包括负责建立核心需求的概念化，为所期望的行为建立模型的分析，建立架构的设计，形成实现的进化，以及管理软件交付使用的维护等5个主要活动
而微过程则基本上代表了开发人员的日常活动，它由4个重要、没有顺序关系的步骤组成：在给定的抽象层次上识别出类和对象，识别出这些类和对象的语义，识别出类间和对象间的关系，实现类和对象

2.3、OMT方法

OMT是对象建模技术的缩写，它是由JamRambaugh及其同事合作开发的，它主要用于分析、系统设计和对象设计。包括对象模型（静态的、结构化的系统的“数据”性质，通常采用类图）、动态模型（瞬时的、行为化的系统“控制”性质，通常使用状态图）和功能模型（表示变化的系统的“功能”性质，通常使用数据流图）。OMT方法的三大模型如表所示。.

2.4、OOSE方法

OOSE是面向对象软件工程的缩写，它是由IvarJacobson提出的。它在OMT的基础上，对功能模型进行了补充，提出了“用例”的概念，最终取代数据流图进行需求分析和建立功能模型。

3、统一建模语言

统一建模语言（UnifiedModelingLanguage，UML）是用于系统的可视化建模语言，它将OMT、OOSE和Booch方法中的建模语言和方法有机地融合在一起，是国际统一的软件建模标准。虽然它源于OO软件系统建模领域，但由于其内建了大量扩展机制，也可以应用于更多的领域中，例如工作流程、业务领域等

3.1、UML是什么

• UML是一种语言：UML在软件领域中的地位与价值就像“1、2、3、+、 等符号在数学领域中的地位一样。它为软件开发人员之间提供了一种用于交流的词汇表和一种用于软件蓝图的标准语言。
• UML是一种可视化语言：UML只是一组图形符号，它的每个符号都有明确语义，是一种直观、可视化的语言。
• UML是一种可用于详细描述的语言：UML所建的模型是精确的、无岐义和完整的，因此适合于对所有重要的分析、设计和实现决策进行详细描述
• UML是一种构造语言：UML虽然不是一种可视化的编程语言，但其与各种编程语言直接相连，而且有较好的映射关系，这种映射允许进行正向工程、逆向工程。
• UML是一种文档化语言：它适合于建立系统架构及其所有的细节文档。

3.2、UML的结构

UML由构造块、公共机制和架构三个部分组成
（1）构造块
构造块也就是基本的UML建模元素（事物）、关系和图建模元素：包括结构事物（类、接口、协作、用例、活动类、组件、节点等）、行为事物（交互、状态机）、分组事物（包）、注释事物
关系：包括关联关系、依赖关系、泛化关系、实现关系。
图：UML2.0包括14种不同的图，分为表示系统静态结构的静态模型（包括类图、对象图、包图、构件图、部署图、制品图），以及表示系统动态结构的动态模型（包括对象图、用例图、顺序图、通信图、定时图、状态图、活动图、交互概览图）。
（2）公共机制
公共机制是指达到特定目标的公共UML方法，主要包括规格说明、修饰、公共分类和扩展机制4种。

• 规格说明：规格说明是元素语义的文本描述，它是模型的重要组成部分。
• 修饰：UML为每一个模型元素设置了一个简单的记号，还可以通过修饰来表达更多的信息。
• 公共分类：包括类元与实体（类元表示概念，而实体表示具体的实体）、接口和实现（接口用来定义契约，而实现就是具体的内容）两组公共分类
• 扩展机制：包括约束（添加新规则来扩展元素的语义）、构造型（用于定义新的UML建模元素）、标记值（添加新的特殊信息来扩展模型元素的规格说明）。

（3）架构
UML对系统架构的定义是：系统的组织结构，包括系统分解的组成部分、它们的关联性、交互、机制和指导原则，这些提供系统设计的信息。而具体来说，就是指5个系统视图。

逻辑视图：以问题域的语汇组成的类和对象集合。
进程视图： 可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例
实现视图：对组成基于系统的物理代码的文件和组件进行建模。
部署视图：把组件物理地部署到一组物理的、可计算的节点上。
用例视图： 最基本的需求分析模型

3.3、用例图基础

用例是什么呢？lvarJacobson是这样描述的：“用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。”首先，从定义中得知用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景。其次，可以知道，用例应该给参与者带来可见的价值，这
点很关键。最后，用例是在系统中的
而用例模型描述的是外部参与者所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。