qq139g1stud rapsody

8/17/2019 QQ139G1STUD rapsody

http://slidepdf.com/reader/full/qq139g1stud-rapsody 1/503



IBM CorporationRational software

U.S. Government Users Restricted Rights - Use, duplication ordisclosure 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 othercountries. Consult your local IBM representative for information on the products and servicescurrently available in your area. Any reference to an IBM product, program, or service is notintended to state or imply that only that IBM product, program, or service may be used. Anyfunctionally equivalent product, program, or service that does not infringe any IBM intellectualproperty right may be used instead. However, it is the user's responsibility to evaluate and verifythe operation of any non-IBM product, program, or service.

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

IBM Director of LicensingIBM Corporation

North Castle Drive Armonk, NY 10504-1785U.S.A.

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

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan Ltd.1623-14, Shimotsuruma, Yamato-shiKanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any other country wheresuch provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINESCORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANYKIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warrantiesin certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes areperiodically made to the information herein; these changes will be incorporated in new editions ofthe publication. IBM may make improvements and/or changes in the product(s) and/or theprogram(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 anddo not in any manner serve as an endorsement of those Web sites. The materials at those Websites are not part of the materials for this IBM product and use of those Web sites is at your ownrisk.

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, shouldcontact:



Intellectual Property Dept. for Rational SoftwareIBM Corporation5 Technology Park DriveWestford, MA 01886U.S.A.

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

The licensed program described in this document and all licensed material available for it areprovided by IBM under terms of the IBM Customer Agreement, IBM International ProgramLicense 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 measurementsmay have been made on development-level systems and there is no guarantee that thesemeasurements will be the same on generally available systems. Furthermore, somemeasurements may have been estimated through extrapolation. Actual results may vary. Users ofthis document should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, theirpublished announcements or other publicly available sources. IBM has not tested those productsand 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 thesuppliers of those products.

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

This information contains examples of data and reports used in daily business operations. Toillustrate 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 thenames 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 notappear.

Trademarks and s ervice marks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of InternationalBusiness Machines Corp., registered in many jurisdictions worldwide. Other product and servicenames might be trademarks of IBM or other companies. A current list of IBM trademarks isavailable on the Web at “Copyright and trademark information” atwww.ibm.com/legal/copytrade.html

• Adobe, the Adobe logo, PostScript, and the PostScript logo are either registeredtrademarks 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 registeredtrademarks of Intel Corporation or its subsidiaries in the United States and othercountries.Intel trademark information

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

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

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



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



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

• ITIL is a registered trademark, and a registered community trademark of the Office ofGovernment 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 othercountries.

• 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 SoftwareEngineers – 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-1Exercise 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.6

for Software Engineers

Module 0: About this course

Contents

Introductions 0-2

Course outline 0-6

Logistics 0-7

Module 0 – About This Course




0 -


2

2 © Copyright IBM Corporation 2012

Introductions

Your organization

Your role

Your background and experience

Software development experience

Object technology experience

Course expectations




0 -


3


Intended audience

Primary target audience:

Software developers

Technical team leads

Secondary target audience:

Systems engineers with

software-intensive focus

QA and compliance officers

Managers





0 -


4


Course objectives

Upon completion of this course, you should know:

How to identify the core UML 2 notation and techniques:

Use cases and requirements

Modeling structure, including classes and composite structure

Modeling 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 engineering

Configuration management tools

Document 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 outline

Module 0: About this course

Module 1: Why use modeling

Module 2: Overview of diagramsModule 3: Encapsulating structure by using UML

Module 4: Object discovery strategies

Module 5: Describing behavior by using state machines, part 1


Module 7: Describing communication by using UML

Module 8: Describing modularity and reusable components

Module 9: Describing use cases and requirements

Module 10: Advanced sequence diagrams

Module 11: Extending UML

Module 12: Advanced topics

Module 13: Exercise solutions




0 -




Logistics

Morning

1 15-minute break

Lunch

45 minutes

Afternoon

1 15-minute break







Course materials

Materials for this course:

Labs (tool training workbook)

Student manual of UML, tool training, and advanced topic slides




0 -




Course description

This 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 1

Theory:


Module 2: Overview of diagrams

Module 3: Describing structure by using UML

– Exercise 3.1: Attributes and operations



– Exercise 5.1: Luggage belt

– Exercise 5.2: LED

Rational Rhapsody labs:

Hello World Count 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:


– Exercise 6.1: Mouse

– Exercise 6.2: Battery charger

Module 7: Describing communication by using UML

– Exercise 7.1: Elevator system


Rhapsody labs:

Dishwasher

Dishwasher system




0 -





Theory:

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 -





Theory:


Advanced topics:

Reverse engineering and code-centric workflow

The Rhapsody Oxf framework and containers

Configuration management

Document generation

Reverse 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?




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


Discussion

What 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 problems

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

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 requirements

Software problems are 100 to 1000 times more costly to find andrepair after deployment.

During therequirements phase

During thedesign &construction phase

After the product isreleasedDuring the

QA/testing phase

Source: 2008 GBS Industry standard study

Defect cost derived from the assumptionthat it takes 8 hrs to find, fix, and repair adefect when found in code and unit test.Defect FFR cost for other phasescalculated by using the multiplier on ablended rate of $80/hr.

$80/defect $240/defect

$960/defect

$7,600/defect

Costs of

Design

Change

Time

Induced

Errors

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 met

Requirements churn

Models do not fit

Hard to maintain

Late discovery

Poor quality

Poor performance

Colliding developers

Build-and-release

Insufficient requirements

Brittle architectures

Overwhelming complexity

Undetected inconsistencies

Poor testing

Subjective assessment

Waterfall development

Uncontrolled changeInsufficient automation

Symptoms Root causes Best practices

Ambiguous communicat ion

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 other

Best practices:

• Develop iteratively

• Manage requirements

• Use component architectures

• Model visually

• Verify quality continuously

• Manage change

Validates architecturaldecisions early on.

Addresses complexity of design andimplementation incrementally.

Measures quality early and often.

Evolves baselines incrementally.

Ensures that users areinvolved as requirementsevolve.

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 requirements

Ensures 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 managementthroughout 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 behavior

Shows how system elements fit together

Keeps design and implementation consistent

Hides 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 text

Engineer 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. WhenB changes to Running it will send back a message Y to A andthen wait for 2 second before returning to Idle. System A willhave started in Idle also and will go to Running after B sendsback event Z which happens after the 2 seconds before goingto 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 UML

Engineer 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™

UML2.0

UML1.5

Mid ’70s – Late ’80s

Identifiable OO modeling languages began to appear

1989 1994

Number of identifiable OOmodeling languagesincreases from <10 to >50

“Method Wars” Begin!

Ivar

Jacobson

(Objectory)

adds OOSE

1996 1997

2001

Joint special interestgroup in systems

engineering modeling

formed between

OMG and INCOSE

2003 2005

Incorporation ofstructured notationtechniques, including

ports and parts

ROOM,UML-RT,

and others

1983

UML0.8

Grady Booch and

Jim Rumbaugh begin

unifying Booch &

OMT methods

Harel

Statecharts

incorporated

UML0.9

2007

OMGSysML 1.0

adopted

UML1.1

OMG

stewardship

UML2.3

2010

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 continuously

Software problems are 100 to 1000 times more costly to find andrepair after deployment

Cost to repair software

Cost of lost opportunities

Cost 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 change

To avoid confusion: Provide each developer with a secure workspace.

Provide automated integration and build management.

Develop in parallel.

Workspace

Management

Process

Integration

Parallel

Development

Build

Management

Configurationmanagement is morethan just check inand 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 multiple

versions 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 problemis identified in any one of the versions, the fix must be propagated among all of them.





1 -


16


Achieving best practices

Iterative approach

Guidance for activities and artifacts

Process focus on architecture

Use cases that drive design and implementation

Models 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 summary

In 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




Module 2: Overview of UML diagrams

Module 2 – Overview of UML diagrams




2 -


2


Module overview


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 ModelingLanguage

The 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 systems

Large scale systems, networking, web enablement, data management

Extensible and configurable

Unprecedented interdisciplinary market penetration

UML 2.4.1 released in August 2011UML 2.x OMG SysML™

Originally a unification of various notations by Grady Booch, James Rumbaugh, and Ivar

Jacobson, 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-specific

extensions (using profiles). As well as sharing models and best practices, interdisciplinaryteams can use common tools within their organization to reduce support costs.





2 -


4


Diagram taxonomy

Precise syntax and semantics

Multiple 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 diagrams

Use 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 diagrams

Activity 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 creation

of 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 composition

relationships 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 diagrams

Object 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 diagrams

Composite 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 required

interfaces.





2 -


11


State machine diagrams

State 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 diagrams

Packages 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 diagrams

In UML1 style you can show how .lib, .exe, .dll, and other

artifacts are interconnected.In UML2 the term

component is broadenedto 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, forexample, 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 anexecutable file, Gui.exe. This file has a «Usage» dependency on the Controller

component, 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 Gui

executable is linked.





2 -


14


Deployment diagrams

Deployment 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 havethe 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 diagrams

Timing 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

Monitor

Initializing

AcquiringReporting

Idle

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 diagrams

Communication 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 interactions

between 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 diagrams

Interaction 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 systems

Real-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 programming

Special concerns about safety and reliability

Special 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

A n a l y s i s

D e s i g n

This activity

iterates, typically

every 4-6 weeks




Harmony/ESW Microcycle

A n a l y s i s

D e s i g n

Complex projects requiring

very high quality may add

reviews between each phase.




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 their

structure and behavior

How to use the diagrams for development of real-time systems

How to follow a workflow for model-driven development




Module 3 – Encapsulating structure using UML

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

3 -


2


Module overview

In this module, you learn:

How to apply the principles of abstraction and encapsulation to UML

using classes and objects

How 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 be

Permits you to specify the structure or behavior of a system

Gives you a template that guides you in constructing a system

Documents 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 achievesfour 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 onlyin specification and requirement documents. Models bring about more specificunderstanding of the system.

2. Models permit you to specify the behavioral structure of a system. You can documentsystem 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 eradicatethat 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.

A b s t r a c t i o n

H i e r a r c h y

Object orientation

E n c a p s u l a t i o n

M o d u l a r i t y

Object orientation relies on four basic principles:

• Abstraction

• Encapsulation

• Modularity• Hierarchy





3 -


5


Review: Abstraction

Abstraction 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


Objects

Software things Occupy memory at some time

For example, CustomerRecord, ECGSample, window, font

Electronic things Occupy physical space at some time

For example, thermometer, LCD display, motion sensor, DC motor

Mechanical things Occupy physical space at some time

For example, wing surface, gear, door, hydraulic press

Chemical things Occupy physical space at some time

For example, battery, gas mixture, halothane

System things Occupy physical space at some time

For 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 objects

Abstraction is supported by the concept of a class.

A class is a description of a set of objects that share the sameattributes, 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 radio

Responsibilities:

Playing a radio frequency for a user who listens.

Attributes:

Wavelength

Frequency

Volume

Behaviors:

Tune to a frequency

Store and recall a frequency

Change volume

Switch 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 camera

Responsibilities:

Take digital photos

Attributes:

Available memory

Picture resolution

Battery level

Behavior :

Select resolution

Focus

Take photo

Upload photos

Browse 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 attributes

of 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 oven

Responsibilities?

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 clients

Protects 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 views

Objects generally have two different views:

The public view, which is the object as seen from outside

The 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 attributes

Objects contain their own attributes but, generally do not allow

other 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 attributes

All 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: int

patientName: 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 operations

Objects execute operations to implement behavior:

Operations are primitive behaviors such as:

x = x + 1

y = sin(x)^2 + cos(x)^2

z = 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 toshow every attribute,every operation, orvisibility.

Attribute values at a specific time

Object name Classname

Implicit

object

Multiplicity

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





3 -


19


Multiplicity

When 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 thesesymbols, RationalRhapsody uses graphical

icons. These icons arealso shown in the browserto aid understanding.

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

Features have these visibility icons:

+ publicAccessible 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 destructors

Every 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 operations

What are the attributes, operations, and responsibilities

of the following classes?

Try this exercise on paper.





3 -


24



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



v7.6 for Software Engineers


Contents

Module overview 4-2

Object discovery strategies 4-3

Module summary 4-13

Module 4 – Object Discovery Strategies





4 -


2


Module overview

In 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 strategies

When you build a new system using objects, you need to start

somewhere. Where should you start?

What do I

do?

What do I

know?

What are my

responsibilities?

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 -


5


Identify the nouns

Find nouns and noun phrases in the problem statements:

• Provide a first-cut list of potential classes and objects.

• Discover:

Objects of interest

Uninteresting objects

and actors

Attributes

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 consideredto 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 elements

Causal 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 database

Audio and video synchronizer

Autopilot

Clothes washer cycle controller

A causal agent is any

entity that produces aneffect, or is responsiblefor 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 -


9


Identify real world entities

Often 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 performed

Objects are useful where there is a set of operations that appear

intrinsically bound and conceptually coherent.

Objects might encapsulate:

Strategy

Algorithm

Creation of complex objects

Examples:

Measurement

Kalman filter

CommandFactory

CRC 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 concepts

Key concepts are the fundamental abstractions in the domain.

These concepts often have no physical manifestation.

Examples include:

UI domain Window, icon, cursor, toolbar

Robotics Task plan

Banking Account

OS Thread

Navigation 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 objects

Transactional objects arise from the need to manage or track the

interaction 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 berouted 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 nouns

Walking through scenarios

Identifying causal agents and control elements

Identifying physical devices

Identifying real-world entities

Coherent services to be performed

Key concepts

Transactional 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 World

This 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





Contents

Module overview 5-2

Module summary 5-27




machines, part 1

5 -


2


Module overview


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.




machines, part 1

5 -


3


Types of behavior

Behavior 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.




machines, part 1

5 -


4


Simple behavior

Simple 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.




machines, part 1

5 -


5


Continuous behavior

The 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

-+ Delay

Wn

Kb

++Vn Zn

UML is not very

good 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.




machines, part 1

5 -


6


State behavior

State behavior is useful when an object:

Exhibits discontinuous modes of behavior

Waits 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.




machines, part 1

5 -


8


State machines can be executed

Because 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.




machines, part 1

5 -


9


State machine execution




machines, part 1

5 -


11


Basic state machine syntax

Transition 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 evOn

event, 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 guardevaluates to true, then the transition is taken and the actions are performed on the transition.

The object then enters the On state.




machines, part 1

5 -


12


Entry and exit actions

Notice the order of execution ofactions. The guard is checkedbefore 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.




machines, part 1

5 -


13


Types of events

UML 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.




machines, part 1

5 -


14


Time event

When 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 actionTime event

Exit action

A common transition in real-time systems is the timeout transition. A time event in Rational

Rhapsody 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.




machines, part 1

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.




machines, part 1

5 -


16


Transitions and discarding events

The 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 state

A 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.


machines, part 1

5 -


17




machines, part 1

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.




machines, part 1

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.




machines, part 1

5 -


20


Actions

Actions 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 object

Through externally available functions

Actions can occur:

When a transition is taken

When a reaction occurs

When a state is entered

When 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.




machines, part 1

5 -


21


Transitions: guards

A 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.




machines, part 1

5 -


22


Null-triggered transitions

Also known as completion transitions

Triggered upon completion of any entry actions

Can contain a guard condition

Are 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. Theguard is retested

every time that the

timeout occurs.




machines, part 1

5 -


23


State machine syntax: OR states

You 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.




machines, part 1

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




machines, part 1

5 -


26


Exercise 5.2: LED





machines, part 1

5 -


27


Module summary

In this module, you covered some of the basic state machine

syntax, as well as some of the benefits of using the notation to

constrain 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.




machines, part 1

5 -


28


Lab: Count Down

In 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





Contents

Module overview 6-2

Module summary 6-20




machines, part 2

6 -


2


Module overview


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

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




machines, part 2

6 -


3


Quick recap

Q1: What is a state?

Q2: How do you get into a state?

Q3: How do you know that something is a trigger rather than anaction 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?




machines, part 2

6 -


4


Pseudostates

UML 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 of

junction pseudostate)

