Real Time UML Workshop for Embedded Systems [NOOK Book]

Overview

This practical new book provides much-needed, practical, hands-on experience capturing analysis and design in UML. It holds the hands of engineers making the difficult leap from developing in C to the higher-level and more robust Unified Modeling Language, thereby supporting professional development for engineers looking to broaden their skill-sets in order to become more saleable in the job market.

It provides a laboratory environment ...
See more details below
Real Time UML Workshop for Embedded Systems

Available on NOOK devices and apps  
  • NOOK Devices
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK Study
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$66.95
BN.com price

Overview

This practical new book provides much-needed, practical, hands-on experience capturing analysis and design in UML. It holds the hands of engineers making the difficult leap from developing in C to the higher-level and more robust Unified Modeling Language, thereby supporting professional development for engineers looking to broaden their skill-sets in order to become more saleable in the job market.

It provides a laboratory environment through a series of progressively more complex exercises that act as building blocks, illustrating the various aspects of UML and its application to real-time and embedded systems. With its focus on gaining proficiency, it goes a significant step beyond basic UML overviews, providing both comprehensive methodology and the best level of supporting exercises available on the market. Each exercise has a matching solution which is thoroughly explained step-by-step in the back of the book. The techniques used to solve these problems come from the author’s decades of experience designing and constructing real-time systems. After the exercises have been successfully completed, the book will act as a desk reference for engineers, reminding them of how many of the problems they face in their designs can be solved.

*Tutorial style text with keen focus on in-depth presentation and solution of real-world example problems

*Highly popular, respected and experienced author

*CD includes test version of the popular Rhapsody tool, allowing engineers to capture and work out the exercises in the book
Read More Show Less

Editorial Reviews

From the Publisher
"As you might expect, there are plenty of UML diagrams. Real-time UML specifications are used throughout, consistent with the purpose of the book. Designers with UML expertise who want to understand how to address real-time applications will find this book useful, as will those in the real-time world who need to understand how to bring UML to bear on the design problem." - William Wong, Electronic Design
Read More Show Less

Product Details

  • ISBN-13: 9780080492230
  • Publisher: Elsevier Science
  • Publication date: 9/20/2006
  • Series: Embedded Technology Series
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 1
  • Pages: 432
  • File size: 12 MB
  • Note: This product may take a few minutes to download.

Meet the Author

Embedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of over 5700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space and consulting with and mentors IBM customers all over the world. He can be followed on Twitter @BruceDouglass. Papers and presentations are available at his Real-Time UML Yahoo technical group (http://tech.groups.yahoo.com/group/RT-UML) and from his IBM thought leader page (www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html).

Read More Show Less

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.

Read More Show Less

Table of Contents

Part I: Basics and Preliminaries; Ch1: Basic UML Introduction: Use Cases and Requirements; Ch 2: The ROPES Process: Project Lifecycles; Part II: Exercises; Ch 3: Specifying the Requirements: Grouping Requirements; Ch 4: Systems Architecture: Performing Tradeoff Analysis for Different Architectures; Ch 5 Object Analysis: Applying Object Identification Strategies; Ch 6: Concurrency Architecture: Identifying Tasks; Ch 7: Distribution Architecture: Asymmetric and Symmetric Distribution; Ch 8: Safety and Reliability Architecture: Identifying Channels; Ch 9: Optimizing Collaborations: Reusability, Data Access, Complexity; Ch 10: Detailed Design: Managing Visibility and Access; Part III: Answers; Appendix A: Notational Summary; Appendix B: Short Rhapsody Tutorial.
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)