UML复习

UML笔记

UML的主要内容就是画图和面向对象的分析设计。

画图的过程当中咱们要注意每种图的元素和每种图的做用。

面向对象的分析设计中咱们要了解OA和OD的思想。

这些都是考试的重点

1. 用例图

1.1 什么是用例

用例是一个活动者（Actor）使用系统的一项功能时所进行的交互过程的一个文字描述序列。

用例的做用

1. 用例是软件从需求分析到最终实现的最后一步，它显示了用户但愿系统实现的功能，有利于用户和软件开发人员之间的沟通。
2. 用例可视化地表达了用户的需求和系统功能，克服了纯文字的说明性不足。
3. 用例是从外部定义系统，用户不用关心系统内部是如何实现各个功能的。

Actor的描述

Actor包括系统以外的须要使用系统与系统进行交互的事物，包括人、设备、外部系统等。

用例的读者

开发人员、用户、项目经理、测试人员等

用例中的关系

Actor与uc之间的关系

actor与use case之间是关联关系，因此他们之间用直线链接

uc与uc之间的关系

1. 泛化
   泛化关系是父子关系，用空心三角箭头表示。箭头指向父uc
2. 包含
   包含关系是完成一个uc动做同时须要完成的动做，通常是多个uc作以前都须要完成这个动做咱们把它抽象为一个包含关系，就是不少uc都包含这个uc。
   包含关系使用虚线箭头表示，箭头指向被包含的这个uc。
3. 扩展
   扩展关系是我在当前uc上扩展出新的uc，可是我不必定要作这个uc的关系。
   扩展关系也是用虚线箭头表示，箭头指向须要扩展的当前uc。

1.2 如何画一个用例图

肯定系统

用例图自己就是为系统设计的，通常我要作的这个东西就是系统。

肯定actors

识别活动者通常有如下几个思路

1. 谁使用了系统的功能
2. 谁修改了系统的数据
3. 谁从系统处获得信息
4. 谁须要对系统进行维护
5. 系统须要哪些硬件设备的支持？

肯定use case

用例实例

语法测试：【用户】使用系统来【用例】

用例实例是在系统中执行的一系列动做，这些动做将产生活动者想要的价值结果。一个用例是由多个用例实例组成的。

避免CURD

肯定uc的时候很容易犯的错误是看到增长、修改、查阅和删除等操做就把他们列为use case，这样会花费本身不少精力但得不偿失。

1.3 案例：邮箱系统

目标：构建一个语音邮箱系统

邮箱系统描述：

语音邮箱系统中,能够为每一个系统用户(邮箱主人)分配一个语音邮箱号码.
进行留言时, 拨打语音邮箱系统的主号码, 在听到提示音“请输入邮箱号”后,输入语音邮箱号,听到主人设定的问候语后,进行留言而后挂断电话.
邮箱主人拨打语音邮箱系统的主号码,在听到提示音“请输入邮箱号”后,输入语音邮箱号,听到主人设定的问候语后, 输入密码进行邮箱管理. 此时系统提供三种服务:1.接收信息; 2.更改问候语; 3.更改密码.其中接收留言包括收听新留言、存储留言、删除留言等。

肯定系统：

邮箱系统

肯定actor

邮箱主人和留言者

肯定use case

共同：

1. 拨打语音邮箱

邮箱主人：

1. 获得语音邮箱号码
2. 接受信息
3. 更改问候语
4. 更改密码

留言人：

1. 给邮箱主人留言

画出用例图

这张图很精妙，能够看出上面3步走的时候遇到的一些问题和对use case之间关系的理解。

总结

use case不单纯是动做，而应该是actor想要通过某一个操做达到某一个效果。（这句话有些别扭，可是在理）。在邮箱系统案例中：

邮箱主人想完成的交互：

1. 接受信息
2. 更改问候语
3. 更改密码

留言人想完成的交互：

1. 留言

这4个交互过程均可以抽象为use case，可是主人和留言人想要完成以上4个交互的时候都须要在语音邮箱系统拨号，因此这就是一个多个uc抽象出来的带有include属性的use case。邮箱主人想要修改系统信息，还须要登陆系统。

以上”拨打邮箱号码“，”登陆系统“就是分析过程当中漏掉的两个use case

2. 类图

2.1 介绍类图

做用

1. 为开发人员提供模仿现实世界的表达方式
2. 以用户的术语与客户进行交流，方便促使客户说出须要解决的重要细节。