Terminal or Final Pseudostate

Initial or Default Pseudostate

Fork Pseudostate Join Pseudostate

Junction Pseudostate

(Shallow) History

Pseudostate

(Deep) History Pseudostate

Choice Pseudostate

EntryPoint Pseudostate

[g]

[g]

Symbol Symbol Name

ExitPoint Pseudostate

label

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




machines, part 2

6 -


5


A junction is a compound transition

If 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

Or

setYellow Event occurs AND sigAhead = YY AND NoTrainInSection = true

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




machines, part 2

6 -


6


Submachines: Parent

Entry point connector

Submachine reference

Exit point

connector

Can you guess what this is a state machine of?




machines, part 2

6 -


7


Submachines: Child

Entry point

connector

Submachine Exit point

connector




machines, part 2

6 -


8


Nested states: Hierarchical events

When 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




machines, part 2

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 pressingthe magnify button (evMagnify).

When in the magnify mode, if you hold the magnify

button (evMagnifyHeld), you enter a new state

where the up (evUp) and down (evDown) buttons

zoom the magnification using theincMag() and decMag() operations.

The mouse remains in this mode until the magnify

button is released (evMagnifyReleased)

When the magnify button is not held, the

up (evUp) and down (evDown) buttonsstart operations up() and down()

Paper exercise 6.1: Mouse




