模型通常是在业务系统和IT系统语境中构建的,目的是更好地理解现有的或者未来的系统。不过,模型从来不会与现实完全一样。建模采用的手段总是强调本质的细节,忽略不相关的详情。但什么是本质的,什么又是不相关的,这个问题没有通用的答案。其答案取决于模型的目标是什么,以及谁将评审或阅读它。
考虑下列模型中强调或忽略了什么:
如果为模型赋予更多的信息,就会使模型变得更加复杂和令人费解。例如,在一张欧洲地图中同时包含行政区划、地质特征、人口统计数据、交通相关信息等内容,那么就会使这张地图变得难以阅读。针对该问题的解决方案就是把不同类型的信息分到独立的地图上,不同的视图关注的对象不同,这些视图将通过多种方法相互连接。通常,如果有一个视图被修改,那么其他视图也需要进行调整。例如,如果荷兰在北海开垦了个新岛屿,那么所有的视图(就是所有的地图)都必须更新。
对于建筑模型也是这样的。如果在原有的建筑物上添加一个新的侧厅,那么各种视图都将会受到影响,包括建筑平面图、表面图以及由wood制作的3D模型。如图2.3所示以简图方式说明了这个问题。在2.4节“范例分析的模型”中,将明确本书使用的各种模型之间的关系。每个模型的不同视图将在第3章“业务系统建模”、第4章“IT系统建模”和第5章“系统集成建模”中详细描述。
图2.3 一个对象的不同视图
作为通用规则,一个系统模型必须完成以下任务:
回答下列问题:
在现实生活中,我们经常发现烦琐、乏味、昂贵的建模结果在某人桌面上的一堆纸中简单地消磨殆尽。我们可能会问为什么会这样做,有两个因素对建模的结果将产生巨大影响:该模型为谁创建,期望用于什么目的。如果对此还没有充分讨论和定义就开始建模,那么在最终模型中未能体现用户重要信息的风险就可能存在。换句话说,如果没有正确地进行强调和忽略,那么所呈现的内容也就是没有价值的。
要定义模型的目的及目标读者群,应回答以下问题:
在模型的抽象级别、清晰度和详细程度上必须做一个折中。也可以开发几个规范程度与详细程度都不同的模型构件,以满足不同的目标读者群。采用这种方法,在模型构建者、客户、用户及开发人员之间的沟通就会更加简单。不过很重要的一点是不要做过头,只需针对模型的目标读者群做一些调整即可。
分析或设计模式描述的是通用设计和建模方法的样例模型。只要有可能,就应该寻找这样的样例模型:在因特网上、在书籍中(例如,Martin Fowler编著的《分析模式:可复用的对象模型》、在杂志里查询或询问你的同事。
在图2.4中展示了分析的全过程,它是由获取(obtaining)、表述(representing)和验证(verifying)三个方面组成的。
图2.4 分析流程
分析过程将生成一个规格说明书,它是源于模型及其他信息的表述。分析工作是和知识携带者一起进行的,诸如客户、用户和领域专家等。
如果对所讨论议程的技术基础不精通,那么开发并验证一个可用的模型是不可能的。去哪里找这些对待建模系统很熟悉的知识携带者呢?我们和以下人群有过很好的合作经历:
对于业务流程的分析和理解而言,有许多技术已被证实很有效:
每种特定的UML图就是系统模型的一个视图。使用不同的图表类型,所强调或忽略的方面也就不同。将这些不同的视图组合在一起,就能够获得系统的良好模型。UML中大部分图表(diagram)都是属于graph类型的(如图2.5所示),也就是说它是由图形元素以及连接图形元素的线组成的。
要阅读这些图表,需要知道元素和线条有哪些类型,以及它们的含义。我们将对在后续章节中将要使用的图表进行解释。
甚至在CASE工具中也尝试把UML图表当作视图。它们还将使用数据库来保存模型的相关信息,每个图表(可看作视图)都显示了一部分信息,这样,CASE工具将帮助你确保每个视图的一致性。例如,如果在一个类图中某个类的名字被修改,则与该类相关的顺序图也会自动更新。
模型数据库是区分CASE工具与绘制程序的本质功能,如图2.6所示。使用纸和笔或者绘图程序都能够简单地绘制任何一种UML图。但在这种情况下,生成的各种图表除了图形之外没有任何其他信息。只有使用符合UML规范的带数据库的CASE工具,才能确保模型信息收集、管理和修改的一致性。UML提供了其自己的数据库模型:UML元模型,它是UML规范的组成部分(“OMG:统一建模语言:下部构造,2.0版,最终采纳标准修订版,2003年9月”和“OMG:统一建模语言:上层构造,2.0版,最终采纳标准修订版,2004年10月”,可在http://www.omg.org下载到)。在UML图中的所有元素以及这些元素的描述都包含于UML元模型中。例如它声明一个类可以拥有属性和方法,这个UML的“数字模型”被看作一个语言,这是所有UML CASE工具的模型数据库基础。不幸的是,许多CASE工具都需要大量的资源、很昂贵、开发较少、笨重并且需要外部培训。尽管如此,除了那些很小的项目之外,使用它们还是很有价值的。
图2.6 CASE工具将起到一个数据库的作用
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号
京公海网安备110108001071号