Essentials of Rational - IBM€¦ · Module 6: Describing behavior by using state machines, part 2...

Essentials of IBM Rational Rhapsody v7.6 for Software Engineers QQ139 ERC 1.0 UML Student Manual

IBM Corporation Rational software U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this documentation in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

Intellectual Property Dept. for Rational Software IBM Corporation 5 Technology Park Drive Westford, MA 01886 U.S.A.

Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

If you are viewing this information in softcopy, the photographs and color illustrations may not appear. Trademarks and service marks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.html

• Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.

• IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce

• Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Intel trademark information

• Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

http://www.ibm.com/legal/copytrade.shtml

http://www.intel.com/sites/corporate/tradmarx.htm#Trademark

• Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Microsoft trademark guidelines

• ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office

• UNIX is a registered trademark of The Open Group in the United States and other countries.

• Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom.

• Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

http://www.microsoft.com/about/legal/intellectualproperty/trademarks/usage/default.mspx

Contents

Essentials of IBM® Rational® Rhapsody® for Software Engineers – UML

About the course...................................................................................................... 0-1 Why use modeling ? ............................................................................................... .1-1 Overview of UML diagrams................................................................................... .2-1 How do you encapsulate structure using UML?..................................................... .3-1 Object discovery strategies ..................................................................................... .4-1 Describing behavior using State machines pt 1 ....................................................... 5-1 Describing behavior using State machines pt2 ....................................................... 6-1 How do you describe communication?.................................................................... 7-1 How do you describe modularity and reusable components?.................................. 8-1 How to capture use cases and requirements ............................................................ 9-1 Advanced sequence diagrams...................................................................... ……..10-1 Extending UML........................................................................................... ……..11-1 Exercise solutions ........................................................................................ ……..12-1 Advanced topics .......................................................................................... ……..13-1

Essentials of IBM Rational Rhapsody for Software Engineers Module 0: About this course

0 -

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

© Copyright IBM Corporation 2012

Essentials of IBM Rational Rhapsody v7.6for Software Engineers Module 0: About this course

ContentsIntroductions 0-2Course outline 0-6Logistics 0-7

Module 0 – About This Course


0 -


2

2 © Copyright IBM Corporation 2012

IntroductionsYour organization

Your role

Your background and experienceSoftware development experienceObject technology experience

Course expectations


0 -


3


Intended audiencePrimary target audience:

Software developersTechnical team leads

Secondary target audience:Systems engineers withsoftware-intensive focusQA and compliance officersManagers



0 -


4


Course objectivesUpon completion of this course, you should know:

How to identify the core UML 2 notation and techniques:Use cases and requirementsModeling structure, including classes and composite structureModeling behavior, including sequence diagrams and state machines

How to use the capabilities of IBM® Rational® Rhapsody® to obtain a wealth of hands-on experience using the Rhapsody workspace to build and test models



0 -


5


Identify advanced Rhapsody features:Reverse engineeringConfiguration management toolsDocument generation

Course objectives: Additional topics

The focus is on applying UML2 in

the context of real-time systems.



0 -


6Module 0 – About This Course


Course outlineModule 0: About this courseModule 1: Why use modelingModule 2: Overview of diagrams Module 3: Encapsulating structure by using UMLModule 4: Object discovery strategiesModule 5: Describing behavior by using state machines, part 1 Module 6: Describing behavior by using state machines, part 2Module 7: Describing communication by using UMLModule 8: Describing modularity and reusable componentsModule 9: Describing use cases and requirementsModule 10: Advanced sequence diagramsModule 11: Extending UMLModule 12: Advanced topicsModule 13: Exercise solutions


0 -




LogisticsMorning1 15-minute break

Lunch 45 minutes

Afternoon1 15-minute break





Course materialsMaterials for this course:

Labs (tool training workbook)Student manual of UML, tool training, and advanced topic slides


0 -




Course descriptionThis course teaches you how to use IBM Rational Rhapsody effectively. It combines class lectures with hands-on lab work.

The delivery of the course is flexible. For example, some instructors may choose to cover UML up front, followed by labs that use Rational Rhapsody, while others may choose to alternate UML theory with the labs that use Rational Rhapsody.

The following slides are provided as guidance only. No two courses are the same, because an instructor may choose to adapt it in order to suit the students’ previous knowledge and experience, or in response to questions that are raised.


0 -




Course description: Day 1Theory:

Module 1: Why use modelingModule 2: Overview of diagramsModule 3: Describing structure by using UML– Exercise 3.1: Attributes and operations

Module 4: Object discovery strategiesModule 5: Describing behavior by using state machines, part 1– Exercise 5.1: Luggage belt– Exercise 5.2: LED

Rational Rhapsody labs:Hello WorldCount down


0 -Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 11


Course description: Day 2 (example guidance only)Theory:

Module 6: Describing behavior by using state machines, part 2– Exercise 6.1: Mouse– Exercise 6.2: Battery charger

Module 7: Describing communication by using UML– Exercise 7.1: Elevator system

Module 8: Describing modularity and reusable components

Rhapsody labs:DishwasherDishwasher system


0 -





Module 9: Describing use cases and requirements– Exercise 9.1: Filling station– Exercise 9.2: MP3 player

Module 10: Advanced sequence diagrams

Tool training:Start the Cash register (the use cases and requirements section)


0 -





Module 11: Extending UML

Advanced topics:Reverse engineering and code-centric workflowThe Rhapsody Oxf framework and containersConfiguration managementDocument generationReverse engineering and code-centric workflow

Tool training:Finish the Cash register lab (at least use cases 1 and 2)Cash register reverse engineering lab (use case 3)Stopwatch free-form model (optional half day exercise)

Essentials of IBM Rational Rhapsody for Software Engineers Module 1: Why use modeling

1 -


1


Essentials of IBM Rational Rhapsody v7.6 for Software Engineers

Module 1: Why use modeling

Module 1 – Why use modeling?


1 -


2Module 1 – Why use modeling?


Module overview After completing this module, you should be able to:

• Identify the symptoms of software development problems• Explain the best practices• Understand the benefits of modeling

The objective of this module is to place graphical modeling in the context of the overall problem that organizations are typically trying to solve when developing complex software intensive systems.


1 -


3


DiscussionWhat are typical problems faced by development teams?What improvements can be made?

To the tools? To process? To training?

What are typical problems faced by development teams?

What changes can you make to help solve some of these problems? To tools? To process? To training?



1 -


4


Symptoms of software development problemsUser or business needs not metRequirements not addressedModules not integratingDifficulties with maintenanceLate discovery of flawsPoor quality of end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issues

Typical software development problems include:•User or business needs not met•Requirements not addressed•Modules not integrating•Difficulties with maintenance•Late discovery of flaws•Poor quality of end-user experience•Poor performance under load•No coordinated team effort•Build-and-release issues



1 -


5


Problems with requirementsSoftware problems are 100 to 1000 times more costly to find and

repair after deployment.

During the requirements phase

During thedesign & construction phase

After the product is releasedDuring the

QA/testing phase

Source: 2008 GBS Industry standard study

Defect cost derived from the assumption that it takes 8 hrs to find, fix, and repair a defect when found in code and unit test. Defect FFR cost for other phases calculated by using the multiplier on a blended rate of $80/hr.

$80/defect$240/defect

$960/defect$7,600/defect

Costs ofDesign Change

Time

InducedErrors

Requirements Design Implementation Test

Quality, as used within the Rational Unified Process (RUP), is defined as “The characteristic of having demonstrated the achievement of producing a product which meets or exceeds agreed-upon requirements, as measured by agreed-upon measures and criteria, and is produced by an agreed-upon process." Given this definition, achieving quality is not simply “meeting requirements" or producing a product that meets user needs and expectations. Quality also includes identifying the measures and criteria (to demonstrate the achievement of quality) and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality (and can be repeated and managed).

This principle is driven by a fundamental and well-known property of software development: It is a lot less expensive to correct defects during development than to correct them after deployment.



1 -


6


Trace symptoms to root causes

Needs not metRequirements churnModels do not fitHard to maintainLate discoveryPoor qualityPoor performanceColliding developers Build-and-release

Insufficient requirements

Brittle architectures Overwhelming complexityUndetected inconsistencies Poor testingSubjective assessmentWaterfall development Uncontrolled changeInsufficient automation

Symptoms Root causes Best practices

Ambiguous communication

Undetected inconsistencies

Develop iteratively

Manage requirements

Use component architectures

Model visually (UML)

Verify quality continuously

Manage change

Model visually (UML)

Continuously verify quality

Modules do not fit

By treating these root causes, you eliminate the symptoms. By eliminating the symptoms, you are in a much better position to develop high-quality software in a repeatable and predictable fashion.

Best practices are a set of commercially proven approaches to software development, which, when used in combination, strike at the root causes of software development problems. They are called best practices, not because we can precisely quantify their value, but because they have been observed to be commonly used in the industry by successful organizations. The best practices have been harvested from thousands of customers on thousands of projects and from industry experts.



1 -


7


Best practices reinforce each otherBest practices:

• Develop iteratively

• Manage requirements

• Use component architectures

• Model visually

• Verify quality continuously

• Manage change

Validates architectural decisions early on.

Addresses complexity of design and implementation incrementally.

Measures quality early and often.

Evolves baselines incrementally.

Ensures that users areinvolved as requirements evolve.

In the case of our best practices, the whole is much greater than the sum of the parts.

Each of the best practices reinforces and, in some cases, enables the others. This slide shows just one example: how iterative development supports the other five best practices. However, each of the other five practices also enhances iterative development. For example, iterative development done without adequate requirements management can easily fail to converge on a solution. Requirements can change at will, which can cause users not to agree and the iterations to go on forever.

When requirements are managed, this is less likely to happen. Changes to requirements are visible, and the impact on the development process is assessed before the changes are accepted. Convergence on a stable set of requirements is ensured. Similarly, each best practice supports each of the other best practices. Hence, although it is possible to use one best practice without the others, this approach decreases the resulting benefits significantly.



1 -


8


Best practice #1: Managing requirementsEnsures that you:

Solve the right problem.Build the right system.

by taking a systematic approach to:Eliciting …Organizing …Documenting …Managing …

… the changing requirements of a software application.

