软件开发UML.docx

1、软件开发UML软件开发-UML（）一、什么是UML 1二UML类图元素 3三、UML 动态图类型 6四、 开发过程 9（一）、 需求分析模型 10（二）、分析模型 15（三）设计 17（四）实现 20（五）测试 20一、什么是UMLUML是 Unified Modeling Language，统一建模语言，主要由Booch、Rumbaugh及Jacobson三人提出，他们三人把自己分别提出的建模方法Booch、OMT、OOSE融合为一种方法称为UML。 UML的特点如下：统一的标准，UML已经被OMG接受为标准的建模语言，而且越来越多的开发人员使用ULM语言进行开发；UML是支持面向对象技术的

2、建模语言；可视化、表示能力强大；独立于过程，UML不依赖于特定的软件开发过程；概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。* 谁应该建模1、业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与2、需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与3、设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导。4、实现模型：以资深开发人员（设计人员）为主，架构师提供总体指导。5、数据库模型：以数据库开发人员为主，架构师提供指导，资深开发

3、人员（设计人员）予以配合。 UML建模的要点总结图名功能备注类图描述类、类的特性以及类之间的关系UML 1原有对象图描述一个时间点上系统中各个对象的一个快照 UML 1非正式图复合结构图描述类的运行时刻的分解UML 2.0新增构件图描述构件的结构与连接UML 1原有部署图描述在各个节点上的部署UML 1原有包图描述编译时的层次结构UML中非正式图用例图描述用户与系统如何交互UML 1原有活动图描述过程行为与并行行为UML 1原有状态机图描述事件如何改变对象生命周期UML 1原有顺序图描述对象之间的交互，重点在强调顺序UML 1原有通信图描述对象之间的交互，重点在于连接UML 1中的协作图定时图

4、描述对象之间的交互，重点在于定时UML 2.0 新增交互概观图是一种顺序图与活动图的混合UML 2.0新增二UML类图元素1. 类（Class） 类（图A）是对象的蓝图，其中包含3个组成部分。第一个是Java中定义的类名。第二个是属性（attributes）。第三个是该类提供的方法。属性和操作之前可附加一个可见性修饰符。加号（+）表示具有公共可见性。减号（-）表示私有可见性。#号表示受保护的可见性。2. 包（Package） 包是一种常规用途的组合机制。UML中的一个包直接对应于Java中的一个包。在Java中，一个包可能含有其他包、类或者同时含有这两者。3.接口（Interface） 接口是

5、一系列操作的集合，它指定了一个类所提供的服务。它直接对应于Java中的一个接口类型。接口既可用图的那个图标来表示，也可由附加了的一个标准类来表示。4. 类的关系4.1 依赖（Dependency） 实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例。更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。也可利用“依赖”来表示包和包之间的关系。由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系

6、。4.2关联（Association） 实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。在Java中，关联转换为一个实例作用域的变量，就像图的“Java”区域所展示的代码那样。可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示着实例之间的关系。在示范代码中，Employee可以有0个或更多的TimeCard对象。但是，每个TimeCard只从属于单独一个Employee。4.3聚合（Aggregation） 聚合是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上处于比局部更高的一

7、个级别，而关联暗示两个类在概念上位于相同的级别。聚合也转换成Java中的一个实例作用域变量。 关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。4.4合成（Composition） 合成是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。局部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”

8、。4.5泛化（Generalization）泛化表示一个更泛化的元素和一个更具体的元素之间的关系。泛化是用于对继承进行建模的UML元素。在Java中，用extends关键字来直接表示这种关系。4.6实现（Realization） 实例关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。三、UML 动态图类型 通用的模型元素 1. 用例图 2.类图、对象图 3.状态转移图 4. 活动图 5.序列图 6. 通信图 7. 组件图 8.部署图四、 开发过程 （一）、 需求分析模型 1.

9、1 用例模型 用例是一个角色使用系统的某项功能时交互过程的文字描述。用例的是系统的功能性需求。用例从使用系统的角度描述系统中的信息，即站在系统外部观看系统的功能，而不考虑系统内部对该功能的具体实现方式。 用例描述了用户提出的一些可能需求，对应一个具体的用户目标，用例可以促进与用户沟通、理解正确的需求，同时也可以用来划分系统与外部实体的界限，是面向对象系统设计的起点，是类、对象、操作的来源。用例 图主要用于描述拟建系统和外部环境的关系。 用例图包括角色、系统边界、用例以及元素间的关联, 用例间的关系通常有包含、泛化、扩展。1. 识别角色 角色不仅仅是使用系统的用户也可以是硬件、外部系统等等。角色

10、应该和系统具有交互行为，即角色向用例发送消息或者接收用例反馈的消息。角色之间存在继承关系。通过回答以下6个问题来识别A系统的角色： （1）谁使用系统的主要功能。 回答：质监人员。 （2）谁需要系统的支持以完成日常工作。 回答：质监人员。 （3）谁负责维护、管理并保持系统正常运行。 回答：质量监督结构的管理员。 （4）系统需要应付哪些设备。 回答：不需要。 （5）系统需要和哪些外部系统交互。 回答：无。 （6）谁或什么对系统运行结果感兴趣。 回答：质监人员。 综上所述我们分析出来的A系统角色有质监人员、管理员。2. 识别用例 识别用例时由于角色已经识别出来，所以我们主要根据角色来识别用例，识别用

