UML概要基础知识(待完善)

最新推荐文章于 2022-08-26 17:45:27 发布

GU_PPY

最新推荐文章于 2022-08-26 17:45:27 发布

阅读量1.1k

点赞数

分类专栏：软件工程文章标签： uml 软件工程师

本文链接：https://blog.csdn.net/qq_43506805/article/details/115011463

版权

本文介绍了UML的基本元素，重点讲述了用例的定义、特征、业务用例和用例粒度。用例是参与者驱动的活动集合，其粒度取决于分析阶段。此外，还探讨了边界、包和分析类在系统建模中的作用，为理解和应用UML提供基础。

摘要由CSDN通过智能技术生成

记录—UML

Written by guppy.

version: 0.3

1. 概述

OOA（面向对象分析）为上世纪七十年代末期面向对象运动兴起所诞生，在最初面向对象进入的领域是编程领域，面向对象语言Smalltalk诞生，但软件分析与设计还是以结构化的面向过程方法为主。后面许多面向对象大师创建了自己的面向对象分析方法，随方法不同但理念相通。

有三位面向对象大师决定将其他们各自的方法统一起来，在1995年10月推出了第一个版本，称为“统一方法”（Unified Method 0.8），随后又以“统一建模语言”（Unified Modeling Language）UML 1.0的正式名称提交到OMG（对象管理组织）。

2. 基础元素

2.1 用例

2.1.1 概述

用例（Use Case），由参与者（actor）驱动的，并且给参与者提供可供观察的 有意义的结果的一系列活动的集合。它是一种把现实世界的需求捕获下来的方法。

官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观察的值。

换句话说，一个用例就是与参与者（actor）交互的，并且给参与者提供可供观察的有意义的结果的一系列活动的集合。而做一件事可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这种事情是由很多不同情况的集合构成的，在UML中称之为用例场景，一个场景就是一个用例的实例。

比如说你想做饭，你需要完成煮饭和炒菜两件事情，这两件事情就是两个用例。而煮饭可以有不同的做法，你可以用电饭煲煲饭，也可以用蒸笼做，这就是两个不同的场景，也就是两个实例。而同样用电饭煲做饭，如果是糙米你可能需要先淘米，也是精米你可以省掉淘米的步骤直接下锅，这是用例在不同条件下的不同处理场景。

综上，一个完整的用例由参与者、前置条件、场景、后置条件构成。如下图图2-1：

2.1.2 特征

用例有一系列的特征，这些特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否正确的依据。

用例是相互独立的

这就是说它不需要与其它用例进行交互就能直接完成参与者的目的。

用例的执行结果对参与者来说是有意义的和可观察的

比如说，登陆系统是一个有效的用例，但输入密码却不是。登陆系统对参与者来说是有意义的，可以获取身份认证和授权，单纯输入密码却没有任何意义。还有如下图2-2、图2-3，转账是一个有效的用例，而填写收款人账户却不是。

又比如说，有一个后台进程监控系统操作，并在参与者删除数据之前进行备份操作，虽它是系统的一个必须的组成成分，但是在需求阶段它不应该作为用例出现，它是后台进程，对参与者来说是不可观察的。

一件事必须由一个参与者发起，不存在没有参与者的用例，也不能主动启动另外的用例

用例是由参与者的愿望所诞生，是希望系统能够为参与者完成某些业务或事情，那么系统的必定需要参与者来驱动。例如从ATM机中取钱是有效的用例，ATM机吐钞票却不是。

高中的时候，我们学过，没有外力影响下，一个物体保持匀速直线运动和静止不动，一个独立无外力影响的系统要么静待命令，要么一直做相同的事，哪怕是定时发送邮件，也需要参与者先为定时模块设定发送时间。因此一个用例不能主动驱动或启动另一个用例。

用例必然是由动宾短语的形式组成的

用例必须有一个动作和动作的受体。比如，喝水是一个有效的用例，而“喝”和“水”却不是

一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元

一旦决定了用例，软件开发工作的其他活动都以这个用例为基础，围绕它进行。分析、设计、组织、开发、测试、部署都需要围绕需求单元来进行活动开展。

2.1.3 业务用例

业务用例（business use case）是用例版型中的一种，专门用于需求阶段的业务建模。形状如下图“图213-1 业务用例图”。

图213-1 业务用例图

本还有两个业务用例的版型，业务用例实现和概念用例，但在EA中没有，就不做绘制了，用处其实都可以用最基本的椭圆来替代，整这么版型倒还需要记概念，不需要这么复杂。

2.1.4 用例粒度

用例的粒度是令人困扰的，比如在ATM机取钱的场景下，取钱、读卡、验证账号、打印回执单，都是可能有的用例，但是取钱这一用例明显包含了后续的这些用例，取钱这一用例明显粒度大于后面这些，其它用例要小一些，那到底是一个大的用例好些还是拆解成几个小用例好些呢？

这里有一些建议，在不同阶段使用不同粒度的用例。

在业务建模阶段，用例以每个用例能够说明一件完整的事情为宜，既一个用例描述一项完整的业务流程。
在用例分析阶段（概念建模阶段），用例的粒度能够完整的描述一件事情为宜。既一个用例描述一项完整业务的一个步骤。
在系统建模阶段，用例视角是面向计算机的，因此用例的粒度以一个用例能够完整描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、取消申请单等等。

这些也只是一些建议，可实际根据自身实际情况划分粒度，只要是以该用例是否完成了参与者的某个完整目的为依据的。一切从实际目的（需求）出发。