UML的基本概念
UML(Unified Modeling Language)
1.通用的可视化建模语言,能与所有的开发方法一同使用,可用于软件开发的整个生命周期。
2.UML能表达系统静态结构和动态信息,能管理复杂的系统模型。
3.UML便于软件团队之间的合作开发。
4.UML不是编程语言,支持UML语言的工具可以提供从UML到各种编程语言的代码生成,提供从现有程序逆向构建UML模型。
5.UML并不是万能的,它是一种离散的建模语言,对于特定的领域,比如:GUI、VLSI电路设计或基于规则的人工智能,用特定的语言和工具可能更合适。
6.UML是所有建模人员可以使用的通用建模语言。它包含主流建模方法的概念,从而可以替代现有的软件分析和设计方法,比如:OMT,Booch,OOSE等。
7.UML不是完整的开发方法,它不包括逐步的开发流程,但它提供所有必要的概念,具备足够的表达能力。
8.UML的另一个目标是:能尽量简洁地表达系统的模型。
UML概念可以划分为以下范围:
系统概念、静态结构、动态行为、交互行为、物理实现、各种图之间的关系、模型组织、扩展机制。
系统需求
用例视图:
1.从外部用户的角度来描述系统的行为,它将系统功能划分为对用户有意义的事物,这些事物被称为用例,用户被称为执行者。
2.用例试图 也就是描述活动者在各个用例中的参与情况,它指导所有的行为视图。
静态结构
静态视图(Static View):
1.一个模型必须首先定义各种事物的内部特征和相互之间的关系。
2.应用概念建模成类,为描述事物的属性 和以及在这些属性上的操作。
3.类之间可以存在不同的关系,比如泛化(继承)、关联 和依赖 等。静态视图表示成类图,静态视图在某一时刻的快照称为对象图。
动态行为
状态机视图(State Machine View):
1.对每个类的对象的生命周期进行建模。
2.描述对象时间上的动态行为。
3.由状态和迁移 组成的图,状态机通常附属于类,描述类实例对接受事件 的响应。
活动视图(Activity View):
1.利用状态机对运算和工作流 进行建模的特殊形式。
2.活动图 的状态代表了运算执行的状态,而非一般对象的状态。
3.活动图和流程图很相似,不过它支持并发。
交互行为
交互视图(Interaction View):
对象通过交互来实现行为,通过协作来进行建模,协作有结构和行为两方面。
1.结构包含为行为方面而定义的一系列角色和关系。
2.行为方面是绑定于角色的对象间的一系列交换的消息。
3.消息在协作中称为交互。
4.消息序列可用两种图来表示:顺序图 (重点在消息的时间顺序)、协作图 (重点在交换消息的对象间的关系)
物理实现
物理视图(Physical View):
1.许多系统模型独立于最终的实现,在实现方面,必须充分考虑系统的重用性和性能。
2.UML有两种视图来表示系统的实现:实现视图 将可重用的系统片段打包成组件、部署视图 描述系统运行时资源的物理分布,这些资源称为结点。
各种图之间的关系
1.静态视图(类图,对象图),物理视图(实现视图,部署视图)是描述系统的静态结构,没有交互、动作在里面。
2.用例图是描述系统的外部视图,反应系统和外部的交互。
3.活动图描述系统的外部 / 内部视图。
4.交互视图(顺序图,协作图)描述系统的内部视图,是动态的、交互的关系。
5.状态图描述单个类的动态行为。
模型组织
模型管理视图(Model Management View):
1.任何大系统必须划分为较小的单元,以使人们能在某一时刻只接触有限的信息,不影响团队间的并行工作。
2.模型是利用包(Package) 和包的依赖 来进行管理的。
3.包是UML模型中通用的层次组织结构,包上的依赖总结了包内容的依赖关系。
扩展机制
扩展机制(Extension Mechanisms):
1.UML能满足绝大部分系统建模的需要,但任何语言都不是万能的,它必须考虑一定的扩展机制。
2.UML的扩展机制包括约束 、标签值 和原型。
3.这些扩展机制可以用来为特定领域剪裁UML的配置,根据自身需要来使用建模语言。相当于模板,在模板的基础上进行扩展。
静态建模
一个模型必须首先定义各种事物的内部特征和相互之间的关系,下面介绍一些基本的模型元素:
类
类是具有相同属性、操作和关系的对象集合的总称。
通常在UML中类被画成矩形,包括三个部分:名称、属性 和操作 。
名称 :每个类都必须有一个名字,用来区分其他的类。类名是一个字符串,称为简单名字。路径名字是在类名前加包含类的包名为前缀。
属性 :类可以有任意多个属性,也可以没有属性,在类图中属性只要写上名字就可以了,也可以在属性名后跟上类型甚至缺性取值。
操作 :操作室内的任意一个实例对象都可以调用的,并可能影响该对象行为的实现。
例如,以下为一个类的例子,
接口
接口是未给出实现的对象行为的描述,包含操作,但没有属性。一个或多个类可以实现接口,每个类实现接口的操作。
子系统(包)
1.任何大系统都必须划分为较小的单元,以使人们在某一时刻可以在有限的信息工作,使团队的工作不互相影响。
2.包可以包含各种模型元素和其他的包,包之间还可能存在一定的依赖。
3.子系统 是具有独立的说明和实现部分的包,代表了与系统其他部分具有清晰接口的清晰单元;通常代表了系统在功能或实现范围上的划分。
执行者、用例
1.执行者是与系统、子系统或类交互的外部人员,进程或事务。
2.在运行时,具体人员会充当系统的多个执行者,不同用户可能会成为一个执行者。
3.用例是系统提供的外部可感知的功能单元,目的是定义清晰的系统行为,不解释系统的内部结构。
4.用例可以与执行者关联,也可以参与其他的多种关系,比如扩展、泛化和包含等。
5.用户的动态部分用交互视图来描述,比如顺序图、协作图。
6.用例用椭圆来表示,用例名称标在椭圆下方,用实线与同自身通信的用户相连。
用例图
用例图描述执行者在各个用例中的参与情况
描述执行者在各个用例中的参与,即用用例图反应谁要使用这个系统,要什么样的功能。
组件、结点
1.组件是可重用的系统片段,具有良好定义接口的物理实现单元,每个组件包含系统设计中某些类的实现。
2.组件设计的原则:良好的组件不直接依赖于其它组件,而是依赖于其它组件所支持的接口,好处是系统中的组件可以被支持相同接口的组件所取代。
3.一个组件可能是源代码 、可执行程序 或动态库 。
4.结点代表系统运行时的物理对象,通常拥有运算能力,它可以容纳对象和组件实例。
注释
注释用于解释设计的思路,便于理解,一个好的模型应该有详尽的注释。
关联
1.关联描述了系统中对象和其它实例之间的离散的连接,关联是有序的,它允许重复,关联的实例是链 。
2.关联至对象的连接点称为关联端点 ,很多信息被附在关联端点上,它拥有角色名、重数(多少个类的实例可以关联于另一个类的实例),可见性等。
3.关联有自己的名称,可以拥有自己的属性,这时关联本身也是类,称为关联类 。
聚集、组合
**聚集(Aggregation)**用来表达整体 - 部分关系的关联。
**组合(Composition)**是一种聚集,是关联更强的形式。
泛化
1.泛化是一般化和具体化之间的一种关系。
2.继承就是一种泛化关系,更一般化的描述称为双亲 ,双亲的双亲称为祖先 ,更具体化的描述称为孩子 ,在类的范畴,双亲对应超类,孩子对应子类。
多重继承
多重继承,一个孩子可以从多个双亲继承属性和方法。多重继承可能存在冲突 ,因为被继承的双亲可能存在相同的类声明,这时,最好显式解决冲突问题。
依赖
1.依赖指明两个或两个以上模型元素之间的关系。
2.依赖有很多种类,比如:实现(realize)、使用(usage)、实例化(instantiate)、调用(call)、派生(derive)、访问(access)、引入(import)、友元(friend) 等等。
实现
实现是依赖的一种,但由于它具有特殊意义,实现是连接说明和实现之间的关系。
约束
约束用来表示各种限制,如关联路径上的限制,和属性特征检测(存在、所有)。
类图
静态视图是UML的基础,静态视图表示为类图,主要是描述类和类之间的关系。
对象图
对象图是系统在某一时刻的快照。
动态建模
状态机图
状态机图:
1.对单个类的对象的生命周期进行建模◆描述了对象时间上的动态行为
2.每个对象被认为是事件驱动 的孤立实体。
3.由状态 和跃迁 组成的图,通常状态机附属于类,描述类实例对接受事件的响应。
4.事件表达对象间的调用、显式信号、值的改变或时间的推移。调用事件、变更事件、信号事件、时间事件。
5.状态描述对象生命周期的一. 段时间,可以是等待其它事件时所处的时间,或是执行某一活动时所处的时间,状态分为简单状态 和复合状态 。
跃迁定义对象对某一事件发生的反应
1.迁移具有触发事件 、跃迁条件、动作 和目标状态 。
2.跃迁的种类有外部跃迁 和内部跃迁 。外部跃迁是最普通的跃迁,会发生状态改变;内部跃迁不发生状态改变。
3.跃迁有两个隐式动作:进入动作 和退出动作。无论何时进入和退出时都要执行,这方便进入时进行初始化工作,退出时进行资源的释放工作。
用例图
用例图描述各个执行者在各个用例中的参与情况,描述系统为用户所感知的外部视图。通过用例图才把需求真正地反映出来。
用例图的功能:
1.捕获系统用户需求描述系统边界。
2.指明系统外部行为。
3.指导系统开发者的功能开发。
4.系统建模的起点,指导所有的类图和交互图的设计。
5.产生测试用例,用户文档。
6.估计项目大小和进度。
7.用例可以参与多种关系:关联、扩展、泛化和包含。
活动图
1.活动图是用状态机对工作流进行建模的特殊形式,它和流程图很类似,不过它支持并发控制。活动图强调的是活动的关系,而状态图强调的是状态的变化。
2.活动图一般不描述所有的运算细节,它显示活动的流,但不显示执行活动的对象。
3.活动图处于系统的外部和内部视图之间,所以它可以作为设计的起点,为了完成设计,每个活动必须扩展成一个和多个操作,每个操作被指派给特定的对象来实现。
4.将商业组织控制的活动划分在一起,这类划分可以通过分隔的区域来表达,由于它们的外观,每个区域称为泳道(swimlane) 。
交互图
1.对象行为是通过交互来实现的,交互是对象间为完成某-目的而进行的一系列消息 交换。
2.消息是对象间的单向通信,从发送者到接受者的携带信息的控制流。消息可能带有值参 。
3.消息序列可用两种图表示:顺序图(重点在消息的时间顺序) 和协作图(重点在交换消息的对象间的关系) 。对协作图来说,时间顺序可以从顺序号获得。
4.顺序图用二维表来表示交互,纵向是时间轴,横向是参与的角色以及它们交换的消息。
5.角色的生命周期表现为生命线,- 条垂直的线,在激活的时间段里是双线,在状态保持的时间里是虚线。
6.消息表示为从一条生命线出发到另- -条生命线的有向线,从上而下,表示消息的时间顺序。
协作图
1.协作图包含分类角色和关联角色,当它实例化时,对象被绑定到分类角色,链被绑定到关联角色关联角色还可能被各种暂时性的链来充当,如过程参数和局部过程变量,链可以指定暂时性的原型:{parameter}、{local}或自身调用{self}。
2.协作图对实现协作的对象和链进行建模,而忽略其他对象。
3.通常在一个协作图中每个对象分配一个符号,然而有时不同状态的对象需要显式指出,流 将同一个对象的不同状态版本关系在一起,使用{become}原型。流的{copy}原型不太常用。
物理架构
实现视图
实现视图描述可重用的系统组件以及组件之间的物理依赖,比如动态链接库、应用程序。
部署视图
部署视图描述系统资源在运行时的物理分布,系统资源成为结点。
建模步骤
- UML是一种建模语言而不是方法,这是因为JML中没有过程的概念,而过程正是方法的一个重要组成部分。UML本身独立于过程,这意味着用户在使用UML进行建模时,可以选用任何适合的过程。
一般采用的建模过程有:瀑布开发模型、迭代递增开发模型,如下图所示,
瀑布开发模型 ↓↓↓
迭代递增开发模型 ↓↓↓
- 基于UML 的系统开发采取增量迭代开发模型。
[1]需求 最初需求规格说明 应当由代表系统最终用户的人员提供,内容包括系统基本功能需求和对计算机系统的要求。
[2]分析 分析的任务是找出系统的所有需求并加以描述,同时建立模型,以定义系统中的关键领域类,应由系统用户和开发人员合作完成。
分析的第一步是定义用例 ,以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明,此时需要与系统的潜在用户进行讨论
[3]设计 设计阶段的任务是通过综合考虑所有的技术限制,以扩展和细化分析阶段的模型。
设计阶段可以分为两个部分:结构设计 是高层设计,其任务是定义包(子系统),包括包间的依赖性和主要通信机制。我们希望得到尽可能简单和清晰的结构,各部分之间的依赖尽可能的少,并尽可能的减少双向的依赖关系。第二部分是详细设计 ,细化包的内容,使编程人员得到所有类的一个足够清晰的描述。
结构设计 一个设计良好的系统结构是系统可扩充和可变更的基础。包实际上是一些类的集合。类图中包括有助于用户从技术逻辑中分离出应用逻辑(领域类),从而减少它们之间的依赖性。
详细设计 详细设计的目的是通过创建新的类图、状态图和动态图(顺序图、协作图和活动图),描述新的技术类,并扩展和细化分析阶段的对象类。
[4]实现 构造或实现阶段是对类进行编程的过程。可以选择某种面向对象对象编程语言(如Java)作为实现系统的软件环境。Java很容易实现从逻辑视图到代码部件的映射,因为类到Java代码文件之间是一 一映射关系。
在实现阶段中,可以选取各种图的说明来辅助编程,比如:类图,状态图和动态图等。
[5]测试和配置 完成系统编码后,需要对系统进行测试,它通常包括:单元测试 、集成测试 、系统测试 和验收测试 。
在单元测试中使用类图和类的规格说明,对单独的类或一组类进行测试;在集成测试中,使用组件图和合作图,对各组件的合作情况进行测试;在系统测试中,使用用例图,以检验所开发的系统是否满足例图所描述的需求。系统的配置是实际地交付系统,包括文档和组成模型等。
Rose的使用