面向对象的分析与设计简介 - nanjing university ·...

1

面向对象的分析与设计简介

OOA & OOD: An introduction

• 引言

• 如何分析发现“类”

• 如何设计“类”

• 小结

2019/3/26

摘要 2

• 软件固有的复杂性

• 问题域的复杂性

• 功能性非功能性需求之间的平衡、需求描述的不明确、需

求改变等

• 管理开发过程的困难性

• 大规模软件开发人员之间的沟通、协调

• 软件中随处可能出现的灵活性

• 开发者实现功能的灵活性

• 描述离散系统行为的问题

• 程序状态复杂

2019/3/26

为什么需要面向对象的分析与设计方法？ 3

在每一种工程实践中，设计都是一种训练有素的方法，可以通过它来创造某个问题的解决方案，从而提供实现需求的途径。

• 软件工程：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。

• 好的设计方法可以为开发过程带来非常必需的实践方法，软件工程界已经发展出了几十种不同的设计方法学。

• 所有这些方法都有一些共同的要素：

• 表示法：表达每个模型的语言(UML)

• 过程：导致有序构建系统模型的过程(RUP, XP, SCRM…)

• 工具：消除建模中的枯燥工作并强制实现模型本身的规则的工具

2019/3/26

为什么需要面向对象的分析与设计方法？ 4

2019/3/26

面向对象软件工程 5

问题域

需求分析

总体设计

详细设计

计算机

OOT

OOP

OOD

OOA

问题域

编程

测试

计算机

自然语言

自然语言

分析与设计的鸿沟

编程语言

自然语言

面向对象的编程语言

传统的软件工程方法

面向对象的软件工程方法

• 面向对象方法真正意义深远的目标是它适合于解决分析

与设计期间的复杂性并实现分析与设计的复用。

• 面向对象的开发不仅仅是编程，必须在整个软件生命周

期采用一种全新的方法：在软件开发过程所有阶段都运

用面向对象的方法，将OOA，OOD，OOP，OOT有机地集

成在一起，这样有利于系统的稳定性。

2019/3/26


• 喷泉模型

• 以用户需求为动力，以对象为驱动

• 各阶段是相互迭代和无间隙的

• 使用相同的描述方法和模型，使得软件生存期各阶段

所使用的方法、技术具有高度的连续性。

2019/3/26


• Ivar Jacobson 92

• James Rumbaugh 91

• Grady Booch 93

• => Rational公司

• => UML (OMG)

2019/3/26

面向对象方法 8

面向对象方法都支持三种基本的活动

识别类和对象

描述对象和类之间的关系

通过描述每个类的功能定义对象的行为

• Rational Unified Process (RUP)– Rational统一开发过程

• 提供了在开发组织中分派任务和责任的纪律化方法

• 目标是在可预见的日程和预算前提下，确保满足最终用

户需求的高质量产品

• 迭代式的增量开发

• 用例驱动

• 以软件体系结构为核心

2019/3/26

面向对象方法 9

• OO方法强调开发过程的连续性

• 构造一系列不断精化的面向对象的模型

• 实际上目前大多倾向于采用迭代式开发

• 类成为分析、设计和实现的基本单元

• 核心问题：

• 如何发现类（不同层面的类）?

• 如何设计类 ?

2019/3/26

面向对象的分析与设计 10

• Craig Larman: Applying UML and Patterns: An Introduction

to Object-Oriented Analysis and Design and Iterative

Development

2019/3/26

推荐 11

• OOA是软件开发过程中的问题定义阶段

• 领域分析（Domain Analysis）：抽取和整理用户需求

并建立问题域精确模型的过程。以公共对象、类和框

架等形式在特定应用领域中标识、分析和规约公共的

可复用的软件成分的能力。抽象出目标系统的本质属

性，建立问题领域模型。

• 应用分析（Application Analysis）：将领域分析建立

起来的问题领域模型，用某种基于计算机系统的语言

来表示。响应时间需求、用户界面需求和数据安全等

特殊的需求也都在这一层分解抽出。

2019/3/26

面向对象分析 12

• 领域分析

2019/3/26


领域知识源

领域分析模型

领域分析

