三种模型

 

《uml面向对象建模与设计》本书提出了一套面向对象的表示法并且从分析到设计再到实现扩展出了一种过程。在开发过程的所有阶段里,都可以应用相同的表示法。本节为大家介绍类模型。

 

2.3 三种模型

我们发现从三种相关但不同的角度来构建系统模型会很有效, 每种角度都捕获了系统重要的一个层面, 但完整描述就需要全部三种模型。类模型表示系统静态的、结构化的“数据冶层面; 状态模型表示系统时序的、行为的“控制冶层面; 交互模型表示各个对象的协作, 是系统的“交互冶层面。一般的软件过程具备所有这三个方面: 它使用数据结构(类模型), 按时间设定操作顺序(状态模型), 并在对象之间传递数据和控制(交互模型)。每种模型都包含了对其他模型中的实体的引用。例如, 类模型将操作依附于类, 而状态模型和交互模型则详细描述这些操作。

三种模型将一个系统划分成不同的视图。不同的模型并不是完全独立的———系统不只是一系列独立的部件———但每种模型在很大程度上都可以被单独查看或理解。不同模型之间有着有限而清晰的互连。当然, 创建出糟糕的设计也是有可能的, 会让这三种模型交织在一起,不能分开; 但好的设计会隔离系统的不同层面, 限制它们之间的耦合。

在这三种模型当中, 每一种都会随着开发过程而演化。首先, 分析师在不考虑最终实现的情况下创建了应用程序的模型, 然后设计人员会给模型添加解决方案构件, 实现人员对应用程序和解决方案构件进行编码。模型有两维———系统的视图(类模型、状态模型或交互模型) 和开发的阶段(分析、设计或实现)。其意义一般从上下文中就可以清晰地看出来。

 

 

 

 

2.3.1 类模型

类模型描述系统中对象的结构———它们的标识、与其他对象的关系、属性和操作。类模型提供了状态和交互模型的上下文。除非要改变某些东西, 或要与其交互, 否则变化和交互就是无意义的。对象是我们划分世界的单元, 是模型的分子。

在构建类模型的过程中, 我们的目标是从现实世界中捕获那些对应用而言重要的概念。在构建工程问题模型的时候, 类模型应该包含为工程师所熟知的术语; 在构建商业问题模型的时候, 应该使用商业术语; 在构建用户界面模型的时候, 要使用应用程序的术语。分析模型不应该包含计算机概念, 除非正在建模的应用本质上就是计算机问题, 例如编译器或操作系统等。设计模型描述了要如何解决问题, 可能会包含计算机概念。

类图表达了类模型。泛化使得类之间可以共享结构和行为, 关联使得类之间发生关系。类定义了每个对象的属性值, 以及每个对象执行或经历的操作。

 

 

2.3.2 状态模型

状态模型描述了与操作的时间和顺序相关的对象层面———标记变化的事件, 界定事件上下文的状态, 以及事件和状态的组织。状态模型捕获控制, 即描述操作出现顺序的系统层面,不用考虑操作做了些什么, 它们在操作什么, 或它们是如何实现的。

状态图表示状态模型。每幅状态图都显示了系统内允许的某个对象类的状态和事件序列。状态图会引用其他的模型。状态图中的动作和事件都变成了类模型中对象上的操作。状态图之间的引用变成了交互模型中的交互。

 

2.3.3 交互模型

交互模型描述对象之间的交互———各个对象如何协作, 来从整体上完成系统的行为。状态和交互模型描述了行为的不同侧面, 它们两者配合才能完整描述行为。

用例、顺序图和活动图描述交互模型。用例描述系统和外部参与者之间交互的主要内容,顺序图显示交互的对象和交互的时间顺序, 活动图显示计算的处理步骤之间的控制流。

 

2.3.4 模型间的关系

每一种模型都描述了系统的一个方面, 但也包含了对其他模型的引用。类模型描述状态模型和交互模型操作的数据结构。类模型中的操作对应于事件和动作。状态模型描述对象的控制结构。它显示了依赖于对象取值的决策, 并引发动作来改变对象取值和状态。交互模型专注于对象之间的信息互换, 并提供了系统操作的整体视图。

关于由哪种模型来包含某段信息, 偶尔也会出现含糊不清的地方。这很自然, 因为任何抽象都只是对现实的一种粗略概括, 肯定有一些内容会超出抽象范围之外。系统的一些特性可能被模型表现得很差。这也很正常, 因为没有哪一种抽象是完美的, 抽象的目标是在不使模型负担过重的条件下简化系统描述, 否则太多的构想会使模型变成负担, 而不会起到帮助作用。对于模型无法充分捕获的那些内容, 自然语言或特定于应用的表示法也是可以接受的。