A report from the Standish Group confirms that a distinct minority of software development projects is completed on time and on budget. In their report, the success rate was only 16.2%, while challenged projects (operational, but late and over budget) accounted for 52.7%. Impaired (canceled) projects accounted for 31.1%. These failures are attributed to incorrect requirements definition from the start of the project and poor requirements management throughout the development lifecycle. (Source: Chaos Report, http://www.standishgroup.com)Aspects of requirements management:•Analyze the problem.•Understand user needs.•Define the system.•Manage scope.•Refine the system definition.•Manage changing requirements.



1 -


9


Best practice #2: Model visually (UML)Captures structure and behaviorShows how system elements fit togetherKeeps design and implementation consistentHides or exposes details as appropriate Promotes unambiguous communication

UML provides one language for all practitioners.

A model is a simplification of reality that provides a complete description of a system from a particular perspective. We build models so that we can better understand the system we are building. We build models of complex systems because we cannot comprehend any such system in its entirety.

Modeling is important because it helps the development team visualize, specify, construct, and document the structure and behavior of system architecture. Using a standard modeling language such as UML (the Unified Modeling Language), different members of the development team can communicate their decisions unambiguously to one another. Using visual modeling tools facilitates the management of these models, letting you hide or expose details as necessary.

Visual modeling also helps you maintain consistency among system artifacts: requirements, designs, and implementations. In short, visual modeling helps improve a team’s ability to manage software complexity.



1 -


10


Conceptual collaboration by using textEngineer 1:

“Ok. Here’s what we need to do:System A will pass message X to System B and that willchange B’s state to Running from its previous Idle state. When B changes to Running it will send back a message Y to A and then wait for 2 second before returning to Idle. System A will have started in Idle also and will go to Running after B sends back event Z which happens after the 2 seconds before going to Idle. All this should happen in less than 5 seconds.”

Engineer 2:“Huh?”

You could communicate complex behavior textually…



1 -


11


Conceptual collaboration by using UMLEngineer 1:

“Here, look at thissequence diagram.”

Engineer 2:“Ahhh, now I see!”

… but sometimes a diagram paints a thousands words.

Of course, the diagram’s meaning is shared by the reader. Note that UML is an international standard graphical language. The standardization process helps reduce ambiguity and enables the reuse of skills and best practices across industries and employers.



1 -


12


Chronology of UML and OMG SysML™

UML 2.0

UML 1.5

Mid ’70s – Late ’80s

Identifiable OO modelinglanguages began to appear

1989 1994

Number of identifiable OO modeling languages increases from <10 to >50

“Method Wars”Begin!

IvarJacobson (Objectory) adds OOSE

1996 1997

2001

Joint special interest group in systems engineering modeling formed between OMG and INCOSE

2003 2005

Incorporation of structured notation techniques, including ports and parts

ROOM, UML-RT, and others

1983

UML 0.8

Grady Booch and Jim Rumbaugh begin unifying Booch & OMT methods

HarelStatechartsincorporated

UML 0.9

2007OMG

SysML 1.0 adopted

UML 1.1

OMG stewardship

UML 2.32010

This diagram illustrates the chronology of UML development. Key milestones include:

UML 1.1 was standardized in 1997. UML evolved from 1997 in various minor iterations under the stewardship of the Object Management Group (OMG).

A key milestone was UML 2.0 in 2005. This major release marked the inclusion of some key concepts including the idea of composite structure, the ability to hierarchically decompose a system into parts, with ports defining the provided and required interfaces. This notation supports large-scale systems architecture and component-based design.

Many of these techniques are incorporated into OMG Systems Modeling Language (SysML), a profile that extends the UML for systems engineering.



1 -


13


Best practice #5: Verify quality continuouslySoftware problems are 100 to 1000 times more costly to find and

repair after deploymentCost to repair softwareCost of lost opportunitiesCost of lost customers

Cost

TransitionConstructionElaborationInception

It is a lot less expensive to correct defects during development than to correct them after deployment.

Tests for key scenarios ensure that all requirements are properly implemented.• Poor application performance hurts as much as poor reliability.• Verify software reliability by checking for memory leaks and bottlenecks.• Test every iteration by automating testing.



1 -


14


Testing dimensions of quality

Functional testing verifies that a system embodies the required use-case scenarios as intended. Functional tests may include the testing of features, usage scenarios, and security.

Usability testing evaluates the application from the user’s perspective. Usability tests focus on human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, and training materials.

Reliability testing verifies that the application performs reliably and is not prone to failures during execution (crashes, hangs, and memory leaks). Effective reliability testing requires specialized tools. Reliability tests include tests of integrity, structure, stress, contention, and volume.

Performance testing checks that the target system works functionally and reliably under production load. Performance tests include benchmark tests, load tests, and performance profile tests.

Supportability testing verifies that the application can be deployed as intended. Supportability tests include installation and configuration tests.



1 -


15


Best practice #6: Manage changeTo avoid confusion:

Provide each developer with a secure workspace.Provide automated integration and build management.Develop in parallel.

WorkspaceManagement

Process Integration

Parallel Development

Build Management

Configuration management is more than just check in and check out

Establishing a secure workspace for each developer provides isolation from changes made in other workspaces and control of all software artifacts — models, code, documents and so forth.

A key challenge to developing software-intensive systems is the need to cope with multiple developers, organized into different teams, possibly at different sites, all working together on multiple iterations, releases, products, and platforms. In the absence of disciplined control, the development process rapidly degrades into chaos. Progress can come to a stop. Three common problems that result are:

• Simultaneous update: When two or more roles separately modify the same artifact, the last one to make changes destroys the work of the others.

• Limited notification: When a problem is fixed in shared artifacts, some of the developers are not notified of the change.

• Multiple versions: With iterative development, it is not unusual to have multipleversions of an artifact in different stages of development at the same time. For example, one release is in customer use, one is in test, and one is still in development. If a problem is identified in any one of the versions, the fix must be propagated among all of them.



1 -


16


Achieving best practicesIterative approachGuidance for activities and artifactsProcess focus on architectureUse cases that drive design and implementationModels that abstract the system

Examples:• The dynamic structure (phases and iterations) of the Rational Unified Process creates the

basis of iterative development.• The project management discipline describes how to set up and execute a project using

phases and iterations. • Within the requirements discipline, the use-case model and the risk list determine what

functions you implement in an iteration.• The workflow details of the requirements discipline show the activities and artifacts that

make requirements management possible.• The iterative approach provides a way to progressively identify components and to

decide which one to develop, which one to reuse, and which one to buy. • The Unified Modeling Language (UML) used in the process represents the basis of

visual modeling and has become the de facto modeling language standard.• The focus on software architecture focuses you on articulating the structure: the

components, the ways in which they integrate, and the fundamental mechanisms and patterns by which they interact.



1 -


17


Module summaryIn this module, you learned:

Best practices guide software engineering by addressing root causes.Best practices reinforce each other.Modeling has practical benefits.Processes guide a team on who does what, when, and how.A defined process is a means of achieving best practice.



1 -


18


Essentials of IBM Rational Rhapsody for Software Engineers Module 2: Overview of UML diagrams

2 -


1


Essentials of IBM Rational Rhapsody v7.6for Software Engineers Module 2: Overview of UML diagrams

Module 2 – Overview of UML diagrams


2 -


2


Module overviewAfter completing this module, you should be able to:Identify the various diagrams in UML and:

categorize their structure and behavior.use the diagrams for development of real-time systems.

Follow a workflow for model-driven development



2 -


3


Unified Modeling LanguageThe Unified Modeling Language (UML) is a comprehensive, full lifecycle graphical modeling language

Standardized in 1997 by the OMG (Object Management Group)Created by a consortium of companies from various domains, including IBM as a key contributor (previously Telelogic, Rational, I-Logix)(http://www.omg.org/spec/UML/)

Incorporates state-of-the-art software and systems concepts Matches the growing complexity of real-time systemsLarge scale systems, networking, web enablement, data management

Extensible and configurableUnprecedented interdisciplinary market penetrationUML 2.4.1 released in August 2011

UML 2.x OMG SysML™

Originally a unification of various notations by Grady Booch, James Rumbaugh, and IvarJacobson, Unified Modeling Language (UML) is a graphical language for specifying, constructing, visualizing, and documenting software-intensive systems. You can use UML for business modeling and modeling of other non-software systems, too.

The language has evolved since 1997 under the stewardship of the Object Management Group. The OMG is an international, open membership, non-profit computer industry consortium. Any organization can join OMG and participate in their standards-setting process.

Unlike some structured design techniques, UML is not a methodology. It is a notation that can be used in many different methodologies. This has supported widespread adoption and exploitation of modeling techniques across a wide range of industries.

In addition, UML is extensible. You can adapt the language with domain-specificextensions (using profiles). As well as sharing models and best practices, interdisciplinary teams can use common tools within their organization to reduce support costs.



2 -


4


Diagram taxonomy

Precise syntax and semanticsMultiple views (14 diagram types)*Added, modified significantly, or renamed since UML 1

UML2 includes many different diagram types. Broadly speaking you can separate them into two categories: structure and behavior.

The structural diagrams show how structural elements are related or composed of other elements. Structural elements include objects, classes, and packages.

The behavioral diagrams show things like sequences of messages passing between elements (on sequence diagrams), how elements react to messages by changing state (on state machine diagrams), or what activities or actions a system or one of its components performs (on activity diagrams). A special subcategory of behavior diagrams in UML2 covers interactions, that is, how structural elements interact over time.

Although there are class, package and composite structure diagrams, it is possible to draw all of these on a single diagram. Therefore, the distinction between diagram types is sometimes blurred.



2 -


5


Use case diagramsUse case diagrams shows what the system does and who uses

the system.

Use case diagrams provide a high-level functional context diagram of what the system does and for whom.

A use case is like a story of the use of the system, to provide something of value to an external user or system. Things outside the system are referred to as actors.

Use case diagrams are like a visual index into a library of stories about how the system is used. Note how they intentionally avoid detail about what happens in a particular use case. Instead, they communicate a high-level view of key functions or capabilities.

Use cases are also a useful starting point for designing a new system and eliciting requirements from users. They are often the first diagram to go to when you want to become familiar with an existing system and what it does.



2 -


6


Activity diagramsActivity diagrams describe behavior for operations, classes, or use cases. As soon as one activity finishes, the next one starts.

One way to describe a use case or the behavior of a particular operation is to use the activity model. Activities are one of the key behavioral models in UML. Use activities to coordinate a sequence of actions.

In their simplest form, activity diagrams are similar to flow charts. Activity diagrams show flow between actions, including conditional and iterative logic. Activity diagrams also show actions that occur in parallel.

Activity diagrams in UML2 also have more advanced semantics. You can show both control flow and object flow resulting from actions or activities (for example, the creationof data).

Actions can also invoke other activities so that you can decompose the behavior of a system hierarchically. This technique is used for model-based systems engineering, and often involves a stage where activities are allocated to components in the system.



2 -


7


Class diagrams show classes and the relationships between them.

Class diagrams

Active class symbol

For an object to communicate with another object, a relationship must exist between classes. The class diagram provides a visual notation for expressing relationships between classes.

As well as the association, aggregation, and dependency relationships shown here, we might also have generalization relationships based on inheritance and compositionrelationships showing whole or part relationships.

In UML, a single diagram does not usually explain the whole system. Object-oriented systems are usually built incrementally by using class diagrams to show how classes relate for a particular collaboration or use case. Class diagrams are like a view of the class model, rather than the class model in its entirety.



2 -


8


Object diagramsObject diagrams show instances of classes and which ones are linked to others at run time.

Operations in an object-oriented design are normally invoked on objects, not the classes themselves. An object is an instance of a class.

You can show instances of classes and how they relate on an object diagram. This diagram is perhaps less commonly used that the class diagram, but may be useful for expressing the particular state of a system or object at a moment in time.



2 -


9


Sequence diagrams show instances communicating over time.

Sequence diagrams

Another way to describe behavior in UML is to describe an interaction model by using sequence diagrams. Sequence diagrams show a time-ordered sequence of calls.

Sequence diagrams are commonly used in software modeling to capture how a set of classes or objects collaborate to achieve a particular objective. Often sequence diagrams show the different scenarios that can occur in a specific use case. Some scenarios are “sunny day”; others are “rainy day”.

Sequence diagrams are enhanced in UML2 to support the ability to show logic flow using interaction fragments, and hierarchical decomposition of the behavior by referencing other sequence diagrams. It is now possible to show multiple scenarios on a single sequence diagram.

Often sequence diagrams are favored by software engineers, as they depict methods and operation calls. Activity diagrams are favored by systems engineers because they can be drawn without needing to know anything about how the system is decomposed.



2 -


10


Composite structure diagramsComposite structure diagrams show the internal structure of

classes, which are parts inside a structured class.

UML2 ports and

interfaces

One of the most powerful notations introduced in UML2 is composite structure. A composite structure can decompose a class into parts that can be connected together in an assembly.

The composite structure diagram provides a notation for expressing this decomposition. This notation supports the key objectives of UML2: to support large-scale systems development and component-based design.

The concept of hierarchical decomposition can be performed to any arbitrary level, but is often used to identify significant chunks of a system or subsystem. As well as parts, this notation supports the concept of ports, so you can clearly separate provided from requiredinterfaces.



2 -


11


State machine diagramsState machines are used when you need to wait until something happens before going to a different state.

Unlike the activity diagram, which shows functional flow between actions, the state machine diagram provides a notation for expressing state-based behavior.

State machines are very powerful for showing event-driven behavior, where an object waits for a trigger that causes it to change state. The actions are performed when the transition is taken, causing the state of the object to change.

One of the interesting aspects of the state machine diagram is its relationship with the interaction model. You can create sequence diagrams from a running state machine. You can also use state machines to create an executable definition of an object’s behavior, based on interactions that are defined on multiple sequence diagrams.



2 -


12


Package diagramsPackages are similar to folders. Use them to organize UML model elements.

Packages in UML organize UML model elements to give structure to the model and make separation of concern possible. Packages are similar to folders in a file system and can be nested inside other packages.

You partition a model using packages in relation to configuration management and how your team works. Because it is also possible to share packages between models, you can use them to organize intra-model relationships, for example, the flow of shared information between a system model and other models that implement the functionality defined in the interfaces.

For example, you might separate interfaces into a package that is referenced by subsystems that either provide or require the interfaces. You might also decide to use packages to group together artifacts that are associated with stages in your process, such as requirements, analysis, detailed design, logical versus physical design, and so on.



2 -


13


Component diagramsIn UML1 style you can show how .lib, .exe, .dll, and other artifacts are interconnected.

In UML2 the term component is broadened

to encompass component-based design using structured classes.

A «subsystem» is a type of component

In UML, components can represent collections of entities that are assembled together, for example, to create an executable (.exe file) or a library (.lib file).

A component diagram can express the relationships between components. For example, a component called Gui contains a number of files that are compiled and linked to form an executable file, Gui.exe. This file has a «Usage» dependency on the Controllercomponent, which is compiled to create a .lib file.

By expressing relationships on a component diagram, you can effectively express a compilation sequence. For example, the Controller library must be built before the Guiexecutable is linked.



2 -


14


Deployment diagramsDeployment diagrams show how UML artifacts are deployed onto hardware nodes.

Deployment diagrams share some relationship with component diagrams, in that they can express physical aspects of a system. Both the component and deployment diagrams originated from version 1 of UML. On a deployment diagram you can express physical nodes, together with how artifacts such as components are deployed to them.

In this example you see that both the HighPerformancePDA and LowCostPDS node have the Pda.exe component deployed on them, but that the HighPerformancePDA node also has a Bluetooth and Wifi component.

In UML2 you can also use composite structure to model physical assemblies. So, in a sense, the need for deployment diagrams is lessened. However, they are included here for completeness.



2 -


15


Timing diagramsTiming diagrams focus on changing conditions within and among objects on a linear time axis.

Time

Sending::Low

Sending::High

Receving::Low

Receiving::High

Sending

Receiving

Idle

Coil Driver

Transceiver

transmit(value)

Tristate

MonitorInitializing

Acquiring

ReportingIdle

send(value)

send(value)

tm(bitTime)

{1 ms +/- 0.2ms}

{3 ms +/- 0.2ms}

evDone

The timing diagram is new in UML version 2 to express timing relationships that result from interactions.

Unlike a sequence diagram that expresses time from top to bottom, a timing diagram expresses time in a linear fashion along the x axis from left to right. Along the y axis you can see the changing state of objects over time.

For example, the transceiver is in an idle state until it receives a send event, when it switches to a sending state. You can also see in the example how the coil driver oscillates over time while the transceiver is sending.



2 -


16


Communication diagramsCommunication diagrams were called collaboration diagrams in UML1. They are similar to sequence diagrams, but are generally less popular.

The communication diagram in UML2 is an alternative way to show the interactionsbetween objects in order to satisfy a particular scenario or collaboration. The methods invoked are numbered to show a sequence of calls between objects.

This communication diagram is similar to the sequence diagram, in that the same information can be shown on a sequence diagram. The sequence diagram is perhaps more common, particularly during the concrete design phase, because it is often easier to read when the number of interactions increases.

Communication diagrams, however, can be useful in the analysis phase, for illustrating how a set of candidate objects collaborate to satisfy something like a use case.



2 -


17


Interaction overview diagramsInteraction overview diagrams define Interactions through a variant of activity diagrams in a way that promotes an overview of the control flow.

sdsd

ref

dispatch_event

The interaction overview diagram is also new in UML2 and describes a high-level view of a group of interactions that are combined into a logical sequence, including control logic to navigate between the interactions.

In essence it is similar to an activity diagram that coordinates interactions.



2 -


18


How UML applies to real-time systemsReal-time UML is standard UML

“Although there have been a number of calls to extend UML for the real-time domain … experience has proven this is not necessary.” Bran Selic, Communications of the ACM, Oct 1999

Real-time and embedded applications Special concerns about quality of service (QoS)Special concerns about low-level programmingSpecial concerns about safety and reliabilitySpecial concerns about embedded Real-Time Operating Systems (RTOS)

Real-time UML is about applying UML to meet the specialized concerns of the real-time and embedded domains.

Many aspects are considered important when modelling real-time systems, such as timing requirements, memory segmentation, physical device drivers, real-time operating systems, and so on.

In response, UML2 provides many existing features that you can use to capture these aspects. The following slides give some examples.



2 -


19


Diagrams we will focus on

In this training course we focus mostly on the core diagrams shown that relate to the executable specification of a system (such as diagrams that are used for code generation).

We also explore the new additions to the language since UML2, such as the use of composite structure and UML2 extensions to the sequence diagram syntax.



Harmony/ESW Process: Microcycle

Ana

lysi

sD

esig

n

This activity iterates, typically every 4-6 weeks


Harmony/ESW Microcycle

Ana

lysi

sD

esig

n

Complex projects requiringvery high quality may add

reviews between each phase.


Prototype Definition

System use cases(mission statements,

No detail)


Object Analysis


Architectural Design


Defining the Concurrency Model


Mechanistic Design Workflow


Detailed Design


Validation


2 -


30


Module summary In this module you learned:

What the various diagrams are in UML and how to categorize theirstructure and behaviorHow to use the diagrams for development of real-time systemsHow to follow a workflow for model-driven development


Essentials of IBM Rational Rhapsody for Software Engineers Module 3: Encapsulating structure by using UML

© Copyright IBM Corp. 2012 3 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 3: Encapsulating structure by using UML

ContentsModule overview 3-2Objects 3-6Encapsulation: Hiding your private bits 3-12Module summary 3-25

Module 3 – Encapsulating Structure Using UML

Module 3 – Encapsulating structure using UML


3 -


2


Module overviewIn this module, you learn:

How to apply the principles of abstraction and encapsulation to UML using classes and objectsHow to use UML notation to express attributes and operations, including visibility adornments, class compartments, and abstract and static notation


3 -


3


Review: Why model?Modeling achieves four goals:

Helps you to visualize a system the way that you want it to bePermits you to specify the structure or behavior of a systemGives you a template that guides you in constructing a systemDocuments the decisions you have made

You build models of a complex system because you cannot comprehend such a system in its entirety.You build models to better understand the system that you are developing.

According to Booch in The Unified Modeling Language User Guide, modeling achieves four goals:

1. Models help you to visualize a system the way that you want it to be. A model helps the software team communicate the vision for the system that is being developed. It is difficult for a software team to share a unified vision of a system that is described only in specification and requirement documents. Models bring about more specific understanding of the system.

2. Models permit you to specify the behavioral structure of a system. You can document system behavior and structure before coding the system.

3. Models provide a template that guide you in constructing a system. A model is an invaluable tool during construction, it serves as a road map for a developer. Have you experienced a situation where a developer coded incorrect behavior because he or she was confused over the wording in a requirements document? Modeling helps eradicate that situation.

4. Models document the decisions you have made. Models are valuable tools in the long term because they give “hard” information on design decisions. You do not need to rely on someone’s memory.



3 -


4


Review: Basic principles of object orientation

This module focuses on abstraction and encapsulation.

Abst

ract

ion

Hier

arch

y

Object orientation

Enca

psul

atio

n

Modu

larity

Object orientation relies on four basic principles:• Abstraction• Encapsulation • Modularity• Hierarchy



3 -


5


Review: AbstractionAbstraction enables you to recognize familiar things without focusing on the detail of how they are implemented.Abstract concepts often relate to the problem domain or a particular usage context.

Autopilot

Sensor

Engine

ControlSurface

Student

Everyone can recognise the abstract concepts of a house, a plane, a bike, or a car. Abstraction is a technique that everyone uses to recognize things that are familiar, enabling us to focus on things that are important and ignore detail that is irrelevant or different.

An abstraction depends on the context of the system. For example, we might all be employees, and we could consider that all employees have payroll numbers. This is a useful abstraction if you are building a payroll system. The concept of a control surface makes sense in an avionic system.



3 -


6


ObjectsSoftware things

Occupy memory at some timeFor example, CustomerRecord, ECGSample, window, font

Electronic thingsOccupy physical space at some timeFor example, thermometer, LCD display, motion sensor, DC motor

Mechanical thingsOccupy physical space at some timeFor example, wing surface, gear, door, hydraulic press

Chemical thingsOccupy physical space at some timeFor example, battery, gas mixture, halothane

System thingsOccupy physical space at some timeFor example, power subsystem, robot arm, space shuttle

In an object-oriented system we can look for objects that represent a real-world entity in the problem domain. When you use the technique of abstraction, you focus on the objects themselves, not on how they are implemented.



3 -


7


Classes and objectsAbstraction is supported by the concept of a class. A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class is an abstraction:

It emphasizes relevant characteristics.It suppresses other characteristics.

• Many objects are identified for any domain. • Recognizing the commonalities between the objects and defining classes helps us deal

with the potential complexity. • The object-oriented principle of abstraction helps us deal with complexity.



3 -


8


Classes and objects (continued)Every object or class has:

Responsibilities:– What does it do? – Why does it exist?

Attributes:– Internal state data that is either fixed in value or variable

Behavior:– Actions that are performed to fulfill its responsibilities

An attribute is a named property of a class that describes the range of values that instances of the property can hold. (The Unified Modeling Language User Guide, Booch, 1999.)A class can have any number of attributes, or no attributes at all. At any time, an object of a class has specific values for every one of the attributes of its class.An operation is a service that can be requested from an object to affect behavior. An operation has a signature, which can restrict the actual parameters that are possible.The operations in a class describe what the class can do.In order to determine the attributes and operations of a class, it must first be clear what the class is abstracting. A class should have a clear responsibility. Avoid classes with multiple personalities. A class that has multiple things or multiple personalities is difficult to reuse, understand, and maintain.



3 -


9


A radioResponsibilities:

Playing a radio frequency for a user who listens.

Attributes:WavelengthFrequencyVolume

Behaviors:Tune to a frequencyStore and recall a frequencyChange volumeSwitch on and off

A radio is responsible for playing a radio frequency so a user can listen. It provides a number of operations to the user through its public interface, such as allowing the user to turn it on and off, turn the volume up, or listen to a required frequency.

These operations affect the internal state of the radio, for example, the stored wavelength and frequency, or its battery level, causing its internal attributes to change.

Some of the operations represent more complex behavior such as the ability to store and recall a list of favorite channels. This is where the principles of encapsulation and abstraction are useful.



3 -


10


A digital cameraResponsibilities:

Take digital photos

Attributes:Available memoryPicture resolutionBattery level

Behavior:Select resolutionFocusTake photoUpload photosBrowse existing photos

A digital camera is responsible for taking photographs.

It provides a number of public operations to the user, such as the ability to select a resolution or light-mode, or take a picture. These operations affect the internal attributesof the camera, such as consuming the remaining memory and battery levels.

Some of the operations encapsulate complex behavior, such as the ability to upload pictures to a PC or browse a history of existing pictures.



3 -


11


Discussion: A microwave ovenResponsibilities?Attributes?Behaviors?

What is the responsibility of a microwave oven?

What public operations does it provide?

How does invoking these operations affect the internal attributes of the oven?

Provide some examples where complex behavior is encapsulated by a public interface.



3 -


12


Encapsulation: Hiding your private bits Related to the concept of abstraction is the principle of encapsulation, or information hiding.

Encapsulation reduces the ripple effect. It offers two forms of protection:

Protects the internal state of an object from being corrupted by its clientsProtects clients from changes in the object’s implementation

One of the principles of object orientation is encapsulation. Encapsulation is often called “information hiding,” making it possible for the clients to operate without knowing how the implementation fulfills the interface.

Encapsulation eliminates direct dependencies on the implementation (clients depend on and use the interface). Thus, it is possible to change the implementation without updating the clients as long as the interface is unchanged.

Encapsulation offers two kinds of protection: 1. It protects an object’s internal state from being corrupted by its clients.2. It protects a client’s code from changes during the object’s implementation.

Encapsulation reduces the “ripple effect,” which happens when a correction to one operation forces the corresponding correction in a client operation, and so on.

As a result of encapsulation, maintenance is easier and less expensive.



3 -


13


Object viewsObjects generally have two different views:

The public view, which is the object as seen from outsideThe private view, which is the internal view. Access is controlled and the details are hidden from the outside world.

Objects have two different views:

• Public view—what is seen from outside the object. The public view of an object is the interface that the object exposes to the outside world, which other objects can use to communicate with it.

• Private view—the internal view. Access is controlled, and the details are hidden from the outside world.



3 -


14


Hiding attributesObjects contain their own attributes but, generally do not allowother objects to manipulate these attributes directly.If other objects need access to the attributes, the object provides public operations (known as getters and setters) to manipulate these attributes.

Hiding attributes give you the freedom to change the type of the attribute without the clients knowing about it, or having to make any changes.

Getters and setters are sometimes called accessors and mutators.

The key to encapsulation is its public interface.

The public interface of the object ensures that all communication with the object takes place through a set of predefined operations. Data inside the object is only accessible to the operations of that object. Its attribute values cannot be reached or changed from the outside.

Hiding attributes allows the freedom to change the type of the attribute without the client knowing about it or indeed having to make any changes. In order to manipulate the new attribute type, you only need to modify the getter and setter.



3 -


15


Object attributesAll objects of the same type have the same set of attributes, but different copies (so that they can have different values).Attributes are primitive in structure and behavior:

If they are rich, they should themselves be objects (we cover relationships later).

Attributes are typed values that hold information that is known to the object, for example:

value: intpatientName: string

All objects of the same type have the same set of attributes, but different copies (and possibly different values).Attributes are primitive in structure and behavior:

• If they are rich, then they should themselves be objects.Attributes are typed values holding information known to the object, for example:

• value: int• patientName: string



3 -


16


Object operationsObjects execute operations to implement behavior:

Operations are primitive behaviors such as:x = x + 1y = sin(x)^2 + cos(x)^2z = mySensor->getValue()

Operations can manipulate the attributes and call other operations.Operations can be invoked from other objects, as well as from a state machine or activity diagram that is attached to the object.

Objects execute operations to implement behavior.Operations can manipulate the attributes and call other operations.Operations can be invoked from other objects, as well as from a state machine or activity diagram that is attached to the object.



3 -


17


A class is represented in UML using a rectangle with compartments and can be shown in many ways.

On some diagrams, you might want to show just the name of the class.Sometimes, you might want to show just some of the operations. At other times, you might want to show all attributes and all operations.

Representing classes on class diagrams

Operations

Name

Attributes

A class is represented by a rectangle with the name of the class.

It is possible to show the attributes and operations of a class in compartments underneath the name. Usually an attribute compartment is shown followed by an Operations compartment.

You can choose to elide these if you wish. You can also choose which specific operations or attributes to show. For example, you might show only the public operations, or you might hand-select operations that are called only in the particular collaboration.

Since a class diagram is a view of the class model, you can also put the same class on the same diagram in multiple places, for example, to avoid having to draw relationships across other model elements.



3 -


18


An object (an instance of a class) can be shown in many ways:

UML object

It is not necessary to show every attribute, every operation, or visibility.

Attribute values at a specific time

Object name Class name

Implicitobject

Multiplicity

How many classes are shown on this diagram? How many objects are shown?



3 -


19


MultiplicityWhen showing objects, indicate how many objects there are.The multiplicity is usually 1.

How many classes are shown on this diagram? How many objects are shown?



3 -


20


Attributes and operations are features of a class.Features have these visibility adornments:

+ public– Accessible by any client of the class

# protected– Accessible only from within the same class or subclasses

- private– Accessible only from within the same class

Visibility defined

Rather than using these symbols, Rational Rhapsody uses graphical icons. These icons are also shown in the browser to aid understanding.

Attributes, methods, and operations are features of a class.

Features have these visibility icons:+ public

Accessible by any client of the class.# protected

Accessible only from within the same class or subclasses.- private

Accessible only from within the same class.



3 -


21


Constructors and destructorsEvery class has special operations that allow objects to be constructed and destroyed.

Constructors are used when an object is created. Constructors generally initialize the class attributes.Destructors are used when the object is destroyed. Destructors ensure that any allocated resources are properly returned.

Constructor

Destructor

Rational Rhapsody supports special operations for constructors and destructors that enable you to distinguish them with a special icon.



3 -


22


A static operation or static attribute is shown underlined.An abstract operation is shown in italic.

Static and abstract operations

A static operation is invoked on a class rather than an object. A static operation normally has a direct correspondence with the implementation language, for example, adding the static keyword to an operation in C++. In C++, a static operation can only access static attributes, and can be invoked on the class, for example Printer::theInstance().

An abstract operation does not have a concrete implementation. It merely defines the signature of the operation that can be invoked. An abstract operation normally has a direct correspondence with the implementation language, for example, adding the abstract keyword to an operation in C++, and avoiding the generation of an implementation.



3 -


23


Exercise 3.1: Attributes and operationsWhat are the attributes, operations, and responsibilities of the following classes?

Try this exercise on paper.



3 -


24


Exercise 3.1: Attributes and operations

This slide is intentionally blank

Try this exercise on paper.




3 -


25


Module summary In this module, you learned:

How the principle of abstraction applies in UML with the notion of classes and objects.How the principle of encapsulation applies in UML with the idea of public and private operations.How the principle of protecting attributes is realized through the use of getters and setters (accessors and mutators).How UML notation is used to express the attributes and operations, including visibility adornments, class compartments, and class notation.


3 -


26


Essentials of IBM Rational Rhapsody for Software Engineers Module 4: Object Discovery Strategies

4 -


1


Essentials of IBM Rational Rhapsody v7.6 for Software EngineersModule 4: Object discovery strategies

ContentsModule overview 4-2Object discovery strategies 4-3Module summary 4-13

Module 4 – Object Discovery Strategies



4 -


2


Module overviewIn this module, you learn some of the techniques for discovering objects in an object-oriented design.

This is a very brief introduction to object discovery strategies for real-time and embedded systems. For more detail, see Doing Hard Time by Bruce Powel Douglass, Addison-Wesley, 1999.


4 -


3


Object discovery strategiesWhen you build a new system using objects, you need to start somewhere. Where should you start?

What do Ido?

What do Iknow?

What are myresponsibilities?

The key to object-orientated design is that we aim to build collaborations of objects that satisfy a design. Ideally, each object should have a clear responsibility, and it should encapsulate some behavior or attributes that are important in that collaboration.

When performing object identification, we might have to apply more than one strategy. It is also an evolutionary process. As we get more into the analysis, we might discover new objects. As we transition from analysis (the problem domain) into design (the solution domain) additional objects and patterns are added to satisfy the needs of the system.



4 -


4


Object discovery strategiesSome of these strategies might be useful:

Identify the nouns.Walk through scenarios.Identify causal agents and control elements.Identify physical devices.Identify real world entities.Determine what coherent services must be performed.Identify the key concepts.Recognize transactional and persisted objects.Use your experience.

Techniques can often be combined to give better effect.


The following slides explore some of these strategies.


4 -


5


Identify the nounsFind nouns and noun phrases in the problem statements:• Provide a first-cut list of potential classes and objects.• Discover:

Objects of interestUninteresting objects and actorsAttributes

The first strategy is to work directly with problem statements or requirement specifications. By underlying each noun or noun phrase, you can build up a list of candidate objects. This technique is useful to gain a first-cut object list.

You can then categorize candidates as:• Objects of interest (which have complex attribute states)• Uninteresting objects and actors• Attributes of objects (simple types) that are just properties of objects

In a complex requirements specification, you might find names that are synonyms for other names. For example, an aircraft might also be called a plane or a flight. Often, it requires some domain expertise to ascertain synonyms because, in a particular system, the terms may mean different things.

Another consideration is to be sure of the system context. For example, actors are considered to be external to the system. Some of the nouns might actually represent things that do not talk directly to the system. Some of these things might need to be modeled, but others might not be modeled at all.



4 -


6


Scenarios consist of objects interacting in specific ways over time.Scenarios allow testing of class and object models:

Are all necessary facilities and services available?Do the attributes and behaviors of the object support its responsibilities?

Scenarios relate to use cases.

Walking through scenarios

Related techniques include:•Class Responsibility Collaborator (CRC) cards•Robustness analysis (boundary, control, and entity elements)

Walking through scenarios is one of the key techniques of use case analysis. It is very good at testing candidate objects and finding omissions. Walking through scenarios is most commonly done by a single person, or by a group of people play-acting the roles of the collaborating objects.



4 -


7


Identify causal agents and control elementsCausal agents and control elements are objects that provide the interface for an actor to control system behavior, such as sources of actions, events, and messages.Control elements are a specific type of causal agent that controls the actions of other objects.Examples:

Transaction controller in databaseAudio and video synchronizerAutopilotClothes washer cycle controller

A causal agent is any entity that produces an effect, or is responsible for events or results.

Think of causal agents as objects that initiate or control actions, or that inject events into the system. These events can come from outside the system. In an event-driven system, the events might cause the system to react by changing state. Causal agents are often objects that encapsulate interfaces to actors or external systems.

Control elements are objects that provide the interface for an actor to control system behavior.



4 -


8


Physical devicesCommon approach in embedded systemsDevices are often modeled as classes and objectsECG example:

HeartA/D converterSwitchButton

Physical devices are modeled either as interfaces to the hardware or as simulations. As interfaces the actual behavior is in the hardware; the software class provides a way for objects to talk to it. Less commonly, simulationssimulate actual hardware behavior.

Physical devices include the sensors and actuators provided by the system, as well as the electronic devices that the system might monitor or control.

By modeling devices that are used by the system as objects, you can encapsulate the interface that they provide from the rest of the system. You can also encapsulate behavior such as configuring, calibrating, and enabling them. Devices can be modeled as objects to store information representing their operational status.



4 -


9


Identify real world entitiesOften the system needs to model information that is related to real world entities even though they are not part of the system,and are not physical devices.These entities might represent the data that is associated with real world entities that the system must store.Examples:

Respiratory gases, air pressures, forces, chemicals, and vats

Often the system needs to model information that is related to real world entities, even though those entities are not part of the system and are not physical devices.

These entities might represent interfaces to external systems, or they might represent the data associated with real world entities that the system must store.



4 -


10


Coherent services to be performedObjects are useful where there is a set of operations that appear intrinsically bound and conceptually coherent.Objects might encapsulate:

StrategyAlgorithmCreation of complex objects

Examples: MeasurementKalman filterCommandFactoryCRC calculations

You might discover objects that encapsulate sets of services that need to be performed, for example, CRC calculations or digital filtering.



4 -


11


Key conceptsKey concepts are the fundamental abstractions in the domain.These concepts often have no physical manifestation.Examples include:

UI domain Window, icon, cursor, toolbarRobotics Task planBanking AccountOS ThreadNavigation Waypoint

Sometimes objects are defined by abstract concepts relevant to the solution. User interfaces, for example, have a taxonomy of recognizable objects such as windows, scroll bar, cursor, and radio buttons.

These objects have no physical manifestation. They exist only as abstract concepts within their appropriate domain.



4 -


12


Transactional versus persistent objectsTransactional objects arise from the need to manage or track theinteraction of other objects. They can be volatile if they disappear when the transaction completes.

Examples:– Bus messages– Data queues– Radar tracks

Persistent objects, such as information that must be stored for later retrieval, are either objects or attributes.

Examples:– A medical device must maintain an alarm history for later reporting.– Waveform data must be maintained for 20 seconds in a buffer to be

routed to a chart recorder.– Access passwords and user IDs must persist.– Calibration constants are used many times.

Transactional objects represent data that exists temporarily in the system.

Persistent objects represent data that needs to exist beyond the power cycling of the device. Persistent object data might be held in passive objects such as queues, trees, and databases, or stored on a file system.




4 -


13


Module summary In this module, you were introduced to some of the techniques for discovering objects in an object-oriented design, including:

Identifying the nounsWalking through scenariosIdentifying causal agents and control elementsIdentifying physical devicesIdentifying real-world entitiesCoherent services to be performedKey conceptsTransactional and persisted objects

This was a very brief introduction to object discovery strategies for real-time and embedded systems. For more detail see Doing Hard Time by Bruce Powel Douglass, Addison-Wesley, 1999.



4 -


14


Lab 1: Hello WorldThis lab is a starting point for getting used to the Rational Rhapsody user interface.In this lab, you create a simple model that prints “Hello World”to the console window.

Essentials of IBM Rational Rhapsody for Software Engineers Module 5. Describing behavior by using state machines, part 1

5 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 5: Describing behavior by using state machines, part 1

ContentsModule overview 5-2Module summary 5-27


5 -


2


Module overview After completing this module, you should be able to:

Describe some of the different types of object behavior.Build simple state machines, applying the key syntax associated with triggers, guards, and actions on transitions.Apply an understanding of timers onto states.Explain nested states and why they are valuable.


5 -


3


Types of behaviorBehavior can be simple:

Simple behavior does not depend on the history of an object.

Behavior can be continuous:Continuous behavior depends on the history of an object, but in a smooth, continuous fashion.

Behavior can be state-driven:State-driven behavior means that the behavior of an object can be divided into disjoint sets. Behavior can be defined that is both “reactive” and “dependent on an internal condition.”

Objects have both structure and behavior. We can categorize behavior as simple, continuous, or state-driven on the basis of how they interact with the attributes of an object over time.


5 -


4


Simple behaviorSimple behavior is not affected by the history of an object:

cos(x)getTemperature( )setVoltage(v)Max(a,b)

It can be represented by activity diagrams.…\Samples\CSamples\Flowchart

An object with simple behavior performs services on request without keeping a memory of previous services. An object with simple behavior always responds to an input in the same way, regardless of its history. Examples include simple mathematical calculations such as sine and cosine, or returning the value of a physical sensor at a particular moment in time.


5 -


5


Continuous behaviorThe behavior of an object depends on history in a continuous

way.

PID control loop:

Digital filter:

Fuzzy logic uses partial set membership to compute a smooth, continuous output

KaXn Yn

-+ DelayWn

Kb

++Vn Zn

UML is not verygood at describing continuous behavior.

An object with continuous behavior is one with an infinite set of existing conditions. Mathematical control systems, fuzzy logic, and neural networks all display continuous behavior.


5 -


6


State behaviorState behavior is useful when an object:

Exhibits discontinuous modes of behaviorWaits for and responds to incoming events

For example, a light can be:

Off

On

Flashing

State is an ontological condition that persists for a significant period of time, which is both distinguishable from other such conditions and disjoint from them. A distinguishable state means that it differs from other states in the events that it accepts, the transitions that it takes as a result of accepting those events, and the actions that it performs. A transition is a response to an event that causes a change in state.


5 -


7


Why use state machines?A state machine is an abstraction of the wanted behavior of a

system with actions, activities, and constraints.Some benefits of using a state machine are:

State machines are a more abstract view of behavior based on theperspective of an object, not the implementation.Behavioral possibilities can be defined in a primitive way using the operations of an object. A state machine constrains the use of those operations into particular sequences. When the object is constrained, the behavior of the object is more understandable and more easily tested.

Modeling an object as a finite state machine attempts to simplify behavioral complexity by constraining the overall behavioral space of an object as defined by its operations. A state machine constrains the execution of the operations provided by the object into specific sequences that occur when specific preconditions are satisfied.


5 -


8


State machines can be executedBecause state machines are formally defined, they can be

executed and visualized at the design level of abstraction.State machines can be animated. Their dynamic behavior can

be shown graphically, enabling you to interact with an event-driven system.

State machines provide for easy testing.You can focus on the abstract behavior:

Was the door locked with a card or a code? Rather than is some variable 0 or 1.

State machines provide for easy testing because you can do standard debugging, such as stepping through and setting breakpoints. Because event-driven systems wait for events before doing anything, you can interact with the application by injecting events and viewing how the objects change state. This enables you to test for the behavior you want and detect unwanted emergent behavior.


5 -


9


State machine execution


5 -


10


States, transitions, and actions

What is a state?

What is a transition?

What is an action?

A state is a distinguishable, disjoint, orthogonal condition of existence of an object that persists for a significant period of time.

A transition is a response to an event of interest that moves the object from one state to another.

An action is a run-to-completion behavior. The object does not accept or process any new events until the actions associated with the current event are complete.

An object whose behavior is captured in a state machine can be said to be reactive. The behavioral space of the object is divided into disjoint and non-overlapping conditions of existence called states. A distinguishable state means that it differs from other states in that it reacts to different events, and performs different actions and transitions as a result of receiving events. A transition is a response to an event that causes a change in state. Actions are performed on that change.


5 -


11


Basic state machine syntaxTransition syntax

trigger [guard] / action list

Guard

TransitionState

State nameTrigger

Action list

Default transition

This statechart defines two states, on and off. The default transition determines what state is entered when the object is created. The Off state has one outgoing transition. The trigger for taking the transition is evOn. If the object is in the Off state and receives the evOnevent, it checks the guard. The guard is a Boolean (true or false) condition. If the guard evaluates to false, then the event is discarded and no actions are performed. If the guard evaluates to true, then the transition is taken and the actions are performed on the transition. The object then enters the On state.


5 -


12


Entry and exit actions

Notice the order of execution of actions. The guard is checked before any actions are taken.

Entry actions

Exit actions

It is also possible to specify entry and exit actions on the states. Entry actions are performed on entry to the state. Exit actions are performed on exiting the state. Note that these actions are performed only when the transition is taken. We can view the sequence of events and actions on a sequence diagram. This is a powerful way to visualize a particular scenario that causes the object to change state and to change the order in which actions are performed.

Note that the exit actions of the exit states are executed, followed by the transition actions, followed by the entry actions of the entered state.


5 -


13


Types of eventsUML defines four kinds of events:

Signal event– An asynchronous signal is received, for example, evOn, evOff.– This is known as an event in Rational Rhapsody.

Call event– An operation call is received, for example, opCall(a,b,c).– This is known as a triggered operation in Rational Rhapsody.

Change event– A change in value occurred.

Time event– An absolute time is reached.– A relative amount of time has elapsed, for example,

tm(PulseWidthTime).

A signal event is an occurrence of interest arising asynchronously from outside the scope of the state machine. In the Rational Rhapsody standard C++ Object eXecution Framework (OxF), these are called Events. There is an associated event queuing mechanism where events are posted from external sources and then ultimately processed.

A call event is an explicit synchronous notification of an object by another. This is known as a Triggered Operation in Rational Rhapsody. With Triggered Operations, the caller of the trigger is blocked while the object receiving the trigger processes it.

A change event is an event based on the changing of an attribute value.

A time event represents the end of a specific time duration, or the reaching of an absolute time.


5 -


14


Time eventWhen an object enters a state, any timeout from that state is

started. When the timeout expires, the state machine receives the expiration as an event.

When an object leaves a state, any timeout that was started on entry to that state is canceled.

Only one timeout can be used per state. Nested states can be used if several timeouts are needed.

Entry action Time event

Exit action

A common transition in real-time systems is the timeout transition. A time event in RationalRhapsody has a special syntax tm with the number of milliseconds of the timer in brackets. The timer is started when the state is entered, and is cancelled when the object leaves the state.

This example gives the state machine for a simple CourtesyLight class. The object starts in the off state. It receives messages when the door is opened or closed (perhaps from a sensor). When the door opens, it transitions into an on state, and then performs the lightOn() exit action from the off state. When the door closes, no actions are performed, however the object transitions into a delay state, causing a five-second timer to start. If nothing else happens, then the timer expires, and the object transitions into the off state, invoking the lightOff() entry action. The delay state keeps the light on for five seconds after the door closes. Note that if the door opens and closes, then the five-second timer is cancelled and restarted.


5 -


15


tm(delay time)tm(delayTime) is specific to Rational Rhapsody, in particular:

Code is automatically generated to start and stop the timeout.This is equivalent to the second statechart where a timer is started on entering the state and stopped on exiting the state.If the timer expires, then it sends the requested event, for example, evDelay.

The tm syntax avoids the necessity to build explicit timer objects that propagate transitions to other objects that use them.


5 -


16


Transitions and discarding eventsThe state machine transitions to the specified state if the event

triggers a named transition and the guard (if any) evaluates to TRUE.

Events are quietly discarded:If a transition is triggered, but the guard evaluates to FALSE.If a transition to a conditional pseudo-state is triggered, but all exiting transition guards evaluate to FALSE.

Note:If an event cannot be handled, UML provides an option where the event can be deferred until a suitable time when it can be handled.

Rational Rhapsody does not yet handle deferred events.


Reaction in stateA reaction in state is an event that is handled without exiting the

state.

Condition connector

Parameter passed with event

Reaction in state

But, how much parking time would you get for two coins?

The question is asked in order to highlight the pitfalls of this statechart. Credit is an attribute. The time unit is set to one standard unit of time. When the credit decrements it goes to the legal Parking state even though there is no credit. That’s why you get 3 units of parking time even though there are only 2 coins. The credit <=0 evaluates to false and then the guard [else] is evaluated.


5 -


17


5 -


18


Draw the state machine for a luggage belt system. The belt starts when the start button is pressed. It runs until either the stop button is pressed, or until there is no luggage on the belt. This condition is when no luggage has been detected for the previous 60 seconds.

Exercise 5.1: Luggage belt system

For this exercise, in addition to timers, you can only use the triggers evStart, evDetect and evStop, and the actions beltOn() and beltOff().

Note that evDetect tells the object when luggage is present (perhaps from a light sensor on the belt). However, there is no notification to tell the object when luggage is not present. Assume luggage is not present if we do not receive an evDetect signal for 60 seconds.


5 -


19


Exercise 5.1: luggage belt system


For this exercise, in addition to timers, you can only use the triggers evStart, evDetect and evStop, and the actions beltOn() and beltOff().

Note that evDetect tells the object when luggage is present (perhaps from a light sensor on the belt). However, there is no notification to tell the object when luggage is not present. Assume luggage is not present if we do not receive an evDetect signal for 60 seconds.


5 -


20


ActionsActions are run to completion:

They take an insignificant amount of time to perform.They can be interrupted by another thread execution, but that object completes its action list before doing anything else.Only if the transition is taken are the actions performed (the guard is checked first).

Actions are implemented: Through the operations of an objectThrough externally available functions

Actions can occur:When a transition is takenWhen a reaction occursWhen a state is enteredWhen a state is exited

Actions are non-interruptible behaviors executed at particular points in the state machine. Actions can be sequences of actions. They can be represented by calls to operations defined within the class, or statements in a formal language.

Actions are considered to take essentially zero time. In reality, they do take time, so the focus is on ensuring that they only take an insignificant amount of time.


5 -


21


Transitions: guardsA guard is a condition that must be met for the transition to be

realized. Guards can be:Variable range specifications, for example: [cost<50]Concurrent state machine is in some state [IS_IN(fault)]

Guards are evaluated before the execution of any action.

If two guards are likely to be true at the same time, then it is a good idea to chain condition connectors so that the order in which the guards are tested is known.


5 -


22


Null-triggered transitionsAlso known as completion transitions

Triggered upon completion of any entry actions

Can contain a guard conditionAre only evaluated once, even if the guard condition later

becomes true

The guard is immediately tested upon entering the polling state since there is no trigger.If it is true, the object moves to the ready state. The guard is retested every time that the timeout occurs.


5 -


23


State machine syntax: OR statesYou have looked at OR states in which an object must be in

exactly one OR state at a given level of abstraction.The object must be in off, on, or delay. It cannot be in more than one or none.


5 -


24


…\Samples\CppSamples\HomeAlarmWithPorts

UML notation allows a state to have substates:

State machine syntax: NESTED states

If the event evDisarm is received when the object is in armed state, irrespective of which nested state is active, the transition is taken, and the object goes into the off state.

Nestedstates


5 -


25


On paper, draw the state machine for an LED class that can be in one of three modes: on, off, or flashing at 1 Hz.

Exercise 5.2: LED


5 -


26


Exercise 5.2: LED



5 -


27


Module summaryIn this module, you covered some of the basic state machine

syntax, as well as some of the benefits of using the notation toconstrain and abstract the behavior of objects.

In particular, you learned the syntax for triggers, guards, and actions on transitions, the use of entry and exit actions, reactions (in state), timers on states, and nested states.


5 -


28


Lab: Count DownIn this lab, you build and execute a running state machine.

Essentials of IBM Rational Rhapsody for Software Engineers Module 6: Describing behavior by using state machines, part 2

6 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 6: Describing behavior by using state machines, part 2



6 -


2


Module overviewAfter completing this module, you should be able to:

• Use more advanced state machine syntax, including pseudostate connectors and AND-states.

• Identify things to look out for when building state machines.


6 -


3


Quick recapQ1: What is a state?Q2: How do you get into a state?Q3: How do you know that something is a trigger rather than an

action on a transition?Q4: What are guard conditions? How do you know that

something is a guard on a transition?Q5: What are entry and exit actions? Why are they valuable?Q6: What are reaction in states? Why are they valuable?Q7: What are nested states? Why are they valuable?


6 -


4


PseudostatesUML defines several things for state machines that are almost states, but are used to combine logic or to provide additional meaning.

T

C H*

or

Symbol Symbol Name

H

Branch Pseudostate (type ofjunction pseudostate)

Terminal or Final Pseudostate

Initial or Default Pseudostate

Fork Pseudostate Join Pseudostate

Junction Pseudostate

(Shallow) HistoryPseudostate

(Deep) History Pseudostate

Choice Pseudostate

EntryPoint Pseudostate

[g]

[g]

Symbol Symbol Name

ExitPoint Pseudostatelabel

You cannot draw a choice pseudostate in Rational Rhapsody. Instead, use a state.

Figure taken from Real-Time UML: Developing Efficient Objects for Embedded Systems 2nd Edition by Bruce Powel Douglass; Addison-Wesley, 1999


6 -


5


A junction is a compound transitionIf guards are used, then the entire compound transition is treated as a single transition, for example, all guards must evaluate to true before the transition is taken.

Junctions

Common guard or action

This transition takes place under one of two conditions:setGreen Event occurs AND sigAhead = Y AND NoTrainInSection = true

OrsetYellow Event occurs AND sigAhead = YY AND NoTrainInSection = true

Only when one of these two conditions is true do any of the actions occur.


6 -


6


Submachines: Parent

Entry point connectorSubmachine reference

Exit point connector

Can you guess what this is a state machine of?


6 -


7


Submachines: Child

Entry point connector

Submachine Exit point connector


6 -


8


Nested states: Hierarchical eventsWhen an event is received, it is processed in order starting with

the innermost state until the event is processed. For example, if the event evMove is received:

If up, it transitions to down.

If down, it transitions to up.

However, if stationary, it prints:

evMove not handled


6 -


9


Draw the state machine for a mouse with extra buttons:A button allows the mouse to magnify the area around the mouse. This magnify mode is invoked and exited by pressing the magnify button (evMagnify).When in the magnify mode, if you hold the magnifybutton (evMagnifyHeld), you enter a new state where the up (evUp) and down (evDown) buttons zoom the magnification using the incMag() and decMag() operations. The mouse remains in this mode until the magnifybutton is released (evMagnifyReleased)When the magnify button is not held, the up (evUp) and down (evDown) buttons start operations up() and down()

Paper exercise 6.1: Mouse


6 -


10


Exercise 6.1: Mouse



6 -


11


Orthogonal states and regionsWhen a state has multiple orthogonal states, the object must be in exactly one substate in each active region at the same time.Orthogonal states can be called AND states. They are logically concurrent:

All active AND states receive their own copy of any event the object receives, and independently act on it or discard it.You cannot tell in principle which AND state executes the same event first.

They are not necessarily concurrent in the thread or task sense:Orthogonal states can be implemented as concurrent threads, but that is not the only correct implementation strategy.UML uses active objects as the primary means of modeling concurrency.


6 -


12


Orthogonal states and regions

Regions

Orthogonal state separator


6 -


13


Region communicationRegions can communicate through:

Broadcast events– All active regions receive their own copy of each received event, and

are free to act on it or discard it.Propagated events– A transition in one region can send an event that affects another.

Guards– That test the state of a state machine

Attributes– Since the regions have the same owner, they see all the same

attributes.

The state machine implementation can provide mechanisms to test to see if an object is in a particular state, such as IS_IN(State).


6 -


14


Communication across regionsAND state name (optional) Both sides handle the same event

IS_IN test across AND states\Samples\CppSamples\HomeAlarmWithPorts


6 -


15


State machine syntax – history, fork, and joinsInitialize both history and default state

Fork

Join

History

Diagram (must be

pair)

Junction

Terminator (calls destructor)

Final state

You only need a fork when you want to enter an AND state but not use the default substates. You only need a join when you want to exit an AND state but want to specify that a certain set of predecessor states must be true.


6 -


16


What is the output of the following state machine?

Timeouts revisited


6 -


17


Poorly formed state machine

Overlapping guards

No default state

Race condition

Conflicting transitions

Use before initialization

Must be the same event

History not initialized


6 -


18


Draw the state machine for a simple battery charger that can charge two batteries in parallel:

The battery charger starts in an idle state. When a button is pressed (evStart), the batteries start charging.However, before each battery can be charged, it must be discharged.When each battery is discharged, it sends an event (evAIsDischarged or evBIsDischarged) to the battery charger.When each battery is charged, it sends an event (evAIsCharged or evBIsCharged) to the battery charger.When both batteries are charged, the battery charger returns to the idle mode.

Exercise 6.2: Battery Charger


6 -


19


Exercise 6.2: Battery Charger



6 -


20


Module summary In this module, you learned some of the more advanced state machine syntax, including:

Use of the junction pseudostate to form a compound transitionEntry and exit point connectors, and how they enable a substatemachine to be shown on a separate diagramHow to define logically concurrent regions, including an overview of the ways in which regions can communicateThe history pseudostate, enabling a state machine to remember a previous state when reentering

You also learned some practical advice on things to look out for when building state machines.


6 -


21


Lab: DishwasherIn this lab, you build and execute a running state machine with AND states.


6 -


22


Essentials of IBM Rational Rhapsody for Software Engineers Module 7: Describing communication

7 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 7: Describing communication


Module 7 – Describing Communication


7 -


2



Recognize basic object-oriented relationships and their associated notation in the UML.Apply some of the basic principles of object oriented design.

In this module, you begin to use some of the other key principles of object orientation.



7 -


3


Object collaboration Objects work together to form cohesive assemblies called

collaborations.Collaborations work by fulfilling system-level behaviors called

use cases, through their behaviors and operations.

Autopilot

Sensor

Engine

ControlSurface

setSpeed ( )

setFlapPosition( )

getData( )

An object-oriented design consists of objects collaborating to fulfill the requirements of the system. Each object plays a role defined by its responsibilities. For objects to collaborate, there must be some communication path between them. This section looks at the types of relationship that are possible.



7 -


4


MessagesObjects communicate with each other through messages. Messages:

Synchronous for example, Function callAsynchronous for example, Posting OS message

Objects communicate with each other by invoking messages.

With a synchronous message, the caller waits until the provider is done before carrying on. A synchronous message is used to represent the invoking of a primitive operation.

With an asynchronous message, the caller is kept waiting. An asynchronous message can represent posting a message to a queue that is then processed by the provider. Messages of this type are often found in multithreaded applications and message-oriented middleware.

An analogy is that asynchronous messages are akin to mailing someone a letter, whereas synchronous messages are like telephoning someone. When you telephone, you are blocked from doing something else while communicating. If you post someone a letter, it goes into the mail system, and is eventually delivered and processed, but you can carry on doing other things.



7 -


5Module 7 – Describing Communication


Review: Class relationshipsIn order to send a message to another object, there must be

some relationship between the classes.“The semantic connection between classes” ~ Grady BoochClass diagrams are used to draw these relationships.

Abs

tract

ion

Hie

rarc

hy

Object Orientation

Enc

apsu

latio

n

Mod

ular

ity

There are four basic principles of object orientation:• Abstraction• Encapsulation • Modularity• Hierarchy

You use these principles to assemble architecture and designs. We have already covered encapsulation and abstraction to some degree. Now we begin to apply some of the other principles in order to build collaborations of objects.

The four basic principles of object orientation include:Abstraction—any model that includes the most important aspects of something while suppressing or ignoring less important details. Encapsulation—the physical localization of features that hides their implementation behind a public interface. Modularity—the logical and physical decomposition of things into small, simple groupings, which increase the achievements of software-engineering goals. Hierarchy—any ranking or ordering of abstractions into a tree-like structure.


7 -


6


Communication – Can you read this class diagram?

Can you read this diagram? Which relationships exist and what do they mean?



7 -


7


Communication – Can you read this class diagram?

Association = “uses”

Aggregation =“has a” (shows weak ownership)

Composition = “has a”(strong ownership)

Generalization = “is a type of”

Dependency

Note how you can read the relationships. For example, a composition can be read as “has a”, and a generalization as an “is a” relationship. Associations can be named, but in general this is called a “uses” (objects of type) relationship. Dependencies are the weakest form of relationship, as they do not imply that an object relationship exists. They might be used just to represent a usage of something like a library of functions.



7 -


8


Class diagrams typically contain the following relationships:

Review: Class diagram relationships

AssociationAggregationCompositionGeneralizationDependency

The next several slides explain and define each of these relationships.



7 -


9


NavigationNavigation indicates that it is possible to navigate from an

associated class to the target classRelations can indicate navigation with an open arrowhead.

Most associations are unidirectional.

Navigation allows objects to invoke services on other objects.

Lifecycles of the objects are independent.

Navigation

Relation name or label

The navigability property for a role indicates that it is possible to navigate from an associated class to the target class using the association. This can be implemented in a number of ways: direct object references, associative arrays, hash tables, or any other implementation technique that allows one object to reference another.

Navigability is indicated by an open arrow placed on the target end of the association line next to the target class (the class being navigated to). The default value of the navigability property is true (associations are bi-directional by default).

According to this diagram, the teacher teaches student objects. But, how many are there at any time? Also, can the student invoke operations on its teacher? How would you show it?



7 -


10


Review: Multiplicity and rolesFor each association, there are two multiplicity decisions to

make, one for each end of the association.Unadorned associations are assumed to be symmetric.

Multiplicity is the number of instances one class relates to oneinstance of another class.

Associations can have roles:The role name identifies the role (or responsibility) of the object in the association.

Association labels (names), are often elided in favor of role names.

Role name

Multiplicity can be defined as the number of instances of one class that relate to one instance of another class.

• For each role, you can specify the multiplicity of its class and how many objects of the class can be associated with one object of the other class.

• Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges.

• It is important to remember that multiplicity is referring to instances of classes (objects) and their relationships. In this example, a Teacher object can have one or more Student objects relating to it.

• Multiplicity must be defined on both ends of the association.



7 -


11


Review: Multiplicity indicators

2..4

0..1

1..*

0..*

1

*

2, 4..6

Unspecified

Exactly one

Zero or more

Zero or one (optional scalar role)

One or more

Specified range

Multiple, disjoint ranges

Zero or more

• Multiplicity is indicated by a text expression on the role. • The expression is a comma-separated list of integer ranges. • A range is indicated by an integer (the lower value), followed by two dots, followed by

another integer (the upper value).• A single integer is a valid range, and the asterisk symbol (*) indicates many, that is, an

unlimited number of objects. • The symbol * by itself is equivalent to “0..*”. That is, it represents any number, including

none. This is the default value. • An optional scalar role has the multiplicity 0..1. • You can use a constant, for example, N_ELEVATORS.



7 -


12


Review: What is a composition?A composition is a whole or part relationship in which the

composite has sole responsibility for managing its parts.It is shown by a diamond-filled adornment on the opposite end.Composition is a “has a” relationship where the whole both

creates and destroys part objects.Composition implies a multiplicity of no more than one with the

whole.Forms a tree with its parts.

The relationship from car to axle is modeled as a composition because if you got rid of the car, you would get rid of any axles for that car. Here are some general rules for when to use composition:

• Properties need independent identities.• Multiple classes have the same properties.• Properties have a complex structure and properties of their own.• Properties have complex behavior of their own.• Properties have relationships of their own.

Otherwise, use attributes.



7 -


13


Review: What is an aggregation?An aggregation is a special form of association that also models

a whole-part relationship.An aggregation is a “has a” relationship but is a weaker form of

composition. Nothing is implied about navigation, ownership, or lifetimes of participating objects.

An aggregation is indicated by a hollow diamond. Multiplicity is represented like other associations.

An aggregation can be defined as a special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.

• Aggregation is used to model relationships between model elements. There are many examples of aggregation: a library contains books; departments are made up of employees; a computer is composed of a number of devices. To model an aggregation, the aggregate (department) has an aggregation association to its constituent parts (employee).

• A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation.



7 -


14


AggregationMultiplicity of owners > 1 indicates a shared part. In other words,

the same object can be shared or referenced by multiple owners.

This example of the Card class forms a graph with its parts.

{Shared}By forming a graph, a class can aggregate itself (although it must be a different instance), but in composition it does not aggregate (compositions can only form trees).

An aggregation relationship that has a multiplicity greater than one for the aggregate is called shared. Destroying the aggregate does not necessarily destroy the parts. By implication, a shared aggregation forms a graph or a tree with many roots. Shared aggregations are used where there is a strong relationship between two classes. Therefore, the same instance can participate in two different aggregations.

A shared part is also known as a catalog aggregation. Note that in the figure we are explicit about sharing the parts with the {share} constraint. Otherwise, shared parts are not implied, because although they aggregate instances of the same classes, this does not mean that they are the same instances.



7 -


15


Qualified associations, aggregations, compositionsA qualifier makes it possible to sort the relations by the value of

an attribute.Qualifiers are used with a relation of multiplicity. *

A qualified association can be implemented as a balanced tree.

Qualifier

A qualifier makes it possible to sort a relation according to the value of an attribute.

When using collections, the existence of a qualifier can be used by a code generator to provide additional methods related to the collection. For example, the ability of an airline object to query its collection of member objects that are used the frequentFlyerNumber.

The AuthorCatalog, NameCatalog, and ISBNCategory all store collections of book objects. However, they can sort the books based on different qualifiers.



7 -


16


Review: What is a generalization?A generalization is a relationship among classes where one

class shares the structure or behavior, or both, of a parent class.

Defines a hierarchy of abstractions in which a subclass inheritsfrom one or more superclasses.Single inheritanceMultiple inheritance

This approach is often called an “is a kind of” or an “is a”relationship.

Generalization is shown with a solid line and closed arrowhead pointing to the more general class.

A common convention is to draw the “Super” classabove the “Sub” class.

Generalization can be defined as:A specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). (The Unified Modeling Language User Guide, Booch, 1999)

• The subclass can be used where the superclass is used, but not vice versa.• The child inherits from the parent.• Generalization is transitive. You can always test your generalization by applying the

“is a kind of” rule. You should always be able to say that your specialized class “is a kind of” the parent class.

• The terms generalization and inheritance are generally interchangeable. If you need to distinguish, generalization is the name of the relationship, while inheritance is the mechanism that the generalization relationship represents or models.

Inheritance can be defined as:The mechanism by which more specific elements incorporate the structure and behavior of more general elements. (The Unified Modeling Language User Guide, Booch, 1999)

• Single inheritance: The subclass inherits from only one superclass (with only one parent).

• Multiple inheritance: The subclass inherits from more than one superclass (with multiple parents).



7 -


17


Review: Hierarchy pillarHierarchy is one of the key pillars of OO modeling:

Decreasing abstraction

Increasingabstraction

Asset

RealEstate

Savings

BankAccount

Checking Stock

Security

Bond

Elements at the same level of the hierarchy must be at the same level of abstraction.

Hierarchy can be defined as:Any ranking or ordering of abstractions into a tree-like structure. Kinds: Aggregation hierarchy, class hierarchy, containment hierarchy, inheritance hierarchy, partition hierarchy, specialization hierarchy, type hierarchy. (Dictionary of Object Technology, Firesmith, Eykholt, 1995)

• Hierarchy organizes items in a particular order or rank (for example, complexity and responsibility). This organization depends on perspective. Using a hierarchy to describe differences or variations of a particular concept results in more descriptive and cohesive abstractions and a better allocation of responsibility.

• In a given system, there might be multiple abstraction hierarchies (for example, a financial application might have different types of customers and accounts).

• Hierarchy is not an organizational chart or a functional decomposition.• Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to recognize

similarities and differences. For example, botany organizes plants into families. Chemistry organizes elements in a periodic table.



7 -


18


GeneralizationGeneralization means two things in UML:

Inheritance– A subclass inherits structure and behavior from the superclass:

• Attributes• Operations• Relations• State machine or activity diagram

Substitutability– Liskov substitution principle: “An instance of a subclass must be freely

substitutable for an instance of its superclass.”• It is satisfactory to use the substitute instead of the intended item.• An object with a relation to a general object must be able to use the objects

derived from the general object without knowing it.

Note that when using generalization, the subtype inherits not just the attributes and operations from the superclass but also its relations and behavior.

In 2008 computer scientist Barbara Liskov received the Turing Award from the Association for Computing Machinery (ACM) for her work in the design of programming languages and software methodology that led to the development of object-oriented programming. With Jeannette Wing, she developed a particular definition of subtyping, known as the Liskov substitution principle (LSP). More formally, if S is a subtype of T, then objects of the T type in a program can be replaced with objects of the S type without altering any of the desirable properties of that program (such as correctness).



7 -


19


Extending or specializing subclassesSubclasses:

Extend by adding new attributes or operations Specialize by redefining existing operations

Inherited operation

New attribute

New operation

Virtual operations

Specialized operations

In this example the CachedQueue is a queue class that stores a queue as a file.

The CachedQueue class inherits the head, tail, and size attributes of the queue class and adds an additional attribute called filename. It also extends the queue to add a new operation called flush.

The insert and remove methods are marked as virtual. These methods are specialized by the cached queue and are overridden to provide new implementations. This design uses polymorphism and runtime dispatch of the implementation language. Essentially, when the client starts to remove or insert a queue object, the call is dispatched to either the queue or the cached queue implementation, depending on the type of the object.

Importantly, a cached queue is also a queue, and hence is freely substitutable.



7 -


20


Review: PolymorphismThe ability to hide many different implementations behind a

single interfaceInstances of the subclass are freely substitutable for instances of the superclass

The client calls the insertoperation without knowing if the queue or cached queue is being used.

itsQueue->insert(“abc”);

The Greek term polymorphos means “having many forms.” There might be one or many implementations of a given interface. Every implementation of an interface must fulfill the requirements of that interface. In some cases, the implementation can perform more than the basic interface requirements.

For example, the client can use any queue provided that it realizes the same operations. It does not matter to the client whether the queue is a queue or a cached queue.



7 -


21


Inherited state behavior 1There are two different approaches to inheritance for

generalization of reactive classes:Use custom state machines for each subclass.Reuse (inherit) state machines of parent.– Makes automatic code generation of reactive classes efficient in the

presence of class generalization



7 -


22


Inherited state behavior 2Assumes Liskov substitution principle for generalization:

You can:– Add new states.– Elaborate substates in inherited states.– Add new transitions and actions.

You cannot delete inherited transitions or states.

Subclasses:Specialized:– You can add substates.– You can reroute transitions.– You can modify action lists.

Extended:– You can add new states, transitions, and action lists.

Essentially, you can apply Liskov’s substitution principle: an object of a subclass should be freely substitutable for an object of the superclass. Thus, you can add new states and new transitions, but not remove states or transitions.



7 -


23


Example: generalization

New AND states

Modified action list

New substatesand transitions

The blower has two states: on and off.

The dual speed blower is also a blower. It can also be turned on and off. However, when it is in the on state it can be turned low or high.

The Dual Speed Multi Heat Blower is also a dual speed blower. It can be turned low or high, and you can also set it cool or warm.

Note that the Liskov substitution principle applies. If the Dual Speed Blower is a subtype of Blower, then objects of the Blower type in a program can be replaced with objects of the Dual Speed Blower type without altering any of the desirable properties of that program (such as correctness).



7 -


24


Good generalizationHere are different types of buttons that all have different

behaviors.

These buttons are different in structure, behavior, or interface.



7 -


25


Bad generalizationThe following buttons are all basically the same class.

They could all be of the class Button, with an attribute that indicates the type of button.

These buttons are all the same. They differ only in context, not in structure, behavior, or interface.



7 -


26


Ugly generalizationBeware of multiple generalization:

Gets two copies of the attribute ID.

Which execute is run?

This situation is also known as the Diamond of Death.

This is the “diamond of death.” Of course, some programming languages prevent such a possibility by banning multiple inheritance of implemented operations.



7 -


27


Association classAn association class is used when information does not seem

to belong to either object in the association, or it belongs equally to both.

Association class

Sometimes we encounter situations where a class exists only because of a relationship between two other classes. In UML, the concept of an association class can be used to capture this situation.



7 -


28


Template and generic classesSome languages, such as C++, Ada, C#, and Java, allow the

use of template or generic classes. UML allows template or generic classes to be drawn.

Templateargument

Some languages provide the ability to define template classes (also known as Generics in Ada). Essentially, the template has a number of parameters that are substituted with concrete values during compilation. An example is some kind of abstract container. At compile time we could instantiate the template class with the type of element to be contained, for example, an integer, a float, or a user-defined type. The compiler instantiates the code needed to handle the particular parameters. We can visualize the template class as shown, with the parameter of the template class in the top right corner.



7 -


29


DependenciesA dependency can be used when a class has no direct relation

to objects of another class, but uses it in some way.Dependency is a relationship between two model elements

where a change in one might cause a change in the other.It is a non-structural, “usage” relationship.

Package

Class

Component

A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier, where the client does not have semantic knowledge of the supplier. A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier might cause a change in the client.

In an object oriented design most operations are called on objects. The call of the operation (methods in c++) causes the object to change attributes or state. For example,

itsBall->move();ItsBall.draw();

This is true for associations, aggregations (a type of association), compositions, and generalizations (the OO relations).

The dependency relation is weaker because it does not imply an object is owned, rather it implies a usage of another class where objects are not used. In this essence it's a non-object oriented relation.

One example is the «usage» dependency of a class called <math.h> that provides a set of library functions. When you invoke operations such as '+' and '-' you don't invoke these on objects, rather you pass all the parameters in the call.



7 -


30


Stereotyping dependencies«stereotypes» are often used with dependencies to specify how

one item depends on the other.

Note that dependencies are often stereotyped to give them meaning. Not all such relationships are realized in code. Some relationships might capture other semantics of interest, or just be present to increase understanding.

For example:«Usage» might denote the addition of an #include statement in C++.«Bind» might denote an instantiation relationship between a class and a template class.«Satisfy» or «trace» might be used to capture a traceability relationship between a model element and a requirement that it fulfills.

UML has a number of predefined keywords. You can extend UML with new stereotype terms of your own.



7 -


31


Exercise 7.1: Elevator systemAn elevator system has two elevators and eight floors.Each floor has two buttons to call the elevator. Each button has an indicator indicating that it has been pressed. Each elevator has a button and corresponding indicator for each

floor.

Draw the class diagram.Draw two different scenarios.

Drawing the scenarios helps to verify that the class diagram is correct.

The term scenario is often used to describe the path through a particular use case. We often differentiate between “sunny day” scenarios and “rainy day” scenarios that denote exception behavior.



7 -


32


Elevator system: Class diagram




7 -


33


Elevator system: Scenario 1




7 -


34


Elevator system: Scenario 2




7 -


35



Basic object-oriented relationships and their associated notation in UML, including:

– Association– Aggregation– Composition– Generalization– Dependency

Some of the basic principles of object orientation

In this module, you began to use some of the other key principles of object oriented programming.



7 -


36Module 7 – Describing Communication


Lab: Dishwasher systemIn this lab, you extend the Dishwasher class using a class diagram to define a collaboration.

Essentials of IBM Rational Rhapsody for Software Engineers Module 8: Describing modularity and reusable components

8 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 8: Describing modularity and reusable components


Module 8 – Describing Modularity


8 -


2


Module overviewAfter completing this module, you should be able to use some of

the modeling techniques in UML2 for handling modularity, component-based design, and architectural design.



8 -


3


Review: ModularityOne of the pillars of object-oriented design is

how to handle modularity, for example, breaking complex systems into smaller modules.

Billing system

Course registration system

Course catalog system

Student management system

Often, the system under development is too complex to grasp at once. To improve understanding, the system is broken into smaller blocks that are each maintained independently. Breaking down a system in this way is called modularity. It is critical for understanding a complex system.

For example, the system under development might be a course registration system. The system itself is too large and abstract to allow an understanding of the details. Therefore, the development team broke this system into three modular systems, each independent of the others.

• Billing system• Course catalog system• Student management system

Modularity enables the system to be developed in parallel by different teams.



8 -


4


The need for interfacesWhen the button is pressed in the following model, it calls the

press() operation on the application, for example:

It is difficult to reuse the Button class because it is closely associated, or coupled with the Application class.

itsApplication->press();

This example shows a tight coupling between the Button class and the Application class.



8 -


5


Interface IButtonListenerOne solution is to add a new class to isolate the button from the

application. This class is an «Interface» in UML, and has abstract operations with no implementation.

Abstractoperation

itsIButtonListener->press();

To make Interface classes more apparent, a naming convention is often used, for example, prefix with letter I. The name of the class and the abstract operations are italicized.

One solution to reduce coupling is to introduce an Interface class. An interface is special type of class in UML that describes a set of operation signatures without a concrete implementation.



8 -


6


Interface IButtonListenerDifferent application classes can then realize the IButtonListener

interface and implement the press() operation.Realization is a special form of generalization where the parent class is an interface.

Note that the Button class is coupled to the Interface class, so that the invocation of operations is performed on its IButtonListener instance. It doesn’t matter whether the object is an elevator or a floor class.

Interfaces formalize polymorphism. They provide a way to define polymorphism declaratively, unrelated to implementation. Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces. In other words, if two objects use the same behaviors to get different but similar results, they are considered to be polymorphic. A cube and a pyramid can both be drawn, moved, scaled, and rotated, but they look very different.



8 -


7


Review: Interfaces in UMLAn interface is a coherent set of public operations or messages

(services contract). They are a special form of class. They have no implementation and generally have no attributes.Categories:

Provided interfaces: the interfaces that the element exposes to its environment.Required interfaces: the interfaces that the element requires from other elements in its environment.

Classes realize an interface by providing a method (implementation) of its operations:A class that realizes an interface is compliant with that interface.Classes might realize any number of interfaces.Interfaces might be realized by any number of classes.

Interfaces are the key to the “plug and play” ability of an architecture: any classifiers (for example, classes, subsystems, components) that realize the same interfaces can be substituted for one another in the system, thereby supporting the changing of implementations without affecting clients.

Polymorphism is one of the big benefits of object orientation. Without interfaces, there is no way to enforce it, verify it, or even express it except in informal or language-specific ways. Formalization of interfaces strips away the mystery of polymorphism and gives us a good way to describe, in precise terms, what polymorphism is all about. Interfaces are testable, verifiable, and precise.



8 -


8


Ball and socket notationAnother notation for drawing the realization of an interface is to

use the “ball and socket” notation in UML2.

“Ball and socket” notation is sometimes referred to as “lollipop and cup” notation.

To recall if this symbol means required or provided, think that there is an O in prOvided.

Provided interfaceRequired interface

The ball and socket is an alternative notation for describing the same relationship as shown on the previous slide.

The ball denotes the provision of a interface, whereas the socket denotes that the interface is being used.

Another synonym for this notation is the lollipop and cup notation.



Ports and interfacesRational Rhapsody uses ports for ball and socket notation.

Ports are another key concept in UML2 for encapsulation. Ports can be typed by the provided and required interfaces to define contracts between the class and the outside world.


8 -


9


8 -


10


What is a port?A port is a structural feature that encapsulates the interaction

between the contents of a class and its environment.Port behavior is specified by its provided and required interfaces.

Ports permit the internal structure to be modified without affecting external clients.External clients are not visible to internals.By using ports a part can provide an interface across the boundary of its enclosing structured class without revealing the internal structure of the structured class to the client of the service.

A class can have any number of ports.Each port has a set of provided and required interfaces.These interfaces can consist of synchronous or asynchronous operations, or both.

Since the port is a structural element, it is created and destroyed along with its structured class.

Each port might have multiple provided interfaces, multiple required interfaces, or a combination of both. The key concept of a port is that it isolates the classifier from the outside world. External clients do not need to know anything about the internal implementation, and the structured class is abstracted away from the provider of the external operations it requires.



8 -


11Module 8 – Describing Modularity


Response Messages

Structured class: conceptual view 2.0

Ports

Encapsulation shell

Message

Response message

(bidirectional)

The structured class has a shell that completely encapsulates its contents. The internal contents of the structured class are not visible to the outside.

The structured class can have ports. Ports are the access “windows” through which messages pass. They are covered in more detail in subsystem design. Ports are named interaction points between a classifier and the outside world.

A stimulus message is received that causes additional response messages to be sent out.


8 -


12


Composite structure in UML2Ports are often used with structured classes. A structured class contains parts or roles that form its structure

and realize its behavior.The parts or roles describe the internal implementation structure.

The parts can also be structured classes.The hierarchical structure permits a clear expression of multilevel models.

A structured (or composite) class is a class that contains parts. Parts are essentially instances of other classes.

A role is a constituent element of a structured class that represents the appearance of an instance (or, possibly, a set of instances) within the context that is defined by the structured class.



8 -


13


How can you model the following things in UML?

A PC is system that contains, among other things, a system board and a keyboard. It might be connected to either a monitor or a projector. It might also be connected to a joystick or a PDA. How could you model this using UML?



8 -


14


Modeling the PC system using compositionWe could use composition to show two different assemblies.

Composition notates a strong “has a” relationship.

Composition

In some instances we might assemble a PC system that has only a PC, display, keyboard, and PDA. In other instances we might assemble a PC system that has a PC, but has a projector instead of a display, and a joystick instead of a keyboard.

We could use composition on a class diagram to show this setup.



We could add associations to show possible relationships that might exist between instances (such as objects).

Adding associations to the class model

Associations

Problem: There is no way to cleanly specify how an instance of a PC is connected to a projector rather than a display.

Note, however, that the class diagram shows only the relationships that exist between classes. We cannot see, for example, that a particular instance of the PC is connected to a particular instance of the keyboard.


8 -


15


Alternatively, in UML2, we can use structured classes to show decomposition of a class into parts.

UML structured classes

Part

We can now show that the PCSystem1 class contains an instance of a PDA and a display, whereas PCSystem2 contains a projector and a joystick.

A structured class enables us to model what instances are involved in a particular context. For example, the PCSystem1 structured class has four parts; a display called itsDisplay, a keyboard called itsKeyboard, a PDA called itsPda and a PC called itsPC. Parts are like instances of classes that exist in the context of the owning class.

This diagram is known in UML2 as a composite structure diagram. It is useful for modeling physical as well as software system architectures, and forms the basis for much key notation in the OMG Systems Modeling Language.

The PCSystem1 class, for example, has a PC with a display, joystick, and keyboard. However, the PCSystem2 has a projector instead of a display, and a PDA instead of a joystick.


8 -


16


A link (connector) represents communications paths among parts. It can represent an association in a particular context, and can be used for initialization of attribute pointers representing the role ends.

Links (connectors) vs. associations

Link (between objects and parts)Association

(between classes)

A connector (or link) might be used to represent an instance of an association in a particular context. A code generator could use this definition to build and instantiate the composite structure and initialize the relationships between the objects.


8 -


17


Coupling between classesIn our class model, however, we are still using associations, so

the classes are tightly coupled.

Problem: The PC class needs to know about both the Display and Projector classes (and the Joystick and PDA classes).


We could improve the design with interfaces. The UML1 notation for this is:

Improved design with UML1

Problem: This still looks quite complex, doesn’t it?


Alternatively, using UML2, we could use ports and interfaceswith “ball and socket” notation.

Showing ports and interfaces instead

There are now UIrelationships between the PC and the other classes in the class model.

Provided contract Required

contract


Combining parts with ports/interfacesParts and ports are now shown in the composite structure

diagram compartments for the structured classes.

Part

Port

Using UML2, you might model the PC system with ports instead.

Ports can be contracted to specify the interfaces that are provided or required at the interaction point.

The notation of ports is combined with the lollipop and cup notation to provide a visual specification of the interaction points and their contracts.


8 -


21


This technique was introduced in UML2 for component-based design.

It supports the ability to plug and play with different classes that implement or require the same interfaces.

Port wiring to plug and play… and links (connectors) can be used to wire up the parts.

Link

You can then combine the concepts of composite structure, ports and links (connectors). The concept of ports and parts, therefore, is key to the idea of component-based design in the UML2 standard. It enables us to plug and play instances of the classes in different composite assemblies.


8 -


22


PC internalsStructured classes can be hierarchically decomposed to any

arbitrary level, enabling different levels of abstraction to be captured.

Relay connector

Behavioral port

Note here that the PC actually does nothing. All the external ports are connected to internal parts.

As the system is further decomposed, each of the parts might be a structured class which itself contains parts, enabling a system to be recursively decomposed into subsystems to any arbitrary level. This is an effective method to visualize the system architecture.

In the example shown, the PC class provides an IKeybdListener interface. However, the pKeyb port is connected to an internal part of the Motherboard type, which is actually providing this interface. We know that the motherboard is providing the interface because of the special “behavioral” port notation (an ellipse hanging off the port).

If a port is not behavioral, it is assumed to be a relay port, which needs to be connected to an internal part for the system to build correctly. A port with a relay connector to an internal part is also called a delegation port.


8 -


23


8 -


24


Benefits of using portsPorts enforce encapsulation of internal parts.

Parts can publish services across the boundary of their owning composite classes without revealing to the client of the service which part offers it.Ports are implemented by classes that provide behavioral delegation services to their clients.Since they are typed by interfaces: – Compatible ports are conjugates: one offers, the other requires the

same or a compatible interface.– Interfaces that are provided by subclasses are compatible with

interfaces that are required by superclasses.

Environment

Structured class

S1

S2

Port

Ports are optional.

Parts can publish services across the boundary of their owning composite classes without revealing to the client of the service which part offers it. They are typed by interfaces.

Compatible ports are conjugates: one offers and the other requires the same or a compatible interface.

Interfaces that are provided by subclasses are compatible with interfaces that are required by superclasses.



8 -


25


Things to remember about portsPorts are optional.

Everything you can do with ports, you can also do without them.

Ports are a design pattern.All design patterns have pros and cons.– Con: Ports require instantiation, and thus occupy memory and require

execution time.

Ports are ideal for communicating between subsystems (but they are not ideal for every class).

Ports and parts are used to specify and encapsulate architecturally significant chunks of functionality such as subsystems. Importantly, not every class in the model should have ports because they have memory and performance costs.

A good design has areas that exhibit tight cohesion, and areas that exhibit loose coupling. It is in the areas of loose coupling where ports and interfaces are useful, and in the areas of tight cohesion where other relationships such as associations and composition are useful.



8 -


26


Ports can have multiplicity

It is possible for ports to be dynamically (programmatically) connected and disconnected.



8 -


27


Flow portsFlow ports are a form of port used in SysML to model data flow.Flow ports can connect UML models to code that is generated

from other tools such as SDL Suite or Simulink.

See \Samples\CppSamples\PowerWindowWithSimulink

Flow ports in SysML have a direct arrow, rather than using provided or required interfaces.

In this instance, when either the down or up attribute changes, the new values are passed to the windowSys block. This block calculates a new position based on a control algorithm. The new position is then propagated to the window class, which receives a change event on its position port.



8 -


28


Handling concurrencyIn embedded and real-time systems, one of the key aspects you

might want to model is multithreading.In UML 2, an active class runs on own thread, and is denoted

by double vertical lines.Denoting a class as active can be accounted for in code

generation.

Rather than having double vertical lines, Rational Rhapsody uses one thick line to denote an active class.

The abstract concept of an active class in UML2 can be implemented by a modeling tool in its code generation pattern for a particular target language. For example, an active class can be mapped to the concept of a C++ thread in a particular real-time operating system, such as Win32. Conceptually, though, the application can be modeled independently of this platform-specific implementation. This notion of using abstract concepts is a powerful mechanism for reducing platform dependence and supporting concepts such as host versus target deployment to increase early testing.



8 -


29


Class diagram showing active classes

Tag values Interrupt routine

Active class

symbol

This class diagram is a specialized version of a UML class diagram that shows a number of active classes, as well as real-time concepts, such as interrupts and mutexes.

For more information, see Doing Hard Time: Developing Real-Time Systems with UML, Objects, Framework, and Patterns, Bruce Powel Douglass, Pearson Series, 1999.



8 -


30


Regrouping classes into threadsClasses can be grouped onto the same thread by using structured classes:

We can also consider the concepts of active classes with structured classes. By combining these concepts, we could group instances of classes onto the same thread by using the containment of a structured class.



8 -


31


Review1. What is polymorphism? 2. What is an interface? 3. What is a structured class?4. What mechanism do structured classes use to encapsulate

behavior?5. What is a behavioral port? How does it differ from a non-

behavioral port?6. What is an active class in UML2? What benefits do active

classes bring?

Can you answer these questions?



8 -


32



Some of the modeling techniques in UML2 for handling modularity, component-based design, and architectural design.


Essentials of IBM Rational Rhapsody for Software Engineers Module 9: Capturing use cases and requirements

9 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 9: Capturing use cases and requirements



9 -


2



Explain the purpose of use case modeling.Explain the complementary relationships between use cases and requirements.Describe the value of performing use case modeling as a team.Describe ways in which use cases can be related to other use cases to simplify your use case model.Identify some of the dangers of using use case relationships incorrectly.


9 -


3


Use case modelingThe starting point in modeling any system is deciding:

What should the system do?How well should the system perform?Who or what uses the system?

This information can be captured by using a number of use case diagrams on which you can show:

Use cases (What the system should do)Actors (Who or what uses the system)Requirements, constraints,or both (How well should the system perform)

Use cases are a powerful mechanism to bridge between what the system should do and howthe system should do it. Most importantly, use cases place a focus on understanding what the system should do before you actually build the system. You can use this analysis to identify the candidate classes of a system. You can use the use case diagram to visualize the use cases and the actors that participate in them.


9 -


4


Basic syntax

Use case

ActorSystem boundary

Relation

The first thing to notice about use case diagrams is how simple they are.

Essentially they provide a functional context diagram for the system. They do not describe the actual detail of the use cases. They tell you that the use case exists and who is involved. Nor do they tell you about how the system is constructed. The view is entirely from a functional perspective of system usage.

One of the benefits of the simplicity is that you do not need to know too much in order to read use cases. This makes them accessible to a wider audience.


9 -


5


An actor represents anything external that interacts with the system:

A hardware device

A legacy system

A human user

An actor is a role played by using the system. The same person or external system might play multiple roles.

Actors

Rather than using stick figures, you can use pictures.Supervisor

AlarmSubsystem

FireAlarm

An actor represents a coherent set of roles that users of the system play when interacting with these use cases. An actor usually represents a human, a hardware device, or some other external system.

The use case model also identifies the actors that interact with the system. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do.

It is important to realize that actors play their roles by using the system. It is therefore possible for the same actual external system or person to play multiple roles as different actors. For example, for a cash register the actual manager of a shop might also act in the role of a cashier.


9 -


6


Use casesA use case is a sequence of actions a system performs that yieldan observable result of value to a particular actor.A use case is a named capability of a system.The use case returns a result visible to one or more actors, embodying a reason why the user interacts with the system.The use case does not reveal or imply internal structure of the system.It can be used to organize requirements and help with project planning.

One convention is to use a verb plus a noun to name use cases.

Use cases are developed on the basis of the actors' needs, ensuring that the system turns out to be what the users expected. A use case is a sequence of actions a system performs to yield an observable result that is of value to a particular actor.

When developing a system incrementally, use cases provide a useful planning tool for developing the system in layers, because if we implement a use case, then by definition we expect the system to do something of value. A use case describes what a system does, but it does not specify how it does it.


9 -


7


Examples of use casesAs the system gets bigger, use cases get more abstract and high-level.

A key challenge with use cases is to capture them at the right level of abstraction. Note that as the system gets bigger, the use cases get more abstract and high-level. This abstraction plays an important role in developing the system. The use case “Retrieve Rock on Mars” is very abstract, but very important since we are building the space craft to obtain that rock sample.

If we hierarchically decompose the system using composite structure, you might have use case models that describe lower levels for each of the parts. For these use case models, the other parts of the system become actors at the subsystem level.


9 -


8


CommunicationIdentificationVerification

Review: The benefits of a use case model

User Domain expert Users

Verification

Iden

tific

atio

n

Communication

Use case

If you get use cases right, they have many benefits:

Communication with users and domain experts:• Provide buy-in at an early stage of system development.• Ensure a mutual understanding of the requirements.

Identification of system users and what the system needs to do:• Establish the requirements for the system interfaces.

Verification that all requirements have been captured:• Ensure that the development team understands the requirements.


9 -


9


Constraints and requirementsUse cases can capture functional aspects. You might also want to capture Quality of Service constraints and non-functional requirements:

Worst-case execution timeAverage execution timeThroughputPredictabilityCapacitySafetyReliability

Use cases cannot capture everything that is needed about a system; they just capture a functional perspective. Other important aspects of the system might need to be captured, such as important Quality of Service requirements and reliability constraints.

The perspectives of use cases and non-functional requirements and constraints can be considered complementary. Text requirements on their own are often misinterpreted or hard to understand. If you place them in the context of a use case, they can become clearer. Furthermore, you can use the use case to group requirements together into use case chunks of function.


9 -


10


Modeling requirementsA requirement is a statement of a necessary aspect of a system:

Functional requirementFunctional or project QoSSystem parametric requirement

UML does not have the concept of a requirement but OMG SysML (Systems Modeling Language), a profile that is heavily based on UML 2, does. A requirement is an extension (stereotyped model element) to UML.Requirements might:

Depend on (derive, elaborate, or specify) other requirementsBe collected into use casesBe satisfied by design and implementationBe verified by test elements

Although it has constraints, UML does not have the concept of a text requirement. This concept, however, can be synthesized using standard UML extension mechanisms, and forms part of the OMG SysML extension to UML for systems engineering.

OMG SysML and basic Rational Rhapsody both recognize the importance of requirements. You can model requirements as part of a model as distinct requirement elements. In Rational Rhapsody, you can place requirements on any diagram, and establish relationships from model elements to requirements using stereotyped dependencies.

The combination of visual modeling techniques with requirements management is useful for traceability. You can also use models to derive requirements that the system needs to implement.


9 -


11


Requirement relations

Requirements can connect to other model elements using stereotyped dependencies, to capture, analyze, and report on traceability.

In this diagram, you see a number of relationships that are expressed as stereotype dependencies. The meaning of these dependencies is taken from OMG SysML. They illustrate how to use stereotyping a dependency relationship to give traceability a meaning.

The derive relationship shows that a lower-level requirement is derived from a requirement in a higher-level specification. An example is the traceability from a systems requirement to a user requirement that it is intended to satisfy.

The satisfy relationship shows that a model element satisfies a requirement. For example, the primitive operation activateEmergencyRelease satisfies the SRS requirement 2.2.1.

The verify relationship shows that a test case is verifies a requirement.

By using stereotyped dependencies to express different traceability types, you can also analyze this traceability independently. For example, at one level you might want to check that all the requirements have been allocated to use cases. At another level, you might want to analyze that all the requirements have been satisfied by an element of the concrete design.


9 -


12


Identifying use casesAnswer questions such as these:

What are the primary functions of the system?What are the secondary functions of the system?What must the system interface with?Why is the system being built?

Play each actor in turn and ask:What do I want out of this system?

Identify:Capabilities (use cases)Other context participants (actors)

Identifying use cases is not easy, because there are many potential satisfactory solutions. This activity is best performed as a team.

When identifying use cases, consider both top-down and bottom-up approaches.

One approach is to play each actor in turn and ask, “What do I want out of this system?”Domain knowledge might help derive helpful use cases.

You must be careful, however, to focus on use cases as end-to-end uses of the system. A stopwatch, for example, must not have a use case for starting the timer and a different use case for stopping the timer. Rather, it must have a use case for timing a lap.


9 -


13


What use cases are notBecause use cases provide a functional decomposition model,

which is how:They do not capture how in any way.They do not capture anything the actors do outside the system.

One of the most common pitfalls is to try to capture a functional decomposition of the system by using use cases. This model is not appropriate. To capture a functional decomposition, use a different diagram, such as an activity model. Use cases are intended to capture the end-to-end use of the system from the actors’ perspective.

Do not model anything outside the system. For example, the interaction between actors is not relevant. One side-effect of use case diagrams is that they force us to identify the system boundary. This can be a useful exercise in determining the scope of the system.


9 -


14


Use case descriptionsA use case description is often structured in the following way:

NamePurpose– Can be written informally (“The purpose of the capability is to…”)

Description– Can be written semi-formally (“The system will…”)– Can be a hyperlink to an external textual document

Preconditions– What is true before the execution of the capability?

Postconditions– What does the system guarantee to be true after the execution of the

use case?Constraints– Additional QoS requirements or other rules for the use case

No firm rules can help with writing use cases, partly in recognition that use cases can be used for many different audiences. Bear in mind your audience when you write the use case.


9 -


15


Detailing use cases: Description

This use case description is written using the Description field of the use case within Rational Rhapsody. One benefit here is that you can drag hyperlinks from model elements into the description field.This provides more elaboration about the use case.

Some people like to use a Microsoft Word document with a table format. An alternative mechanism in Rational Rhapsody is to add these to the model as “controlled files” and add a hyperlink to them from the use case.


9 -


16


Use case relationsUse cases can be related to one another using relationships. There are three primary relations:

Generalization– One use case is a more specialized or refined version of another.

<<include>>– One use case includes another.

<<extend>>– One use case provides an optional extension of another.

The point is to capture requirements, not to decompose the system functionally. Many use case diagrams are realized without needing to use any of these relations.

To relate use cases to one another, use case relations. You can show where requirements intersect, are elaborated, or are decomposed.


9 -


17


Use generalization when one use case is a more specialized form of a parent use case.Use generalization when:

The use cases are at a different level of abstraction.The more general use case represents requirements and relationships that are common to the specialized use cases.

Use case generalization

The key point about generalization is that it is an end-to-end replacement of the general use case. Also, it inherits all the relations of the general use case. Hence, the use of generalization can help simplify your diagram.


9 -


18


Use «include» when a common capability is required by more than one use case, and you do not want to repeat it.Use «include» when the included use case is used by more than one use case, and has multiple alternate flows.Use «include» to reference an included use case in its own partition of a more general use case scenario.

Use case «include» dependency

The include relationship is generally the one which causes the most problems, because it is easy to misuse for functional decomposition. Be careful to use it only when a section of the use case must be refined because of its complexity. Generally, this occurs later in the elaboration phase when you have explored all the alternate flows and you know what the steps are. Remember that the use case needs to capture the end-to-end use of the system, not a functional decomposition of what the system does.

If your included use case has only one step in it or only one scenario, question whether it is necessary at all. Generally, use an include relation only when the same steps are reused in other use cases.


9 -


19


Use case «extend» dependencyUse «extend» to add optional capabilities at named extension points.Insert the extended use case only in a subset of the scenarios for the primary use case.

In UML modeling, you can use an extended relationship to specify that one use case (the extension) extends the behavior of another use case (the base). The extend relationship specifies that the extension use case is incorporated only depending on what happens when the base use case executes. The extension use case owns the extend relationship. You can specify several extended relationships for a single base use case.

Although the base use case is defined independently and is meaningful by itself, the extension use case is not meaningful on its own.


9 -


20


Use case flow of eventsHas one normal, basic flow Several alternative flows

Regular variantsOdd casesExceptional flows for handling error situations

A use case flow of events: • Contains the most important information derived from use-case modeling work. • Describes the flow of the use case flow clearly enough for an outsider to easily

understand it. • Presents what the system does, not how the system is designed to perform the required

behavior.

When specifying the flow of events, the content must:• Detail the flow of events. Answer all “what” questions. Remember that test designers

will use this text to identify test cases.• Describe how the use case starts and ends. • Describe the flow of events, not only the functions. To reinforce this, start every action

with “When the actor . . . ”.• Describe only the events that belong to the use case and not what happens in other use

cases or outside the system. • Describe the data that is exchanged between the actor and the use case. • Avoid describing the details of the user interface unless they are needed to provide an

understanding the behavior of the system. • Avoid vague terminology such as “for example”, “etc.,” and “information”.


9 -


21


ScenariosA scenario is an instance of a use case.

Each use case usually has a few to several dozen scenarios of interest.

A scenario is an instance of a use case. It is one flow through a use case.

Each use case has a web of flow of events, with a scenario being an instance of a particular flow of events. The scenario might involve the basic flow and any number of alternative flows in any number of combinations.


9 -


22


Detailing use cases: ScenariosThe first scenarios to capture are the sunny day scenarios. These scenarios are the normal ones, where the system functions in the expected way.After the sunny day scenarios, you can try to find the rainy day scenarios. These scenarios are the ones where exceptions occur, such as when something malfunctions.Many, but not all, use cases are originated by an actor.An almost infinite number of possible scenarios are often possible, so it is important to capture just the important scenarios:

Interestingly different scenariosScenarios that span all interesting variants of behaviorScenarios that add requirements

You must elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be used to understand, as well as to validate, each flow of events in the use case. Some people write scenarios first and extract use cases, while others identify use cases first and validate those use cases by writing scenarios.


9 -


23


Sequence diagrams as use case scenariosScenarios can be described in text, but more often than not, they are captured using sequence diagrams.Sequence diagrams show system elements collaborating over time.

It is common to show actors and a black box system instance collaborating on a sequence diagram.A sequence diagram generally shows a single path through a use case.Sequence diagrams can also be used as test cases.

“Black box” means looking at the system interaction from the perspective of the outside world (actors), rather than internal interactions.

You can model scenarios as sequence diagrams. By using sequence diagrams you can capture the interaction between the system and an actor graphically. You might start with a black box view of the system and then elaborate it into a white box view after you are satisfied that the interaction with the actors is correct.

Scenarios modeled as sequence diagrams also make excellent test cases. These diagrams describe a sequence of interactions that are expected to be valid, together with a specification of what happens when the system receives an ordered sequence of messages.


9 -


24


Sequence diagram: Entering a pin code

Instance of a use case

TimingMessage

Instance of an actor

Partition line and note

You read a sequence diagram from top to bottom to understand the sequence of interactions. In this case, the interactions are between actors, which are external to the system, and the system itself. A lifeline is used here to capture the system interactions that are relevant to the use case. This sequence diagram shows the scenario where a visitor enters four digits on the pin pad in less than 10 seconds, which is an explicit timing constraint. The diagram adds some contextual information to help the reader.


9 -


25


Sequence diagram: Valid pin code

Reference sequencediagram

Timeout

This sequence also shows a “sunny day” scenario. This case reuses the entering pin code sequence diagram in the reference interaction fragment. This feature is added to sequence diagrams in UML2 to make them easier to read and maintain.

In this sequence diagram, the visitor swipes a card, enters a valid four-digit pin code, and the door unlocks. A timeout annotation shows that the door relocks after fifteen seconds.


9 -


26


Sequence diagram: Invalid pin code

In this rainy day scenario, the visitor swipes a card, enters an invalid pin code, and the system gets the door to sound a warning. The user makes two more attempts, but each time with an invalid code. After the third attempt, the system notifies the Security actor of an “invalid pin alert.” The postconditions make it clear that the door is locked, security is alerted, and the card is blocked.


9 -


27


Exercise 9.1: Filling stationDraw a use case diagram for a fuel filling station system:

Before fuel pumping is allowed, an electronic image of the car and the motorist must be taken and recorded.The motorist fills the car with fuel manually.Several payment options are available: – The motorist can swipe a credit card at the pump, but only before fuel

is dispensed. – The motorist can also pay by credit card inside the booth by handing

the card to the teller. The teller swipes the card through the card reader, which interfaces with the electronic payment system (EPS). Cash payment is also accepted.

– If the motorist swipes a loyalty card at the pump or in the booth, the readout shows current points.

For safety, the fuel pump automatically disconnects the fuel supply after three minutes, or if the pump handle is replaced, whichever is sooner.

Do this exercise on paper.


9 -


28


Fuel filling station use case diagram



9 -


29


Detailing use casesUse cases are usually detailed with a text description and are often supplemented:

Sequence diagrams– A scenario captures a specific path through the use case.– Scenarios are described by using sequence diagrams.– The number of possible scenarios is infinite, so you must select

scenarios that are interestingly different.– Non-technical users can understand scenarios.

Activity diagram– An activity diagram can help describe the sequence of actions that

occur, especially if they are concurrent.State machine– A state machine can help capture all the various modes of the use case

(some non-technical users might struggle to understand these diagrams).

As well as using text and sequence diagrams, you can also capture use cases as activity diagrams and state machine diagrams.


9 -


30


An activity diagram can capture the activities in a use case.An activity diagram is like a flow chart that shows the flow of control from one activity or action to another.

Detailing use cases: Activity diagrams

Initial node Action node

Edge

Guard

Decision node

Activity final

Merge node

An activity diagram can be used to capture the activities in a use case. It is essentially a flow chart that shows the flow of control from one activity or action to another.

The workflow of a use case describes what the system needs to do to provide the value that the served actor is looking for. It consists of a sequence of activities that, together, produce something for the actor.

The workflow often consists of a basic flow and one or several alternative flows. The activity diagram shows the structure of each workflow graphically.


9 -


31


Detailing use cases: Activity diagrams with partitions

This example shows a black box view of a use case. The partitions (or swim lanes) allocate actions to the participants in the use case. This approach can also allocate activities (the functional aspects of the system) to the internal structural elements that must perform the action or activity.


9 -


32


Detailing use cases: State machines

Another approach is to assemble multiple scenarios that show the system interaction into a single executable specification. Integrate the scenarios into a state machine diagram for the use case.

The state machine diagram uses states to constrain the order in which actions are performed and how the system reacts to certain events when in a particular state. The diagram can be executed to find emergent behavior of the system and explore alternate flows.

You can use the resulting sequence diagrams from this execution as test cases for the system, or to specify to implementers what the expected behavior of the system is in certain scenarios.


9 -


33


Exercise 9.2: MP3 playerDraw a use case diagram for an MP3 player:

The MP3 player must play both MP3 and WMA formats initially. It must be possible to support other future formats.The user must be able to connect the player through a USB connection to a PC in order to upgrade the software through the Internet and to download music files.The user must be able to browse the music on the player and select the music by artist, album, or track.The user must be able to stop, start, pause, fast forward, fast reverse, select next and previous tracks, and so on.The player should show the name of the artist and title for the current track.The player must play continuously for at least eight hours without a battery change. To save battery life, the player switches off one minute after the music stops.

Perform this exercise on paper.


9 -


34


MP3 player use case diagram



9 -


35



The purpose of use case modelingThe complementary relationships between use cases and requirementsThe value of performing use case modeling as a teamHow to relate use cases to other use cases to simplify your use case modelThe dangers of incorrectly using use case relationships

Essentials of IBM Rational Rhapsody for Software Engineers Module 10: Advanced sequence diagrams to show interactions

10 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 10: Advanced sequence diagrams to show interactions



10 -


2



Identify the different syntax for synchronous and asynchronous messagesDecompose sequence diagrams, showing conditional logic, parallel behavior, and iterative logic on sequence diagramsUse the techniques for expressing timers and state condition marks in sequences


10 -


3


Sequence diagramsSequence diagrams show system elements collaborating over time.

Vertical lines (lifelines) represent instances of a subsystem, use case, actor, object, or other classifier.Horizontal lines with arrows between instances represent messages that are sent to or received from elements of the system.The vertical axis of the diagram denotes time, and it advances from top to bottom.It is common to show actors and a black box system instance collaborating on a sequence diagram.Often sequence diagrams show a single path through a use case (ascenario). A single use case might therefore own multiple sequence diagrams.

You can model scenarios as sequence diagrams. You can capture the interaction between the system and an actor graphically. You might start with a black box view of the system and then elaborate this into a white box view when you are happy that the interaction with the actors is correct.

Scenarios that are modeled as sequence diagrams also make excellent test cases. They describe a sequence of interactions that are expected to be valid, together with a specification of what happens when the system receives an ordered sequence of messages.


10 -


4


Asynchronous and synchronous messages

The arrowheads are different for asynchronous and synchronous operations.

Synchronous operation

Asynchronous operation

Environment (system border)

To show an object (lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if it is a synchronous call operation) or with a stick or open arrowhead (if it is an asynchronous signal). Place the message or method name above the arrowed line. The message that is being sent to the receiving object represents an operation or method that is implemented by the class for the receiving object.


10 -


5


(Optional) showing concurrency

Different colors can be used on activation bar to show different threads.

Execution occurrence (optional)

One (non-UML) technique for handling concurrency in sequence diagrams is to use the activation bar and to color it.


10 -


6


Constructors, destructors, timers, and state marks

State or condition

mark

Expired timeout

Destructor

Constructor

Canceled timeout

In this sequence diagram you can visualize what happens when an alarm system detects an over temperature event.

The state or condition mark indicates that the AlarmManager is starting in a normal state. When it receives an evOverTemp event, it creates an alarm object, sets an ALARM_CLEAR_TIME timer, and enters an alarmed state.

The constructor for the alarm object instructs the display object to show an “over temperature” message and sets a timer on itself for the ALARM_DISPLAY_TIME.

This scenario shows the alarm object timer expiring, causing the display to clear the “over temperature” message. However, the ALARM_CLEAR_TIME timer does not expire, as you can see from the cancelled timeout with the dashed line. The AlarmManager timer does not expire because an evNormal event is received. This causes the AlarmManager to destroy the alarm object and re-enter the normal state.


10 -


7


Combined (interaction) fragment operators

sd – named sequence diagramref – reference to interaction fragment

loop – repeat interaction fragmentopt – optional behavioralt – selectionpar – concurrent (parallel) regions

seq – partial ordering (default, weak)strict – strict ordering

critical – identifies atomic fragmentsassert – required (for example, causal)neg – cannot happen or a negative specificationignore/consider – msgs. outside and inside causal stream

Flow of control

Naming

Ordering

Causality

In most sequence diagrams, the UML 1.x "inline" guard notation was not sufficient to handle the logic required for a sequence being modeled. This lack of functionality was a problem in UML 1.x. UML 2 has addressed this problem by removing the "inline" guard and adding a notation element called a combined fragment. A combined fragment groups sets of messages together to show conditional flow in a sequence diagram.


10 -


8


Lost and found messages, and loops

Found message

Reply message

Object destructionLost message

Loop operator

Occasionally, you need to model a repetitive sequence. In UML 2, modeling a repeating sequence has been improved with the addition of the loop combination fragment. The loop combination fragment looks similar to the other fragment types. You draw a frame, and in the frame's name box you put the text "loop." Toward the top of the content area for the frame, you put the guard for the loop.

(Optional) Besides just showing message calls on the sequence diagram, you can also include return messages. Draw a return message as a dotted line with an open arrowhead back to the originating lifeline, and above the line you place the return value from the operation. The use of return messages depends on the level of detail or abstraction that you are modelling. Return messages are useful if finer detail is required; otherwise, the invocation message is sufficient.

Also shown here are “lost” and “found” messages:A found message is a message that is received, but its origin is unknown.A lost message is one that was sent, but never reached its destination.


10 -


9


Parallel regions and data flows

Data flow

Parallel regions

Use the parallel combination fragment element to show parallel processing of interactions.

Draw the parallel combination fragment by using a frame, with the text “parallel” (or “par”) in the frame's name box. You then break up the content section of the frame into horizontal operands separated by dashed lines. Each operand in the frame represents a thread of execution done in parallel.


10 -


10


Referencing interaction occurrences:

Horizontal decomposition

Interaction occurrence

\Samples\CppSamples\Handset

When working with sequence diagrams, developers often reuse existing sequence diagrams in the sequences for their diagrams. UML 2 introduced the interaction occurrenceelement, which is arguably the most important innovation in UML 2 interaction modeling. Interaction occurrences add the ability to compose primitive sequence diagrams into complex sequence diagrams. You can use them to combine (reuse) the simpler sequences to produce more complex sequences. The result is abstracting out a complete, and possibly complex, sequence as a single conceptual unit.

An interaction occurrence element is drawn using a frame. The text "ref" is placed inside the frame's namebox, and the name of the sequence diagram being referenced is placed inside the frame's content area along with any parameters to the sequence diagram.


10 -


11


Messaging between structured classes:

Vertical decomposition

Part decomposition

Other interactions can be referenced from a lifeline.

In this example, a high-level scenario shows the interactions that occur between varioussubsystems. The connection management subsystem is decomposed into parts using a UML2 composite structure diagram.

What happens internally in the Connection Management subsystem can be shown by referencing the internal sequence diagram from the lifeline. The higher-level sequence diagram can be kept in sync with the lower-level sequence diagram with minimal impact. The actual detail of what happens is kept on a separate diagram, and thus the abstract view is preserved.


10 -


12


Interaction operator: option and alternatives

Alternatives are used to designate a mutually exclusive choice between two or more message sequences. Draw an alternative fragment element by using a frame, and place the word "alt" inside the frame's name box. Divide the larger rectangle into what UML 2 calls operands, each with a guard. Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline. If an operand's guard equates to "true," then that operand is the operand to follow.

The option combination fragment models a sequence that occurs, given a certain condition; without that condition, the sequence does not occur. An option models a simple “if then”condition. The option combination fragment notation is similar to the alternation combination fragment, except that it has only one operand and never has an "else" guard. To draw an option combination, draw a frame. Place the text "opt" inside the name box of the frame, and in the content area place the option's guard toward the top left corner on top of a lifeline. Place the sequence of messages for the option in the remainder of the content area.

When you model a sequence diagram, an object sometimes must send a message to itself. To draw an object that calls itself, draw a message as usual, except that instead of connecting it to another object, you connect the message back to the object itself. Do not confuse this with the timer.


10 -


13


Interaction operators: Weak sequencingThe order is not

important, but all messages must be received.

The seq operator represents a weak sequencing between the behaviors of the operands. Weak sequencing is defined by the set of traces where the ordering on different lifelines from different operands can be in any order.

Seq or weak sequencing contrasts with the interactional operation strict which designates that the fragment represents a strict sequencing between the behaviors of the operands. The interaction operator strict designates that the fragment represents a strict sequencing between the behaviors of the operands.


10 -


14


System must not be interrupted during these operations.

Interaction operators: critical region

The interaction operator “critical” (or “critical region”) designates that the fragment represents a critical region. A critical region means that the traces of the region cannot be interleaved by other operations (on those lifelines covered by the region). This means that the region is treated atomically by the enclosing fragment when determining the set of valid traces. Even though enclosing fragments may imply that some operations may interleave into the region, such as with par-operator, this is prevented by defining a region.


10 -


15



The different syntax for synchronous and asynchronous messagesHow to decompose sequence diagrams, showing conditional logic, parallel behavior, and iterative logic on sequence diagramsTechniques for expressing timers and state condition marks in sequences


10 -


16


Essentials of IBM Rational Rhapsody for Software Engineers Module 11. Extending UML

11 -


1


Essentials of IBM Rational Rhapsody v7.6for Software EngineersModule 11: Extending UML



11 -


2


Module overviewAfter completing this module, you should know how to extend UML and understand the potential benefits.


11 -


3


Extending UMLPrimary lightweight extension mechanisms:

Tagged value– An extra model property to hold and convey additional meaning– Examples: worst-case execution time, author, complexity

Stereotype– A special type of model element (can have tags)– Examples: active class, hardware class, internal use case– Shown with « » for example, «subsystem»– Can inherit from other stereotypes

Constraint– A user-defined rule to ensure that the model is well formed– Can use tags and assign it to stereotypes


11 -


4


ProfilesA profile is a coherent set of stereotypes, tags, and constraints:

Specializes UML for a vertical market domain, business environment, or companyCan also add a library of model elements (for example, types)

In Rational Rhapsody, you can use profiles to apply custom Rational Rhapsody properties settings to a model.


11 -


5


Associating tags with stereotypes


11 -


6


Task diagramsFor example, you can use a class diagram to create a task diagram that shows only model elements that are related to the concurrency model:

Active objects (primary)Semaphore objects (optional)Message and data queues (optional)Constraints and tagged valuesInterrupt routines

See next slide.


11 -


7


Class diagram showing tasks

Active class

symbol

Interrupt routine

Tag values

This is a standard class diagram in UML2. It shows aspects of the system that relate to real time.


The following slides show some examples of profiles that extend the profile by defining new terms and new diagram toolbars.

Examples of profiles


11 -


8


Example: OMG SysML profile \Samples\SystemSamples\Distiller

UML 2.1 SysML 1.0

UML4SysML

The OMG Systems Modeling Language (OMG SysML) profile is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. The SysML profile is one of the most widely used extensions to the UML supporting extensions for requirements analysis, architectural design, and parametric modeling.


11 -


9


11 -


10


Example: UML2 Testing profile

\Samples\CppSamples\TestConductor\CppCarRadio

The UML Testing profile in Rational Rhapsody is an implementation of the OMG Testing profile, which extends the UML to support testing concepts such as test cases, test contexts, and test components. The Test Conductor Add On for Rational Rhapsody uses this profile to define tests by using UML diagrams such as sequence diagrams, activity diagrams, and state machines diagrams as well as scripted tests. You can trace tests to requirements in the model, execute them as a regression suite, and analyze and store the results in the Rational Rhapsody project.


Example: AUTOSAR_31 profile \Samples\Automotive\LightsManager

The Automotive Open System Architecture (AUTOSAR) profile is a standardized and open automotive software architecture that was developed in collaboration by automobile manufacturers, suppliers, and tool developers. IBM Rational Rhapsody provides tools that you can use for the automotive industry that provide specification and design of automotive systems and software applications.

Rational Rhapsody provides the model-driven development environment that is needed for AUTOSAR for both the Unified Modeling Language (UML) and Systems Modeling Language (SysML). AUTOSAR profiles make it possible for engineers to reuse specifications for common vehicle features across multiple automotive lines. You can use these profiles in Rational Rhapsody for the architectural description of an AUTOSAR model that uses the native AUTOSAR concepts.


11 -


11


11 -


12


Example: DoDAF/MODAF/UPDM \Samples\UPDM\WaterLogistics

The IBM Rational Rhapsody DoDAF, MODAF, and UPDM Add On software offers the defense industry a comprehensive Department of Defense Architecture Framework (DoDAF), Ministry of Defence Architecture Framework (MODAF), and Unified Profile for DoDAF/MODAF (UPDM) solution. These profiles create an advanced modeling environment to support the design, construction, and analysis of DoDAF-, MODAF- and UPDM-compliant architectures.


11 -


13


Module summaryAfter completing this module, you know how to extend UML and understand the potential benefits.


11 -


14


Essentials of IBM Rational Rhapsody for Software Engineers Module 12: UML exercise solutions

12 -


1


Essentials of IBM Rational Rhapsody for Software EngineersModule 12: UML exercise solutions (and stopwatch, speed camera, and microwave)

ContentsExercise solutions 12-2Optional test questions 12-13Optional extra exercises 12-15Recommended reading 12-25Further information 12-26Course Survey 12-27

Module 12 – Exercise Solutions


12 -


2


What’s next?

> = Current topic

> Exercise solutionsOptional test questionsOptional extra exercises



12 -


3


Exercise 3.1: Attributes and operations



12 -


4


Exercise 5.1: Luggage belt system



12 -


5


Exercise 5.2: LED



12 -


6


Exercise 6.1: Mouse



12 -


7


Exercise 6.2: Battery charger



12 -


8


Exercise 7.1: Elevator system (class diagram)



12 -


9


Exercise 7.1: Elevator system (sequence 1)



12 -


10


Exercise 7.1: Elevator system (sequence 2)



12 -


11


Exercise 9.1: Filling station



12 -


12


Exercise 9.2: MP3 player



12 -


13


What’s next

> = Current topic

Exercise solutions> Optional test questions

Optional extra exercises



12 -


14


Day 1: A test1. UML is an international standard. Which organization steers its

development?2. In 2005, UML went through a major revision cycle. What was the new

version called, and what was the main purpose?3. Is UML a purely object-oriented notation? 4. What is the purpose of a profile in UML?5. What is SysML and its relationship with UML?6. Which diagram in UML provides a functional context diagram for the

system, that is, what is inside versus outside the system?7. Describe the difference between activity diagrams and state machine

diagrams.8. What is the difference between a class and an object? How can you

synthesize a class in C or Ada? 9. In an OO implementation, you often create accessors and mutators. What

are they, and what is their purpose?



12 -


15


What’s next?

> = Current topic

Exercise solutionsOptional test questions

> Optional extra exercises



12 -


16


Stopwatch exercise (1 of 2)The goal is to build a simple stopwatch that has a single button and a display. The stopwatch displays minutes and seconds up to a maximum of 99 minutes and 59 seconds.Every time the button is pressed and released within 2 seconds, the stopwatch starts or stops.However, if the button is pressed for longer than 2 seconds, the stopwatch resets to 0.



12 -


17


Stopwatch exercise (2 of 2)Imagine that an ISR (interrupt service routine) triggers every time that a key is pressed or released, and generates evPress or evRelease events.A colon between the minutes and the seconds (such as 00:04) flashes to indicate that the stopwatch is running.Build a model of a stopwatch that can be stopped, started, and reset by injecting evPress and evRelease events.



12 -


18


Speed camera exercise (1 of 2)The goal is to build a speed camera system. This system hasfour cameras, to be installed equidistant from each other. It must be easy to change the number of cameras. Each camera can read and decode a number plate of a vehicle. Whenever a vehicle passes a camera, the number plate is read and sent to the speed camera system.The speed camera system checks the average speed between adjacent cameras. If any vehicle takes less than the allowed time (combination of the speed limit and the distance between cameras) to pass between two cameras, then it is reported as speeding.



12 -


19


Speed camera exercise (2 of 2)After a vehicle passes the last camera, any retained informationis discarded.Assume that every camera receives the evVehicle(aNumberPlate) event every time a vehicle passes.The speed camera system must print out the number plates of all vehicles that it detects as speeding.



12 -


20


Additional exercisesIf the UML training is extended, there is time for the following two exercises.For both exercises, proceed as follows:

Draw a use case diagram.Draw a class diagram.Draw sequence diagrams for all interesting scenarios.Draw statecharts for all reactive objects.

If you want to draw the models in Rational Rhapsody, supply the requirements in a Microsoft Word document that you can import into Rational Rhapsody by using the Rational Rhapsody Gateway.



12 -


21


Microwave ovenDesign a microwave oven that satisfies the following requirements:



12 -


22


Electronic safe – Requirements 1Design an electronic safe that satisfies the followingrequirements:



12 -


23


Electronic safe – Requirements 2



12 -


24


Electronic safe – Requirements 3



12 -


25


Recommended reading




12 -


26


Further information Additional training

www.ibm.com/trainingRational software training: http://www.ibm.com/training/us/catalog/rational/

Information Center (online help)http://www.ibm.com/support/publications/us/library/index.shtml#softwarehttp://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/index.jsp

Supporthttp://www.ibm.com/planetwide/http://www.ibm.com/support

DeveloperWorks for webcasts, workshops, white papers, demos, and so onhttp://www.ibm.com/developerWorks/rational

Forumshttp://ibmforums.ibm.com/forums/category.jspa?categoryID=208

Blog

Facebookhttp://m.facebook.com/?w2m&refsrc=http%3A%2F%2Fwww.facebook.com%2F&_rdr

Twitterhttp://twitter.com/ibmrational

Books and articles



12 -


27


Course surveyComplete the course survey

If you have web access in class– http://osart.atlanta.ibm.com

If you do not have web access, an email will be sent to you– Provide the instructor with your:

• Name• Email

– Please wait for the email

Class Number: __________Provided by instructor

Course Code: _______If you are taking multiple courses, please complete a survey for each course and request certificates for each as well.


12 -


28



Essentials of IBM Rational Rhapsody for Software Engineers Module 13 - Advanced Topics



1


Essentials of IBM Rational Rhapsody for Software Engineers v7.6Advanced Topics

ContentsReverse engineering and code-centric development 13-3Triggered operations 13-19Introduction to the Rhapsody framework (OXF) 13-27Managing interrupts 13-62Multicore development 13-65Generating reports 13-71Using the Java API 13-82Collaborative working – understanding units 13-95Configuration management 13-119Rhapsody in Eclipse and Jazz/Rational Team Concert 13-136Introduction to Test Conductor 13-146Useful tips 13-160Avoiding common mistakes 13-165Generating support requests 13-172Module summary 13-180Further information 13-181Course Survey 13-182




2


Module overviewNow that you know the basics about IBM Rational Rhapsody, you should be able to start creating your own projects. At the end of this section, you should have an understanding of topics such as:

Reverse Engineering/Code-centric developmentThe Rational Rhapsody FrameworkGenerating reportsUsing the APIMulticore DevelopmentUsing Configuration ManagementRational Rhapsody TestConductor




3


What’s next?

> = Current topic

>Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests

What is Reverse Engineering? There are many different definitions for this term in the world of software. The definition that applies to this presentation is the following:

Source code is already available for reuse, but higher-level aspects of the program, perhaps poorly documented or documented but no longer valid, are discovered. Through the process of reuse you are able to reuse and document your source code in a model. It can also mean going backward through the development cycle.




4


CodeCentric

CodeCentric

Code in the world of Model Driven Development

Code is the masterEverything is done in the code and should stay exactly as-is

Code Construction

Software Architectureand Design

Using implementation languageGenerating readable code

Open frameworkModel-Code Associativty

Model-Code co-Debugging

Model-is-codeFrom the modelCode is “black box”One-way development flow

ExecutableModels

Model-driven development brings many advantages to developers. Switching over to it is an involved change. Many software teams are reluctant to make the change. The goal of this presentation is to review technologies and capabilities that bring model-driven development into software teams. Model Centric: No production code, code is “ugly”, The flow is in one direction – from model to code. Code Centric: The developer knows their (external) code; the model is used for communication, review etcIn between – the code aware developers want to do model-driven development but they want high quality code. If they do a change in either the code or the model, they want the change to be made in both places.




5


Code centric workflows with MDD

Visualize legacy/external codeOn-going coding with updated documentationCode-centric developmentModernizing code using model-driven development

Model

Code

Project time line

Model is being used in first stages of the project

But as the project progresses the code is what “matters”

In between model-centric and code-centric – the code aware developers want to do model-driven development but they want high quality code. If they do a change in either the code or the model, they want the change to be made in both places. The workflows listed here are discussed in this presentation.




6


Four keys to successKnow the architecture of the original code to identify the components, boundaries, and interfacesDetermine what is potentially reusableEstimate the time to reuse versus rebuild the componentsMake a decision on a component by component basis on what to reuse and how to reuse – no change, minor update, major update




7


Visualize external code“We need to understand the structure of this spaghetti code””I need to understand the behavior of the library I was given””We need to hand-over documentation for this code”

The model is being used to view the model

The code is stable or otherwise external to the project

There’s a library (x.lib) and a header file (x.h) describing the interface of the library. You want to do model driven testing of this library (for example the library + header file come from supplier)

There’s source code (a.cpp + a.h, b.cpp + b.h etc.) which is maintained outside of Rhapsody (for example using Visual Studio or some other development environment).

When you visualize external code it is referenced externally from Rhapsody. It is not actually brought into Rhapsody. There is no intent to modify the code this way. You can see the external code visualized in diagrams.




8


On-going coding with updated documentation“We need to keep documentation always consistent with the

code”“We need to trace back code to requirements”“The developers are using Eclipse to code, but we want to do

reviews in a higher level than code”“Management tells us to use UML, but we are happy with our

editors”

The model is being used to visualize the code

Code evolves using editors and IDEs

This is similar to visualization with the added benefit of roundtripping. The model can be updated with changes in the external code.




9


Code-centric developmentCode generation is done in Rhapsody but you can preserve guidelines in the source code. Code is the master

Code is the master but code is generated in Rhapsody and the external source code is updated.




10


Modernize code using MDD“Our external code still evolves”“We want to find reusable code in our legacy”“I want to refactor my legacy code”

The model receives growing focus

Code loses some focus but it still “matters”

Here the model is the master.Some users do not want all the code generated in Rhapsody.

Some code may not be brought into the model. Here you maintain code in the model as the primary place.Modernizng code with MDD means start with Code, bring it in, re-generate, now model is masterYou can generate code in Rhapsody and external code can be updated with the changes. They are not regenerating the source files. Source files are preserved. They preserve original code with some changes. They would run Code generation to get changes from model back to code.




11


Essential capabilities and technologiesVisualization (reverse engineering)Code-centric settingsDMCA - Dynamic model-code associativityReverse engineering versus round-tripping IDE integrationsSimulation/AnimationModel-based testing

Visualization is what we do in the lab. Code-centric settings are automatic with reverse engineering. With Reverse engineering you get a dependency from the component to the settings. In the lab the reverse engineered code is associated with a component. You can set it so the code-centric settings affects one component.Round-tripping is aggressive and says that changes in the external code are stronger than themodel. The Rhapsody architect for software product automatically loads the code-centric settings.DMCA refers to the direction of roundtripping. You can go from model to code, or code to model or both. You can have automatic updates from both sides. You can have it set to automatically update or you can run roundtripping manually. Going from the model to code is called code generation. Code to model is roundtripping.




12


Visualization (reverse engineering)Reverse engineering existing code into a model

File-system directories into UML packages; C++ data-member into UML associations

Creating diagrams – OMD, flow charts

Benefits:Show and document the architecture of a working systemImmediate benefit from using a modeling toolA first step in leveraging MDD




13


Code-centric settings (mode)Model-centric and Code-centric workflows are differentPrioritize changes in the code into the modelCustomizable

What “patterns” will be used during code generation– Getter/setter for an attribute?

What types of changes can be done in the code?

Added to the model during reverse engineeringDefault in Rational Rhapsody Architect for software

Code-centric settings are automatic with reverse engineering. With Reverse engineering youget a dependency from the component to the settings. In the lab the reverse engineered code is

associated with a component. You can set it so the code-centric settings affects one component.




14


DMCA - Dynamic Model-Code Associativity

Round-trip engineering

Changes done in the code are mirrored in the model - Incremental code visualization

Changes done in the model are reflected in the code - incremental code update

Batch vs. Dynamic

BenefitsKeep the model and the code always in syncDevelop using the best/appropriate flow - from model or from codeRun-time DebuggingAn incremental approach toward MDD

This is also referred to as round-trip engineering.




15


IDE IntegrationsIntegrations with Eclipse, Microsoft Visual Studio ©,

WindRiver Workbench, ...

You can work on source code in these tools DMCA works with these tools. With roundtripping you can update the model from the code or vice versa but you need the EclipsePlug-in or the VS add-on. You get a nice toolbar for roundtripping when you work with the IDEs.




16


Simulation/AnimationUnderstand reactions to the

environmentUnderstand interactions between

different parts of the system Incrementally instrument the code

without having to “redo” the entire code

You may not be using Rhapsody for modeling. You are working on code-centric development. If you are maintaining existing code outside Rhapsody you can use animation to see Interactions between classes. This helps you understand the code when you can visualize it. You can animate code and it could not be intrusive to your external code. Then you can remove Animation and it is not intrusive to your external code. Code-centric settings preserve external Code. You can only change what is needed, create an animated sequence diagram to see the behavior and interactions between classes. There are some limitations with complicatedCode.




17


Model-based testingHost level and target based execution

White-box, black-boxInteractive, batch“Offline testing” mode: tests are executed without MDD tool in the loop – test component and SUT code linked to a single executable

Definition and management of regression tests

Requirements to test results coverageIntegration with

Code level testingRuntime analysis tools Quality management tools

TestActions can be used to:define complex test data for individual messagesperform complex checks for out valuesperform complex checks within stubbed functions




18


SummaryDifferent users have different needs in different contextsModels can be useful “even” when code-is-the-kingMix-and-match across the model-centric and code-centric scale

CodeCentric

CodeCentric

Code Construction

Software Architectureand Design

ExecutableModels




19


What’s next?

> = Current topic

Reverse engineering> Triggered operations

Introduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




20


Sending an eventIn the DishwasherSystem created previously (Dishwasher if you did not save the model as DishwasherSystem model), events such as evStart were sent from the FrontPanel to the Dishwasher.The event was put into a queue. Then the event was executed after a delay depending on how many other events were in the event queue.Another potential problem is that the FrontPanel could send events faster than the Dishwasher could handle them. In this case, the event queue might overflow.A solution to these problems is to use a triggered operation, which is basically a synchronous event, also known as a blocking call.




21


Triggered operationA triggered operation can be used on a transition in a Statechart the same way as an event.For example, you can change all the events in the dishwasher to be triggered operations. It is often a good idea to also change the prefix ev to tg.




22


Calling the triggered operationsYou can modify the processKey() operation in the FrontPanelto call the triggered operations:

The syntax for calling a triggered operation is the same as for an operation.




23


Sequence diagramWhen executing the model, you can see the difference between an event and a triggered operation.

Asynchronous call

Synchronous call




24


Triggered operation code

Statechart transition blocks the caller.




25


Invoking triggered operationsIn order to invoke a triggered operation or a primitive operation from the animation bar, set Enable Operation Calls to Public or All.




26


Calling operationsOnce the code is regenerated and rebuilt, click the arrowto invoke operations.




27


What’s next?

> = Current topic

Reverse engineeringTriggered operations

> Introduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




28


FrameworkThe Rational Rhapsody framework is a collection of base classes and interfaces that are used by the code generated from a users model.

There are two main parts to this framework:The Object eXecution Framework (OXF), which is the part of the framework that is always linked into the final generated code.The Animation and Tracing Framework, which is only used when animating or tracing, and as such is less important to understand than the OXF.

CPU

Exte

rnal

Code

RTOSOXF Framework

Rational RhapsodyGenerated Code

When we generate – causes the headers from the OXF to get included into the source files that are being generated and also causes the generated code to have calls to the OXF. At compile time, the compiler looks at the headers and cofnims everything resolves correctly (function names are correct). At link time, Rhapsody links the OXF library into the final application and at run time Rhapsody runs whatever was linked together as part of the application. You need to check the Real Time OS settings box when you install Rhapsody in order to get the OXF framework. By checking the Real Time OS settings, Rhapsody looks for operating systems development environment installations. It taells Rhapsody to inlcude the different OS’s as either libraries or sources.




29


Why do you need the OXF framework?1. It allows you to port your application onto an Operating

System1. It serves as a way to standardize the calls to the real time operating

system.

2. It is linked into your final application and in regulated environments every piece of code needs to be known




30


Object eXecution framework organizationThe OXF is created directly from a Rational Rhapsody model.There are three things necessary in order to execute an application generated by Rhapsody:Event Driven Framework (Core and Core Implementation package)Operating System Adapter Layer (Adapters package)Container Classes (Part of Services package)

The OXF can be modified by you for a variety or reasons:– To create your own OS adapter– You want your containers to work with Rhapsody

CPU

Exte

rnal

Code OXF Framework


RTOS Event Driven Framework

Operating System Adapter Layer

ContainerClasses

To view the model, see <RhapsodyInstall>\Share\LangCpp\oxf\model\oxf.rpy.




31


Object eXecution framework modelThe OXF Framework consists of many different nested packages that enable it to be built in a scalable fashion, and to include only the required functionality.There is a set of interfaces in CoreAPI and a default implementation inCoreImplementation for the framework behavior. This allows you to provide your own implementation yet not break the automated code generation process.

You can see a model of the OXF framework in Rhapsody by going to:C:\Program Files\IBM\Rational\Rhapsody\7.6\Share\LangCpp\oxf\model




32


Event driven framework interfacesThe principal interface classes in the Event Driven Frameworkare:IOxfActiveIOxfReactiveIOxfEventIOxfTimeout




33


Event driven framework implementationThe principal implementation classes in the default Event Driven Framework are:OMThreadOMReactiveOMEventOMTimeoutOMProtectedOMTimerManagerOMMemoryManager




34


OMEventOMEvent is a base class for all signal and timed events:

OMEvent has a unique ID.OMEvent knows the address of its destination (receiving reactive object).There are specific Frameworkevents for internal usage.Events may or may not be deleted after consumption (if static).OMEvent may provide its own customdestroy() operation, for example, to reuse the event in a memory pool.




35


OMTimeoutOMTimeout is a base class for all Rational Rhapsody timed events:

OMTimeout inherits everything from OMEvent.OMTimeout events have a special ID.OMTimeout adds a delay time attribute.OMTimeout may be canceled before it matures, or after being queued.




36


OMReactiveOMReactive is a base class for all reactive classes (for example, all classes with statecharts).

OMReactive knows the thread it runs on.It provides send() operations in order to put events into the input message queue of its active class using OMThread::queue().It provides the operations handleEvent() for asynchronous signal events, and handleTrigger() for synchronous events.It provides operations to schedule and cancel relative timeouts.It defines virtual operations for the code generator in order to implement the state machine of the application class, for example, rootState_processEvent().




37


OMThreadOMThread is a base class for all «active» objects for multi-threaded applications.

OMThread creates one event Queue and a dispatchingGuard. It runs its execute() operation in an operating system thread.The operation queue() enables you to put events of type IOxfEvent into the message queue.execute() readsmessages from the queue by default, anddispatch() them calling the reactive destination’s handleEvent().




38


OMThread (continued)Each OXF thread waits on an event queue for incoming events:

The above example is a simplified version of the main loop operation in an OXF thread. It is named execute().This operation may be overloaded in order to read from other blocking devices, rather than read OXF message queues. This was done in the KeyReader class in the CashRegisterexample.

OMReactive* OMThread::execute() { for ( ;; ) { while ( !eventQueue->isEmpty() ) { IOxfEvent *event = eventQueue->get(); IOxfReactive *dest = event->getDestination(); dest->handleEvent(event); delete event; } eventQueue->pend(); } }




39


Client server OXF sequence - sending




40


Client server OXF sequence - receiving




41


OMProtectedOMProtected is used to protect an operation from concurrent access. You set the property CG:Operation:Concurrency from sequential to guarded.

This protects the operation with OMProtected (basically a mutex).

For more information, see the OMProtected.h file.




42


OMMemoryManagerThe framework includes a memory manager that overrides new and delete to allocate memory.

For more information, see the OMMemoryManager.h file.




43


Extending memory managementThere are two ways to override memory allocation:

Use the static architecture properties so that memory is allocated statically using memory pools.Provide a custom memory manager class.




44


Interrupt driven frameworkBy using the interrupt driven framework (IDF), it is possible touse Rational Rhapsody in C++ without the need for an operating system.The IDF:Can replace the OXF and RTOS.Generates smaller code. Requires that a periodic interrupt be configured so that timeouts can be used in statecharts.Is in Rational Rhapsody in C++ model RiCpp_InterruptDrivenFramework.rpy.

CPU

Exte

rnal

Code

IDF Framework


For more information, see the documentation included in the V73_RiCpp_InterruptDrivenFramework model.




45


Synchronous frameworkOXF and IDF both allow asynchronous and synchronous communication.If you want only synchronous communication so that the behavior is deterministic, then use triggered operations instead of events.In this case, most the framework is redundant.The Synchronous Framework is the minimum framework necessary to allow the use of triggered operations.The Synchronous Framework does not require an OS. Therefore, active classes are not supported.Timeouts and events are not supported.It has a smaller footprint than the IDF.

CPU


Exte

rnal

Code

SF Framework




46


No frameworkIf the framework is not required, then you set the stereotype «NoFramework» to the configuration. Without the framework, there is no code generation for active classes, ports, statecharts, relations with unbounded multiplicity, and so on.

This stereotype is provided in the same profile used during the CashRegister exercise.




47


Container classesTemplate based containers

OMList<Concept>OMCollection<Concept>OMMap<Key,Concept>OMIterator<Concept>

Untyped containers that do not use templatesOMUListOMUCollectionOMUMapOMUIterator

MiscellaneousOMStringOMBoolean

These classes are in Rhapsody\Share\LangCpp\oxf.




48


Operating System Adapter LayerTo work with almost any operating system, Rational Rhapsody provides a thin Operating System Adapter Layer that describes the services required of an OS.When the application needs to use an OS service such as creating a mutex, it does so through this adapter layer.This allows you to work with multiple operating systems. For example, you can test on a host using Windows, then deploy on a target with INTEGRITY, VxWorks, Windows CE, OSE, Nucleus, Linux, ThreadX, or QNX, pSOSThe adapter layer is implemented using the Abstract Factory design pattern.




49


Adapter interface




50


NT adapter

This is showing how the mutex is created- a mutual exclusion semaphore. These are calls used to create and lock mutex’s for NT. It’s done differently depeniding on the OS.




51


VxWorks adapter




52


INTEGRITY adapter




53


Nucleus adapter

OMOSSemaphoreOMOSMessageQueueOMOSThread OMOSMutexOMOSEventFlag OMOSTimer

NuMutex NuOSMessageQueueNuOSEventFlag NuOSSemaphoreNuThread NuTimer

OMOSFactory

NuOSFactory




54


Using the adapterTo use a mutex:

Create an attribute of type OMOSMutex*:

OMOSMutex* itsMutex;Create using: itsMutex = OMOSFactory::instance()->createOMOSMutex();

Locking:itsMutex->lock();

Unlocking:itsMutex->unlock();

If you use this method to create event flags, mutexes, and semaphores, then it works on all operating systems.




55


What’s next?

> = Current topic

Reverse EngineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)

