对于标准建模语言UML,每一个程序设计人员都不陌生,它可用于软件开发的分析、设计和实现的全过程,软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。下面小编和大家探讨的是模型的概念域。
静态结构。任何一个精确的模型必须首先定义所涉及的范围,即确定有关应用、内部特性及其相互关系的关键概念。UML的静态组件称为静态视图。静态视图用类构造模型来表达应用,每个类由一组包含信息和实现行为的离散对象组成。对象包含的信息被作为属性,它们执行的行为被作为操作。多个类通过泛化处理可以具有一些共同的结构。子类在继承它们共同的父类的结构和行为的基础上增加了新的结构和行为。对象与其他对象之间也具有运行时间连接,这种对象与对象之间的关系被称为类间的关联。一些元素通过依赖关系组织在一起,这些依赖关系包括在抽象级上进行模型转换、模板参数的捆绑、授予许可以及通过一种元素使用另一种元素等。另一类关系包括用例和数据流的合并。静态视图主要使用类图。静态视图可用于生成程序中用到的大多数数据结构声明。在UML视图中还要用到其他类型的元素,比如接口、数据类型、用例和信号等,这些元素统称为类元,它们的行为很像在每种类元上具有一定限制的类。
动态行为。有两种方式对行为建模。一种是根据一个对象与外界发生关系的生命历史;另一种是一系列相关对象之间当它们相互作用实现行为时的通信方式。孤立对象的视图是状态机—当对象基于当前状态对事件产生反应,执行作为反应的一部分的动作,并从一种状态转换到另一种状态时的视图。状态机模型用状态图来描述。
相互作用对象的系统视图是一种协作,一种与语境有关的对象视图和相互之间的链,通过数据链对象间存在着消息流。视图点将数据结构、控制流和数据流在一个视图中统一起来。协作和互操作用顺序图和协作图来描述。对所有行为视图起指导作用的是一组用例,每一个用例描述了一个用例参与者或系统外部用户可见的一个功能。
实现构造。UML模型既可用于逻辑分析又可用于物理实现。某些组件代表了实现。构件是系统中物理上的可替换的部分,它按照一组接口来设计并实现。它可以方便地被一个具有同样规格说明的构件替换。节点是运行时间计算资源,资源定义了一个位置。它包括构件和对象。部署图描述了在一个实际运行的系统中节点上的资源配置和构件的排列以及构件包括的对象,并包括节点间内容的可能迁移。
模型组织。计算机能够处理大型的单调的模型,但人力不行。对于一个大型系统,建模信息必须被划分成连贯的部分,以便工作小组能够同时工作在不同部分上。即使是一个小系统,人的理解能力也要求将整个模型的内容组织成一个个适当大小的包。包是UML模型通用的层次组织单元,它们可以用于存储、访问控制、置以管理配及构造包含可重用的模型单元库。包之间的依赖关系是对包的组成部分之间的依赖关系的归纳。系统整个构架可以在包之间施加依赖关系。因此,包的内容必须符合包的依赖关系和有关的构架要求。
扩展机制。无论一种语言能够提供多么完善的机制,人们总是想扩展它的功能。我们已使UML具有一定的扩展能力,相信能够满足大多数对UML扩充的需求而不改变语言的基础部分。构造型是一种新的模型元素,与现有的模型元素具有相同的结构,但是加上了一些附加限制,具有新的解释和图标。代码生成器和其他的工具对它的处理过程也发生了变化。标记值是一对任意的标记值字符串,能够被连接到任何一种模型元素上并代表任何信息,如项目管理信息、代码生成指示信息和构造型所需要的值。标记和值用字符串代表。约束是用某种特定语言(如程序设计语言)的文本字符串表达的条件专用语言或自然语言。UML提供了一个表达约束的语言,名为OCL。与所有其他扩展机制一样,必须小心使用这些扩展机制,因为有可能形成一些别人无法理解的方言。但这些机制可以避免语言基础发生根本性变化。