UML软件工程组织

使用UML和SDL设计并发通信软件系统
P S Kritzinger 等 著,车皓阳 译

摘要

本文所描述的案例研究的是并发通信系统(CCSs)的软件工程。我们使用最佳实践软件工程方法学来说明和设计VoIP系统,而后实现。方法包括统一建模语言(UML)以及规范和描述语言(SDL),对于特定项目也混合使用两者。

这里实现的VoIP系统,称作ChattaBox,允许用户通过语音以及其它一些功能进行通信。系统需求和静态设计是用UML图来进行的。动态设计最初也用UML来做,随后就转向SDL,使用Telelogic提供的工具来做。SDL设计的结果使用这个工具来验证。

最终系统要验证正确性、性能和可用性。它要满足工程过程最初阶段定下的所有要求,同时还要保持稳定,兼容协议。在工程过程自身完成评估之后,我们得出结论,软件工程标准对于CCS工程领域来说是非常重要的。更进一步,UML对于高层设计功能很有帮助,但不能充分提供协议验证。在软件工程过程中提出的最大的缺点就是不充分和易于出错的转换过程,那需要手工除错和人为干预,转换SDL图弥补了这一点。

本项目由CapeTown大学DNA实验室承担。DNA实验室与南非法国大使馆资助的INT(巴黎近郊)有一项正式的研究合作协议。这个项目还由国家研究基金(NRF)以及与南非西门子通信公司的合作项目THRIP资助,Telkom作为工业成员也参与了这个项目。

I.引言

在今天这个复杂技术构成的世界里,有效的软件工程过程对于开发软件制品来说十分重要。然而,软件工程领域仍然没有提出一种方法,适合开发所有类型的系统。本文关注于CCSs系统的工程设计。使用移动通信和网络协议的应用程序是这些系统最基本的一些例子。我们研究了一个案例,用以调查并发通信软件系统的工程过程。案例研究的主要目标是分析使用最佳工程实践和CASE工具创建这样的系统时,可能的软件工程路线。为了这个目的,我们设计并实现一套称为ChattaBox的VoIP系统。

起初,创建这个软件的基本需求是要支持VoIP通信[1]。但是,为了使它变得足够复杂,可以作为案例来研究,ChattaBox演化成了一个全面的工业强度的分布式应用程序。加入了象语音邮件和动态地址这样的服务。而且,我们还决定在ChattaBox系统服务器端应该支持负载均衡、安全和数据管理。

在这次案例研究的过程中,我们有效地组合了现有软件工程方法,用以构建复杂的软件系统。现有的设计方法有UML[2]和SDL[3]。而且,在这个领域中面向对象设计范型的有效性也同时得以检查。

而后提出了正向工程方法[4]。与这种方法相一致,规范和最初的设计用UML完成。之后,UML设计图转化成SDL规范,进行校验和验证。开发过程如图1所示。

为了实现正向工程过程,需要有一种方法把UML设计转换成等价的SDL规范。为了这个目的,我们布署了UML suite 4.5以及由Telelogic提供的SDL和TTCN suite 4.3[5]。


图1 使用UML和SDL进行正向工程

II 背景

在实际开发系统之前,要进行UML、SDL和VoIP中所涉及协议的背景研究。

A.统一建模语言

根据Booch et al.[2],UML是一种用于软件工程的图形化建模技术。最近这些年,由于面向对象方法学的研究兴趣逐渐增温,它的用途也变得日益广泛起来。自1997年11月11日起,UML已经由OMG组织标准化。尽管UML主要是设计用来辅助软件开发,但还是可以用它来对不同类型的系统建模。它的主要目标是方便程序员、软件工程师和客户之间的交流。为了完成这个功能,它提供了措施可以对软件开发生命周期的每个阶段,从需求分析到实现进行建模。

使用UML的一个好处是它提供了许多不同的图,这样对特定的系统就会持有许多不同的视图。UML的另一项正面作用是有广泛的CASE工具支持。

另一方面,正如以前提到的那样,UML主要的不利之处在于它没有形式化的语义。这使得仿真UML模型测试正确性变得很困难,而这也恰恰是CCSs工程主要关注的地方。

B.规范和描述语言

如Belina et al.[3]所述,SDL是一种形式化语言,可用于确认和描述软件系统的功能行为。它由ITU(国际电信联盟)标准化,SDL有图形格式(SDL/GR)和文本格式(SDL/PR)。