> More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




56


OMContainersYou have seen that for the relation of multiplicity *, Rational Rhapsody generates the following:

OMList<Observer*>

OMCollection<Observer*>

OMMap<int,Observer*>




57


Using an OMContainer




58


STLContainersIf you set the property ContainerSet to STLContainers, then Rational Rhapsody uses the STL (standard template library).

list<Observer*>

vector<Observer*>

map<int,Observer*>




59


Using an STL container

Make sure that you use ++iter rather than iter++ to avoid the creation of a temporary object.




60


OMUContainersIf you set the property ContainerSet to OMUContainers, then Rational Rhapsody uses the untyped containers:

OMUList

OMUCollection

OMUMap




61


Using an OMU container

These containers do not use templates. Templates can sometimes be a problem for some compilers.




62


Static arraysSometimes it is more efficient (though less safe) to use a static array.To use a static array, the multiplicity must be bounded, for example, MAX_OBSERVERS.




63


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containers

> Managing interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




64


Interrupt service routinesSetting up interrupt service routines varies from one CPU to another and from one OS to another. With Rational Rhapsody, you should use the same method you would use without Rational Rhapsody.Example: with VxWorks: The ISR routine must be static and non-animated.




65


Sending events from ISR routinesTo send an event from an ISR routine, there is a special macro GEN_ISR that can be used.