11、例的人为因素很大，不同的人针对同一个需求识别出的用例不一定是相同的，用例识别和经验关系很大。我们以角色“管理员”为例，根据这个角色来识别相关的用例。 （1）某个角色要求系统为其提供什么功能？该角色需要做哪些工作？ 回答：管理员登录软件以后主要进行用户管理。另外系统的新建数据库、连接数据库这些工作也主要由管理员来做。 （2）角色需要阅读、创建、销毁、更新或存储系统中某些信息吗？ 回答：管理员需要创建、删除、修改用户信息，进行用户管理。 将这个角色涉及到的用例进行分析得到和这个角色相关的用例：管理用户、选择数据库、建立数据库、登录。采用类似的方法还可以分析出系统的其他用例。 3. 用例图 4用例描

12、述 用例采用自然语言描述角色和系统进行交互时双方的行为。用例描述没有一个统一的标准，但一般应该包括以下的内容：用例的目的；用例是怎样启动的；角色和用例之间的消息是如何传送的；用例中除了主要路径外，其他路径是什么；用例结束后系统的状态；其他需要描述的内容。用例名称：选择建设项目综述：所有建设项目的数据保存在同一个数据库中，当用户登录后需要选择某个建设项目或者新建建设项目。前置条件：登录成功，打算对某个项目进行操作后置条件：进入软件主界面基本操作流： 1、 系统提供已有建设项目供用户选择。2、 用户从系统提供的项目列表中选中某个建设项目。3、 系统对当前选中的建设项目进行标识，进入主界面。可选操作

13、流：可选流1：1、系统提供查询条件，查询条件包括公里等级、项目名称。2、用户输入查询条件3、系统提供满足条件的项目，如果用户没有输入系统提示，并不进行查询操作。4、 用户选中建设项目。5、 系统对当前选中的建设项目进行标识，进入主界面。可选流2：1、 用户选择建设项目的界面上提供新建建设项目功能。2、 系统提供新建建设项目页面3、 用户输入建设项目信息界面建模将界面建模 放在需求分析阶段，一方面软件界面的需求也是用户需求的一部分，另一方面使用界面模型和用户交流系统的功能需求直观、明确，用户很容易理解。1、界面设计的基本要求 * 界面设计要完整的体现出用户需求的表现形式。 * 界面设计要美观大方

14、，一般来说界面设计的结果要符合用户群的习惯、感官、感觉。 * 界面设计中的交互操作过程要符合用户习惯性的工作过程。 首先确定界面元素，通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等等。Visio作为界面建模工具。（二）、分析模型2.1 架构设计1. 分层架构 架构设计决定了各子系统如何组织以及如何协调工作。架构设计的好坏影响到软件的好坏，系统越大越是这样。在分解复杂的软件系统时，经常使用的一种架构技术就 是分层。本软件架构设计2.2 获取分析类 类图的获取是一个不断细化的过程，一般我们先从分析类开始。分析类是概念层面上的类，是

15、进行类设计的基础，获取分析类是系统分析中一项很重要的工作。获取分析类的是一个需要大量技巧的工作，我们主要根据用例描述来确定分析类。识别用例中类的问题：用例描述中出现了那些实体？用例的完成需要哪些实体合作？用例执行过程中会产生并存储哪些信息？用例要求与之关联的每个角色的输入是什么？用例反馈与之关联的每个角色的输出是什么？用例需要操作哪些硬设备？2.3 用例实现 获得分析类以后，我们就可以借助分析类通过交互模型对用例如何实现进行描述。用例实现是一个由需求转移到分析、设计的过程。用例描述了用户的功能性需求，用例实现借助分析类以及他们之间的交互来描述用例被如何实现。可以看出使用UML从需求到分析、设计

16、的过渡是很平滑的。在描述用例实现时我们可以使用活动 图、顺序图、协作图等方式。活动图和协作图可以互换，一般我们仅选择其中的一种就可以了。 活动图顺序图2.4 整理分析类整理分析类主要是依据用例实现部分的一系列的交互图。我们已经获得了分析类，在用例实现中我们在交互图中使用了这些类。但是这些类还没有属性、职责。我们需要对他们进行整理，完成分析类的属性、职责以及类之间的关系，并在类图中将他们展示出来。在整理分析类的过程中一定要注意分析类不仅仅参与了一个用例，它可能参与了很多的用例，因此在分析属性、职责及类之间关联的时候要考虑每个用例的情况，进行归纳总结。通过整理分析类绘制的类图仅仅是分析阶段的类图还

17、需要在后续阶段继续完善和细化。（三）设计 设计阶段对分析模型进行扩展并将模型进一步细化，并考虑技术细节和限制条件。 功能类图模型。功能菜单中的用户界面类一般都有1对1的关联关系，表示需要建立关联的窗口类，或者需要访问关联的商业对象类。（四）实现 在构造或称实现阶段进行程序编写。编写代码时，从下面的设计模型的图中取出规范说明：1类规范：每一个类的规范详细地显示了必要的属性和操作。2类图：类图由类构成，显示了类的结构以及类之间的关系。3状态图：类的状态图显示了类可能具有的状态以及需要处理的状态转移（以及触发转移的操作）。4动态图（顺序图、协作图和活动图）：涉及到类的对象，显示了类中的特定方法如何实现，或对象之间如何使用其它类的对象进行交互。5用例图和规范：当开发者需要了解更多的关于系统如何被使用的信息时（当开发者感到他或她已经迷失在一片细节中），他们显示了系统被使用的结果。（五）测试作业：将原解剖的案例用反向工程方法，用UML表达出来。