IBM杰出工程师Bran  Selic

领域热点主题概述

    【IT168现场报道】今天下午主要是三大块，第一块解释一下问题背景，什么是嵌入式系统，什么是工业系统，下一步谈一下IBM  Rational的方面，最后介绍一下我们相关的工具架构。所谓的嵌入式系统，大家看到的工业系统是由软件控制管理硬件的由系统构成的系统。这是嵌入式系统应用的主要的一些领域，航空航天、电信、汽车等等。所以我们在嵌入式系统开发的方面到底有哪些问题呢，第一个是有关需求方面的，需求可能是现在大家知道太复杂了，可能有一些需求写的不够完备，有的可能太过于完备，以至于它们之间太矛盾了，或者之间发生了变化，是我们经常遇到的问题。
   

    另外一个问题就是我们在开发嵌入式系统过程当中，运用了不同的开发流程，不同的工具，涉及到软件和硬件，有的时候想知道硬件系统设计发生的变化，对软件发生的影响，这是我们开发的时候遇到的难点。那么另外在开发嵌入式系统的时候，我们必须处理很多很复杂的一些因素，比如说要处理容错机制，怎么样处理这种分布性的要求等等，还有响应时间，这些给我们的开发带来很大的风险和困难。还有治理的问题，即便是在英文单词Governance里面也是一个很复杂的概念，下面会给大家做一个详细的解释什么是Governance？另外我们现在开发越来越趋向于分布式的团队，这家空客的A380飞机设计的时候是法国和德国两个分布式的团队开发的，他们运用的工具和方法不兼容，导致这个项目的一再延误，导致上亿美金的损失。这是我们开发软件的现状，我们做不同的工作使用不同的工具，硬件可能用CAD工具，软件还有软件开发的工具，项目有项目管理的工具，它们之间的耦合非常脆弱，它们之间可能进行用一些文档进行耦合。因为它们之间的耦合很松散的，你的信息从一种工具转入到另外一种工具的时候，不可避免的会引入一些错误，值得指出的如果能够自动化的话，对这个方面有很大的改善的。所以这里给出Governance治理的一个定义，治理就是在公司企业内部建立的一整套机制，由它来保证公司日常运营中做的任何工作，跟公司的策略、目标相一致的，那么并且要保证我们日常所做的工作，要符合公司的一些规范、一些法规等等。那么我们这边要讨论的就是Development  Governance，它指的是怎么样治理整个开发的过程，我们的开发的话必须跟公司的策略相一致的。
   

    所以接下来我们看一下策略方面的，在这里把我们开发过程分成几个层次，最下面的这个层次是非常具体的一些开发活动，开发一个组件也好，开发一个模块也好，这里涉及到的个人用到的开发工具。所以这些方面看到的工具是两类，电子电路的设计，机械的设计，另外一个方面我们看到的软件部分的设计工具，Rational是涉及到在软件方面的领域。当然我们要成功的开发一个嵌入式产品，光看软件或者硬件是不够的，我们必须把眼光上升到一个层次，把整个嵌入式在系统这个级别上升到一个层次。但是作为一家企业来讲，你光开发单个的产品是不够的，你要上升到更高的一个层次，产品家族，产品组合这个层次，这个层次上除了开发产品之外，还要关心市场的需求等等，很多方面的因素。所以我们开发一个嵌入式产品的话，涉及到所有的三个层面。所以我们需要一整套的工具管理整个的开发过程。所以IBM  Rational专注的领域是红框的领域，我们提供工具、服务、方法。至于在我们不涉及的这个领域，我们的策略就是我们想办法把我们的工具跟其他的工具来进行集成。

    所以这边列出的是我们针对这个领域的四个策略，第一是把我们可视化建模的优势引入到嵌入式的领域，我们的MDSD的嵌入式系统开发，第二我们采用标准的规范的一些流程和框架，第三我们采用开放的流程控制项目的风险，最后我们采用一些非常客观的评价手段评价我们的开发是不是做得好还是坏。下面我们逐点给大家详细地解释一下。其实建模的概念并不是一个新的概念，是一个传统的工程技术，建模主要的目的就是要把管理复杂度，把复杂的系统要简化，解决问题的时候，把你的注意力集中到一些相对简单的侧面上。所以建模主要的解决的问题就是复杂度的问题。模型就是抽象的，比较复杂的东西用一个简单的东西把它抽象出来。模型这个概念在软件工程里面是一个什么样的作用，这边举了一个例子，大家看到的是我们先设计一个状态机，然后我们转换成一个代码，就是这样一个Switch语句。在这个转化的过程当中，很容易引起一些问题，把这个Bug带进来。人在看这个东西的时候，可能对模型的认知更容易理解一些，这种转化工作有一个工具自动化的来做，可能更加有效。如果我们建的模型更加复杂一些的话，那么你在把它翻译成代码的时候，有一些问题，而且这个Bug的话就更多了。在这个过程当中，其实工具自动化的代码生成的工具可以扮演一个很重要的作用，在转换的过程完全是一个机械的过程。所以这就是我们引入模型驱动软件开发这个概念的一个原因。那么MDD这种方法的话，主要基于两种基本的原则。第一点就是我们要尽量地提高这个抽象层次，使得我们能够更加专注于描述问题的本身。那么第二点就是尽量地用一些自动化的手段、用工具帮助我们把高抽象度的模型转换成为比较具体的代码。这个模型相当于我们以前引入的第三代语言，高级语言一样，这种转换的过程可以很大的提高我们的生产效率。这里给大家举一个例子，一个主要的电信设备供应商，采用的模型驱动，开发的这种技术，它自动生成的代码达到450万行代码，这个自动生成的代码，在性能方面的表现可能比手工的代码大概正负15%的总偏差。那么生产力的提高的话，大概有关质量和生产力的提高，大概80%到200%之间。这里是一些其他的例子，从卡拉OK唱机到核弹的设计等等。我们把模型驱动开发这种概念从纯软件的开发进一步推广到嵌入式开发的这个领域。当你在设计一个模型的时候，实际上你设计的系统跟具体的实践技术是没有关系的。那在这个过程中，你所构建的模型，扮演的就是我们平时所说的文档的角色，这个里面我们用模型取代了这个文档，并且提供了一种更加自动化的开发过程。

    那么在这里就是我们谈到的概念就是系统模型，就是对你的目标系统的一个刻划，是独立于任何具体的实现系统的技术。那么这个领域有一种新的基于UML的语言叫SysML，已经成为新的建模里面的标准。如果你熟悉UML的话，这种SysML的语言跟它很相像，借用了很多UML当中的语言，像状态机，像持续图等等。这里所增强的部分第一在需求方面，它能够描述需求之间的关系，那么在另外一个方面，它可以描述系统的不同的模块之间的功能上的关系。所用到的工具就是从我们的工具叫ISA的工具，还有一个SysML，就可以做这种类型的设计。有关标准的话，早上已经谈了很多，我们也参与了很多标准的制定，并且我们的工具基本上都是满足这些标准的。那么在工具方面我们采用的是一个更加开放的策略，我们并不强调我们的用户把所有的工具集中到Rational平台上来，我们采用一个联合的方式，跟我们的合作伙伴一起合作来提高这种开发的能力。所以我们采取了策略就是跟业界一些最好的供应商来结成合作的关系，能够使他们的这些工具能够插入到我们的工具平台上来。
   
    观众提问：刚才的那张图下面的那块的模拟的，看起来的两个观点完全是不一样的，能不能解释一下到底有什么差别，或者以后做什么结合，还有以后的发展？

    Bran  Selic：因为刚才的问题是说在最下面的层次的话，我们平时讲的系统建模的话，主要在最下面的层次描述这个软件和硬件的驱动关系，至于跟上面的层次的关系的话，因为首先描述这种关系的话，是UML和SysML，都是用这种描述语言的话，可以很好的描述它们之间的关系，我们现在推荐的是Jazz的技术，可以更好地整合各种不同阶段的模型，可以很好地进行关联起来。在这次大会上，大家有很多次机会听我们谈到这个Jazz的新的技术，大家可以访问Jazz.net这个网站，可以了解更多的有关Jazz的信息。Jazz不是一个产品，是下一代的新技术的框架，它使得不同的开发团队可以很好地在一起进行实时的协作。Jazz的另外一个目的可以从项目开发的整个过程当中，更加有效地抽取一些我们想要的数据，通过这些数据可以更加客观的描述项目的状态和项目的进展情况。Jazz的另外一个作用就是回答刚才的问题，它可以很好的把开发过程当中，采用不同的工具，可以组建的话这些信息的话可以很好地进行关联起来。更重要的采用Jazz技术的话，可以使你的项目真正采用针对你这个项目的特定的工作流程来进行工作，并且它可以帮助你来监控在项目的进展过程当中，是不是按照这个流程来走的，有没有什么偏差。跟Eclips不同的话，大家看它是一个总线，你可以在上面插各种各样的插线，在上面又分了一层可以成为一个框架，这是理解项目的过程的，所以说你插入一个ISA模型的话，插入一个电路设计模块的话，就知道这个硬件设计怎么样的，可以在两者之间建立起关联。

    第三个基本点就是我们采用迭代化的开发流程来控制风险。那么迭代化开发跟传统的项目开发流程相比的话，传统的流程大家看上面这条红线，就是在整个项目周期中，一般来说一个项目开始的时候风险比较高的，传统的这种工作流程的话在整个项目过程当中，可能风险始终维持在一个高的水平，只有你做系统集成系统测试的时候，在那个时候会发现很多的问题，导致你的返工，迭代化开发的话，试图在项目的早期尽早把风险降低，从而使我的项目周期的话，大部分时间处于一个低风险的状态。我们采用的方法我们要做到的目的就是要尽早地看到哪里有风险，并且要对风险的严重性、紧急程度做出一个客观的预测。那么我们这里要介绍的一个方法，传统的方法就是一开始的时候，由项目的干系人来提出各种需求，然后在这个基础上抽取出系统的需求，然后逐步地细化，细化到概要设计、详细设计，是传统的瀑布式模型开发的过程。我们借用了刚才讲的软件开发里面模型驱动开发的方法，那么我们在系统需求这个层次，我们会首先把系统需求进一步细化，而且在这个级别我们来设计一个系统模型，在系统模型的级别，我们判断一下系统模型有没有很好地执行系统需求所定义的功能，同时在这个过程当中，我们会对系统需求来提出一些反馈，可能系统需求有不对的地方可以及早改正这些不正确的需求。并且在这个层次上，我们还可以找到及早发现一些关键的风险，并且及早地解决这些风险，不是在这些风险解决之前，就急着进入下一个层次的设计。所以你会看到这样的话一层一层的逐步地细化我的设计，直到最后得到我的实现。大家看到传统的瀑布式模型的开发到这边的直线，还有不同的层次的话做这个模型，及早地发现这些问题。最后一点是怎么样客观地进行一些对项目过程的评价。我们这里建议采用一些自动化的软件工具来帮助我们统计一些客观的评价数据，不是通过问某一个人而得到一些非正式的主观的一些答案。在这个过程当中，除了刚才提到的Jazz平台之外，除了帮助我们收集相关的数据之外，我们还可以称之为模拟的技术，可以使我们在模型这个级别可以模拟目标系统的执行，这里大家看到的是我们的一些合作伙伴提供的插件，使得我们能够去做这种模型级别的这种模拟的工作。或者你可以采用数学的方式，这里采用的技术已经被称之为MARTE的技术，已经在这个模型里面用数学公式表达的这种精确的描述，来帮助你描述这个模型。你可以精确地用一些数据来限制你的系统的一些性能的描述。所以这个里面举一个例子，你可以用 我们的RSD这个模型，在这个模型里面加入这些MARTE的限制性的描述，然后你可以由这个模型生成一个比如说排队系统，你可以模拟排队系统的模型帮助你来判断排队系统的性能到底怎么样。现在跟你的传统的开发方式相比，你原来在脑子里面来判断，你这个系统正确，大概性能怎么样，这里采用一些更加数学的和工具自动化的方式来帮助你做这个方面的判断。所以这是我们的工具架构的一个图，以前我们在Eclipse上面有一个插件，构建我们的平台，这个价值平台可以了解项目的数据，可以更好地整合不同的工具，以达到它们之间的联系。那么这里大家看到这个架构实际上是我们一直讲的SOA架构，这个里面都有一个SOA的接口跟它的总线进行互联，里面还有一个库，称之为语义链接，可以跟硬件模型关联起来，当任何一个部分发生变化的时候，会告诉你哪一部分受到了影响。

    观众提问：第一个问题刚才讲的嵌入式的开发在航空航天方面的运用是非常明显的，我想说一些模型化的问题，怎么样利用这个工具支撑这个模型，刚才讲的没有具体的，只是一种主意，但是现在对工业来说，如果实施的话比较关心这个问题。第二我们刚才说的IBM要收购一家公司，他们有一个产品，那么未来的发展会朝着什么样的方向发展。这也是IBM产品战略的一个方面。

    Bran  Selic：首先怎么样去做实际的开发，从方法论的角度来说，我们有Rup  SE这样的方法，包括刚才提到的模型驱动的系统开发的方法，来支撑怎么样把这些理念落到实处进行开发。另外有这样一本书，一起跟别人合写的一本系统的、有关嵌入式开发的一本书，大概两三个月就可以出版了。

    谈到第二个问题，我们为什么要收购这个公司呢，因为在工具的领域我们双方的认同是一致的，我们对工具发展的方向，一个前景的预测是非常接近的，所以我们决定收购这家公司，至于以后产品怎么样发展，因为收购还没有完成，所以有一些法律方面的限制，现在还不能探讨这个方面的信息。

    观众提问：我是做嵌入式系统设计的，我关心一个事后的问题，我的嵌入式系统已经完成了，因为在运用过程当中各种条件是不可预料的。一个系统的建设程度跟系统的运行之间有一个关系，可能这个系统运行着，但是非常依赖于一个软件或者硬件。这个问题怎么解决呢？

    Bran  Selic：基本上讲的跟我们介绍的方法可以解决一部分问题，我们强调的系统模型的设计，你在模型的级别，在正式的系统开发出来之前，可以利用MARTE的一种数学的方式，在这个方面进行运行，帮你及早地帮你找出逻辑运行方面的问题在一定程度上可以解决你刚才提出地问题。谢谢大家！