See the InterruptHandler model for more information.




66


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interrupts

> Multicore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




67


Multicore developmentMany companies are looking at multicore processors as an opportunity to realize significant price and performance improvements. Concerns are:

Adding complexity to the product development process with many more design options to consider such as number of cores, communications, and load distribution. Risks that specifying the wrong architecture can significantly reduce or even eliminate multicore benefits.

Versus




68


How Rational Rhapsody can help multicore developmentRational Rhapsody can assist by providing:

System and software models that describe design options early in the development process. A profile for modeling multicore and a matrix view for understanding core allocation.Generation of code allocated to specified cores to automate manual coding tasks.Animation and execution of instrumented models to assist analysis.




69


Viewing multi-core allocation using Rhapsody




70


Visualization of multicore executionTest and Debug at the right

level:Create sequence diagrams during execution, highlighting core allocation to better understand core utilization.Simulated time mode for animation to help support time calculations on multicore applications.Simulation of generated code on third-party host simulators for early design validation.




71


Use automated generation to build applications Rapidly support design decisions:

Generate structure, behavior, and IPCApplication mappings used to generate optimized codeLeverage the modeled trade-offs and deploy tasks to cores Target tasks again and regenerateChange OS, IPC, cores, and processors, and regenerate




72


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore development

> Generating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




