面向对象分析与设计


用例之间的三种关系(难点)
包含关系(Include)
扩展关系(Extend)
泛化关系(Generalization)

参与者之间的关系
依赖关系
泛化关系

参与者和用例间的关系
关联关系

面向对象分析(Object-Oriented Analysis, OOA)

~~面向对象分析技术关注应用领域中的实体,并将其建模为对象
~~每个对象类都定义了一组数据和一组方法。数据用于表示对象的静态属性,是对象的状态信息。
~~面向对象分析技术主要基于分类、泛化、聚合关系在对象集合之间建立结构
~~对象的行为是执行预定的动作(服务/活动)
~~对象通过执行动作来完成状态变迁

3个模型

在面向对象分析中,通常需要建立3种形式的模型:

~~描述系统数据结构的对象模型

~~描述系统控制结构的动态模型

~~描述系统功能的功能模型

一个典型的软件系统使用数据结构(对象模型)执行操作(动态模型),并且完成数据值的变化(功能模型)。这3个模型中对象模型是最基本、最重要、最核心的。

组成对象模型的5个层次

~~“对象”是问题领域中真实存在的实体,有“定义清晰的边界”
~~ 对象中封装有属性和行为
 ~~面向对象分析的五个核心概念在这里插入图片描述

主题

主题是指导读者理解大型、复杂模型的一种机制。也就是说,通过划分主题把一个大型、复杂的对象模型分解成几个不同的概念范畴。给出分析模型的总体概貌。
在这里插入图片描述

面向对象分析过程

在概念上可以认为,面向对象分析大体上按照下列顺序进行:寻找类与对象,识别结构,识别主题,定义属性,建立动态模型,建立功能模型,定义服务
但是,分析不可能严格地按照预定顺序进行,大型、复杂系统的模型需要反复构造多遍才能建成。
分析也不是一个机械的过程。系统分析员必须与领域专家及用户反复交流,以便澄清二义性,改正错误的概念,补足缺少的信息。

软件系统建模原则

在这里插入图片描述

对象建模原则(1): 抽象

抽象
• 在对象间找出共性 , 忽略不相关细节
• 关注对象间的一般/ 特殊关系
将具有相同属性或角色的对象放入同一个类集合中
再通过父子关系,将由共性的类定义为同一个父类的子类

继承(一般-特殊结构)
   **一般-特殊结构**将类组织成基于继承关系的分类层次结构

• 自底向上是从特殊到一般的类 (generalization)
• 自顶向下是从一般到特殊的类(specialization)
在这里插入图片描述

对象建模原则(2): 分解

分解
—表达整体部分关系,细分为聚合和组合
要研发一个飞行器
— 将问题分解为子系统研发:
导航系统
数据处理系统
指挥控制系统
环境控制系统等
这是我们对问题的分解
  —现实世界中的设计可以组件化
—系统分解方式决定系统的体系结构设计

服务建模

对象为其周围的其他对象提供服务,例如,医生对象对外提供的服务为体检,出体检报告等。
OOA方法中,定义了三种类型的服务
瞬时服务:对象的创建、结束,修改等
计算服务:对象为其他对象完成计算任务等
监控服务:对象持续监控流程,检查预设条件是否满足

从面向对象到面向服务,是看待问题的视角的切换

服务关系

在这里插入图片描述

对象建模原则(3) : 投影

投影
• 从多个视角分别建模问题的不同方面
• 一如建筑施工中的不同视角的图纸
飞行器需求建模,投影建议分别建模
•安全性、容错性、实时性 …
注意:投影和分解有共同点
•分解定义整体-部分关系
•投影定义视图
•分解的假设是子模块间依赖性较小

面向对象的分析方法学

• 识别对象和类(类是对象的抽象定义)
• 识别类之间的关系,建立由继承和组合关系组成
的类层次结构
• 定义主题,通过主题将对象模型组织成多个抽象
层次或视角,一般说来通过继承关系或整体部分
关系联系起来的类同属于一个主题
• 识别各个对象内部的属性信息,并将其赋予相应
抽象层次的类
• 为每个类定义服务

面向对象设计(Object-Oriented Design, OOD)

分析是提取和整理用户需求,并建立问题域精确模型的过程。

设计则是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。

从面向对象分析到面向对象设计,是一个逐渐扩充模型的过程。或者说,面向对象设计就是用面向对象观点建立求解域模型的过程。

面向对象设计过程

• 进行适当的领域分析
• 撰写问题描述,确定系统的开发任务
• 基于问题描述抽取需求
• 开发用户界面原型
• 识别对象类
• 定义每个类的职责
• 确定类之间的交互关系
• 建立系统的设计模型

面向对象思维方式的核心理念

区分接口与实现
从具体到抽象
最小接口原则

设计抽象的接口

在这里插入图片描述

不太抽象的接口

在这里插入图片描述

抽象的接口:向用户暴露尽可能少的实现细节

让用户知道的关于类的内部实现细节越少越好
• 只给看必须的
• 只看公开的
• 只为用户的业务需求考虑

                **最小用户负担原则**
确定用户

• 用户是谁 ? 重要程度高达50%
• 面向服务的原则
在这里插入图片描述

确定对象行为
              **用例 !!!**
识别环境约束
环境对对象的行为施加约束限制条件
前置条件/后置条件/例外条件…
公共接口的识别

用户使用出租车对象的时候,需要以下功能
• 上车
• 告知司机终点
• 付钱
• 下车
用户要用出租车的时候
• 有出行地点
• 召唤出租车
• 付钱
在这里插入图片描述

确定实现细节

