模型驱动系统开发的RUP插件入门

【IT168 技术文章】

    系统工程是一种各规程间融合的方法，它有助于成功系统的实现。 1 它关注于在开发周期的早期阶段定义消费者需要和功能性需求，记录需求，然后当考虑整个问题时（包括操作、金钱和时间、性能、培训和支持、测试、部署、制造等），进行设计集成和系统验证。

    系统工程将所有规程和专业团队整合在一起，形成了一个从概念到生产，从生产到操作的结构化开发过程。系统工程既考虑所有消费者的业务需要，也考虑他们的技术需要，其目标是提供一个满足使用者需要的高质量的产品。International Council on Systems Engineering (INCOSE) 的成员已经就如何定义“系统”和“系统工程”达成一致。 2

    模型驱动系统开发（MDSD）支持 INCOSE Consensus 的声明。它有助于管理设计系统的复杂性。为模型的任意一个特定层级管理细节的适当层级，是 MDSD 的一个重要组成要素。若干能够被描述为最佳实践的技术，被用作完成以下工作：

    *分解系统，而非需求
    *既能分割，又能集成
    *系统和组成要素合作；各个开发团队间也应如此
    *规范流程向上和向下体系结构
    *将生命周期基于移除风险和添加价值之上
    *开发组织应当反映产品体系结构

    系统通过如下手段被实现：

    *通过统一建模语言（UML）和用例对系统进行建模
    *通过 Context Workshops 创建一个普通的景象
    *基于方法论的 IBM® Rational® Software Architect 工具和 IBM Rational Unified Process® (RUP®) 的使用
    *注重早期风险移除的迭代化工作
    *采用一种反映系统体系机构的程序组织
    *确保体系结构和设计能够通过技术准备就绪资产被实现

    现在，MDSD 插件程序已经可以被提供给 RUP。本文将探索 MDSD 的基本规程，包括建模层级、分解层级、以及 MDSD 是如何支持 软件工程协会的能力成熟度模型集成（Capability Maturity Model Integration ，(CMMI®)）概念的。

    模型和抽象

    直观地，我们从抽象方面进行思考。无论我们是否意识到，该过程包括模型的使用——简单地描述，有时只存在于我们的头脑中；还包括分解——将事情分解为它们的组成部分。MDSD 通过在一个系统中不同的建模和分解层级的使用，将这样一个抽象的想法形式化。

    在每天的生活中，我们使用抽象来帮助对复杂性进行管理。例如，当我们驾驶一辆汽车时，我们并不去考虑汽车内部的工作，将汽车想象为一个大的“黑盒”，它拥有一些主要的接口，包括轮胎、加速器和制动器。在这个理解层级上，我们隐藏了这些功能的内部实现，仅仅从外部考虑它们的使用（因此用“黑盒”来比喻我们看不到、不关心内部的细节）。这样做将汽车放置在驾驶者和乘客所使用的上下文之中。

    另一方面，我们本地的机修工是从另外一个完全不同的抽象角度考虑问题。我们将整辆汽车想象为一个黑盒，而对于机修工而言，汽车表现为一个“白盒”——一组被查看、理解、修复或者替换的组成元件；每一个元件本身是一个黑盒。机修工最明白包括发动机、传动装置、制动系统等的各个组成部件之间的交互作用。模型、抽象和分解的层级允许我们不需考虑其内部的复杂性，思考大的系统和子系统以及它们之间的关系。

    分解的层级

    “分解的层级”是指系统各元素在那一个细节的层级上被考虑。在上面的例子中，机修工在一个比汽车拥有者更低的分解层级上考虑汽车；如果机修工将汽车的某个组件交给一位专业人员来修理，那么该专业人员就将在一个比机修工更低的分解层级上考虑那个组件。

    在任何给定的分解层级上，都有一组从黑盒角度考虑的逻辑系统元素。这些元素在那个分解层级上被当作黑盒来处理。它们其中的白盒元素只有在下一个分解层级中才会被考虑。
   
    因此，在模型中选择什么分解层级就决定了建模器选择暴露什么系统元素。依次，这个决定的部分依赖于谁将成为这个分解层级上的听众。我们可能都看到过在一个高层级听众面前暴露过度细节的缺点。在一个给定的分解层级上被暴露的系统元素应当被听众所认知，实际上，应当以他们所熟悉的形式被命名。

    例如，如果我们向抵押公司的部分领导和业务功能所有者发表演讲，就不应当包括诸如模型中信息操作者和数据库管理者这样的元素，相反，应当包括比如贷款发源、信用和可接受的标题之类的元素。