编辑推荐: |
本文主要介绍UML2.0的一些结构,这些结构将应用于嵌入式的开发,希望对您有所帮助。
本文来源于www.telelogic.com,由火龙果软件Linda编辑,推荐。 |
|
尽管统一建模语言,也就是UML语言从1997年被承认以来在软件开发者中得到普遍认可并且得到了巨大的发展,当把它与一些先进的技术,如基于构件(Component)的开发来对比,UML语言有些显出不能与时具进的情况。进一步说,有更多的愿望把UML应用于一些并不是UML开始目的的领域,例如硬件、交互仿真等领域,而在这些领域UML并不很好能应用与其中。由一种因素是尽管在高层的抽象水平看、偏向把UML作为具有更多功能的编程语言,并把UML转化为可执行的描述系统功能的语言的趋势。
所有这些方面共同促使OMG组织——此组织拥有并进行标准化UML——开始了对UML语言的巨大修改。目前正在制订中的将于今年年底完成的这份修改,目的就是规范下一代的语言——UML2.0。一些团体已经并且还在产生一些建议,这些建议将会融合入新的规范中。UML Partners组织包括了许多的UML工具提供商和大的用户:Alcatel, CA, ENEA, Ericsson, HP, IBM, I-Logix, IONA, Jaczone, Kabire, Motorola, Oracle, Rational, Softteam, Telelogic, Unisys,和WebGain.
UML2.0计划:
UML2.0的发生并不是偶然的,是被基于常年的用户和提供商的需求得出的经验所驱动的。这些用户与工具供应商使用UML的当前版本,UML1.X。同时语言的设计者被鼓舞从其它成熟的建模语言借用有用的思想,这些语言例如SDL和MSC。为使我们更好的了解这次改动的目的,让我们检查一些重要的需求。现在这种需求中,语言的可扩展性与精确性将频繁出。
UML最开始是为了面向对象的开发所设计,但是目前有范例表明UML正朝着基于部件的(Component-based)开发方向发展。 其主要原因是诸如COM+、EJB等部件框架(Component frameworks)技术的广泛使用,近来的诸如J2EE和.Net企业框架(Enterprise frameworks)技术更加加快了这种趋势。并且,嵌入式开发领域也提出相似的需求。改进提高对这类模型的支持是UML2.0中极为重要的发展。
另外一个极高的目标是简化语言。这并不是意味着语言本身会更小。尽管有使用户疲惫于语言很少被使用到的实事,可能在新的语言中更多的结构将被引入,而不是被减少了。这种简化的目的是使语言更加直观和更加贴近实际。例如,不同种类的结构图(Structural Diagrams)将被统一,不同种类的行为图(Behavior Diagrams)将会被更好的结合。
更大的包含了对行为的细节设计是可能引入更多结构的原因之一,例如包括对行为与状态的精确描述,如分配,决定,循环。采用目前的UML,一般使用代码(Code)的形势描述详细行为,此类代码被加入生成桩程序(Stubs);或者说是在模型中被增添到相关位置的代码框架,这些代码框架被提供作为详细行为的描述。这些代码本身是不可执行的,但是需要一种编程语言和编译器完成执行目的。这种解决办法取决于工具所限制。许多工作进入到UML对行为语义的描述中,这些语义是使语言可实现化的基础,例如,在UML中不通过结合编程语言代码表述全部的系统功能。这表明把UML直接编译为目标代码开始变为可能,但不是实际的实用。一个更加实用化的方法是首先把UML模型编译为代码,使用在UML中定义的配置和实现信息,然后编译代码。在这种方式中,代码首先被作为中间代码对待,类似于P代码,然后不必通过任何办法改变。注意,采用这种方式时,UML2.0不是只与平台无关,但仍然和目标语言独立。结合这些功能和其它的目的,例如定义UML用于测试,给予了在早期实现时对系统的验证巨大的功能。
从行为的观点看,仍有一些其它的必须解决的要求。例如,行为图(Activity Diagrams)从状态转移图(State Chats)中分出,并基于Petri网图,其目的是对工作流和数据流建模。顺序图(Sequence Diagrams)和状态机(State Machine)将会改变成更具有扩展性。在使用顺序图(Sequence Diagrams)方面,最基本的是加强其表述需求和描述测试例的能力。
最后,新的UML语言将被期望用户能被适配到专门的领域,例如表示实时,诸如表示时间和执行时间。为了这个原因,客户化UML的产生轮廓(Profile)的机制将被特别强调。当把UML客户化到不同的领域时,轮廓(Profile)是一个非常重要的角色,特别在表示行为时我们可以期望轮廓(Profile)是诸如C++, Java, C等特定的编程语言。此行为的语义并不强制特别的标注方法,提供商们被期望提供它们自己的标注方法,并把此标注方法置于行为语义之上,这点很像.Net的一般语言描述的设置。纯软件语言并不只是适合作为轮廓(Profile);系统级别的设计语言诸如System C 和Sepc C是成为轮廓(Profile)的基本候选项,这点如同在硬件语言中的VHDL和Verilog的情况一样。
建议
因为此篇文章并不会涉及到UML2.0的完全描述,我们将专注于建议的一些结构,这些结构将应用于嵌入式的开发。基于部件(Component-based)的开发方法一个明显的部分是处理模型设计,在这些模型中,通过清楚的定义接口和通信通道,用户可以按级别分解一个系统为若干的子系统,或者按相反的方式把若干小的模块合成为大的系统。通常实现此种从上之下或从下之上的方法有使用SDL语言和使用ROOM等方法。我们将着重探讨在UML2.0中融入的观点(当然注意到这种标注方法是初步的并且会改变的),而不是探讨这些概念起到的作用。这些概念包括起到很大作用的块(Blocks)、进程(Process)和封装(Capsules)等。
在UML中应用最为普遍的是类(Class),在嵌入式开发中我们一般区别主动类(Active Class)与被动类(Negative Class)。主动类(Active Class)控制自己的行为,而被动类(Negative Class)只能执行于其它的执行实体如活动类。每一种类都可以描述内部的结构(Internal Structure)。内部结构(Internal Structure)被用于隐藏和用户与类无关的信息,而这些信息又和系统设计员和实现员紧密相关。在另一方面,和用户相关的信息可以通过接口(Interface)描述。区别开被提供的接口(Provided Interface)和被要求的接口(Required Interface)非常重要,在被提供的接口(Provided Interface)中描述被类(Class)所执行的服务,在被要求的接口(Required Interface)中描述在其它实现中被期望的服务。在我们更加深入之前,我们先看一下在UML中描述类(Class)将被保存的机制,和在此描述的结构被扩展的机制。
类进一步将具有端口(Ports),端口作为互作用点并且在UML提供的类封装的“壳”中提供开放的门。通过类封装(Class encapsulation),信号(Signals)或操作(Operations)能被发到类(Class)或从类(Class)发出。如同类(Class)可能有接口一样,端口(Ports)能同样的有接口。这种端口(Ports)都表示当类(Class)的实例产生后分别可设定位置的类。图一是一有端口(Ports)和接口的活动类(Active Class)的例子。通常,这种类对软件和硬件的建模是非常有用的。
图一:带有端口(Ports)和接口的类(Class)
一个类的内部可以使用不同的形势。在最简单的情况中,操作是类提供的实现。这种操作的行为可以通过不同的方式实现,例如通过定义状态机或描述功能的行为。在更复杂的情况中,分等级的分解被用于描述类的内部结构,在此结构中其它的类提供其功能的部分。如何定义类和其它的类互相操作非常重要,因为它们可以不同的方式连接并依赖于它们应用的环境。如何通过端口(Ports)和连接器(Connector)表示类之间的互操作,在什么地方可以简化描述从特定的类(Class)和连接器(Connector)中产生的实例。这些类(Class)和连接器(Connector)被用于连接这些部分,并表明在实例中间有连接关系。如果某部分的类(Class)有端口(Ports),连接器(Connectors)被附加用于通信此部分中的端口(Ports)的联系。连接器(Connectors)描述了内部的通信路径,同时可以被用于在部分和环境周围的类的端口之间。
当一个封装类的实例被产生时,通过部分表述的被封装的实例同时被产生。对每一个部分,可能给出一个初始势的集(Cardinality)用于表示,当封装的类被示例时,多少的类的实例将要被产生。因为这些部分的多样性,生成或删除部分实例是有可能的或是没有可能的。同样的,当一个部分的实例被破坏了,封装的一个实例也被破坏了。注意到在内部结构使用的类都可能有内部的结构。这样,处理任意大的分解结构是有可能实现的。图二是一个具有内部结构的活动类的例子。
图二:一个具有内部结构的类
在此描述的结构可以使基于构件(Component-based)的开发达到高的可扩展性和重用性,并且在近十年的工业项目中,尤其是电信、自动、航空航天领域,已经被证实。注意甚至在UML相关的被限制的领域,仍然有很多我们没有展示的功能。
未来
尽管UML2.0的建议还在初始阶段,还有很多的工作要做。其中一个语言设计者的基本任务是如何在不影响工作的时间和质量的前提下,综合众多的组织提交的建议和融合这些建议来产生OMG的共同建议。
尽管通过UML2.0将不仅大幅度提高对系统的描述,还能提高对倾向硬件的嵌入式和实时系统的定义,我们如何正确的使用还是很重要的。因为这项工作正在进行中,感兴趣的人可以通过浏览http://www.u2-partners.org 来得到相关信息并且加入其中。在此网站上可以下载UML2.0相关建议的最新的情况,查找相关连接,并且加入讨论组。
|