【系统分析师】-面向对象方法

目录

1、基本概念

2、UML

2.1、基本结构

2.1.1.构造块

2.1.1.1、事物

2.1.1.2、关系

2.1.1.3、图形

2.1.2.规则

2.1.3.公共机制

2.2、4+1视图

3、面向对象分析OOA

3.1、用例模型

3.2、分析模型

4、面向对象设计OOD

4.1、细分

4.2、设计原则

5、面向对象的程序设计OOP

6、面向对象测试OOT

6.1、从低到高的层次

6.2、测试分类

7、设计模式

---

考点整理：

(1)信息系统综合知识

• 统一建模语言：熟练掌握 UML(2.x版)的图形表示、含义和用法。
• 面向对象的分析：熟练掌握继承、抽象、封装、多态的概念和用法;面向对象分析的基本概念;利用UML对系统需求建模，熟练掌握基于场景的建模
• 面向对象的设计：面向对象设计方法;利用UML对软件设计建模:熟练掌握面向对象程序设计;掌握设计模式。
• 面向对象软件的测试：面向对象软件的测试层次。
• 设计模式：23 种模式的定义和结构。.

(2)系统分析设计案例

• 对象业务流的提取和确认：在面向对象的系统中，提取基于对象的业务流程，使用对象交互(活动图，顺序图等)的方式确认业务流程。
• 用例驱动的开发方式：说明用例驱动开发的原则和注意事项，结合具体案例，给出采用用例开发的方式和具体过程。
• 面向对象建模技术：结合具体案例，说明在采用某种具体的面向对象建模技术(UML等)进行系统建模时需要考虑的因素，并给出具体的模型;面向对象的系统分析方法，能够结合案例采用某种方法进行具体分析;当采用面向对象分析方法进行系统分析时，系统的功能划分方式和数据资源分布。

(3)系统分析设计论文

包括结合项目实践说明如何采用面向对象的思想和技术进行系统分析、系统设计、系统构建;

面向对象软件的测试策略。

1、基本概念

1、对象

指一组属性及这组属性上的专用操作的封装体

对象名、属性、操作

2、类

类是一组具有相同属性和相同操作的对象的集合。

类型、属性、操作

实体类：现实中的真实实体

边界类：为用户提供一种与系统交互的方式。显示器、窗口、表单、条形码、系统接口等

控制类：控制活动流，充当协调者

3、三大特性

1）继承：子类可以使用父类的属性、方法

如果B类继承A，则A是B的泛化

2）封装：对象之间只能通过封装的接口进行调用，信息隐藏

3）多态：同一个操作作用于不同的对象产生不同的结果，动态绑定

2、UML

2.1、基本结构

UML 的结构包括 UML的基本构造块、支配这些构造块如何放在一起的规则(体系结构)和一些运用于整个 UML的机制。

2.1.1.构造块

UML有三种基本的构造块，分别是

事物(thing)、关系(relationship)和图(diagram)

事物是 UML中重要的组成部分，

关系把事物紧密地联系在一起，

图是很多有相互相关的事物的组。

2.1.1.1、事物

1）结构事物

结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。总共有七种结构事物:

第一种是类，类是描述具有相同属性、方法、关系和语义的对象的集合。一个类实现一个或多个接口。

第二种是接口，接口是指类或构件提供特定服务的一组操作的集合。一个接口描述了类或构件的对外的可见的动作。一个接口可以实现类或构件的全部动作，也可以只实现一部分。

第三种是协作，协作定义了交互的操作，是一些角色和其他元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。因此，协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成部分。这些协作代表构成系统的模式的实现。

第四种是用例，用例是描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的值。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。

第五种是活动类，它的对象有一个或多个进程或线程。活动类和类很相似，只是它的对象代表的元素的行为和其他的元素是同时存在的。

第六种是构件，构件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，可能会遇到不同种类的构件。

第七种是节点，节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。

2）行为事物

行为事物是 UML 模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。总共有两种主要的行为事物。

第一种是交互(内部活动)，交互是由在一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作。

交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序(消息产生的动作)、连接(对象之间的连接)。

第二种是状态机，状态机由一系列对象的状态组成。

3）分组事物

分组事物是 UML 模型中组织的部分，可以把它们看成是个盒子，

包是一种将有组织的元素分组的机制。

结构事物、行为事物甚至其他的分组事物都有可能放在一个包中。

与构件(存在于运行时)不同的是包纯粹是一种概念上的东西，只存在于开发阶段。

4）注释事物

UML模型的解释部分。

2.1.1.2、关系

关系把事物连接在一起

2.1.1.2.1、UML四种关系

(1)依赖(dependencies)

两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。

(2)关联(association)