machines, part 2

6 -


10


Exercise 6.1: Mouse





machines, part 2

6 -


11


Orthogonal states and regions

When 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.




machines, part 2

6 -


12


Orthogonal states and regions

Regions

Orthogonal state separator




machines, part 2

6 -


13


Region communication

Regions 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 canprovide mechanisms to test to see if an object

is in a particular state, such as IS_IN(State).




machines, part 2

6 -


14


Communication across regions

AND state name (optional) Both sides handle the same event

IS_IN test across AND states\Samples\CppSamples\HomeAlarmWithPorts




machines, part 2

6 -


16


What is the output of the following state machine?

Timeouts revisited




machines, part 2

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




machines, part 2

6 -


19


Exercise 6.2: Battery Charger





machines, part 2

6 -


21


Lab: Dishwasher

In this lab, you build and execute

a running state machine with AND

states.




machines, part 2

6 -


22




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

7 -


1




Module 7: Describing communication

Contents

Module overview 7-2

Module summary 7-35

Module 7 – Describing Communication




7 -


2


Module overview


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


Messages

Objects communicate with each other through messages.

Messages: Synchronous for example, Function call

Asynchronous 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 relationships

In order to send a message to another object, there must be

some relationship between the classes.

“The semantic connection between classes” ~ Grady Booch

Class diagrams are used to draw these relationships.

A b s t r a

c t i o n

H i e r a

r c h y

Object Orientation

E n c a p s

u l a t i o n

M o d u

l a r i t y

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 whilesuppressing 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

Association

Aggregation

Composition

Generalization

Dependency

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





7 -


9


Navigation

Navigation indicates that it is possible to navigate from an

associated class to the target class

Relations 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 roles

For 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 one

instance 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


Aggregation

Multiplicity 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 canonly 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, compositions

A qualifier makes it possible to sort the relations by the value of

an attribute.

Qualifiers are used with a relation of multiplicity. *

A qualifiedassociation 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 inherits

from one or more superclasses.

Single inheritance

Multiple 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” class

above 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 pillar

Hierarchy 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 hierarchymust 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 andresponsibility). 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


Generalization

Generalization 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 -


20


Review: Polymorphism