技术文件

专家建议

已有应用

客户考察

目前/未来的需求

类的分类

复用标准

功能模型

领域语言

• 具体步骤

2019/3/26


获取用户基本需求

标识类和对象

定义类的结构和层次

表示类（对象）间的关系

为对象行为建模

常用用例来收集和描述用户的需求

标识类及类的属性和服务

描述系统的静态结构

描述系统的动态行为

• FURPS+

• Functional功能性• features, capabilities, security

• Usability易用性• human factors, help, documentation

• Reliability可靠性• frequency of failure, recoverability, predictability

• Performance性能• response times, throughput, accuracy, availability, resource usage.

• Supportability可支持性• adaptability, maintainability, internationalization, configurability.

• “+”• Implementation, Interface, Operations, Packaging, Legal

2019/3/26

Requirement checklist 16

• OOD是面向对象方法在软件设计阶段应用与扩展的结果，

通常分为两个阶段

• 高层设计：建立应用的体系结构

• 低层设计：集中于类的详细设计

• OOD的准则

• 抽象，信息隐藏，模块化，弱耦合，强内聚，可重用

2019/3/26

面向对象设计 17

• OOD具体内容

• 按实现条件对OOA模型进行调整，并补充几个新的组

成部分：

• 设计问题域组元：设计构造一组为底层应用建立模型的类

和对象，细化分析结果

• 设计人机交互组元：设计一组有关类接口视图的用户模型

的类和对象，设计用户界面

• 设计任务管理组元：确定系统资源的分配，设计用于系统

中类的行为控制的对象、类

• 设计数据管理组元：确定持久对象的存储，将对象转换成

数据库记录或表格

2019/3/26

面向对象设计 18

• OO方法强调开发过程的连续性

• 构造一系列不断精化的面向对象的模型

• 实际上目前大多倾向于采用迭代式开发

• 类成为分析、设计和实现的基本单元

• 核心问题：

• 如何发现类（不同层面的类）?

• 如何设计类 ?

2019/3/26

面向对象的分析与设计 19

• 引言

• 如何分析发现“类”


• 小结

2019/3/26

摘要 20

• Three worlds

2019/3/26

回顾：三个世界 21

问题世界现实世界

软件世界

2019/3/26

22

现实世界

问题世界

软件世界

Reality

抽象

• 用例

• 基于需求文档

• Use-case model: writing requirements in context

2019/3/26

问题：如何发现类？ 23

• 用例是一个叙述性文档，用来描述参与者(actor)使用系

统完成某个过程时的事件发生顺序。

• 用例乃是对过程的描述。

• 过程描述事件、动作和事务处理自始至终的发生顺序。

• Use cases are text documents, not diagrams, and use-case

modeling is primarily an act of writing text, not drawing

diagrams.

2019/3/26

用例（Use Cases） 24

• Process Sale:

• A customer arrives at a checkout with items to purchase.

顾客带着商品到收银台结算购买商品

• The cashier uses the POS system to record each purchased item.

收银员采用POS系统记录每件购买的商品

• The system presents a running total and line-item details.

系统提供一个流水单以及商品明细

• The customer enters payment information, which the system validates and records.

顾客输入付款信息，系统核实并记录

• The system updates inventory.

系统更新存货

• The customer receives a receipt from the system and then leaves with the items.

顾客收到发票并带着商品离开

2019/3/26

Use Case例子： 25

• 简单地说，

• an actor is something with behavior,

• such as a person (identified by role), computer system, or organization; for example, a cashier.

• a scenario is a specific sequence of actions and interactions between actors and the system; it is also called a use case instance.

• It is one particular story of using a system, or one path through the use case; for example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit payment denial.

• a use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. For example, here is a casual format use case with alternate scenarios:

2019/3/26

Actor, Scenario, Use Case 26

2019/3/26

Process Sale 27

2019/3/26

28

• Ivar Jacobson: A set of use-case instances, where each

instance is a sequence of actions a system performs that

yields an observable result of value to a particular actor.

• 软件工程师容易犯的错误：自认为所做的是客户/

用户需要的。

• 不能代替客户/用户假想其价值所在。

2019/3/26

