3.面向对象方法学

3.1.  面向对象基础

3.1.1.   基础概念

Ø  对象与类

对象是指一组属性以及这组属性上的专用操作的封装体；

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

Ø  继承

继承是在某个类的层次关联中不同的类共享属性和操作的一种机制；

一个子类只有唯一的一个父类，这种继承称为单一继承。一个子类有多个父类，可以从多个父类中继承特性，这种继承称为多重继承。

Ø  消息

消息是对象间通信的手段、一个对象通过向另一对象发送消息来请求其服务；

一个消息通常包括接收对象名、调用的操作名和适当的参数（如有必要）。

Ø  多态性和动态绑定

多态是指类中具有相似功能的不同函数是用同一名称来实现，从而可以使用相同的调用方式来调用这些具有不同功能的同名函数。

多态分为过载多态（重载多态）；强制多态；包含多态：通过虚函数来实现；参数多态。（前两个被称为专用多态，后两者被称为通用多态）

多态有分为编译时多态（静态绑定），运行时的多态（动态绑定）。

Ø  类库

类库是一种预先定义的程序库，它以程序模块的形式，按照类层次结构把一组类的定义和实现组织在一起。

Ø  类属类

如C++模板类。

一个类属类并不是一种真正的类类型；

类属类必须经过实例化后才能成为可创建对象实例的类类型；

类属类的实例化是指用某一数据类型替代类属类的类型参数。

 

3.1.2.   类的定义

 

Ø  访问指明符：private 、protected 、public

Ø  继承的限定：private 、protected 、public

 

3.1.3.   面向对象的方法

 

Ø  OOA和OOD方法（OOSE）

1．  OOA模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。

 

2．  OOD模型由4个部分组成，分别是设计问题域部分、设计人机交互部分、设计任务管理部分和设计数据管理部分。

Ø  Booch方法

1.       标识类和对象

2.       确定他们的含义

3.       标识他们之间的关系

4.       说明每一个类的界面（接口）和实现

Ø  OMT方法

1.       对象模型

 

2.       动态模型

 

3.       功能模型

 

 

3.2.  ※统一建模语言（UML）

Ø  UML是一个通用的可视化建模语言，用于对软件进行描述、可视化管理、构造和建立软件系统制品的文档；

Ø  UML包括概念的语义，表示法和说明，提供了静态、动态、系统环境及组织结构的模型。

Ø  UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。

Ø  UML标准没有定义一种标准的开发过程，但它适用于迭代式的开发过程。

3.2.1.   UML结构

Ø  构造块

1.       建模元素：结构元素、行业元素、分组元素、注解元素；

2.       关系：关联、依赖、泛化关系、实现关系等；

3.       图：9种图。类图、构件图、部署图；对象图、用例图、协作图、状态图等；包图。

Ø  公共机制

1.       规格说明（详细说明）

2.       修饰

3.       公共分类（通用划分）：类元（抽象）与实体（实际）；接口与实现。

4.       扩展机制

Ø  规则

为建模元素、关系和图命名

 

3.2.2.   用例图

 

Ø  包含关系：Include = use ,抽象用例

Ø  扩展关系：主用例与辅助用例

 

3.2.3.   类图与对象图

 

关系图例

 

3.2.4.   顺序图（交互图1）

 

3.2.5.   协作图（交互图2）

 

3.2.6.   状态图

 

3.2.7.   活动图

简单活动图

 

带泳道的活动图

、

3.2.8.   构件图

 

3.2.9.   部署图

 

3.3.  面向对象的分析

3.3.1.   建立域模型

Ø  寻找类

名词动词法

Ø  确定类之间的关联

Ø  为类添加职责（属性和方法）

Ø  域模型的详细度

3.3.2.   建立用例模型

Ø  用例的获取

执行者需要系统执行的主要任务是什么？

执行者需要在系统中创建、存储、修改、删除和读取数据么？

执行者需要告知系统突然发生的外部变动么？

系统的所有特性是否可被已经识别的用例实现？

执行者是否要执行系统的启动和关闭？

用例获取的结束条件：

1）  用户不能想出更动的用例；

2）  用户提出的新的用例可以通过已经获取的用例相关的功能需求来实现；

3）  用户新提出的需求涉及到具体的实现细节，可由有限的简单操作完成，其相应的用例粒度太小；

4）  用户提出的需求涉及到系统将来的特性，超出了当前的系统范围。

Ø  识别执行者

谁直接使用系统；

谁负责系统的维护工作？

系统使用的外部硬件。

要与本系统交换信息的其他系统。

谁将提供、使用、删除信息？

谁将使用这个功能？

谁对某一特定需求感兴趣？

谁负责系统某一方面的维护工作？

系统外部的资源是什么？

那些外部系统需要与系统的这一部分交互？

Ø  合并需求获得用例

将特征分配给相应的执行者；

进行合并操作。

Ø  绘制成用例图

Ø  细化用例描述

用例名称；

简要说明；

事件流；

非功能要求；

前置条件；

后置条件；

扩展点；

优先级（用满意度描述1-5）。

Ø  用户需求的用例模型

从所有的用例中识别出表达抽象行为的抽象用例，在基用例与这些抽象用例之间运用用例的包含、扩展和泛化关系建立联系。

在具有公共特性的执行者之间建立建立执行者的泛化关系。

Ø  功能需求的获取

1）  选择一个具有最高优先级用例

2）  场景分析

3）  用例分解

4）  用例判定

5）  对剩余的用例，重复（2）-（4）步

Ø  非功能需求的获取

非功能需求：易操作性、可靠性、可维护性、业务规则、各种法规、制度等。

非功能需求不能由用例分析得到。相反，其中一些非功能需求会对用例的实现具有制约作用。