| UML软件工程组织 | |||
| |
|||
|
|||
模型驱动系统开发的 RUP 插件入门
RUP
plug-in for Model Driven Systems Development
2008-05-15 作者：Tom Wickstrom 来源： IBM
用于 IBM Rational Unified Process (RUP) 的模型驱动系统开发插件程序，支持系统工程和 MDSD 的基本规程。用于 MDSD 插件程序的 RUP 将尤其吸引系统开发项目管理者以及项目分析和规范、系统体系结构、实现和测试等相关人员的兴趣 系统工程是一种各规程间融合的方法，它有助于成功系统的实现。 1 它关注于在开发周期的早期阶段定义消费者需要和功能性需求，记录需求，然后当考虑整个问题时（包括操作、金钱和时间、性能、培训和支持、测试、部署、制造等），进行设计集成和系统验证。 系统工程将所有规程和专业团队整合在一起，形成了一个从概念到生产，从生产到操作的结构化开发过程。系统工程既考虑所有消费者的业务需要，也考虑他们的技术需要，其目标是提供一个满足使用者需要的高质量的产品。International Council on Systems Engineering (INCOSE) 的成员已经就如何定义“系统”和“系统工程”达成一致。 2 模型驱动系统开发（MDSD）支持 INCOSE Consensus 的声明。它有助于管理设计系统的复杂性。为模型的任意一个特定层级管理细节的适当层级，是 MDSD 的一个重要组成要素。若干能够被描述为最佳实践的技术，被用作完成以下工作：
系统通过如下手段被实现：
现在，MDSD 插件程序已经可以被提供给 RUP。本文将探索 MDSD 的基本规程，包括建模层级、分解层级、以及 MDSD 是如何支持 软件工程协会的能力成熟度模型集成（Capability Maturity Model Integration ，(CMMI®)）概念的。 模型和抽象直观地，我们从抽象方面进行思考。无论我们是否意识到，该过程包括模型的使用——简单地描述，有时只存在于我们的头脑中；还包括分解——将事情分解为它们的组成部分。MDSD 通过在一个系统中不同的建模和分解层级的使用，将这样一个抽象的想法形式化。 在每天的生活中，我们使用抽象来帮助对复杂性进行管理。例如，当我们驾驶一辆汽车时，我们并不去考虑汽车内部的工作，将汽车想象为一个大的“黑盒”，它拥有一些主要的接口，包括轮胎、加速器和制动器。在这个理解层级上，我们隐藏了这些功能的内部实现，仅仅从外部考虑它们的使用（因此用“黑盒”来比喻我们看不到、不关心内部的细节）。这样做将汽车放置在驾驶者和乘客所使用的上下文之中。 另一方面，我们本地的机修工是从另外一个完全不同的抽象角度考虑问题。我们将整辆汽车想象为一个黑盒，而对于机修工而言，汽车表现为一个“白盒”——一组被查看、理解、修复或者替换的组成元件；每一个元件本身是一个黑盒。机修工最明白包括发动机、传动装置、制动系统等的各个组成部件之间的交互作用。模型、抽象和分解的层级允许我们不需考虑其内部的复杂性，思考大的系统和子系统以及它们之间的关系。 分解的层级“分解的层级”是指系统各元素在那一个细节的层级上被考虑。在上面的例子中，机修工在一个比汽车拥有者更低的分解层级上考虑汽车；如果机修工将汽车的某个组件交给一位专业人员来修理，那么该专业人员就将在一个比机修工更低的分解层级上考虑那个组件。 在任何给定的分解层级上，都有一组从黑盒角度考虑的逻辑系统元素。这些元素在那个分解层级上被当作黑盒来处理。它们其中的白盒元素只有在下一个分解层级中才会被考虑。 因此，在模型中选择什么分解层级就决定了建模器选择暴露什么系统元素。依次，这个决定的部分依赖于谁将成为这个分解层级上的听众。我们可能都看到过在一个高层级听众面前暴露过度细节的缺点。在一个给定的分解层级上被暴露的系统元素应当被听众所认知，实际上，应当以他们所熟悉的形式被命名。 例如，如果我们向抵押公司的部分领导和业务功能所有者发表演讲，就不应当包括诸如模型中信息操作者和数据库管理者这样的元素，相反，应当包括比如贷款发源、信用和可接受的标题之类的元素。 在考虑分解的一个层级时，有以下三个重要的因素：
这些因素将在下面被详细的讨论。 在开发一个复杂的“系统中的系统”模型的过程中，无论它是用于一个产品、一个企业级的 IT 开发项目，还是一个新的业务单元，主要的挑战就是指出层级的正确集合，并通过它们表达该模型。在 MDSD 中，我们识别四种模型层级，每一个层级都有着不同的目的：
上下文模型层级，包括分解的顶层或者企业级，允许行动者和其他外部系统看到该系统使用的上下文。这一层级所表达的区域往往超出团队的控制。例如，如果我们要对一种新的交通灯进行建模，我们可能希望从全市交通系统的层级开始，以便我们能够将交通灯置于它的上下文中。于是，全市交通系统就将成为我们模型的企业级、0层级和起点。这将成为上下文模型层级的部分。一个复杂的系统在上下文模型层级中拥有不止一种的分解层级，但是在实践中，通常只有一种。 分析模型层级详细描述功系统的能性、逻辑结构和分发。在这一层级上，我们创建逻辑元素、分发元素和系统功能性的收集，并且对它们的交互作用进行建模。这种方法的独特性在于这些交互作用并不是孤立存在，而是从系统的高层使用中获得的。分析模型层级提供了实际设计的一个抽象。没有人从分析层级上设计或者建造。在上面全市交通系统的例子中，分析层级可能包括诸如交通信号、交通探测、中央控制和过载控制等系统元素。 在分析模型层级中，我们考虑为黑盒元素的逻辑和分发元素，是由硬件、软件、人员和信息结合而成的。它们小可以小到一个单独自动实现的功能，大可以大到一支军队。我们将它们选作体系结构中的元素，以便我们能够思考它们的交互作用和责任。创建层级的数量依赖于系统的复杂性。 设计模型层级捕获了“可设计的”各个元素之间的交互作用。在这个模型层级上，各个元素通常都是同质的；也就是说，它们可能由硬件、软件或者人员组成，但并不是这些元素的一个结合。通过 MDSD 方法，我们将为这些元素指派负责特定操作的责任，设计者将使用这些规范来创建元素。 如何设计处理依赖于元素的类型。软件元素能够使用 UML 和用例实现（一种同 MDSD 非常类似的方法，但是被应用于软件设计层级上），创建软件的技术设计。一个电子组成要素的设计更像是被表达为一个示意性的图表，“人员”元素可能使用有组织的图表和技巧列表。 实现模型层级处理设计模型层级中被表达的元素如何在现实世界中被创建。对于软件来说，包括代码模型、实现、DLL 等的结构，而对于硬件来说，可能包括电路布线、电路板布局等。 在 MDSD 中我们首先关注上下文和分析模型层级，这是因为我们的主要目的就是在上下文中理解系统，分析整个系统的行为，并且通过设计-建造团队安排工作的实现。这些设计-建造团队可能是用 RUP 进行软件创建，使用其他专门规程的方法进行硬件设计和人员设计。 我们进一步考虑一下黑盒和白盒透视图之间的区别。“黑盒”和“白盒”是指处理一个系统或者系统的某一个部分时所采用的透视图。采用黑盒透视图是指，我们忽略系统的内部工作，仅仅关注同该系统进行的交互作用。大多数人对于电视机就是采用这种透视图。他们不知道也不关心电视是如何工作的、里面都存在那些组成要素，他们所做的只是通过输入（遥控器、电源等）和输出（屏幕和扬声器）来同电视进行互动。采用黑盒透视图就是将注意力仅仅放在输入和输出上面，而隐藏或者忽视所有的内部细节。 改变电视频道的操作将被简单的描述为：观看者按下‘+’键并且电视改变了其当前的显示。请注意，这里并没有提到屏幕或者调节器，这是因为它们都是内部的系统元素。 另一方面，白盒透视图包括系统的另外两个方面的信息。除了输入和输出，白盒透视图还描述了：
以白盒的顺序进行描述，改变电视频道的操作将指定：观看者如何按下遥控器上面的‘+’键，遥控器如何发送一个红外线信号到电视上，电视控制接口如何通知调节器转换到另外一个频道，以及显示控制器如何将新频道的图像显示出来。请注意，采用一个白盒描述并不意味着系统被完全分解到它的最低层级元素。白盒描述依然包括黑盒一样的抽象。“电视控制接口”就被视作一个黑盒来处理。在一个更低层级的分解中，它还可以进一步被描述为它自身的组成要素。 黑盒和白盒属性并不是一个元素的内在特性，注意到这一点非常有用。也就是说，并不存在“黑盒元素”或者“白盒元素”。只存在黑盒和白盒透视图，并且在 MDSD 的整个建模过程中都被我们所使用。 一个分解级别最本质的方面就是它所暴露和隐藏的交互作用。由于一个分解级别中的每一个元素都是从黑盒的角度被考虑的，所以显示出来的只是它们同系统参与者之间的交互作用。这些元素内部子元素之间的交互作用则被隐藏起来。 一个有趣的例子来自近期一组人员建模一个商业航行器。在分解的一个特定层级上，航行器表现为一个元素，并且被描述为包括机身、所有板上系统以及机组人员。由于所有这些都被包括在黑盒指定的航行器中，在这个层级上该模型不需要指明任何内部事物。在描述乘客如何开始他们旅行的时候，该模型描述如下：乘客被问候，并且被引导到他们的座位上。虽然听起来很奇怪，但是这是描述这一行为的唯一方法。由于机组人员被看作是航行器的一部分，所以机组人员问候乘客就必须被描述为航行器问候乘客。实际上，这是一种有价值的方法，因为究竟是让乘务员问候乘客还是让自动检票器问候乘客的设计决定，在这个分解层级上并没有做出。 与此同时，一个分解层级上被强调的内容就是被识别元素之间的交互作用。在上面的例子中，就是乘客和飞行器之间的交互作用。那一个交互作用是重要的将成为决定使用什么分解层级的一个主要因素。将飞行员引入到我们的商业飞行器中。飞行员是属于飞行器系统的一部分呢，还是系统之外的一部分？这两种选择都是对系统建模的完全有效的方法，但是到底选择那一个，取决于那一种交互作用是重要的。如果重要的是飞行员如何同飞行器交互——也就是将飞行器当作一个黑盒，使用整个飞行器的接口——那么在这个层级上就把飞行员当作一个独立的实体为好。这将允许我们描述飞行员和作为黑盒的飞行器之间的交互作用。另一方面，也可以将飞行员和航行器合在一起作为一个系统元素——因而强调控制塔和包括飞行员在内的航行器元素之间的交互作用。出于某些原因，这可能是一种更好的方法。如果我们在设计航行器，那么我们可能对航行器作为一个整体（包括机组人员），如何同诸如控制塔、乘客等外部元素进行交互作用更加感兴趣。 这可能会考虑让飞行员同航行器内部的元素或者子系统进行交互，而不是同整个航行器进行交互。因此，我们将飞行员作为这个较低分解层级上的独立元素，最为许多独立元素中的一员。 实践中，判断在您的体系结构中将其设置为什么元素主要取决于所在领域中的经验。选择这些元素是设计系统体系结构的一个关键部分。 与 RUP 的集成MDSD 尚没有作为一个独立的规程被添加到 RUP 之中，它强调团队的统一本性，以及过程的统一本性。 没有 MDSD 插件程序的 RUP 是软件工程的一种方法。具备 MDSD 插件程序的 RUP 是系统工程的一种方法，它用于软件工程（通过 RUP），然后成为一个子集。 默认的 RUP 规程（业务建模、需求、分析和设计、实现、测试、配置）和支持性规程（配置和变化管理、项目管理、环境）在系统工程中有着同软件工程一样多的结构部分。MDSD 添加了新的任务、产物和活动，并且修改了某些已经存在的地方，从而为生命周期开发的更广范围和系统工程的额外关注提供支持。 系统工程在 RUP 网站上并没有被明显描绘成一个独立的规程。然而，包含现有 RUP 的 MDSD 规程是系统工程生命周期的一个过程。 理解 MDSD 插件程序被连接到 RUP 其余部分的方式同样非常重要。MDSD 期望系统由子系统组成，子系统再由更小的子系统组成。系统，在 MDSD 的上下文中，被定义为和用于处理系统的系统。 具备 MDSD 扩展的 RUP 可适用于层次系统中的任何层级上，包括最低层级，在这一层级上，至少对于软件而言，子系统的行为是通过软件对象（和链接）的协作被实现的。请注意，从开发人员层级的角度来看，子系统的开发努力就像整个系统开发的过程需要：也就是说，它需要一个启始阶段、精化阶段，等等。所以，如果您查看整个系统的开发计划，您将发现 RUP 阶段顺序，然后看“进去”的话，您将发现许多 RUP 的发展或者生命周期，为每个子系统都提供一个。 顶层活动是从各个低层级累积得到的。在每一个层级上都有需求、设计和其他活动，并且伴随着独立的逻辑计划。这样做允许我们简单的描述过程，但是仍然能够通过 RUP 生命周期的递归程序，建造十分复杂的计划。然后在任何一个层级上，您可以为您的目的选择活动、任务和任务中的各个步骤。 用于开发的 CMMIMDSD 支持 CMMI-DEV v1.2 过程模型，它描述了系统工程和系统工程师的特色： “各规程间的方法掌控着将一组消费者的需要、期望和约束转换到一个产品解决方案，并且在产品的生命周期始终为该解决方案提供支持所需求的全部技术和管理的努力。（请参见“硬件工程”和“软件工程”） 这包括技术性能测量的定义，专门面向一种产品体系结构的建立的项目集成，以及支持生命周期过程（平衡花销、性能和时间对象）的定义。” 3 一个系统可能包含硬件（计算的和非计算的）、软件和工作人员——交付时需要使用户具备操作能力，它本身也要求支持系统。系统工程不仅必须考虑产品的规范和创造，也必须考虑该产品的“在职期间的”支持（例如维护），确保它的持续效用。 系统的这个视图扩展了 RUP 核心中的视图，在那里“系统”就是软件和计算性硬件运行的环境。此外，大多数 MDSD 应用程序都是大型的开发，其中被分解的子系统都足可以被看作是一个复杂的系统了。这意味着 RUP 或者 MDSD 能够被再次运用到它们的开发过程中。 系统工程过程能够处理那些十分复杂和大型的系统，那些系统要求将各种规程的方法应用到它们的建造、配置和支持中。在 The Rational Unified Process for Systems Engineering 白皮书 4 中描述了用作 RUP for Systems Engineering (RUP SE) 开发的动机。作为 RUP SE 的一个发展，MDSD 扩展了过程模型，从而能够处理规模和复杂性问题（使用者的需要和需求）、服务质量、以及系统工程师所面对的其他工程学特性。 MDSD 插件程序同样吸引系统开发项目管理者以及项目分析和规范、系统体系结构、实现和测试等相关人员的兴趣。 注释1 INCOSE Systems Engineering Handbook，INCOSE-TP-2003-002-03.1，2007年8月。 2 了解该声明的完整信息，请参见 http://www.incose.org/practice/fellowsconsensus.aspx。 3 了解该引用材料的完整信息，请参见 http://www.sei.cmu.edu/cmmi/faq/cov-faq.html 上的 CMMI 页面。 4 Rational Unified Process for Systems Engineering，Murray Cantor，Copyright IBM Rational Software，2003。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