2.2 类与类之间的关系

1. 泛化
   泛化就是继承关系。实线三角箭头指向父类。
2. 接口
   interface嘛。虚线三角箭头指向父类。
3. 组合
   总体由部分组成，部分能够独立于总体而存在。实心菱形箭头指向总体类。
4. 聚合
   总体由部分组成，部分不能够独立于总体而存在。空心菱形箭头指向总体类。
5. 关联
   拥有的关系，一个类知道并能够调用另外一个类的属性和方法。
   双向关联：老师能够有多名学生，而一个学生也能够有多名老师。
   单向关联：一个学生能够有多门课程，可是课程是抽象类没法拥有学生。
6. 依赖
   一个类的实现须要另外一个类的帮助。
   依赖关系用虚线箭头表示。箭头指向被依赖的对象。

2.3 类的版型

边界类

边界类是系统与外界的皎洁。如UI、窗体等类。

控制类

控制类用于体现应用程序的执行逻辑，提供相应的业务操做，将控制类抽象出来能够下降界面和数据库之间的耦合度。

控制类通常是由动宾结构的短语（动词+名词）转化来的名词，如增长商品对应有一个商品增长类，注册对应有一个用户注册类等

实体类

实体类保存要放进持久存储体（数据库／文件等）的信息。通常咱们建立的类都是实体类，好比书类、计算机类等。

2.4 类图的抽象层次

2.5 如何构造类图

1. 寻找案例中的名词
2. CRC原则（Class、Responsibility、Collaboration）

案例：图书管理系统

2.6 对象图

3. 顺序图和协做图

3.1 顺序图

基本概念

顺序图显示的是对象之间交互的图，按照时间顺序排列。时序图是一个模型，用于描述对象如何随着时间在某些行为方面进行协做。

顺序图的命名

1. objectName:className
2. :className
3. objectName

因此看到奇怪的命名方式不要感到惧怕

构成要素

1. 对象
2. 生命线
3. 控制焦点

案例：图书管理系统

案例描述：

课件里的案例比较奇怪，边界类比较少讲可是在这个案例里用了不少。会显得比较乱。

常见问题

1. 消息循环发送
   *[i:= 1..n ]:Message2()
2. 消息条件发送
   1.[a>b]:message()
   2.使用文字说明
3. 类图和顺序图中对象的关系
   须要相互参考、相互补充、相互协调

3.2 协做图

概念

协做图是表示对象间的交互图，侧重强调对象间的协做。

转换成协做图也比较容易，找到最开始的类，而后根据开始类延伸出一系列的类，相似画脑图同样的方式画出来就是协做图了。

若是一个协做图中的两个对象之间的交互超过了两个该怎么画这样的协做图？

答：一条状态线上能够有多个交互，也就是多个箭头。➡️➡️

3.3 顺序图&协做图

相同

1. 都支持全部的消息类型
2. 都肯定了发送者和接受者的责任
3. 都能在必定程度上衡量系统的耦合度

不一样

1. 协做图不能反映对象的建立、撤销等操做
2. 顺序图强调的是时间顺序上的交互，协做图强调的是对象与对象之间的的交互
3. 协做图必需要有消息的序列号

4. 状态图和活动图

4.1 状态图

定义

状态图描述的是一个对象生命周期中的状态序列，以及引发状态变化的事件和伴随状态变化后的动做。

组成状态图的元素

1. 实心圆圈：初态
2. 实心圆圈外一个圈：终态
3. 圆角矩形：状态
4. 箭头：转换。描述包括触发事件、监护条件和动做等。turnOn[water exists]/boil water

细节

1. 能够设置某个状态进入和退出的时候执行什么：
   entry/balabala和exit/balabala
2. H：
   表示历史状态

4.2 活动图

定义

活动图是描述系统行为的模型，用来描述过程当中活动及其迁移。

活动图中能够包含多个对象，在图中 有客户、系统和供应商三个对象。

组成活动图的元素

1. 实心圆圈：初态
2. 实心圆圈外一个圈：终态
   1. 椭圆矩形：活动节点
3. 菱形：分支与监护条件
4. 粗直线与箭头：分岔与汇合
5. （泳道）（对象流）

4.3 状态图&活动图

相同

1. 都是对系统的动态行为建模。

不一样

1. 状态图主要表示对象之间的交互关系，活动图主要表示过程当中活动的交互关系。
2. 状态图中可以表现出并发