一种描述一组对象之间连接的结构关系，如聚合关系(描述了整体和部分间的结构关系)、组合关系（同一个生命周期）。

(3)泛化(generalization)

一种一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。

(4)实现(realization)

类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

2.1.1.2.2、用例之间关系

(1)包含关系

用于重用的包含关系，用构造型<<include>>或<<use>>表示

当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例很重要的部分功能时,应该使用包含关系来表示它们。其中提取出来的公共用例称为抽象用例。

例如，图书订单处理系统中，“创建新订单”和“更新订单”两个用例都需要检查客户的账号是否正确，为此定义一个抽象用例“核查客户账户”。用例“创建新订单’和“更新订单”与用例“核查客户账户”之间的关系就是包含关系。

(2)扩展关系

用于分离出不同行为的扩展关系，用构造型<<extend>>表示。

如果一个用例明显地混合了两种或两种以上的不同条件场景，即根据情况可能发生多种事情，则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。

例如，图书管理系统中，读者归还图书时，需要判断当前日期是否已经超过了图书借阅的周期。如果超过了借阅周期，则必须罚款。“归还图书”和“罚款”用例之间的关系就是扩展关系。

(3)泛化关系

用例可以被特别列举为一个或多个子用例，这被称做用例泛化。

当父用例能够被使用时;任何子用例也可以被使用。

例如，购买飞机票时，既可以通过电话订票，也可以通过网上订票，则订票用例就是电话订票和网上订票的泛化。

2.1.1.2.3、类之间的关系

与UML的关系基本一致

(1)关联关系

描述了给定类的单独对象之间语义上的连接。关联提供了不同类之间的对象可以相互作用的连接。其余的关系涉及类元自身的描述，而不是它们的实例。

 (2)聚合关系

聚合是一种特殊形式的关联，它是传递和反对称的。聚合表示类之间的关系是整体与部分的关系。例如一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘，就是聚合的一个例子。在UML中，使用一个带空心菱形的实线 表示聚合关系，空心菱形指向的是代表“整体”的类。

(3)组合关系

如果聚合关系中的表示“部分”的类的存在与否，与表示“整体”的类有着紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示这种关系。在UML中，使用带有实心菱形的实线 表示组合关系。

(4)依赖关系

有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素依赖于元素X。在UML 中，使用带箭头的虚线表示依赖关系。
在类中，依赖由各种原因引起，例如，一个类向另一个类发送消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类的接口改变，则它发出的任何消息都可能不再合法。

(5)泛化关系

泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线 表示泛化关系，箭头指向父类。

(6)实现关系

将说明和实现联系起来。接口是对行为而非实现的说明，而类之中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。

(7)流关系

将一个对象的两个版本以连续的方式连接起来。它表示一个对象的值状态和位置的转换。流关系可以将类元角色在一次相互作用中连接起来。流的种类包括变成(同一个对象的不同版本)和复制(从现有对象创造出一个新的对象)两种。

2.1.1.3、图形

(1)类图(class diagram)

描述一组类、接口、协作和它们之间的关系。

类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。

(2)对象图(object diagram)

描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。

和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是以真实案例或原型案例的角度建立的。

(3)构件图(component diagram)

描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。

构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。

(4)组合结构图(compositestructure diagram)

描述结构化类(例如构件或类)的内部结构，包括结构化类与系统其余部分的交互点。它显示联合执行包含结构化类的行为的构件配置。组合结构图用于画出结构化类的内部内容。

(5)用例图(use case diagram)

描述一组用例、参与者(一种特殊的类)及它们之间的关系。 

用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。

(6)顺序图(sequence diagram，序列图)

一种交互图(interaction diagram)，交互图展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。

基本元素：对象、参与者、生命线、激活框、消息、消息路线

(7)通信图(communication diagram)

一种交互图，它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念，但每种图所强调的概念不同，顺序图强调的是时序，通信图则强调的是消息流经的数据结构。

(8)定时图(timing diagram，计时图)

一种交互图，它强调消息跨越不同对象或角色的实际时间，而不仅仅只是关心消息的相对顺序。

(9)状态图(state diagram)

描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。

(10)活动图(activity diagram)

将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模特别重要，并强调对象间的控制流程。

(11)部署图(deploymentdiagram)

描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了体系结构的静态部署视图,通常一个节点包含一个或多个部署图。

(12)制品图(artifactdiagram)

描述计算机中一个系统的物理结构。制品包括文件数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。

(13)包图(package diagram)

描述由模型本身分解而成的组织单元，以及它们的依赖关系。

(14)交互概览图(interactionoverviewdiagram)

是活动图和顺序图的混合物。

2.1.2.规则

UML 用于描述事物的语义规则分别是为事物、关系和图命名。

给一个名字以特定含义的语境，即范围;

