「武汉理工大学 软件工程复习」第四章 | 面向对象 & UML建模
目录
【对象、属性、方法】
【面向对象分析与设计】
专有名字的缩写
面向对象的分析 OOA
面向对象的设计 OOD
UML介绍
【面向对象设计原则】
SOLID原则
OO设计时需要注意的一些问题
CRC卡片分拣法
【类图 & 类图】
类图的相关概念
类图关系:关联关系
类图关系:聚合关系、组合关系
类图关系:泛化关系
类图关系:依赖关系
类图关系:实现关系
关联类
类图符号总结
类图建模的过程
【用例图】
用例图的相关概念
用例图关系
用例建模的流程
【顺序图】
顺序图的相关概念
顺序图建模的流程
顺序图的组合框
顺序图 VS 用例图
【状态图】
状态图的相关概念
状态图建模的流程
【单元测试题】
选择题
判断题
【对象、属性、方法】
什么是软件对象?
- 软件也是由不同类型的软件对象组成的.每个软件对象也有自己的状态和行为。
什么是类?
- 一个蓝图或原型,它定义了某种类型的所有对象通用的变量和方法,具有可重用性以节省开发许多同类对象的工作。
对象的消息传递:
- 对象不会接受任意的消息传递,对象可接受的消息通常被定义为该对象的一组方法
接口:
- 方法声明的集合
- 接口是一个软件对象所能提供的所有功能属性(服务)的集合。
- 接中的方法定义了服务对象所能实现的各种“服务”
- 方法(或服务)的产生以及命名,都必须遵循使用该服务的客户对象的需求
- 设计一应该从客户对象的需求中“提取”服务对象类的接口以及各方法的具体实现,而不是向客户对象“推送”我们认为这个服务对象类应该提供的功能。
对象是软件模块
- 软件模块只是子程序和数据的一种松散组合
【面向对象分析与设计】
专有名字的缩写
OOAD(Object oriented analysis design),面向对象分析设计
OOP(Object oriented programming),面向对象程序设计
OOD(Object oriented design),面向对象设计
OOA(Object oriented analysis),面向对象分析
面向对象的分析 OOA
面向对象程序设计(OOP):将OOP中的概念上推到分析和设计阶段
数据库设计(Database design):将数据语义建模概念,如实体-关系、泛化、聚合和分类用于系统分析和设计
结构化分析〈Structured Analysis ):将结构化分析方法与技术,如SADT方法等用于系统分析与建模
知识表示(Knowledge Representation):采用基于问题框架和语义网络的知识表示方法
面向对象的设计 OOD
早期OODの特点
- 不是基于OOA的,大多基于结构化分析结果
- 是OO编程方法的延伸,多数方法与编程语言有关
- 不是纯OO的,对某些OO概念缺少支持
- 不是只针对软件生存周期的设计阶段
- 早期的OOD可看作现今OOAD方法的雏形。
90年代以后 の OOD的特点
- 以面向对象的分析为基础
- 相应的OOA方法共同构成一种OOAD方法体系
- 较全面地体现面向对象方法的概念与原则
- 大多数方法独立于编程语言,可以由不同的编程语言实现
- 面向对象的设计OOD:在OOA模型基础上运用面向对象方法进行系统设计,产生一个符合具体实现条件的OOD模型。
几种典型的面向对象的方法
Booch方法、Coad-Yourdon方法、Firesmith方法、Jacobson方法(OOSE)、Martin-odell方法、Rumbaugh方法(OMT)、Seidewitz-Sark方法、
Shlaer-Mellor方法、Wirfs-Brock方法
方法的异同体现于:概念、表示法、系统模型、开发过程、可用性、技术支持
- 【Booch方法】微过程:识别类和对象 - 识别类和对象的语义 - 识别类和对象的关系 - 实现类和对象;
- 【Jacobson方法】特点:通过用例描述用户需求、用交互图描述对象之间的交互、用例驱动的观点言之有过
- 【OMT方法】特点:概念严谨,阐述清楚 ; 过程具体,可操作性强 ; 包含了许多非面向对象的内容 ; 提出若干扩充概念,偏于复杂
UML介绍
UML简介
- 什么是UML?UML-Unified Modeling Language 统一建模语言,又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言
- UML是一个开放的标准、一种描述性语言:严格的形式语法(如编程)、一种说明性语言:由用法和约定塑造
- UML包含很多语言:用例图、类图、顺序图、状态图等等
使用UML
- 草图:交流系统的各个方面,通常在白板或纸上完成用于获得粗略的选择性想法
- 蓝图:要实现的完整设计,有时用CASE(计算机辅助软件工程)工具完成
- 正向设计:在编码之前使用
- UML逆向设计:在编码为文档之后进行UML建模
- 作为一种编程语言:使用正确的工具,可以从UML自动生成和执行代码
【面向对象设计原则】
SOLID原则
OO设计时需要注意的一些问题
- 不同类中相似方法的名字应该相同
- 遵守已有的约定俗成的习惯
- 尽量减少消息模式的数目。只要可能,就使消息具有一致的模式,以利于理解。
- 设计简单的类。类的职责要明确,应该从类名就可以较容易地推断出类的用途。
- 定义简单的操作、方法
- 定义简单的交互协议
- 泛化结构的深度要适当
- 把设计变动的副作用减至最少
CRC卡片分拣法
CRC卡片分拣法的作用是 根据用例描述中的名词确定类的候选者,根据用例描述中的名词确定类的候选者
具体方法:
- 由名词寻找实体类 由动词寻找职责也要从字面去发现职责
- 根据边界类,控制类,实体类的划分来帮助发现系统中的类
- 对领域进行分析,或利用已有的领域分析结果得到类
- 参考分析,设计模式来确定类
【类图 & 类图】
参考资料:类图六大关系总结_大音希声_的博客-CSDN博客_类图关系
类图的相关概念
什么是类和对象?
- 类:具有相同性质、行为、对象关系、语义的对象集合
- 对象:类的实例,两个不同对象可以有相同的属性值
类的分类
边界类,控制类,实体类
- 边界类位于系统与外界的交界处
- 实体类保存要放进持久存储体的信息。通常每个实体类在数据库中有相应的表,实体类中的属性对应数据库表中的字段。
- 控制类是控制其他类工作的类。每个用例通常有一个控制类,控制用例中的事件顺序,控制类也可以在多个用例间共用。其他类并不向控制类发送很多消息,而是由控制类发出很多消息。
类图的表示
类图显示了软件系统中实体类的存在及其关系。
类图显示模型的静态结构,特别是存在的事物,如类、它们的内部结构,以及它们与其他类的关系。
它是一个系统的静态视图,主要支持系统的功能需求。
类图关系:关联关系
单项关系示例
public class Phone {
private User user;
}
public class User {
}
双向关系示例
public class Person {
private IDCard idCard;
}
public class IDCard {private Person person;
}
- 一个完整的关联关系应该包含的元素:关联关系名、导航性、多样性、角色
- 关联关系的种类:自返(递归)关联、二元关联、N元关联
类图关系:聚合关系、组合关系
聚合关系
聚合关系表示的是整体与部分之间的关系,整体与部分可以分开。
聚合关系是关联关系的特例,所以它具有关联的导航性和多重性。聚合关系使用带空心菱形的实现来表示。
示例:
public class Computer {
private Mouse mouse;
private Monitor monitor;
public void setMonitor(Monitor monitor) {
this.monitor = monitor;
}
public void setMouse(Mouse mouse) {
this.mouse = mouse;
}
}
public class Mouse {
}
public class Monitor {
}
组合关系
- 组合关系也是整体与部分的关系,但是整体与部分不可以分开。即:整体与部分是同生共死的关系。
- 组合关系使用实心菱形表示。
- 聚合和组合的区别:聚合是将类作为属性;组合是将对象作为属性
示例
public class Computer {
private Mouse mouse=new Mouse();
private Monitor monitor=new Monitor();
}
public class Mouse {
}
public class Monitor {
}
类图关系:泛化关系
泛化关系 Generalization
- 泛化关系其实就是继承关系,它是依赖关系的特例。这个很简单,如果A类继承了B类,那么A和B就存在泛化关系。
- 使用实线白色三角箭头表示泛化关系。子类指向父类
示例
public abstract class DaoSupport {
public void save(Object entity){ }
public void delete(Object id){ }
}
public class PersonServiceBean extends DaoSupport {
}
类图关系:依赖关系
依赖关系 Dependency
- 定义:只要在类中用到了对方(注意:若在类中定义了另外的类或者类的对象,则属于聚合或组合关系),那么它们之间就存在依赖关系。如果没有对方,则编译不能通过。
- 使用普通箭头表示依赖关系
示例
public class PersonServiceBean {
private PersonDao personDao;
//这里只是用于理解依赖关系,没有具体实现
public void save(Person person){ }
public IDCard getIDCard(Integer personid){
return null;
}
public void modify(){
//注意:局部变量是类对象,不符合迪米特法则,这里只是用于理解依赖关系
Department department=new Department();
}
}
public class PersonDao {
}
public class IDCard {
}
public class Person {
}
public class Department {
}
类图关系:实现关系
实现关系 Realization
- 实现关系就是A类实现B接口,它是依赖关系的特例。
- 使用虚线的白色三角箭头表示实现关系
示例
public interface PersonService {
public void delete(Integer id);
}
public class PersonServiceBean implements PersonService{
@Override
public void delete(Integer id) {
}
}
关联类
- 有时要为关联相关信息的存储定义一个专门的类,称为“关联类”
- 保存与关联关系本身相关的信息,这些信息不属于关联所连接的两端的类。
- 关联类通过一条虚线连接至关联。
示例:
public class Company {
private String companyName;
public Person employee[];
}
public class Contract {
peuvate Double salary;
}
public class Person {
private String personName;
protected Company employer;
}
类图符号总结
类图建模的过程
定义类名 → 定义类属性 → 定义类的操作 → 建立类和类之间的关系 → 定义关联关系的多样性、方向和名字
示例:
【用例图】
用例图的相关概念
- 用例建模的目的:关联干系人需求以及软件需求、确认与系统交互的人或对象(参与者)、定义系统的边界、捕捉和传达系统的理想行为(用例)
- 用例图(use case diagram ):由参与者、用例以及它们之间的关系构成的,用于描述系统功能的动态视图。
- 用例建模的概要:概要描述、参与者Actor列表、用例Use-case列表
用例图的主要元素:参与者、用例、关联、系统边界
参与者:与系统交互的人、与系统交互的外部系统、硬件设备
- 如顾客通过在信息管理系统的支持下运行的web购物系统购物,则参与者是:顾客、信息管理系统;用例是:web购物系统
- 参与者是一个角色,而不是具体的人:如A、B、C都是老师
- 一个人不一定只有一个角色:如A是店长,也是店员
用例:作为外部实体的参与者与系统的交互序列;即系统的一系列行为,为参与者提供有价值且可观测的结果
- 用例不是功能分解的过程!
- 常见用例:参与者要用到的系统功能、系统为实现参与者价值所开展的行为序列、交互活动、事件流
关联:参与者与用例之间的交互通道
- 有箭头:指出是谁发起的交互
- 没箭头:双方都可以发起的交互
系统边界:包含的所有系统成分与系统以外各种事物的分界线
- 系统边界会对用例以及Actor的定义有所影响
用例图关系
参考资料:用例建模_万事胜意L的博客-CSDN博客_用例建模
注意一下指向: 泛化:子用例→父用例 ; 包含:基用例→包含用例 ; 扩展:扩展用例→基用例
关联关系:表示参与者与用例之间的通信。
泛化关系:参与者之间可以有共同的属性和行为,因此可使用泛化关系来描述多个参与者之间的公共行为。它们之间有特殊和一般的关系。
- 示例:电话订票、网络订票,都包含于”订票“
包含关系:指一个用例可以包含其他用例具有的行为,并把它所包含的用例行为作为自身用例的一部分。其实就是基础用例中一个不得不执行的用例部分。
- 示例:下订单 包含 提供用户信息
扩展关系:一个用例也可以被定义为基础用例的增量扩展,这称作扩展关系,扩展关系是把新行为插入到已有用例的方法。
- 示例:”取消订单“ 是 ”检查订单状态“ 的扩展
用例建模的流程
画系统边界 → 列出actor-goal lists → 找到参与者 → 找到用例 → 按照时间流程和用例关系画出关系
Step1.找出参与者和外部系统、画出 actor-goal lists,找到参与者和用例
actor-goal lists
Step2.按照actor-goal lists画出用例图
由actor的目标来确定用例
Step3.写出用例详细规约
包含 不同的场景(成功、失败)、用例建模详细规约
用例建模详细规约的编写:找出用例的执行者和目标、撰写用例概述和主成功场景、考虑操作失败的场景、列出所有可替换场景
【顺序图】
顺序图的相关概念
顺序图建模的流程
① 从用例中识别交互过程;
② 获取要画顺序图对应的参与者,并把它放在最开始的位置。然后识别参与交互过程的对象;
③ 为每一个对象设置生命线,并确定对象的存在期限;
④ 从引发交互的初始消息开始,在对象生命线上依次画出交互的消息;
⑤ 如果需要,可以给消息增加时间约束,以及前置条件和后置条件。
示例:
顺序图的组合框
顺序图 VS 用例图
- 顺序图往往和用例图绑定使用
- 顺序图表达用例的单个场景实例的行为。
- 顺序图表达对象间如何协作完成用例所描述的功能。
顺序图可用于开发周期的不同阶段,服务于不同目的,描述不同粒度的行为
- 用于表示为完成用例而在系统边界输入输出的数据以及消息
- 用于表示系统内部对象间的消息传递。
【状态图】
状态图的相关概念
- 有限状态机的主要元素:状态和转移、事件和行为
所有的对象 都有状态!! 对象的存在 / 不存在 也是一种状态
状态图用于表示【一个】类对象的全生命周期过程
描述状态图的图符元素有:状态图符、迁移图符、起始状态、终止状态、条件判定、发出信号、接收信号和并发等。
- 【起始、终止】必须要有起始和结束状态
- 【迁移】包含的元素:原状态、触发事件、动作表达式(每个状态迁移都对应一个触发事件,同时满足一定警戒条件)
- 【迁移】的最终结果一定只能达到一个。即:若有多个分支,则这几个分支间的条件应该是互斥的
- 【事件】状态图中,事件仅需和系统或当前建模对象相关,在OOD中通过传递消息的方式实现事件
- 【事件】四类事件:变更事件、调用事件、时间事件、信号事件
变更事件(Changeevents):当给定条件成立时就会发生变更事件
调用事件(Callevents):当给定对象的操作被调用执行时会发生调用事件
时间事件(Elapsed-timeevents):表明时间段过去,或某个特殊时间点的触发
信号事件(Signalevents):当给定对象收到某实时信号
- 【动作】在状态内部或者状态间迁移时执行的原子操作,两种特殊的动作:入口动作、出口动作
状态图建模的流程
①找出适合用模型描述其行为的类。
②确定对象可能存在的状态。
③确定引起状态迁移的事件。
④确定迁移进行时对象执行的相应动作。
⑤对建模的结果进行相应的精化和细化。
示例:
【单元测试题】
选择题
判断题
1.用户界面设计对于一个系统的成功是至关重要的,一个设计得很差的用户界面可能导致用户拒绝使用该系统。 F
2.系统设计的主要任务是细化分析模型,最终形成系统的设计模型。 F
辨析:系统设计的主要任务是在系统分析的基础上,按照逻辑模型的要求,科学合理地进行系统的总体设计和具体的物理设计,为下一阶段系统提供实施提供必要的技术资料。而不是【最终】形成系统的设计模型
3.面向对象设计是在分析模型的基础上,运用面向对象技术生成软件实现环境下的设计模型。 T
还没有评论,来说两句吧...