UML软件工程组织

 
更多技术资源 文章，讲座 ,培训，咨询 请访问 www.uml.org.cn

 
UML2.0实战：项目开发指南-2.2 模型、视图和图
 
来源：csdn
 


2.2  模型、视图和图

2.2.1  什么是模型

模型通常是在业务系统和IT系统语境中构建的，目的是更好地理解现有的或者未来的系统。不过，模型从来不会与现实完全一样。建模采用的手段总是强调本质的细节，忽略不相关的详情。但什么是本质的，什么又是不相关的，这个问题没有通用的答案。其答案取决于模型的目标是什么，以及谁将评审或阅读它。

考虑下列模型中强调或忽略了什么：

  • 汽车风洞模型；
  • 1∶50的建筑模型；
  • 地铁的路线计划；
  • 地图；
  • 组织结构图。

如果为模型赋予更多的信息，就会使模型变得更加复杂和令人费解。例如，在一张欧洲地图中同时包含行政区划、地质特征、人口统计数据、交通相关信息等内容，那么就会使这张地图变得难以阅读。针对该问题的解决方案就是把不同类型的信息分到独立的地图上，不同的视图关注的对象不同，这些视图将通过多种方法相互连接。通常，如果有一个视图被修改，那么其他视图也需要进行调整。例如，如果荷兰在北海开垦了个新岛屿，那么所有的视图（就是所有的地图）都必须更新。

对于建筑模型也是这样的。如果在原有的建筑物上添加一个新的侧厅，那么各种视图都将会受到影响，包括建筑平面图、表面图以及由wood制作的3D模型。如图2.3所示以简图方式说明了这个问题。在2.4节“范例分析的模型”中，将明确本书使用的各种模型之间的关系。每个模型的不同视图将在第3章“业务系统建模”、第4章“IT系统建模”和第5章“系统集成建模”中详细描述。

图2.3  一个对象的不同视图

2.2.2  为什么需要模型

作为通用规则，一个系统模型必须完成以下任务：

  • 实现所有相关参与者之间的沟通：要构建正确的系统，其本质就是使所有相关参与者沿着同一条线进行思考。特别重要的是使每个人都能够理解所使用的术语，赞同相同的需求，而开发人员也能够理解这个需求，并且确保在几个月后仍然能够理解。
  • 将针对客户、专家和用户的所有因素进行可视化：收集的所有与系统相关的因素都需要用大家都能够理解的方式来表述。但是，根据我们的实际经验，当想基于图表而非基于文本进行沟通时，总是经常头撞南墙。这背后的原因主要是对未知的恐惧，以及这些图表最初看起来总显得有些复杂。因此，本书中提供了阅读每种图表的指南。
  • 从完整性、一致性和正确性方面对这些因素进行验证，一个（或多或少）规范的模型使得对这些因素的完整性、一致性和正确性的验证工作成为可能。特别是可以通过询问特定的问题并回答它，就能够获取对它们之间关系的清晰描述。我们将在每种图之后列出这些问题。

回答下列问题：

  • 当讨论一个系统时，最后一次感觉自己在反其道而行是什么时候？
  • 最近一次对同一个问题一而再地讨论是什么时候？
  • 希望已经记录的讨论结果能够获得大多数人的认可，最近一次是什么时候？

2.2.3  模型的目的和目标群

在现实生活中，我们经常发现烦琐、乏味、昂贵的建模结果在某人桌面上的一堆纸中简单地消磨殆尽。我们可能会问为什么会这样做，有两个因素对建模的结果将产生巨大影响：该模型为谁创建，期望用于什么目的。如果对此还没有充分讨论和定义就开始建模，那么在最终模型中未能体现用户重要信息的风险就可能存在。换句话说，如果没有正确地进行强调和忽略，那么所呈现的内容也就是没有价值的。