怎样使用或看见名字，即可见性;

事物如何正确、一致地相互联系，即完整性;

运行或模拟动态模型的含义是什么，即执行。

2.1.3.公共机制

公共机制是指达到特定目标的公共UML方法，主要包括

(1)规格说明

规格说明是元素语义的文本描述，它是模型真正的核心。

(2)修饰

UML 为每一个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息。

(3)公共分类

包括类元与实体(类元表示概念，而实体表示具体的实体)、接口和实现(接口用来定义契约，而是实现就是具体的内容)两组公共分类。

(4)扩展机制

包括约束(添加新规则来扩展事物的语义)、构造型(用于定义新的事物)、标记值(添加新的特殊信息来扩展事物的规格说明)。

2.2、4+1视图

区分与系统架构的4+1，UML以用例为核心

(1)逻辑视图：以问题域的语汇组成的类和对象集合。

(2)进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。

(3)实现视图：对组成基于系统的物理代码的文件和构件进行建模。

(4)部署视图：把构件部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。

(5)用例视图：最基本的需求分析模型。

3、面向对象分析OOA

OOA 就是直接以问题域中客观存在的事物或概念识别为对象，建立分析模型，用对象的属性和服务分别描述事物的静态特征和行为，并且保留问题域中事物之间关系的原貌。

问题域指一个包含现实世界事物与概念的领域，这些事物和概念与所设计的系统要解决的问题有关

分析模型独立于具体实现，即不考虑与系统具体实现有关的因素

OOA的任务是“做什么”，

OOD的任务是“怎么做”

3.1、用例模型

构建过程：

1、识别参与者

主要参与和次要参与者

开发用例的重点是找到主要参与者

2、合并需求获取用例

业务用例和系统用例

3、细化用例描述

用例建模的主要工作是书写用例规约，而不是画图

用例模板：用例名、参与者、目标、前置条件、事件流（基本事件、扩展事件）、后置条件

还包括非功能性需求、用例优先级

3.2、分析模型

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及如何保持通信实现系统行为（动态模型）。

每个用例对应一个类图

使用领域模型

分析建模的基本活动：

1、发现领域对象，定义概念类

2、识别对象属性

3、识别对象关系：包括建立类的泛化关系、对象的关联关系

4、为类添加职责

5、建立交互图：顺序图、通信图、定时图、交互概览图

4、面向对象设计OOD

4.1、细分

1）系统设计：确定实现系统的策略和目标系统的高层结构

2）对象设计：确定解空间中的类、关联、接口形式以及实现操作的算法

基本原则：模块化、抽象、信息隐藏、高内聚、低耦合

4.2、设计原则

1）单一职责：一个类/接口一个职责

2）开闭原则：对扩展开放，对修改关闭

3）李氏替换：子类可以替换父类的存在，子类是扩展父类的责任，但不能重写责任。在使用基类时，不需要考虑子类是否存在，是否有影响。

4）依赖倒置：依赖于高层的抽象（接口），而不是具体的实现

5）接口隔离：对外提供更多更单一功能的接口，而不是提供一个总接口

6）组合重用：使用组合代替继承关系

7）迪米特：最少知识原则，要求类暴露最少的接口、属性、功能

5、面向对象的程序设计OOP

6、面向对象测试OOT

更早的提出测试用例。

6.1、从低到高的层次

(1)算法层

测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试。

(2)类层

测试封装在同一个类中的所有方法与属性之间的相互作用。在面向对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块(单元)测试。

(3)模板层

也称为主题层，测试一组协同工作的类或对象之间的相互作用。大体上相当于传统软件测试中的子系统测试，但是也有面向对象软件的特点(例如:对象之间通过发送消息相互作用)。

(4)系统层

把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。

6.2、测试分类

1）黑盒测试

功能测试，是一种基于软件需求规格说明书进行的测试方法。

2）白盒测试

又称结构测试或透明盒测试，是一种基于软件内部结构和逻辑进行的测试方法。测试人员需要了解程序的源代码、数据结构、算法等内部信息，通过检查数据流、控制流、循环覆盖等指标来评估软件质量。

验证软件内部结构、代码覆盖率和路径执行

3）灰盒测试

灰盒测试是介于黑盒测试与白盒测试之间的一种测试方法。它不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试者可能知道系统组件之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解。

灰盒测试多用于集成测试阶段，以确保软件的质量和提高软件质量。它结合了黑盒和白盒测试的优点，既关注外部功能，又考虑内部逻辑。

如：API接口测试、数据库交互测试

7、设计模式

带 * 的表示类，其他是对象

本章节内容建议使用  软考真题 APP 加以训练。

具体位置如下：
1）“章节练题” >> "第十章 软件工程"

2）“知识点练题” >> "面向对象方法学"