第7章 面向对象方法基础

面向对象的基本概念

• 面向对象方法的世界观：一切系统都是由对象构成的，他们的相互作用、相互影响，构成了大千世界的各式各样系统。
• 面向对象方法是一种以对象、对象关系等来构造软件系统模型的系统化方法。
  面向对象 = 对象（object ） + 分类（classification） + 继承（inheritance） + 通过消息的通信（communication with messages）
• 一个对象通常可由对象名、属性和操作三部分组成

  1. 对象（object）
     对象是指一组属性以及这组属性上的专用操作的封装体
     属性（attribute）通常是一些数据，有时它也可以是另一个对象。每个对象都有它自己的属性值，表示该对象的状态。对象中的属性只能通过该对象所提供的操作来存取或修改
     操作（operation）（也称方法或服务）规定了对象的行为，表示对象所能提供的服务
     封装（encapsulation）是一种信息隐蔽技术，用户只能看见对象封装界面上的信息，对象的内部实现对用户是隐蔽的。封装的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。简而言之，对象的属性和操作结合为一体，构成一个独立的实体，对外屏蔽其内部细节即为封装

  2. 类（class）
     类是一组具有相同属性和相同操作的对象的集合。一个类中的每个对象都是这个类的一个实例（instance）
     类是创建对象的模板，从同一个类实例化的每个对象都具有相同的结构和行为
     

  3. 继承（inheritance）
     继承是类间的基本关系，它是基于层次关系的不同类共享数据和操作的一种机制。父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和操作外，可以继承其父类（或祖先类）的属性和操作，还可以对父类（或祖先类）中的操作重新定义其实现方法
     如果一个子类只有唯一一个父类，这种继承称为单一继承。如果一个子类有一个以上的父类，这种继承称为多重继承

  4. 消息（message）
     对象之间只能通过消息进行通信（不允许一个对象直接使用另一个对象的属性），以实现对象直接的动态联系。一个对象通过向另一个对象发送消息来请求其服务。**一个消息通常包括接收对象名、调用的操作名和适当的参数（如果有必要的话）。**消息只告诉接收对象需要完成什么操作，但并不指示接收者怎样完成操作。消息完全由接收者解释，接收者独立决定采用什么方法完成所需的操作

  5. 多态性（polymorphism）
     多态性是指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。例如“画”操作，作用在“矩形”对象上，则在屏幕上画一个矩形，作用在“圆”对象上，则在屏幕上画一个圆。也就是说，相同操作的消息发送给不同的对象时，每个对象将根据自己所属类中定义的这个操作去执行，从而产生不同的结果

  6. 动态绑定（dynamic binding）
     动态绑定是指在程序运行时才将消息所请求的操作与实现该操作的方法连接起来
     传统的程序设计语言的过程调用与目标代码的连接（即调用哪个过程）放在程序运行前（即编译时）进行（称为静态绑定），而动态绑定则是把这种连接推迟到运行时才进行
     动态绑定是一种在运行时确定被执行代码的技术

面向对象的分析和设计过程

面向对象分析的一般步骤如下：

1. 获取客户对系统的需求：包括标识场景（scenario）和用况（use case，也称用例），以及建造需求模型
2. 用基本的需求为指南，来选择类和对象（包括属性和操作）。
3. 定义类的结构和层次。类的结构主要有两种：一般—特殊结构 和 整体—部分结构
4. 建造对象—关系模型。对象–关系模型描述了系统的静态结构，它指出了类间的关系。类之间的关系有关联、依赖、泛化、实现等
5. 建造对象—行为模型。
6. 利用用况/场景来复审分析模型。

UML概述

• UML是一种可视化语言，用于：
  (1)规约系统的制品一一UML适用于对所有重要的分析、设计和实现决策进行详细描述
  (2)构造系统的制品一一UML描述的模型可与各种编程语言直接相关联
• UML应用范围
  (1)可用于对象方法和构件方法;
  (2)可用于
  • 所有应用领域(例如，航空航天、财政、通讯等)
  • 不同的实现平台

UML简介

视图：为了完整的描述一个系统，往往需要描述系统的许多方面，用视图可以表示被建模型系统的各个方面，即从不同目的出发可以为系统建立多个模型，这些模型都描述同一个系统，只是描述的角度不同。UML2.0把视图分成四个主题域：结构化域、动态域、物理域和模型管理域。
图：图是用来表达一个视图的内容的，通常，一个视图由多张图组成。
模型元素：包括事物和事物之间的联系。（事物、关系）