要定义模型的目的及目标读者群，应回答以下问题：

  • 所要求的业务专用知识（business expertise）有多少？能否假定读者群对该主题的知识有基本的了解，或能对模型中事件和流程背后的基本原理进行解释？
  • 你的目标读者群需要多少细节信息？模型允许达到什么样的复杂度？如果流程和系统是经常发生变化的，那么很详细的模型就是不切合实际的。这是因为绝大部分时间中，以满意的形式维护这些模型是不可能的。模型的详细程度越低，所需的开发和修改的努力就越少，但同时也更不精确。
  • 目标读者群要花多少时间来阅读和解释模型？选择合适的详细程度和复杂程度，可以避免建模的结果在某人桌面上的一堆纸中消磨殆尽；否则将没有人有足够的时间阅读它。
  • 该模型中将使用什么语言？目标读者群是否理解业务的专用术语？是否理解IT术语？用一个简单的例子来说明：如果在一个装满水的瓶子外面贴上写着“水”的标签，那么肯定每个人都能够知道瓶子中装的东西。但是，如果标明的是“H2O”，虽然也是正确的，但针对的却是一个较小的人群，例如化学工作者。当然，其额外的好处就是展示了它的组成成分：氢和氧。在任何情况下，都需要决定什么样的“标签”最适合于目标读者群。
  • 选择什么样的抽象级别？抽象度越低的模型，就是更易于理解的模型，也是对用户越清晰的模型。这是因为一个抽象度越低的模型就越接近于用户实际使用的语言。另一方面，抽象度越高的模型，复用性就越高，也就更易于转换成IT系统，而且还可以证明越精确的模型其正确性也越高。对于IT专家而言，更适合于管理较高层面的抽象。反过来，如果让用户来处理这样的模型，可能就会令他比较为难了。
实践技巧

在模型的抽象级别、清晰度和详细程度上必须做一个折中。也可以开发几个规范程度与详细程度都不同的模型构件，以满足不同的目标读者群。采用这种方法，在模型构建者、客户、用户及开发人员之间的沟通就会更加简单。不过很重要的一点是不要做过头，只需针对模型的目标读者群做一些调整即可。

分析或设计模式描述的是通用设计和建模方法的样例模型。只要有可能，就应该寻找这样的样例模型：在因特网上、在书籍中（例如，Martin Fowler编著的《分析模式：可复用的对象模型》、在杂志里查询或询问你的同事。

2.2.4  分析过程

在图2.4中展示了分析的全过程，它是由获取（obtaining）、表述（representing）和验证（verifying）三个方面组成的。

图2.4  分析流程

分析过程将生成一个规格说明书，它是源于模型及其他信息的表述。分析工作是和知识携带者一起进行的，诸如客户、用户和领域专家等。

  • 事实的获取是由分析员和领域专家协作完成的，领域专家负责提供领域知识，分析员则贡献分析方法学知识。
  • 事实将以图表及文档的形式来表述，这通常是由分析员完成的。
  • 事实的验证则是只由知识携带者完成的，因为只有他们可以确定表述的内容是否正确。验证是绝对必要的，没有这项工作，虽然可能会有很漂亮的图表，但所表述的内容存在缺陷的可能性是很高的。简单地说，开发一个未经验证的模型是绝对没有价值的。
实践技巧

如果对所讨论议程的技术基础不精通，那么开发并验证一个可用的模型是不可能的。去哪里找这些对待建模系统很熟悉的知识携带者呢？我们和以下人群有过很好的合作经历：

  • 执行、操作和控制业务流程的人；
  • 类似或相关IT系统的用户；
  • 客户，这通常是很重要且很具创新性的知识携带者；
  • 业务伙伴；
  • 领域专家；
  • 管理者；
  • 外部观察者。

对于业务流程的分析和理解而言，有许多技术已被证实很有效：

  • 观察员工的工作；
  • 参与到要研究的业务流程中；
  • 找一个局外人（例如客户）；
  • 进行用户调查；
  • 进行用户访谈；
  • 相关人员的头脑风暴；
  • 和领域专家讨论；
  • 研究已有的表单、文档、规约、用户手册和工作工具；
  • 描述组织结构和工作流管理（组织结构图等）。

2.2.5  将图表看作视图

每种特定的UML图就是系统模型的一个视图。使用不同的图表类型，所强调或忽略的方面也就不同。将这些不同的视图组合在一起，就能够获得系统的良好模型。UML中大部分图表（diagram）都是属于graph类型的（如图2.5所示），也就是说它是由图形元素以及连接图形元素的线组成的。

文本框: 图2.5 UML图表都是graph类型的

要阅读这些图表，需要知道元素和线条有哪些类型，以及它们的含义。我们将对在后续章节中将要使用的图表进行解释。

甚至在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工具将起到一个数据库的作用
 
更多技术资源 文章，讲座 ,培训，咨询 请访问www.uml.org.cn