java建模工具_UML建模工具的使用

学完面向对象的分析与设计课程之后现在终于有时间来整理一下

UML(Unified Modeling Language)称为统一建模语言，是对象管理组织指定的一个通用的、可视化的建模语言标准，可用来可视化、描述、构造和文档化软件密集型系统的各种工作。

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

首先使用的画图工具是starUML-5.0。

下载地址为：StarUML​staruml.io

因为是开源的软件所以免费的，当然画图也可以用rose之类的，但是那些大多都是收费的。

至于下载安装不再过多的描述。

为了方便可以把starUML安装到U盘中，那样用起来极为方便，毕竟不是每个电脑都会配置starUML。

一.首先把其中涉及的最基本专属名词解释一下。

OO：Object Oriented,面向对象。基于对象概念，以对象为中心，以类和即成为构造机制，来认识、理解、刻画客观世界和涉及、构建相应的软件系统。

OOA：Object-Oriented Analysis,面向对象的分析。是确定需求或者业务的角度，按照面向对象的思想来分析业务。

OOD:Object-Oriented Design,面向对象的设计。是处于OOA和OOP之间的一个业务流程，其主要作用主要是对OOA分析的结果做进一步的规范化整理，一边能够被OOP直接应用。

OOP：Object Oriented Programming,面向对象的程序设计。简而言之就是在代码层面实现OOA和OOD。

如果学过面向对象的编程下边的都可以省略............

对象：是现实世界中实际存在的事物。例如：灰鸭、红头鸭、棉花鸭等。

属性：描述对象静态特征的数据项。例如：鸭子的羽毛有灰色、白色、褐色等。

操作：描述对象动态特征的一个动作序列。

类：具有相同属性和操作的一组对象的集合，也可以说是生成对象的模板。例如：灰鸭、红头鸭、棉花呀都属于鸭类。

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

封装：隐藏对象的属性和实现细节，仅仅对外提供接口，控制属性的读和修改的访问级别，来加强程序的安全性。

继承：主要是子类继承父类，然后子类拥有父类的属性和方法。

消息：向对象发出的服务请求。

多态：同一命名可以具有不同的语义。在OO方法中，常指在一般类中定义的属性或者方法被子类继承之后，可以具有不同的数据类型或者是表现出不同的行为。

剩下的关系在具体图中分别解释。

二.用例图(UseCaseModel)

用例图是从用户的角度来描述系统的功能，使用户所能观察到系统功能的模型图。可以描述参与者与系统之间交互作用的功能模块。

建模元素如下：

Usecase：用例即系统的功能。

Actor：系统的参与者。

Association：关联关系。

DirectedAssociation：直接关联关系。

Generization：泛化关系，即继承关系。

Dependency：依赖关系。

Inducle：包含关系。

Extend：扩展关系。ps:1.在staruml中在同一用例图中不允许出现相同Actor的行为。 2.虚线和长方形方框为解释的作用。

如图，该用例图反映了三个参与者即：客户、职员、银行三个参与者的功能和关系。

客户依赖职员来完成存款、转账、取款功能。而职员又可以有登陆和维护账户的功能。

跨行转账和本行转账同属于转账范畴，因此使用了继承关系，就例如类与对象的关系一样。又例如支付手段有：微信字符、银联支付、支付宝支付那样。这三种支付手段同一继承到支付手段上。

包含关系：从基用例指向扩展用例。指的是在执行基用例之前必须先执行扩展用例，同时可以做功能的分解功能(一般用的比较少)。上边的图片就是用作功能的分解。

扩展关系：从扩展用例指向基用例。一般在执行基用例之前看看是否符合扩展用例的条件。例如在订购商品之前看看购买者是否是会员，如果是会员就可以进行打折优惠等等。

另外在扩展关系中，扩展关系中的基用例是可以单独存在的，在每次执行基础用例之前扩展用例不是都必须被执行。扩展用例依赖于基础用例。而在包含关系中恰恰相反，基用例的执行必须在扩展用例的基础上才可以。

下图反映了包含和拓展在一起的时候的一个用例

继承关系：继承关系是将多个扩展用例抽象出一个基用例。类似类和对象的关系，基用例是类而扩展用例是对象，也就是说基用例是生成扩展用例的模板。

其关系主要如下：

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

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

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

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

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

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

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

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

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

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