科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道基础软件构建有效的系统模型

构建有效的系统模型

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

在本文中,您将了解如何基于形式、主题和轴心内容的原则组织和表示 UML 模型视图。

作者:Benjamin Lieberman 来源:ibmdw 2007年12月26日

关键字: 系统 模型

  • 评论
  • 分享微博
  • 分享邮件

引言

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

模型形式

有两种相关的模型形式:表示形式和组织形式。软件开发中的常见表示形式是 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. 应用程序模型主题
主题 描述 示例
分层 依赖关系管理 数据访问层
业务类别 稳定的业务操作和流程 合同谈判
集成 子系统和组件间的适配器、连接器和接口 第三方关系数据库
工作流 系统操作与异常控制 规则引擎
规则 对系统行为的约束 数据验证
环境 操作系统、资源和配置 服务器进程分配
构建、打包与交付 系统组件、物理交付媒介以及机制 构建文件(.zip 和 .tar 文件、FTP 交付与 HTTP 下载)

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


图 2. 工作和调度管理
工作调度

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

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


图 3. 工作状态图
工作状态图

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


关系图轴心内容

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

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

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

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

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


表 3. 关系图轴心内容类别
轴心内容 描述 示例
控制点 集中业务逻辑点 Enterprise JavaBeans (EJB) 会话对象
框架使用情况 框架元素实现和集成 事务管理和安全性
风险 高复杂性、耦合与变更 体系结构相关的用例实现
体系结构 体系结构相关的用例或系统组件 体系结构机制实现,如消息传递、安全性和审核
接口 子系统与组件间的接口的实现 商业化的现成集成适配器
功能分配 需求与设计间的可跟踪性 包含用例实现的协作关系图
性能 关注处理瓶颈、资源利用率和限制 Web 服务
结构 系统的结构方面,如包含层次机构、状态表和组件关系(依赖关系) 类/组件关系图
行为 系统的行为方面,如消息传递、对象创建/销毁、方法调用、广播/侦听器 序列关系图

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


总结

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

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

查看本文来源

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章