5. 构件图与部署图

5.1 构件图&部署图

构件图用来建模系统的各个构件，包括源代码文件、脚本文件、可执行文件等。它们是经过关系或者包的形式组织在一块儿的。构件图能够帮助咱们了构件实现了软件的哪些功能和构件位于软件的什么位置。

部署图帮助咱们了解各个构件驻留在什么硬件位置，以及硬件节点之间的交互关系。

5.2 构件图

构件是系统中可更换的代码模块。

构件图的解读

1. 构件能够由构件组成
2. 构件之间的关系主要是依赖：include、import和implement等。
   关系表示为虚线箭头上的文字
3. 构件还能够和类图中的对象产生联系。

5.3 部署图

案例：web server

描述：

例 建模一个网上扫描系统的部署图。其详细的需求以下所示：

扫描仪经过内部的PCI总线链接到网卡。须要编写代码来控制扫描仪，代码驻留在扫描仪内部。

扫描仪经过无线网卡与插入到Web服务器KONG的无线hub通讯，服务器经过HTTP协议向客户PC机提供Web页。

Web服务器安装定制的Web服务器软件，经过专用数据访问构件与产品数据库交互。

在客户的PC机上将提供专用的浏览器软件，它运行产品查询插件，只与定制的Web服务器通讯。

画部署图的过程

1. 肯定节点

   注意案例中出现的硬件中网卡和无限模块的关系。因此最后肯定下来的节点有：

   Scanner、NetworkCard、WirelessHub、KONG:WebServer和ClientPC。共5个

2. 添加通讯关系

   根据案例的描述很容易肯定通讯关系

3. 添加构件

   在硬件中有什么软件基本上就是须要寻找的构件。本案例中把DB做为一个构件而不是一个硬件放在部署图中，多是由于确实须要用到的地方实在比较小不做为一个硬件。

4. 肯定关联关系

   easy

6. GRASP原则

​ GRASP(General Responsibility Assignment Software Patterns)，中文名称为“通用职责分配软件模式”，GRASP一共包括9种模式，它们描述了对象设计和职责分配的基本原则。

案例：购物车、商品

6.1 基本模式

信息专家（Expert）

通俗点来说，就是一个类只干该干的事情，不应干的事情不干。在系统设计时，须要将职责分配给具备实现这个职责所须要信息的类。信息专家模式对应于面向对象设计原则中的单一职责原则。

创造者（Creator）

若是符合下面的一个或者多个条件，则可将建立类A实例的职责分配给类B：

• B包含A；
• B聚合A；
• B拥有初始化A的数据并在建立类A的实例时将数据传递给类A；
• B记录A的实例；
• B频繁使用A。

此时，咱们称类B是类A对象的建立者。若是符合多个条件，类B聚合或者包含类A的条件优先。

低耦合模式（Coupling）

耦合是评价一个系统中各个元素之间链接或依赖强弱关系的尺度

为了下降改变带来的影响和类与类之间的依赖，并提升重用性提出了低耦合的思想。

低耦合的基本原则

1. Don't Talk To Strangers

   不须要通讯的两个类就谁也别理谁好了。

2. Transfer

   若是一个职能分配给A不合适（提升了耦合度或者不符合信息专家原则），能够把这个职能分配给和A有链接的B

3. no connection between inner class

   两个不一样模块的内部类之间不能直接链接

高内聚模式（Cohesion）

内聚是评价一个元素的职责被关联和关注强弱的尺度。

在一个低内聚的类中会执行不少互不相关的操做，操做与操做之间没有联系会显得这个类很是杂乱，难以理解。

控制器模式（Controller）

问题：谁应该负责处理一个输入系统事件？

分析：一个控制器是接受并处理系统事件的非图形用户界面的对象。一般一个控制器须要把接收的任务委托给其余对象，它只负责控制和协调，自己不完成太多的功能。控制器不用包含太多的业务逻辑，因此一个系统能够也应该设计多个控制器实现对不一样模块的控制。

6.2 拓展模式

多态（Polymorphism）

就是咱们学习的多态，能够经过不一样的子类实现不一样的功能。

纯虚构（Fabrication）

目的

纯虚构模式用来处理低耦合与高内聚之间的矛盾。高内聚须要拆分出更多数量的类，可是对象之间须要协做来完成任务，这又形成了高耦合，反之亦然。

定义