Actor有Goal 29

• 用例可以是一个场景，包括动作和交互。

• 用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。

• 用例里不要有系统设计，用例里不要有界面设计，用例里不要有特性列表，用例里不要有测试。

• 用例应该描述行为需求。

• 用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。

• 用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

2019/3/26

创建USE CASE的一些原则 30

• 界定系统边界

• 基于参与者

• 先识别参与者

• 对每个参与者，找出其所发起和参与的过程

• 基于事件

• 识别系统必须响应的外部事件

• 把事件与参与者和用例联系起来

2019/3/26

用例的识别 31

2019/3/26

边界，Actors，Goals 32

除了明显的Actors之外，还要问问诸如以下这些问题：

• 谁启动和停止系统？

• 谁管理系统？

• 谁进行用户和安全管理？

• 系统失败时是否有监管进程对系统进行重启操作？

• 谁负责评价系统行为和性能？

• 如何处理软件更新？采用PUSH还是PULL的方式？

• 谁评价日志？日志是否可以远程获取？

• 主要角色除了人，是否还有外部软件或机器人系统会访问系统服务？

• 当出现错误或失败时，谁会得到通知？

• ……

识别Actors及其Goals 33

• “The nouns and the verbs”

• 启发：类与方法；

• 基本原则：ADT

• 没有机械的办法。

• 基于经验的启发性、指导性的原则：

• 哪些东西是可能的类；

• 哪些形式的类不理想，可考虑从模型中去除。

2019/3/26

Find the classes 34

• 明确的抽象

• 类名是名词或形容词，刻画该抽象

• 形容词常用于表达接口

• 代表一系列运行时刻的对象。

• （允许特意的singleton）

• 有修改操作（或作用式操作）

• 形式或非形式地刻画性质：不变式前后置断言

2019/3/26

The ideal class 35

• 分析类

• 直接对应于问题域

• 设计类

• 为得到优雅的、可扩展的结构而引入

• 实现类

• 满足软件系统实现算法所需。如LinkedList; Array等

2019/3/26

三种类 36

• 分析类代表了关于系统责任和行为的概念早期模型

• 分析类用来捕捉系统对象模型的“初稿”

• 分析类处理主要的功能需求

• 分析类从问题领域进行对象建模

2019/3/26

分析类 37

• 系统最可能改变的方面：

• 系统和它的角色之间的边界 (boundary)

• 系统使用的信息 (entity)

• 系统的控制逻辑(control)

2019/3/26

分析类 38

behaviour

information

boundary

延伸思考：MVC

• 寻找分析类

• 外部世界某些方面的Operational Model

• 仿真/模拟

• 不一定是客观实体，也可能是抽象概念

2019/3/26

Heuristics for finding classes 39

• 寻找设计类

• 创造性工作

• 设计模式的用武之地

• 其他途径

• 旧系统

• Adaptation through inheritance

2019/3/26


• 寻找实现类

• 实现难

• 多复用

• 数据结构与算法知识

• 延迟实现类

• 如”Queue”

• 类层次组织多种不同实现

2019/3/26


2019/3/26

42

• 领域模型可以被看作是一个系统的概念模型，用于以可视化的形式描

述系统中的各个实体及其之间的关系。领域模型记录了一个系统中的

关键概念和词汇表，显示出了系统中的主要实体之间的关系，并确定

了它们的重要的方法和属性。因此，对应于用例所描述的动态视图，

领域模型提供了一种对整个系统的结构化的视图。领域模型的一个好

处是描述并限制了系统边界。

• 领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建

立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。

• 领域模型的语义可以被用在源代码中，因此领域模型可以被应用在底

层的软件开发阶段中。实体可以演化为类，方法和属性可以直接演化

至代码之中。

2019/3/26

Domain Model 领域模型 43

• 领域模型设计的步骤为：

• 1. 从业务描述中提取名词；

• 2. 从提取出来的名词中总结业务实体，区分名词中的属性、角

色、实体、实例，形成问题域中操作实体的集合；

• 3. 从业务实体集合中抽象业务模型，建立问题域的概念（例如

在前面的例子中，我们把容易变质的水果称之为“短期保持水

