uml用例图实验总结-UML类图几种关系的总结

最近过年因为新冠病毒的肆虐各公司都开始放长假了,初步估计都是要出了元宵才能回成都上班,虽然返岗之前要在家办公(上班),但是还是得做点欠着的事情舍,其中比较重要的一个就是我的毕业设计嘞,一两个月就要交初稿了,但是我还没开始嘞

由于毕业设计需要用到各种UML图,所以就趁这个机会好好复习和总结一下软件工程课程有关UML图的相关内容吧,毕竟这个在软件设计和分析的流程中还是占据比较重要的地位,也是软件分析的利器,能帮助我们快速分析我们要做的事情,也能使我们要做的东西一目了然,接下来就直接开始总结和复习吧,就以我的毕业设计――一个简单的在线考试系统为例开始我们的学习之旅

用例图(User Case)是外部用户(被称为参与者)所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者,一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。

例如我们在线考试系统的业务用例图:

简单来说就是:用例图是由参与者(Actor)、用例( Use Case )、 系统边界 、箭头组成,用画图的方法来完成的一个表达系统功能的图示。

接下来分别介绍其成分。

参与者(Actor)是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。

简单来说就是:

一个系统的使用者,可能涉及的角色就是一个参与者

每个参与者可以参与一个或多个用例,每个用例也可以有一个或多个参与者。

在用例图中使用一个人形图标来表示参与者,参与者的名字写在人形图标下面。

简单来说就是: 用例 是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。

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

要创建用例,我们需要分析哪些可以作为用例,如何识别,可以从以下几点来确定用例:

简单来说就是:如果用例的粒度很小,得到的用例数就会太多。反之,如果用例的粒度很大,那么得到的用例数就会很少。

比如在我们的考试系统中:我们的老师可以对试卷进行管理,那么展示出来的粒度较大的用例可以是这样:

如果我们按照具体的操作把它抽象成多个用例(粒度变小),它也可以是这样的:

它展示的系统需求和单个用例是完全一样的。

用例之间的关系包括以下几种:

例如:老虎是动物的一种,即有老虎的特性也有动物的共性。 【箭头指向】:带三角箭头的实线,箭头指向父类 2. 实现(Realization) 【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现. 【箭头指向】:带三角箭头的虚线,箭头指向接口 3. 关联(Association) 【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。 【代码体现】:成员变量 【箭头及指向】:带普通箭头的实心线,指向被拥有者 C#代码: 单向关联 Public class Order { Public List<Product> order; Public void AddOrder(Product product ) { (product); } } Public Class Product { } 上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程是个抽象的东西他不拥有学生。 下图为自身关联: 4. 聚合(Aggregation) 【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。 聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。 【代码体现】:成员变量 【箭头及指向】:带空心菱形的实心线,菱形指向整体 5. 组合(Composition) 【组合关系】:是整体与部分的关系,但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系,没有公司就不存在部门。 组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。 【代码体现】:成员变量 【箭头及指向】:带实心菱形的实线,菱形指向整体 6. 依赖(Dependency) 【依赖关系】:是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖. 【代码表现】:局部变量、方法的参数或者对静态方法的调用 【箭头及指向】:带箭头的虚线,指向被使用者 各种关系的强弱顺序: 泛化= 实现 > 组合 > 聚合 > 关联 > 依赖 下面这张UML图,比较形象地展示了各种类图关系:

用例图第一次遇到它的时候印象就是一个个的小人,很好看但是有什么卵用,可以用功能描述为什么要画“小人”(用例),只要配置了相应的权限,系统的任何角色都可以使用任何一个功能点,为什么需求要写成什么角色对应什么用例这种模式。或者要给千千万万的用户分成什么角色。

其实用例图还需要和其他UML图配合使用,才能发挥更大的威力。当然也发现用例图并不是在任何情况下都是作用巨大的,用例图和其他UML图一-样,只是我们可以利用的一种工具。

用例图简单说就是描述系统需求的一种方法,描述什么角色通过什么系统能做什么事情,关注的是系统的外在表现,系统与人的交互,系统与其他系统的交互。概括下就是回答:

我们在做一个考勤系统时,不会列出好多功能,比较好的方式是先思考什么角色用,思考不同角色对系统有什么需求。

描述系统需求喜欢用什么功能、什么模块之类的表达,描述需求会不自觉地用到很多技术用语,这其实是很多技术人员做需求分析工作的通病。要分析好一个系统的需求,首先要搞清楚本系统的目标,然后思考什么角色会用这个系统,这些角色希望通过这个系统完成什么事情,由粗到细地理出细致的需求。用例图语法不复杂,其实用好用例图的关键在于改变需求分析的旧有习惯,要学会从角色入手,从用户的角度来思考他们需要什么,用他们能看懂的语言来表达需求。

进阶部分不继续写了,就是综合类图到用例中