73


ReportsThere are three ways that you can generate a report:

Report on modelIBM Rational Rhapsody ReporterPLUSRational Publishing Engine (RPE)

ReporterPLUS and Rational Publishing Engine have additional licenses associated with them.




74


Report on modelUse Report on model to generate a quick but simple .rtfformat file.




75


Rich text format outputThis generates a simple rich text format (.rtf) file.The report generation is quick, but there is little control over the formatting.




76


Rational Rhapsody ReporterPLUSWith the Rational Rhapsody ReporterPLUS, you can generate HTML, RTF, Microsoft Word, or Microsoft PowerPoint files. You can also use provided templates, or you can customize your own templates to format the documentation as you want.Rational Rhapsody ReporterPLUS has a graphical IDE for creating templates.




77


Rational Rhapsody ReporterPLUS IDE

Create templates with the IDE by dragging them.




78


CashRegister.doc




79


CashRegister.html




80


Rational Publishing Engine (RPE)Create multi-source documents, and extract data from IBM®

Rational® DOORS®, IBM Rational Rhapsody, IBM® Rational®ClearCase®, IBM® Rational® ClearQuest®, IBM® Rational®Quality Manager, IBM® Rational® TestManager, IBM®

Rational® RequisitePro®, and XML data sources

80 80




81