SDL最主要的长处在于其仿真和元级执行模型的能力上。使用这种语言生成的系统可以校验和验证。特别是,在创建并发通信系统时,可以在实现之前检测到错误。这是节省成本而且高效的。而且,从高层系统图到低级过程图,SDL图形成了细节层次。

SDL的一个缺点是它目前只有很少的CASE工具支持。进一步的缺点是,SDL图类型很少,因此系统就不能确定出足够多的视图。最后,SDL并没有提供需求规范。

正是因为这个原因,我们仅在ChattaBox系统设计的后半部分选用了SDL。下面会给出VoIP的详细讨论。

C.VoIP

VoIP由协议栈组成,设计它们是要在包交换网络上传送语音数据。声音信号是使用codec编解码器数字化编码的。而且数据被封包,在终端之间通过IP网络(LAN、Internet,等等)进行传输。

用于案例研究目的的VoIP系统涉及的实现有:实时协议(RTP)、实时控制协议(RTCP)、会话描述协议(SDP)和会话启动协议(SIP)。这些内容在[6]和[1]有详细描述。在VoIP系统的顶层,SIP是标准协议,用于启动涉及如语音[7]等多媒体元素的交互式用户会话。SIP与SDP联合使用,用于给多媒体会话过程[8]的参与者传递媒体流信息。

实际的语音包由RTP传输,这个协议通过单播或多播网络服务[9]为程序管理实时多媒体传输。最后,RTP由RTCP实现,这使得它可以监控数据传输。监控过程使得接收者可以检测是否有包丢失或补偿延时抖动的现象。VoIP中涉及的协议足够复杂,可以在CCS工程中全面测试UML和SDL的使用情况。

III 相关工作

组合应用UML和SDL引起了许多研究者的兴趣。Holz[10]觉得软件工程过程应该同时使用这两种语言。他认为UML适合系统的分析和早期设计工作,而SDL则更适合详细设计和充分高层实现语言。更进一步,他建议扩展SDL,包含UML的概念。与他同出一辙,Bjorkander [11]和Dimitrov et al.[4]也宣称应该组合UML的表达能力和SDL的一致性与语义。

而且,许多研究人员也曾经研究过把一种语言映射为另一种语言。例如,Selic et al[12]曾经借助一定的扩展把SDL映射为UML。与此相似,ITU发布了推荐标准Z.109,详细解释了如何将UML映射为SDL。

最后,两种语言的标准化组织扩充语言,包括了ITU最新版的SDL、SDL 2000的概念,并试图匹配SDL和UML。同样,OMG目前正在推出UML 2.0,它将包含验证UML规范的概念。

很明显,这两种语言都有各自的支持者,研究它们的组合方法将会有更广阔的空间。

IV 软件工程过程

为了进行案例研究开发的ChattaBox系统使用下面列出的过程完成工程任务。

A.需求分析和规范

软件工程过程的第一个阶段是需求分析和规范。一开始错误地理解系统需求可能会产生有缺限的软件。ChattaBox的需求使用UML用例图表示,用例图专门用于系统需求工程。这些图有三个组成部分:参与者(绘制成棒状小人)、用户与之交互的系统(绘制为盒/块)和用例(显示成系统模块中的气泡)。参与者可以是人或者是系统以及它们的组件。

在ChattaBox系统中,要确定两种主要的需求分组:终端用户需求和内部系统需求。

终端用户需求,正如上面所说的那样,指的是由ChattaBox提供给公众用户的功能。建立这些需求需要确定软件的所有可能需要的功能。ChattaBox提供的主要功能是使用户可以建立语音会话链接。另外,还确定了大量其它的功能需求。在图2中,用例图组成了ChattaBox终端用户的部分需求规范。

在这个用例图中,从用户的观点来看很容易看出ChattaBox需要什么。ChattaBox需要为每个用户保留一个帐户,提供登录设施。帐户允许用户保存个性化设置和地址簿。另外,软件要允许用户调用基本话务功能,例如选择或回复呼叫。还要提供状态服务,反映用户是否可以接收呼叫。

除了上面提到的基本功能以外,还要为ChattaBox建立高级的需求,包括语音邮件服务等。


图2 ChattaBox的终端用户需求

内部系统需求用来描述ChattaBox分布式结构中对不同组件的需求。每个组件必须给其它组件提供服务。这些需求也使用用例图映射出来。

