Read an Excerpt
Real-Time UML Workshop for Embedded Systems
By Bruce Powel Douglass
Newnes
Copyright © 2007 Elsevier Inc.
All right reserved.
ISBN: 978-0-08-049223-0
Chapter One
Introduction
What you will learn:
• Basic Modeling Concepts of the UML
Overview of the UML. What's a design pattern?
• Class and object models
What classes and objects are. How classes and objects work together in collaborations. Collaborations are the realizations of use cases. Includes packaging of logical elements.
• Component and deployment models
Representing run-time artifacts and localizing them on processor nodes.
• State machines and behavioral models
What are state machines and how do they model behavior?
• Use case and requirements models
Capturing black-box behavior without revealing internal structure
Basic Modeling Concepts of the UML
The Unified Modeling Language (UML) is a third-generation object-modeling language standard, owned by the Object Management Group (OMG). The initial version of the OMG UML standard, 1.1, was released in November of 1997. Since then, a number of minor revisions and one major revision have been made. As of this writing, the current version of the standard is 2.0 and is available from the OMG at www.omg.org.
The UML is a rich language for modeling both software and systems, and it is the de facto standard for software modeling. There are a number of reasons for this, and it is the totality of all of them which, I believe, accounts for the phenomenal success of the UML. The UML is, first of all, relatively easy to learn and, once learned, relatively intuitive. Secondly, the UML is well-defined, and models written in the UML can be verifiable (if care is taken to be precise), so not only can the models be directly executed (with appropriate tools, such as Rhapsody™) but production-quality code can be generated from them. Third, there is great tool support; there are many vendors, and they have distinguished themselves in the market by emphasizing different aspects of modeling and development.
The notation used by the UML is graphical in nature, easy to master and, for the most part, simple to understand. Although some people claim that the UML has too many diagrams, in reality there are only four basic types (see Figure 1.1). Structural diagrams include class, structure, object, package, component, and deployment diagrams. These are all basically differentiated, not on the contents of the diagram, but on their purpose. Functional diagrams emphasize functionality but not structure or behavior; functional diagrams include use case and information flow diagrams. Interaction diagrams focus on how elements collaborate together over time to achieve functional goals; interaction diagrams include sequence, communication (formerly known as "collaboration"), and timing diagrams. Lastly, behavioral diagrams focus on specification of behavior of individual elements; these include state machine and activity diagrams. Although the breadth of the notation can be a bit overwhelming to newcomers, in reality, complex systems can be easily developed with three core diagrams—class diagrams, statecharts, and sequence diagrams. The other diagrams can be used to model additional aspects of the system (such as capturing requirements, or how the software maps onto the underlying hardware). The additional diagrams add value, certainly, but you only need the three basic diagram types to develop systems and software.
The UML has a well-defined underlying semantic model, called the UML metamodel. This semantic model is both broad (covering most of the aspects necessary for the specification and design of systems) and deep (meaning that it is possible to create models that are both precise and executable and can be used to generate source-level code for compilation). The upshot is that the developer can fairly easily model any aspect of the system that he or she needs to understand and represent. Figure 1.2 shows a screen shot of a model execution. Rhapsody uses color-coding to depict aspects such as the current state, but color-coding doesn't show up well in a black-and-white image. You can see the execution controls in the figure for step-into, step-over, setting breakpoints, inserting events and so on. Rhapsody can also dynamically create sequence diagrams that show the history of the interaction of specified objects as they run.
The UML is a standard, unlike most modeling languages that are both proprietary and single-sourced. Using a standard modeling language means that the developer can select both tools and services from many different sources. For example, there are at least a couple of dozen different UML modeling tools. Since the tools focus on different aspects of modeling and have different price points, developers can find and select tools that best meet their own and their project's needs. For example, Rhapsody from Telelogic emphasizes the deep semantics of the UML, allowing the validation and testing of the user's models via execution and debugging using the UML notation. This execution can take place on the host development machine or on the final target hardware, and the generated code can then be used in the final delivered system. Other tools emphasize other aspects, such as drawing the diagrams but permitting more flexibility for a lower price point. The availability of so many different tools in the market gives the developer a great deal of latitude in tool selection. It also encourages innovation and improvement in the tools themselves. Because the UML is such a well-adopted standard, many companies provide training in the use and application of the UML. I spend a great deal of my time training and consulting all over the world, focusing on using UML in embedded real-time systems and software development.
The UML is applicable to the development of software and systems in many different application domains. By now, the UML has been used in the development of virtually every kind of software-intensive system from inventory systems to flight control software. Being a maintained standard, the standard itself evolves over time, repairing defects, adopting good ideas and discarding ones that didn't pan out. The UML is used today to model and build systems that vary in scope from simple one- or two-person projects up to ones employing literally thousands of developers. The UML supports all the things necessary to model timeliness and resource management that characterize real-time and embedded systems. That means that developers need not leave the UML to design the different aspects of their system, regardless of how complex or arcane those things might be.
In this chapter, we'll introduce the basics of the UML. This is intended more as a refresher than a tutorial. Those desiring a more in-depth treatment of UML itself should pick up the companion book to this volume, Real-Time UML, Third Edition: Advances in the UML for Real-Time Systems, Addison-Wesley, 2004 by Bruce Powel Douglass. Additionally, there are many white papers available on the I-Logix website, www.ilogix.com.
Structural Elements and Diagrams
The UML has a rather rich set of structural elements and provides diagrammatic views for related sets of them. Rather arbitrarily, we'll discuss modeling small, simple elements first, and then discuss large-scale elements and model organization afterwards.
Small Things: Objects, Classes, and Interfaces
There are a number of elementary structural concepts in the UML that show up in user models: object, class, data type, and interface. These structural elements form the basis of the structural design of the user model. In its simplest form, an object is a data structure that also provides services that act on that data. An object only exists at run-time; that is, while the system is executing, an object may occupy some location in memory at some specific time. The data known to an object are stored in attributes—simple, primitive variables local to that object. The services that act on that data are called methods; these are the services invoked by clients of that object (typically other objects) or by other methods existing within the object. State machines and activity diagrams may enforce specific sequencing of these services when pre- and post conditions must be met.
A class is the specification of a set of objects that share a common structure and behavior. Objects are said to be instances of the class. A class may have many instances in the system during run-time but an object is an instance of only a single class. A class may also specify a statechart that coordinates and manages the execution of its primitive behaviors (called actions, which are often invocations of the methods defined in the class) into allowable sets of sequences.
If you look in Figure 1.3, you can see a basic class diagram. Note that objects are not shown. That is because when you show objects you are showing a snapshot of a running system at an instant of time. Class diagrams represent the set of possible object structures. Most often, when you create structural views, you will be more interested in creating class, rather than object, diagrams.
The DeliveryController object in the figure is an example class. It contains attributes, such as commandedConcentration (which is of type double) and the selected agent (i.e., drug) type. It provides methods, such as the ability to select an agent, to get the amount of drug remaining, and to set the commanded drug concentration. The DeliveryController class is shown as a standard box with three segments. The top segment holds the name of the class. The middle segment holds a list of the attributes. Note, however, that this list need not be complete—not all of the attributes owned by the class must be shown. The bottom compartment shows the methods of invocable services provided by the class.
Figure 1.3 shows other classes as well, and lines (called an relations—more on that later) connecting them. Some of these are shown in a simple, nonsegmented box, such as the TextView class. The attributes and methods, collectively known as features of the class, need not be shown. They are contained within the model and easily visible in the tool browser view, and may be exposed on the diagram if desired. But you have control over which features are shown on which diagrams.
An interface is a named collection of services. Services come in two basic flavors. Operations are synchronous services that are invoked, or called, by clients. Event receptions are asynchronous services that are invoked by sending an asynchronous signal to the object accepting that event. An interface can contain either or both operations and event signals. Both operations and event signals can contain data, called parameters, passed with the invocation. The set of parameters, along with the name of the service, is called the signature of the service. A class that is compliant with an interface provides a method for every operation and an event reception for every signal specified in the interface.
Interfaces allow you to separate the specification of services that may be called on a class from the implementation of those services. A class defines methods (for operations) and event receptions (for signals, specified on the state machine). Both these methods and event receptions include the lines of code that implement the service. An operation or signal is a specification only and does not include such implementation detail.
Interfaces may not have implementation (either attributes or methods) and are not directly instantiable. A class is said to realize an interface if it provides a method for every operation specified in the interface, and those methods have the same names, parameters, return values, preconditions and postconditions of the corresponding operations in the interface.
Interfaces may be shown in two forms. One looks like a class except for the key word interface placed inside guillemots, as in "interface".This form, called a stereotype in UML, is used when you want to show the service details of the interface. The other form, commonly referred to as the "lollipop" notation, is a small named circle on the side of the class. Both forms are shown in Figure 1.4. When the lollipop is used, only the name of the interface is apparent. When the stereotyped form is used, a list of operations of the interface may be shown.
(Continues...)
Excerpted from Real-Time UML Workshop for Embedded Systems by Bruce Powel Douglass Copyright © 2007 by Elsevier Inc.. Excerpted by permission of Newnes. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
