软件开发UML.docx

软件开发UML.docx

《软件开发UML.docx》由会员分享，可在线阅读，更多相关《软件开发UML.docx（26页珍藏版）》请在冰豆网上搜索。

软件开发UML

软件开发-UML（）

一、什么是UML1

二UML类图元素3

三、UML动态图类型6

四、开发过程9

（一）、需求分析模型10

（二）、分析模型15

（三）设计17

（四）实现20

（五）测试20

一、什么是UML

UML是UnifiedModelingLanguage，统一建模语言，主要由Booch、Rumbaugh及Jacobson三人提出，他们三人把自己分别提出的建模方法Booch、OMT、OOSE融合为一种方法称为UML。

UML的特点如下：

统一的标准，UML已经被OMG接受为标准的建模语言，而且越来越多的开发人员使用ULM语言进行开发；UML是支持面向对象技术的建模语言；可视化、表示能力强大；独立于过程，UML不依赖于特定的软件开发过程；概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。

**谁应该建模

1、业务建模：

以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与

2、需求模型：

以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与

3、设计模型：

高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。

详细设计模型则以资深开发人员为主，架构师提供指导。

4、实现模型：

以资深开发人员（设计人员）为主，架构师提供总体指导。

5、数据库模型：

以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）予以配合。

UML建模的要点总结

图名　　　　　　　　　　　　功能　　　　　　　　　　　　　　　　备注

类图　　　　　　描述类、类的特性以及类之间的关系　　　　　　　　UML1原有

对象图　　　　　描述一个时间点上系统中各个对象的一个快照　　UML1非正式图

复合结构图　　　描述类的运行时刻的分解　　　　　　　　　　　　　UML2.0新增

构件图　　　　　描述构件的结构与连接　　　　　　　　　　　　　　UML1原有

部署图　　　　　描述在各个节点上的部署　　　　　　　　　　　　　UML1原有

包图　　　　　　描述编译时的层次结构　　　　　　　　　　　　　　UML中非正式图

用例图　　　　　描述用户与系统如何交互　　　　　　　　　　　　　UML1原有

活动图　　　　　描述过程行为与并行行为　　　　　　　　　　　　　UML1原有

状态机图　　　　描述事件如何改变对象生命周期　　　　　　　　　　UML1原有

顺序图　　　　　描述对象之间的交互，重点在强调顺序　　　　　　　UML1原有

通信图　　　　　描述对象之间的交互，重点在于连接　　　　　　　　UML1中的协作图

定时图　　　　　描述对象之间的交互，重点在于定时　　　　　　　　UML2.0新增

交互概观图　　　是一种顺序图与活动图的混合　　　　　　　　　　　UML2.0新增

二UML类图元素

1.类（Class）

类（图A）是对象的蓝图，其中包含3个组成部分。

第一个是Java中定义的类名。

第二个是属性（attributes）。

第三个是该类提供的方法。

属性和操作之前可附加一个可见性修饰符。

加号（+）表示具有公共可见性。

减号（-）表示私有可见性。

#号表示受保护的可见性。

2.包（Package）

包是一种常规用途的组合机制。

UML中的一个包直接对应于Java中的一个包。

在Java中，一个包可能含有其他包、类或者同时含有这两者。

3.接口（Interface）

接口是一系列操作的集合，它指定了一个类所提供的服务。

它直接对应于Java中的一个接口类型。

接口既可用图的那个图标来表示，也可由附加了<>的一个标准类来表示。

4.类的关系

4.1依赖（Dependency）

实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例。

更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。

其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。

也可利用“依赖”来表示包和包之间的关系。

由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系。

4.2关联（Association）

实体之间的一个结构化关系表明对象是相互连接的。

箭头是可选的，它用于指定导航能力。

如果没有箭头，暗示是一种双向的导航能力。

在Java中，关联转换为一个实例作用域的变量，就像图的“Java”区域所展示的代码那样。

可为一个关联附加其他修饰符。

多重性（Multiplicity）修饰符暗示着实例之间的关系。

在示范代码中，Employee可以有0个或更多的TimeCard对象。

但是，每个TimeCard只从属于单独一个Employee。

