Model-Driven Development Using Rhapsody
William A.Fritz
Department of Software Engineering
University of Wisconsin– Platteville
Platteville, WI53818
Abstract
As the software systems being used in embedded systems become more complex, it becomes more difficult to represent the system in any method other than as a model. While many CASE tools exist for creating these models, and for generating code from them, they are often lacking in making any decent code or even cause the code to no longer match the model. Model-Driven Development (or MDD) tools are the attempt to fix this shortcoming. This paper will cover how MDD attempts this, and in the specific how Rhapsody works.
Introduction
While CASE tools have gained more support over time, many of them are lacking when it comes to generating code from the model, or editing the model to match the code. Model-Driven Development tools use UML and SysML to make a better overall tool. The program this paper will center on, Telelogic’s Rhapsody, supports using UML 2.0, SysML, and DoDAF for creating its models. It is a fully integral program that can contain the entire system from requirements all the way through to final code and testing.
Model Driven Development
What is Model Driven Development?
Model Driven Development is a method for producing software quickly, efficiently, and with as little cost as is possible. The basic concept of Model Driven Development is for embedded systems, or other state machine based applications. It starts out with making a requirements document and a series of models using UML, SysML or a similar modeling language. These models and requirements are then used directly for the generation of code.
This differs from CASE tools such as Rational Rose in that Rose would create a code framework from your models, a framework that often needed heavy modification to be useable. MDD tools however will create complete functioning code that is ready to be put on the target device.
Why Use Model Driven Development?
The idea behind MDD is that modeling and transforming is abetter foundation for the development and maintenance of systems than programming [2]. It allows for more easily understood representation of a state machine system without having to translate diagrams into different documents to meet the development style. A quality MDD tool can facilitate many tasks, including “communicate the solution to stakeholders who are not involved with the development of the product, create a contract with the team that is developing the solution, and track the history of the decisions behind the solution's design.”[1] If these tasks can be achieved using MDD, and it is cheaper and more efficient than other development methods, perhaps the better question is, why not use it?
Advantages of Model Driven Development
Model Driven Development’s main advantages lie in the ability to work with a system at the model level. “By using models, software engineers and other stakeholders are able to argue conceptually about a problem without worrying about syntax or other platform specific issues.”[4] This is an advantage because it takes out one of the things that can often confuse stakeholders. While they know what they want, they often do not have the technical knowledge of coding to understand what the difference between platforms can mean. When looking at a model, it is at a high enough level to be easily understood to someone who has an idea of what the system should do.
This ease of communication can lead to quicker overall design times, as it makes it easier to get what the stakeholders’ requirements are out of them, and since the entire system can be generated directly off of the diagrams, it can be simply displayed to them.
Another of the major advantages to Model Driven Development is that it is system independent. When designing the overall model very little needs to be known about the final platform. MDD emphasizes developing system independent models, and then using model transformations to fit those system independent models to the final target system. By using this type of structure it makes a system easily portable to different hardwares.
MDD tools vs. CASE tools
The major difference between MDD tools and CASE tools is scale. Most CASE tools are used as a supplement to the development process, allowing models to be created and linked together easily. MDD tools on the other hand are meant to use models as the primary means of development.
What is Telelogic Rhapsody?
Rhapsody is a full Model-Driven Development environment tool put out by Telelogic. It has support for generating final code in Ada, C, C++, and Java. It is currently the industry leader for MDD environments. Rhapsody contains all of the tools necessary to create a set of requirements and graphically represent a large or small embedded system. Once the system has been designed tests can be autogenerated from the model, and the code can be generated and debugged straight through Rhapsody. It even supports debugging on the target hardware.
Why use Rhapsody?
Rhapsody has many things that make it a good choice as a development environment for embedded systems. First among these is that it has within it support for code in 4 different languages and can be easily targeted for 8, 16, 32 and 64 bit platforms. It can also easily be changed to generate any of the supported code types, allowing a single model to be deployed to many hardware target’s quite simply. It can also be configured to allow for deployment to a number of commercial and proprietary RTOS’s, as well as systems with no RTOS at all.
Design for Testability
Rhapsody includes integral support for Design for Testability (DFT) methodologies. Built in tools allow for creating model and requirements based tests automatically. It also can run these tests on a host or the target hardware.
Dynamic Model Code Associativity
Dynamic Model Code Associativity (DMCA) is the method through which Rhapsody allows for changes in the model to affect the code, and the other way around. A user can change their Model and the code will be changed to match it,and in the same way a change in the code can be automatically applied to the model that originally generated it. This allows a high level of flexibility to the user to edit what needs to be. They can edit what needs to be changed directly in the code and have the model updated rather than have to find what needs to be changed in the model to get the change they want in the code.
Rhapsody Features
Moving Current Projects to Rhapsody
Rhapsody has built in support for importing projects from other tools such as Rational Rose into itself. As long as Rose is installed on the machine that the import is to take place on it is a simple wizard design that allows for importing of many of the views Rose can create, as seen in figure 1.
Figure 1: Rose Import Options
Rhapsody also supports use of design blocks from the Simulink MATLAB extension. For these a black-box approach is used, Rhapsody can use the Simulink components but is not able to edit them in itself. However the user can update the component in Simulink and then simply synchronize the model within Rhapsody. The last major importing technology in Rhapsody is its XML Metadata Interchange (XMI) interface. “The XML Metadata Interchange (XMI) is an OMG standard for exchanging metadata information via Extensible Markup Language (XML).”[5] XMI is primarily used for exchange of UML models. Rhapsody can not only import XMI models into its own projects but also has exporting capabilities.
Rhapsody Export Tools
As alluded to previously, Rhapsody can make exports to XMI. It is able to export an entire model to XMI for closer examination, or for being parsed into another tool. The other nice feature of the XMI export is that you can set it to export the model to be searched in an html browser. Rhapsody can also export its variable, type, and class data, as well as design information to the DOORS environment. DOORS (Dynamic Object-Oriented Requirements System) is Telelogic’s requirements management tool.Once information has been exported to DOORS, it is also possible to check their status from within Rhapsody, allowing for a fairly full integration.
Debugging Tools
Rhapsody has many built in tools for tracing and debugging your project.
Animator
One of the extremely useful tools it has is its animator. It allows you to view an animated version of many diagrams in real time as the program is running. These diagrams include the sequence diagrams, state charts,activity diagrams,browser,event queue window,Call stack window, andoutput window. This allows you to watch the flow and state changes of the project as it is working in a graphical manner.
When using the animator within a state diagram, the currently chosen state is highlighted in brown. In Figure 2 the Sample Home Alarm System has been set off using the Door event, and the state diagram shows that the system is currently in the intrusion state.
Figure 2: Intrusion alarm state
After entering the correct code the alarm is turned off, moving the system into the silence state, as seen in Figure 3. If the off button had been pressed after the code was entered the armed state would have been exited and the full system would have moved to the off state.
Figure 3: Silenced alarm state
The Animator can also be useful when showing progress to the stakeholders in a project. It allows you to work with the diagrams that have already been shown to them in the design phase and show in real time how it now works.
Tornado IDE Integration
Rhapsody also has the ability to work side by side with the Tornado IDE to allow for code level debugging on the target hardware through Tornado synchronized with design level debugging in Rhapsody. Rhapsody is able to receive breakpoint information from Tornado, as well as sending breakpoints that Tornado understands. This allows you to not only have the program running on the target hardware, but also to still be viewing the animated state diagrams to see what the system is doing.
Companies That Use MDD via Rhapsody
There are many companies that use Rhapsody for their system development. The Trane Company used Rhapsody to create a high-efficiency water chiller and went from blackboard to the testing stage in three months, which is fast for that type of project according to Pat Wilson, their manager of software engineering. Other companies include Smiths Aerospace, Boeing, Lockheed Martin, Airbus, Mitsubishi, Ford, 3Com, Motorola, Nokia, Intel, Seagate, and many others.
Disadvantages of Model Driven Development
As good as model driven development can be for embedded systems, it does have a few drawbacks. One of these actually deals with one of its major strengths. Model Driven Development’s basis “…is to raise the level of abstraction at which designers and developers interact withthe software systems they are building.”[3] While this high level view is very nice for initial development, the distance from the implementation can cause problems when it comes to testing and maintenance.
While Model Driven Development creates the final code directly from the models, this does not mean that the generated code does not need to be tested. While most MDD software will test the models and generated code, it tends to be tested within a simulated host, not on the final hardware. According to Rutherford [3], all of this testing is actually irrelevant. Only the testing in the context of the final system really matters.
This is where Rhapsody has some advantages, the foremost of which is its ability to test the final software product on the target hardware. This allows it to make up for this shortcoming.
References
[1] Hofstader,Joseph; Building Distributed Applications Model-Driven Development,
[2] Mellor, S., Scott, K., Uhl, A. and Weise, D. MDADistelled; Principles of Model-Driven Architecture,Addison Wesley, 2004.
[3]Rutherford, Matthew J. and Wolf, Alexander L.; A Case for Test-Code Generation inModel-Driven Systems, Springer-VerlagBerlinHeidelberg, 2003
[4] Bull, R. Ian; Integrating Dynamic Views Using Model Driven Development, 2006
[5] Wikipedia; “XML Metadata Interchange”,
Fritz1SE411