The ability to hide many different implementations behind a

single interface

Instances of the subclass are

freely substitutable for instances

of the superclass

The client calls the insert

operation withoutknowing 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 1

There 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 2

Assumes 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 substates

and 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 -


25


Bad generalization

The 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 generalization

Beware 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 class

An 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 -


29


Dependencies

A 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 itimplies 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 system

An 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 helpsto 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 -


36Module 7 – Describing Communication


Lab: Dishwasher system

In 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





Contents

Module overview 8-2

Module summary 8-32

Module 8 – Describing Modularity




components

8 -


2


Module overview

After 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.





components

8 -


3


Review: Modularity

One of the pillars of object-oriented design is

how to handle modularity, for example,

breaking complex systems into smaller modules.

Billing

system

Course registrationsystem

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.





components

8 -


4


The need for interfaces

When 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 closelyassociated, or coupled with the Application class.

itsApplication->press();

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





components

8 -


5


Interface IButtonListener

One 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.

Abstract

operation

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 abstractoperations 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.





components

8 -


6


Interface IButtonListener

Different 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.





components

8 -


7


Review: Interfaces in UML

An 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.





components

8 -


8


Ball and socket notation

Another 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 interfaces

Rational 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.


components

8 -


9




components

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.





components

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.




components

8 -


12


Composite structure in UML2

Ports are often used with structured classes.

A structured class contains parts or roles that form its structureand 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.





components

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?





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 aninstance of a PC is connected to a projector ratherthan 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.


components

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 PDAand 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.


components

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.


components

8 -


17




Coupling between classes

In 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 andProjector 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 stilllooks quite complex,doesn’t it?




Alternatively, using UML2, we could use ports and interfaces

with “ball and socket” notation.

Showing ports and interfaces instead

There are now UI relationships between thePC and the other classesin the class model.

Provided

contract Required

contract




Combining parts with ports/interfaces

Parts 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.


components

8 -


21




This technique was introduced in

UML2 for component-based

design.

It supports the ability to plug and

play with different classes thatimplement 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.


components

8 -


22




PC internals

Structured 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 areconnected 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.


components

8 -


23




components

8 -


24


Benefits of using ports

Ports 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.





components

8 -


25


Things to remember about ports

Ports 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.





components

8 -


26


Ports can have multiplicity

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





components

8 -


27


Flow ports

Flow ports are a form of port used in SysML to model data flow.

Flow ports can connect UML models to code that is generatedfrom 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.





components

8 -


28


Handling concurrency

In 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 doublevertical lines, RationalRhapsody uses one thick lineto 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 powerfulmechanism for reducing platform dependence and supporting concepts such as host versus

target deployment to increase early testing.





components

8 -


29


Class diagram showing active classes

Tag valuesInterruptroutine

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.





components

8 -


30


Regrouping classes into threads

Classes 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.





components

8 -


31


Review

1. 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?




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

9 -


1




Module 9: Capturing use cases and requirements

Contents

Module overview 9-2

Module summary 9-35




9 -


2


Module overview


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 modeling

The 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 how

the 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

Actor System 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 -


6


Use cases

A use case is a sequence of actions a system performs that yield

an 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 usecases.

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 cases

As 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


Communication

IdentificationVerification

Review: The benefits of a use case model

User Domain expert Users

Verification

I d e n t i f i c a t i o 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 requirements

Use cases can capture functional aspects. You might also want

to capture Quality of Service constraints and non-functional

requirements:

Worst-case execution time

Average execution time

Throughput

Predictability

Capacity

Safety

Reliability

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 -


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 checkthat 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 cases

Answer 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 bestperformed 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 not

Because 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 descriptions

A use case description is often structured in the following way:

Name

Purpose

– 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 relations

Use 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 systemfunctionally. 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»dependency

Use «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 events

Has one normal, basic flow

Several alternative flows Regular variants

Odd cases

Exceptional 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


Scenarios

A 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: Scenarios

The 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 scenarios

Scenarios that span all interesting variants of behavior

Scenarios 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 scenarios

Scenarios 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 theperspective 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 timingconstraint. The diagram adds some contextual information to help the reader.




9 -


25


Sequence diagram: Valid pin code

Reference

sequence

diagram

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 station

Draw 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 -


30


An activity diagram can capture the activities in a use case.

An activity diagram is like a flow chart that shows the flow ofcontrol 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 -


34


MP3 player use case diagram




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

interactions

10 -


1




Module 10: Advanced sequence diagrams to show interactions

Contents

Module overview 10-2

Module summary 10-15




interactions

10 -


2


Module overview


Identify the different syntax for synchronous and asynchronous

messages

Decompose sequence diagrams, showing conditional logic,

parallel behavior, and iterative logic on sequence diagrams

Use the techniques for expressing timers and state condition

marks in sequences




interactions

10 -


3


Sequence diagrams

Sequence 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 (a

scenario). 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.




interactions

10 -


4


Asynchronous and synchronous messages

The arrowheads are differentfor 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.




interactions

10 -


5


(Optional) showing concurrency

Different colorscan be used onactivation bar toshow differentthreads.

Execution

occurrence

(optional)

One (non-UML) technique for handling concurrency in sequence diagrams is to use the

activation bar and to color it.




interactions

10 -


6


Constructors, destructors, timers, and state marks

State or

condition

mark

Expired

timeout

Destructor

Constructor

Canceledtimeout

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.




interactions

10 -


7


Combined (interaction) fragment operators

sd – named sequence diagram

ref – reference to interaction fragment

loop – repeat interaction fragmentopt – optional behavior alt – 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.




interactions

10 -


8


Lost and found messages, and loops

Found

message

Reply

message

Object destruction

Lost 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.




interactions

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.




interactions

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 occurrence

element, 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 sequencesto 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.




interactions

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 theoperand 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.




interactions

10 -


13


Interaction operators: Weak sequencing

The 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.




interactions

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 interleaveinto the region, such as with par-operator , this is prevented by defining a region.




interactions

10 -


15


Module summary

In this module, you learned:

The different syntax for synchronous and asynchronous messages

How to decompose sequence diagrams, showing conditional logic,

parallel behavior, and iterative logic on sequence diagrams

Techniques for expressing timers and state condition marks in

sequences




interactions

10 -


16




Essentials of IBM Rational Rhapsody for Software Engineers Module 11. Extending UML

11 -


1





Contents

Module overview 11-2

Module summary 11-13




11 -


2


Module overview

After completing this module, you should know how to extend

UML and understand the potential benefits.




11 -


3


Extending UML

Primary 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


Profiles

A profile is a coherent set of stereotypes, tags, and constraints:

Specializes UML for a vertical market domain, business environment, or

company Can 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 diagrams

For 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 values

Interrupt routines

See next slide.




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 SysMLprofile \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 parametricmodeling.


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- andUPDM-compliant architectures.




11 -


13


Module summary

After 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




Module 12: UML exercise solutions (and stopwatch, speed camera,

and microwave)

Contents

Exercise solutions 12-2

Optional test questions 12-13

Optional extra exercises 12-15Recommended reading 12-25

Further information 12-26

Course Survey 12-27

Module 12 – Exercise Solutions




12 -


2


What’s next?

> = Current topic

> Exercise solutions

Optional test questions

Optional extra exercises





12 -


3







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 -


15


What’s next?

> = Current topic

Exercise solutions

Optional 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 -


19


Speed camera exercise (2 of 2)

After a vehicle passes the last camera, any retained information

is discarded.

Assume that every camera receives theevVehicle(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 exercises

If 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 documentthat you can import into Rational Rhapsody by using theRational Rhapsody Gateway.





12 -


21


Microwave oven

Design a microwave oven

that satisfies the

following requirements:





12 -


22


Electronic safe –Requirements 1

Design an electronic safe

that satisfies the following

requirements:





12 -


23







12 -


24







12 -


25


Recommended reading






12 -


27


Course survey

Complete 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

© Copyright IBM Corp. 2012 13 -


2


Module overview

Now 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 topicssuch as:

Reverse Engineering/Code-centric development

The Rational Rhapsody Framework

Generating reports

Using the API

Multicore Development

Using Configuration Management

Rational Rhapsody TestConductor






3


What’s next?

> = Current topic

>Reverse engineering

Triggered operations

Introduction to the Rhapsody framework (OXF) More about containers

Managing interrupts

Multicore development

Generating reports

Using the Java API

Collaborative working – understanding units


Rhapsody in Eclipse and Jazz/Rational TeamConcert

Introduction to Test Conductor Useful tips

Avoiding common mistakes

Generating 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 master

Everything is done in the

code and should stayexactly as-is

CodeConstruction

SoftwareArchitectureand Design

Using implementation language

Generating readable code

Open framework

Model-Code Associativty

Model-Code co-Debugging

Model-is-code

From the model

Code 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 – frommodel to code.

Code Centric: The developer knows their (external) code; the model is used for

communication, review etc

In 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 code

On-going coding with updated documentationCode-centric development

Modernizing 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 success

Know the architecture of the original code to identify the components,boundaries, and interfaces

Determine what is potentially reusable Estimate the time to reuse versus rebuild the components

Make a decision on a component by component basis on what to reuseand 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.






9


Code-centric development

Code generation is done in Rhapsody but you can preserve guidelines inthe source code.

Code is the master

Code is the master but code is generated in Rhapsody and the external source code is

updated.






12


Visualization (reverse engineering)

Reverse engineering existing code into a model

File-system directories into UML packages; C++ data-memberinto UML associations

Creating diagrams – OMD, flow charts

Benefits:

Show and document the architecture of a working system

Immediate benefit from using a modeling tool

A first step in leveraging MDD






13


Code-centric settings (mode)

Model-centric and Code-centric workflows are different

Prioritize changes in the code into the model

Customizable 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 engineering

Default in Rational Rhapsody Architect for software

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.






14


DMCA - Dynamic Model-Code Associativity

Round-trip engineering

Changes done in the code are mirrored in the model - Incremental codevisualization

Changes done in the model are reflected in the code - incremental codeupdate

Batch vs. Dynamic

Benefits

Keep the model and the code always in sync

Develop using the best/appropriate flow - from model or from code

Run-time Debugging

An incremental approach toward MDD

This is also referred to as round-trip engineering.






15


IDE Integrations

Integrations with Eclipse, Microsoft Visual Studio © ,WindRiver Workbench, ...

You can work on source code in these tools DMCA works with these tools. With round

tripping you can update the model from the code or vice versa but you need the Eclipse

Plug-in or the VS add-on. You get a nice toolbar for roundtripping when you work with the IDEs.






16


Simulation/Animation

Understand reactions to theenvironment

Understand interactions betweendifferent parts of the system

Incrementally instrument the codewithout having to “redo” theentire 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 complicated

Code.






20


Sending an event

In the DishwasherSystem created previously (Dishwasher ifyou did not save the model as DishwasherSystem model),

events such as evStart were sent from the FrontPanel to theDishwasher .

The event was put into a queue. Then the event was executedafter a delay depending on how many other events were in theevent queue.

Another potential problem is that the FrontPanel could sendevents faster than the Dishwasher could handle them. In thiscase, 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 ablocking call.






21


Triggered operation

A triggered operation can be used on a transition in aStatechart the same way as an event.

For example, you can change all the events in the dishwasherto be triggered operations. It is often a good idea to alsochange the prefix ev to tg .






22


Calling the triggered operations

You can modify the processKey() operation in the FrontPanel

to call the triggered operations:

The syntax for calling a triggered operation is the same as for an operation.






23


Sequence diagram

When executing the model, you can see the differencebetween an event and a triggered operation.

Asynchronous call

Synchronous call






24


Triggered operation code

Statechart transition blocks the caller.






25


Invoking triggered operations

In order to invoke a triggered operation or a primitiveoperation from the animation bar, set Enable Operation Calls

to Public or All.






27


What’s next?

> = Current topic

Reverse engineering


> Introduction to the Rhapsody framework (OXF) More about containers

Managing interrupts


Generating reports

Using the Java API












28


Framework

The Rational Rhapsody framework is a collection of baseclasses 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 theOXF.

CPU

E x t e r n a l

C o d e

RTOS

OXF Framework

Rational Rhapsody

Generated 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 theapplication.

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 OperatingSystem

1. It serves as a way to standardize the calls to the real time operatingsystem.

2. It is linked into your final application and in regulatedenvironments every piece of code needs to be known






32


Event driven framework interfaces

The principal interface classes in the Event Driven Framework

are:

IOxfActive

IOxfReactive

IOxfEvent

IOxfTimeout






34


OMEvent

OMEvent is a base class for all signal and timed events:

OMEvent has a unique ID.

OMEvent knows the address of itsdestination (receiving reactiveobject).

There are specific Frameworkevents for internal usage.

Events may or may not bedeleted after consumption (if static).

OMEvent may provide its own customdestroy() operation, for example, toreuse the event in a memory pool.






35


OMTimeout

OMTimeout is a base class for all Rational Rhapsody timedevents:

OMTimeout inherits everything fromOMEvent.

OMTimeout events have aspecial ID.

OMTimeout adds a delay time attribute.

OMTimeout may be canceled beforeit matures, or afterbeing queued.






36


OMReactive

OMReactive 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 toput events into the input message queueof its active class using OMThread::queue().

It provides the operations handleEvent()

for asynchronous signal events, andhandleTrigger() for synchronous events.

It provides operations to schedule andcancel relative timeouts.

It defines virtual operations forthe code generator in order to implementthe state machine of the application class,for example, rootState_processEvent().






37


OMThread

OMThread is a base class for all «active» objects for multi-threaded applications.

OMThread creates one event Queueand a dispatchingGuard. It runsits execute() operation in an operatingsystem thread.

The operation queue() enables you toput events of type IOxfEvent into themessage queue.

execute() readsmessages from the queue by default, anddispatch() them calling the reactivedestination’s handleEvent().






38


OMThread(continued)

Each OXF thread waits on an event queue for incomingevents:

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 CashRegister example.

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


OMProtected

OMProtected is used to protect an operation from concurrentaccess. 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


OMMemoryManager

The framework includes a memory manager that overrides newand delete to allocate memory.

For more information, see the OMMemoryManager.h file.






43


Extending memory management

There 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 framework

By 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

E x t e r n a l

C o d e

IDF Framework

Rational Rhapsody

Generated Code

For more information, see the documentation included in the

V73_RiCpp_InterruptDrivenFramework model.






45


Synchronous framework

OXF and IDF both allow asynchronous and synchronouscommunication.

If you want only synchronous communication so that thebehavior is deterministic, then use triggered operationsinstead 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

Rational Rhapsody

Generated Code

E x

t e r n a l

C o

d e

SF Framework






46


No framework

If the framework is not required, then you set the stereotype«NoFramework» to the configuration.

Without the framework, there is no code generation for activeclasses, ports, statecharts, relations with unboundedmultiplicity, and so on.

This stereotype is provided in the same profile used during the CashRegister exercise.






47


Container classes

Template based containers OMList<Concept>

OMCollection<Concept> OMMap<Key,Concept> OMIterator<Concept>

Untyped containers that do not use templates OMUList OMUCollection OMUMap OMUIterator

Miscellaneous OMString OMBoolean

These classes are in Rhapsody\Share\LangCpp\oxf.






48


Operating System Adapter Layer

To work with almost any operating system, Rational Rhapsodyprovides 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. Forexample, you can test on a host using Windows, then deployon a target with INTEGRITY, VxWorks, Windows CE, OSE,Nucleus, Linux, ThreadX, or QNX, pSOS

The adapter layer is implemented using the Abstract Factorydesign 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


VxWorksadapter






52


INTEGRITY adapter






53


Nucleus adapter

OMOSSemaphoreOMOSMessageQueueOMOSThread OMOSMutexOMOSEventFlag OMOSTimer

NuMutex NuOSMessageQueueNuOSEventFlag NuOSSemaphoreNuThread NuTimer

OMOSFactory

NuOSFactory






54


Using the adapter

To 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 Engineering


Introduction to the Rhapsody framework (OXF)> More about containers

Managing interrupts


Generating reports

Using the Java API












56


OMContainers

You have seen that for therelation of multiplicity *,

Rational Rhapsodygenerates the following:

OMList<Observer*>

OMCollection<Observer*>

OMMap<int,Observer*>






58


STLContainers

If you set the propertyContainerSet to

STLContainers, thenRational Rhapsody usesthe STL (standard templatelibrary).

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


OMUContainers

If you set the propertyContainerSet to

OMUContainers, thenRational Rhapsody usesthe untyped containers:

OMUList

OMUCollection

OMUMap






62


Static arrays

Sometimes it is more efficient (though less safe) to use astatic array.

To use a static array, the multiplicity must be bounded, forexample, MAX_OBSERVERS.






63


What’s next?

> = Current topic

Reverse engineering



> Managing interrupts


Generating reports

Using the Java API












64


Interrupt service routines

Setting up interrupt service routines varies from one CPU toanother and from one OS to another. With Rational Rhapsody,

you should use the same method you would use withoutRational Rhapsody.

Example: with VxWorks:

The ISR routine must be static and non-animated.






65


Sending events from ISR routines

To send an event from an ISR routine, there is a specialmacro GEN_ISR that can be used.

See the InterruptHandler model for more information.






66


What’s next?

> = Current topic

Reverse engineering



Managing interrupts

> Multicore development

Generating reports

Using the Java API












67


Multicoredevelopment

Many companies are looking at multicore processors as anopportunity to realize significant price and performance

improvements.Concerns are:

Adding complexity to the product development process with many moredesign options to consider such as number of cores, communications, andload distribution.

Risks that specifying the wrong architecture can significantly reduce oreven eliminate multicore benefits.

Versus






68


How Rational Rhapsody can help multicore development

Rational 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 manualcoding tasks.

Animation and execution of instrumented models to assist analysis.






69


Viewing multi-core allocation using Rhapsody






70


Visualization of multicore execution

Test and Debug at the rightlevel:

Create sequence diagramsduring execution, highlightingcore allocation to betterunderstand core utilization.

Simulated time mode foranimation to help supporttime calculations onmulticore applications.

Simulation of generated codeon third-party host simulatorsfor early design validation.






71


Use automated generation to build applications

Rapidly support design decisions:

Generate structure, behavior, and IPC

Application mappings used to generate optimized code

Leverage the modeled trade-offs and deploy tasks to cores

Target tasks again and regenerate

Change OS, IPC, cores, and processors, and regenerate






72


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


> Generating reports

Using the Java API












73


Reports

There are three ways that you can generate a report:

Report on model

IBM Rational Rhapsody ReporterPLUS

Rational Publishing Engine (RPE)

ReporterPLUS and Rational Publishing Engine have additional licenses associated with them.






74


Report on model

Use Report on model to generate a quick but simple .rtf

format file.






75


Rich text format output

This generates a simplerich text format (.rtf)

file. The report generation is

quick, but thereis little control over theformatting.






76


Rational Rhapsody ReporterPLUS

With the Rational Rhapsody ReporterPLUS, you can generateHTML, RTF, Microsoft Word, or Microsoft PowerPoint files. You

can also use provided templates, or you can customize yourown templates to format the documentation as you want.

Rational Rhapsody ReporterPLUS has a graphical IDE forcreating templates.






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 Studio

Create 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 -Launcher

Create documents fast using the easy and intuitive RationalPublishing Engine Launcher.






83


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


Generating reports

> Using the Java API












84


Simple Java program

You can use Eclipse to create a Java project that referencesthe Rational Rhapsody Java API.

In the Case Study, you entered several use case descriptionsbased 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 program

You can run the Java programfrom within the Eclipse

environment, or add a helperto invoke the program byright-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-in

To get betterperformance from

the Java program,rewrite it as aplug-in and createa compressed filefrom 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.hep

Write a helper file so that the plug-in is loaded every timeRational Rhapsody starts.






89


Loading a helper file

Add the following code to the site.prp or siteC++.prp file toload the helper file:

The next time that Rational Rhapsody starts, you can format ause case example.






90


The built-in model checker

Some checks are run every time that code is generated, forexample checking to ensure that there is a default transition.

You can run the same checks and more by clickingTools > Check Model.






91


Customizing the model checker

Use the API to write your own model checks that can beadded 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 classesthat 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, theseare classes that were added inadvertently. They usually have a name thatends in _1, _2, and so on.






92


CustomChecksHelper






93


HistoryCheck

See CustomChecksHelper.zip for the complete code.






94


Helper file

The checks can be added with a Helper file.






95


Viewing the custom check results

Every time that Rational Rhapsody generates code, the customchecks execute.






96


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


Generating reports

Using the Java API

> Collaborative working – understanding units











97


Overview

If you are interested in collaboration with Rational Rhapsody, thissection covers:

How Rational Rhapsody facilitates collaborative working

Configuration management of Rational Rhapsody models

Differencing and merging of Rational Rhapsody models

When dealing with the concept of collaborative working, thereare several issues to consider: How best to structure the model to facilitate team working

How to restrict access to model elements

How to merge models when they diverge






98


Parallel working strategies

There 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 intoa 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 –units

Rational Rhapsody models have the concept of a unit.

A unit is a model element that is stored as a separate file inthe model repository.

The following page lists all the model elements that can bestored as separate units. Out of the box Units are:

– The Project

– Packages

– Components






100


Rhapsody file extensions

.omd

.omd

.omd

.omd

.std

.msc

.ucd

Diagrams

Block Definition

Parametric

Requirement

Package

Internal Block

Sequence

Use 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 icon

Each unit is identified in the browser by this symbol:

To create a unit, right-click the item, and then click Create Unit.






102


Unit properties

New model elements can be made into units automatically if thefollowing properties are set:

Existing elements are unaffected

You may create a script to convert existing model elements into units

This is not the SysMLblock. It is a RationalRhapsody-specific modelelement that is due to bephased out.

Classes, Blocks, Actors,

and Use Cases

Objects, Parts






103


Referencing units

Units from one model can be added to others as a:

Reference

– When the owner of the model element modifies it. Changes arepropagated to any model that references it.

– Changes are only seen when the model referencing the element isreloaded.

Unit

– A copy of the original unit is made in another project.

– The copy is disconnected from the original. Changes are notpropagated.






104


Configuration Management (CM)

Referencing may be used with configuration management.

Putting models into configuration management is discussed later in this

module.






105


Model structure

Model 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 levelmodel artifacts that define their requirements.






106


Example model structure






107


Importing units using Add to Model

Add 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 subunits

When adding As Unit, you can choose not to add subunits. Initially, subunits are added, but are stubbed out (unloaded).

New model withSystemRequirementsPkgadded 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 unitsare essentially orphans that should be deleted.






110


Locating unresolved elements

The advanced search dialog includes an option to search forunresolved elements. Click Edit > Advanced Search and

Replace.






111


Loading multiple projects

More than one project can be open in the Rational Rhapsodyworkspace.

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.






113


Multiple browsers

You can view packages in separate browsers. This makes iteasier 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 reference

You can drag a unit to another project to create references whenmultiple projects are open.

The Common project must be the active project before attempting thisoperation.

In all cases, subunits are imported automatically. If subunits are notrequired, then use Add to Model (as unit). If Adding By Reference, subunitsare always included.

Creates a reference to theunit in the other project






115


Drag between projects

When multiple projects are loaded, any unit can be dragged fromone 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, whilechanging unit of the inactive project to a reference of the newly movedunit.

– 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 unit

To move a unit by dragging, press the Alt key.

Caution: This operation isirreversible

Moves the Package, butleaves behind a reference






117


Project lists

You can save project lists:1. Click File > Open.

2. Before opening a new project,Rational Rhapsody gives youthe option to save the openproject list and all its projects.






118


Partial loading

When you work on a large model, you often only need to workon 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 projects

Unloaded units display as Stubs and have a (U) prefix.

Units can be loaded with or without subunits, and can beunloaded using the pop-up menu.






120


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


Generating reports

Using the Java API


> Configuration management










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. Youchoose SCC or command line in the project properties, or youcan set it up in the site.prp file.

Rational Rhapsody checks in and checks out parts of themodel. 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 interface

Before using the configurationmanagement, you must decide

whether to use the SCCinterface 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 options

Before you use the configurationmanagement, there are

various options that you canset, for example,what should happen if amodel element gets deleted,moved, or renamed.






124


Using the SCC interface

Tree viewFlat view






126


Step 2: Add to archive

After you connect to the archive, add the model elements tothe archive using the Tree view:

1. Select the project.

2. Click Add to Archive.






128


What has changed?

To see the difference between thecurrent model and the archive,

select the unit and click Diffwith Rhapsody.

To see the differencebetween two different

models, use the RationalRhapsody DiffMerge tool.






129


Rational Rhapsody DiffMergetool

The two browsers are interposed. The decorations indicatewhere there are differences between the models.






130


Viewing model differences

You can view just the model differences:






131


Ignoring graphical differences

By default, Rational Rhapsody DiffMerge ignoresany changes that are graphical, for example,

where a class has been moved on a diagram.






132


Viewing the diagram differences

Click Highlight Differences to highlight all the differences.

Click First difference to highlight the first difference. ClickNext to highlight each subsequent difference.






133


Merging

Click Start Merge to merge two models into one.

Either of the models can be used as a starting point by usingthe 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 toRational Rhapsody.






134


Base-aware merge

You can use the Rational Rhapsody DiffMerge to perform abase-aware comparison and merge.

Ideally, you would use a CM tool such as Rational Synergy orRational ClearCase to allow automatic merging.






135


Base-aware Diff






136


CM status

When using the SCC interface, you can display the status ofeach model element in the browser:

This package has nosymbol, since it is not yetControlled by CM .






137


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


Generating reports

Using the Java API



> Rhapsody in Eclipse and Jazz/Rational TeamConcert









138


Rhapsody platform integration with Eclipse

Rational Rhapsody can also be integrated into Eclipse. TheRational Rhapsody plug-in for Eclipse is available in the Rational

Rhapsody installation.






139


Creating Rational Rhapsody projects in Eclipse

When installed you can create Rhapsody projects inside Eclipse.






140


Rational Rhapsody Modeling perspective in Eclipse






141


Creating new model elements

In the Rational Rhapsody Modeling Perspective, how youcreate 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 perspective

You can customize your Rational Rhapsody perspective byshowing 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 specificviews.






143


Rational Rhapsody debug perspective






144


Managing collaboration using Rational Team Concert

The Rational Rhapsody Eclipse integration with Rational TeamConcert provides collaborative teamwork on the Jazz™ platform.






145


Invoking DiffMergein Rational Team Concert

Use Rational Rhapsody DiffMerge to perform all mergingduring acceptance of incoming changes.

When there are no conflicts, the merging is done automaticallyunless you specify merge manually.






146


Learning more about Jazz

Rational Team Concert is a collaborative work environment fordevelopers, architects, and project managers with work item,

source control, build management, and iteration planningsupport

Jazz is an initiative to transform software delivery making itmore collaborative, productive, and transparent

To learn about Jazz and Rational Team Concert see https://jazz.net/learn/






147


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


Generating reports

Using the Java API




> Introduction to Test Conductor Useful tips








148


TestingProfile

The Rational Rhapsody TestingProfileprovides a number of stereotypes

that conform to the UML Testing Profile: «SUT»

«TestCase»

«TestObjective»

«TestContext»

«TestComponent»

«TestConfiguration»






149


Testing phases

Create 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 independentlyof the rest of the system. You can create the Test Architecture manuallyor automatically.

Create Test Cases You 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 errorscan be reported and analyzed.






150


Testing artifacts

All testing artifacts are UML modelelements.

You can manage artifacts withconfiguration management in thesame way as any other RationalRhapsody model element.






151


Test architecture

You can create a test architecture by selecting a class to test,and then creating a test architecture similar to the following

example:






152


TestScenario

After you have a test architecture, you can describe testscenarios using sequence diagrams such as in the following

example:






153


TestCase: based on test scenarios

A TestCase can play back anumber of TestScenarios in a

specific order to verify that themessages received are asexpected.

Each TestScenario can beparameterized, and used severaltimes with different parameters.






154


Manual test cases

If you have some complex structures that you want to pass, orwant to check return values or output values, it is difficult to do

graphically with sequence diagrams. In these cases, you canwrite manual test cases. You can either manually write the code,or you can use a flow chart:






155


Building the test context

Before you run the TestCases, you mustbuild the TestContext.






156


Executing the TestContext

To run a TestCase, click Execute TestConent.






157


Test results

After the test completes, aTestResult and a

CoverageResultis added to the TestCase.






158


Running all the test cases

You can run all the TestCases in mode batch:






159


Code coverage

Animation can be switched off for the SUT. Switching off theanimation allows Rational Rhapsody TestConductor to be used

with tools such as IBM Rational Test RealTime, in order to getthe Dynamic Code Coverage. With Dynamic Code Coverage,there is no unused code.






160


Failed test

If a test fails, then a sequence diagram can be automaticallyadded to the model to help analyze the problem.

Expectedmessage

Incorrectlyreceivedmessage

Correctlyreceivedmessage






161


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


Generating reports

Using the Java API




Introduction to Test Conductor > Useful tips








162


Useful tips 1

Keep statecharts simple. If they are too complex, then usesub-statecharts.

Draw states as small as possible, and as close as possible toother states. Small states are more readable during animation,especially when there are several diagrams open at the sametime.

Do not call many actions on a statechart. It makes thediagram difficult to read. Instead, call a new operation thatcalls the actions.

To aid navigation within the model, set up hyperlinks for everyuse case, class, and package.






163


Useful tips 2

Look at the Rational Rhapsody samples and revisit the CashRegister 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 filesoverwrite each other.

When working with large projects, it is essential to divide themodel into components. The interfaces between thesecomponents should be well-defined. Then, work can becarried out simultaneously and independently by differentteams on each component.






164


Useful tips 3

Do not put everything onto a single diagram. This can makereading the diagram difficult. Using a couple of diagrams,

depicting different views can really help in communicating themodel.

Use an iterative approach similar to the approach taken duringthis course—constantly model, save, generate, make, andrun. 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 conventions

Start 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 attributeswith a lowerCase.

Use an UpperCase to separate concatenated words, forexample, restartSecondTimer().

These conventions help when reading diagrams and when recalling names of model elements.






166


What’s next?

> = Current topic

Reverse engineering



Managing interrupts


Generating reports

Using the Java API





> Avoiding common mistakes







167


Deadlock situation 1






168


Deadlock situation 2






169


Transition or reaction in state?

Reactionsin state






170


Null transitions

Each time a state is entered, Rational Rhapsody checks to see if there 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, themessage Infinite loop of Null Transitions displays.

A NullTransition is atransition thathas no trigger.






171


What is done first?

When in the waiting state, what happens when the evCoin eventis received?

Answer: The value of coin is tested BEFORE it is assigned!






172


Attribute access

Setting the access for an attribute modifies the access for theaccessor and mutator, not for the attribute itself. Attributes are

always protected by default.






174


Generate support request

Rational Rhapsody includes a special function that facilitatessending an email to Technical Support.

This function collects information about your system, and theRational Rhapsody environment and model, then creates acompressed file.

The compressed file can then be sent to support.

Alternatively, the compressed file can be transferred toanother machine and sent in an email.






175


Support request

Quickly collectsproblem information

Information aboutRational Rhapsodyand systemautomaticallycollected






176


Adding files, screen captures, videos, and other information

Model and extra filescan be quickly added

Screensnapshotscan be

captured

Videos can becaptured to aidproblem description






177


Sending the email

All models, files, and screen captures areautomatically compress and attached to an email.






178


eLearning

eLearning is Web-based, self-paced training.

Interactive multi-media features: Demonstrations

You try it exercises

Quizzes with feedback

Post-learning tests to ensure that knowledge has been acquired

Intended as an introduction to: Modeling languages

Advanced topics

Add-on products






179


eLearning: current courses

For a listing of all courses thatare offered, see:

http://www.ibm.com/training






180


Recommended reading






181


Module summary

You should now know enough about Rational Rhapsody tostart creating your own projects. You should have basic

familiarity with the following topics: Reverse Engineering/Code-centric development

The Rational Rhapsody Framework

Generating reports

Using the API

Using Configuration Management


Rational Rhapsody TestConductor

To develop more in-depth skill and knowledge about the

topics listed above, there is additional Rational RhapsodySpecialist training available.






182


Further information

Additional Trainingwww.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/

Twitter http://twitter.com/ibmrational




Course survey

Please 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 eachcourse and request certificates foreach as well.