4.3聚合（Aggregation）

聚合是关联的一种形式，代表两个类之间的整体/局部关系。

聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。

聚合也转换成Java中的一个实例作用域变量。

关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。

聚合还暗示着实例图中不存在回路。

换言之，只能是一种单向关系。

4.4合成（Composition）

合成是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。

合成也是非共享的。

所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。

局部不可与其他整体共享。

但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。

Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。

4.5泛化（Generalization）

泛化表示一个更泛化的元素和一个更具体的元素之间的关系。

泛化是用于对继承进行建模的UML元素。

在Java中，用extends关键字来直接表示这种关系。

4.6实现（Realization）

实例关系指定两个实体之间的一个合同。

换言之，一个实体定义一个合同，而另一个实体保证履行该合同。

对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。

三、UML动态图类型

通用的模型元素

1.用例图

2.类图、对象图

3.状态转移图

4.活动图

5.序列图

6.通信图

7.组件图

8.部署图

四、开发过程

（一）、需求分析模型

1.1用例模型

用例是一个角色使用系统的某项功能时交互过程的文字描述。

用例的是系统的功能性需求。

用例从使用系统的角度描述系统中的信息，即站在系统外部观看系统的功能，而不考虑系统内部对该功能的具体实现方式。

用例描述了用户提出的一些可能需求，对应一个具体的用户目标，用例可以促进与用户沟通、理解正确的需求，同时也可以用来划分系统与外部实体的界限，是面向对象系统设计的起点，是类、对象、操作的来源。

用例图主要用于描述拟建系统和外部环境的关系。

用例图包括角色、系统边界、用例以及元素间的关联,用例间的关系通常有包含、泛化、扩展。

1.识别角色

角色不仅仅是使用系统的用户也可以是硬件、外部系统等等。

角色应该和系统具有交互行为，即角色向用例发送消息或者接收用例反馈的消息。

角色之间存在继承关系。

通过回答以下6个问题来识别A系统的角色：

（1）谁使用系统的主要功能。

回答：

质监人员。

（2）谁需要系统的支持以完成日常工作。

回答：

质监人员。

（3）谁负责维护、管理并保持系统正常运行。

回答：

质量监督结构的管理员。

（4）系统需要应付哪些设备。

回答：

不需要。

（5）系统需要和哪些外部系统交互。

回答：

无。

（6）谁或什么对系统运行结果感兴趣。

回答：

质监人员。

综上所述我们分析出来的A系统角色有质监人员、管理员。

2.识别用例

识别用例时由于角色已经识别出来，所以我们主要根据角色来识别用例，识别用例的人为因素很大，不同的人针对同一个需求识别出的用例不一定是相同的，用例识别和经验关系很大。

我们以角色“管理员”为例，根据这个角色来识别相关的用例。

（1）某个角色要求系统为其提供什么功能？

该角色需要做哪些工作？

回答：

管理员登录软件以后主要进行用户管理。

另外系统的新建数据库、连接数据库这些工作也主要由管理员来做。

（2）角色需要阅读、创建、销毁、更新或存储系统中某些信息吗？

回答：

管理员需要创建、删除、修改用户信息，进行用户管理。

将这个角色涉及到的用例进行分析得到和这个角色相关的用例：

管理用户、选择数据库、建立数据库、登录。

采用类似的方法还可以分析出系统的其他用例。

3.用例图

4用例描述

用例采用自然语言描述角色和系统进行交互时双方的行为。

用例描述没有一个统一的标准，但一般应该包括以下的内容：

用例的目的；用例是怎样启动的；角色和用例之间的消息是如何传送的；用例中除了主要路径外，其他路径是什么；用例结束后系统的状态；其他需要描述的内容。

用例名称：

选择建设项目

综述：

所有建设项目的数据保存在同一个数据库中，当用户登录后需要选择某个建设项目或者新建建设项目。

前置条件：

登录成功，打算对某个项目进行操作

后置条件：

进入软件主界面

基本操作流：

1、系统提供已有建设项目供用户选择。

2、用户从系统提供的项目列表中选中某个建设项目。

3、系统对当前选中的建设项目进行标识，进入主界面。

可选操作流：