UML模型元素

• UML语言中的事物分为：结构事物、动作事物、组织事物和注释事物。
  • 结构事物：分为类、接口、用例、协作、结点、构件等
  • 动作事物：是UML模型中的动态部分，包括交互和状态机
  • 组织事物：包
  • 注释事物：UML模型的解释部分，用来对模型中的元素进行说明、解释。
• UML语言中的关系：关联、依赖、泛化、实现、聚合、组合
  
  

UML中的图

类图（*重点）

类图展示了系统中类的静态结构，即类与类之间的相互联系。类之间有多种联系方式，如关联（相互连接）、依赖（一个类依赖或使用另一个类）、泛化（一个类是另一个类的特殊情况）等。可以把若干个相关的类包装在一起作为一个单元（包）,相当于一个子系统。一个系统可以有多张类图，一个类也可以出现在几张类图中

对象图

对象图是类图的实例，它展示了系统执行在某一时间点上的一个可能的快照。对象图使用与类图相同的符号，只是在对象名下面加上下划线，同时它还显示了对象间的实例链接（link）关系

用况图（* 重点）

用况图展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述，执行者是指那些可能使用这些用况的人或外部系统，执行者与用况的连接表示该执行者使用了那个用况。用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能。
用况图的主要元素有：参与者、用例、关系（关联、包含include、扩展Extend、泛化）

* 内部结构图

展示了类的分解，给出了组成一个结构化类元的相互连接的部分、端口和连接器。

协作图

协作图展示了协作的定义，是一种合成的结构图。协作是为了完成某一目的而一起工作的一组对象间的上下文关系。

状态机图（* 重点）

状态机图通常是对类描述的补充，它说明该类的对象所有可能的状态以及哪些事件将导致状态的改变。一个事件可以是另一个对象向它发送的一条消息，或者是满足了某些条件。状态的改变称为迁移（transition）。一个状态迁移还可以有与之相关的动作，该动作指出状态迁移时应做什么
并不是所有的类都要画状态机图，有些类有一些意义明确的状态，并且其行为受不同的状态所影响和改变，这些类才需要画状态机图

活动图（* 重点）

活动图展示了连续的活动流。活动图通常用来描述完成一个操作所需要的活动。当然它还能用于描述其它活动流，如描述用况。活动图由动作状态组成，它包含完成一个动作的活动的规约(即规格说明)。当一个动作完成时，将离开该动作状态。活动图中的动作部分还可包括消息发送和接收的规约

顺序图（* 重点）

顺序图展示了几个对象之间的动态交互关系。它主要是用来显示对象之间发送消息的顺序，它还显示了对象之间的交互，即系统执行的某一特定点所发生的事

通信图

通信图描述了交互作用中的角色，显示了有协作关系的角色之间的交互。通信图明确地显示元素之间的协作关系，而不显示作为独立维的时间，消息的顺序和并发线程必须由顺序号确定

部署图

部署图展示了运行时处理结点和在结点上生存的制品的配置。结点是运行时的计算资源，制品是物理实体，如构件、文件
部署图中显示部署在结点上的制品和它们之间的关系，以及结点之间的连接和通信方式
包图是由包和它们间的关系组成的结构图
模型是在某一视点给定的精度上对系统的完整描述，一个系统可以从不同的视点（如分析模型、设计模型）存在多个模型。一个模型可看作一个特定类型的包，通常仅显示包就足够了（不必显示包内部的细节）

用况建模

用况建模是用于描述一个系统应该做什么的建模技术，用况建模不仅用于新系统的需求获取，还可用于已有系统的升级。用况模型用用况图来描述；
用况图展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述；
——描述动作者和使用案例之间的关系
——用于表现系统根据需求所提供的功能

用况图的组成元素

• 图中的元素包括：执行者、用况、一个方框和一些表示关系的连接线
• 所有的用况都位于方框之内，该方框称为“系统边界”
• 执行者与用况的关系：在执行者和用况之间的关联是用一根带箭头的线来表示的
• 用例之间的关系：
  1）关联关系
  2）包含关系
  3）扩展关系
  4）泛化关系

用况建模步骤

（1）定义系统
（2）确定执行者
（3）识别用例
（4）确定用例图中的关系并绘制用例图
（5）描述用例（用文字描述）
（6）确认模型

