Defining a System with UML

As system engineers explore the requirements for a system and begin to define a high-level solution, they face a number of challenges, including defining the system context and top-level structure; understanding system-level behavior; and prototyping physical appearance and user interface. A survey on the Artisan Software Web site found that 72% of engineers found initial system definition one of the most difficult parts of a project.

There are a number of well-documented techniques and notations for system architecture and behavior descriptions. This article suggests a set, based on the popular UML notation, which you can use for describing embedded control systems. Similarly, the article suggests an approach to building prototype physical UI models for such systems.

Automation tools provide significant help in applying these techniques, not just in building and maintaining the descriptions but, more importantly, in simulating models early in the design process. Early simulation helps the system engineer formulate and verify his ideas, and engages project sponsors and users in design validation during the early stage of system definition. An Artisan survey found that 56% of engineers thought that detailed simulation of a system state-chart before building the system was valuable and a good use of their time.

A combination of modeling and simulation tools, in this case Artisan Real-time Studio (RtS) Professional and Altia FacePlate, can help greatly during early system design. When used together, these two types of products help system engineers effectively and productively meet the system-design challenges they face.

The example used in this article is a simple cardiac monitor. The patient's pulse is fed to the monitor, which provides a time-based plot of heart rate plus a visible alarm when the heart rate exceeds a safe value.

• The system architecture, defining structure and scope
• System usage, featuring typical use scenarios
• System behavior, how the system reacts to input and produces outputs.

Documenting the System Architecture
The starting place for many system engineers is a high-level context diagram (Figure 1).

Figure 1:  High-level system architecture for a cardiac monitor

This high-level architecture (sometimes called context) diagram shows the subsystem (Cardio) that we're trying to build, the devices to which Cardio connects, and the signals sent between Cardio and these devices. This is a natural starting place, since it scopes the system's responsibilities and provides a black-box view of the system interface. UML does not feature a system-level diagram of this type, although you can use a collaboration diagram with classes representing the system-level elements.

System Usage
An increasingly successful and often-used system definition technique is to describe specific uses of the system (called use cases), and document individual scenarios as sequences of messages exchanged between the system and the devices to which it attaches. The context diagram provides vocabulary for describing such scenarios. Specific usage scenarios are easy for users to describe and to use to form good acceptance tests. Figure 2 shows a particular scenario, described using a UML sequence diagram. When a new heart rate is detected from the patient's pick-up, that rate is outputted to the display; depending on the rate, the alarm LED may be either lit or extinguished.

Figure 2:  A Usage scenario described with a Sequence Diagram

Documenting System State
As the set of possible scenarios is built up, you can start to produce a behavioral definition. Many control systems benefit from the definition of a behavioral model for the subsystem, which describes how the subsystem reacts at the highest level to input and generates outputs.

When describing the behavior of a control system, you can use a reactive model, such as a state-chart. At this early stage, you describe the state chart directly in terms of the signals the control system exchanges with the system's physical devices. The system engineer doesn't need to drill down into object or class design in order to produce a useful and complete state-chart. The context diagram in Figure 1 shows all the information you need about the system interface.

The window in Figure 3 shows the Cardio state-chart subsystem using a simulation tool GUI. The state-chart is mostly triggered by signals directly from the context diagram, for example Rate and Power, but where appropriate you can use a timed event, such as, after (PlotInterval). The model responds to these signals mostly by sending signals back to the devices, for example Alarm(1) and ClearActualRate() but, if required, the system can remember data between signals, for example, numberOfTicks.

How A Modeling Tool Can Help
You can describe the diagrams in this article using pencil and paper or a simple drawing tool, so why use a modeling tool? The answer obviously depends on the features of the tool, but typically, there are four benefits to tool usage:

• Automatic document generation, so that you can produce review and contractual documents simply and quickly
• Enforcing a standard notation, such as UML, which will make the details of the system definition easier to convey to others
• Building a sophisticated model of the system that can provide leverage later during the system's design (for example, all of the signals on the state chart in Figures 2 and 3 were reused from the context diagram in Figure 1)
• Maintenance of the models as the project progresses is far easier than with simple drawings, since the diagrams understand the semantics and reflect the content of the single, underlying model.

