目录
从今天开始,就到了最干的各种的图的梳理和学习了,未来AI就能编码了,把业务建模和设计的基本功打好,也许能和AI和平相处呢。
UML中的用例图是一种描述系统功能的动态视图,它由参与者(Actor)、用例(Use Case)以及它们之间的关系构成。这种图主要用于对系统、子系统或类的功能行为进行建模,并展示用例之间以及同用例参与者之间是怎样相互联系的。用例图定义了系统的功能需求,是从系统的外部看系统功能,并不描述系统内部对功能的具体实现。它是需求分析中的产物,主要作用是描述参与者和用例之间的关系,帮助开发人员可视化的了解系统的功能。
用例图主要多用于需求分析阶段。
参与者(Actor)是与主体系统交互的外部实体。每个参与者实际上是一个角色集。在UML中,参与者使用使用人形的图形表示,并给这个参与者赋予一个名字。如下图中的“管理员”即是图书馆借阅系统中的一个参与者。
但是一定要注意:参与者不一定是人。
在UML的用例图中,“参与者”(Actor)是一个重要的元素,指的是与系统进行交互的外部实体。这些实体可以是用户、其他系统、组织或任何与所建模系统有交互行为的对象。参与者的主要特点是,它们不是系统的一部分,但是会与系统进行交互,从而触发系统的某些功能或行为。
简而言之,参与者是与系统发生交互作用的人或事物,它们通过用例与系统交换信息,并期望系统能够提供某种服务或功能。在用例图中,参与者通常用人形图标表示,以突出其与系统之间的交互关系。
识别用例图中的参与者是一个涉及多个维度的过程,需要综合考虑系统的各种交互场景和可能的利益相关者。以下是一些常用的方法来识别和确定参与者:
1.定义系统边界:
2.识别用户角色:
3.考虑其他系统或设备:
4.分析业务场景和用例:
5.考虑信息的来源和目的地:
6.检查现有文档和资料:
7.进行访谈和调研:
8.使用原型和模拟:
9.持续更新和调整:
10.注意特殊情况和异常:
此外,还有一些有用的思考维度,可以帮助你找到系统的参与者:
再次注意:参与者可能是其它子系统、其它系统、时间、温度等其它因素。
在用例图中,参与者之间的关系主要是描述它们之间的相似性或差异性。其中,泛化关系是参与者之间最常见的一种关系。
泛化关系(Generalization):
这里稍微有些“别扭”,就是泛化这个词,我们很容易直觉理解为,是从一般到具体。但是箭头,却是从具体指向一般。可以说,UML中,泛化关系的箭头方向可能初看起来有些反直觉!这种表示方法有助于强调子类是父类的一种特殊情况或具体实现。
记忆这个规则的一个方法是将其与继承的概念联系起来。在面向对象编程中,子类继承父类的属性和方法。因此,可以将箭头从子类指向父类理解为“子类继承了父类的特性”。这样,当看到箭头指向一个更一般的参与者或类时,就可以联想到“继承”和“特化”的概念,从而帮助记忆泛化关系的表示方法。
除了泛化关系外,参与者之间还可以存在其他关系,但这些关系在用例图中并不常见。例如,在某些情况下,参与者之间可能存在关联关系,表示它们之间的某种联系或交互模式。但这些关系通常不直接在用例图中表示,而是通过用例之间的交互来描述。
(未完,下次来讲用例。)