您的位置：首页 > 其它

UML中静态与动态视图的总体介绍

2017-04-07 13:32 218 查看

主要的域	视图	图	主要概念	简单说明
结构（描述了系统中的结构成员及其相互关系）	静态视图（概念建模）	类图	元素（类、接口），关系（关联、泛化、依赖关系、实现）	对应用领域中的概念以及与系统实现有关的内部概念模型。由类与类的相互关系组成；包含属性与操作描述系统内部类与类的静态关联关系静态视图说明了对象的结构。一个面向对象的系统使数据结构和行为特征统一到一个独立的对象结构中。根据面向对象的观点，数据和行为是紧密相关的。静态视图将行为实体描述成离散的模型元素，但是不包括它们动态行为的细节。静态视图中的关键元素是类元及它们之间的关系。类元是描述事物的建模元素。
用例视图（概念建模）	用例图	元素（用例、参与者），关系（关联、扩展、包括、用例泛化）	用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行描述参与者与系统之间的关系用例实例（使用场景：用户使用系统的一个实际的、特定的场景）是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。用例应该给参与者代理客观的价值，用例是在系统中的。用例模型描述的是外部参与者所理解的系统功能，使用在需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明开发者和用户对需求规格达成的共识。
实现视图（物理视图）	构件图	构件、接口、依赖关系、实现	为了可重复性和可操作性的目的，系统实现方面的信息也和重要。实现视图为系统的构件建模— 构件即构造应用的软件单元— 还包括各构件之间的依赖关系，以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响。从构件到接口的实线表明该构件提供的列在接口旁的服务。从构件到接口的虚线箭头说明这个构件要求接口提供的服务。将系统中可重用的块包装成具有可替代性的物理单元，这些单元称为构件。实现视图利用构件与构件之间的接口和依赖关系来表示设计元素（例如类）的具体实现。构件是系统高层的可重用的组成部件。
部署视图（物理视图）	部署图	节点、构件、依赖关系、位置	部署视图描述位于节点实例上的运行构件实例的安排。节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配。表示运行时计算资源（如计算机及他们之间的连接）的物理布置。这些运行资源被称为节点。在运行时节点包含构件和对象，构件和对象的分配可以是静态的，他们也可以在节点间迁移，如果含有依赖关系的构件实例放在不同的节点上，部署视图可以展现出执行过程的瓶颈。
动态（描述了系统随时间变化的行为）	状态机视图（概念建模）	状态机图	状态、事件、转换、动作	状态机视图是一个类对象所可能经历的所有历程的模型图。状态机由对象的各个状态和连接这些状态的转换组成。状态图可用于描述用户接口、设备控制器和其他具有反馈的子系统。它还可用于描述在生命期中跨越多个不同性质阶段的被动对象的行为，在每一阶段该对象都有自己特殊的行为。每一个对象都被看作是通过对事件进行探测并做出回应来与外界其他部分通信的独立的实体。通过对类对象的生命周期建立模型来描述对象随时间变换的动态行为。状态机是展示状态与状态转换的图，状态机用于描述类的行为，但他们也描述用例、协作和方法的动态行为。对这些对象而言，一个状态代表了执行中的一步。我们通常用类和对象来描述状态机，但是它也可以被其他元素所直接应用。状态机是一个类的对象所有可能的生命历程的模型，状态机是一个对象的局部视图，一个将对象与其外部世界分离开来并独立考查其行为的图。利用状态机可以精确地描述行为，但不适合综合理解系统执行操作。如果要更好地理解整个系统范围内的行为产生的影响，那么交互视图将更有用些。然而，状态机有助于理解如用户接口和设备控制器这样的控制机。状态机描述的范围不宽，但它描述了对象深层次的行为，是单独考察每一个对象的“微缩”视图。对状态机的说明是精确的，而且可以直接用于代码。然而在理解系统的整个功能时存在困难，因为状态机一个时刻只集中描述一个对象，要确定整个系统的行为必须同时结合多个状态机进行考察。交互视图更加适合描述一组对象的整体行为。
活动视图（概念建模）	活动图	状态、活动、完成转换、分叉、结合	活动图是状态机的一个变体，用来描述执行算法的工作流程中涉及的活动，用于对计算流程和工作流程建模。活动图中的状态表示计算过程中的所有状态，而不是普通对象的状态，通常，活动图假定在整个计算处理过程中没有外部事件引起的中断，否则普通状态图更适合描述该情况。用途是对人类组织的现实世界中的工作流程建模。对事物建模是活动图的主要用途，但活动图也可对软件系统中的活动建模。活动图有助于理解系统高层活动的执行行为，而不涉及建立协作图所必须的消息传送细节。表示方式：活动状态表示成带有圆形边线的矩形框，它含有活动的描述（普通的状态盒为直边圆角）。简单的完成转换用箭头表示。分支表示转换的监护条件或具有多标记出口箭头的菱形。控制的分叉和结合与状态图中的表示法相同，是进入或离开深色同步条的多个箭头。活动图没有表示计算处理过程中的全部详细内容。表示了活动进行的流程但没表示出活动执行的对象。活动图是设计活动的起点，为了完成设计，每个活动必须扩展细分成一个或多个操作，每个操作被指定到具体类，这种分配的结果引出了用于实现活动的对协作的设计工作。
交互视图（概念建模）	交互视图		交互视图描述了执行系统功能的各个角色之间相互传递消息的顺序关系。交互视图显示了跨越多个对象的系统控制流程。对象间的相互作用体现了对象的行为。这种相互作用可描述成两种互补的方式。一种以独立的对象为中心进行考察，一种以相互作用的一组对象为中进行考察。交互视图是对象间协作关系的模型。顺序图和协作图都可以表示各对象间的交互关系，但它们的侧重点不同。顺序图用消息的几何排列关系来表达消息的时间顺序，各角色之间的相关关系是隐含的。协作图用各个角色的几何排列图形来表示角色之间的关系，并用消息来说明这些关系。
顺序图（时序图）	交互、对象、消息、激活	顺序图表示了对象之间传送消息的时间顺序；顺序图的一个用途是用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件
协作图	协作、交互、协作对象、消息	协作图对在一次交互中有意义的对象和对象间的链建模。对象和关系只有在交互的语境中才有意义。类元角色描述了一个对象，关联角色描述了协作关系中的一个链。协作图的一个用途是表示一个类操作的实现。协作图可以说明类操作中用到的参数和局部变量以及操作中的永久链。
模型管理（说明模型的分层组织结构）	模型管理视图	类图	包、子系统、模型	模型管理视图对模型自身组织建模。一系列由模型元素（如类、状态机和用例）构成的包组成了模型。包可能包含其他的包，因此，整个模型实际上可看成一个根包，它间接包含了模型中的所有内容。包是操作模型内容、存取控制和配置控制的基本单元。每一个模型元素包含于包中或包含于其他模型元素中。模型是从某一观点以一定的精确程度对系统所进行的完整描述。从不同的视角出发，对同一系统可能会建立多个模型，例如有系统分析模型和系统设计模型之分。模型是一种特殊的包。子系统是另一种特殊的包。它代表了系统的一个部分，它有清晰的接口，这个接口可作为一个单独的构件来实现。任何大的系统都必须被分成几个小的单元，这使得人们一次只处理有限的信息，并且分别处理这些信息的工作组之间互不干扰，模型管理由包及包之间的依赖关系组成。
可扩展性	所有	所有	约束、构造型、标记值	U M L包含三种主要的扩展组件：约束、构造型和标记值。约束是用某种形式化语言或自然语言表达的语义关系的文字说明。构造型是由建模者设计的新的模型元素，但是这个模型元素的设计要建立在U M L已定义的模型元素基础上。标记值是附加到任何模型元素上的命名的信息块。这些组件提供了扩展 U M L模型元素语义的方法，同时不改变 U M L定义的元模型自身的语义。使用这些扩展组件可以组建适用于某一具体应用领域的 U M L用户定制版本。 UML提供几种扩展机制，允许建模者在不改变基本建模语言的基础上做一些通用的扩展。这些扩展机制已经被设计好，以便在不需要理解全部语义的情况下就可以存储和使用。由于这个原因，扩展可以作为字符串存储和使用。对不支持扩展机制的工具来说，扩展只是一个字符串，可以作为模型的一部分被导入、存储，还可以传递到其他工具。我们期望后端工具设计成能够处理各种扩展，这些工具会为他们需要理解的扩展定义特定的语法和语义。这种扩展方法很可能不能满足出现的多种要求，但是它以一种易于实现的简单方式容纳建模者对UML制裁的大部分要求。一定要记住扩展是违反UML的标准形式的，并且使用它们会导致互相影响，在使用扩展机制之前，建模者应该仔细权衡利弊，特别是当前现有机制可以合理工作时。典型的，扩展用于特定的应用域或编程环境，但是他们导致了UML方言的出现，包括所有方言的优点和缺点。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签： uml

相关文章推荐

新的分享

章节导航

添加评论
分享网址
分享文章
返回顶部