MeDUSA Method for Designing UML2-based Embedded System Software Architectures Alexander Nyßen 1, Horst Lichter 1, Jan Suchotzki 2, Lukas Kurmann 3 1 Introduction MeDUSA (Method for Designing UML2-based Embedded System Software Architectures) is a model-driven software design method targeting the domain of small embedded systems. It was developed by the Research Group Software Construction of the RWTH Aachen in close cooperation with the German ABB Research Centre in Ladenburg. MeDUSA incorporates various practical experiences gained during the industrial development of embedded software in ABB Business Unit Instrumentation. Regarding its applicability, the domain covered by MeDUSA can be characterized, as stated above, as software development of small embedded devices. However, as this application domain is rather broad and even if we think that MeDUSA would be applicable to quite a lot of its different sub domains understanding the method and its characteristics can be best achieved by taking into consideration the domain MeDUSA was initially developed for, namely that of software development for field devices. Field devices are rather small embedded systems that are integrated into an often large process automation plant. They are used across various industries such as food, chemicals, water and waste water, oil and gas, pharmaceutical, and others. Most of them occur in many different variants. Measurement devices for example, which are one sub category of field devices, occur in different product variants concerning the physical quantity they measure (temperature, pressure, flow), the measure principle applied, the communication capabilities offered, as well as the safety and reliability constraints accomplished. 2 Requirements and Objectives All field devices do have in common that they can be characterized by rather strong resource constraints regarding memory, power consumption, and computing time. Thus, object-oriented programming languages are not yet the first choice and C is still the main implementation language in the regarded application domain. Any design method being applicable to the domain should therefore allow a smooth and rather direct transition from a detailed design into a procedural implementation in the C-language. The large extend of variety, field devices occur in, does precipitate that the development of them is done or is at least intended to be done in a product line approach. The software of most measurement devices is for example developed on top of a common product unspecific platform covering basic services and hardware interfaces, into which product specific components regarding the measurement task, which is strongly dependent on the physical quantity to measure as well as on the measurement principle applied, have to be integrated. A method supporting the development of software for such devices should therefore be capable of supporting distributed development of software components, so that platform as well as product specific components can be developed in a distributed manner and can then be easily integrated.
The last basic requirement posed on any method targeting the regarded application domain is, that the notation employed is not proprietary but best based on a standard or at least industry standard. There are several reasons for this. First the development of software for safety critical application areas requires the application of standards wherever possible. Second, the application of a standard best enables the communication in a distributed development organization (as we focus in ABB Business Unit Instrumentation), as training of developers can be easily achieved. Last, a large number of standard-conformant tools is available from which a selection can be made when assembling a tooling infrastructure. Having all that in mind, our intention was to develop a design method that fulfills all those requirements while also considering the expectations and practical experience of application developers. Having already gained practical experience with the application of the objectoriented COMET method [Go00] in the domain [NM04], we regarded it to be an adequate starting point. Thus MeDUSA tries to transfer all of COMET s advantages to the regarded application domain while trying to expunge the most of its shortcomings identified during its practical application. 3 The MeDUSA Workflow MeDUSA covers the software development life cycle from the early requirements modeling, via analysis and architectural design, up to detailed design modeling as shown in Figure 1. It supports the model-driven paradigm by a systematic and intense use of models through all those steps. Figure 1: MeDUSA workflow overview 3.1 Requirements Modeling During requirements modeling, functional requirements of the software system are captured in terms of use cases. Besides graphical modeling based on the UML, a major focus is also spent on developing narrative use case descriptions to capture the detailed flow of events of each use case, as well as pre- and post-conditions or other important information. Although use case modeling is only partly suited to capture non-functional requirements, the context of real-time systems requires that some of them - especially timing constraints - have to be already regarded during this early step. That is why MeDUSA adopts the concept of timer actors, introduced by the COMET method, to capture non-functional timing constraints during use case modeling.
3.2 Analysis Modeling During analysis modeling, the problem domain is regarded. Analogous to COMET, a system context model is first developed that captures the system s environment (or more precise the internal interfaces to that environment) in terms of interface and timer objects. Subsequently a system information model is then developed, which captures the relevant long living application data in terms of entity objects. In contrast to COMET, where both models are recorded in terms of static class diagrams, MeDUSA makes use of object (instance) diagrams in this step, as this facilitates the intuitive understanding of the developers in the targeted domain. While the two initial steps of the analysis phase - system context and system information modeling - deal with identifying interface, timer and entity objects, adjacent analysis steps of the analysis phase deal with the identification of further analysis objects (control and application logic) in order to gain a complete analysis model. The identification process is supported by applying object structuring criteria, which were with slight modifications adopted from the COMET method. In detail, missing control and application logic objects are identified by modeling an object collaboration for each identified use case, so that the inter-object behavior of the collaboration jointly reaches the goal of the use case. Last, the internal object behavior is then modeled for those control and application logic objects that possess non-trivial behavior. 3.3 Architectural Design Modeling After having understood the problem domain in terms of analysis objects, whose internal and external behavior have been captured, architectural design modeling is the first step of composing a solution. Here, identifying subsystems by grouping together functionally dependent analysis objects is the starting point. It is similar to the identification of objects during analysis modeling supported by taking into consideration subsystem structuring criteria, which were adopted from COMET. After that, the structural and behavioral relationships between the identified subsystems have to be regarded, in order to design the structural and behavioral aspects of the interfaces between them. In contrast to COMET, where a class and a consolidated collaboration diagram are employed to model the architectural design on the system level, MeDUSA uses component (respectively composite structure) and sequence diagrams for this purpose. A component diagram in the form of a composite structure diagram is best suited to model the top-level runtime structure of the system in terms of interconnected subsystems. Sequence diagrams are well suited to describe the behavioral relationships between subsystems as they are far more expressive than collaboration diagrams and thus allow to model not only a main flow of events, but also all facets of alternative flows. In contrast to COMET, where the internal decomposition of each subsystem is also regarded during this step by using a collaboration and a class diagram to demonstrate the internal decomposition of each subsystem in terms of objects and related classes, MeDUSA does not regard the internal details of each subsystem during architectural design. They are regarded not earlier than during detailed design. The reason for this is that MeDUSA was designed to allow the distributed and independent design of each subsystem (something that was motivated by the distributed organization structure of the ABB Business Unit Instrumentation). Therefore the decomposition of the system into subsystems and the structural and behavioral relationships between those subsystems are regarded during architectural design, to assure that a postponed integration of the separately designed subsystems can be achieved.
3.4 Detailed Design Modeling After having identified subsystems and after having defined their structural and behavioral relationships during architectural design, the focus is then placed on designing the internal decomposition of each subsystem. That is, the initial object collaboration that has been grouped together to form the subsystem during early architectural design modeling is now consolidated and enriched. At the end, a detailed decomposition of each subsystem into design objects (or components in terms of more complex subsystems) has to be found, which cooperatively perform to deliver the services offered by the subsystems via its interfaces. Next this internal decomposition has to be analyzed concerning concurrency issues. That is, active objects have to be identified and transferred into tasks. The initial task design then has to be optimized, as the number of tasks has to be removed to a reasonable amount. This step is supported by the task structuring criteria adopted from the COMET method. Last, the detailed class design has to be developed for all active and passive design objects that are part of a subsystem s decomposition (for those objects that are used as parameters in a provided or required interface of a subsystem, the classifier design has already been done during architectural design to ensure that the separately developed subsystems can be well integrated). It has to be pointed out that, not earlier than during this step, the transition from objects to classifiers is done for all objects that form the internal subsystem decomposition something that we describe as the characteristic of the method to be instance-driven. We will come back to this in the next section. 4 Characteristics of MeDUSA Acting on the maxim that model-driven development for small embedded systems should allow a seamless transition from the design model to an implementation in the C-language MeDUSA was - unlike COMET - designed to be an object-based rather than an objectoriented method. That is inheritance and polymorphism are disregarded until the late detailed design, as the conception of classifiers is done not earlier than during this step (to be precise this holds for all objects forming the internal decomposition of a subsystem, as stated above). The application of object-oriented concepts is not enforced during earlier steps of the method. Therefore those concepts may even be omitted during detailed design to allow a more straightforward implementation of the detailed design model. Taking into consideration that the run-time structure of software systems in the regarded domain is mostly rather small - being comprised of only a few subsystems and a manageable amount of objects - MeDUSA was designed to be an instance-driven method. That is, during all steps of the method, from the early analysis up to the late detailed design, the modeling of objects (or more precise classifier instances) rather than the modeling of classifiers is enforced. This allows the architectural design of the system to be directly captured in terms of the system s run-time structure rather in an abstracted classifier-based view on it and does - according to our practical experience - accommodate the intuitive understanding of the application designers and developers. Due to the fact that the main focus of the method resides on modeling the run-time structure of the system rather than modeling the static classifier structure, the enhancements and additions the UML introduced with its new standard version 2 are quite beneficial [NL05]. The newly introduced composite structure diagrams for example are very well suited to cover the runtime structure of a system s subsystems. Because of this and because of the tool landscape which is currently shifting to the new standard release - MeDUSA was conceptually designed to employ the latest UML version as its notation.
5 Lessons Learned MeDUSA was of course developed in several iterations. Although we tried to include representatives from different development teams of ABB Business Unit Instrumentation already into the development of the initial version of the method, the result did not yet fulfill the developers needs to all extend so that several changes from which some were also of major kind - had to be applied. Most of these changes however even including a redesign of the method to obtain its instance-driven nature were introduced already in the first revision of the method. It was developed after the method had been established for about 10 months so that enough experience from its practical application had been gained. Especially the coaching of developers by MeDUSA introduction workshops and guided analysis & design sessions during the introduction phase of the method gave a great insight into the problems, the first version still had. Additionally a job rotation of one of the method developers from ABB Research Centre into a development site applying the new method was a key success factor for its acceptance and improvement. One of the most important lessons learned from our viewpoint therefore is that developing and introducing a new design method does indeed take - first and foremost - time. Even if the method is developed in a very systematic manner, and even if its users are involved in the development process very close and right from the beginning, enough time to gain experience and learn from applying the method in practice simply has to be taken. Also, it has to be assured that the people having to apply the method are willing to learn and that their anxieties and obscurities are eliminated. A good means to achieve this is to offer extensive coaching and to establish a transparent direct feedback loop. 6 Conclusion and Outlook We tried to create a method that suits the special needs of software development for small embedded systems. As C is still the main implementation language in the targeted domain, and as a smooth transition from detailed design to implementation is essential for the success of a model-driven development approach, we decided to create an object-based rather than an object-oriented method. The manageable complexity of the regarded software systems does allow to model their run-time structure directly. This is what led us to equip the method with what we call its instance-driven nature. That is, up to the late detailed design, instances rather than classifiers are modelled. We hope that both of these outstanding characteristics help to better support the development of systems in the targeted domain. At least in ABB Business Unit Instrumentation we retrieved strong evidence that this might be the case. The full benefit of a model-driven method like MeDUSA can of course only be unleashed if its application is supported by adequate tools. Although one can choose from a broad variety of available modeling tools, as the method is based on the UML2 standard, we noticed that none of these does indeed support MeDUSA s notation subset to all extend. Actually we did not find a single modeling tool that could be characterized as being fully UML2 standard conformant. Best possible support for MeDUSA can therefore only be achieved by using a customized modeling tool, which fully supports the notation used by MeDUSA and which also offers automated code generation to allow a direct transition from design to code. Therefore we are currently spending a lot of effort in this direction.
Besides that we are currently investigating to adapt MeDUSA to make it best suitable for a product-line engineering approach. While distributed development of reusable components based on a common architecture is already done based on MeDUSA, the method has still to be enhanced to offer support for dealing with the variability that occurs in a product-line context. That is, modeling support for variability has to be introduced to the different UML2 diagram types employed by MeDUSA and the different objectives and requirements of domain and application engineering have to be reflected by MeDUSA s methodology. Although MeDUSA was initially designed targeting the rather narrow domain of field devices, we think that it might be applicable to the development of quite a broad range of small embedded systems. We still have to supply the evidence for this. However, a small indication might be that other business units of ABB are currently planning to introduce MeDUSA for their development as well. Literature [Go00] Gomaa, Hassan: Designing Concurrent, Distributed, and Real-Time Applications with UML. Object Technology Series, Addison Wesley, 2000. [NM04] Nyßen, Alexander; Müller, Peter; Suchotzki, Jan; Lichter, Horst: Erfahrungen bei der systematischen Entwicklung kleiner eingebetteter Systeme mit der COMET- Methode. in Hesse, Rumpe (Hrg.), Lecture Notes in Informatics (LNI) Modellierung 2004, Marburg, Volume P-45, p229-234. [NL05] Nyßen, Alexander; Lichter, Horst; Suchotzki, Jan; Müller, Peter; Stelter, Andreas: UML2-basierte Architekturmodellierung kleiner eingebetteter Systeme Erfahrungen einer Feldstudie. in Klein, Rumpe, Schätz (Hrg.), Tagungsband des Dagstuhl-Workshops Modellbasierte Entwicklung eingebetteter Systeme (MBEES), Technischer Bericht, TU Braunschweig, TUBS-SSE-2005-01, 2005. 1 RWTH Aachen, Research Group Software Construction email: {any lichter}@cs.rwthaachen.de 2 ABB Automation GmbH, D-32425 Minden, email: jan.suchotzki@de.abb.com 3 ABB Corporate Research, D-68526 Ladenburg, email: lukus.kurmann@de.abb.com