Rational Publishing Engine - Document StudioCreate and modify templates using intuitive editing environment.

Drag capability.Scripting support (JavaScript) with expression editor for ease of use.Build, share, and reuse templates.




82


Rational Publishing Engine - LauncherCreate documents fast using the easy and intuitive Rational Publishing Engine Launcher.




83


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reports

> Using the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




84


Simple Java programYou can use Eclipse to create a Java project that references the Rational Rhapsody Java API.In the Case Study, you entered several use case descriptions based on the same template.You can create a Java application to facilitate this.

More detailed steps are available in the IBM Rational Rhapsody Information Center.




85


FormatUseCaseHelper.java




86


Running the Java programYou can run the Java program from within the Eclipse environment, or add a helper to invoke the program by right-clicking a use case.

-Djava.class.path=$OMROOT\javaApi\rhapsody.jar;D:\eclipse\JavaApps\FormatUseCaseHelper -Djava.library.path=$OMROOT\javaApi com.rhapsody.helpers.FormatUseCaseHelper




87


Changing a Java application into a plug-inTo get better performance from the Java program, rewrite it as a plug-in and create a compressed file from it.

Java plug-ins run inside the Rational Rhapsody process. This means that they are fast, but need to be written well.




88


Helper file: FormatUseCase.hepWrite a helper file so that the plug-in is loaded every time Rational Rhapsody starts.