果”，当然也可以是其它说法，只要能跟用户达成共识即可）；

• 4. 用UML提供的方法和图例进行领域模型设计、确定模型之间

的关系

2019/3/26

Domain Model 44

2019/3/26

Domain Model 45

• 识别系统事件

• 定义系统操作

• 给出这些操作的Contracts

2019/3/26

System Sequence Diagrams 46

Contract CO2: enterItem

Operation: enterItem(itemID: ItemID, quantity: integer)

Cross References: Use Cases: Process Sale

Preconditions: There is a sale underway.

Postconditions: - A SalesLineItem instance sli was created (instance

creation).

- sli was associated with the current Sale (association

formed).

- sli.quantity became quantity (attribute modification).

- sli was associated with a ProductDescription, based

on itemID match (association formed).

2019/3/26

48

• 建立系统类模型类图

• 在类之间分配职责

2019/3/26

接下来 49

• 引言

• 如何发现“类”


• 小结

2019/3/26

摘要 50

• OO设计是一个迭代的过程！

• 把分析类直接带入设计阶段

• 如果在设计阶段合并了分析模型，那么在演化的时候，

保持分析和设计模型的一致性会更容易

• 类设计：增加细节和执行精细决策

2019/3/26

Class Design 51

• 填补从高层需求到低层服务之间的空白

• 用操作实现用例

• 阐述每个操作的算法

• 选择算法；数据结构；设计内部类和操作

• 向下递归到支持更高层操作的设计操作

• 功能分层；机制分层

• 把模型重构成更简洁的设计

2019/3/26

Class Design 52

• 设计优化

• 效率问题

• 具体化必须操作的行为

• Command, Strategy模式

• 调整类的结构以增加继承

• 重新调整类和操作；提取公共行为；使用委托来共享行为

• 组织类和关联

• 信息隐藏；内聚性；微调包

2019/3/26

Class Design 53

• 创建初始设计类

• 定义操作

• 定义方法

• 定义状态

• 定义属性

• 定义依赖

• 定义关联

2019/3/26

Class Design 54

• 大部分，简单的类意味着每一个类

• 封装较少的整个系统的智能

• 更易被复用

• 更易实现

• 少部分，复杂的类意味着每个类

• 封装较多的整个系统的智能

• 不太会被复用

• 更难实现

2019/3/26

How Many Classes Are Needed? 55

A class should have a single well focused purpose. A class should do

one thing and do it well!

• 面向对象分析和设计

• 特点，过程，任务

• 如何发现类

• 用例

• 领域模型

• 如何设计类

2019/3/26

小结 56

2019/3/26

UML - Books 57

2019/3/26

UML - Tools 58

？

需要开发的流程图绘制软件的基本功能可以参照PPT或者Visio中的图

形以及流程图绘制功能。

基础功能需求：

1. 设计良好的图形用户界面，界面中要求至少有默认大小的方框、圆形、连接线三个

元素可供用户选择后，单击绘制到画布上；

2. 支持拖拽绘制方框、圆形、连接线；

3. 允许用户对一个图形添加文字描述；

4. 单击可以选中图形，并允许对图形的拷贝复制；

5. 支持撤销上一步操作的功能。

扩展功能需求：

1. 选中图形后可对图形的尺寸进行拖拽调整图形大小；

2. 支持个性化界面，包括设置界面字体大小、界面皮肤等；

3. 支持撤销多步的功能；

4. 设计一种硬盘文件存储格式可以保存用户绘制的图形，并可以加载。

2019/3/26

流程图绘制软件-开发需求 59

• 对上述给定的软件开发问题，完成分析设计文档

• 首先采用面向对象分析的方法，给出用例文本，用例

图，领域模型，系统顺序图，操作契约

(其中图的绘制可以采用绘制软件如Visio, StarUML或一些免费的网

站https://www.processon.com/，学习使用其中UML图绘制的功能)

• 结合上述分析结果，给出面向对象设计中的类结构详

细设计，给出系统的类图，类与类之间的结构关系图

2019/3/26

作业 60

4月8号24点截止提交，提交到邮箱[email protected]

面向对象的分析与设计简介 - nanjing university ·...

Documents