UML笔记(二)--用例图

本文详细介绍了UML用例图在需求分析中的重要性,包括用例、参与者、场景和系统边界的定义。讨论了用例的目的、编写形式以及如何发现用例,并提醒在实际项目中应关注参与者的目标和业务流程。同时,阐述了用例的关联关系如包含、扩展和泛化,强调避免过度关注关系而忽略用例文本的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  用例图在需求分析阶段起到很重要的作用,它将用例图形化,给人直观,便捷感觉。

  这篇就讲述下需求分析阶段所涉及到用例及用例图的内容。

  一.需求分析和用例 的一些基本概念:

     需求:系统(或者项目)必须提供的能力和必须遵从的条件。

     用例:是文本形式的情节描述,用于需求的发现和记录,用例会影响后续的ooa&d工作。

     参与者(actor):某种据用行为的事物,可以是人(由角色标识)、计算机系统或者组织。

     场景(scenario):是参与者和系统之间的一系列特定的活动和交互。

                                包括:主成功场景和交替场景(主路径和扩展路径)

    系统边界:参与者是系统外部有行为的事物,内部事物不叫参与者。

                   系统边界是由要开发的系统的,随着需求想法的不同而不同。

 

 二.用例应用注意事例:

     用例的目的 :用例强调用户的目标和观点

     需求分析时应该考虑的问题

       谁使用系统?他们的使用的典型场景是什么?它们的目的是什么?

     用例编写的形式

         摘要--需求分析早期使用,通常用于主成功场景。

         非正式--需求分析早期使用,可以覆盖不同的场景。

         详述--详细编写所有步骤及各种变化。

     用例的名称应该使用动词开始。

     编写用例的时候应该尽量使用行业的专业名称,而不是计算机专业术语。

 

三.如何发现用例:

    1.选择系统边界

    2.确定主要参与者

    3.确定每个主要参与者的目标(合适的用例粒度:基本路径10步之内)

    4.定义满足用户目标的用例,根据其目标对用例命名。

 

    真实项目发现用例的一种思维习惯--了解企业的架构和权力分布

    调研需求时最先弄清楚有多少个部门、多少个岗位(参与者);

    然后找到每个岗位的业务代表,问他们类似的问题:

       平时都做什么?(参与者目标)

       这件事情是谁交办的?

       做完后需要通知或者传达给谁?

       做这件事情需要写些什么表格?(了解数据的属性,以便自己整理)

 

四、用例关联以及一些术语 

      包含关系--主要目的是避免用例文本的重复编写。

      扩展关系--可以讲可选路径中的场景抽象为扩展关系(但一般是没有必要的)。

      泛化关系--两个或者更多的用例咋行为、结构、目的等方面存在共性时,可以使用泛化关系。

 

 PS:用例彼此之间可能具有联系。

      避免陷入用例关系的陷阱:不要话太多时间争论在用例图中如何关联用例,而不关注更重要的编写用例文本。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值