B.设计

设计阶段开始于对ChattaBox系统架构的概括,这要使用UML组件图描述。这些图是显示高层通信以及组件和对象分布的好地方。


图3 概括ChattaBox系统

图3概括了ChattaBox系统的架构。大体上,这个系统由两个实体组成:客户和服务器。

ChattaBox服务器有三个主要的组成部分:

1) 远程服务器 – 这部分依靠微软的.NET远程基础架构完成抽象网络调用,使得用户状态变化和语音邮件这样的设施成为可能。注意为了验证的目的这个组件需要安全包。

2) 数据库 – 数据库组件管理数据的持久化。

3) SIP代理服务器 – SIP代理服务器负责转发SIP消息,它在会话建立阶段使用。

ChattaBox客户由下面四个部分组成:

1) 远程客户 – 远程客户与远程服务器通信,同时使用安全包验证用户。

2) SIP客户 – SIP客户发送和接收SIP消息,许可建立会话。

3) RTP – RTP组件处理实时语音数据,在两个ChattaBox客户端之间进行传输。

4) 语音处理器 – 语音处理器从通过RTP发送的声音输入流中捕捉语音数据。

客户和服务器验证使用对称密钥和基于X.509[13]的证书机制。

1) 静态设计:下一阶段关心设计结构和静态层面。这个阶段布署了UML类图。类图描述了系统中对象的类型和它们之间存在的不同类型的静态关系。它们也表明类的属性和方法,以及对象之间相关的关系约束。图4中给出了类图的一个示例。


图4 ChattaBox用户,VoiceMail Box和Voice Mail Message类

2) 动态设计:设计过程最后阶段要处理系统的动态行为。绘制UML交互和状态图是用来捕捉设计的这层因素。交互图是描述对象组如何以某种行为进行交互的模型。一种特殊类型的交互图、时序图都被用来捕捉单个用例的行为。时序图描述对象之间传递的消息,它使得设计者可以理解和把握整体的控制流程。对于并行过程建模来说,它们特别有意义。图5给出了时序图的一个例子。


图5 语音下载时序图

状态图描述特定对象可能会处于的所有状态,以及作为达到这个对象的事件结果状态会如何发生变化。我们发现状态图在描述跨越几个用例的对象行为中非常有用。图6给出了状态图的一个示例。描述大量交互对象的行为来说,它们尤为有用。但是,状态图及时序图的组合完整概括了设计的动态因素。

这个案例研究的主要目的是验证SIP协议实现的正确性,这样在设计阶段就关注于系统这方面的内容。

C.把UML转换为SDL

按照客户机/服务器模型划分,ChattaBox的SIP组件中完整的设计结果由两套类图和状态图组成。每套图都单独转化形成一个独立的SDL系统,它与环境进行交互。


图6 处理SIP消息的状态图

这个转换并不是个简单的过程,为了这一步,在UML中需要遵循特殊的语法。最初的类图和状态图,在它们适合完成转换之前,不得不修改数百次。例如,为了将UML类正确转换为SDL制品,要使用原型。

系统设计的客户机和服务器部分单独进行转换。一经转换,就会发现部分原始UML设计并没有被转化。因此SDL图必须扩展以保留它们的含义,同时在SDL中要保持语法和语义上的正确性。结果就需要详细了解SDL,对SDL图求精的过程是极度耗时的。

D.设计验证

在使用SDL描述ChattaBox中的SIP之后,它就被认为是完整的,并且认为与UML设计是等价的,验证就被执行。这些内容可以由Telelogic SDL和TTCN suite 4.3等仿真器和校验工具来完成。

仿真器允许分组给系统发送选择信号,并监控结果行为。对于环境发送的每个信号,都要监测这两个系统的反应和初始化行为。这意味着缺少设计,应当改进。除此之外,校验工具还用来对每一套SDL图都进行状态检测。结果表明系统没有死锁现象。

一旦SDL设计被正确验证,就开始实现ChattaBox。UML和SDL都被当作参考模型,以确保可以准确反映设计过程的结果。实现细节超出了本文讨论的范围。

E.测试

为了确定实现的并发通信和分布式系统是否正确,测试是必不可少的。要确定两个主要的正确性度量。第一个是要测试是否所有的系统组件都完成了相应的功能。第二是要测试终端用户是否对ChattaBox产品表示满意。

