《火球:UML大战需求分析》学习笔记——分析业务模型(类图)

2019-11-19  本文已影响0人  紧松

本系列笔记是针对张传波老师所著的《火球:UML大战需求分析》的学习笔记,内容完全是对张老师书籍中重点内容的摘抄。如有侵犯,请联系本人处理。

目录

二、分析业务模型——类图

2.1 类和类图

2.1.1 类

类:需求中提到的各种业务概念、人物等,进过抽象后都可以视之为类。

类的用途:每个软件系统都会涉及到很多人、业务概念和物品等,这些东西之间可能会有很多关系,发生很多事情。类图能帮助我们识别出这些人、业务概念、物品和事情等,并理清它们的关系。

2.1.2 类图

一个类的类图

一个类就是一个矩形的方框,最上面是类的名字,中间是属性(Attribute),最下面是操作(Operation)。表示一个类时,可只显示类名,也可以只显示类名和属性,或者是类名和操作。

+  Attribute A: int

“+”表示这个属性是public类型的(“-”表示private),冒号后面的int,表示属性的类型是int型(整数型),往往在需求分析初始阶段,可不必标注属性的类型。

每一个类应该具备表征它核心特点的关键属性,而一般的无特殊意义的属性,可不必标记进去。

2.1.3 抽象类

注意图中抽象部门四个字是斜体字,这表明这个类是抽象类(Abstract Class),抽象类表示这个类是提炼出来的一种概念,不是具体存在的,具体存在的是继承抽象部门的各个具体的部门。

2.1.4关联类

上图中在表示公司与雇员关系的直线上,拉出一条虚线,虚线另一端连接劳动合同类,这样的类叫做关联类(Association Class),关联类是对两个类的关系的进一步约束。

2.2 类之间的关系

2.2.1 关联关系(Association)

a. 一对一的关系

b. 一对多的关系

c. 一对零到三个的关系

d. 角色关系

角色前的“+”号表示这个角色的类型是public,“-”号则表示private。

e. “导航”关系

表示由“教师”可以找到“学生”

2.2.2 “包含”关系

两种“包含”关系:聚合和复合

a. 聚合关系(“弱”包含)Aggregation

班级消失,则学生依然存在。学生可属于多个班级。

b. 复合关系(“强”包含)Composition

班级消失,学生消失。学生仅属于此班级。

c. “包含”关系中的数量关系

存在0到多个班级、0到多个学生,每个学生仅属于某一班级。

2.2.3 “继承”关系(泛化Generalization)

表示A继承了B,A具备B的特点,同时也有自己特有的特点,注意不要搞错继承方向。

UML中文标准术语是泛化(Generalization),上图可读作:A泛化为B。

2.2.4 “依赖”关系(依赖Dependency)

表示A依赖于B,依赖程度是相对而言的,不一定是A没有B就无法存在了。在具体的业务逻辑中,对于某个事情,A需要B来协助才能完成,这样也是一种依赖。

2.2.5 读图检查法

你可以分别从左往右、从右往左来读图,看看有没有不合理的地方。以上图为例,从左往右读:1个你对应多个你的另一半。从右往左读:1个你的另一半对应1个你,而不要读成多个你的另一半对应1个你。

注意:由“多”的一边往另一半读时,仍然是1个什么对应多少个什么,无论你从哪边开始读起,都是由“1个……”开头。

2.2.6 “递归”关系

“自包含”

“自关联”

2.2.7 “三角”关系

2.3 如何识别类

用类图获取需求的大致步骤如下:

1) 识别出类;

2) 识别出类的主要属性;

3) 描绘出类之间的关系;

4) 对各类进行分析、抽象、整理。

上一篇下一篇

猜你喜欢

热点阅读