text: 前言：在即时软体设计上，SDL与UML的使用分別面临各种不同的难题。SDL-RT得利于C与SDL的完整性，另一方面又具备UML易于了解的视觉化。因此，一个以SDL-RT为基础的工具，便可以解决SDL与UML两者不能同时兼顾的重重限制。
  此外，某些即时概念如信号(semaphore)与指标(pointer)并未包含在SDL语言中，因此，SDL发展者开始在SDL的图表中写入C，以填补此部分的缺点。又因当时市面上并未有任何支援SDL与C混合写成的工具，因此使用者必须自行撰写Ccodegenerator，以从SDL与C混合使用的图表中匯出程式码。
  由上述所提到的问题看来，我们不难发现SDL开始被广泛地使用。这也就是为什么包含UML特点的SDL-RT能够解决SDL语言与生俱来的缺陷。
  即时与嵌入式软体以即时作业系统或排程为基础，基本构成元素为任务(task)。同时执行好几个任务(task)便可完成一个基本的功能用途(function)；好几个功用同时运作便可以完成更复杂的功用(function)；直到最后完成整个应用(application)。也就是说，SDL的架构能够在功能方块中聚集任务(task)，接着在更高阶的方块中聚集所要执行的功用(function)，一层包一层，直到完成整个系统。这样的图形化显示架构能够完美诠释任何即时(real-time)系统，亦可完整描述系统中不同功能间的沟通介面。
  SDL的有限状态机很适合透过图表的方式来描述这种系统行为。从’92版开始，SDL在所有图形化阶层皆使用物件导向，所以建立软体元件专门的函式库是确实可行的。
  理论上，SDL似乎是针对即时系统规格与设计的最佳语言，但技术上的执行却相当困难。当涉及实务设计，因为那些操作ADT的语法是被定义用以制定协定规格，而不是设计协定，因此SDL的抽象资料型态(ADT)将变成设计者难以跨越的栅栏。此时，软体设计者将陷入困境，他们不再拥有传统程式语言的精确性，如C，并且市面上并沒有SDL编译器或交叉编译器，因此当在Target上实行SDL系统时，C或C++的程式码产生都将会是必要的。然而，ADT的基础概念无法直接转译成C或C++，某些特殊的运算子的产生，将会导致程式码无法使用。
  此外，整合前人所遗留的程式码也是一大麻烦，因为SDL与C/C++的资料型态不同，需要重新建立两者间的沟通桥樑，况且，当需要将SDL系统所产生的程式码整合到RTOS上时，某些SDL的语意概念并无法直接支援。
  我们可以看看下面两个简单例子：当将RTOS的优先权概念实施在任务(task)上时，SDL则将优先权交付给讯息(Message)。SDL语法认为无论任何时候，即使RTOS的执行被打断，自动切换也不能被中止，尤其是在切换不同优先权的任务时发生系统唿叫。此时为了保证产生的程式码能够如同我们所预期地运作正常，系统会自动建立SDL虚拟机，但虚拟机使得程式码与Target间的整合变得非常难以处理，并且根本无法存取使用某些RTOS服务。这一切灾难都是由于SDL中并不存在信号(semaphore)的概念，但偏偏信号的使用在即时应用程式中是最典型的同步机制。由于SDL的起源是针对协定如何与远端实体进行沟通，因此信号(semaphore)的概念在当时并不需要纳入考量。
  基于上述理由，为了要实行SDL中所描述的系统，工具将会变得非常难以制造、非常昂贵，并且需要很长的训练时间，再加上超级棒的技术顾问，才有办法使系统在Target上正常运行。最后终于，一切问题都解决了，我们才会发现：使用图形化语言真是一点好处也沒有！
  造成这样情况的主因是，软体开发者希望坚守SDL的标准，无论我们已经看到哪些必然会发生的技术问题。因此，SDL使用者开始在SDL图表中写入C，并打破SDL语法以符合未来技术。但既然商用工具无法支援C与SDL的交替使用(因为无法符合公定标准)，这一批人何不发展他们自己的工具链呢？这也就是为什么Alcatel、Nokia、Nortel、EADS和Sagem这些主要的电信制造商都开始发展他们自己的Ccodegenerator，以从SDL与C混杂的图形化设计图中获得可用的程式码。然而，第一版的SDL-RT就是看准了这样的需求而发行的。为了扩展这种语言普遍使用到所有即时应用程式中，SDL-RT也加入了图形符号来处理信号。
  UML图表与设计之间薄弱的关联性导致两个不断重演的问题：UML记号与最终程式码之间的同步，以及缺乏组织架构以驱动发展程序。上述问题显露了UML成功的事实，是由于软体发展团队依旧继续做他们过去所做的，但使用这个语言来将程式码文件化。这种做法的好处其实是非常有限的，这也就是为什么某些大公司决定停止使用UML。在标准1.x版中所包含的九种图表中，即时系统仅使用类別图、序列图，以及状态图。虽然UML基本是一个画图的工具，程式码产生的能力很有限，但对业界来说远比SDL工具负担的起。
  UML使得技术普及，但不可否认许多大型开发团队密集使用UML的经验，最后都是以失败收尾。从上述情况看来，这些工具产生在Target上可运行的低效能、无臭虫大型程式码，几乎指向同一个问题：在即时与嵌入领域中，使用一个完全物件导向的传统方法真的是可行的吗？
  这样的问题是很难给一个直接的答案，但是显然物件导向的发展能够成功地针对系统模式的重用性(re-use)，提供有效益的方式并纳入资料库的组织元件。再说，UML的市场力量太强大，因此SDL必须针对自己身为图形化塑模语言的地位重新定义。最新的SDL版本为’2000，并且将UML的类別图整合进来，为将来与UML2.0整合而铺路。为了针对各种应用领域来定义专用的设定档(profile)，新版的UML主要的目标是支援MDA(模式驱动架构，modeldrivenarchitecture)。
  反观SDL这边，先不管软体商们一开始的承诺，最新版的SDL语言依旧沒有实行到任何一个工具中。一般来说，因为SDL的复杂性，导致大部分的使用者倾向使用UML－即使精确性较低，也完全不为SDL所动。于是，SDL论坛开始成立一个特別小组来，将重新定义和简化SDL的特性，并且在SDL中定义UMLprofile。此时，SDL使用者仍然使用’96版。
  SDL-RT2.0版整合了UML的类別图与部署图，不但可补足SDL的图表显示，亦可保持其在不同表示法中原有的一致性。UML2.0也整合了SDL中现有的特点，像从区块图到结构图，以及MSC到序列图，也可以定义专门领域的设定档，但不幸地，并沒有针对标准的即时设定档。因为那些在OMG拥有投表权的人员职务调度，主要业界公司都质疑这样的设定档到底有沒有标准化？
  然而，第一版的UML2.0目前已经上市，新标准的最初目的是为了简化程式的移植性与可读性，但每个制定者都只专注于自己专用的设定档，而使得目标并未达成。这些设定档不适合共用，工具本身也很难提供使用者自行修改设定档，因此最后市面上充斥一堆各种版本的UML2.0工具，对使用者来说，程式码的阅读与移植比以前更加困难。
  无论工具本身是以SDL或UML为基础，规格制定者们内心都有一个预言：透过研讨会和广告，并用他们的语言与所花费的精力来证明他们是对的。这样的行动引起的许多技术狂热者，并且他们再也无法听进其他人的技术建议，直到技术实务将他们又带回了最初的思考，但代价是什么？多想想，我们所需要的就是像SDL-RT这样的工具，能够透过工业用途与理想的启示，提供实务的解决方案，而不须忽略目前的趋势。
  这就是为什么使用者需要把某些UML图表、大部分SDL图表，以及标准程式语言C/C++放到同一个一致性的架构中：目的就是为了针对即时与嵌入领域，取出各种不同语言的所有优点，缺点都丢掉。为了能够重复使用这些系统图表，而不须使用专门的工具，所有的资料都会储存在XML档案中。抛开语言本身不谈，软体工具的品质必须好到足以说服使用者，虽然开发团队的目标无法与现有标准一致，但SDL-RT可以，并且带给系统设计最佳的品质与效能。(本文由皮托科技股份有限公司提供，作者:EmmanuelGaudin,PragmaDev译者:林舜英。)