和C++中的纯虚函数相似，将实体类中的一部分功能抽象出来成为纯虚类。

中介模式（Indirection）

不影响耦合和状况下把两个类链接起来

受保护变化模式（Variation）

定义

预先找出不稳定的变化点，使用统一的接口封装起来，若是将来发生变化的时候，能够经过接口扩展新的功能，而不须要去修改原来旧的实现。也能够把这个模式理解为OCP(开闭原则)原则，就是说一个软件实体应当对扩展开发，对修改关闭。

6.3 补充：单一职责原则

“就一个类而言，应该仅有一个引发它变化的缘由。”也就是说，不要把变化缘由各不相同的职责放在一块儿，由于不一样的变化会影响到不相干的职责。

案例：

图形绘制程序和Area()之间没有任何联系，违反了单一职责原则，应改成：

7. 面向对象设计原则

7.1 OO的原则

单一职责原则

应该只包含单一的职责，而且该职责被完整地封装在一个类中。

就一个类而言，应该只有一个引发它变化的缘由。

开闭原则

软件实体应该对扩展开放，对修改关闭。

软件应该具备稳定的抽象层+灵活的具体层，找到系统的可变因素并将其封装起来。

里氏替换原则

全部引用基类的地方必须可以透明地使用其子类的对象。

在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和一异常，反过来则不成立。

我喜欢动物——>我喜欢狗

依赖倒转原则

高层模块不该该依赖低层模块，他们都应该依赖抽象。

在程序中尽可能使用抽象层进行编程，而将具体类写在配置文件中。

接口分离原则

客户端不该该依赖哪些它不须要的接口。

当一个接口太大的时候，能够将它分割成更小的接口。每个接口应该承担一种相对独立的角色，不应作的事情不要作。

7.2 其余原则

合成复用原则

优先使用对象组合，而不是继承来达到复用的目的。

继承复用实现简单、易于拓展，可是破坏了系统的封装性。组合／聚合的耦合度较低，能够有选择性地调用对象的操做。

迪米特法则

一个软件实体应当尽量少于其余实体发生相互做用来下降耦合度。

不要和陌生人说话就是迪米特法则的内容。

8. 面向对象的分析设计

OOA的主要构成

如何使用OOA进行分析

OOD的方法

7.1 为何须要面向对象的分析设计？

因为现实世界中的问题一般较为复杂，分析过程当中的交流又具备随意性和非形式化等特色，每每客户对软件的需求是站在用户的角度，而做为软件构架的工程师要按照软件的角度来分析客户的需求。为了保证软件需求规格说明的正确性、完整性和有效性就须要进一步验证，咱们须要有一套完整而且具备至关可信力的分析设计体系，以便及时加以修正。所谓分析就是理解客户脑子中的概念，跟客户来沟通，分析出专业术语。设计就是对分析出来的专业术语进行概括，让程序员可以思路更加清晰、更加顺利进行软件的开发活动。

7.2 OOA（Analysis）

面向对象分析方法（Object-Oriented Analysis，OOA），是在一个系统的开发过程当中进行了系统业务调查之后，按照面向对象的思想来分析问题。OOA所强调的是在系统调查资料的基础上，针对OO方法所须要的素材进行的归类分析和整理。

OOA的主要部分

OOA的主要部分分为需求模型、基本模型、辅助模型和模型规约。

需求模型的主要表现方式就是咱们使用作多的用例图，这是咱们进行面向对象分析的起点，咱们设计人员根据客户的需求来建立和解释用例图，用来描述软件应具有哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来链接以求把系统的整个结构和功能反映给客户，最终咱们会获得软件的结构和功能分解。

基本模型的主要表现方式是咱们常常用到的类图，而基本模型能够分为3个层次：对象层、特征层和关系层。对象层给出全部问题域和系统责任有关的对象，用对象类表示。特征层定义每一个对象类的属性与服务。关系层经过必定义的关系描述对象类之间的关系。

辅助模式的主要表现方式包括交互图、活动图、状态图和包图等。这些图都可以帮助咱们更好地理解和分析整个系统开发的业务和逻辑。

模型规约对模型中的全部元素进行详细说明。

OOA方法的基本步骤

首先肯定需求和系统。系统是指事物的整体概貌和整体分析模型，对系统进行大体的规划是开始系统分析的第一步。

而后捕捉系统系统中的对象。这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。同时咱们须要将捕捉到的对象进行分类为系统和系统以外的，分离出用户、用例并画出用例图。

