系统分析与设计知识点用例建模发布.docx

系统分析与设计知识点用例建模发布.docx

《系统分析与设计知识点用例建模发布.docx》由会员分享，可在线阅读，更多相关《系统分析与设计知识点用例建模发布.docx（11页珍藏版）》请在冰豆网上搜索。

系统分析与设计知识点用例建模发布

系统分析与设计——用例分析与建模

一、用例建模概念

⏹大多数项目失败的原因就在于需求不明确。

⏹用例（UseCase）描述的是参与者为了使用系统所提供的某一功能而与系统之间发生的交互（执行的一系列的动作序列）；

•一种描述系统需求的方法；

•使用用例的方法来描述系统需求的过程就是用例建模。

•用例的各个成分将强迫你思考真正的需求。

⏹用例方法的基本思想

•从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的。

•用例图（用例模型）是从用户角度来描述系统功能的。

强调的是外部功能，不反映功能的实现方式。

•用例图用来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用户提供的功能。

•用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。

二、用例图的构成

▪用例图用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的连接关系。

▪用例图的构成元素

1参与者（Actor）（活动者、角色）

2用例（UseCase）

3关系（Relationship）

参与者（活动者、角色）

▪参与者（actor）是系统外部与系统交互的事物。

也被称为活动者。

▪参与者参与用例的执行过程。

▪每个参与者可以参与一个或多个用例。

参与者的特征是其作为外部用户与系统发生交互。

⏹参与者是由参与用例时所担当的角色来表示。

⏹Actor不是指人，而是指代表某一种特定功能的角色。

因此，一个人可能对应多个Actor。

⏹Actor是虚拟的概念，可以指外部系统和设备。

提供信息，获取信息，操作系统，维护系统，使用哪些外部资源

参与者在系统中的作用主要包括：

1.系统的启动者

2.系统的服务者

3.系统服务的接收者

用例

▪用例是系统、子系统或类，与外部的参与者（actor）交互的动作序列的说明。

▪用例定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一功能而与系统之间发生的交互（执行的一系列的动作序列）。

▪用例是外部可见的系统功能单元，是对功能需求的描叙。

▪用例分析可以认为是系统功能的分解。

▪用例的名称：

1简单名

2路径名：

指出用例所在的包

（可以用包将相关的用例进行组装）

▪用例识别

识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。

系统边界

在项目开发过程中，边界是一个非常重要的概念。

这里说的系统边界是指系统与系统之间的界限。

通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。

把什么作为一个用例，前提是你事先划定了一个边界。

站在边界外的是actor，边界内的是用例。

边界同时可以决定粒度。

关系

注意：

•这里没有实现关系。

主要是关联、依赖、泛化的关系。

•关联指参与者与用例之间的关系

•包含、扩展、泛化指用例之间的关系

泛化即可以用于参与者之间的关系，也能用于用例之间的关系

关联关系

▪表示参与者用例之间进行通信。

▪每个用例都有参与者启动，除了依赖（包含和扩展用例）。

▪一个参与者可以访问多个的用例；

▪一个用例可以被多个参与者访问。

▪关联关系是单向的。

包含关系

注意：

被包含用例如果不存在了，基用例就不完整了，即基用例依赖于被包含文件的存在而存在。

扩展关系

注意1扩展用例的明显特征：

每次执行不一定要调用扩展用例。

依赖关系中，执行A一定执行B，则A和B之间是包含依赖。

如果不一定则是扩展依赖

注意2扩展用例不能单独执行

▪扩展用例被定义为基础用例的增量扩展。

▪基础用例提供扩展点以添加新的行为。

▪注意：

基础用例本身是完整的，可以单独存在，在每次执行基础用例时，扩展用例不是每次都被执行。

扩展用例的执行必须依赖于基础用例。

泛化关系

▪子用例表示父用例的特殊形式。

▪子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。

三、管理用例的复杂度

▪用例分析可以认为是对系统功能的分解。

用例的粒度（用例大小）

▪一个系统需要有多少个用例？

在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。

（一般来讲：

1个系统10-20几个用例比较合适。

）

▪划分若干的子系统，每个子系统放到一个包中。

▪用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。

▪我们应该根据每个系统的具体情况，因时因地制宜来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。

▪对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。

▪对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。

（1）过于关注于实现而不是关注需求（增删改等细节）

（2）过于具体，局限性容易漏掉需求（比如，学生转学）

（3）细节过多，导致系统模型过于复杂

用例包

▪包（Package）是UML中最常用的管理模型复杂度的机制，它就是一种分组容器，在包中可以容纳其他任意的模型元素（包括其他的包）。

▪在用例模型中，我们可以用构造型<>来扩展标准UML包的语义，叫用例包（UseCasePackage），用于分类管理用例模型中的模型元素。

▪如何创建用例包以及用例包的个数取决于不同的系统和系统分析员，但要保证整个用例模型易于理解。

四、用例描述

⏹用例图描述了参与者和系统特征之间的关系，但是它缺乏描述系统行为的细节。

⏹所以一般情况下，还会以书面文档的形式对用例进行描述，每个用例应具有一个用例描述。

⏹在UML中对用例的描述并没有硬性规定，但一般情况下用例描述应包括以下几个方面：

▪用例名称

表明用例的用途，如上面示例中的“借阅图书”、“归还图书”。

▪标识符[可选]

惟一标识符一个用例，如“UC200601”。

这样就可在项目的其他元素（如类模型）中用它来引用这个用例。

编号

▪参与者[可选]

与此用例相关的参与者列表。

尽管这则信息包含在用例本身当中，但在没有用例图时，它有助于增加对该用例的理解。

▪简要说明

对该用例进行说明，描述用例作用。

注意语言简要，使用自然语言。

▪前置条件

一个条件列表。

前置条件描述了用例之前系统必须满足的条件。

如果条件不满足，则用例不会被执行。

例如：

借阅图书用例

前置条件：

学生出示的借书证必须是合法的借书证。

▪后置条件

后置条件在用例成功完成后得到满足，它提供了系统的部分描述。

用例结束后，系统处于什么状态。

例如：

借阅图书用例

后置条件：

借书成功，则返回该学生借阅信息；借书失败，则返回失败的原因。

▪扩展点

如果包括扩展用例，则写出扩展用例在什么情况下使用。

应该在编写事件流的同时编写。

▪基本事件流

描述当各项工作都正常进行时用例的工作方式。

事件流描述了用户和执行用例之间交互的每一步。

事件流是将个别用例进行合适的细化任务。

可以发现原始用例图遗漏的内容。

▪其它事件流（扩展事件流，错误事件流）

在变更工作方式、出现异常或发生错误的情况下所遵循的步骤。

五、用例建模

六、案例

图书管理系统的主要功能

（1）图书借阅员主要使用图书管理系统借出图书、归还图书、续借图书、查询信息等，也可以修改密码，以合法身分登录系统。

（2）图书管理员主要管理图书类型、借阅者类型、出版社数据、藏书地点、部门数据等基础数据，编制图书条码、打印书标、图书入库、管理书目信息、维护借阅者信息、办理借书证等。

（3）系统管理员主要是管理用户、为用户分配权限、设置系统参数、备份数据、保证数据完整、保证网络畅通和清除计算机病毒等。

（4）图书借阅者可以查询书目信息、借阅信息和罚款信息。