首页 > 编程知识 正文

java uml类图怎么画(主流的uml建模工具)

时间:2023-05-05 19:45:45 阅读:72650 作者:2345

在上了面向对象的分析和设计课之后,现在终于有时间整理了

统一建模语言(UML )称为统一建模语言,是一种通用的可视化建模语言,用于可视化、描述、构建和记录由对象管理组织指定的软件密集型系统的各种任务

学习过程中最主要的几个图主要是用例图、活动图、类图、序列图、合作图、状态图等。

首先使用的绘制工具是starUML-5.0。

下载地址为StarUML staruml.io

因为是开源软件,所以是免费的。 当然画画也可以用rose等,但是它们大多是收费的。

关于下载安装,没有更多的说明。

为了方便地将starUML安装在USB存储器中,这样使用非常有用。 并不是所有计算机都有starUML。

一.首先,说明其中涉及的最基本的专属名词。

oo :面向对象,面向对象。 基于对象概念,以对象为中心,以类和即成结构机制认识、理解、描述客观世界及其相关的相应软件系统。

OOA :面向对象的分析,面向对象的分析。 确定需求和业务观点,按照面向对象的思想分析业务。

ood :面向对象的设计,面向对象的设计。 OOA和OOP之间的业务流程,其主要作用主要是进一步规范和整理OOA分析的结果,同时可以直接应用于OOP。

OOP :面向对象的编程,面向对象的编程。 简而言之,就是在代码级别实现OOA和OOD。

如果你学过面向对象编程,下面的就可以省略了.

对象:现实世界中实际存在的东西。 例如灰鸭、红头鸭、棉花鸭等。

属性:描述对象静态特征的数据项。 例如,鸭翅有灰色、白色、褐色等。

操作:一系列操作,用于描述对象的目的特征。

类:具有相同属性和操作的对象的集合,也可以称为用于生成对象的模板。 例如,灰鸭、红头鸭和棉花都属于鸭类。

接口: (interface )是java中的抽象类型,是抽象方法的集合,抽象类通过继承接口来继承接口中的抽象方法。 在实际应用过程中一般由抽象类继承接口,然后由具体类实现抽象接口。

封装:通过隐藏对象的属性和实现详细信息、向外部提供接口以及控制属性读取和修改的访问级别,提高程序安全性。

继承:主要是子类继承父类,子类拥有父类的属性和方法。

消息:对目标方的服务请求。

多态性:可以让同一个名字有不同的含义。 在OO方法中,在子类中定义的属性或方法继承到子类后,通常会指示可以有不同的数据类型或不同的行为。

剩下的关系用具体的图分别说明。

二、用例图(使用案例模型)。

用例图是从用户的角度描述系统功能并允许用户观察系统功能的模型图。 能够描述参与者和系统之间相互作用的功能模块。

建模元素包括:

Usecase :用例,即系统的功能。

Actor :系统参与者。

关联:关联关系。

直接关联:直接关联关系。

Generization :泛化关系,即继承关系。

从属关系:依赖关系。

Inducle :包括关系。

扩展:扩展关系。 PS:1.staruml不允许同一用例图中的同一Actor行为。 2 .虚线和长方形的方框是说明的作用。

如图所示,此用例图反映了三个参与者的功能和关系:客户、员工和银行。

顾客依靠职员完成存款、转账、取款功能。 职员还可以具有登录和维护账户的功能。

由于转账和正式业务转账属于相同的转账范畴,所以使用继承关系,例如设为类和对象的关系。 例如,支付手段有微信、银联支付、支付宝支付等。 这三种支付手段同样由支付手段继承。

包含关系:从基本用例到扩展用例。 在运行基本用例之前,必须运行扩展用例,同时执行功能分解功能(一般不常用)。 上面的照片被用作功能的分解。

扩展关系:从扩展用例到基本用例。 在运行基本用例之前,一般要检查是否满足扩展用例的条件。 例如,在订购商品之前可以确认购买者是否为会员,如果是会员则可以进行折扣优惠。

此外,在扩展关系中,具有扩展关系的基本用例可以单独存在,而不必每次运行基本用例时都运行扩展用例。 扩展用例依赖于基础用例。 在包含关系中,基本用例的执行必须基于扩展用例。

下图反映了包含和展开时的用例

继承关系:继承关系是指将多个扩展用例抽象为一个基本用例。 基本用例是类,而扩展用例是对象,如类与对象之间的关系。 也就是说,基本用例是生成扩展用例的模板。

ter">其关系主要如下:

参与者与参与者、参与者与用例、用例与用例之间的关系:

①参与者与参与者之间的关系:泛化(继承)、依赖关系。

②参与者与用例之间的关系:关联关系。

③用例与用例之间的关系:泛化、扩展、包含。

用例粒度:用例粒度指的是用例所包含的系统服务或功能单元的多少。用例粒度越大,用例包含的功能越多,反之则包含的功能越少。

用例粒度确定错误所造成的影响:

①如果用例粒度过大,造成的用例过多,在后期系统实现过程中可能会出现冗余现象。

②如果用例粒度过小,可能会造成系统功能不清晰。

在用例建模过程中比较难的可能就是系统功能的提取以及Actor的提炼。另外用例图画出来之后要写用例规约,至于用例规约等等下边的部分下次再写。

如果其中有错误的地方、或者重要的地方未提及也请大神们多多指正。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。