• 公共接口以外的内容都可以看做是实现相关的
• 用户永远无需关注实现细节
• 方法的命名和参数定义
• 编码实现
• 对实现的修改无须牵涉接口
• 实现为用户的期望提供解决方案
• 接口从用户的角度看待对象,实现则是对象的
果核和果肉
• 实现中包含有描述对象状态的代码

开闭原则(Open/Closed Principle, OCP)

软件实体在扩展性方面应该是开放的,而在更改性方面应该是封闭的。
例:打印输出设计
在这里插入图片描述
在这里插入图片描述

里氏替换原则 (Liskov Substitution Principle, LSP)

子类可以替换父类出现在父类能出现的任何地方
为了满足里氏替换原则,设计时要求:
• 子类中方法的前置条件不能强于父类中相应方法的前置条件。
• 子类中方法的后置条件不能弱于父类中相应方法的后置条件。

里氏替换原则要求子类宽入严出

依赖倒置原则 (Dependency Inversion Principle, DIP)

依赖倒置原则指的是依赖关系应该是尽量依赖接口(或抽象类),而不是依赖于具体类。
在这里插入图片描述

接口分离原则(Interface Segregation Principle, ISP)

在设计时采用多个和特定客户类(client)有关的接口要比采用一个通用的接口要好。
在这里插入图片描述
在这里插入图片描述

其他设计原则

单一职责原则一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。单一职责原则是实现高内聚、低耦合的指导方针,是最简单却最难运用的原则,需要设计人员发现类的不同职责并将其分离。

合成复用原则优先使用对象组合,而不是继承来达到复用的目的。一般而言,如果两个类之间是"Has-A"关系应使用组合或聚合,如果是"Is-A"关系可使用继承。

迪米特法则-又称最少知识原则一个类对于其他类知道的越少越好,就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信,不和陌生人说话。

面向对象设计时要注意的一些问题

1. 不同类中相似方法的名字应该相同
2. 遵守已有的约定俗成的习惯
3. 尽量减少消息模式的数目。只要可能,就使消息具
有一致的模式,以利于理解。
4. 设计简单的类。类的职责要明确,应该从类名就可
以较容易地推断出类的用途。
5. 定义简单的操作、方法
6. 定义简单的交互协议
7. 泛化结构的深度要适当
8. 把设计变动的副作用减至最少

类图建模

要确定真实世界中的抽象,即系统中将涉及的主要概念性对象。这些问题域抽象的模型是整个对象建模工作的基础。
根据当前项目的业务范围,创建领域模型的步骤如下:

  1. 研究分析问题领域,确定系统需求;
  2. 寻找(识别)类,明确其含义和责任,确定属性和操作;
  3. 确定类之间的关系;
  4. 设计类与关系,解决命名冲突、功能重复等问题;
  5. 绘制类图并编制相应的说明。
什么是类图

类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。类图技术是OO方法的核心。

类图标加上它们之间的关系就构成了类图

A class diagram is a graphic presentation of the static view that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.

类图的组成

类图通常包含下述内容:

接口
协作

依赖、泛化和关联关系

类图可以包含注解和约束;
类图还可以有包或子系统,二者都用于把模型元素聚集成更大的组件。

类图的三个层次

在这里插入图片描述

关系(Relationship)

关系是事物间的关系。在类的关系中,最常用的4种分别为:

依赖(Dependency):类之间的使用关系。
泛化(Generalization):类之间的一般和特殊的关系。
实现(Realization) :规格说明和其实现之间的关系。
关联(Association):表示对象之间的结构关系。

1 依赖(Dependency)

A dependency is a relationship between two elements in which a change to one element (the supplier) may affect or supply information needed by the other element (the client).
有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。
在这里插入图片描述
依赖关系
在类中,依赖由各种原因引起,如:一个类向另一个类发消息;一个类是另一个类的某个操作参数类型。

依赖关系有如下三种情况:
A类是B类方法当中的一个参数。
A类是B类中的(某种方法的)局部变量。
A类向B类发送消息,从而影响B类发生变化。

2 泛化(Generalization)

泛化表示类与类之间的继承关系,接口与接口之间的继承关系。
例如,老虎和狗都是动物的子类。
在这里插入图片描述

3 实现(Realization)

是规格说明和其实现之间的关系。

大多数情况下,实现关系用来规定接口和实现接口的类或组件之间的关系。
在这里插入图片描述

4 关联(Association)

对于两个相对独立的对象,当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时,这两个对象之间为关联关系。
在这里插入图片描述
关联关系
比如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单。
再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司。
在这里插入图片描述
重数性关联
又称多重性关联关系,表示一个类的对象与另一个类的对象连接的个数。
在关联直线上增加一个数字表示与之对应的另一个类的对象的个数。
重数性关联的表示方式如下:
在这里插入图片描述
关联关系的角色和关联类
在这里插入图片描述

两种特殊的关联关系

聚合关系
用来描述整体和部分的关系,有着聚合关系的两个类,一个是整体,一个是部分。在聚集中,部分类可以独立存在。
组合关系
也是用来描述整体和部分的关系。在组成关系中,部分类不能脱离整体类而存在。一旦整体对象不存在,部分对象也将不存在(同生共死)。
1) 聚合关系
比如电脑和它的显示器、键盘、主板以及内存就是聚集关系,因为主板是电脑的组成部分。
聚合关系的UML图示:
在这里插入图片描述
2) 组合关系
组成:例滑翔机与机身、机尾、左右机翼。
在这里插入图片描述

关联与聚合、组成的区别

在这里插入图片描述

  • 3
    点赞
  • 37
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值