以后划分类和类的属性。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中创建一个新对象的描述。属性就是数据元素，可用来描述对象或分类结构的实例，可在类图中给出，并在对象的存储中指定。

最后识别对象间的关系。结构是指问题域的复杂性和链接关系。类成员结构反映了泛化-特化关系，总体-部分结构反映总体和局部之间的关系。

若是有特殊须要，还能够创建详细说明，对模型中的成分进行规范的定义和文字说明，能够集中进行，也能够分散在各个活动中。

OOA的主要原则

（1）抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫做抽象。抽象是造成概念的必须手段。抽象是面向对象方法中使用最为普遍的原则。抽象原则包括过程抽象和数据抽象两个方面。过程抽象是指，任何一个完成肯定功能的操做序列，其使用者均可以把它看做一个单一的实体，尽管实际上它多是由一系列更低级的操做完成的。数据抽象是根据施加于数据之上的操做来定义数据类型，并限定数据的值只能由这些操做来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操做（服务）结合为一个不可分的系统单位（即对象），对象的外部只须要知道它作什么，而没必要知道它如何作。

（2）封装：把对象的属性和服务结合为一个不可分的系统单位，并尽量隐蔽对象的内部细节。

（3）继承：特殊类的对象拥有的其通常类的所有属性与服务，称做特殊类对通常类的继承

（4）分类：就是把具备相同属性和服务的对象划分为一类，用类做为这些对象的抽象描述。分类原则其实是抽象原则运用于对象描述时的一种表现形式。

（5）聚合：又称组装，其原则是：把一个复杂的事物当作若干比较简单的事物的组装体，从而简化对复琐事物的描述。

（6）关联：是人类思考问题时常常运用的思想方法：经过一个事物联想到另外的事物。能令人发生联想的缘由是事物之间确实存在着某些联系。

（7）消息通讯：这一原则要求对象之间只能经过消息进行通讯，而不容许在对象以外直接地存取对象内部的属性。经过消息进行通讯是因为封装原则而引发的。在OOA中要求用消息链接表示出对象之间的动态联系。

（8）粒度控制：通常来说，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。所以须要控制本身的视野：考虑全局时，注意其大的组成部分，暂时不详察每一部分的具体的细节；考虑某部分的细节时则暂时撇开其他的部分。这就是粒度控制原则。

（9）行为分析：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各类行为每每相互依赖、相互交织。

7.3 OOD（Design）

OOD（Object Orient Design）是一种解决软件问题的设计范式，一种抽象的范式。抽象能够分红不少层次，从很是归纳的到很是特殊的都有，而对象可能处于任何一个抽象层次上。另外，彼此不一样但又互有关联的对象能够共同构成抽象：只要这些对象之间有类似性，就能够把它们当成同一类的对象来处理。

OOD设计

OOD的主要工做是使用OOA的结果，将OOA得出的问题，给予设计方案解决。这一阶段须要作的是对软件系统的设计和规划，包含的工做为：

①问题域部分的设计；

对OOA的对象和类的模型进行细致修改，详细考量类的属性、删除没必要要的类、抽象须要的继承层次、组织对象的包含结构、对象间消息的传递方式和总体消息顺序安排；

②人机交互与应用控制部分的设计；

交互界面子系统的设计:与界面有关的类及类间结构的设计,以及有关算法的设计；

交互界面子系统和应用之间接口的设计；

应用控制部分的设计:这部分对象主要完成应用的驱动工做。这部分对象不一样于从现实世界中抽象出来的对象，在现实世界和问题域中没有原型，它们同界面子系统中的对象及问题对象发生做用，控制系统的运行。

OOD阶段就须要细致到软件的具体实现，而后是人机交互方面，如何使UI合理的提供交互，是否便于后续的功能扩展等。

OOD的目标

OOD的目标是管理程序内部各部分的相互依赖。为了达到这个目标，OOD要求将程序分红块，每一个块的规模应该小到能够管理的程度，而后分别将各个块隐藏在接口的后面，让它们只经过接口相互交流。好比说，若是用OOD的方法来设计一个服务器-客户端应用，那么服务器和客户端之间不该该有直接的依赖，而是应该让服务器的接口和客户端的接口相互依赖。

OOA和OOD的区别

OOA重点在于业务需求的分析，而OOD需在前述的问题基础上设计软件结构。