案例1：需求描述

小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计

一. 定义系统

用况图中的矩形框代表系统，系统的用况画在矩形框内，代表系统之外的执行者画在矩形框外。

二. 确定执行者

• 执行者是指与系统交互的人或其他系统
• 执行者代表一种角色，而不是具体的某个人
• 执行者可分成主执行者和副执行者：
  • 主执行者使用系统的主要功能
    例如，保险系统中主执行者处理保险的注册和管理
  • 副执行者处理系统的辅助功能
    例如，管理数据库、通信、备份以及其他管理等系统维护
• 执行者还可分为主动执行者和被动执行者：
  • 主动执行者开始一个用况
  • 被动执行者从不开始用况，只是参与一个或多个用况
• 执行者
  • 系统功能的使用者
  • 从系统获取信息者
  • 向系统提供信息者
  • 系统需要访问（读写）的那些外部硬件设备
  • 系统的维护和管理者
  • 与该系统进行交互的其他系统
  • 特殊参与者：系统时钟
  • 已有的上下文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。
  • 项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。
  • 书面的规格说明和其它项目文档（如会谈备忘录等）
  • 需求研讨会和联合应用开发会议的记录：这些会议的参与者通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的执行者。
  • 当前过程和系统的培训指南及用户手册：这些东西中经常会有潜在执行者。
• 执行者——个人图书管理系统
  • 图书管理员

三. 识别并确定用况

1. 一个完整的系统包含若干个用例（USE CASE），每个用例具体说明应完成的功能。
2. 寻找用况
   可以通过让每个执行者回答以下问题来寻找用况：
   • 执行者需要系统提供哪些功能？执行者需要系统做什么？
   • 执行者是否需要读、创建、删除、修改或储存系统中的某类信息？
   • 执行者是否要被系统中的事件提醒，或者执行者是否要提醒系统中某些事情？从功能观点看，这些事件表示什么？
   • 执行者的日常工作是否因为系统的新功能（尤其是目前尚未自动化的功能）而被简化或提高了效率？

• 
• 记录需求—个人图书管理系统
  
• 

四、确定用况之间的关系并绘制用况图

• **
  

• 包含与扩展关系
  • 被包含的用况（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用况（此例中的预订座位、安排座位）的一部分出现
  • 基用况是可以独立于扩展用况存在的，只是在特定的条件下，它的行为可以被另一个用况的行为所扩展

• 泛化关系
  • 可以用来表示执行者与执行者之间，用况与用况之间的特殊/一般化关系

• 绘制用况图
  

 五、用况的描述

• 用况的简单描述
  （1）执行者的简要描述
  客户：向公司订购商品的人
  客户代表：公司处理客户请求的人
  库存系统：记录公司库存的软件
  （2）用况的简要描述
  订购货物：客户创建一个新的请求商品的订单
  取消订单：客户取消一个已经存在的订单
• 用例描述模板如下：
  
• 细化用况描述—个人图书管理系统

1.用况名称：新增书籍信息（UC01）
2.简要说明：录入新购书籍信息，并自动存储建档。
3.事件流：……
3.事件流：3.1 基本事件流1）图书管理员向系统发出“新增书籍信息”请求；2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；3）图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号；4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本、页数、定价、是否有CDROM；5）系统确认输入的信息中书名未有重名；6）系统将所输入的信息存储建档。3.2 扩展事件流5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理选择修改书名或取消输入；5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作；5a2）图书管理员选择修改书名后，转到5）
4.非功能需求
5.前置条件：用户进入图书管理系统。
6.后置条件：完成新书信息的存储建档。
7.扩展点：无
8.优先级：最高（满意度 5，不满意度5）

• 编写要点

  • 使用简单的语法：主语明确，语义易于理解；
  • 明确写出“谁控制”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；
  • 从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是从第三者观察的角度；
  • 显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键作为一个事件就是不合适的）；
  • 显示参与者的意图而非动作（如果只描述了动作，人们不能够很容易地直接从事件流描述中理解用例）；
  • 包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）；
  • 用“确认”而非“检查是否”，例如“系统确认所输入的信息中书名未有重名”；
  • 可选择地提及时间限制；
  • 采用“用户让系统A与系统B交互”的习惯用语；
  • 采用“循环执行步骤x到y，直到条件满足”的习惯用语。