89


Loading a helper fileAdd the following code to the site.prp or siteC++.prp file to load the helper file:

The next time that Rational Rhapsody starts, you can format a use case example.




90


The built-in model checkerSome checks are run every time that code is generated, for example checking to ensure that there is a default transition.You can run the same checks and more by clicking Tools > Check Model.




91


Customizing the model checkerUse the API to write your own model checks that can be added to the built-in checks.

For example, you could add checks to do the following: Ensure that a history connector is initialized, if it is present.Ensure that there are no redundant classes. Generally, these are classes that were added inadvertently. They usually have a name that ends in _0, _1, and so on.Ensure that there are no possible redundant relations. Generally, these are classes that were added inadvertently. They usually have a name that ends in _1, _2, and so on.




92


CustomChecksHelper




93


HistoryCheck

See CustomChecksHelper.zip for the complete code.




94


Helper fileThe checks can be added with a Helper file.




95


Viewing the custom check resultsEvery time that Rational Rhapsody generates code, the custom checks execute.




96


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java API

> Collaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




97


OverviewIf you are interested in collaboration with Rational Rhapsody, this section covers:

How Rational Rhapsody facilitates collaborative workingConfiguration management of Rational Rhapsody modelsDifferencing and merging of Rational Rhapsody models

When dealing with the concept of collaborative working, there are several issues to consider:

How best to structure the model to facilitate team workingHow to restrict access to model elementsHow to merge models when they diverge




98


Parallel working strategiesThere are fundamentally two ways to work:

Optimistic strategies, for example duplicate and merge:– Each user has their own copy of the model artifact.– Each user can modify their own copy.– There is a merging phase whereby parallel modeling is combined into

a single model.Pessimistic strategies, for example exclusive checkout:– All users work on fundamentally the same model.– Only one user can have write access to a model element at a time.– Configuration management is used to provide the access restriction.– Merge phase is not required.




99


Basic concepts – unitsRational Rhapsody models have the concept of a unit.A unit is a model element that is stored as a separate file in the model repository.The following page lists all the model elements that can be stored as separate units.Out of the box Units are:– The Project – Packages– Components




100


Rhapsody file extensions

.omd

.omd

.omd

.omd

.std

.msc

.ucd

DiagramsBlock DefinitionParametricRequirementPackageInternal BlockSequenceUse Case

any extensionControlled Files

.clsBlocks, Actors, Use Cases, Parts

.cmpComponents

.sbsPackages / Profiles

.rpyProjects

File extensionModel element

Types of model element that can be made into units:




101


Unit overlay iconEach unit is identified in the browser by this symbol:To create a unit, right-click the item, and then click Create Unit.




102


Unit propertiesNew model elements can be made into units automatically if the following properties are set:

Existing elements are unaffectedYou may create a script to convert existing model elements into units

This is not the SysMLblock. It is a Rational Rhapsody-specific model element that is due to be phased out.

Classes, Blocks, Actors, and Use Cases

Objects, Parts




103


Referencing unitsUnits from one model can be added to others as a:

Reference– When the owner of the model element modifies it. Changes are

propagated to any model that references it.– Changes are only seen when the model referencing the element is

reloaded. Unit– A copy of the original unit is made in another project.– The copy is disconnected from the original. Changes are not

propagated.




104


Configuration Management (CM)Referencing may be used with configuration management.

Putting models into configuration management is discussed later in this module.




105


Model structureModel structure is user-defined:

It can relate to workflows, for example Rational Harmony-SE.It can relate to architectural components.It can relate to team organization.

In general:A common model can be created that contains any artifacts that are shared between projects of the same level. For example:– Interfaces– Requirements

Lower-level models should ‘Add to model by reference’ any higher level model artifacts that define their requirements.




106


Example model structure




107


Importing units using Add to ModelAdd to Model can be used to import units from another model.You can add the model as either:

As Unit (read/write copy)– with or without Subunits

As Reference (read-only reference)




108


Importing units by copy without subunitsWhen adding As Unit, you can choose not to add subunits.

Initially, subunits are added, but are stubbed out (unloaded).

New model with SystemRequirementsPkgadded As UnitOriginal model

Add to model




109


Importing units by copy without subunits (continued)Before saving, you can choose to load subunits:

Once you save, the subunits become unresolved. These units are essentially orphans that should be deleted.




110


Locating unresolved elementsThe advanced search dialog includes an option to search for unresolved elements. Click Edit > Advanced Search and Replace.




111


Loading multiple projectsMore than one project can be open in the Rational Rhapsody workspace.Only one project at a time can be read/write.Existing projects can be added to the workspace.New projects can be created and added to the workspace.




112


Adding projects to the workspaceTo add a project to the workspace:

1. Open a model. 2. Click File > Insert Project > New to create a new project, and then add

it to the workspace.3. Name the project Common.

The browser then contains both projects:Only one project can be read/write at a time.The inserted project is the active project.




113


Multiple browsersYou can view packages in separate browsers. This makes it easier to copy and move elements between projects or packages.Right-click a package, and then click Browse from Here.Each browser displays one package in a project.




114


Adding by referenceYou can drag a unit to another project to create references whenmultiple projects are open.

The Common project must be the active project before attempting this operation. In all cases, subunits are imported automatically. If subunits are not required, then use Add to Model (as unit). If Adding By Reference, subunits are always included.

Creates a reference to the unit in the other project




115


Drag between projectsWhen multiple projects are loaded, any unit can be dragged from one project to another:

Drag (Create Reference) – Creates a reference in the active project to a unit in an inactive project.

Ctrl+drag (Copy)– Copies a unit from an inactive project to the active project.

Alt+drag (Move and Leave a Reference) – Moves a unit from an inactive project to the active project, while

changing unit of the inactive project to a reference of the newly moved unit.

– Is useful for breaking a model down into smaller models.Shift+drag

– Displays a menu in the active project with the choices listed here.




116


Moving a unitTo move a unit by dragging, press the Alt key.

Caution: This operation is irreversible

Moves the Package, but leaves behind a reference




117


Project listsYou can save project lists:

1. Click File > Open.

2. Before opening a new project, Rational Rhapsody gives you the option to save the open project list and all its projects.




118


Partial loadingWhen you work on a large model, you often only need to work on one package at a time. Rather than loading the entire model, you can load just the units that you want to work with.




119


Partially loaded projectsUnloaded units display as Stubs and have a (U) prefix.Units can be loaded with or without subunits, and can be unloaded using the pop-up menu.




120


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding units

> Configuration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




121


Configuration Management (CM)Rational Rhapsody can work with many CM tools such as IBM®

Rational® Team Concert™, IBM® Rational® Synergy, PVCS Dimensions, PVCS Version Manager, IBM® Rational®ClearCase®, Visual SourceSafe, SourceIntegrity.The connection can be done by using either the SCC interface, through Eclipse, or through a command-line interface. You choose SCC or command line in the project properties, or you can set it up in the site.prp file.Rational Rhapsody checks in and checks out parts of the model. The parts are called units.Units that are checked out without a lock are read-only.

In order to work with Subversion or CVS, an SCC plug-in must be obtained. For example, PushOk or the Eclipse/Rhapsody Platform Integration Eclipse plug-in can be used.




122


SCC or command-line interfaceBefore using the configuration management, you must decide whether to use the SCC interface or the command-lineinterface (assuming you are notusing Rhapsody in Eclipse).

To learn more about which method to use, see the IBM Rational Rhapsody Information Center.




123


Configuration management optionsBefore you use the configuration management, there are various options that you can set, for example, what should happen if a model element gets deleted, moved, or renamed.




124


Using the SCC interface

Tree viewFlat view




125


Step 1: Connect to archiveThe first step is to connect to the archive:

The menus presented may be different, depending on the CM tool present. The menus shown here are for Visual SourceSafe.




126


Step 2: Add to archiveAfter you connect to the archive, add the model elements to the archive using the Tree view:1. Select the project.2. Click Add to Archive.




127


Step 3: Checking out filesA model element that is checked in is read-only. To work on that model element, check it out.




128


What has changed?To see the difference between the current model and the archive, select the unit and click Diff with Rhapsody.

To see the difference between two different models, use the Rational Rhapsody DiffMerge tool.




129


Rational Rhapsody DiffMerge toolThe two browsers are interposed. The decorations indicate where there are differences between the models.




130


Viewing model differencesYou can view just the model differences:




131


Ignoring graphical differencesBy default, Rational Rhapsody DiffMerge ignores any changes that are graphical, for example, where a class has been moved on a diagram.




132


Viewing the diagram differencesClick Highlight Differences to highlight all the differences.Click First difference to highlight the first difference. Click Next to highlight each subsequent difference.




133


MergingClick Start Merge to merge two models into one.Either of the models can be used as a starting point by using the Take from Left or Take from Right buttons. Model elements can be selected one by one.You can save the merged model, or you can merge it back to Rational Rhapsody.




134


Base-aware mergeYou can use the Rational Rhapsody DiffMerge to perform a base-aware comparison and merge. Ideally, you would use a CM tool such as Rational Synergy or Rational ClearCase to allow automatic merging.




135


Base-aware Diff




136


CM statusWhen using the SCC interface, you can display the status of each model element in the browser:

This package has no symbol, since it is not yet Controlled by CM.




137


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration management

> Rhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




138


Rhapsody platform integration with EclipseRational Rhapsody can also be integrated into Eclipse. The Rational Rhapsody plug-in for Eclipse is available in the Rational Rhapsody installation.




139


Creating Rational Rhapsody projects in EclipseWhen installed you can create Rhapsody projects inside Eclipse.




140


Rational Rhapsody Modeling perspective in Eclipse




141


Creating new model elementsIn the Rational Rhapsody Modeling Perspective, how you create model elements, and how you navigate the model are similar to the stand-alone version of Rational Rhapsody.Use the Rational Rhapsody browser to navigate the model in the same way.




142


Customizing a perspectiveYou can customize your Rational Rhapsody perspective by showing other views, for example, the Bird’s Eye view.1. Click Window > Show View > Other.2. Expand the Rhapsody folder to see the available Rhapsody specific

views.




143


Rational Rhapsody debug perspective




144


Managing collaboration using Rational Team ConcertThe Rational Rhapsody Eclipse integration with Rational Team Concert provides collaborative teamwork on the Jazz™ platform.




145


Invoking DiffMerge in Rational Team ConcertUse Rational Rhapsody DiffMerge to perform all merging during acceptance of incoming changes.When there are no conflicts, the merging is done automatically unless you specify merge manually.




146


Learning more about JazzRational Team Concert is a collaborative work environment for developers, architects, and project managers with work item, source control, build management, and iteration planning supportJazz is an initiative to transform software delivery making it more collaborative, productive, and transparent

To learn about Jazz and Rational Team Concert see https://jazz.net/learn/




147


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team Concert

> Introduction to Test ConductorUseful tipsAvoiding common mistakesGenerating support requests




148


TestingProfileThe Rational Rhapsody TestingProfileprovides a number of stereotypes that conform to the UML Testing Profile:

«SUT»«TestCase»«TestObjective»«TestContext»«TestComponent»«TestConfiguration»




149


Testing phasesCreate a Test Architecture

To start testing, select the classes that you want to test. Next, create a test architecture for the classes so that you can test them independently of the rest of the system. You can create the Test Architecture manually or automatically.

Create Test CasesYou can write Test Cases in one of two ways:– Graphically using sequence diagrams– Manually using code, activity diagrams, or flow charts

Execute Test Cases You can run test cases either interactively or in batch mode. Any errors can be reported and analyzed.




150


Testing artifactsAll testing artifacts are UML model elements. You can manage artifacts with configuration management in the same way as any other Rational Rhapsody model element.




151


Test architectureYou can create a test architecture by selecting a class to test, and then creating a test architecture similar to the following example:




152


TestScenarioAfter you have a test architecture, you can describe test scenarios using sequence diagrams such as in the following example:




153


TestCase: based on test scenariosA TestCase can play back a number of TestScenarios in a specific order to verify that the messages received are as expected.Each TestScenario can be parameterized, and used several times with different parameters.




154


Manual test casesIf you have some complex structures that you want to pass, or want to check return values or output values, it is difficult to do graphically with sequence diagrams. In these cases, you can write manual test cases. You can either manually write the code,or you can use a flow chart:




155


Building the test contextBefore you run the TestCases, you must build the TestContext.




156


Executing the TestContextTo run a TestCase, click Execute TestConent.




157


Test resultsAfter the test completes, a TestResult and a CoverageResultis added to the TestCase.




158


Running all the test casesYou can run all the TestCases in mode batch:




159


Code coverageAnimation can be switched off for the SUT. Switching off the animation allows Rational Rhapsody TestConductor to be used with tools such as IBM Rational Test RealTime, in order to get the Dynamic Code Coverage. With Dynamic Code Coverage, there is no unused code.




160


Failed testIf a test fails, then a sequence diagram can be automatically added to the model to help analyze the problem.

Expected message

Incorrectly received message

Correctly received message




161


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test Conductor

> Useful tipsAvoiding common mistakesGenerating support requests




162


Useful tips 1Keep statecharts simple. If they are too complex, then use sub-statecharts.Draw states as small as possible, and as close as possible to other states. Small states are more readable during animation, especially when there are several diagrams open at the same time.Do not call many actions on a statechart. It makes the diagram difficult to read. Instead, call a new operation that calls the actions.To aid navigation within the model, set up hyperlinks for every use case, class, and package.




163


Useful tips 2Look at the Rational Rhapsody samples and revisit the Cash Register model that you built during this course. Ensure that you understand these models before you start a project.Do not give the same name to several different elements of the model, example package, and class. The generated files overwrite each other.When working with large projects, it is essential to divide the model into components. The interfaces between these components should be well-defined. Then, work can be carried out simultaneously and independently by different teams on each component.




164


Useful tips 3Do not put everything onto a single diagram. This can make reading the diagram difficult. Using a couple of diagrams, depicting different views can really help in communicating the model. Use an iterative approach similar to the approach taken during this course—constantly model, save, generate, make, and run. Do not wait until the model is too large before animating.Each diagram should have a mission, a reason why it is there, and should be named in such a way as to reflect this.




165


Useful naming conventionsStart Event names with ev:

For example, evStart

Start Triggered operation with tg:For example, tgPress

Start Condition operations with is:For example, isPressed()

Start Interface classes with an I:For example, IHardware

Start Classes with an UpperCase. Start operations and attributes with a lowerCase.Use an UpperCase to separate concatenated words, for example, restartSecondTimer().

These conventions help when reading diagrams and when recalling names of model elements.




166


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tips

> Avoiding common mistakesGenerating support requests




167


Deadlock situation 1




168


Deadlock situation 2




169


Transition or reaction in state?

Reactions in state




170


Null transitionsEach time a state is entered, Rational Rhapsody checks to see ifthere is a null transition to take. If there is, then the Rational Rhapsody takes the transition.

In the following example, there is no stable state because every state has a null transition with a guard that evaluates to True. In this case, the message Infinite loop of Null Transitions displays.

A Null Transition is a transition that has no trigger.




171


What is done first?When in the waiting state, what happens when the evCoin event is received?

Answer: The value of coin is tested BEFORE it is assigned!




172


Attribute accessSetting the access for an attribute modifies the access for the accessor and mutator, not for the attribute itself. Attributes are always protected by default.




173


What’s next?

> = Current topic

Reverse engineeringTriggered operationsIntroduction to the Rhapsody framework (OXF)More about containersManaging interruptsMulticore developmentGenerating reportsUsing the Java APICollaborative working – understanding unitsConfiguration managementRhapsody in Eclipse and Jazz/Rational Team ConcertIntroduction to Test ConductorUseful tipsAvoiding common mistakes

> Generating support requests




174


Generate support requestRational Rhapsody includes a special function that facilitates sending an email to Technical Support.This function collects information about your system, and the Rational Rhapsody environment and model, then creates a compressed file.The compressed file can then be sent to support. Alternatively, the compressed file can be transferred to another machine and sent in an email.




175


Support request

Quickly collects problem information

Information about Rational Rhapsody and system automatically collected




176


Adding files, screen captures, videos, and other information

Model and extra files can be quickly added

Screen snapshots can be captured

Videos can be captured to aid problem description




177


Sending the email

All models, files, and screen captures are automatically compress and attached to an email.




178


eLearningeLearning is Web-based, self-paced training. Interactive multi-media features:DemonstrationsYou try it exercisesQuizzes with feedbackPost-learning tests to ensure that knowledge has been acquired

Intended as an introduction to:Modeling languagesAdvanced topicsAdd-on products




179


eLearning: current coursesFor a listing of all courses that are offered, see:

http://www.ibm.com/training




180


Recommended reading




181


Module summaryYou should now know enough about Rational Rhapsody to start creating your own projects. You should have basic familiarity with the following topics:Reverse Engineering/Code-centric developmentThe Rational Rhapsody FrameworkGenerating reportsUsing the APIUsing Configuration ManagementMulticore developmentRational Rhapsody TestConductor

To develop more in-depth skill and knowledge about the topics listed above, there is additional Rational Rhapsody Specialist training available.




182


Further information Additional Training

www.ibm.com/trainingRational software training: http://www.ibm.com/training/us/catalog/rational/

Information Center (online help)http://www.ibm.com/support/publications/us/library/index.shtml#softwarehttp://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/index.jsp

Supporthttp://www.ibm.com/planetwide/http://www.ibm.com/support

developerWorks for webcasts, workshops, white papers, demos, and morehttp://www.ibm.com/developerworks/rational

Forumshttp://ibmforums.ibm.com/forums/category.jspa?categoryID=208

Facebookwww.facebook.com/

Twitterhttp://twitter.com/ibmrational




183


Course surveyPlease complete the course survey

If you have web access in class– http://osart.atlanta.ibm.com

If you don’t have web access, an email will be sent to you– Please provide the instructor with your:

• Name• Email

– Please wait for the email

Class Number: __________Provided by instructor

Course Code: _______If you are taking multiple courses, please complete a survey for each course and request certificates for each as well.




184


Essentials of Rational - IBM€¦ · Module 6: Describing behavior by using state machines, part 2...

Documents

Transcript of Essentials of Rational - IBM€¦ · Module 6: Describing behavior by using state machines, part 2...