State-Chart Simulation
Model simulation provides another major benefit. Models can get complex when describing more sophisticated control systems. Even though, arguably, UML state-charts are the clearest and most powerful of the notations available today, it is often difficult to predict beforehand exactly how a state machine will execute. A test harness that allows attributes to be set and events to be injected into an executing state machine is an essential aid in verifying the state machine's behavior.

Figure 3 shows the simulation of the state chart for the Cardio subsystem being tested in the test harness. RtS Professional provides automatic generation of both the simulation and a test harness interface to a state chart.

During simulation, the red outlines identify current states and the last transitions; blue outlines identify states visited and transitions taken; and black outlines surround elements that have not been visited. You can inject signals (called Events here) and inspect and change data values. In this case, we can see that maxSafe is set to 180, so that has been set as the Value of the input signal Rate to test that the transition Rate[value>=maxSafe] is taken (the red outline indicates that it has). The simulation log at the bottom of the figure shows that the output signal Alarm, with value 1, has been sent.

The techniques for presenting a physical-system interface vary from pencil and paper to a physical mock-up of the interface, with varying degrees of cost and effectiveness. Figure 4 shows a solution of medium sophistication, designed using a physical UI prototyping tool.

Figure 4:  A potential front panel for the Cardiac Monitor. The red alarm LED indicates that the heart rate is too high. The bottom slider emulates the pulse from a patient. The main readout shows the heart-rate plot with a digital readout of the heart rate. Note that the components in the simulation have been given a real look-and-feel to increase the sense of reality.

An Altia product called FacePlate produced this UI. FacePlate is very good for describing the physical UIs found in many embedded systems, such as medical electronics, process control, and consumer electronics.

Integrating System Behavior and UI
Using an animated state chart with a test harness is a good way for a system engineer to verify ideas about the system behavior. However, when it comes to the engineer conveying ideas to project sponsors or end-users, these might not be the ideal tools. Not everyone wants to look at an executing state-chart.

Staring at a mock-up of a front-panel has its uses as well, but often users are interested in how the system reacts when the various buttons and dials are manipulated.

Far better, then, is to connect the behavior of the system as proven using the state-chart simulation to the physical UI prototype. This means users can validate system behavior in the context of a realistic mock-up of the intended UI.

The interconnection between modeling and UI tools can be very powerful. In Figure 4, the plot and meters are driven by RtS in response to the slider values provided by FacePlate.

Hardware Design
The diagram in Figure 1 sits above the level of hardware and software design, providing the required context for both. Hardware engineers start to work on board designs, defining the required processors, memories, and I/O hardware to communicate with external devices.

Software Design
Often in smaller systems, once the engineer has modeled and accepted system behavior, detailed design is mostly concerned with device interaction, error handling, and providing an adequate level of service. The system-level state chart then forms the basis of the controller class in an OO design. Using RtS, you can get this controller with minimal change. You can map input signals to functions in the interface of the controller class. You can also direct output signals to driver classes. This often leaves the original design substantially untouched.

A UI tool, depending on its functionality, continues to be useful as a front-end for quite a while, particularly if the system is host-based, or if you do a lot of integration and testing is on the host.

Verification
The initial validation period with project sponsors and users provides very valuable acceptance criteria for the finished system. You can use a record/playback capability, if available, to maintain testing scenarios, which you can then use as acceptance tests later in development.

About the Author Alan Moore is the Vice President for Product Strategy at Artisan Software. Alan has 15 years of experience in the development of real-time and object-oriented methodologies and their applications in a variety of problem domains. He has been actively involved in product development, training, and consulting related to OOAD and structured development tools during that time. Alan has co-authored a book on GUI design, published several papers, and has lectured on a wide variety of analysis and design issues. Alan is responsible for the specification, planning, and management of the ARTiSAN product strategy. He is the author of ARTiSAN "Real-time Perspective," a pragmatic approach to the development of real-time systems, and is an active participant in the Real-time Analysis and Design Group (RTAD) of the Object Management Group (OMG).