可选流1：

1、系统提供查询条件，查询条件包括公里等级、项目名称。

2、用户输入查询条件

3、系统提供满足条件的项目，如果用户没有输入系统提示，并不进行查询操作。

4、用户选中建设项目。

5、系统对当前选中的建设项目进行标识，进入主界面。

可选流2：

1、用户选择建设项目的界面上提供新建建设项目功能。

2、系统提供新建建设项目页面

3、用户输入建设项目信息

界面建模

将界面建模放在需求分析阶段，一方面软件界面的需求也是用户需求的一部分，另一方面使用界面模型和用户交流系统的功能需求直观、明确，用户很容易理解。

1、界面设计的基本要求

*界面设计要完整的体现出用户需求的表现形式。

*界面设计要美观大方，一般来说界面设计的结果要符合用户群的习惯、感官、感觉。

*界面设计中的交互操作过程要符合用户习惯性的工作过程。

首先确定界面元素，通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等等。

Visio作为界面建模工具。

（二）、分析模型

2.1架构设计

1.分层架构

架构设计决定了各子系统如何组织以及如何协调工作。

架构设计的好坏影响到软件的好坏，系统越大越是这样。

在分解复杂的软件系统时，经常使用的一种架构技术就是分层。

本软件架构设计

2.2获取分析类

类图的获取是一个不断细化的过程，一般我们先从分析类开始。

分析类是概念层面上的类，是进行类设计的基础，获取分析类是系统分析中一项很重要的工作。

获取分析类的是一个需要大量技巧的工作，我们主要根据用例描述来确定分析类。

识别用例中类的问题：

用例描述中出现了那些实体？

用例的完成需要哪些实体合作？

用例执行过程中会产生并存储哪些信息？

用例要求与之关联的每个角色的输入是什么？

用例反馈与之关联的每个角色的输出是什么？

用例需要操作哪些硬设备？

2.3用例实现

获得分析类以后，我们就可以借助分析类通过交互模型对用例如何实现进行描述。

用例实现是一个由需求转移到分析、设计的过程。

用例描述了用户的功能性需求，用例实现借助分析类以及他们之间的交互来描述用例被如何实现。

可以看出使用UML从需求到分析、设计的过渡是很平滑的。

在描述用例实现时我们可以使用活动图、顺序图、协作图等方式。

活动图和协作图可以互换，一般我们仅选择其中的一种就可以了。

活动图

顺序图

2.4整理分析类

整理分析类主要是依据用例实现部分的一系列的交互图。

我们已经获得了分析类，在用例实现中我们在交互图中使用了这些类。

但是这些类还没有属性、职责。

我们需要对他们进行整理，完成分析类的属性、职责以及类之间的关系，并在类图中将他们展示出来。

在整理分析类的过程中一定要注意分析类不仅仅参与了一个用例，它可能参与了很多的用例，因此在分析属性、职责及类之间关联的时候要考虑每个用例的情况，进行归纳总结。

通过整理分析类绘制的类图仅仅是分析阶段的类图还需要在后续阶段继续完善和细化。

（三）设计

设计阶段对分析模型进行扩展并将模型进一步细化，并考虑技术细节和限制条件。

功能类图模型。

功能菜单中的用户界面类一般都有1对1的关联关系，表示需要建立关联的窗口类，或者需要访问关联的商业对象类。

（四）实现

在构造或称实现阶段进行程序编写。

编写代码时，从下面的设计模型的图中取出规范说明：

1．类规范：

每一个类的规范详细地显示了必要的属性和操作。

2．类图：

类图由类构成，显示了类的结构以及类之间的关系。

3．状态图：

类的状态图显示了类可能具有的状态以及需要处理的状态转移（以及触发转移的操作）。

4．动态图（顺序图、协作图和活动图）：

涉及到类的对象，显示了类中的特定方法如何实现，或对象之间如何使用其它类的对象进行交互。

5．用例图和规范：

当开发者需要了解更多的关于系统如何被使用的信息时（当开发者感到他或她已经迷失在一片细节中），他们显示了系统被使用的结果。

（五）测试

作业：

将原解剖的案例用反向工程方法，用UML表达出来。