常用技术文档图--usecase图

构成

用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。

参与者

参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。还有一点要注意的是,参湖与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员,他参与图书馆管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里小明扮演了两个角色,是两个不同的参与者。参与者在画图中用简笔人物画来表示,人物下面附上参与者的名称。

用例

是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义,对我们初学者可能有点难懂。我们可以这样去理解,用例是参与者想要系统做的事情。对于对用例的命名,我们可以给用例取一个简单、描述性的名称,一般为带有动作性的词。用例在画图中用椭圆来表示,椭圆下面附上用例的名称。

系统边界

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分,边界外表示系统外部。系统边界在画图中方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。因为系统边界的作用有时候不是很明显,所以我个人理解,在画图时可省略。

箭头

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方,箭头头部用来表示被启动的一方,其中用例总是要由参与者来启动。

在这里插入图片描述
用例图主要的作用有三个:(1)获取需求;(2)指导测试;(3)还可在整个过程中的其它工作流起到指导作用。

元素之间的关系用例图中包含的元素除了系统边界、角色和用例,另外就是关系。关系包括用例之间的关系,角色之间的关系,用例和角色之间的关系。

角色之间的关系

角色之间的关系。由于角色实质上也是类,所以它拥有与类相同的关系描述,即角色之间存在泛化关系,泛化关系的含溺义是把某些角色的共同行为汰提取出来表示为通用的行为。
用例之间的关系:
包含关系:基
USE CASE图
USE CASE图
本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系,这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。
泛化关系:代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段,泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义,子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
扩展关系的基本含义和佣泛化关系类似,但在扩展
USE CASE图
USE CASE图
关系中,对于扩展用例有更多的规则限制,基本用例必须声明扩展点,而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样,扩展关系也是依赖关系的版型。在扩展关系中,箭头的方向是从扩展用例到基本用例,这与包含关系是不同的。
用例的泛化、包含、扩展关系的比较。一般来说可以使用“is a”和“has a”来判断使用那种关系。泛化和扩展关系表示用例之间是“is a”关系,包含关系表示用例之间是“has a”关系。扩展与泛化相比多了扩展点,扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系,实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时,可以
USE CASE图
USE CASE图
在基本用例中设置扩展点,使用扩展关系。扩展关系比较难理解,如果把扩展关系看作是带有更多规则限制的泛化关系,可以帮助理解。通常先获得基本用例,针对这个用例中的每一个行为提问:该步骤会出什么差错?该步骤有不同的情况工作怎样以不同的方式进行等,把所有的变化情况都标识为扩展。通常基本用例很容易构造,而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时,可以把相似的部分从两个用例中抽象出来单独作为一个用例,该用例被这两个用例同时使用,这个抽象出的用例和另外两个用例形成包含关系。
用例之间的关系举例
包含:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。
扩展:系统中允许用户对查询的结果进行导出、打印。对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的。导出、打印和查询相对独立,而且为查询添加了新行为。
泛化:子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。
用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化,使用户能够理解如何使用这些元素,并使开发者能够实现这些元素。
将每个系统中的用户分出工作状态的属旺性和工作内容,方便建模,防止功能重复和多余的类。
用例图定义了系统的功能需求,它是从系统的外部看系统功能,并不描述系统内部对功能的具体实现。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
进行一次修改和扩展,以进一步完善系统的功能和逻辑。 首先,我将在现有的用例模型中添加一个新的用例。这个用例是关于用户注册的功能。在这个用例中,用户可以填写必要的注册信息,例如用户名、密码和电子邮件地址。系统会对用户提交的信息进行验证,确保注册信息的合法性。如果注册信息有效,系统将创建一个新的用户账户,并向用户发送一封验证邮件。 另外,我还会修改现有的用例,添加一些新的步骤和功能。例如,在用例"在线购物"中,我会增加一个新的步骤,让用户选择支付方式。用户可以选择信用卡支付或者支付宝支付,并输入相应的支付信息。系统会将用户的支付信息保存并进行相应的处理。 此外,我还会优化现有用例中的一些功能和步骤。例如,在用例"查询订单"中,系统会显示用户的订单列表。为了提高用户的体验,我想在订单列表中添加一些筛选和排序功能,让用户可以根据自己的需求快速找到想要的订单。 最后,我会更新用例模型中的相关文档,确保所有的修改都得到记录和归档。我将对用例进行详细的描述,包括相关的前置条件、后置条件和活动流程等。 通过上述的修改和扩展,系统的功能将得到进一步的完善和优化,用户将能够更方便、更快捷地使用系统的相关功能。这对于提升系统的用户体验和用户满意度非常重要。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值