1) 组件测试:在实现阶段,单个组件要单独测试。测试包括黑盒和白盒测试。下面是测试中得到的一些结果:

X SIP正确性:SIP呼叫能够成功跨越多个领域和代理服务器。SIP呼叫序列遵循SIP RFC标准[7]。SIP呼叫要能正确对付错误,也可以优雅地中断(称作teardowns)。

X RTP正确性:要正确处理RTP连接,会话要干净地关闭。语音数据要可听,要能正确地传输才行。

X 分布式架构完整性:分布式架构要能有效地均衡负载。除非发现合法的证书以及档案和语音邮件要能正确地管理,否则服务器将无法运行。

2) 用户测试:系统由十人组中进行测试,他们的年龄分布从18岁到49岁。两人分为一组,进行测试,这两个人都使用ChattaBox进行通信。用户要用系统来执行任务。之后他们要通过调查问卷判断系统,问卷是事先做好的。分析完用户测试的采样数据之后,我们得出了下面关于ChattaBox系统的结论:

X 尽管有迟滞现象,但声音质量很好。

X 系统可以响应启动呼叫、档案改动和语音邮件管理等行为。

X 用户界面很有效,相当容易使用。

X 系统并非不可预测,可以按照用户的想法进行工作。

总的来说,ChattaBox成功地满足了要求。组件和用户测试表明它是一个稳定的,正确的系统。

V 结论

在案例研究的最后,我们可以得出下面这些结论。

A.UML和SDL的软件工程

把UML用于需求分析和最初的设计,SDL用于验证和测试设计,这样的选择把软件工程视为一个整体。案例研究中获得的经验也证实在完成复杂系统工程时,有结构的软件开发过程是很重要的。

而且,我们也评估了使用UML和SDL实施CCS工程的价值。UML有很大帮助,它可以从高层快速开发系统。如果这条路可行且有效,仍然需要改进转换过程。

使用软件工程方法验证系统正确性的做法已经受到注意。尤其在把独立组件整合进最终系统的时候,开发大型通信和分布式系统被证明是特别困难的。

完成了耗时的测试之后,还要与系统进行会话以确保它可以顺利运行。很明显,任何减少SDLC的作法都是有用的。进而,了解系统设计逻辑是否正确可以在实现阶段节省大量的时间。如果设计正确,实现中遇到的错误就不大可能会是逻辑错误,逻辑错误需要花费大量时间来解决。

B.面向对象设计范型的适宜性

UML设计完全是面向对象的。我们发现在最终系统中用到的许多概念并不适合使用面向对象范型来建模。这些概念包括事件、远程对象和线程。大多数分布系统的实现要用到这些概念。因此我们建议采用UML扩展以更好地对这些概念进行建模。

而且,如果对正在使用的概念没有深刻地掌握,完整而详细的设计就不总是可以实现的。例如,最终实现中用到的许多制品在设计阶段并不为人所知。再者,在不具备这些知识的时候就开始建模意味着设计只能停留在相对较高的层次。

C.CASE工具的使用

作者对在软件工程过程中CASE工具的位置理解得尚且不好。图形对于团队成员之间的概念交流来说是很必要的,可以用来澄清不能很好理解的概念。使用Telelogic和Microsoft的CASE工具将会大大完善软件开发生命周期(SDLC)。

从ChattaBox案例研究初始阶段直到系统实际实现是一段很长的时期。但是,我们现在对使用软件工程构造复杂的系统和团队协作有了更为深刻的见解。

VI 未来的工作

下面提出了一些对在未来工作和案例研究中选用不同的软件工程道路的建议。

把UML设计转换为SDL的过程应该更加高效。在转换之后,如果没有对SDL图进行扩充,效率会提高。

应该进一步调查,开发工具允许在UML和SDL之间进行逆向工程。有了这种工具,开发人员就得以保证在任何时候都能操控系统的表示。相应地,要用SDL验证设计的正确性,同时也要用更为友好的UML进行归档。

另一种方法是采用UML 2.0或SDL 2000进行案例研究。这样的案例研究会帮助弄清楚这些方法学的扩展是否允许在软件开发周期内仅使用一种技术,从需要和设计到验证,最后到实现,测试和归档阶段。假如说这些语言可以成功地完成CCSs工程,那么它们对于以后的软件工程师也会是一种有价值的工具。


版权所有:UML软件工程组织