UML and Mobile Communication

by Albrecht Müller
This page is about UML and mobile communication. The idea is to collect and describe ideas related to the forthcoming ETSI Standard DTR/MTS-00085 "UML Profile for Communicating Systems" and to what I call "reference models" related to technical specifications in the mobile communication area (GSM, TD-SCDMA, UMTS). A "reference model" in this sense is a model that describes contents of technical specifications in a formal way using UML. In some sense this is similar to what in another context is called a business model.

In its current form this page is just a dummy page, containing just a little story about software development and a few references I collected. The story is about why I think that it will become more and more important to use formal techniques such as UML.

Some time ago I had to test some device driver. There was a well implemented software development process and a design specification describing the driver in prose was available. It took me quite some time to understand the specification, define the test cases, implement the test software and to run the tests. I detected a strange behaviour of one feature making in unusable. When I asked the developers of the device driver they explained to me that the software worked as specified. I was not satisfied with this situation and found out that there was a single subsystem that could use this feature. The result of a short phone call to the responsible person was that nobody uses this feature, therefore its strange behaviour does not pose any problems.

A few months later I attended a seminar with Ivar Jacobson. It was interesting to see what you can do if you specify your software using UML. At the seminar they showed software agents supporting the people that specify software. If they define a use case this agent may give hints such as: 'You are defining a feature but in the model there is no association to an actor that uses it. Please add an association to some actor. If you are not able to find someone or something that uses this feature consider dropping it.'

Imagine this in the case of the device driver: The phone call had been a few months earlier and the specification, implementation and test of the feature had been dropped, saving quite some time and money. The problem is that from a short term point of view it may be cheaper to stay with the conventional approach as it takes some time to implement formal techniques such as UML.

You will find the references I collected if you follow this link.Last Modification: 26. May 2003
Back to the Software Team Page
Contact the Author