【IT168 技术文章】

    引言

    长期以来，可视建模被视为软件开发的一项主要非常好的实践。通过关系图，设计人员和分析人员能够更方便而有效地向各种受众呈现复杂信息。不幸的是，很多模型的构建工作差强人意、缺乏组织性或使用率不高。为了尽可能从可视模型表示获得最大好处，不仅应该考虑模型的内容，还要考虑信息的表示。创建有效的系统模型时，需要关注三个主要概念：关系图形式 的选择、关系图围绕共同 主题 的组织以及侧重名为轴心内容 的信息具体特征的视图的创建。

    模型形式

    有两种相关的模型形式：表示形式和组织形式。软件开发中的常见表示形式是 UML，可详细说明由 13 种关系图类型组成的集合的具体概念和语法，每个类型都分别针对从需求到部署的特定软件系统开发方面。这包括结构关系图（如类、对象和部署）和行为关系图（如序列、活动和状态）。此类关系图集合的内容非常多，这意味着您必须全面地了解每种形式，仔细考虑目标受众，并花时间创建一致且具有内聚性的关系图集合，以传递模型的预期意图。例如，系统设计人员对系统的逻辑和物理方面感兴趣，因此最有用的形式就是类和序列关系图，而不是用例和活动关系图。相反，系统分析人员对用例关系图中描述的概念感兴趣，而对构造和部署的细节不太感兴趣。 UML 语法可强制规定特定的建模关系。例如，消息关系仅能出现在对象的两个实例间。

    除了 UML 外，还经常使用其他一些建模形式用于软件建模，包括美国国防部体系结构框架（Department of Defense Architecture Framework，DODAF）、Open Group 体系结构框架（The Open Group Architecture Framework，TOGAF）和 Zachman 框架。（有关 Zachman 框架的更多信息，请参见参考资料。）另外还可以使用不同的语言，如集成计算机辅助制造（Integrated Computer-Aided Manufacturing，ICAM）定义语言、实体关系数据模型和使用系统建模语言（Systems Modeling Language，SysML）捕获的系统模型。无论所使用的建模形式或语言如何，都必须采用一致的方式描述所涉及的系统。

    可以将模型的组织形式作为一组视角加以捕获（请参见侧栏）。视角定义为模型视图的集合，使用一组关系图、文档和其他相关构件进行表示。可以为了满足对模型内容感兴趣的特定涉众创建每个视图（请参见图 1）。

    图 1. 应用程序模型视角

    软件应用程序必须满足不同的涉众需求，因此描述这些系统的模型也一定具有复杂性。例如，业务涉众对需求 (Requirements) 视角感兴趣，可以将此视角用于组织用例关系图、活动关系图和其他关于系统功能的信息。软件系统存在很多可能的视角，包括 Philippe Kruchten 的经典 4+1 视图（有关更多信息，请参见参考资料部分）以及侧重环境注意事项、维护和自动化测试的视角。表 1 描述了对任何软件系统模型都应该有用的一组视角。

    表 1. 常见的有用视角

    模型主题

    确定了模型的相应形式后，需要根据每个系统体系结构区域的主题对信息进行组织。例如，所有软件系统的一个关键方面是内部依赖关系的组织；表示这种关系的一个方法是采用分层体系结构。表示此区域的模型视图集合的主题是依赖关系管理。因此，模型主题由系统的本质所决定，包括系统用途和目标。模型中视角的内容是围绕特定的主题收集的，类似于表 2 中的内容。

    表 2. 应用程序模型主题

    为了进行演示，让我们以一个特定的视角及该视角中的主题为例。例如，假定所考虑的系统是管道修复公司的调度应用程序。该公司需要有效地分配每辆车和每个技术人员，从而使技术人员在前后工作现场之间用在路上的时间尽可能少。一系列涉众对此系统感兴趣，包括业务所有者、系统开发人员、技术人员、系统管理员、数据管理人员、需求工程师、测试人员和架构师。具体的视角可满足不同涉众的需求。例如，“用例”视角允许需求工程师和业务所有者讨论系统功能的特征。“逻辑”视角则侧重说明结构和行为方面的情况。结构方案可能包含一系列主题，其中一个就是资源调度要点。在本例中，所感兴趣的资源是技术人员、车辆以及需要进行调度的工作。图 2 显示了一个这样的结构视图。

    图 2. 工作和调度管理

    图 2 还说明了关系图如何使用轴心内容（在关系图轴心内容部分讨论）表示模型信息。此处的轴心内容是 JobSchedule 组件的结构关系。具体来说，查看者将会注意到 ScheduleManager，因为其颜色不同，而且位于关系图的上部居中位置。请注意关系图中没有显示外部信息，如调试日志记录等。这可确保仅仅传递单个信息——关系图轴心内容所代表的信息。

    除了结构关系图外，还可以通过其他几个关系图说明行为，如序列关系图和主题关系图（请参见图 3）。

    图 3. 工作状态图

    所有这些关系图的主题都是“资源调度”，所以会在模型中进行分组。通过按主题对模型视图进行分组，可以确保模型提供一组针对特定查看者（如涉众）的有组织视图，而且能够代表系统描述的重点部分。

    关系图轴心内容

    最后，必须考虑每个特定关系图的内容。为了确保每个关系图有效地表示其信息，需要确保关系图内容基于单一的特定信息。轴心内容提供关系图元素焦点，可确保仅在特定的关系图中包含相关的信息。例如，在图 3 所示的 Job 的状态关系图中，关系图仅仅关注 Job 及其状态转换。如果包括了其他对象，关系图将在其重点及其要传达的信息方面就会变得模糊。

    此处要记住的最重要一点是：使用关系图向查看者传达模型所包含的内容。其他的都是用于帮助快速找到提及的关系图的组织结构。因此，如果查看者对关系图信息感到迷惑不解，则可能因为其中包含的信息太多，关系图达到预期影响的目的就可能无法实现。

    创建复杂系统关系图的人员会有一种奇怪的趋势，习惯不断向关系图中添加越来越多的信息，以致于会让受众感到信息容量过多。或许他们希望创建涵盖系统的所有有意义部分的单一视图。不过，通过在一个可视图像中提供这么多信息，会让核心信息被细节所淹没。我遇到过很多这样的情况，但我想说在从事科研工作早期所遇到的一种情况。我当时在参加一位知名研究人员主持的研讨会，他在会上说明自己在细胞信号传递途径方面的成果。他的演讲的开始部分非常好，使用了几张概述性的幻灯片，每张幻灯片都侧重于单个信息点——每张幻灯片都具有清楚的轴心内容。然后他将有关四个复杂图表的数据全部挤到了单张幻灯片中。任何离屏幕两英尺远的人都无法阅读其中的内容，甚至他自己在区分每个坐标标签时都出现了错误。无数的数据行都以单色显示，似乎是随意排列在每个图表上，数据中的小数点与污迹都无法区分了。不管怎样，这位受人尊敬的科学家接下来用了 20 分钟时间解释这单张幻灯片中的所示的数据。我留意了一下房间中的其他人，几乎所有人（包括我自己）都感到迷惑不解，大部分都完全失去了兴趣。

    这个例子的要点是，很容易在给出了大量详细信息时让人产生困惑。如果演讲者直接将四个图表分为独立的幻灯片，则每个人都能够更好地了解其中的细节。而且，这将帮助对屏幕显示进行分离，从而使其一次仅涉及一个要点——清楚的核心内容。让听众分别看四个图表将更容易跟上演讲者的思路，而通过一个总结幻灯片又能将四个图表的内容方便地整合在一起。

    考虑每个关系图的轴心内容时，首先要考虑整个表示（或模型）。所描述的整个系统是什么？最好采用哪种方法进行表示，以便每个组件提供足够的细节？可以忽略哪些内容，以便查看者更好地重点关注重要方面？通过这些问题，可以很好地选择轴心内容点。对于形式和主题，可以选择很多可能的关系图轴心内容（请参见表 3）。

    表 3. 关系图轴心内容类别

    在 UML 中，每个关系图侧重特定的系统方面，如类关系图用于捕获结构信息。不过，特定关系图类型中应该只有一个信息焦点（即轴心内容）。定义糟糕的轴心内容可能会让关系图要传递的信息含混不清。

    总结

    创建系统模型在时间和资金方面投入都比较大；让这个重要的资源由于对模型结构错误认识而被滥用，既非常浪费，也会降低效率。模型旨在进行重复利用；根本没有理由让开发团队将宝贵时间浪费在构建复杂而详细的一次性构件上。为了让模型创建和维护方面的成本物有所值，需要确保模型非常有用。

    除非系统模型中包含的信息经过了有效的组织，能够进行方便的维护，而且能够让模型受众快速发现相关信息，否则创建复杂的系统模型几乎没有任何价值。缺乏组织性的模型将很快失去准确性，会变得很难使用（可能这一点更为重要），从而导致最终将其弃用。创建模型需具有一致的形式、围绕可理解的共同主题而且需提供信息关系图的内聚性集合，才能提高此模型的短期和长期价值。只有这样，在可视建模工作上所投入的精力才会带来巨大的好处。

    参考资料

    学习

    您可以参阅本文在 developerWorks 全球网站上的 英文原文。

    从 IEEE 网站了解关于 IEEE 1471 规范的更多信息。

    关于 IEEE 1471 规范的 Wikipedia条目。

    阅读 Cris Kobryn 和 Chris Sibbald 撰写的白皮书 Modeling DoDAF Compliant Architectures (PDF)（Telelogic，2004 年 10 月）。

    阅读 Thomas A. Hokel 撰写的白皮书 The Zachman Framework for Enterprise Architecture: An Overview，了解关于 Zachman 框架的更多信息。

    Murray Cantor 撰写的 Rational Unified Process for Systems Engineering Part II: System architecture（The Rational Edge，2003 年 9 月）讨论了 IBM? Rational Unified Process? 的 Engineering 扩展，并介绍了基于视角的系统建模方面的内容。

    阅读 Philippe Kruchten 撰写的 架构蓝图--软件架构 "4+1" 视图模型（IEEE Software，1995 年 11 月），了解经典 4+1 视图的更多信息。

    阅读 Bran Selic 撰写的 统一建模语言(UML) 版本 2.0（developerWorks，2005 年 4 月），了解关于 UML 的更多信息。

    阅读 Kim Letkeman 撰写的包含六个部分的系列文章 Comparing and merging UML models in IBM Rational Software Architect（developerWorks，2005 年 6 月）。

    在 developerWorks 的 Architecture 架构专区中，获取用以提高您在体系结构方面的技能的各种资源。

    浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。

    了解关于 developerWorks 技术事件和网络广播的最新信息。

    获得产品和技术

    下载 Rational Software Modeler 的试用版。

    讨论

    参与论坛讨论。

    访问 developerWorks Blog，从而加入到 developerWorks 社区中来。