ibm-rationalswarchmanual rd541gv1 insman

IBM Rational University

Essentials of IBM Rational Software Architect v7.0 RD541/DEV396 February 2007 Instructor Manual Part No. 800-027292-000

IBM Corporation Rational University Essentials of IBM Rational Software Architect v7.0 Instructor Manual February 2007 Copyright © International Business Machines Corporation, 2007. All rights reserved. This document may not be reproduced in whole or in part without the prior written permission of IBM. The contents of this manual and the associated software are the property of IBM and/or its licensors, and are protected by United States copyright laws, patent laws, and various international treaties. For additional copies of this manual or software, please contact Rational Software. IBM and the IBM logo are trademarks or registered trademarks of IBM Corporation, in the United States, other countries or both. Rational, the Rational logo, ClearCase, ClearCase LT, ClearCase MultiSite, Unified Change Management, Rational SoDA, and Rational XDE are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both. WebSphere, the WebSphere logo, and Studio Application Developer, are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both. Microsoft Windows 2000, Microsoft Word, and Internet Explorer, among others, are trademarks or registered trademarks of Microsoft Corporation. Java and all Java-based marks, among others, are trademarks or registered trademarks of Sun Microsystems in the United States, other countries or both. UNIX is a registered trademark of The Open Group in the United States, other countries or both. Other company, product and service names may be trademarks or service marks of others. Printed in the United States of America. This manual prepared by: IBM Rational Software 555 Bailey Ave. Santa Teresa Lab San Jose CA 95141-1003 USA

DEV396 Essentials of IBM Rational Software Architect V7 Table of Contents

Contents

Module 0 About This Course Introductions............................................................................................................ 0-2 Intended Audience................................................................................................... 0-3 Prerequisites............................................................................................................. 0-4 Course Goals and Objectives................................................................................... 0-5 Course Agenda ........................................................................................................ 0-6

Module 1 Getting Started with Rational Software Architect Module Objectives................................................................................................... 1-2 The IBM Rational Software Delivery Platform....................................................... 1-4 Basic User Interface................................................................................................. 1-7 Projects and Tasks ................................................................................................. 1-17 Lab 01: Creating a Project ..................................................................................... 1-23 More on Navigation............................................................................................... 1-24 Lab 02: Customizing Perspectives......................................................................... 1-31 What is Rational Software Architect? ................................................................... 1-32 Review................................................................................................................... 1-35

Module 2 Model Structure and Templates Module Objectives................................................................................................... 2-2 Introduction to Models ............................................................................................ 2-3 Modeling Perspectives and Views........................................................................... 2-8 Creating and Organizing Projects and Models ...................................................... 2-17 Demonstration: Model Structure and Building Blocks.......................................... 2-27 Review................................................................................................................... 2-28

Module 3 Creating UML Diagrams Module Objectives................................................................................................... 3-2 UML Diagrams........................................................................................................ 3-3 Creating UML Model Diagrams.............................................................................. 3-7 Lab 03: Create UML Diagrams ............................................................................. 3-14 UML Visual Development .................................................................................... 3-15 Query Diagrams..................................................................................................... 3-19 Lab 04: Create Browse and Topic Diagrams......................................................... 3-23 Review................................................................................................................... 3-24

Module 4 Creating UML Diagrams of System Structure Module Objectives................................................................................................... 4-2 Class Diagrams ........................................................................................................ 4-5 Lab 05: Create a Class Diagram ............................................................................ 4-16

© Copyright IBM Corp. 2007 i Course materials may not be reproduced in whole or in part without the prior written permission of IBM.


Object Diagrams .................................................................................................... 4-17 Composite Structure Diagrams.............................................................................. 4-20 Lab 06: Create Composite Structure Diagrams ..................................................... 4-31 Component Diagrams ............................................................................................ 4-32 Lab 07: Create Component Diagrams ................................................................... 4-34 Deployment Diagrams ........................................................................................... 4-35 Lab 08: Create Deployments Diagrams................................................................. 4-38 Review................................................................................................................... 4-39

Module 5 Creating UML Diagrams of System Behavior Module Objectives................................................................................................... 5-2 Use-Case Diagrams ................................................................................................. 5-4 Lab 9: Create Use-Case Diagrams........................................................................... 5-7 Activity Diagrams.................................................................................................... 5-8 Lab 10: Create Activity Diagrams ......................................................................... 5-24 Interaction Diagrams ............................................................................................. 5-25 Lab 11: Create Sequence Diagrams....................................................................... 5-39 Lab 12: Create Communication Diagrams ............................................................ 5-40 State Machine Diagrams........................................................................................ 5-41 Lab 13: Create State Machine Diagrams ............................................................... 5-53 Review................................................................................................................... 5-54

Module 6 Team Development Module Objectives................................................................................................... 6-2 Configuration Management in Rational Software Architect ................................... 6-4 Compare and Merge Models ................................................................................. 6-11 Lab14: Compare and Merge a Model .................................................................... 6-16 Lab15: Combine Models ....................................................................................... 6-19 Model Publishing................................................................................................... 6-20 Demo: Model Publishing....................................................................................... 6-23 Lab16: Publish a Model and Generate a Model Report......................................... 6-24 Review................................................................................................................... 6-25

Module 7 Applying Patterns and Transformations Module Objectives................................................................................................... 7-2 Asset- and Pattern-based Development ................................................................... 7-3 Applying Design Patterns ...................................................................................... 7-13 Demo: Applying a Design Pattern ......................................................................... 7-18 Lab 17: Apply Patterns .......................................................................................... 7-19 Applying Transformations..................................................................................... 7-20 Demo: Apply a Transformation............................................................................. 7-30 Lab 18: Run a UML to Java Transformation......................................................... 7-31 Packaging Reusable Assets.................................................................................... 7-32 Review................................................................................................................... 7-36

© Copyright IBM Corp. 2007 ii Course materials may not be reproduced in whole or in part without the prior written permission of IBM.


Module 8 Traceability Module Objectives................................................................................................... 8-2 Integration with RequisitePro .................................................................................. 8-5 Lab 19: Create Traceability Links ......................................................................... 8-14 Integration with WebSphere Business Modeler .................................................... 8-15 Exploring Traceability Relationships .................................................................... 8-24 Review................................................................................................................... 8-27

Module 9 Static Analysis and Code Review Module Objectives................................................................................................... 9-2 Automated Static Analysis....................................................................................... 9-6 Demo: Code Review.............................................................................................. 9-19 Lab 20: Perform Static Analysis............................................................................ 9-20 Manual Static Analysis .......................................................................................... 9-23 Review................................................................................................................... 9-27

Module 10 Summary Software Development with Rational Software Architect..................................... 10-2 Design: Models and Diagrams............................................................................... 10-3 Generate: Patterns and Transformations................................................................ 10-4 Identify: Visualization and Structural Review....................................................... 10-5 Analyze: Code Review .......................................................................................... 10-6 Resolve: Reconcile and Refactor........................................................................... 10-7 Process: Rational Unified Process (RUP) Methodology ....................................... 10-8

© Copyright IBM Corp. 2007 iii Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Essentials of IBM Rational Software Architect

Instructor Notes:

Module 0 - About This Course 0 - 1© Copyright IBM Corp. 2007

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

®

IBM Software Group

© 2007 IBM Corporation

DEV396: Essentials of IBM Rational Software Architect, V7

Module 0: About This Course

This module will require approximately 30 minutes to complete:


Instructor Notes:



2

IntroductionsYour organization

Your role

Your background and experienceSoftware development experienceObject technology experience

Course expectations

Introductions: instructor and students.

1. Introduce yourself. Give your background. Hand out business cards.

2. Get to know the student profile:

• Enterprise software development and OOP experience

• Jobs, roles, and activities

• Course expectations

3. Hand out sign-in and registration form.


Instructor Notes:



3

Intended AudienceThe intended audience for this course is software developers who architect and develop enterprise applications, and who:

Use the Unified Modeling Language (UML) for object-oriented analysis and design (OOAD)

Develop Java™ applications

Apply design patterns in their system design

Work as part of a team of developers

Essentials of IBM® Rational® Software Architect teaches architects, designers, and lead developers how to apply Rational Software Architect to perform model-driven development, apply patterns and perform model transformations, and develop software with Software Architect as part of a development team.

The intended audience is the architect and lead developer who designs enterprise applications using model-driven methods.


Instructor Notes:



4

PrerequisitesThis course assumes that students:

Have experience architecting and designing Java solutions

Have taken the following courses covering IBM® Rational® tools, or have equivalent experience:

DEV275: Essentials of Visual Modeling with UML 2.0 (ILT) or the DEV110: Principles of Modeling with UML 2.0 (WBT)

DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0 (ILT) or the DEV111-113 and 160 Principles of ... with UML 2.0 (WBT) series

This course does not provide in-depth explanations of UML or OOAD concepts and notation, and it is expected that students already have this background. This course will cover how the diagrams can be created using Rational Software Architect.

This course will cover how UML diagrams can be created using Rational Software Architect but does not provide in-depth explanations of UML or OOAD concepts and notation.


Instructor Notes:



5

Course Goals and ObjectivesAfter completing this course, you will be able to perform the following tasks with IBM® Rational® Software Architect:

Navigate the user interface and create perspectives

Create new UML Model projects

Create structural and behavioral UML diagrams

Compare, merge, combine, and publish diagrams

Apply patterns and transformations

Create traceability to IBM® Rational® RequisitePro® and IBM® WebSphere® Business Modeler

Perform static analysis on Java™ 2 Platform, Standard Edition (J2SE™ platform) and Java™ 2 Platform, Enterprise Edition (J2EE™ platform) systems

This course introduces Rational Software Architect for modeling enterprise applications. The course includes a discussion of team development issues, patterns, and transformations, and how to use code review features for architectural control and architectural discovery.

The course assumes a working knowledge of Java concepts, and the UML. The course shows how to use Rational Software Architect (RSA) to build simple models and diagrams, as well as how to merge models and conduct code review and structural review.

The course focuses heavily on hands-on lab activities to give students the knowledge and skills to implement an enterprise application.


Instructor Notes:



6

Course AgendaDay 1

Module 0: About This Course

Module 1: Getting Started with Rational Software Architect

Module 2: Model Structure and Templates

Module 3: Creating UML Diagrams

Module 4: Creating UML Diagrams of System Structure

Module 5: Creating UML Diagrams of System Behavior

Day 2

Module 6: Team Development

Module 7: Patterns, Transformations, and Visualization

Module 8: Traceability, Model Querying, and Model Validation

Module 9: Static Analysis

Module 10: Summary

The time it will take for each module may vary depending on your students’ needs.

The Day 1 and Day 2 suggestions are a rough guide of what might be delivered on each day.

Certain modules begin with a discussion slide that allows the instructor to ask the students about their experience in a certain area. This should enable you to make decisions on whether to cover certain topics in depth, more quickly, or to skip some topics entirely.


Instructor Notes:



7

Logistics

Morning2 15-minute breaksLunch 1 HourAfternoon2 15-minute breaks

Familiarize students with the facility, if necessary.

• Restrooms

• Phones

• How people from the outside can reach them or leave a message

• Where they can connect to the internet (where possible)


Instructor Notes:



8

Essentials of IBM Rational Software Architect, V7

Instructor Notes:

Module 1 - Getting Started with Rational Software Architect 1 - 1© Copyright IBM Corp. 2007


®

IBM Software Group


DEV396: Essentials of Rational Software Architect, V7

Module 1: Getting Started with Rational Software Architect

This module will require approximately one hour to complete. The labs will each take 15 minutes.


Instructor Notes:



2

Module ObjectivesAfter completing this module, you will be able to:

Describe the underlying framework behind all IBM® Rational® Software Delivery Platform tools.

Navigate the basic user interface of any IBM Rational Software Delivery Platform tool.

Create, modify, and save a Perspective

Create and modify a Project

Describe the basic purpose of Rational Software Architect

The purpose of this module is to introduce you to the common framework beneath the IBM® Rational® Software Delivery Platform and provide an introduction to Rational Software Architect.


Instructor Notes:



3

Discussion

How much experience do you have with Eclipse or Eclipse-based products?

This module provides the students with a background on the Eclipse functionality and navigation beneath Rational Software Architect (RSA).

Take a moment to go around the room and find out what kind of experience the students may already have Eclipse or Eclipse-based tools.

If all of the students are already familiar with Eclipse functionality, you may skip ahead to slide 30, which discusses Eclipse cheat sheets. These slides are necessary because all of the labs in this course are delivered as Eclipse cheat sheets, and this gives the student a guide to using cheat sheets.

If some or none of the students are familiar with Eclipse, it is recommended that you cover all of the material in this module.


Instructor Notes:



4

Where Are We?The IBM Rational Software Delivery PlatformBasic User InterfaceProjects and TasksMore on NavigationWhat is Rational Software Architect?


Instructor Notes:



5

The IBM Rational Software Delivery Platform The IBM Rational Software Delivery Platform is a complete solution for developing software and software-based systems.

Most platform tools are based on the Eclipse framework, which:

Simplifies development

Integrates the enterprise environment

Unifies technologies into a single development environment

Delivers flexibility and choice

Most platform tools are based on the Eclipse framework, which:

•Simplifies development environment complexity and consolidates the use of diverse development technologies.

•Makes it easier to develop, test, and deploy high-quality software by integrating the enterprise environment.

•Provides multi-language support that unifies Java™ 2 Platform, Enterprise Edition (J2EE™) technology, Web services, UML, C++, and other technologies into a single development environment tailored to specific development needs.

•Delivers flexibility and choice as an open source, highly extensible platform that runs on many operating systems.


Instructor Notes:



6

What is Eclipse?

Eclipse is a platform for building, deploying, and managing software across the lifecycle.

The Eclipse platform encourages rapid development of integrated features based on a plug-in model.

The Eclipse platform user interface is featured in all IBM Rational Software Delivery Platform tools.

Eclipse is comprised of extensible frameworks, tools and runtimes. The Eclipse platform provides the basis for the integration of plug-ins into a common workbench.


Instructor Notes:



7

Where Are We?The IBM Rational Software Delivery PlatformBasic User Interface Projects and TasksMore on NavigationWhat is Rational Software Architect?


Instructor Notes:



8

The WorkspaceWhen you open any tool in the IBM Software Delivery Platform for the first time, you will see the Workspace Launcher dialog.

A workspace is the location where you store your work.

Any resources (projects, folders, and files) that you are working on are available in this workspace.

The workspace itself is a directory, which defaults to the name workspace. You may locate it anywhere you want. It may contain either new projects as sub-directories, or just references to projects that exist elsewhere on the file system.

If possible, you should give the workspace a short path name. The path can get rather long to some assets, and Microsoft® Windows® can have issues with long path names.


Instructor Notes:



9

The Welcome View

Basic User Interface: The Welcome ViewAfter the workspace dialog, the Welcome view will be the first thing you see.

OverviewGet an overview of the features

What’s NewFind out what is new

SamplesTry out the samples

TutorialsGo through tutorials

WorkbenchGo to the workbench

Note: You can get the Welcome view back at any time by selecting Help > Welcome.

Web ResourcesRead more on the web

MigrateMigrate to the new release

First StepsMake first steps

The Welcome page is the first page you see when you first launch Eclipse. Its purpose is to introduce you to the product. Welcome content typically includes an overview of the product and its features, tutorials to guide you through some basic tasks, samples to get you started, and so on.

Note that the “What’s New” function is only available from the Welcome View.


Instructor Notes:



10

The Workbench

Basic User Interface: The WorkbenchThe workbench acts as a hub for identifying all of the plug-in functions. Each workbench offers one or more perspectives, which contain views and editors to display information.

In the workbench you can navigate resources, as well as view and edit the content and properties of these resources.

A shortcut bar appears in the top right corner of the window. This allows you to open new perspectives and switch between ones already open.

The name of the active perspective is shown in the title of the window, and is highlighted in the shortcut bar.

After you close the Welcome screen, the first thing you will see is a dialog that allows you to select your workspace. The workspace is the directory where your work will be stored. For now, just click OK to pick the default location. Initially, in the first Workbench window, you see the Resource perspective, with only the Welcome view visible.

Note: The title bar of the Workbench window indicates which perspective is active. In this example, the Resource perspective is in use. The Navigator, Tasks, and Outline views are also open, along with an editor.


Instructor Notes:



11

PerspectivesA perspective defines a set of editors and views arranged in an initial layout for a particular role or task.

For example, the initial layout of the Resource perspective makes the Navigator view and editor visible, and arranges them in a default layout. The default set of views is different for each of the perspectives.

You can open the workbench to any of several perspectives, or you can define your own perspective. Different perspectives are better suited for different user tasks. Common perspectives include:

Resource The default perspective of most tools

JavaFor working with Java projects

CVS Repository ExploringFor checking projects in and out securely

Java Browsing For browsing the structure of Java projects

DebugFor debugging a program

Plug-In DevelopmentFor developing Eclipse plug-ins

Tip: The Window > Preferences > General > Perspectives allows you to specify general perspective behavior.


Instructor Notes:



12

Views and Editors

A view is used to navigate a hierarchy of information (such as the resources in the Workbench), open an editor, or display properties for the active editor.

The Navigator View provides a hierarchical view of resources and allows you to open them for editing.

An editor is used to edit or browse a resource.

An editor or view that is active is the one whose title bar is highlighted. Here, the Navigator view is active.

Views and editors are the main visual entities that appear in the Workbench. In any given perspective, there is a single editor area that can contain multiple editors, and a number of surrounding views that provide context.


Instructor Notes:



13

EditorsEditors allow document editing from within the workbench for various types of artifacts, including text and diagrams.

The name of the file appears in the tab of the editor. If an asterisk (*) appears at the left side of the tab, this indicates that the editor has unsaved changes.

Several editors can be open at the same time, but by default are stacked in the user interface. You can arrange them to make more than one visible at a time.

Depending on the type of file being edited, the appropriate editor is displayed in the editor area. For example, if a txt file is being edited, a text editor displays in the editor area.

Note: If you attempt to close the editor or exit the Workbench with unsaved changes, you will be prompted to save the changes.


Instructor Notes:



14

More on PerspectivesYou can design a perspective with a predefined set of functions that you can perform while in it.

You can have one or more perspectives open at a time, or switch between perspectives from the shortcut bar.

When opening a perspective, you actually open an instance of that perspective. Once open, you can tailor the instance for the way you work, then save it.

Once you configure the perspective to your needs, select Window > Save Perspective As...and provide a name for the perspective. The name can be the default perspective name, or a new name.

When selecting Window > Open Perspective, the available perspectives list will include your customized perspective.

When you tailor a perspective instance, Eclipse remembers the settings of open perspective instances so that, when you shut down and restart Eclipse, it restores the instance to how you tailored it. The changes are temporary and apply only to an open instance of a perspective. If you change a perspective instance and then close it, when you open the perspective you will open a new instance based on its original configuration. You can open the workbench to several default perspectives, or define your own perspective.


Instructor Notes:



15

Managing ViewsEach perspective has a number of associated views that can be resized, dragged, or stacked. A view is either:

You can position views within the perspective by dragging and dropping, or by using the view menus:

Single:There are no other views at that position in the perspective

Stacked:There are multiple views available by clicking on a tab at the top of the view pane

Views have two menus. The first, which is accessed by right clicking the view's tab, allows the view to be manipulated.

The second menu, called the view pull-down menu, is accessed by clicking the down arrow.

You can also convert a view into a Fast View. Fast views are hidden views that can be quickly made visible. They work the same as normal views, only when they are hidden they do not take up screen space on the Workbench window. Once you have converted the Navigator to a fast view it will appear in the shortcut bar.


Instructor Notes:



16

Tailoring Perspectives

Select Window > Customize Perspective... to display the Customize Perspective dialog

Another way is to customize the perspective by specifying which items you want to appear on various submenus, the menu bar, and the toolbar.

To add a view that is not included in the current perspective, select Window > Show View from the main menu bar.

One way to tailor a perspective is by adding and deleting views.

The Customize perspective dialog contains two menu tabs:•The Shortcuts page allows you to configure the entries that appear on the short list for several submenus. •The Commands page allows you to configure the items you want to appear on the menu bar and the toolbar.

Note: You can enable or disable various product components such as Java development and plug-in development by using the General > Capabilitiespreference page. Some capability selections have dependencies on other capabilities: disabling a required capability while leaving dependant capabilities enabled will only result in the required capability becoming re-enabled. This is the case when you clear Java Development and Core Team Support.


Instructor Notes:



17



Instructor Notes:



18

Projects

A project is a collection of any number of files and folders. It is a container for organizing other resources that relate to that project.

Projects are used for builds, version management, sharing, and resource organization.

The New Project wizard helps you create a new C or C++ project in the workbench. To access the wizard, select File > New > Project from the menu.

Like folders, projects map to directories in the file system. (When you create a project, you specify a location for it in the file system.)

A project is either open or closed. When a project is open, the structure of the project can be changed and you will see the contents. When a project is closed, you cannot make changes to it in the Workbench.

The resources of a closed project will not appear in the Workbench, but the resources still reside on the local file system. Closed projects require less memory. Since they are not examined during builds, closing a project can improve build time.


Instructor Notes:



19

Importing and Exporting Projects You can use the Import wizard to import a project that exists in a different workspace, or one that previously existed in a workspace, into the Workbench.

The Import wizard can be accessed from the main menu bar: select File > Import.

Importing an existing project allows you to browse your file system for a project and import it as it is currently defined. This results in creating a new project in your workspace, but the existing project is not actually moved onto your file system. Instead, the project is referenced. Be careful when you delete a project in your workspace. If you delete a project from your workspace and answer Yes to the delete from the file system prompt, you will completely delete the files in the original location. If you want to move projects into the workspace directory, you have to copy the content to a workspace directory manually, and import it by pointing to that location. When exporting a project, you have the option of selecting several file formats. Two common formats are: .zip file (you export the project in to a single file) and File System (you export the project to the file system based on the defined hierarchy in the Navigator or Package Explorer). Given that the project already exists on the file system, a key benefit for performing an export is that you do not have to scan your file system, as it may not be in the default location. Recall that an imported project does not necessarily reside in your workspace.


Instructor Notes:



20

Project Interchange

You can export and import projects using the Project Interchange feature for the purpose of sharing projects with other developers.

When you export projects using Project Interchange, the entire project structure is maintained, including metadata files, and you have the convenience of including required projects for an entire application.

The projects can be easily imported into another workspace with a single action.

The Project Interchange mechanism exports projects as they exist in the workbench, including the metadata in those projects. Some of this metadata is specific to your workspace, such as the target server, location of the JRE (Java Runtime Environment), and environment variables. If you import projects into a different workspace, the metadata in the imported projects may not be correct for that workspace. In that case, you must update the metadata after importing the projects. For example, you may need to update the target server runtime for the projects.


Instructor Notes:



21

The Preferences dialog can be accessed from the main menu bar by selecting Window > Preferences.

PreferencesThe Preferences dialog allows you to customize settings for the Eclipse Workbench, as well as its tools and components.

The Preferences dialog pages can be searched using the filter function. Enter keywords or page names in the type filter text field.

The Preferences dialog pages can be searched using the filter function. To filter by matching the page title, simply type the name of the page you are seeking and the available pages will be presented below.

The filter also searches on keywords such as appearance and java. The history controls allow you to navigate through previously viewed pages. To step back or forward several pages at a time, click the drop-down arrow and a list of the most recently viewed preference pages will appear.


Instructor Notes:



22

TasksYou can track specific work items or create reminders by using tasks.

The Tasks view displays the list of tasks to be performed, along with the reference to the resource.

You can automatically generate tasks from templates, or manually create tasks.

To create a task linked to a specific line in a resource, right-click the editor's marker bar for the line you want associated with the task, and select Add Task.

In the editor view, tasks are shown on the editor marker bar as a clipboard with a checkmark.

For tasks that are associated with a resource, double-click the task to open the resource editor and have the cursor positioned on the relevant line.

Following is an example of adding items to the Tasks view manually. If you would like to record reminders to follow up on something later, but do not want the task associated with a specific resource, add it to the Tasks view. Since tasks are in essence a to-do list, they not only provide completed and not completed state information, but also three levels of priority to help manage your tasks.


Instructor Notes:



23

Lab 01: Creating a Project

In this lab, you will learn how to create a new project, a folder within the project, and two files within that folder.

After completing this lab, you will be able to:

Create and use resources

Manipulate the user interface

To begin the lab:

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.

Click Select a Cheat Sheet from the list.

Expand DEV396 Labs, then select 01 Create a Project.

Follow the directions indicated on the Cheat Sheet.

The instructor will walk through this lab together with the class in order to demonstrate cheat sheet navigation.Because students may not be familiar

with cheat sheets, it is recommended that you walk through this first lab with the students.

Try to demonstrate cheat sheet navigation and answer any questions about cheat sheets during this lab, so that the subsequent labs run smoothly.


Instructor Notes:



24



Instructor Notes:



25

Running Multiple WindowsYou can run multiple windows in the same workspace.

Activity in one window will be reflected in the others.

You can open a new window with Window > New Window, or when you open a perspective by setting the perspective preferences under Window > Preferences > Workbench > Perspectives.

Filtering is specific to a window. This allows you to have multiple windows open on the same workspace, while each window can have different filters or working sets defined to show you visibility to different sets of resources.


Instructor Notes:



26

Using Multiple Workspaces You can open multiple windows in the same workspace. However, only one Eclipse instance can run on a workspace at any one time.

This may lead you to decide to partition your work among multiple workspaces to facilitate parallel team development.

As mentioned earlier, the Workspace Launcher dialog you see at startup allows you to select the workspace to use with this session. Either the default or the last workspace you used will be presented. You can also browse to another workspace location, or create a new one.

To select a previously used workspace, you can also select it from the drop-down list but, by default, Eclipse will only list the previous five workspaces.

Tip: To change the number of workspaces kept in the drop-down list, modify the MAX_RECENT_WORKSPACES=5 line in the <ECLIPSE_INSTALL_DIR>\configuration\.settings\org.eclipse.ui.ide.prefs file.

Tip: To bypass the Workspace Launcher, use the –data parameter followed by the workspace name. For example, eclipse -data myWorkspace.

Tip: Use the –showlocation parameter to display the workspace on the Eclipse title bar. For example, eclipse -showlocation -data myWorkspace.


Instructor Notes:



27

BuildersA builder is a program that runs when a resource changes within a specific project. That is, you define builders for a specific project and for that project only. Some specialized project types, such as a Java project, will have builders defined when they are created.

To define a builder for a project, first select the project in the Navigator view or Project Explorer. Right-click it and select Properties, and then select Builders. On the Builders page, select New, and on the next dialog, select Programand click OK.

The pages on defining a builder are similar to those used when defining an External Tool, with the exception of the Build Options page.


Instructor Notes:



28

HelpThere are extensive Help resources that include:

Help Contents

Tips and Tricks

Cheat Sheets

Dynamic Help

You can access the Help system by selecting Help from the menu bar.


Instructor Notes:



29

Cheat SheetsThe exercises included with this course will be performed in Cheat Sheets. Cheat sheets provide an interactive lab environment within the application we are exploring.

Cheat Sheets save the student time by:Having the lab steps in place beside the work being doneNot having to retype contentAllowing steps to be repeated Automating the loading of lab input artifacts

Cheat Sheets assists the student in learning by:Integrating with multimedia Allowing you to take the cheat sheets of interest and install them in your own instance of the product, for later reference and guidance

Cheat sheets are launched by selecting Help > Cheat Sheets from the menu bar. They show two panels that will either be side by side or one above the other, depending on the relative height and width of the view.

Using Cheat Sheets:To start working with a cheat sheet, select Click to Begin in that step. The next step is expanded and highlighted. You can now begin working through the tasks.

Selecting Click to Perform will launch a tool, and you will be required to work with that tool. When you finish, the next step is automatically highlighted and becomes the current step.

When the current step is a manual task, you will need to perform the work and click Click to Complete to move to the next step.

A check mark appears in the left margin of each completed step.


Instructor Notes:



30

Navigating Cheat Sheets

Cheat Sheets provide guidance through a complex problem by breaking that problem into a set of smaller tasks.

Each task consists of a series of steps that usually must be performed in order.

A set is a set of tasks that can be performed in any order

A sequence is a set of tasks that must be performed in order. A dimmed step is one that cannot be performed until the previous one is complete.

A choice represents a set of tasks, only one of which should be performed.

If a task is optional it can be skipped

Important Note: Students much check off each step in order to move on to the next one.

Some different kinds of tasks:

Each cheat sheet has a list of steps, and it always begins with an Introduction step. When you launch a fresh cheat sheet, the Introduction step is expanded so that you can read a brief description of the cheat sheet. Any time after starting a cheat sheet, you can restart from the first step by clicking Click to Restart in the Introduction step. If you have already created some artifacts, you will have to manually clean up the workspace before restarting the cheat sheet.You can redo any step that you may have completed or skipped in the current cheat sheet. To redo the step, expand the step by clicking its expand (+) icon and then clicking Click to Redo. After redoing a step, the cheat sheet will continue from the redo step.When you finish the last step in a cheat sheet, it automatically restarts. You can also close the active cheat sheet by clicking the close (X) icon in the cheat sheet's toolbar. The active cheat sheet saves its completion status when it is closed, so that you can continue where you left off at a later time.

To install cheat sheets in any Eclipse-based tool, copy the cheat sheet files into the <Eclipse_Install_Directory>/eclipse/plugins directory. Make sure to restart any running instances of the tool before attempting to open the cheat sheets.


Instructor Notes:



31

Lab 02: Customizing PerspectivesIn this lab, you will work with multiple instances. You will begin by customizing a perspective, and then make it the default perspective.

After completing this lab, you will be able to:Customize a perspective Open multiple windows and workspaces

To begin the lab:



Expand DEV396 Labs, then select 02 Customize Perspectives.



Instructor Notes:



32



Instructor Notes:



33

Rational Software Architect: For Architects and DevelopersFor software architects who need to:

Model applicationsEnforce architectural and coding standardsDevelop and apply patterns and transformations

For software developers who need to:Develop using models and codeReview code against coding standardsApply patterns and transformations

For all who develop as part of a team

Software architects and senior developers within a development team are responsible for specifying and maintaining all aspects of an application’s software architecture. They need powerful and configurable tools to manage the complexity found in today’s applications.Rational Software Architect is a UML model-driven design and development tool for creating well-architected applications and services.


Instructor Notes:



34

Model-Driven Development in Rational Software Architect

Create the domain model

Create the use-case model

Create the design model

Complete the implementation using UML visualization

Transformation

Transformation

Transformation

Traceability relationships created as a byproduct of patterns and transformations

Rational Software Architect is designed to support model-driven development, the development of the appropriate models to facilitate all development activities and stages in the lifecycle. It contains tools to transform models into more detailed or more abstract models to move development work forward.An analyst might begin by modeling the business domain in Rational Software Architect to define the key products, deliverables, and events. The analyst can then create a use-case model to define the actors, system boundaries, and use cases that the system will support.The architect then uses Rational Software Architect to create a platform-independent design model from the use-case model. This model or set of models can be transformed into platform-dependent implementation models (including code and UML) with the assistance of visual development tools, such as: • UML editors for Java, C++, or data • Site Designer• Page DesignersAs each new stage of development begins, transformations can be used to create more detailed models that are incrementally closer to the target platform and infrastructure. Transformations can be designed to include traceability so that you can query the target model using elements from the source model to find elements in the target model. This feature is currently built into the UML to Java transformation that comes with Rational Software Architect. After the transformation is complete, you can right-click a model element in the design model and perform a query to find the associated Java code.

The transformation “trail” is a traceability link between the transformation source and its target, which can be followed using a model query.


Instructor Notes:



35

ReviewThe IBM Rational Software Delivery Platform is a software development solution based on what platform?

Which view provides a hierarchical view of resources and allows you to open them for editing?

Rational Software Architect is designed to support what kind of development?

Q: The IBM Rational Software Delivery Platform is a software development solution based on what platform?

A: Eclipse

Q: Which view provides a hierarchical view of resources and allows you to open them for editing?

A: The Navigator View

Q: Software Architect is designed to support what kind of development?

A: Model-Driven Development


Instructor Notes:



36


Instructor Notes:

Module 2 - Model Structure and Templates 2 - 1© Copyright IBM Corp. 2007


®

IBM Software Group



Module 2: Model Structure and Templates

This module will require approximately 1 hour to complete. There are no labs in this module.


Instructor Notes:



2

After completing this module, you will be able to:Locate and use the Modeling perspective and viewsCreate and organize projects and models in Rational Software Architect Create Models based on Model templates

Module Objectives


Instructor Notes:



3

Where Are We?Introduction to ModelsModeling perspective and viewsCreating and organizing projects and models


Instructor Notes:



4

What is a Model?A model is a semantically closed abstraction of a subject system.

The RUP methodology defines a model as a complete description of a system from a particular perspective.

Examples of models:UML modelCodeData model

In the IBM® Rational® Unified Process (RUP®) methodology, a model is defined as a complete specification of a problem or solution domain from a particular perspective. Each model is complete in the sense that you do not need any additional information to understand the system from that perspective. A problem domain or a system may be specified by a number of models that represent different perspectives for different project stakeholders.


Instructor Notes:



5

Difference Between Model and DiagramA model can contain one or more diagrams.Different diagrams graphically depict views of different parts of your model.A model element that appears only once in your model can appear on one or more diagrams, to show it in different contexts.

Diagrams provide a means of visualizing and manipulating the model elements.


Instructor Notes:



6

A UML model is only one type of model, which is used for:Specifying structure, behavior, or bothVisualizing an existing system to improve understandingAutomating system development (Model-Driven Development)

UML Models in Rational Software Architect:

A resource (.emx)Logical model, the contents of a model file

What is a UML Model in Rational Software Architect?

Physical Model File

(Logical) Model

Closed model

Open model

Model files in a UML Modeling project as shown in the Navigator view.

In the RUP methodology, a model is defined as a complete specification of a problem or solution domain from a particular perspective. A UML (Unified Modeling Language) model is just one of many types of models used in software development. UML models help the development team visualize, specify, construct, and document the structure and behavior of system architecture. Using a standard modeling language such as the UML, different members of the development team can communicate their decisions unambiguously to one another.You can use UML models to represent a system that you want to build visually; to build a common understanding of a system; to develop, verify, and communicate a system’s architecture; and to generate code. UML model files in Rational Software Architect contain model elements (such as actors, use cases, and classes, and packages, relationships, and associations), and one or more diagrams.In addition to these objects, models contain UML profile information, user preferences, and workspace information.A modeling project can contain any number of models. You can open and manage each model in the Project Explorer view, and you can open diagrams from more than one model at the same time.

Note that the main file types used in Rational Software Architect are:File Type ExtensionUML Model .emxUML Model Fragment .efxUML Profile .epxClass Diagram .dnxTopic Diagram .tpxObject Constraint Language (OCL) resource .oclTransformation Configuration .tcReusable Asset .rasRAS Manifest .rmd

Design, analysis, and data models are all in separate model files.The Project Explorer view is new in v7, replacing the Model Explorer view. The Project Explorer view shows only the local contents of all the models in a project. You no longer formally have to open the model.


Instructor Notes:



7

Models at Different Levels of Abstraction

Platform-Independent

Model

Code-based Development

ITER

ATE

Application Design (high abstraction)

Implementation

Application Use-Cases

Application Analysis

ComputationalIndependent

Model

Platform-Specific Model

Business AnalysisBusiness Process Models

Business Use-Cases

Model-Driven Architecture RUP Methodology

Platform-specific model markup

It is important to mention here that there is not a set number of models needed to do MDD or MDA-style development. One organization might need all of these models, another might just need two. In MDA, CIM, PIM, and PSM are just descriptive categories for models and do not refer to specific model types (there are many kinds of platform-specific models). Avoid leaving the impression that you have to create all of these models to do MDD or follow MDA.Moreover, categories of models in MDA do not imply a specific level of abstraction. One person's PIM can be another person's CIM. Perspective is key to how the models are interpreted.


Instructor Notes:



8

Where Are We?Introduction to ModelsModeling Perspective and ViewsCreating and Organizing Projects and Models


Instructor Notes:



9

The Modeling PerspectiveThe Modeling Perspective contains the tools needed to build UML models and diagrams.

Editors

Views

The Rational Software Architect workbench window contains one or more perspectives. A perspective defines the initial set of content editors and related views (used to navigate information in the editor), and their layout in the workbench window.Perspectives gather together sets of features for specific development activities. For example, the Java perspective gathers tools for writing code: the Package Explorer, Problems view, Outline view, and Java editor. The Modeling Perspective contains the tools needed for building UML models and diagrams, including the diagram editor, with the following views: Project Explorer view, Pattern Explorer, Outline view, Inheritance Explorer, Properties view, Tasks view, Output window, and Bookmarks view.

Note: the diagram editor is covered in detail later.

The palette is part of the diagram editor and not a separate view.


Instructor Notes:



10

Views in the Modeling PerspectiveViews in the ModelingPerspective:

For exploring modeling projects:

Project Explorer view– Diagrams– Models

For exploring resources:Pattern Explorer viewOutline viewInheritance Explorer viewProperties view

For getting feedback:Tasks viewOutput window

Views are windows that provide different ways to navigate the information in the workspace and in the workbench. For example, the Project Explorer view displays projects and models you are working with. A diagram in the Project Explorer view can be opened into the diagram editor. The properties of the selected diagram can be modified in the Properties view.A view might appear by itself, or stacked with other views in a tabbed notebook. You can change the layout of a perspective by opening and closing views, and by docking them in different positions in the Workbench window.


Instructor Notes:



11

Project Explorer ViewUsed for navigating and organizing models.

Class

Attribute

Diagram

Relationship

Package

Diagram

Open Model

Closed Model

Under each model file, the Project Explorer view displays the logical structure of the model, including the name of the model and any packages, diagrams, relationships, and other model elements it contains. The model icon (light brown, containing a triangle) inside the model file allows you to add model elements at the root level of the model, and it allows you to set certain properties for the model.You can use the Project Explorer view to add, delete, move, organize, and sort model elements for each model in your project.

Use the screenshots to introduce the idea of model files (.emx).

Note that the Project Explorer shows the physical projects in the workspace and any model files they contain. It also shows the logical contents of the model file.

Note that packages in the Project Explorer do not correspond to physical packages in the project.


Instructor Notes:



12

Properties ViewDisplays properties and values for the selected element.

All models, diagrams, model elements, and relationships have associated properties, just like all other project resources.In the Modeling Perspective, properties are organized into a series of tabbed categories. Most model elements contain the following categories:

• General: Includes the name of the elements, qualified name, keywords forsearches, visibility, and an option to make the element abstract.

• Documentation: Used for adding documentation to model elements.• Advanced: Displays an Eclipse-style properties page.

Describe the other tabs in the Properties view (General, Documentation and Advanced are covered in the Student Notes).

Models and model elements, of course, are not unique in having associated properties. The properties view appears in many perspectives, though usually as just a list of items and not in categories as shown here.

Also note that though there are three default properties pages (General, Documentation, Advanced), other pages may appear with different model elements (the slide shows additional pages for the selected class).

The Advanced properties page shows all the property values in a two-column table, just as properties appeared in the Rational XDE Developer Properties view.


Instructor Notes:



13

Diagram EditorDrawing Surface

Tools

Palette

Drawers

The diagram editor contains both the drawing surface and the toolbox. The toolbox contains a basic set of tools (available by default) for selecting and annotating shapes in the diagram, along with one or more drawers of tools for various diagram types. You can customize the look and behavior of drawers in the toolbox, as well as create and customize your own drawers.

The diagram editor has two parts: the drawing surface and the toolbox (which contains a palette of drawers containing drawing tools).

Note that some tools have dropdown menus (class, association, and so on) that allow the user to select different specialized forms of the tool.


Instructor Notes:



14

Outline ViewWhen the diagram editor is open, the Outline view can show either:

A thumbnail graphical view of the diagramA tree view listing the elements of the diagram

The Outline view displays an outline of the structured file that is currently open in the editor area, and lists its structural elements.The contents of the Outline view are editor-specific. When the diagram editor is open, the Outline view can show either:

•A tree view listing the elements in the file open in the editor area (upper-right icon named Outline) •A thumbnail of the diagram (upper-right icon named Overview) with the screen area dimmed (in gray). In the screenshot, the Overview icon is selected, thus showing a graphical thumbnail of the diagram. You can move the active screen area in the outline view to navigate the diagram.


Instructor Notes:



15

UML Model Editor

The UML Model editor appears every time you open a model. To close your model, close the UML Model editor. From the UML Model editor, you can add documentation to the model and navigate to specific diagrams in the model. It also provides the following model information:Overview

• Alerts and Action Items: Lists problems associated with this model• General Information: Provides general model file properties, including

name, location in the workspace, size of the file, modify date, and read or write status

• Documentation: Allows you to add documentation at the model level, just the way you would document an element in a model

Details• Applied Profiles: Shows which UML profiles are currently applied to the

model. Applying profiles makes available sets of stereotypes that extend the UML to create specialized models.

• Diagrams: Lists diagrams in this model• Model Libraries: Model libraries imported by this model

References• Referenced Models: Shows the models that the open model references. A

referenced model contains model information from a referenced component or project.

Fragments: Lists fragments of this model

The UML Model Editor opens when the model opens. Remind students that if they close the Model Editor, the model closes.

The UML Model Editor appears in the editor area of the screen, though mostly it is used for reference and navigation. The only thing you can modify in this editor is the Documentation field.


Instructor Notes:



16

Rational Unified Process ResourcesProcess guidance is built in the:

Rational Software Architect Process Advisor featureRational Software Architect Process Browser feature

These resources can guide you in determining what models and diagrams you need.

The RUP platform is a software engineering process and an industry-wide platform for best practices. There is a configuration of the RUP methodology designed especially for Rational Software Architect users, one which is accessible in two features in Rational Software Architect: Process Advisor: The Process Advisor is a view that presents context-sensitive references to RUP Tool Mentors, Artifacts, and Activities. From this view you can also search the RUP product and access Help.Process Browser: The RUP Process Browser in Rational Software Architect is a separate window that opens to display the RUP content selected in the Process Advisor view. It also allows you to browse the RUP product.

In the screenshot, a class is selected in the diagram editor. The Process Advisor shows a list of RUP tool mentors, as well as artifacts and activities that are offscreen. When the user clicks on a topic, it will open the RUP process browser, which is not pictured.

Provide a demo if students are interested in seeing the Process Advisor and Process Browser views in action.


Instructor Notes:



17

Where Are We?Introduction to ModelsModeling Perspective and ViewsCreating and Organizing Projects and Models


Instructor Notes:



18

Rational Software Architect Project Types

There are two basic types of projects.

UML projects:For pre-implementation modelsBlank or based on a model template

Implementation projects:Java, EJB™ (Enterprise JavaBeans™) technology , and so onImplementation projects can contain UML class and sequence diagrams

Simple projects can be of either type. New Project wizard

Java Project

Simple Project

UML Project

A project in Rational Software Architect is just a container for resources, such as model files, code files, HTML or XML files, and so on.In Rational Software Architect, you will develop two types of projects: UML projects for pre-implementation models, and implementation projects, in which the code is the implementation model. Implementation projects can contain free-standing UML class and sequence diagrams,which you can use to visualize the code’s structure and runtime behavior.A Simple project is an empty project folder, which you can populate withany file structures and resources.A UML project is a Simple project that contains a model file. You can either create blank models or ones based on a Rational Software Architect UML model template.The following implementation projects are available in Rational Software Architect:Enterprise: An enterprise application project contains the hierarchy of resources required to deploy a J2EE enterprise application, often referred to as an EAR file.EJB: EJB (Enterprise JavaBeans™) projects include the resources contained in an EJB module.Web: Web projects are used for creating dynamic Web applications andstatic Web sites. Dynamic Web projects provide an accompanying EAR project.Connector: A connector is a J2EE standard extension mechanism for containers that provides connectivity to enterprise information systems (EISs).

“Pre-implementation models” means, for example, use-case, analysis, and design models, any model to be used as a high level model to be implemented with code.There are no “code models” in Software architect for roundtrip engineering, as there were in Rational XDE Developer. In Software Architect, code (as part of the implementation model) can be visualized using UML class and sequence diagrams.


Instructor Notes:



19

Model Templates in Rational Software ArchitectUML Project templates are available in the New Project wizard. The following model templates are available:

Analysis ModelBlank ModelCORBA Template ModelDoDAF ModelEnterprise IT Design ModelService Design ModelUse Case ModelXSD Model

In Rational Software Architect, model files are used to create pre-Implementation models. They contain conceptual UML content that does not directly reflect implementation artifacts. They present just enough detail so that you can easily understand them. Model files contain both the UML semantics of the model and UML diagrams that depict the semantic elements.When creating a UML Modeling project, a page in the New Project wizard offers either a UML model template or a blank model for the new project. Once the project has been created, you can add additional model resources, or delete the original model resource if necessary.Some of the templates available are:Analysis Model: creates a new Analysis Model following IBM® Rational® Software Modeler and Rational Software Architect Model Structure Guidelines. Contributes the Software Engineering Process profile, and some default content, such as packages and diagrams. Blank Model: creates a blank UML model that includes no default content other than a Main freeform diagram with no profiles applied. The blank model template allows you to create your own model types and structures. CORBA Template Model: contains a basic CORBA (Common Object Request Broker Architecture) infrastructure and tips on how to use UML to model CORBA IDL (Interface Definition Language).DoDAF Model: creates a model based on the Department of Defense Architecture Framework.Enterprise IT Design Model: creates a new Enterprise IT Design Model following Rational Software Modeler and Rational Software Architect Model Structure Guidelines. Contributes default content, including a profile that supports modeling services and transforming designs into code. Use this template for design (and optionally for analysis) when targeting business applications. To create a design model for a simpler application, start with a blank model instead and add the appropriate package structure.Service Design Model: creates a new Service Design Model following Rational Software Modeler and Rational Software Architect Model Structure Guidelines.Use Case Model: creates a new Use Case Model following Rational Software Modeler and Rational Software Architect Model Structure Guidelines. Includes a blank model with default content (use cases, package structure, and diagrams) for building a use-case model.XSD (XML Schema Definition) Model: creates a UML model of an XML schema.

Model types are mostly self-explanatory. Students need to know that Rational Software Architect provides templates with default content and UML profiles applied.

If the question arises, it is possible to create your own model templates in RSA v7.0.


Instructor Notes:



20

UML ProfilesUML profiles are often included with module templatesProfiles provide a mechanism for extending the UML without having to change the modeling language itself.Profiles include:

Stereotypes: A simple textual marker («…») or icon placed on a model element to add semantics to the elementTagged values: To add properties that are not supported by the base elementConstraints: Constraints enforced on the element or its attributes

A UML profile identifies a particular subset of model elements and defines stereotypes and constraints that can be applied to it. The stereotypes that are contained in a profile can be used when a profile is applied to a UML model.

• Stereotype: A simple textual marker («…») or icon placed on a model elementto add semantics to the element. A stereotype extends UML, but not its structure. You can add stereotypes to model elements to create specialized forms, but you cannot add new elements to UML.

• Tagged Values: Typically a string or Boolean value, tag definitions can be associated with specific stereotypes or with all model elements of a specific type (class, association, operation parameter, and so on). Tagged values used to add values to model elements, similar to metadata, and used very often to add information for transformations and code generation.

• Constraint: A set of rules that can be executed to determine a model or modeling element’s correctness. Constraints are usually defined using the Object Constraint Language (OCL), but can also be defined in natural languages and Java.

In the Rational Software Architect tool, the UML 2.0 Base, Intermediate, and Complete profiles are automatically applied to every UML model. The tool also provides the Deployment profile and the Default profile, both of which are also automatically applied to every UML model.Two key best practices for working with profiles in multiple models are:

• Keep platform-independent content and platform-specific content separate, in different logical (top-level) models.

• Maintain cross-model relationships in the platform-specific models.

Spend some time explaining the value of using profiles. Some reasons to cover include:

• UML is meant to be a general purpose language. If you have unique information that must be captured, then a profile provides a way to extend UML to capture that information.

• As a way to add additional information to a model that will be used as the source for a transformation.


Instructor Notes:



21

How Are Profiles Used?Profiles are used to model platform-or model-specific abstractions, for example:

Enterprise beansAnalysis classes

Profiles provide a domain-specific language for reusable assets:

Add to model templatesUse with domain-specific patternsUse a transformation to create a platform-specificmodel

Custom profiles can be created in Rational Software Architect and shared with other users

Profile

Model Template

Patterns

Designed to recognize andtransform elements with stereotypesfrom the profile.

May include parameters with stereotypesfrom the profile. Patterns can be used to add stereotypes to model elements.

Profile added to the template and modelscreated from it. Elements in the model can have stereotypes from the profile, with constraints ensuringcorrect usage.

Transformations

Rational Software Architect allows you to develop and apply UML profiles that you can use to create model elements that reflect the semantics of a specific domain or platform, or for a particular model. For example, the RUP Analysis model template is supported by the Analysis profile, which provides «Boundary», «Entity», and «Control» stereotypes.Profiles are not just used for modeling, however. They are also used for automating modeling and model transformation using patterns. Design patterns in Rational Software Architect can be used to apply stereotypes to model elements, which are then recognized by transformations run on them so that they can be realized by technology- or platform-specific implementation code.

Note: If your customer is using Rational Software Architect and Rational Software Modeler together and sharing artifacts, note that models created with custom profiles in Rational Software Architect can always be opened safely in Rational Software Modeler, but a warning will appear. Consider model publication as an alternative to the sharing of artifacts between the two tools in cases where sharing is not essential.


Instructor Notes:



22

Populate a Model With Reusable Building BlocksCreate a UML project and select a template. Then populate the model with:

UML packages UML elements based on model building blocks provided

Templates can be customized. You can also create your own templates.

Example Building Block package

Example Building Block element

Every template contains a «modelLibrary» package called TemplateNameBuilding Blocks. This package contains chunks of model content that you can use to build the design model more quickly. Building blocks act as template model elements. You can copy (CTRL+C) and paste (CTRL+V) the building block elements to create new elements for your model. To use a building block element:

1. In the Project Explorer, copy a building block element from the building blocks package and paste it in the desired location in the model.

2. Right-click the new element and choose Find/Replace to change the placeholder name {$name} to the desired name.

A best practice for naming diagrams is to come up with a descriptive name and then add the diagram type. For example, the use-case diagram above is called “PO Management Use Cases.” You might also call it “PO Management Use-Case Diagram.”


Instructor Notes:



23

Model Templates: Use-Case ModelA use-case model is a model of the system’s intended functions, and of its environment.

Use CaseUnit of externally visible functionality

Versatile ActorsActors that participate in multiple functional areas of the application

ActivityFor gathering activity diagrams for the use case (optional)

PerspectiveHas overview diagrams and a package with actors

The use-case model is a model of the system's intended functions and itsenvironment. The use-case model template in Rational Software Architect contributes the default content shown in the slide. The model is divided by packages into the functional areas within the application. Each functional area package contains actors and use cases. Each use case can optionally contain interactions that link directly to use-case specifications, and contain activity diagrams showing each flow of events graphically. The use-case model is used as an essential input to activities in analysis, design, and test.The model includes a «perspective» package containing overview diagrams of all the functional areas in the model, and a package containing versatile actors, which are actors that appear in multiple functional areas in the application. To create your use-case model using the building blocks you will perform these activities iteratively:

• Create functional area packages using the package building block provided.• Populate each package with the use cases for that functional grouping using the

use-case building block provided.You can then perform the other activities of use-case modeling, such as gathering use cases into use-case diagrams, adding actors, drawing extend or include relationships among the use cases, drawing associations from the use cases to the actors that participate in them, writing descriptions for the use cases and actors, and (where it adds value) composing the high-level activity and "black box" sequence diagrams for each use case.For information on the use-case model, see the Rational Unified Process: Artifacts > Requirements Artifact Set > Use-Case Model.

Note that these templates are developed for modeling very large systems. You can think of a model template as a superset of what you would need to create a model of this type. Templates can be customized and saved as new templates.


Instructor Notes:



24

Model Templates: Analysis ModelAn analysis model describes the realization of use cases to analysis classes.

Provides an abstraction of the design model

Boundary Class

Controller Class

Use-Case Realization

Entity Class

The analysis model is an object model that describes the realization of use cases (shows the collaborating objects derived from flows of events modeled in the use-case model). It contains the results of use-case analysis. It serves as an abstraction of the design model.In Rational Software Architect, the Analysis model template contributes the default content shown in the slide. An Analysis profile is applied to model files created from this template.The analysis model includes packages for the same functional areas defined in the use-case model, containing analysis classes and diagrams, derived from use-case realizations.The process of use-case realization is beyond the scope of this course, though it is described in the RUP methodology (located in Designer role > Use-Case Design > Guidelines > Use-Case Realization). For a review of the analysis model and analysis classes, see Artifacts > Analysis & Design Artifact Set > Analysis Model.Boundary Class: Mediates between the system and something outside the systemController Class: Provides the coordinating behavior in the systemEntity Class: Reused in many use cases, often with persistent characteristicsUse-Case Realization: Shows how a use case is implemented in terms of collaborating objects


Instructor Notes:



25

Model Structure: Enterprise IT Design ModelA design model describes the realization of use cases to design classes.

Provides an abstraction of the implementation of the system

Architectural Layers

Use-Case Realization

Viewpoints

The design model is an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code. The design model is used as essential input to activities in implementation and test.The Enterprise IT Design Model (EITDM) template contributes default content, including a profile that supports modeling of services and transformations of design model elements into code. This is the appropriate model type to use for design (and optionally for analysis) when targeting business applications and using code-generating transformations to support creation of such applications.To create your design model using the building blocks, you perform these activities iteratively:

• Create functional area element and functional area realization packages.• Populate the realization packages with specification elements as you specify the

behaviors (typically interactions) that express the design-level realizations of your use cases. The realization packages define the usage contracts for your components and services.

• Populate the element packages with implementation elements that realize the specification elements in the realization packages.

For more information on the design model, see the RUP platform, Artifacts > Analysis & Design Artifact Set > Design Model.Architectural Layers separate business logic from data and the user interface.Use-Case Realization shows how a use case is implemented in terms of collaborating objects.Viewpoints contain diagrams presenting architecturally-significant cross-cutting views of the model.

Use-case realizations are covered in more detail later.


Instructor Notes:



26

Model Template: Service Design Model

serviceProviderserviceConsumer

ServiceMessage

serviceSpecification

A Service Design Model is used to conceive and document the design of the software services.

•ServiceConsumer: Any consumer of a service.•ServiceProvider: The provider of one or more services.•ServiceSpecification: The specification of operations and associated messages defining a service.•Service Model: A model of the core elements of a service-oriented architecture. The service model is used as essential input to activities in implementation and test.•ServiceCollaboration: The behavior of a set of cooperating services.•ServicePartition: The logical or physical grouping of one or more services.

Perspectives:•Message: A container for actual data that has meaning to the service and the consumer.•Service: Provides the end-point for service interaction, whereas the definitions of these interactions is a part of the service specification.


Instructor Notes:



27

Demonstration: Model Structure and Building BlocksThe instructor will now show you how to:

1. Switch to the modeling perspective.2. Create a UML Project.3. Add a Model to the Project (using a template). 4. Use Building Blocks to structure a model.

Depending on your instructor, you may follow the same steps on your computer.

Watch your instructor create a model with building blocks.


Instructor Notes:



28

Review1. What model templates are available with

Rational Software Architect?2. How do you use a building block to minimize

repetitive work?3. What is the difference between a model and

a diagram?

1. Model templates include: •Analysis Model, •Blank Model, •CORBA Template Model, •DoDAF Model, •Enterprise IT Design Model, •Service Design Model, •Use Case Model, •XSD Model

2. Building blocks act as “template” model elements. You can copy and paste the building block elements to create new elements for your model. To use a building block element:

-In the tool, copy and paste a building block element from the building blocks package to the desired location in the model.

-Right-click the new element and choose Find/Replace to change the placeholder name {$name} to the desired name.

3. A model can contain one or more diagrams. Different diagrams graphically depict views of different parts of your model. A model element that appears only once in your model can appear on one or more diagrams to show it in different contexts.


Instructor Notes:



29

Further InformationWeb resourcesArticles

Web resources:developerWorks Rational Software Architect page<http://www-128.ibm.com/developerworks/rational/ products/rsa/>

Articles:Smith, Bill, “Model Structure Guidelines for Rational Software Modeler and

Rational Software Architect”. IBM developerWorks, 2006. <http://www-128.ibm.com/developerworks/rational/ library/04/r-3155/>


Instructor Notes:



30


Instructor Notes:

Module 3 - Creating UML Diagrams 3 - 1© Copyright IBM Corp. 2007


®

IBM Software Group



Module 3: Creating UML Diagrams

This module will require approximately 2 hours to complete:

• Lecture: 50 minutes.• Lab 3: 30 minutes• Lab 4: 30 minutes


Instructor Notes:



2

After completing this module, you will be able to:Create UML Diagrams

Diagrams in UML modelsQuery diagramsVisual development diagrams

Describe how UML elements can be added to diagrams using:

Action BarsTool paletteProject Explorer view

Module Objectives

This module introduces three types of UML diagrams in Rational Software Architect: diagrams in UML models, query diagrams, and visual development diagrams.The module also shows three methods for populating UML diagrams in Rational Software Architect: using the tool palette, action bars, and the Project Explorer view.This module will identify how UML diagrams can be created using Rational Software Architect, but it does not provide in-depth explanations of UML or OOAD (object-oriented analysis and design) concepts and notation.

This course does not provide in-depth explanations of UML or OOAD concepts and notation and it is expected that students already have this background. This course will cover how the diagrams can be created using Rational Software Architect.


Instructor Notes:



3

Where Are We?UML DiagramsCreating UML Model DiagramsUML Visual DevelopmentQuery Diagrams

This section explains how UML diagrams are used in modeling and describes the range of UML diagrams available in Rational Software Architect.


Instructor Notes:



4

UML Diagrams in Rational Software ArchitectA model element appears in zero or more diagrams

Diagrams graphically depict a view of a part of your model or codeDifferent diagrams represent different views of the system that you are developing

In Rational Software Architect, you can open and add diagrams to the model in the Project Explorer view.A UML project has two main packages that show different views of diagrams in the model. The Models package shows diagrams in their logical place within the model, the Diagrams package shows only the diagrams in the model, spelling out the paths of their locations.UML diagrams can help system architects and developers understand, collaborate on, and develop an application. High-level architects and managers can use UML diagrams to visualize an entire system or project, and separate applications into smaller components for development.System developers can use UML diagrams to specify, visualize, and document applications, which can increase efficiency and improve their application design. UML diagrams can also help identify patterns of behavior, which can provide opportunities for reuse and streamlined applications.The visual representation of a system that UML diagrams provide can offer both low-level and high-level insight into the concept and design of an application.

Be sure to mention that in Rational Software Architect V7, you can open diagrams either from the Modelspackage or the Diagrams package (which is not shown on the slide, to save space) in the new Project Explorer view. The Diagrams package in the Project Explorer view replaces the Diagram Navigator view that was in V6.


Instructor Notes:



5

UML Diagrams in Rational Software Architect

Behavioral Diagrams

Structural Diagrams

ActivityDiagrams

SequenceDiagrams

CommunicationDiagrams

State MachineDiagrams

ComponentDiagrams

CompositeStructureDiagrams

ClassDiagrams

Model

ObjectDiagrams

DeploymentDiagrams

Use-CaseDiagrams

Visual models of a system require many different diagrams to represent different views of the system for different project stakeholders. The UML provides a rich notation for visualizing models.Structural DiagramsRational Software Architect allows you to create the following structural diagrams:

• Class diagrams to illustrate logical structure• Object Diagram to show objects that are instances of classes• Composite Structure diagrams to show the internal structure of a class or

component at runtime• Component diagrams to illustrate the organization and dependencies among

modular parts of the system• Deployment diagrams to show the mapping of software to hardware

configurationsBehavioral DiagramsRational Software Architect allows you to create the following behavioral diagrams:

• Use-Case diagrams to illustrate user interactions with the system• Activity diagrams to illustrate flows of events• State Machine diagrams to illustrate the series of states an object can have• Communication diagrams to illustrate behavior in terms of how objects

interact• Sequence diagrams to illustrate behavior in terms of the sequence of

interactions between objects

Someone may ask whether the use-case diagram is a structural rather than a behavioral diagram. They are listed and described in the OMG’s UML spec as behavioral diagrams. Use cases are units of behavior.


Instructor Notes:



6

How Many Diagrams Need To Be Created?The number of diagrams you need depends on the artifacts being modeled and the needs of users of the model.

You use diagrams to visualize the system from different perspectivesNo complex system can be understood in its entirety from one perspective

Model elements can appear in one or more diagrams.

A class can appear in one or more class diagrams, be represented in a state machine diagram, and have instances that appear on a sequence diagramEach diagram provides a different perspective

Good diagrams make the system you are developing understandable and approachable to the intended viewer. Choosing the right set of diagrams while modeling your system forces you to ask the right questions about your system, and helps to maintain an evolving, overall understanding of the problem or solution.Diagrams are necessarily selective in what they illustrate. The main benefit of modeling is abstraction, providing a simple, visual representation of the key details of a software-intensive system. This purpose is easily defeated when the wrongdiagrams are presented, or when disorganized diagrams are crowded with details.


Instructor Notes:



7


This section describes how to create and populate diagrams in Rational Software Architect.


Instructor Notes:



8

Creating UML Model DiagramsUse diagrams to represent different views of the system or application:

UML diagramsNon-UML (freeform) diagrams

Create diagrams in:

ModelsModel elements

PackagesComponentsActiveclassesAnd so on

Creating a diagram in the Project Explorer view.

You can add UML diagrams to models to represent different views of a system. To provide more detail about a specific model element, you can also add one or more diagrams to an element, such as a package, component, or state machine.For more informal and informational modeling, Freeform diagrams are available. Freeform diagrams allow you to add any element, including the non-UML geometric shapes available in Rational Software Architect.


Instructor Notes:



9

Review: Diagram EditorDrawing Surface

Tools

Palette

Drawers

The diagram editor contains both the drawing surface and the toolbox. The toolbox contains a basic set of tools (available by default) for selecting and annotating shapes in the diagram, along with one or more drawers of tools for various diagram types. You can customize the look and behavior of drawers in the toolbox, as well as create and customize your own drawers.

The diagram editor has two parts: the drawing surface and the toolbox (which contains a palette of drawers containing drawing tools).Note that some tools have dropdown menus (class, association, and so on) that allow the user to select different specialized forms of the tool.


Instructor Notes:



10

Adding Model Elements to a Diagram1

Drag an existing element from the Project Explorer view.

+

2Click a tool in the diagram editor’s tool palette and then click inside the diagram.

Hover or click the mouse in the diagram to make the action bar appear. Select the element to insert. Hover over the new model element to use the action bar to add details (attributes and operations).

3

To display elements in the Project Explorer view on an open diagram, just drag them on to the diagram surface. To add new model elements (shapes) using the diagram, you can either click an item in the tool palette and click in the diagram, or click the diagram surface and using the action bar to add items and compartment items.Although it is not shown in the slide, you can also add shapes to the model by right-clicking the diagram surface and then clicking Add UML and selecting the appropriate shape.

Note that the action bar is context sensitive. Hover over the drawing surface, and you get options for creating model elements for the selected diagram; hover over a model element, and you get a list of possible connectors with that element.


Instructor Notes:



11

Deleting from the Diagram and the ModelDelete from Diagram

Remove the item from the diagram, but do not delete it from the model

Delete from ModelRemove the item from the diagram and the model

Deleting an Element in the Diagram Editor

You can delete UML model elements from models in the Project Explorer view, and diagrams in the diagram editor. Just right-click the item and click the appropriate delete option:

• Deleting elements from a diagram (using the context menu or Delete key) removes the elements from the diagram, but leaves them in the model.

• Deleting diagram elements from a model (using the context menu) removes the element from the diagram and model.

Note that deleting a model element can be undone (with Edit > Undo or by pressing CTRL-Z), but deleting a diagram from a model is permanent.


Instructor Notes:



12

Diagram Validation: Validating Model SemanticsExamine a model or diagram for broken semantic rules according to the model's language and constraints:

Confirm adherence to UML requirements, logic, structures, and usageClick Run Validation on the Modeling menu to validate all open models

At any time during the construction of a model or a UML diagram, you can check that it is compliant with the defined constraints and ensure that no broken cross-model references exist.You must have a model open in the Modeling perspective, and you must enable at least one constraint category in the Validation preferences.In Validation preferences, you can apply constraints defined by the UML 2.0 specification, , as well as the UML 2.0 metamodel constraints that support the usability of specific modeling functions. To validate a model, diagram, or model element, right-click the item and then click Run Validation. Any violations are listed in the Problems view.After you validate a model or UML diagram, you can view the validation errors and warnings.


Instructor Notes:



13

Demonstration: Create a UML DiagramThe instructor will now show you how to:

Create a new diagramAdd shapes using the Project Explorer viewAdd shapes and connectors using the:

Action barTool palette

Delete from the diagram and the modelValidate the model

The instructor will show you how to create a UML diagram.

Use the instructions for Lab 3 as a guide for performing this demo.


Instructor Notes:



14

Lab 03: Create UML DiagramsComplete the following tasks:

Task 1: Create a new diagramTask 2: Add shapes and connectorsTask 3: Delete from the diagram and the modelTask 4: Validate the model

To begin the lab:

In Eclipse, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 3: Create UML Diagrams.Follow the directions indicated on the Cheat Sheet.

Complete Lab 3: Create UML Diagrams in Rational Software Architect.


Instructor Notes:



15


This section describes how to populate diagrams in Rational Software Architect.


Instructor Notes:



16

UML Visual DevelopmentVisualize Java and C++ code in UML diagramsVisualize code with diagrams that are either:

Project resourcesClass (.dnx)Sequence (.tpx)

New diagrams in an existing model (.emx)

ClassSequenceFreeformTopic

You can use UML diagrams to visually represent and develop artifacts of Java and C++ applications in a single, tightly integrated development environmentYou can use UML diagrams to represent and analyze an existing system to identify the system’s components and interrelationships, and to create representations of the system in another form. You can use UML diagrams to automatically abstract the system’s structural information from code to a new form at a higher abstraction level. You can redesign the system for better maintainability, or to produce a copy of a system without access to the design from which it was originally developed. You can also modify the target system, or develop and generate new systems. A UML class diagram depicts some or all of the components (or elements) in an application. You can use class diagrams to visually represent and develop the structures and relationships for Java classes and interfaces. You can create your own context to understand, collaborate, and develop an application by using a subset of its classes. You can also develop Java elements directly from class diagrams.You can use UML sequence diagrams to visually represent and develop the behaviors and interactions of Java applications, or to visually represent Java methods. You can use temporary, non-editable browse diagrams to create quick static views and explore existing relationships in applications, and use non-editable topic diagrams to create dynamic views of applications based on context and queries.You can also generate Javadoc HTML documentation with UML diagram images to provide more information about the source code.


Instructor Notes:



17

Class DiagramsAdd class diagrams to a Java or C/C++ project to visualize and edit classes.

Code changes automatically update the diagram, and vice versa, when resources are saved.Harvest visualized elements into a model.

You can create new class diagrams and populate them with Java classes to examine structures and relationships within an application.A class diagram depicts some or all of the classes and interfaces in an application. You can create your own context to visually represent an application by using a subset of its classes and interfaces. You can use class diagrams to develop Java packages, classes, and interfaces and to design their structures and relationships.


Instructor Notes:



18

Sequence DiagramsUse sequence diagrams to understand and develop behaviors and interactions among source elements.

Visualize behavior or add and edit lifelines, messages, and combined fragments

You can use sequence diagrams to create a graphical representation of the source elements in a system or application, in order to understand and develop behaviors and interactions between classes and data types. Create new sequence diagrams, populate existing sequence diagrams with source elements, and add lifelines, messages, and combined fragments to sequence diagrams.Static UML sequence diagrams can show disruptable interaction operators. A disruptable interaction operator indicates that the interaction fragment represents an exception handling block in the source code (that is, a Java try or catch block). The code in the first operand of this fragment represents the attempted code (the try block). Subsequent operands represent any exception handling blocks. Optionally, if present in the source, the final operand that is guarded by the condition finally represents code that is executed regardless of whether or not an exception has occurred. A static UML sequence diagram view is a topic diagram, which has a .tpx file name extension. You can refresh static sequence diagram views of Java methods to reflect the latest changes in the source code. You can convert them to editable UML sequence diagrams (which have a .dnx file name extension) that you can use to understand and develop behaviors and interactions between Java classes and interfaces.To create a static sequence diagram of a Java method, in the Package Explorer view, right-click a Java method, then click Visualize > Add to New Diagram File > Static Method Sequence Diagram. Note: You can also create static sequence diagram views of Java methods from class, topic, or browse diagrams: right-click a method in a Java class or interface, then click Navigate > Open as Interaction.


Instructor Notes:



19


This section introduces topic and browse diagrams in Rational Software Architect, which are used to explore relationships between model or code elements.


Instructor Notes:



20

Query Diagrams: Topic and BrowseUse topic and browse diagrams to explore relationships in UML models or in code.

With Topic diagrams, you can:Query the model to see a specific set of relationships between agroup of elements from across the model or codeCapture a snapshot of the current state of a model or codeCreate an edit diagram based on the topic diagram

With Browse diagrams, you can:Explore relationships from a selected element to other elementsNavigate the model or codeGenerate an edit diagram from a browse diagram

Information in your model that might not be worth formally displaying in diagrams might still have to be managed as part of the model. Such information is better accessed using query (topic and browse) diagrams, so that the information can be found just when needed. For example, rather than maintaining diagrams depicting traceability relationships, set up the relationships in the model and then use querying to find the relationships when needed. This approach can help avoid cluttering models.Topic and browse diagrams, both of which are not editable and so are not used for modeling, can also be used to analyze and familiarize yourself with an unfamiliar model as part of research. Topic diagrams can be saved or converted into UML class diagrams in the model. Browse diagrams are designed to provide a quick and convenient means of exploring the model, so they are never saved.

Topic and Browse diagrams are included in this lesson as they are not so much a new type of diagram as a new way of creating a diagram. Rather than drawing a diagram with this information using the palette or an action bar, the user defines the parameters to create the diagram.


Instructor Notes:



21

Using Topic DiagramsCreate Topic diagrams to depict key model elements and their relationships.Topic diagrams are:

Created by querying the model or codePersisted in the modelDynamically updatedMost useful for visualizing codeUsed in architectural discovery

A topic diagram displays a specific set of relationships between a group of given elements. The set of relationships (the topic) defines the parameters of the query for the diagram.Topic diagrams are used for both discovery and as visual documentation, since they can be saved in the model. Developing a topic diagram involves running a query against the existing model contents. You select a key model element and then define what other elements you wish to appear in the diagram, based upon the types of relationships they have to the topical element. As the content of the model changes, topic diagrams adjust accordingly. Rational Software Architect can generate and arrange topic diagrams for you automatically. These diagrams are useful when working in large models that contain many elements with complicated relationships. They are also invaluable when trying to help discover the architecture of an application.


Instructor Notes:



22

Browse DiagramsBrowse diagrams can be used to:

Show the elements related to the selected elementShow the dependencies to the selected elementGain a detailed understanding of the element in focus

Browse diagrams are driven by parameters and filters that you control.

Select relationships to display and levels of relationships, and then click Apply.

Right-click the diagram surface and click File > Save As to save the diagram as an edit diagram or image file.

Double-click an element in the diagram to make it the focus of a new browse diagram.

A browse diagram is a temporary diagram in which you can explore the details of a model and its underlying elements and relationships. A browse diagram provides a view of a context element that you specify, and is similar in functionality to a Web browser. You cannot add or modify the individual diagram elements or save a browse diagram in a model. However , you can convert a browse diagram to a freeform modeling diagram in an open model file, or save it in an image file that captures the inheritance hierarchy (which you can send in an e-mail message or publish on a Web site). To create a browse diagram:

1. In the Project Explorer, right-click a UML or Java element.2. Select Visualize > Explore in Browse diagram.


Instructor Notes:



23

Lab 04: Create Browse and Topic DiagramsComplete the following tasks:

Task 1: Import Java projectTask 2: Visualize Java code in a Browse Diagram viewTask 3: Visualize Java code in a Topic Diagram view

To begin the lab:

In Eclipse, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 4: Create Browse and Topic Diagrams.Follow the directions indicated on the Cheat Sheet.

Complete Lab 4: Browse and Topic Diagrams in Rational Software Architect.


Instructor Notes:



24

ReviewWhat is the difference between a topic diagram and browse diagram in Rational Software Architect?What is the difference betweena topic diagram and a classdiagram (project resource)?

Q: What is the difference between a topic and browse diagram in Rational Software Architect?

A: Both are query diagrams and both can be converted to an edit diagram, but a browse diagram is meant for exploration only and does not exist as part of a model or as a project resource. A topic diagram exists as a project resource.

Q: What is the difference betweena topic diagram and a classdiagram (project resource)?

A: Both diagrams provide a UML visualization of the classes in the model or the code, but topic diagrams are based on a query. You can modify a class using a class diagram. A topic diagram can be used to query both code and models.


Instructor Notes:

Module 4 - Creating UML Diagrams of System Structure 4 - 1© Copyright IBM Corp. 2007


®

IBM Software Group



Module 4: Creating UML Diagrams of System Structure

This module will require approximately 1 hour, 45 minutes to complete:

• Lecture: 45 minutes• Labs: 1 hour


Instructor Notes:



2


Identify the Structural UML diagrams that are available

Identify UML notation, and provide a basic explanation of UML semantics

Create Class, Composite Structure, Component, and Deployment diagrams

This module will identify how structural UML diagrams can be created using Rational Software Architect, but does not provide in-depth explanations of UML or OOAD concepts and notation.



Instructor Notes:



3

Structural UML Diagrams

Behavioral Diagrams

Structural Diagrams

ActivityDiagrams

SequenceDiagrams



ComponentDiagrams


ClassDiagrams

Model

ObjectDiagrams

DeploymentDiagrams

Use-CaseDiagrams

Rational Software Architect allows you to create the following structural diagrams:•Class diagrams to illustrate logical structure•Object Diagram to show objects that are instances of classes•Composite Structure diagrams to show the internal structure of a class or component at runtime•Component diagrams to illustrate the organization and dependencies among modular parts of the system•Deployment diagrams to show the mapping of software to hardware configurations


Instructor Notes:



4

Discussion

Which structural UML diagrams do you have experience modeling?

Take a moment to go around the room and find out what kind of experience the students may already have modeling structural UML diagrams.

Based on this discussion, you may tailor this module to emphasize the diagram types that are least familiar to the students.


Instructor Notes:



5

Where Are We?

Class Diagrams

Object Diagrams

Composite Structure Diagrams

Component Diagrams

Deployment Diagrams


Instructor Notes:



6

Class DiagramsClass diagrams show the classes of the system, their interrelationships, and the operations and attributes of the classes.

Class diagrams are used for a wide variety of purposes, including both conceptual (domain) modeling and detailed design modeling.

A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.

A class is an abstraction in that it:

•Emphasizes relevant characteristics.•Suppresses other characteristics


Instructor Notes:



7

Class Icon

Template Class ParameterClass Name

The class Icon provides compartments for name, attributes, and operations. These compartments can be removed from a diagram if desired.A number of standard stereotyped classes are available in Rational Software Architect:•Type: A class that specifies a domain of objects•ImplementationClass: The implementation of a class in a programming language•Utility: A class that has no instances, but rather a collection of non-member attributes and operations that are class scoped•Metaclass: A class whose instances are also classes•Realization: A classifier that specifies a domain of objects, and its physical implementation•Specification: A classifier that specifies a domain of objects, without defining a physical implementation•Focus: A class that specifies the core logic or control flow for one or more auxiliary classes•Auxiliary: A class that supports a central or fundamental class


Instructor Notes:



8

Other Class Diagram Model ElementsSignal

A signal is a specification of a send request instance communicated between objects

EnumerationA data type whose literal values are enumerated in the enumeration

Data TypeTypically data types represent primitive types (such as integer or string types), and enumerations (such as user-defined data types)

Artifact The specification of a physical piece of information that is used or produced in the software development process

CollaborationType of structured classifier in which roles and attributes co-operate to define the internal structure of a classifier

The data carried by a signal instance is represented by its attributes.


Instructor Notes:



9

Class Relationships

Class diagrams may contain the following relationships:

Association

Aggregation

Composition

Generalization

Dependency

Realizes

OR

OR

OR

In Unified Modeling Language (UML) class diagrams, a relationship is the connection between classes.


Instructor Notes:



10

AssociationSpecifies peer-to-peer relationships between model elements

Navigability can be unidirectional or bidirectional

OR

Association relationships imply that instances of one class connect to instances of another class.

Association is a relationship that is realized as a property of the class.


Instructor Notes:



11

AggregationUsed to model a whole to part relationship between model elements

The part element can exist without the whole


OR

Aggregation is used to gain understanding of and insight into what makes up a class. The parts have their own data and behavior, but are still part of the whole.

This is known in the modeling world as a “has a” relationship (For example,the beacon has a carrier).


Instructor Notes:



12

CompositionAggregation with strong ownership

When the container is destroyed, all of its composite objects are destroyed


OR

Composition is a further refinement of aggregation in that they have coincident life spans. Create the whole and the parts are created as well. Destroy the whole and the parts are destroyed. In straight aggregation, on the other hand, the parts do not have to have coincident life spans.


Instructor Notes:



13

GeneralizationA relationship where one class shares the structure and behavior of one or more classes

Defines a hierarchy of abstractions where a subclass inherits a superclass

This is an “is a kind of” relationship

From Wikipedia, the free encyclopedia:

A crossover SUV (also called CUV, for Crossover Utility Vehicle) or XUV (not to be confused with GMC's Envoy XUV) is an automobile that looks like a sport utility vehicle but is built upon a more economical and fuel-efficient unibody construction.


Instructor Notes:



14

DependencyA relationship in which one class uses another

Dependencies may exist between classes because:

A message is sent from one class to the other

One class is part of another's data

One mentions the other as a parameter to an operation

Following is a list of UML dependency stereotype relationships:

Binding: Used with template elements to identify that the contents of the template would be copied into the target element

Usage: A usage relationship in which one element requires another element for its implementation or operation

Abstraction: An abstraction relationship relates two elements that represent the same concept at two different levels of abstraction

Derive: Specifies a derivation relationship among model elements that are usually, but not necessarily, of the same type

Refine: Specifies a refinement relationship between the two elements or sets of elements. Used in the transformations from analysis to design and other such changes

Trace: Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models

Instantiate: A usage dependency among classifiers indicating that operations on the client create instances of the supplier

Package Import: A directed relationship that identifies a package whose members are to be imported into by a namespace

Element Import: A directed relationship that identifies an element to be imported into by a namespace


Instructor Notes:



15

Realization

A specialized relationship where the client implements the suppliers specification

The Draw operation of the Shape interface is set to abstract (identified by the italicized font).


Instructor Notes:



16

Lab 05: Create a Class Diagram

Complete the following tasks:Review Class Diagram BasicsCreate a New Class DiagramChallenge Yourself

To begin the lab:



Expand DEV396 Labs, then select 05 Create Class Diagrams.


The instructor will walk through this lab together with the class in order to Demonstrate cheat sheet navigation.

Complete Lab 05: Create a Class Diagram in Rational Software Architect.

Between the labs in Module 1 and the labs in Module 4, there is a shift of approach because of the subject matter.

The early labs include pop-up dialogs that the students use to compare results. The diagram-oriented labs, starting with this one, use the internal browser to compare diagrams and for animated viewlets.

It is highly recommended that you walk through this lab with the students to demonstrate how to dock the internal browser underneath the editor.


Instructor Notes:



17

Where Are We?Class Diagrams

Object Diagrams


Component Diagrams

Deployment Diagrams


Instructor Notes:



18

Object DiagramsAn object diagram shows a complete or partial view of the structure of a modeled system at a specific point in time

This snapshot focuses on a particular set of object instances and attributes, and the links between the instances

Object

Link

Attribute Values

Object Name

A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. Only those aspects of a model that are of current interest need to be shown on an object diagram.In addition to class instances, you can also represent node instances, device instances, artifact instances, component instances, use case instances, actor instances, and so on.

The object diagram represents the system at a particular moment in time,and is not intended to show the evolution of the system over time. For that purpose, use a communication or sequence diagram to represent an interaction.

“In general, a dependency represents a relationship among classes, and not objects, and belongs on a class diagram, not an object diagram.” ~ James Rumbaugh


Instructor Notes:



19

More on Object DiagramsAn object diagram is most useful early in your development effort to model examples that support the investigation of requirements.

To validate class diagrams later in your development effort, you can use the object diagram to model test cases for correctness and completeness.

An object diagram basically uses the same notation as a class diagram, but uses a set of instances instead of actual classes.

The object is an instance of a class, and the link is an instance of a relationship, if specified.

When creating a link between objects, you can select an existing element or create the link as unspecified.

Object diagrams can also be used as input for test cases (these objects exist during the test). You can also use object diagrams to model a simulation of the execution of the system.

An object diagram does not show the evolution of the system over time. For that purpose, use a communication or sequence diagram to represent an interaction.


Instructor Notes:



20


Object Diagrams


Component Diagrams

Deployment Diagrams


Instructor Notes:



21

Example: Composite Structure DiagramA composite structure diagram reflects the internal collaboration of classes, interfaces, or components to describe a functionality.

It is used to express run-time architectures, usage patterns, and relationships that might not be reflected by static diagrams.

Composite Structure diagrams are similar to class diagrams, except that they model a specific usage of the structure. Class diagrams model a static view of class structures, including their attributes and behaviors.

When visualizing the system architecture, each of the internal parts may be a structured class that itself contains parts.The internals of the Course Registration System are composed of three parts: StudentManagementSystem, BillingSystem, and CourseCatalogSystem.A later slide will examine the internal structure of the StudentManagementSystem.

Ports have a compositional relationship with their parts. For this reason, we can have duplicate port names as long as they are related to different parts.


Instructor Notes:



22

Defining Internal StructureSome classes may represent complex abstractions and have a complex structure.

Classes may be decomposed into collections of connected parts.

The parts themselves may be complex and require further decomposition.

A class may be encapsulated by forcing communications from outside to pass through ports obeying declared interfaces.

The Internal Structure defines the interconnected parts and connectors that compose the contents of a structured class. It contains parts or roles that form its structure and realize its behavior. Connectors model the communication link between interconnected parts. The interfaces describe what a class must do; its internal structure describes how the work is accomplished.


Instructor Notes:



23

Structured Class UsesDepends on the semantic level of abstraction

Top Level

Block Level

Mid Level

Low Level

Define the system’s layers

Define subsystems

Define message routing infrastructure and control object instantiation

Define leaf-level classes that perform productive work

This is not meant to be a restriction on your application that it should only have a hierarchical depth of four. In reality, the nesting depth is unrestricted, but as a guideline:Structured classes at or near the top of the semantic level hierarchy should only be responsible for grouping and organizing.Mid-level structured classes control message routing and object instantiation.Ideally, productive work is performed at or near the bottom of the semantic level hierarchy.If you think of a tree, and the branches of the tree, the low-level classes are referred to as leaf-level classes, and should have a small number of dependent classes.If you are modeling behavior using state machines, the higher the level the fewer the number of states, whereas the lower level classes are often recognizable by a distinctly higher number of states.


Instructor Notes:



24

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

It is the internal structure to be modified without affecting external clients.

External clients have no visibility to internals.

A class may have a number of ports.Each port has a set of provided and required interfaces.

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

Another class connected to a port may request the provided services from the owner of the port, but must also be prepared to supply the required services to the owner.

An interface is a behavioralSpecification, a contract to be fulfilled.

A port is a structural feature,mediating communication between the structured classand the world external to it.

Ports and interfaces can existindependently from each other.


Instructor Notes:



25

Port NotationA service port is shown as a small square straddling the boundary of a classifier

A non-service port is shown as a small square inside the boundary of a classifier

ProvidedInterfaces

RequiredInterfaces

Mixed Interfaces

This shows a television declaration with its ports. The television has three input ports:•Remote•Multiple standard audio/video with S-video•DVD input. These are shown as provided interfaces, because the television accepts their inputs and acts on them. The television has one output, an audio/video output. This is shown as a required interface, because the television requires the services of another device (such as a second VCR) to process the outputs. The television is also shown with one mixed port, the coaxial port. This port handles both input and output at the same time. This is shown by connecting both a provided and required interface to it.Syntax for the port is as follows (all parts are optional):

name : Type [multiplicity] All ports of a given type have the same interfaces. Instead of declaring port types, you can show the interfaces for the port using the provided and required interface symbols. Multiplicity can be used to declare a set of ports of the same type.

To set a port for service or non-service, select the port and, in the Properties view, you can find the Service property on the General tab and the Advanced tab (Is Service).


Instructor Notes:



26

ConnectorA connector models the communication link between interconnected parts. For example:

Assembly connectors reside between two elements (parts or ports) in the internal implementation specification of a structured class.

Delegate connectors reside between a port on the external structure compartment and an internal part or port in the internal implementation specification of a structured class.

For delegate connectors, environment connections to the external port are treated as going to the internal element at the other end of the delegation connector. The delegate connector links the whole with one of its parts, and is displayed with an open arrowhead at the end of the connecting line.


Instructor Notes:



27

Example: Decomposed Composite Structure Diagram

As the system is further decomposed, each of the parts may be a structured class that itself contains parts. This is a very effective method to visualize the system architecture.The internals of the StudentManagementSystem are composed of two parts:<<;>> MainStudentForm and RegistrationController.


Instructor Notes:



28

UML Collaboration ElementA collaboration element describes a structure of elements working together to accomplish some desired functionality

Typically only incorporates aspects that are deemed relevant to the explanation

Details, such as the identity or precise class of the actual participating instances, are suppressed

Relationships are shown as connectors between the roles, which specify communication paths

A collaboration element is shown as an ellipse.

Collaborations specify a context for relationships between roles that interact to implement a specified responsibility or service. Collaborations prescribe the structure of the relationships, while the contained interactions specify the behavior required to satisfy the responsibility. Collaborations allow you to focus on patterns of interactions at varying levels of abstraction, a perspective that is often useful during the early evolution of an enterprise- or systems-level architecture. The focus is on the collection of objects orroles that interact at the black box level, enabling a “big picture” perspective of the system under consideration. Collaborations provide the capability to represent relationships at varying levels of abstraction. While a collaboration is a structural element, it can be used to represent the relationship between elements of a design or of an architecture, with or without the semantics of connectors or an explicit association. The collaboration is bound to the roles that participate in the relationship. Roles reflect the elements (usually objects) that participate in the collaboration. Connections between the roles may or may not be depicted (see the composite structure diagram).


Instructor Notes:



29

Example: CollaborationCollaboration

NameCollaboration

Role

Role Name

Connector

A collaboration has a dashed ellipse decoration and contains the name of the collaboration. The internal structure of a collaboration, consisting of roles and connectors, may be shown in the structure compartment.The roles shown here all represent an existing class element in the model identified by rolename:classname. You can also use unspecified roles, which will have only the rolename displayed.

Because the collaboration describes the structure of elements, it looks very similar to a communication diagram without the message flow (which describes behavior).

Using interaction diagrams during Use Case Analysis can lead to creating collaborations. These in turn can lead to creating composite structure diagrams.


Instructor Notes:



30

Example: Collaboration Use

Collaboration Use Name : Collaboration Name

Role Name

Binding

A collaboration is shown as a dashed ellipse icon containing the name of the collaboration. The internal structure of a collaboration, consisting of roles and connectors, may be shown in a compartment within the dashed ellipse icon. This is an example of a collaboration for the Persistency RDBMS Read sequence diagram shown earlier. The roles of the collaboration map to the lifelines on the sequence diagram, and the connectors represent the communication paths required for the roles.

Because the collaboration describes the structure of elements, it looks very similar to a communication diagram without the message flow (which describes behavior).

Using interaction diagrams during Use Case Analysis can lead to creating collaborations. These in turn can lead to creating composite structure diagrams.


Instructor Notes:



31

Complete the following tasks:Review Composite Structure Diagram BasicsCreate a New Composite Structure DiagramChallenge Yourself

To begin the lab:

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 06: Create Composite Structure DiagramsFollow the directions indicated on the Cheat Sheet.

Lab 06: Create Composite Structure Diagrams

Complete Lab 06: Create Composite Structure Diagrams in Rational Software Architect.


Instructor Notes:



32


Object Diagrams


Component Diagrams

Deployment Diagrams


Instructor Notes:



33

A ComponentA modular part of a system that hides its implementation behind a set of external interfaces.

Part of a logical or physical system

It conforms to, and provides the physical realization of, a set of interfaces.

It specifies the physical dependency to interfaces it requires.

A component is a modular part of a system that encapsulates its contents, and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. Graphically, a component is shown as a rectangle with the keyword «component».Optionally, in the right hand corner, a component icon can be displayed. This icon is a small rectangle with two smaller rectangles protruding from its left hand side. The name of the component (as a type) is placed inside the outer rectangle.Some component stereotypes are:

• «Process»: A transaction base component• «Implement»: A component definition that is not intended to have a

specification. It is an implementation for a separate «specification» to which it has a dependency.

• «Entity»: A persistent information component representing a business concept• «buildComponent»: A collection of elements defined for the purpose of system-

level development, such as compilation and versioning.

Explain the concept of a component to the students.

Remind students that the component notation is backwards compatible.


Instructor Notes:



34

Complete the following tasks:Review Component Diagram BasicsCreate a New Component DiagramChallenge Yourself

To begin the lab:

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 07: Create Component DiagramsFollow the directions indicated on the Cheat Sheet.

Lab 07: Create Component Diagrams

Complete Lab 07: Create Component Diagrams in Rational Software Architect.


Instructor Notes:



35


Object Diagrams


Component Diagrams

Deployment Diagrams


Instructor Notes:



Deployment has been repositioned in UML 2.0 to apply to artifacts, not model elements.

36

Deployment DiagramsDeployment is assigning, or mapping, software artifacts to physical nodes during execution.

Artifacts are the entities that are deployed onto physical nodesProcesses are assigned to computers

Artifacts model physical entities.Files, executables, database tables, web pages, and so on

Nodes model computational resources.Computers, storage units

A manifestation is the physical implementation of a model element as an artifact: a relationship between the model element and the artifact that implements it Model elements are typically implemented as a set of artifacts. Examples of Model elements are source files, executable files, and documentation files.


Instructor Notes:



37

NodeRepresents a run-time computational resource, and generally has at least memory (and often processing) capability.

Types:Device Physical computational resource with processing capability. Devices may be nested.

Execution Environment Represents particular execution platforms

The essential elements of a deployment diagram are nodes and their connectors. A node is a run-time physical object that represents a computational resource, generally having at least memory (and often processing) capability.Device and Execution Environment <<and device>> are types of nodes, but the UML 2 distinction between them is rather vague. Devices may have artifacts deployed for executing software that controls the functionality of the device itself (physical computational resource with processing capability). Typical examples include «print server», «application server», «client workstation», «mobile device», «embedded device», «processor», and so on. Devices may be complex, and they may contain other devices. Execution Environments represent particular execution platforms, such as an operating system («Win2K», «VxWorks», and so on), a workstation engine («workstation engine»), or a database management system («DB2»), as examples.

Explain a node on a deployment diagram.

Execution Environment and Device were not defined in UML 1.x.

The capability to deploy to nodes with an internal structure has been added to UML 2.0.


Instructor Notes:



38

Complete the following tasks:Review Deployment Diagram BasicsCreate a New Deployment DiagramChallenge Yourself

To begin the lab:

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 08: Create Deployment DiagramsFollow the directions indicated on the Cheat Sheet.

Lab 08: Create Deployments Diagrams

Complete Lab 08: Create Deployment Diagrams in Rational Software Architect.


Instructor Notes:



39

ReviewWhich type of diagram is a snapshot of a complete or partial view of the structure of a modeled system at a specific point intime?

Which class relationship involves one class sharing the structure and/or behavior of one or more classes?

What describes a structure of elements working together to accomplish some desired functionality?

Q: Which type of diagram is a snapshot of a complete or partial view of the structure of a modeled system at a specific point in time?

A: Object diagram

Q: Which class relationship involves one class sharing the structure and/or behavior of one or more classes?

A: Generalization

Q: What describes a structure of elements working together to accomplish some desired functionality?

A: Collaboration


Instructor Notes:



40

Further Information BooksWeb resources

• James Rumbaugh et al. The Unified Modeling Language Reference Manual, Second Edition. Boston: Addison-Wesley, 2004.

• http://www.uml.org/

• http://www.ibm.com/developerworks/


Instructor Notes:

Module 5 - Behavioral Diagrams 5 - 1© Copyright IBM Corp. 2007


®

IBM Software Group



Module 5: Creating UML Diagrams of System Behavior

This module will require approximately 2 hours to complete:Lecture: 1 hourLabs: 1 hour (15 minutes each)


Instructor Notes:



2


Identify the behavioral UML diagrams available in Rational Software ArchitectIdentify UML notation and provide a basic explanation of UML semanticsCreate use-case, activity, sequence, communication, and state machine diagrams in Rational Software Architect

This module will identify how structural UML diagrams can be created using Rational Software Architect, but does not provide in-depth explanations of UML or OOAD concepts and notation.



Instructor Notes:



3

Behavioral Diagrams in Rational Software Architect

Behavioral Diagrams

Structural Diagrams

ActivityDiagrams

SequenceDiagrams



ComponentDiagrams


ClassDiagrams

Use-CaseDiagrams

Model

ObjectDiagrams

DeploymentDiagrams

Visual models of a system require many different diagrams to represent different views of the system for different project stakeholders. The UML provides a rich notation for visualizing models, including the following key diagrams:•Use-case diagrams to illustrate user interactions with the system•Class diagrams to illustrate logical structure•Composite structure diagrams to show the internal structure of a class or component at runtime•Component diagrams to illustrate the organization and dependencies among modular parts of the system•Deployment diagrams to show the mapping of software to hardware configurations•Activity diagrams to illustrate flows of events•State machine diagrams to illustrate the series of states an object can have•Communication diagrams to illustrate behavior in terms of how objects interact•Sequence diagrams to illustrate behavior in terms of the sequence of interactions between objects


Instructor Notes:



4

Where Are We?Use-Case DiagramsActivity DiagramsInteraction Diagrams State Machine Diagrams


Instructor Notes:



5

Use Case DiagramsUse case diagrams:

Model the behavior of a system, and help capture the requirements of the system

Describe the high-level functions and scope of a system

Identify the interactions between the system and its actors

Describe what the system does and how the actors use it, but not how the system operates internally

Illustrate and define the context and requirements of either an entire system, or the important parts of the system

Are typically developed in the early phases of a project, and are referred to throughout the development process

Use-case diagrams are helpful in the following situations:Before starting a project, you can create use-case diagrams to model a business, so that all participants in the project share an understanding of the workers, customers, and activities of the business. While gathering requirements, you can create use-case diagrams to capture the system requirements, and to present to others what the system should do. During the analysis and design phases, you can use the use cases and actors from your use-case diagrams to identify the classes that the system requires. During the testing phase, you can use use-case diagrams to identify tests for the system.


Instructor Notes:



6

Use-Case Diagram Elements

ActorSomeone or something thatinteracts with the system

Use CaseUnits of system behavior

The use-case model contains the following elements, which are displayed in a use-case diagram:•Actors: Used to represent someone or something outside the system that interacts with the system.•Use cases: Used to represent a unit of system behavior that comprises several possible sequences of actions.•Relationships

•Include: Used when the use case modeler sees a piece of behavior that can be reused by more than one use case.•Extend: Used when the use case modeler identifies an optional piece of behavior and places it in a separate use case.•Generalization: Used when a generalization/ specialization relationship exists.

Mention the possible relationships that appear in a use-case diagram.


Instructor Notes:



7

Lab 9: Create Use-Case DiagramsGiven:

Create Use-Case Diagrams cheat sheet

Complete the following tasks:Review the basics of use-case diagrams Create a new use-case diagramRe-create an example use-case diagram from an image

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 9: Create Use-Case DiagramsFollow the directions indicated on the Cheat Sheet.


Instructor Notes:



8



Instructor Notes:



9

ActivityActivity is the specification of behavior expressed as a flow of execution through the sequencing of subordinate units.

An activity is generally modeled as one or more activity diagrams

Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors (that is what sequence diagrams are for). These are commonly called control flow and object flow models. The actions coordinated by activity models can be initiated because other actions finish executing, because objects and data become available, or because events occur external to the flow.


Instructor Notes:



10

Activity Diagrams

Activity diagrams are particularly useful in describing workflow, and a use case’s flow of events. They are similar to the old fashioned flow chart, but are utilized at a much higher level of abstraction than flow charting source code.Activity diagrams can model control as well as data flow. Partitions (the parallel lines) provide a mechanism to describe high-level responsibilities and concurrency.


Instructor Notes:



11

Action

An action is a fundamental unit of executable functionalityIt represents some transformation or processing in the modeled system

An action is a UML Element that you put INTO activity diagramsAn action represents behavior that you do NOT want to model in more detail – it is fundamental or atomic

An action is the fundamental unit of behavior specification. An action takes a set of inputs and converts them into a set of outputs, though either or both sets may be empty.


Instructor Notes:



12

A Call Behavior Action

A call behavior action represents a linked call to a separate activity (and its corresponding activity diagrams)

Drag an activity onto an activity diagram to create a call behavior actionDouble-click a call behavior action to open the linked activity’s diagram

In this case, a call behavior action can be used to represent a complex behavior that is then decomposed in its own activity diagram.From the UML 2.0 specification 11.3.9CallBehaviorAction is a call action that invokes a behavior directly, rather than invoking a behavioral feature that, in turn, results in the invocation of that behavior. The argument values of the action are available to the execution of the invoked behavior. The execution of the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin. In particular, the invoked behavior may be an activity.

You can use the actions palette or the activity diagram canvas to create this action.

Select the activity diagram canvas, right-click and select Call Behavior Action, then select whether to create an activity, select an existing element, or create unspecified.

Call behavior actions can also be used in interaction overview diagrams which will be covered later in this module.


Instructor Notes:



13

A Call Operation ActionA call operation action is an action that transmits an operation call request

It is an action that is linked to a specific method or operation in a specific class (interface, subsystem, and so on)

The official name of the action is the name of the operation

Drag an operation onto the diagram to create a call operation action

To create a call operation action, simply drag any operation onto an activity diagram. The name of the action is the name of the operation, so your naming convention should be useful.

You can use the actions palette or the activity diagram canvas to create this action.

Select the activity diagram canvas, right-click and select Call Operation Action, then select whether to create an operation, select an existing element, or create unspecified.

The example for the drive operation is from the Automobile class in the class diagrams section.


Instructor Notes:



14

Accept Event and Send Signal ActionsAccept event

An action waiting for an eventActions that may be used by themselves, or may be paired with send signal actions

Send signalAn action that creates a signal instance and transmits it to the target object, where it may cause an activity to execute

In the above examples:• The acceptance of the Cancel Order Request signal causes an invocation of a cancellation behavior. This action is enabled on entry to the activity containing it, therefore no input arrow is shown.• After an order is processed, a Request Payment signal is sent. The activity then waits to receive a Payment Confirmed signal. Acceptance of the payment confirmed signal is enabled only after the request for payment is sent; no confirmation is accepted until then. When the confirmation is received, the order is shipped.


Instructor Notes:



15

A Structured Activity Node A structured activity node represents a structured portion of the activity that is not shared with any other structured node

It is a nested activity with a corresponding activity diagram

A structured activity node is an executable activity node that may have an expansion into subordinate nodes. The subordinate nodes must belong to only one structured activity node, although they may be nested.

A structured activity node represents a structured portion of the activity that is not shared with any other structured node, except for nesting.In RSA 7.0, structured activities can be defined and have a linked activity diagram associated with it.


Instructor Notes:



16

Partitions

An activity partition is a kind of activity group for identifying actions that have some characteristic in common.Partitions divide the nodes and edges to constrain and show a view of the contained nodes. They often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the nodes of an activity.Partitions can be horizontally, vertically, or freeform oriented, and some contents can be shared.

To change the orientation, select the activity diagram canvas, right-click and select the orientation at the bottom of the menu.

Partitions can be nested.


Instructor Notes:



17

Control FlowControl flow:

Is the set of lines connecting the activities and actions (activity nodes)Represents the flow of control from one node to anotherCan have guard conditions

Control Flow

A control flow is an edge that starts an activity node after the previous one is finished. Objects and data cannot pass along a control flow edge.Guard conditions may also be used on control flows. The guard condition will be displayed enclosed in square brackets, for example [Yes] and [No].

Two of the control flows have names associated with them, Yes and No. These are not guard conditions. To associate a guard condition to a flow, enter a Value in the flow’s Properties > General tab. The guard condition will be displayed enclosed in square brackets, for example [Yes] and [No].


Instructor Notes:



18

Control NodesControl nodes coordinate the flow in an activity

Initial

Decision/Merge

Fork/Join

Activity End

Flow Final

Initial: The starting control node of the activity.Decision: A decision node has one incoming flow and multiple outgoing flows, of which only one will be taken. Guard conditions should be made to insure that only one flow can be taken.Merge: A control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows, but to accept one among several flows.Fork: A control node that splits an incoming flow into multiple concurrent outgoing flows. Tokens arriving at a fork are duplicated across each outgoing flow.Join: A join node is a control node that synchronizes multiple flows. If there is a token offered on all incoming flows, then a token is offered on the single outgoing flow.Activity End: A node that stops all flow activity.Flow Final: A node that terminates that flow.


Instructor Notes:



19

Object FlowObject flow models the data flow within an activityObject flow can only be attached to object nodesObject nodes and object flow provide the capabilities for explicit data flow modeling

Official definition: “… an activity edge that can have objects or data passing along it.”


Instructor Notes:



20

Object Nodes (1 of 3)An object node represents the data participating in an activity diagram

It represents an instance of a classifier (such as a class), as well as the corresponding data and behaviorAn object node is an abstract class, and is specialized by the following object nodes:

PinsActivity parameter nodesCentral bufferData stores

Official definition: “… abstract activity node that is part of defining object flow in an activity …”This is an abstract UML element, so you do not use this UML element in drawing tools, but use elements that specialize this base element, such as pins, activity parameter nodes, central buffer nodes, and data store nodes.


Instructor Notes:



21

Object Nodes (2 of 3)Pins

Pins are either input pins or output pins. Pins model where actions and activities are sending and receiving data

Activity Parameter NodesRepresent the data parameters coming into or going out of an activityCan send and receiveMay have an associated data type (such as a class or interface)

Output pins are object nodes that deliver values to other actions through object flows.Input pins receive values from other actions through object flows.In the diagrams, pins are represented as a small box attached to the actions and activities.A pin may have an associated data type (such as a class or interface). Go to the Typefield in the pin’s Property page and select the data type.


Instructor Notes:



22

Object Nodes (3 of 3)Central buffer node

An object node for managing flows from multiple sources and destinations

Data store nodeUsed to model persistent data, such as saving information to a database or retrieving information from a database

Central buffer node:•It is a type of data node, so it is used to model data flow•Unlike pins, it is not physically attached to an activity or action•All data nodes have buffer functionality, but the intent of the central buffer node is to make that explicit. In the illustration, the central buffer node will queue up the parts coming from two factories and make them available to the ‘Pack Parts’ activity as needed.

Data store node:•It is a central buffer node for non-transient information.•It is a specialized type of central buffer node (which is in turn a special type of object node).•Used to model persistent data, such as saving information to a database or retrieving information from a database. A data store nde may have an associated data type (such as a class or interface).•Go to the Type field in the Property page and select the data type.


Instructor Notes:



23

Putting Data Flow TogetherUML2 lets you model both control and data flow:

Object flows only connect object nodes. They cannot be directly connected to activities or actions.

Common concrete types of object nodes (which is abstract) are InputPin, OutputPin, activity parameter node, central buffer node, and data store node.The illustrated example shows some of the common ways to model data flow:•OrderData is coming into the Process Order activity as an activity parameter node. •OrderData is going into the CreateOrder activity via an InputPin.•The CreateOrder activity is sending an Order (via an OutputPin) to the SaveOrderactivity (which receives it with an InputPin).•Finally, the SaveOrder activity sends the Order to the database via the ‘Order Database’ data store node.


Instructor Notes:



24

Given:Create Activity Diagrams cheat sheet

Complete the following tasks:Review the basics of activity diagramsCreate a new activity diagramRe-create an example activity diagram from an image

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 10: Create Activity DiagramsFollow the directions indicated on the Cheat Sheet.

Lab 10: Create Activity Diagrams


Instructor Notes:



25



Instructor Notes:



26

Interaction Diagrams (1 of 2)Interaction diagrams show how objects interact, and the order of their interactionsThere are several types of interaction diagrams that emphasize object interactions, including the messages that may be dispatched among them:

Sequence diagram Communication diagramInteraction overview diagram

An interaction diagram is used to model the dynamic aspects of a system. Interaction diagrams can be used to model one particular flow of events for a use case, and commonly contain roles, links, and messages.

Introduce the concept of an interaction diagram for modeling object collaborations.

Emphasize that interaction diagrams are used to model the dynamic aspects of a system.

Static modeling is discussed in the class diagrams module.

There is a tabular alternative to interaction diagrams in the UML 2 specification. It is anticipated that there will be limited tool support for the tabular format so we do not cover it.

Timing diagrams and interaction overview diagrams are considered specialized variants and are not anticipated to be widely used within most conceptual designs.


Instructor Notes:



27

Interaction Diagrams (2 of 2)

Sequence diagramTime-oriented view of

interactions

Communication diagramStructural view of messaging

roles or parts

Interaction overview diagram

High-level view of interaction sets combined with logic

comm

sd

intover

The sequence diagram is a time-oriented view of the interaction between participants to accomplish a behavioral goal of the system. An interaction may be modeled at any level of abstraction within the system design, from subsystem interactions to instance-level interaction for a single operation or activity.The communication diagram is a structural view of the messaging between roles in a collaboration, taken from the collaboration diagram concept of UML1, or parts in a composite structure.The interaction overview diagram is a high-level view of the sets of interactions combined into a logic sequence, including flow-control logic to navigate between the interactions. Think of this as a cross between a sequence diagram, for the interactions sets, and an activity diagram, for the logic sequence.

The interaction overview diagram is a variety of an activity diagram incorporating sequence diagram fragments in place of actions and activities.


Instructor Notes:



The choice of sequence or communication diagrams is a personal choice. This course does not recommend one over the other but describes the advantages of each.

For brainstorming, some find the communication diagram easier — a closer visual representation of CRC cards.

The students should use whichever diagram they like best; however, you may want to recommend that they ultimately create the communication diagram in support of finding relationships between the associated classes. Note: RUP recommends that communication diagrams be used in Analysis and that sequence diagrams be used in Design. Communication diagrams become unwieldy in Design.

28

Sequence Diagrams Versus Communication Diagrams

Show relationships in addition to interactionsBetter for visualizing patterns of collaborationBetter for visualizing all of the effects on a given role or partEasier to use for brainstorming sessions

Show the explicit sequence of messagesBetter for visualizing overall flowBetter for real-time specificationsBetter for complex scenarios

Communication Diagrams

Sequence Diagrams

Sequence diagrams and communication diagrams express similar information, but show it in different ways. Sequence diagrams show the explicit sequence of messages and are better for real-time specifications and for complex scenarios. A sequence diagram includes chronological sequences, but does not include object relationships. Sequence numbers are often omitted in sequence diagrams, in which the physical location of the arrow shows the relative sequence. On sequence diagrams, the time dimension is easier to read, operations and parameters are easier to present, and a larger number of participants are easier to manage than in communication diagrams.Communication diagrams emphasize the structural collaboration of a society of objects and provide a clearer picture of the patterns of relationships and control that exist amongst the objects participating in a use case. Communication diagrams show more structural information (that is, the relationships among objects). Communication diagrams are better for understanding all the effects on a given object, and for procedural design.Both sequence and communication diagrams allow you to capture semantics of the use-case flow of events. They help identify objects, classes, interactions, and responsibilities, and they help validate the architecture.


Instructor Notes:



An interaction use is a type of interaction fragment.

A message from one role to another indicates that the responsibility modeled by the message has been allocated to the receiver. A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message and is not the name of an operation of the receiver. You can later assign the message by specifying the operation on the target. The specified operation will then replace the name of the message. Class operations are not formally defined until Class Design.

Note: To reduce information overload, we intentionally did not include all of the possible UML detail that can be used on sequence diagrams.

A note can be attached to a particular message, so the note moves with the message.

The messages shown here are synchronous message (identified by a filled in arrow head) but creating an automatic return was disabled in Window > Preferences > Diagrams > Sequence and Communication Diagrams.

29

The Anatomy of Sequence DiagramsMessage Reflexive

Message

Hierarchical MessageNumbering

Lifeline Role

EventOccurrence

Execution Occurrence

A sequence diagram describes a pattern of interaction among participants, arranged in a chronological order. It shows the participants in the interaction and the messages they send.A lifeline is shown as a vertical line. The lifeline represents the existence of the role at a particular time. A role symbol is drawn at the head of the lifeline, and shows its name and type, separated by a colon. A message is a communication between roles that conveys information with the expectation that activity will result. A message is shown as a horizontal solid arrow from the lifeline of one role to the lifeline of another role. For a reflexive message, the arrow starts and finishes on the same lifeline. The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number. Execution occurrence represents the participation of behavior either directly or through subordinate behavior. Execution occurrence is shown as narrow rectangles on lifelines. Also known as focus of control or execution specification.Event occurrence represents the sending or receipt of messages. Interaction use is a reference to an interaction within the definition of another interaction. The rectangle covers the lifelines that are included in the referenced interaction.Hierarchical numbering bases all messages on a dependent message. The dependent message is the message whose execution occurrence the other messages originate in. For example, message 1.1 depends on message 1.Notes describe the flow of events textually.


Instructor Notes:



30

Example: Sequence Diagram

By creating an interaction use, you can encapsulate complex behaviors to their own sequence diagrams.Double clicking the interaction use will allow you to navigate to the encapsulated sequence diagram. This technique gives you the ability to develop complex sequence diagrams in a simplified manner.

The messages shown here are asynchronous (identified by their open arrow head).An interaction use is a type of interaction fragment.


Instructor Notes:



31

Combined FragmentsCombined fragments represent a grouping of behavior shown as a nested region within a sequence diagram:

Define conditional structures in interactionsDescribe several traces in a compact and concise manner

InteractionOperand

GuardExpression

CombinedFragment

CombinedFragment

InteractionOperator

In sequence diagrams, combined fragments define conditional structures in interactions.A combined fragment defines an expression of interaction fragments. A combined fragment is defined by an interaction operator and its corresponding interaction operands. You can use combined fragments to describe several traces in a compact and concise manner.A combined fragment consists of an interaction operator, one or more interaction operands, and an optional guard condition.As the figure illustrates, a combined fragment is displayed as a frame that covers lifelines and contains interaction operands. A combined fragment separates the contained interaction operands with a dashed horizontal line between each operand.

The major reason for the replacement of the UML1 sequence diagram was for the use of structured constructs, for example, combined fragments. The current notation is based largely on the MSC (Message Sequence Chart) notation of ITU (International Telecommunications Union) Recommendation Z.120.

A combined fragment is a type of Interaction fragment.


Instructor Notes:



32

An Interaction OperatorAn interaction operator identifies the type of combined fragment

The loop operand indicates that the Fragment is executed repeatedlyThe alternative

operand identifies a set of behaviors from which only one will execute on any one pass through the interaction

The alt interaction operator represents a dynamic choice among several sub-fragments (else Guard is supported).The assert interaction operator has one subfragment that, if reached, must be executed. This interaction operator is typically used in conjunction with ignore or consider operands.The break interaction operator has one subfragment with a guard condition and, if executed, the remainder of the enclosing fragment is not executed.The consider interaction operator has one subfragment and a list of message types that are represented in the subfragment. Other messages can occur, but they are ignored. The consider interaction operator is the opposite of the ignore interaction operand.The critical interaction operator has one subfragment in which events on a single lifeline must not be interleaved with other events in other regions. This overrides the parallel operand that permits interleaving.The ignore interaction operator has one subfragment and a list of message types that are suppressed within the fragment. The ignore interaction operator is the opposite of the consider interaction operand.The loop interaction operator has one subfragment with a Guard that is executed as long as the guard condition evaluates true. The neg interaction operator has one subfragment whose execution shall not occur.The opt interaction operator has one subfragment (with a Guard) that is executed if the Guard evaluates true. This is equivalent to an Alternative Operand with a single guarded subfragment.The par interaction operator has two or more subfragments that are executed concurrently.The seq interaction operator has two or more subfragments where events on the same lifeline are ordered, but events on different lifelines may be interleaved.The strict interaction operator has two or more subfragments where events on different lifelines are ordered according to the subfragments.

The most common types of interaction operators are alternative, loop, and optional.


Instructor Notes:



33

The Guard ExpressionThe guard expression is a Boolean conditional expression that guards an interaction operand:

Appears at the start of the operandIs used to determine

if, or how long, the operand will be executedIts absence equates

to a true condition

In sequence diagrams, a guard condition is a semantic condition or restriction that is set in square brackets in an interaction operand in a combined fragment. When you create a combined fragment, a guard condition is created automatically. You can also manually create a guard condition in an interaction operand that does not have an existing guard condition.A guard condition contains two expressions that designate the minimum and maximum number of times that a loop combined fragment executes.A guard condition appears at the start of the interaction, and contains all the information that is required to make the decision about whether to execute the traces in the interaction operand. If the guard condition tests true, the traces execute. Because a guard condition is optional, the interaction also executes if no guard condition is specified in the interaction operand.

In sequence diagrams, a guard condition is also called an interaction constraint.


Instructor Notes:



34

An Interaction Operand

Each combined fragment is made up of one or more sections

The number of operands depends on the type of combined fragment

For example, a loop has one operand (the loop body), and an alternative has one or more operands (the branches of the conditional)

Each operand covers the lifelines (or a subset of them) contained by the combined fragment

An interaction operand is a structural piece of a combined fragment and may be referred to as a subfragment.

For combined fragments that support more then one interaction operand, you can add more operands by selecting the combined fragment, right-clicking then select Add interaction operand.


Instructor Notes:



35

Example: Alternative Combined Fragment

The alt interaction operator represents a dynamic choice among several sub-fragments.The combined fragment is shown as a rectangular region with the tag alt within a small pentagon on the upper left corner. The fragment is divided into subregions by horizontal dashed lines. A guard constraint representing a successful condition may be placed at the top of the subregion on the lifeline of the role whose values are being tested. The absence of a guard implies a true condition. If no guard constraint evaluates to true, the [else] constraint may be placed on the lifeline to indicate a branch.

Following is the basic flow for the Register for Courses use case. This use case starts when a Student wants to register for course offerings, or to change his or her existing course schedule.The Student provides the function to perform (one of the sub flows is executed):•If the Student selects “Create”, the Create Schedule subflow executes.•If the Student selects “Update”, the Update Schedule subflow executes.•If the Student selects “Delete”, the Delete Schedule subflow executes.

When an alternative combined fragment is first created on a sequence diagram, it displays two interaction operands. To add more operands, select the combined fragment, right-click then select Add Interaction Operand.


Instructor Notes:



36

The Anatomy of Communication Diagrams

Link

Message

HierarchicalMessage

Numbering

ReflexiveMessage

Role

A communication diagram describes a pattern of interaction among roles in a collaboration. It shows the participation in the interaction by their links to each other, and the messages that they send to each other. The nodes are rectangles representing roles of a collaboration or parts of a structured class, with the syntax represented in one of three ways:

rolename:classnamerolename:className

A link is a relationship between participants that can be used to send messages. In communication diagrams, a link is shown as a solid line that forms a communication path. A role interacts with, or navigates to, other roles through its links to these roles. You may think of a link as an instance of an association.A message is a communication between roles that conveys information with the expectation that activity will result. In communication diagrams, a message is shown as a labeled arrow placed near a link. This means that the link is used to transport or otherwise implement the delivery of the message to the target. The arrow points along the link in the direction of the target (the one that receives the message). The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are often used in communication diagrams, because they are the only way of describing the relative sequencing of messages. A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message. You can later assign the message by specifying the operation on the target. The specified operation will then replace the name of the message.

This diagram was created for the Anatomy example sequence diagram by right-clicking on the diagram canvas then selecting Add Diagram > Communication Diagram.

A message from one role to another indicates that the responsibility modeled by the message has been allocated to the receiver.

A comparison of Communication diagrams and sequence diagrams is provided on a earlier slide.

Notice that the interaction use that was on the sequence diagram is not displayed on a communication diagram. Information from combined fragments will attempt to be displayed but they lose valuable information (like the type of combined fragment).


Instructor Notes:



37

Example: Communication Diagram

The above example shows the collaboration of roles to support the Register for Courses use case ( Create a Schedule subflow). It is the communication diagram equivalent of the sequence diagram shown earlier.

You can create a communications diagram from a sequence diagram by right clicking in the sequence diagram and selecting Add Diagram.

Point out how the Communication diagram makes it easy to see the patterns of collaboration among participating objects. For example, boundary class instances are “on the edge,” control class instances are “in the middle,” and entity class instances are “toward the bottom.” This reflects the roles of these class instances, as described earlier.


Instructor Notes:



38

Interaction Overview DiagramUses a combination of activity and sequence diagram notation to provide a high-level view of the logical flow through a set of interaction uses:

Encourages the reuse of interactions, similar to interfaces and classesAllows focus at a higher level, where details are filtered out

Control nodes and flow

Interaction Use

An interaction overview diagram is a UML behavioral diagram that defines interactions. It is a variant of the activity diagram, which emphasizes the high-level control flow. Interaction overview diagrams illustrate an overview of a flow of control in which each node can be an interaction diagram.The combination of notations is depicted using an activity diagram, except interaction uses from sequence diagrams replace actions and activities. Control nodes and flow from activity diagrams are still used to provide the sequencing order and branching. Double click the interaction used to open the associated sequence diagram and view the details.

Some critics feel that the interaction overview diagram adds very little and that it is a strange mixture of concepts. Do not be surprised if your students do not openly accept this diagram.


Instructor Notes:



39

Given:Create Sequence Diagrams cheat sheet

Complete the following tasks:Review the basic editor, tools, and elements in a sequence diagram. Create a new sequence diagramRe-create an example sequence diagram.

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 11: Create Sequence DiagramsFollow the directions indicated on the Cheat Sheet.

Lab 11: Create Sequence Diagrams


Instructor Notes:



40

Given:Create Communication Diagrams cheat sheet

Complete the following tasks:Review the basics of communication diagramsCreate a new communication diagramRe-create an example communication diagram from an image

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 12: Create Communication DiagramsFollow the directions indicated on the Cheat Sheet.

Lab 12: Create Communication Diagrams


Instructor Notes:



41



Instructor Notes:



42

A State Machine DiagramState: “a recognizable situation that exists over an interval of time” ~ HassanGomaaState transitions: Possible paths the system may take from one state to anotherTriggering events: Instantaneous events that stimulate state transitionsActions: Work the system does in response to events

State machines can be used to specify behavior of various model elements. For example, they can be used to model the behavior of individual entities (for example, class instances). The state machine formalism described in this section is an object-based variant of Harel statecharts.


Instructor Notes:



43

StatesStates can have entry, exit, and do activities that are performed while in the state

Executed when the state is entered, after any activity attached to the incoming transition, and before any internal do activity

Described by an expression and executed after the entry activity is completed, but before any exit activity

Executed when the state is exited, after the completion of the do activity and before any activity attached to the outgoing transition

A set of properties whose values determine how the system will respond to stimuli. The representation of state may take on many forms. Generally, state is realized as a set of variables or enumerations in an object.Within the state diagram, the UML modeler has the ability to specify entry, exit, and do activities that are performed within the state.


Instructor Notes:



44

TransitionsA transition is the path taken during a change of state from one state to the next in response to a triggering eventGuard condition: Optional condition to be evaluated; if false, the transition is not taken

A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to an occurrence of an event of a particular type.In Rational Software Architect, there are a number of trigger events that may be used by the UML modeler. They are:•Call Event invoked by a specific operation of the class.•Change Event invoked by an expression becoming true•Signal Event invoked by a specific Signal Classifier.•Time Event invoked by an absolute or relative timer.To assign an event to a transition, right-click the transition and select Add UML > Trigger > (event type).

In composite states, optional refinements to transitions are also available:•Internal: Transition does not cause the state to be exited. Entry and exit actions will not be taken.•Local: Transition will not leave the composite state.•External: Transition will exit a composite state.


Instructor Notes:



45

RegionsRegions provide the ability to show concurrent orthogonal states

Think of orthogonal states as separate state machines that operate in parallel

Parallelism is achieved by the introduction of regions

The semantics of regions is tightly coupled with states or state machines having regions, and it is therefore defined as part of the semantics for states and state machines. When a composite state or state machine is extended, each inherited region may be extended, and regions may be added.


Instructor Notes:



46

Composite States Composite states are states that contain other states and regions

A composite state either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint substatesand a set of transitions. A given state may only be decomposed in one of these two ways.Any state enclosed within a region of a composite state is called a substate of that composite state. Each region of a composite state may have an initial pseudostate and a final state. A transition to the enclosing state represents a tansition to the initial pseudostate in each region.


Instructor Notes:



47

Orthogonal StatesOrthogonal states

Are composite states with two or more regions within the state.

Orthogonal states are an extension of composite states.


Instructor Notes:



48

Submachine StateA submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse

Similar in concept to the call behavior action in activity diagrams

Semantically equivalent to a composite state

A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. The regions of the submachine state machine are the regions of the composite state. The entry, exit, and behavior actions and internal transitions are defined as part of the state. Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse. Transitions in the containing state machine can have the entry and exit points of the inserted state machine as targets.

When creating [composite and simple] states, the states are owned by the region they reside in and can not be reused else where.

The mechanism to reuse state-based behavior is to define it as a submachine. This is a similar concept to the call behavior action in activity diagram.


Instructor Notes:



49

PseudostatesInitial State: Marks the start of the machineChoice Point: Supports dynamic branchesJunction Point: Supports static branchesDeep History: Return to the most recent substateShallow History: Return to the most recent stateJoin, Fork: Similar to activity diagramEntry, Exit Point: Used to designate a default entry or exit into a composite state or state machineTerminate: Marks the end of the state machine’s execution

Combine and direct transitions

When a pseudostate is active, a state machine has not completed its run-to-completion step and will not process events. Pseudostates are used to chain transition segments together, and a transition to a pseudostate implies an automatic transition to another state without requiring another event.


Instructor Notes:



50

Choice PointsChoice points realize a dynamic conditional branch

Actions can change subsequent guard condition evaluations

Only the initial guard conditions are evaluated before transitions are fired

When the Choice Point is reached, the outgoing segments are evaluated

Clarifies state machine modeling

Visualizes implementation decisions at the modeling level

Reaching a choice point results in the dynamic evaluation of the guards of the triggers of its outgoing transitions. This realizes a dynamic conditional branch. It allows transitions to be split into multiple outgoing paths, such that the decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step.If you were to model this example without using a choice point, there would be one transition from State1 and one transition from State2. The transition from each source state would have the same guard condition of [b<0], but the dynamic branching would be at the implementation level:

IF (a<0) {actionLT}ELSEIF (a=0) {actionEQ}ELSE (a>0) {actionGT}

This approach could also increase the maintenance costs if you need to change the actions associated with the implementation, because it is duplicated in multiple places.Choice points should be distinguished from static branch points that are based on junction points.

If more than one of the choice point guards evaluates to true, an arbitrary one is selected. If none of the guards evaluates to true, then the model is considered ill-formed. To avoid this, it is recommended to define one outgoing transition with the predefined “else” guard for every choice point.


Instructor Notes:



51

JunctionsJunctions realize a static conditional branch

Actions will not change subsequent guard condition evaluations

All guard conditions are evaluated before transitions are fired

If all guard conditions return false, then remain in the source state

Simplify state machine modeling

Chain together multiple transition segments

A junction can be used to converge multiple incoming transitions into a single outgoing transition representing a shared transition path (this is known as a merge). Conversely, they can be used to split an incoming transition into multiple outgoing transition segments with different guard conditions. In the latter case, outgoing transitions whose guard conditions evaluate to false are disabled. If you were to model this example without using a junction, there would be three transitions from State1 and three transitions from State2. The first transition from each source state would have a guard condition of [b<0 AND a<0], the second transition would have a guard condition of [b<0 AND a=0], and the third transition’s guard condition would be [b<0 AND a>0]. This approach could also increase the maintenance costs if you need to change the actions associated with the two transitions that now have the same guard conditions.A predefined guard denoted else may be defined for at most one outgoing transition. This transition is enabled if all the guards labeling the other transitions are false. Static conditional branches are distinct from dynamic conditional branches, which allow actions to potentially modify the subsequent guard evaluations.

The intent here is to transition from a source state (State1 or State2) to a destination state (State3, State4, or State5). The junction does not break the single run-to-completion step of the transition chain.

If you were to model the junction with an intermediate state, this would cause the intended run-to-completion step to be broken into two separate transitions with some period of time spend in the intermediate state (and thus also requiring another event to transition out of the intermediate state).

A state is a representation of a situation that exists over a period of time.


Instructor Notes:



52

History Deep History

Represents the most recent active configuration of the composite state that directly contains this pseudostateA composite state can have at most one Deep History vertex

Shallow History Represents the most recent active substate of its containing state (but not the substates of that substate).A composite state can have at most one Shallow History vertex.

From the UML2.0 Superstructure specification:deepHistory represents the most recent active configuration of the composite state that directly contains this pseudostate (e.g., the state configuration that was active when the composite state was last exited). A composite state can have at most one deep history vertex. At most one transition may originate from the history connector to the default deep history state. This transition is taken in case the composite state had never been active before. Entry actions of states entered on the path to the state represented by a deep history are performed.shallowHistory represents the most recent active substate of its containing state (but not the substates of that substate). A composite state can have at most one shallow history vertex. A transition coming into the shallow history vertex is equivalent to a transition coming into the most recent active substate of a state. At most one transition may originate from the history connector to the default shallow history state. This transition is taken in case the composite state had never been active before. Entry actions of states entered on the path to the state represented by a shallow history are performed.


Instructor Notes:



53

Given:Create State Machine Diagrams cheat sheet

Complete the following tasks:Review the basics of state machine diagramsCreate a new state machine diagramRecreate an example state machine diagram from an image

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 13: Create State Machine DiagramsFollow the directions indicated on the Cheat Sheet.

Lab 13: Create State Machine Diagrams


Instructor Notes:



54

Review1. What element in a use-case diagram is used

to represent someone or something outside the system that interacts with the system?

2. What are activity diagrams useful for?3. What’s the difference between sequence

diagrams and communication diagrams?

4. In a state machine diagram, what is a state transition, a triggering event, and an action?

1. These diagrams are particularly useful in describing workflow, and a use case’s flow of events.

2. Actor3. They express similar

information but show it in different ways. sequence diagrams show explicit sequence of messages and are better for real-time specifications and for complex scenarios. communication diagrams emphasize the structural collaboration of a society of objects and provide a clearer picture of the patterns of relationships and control that exist amongst the objects participating in a use case.

4. State transitions: Possible paths the system may take from one state to another; Triggering events: Instantaneous events that stimulate state transitions; Actions: Work the system does in response to events.


Instructor Notes:



55

Further Information Web resourcesBooks

Web resources•http://www.uml.org/

Books•James Rumbaugh et al. The Unified Modeling Language Reference Manual, Second Edition. Boston: Addison-Wesley, 2004.•Miro Samek. Practical Statecharts in C/C++. San Francisco, CA: CMP Books, 2002.


Instructor Notes:



56

Essentials of Rational Software Architect, V7

Instructor Notes:

Module 6 - Team Development 6 - 1© Copyright IBM Corp. 2007


®

IBM Software Group


DEV396: Essentials of Rational Software Architect, V7

Module 6: Team Development


• Lecture: 30 minutes• Labs: 1 hour


Instructor Notes:



2

Module Objectives

After completing this module, you will be able to:

Describe team development best practices with Rational Software Architect.

Compare and merge diagrams in Rational Software Architect.

Combine diagrams in Rational Software Architect.

Publish and share diagrams with other team members.


Instructor Notes:



3

Software Architect and Team Development

Architect

Create and publish models

Transform design model into code

Verify architecture and code with structural code review

Developer

Consult published models and artifacts

Elaborate the code

Verify code with code reviewRepository

The following Rational Software Architect features facilitate collaboration between architects and developers:TransformationRational Software Architect’s model transformation features allow architects to create basic code structures from high-level UML models, which can be used as a starting point for developers.Code ReviewThe code review feature is used to analyze code against the project’s architectural guidelines. Code review includes:

• Structural anti-pattern detection to assist in Java refactoring• Structural rules (including user-defined rules) to enforce architectural control of

Java codeWeb PublisherWhile creating detailed implementation code, the developer can refer to Web-published models and UML-injected Javadocs, which Rational Software Architect can generate automatically.


Instructor Notes:



4

Where Are We?Configuration Management in Rational Software ArchitectCompare and Merge ModelsCombine ModelsModel Publishing

This section discusses the model Web publishing features of Rational Software Architect. Publishing is important for sharing models and diagrams with team members, collaborators, and customers.


Instructor Notes:



5

Configuration Management (CM)CM allows change in software assets to occur in a structured, controlled, and repeatable fashion.

A CM tool can:Give team members simultaneous access to models

Control who can update different model elements

Help introduce changes in a controlled manner

Maintain the evolutionary history of a model and its elements

A CM process defines how tools will be used to manage change in a project.

Business.emx src

Repository

Configuration management (CM) is a software engineering discipline that comprises the tools and techniques (processes or methodology) that a company uses to manage change to its software assets. The goal of successful CM is to allow change in a structured, controlled, and repeatable fashion.Successful CM is achieved by applying both tools and processes to a software development project.CM tools are software tools that automate and facilitate CM activities.A CM process is the way CM is performed on your project; specifically, how a CM tool is applied to accomplish a task. The key to a good process is in tailoring it to be as simple as possible, following standard industry practices.Another important strategy for team development is to facilitate the reuse and sharing of existing project assets, such as patterns and components. Remember that changes to reusable assets need to be controlled the way changes to any other project artifacts are controlled.


Instructor Notes:



6

CM with IBM Rational ClearCaseUse IBM® Rational® ClearCase® to:

Add model, diagram, and code files to source control

Check out and check in files

Merge changes automatically

Maintain a history of changes to a file

Compare and merge versions of a file

Chang

e

Local File System

VOB Check Out

Check In2

1

IBM® Rational® ClearCase® provides software configuration management for medium- to large-sized teams. ClearCase can manage all of the artifacts in the development process, from requirements documents and design models to code and tests. ClearCase supports:

• Parallel development• Advanced workspace management, including dynamic views• Build management features, including mainframe connectors

ClearCase integrates with Rational Software Architect, including Rational Software Architect’s Compare and Merge features. When team members work with version-controlled artifacts, they frequently need to compare file versions to understand their history and development. Team members may need to merge files because a merge result generally contains all the work that multiple team members complete in parallel.

VOB stands for Versioned Object Base.


Instructor Notes:



7

SCM Best Practices: Model PartitioningPartition the model to avoid unnecessary merges

Factors to consider when deciding how to partition a model:

Stabilize abstraction levels

Minimize dependencies between models

Establish ownership policies

Avoid broken references

While the Compare and Merge features in Rational Software Architect are advanced and easy to use, model merge scenarios can become complex and prone to user error if the models involved are needlessly complicated and disorganized. To optimize your models for configuration management and team development, you should observe the following principles:

• Stabilize abstraction levels: Do not partition the model until the top-level subsystems are clearly defined. Once the subsystems are mature and stable, you can separate them to enable parallel development and to improve the speed with which the model opens. When an individual subsystem’s contents stabilize, you can then separate the subsystem from the model.

• Minimize dependencies between models: By minimizing dependencies between models, you can reduce the likelihood that a change in one model will affect another. If you allow dependencies between models, widespread conflicts can occur that must be resolved with out-of-context model merges (which are very challenging).

• Establish ownership policies: Assigning different model files to different team members can help avoid conflicts when you deliver the model to a shared work area. It can also help speed integration. You should establish the size and scope of each model so that a single person can work on it.

• Avoid broken references: Whenever you move a model partition outside of your configuration management system, you break that model file's references. You have to repair these broken references whenever you reintegrate the model back into the CM system. It can be time-consuming and error-prone to resolve a large number of references in a complicated model.

Note that when a model is partitioned, shortcuts to the partitions appear in the model where the original packages were.


Instructor Notes:



8

To partition a model, you can:Create fragments

An element that has been converted into a fragment has this icon:

Create new models from packagesA package that has been made into a model has this icon:

Absorb fragments back into the model

Copy packages from partitions back into the main model

Model Partitioning

Creating a model from a package automatically leaves a shortcut reference to the new model where the package used to be.

Creating a fragment from a model element adds an adornment to the element and creates a separate file for that element.

You can refactor an existing model file into several, smaller model files in Rational Software Architect.To separate a package from a model into a new model file, right-click the package and then click Create Model From Package. To reassemble the model after it has been partitioned, you must copy and paste the packages back into the main model.

To create a fragment, select a model element, right-click and select Create Fragment.To absorb the fragment back into the model, right-click the fragment and select Absorb Fragment.


Instructor Notes:



9

Partition and Fragment FilesAfter you have created a partition and a fragment, Rational Software Architect will create new files to represent these elements. You can view all of the files in the Navigator view.

Design Model.emx is the original model that you started with.

you have two fragments that have been created in relationship to this model. So you have two .efx files within your project.

In addition, you specified that you wanted to convert the presentation package into its own model. So there is another .emx file.

You can partition a model to help organize work in a team development environment.


Instructor Notes:



10

FragmentsFragments model elements into separate files

Model Element Fragments:All model elements – down to the class levelActivity DiagramsComposite Structure DiagramsState Machine DiagramsCommunication Diagrams

Diagrams that cannot be made into Fragments:

Class DiagramObject DiagramFreeform DiagramDeployment DiagramComponent Diagram

When viewing details of a model in the UML model editor, you can see fragments associated with it by clicking the Fragments tab at the bottom of the editor.

Actions and commands applied to a model propagate across fragments.

Compare-merge functionality works with models consisting of multiple fragments.

NOTE: You can make a fragment from an interaction but not from a sequence diagram. An interaction contains a sequence diagram.


Instructor Notes:



11




Instructor Notes:



12

Compare and Merge ModelsRational Software Architect allows you to merge model and diagram files using the compare and merge utility.

Compare models to identify changes between model versions.

Merge models when:Parallel development occursAlternative approaches are exploredCircumstances dictate

Avoid situations that require frequent merging.

You can compare two or three models with a common ancestor to find the differences among them outside a source-controlled environment, or within a team environment, using a configuration management system such as ClearCase. A new feature also allows you to compare models without common ancestry.The Compare feature can be used to compare versions of models just to see what has changed between versions as part of everyday modeling work, particularly in collaborative settings. Compare and merge becomes essential in more complicated team development settings, such as parallel development.Compare and merge scenarios can often become very complicated and difficult to resolve if they are not carefully controlled. When working with large and complicated models, compare and merge should be avoided except when absolutely necessary.


Instructor Notes:



13

Merging Models

Begin with a base contributor, the common ancestor of the models you wish to merge.

Have up to three contributors (modified versions of the base model) in a merge session.

1

12

3

Contributor 1

BaseContributor

Contributor 21

Merge

The slide shows the simplest and most common compare and merge scenario:• You and a colleague work on copies (Contributor 1 and Contributor 2) of a

model file (Base Contributor) that is under source control.• You both make changes to your copies.• Your colleague checks in changes (creating Base Contributor version 2).• You try to check in changes.• The SCM system detects that the latest version in the repository (BC version 2)

is not the version you checked out and modified (BC version 1).• The SCM system detects that your version cannot replace the version in the

repository, or else you lose your colleague’s changes.• The SCM system attempts to merge your changes into the latest version (BC

version 3) in the repository.


Instructor Notes:



14

Compare Editor

Structural Differences•Accept or Reject changes

Merged Model

Left Contributor Right Contributor

Given multiple versions of a model that were modified in parallel, you can merge the models by starting a merge session and using the Compare editor. Once you resolve all conflicts among the contributors, you can save the final merged model as a new version. When you compare two versions of a model, their differences are displayed in the Difference editor.

When working with a version control system, such as ClearCase, a merge session may start automatically when you check in a file under version control. After merging models, saving the merged model, and closing the session, the process that initiated the check-in process continues.Automatic mergesDuring an automatic merge, all differences and trivial conflicts are merged automatically. If the software automatically makes a resolution, a resolution icon is displayed beside the resolved difference in the Structural Differences view. The software also generates a merged model for these resolutions.If the merged model contains conflicts, a conflict icon is displayed beside each conflicting element in the Structural Differences view.Manual mergesDuring a manual merge, you resolve the differences or conflicts. You can right-click a difference or conflict and then Accept or Reject it. You can also accept or reject groups of differences or conflicts.You can start a manual merge session in the following ways:

• Merge models in a ClearCase version or history interface• Compare models in an Eclipse resource view that has one or more modifiable

resources

Students used to using Compare and Merge in IBM® Rational®

XDE™ Developer will find much better performance with Rational Software Architect.

The Compare and Merge view is vastly improved over the Compare and Merge interface in Rational XDE. It is fully integrated into the Eclipse environment.

In the example (which comes from the lab):

• Contributor 1 (left) has added the employeeinfoattribute to Timecard.

• Contributor 2 (right) has added the getNumberhoursoperation.

• The merged model shows the base model plus these additional elements from the two contributors.

You choose to reject automatic changes by right-clicking them in the Structural Differences window. The Structural Differences window has a tab for each contributor, and one called Conflicts<<bold>>. Conflicts have to be resolved manually.


Instructor Notes:



15

Compare and Merge FeaturesDiagram notational merge

Merge notational changes individually, just as you can with diagrams in a model file

Revert session Allows you to restart a merge without exiting the merge application

Package composite deltas Allows you to accept and reject changes at any package level in the hierarchy

Validating models before ClearCase check-in Validate each model merge before committing the update to ClearCase

Field-level merge Resolve conflicting changes by merging multi-line text fields in which scripts or snippets of java are embedded

Full context merge Allows you to merge the entire model instead of merging individual artifacts

Automated profile upgrade Automatically upgrades to the latest profile version

While you are learning how to handle merges, it is possible to get far into a merge only to realize that the approach is incorrect and you need to start over. The Revert Session button makes this easy. It is particularly helpful when you are in the middle of a ClearCase operation, because ClearCase merges all artifacts in sequence, and interrupting and restarting the flow can be tedious. Validating models before ClearCase check-in is useful during a long ClearCase operation, such as when you are delivering many changed artifacts. It can be extremely helpful because you don’t need to remember which models need validation. Rather you can perform the validation immediately after the merge while all decisions are fresh in your mind. Full context merge allows you to synchronize the workspace to the repository in a logical model mode. It provides a stronger merge experience, as each delta and conflict is generated with knowledge of the full context of the models. This eliminates a common source of corruption: the resolution of related conflicts to opposite contributors. The Automated profile upgrade feature prevents the merge from aborting when a contributor is found to be using a newer version of a profile.


Instructor Notes:



16

Lab14: Compare and Merge a ModelIn this lab, you will learn how to compare and merge a model using the Model Compare editor.

After completing this lab, you will be able to:Compare models

Merge models

To begin the lab:



Expand DEV396 Labs, then select 14 Compare and Merge Models.



Instructor Notes:



17




Instructor Notes:



18

Combine ModelsPending Changes•Mark changes from source model to be applied to target model.

Source Model Target Model

You can combine models that are not related by a common ancestry, such as independently created models.

You (as a modeler) might use this feature if you want to assemble a number of models, ones that were created informally at the beginning of your project, into a formal set of models that can be managed with version control.

Change Description

The combine dissimilar models feature is also used when you apply a transformation to update a conceptual model from Java or C++ code.


Instructor Notes:



19

Lab15: Combine ModelsIn this lab, you will learn how to combine dissimilar models.

After completing this lab, you will be able to:Combine models

To begin the lab:



Expand DEV396 Labs, then select 15 Combine Models.



Instructor Notes:



20



Instructor Notes:



21

Model PublishingPublish the entire model to HTMLPublish reports to PDF

Model diagram report

Sample UML metric report

When you publish a model as a Web site, you indicate the scope of data to include, how much about that data to include, and where you want to save the published model.Each published model is a separate, wholly contained entity with its own root page. When you publish, the root page has a link to each included model. It is the current version of the model that is published.

Reports can also be generated using IBM® Rational® SoDA®. SoDA provides cross-tool reporting. It does the work of connecting to a Rational Software Architect model and retrieving data relevant for its reports. In SoDA, you can customize the templates to get the layouts and data that you want.


Instructor Notes:



22

When and Why to Publish Models Publish models as an aid for manual model and architecture review

Publish an established API or framework

Work with developers using IBM® Rational®Application Developer

Share models with customers and partners who are not Rational Software Architect users

Publishing extracts model information and uses it to convert model elements, including diagrams, classes, packages, relationships, attributes, and operations, to images, and model information to HTML for viewing outside the modeling tool.In the published model, hypertext links let viewers navigate the model much as they would within Rational Software Architect.You can publish successive iterations of an evolving model for review or to share information with team members or customers. Another potential use is to publish documentation for a frozen API or framework.


Instructor Notes:



23

Demo: Model PublishingThe instructor will now show you how to:

Publish a model to HTML

Explore the published modelStart page

Packages

Elements

Diagrams

Watch your instructor publish a model in Rational Software Architect.

1. With the Modeling Perspective open, import the ACMEPayrollApplicationsolution project.

2. Select the project icon in the Model Explorer. Then on the Modeling menu, click Publish > Web.

3. In the Publish to Web dialog, click Browse to select a destination and create a folder on the desktop.

4. Minimize Rational Software Architect and open the new folder on the desktop. Describe the contents of the folder.

5. Double-click the index.html file to open it in Model Explorer.

6. Note that on the main page there are links to both published models in the project.

7. Click the link to the design model.

8. Show diagrams in the model.

9. Explore the diagrams in the model.

10. Explore elements in the model.


Instructor Notes:



24

Lab16: Publish a Model and Generate a Model ReportIn this lab, you will learn how to publish a model and generate a model report.

After completing this lab, you will be able to:Publish a model

Generate a model report

To begin the lab:



Expand DEV396 Labs, then select 16 Publish and Generate Reports.



Instructor Notes:



25

ReviewWhy should you partition model files?

What are model fragments?

Why might you want to combine models that are not related by a common ancestry?

Name some examples of when you might need to Web-publish a model.

Q: Why should you partition models?

A: To make team development of models possible when you have large models and teams. To avoid conflicts and potential merges.

Q: What are model fragments?A: Model elements that are

broken into separate files.

Q: Why might you want to combine models that are not related by a common ancestry?

A: This feature might be used if modelers want to assemble a number of models created informally at the beginning of a project into a formal set of models that can be managed with version control.

Q: Name some examples of when you might need to Web-publish a model?

A: Answers mentioned in the slides include: When you want to manually review the architecture, when working with developers using Rational Application Developer, when sharing models with customers and other project stakeholders who do not use Rational Software Architect.


Instructor Notes:



26

Further Information

RUP methodology topicsBooks

• Rational Unified Process, developer topics:• Designer > Whitepapers > Developing Large-Scale Systems with the

Rational Unified Process• Guidance > White Papers > Developing Large-Scale Systems with the

Rational Unified Process (to display the white paper)• Designer > Implementation > Workflow• Disciplines > Implementation > Implementation (to display the

Reference Workflow)• Designer > Configuration and Change Management: Overview• Disciplines > Configuration & Change Management (to display the

Overview)• Designer > Tool Mentors > Rational ClearCase• Guidance > Tool Mentors > Rational ClearCase (to display a list of tool

mentors)

• Brian A. White, Software Configuration Management Strategies and Rational ClearCase: A Practical Introduction. Boston: Addison-Wesley, 2000.


Instructor Notes:

Module 7 - Applying Patterns and Transformations 7 - 1© Copyright IBM Corp. 2007


®

IBM Software Group



Module 7: Applying Patterns and Transformations

This module will require approximately 2 hours to complete:

• Lecture: 1 hour• Lab 18: 30 minutes• Lab 19: 30 minutes


Instructor Notes:



2

Module ObjectivesApply reusable assets in the development process.

Apply a pre-built design pattern in Rational Software Architect.Perform model transformations

Forward transformationsReverse transformations

This module introduces patterns and asset-based development in Rational Software Architect, methods for reusing effective development artifacts and applying best practices in a project. Patterns offer a way to capture, reuse, and share solutions to common problems and a common language for describing problems and solutions. Patterns implemented in a development tool like Rational Software Architect help automate access to, and the application of, patterns. Design patterns and transformations in Rational Software Architect help automate routine modeling and coding tasks.


Instructor Notes:



3

Where Are We?Asset- and Pattern-based DevelopmentApplying Design Patterns Applying TransformationsPackaging Reusable Assets

This section describes asset-based development and the role of patterns.


Instructor Notes:



4

What is a Pattern?A solution to a recurring problem in a given context.

Patterns abstract a way of solving a design problem from the details of any particular technology

A pattern:Provides a solution to a specific problemRequires a strategy for applying the pattern in its context.Comes with consequences (advantages and disadvantages) of applying the pattern.

Grady Booch’s definition of a pattern is still one of the best: “a solution to a recurring problem in a given context.” Patterns provide a standard way of capturing and naming solutions, programming idioms, and best practices. As more developers have researched and understood patterns, patterns have become a standard way for practitioners to communicate and share what they know with each other.For an architect leading a large team of developers, with tools to share and apply patterns automatically, patterns can become a way to enforce coding standards and ensure consistency in the way a design for a system is implemented. For the developer, a set of carefully selected patterns, customized for a specific project or application, can reduce mundane coding tasks and head off confusion about how to approach the implementation of design elements in the system.


Instructor Notes:



5

Pattern SpecificationsPattern specifications are:

Patterns described in books and documentationCapture best practicesUsed for educational and communication purposesHave to be implemented manually

How patterns have beentraditionally used and understood

Pattern specifications are important, but there is much more to patterns than documentation!

Most encounters with patterns occur through pattern specifications, descriptions of patterns in documentation, books, articles, and Web sites. An important function for patterns is to enhance communication and education within the community of designers and developers. The efficiency of using patterns is greatly enhanced by documenting them in a standard way. Usually pattern specifications include at least these three main topics:

• Context: When would you apply this pattern?• Problem: A precise statement of the problem solved by the pattern• Solution: The description of the solution provided by this pattern

This list is often extended with other topics such as consequences of applying the pattern, examples, keywords, and classification.Pattern specifications are critical, but they provide only part of the promise of patterns.


Instructor Notes:



6

Pattern ImplementationsA pattern implementation is an artifact thatautomates the application of a pattern in a particular environment

Automates applying a pattern in the IDEProvides realized solutions to real problemsMakes patterns sharable and reusableHas points of variability that make

every pattern application uniquePatterns become tools, concrete artifacts in the development environment

Patterns allow you to create artifacts that can be more easily reused and customized for each use. The power of patterns is not realized by simply copying and reusing artifacts as-is (unlike cutting and pasting lines of code, or deploying an existing component into a new application). Such procedures are common and do constitute reuse, but patterns take reuse to a higher level by allowing points of variability. Patterns are not cookie-cutters. Each use of a pattern can yield a customized solution. The context in which a pattern is being applied determines the appropriate values to be substituted into the concrete artifacts as they are being realized. The key to pattern automation is the use of pattern implementation tools that expose the variability choices but hide the substitution details.


Instructor Notes:



7

Benefits of Using Pattern ImplementationsPatterns:

Increase productivitySimplify and accelerate building and testingEliminate repetitive workMake development easier and more instructive for beginners

Improve software governance, for:Achieving architecture consistencyEnforcing architectural decisionsEnforcing design and coding standards

Increase qualityApply best practices for functional and non-functional requirementsLeverage expert skills within the development organization

Increase opennessReuse and share existing architectural specificationsCreate less dependency on a specific tools vendor or platform

Organizations adopt pattern- and asset-based development to achieve the following benefits:

• Productivity: Highly repetitive, algorithmic tasks can be automated, and can result in productivity improvements of 10-100 times.

• Quality: When best practices are encapsulated into tooling, every developer consistently delivers output that follows best practices.

• Improved Governance: When required practices or policies are encapsulated in the organization’s tooling, compliance is effectively automated.

• Business Agility: Dramatically reduced development cycle times (particularly for maintenance) mean that IT can respond much more quickly to business change.

• High Leverage of Scarce skills: The best developers can concentrate on developing reusable patterns that other, less skilled, developers can reuse and learn from.

• Openness: The organization becomes less dependent on a particular tools vendor. Much routine development can be made nearly or even fully platform independent. Tooling bridges the gap to the final platform

• Business-IT Gap Reduction: By raising the level of development focus from technical syntax to business variables, the level of mistranslation can be greatly reduced.


Instructor Notes:



8

Patterns in Rational Software ArchitectThree features for automating model development with patterns:

Design Patterns: Add details to the model. Provide model markup and structures that can be transformed into code.

Observer patternSession Facade pattern

Transformations: Translate elements from one model into elements in a different model1. Model-to-model 2. Model-to-code3. Code-to-model

Java Emitter Templates (JET)transformations: a type of transformation that provides customizable, text-based transformations and code templates Transformations

Pattern

1

2

3

In Rational Software Architect, design patterns and transformations are two forms of pattern implementations. Design patterns are sets of model elements that are parameterized to be fitted into any existing model, to speed model development and mark up the model with UML stereotypes from a profile recognized by a model transformation. Transformations can be used to translate model elements from one model to another automatically, to speed the transition of elements from, for example, analysis to design or from design to implementation.Design PatternsDesign patterns allow you to make use of existing solutions developed in the same type of model that you are working on. So, for example, the Observer GoF pattern in Rational Software Architect contains design-level UML classes that can be applied in a design-level UML class model. Patterns have parameters so that you can customize them for a specific context, but patterns do not automatically translate themselves to work in different model types. You cannot, for example, apply a design pattern and get a code-level idiom in Java code without using transformations.TransformationsTransformations take elements from one model and translate them into elements of a different model. For example, you can apply a transformation to move from a platform-independent model to a platform-specific model as you add in details about the platform and get closer to the implementation. When adding levels of refinement, you can transform from a platform-specific model to another, adding more details without changing the model type. Transformations are often applied to whole models, but they can be applied to selections from models as well.

JET (also known as JET2 and EMFT JET) is an advanced topic and is out of scope for this course. JET2 is used only for situations where you need more control and flexibility than you get with design patterns and transformations. JET transformations are unique in being entirely text-based. Any transformation from text-to-text (using XML, for example) is a candidate for JET transformation.For more information about JET, see http://www.eclipse.org/emft/projects/jet.New in version 7 are features that support reverse transformations. Reverse transformations (model to code and code to model) answer customer requests for features similar to roundtrip engineering in Rational Rose and Rational XDE.Reverse transformations can be more flexible than a visualization and harvest, the only options in version 6, because a reverse transformation abstracts information, it does not just sync the model and code verbatim. Reverse transformations are covered later in the module.


Instructor Notes:



9

The Pattern Explorer view

Design Pattern

Transformation

JET Transformation

Right-click to apply, copy, move, or configure the pattern, or to view documentation.

Icons in the Pattern Explorer view

The Pattern Explorer view, associated with the Modeling Perspective, is split into two panes:Pattern tree: Presents a hierarchical list of patterns, organized into pattern groups.

• By right-clicking items in the pattern tree, you can copy and move patterns and groups, and delete and rename groups.

• By right-clicking a pattern, you can choose to apply the pattern using the Apply Pattern wizard, or open the pattern’s full documentation in Help.

• By dragging a pattern onto the drawing surface, you can create a pattern instance that can have its parameters bound by drag-and-drop actions.

Info pane: The information pane has two tabs that provide information about the pattern selected in the pattern tree.

• The Overview presents a participants class diagram, showing what objects participate in the pattern.

• The Short Description provides a brief summary of the problem and the solution the pattern provides. If you have a pattern participant selected, the Short Description describes the participant.

Note that there is an Overview tab in the Pattern Explorer as well that provides a diagram of the pattern participants. You can right-click a pattern and its complete documentation.Notice that now in version 7 transformations are included in the Pattern Explorer view. In version 6 transformations had no visual representation in the UI (transformation configurations were only available through menus and dialogs).Also notice that JET (Java Emitter Templates) artifacts are now included in the new Transformations group.Note that custom patterns show up in the Pattern Explorer view as well.


Instructor Notes:



10

Accelerating Model-Driven Development

Platform-Independent

Model

Code-based Development

Apply Patterns

Apply Patterns

Apply Patterns

ITER

ATE

Forward Transform(embedded patterns) Reverse Transform

(embedded patterns)

Apply Patterns


(embedded patterns)


(embedded patterns)


(embedded patterns)

Application Design (high abstraction)

Implementation

Application Use-Cases

Application Analysis

ComputationalIndependent

Model

Platform-Specific Model

Business AnalysisBusiness Process Models

Business Use-Cases

Model-Driven Architecture RUP Methodology

Platform-specific model markup

Model-driven development (MDD), the use of models as primary artifacts for software development, can boost productivity by improving team communication, componentization of the architecture, as well as the overall governance of the development effort, among other advantages. Automations like design patterns and transformations in Rational Software Architect can make the MDD approach more practical and efficient.MDD (and related approaches, such as the OMG’s Model-Driven Architecture)involves developing a software solution in the form of a hierarchy of models at different levels of abstraction, each model abstracting away the details of a solution from a target model. There is no minimum or maximum number of models needed to do MDD. In each case, the developer is responsible for building up a simplified information model to specify a particular solution. Tooling and automation, in the form of patterns and transformations, transforms the input model into the format required by the target environment (either a more platform-specific UML model, code, and so on).Pattern languages provide the terminology and concepts for modeling a target domain, and can readily be translated into standard UML using UML profiles. Patterns are used to add structures with this markup to a model, transformations that recognize the UML stereotypes can transform these structures down to the next level of abstraction. Reverse transformations can translate elements up to a higher level of abstraction in a similarly controlled way.

The purpose of this slide is to describe the role of the automation offered by patterns and transformations in making the benefits of model-driven development attainable.Make sure that students understand that there is not a set number of models needed to do MDD or MDA-style development. One organization might need all of the models shown on the slide, another might just need two. In MDA, CIM, PIM, and PSM are just descriptive categories for models and do not refer to specific model types (there are many kinds of platform-specific models). Avoid leaving the impression that you have to create all of these models to do MDD or follow MDA.The same guidelines can be applied with the RUP methodology. RUP models are designed to work end to end at many levels of abstraction, but, for example, many organizations skip the analysis and (in some cases) even the high level design model. Categories of models in MDA do not imply a specific level of abstraction. One person's PIM can be another person's CIM. Perspective is key to how the models are interpreted.

Note: Not all the transformations shown in the slide are currently supported by Rational IC, but custom patterns and transformations can be developed to perform any of the transformations shown in the slide that are not provided out of the box.


Instructor Notes:



11

Reuse Sets of Artifacts: Reusable AssetsA reusable asset is an organized collection of artifacts that provides a solution to a problem for a given context.A reusable asset contains:

Artifacts: Patterns, transformations, profiles, pluglets, model templates, and so on.Variability points:

Allow users to customize the asset for a specific project Artifact

Artifact

Artifact

Artifact

Variability Point

Problem

Solution

A reusable asset is an organized collection of artifacts that provides a solution to a problem for a given context. Assets have much in common with patterns. An asset:

• Includes instructions (or usage rules) to minimize the time developers need to discover, analyze, consume, and test the asset

• Includes standard documentation describing the development and business context in which the asset can be used

• Can have variability points that allow users to customize the asset for a specific project

An asset for a development project might contain requirements, models, source code, and tests. Assets might also be used to package and share deployable components, Web services, frameworks, and templates.The standard for structuring reusable assets is the Reusable Asset Specification (RAS). IBM’s Rational Software Analysis, Design, and Construction tools use the RAS format for exporting and importing assets to help with asset-based development. A RAS asset includes:

• RAS asset manifest file: The RAS asset is a compressed file that stores the files that make up the asset. At export, a manifest file is created (from the selected RAS profile file) and is included in every RAS asset's file.

• RAS asset profiles: RAS asset profiles allow you to create different types of assets. A specialized profile extends the original contents of the default profile. Every RAS manifest must have a RAS profile associated with it.

• Activity task types: Activities should be modified only by users who are familiar with using the Reusable Asset Specification to handle code manifest files. Modifications to the RAS manifest files generates activities that can render them incompatible. Activities describe tasks that you should perform to reuse the asset. It is recommended that you do not modify generated activities, but you are encouraged to add your own as needed.

Patterns and assets are both motivated by the same idea: well-documented solutions that are easy to reuse and automate because they have variability points. An asset provides a solution at a higher level of abstraction than patterns. An asset collects together whole sets of artifacts (including patterns, transformations, model templates, UML profiles, documents, and so on).


Instructor Notes:



12

Asset-Driven DevelopmentReuse requirements, design, test, and deployment assets to develop new or enhance existing applicationsSupported by IBM® Rational®products with:

Process guidanceToolingStandardsAssets

AssetManagement

Asset Production

AssetConsumption

Feedback

Feedback

Asset Identification

CandidateAsset

Program Management

The Asset Lifecycle

Asset-based development (ABD) provides a way to reuse requirements, design, construction, test, and deployment assets to develop new (or enhance existing) applications.IBM supports ABD with:

• Process Guidance: Provided with the RUP methodology and its Asset-Based Development Plug-in

• Tooling: The IBM Rational Software Development Platform makes it possible to package and share reusable assets.

• Standards: UML, Model-Driven Architecture, RAS, Middleware • Assets: Patterns, existing components, and new applications

The RUP platform and its ABD plug-in helps team members learn who is expected to do what tasks, and when, with Rational Software Architect and other Rational brand tools. Teams develop architected solutions, models, and other artifacts based on a set of well-defined standards, including RAS and UML. Every project can consume assets and produce assets for other projects in an efficient way.


Instructor Notes:



13


This section introduces applying design patterns in Rational Software Architect.


Instructor Notes:



14

Design Patterns in Rational Software ArchitectA design pattern in Rational Software Architect adds details to a model automatically. Use design patterns to add:

Model elements and relationshipsClasses, packages, and so on

Details to model elementsAttributes, operations

Markup to the modelStereotypes from a UML profile recognized by transformations

A design pattern:Has parameters that are used to bind the pattern to the modelCan be reapplied to or unbound fromthe modelUsually affect small areas of the model when applied

Like all pattern implementations, a design pattern in Rational Software Architect provides a software solution to a recurring problem within a given context. The limitations of a pattern are determined by the pattern design, and the intent of the pattern author. The scope of a design pattern in Rational Software Architect is most often a singular problem, affecting a small part of the model when applied, such as a specific use case being modeled.A design pattern can:

• Add elements and relationships to a model, such as groups of classes, actors and use cases, packages, and so on.

• Add details to model elements, such as attributes and operations to a class.• Add markup to the model. In other words, add stereotypes to model elements

from a UML profile to create elements such as analysis classes, subsystems, and platform- and technology-specific elements.


Instructor Notes:



15

Design Pattern Notation

Parameters

Pattern InstanceA UML Collaboration

Binding Indicator

Parameter Type

Multiplicity Bound Arguments

Pattern instances in Rational Software Architect are represented with UML collaborations that are stereotyped «pattern instance». A pattern instance includes the following features:

• Parameters: Each parameter in the pattern instance takes an argument. When bound, the icon changes to a blue box containing a double arrow.

• Parameter Multiplicity: The parameter’s multiplicity is shown in brackets after the parameter name.

• Parameter Type: After the multiplicity, an icon or text shows the parameter type (for example, class, interface, or operation).

• Binding Indicator: An icon or text that shows whether the parameter has an argument bound to it. An empty blue box indicates that no arguments are bound to the parameter. A binding icon shows that arguments are bound to the parameter.

• Arguments: One (or more, if the pattern allows it) arguments may be bound to the parameter.

Use this slide to talk about the concept of pattern binding.In Modeling preferences, the user can select the desired shape for the pattern instance: either rounded rectangle (the default, which is shown in the slide), or the more canonical UML Shape (ellipse).


Instructor Notes:



16

Applying a Design PatternCreate a pattern instance by dragging a pattern from the Pattern Explorer view to an open diagram, or to a model in the Project Explorer view.

1

Drag an existing class from the diagram or Project Explorer view to a pattern parameter to make it an argument of the pattern, or…

2Use the action bar to create an argument value for a parameter.3

Applying a pattern is a two-step process: you first add an instance of a pattern to the model, and then select (or “bind”) argument values for the pattern—either existing elements of the model or new elements that you create while applying the pattern.There are two ways to apply patterns in Rational Software Architect:

• Apply the pattern using the Apply Pattern wizard. Select a model as the location for the pattern instance and then select or create elements to use as argument values. You can continue to add argument values to the pattern instance after using the wizard.

• Apply the pattern interactively, using the Pattern Explorer view and the diagram editor. Drag the pattern from the Pattern Explorer and drop it onto anopen diagram. If you click or hover the mouse over a parameter in the pattern instance, the action bar will appear, allowing you either to select an existing element in the model or to create a new one as the argument value. You can also drag and drop an existing model element, either from the diagram or from the Model Explorer view, onto a pattern instance’s parameter to bind that element to the parameter.

To “unapply” a pattern, right-click the pattern instance and then click Patterns > Unapply. The pattern instance is deleted and all bindings to model elements are deleted.

Note: This slide has an animated element:

• The slide first shows the Apply Pattern wizard, where users can create a pattern instance and select argument values for the pattern's template parameters.

• A mouse-click reveals the slide shown here, providing the steps for applying patterns interactively, using the Pattern Explorer view and the diagram editor.

The little mouse icon in the lower left corner of the slide is a reminder that this slide has animation.

In the case of patterns that have only one parameter, like Singleton, using the Apply Pattern wizard you can use a model element as the Pattern Instance Target value.


Instructor Notes:



17

Gang of Four (GoF) Design PatternsRational Software Architect has the 23 GoF design patterns built in:

Can be used as the basis for custom patternsThese patterns support widely recognized best practicesHelp seed the code with transformation extensions

ExampleObserver is a GoF behavioral design pattern:

One-to-many dependency between objects When one object changes state, observers are notified and updated automatically

The 23 Gang of Four design patterns are included with Rational Software Architect’s patterns library. The Gang of Four patterns are grouped into Behavioral, Creational, and Structural varieties. For example, the Behavioral set of patterns includes the Observer pattern. Observer is used in cases when aConcreteSubject object needs to inform other objects that have registered an interest that some change inside it has occurred. When these objects have been notified, they interrogate the ConcreteSubject object to see if the change requires them to take action (see Gamma et al., pp. 293–303).


Instructor Notes:



18

Demo: Applying a Design PatternThe instructor will now show you how to:

Select the patternCreate a pattern instanceBind new elements to the patternBind existing elements to the pattern

Watch your instructor demonstrate how to apply a pattern in Rational Software Architect.

Perform a short demo based on the Apply a Pattern tutorial, part of the Rational Software Architect tutorials, available in Help > Tutorials Gallery, or from the Welcome page in Rational Software Architect.Be sure to mention that although applying a simple pattern may not seem very impressive by itself, the GoFpatterns provide only the most basic examples. The stereotype “markup” supplied by design patterns are recognized by transformations. In this way, patterns and transformations work together to elaborate models and seed the implementation code generated from them.


Instructor Notes:



19

Complete the following tasks:Examine the Observer design patternCreate the UML modeling projectSelect a PatternApply a PatternView Pattern Relationships

To begin the lab:In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 17: Apply Patterns.Follow the instructions indicated in the cheat sheet.

Lab 17: Apply Patterns

Complete Lab 17: Apply Patterns in Rational Software Architect.


Instructor Notes:



20


This section introduces applying transformations in Rational Software Architect.


Instructor Notes:



21

TransformationsTransformations create elements in a target model (domain) based on elements from a source model

Often, the source domain is more abstract than the target domain

Examples:Based on a use-case model, create an analysis model that realizes the use cases following a modeling standardBased on the analysis model, create a design model that incorporates elements of the company’s security and persistence frameworks, and follows a modeling standardStarting with a UML model, apply a built-in transformation to create code elementsTake existing code and apply a transformation to abstract out the design elements.

Transformations

You can apply a transformation to a source file to generate another form of output. When you apply a transformation to a model, the transformation interprets the elements of the source model and generates a specific output. In most cases, the source model remains unchanged. The transformation generates a new set of files.As part of MDD , transformations help you transition from an abstract model of the domain to a model that is more platform-specific, thus separating the solution from the specifics of the technology used to implement it. Using transformations, it is possible, for example, to take the same platform-independent model and transform it into multiple platform-specific models. Transformations can also work in the opposite direction. You can take a platform-specific model, like source code, and apply a transformation to create a more abstract, detailed design model based on its structure.


Instructor Notes:



22

Transformations in Rational Software ArchitectThe following transformations are built in to Rational Software Architect:

UML to UMLUML to LDM

UML to codeUML to Java V1.4UML to Java V5.0UML to C++UML to EJBUML to WSDLUML to XSD

Code to UMLC++ to UMLJava to UML

Transformations can be custom built using the Plug-in Development Environment.

There are three types of transformations possible in Rational Software Architect. Each type has at least one example available in the pattern library:

• UML to UML, including UML to Logical Data Model (LDM).• UML to Code, including transformations from UML to Java, C++, EJB

components, Web Services Description Language (WSDL), and XML Schema (XSD).

• Code to UML, including transformations from C++ and Java.


Instructor Notes:



23

Running a TransformationCreate a new instance (configuration) of the transformationChoose an appropriate project targetChoose how to manage source-to-target traceability

Transformation Configuration

Source

Transformation

Target

To apply a transformation, you must configure it by specifying properties, including source and target models, traceability options, and any special mappings needed (such as directory structure from source to destination), and so on. Transformation configurations define how a specific transformation will be applied. You can define multiple transformation configurations for the same transformation for your specific source and target models and projects. The model to be transformed can include markup, such as keyword applications (often from patterns applied to the model) that get used in the transformation. The transformation can also apply stereotypes from any profiles created for a more platform-specific target model.The last step is applying the transformation configuration to generate the transform elements in the target you specified.


Instructor Notes:



24

Create a Transformation ConfigurationA transformation configuration is an instance of a transformation with a specific:

NameSourceTarget

A transformation configuration is an instance of a transformation that includes information that is used by all transformations, such as a unique name, the source, and the target of the transformation. A transformation uses the information you provide in a transformation configuration when it executes. A transformation configuration can also include properties specific to a given transformation. When a configuration is run, an instance of the transformation is created and is executed with the properties defined in that configuration. A project in Rational Software Architect can have multiple transformation configurations, each with its own specific settings for a specific transformation.

Notice that in version 7, the Transformation Configuration editor supplements the Transformation Configuration dialog box from version 6. Notice that transformation configurations are also now project resources that appear in the Project Explorer view.


Instructor Notes:



25

Source to Target Relationships

Create source to target relationshipsCreate derived relationships from generated Java elements to their UML source model element.

Replace UML elementsMake the generated code the focus of development efforts by replacing UML elements with pointers to the code.

If you want to understand how the model elements of your source model relate to the Java or C++ elements in the target project, you can instruct the transformation to create derived relationships from generated elements to their UML source model element. When the system visualizes the generated element, the element has a «derive» dependency relationship to its source element. You can also select the option to replace the UML elements. In this case, the elements in the model are replaced with references to the derived code elements generated during the transformation. Use this option only in cases where your work in the UML is over, and you want to focus development efforts exclusively on the code, using the model to provide a snapshot of the development at the time of the transformation.


Instructor Notes:



26

Reverse TransformationsJava and C++ transformations can be reversedEnable a reverse transformation in the transformation configurationAllows you to synchronize changes between UML models and C++ and Java code

If necessary, compare and merge session starts when transformation is run

In the transformation configuration of a C++ or Java transformation, you can enable a reverse transformation (so that you can always transform both model to code and code to model). The reverse transformation transforms Java source objects into UML objects and stores these objects in the UML model that you specify. In the process, certain platform-specific details are optionally removed. Forward and reverse transformation can be used to maintain both a detailed design model in UML of the solution and its detailed code, so that you can make changes either at the level of the code itself (either using the code editor, or visually, using UML visualization), or in the model.

You will recall that a reverse-transformation for UML to Java was available as an asset for version 6. C++ and Java reverse transformations are now built in as a feature in version 7 and are supported in the Transformation Configuration editor. If you create a UML to Java or Java to UML transformation configuration, you can use the dialog shown in the slide to enable the reverse transformation.Reverse transformations allows for model and code synchronization.


Instructor Notes:



27

Reconciliation: Merge the Transformed ModelThe combine dissimilar models feature is used when you apply a transformation to update a conceptual model from Java or C++ code.

Pending Changes•Mark changes from source model to be applied to target model.

Source Model Target Model

Change Description

The combine dissimilar models feature is used when you apply a transformation to update a conceptual model from Java or C++ code. This step in the reverse transformation allows you to select which features from the source to keep in the target. It is also used to reconcile changes, when changes in the model and the code need to be merged.

This reconciliation step in version 7 is a new feature. It makes it possible to use reverse transformations to synchronize code and models.


Instructor Notes:



28

UML Visual DevelopmentC++ and Java code can be visualized with class and sequence diagrams

Changes to the code update the diagramChanges to the diagram update the codeHarvest classes into UML models

Rational Software Architect includes visual editing (or UML visualization) capabilities for Java and C++ code, including class and sequence diagrams. With these tools, you can develop projects using your existing workflow and leverage UML to:

• Visualize code• Document code • Construct and maintain code visually

You can create visualizations that abstract many of the code details to simplify the understanding of code structure and behavior. Content in the diagrams is configurable so that you can define your own context. Visual editing automates the expansion of the diagrams and serves to facilitate the discovery of an application. You can export or copy and paste diagram images into documents, such as Microsoft Word. To obtain detailed reports, you can publish diagrams and code into a Portable Document Format (PDF) report that can be archived or distributed for review.Visual editing can make coding more efficient. It includes support for creating classes, attributes (or fields), methods, and relationships in the diagram (excluding topic diagrams) automatically.

Be sure to distinguish visual development from transformation and reconciliation. Visual development replaces the roundtrip engineering that used to exist in Rational XDE. The visualized classes are one-to-one UML representations of everything in the code.


Instructor Notes:



29

Concurrent Code and Model DevelopmentReverse transformations allow for the concurrent development of UML models and code

ArchitectureV1.0

ArchitectureV1.1

ArchitectureV1.1+

ReconcileUML Model of Implementation

v1.1

ImplementationV1.0

ImplementationV1.1

ImplementationV1.1+

Model CombineAccepted change

Reverse Transformation

Iterate

Forward Transformation(omit rejected change)

IterateIntroduce an architectural deviation

Forward Transformation

You can preserve your UML specifications at the code-equivalent level of abstraction, treating them as a detailed design contract that can evolve on its own. Next , you can compare and reconcile the design contract with the current, as-built state of the corresponding implementation. This lets you preserve a more complete expression of design intent, which represents a basis for stronger and more fine-grained management of architectural conformance.


Instructor Notes:



30

Demo: Apply a TransformationThe instructor will now show you how to:

Create a UML to Java transformationTransform UML classes to Java classesReview the code

Follow Lab Apply Transformation to show students how they will create a transformation configuration and apply a UML to Java transformation.

Watch your instructor perform a UML to Java code transformation.


Instructor Notes:



31

Lab 18: Run a UML to Java TransformationComplete the following tasks:

Task 1: Create the UML modeling projectTask 2: Create UML ClassesTask 3: Transform UML Classes to Java ClassesTask 4: Perform reverse transformation

To begin the lab:

In Eclipse, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 19: Run a UML to Java Transformation.Follow the directions indicated on the Cheat Sheet.

Complete Lab 18: Apply a UML to Java Transformation.


Instructor Notes:



32

Where Are We?Asset- and Pattern-based DevelopmentApplying Design PatternsApplying TransformationsPackaging Reusable Assets

This section describes the features in Rational Software Architect for packaging assets, including custom pattern libraries.


Instructor Notes:



33

Building Custom Artifacts

Supporting creation of these artifacts in Rational Software Architect are:

The Plug-in Development Environment (PDE)Reusable Asset Specification (RAS) Import and Export

Plug-ins PlugletsModel Templates

UML Profiles TransformationsDesign Patterns

The following artifacts are used to extend Rational Software Architect:• Eclipse Plug-ins: Extension points in Eclipse are available to customize system

behavior using plug-ins. Plug-ins you develop can, in turn, contain their own extensions to existing plug-ins, and make extension points available so that other plug-ins can build on your plug-ins’ functionality. Plug-ins are also used to package and exchange many types of resources (such as patterns and transformations in Rational Software Architect).

• UML profiles are sets of stereotypes, tag value definitions, and constraints that you can use to create model elements that reflect the semantics of a specific domain or platform. Profiles make it possible to tailor the UML for use in a specific domain or platform. You can use them in patterns to apply stereotypes to pattern participants. You can also use them in transformation definitions to specify how specific model elements should be transformed.

• Patterns: You can use the Patterns Service and Framework to create implementations that codify patterns that are specific to your organization.

• Transformations: Rational Software Architect provides support using the PDE and a Transformations API for you to create custom transformations.

• Pluglets are Java applications that provide an alternative to plug-ins for extending the workbench. Pluglets can be thought of as a “lightweight plugin,” usually created to handle routine tasks.

The Plug-in Development Environment (PDE) is a set of tools in Eclipse for creating, developing, testing, debugging, and deploying Eclipse plug-ins. The PDE includes tools for the developing fragments, features, and update sites.

Each of the artifacts depicted on the slide will be covered in detail in this course. Briefly describe and define each one here. See the student notes for details.


Instructor Notes:



34

Sources for ArtifactsPatterns, transformations, and other artifacts are not limited to artifacts you create for yourself. They can come from a variety of sources.

IBM Rational Software

Peer Groups

Your Group

Third-Party Software Companies

Solution inRational Software

Architect

The real power of extensibility resources is that they can be shared between collaborators, projects, groups, or even different organizations.These artifacts can be leveraged into major gains in productivity, not just for single projects but in many different organizations within an enterprise. A good method really deserves more than a single use. By creatively using extensible artifacts, good ideas can be shared and used in new projects simply and effectively.

Describe the extensibility topic as part of a larger objective to achieve efficiency and interoperability.


Instructor Notes:



35

Patterns and Transformations As Reusable AssetsRelated patterns and transformations can be grouped in libraries.Patterns and transformations can reside in the same Eclipse plug-in.Plug-ins can be grouped and exchanged in RAS format.

Eclipse Plug-in

Patterns Library

RAS Asset

Eclipse Plug-in

Patterns Library

Pattern implementations realize their maximum benefit from reuse and distribution as RAS assets. They can be exported as deployable plug-ins. As patterns and transformations are created, the required meta (RAS manifest) files to support the RAS packaging are added to the project (both to the individual artifacts that it comprises, and to the pattern library itself) on export. The content of the manifest file is determined by a patterns profile, which specifies the type of the meta file used to package and also restore RAS assets.A pattern repository is always created for you whenever any pattern plug-ins are detected and available to your workspace. Patterns installed as plug-ins and patterns in other repositories all display in the pattern repository and the Pattern Explorer view.Common RAS features, such as searching and adding groups (folders), are also available in the Pattern Explorer view. Thus, pattern functions can be accomplished without using the Asset Explorer view.


Instructor Notes:



36

ReviewHow many levels of abstraction are needed when creating a software solution?What is a pattern implementation? What is a pattern specification?What tools exist to help build your own patterns?

Q: How many levels of abstraction are needed when creating a software solution?

A: It depends on the project and organizational standards.

Q: What is a pattern implementation? What is a pattern specification?

A: A pattern specification describes a pattern, including the problem it solves, the solution it provides, and its context, along with strategy, consequences, and other optional information.

A pattern implementation is an automated version of the pattern, a tool to apply the pattern automatically in the development of a solution.

Q: What tools exist to help build your own patterns?

A: Rational Software Architect provides pattern authoring tools as part of the Plug-in Development Environment for creating custom design patterns and transformations.


Instructor Notes:



37

Further Information Web SitesBooksArticles

Web Sites• IBM, “Patterns Solutions.” IBM developerWorks, accessed 15-January-2007.

http://www-128.ibm.com/developerworks/rational/products/patternsolutions/assets.html

Books• Buschmann, Frank et al. Pattern–Oriented Software Architecture , Volume 1: A

System of Patterns. Hoboken, NJ: Wiley, 1996.• Gamma, Erich et al. Design Patterns: Elements of Reusable Object-Oriented

Software. Boston: Addison-Wesley, 1995.Articles• Gee, Clive and Eoin Lane. “Building SOA applications with reusable assets, Part

2: SOA recipe reference example.” IBM developerWorks, 2006 http://www-128.ibm.com/developerworks/webservices/library/ws-soa-reuse2/

• Kleppe, Anneke et al. MDA Explained The Model Driven Architecture: Practice and Promise. Boston: Addison-Wesley, 2003.

• Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. 2nd Ed. Upper Saddle River, NJ: Prentice Hall, 2002.

• Larson, Grant and Eoin Lane. “Building SOA Applications with Reusable Assets, Part 1: Reusable Assets, Recipes, and Patterns.” IBM developerWorks, 2006 http://www-128.ibm.com/developerworks/webservices/library/ws-soa-reuse1/


Instructor Notes:



38


Instructor Notes:

Module 8 - Traceability 8 - 1© Copyright IBM Corp. 2007


®

IBM Software Group



Module 8: Traceability

This module will require approximately 1 ½ hours to complete:

• Lecture: 1 hour• Lab 20: 30 minutes


Instructor Notes:



2

After completing this module, you will be able to:Ensure that solutions are connected to requirements (in other words, traceability) Create traceability to IBM® Rational® RequisitePro®

Create traceability to IBM® WebSphere Business ModelerUse topic and browse diagram to investigate traceabilities.

Module Objectives

This module focuses on the integrations between IBM® WebSphere® Business Modeler, IBM® Rational® RequisitePro®, and Rational Software Architect. These tools can be used together to optimize business transformation and systems development efforts. Additionally, the module shows how to create and maintain links and trace relationships between artifacts in these different development tools.Finally, it shows how, within Rational Software Architect, you can do traceability analysis using topic and browse diagrams, set up traceability relationships, and create a traceability report.


Instructor Notes:



3

TraceabilityTraceability answers key questions in development, such as:

What requirements is this part of the design based on?Why did this (feature, use-case, subsystem, class) get implemented this way?What are the non-functional requirements for this design ?"What is the impact of changing a requirement?What happens to the solution if the business process is changed?

?

Software development starts with business modeling, to figure out how to transform a business for competitive advantage through improved business structures, processes, and systems. WebSphere Business Modeler enables you to improve business processes by modeling and analyzing them, and simulating alternatives.Modeling business processes uncovers opportunities for improvement through automation. Analyzing business processes leads to the discovery of new software requirements. RequisitePro is a market-leading requirements management system for project teams who want to improve the communication of project goals, reduce project risk, and increase the quality of applications before deployment.In virtually every systems development effort, traceability is required, implicitly if not explicitly. Even if it is not mandated by your stakeholders, traceability is important to ensure that stakeholder requirements are implemented, and to enable impact analysis if requirements change (as they invariably will). As you design your systems, you need to be able to trace design elements back to requirements, and as you implement your systems, you need to be able to trace from the design elements to code, and in a larger context, to hardware itself.


Instructor Notes:



4

Product Integrations with Rational Software Architect

Rational Software ArchitectIBM®

WebSphere®

Integration Developer

UML (contract)BPEL

WSDL

one-way flow

BPEL has onlystuff that isto be automated

WebSphere Business Modeler

IBM® WebSphere®

Business Monitor

RequisitePro

IBM® WebSphere®

Application Server

IBM® WebSphere®

Process Server

RUNTIME

RequisitePro provides a powerful way to manage requirements and use cases to promote better communication, enhance teamwork, and reduce project risk. RequisitePro is integrated with Rational Software Architect to allow you to link development artifacts and requirements, and to demonstrate traceability from one to the other.Modeling tools are useful in designing and building choreographed business processes. WebSphere Business Modeler models define the interfaces between processes, which are the contract for design and implementation. Rational Software Architect integration with WebSphere Business Modeler supports this business-driven, contract-based design and construction.IBM® WebSphere® Studio Application Developer Integration Edition V5.1 is optimized for developing applications that deploy to IBM® WebSphere® Business Integration Server Foundation (WBISF) V5.1. WebSphere Studio Application Developer delivers a next-generation composite application development environment for building service-oriented applications that extend and integrate your existing IT assets. In addition to a full J2EE development environment, WebSphere Studio Application Developer Integration Edition V5.1 provides easy-to-use tools for creating reusable services out of a variety of back-end systems, and for choreographing the interactions between those services using Business Process Execution Language for Web services (BPEL).


Instructor Notes:



5

Where Are We?Integration with RequisiteProIntegration with WebSphere Business ModelerExploring Traceability Relationships

This section introduces the RequisitePro integration with Rational Software Architect.


Instructor Notes:



6

Traceability from Requirements to Design

Needs

SoftwareRequirements

Design User Doc

FeaturesSolution

Space

Problem Space

Traceability

ProblemProblem

The system to be built

Test Procedures

Managing requirements involves the translation of stakeholder requests into a set of system features. These in turn are detailed into specifications for functional and nonfunctional requirements. Detailed specifications are translated into test procedures, design, and user documentation.IBM Rational tools provide traceability through the whole development and governance lifecycles. You can model your organizations with Rational Software Architect, and your business processes with Rational Software Architect and WebSphere Business Modeler. You can document policies in RequisitePro, andshow how policies are traced to initiatives that allow you to comply with those policies.

Traceability allows us to: • Assess the project impact of a

change in a requirement.• Assess the impact of a failure of a

test on requirements (that is, if the test fails, the requirement may not be satisfied).

• Manage the scope of the project.• Verify that all requirements of the

system are fulfilled by the implementation.

• Verify that the application does only what it was intended to do.

• Manage change.


Instructor Notes:



7

Rational RequisitePro IntegrationRational RequisitePro

A requirements management tool Enables you to track relationships between requirementsProvides functionality to analyze the impact of changes to requirements

The Requirements perspective in Rational Software Architect:

Provides an effective interface to requirements managed in RequisitePro, including:

Documents – Vision, use-case specifications

RequirementsRequirement PropertiesViews

Allows requirements to be traced to model elements

Features and Vision

Vision Document

FEAT 1

FEAT 3

All Features

Use Cases

FEAT 7

The RequisitePro solution is a requirements and use-case management tool for project teams who want to improve the communication of project goals, enhance collaborative development, reduce project risk and increase the quality of applications before deployment.The RequisitePro integration provides capabilities for associating requirements with domain elements in supported IBM Rational Software Delivery Platform products. You can use the integration to create, manage, and track project requirements. From within the Eclipse platform, you can view your requirements artifacts, create new requirements, modify requirement properties (attributes), create relationships (traces) between requirements and model elements, and clear suspect links.Note: The integration capability is only available if the RequisitePro product is installed on the same computer as the IBM Rational Software Delivery Platform product.


Instructor Notes:



8

Views of the Requirement Perspective

RequirementExplorer

Requirements Trace Link Clipboard

Requirements Properties

Query Results Requirement Link Problems

The Requirement perspective in Rational Software Architect enables all the capabilities of the integration, including the following views:

• Link Clipboard: Used to remember which linkable elements or RequisitePro requirements you saved for linking.

• Requirements Trace: Shows requirements (and model elements) that are linked to the requirement selected in the Requirements Explorer.

• Requirements Explorer: The RequisitePro package hierarchy that contains requirements documents, requirements, and views. Buttons across the top of this view allow you to open a RequisitePro project and control whether the package structure is shown in the view, and whether the domain object linking views are shown in the Requirement perspective.

• Requirement Properties: Provides ready access to a selected requirements attributes. From here, you may change attribute values without having to leave your Eclipse environment.

• Query Results: Displays the results of a view.• Requirement Link Problems: Displays any link errors between model

elements and requirements.Note: Views cannot be created in the Requirement perspective.


Instructor Notes:



9

RequisitePro

Requirements Explorer Query Results

The RequisitePro interface and the Requirement perspective views are similar in both functionality and look and feel.The left pane is called the Project Explorer (sometimes called just the Explorer). The right window is where all views are displayed. A view is your window into the project requirements database displayed as matrices.Documents are opened in Microsoft Word, which includes the RequisitePro menu option. You can switch between the Word and RequisitePro to organize and prioritize your requirements and the trace relationships among them, and track requirement changes.


Instructor Notes:



10

RequisitePro Requirements Traceability Model

<<trace to>><<trace to>>

System RequirementsFEAT(Feature)

SUPP(Supplementary Requirement)

UC(Use Case)

<<trace to>>

Domain Element(Other Model Element)

<<link>>

PROXY Requirement

Domain Element(Use Case)

<<link>>

?

When a requirement in RequisitePro is copied or dragged and dropped onto a model element, the default relationship created is a traceability relationship from the model element to the requirement. Therefore, it is recommended that projects follow the traceability model above, which allows you to trace from a model element all the way to your high level requirement. It is the default traceability model provided with a RequisitePro Use Case template.This approach allows you to use indirect traces. You can create an indirect association by linking domain elements and requirements through proxy requirements and traceability. An indirect trace is a trace between two requirement types that have another requirement in between. For example a trace from a Proxy requirement to a SUPP and then to a FEAT will support an indirect trace from the Proxy requirement to the FEAT requirement..By default, the integration generates a proxy requirement for any associated domain elements other than UML use cases. The proxy requirement represents the domain element within Rational RequisitePro. The integration also creates traceability from the proxy to the requirement that you selected for the association.

ReqPro and RSM integration only allows you to drag and drop a requirement onto a model element. Not the other way around. And it creates a default traceability relationship from the model element to the requirement. Because of the way the integration works, it actually becomes a constraint on how to set up the traceability model in a ReqPro project in order to get full traceability from model elements to high level requirements. We suggest that for a ReqPro project you use the bottom up traceability model which traces from a low level requirement to a high level requirement or trace from a derived requirement to a source requirement.


Instructor Notes:



11

Associating Requirements and Model Elements

Associating with an existing element

Drop a requirement on to an existing model element to associate that element with the use case in RequisitePro.You can associate requirements with use cases, classes, diagrams, and relationships (associations, messages, and so on).

Creating a new model element

Drag a requirement to a diagram to create a model element in themodel that is linked to the requirement in RequisitePro. By default, use-case requirements create use cases in the model, all other requirements create classes.

If use cases have been written, but model elements to represent them have not been created in Rational Software Architect, you can drag the use case requirements onto a diagram to create a use case model element.If other requirement types are dragged on to a diagram, a class is created by default. You may create a mapping between requirement types and model element types by modifying the properties of the RequisitePro project in the Requirements Explorer.Consider carefully what traces should be established and maintained between model elements and requirements:

• Creating traces adds maintenance overhead, but with the right balance, the quality and timeliness of change impact analysis can be greatly improved.

• Consider associating architectural and major design elements to those requirements that, if changed, may result in a major impact to the system (and project).


Instructor Notes:



12

Associating Requirements and Model ElementsWhen a requirement is dropped onto a model element, a proxy is created for the model element in RequisitePro.

Use cases are always directly linkedProxies are RequisitePro requirementsMapping between model elements and requirement types are managedusing the RequisitePro project propertiesAdditional attributes may be added to the proxy requirement types.

Linking requirements and model elements enhances Rational Software Architect. You can extend your requirements and model elements with the following capabilities:

• Associate requirements with model elements quickly by dragging artifacts between views.

• Create associated requirements and model elements quickly by dragging artifacts between views.

• Navigate to, and view, associated artifacts. • Manage your model elements with attributes, such as priority and status, in

RequisitePro.• Establish traceability to requirements to indicate dependencies, and ensure that

your design satisfies your project requirements. • Monitor the impact of change within your project. • Develop use cases in RequisitePro and model them in Rational Software

Architect, showing interaction with actors and other use cases. • Change the name and text of a use case in either tool, and synchronize the use-

case artifacts based on rules, which you can configure.


Instructor Notes:



13

Trace Between ElementsExamine traceability relationships between requirements in the Requirements Trace view

Trace from focus element to requirementsTrace to focus element from requirements

Use the Requirement Trace view to examine traceability relationships between requirements. Navigate any traceability within the RequisitePro project, including traceability to and from proxy requirements that are created by indirect associations to model elements. There are several ways to view requirement traceability:

• Select a requirement in the Requirement Explorer view and view traceability in the Requirement Trace view.

• Use the Requirement Query Results view to examine the results of queries that are created in RequisitePro views, including the Traceability Matrix and Traceability Tree views.

You can right-click a requirement in any view to perform any of the following actions:

• Remember the requirement for linking in the Project Explorer view. • Use the Select Requirement In menu items to navigate to the Requirement

Explorer view, the Requirement Trace view, RequisitePro, or a RequisitePro document.

• Remove a link or a trace relationship. • Change the focus of the view to the selected requirement to view its trace

relationships. • Add or remove a suspect condition on a traceability relationship.


Instructor Notes:



14

Given:Existing RequisitePro project

Complete the following tasks:Explore Requirement PerspectiveLink Folders and Files to RequirementsLink UML Model Elements to RequirementsLink Java Classes to RequirementsReview Requirements

To begin the lab:

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 19: Create Traceability Links.Follow the instructions indicated in the cheat sheet.

Lab 19: Create Traceability Links

Complete Lab 19: Create Traceability Links in Rational Software Architect.


Instructor Notes:



15

Where Are We?TraceabilityIntegration with RequisiteProIntegration with WebSphere Business ModelerExploring Traceability Relationships

This section describes the integration between Rational Software Architect and WebSphere Business Modeler.


Instructor Notes:



16

WebSphere Business Modeler People who know the business create the models

Model Resources, roles, organization information, business metricsEnables teamwork, communication, versioning and Web publication

Clean Hand-off to ITBusiness modeling is the starting point for rapid and accurate IT process deployment and application development

WebSphere Business Modeler products help organizations fully visualize, comprehend, and document their business processes. Rapid results can be obtained through the collaboration functionality, where subject matter experts team to clearly define business models and eliminate inefficiencies. You can model business processes, then deploy, monitor, and take actions based upon key performance indicators, alerts, and triggers for continuous optimization. Business processes then get tightly linked with strategic corporate objectives. WebSphere Business Modeler products can drive much more granular business insight and knowledge, where knowledge equates to competitive advantage.


Instructor Notes:



17

Introducing Business Driven Development

Complex processes, choreographed or not, must be architected and designedWebSphere Business Modeler defines the contract for design and implementation of those tasksRational Software Architect reads WebSphere Business Modeler models so that the contract can be implementedOther tasks are automated in WebSphere Integration Developer


WebSphere Business Monitor

Process Modeling and Simulation

Process Automation Process Management

WebSphere Process Server

Rational Software ArchitectIBM® Rational® Software Modeler

Design and Construction

Business-driven development (BDD) is a methodology for developing IT solutions that directly satisfy business requirements and needs, in an effort to move IT away from creating technology-centric solutions and toward the creation of solutions that focus on improving an organization’s actual business processes.In BDD , business processes are modeled to serve as input for requirements, and for modeling the solution domain. The domain model serves as a kind of contract or specification that is fulfilled by the software architecture and its implementation.After deployment, the project enters the monitoring or management phase. Once they are up and running, business processes can be monitored for real-time performance. Measurement is essential to validate whether the IT solution meets the needs of the business as defined by a service level agreement (SLA).The following IBM software tools enable this process:

• WebSphere Business Modeler is used to perform business process modeling, with basic process modeling, validation, and documentation tools.

• Rational Software Architect can read and interpret WebSphere Business Modeler models and translate them into design-time UML constructs.

• IBM® WebSphere® Process Server and IBM® WebSphere ® Integration Developer provide a process integration platform.

• IBM® WebSphere® Process Monitor can monitor business processes in real time, with analysis and reporting tools.


Instructor Notes:



18

WebSphere Business Modeler and Rational Software Architect

1. Business analyst creates business model

2. Software Architect views business model as UML

3. Requirements analyst gathers requirements based on business model

4. Software Architect creates UML design model

5. Software Architect references UML view of Business Process Model from UML design model

6. Software Architect creates design in UML then implementation in code


RationalSoftwareArchitect

UML DesignModel

Business ProcessModel

View as UML Contract

Business Process models serve as contracts for software

implementation of roles / tasks

In BDD , the first task is to use WebSphere Business Modeler to model the business processes that need IT enablement. Normally this starts with modeling the key business processes and then, using the outputs of the modeling activity, communicating the business requirements to the IT domain. In the later stages of the IT lifecycle, the models will help to validate that IT delivered what was proposed by the business. Once the processes are modeled, the models can be used as inputs to the requirements gathering and modeling phases of an initiative. The activities or process steps that make up a given business process model can be analyzed to form the basis of use-case and requirements modeling with Rational Software Architect and RequisitePro.Based on the use cases, the application architecture is structured, designed, and developed in Rational Software Architect. After development, the project moves to the deployment stage, during which the developed components are exposed as publishable, location-transparent, and discoverable services. These software services are deployed to an execution runtime, such as an application server.


Instructor Notes:



19

Business Process Model ElementsProcess diagram generated by WebSphere Business

ModelerStop NodeDecision

Task

Control flow

Business Item

Alternate paths

Annotation

WebSphere Business Modeler notation is based on BPMN (Business Process Meta-model Notation):

• Tasks are the main elements. A task can also be a sub-process that you can expand into another process diagram.

• Control flow passes from left to right, with business items flowing between tasks and sub-processes.

• Decision points specify alternative paths.• Merges synchronize alternative paths back into the main flow.• Parallel or alternate paths can be modelled with Forks and Joins.• Start Nodes begin a process, Stop Nodes end a process, and End Nodes

terminate a path within a process.The slide shows an example process diagram using some of the elements described above. Tasks are the main elements, and can also represent a sub-process that can be explored. The control begins at the Start Node and passes from left to right, moving business items between the tasks. When the control reaches a decision point, alternative paths are available. Merges (not shown here) synchronize these alternative paths back into the main flow. Parallel paths can be modeled with Forks and Joins (also not shown here). The Stop Nodes end a process, and End Nodes terminate a path within a process.


Instructor Notes:



20

Business Processes to Business Use CasesWebSphere Business Modeler models can be opened in Rational Software Architect

Business model elements are automatically translated to UML elements

Business Processes in WebSphere Business Modeler

Business Use Cases in Rational Software Architect

If you have an existing WebSphere Business Modeler project, you can view it as a generated UML 2.0 model file. The generated UML model represents the specification, or contract, that defines usage and realization requirements for implementation architectures.You can also create a separate UML model to represent a specific implementation of the business artifacts that are defined in the business model. You can then use model-driven development to extend, implement, and realize the artifacts that the generated UML 2.0 model defines.


Instructor Notes:



21

Business ProcessesIn Rational Software Architect, a business process maps to:

A use case and realization (black box) viewAn activity diagram (white box) view

When a WebSphere Business Modeler model is opened in Rational Software Architect, process diagrams become activity diagrams in UML. As part of a business-driven approach, these activity diagrams provide the development team with the business context for the project, something which is often overlooked in IT projects.Note the following points about the translation of process elements to UML:

• Actions in the UML are the same as tasks in the process model.• The swimlanes in each diagram show which role is performing the action or

task.• Actions are candidate system use cases.

The activity diagram is generated in Rational Software Architect automatically, but the generated diagram does require some clean-up. However, the generation of this activity diagram has been improved in version 7.


Instructor Notes:



22

Mapping Roles to InterfacesA role is a characteristic of a resourceRoles are shown in WebSphere Business Modeler in the swim-lane viewMethods in the interface are responsibilities of the role that need to be implemented

WebSphere Business Modeler Rational Software Architect

A role is a characteristic of a resource. For example, an Employee resource could have the role of Customer Service Representative, Supervisor, or Manager.Roles in the process model become business workers elements in UML. Seeing the roles in this way provides the development team with a clearer picture of who is involved in using the business, and in implementing business processes. These business workers may become system actors during analysis and design.


Instructor Notes:



23

Mapping Business Items to Classes

Business Entities in Rational Software Architect

Business Item in WebSphere Business Modeler

In the business process model, business items are business documents, work products, or commodities that are transformed into business operations. Examples of business items are manufacturing order, mother board, power supply, and memory chip (in a PC assembly process), itinerary and customer information record (in a trip reservation process), and passenger (in a transportation process).In the UML, business items become business entity classes, with attributes based on the attributes of the business items in WebSphere Business Modeler.


Instructor Notes:



24

Where Are We?TraceabilityIntegration with RequisiteProIntegration with WebSphere Business ModelerExploring Traceability Relationships

This section describes ways to explore traceability relationships between model elements using UML diagrams in Rational Software Architect.


Instructor Notes:



25

Modeling Traceability RelationshipsModel traceability among model elements with dependencies

Using model transformationsManually added in diagrams

Use «derive» or «use» dependency relationship

These relationships can be explored using topic and browse diagrams

This module has described traceability relationships between requirements in RequisitePro and model elements in a model in Rational Software Architect. We also saw how elements in a business process model in WebSphere Business Modeler can be directly translated to UML by opening the model in Rational Software Architect. These translated business model elements have traceability relationships to actors and use cases in the use case model, those elements with design model elements, and so on. Traceability between UML model elements can be documented from one model to another using simple UML notation. Traceability can be shown as a dependency, stereotyped «derive». Previously we saw how «derive» dependency relationships are added by transformations between source models and their target models. These relationships can be displayed for documentation purposes in UML diagrams and reports. They can also be explored using topic and browse diagrams.


Instructor Notes:



26

Exploring Traceability RelationshipsUse topic and browse diagrams to explore traceability relationships and generate edit diagrams

Topic Diagrams:Show traceability from model elements to code and links to requirements documentationSaved in the model

Browse Diagrams:Explore traceability relationships among model elementsAre not saved in the model

You can explore traceability relationships by searching for related elements using a topic diagram, or by searching for dependencies using a browse diagram. Browse diagrams are used for exploring these relationships throughout the model. Topic diagrams persist in the model, so they are more often used to document specific relationships.

Because topic and browse diagrams are not meant to be reformatted, an edit diagram derived from a topic diagram is shown in the slide (you can see the tab for the topic diagram editor behind it). The edit diagram has been formatted so that the elements can be easily viewed in the slide.Browse diagrams are meant to be reviewed and discarded, so they are generally not as carefully formatted as other diagrams. To clean up a browse diagram, convert it to an edit diagram.


Instructor Notes:



27

ReviewHow is traceability between models useful in model-driven and business-driven development?How is traceability handled between business process models in WebSphere Business Modeler and UML models in Rational Software Architect?How do you create and manage traceability between UML models and RequisitePro requirements in Rational Software Architect?What type of relationship is used to show traceability between model elements inRational Software Architect?

Q: How is traceability between models useful in model-driven and business-driven development?

A: Traceability can show what requirements a part of the design is based on; why a feature is implemented a certain way; the impact of changing a requirement or business process; and so on. Ask students how they plan to use traceability.

Q: How is traceability handled between business process models in WebSphere Business Modeler and UML models in Rational Software Architect?

A: Process models from WebSphere Business Modeler can be opened in Rational Software Architect. Requirements, analysis, and design models can be derived from the imported process model with traceabiilty.

Q: How do you create and manage traceability between UML models and RequisitePro requirements in Rational Software Architect?

A: RequisitePro use cases can be used to create use cases in a model. Requirements can be linked to model elements using RequisitePro.

Q: What type of relationship is used to show traceability between model elements in Rational Software Architect?

A: There are many ways to indicate a traceability relationship. The way that transformations show traceability is with a «derive» dependency relationship, so this might be the best way to show traceability in Rational Software Architect.


Instructor Notes:



28

Further Information Web ResourcesArticlesRelated Courses

Web Resources• IBM. “IBM Rational Delivery Platform.” IBM developerWorks.

http://www-128.ibm.com/developerworks/platform/ (Accessed 19 January 2007).

Articles• Ackerman, Lee and Bertrand Portier, “Design SOA services with Rational

Software Architect, Part 1: Get started with requirements, process, and modeling.” IBM developerWorks, 2006. http://www-128.ibm.com/developerworks/rational/education/dw-r-soaservices1/index.html

• Leffingwell, Dean and Don Widrig. “The Role of Requirements Traceability in System Development.” The Rational Edge (September 2002) http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/sep02/TraceabilitySep02.pdf

• Miller, Jeff. “Model Rational RequisitePro requirements in Rational Software Architect.” IBM developerWorks, 2006. http://www-128.ibm.com/developerworks/offers/lp/demos/summary/modelreq.html

• Mitra, Tilak. “Business-Driven Development.” IBM developerWorks, 2005. http://www-128.ibm.com/developerworks/webservices/library/ws-bdd/index.html

Related Courses• REQ370: Essentials of IBM Rational RequisitPro (ILT) or

REQ310: Essentials of IBM Rational RequisitPro (WBT)


Instructor Notes:



2

Module ObjectivesAfter completing this module you will be able to:

Perform static analysis on Java™ 2 Platform, Standard Edition (J2SE) and J2EE systems using:

Architectural DiscoveryUML Model AnalysisCode Review

Explore the architecture of a system visually using code modeling

Class and sequence diagramsTopic and browse diagrams

This module introduces the static analysis features in Rational Software Architect. Static analysis involves examining the structure and behavior of components and resources without running the application. Static analysis employs automated features in Rational Software Architect: Architectural Discovery, UML Model Analysis, and Code Review. It can also involve the use of manual techniques, including UML visualization and query diagrams.

An overview of the static analysis features is coming right up. No need to introduce them in detail here.


Instructor Notes:



3

The Challenge of Software MaintenanceEnterprise applications are too large and complex for traditional code reviewDesign and code standards are often subjective, hard to enforce across large teams

UnstableUnreliableUnpredictable

Rewrite

BusinessRequirements

BusinessRequirements

Complex

It is in the nature of software to change over many releases to keep up with evolving business needs. Cycles of change and evolution in an application, along with the usual challenges of team development, eventually result in greater size and complexity. Over time, new technologies, new components, and third-party components may be integrated; older components may be discarded, updated, or rewritten.Size and complexity in an application multiplies over time, until eventually the code becomes so difficult to understand, so full of errors, and so costly to maintain, that it would be easier simply to start over and rewrite the application.Component-based architecture and visual modeling techniques can be used todevelop a resilient and extensible software architecture. However, the added challenges of software maintenance call for automated tools and processes to enforce adherence to architectural and coding standards over the long term, even as new requirements arise and more and more developers have a hand in making the needed changes.


Instructor Notes:



4

Addressing the ChallengesThroughout development, Rational Software Architect provides key features to detect and fix potential problems

IdentifyArchitectural DiscoveryUML Model Analysis

AnalyzeArchitectural DiscoveryCode ReviewUML Visual Development

ResolveCode Review Quick FixVisual code development

Analyze

Resolve

Identify

Developing analysis and design specifications with UML in Rational Software Architect helps to abstract out key details from the evolving solution, and provide multiple perspectives on the architecture. Modeling is crucial for managing complexity and governing the development of software solutions, but at the end of the day, the goal of all these efforts is still to produce effective and efficient implementation code. Is the code flexible? Is it resilient? Can changes be quickly and easily incorporated into the solution?Along with support and automation for model-driven development, Rational Software Architect also includes important features that facilitate code-driven development. The scope of Rational Software Architect’s support for developing code includes support and automation:

• Within a code element (class, component, package)• Between code elements within a localized area of an application• Between code elements within the entire application

Rational Software Architect’s Code Review, UML Review, Architectural Discovery, and UML Visualization can assist you in determining the quality of the code within an application. It will point out occurrences where best practices have not been followed, and find structural patterns (sometimes called “anti-patterns”). Together, these features give you ways to see the “forest for the trees.”

From the perspective of static analysis, you can think about development as involving three general activities:

• Identifying abstractions: Use Architectural Discovery to understand an existing model or high level abstractions (patterns and anti-patterns) within an existing model, and UML Model Analysis to uncover problems with traceability and the violation of architectural constaints.

• Analyzing the solution: Finding anti-patterns using automatic Architectural Discovery or manual UML Visual Development (class, sequence, and Topic/Browse diagrams); checking code for problems and adherence to code best practices and standards using Code Review.

• Resolving problems: using automated Quick Fixes offered with Code Review, or code updates facilitated with visual code development.


Instructor Notes:



5

Static Analysis in Rational Software Architect Static analysis: Analyze components and resources of an application without having to run the application.

Automated static analysisArchitectural Discovery

– Explore and understand the architecture of an existing application– Find structural and design patterns

Code Review for Java– Help to find and fix problematic code– Check for adherence to design standards, coding standards, and best

practices– Create your own rules

UML Model Analysis– Discover issues with traceability relationships between model elements

Manual static analysisExplore relationships with topic and browse diagramsModel code with class and sequence diagrams

Using static analysis tools, you can analyze the components and resources of an application without having to run the application. You can perform static analysis on your own time, starting at early stages in the development cycle and continuing throughout development, so that you to correct problems that might be difficult to manage if left for the test phase.Code Review, for example, compares the source code of an application with a set of coding standards to ensure that the source code complies with those standards. This helps you find unwanted dependencies, and ensure that the intended structural design of the code is maintained. While the manual code review process can require many hours of detailed code inspection and discussion, Rational Software Architect’s Code Review features are easy to apply and customize for a new project. As a result, you can run routine code reviews during development as often as you please. For users who prefer to resolve issues manually, Rational Software Architect provides support for UML-based visual development for Java and C/C++.

IBM has donated a basic set of code review features to the Eclipse project.The Eclipse Test and Performance Tools Platform (TPTP) project provides Java code review with 71 rules, which are all open source. See http://www.eclipse.org/tptp/.RSx 7.0 adds another 214 rules to the basic set in Eclipse, and more rules are included with each new release of the product. Architectural Discovery and the rest of the static analysis tools are available only in RSx.


Instructor Notes:



6

Where Are We?Automated Static AnalysisManual Static Analysis

This section describes how to use the automated static analysis features available in Rational Software Architect.


Instructor Notes:



7

Running an Automated Analysis: Analysis Configuration

Scope of analysisProjectResource setWhole workspace

Rules or rule sets to applyArchitectural DiscoveryCode review for JavaUML Model Analysis

Create an analysis configuration with:

To begin a static analysis, you create an analysis configuration that specifies the rules and rule categories against which to analyze your resources. A static analysis code review, for example, detects violations of specific programming rules and rule categories, and then generates a report in the Analysis Results view. When you create an analysis configuration, you determine the type of analysis that you want to perform, its scope, and the particular rules to apply to your resources. You can analyze the resources in an entire workspace, in a resource working set that you define, or in a project. You can also designate the rule providers, rule categories, and rules to apply to your resources for a specific analysis configuration.

This analysis configuration dialog is new with version 7.


Instructor Notes:



8

Running an Analysis: Analysis ResultsThe Analysis Results view displays the findings of all analysis sessionsView or ignore results and make quick fixes

As an analysis configuration runs, the Analysis Results view populates a tree of findings that are grouped by the rule categories and severity levels that you define when you set up the analysis configuration. The top-level node of the tree displays details about the analysis, such as the name of the analysis configuration, the date and time that the analysis completed, and the number of results generated. When you expand the tree, each rule category and rule displays the number of results generated, and lists the resources that are associated with the rule.A result is not necessarily a problem, mistake, or bug, but you should evaluate each result in the list to determine what action, if any, you need to take. If the result is a problem that has a trivial solution, the author of the rule might have provided a quick fix that automatically corrects the resource. If a quick fix is available for a particular result, you can select it using the pop-up menu.You can view the results of an analysis in the Analysis Results view. You can filter the results to display findings that correspond to each rule in your analysis configuration, or only those results that do not conform to a particular rule. From the Analysis Results view, you can also open resources in their associated editors to correct problems or apply quick fixes, if they are available.

Note that in version 7, Architectural Discovery results appear in the Analysis Results view to unify the static analysis features. In version 6, Architectural Discovery results appeared in the Diagram Navigator view. The Diagram Navigator view has been consolidated into the Project Explorer view in version 7.


Instructor Notes:



9

Export Analysis ResultsResults of each analysis are available in the Analysis Results view until deletedResults can also be saved and exported as XML format.

The results of each review session appear in chronological order in the Analysis Results, until they are deleted. To save the results outside of the Analysis Results view, or to share or publish the results as a report, you can export the results in XML or HTML format.

This is a new feature in version 7.


Instructor Notes:



10

Architectural DiscoveryFour categories of rules:

Design PatternsDiscover familiar design patterns in the architecture

Object-Oriented PatternsFind the inheritance tree and interfaces

Structural PatternsFind structural patterns and anti-patterns in the architecture

System PatternsExplore the structure of the model

Architectural Discovery is a set of features used to visually inspect an application’s architecture, based on a variety of possible criteria:

• Design patterns: Finds elements that participate in collaborations that match the structure of common design patterns

• Object-Oriented Design patterns: Finds examples of abstraction (for example, interfaces and abstract classes) and inheritance in the application

• Structural patterns: Examines the design for structural anti-patterns• System patterns: Finds and displays all the packages in the application


Instructor Notes:



11

Structural PatternsHas a lot of immediate dependents

If changed, may affect many components

Has a lot of immediate dependencies and dependents

Has a lot of immediate dependencies

Often is affected when the system changes

Often is affected when anything is changed, and affects a lot of other components

Group of interdependent components: changes to one affects all

The structural patterns in architectural discovery are:• Cyclic Dependency (Tangle): A group of objects is so interconnected that a

change to any object could affect all of the others. Cyclic dependencies need to be broken at the weakest link(s) among them.

• Local Breakable: The class has so many dependencies that it is likely to break when another object is changed. The class should be broken into many smaller classes, to distribute dependencies and make the system more stable.

• Global Breakable: Like a local breakable, but with global dependencies. Usually occurs with the highest-level concepts in the system. Having many global breakables in your system implies high instability.

• Local Hub: The object has both many dependencies and many dependents. It is affected when another object is changed. Likewise, when it is changed, other objects are affected. Local hubs need to be refactored into several smaller classes.

• Global Hub: Like a local hub, but with global dependents and dependencies (often basic interfaces, abstract base classes, and utilities). Global hubs indicate that a system is not conceptualized well, and that it is highly unstable.

• Local Butterfly: The object has many immediate dependents. Typically, they would be basic interfaces, abstract base classes, and utilities. Local butterflies present risk. Any changes you make to one will have significant impact on its dependents.

• Global Butterfly: Like local butterflies but with global dependents.


Instructor Notes:



12

Architectural Discovery Analysis Results

Select View Result in the Analysis Results view. Navigate to the Java class from the diagram.

Architectural Discovery results are listed in the Analysis Results view as a collection of special topic diagrams grouped into collections of rules and categories. You can open the topic diagram result and then scale the diagram to view the full result structure, or focus on particular elements. Within the diagram, you can right-click and click Show in Package Explorer to navigate directly to the resource displayed in the diagram.


Instructor Notes:



13

Code ReviewCode review analyses a selected code base, based on a set of configurable rules.Add and configure Code Review settings in an Analysis Configuration.

Rules are organized into categories and category sets.Select only rules you

wish to apply during code review.New rules and

categories can be created and customized.

Code Review in Rational Software Architect is a set of rules that automates the process for a software developer or architect to analyze code for errors, optimize code based on coding best practices, and ensure that implementation code satisfies the design specification for the application.You can set Code Review options in the Code Review preferences dialog box. In it, rules are organized into categories, and the categories are gathered into various code review sets, which provide selections of rules for different types of code reviews (and are available in the Select Code Review box).The software architect can define code review rule sets to enforce project-specific coding standards and architectural constraints.

Note that you can apply whole groups of rules at once by selecting the rule category.


Instructor Notes:



14

Rule Severity LevelsCode review rules have associated severity levels.There are three levels of severity:

Every rule has one of three severity levels associated with it. When creating a new rule, you specify a severity level that appears in code review results. You can also modify the severity level assigned to rules that are shipped with Rational Software Architect.It is best not to discount the importance of recommendation-level rules. They take into account best practices and industry standards that engineering teams should adhere to. The issues they can prevent , while not a serious problem now, could lead to problems in the future with software maintenance and extensibility.


Instructor Notes:



15

Create a New Analysis RuleProcess for creating a custom rule:

Add rule category (if necessary) and new rule in Analysis preferencesSelect rule

templateSelect basic

properties:NameSeverity

You can define new code review rules in the Analysis preferences.All custom rules must be based on rule templates, which you select from the available categories in the dialog box.

• First create a new rule, and optionally a new category (the group of rules the new rule will be available in the list). You can then associate a rule or rule category with a parent category.

• Select a template upon which to base the new rule.• Assign template values and severity to the rule.

This approach to creating rules is new in version 7.


Instructor Notes:



16

Code Review Best PracticesDo:

Use existing hierarchy to group new rules in a meaningful manner.Pick appropriate level of severity for rules.Use resource filters to focus rule enforcement.Share and validate new rules with team.Document your rules.Run code review before checking in code.

Don’tCreate rules on the fly and implement them without testing or team input.Try to prevent all possible defects by making a rule for every occasion.Run rigorous tests on immature code, and tailor your reviews to the maturity of the code.Assume that because the code does not show validation errors that it actually does what it is supposed to do.

There are rules that are very useful to test in some code that are totally useless in other code. Rational Software Architect can keep a catalog of rule sets available for the developer to apply as appropriate .The results display includes the following tabs:

• Example• Explanation• Solution

Review the slide, then ask: How would you use rules?

Examples:

• To enforce object-oriented best practices, reduce coupling points between packages.

• Management of layer dependencies. For example, in the lab we have students create a rule preventing all classes from calling entity beans unless they are session beans.

• Cloning errors.

• Typographical errors.

Prompt students to come up with additional examples. Some additional examples follow in later slides.


Instructor Notes:



17

Code Review Analysis ResultsExamine and work with findings in the Code Review and Code Review Details views.Apply quick fixes.

Quick Fix Available

After running a Java code review, you can double-click items to navigate directly to the site of the issue in the code. If you hover over the problem icon in the code editor, a tool tip will appear with an explanation of the issue. Many of the simpler code review rules have quick fixes available.


Instructor Notes:



18

Applying Quick FixesReview the quick fix in contextClick Quick Fix

After learning about the problem and determining a solution, you can apply the quick fix. A quick fix is an automated solution for a common problem. You apply a quick fix to save time, and to ensure that a problem is fixed the same way for each occurrence. Applying a quick fix ensures that the underlying issue of a finding will be eliminated according to best practices guidelines.


Instructor Notes:



19

Demo: Code ReviewThe instructor will now show you how to:

Perform a code review.Examine findings.Apply a Quick Fix.

Watch your instructor perform a code review and apply a Quick Fix.

Follow the instructions for Lab 21 or have the students perform the lab along with you.


Instructor Notes:



20

Given:Existing project

Complete the following tasks:Task 1: Import Java ProjectTask 2: Create Analysis ConfigurationTask 3: Review Design PatternsTask 4: Fix Circular DependenciesTask 5: Fix J2SE Best Practices Violations

To begin the lab:

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.Click Select a Cheat Sheet from the list.Expand DEV396 Labs, then select Lab 20: Perform Static Analysis.Follow the instructions indicated in the cheat sheet.

Lab 20: Perform Static Analysis

Complete Lab 20: Static Analysis in Rational Software Architect.


Instructor Notes:



21

UML Model AnalysisUse UML Model Analysis to discover issues with traceability relationships between model elements:

No traceability path to an implementation or a specificationBroken trace relationships Circular trace relationships Implied access

violations

UML Model Analysis is used to discover issues with traceability relationships between model elements.Broken Trace RelationshipsThe target or source of a trace dependency that cannot be found or accessed generates a broken trace relationship. You can view broken element trace relationships and their causes in the Model Report view.A trace relationship is broken if the trace relationship of the client or supplier:

• Is an element from another model, but the model is not found or is not open• Is an artifact and its fileName property contains a file that does not exist• Is a visualized element that does not exist

Circular Trace RelationshipsCircular trace relationships occur when one or more model elements have abstraction dependencies on each other.Access Violations Between Model Elements With Implied DependencyRelationshipsAn implied dependency between two UML elements occurs if any of the following items is true:

• Both model elements are in the same package• Each model element is in a different package, and the source model element’s

package has a Permission, Import Package, or Import Element relationship to the target model element’s package

• Each model element is in a different package, and the source model element’s package has an Import Element or Permission relationship to the target model element

Note: If one of the above is not true, an access violation error is listed in the Problems view. A model element that accesses a model element that is in another package without a Permission, Import Package, or Import Element relationship to the target model element’s package is an access violation that might not be resolvable.


Instructor Notes:



22

UML Model Analysis ResultsUse the results in the Analysis Results view to navigate to model elements in the Project Explorer view.

UML model analysis results are displayed and managed in a way similar to Architectural Discovery results. You can right-click a finding and click View Resultto navigate directly to the issue in the model.


Instructor Notes:



23

Where Are We?Automated Static AnalysisManual Static Analysis

This section discusses how you can use tools for manual static analysis, topic and browse diagrams, and UML visualization features.


Instructor Notes:



24

Manual Static AnalysisUse visualization to explore and modify code structure, relationships, and behavior using UML

Explore, analyze, and documentTopic Diagrams

– Query the model to see a specific set of relationships between a group of elements from across the model

Browse Diagrams– Explore relationships from a selected element to other elements in a model– Generate an edit diagram

Explore, analyze, and editClass diagrams

– For visual code modeling and editingSequence diagrams

– Visually explore and edit code behavior

In UML models, you can use topic and browse diagrams to explore and navigate through a model, and to view the details of its model elements. In a topic diagram, you can query a specific topic in a model, and then you can explore the details of a selected context diagram element and its relationships in a browse diagram.Querying elements and relationships in UML modelsIn UML models, you can create a topic diagram to dynamically explore existing relationships between diagram elements by using a specific topic in the context of a diagram element. You can customize, refresh, and save a topic diagram. A topic diagram is a non-editable, query-based diagram that you can use to view existing relationships between elements. A topic diagram displays a specific set of relationships between a group of given elements. The set of relationships, or the topic, defines the parameters of the query for the diagram. Browsing elements and relationships in UML modelsIn UML models, a browse diagram is a temporary diagram in which you can explore the details of a model and its underlying elements and relationships. A browse diagram provides a view of a context element that you specify, and is similar in functionality to a Web browser. You cannot add or modify the individual diagram elements or save a browse diagram in a model. However , you can convert a browse diagram to a freeform modeling diagram in an open model EMX file, or save it in an image file that captures the inheritance hierarchy, which you can send in an e-mail message or publish on a Web site. A browse diagram is a temporary, non-editable diagram that shows the results of a query on a context diagram element. You can use browse diagrams to navigate elements and relationships in a project. For example, you can create a browse diagram to show a dynamic view of a class and its related elements to understand how it fits into the overall project structure.


Instructor Notes:



25

Exploring StructureUse browse and topic diagrams to understand the relationships and associations among Java or C/C++ classesModify the code visually using class diagrams

UML topic and browse diagrams can be used to visualize the structure of the code, as well as the relationships among classes and technology elements.Class diagrams, as you have seen, can be used to navigate and edit these structures.


Instructor Notes:



26

Static Method Analysis: Exploring BehaviorGenerate a static method sequence diagram to interpret existing code and discover problems with:

Method LengthMethod ComplexityPrivate API calls

As with drawing a sequence diagram, editing a generated sequence diagram modifies the underlying code. Sequence diagrams can either be produced as static or dynamic diagrams.To generate a sequence diagram:

1. Right-click an existing method in the Package Explorer (or other views that support method-level browsing).

2. Select Visualization > Make Sequence Diagram.3. Review and edit the generated sequence diagram.

Note: As a companion to the sequence diagram generation, if you need to find out which objects and methods call a method that has already been developed, take a look at the Call Hierarchy view.


Instructor Notes:



27

ReviewWhat three levels of severity are possible for code review rules?What are structural patterns?What resources are used to perform some kinds of static analysis manually in Rational Software Architect?

Q: What three levels of severity are possible for code review rules?

A:Problem: Finding must be addressed.Warning: Finding is likely a problem that needs to be addressed.Recommendation: Finding is not yet a problem, but it is highly recommended that you address it now.

Q: What are structural patterns?

A: Common “worst practices” in design that should be avoided because they make an application unstable or difficult to maintain.

Q: What resources are used to perform some kinds of static analysis manually in Rational Software Architect?

A: UML visualization and visual code development, query diagrams.


Instructor Notes:



28


Instructor Notes:

Module 10 - Summary 10 - 1© Copyright IBM Corp. 2007


®

IBM Software Group



Module 10: Summary

This module will require approximately 20 minutes to complete. There are no labs in this module.


Instructor Notes:



2

Software Development with Rational Software Architect

Identify

Analyze

Resolve

Design

Generate

Process Guidance

As this course has shown, Rational Software Architect provides features that support the range of activities architects, designers, and developers perform, including:

• Design: Use UML models to specify, document, and construct a solution.• Generating: Use automation to generate and construct artifacts and resources

in a software system and implement the design.• Identifying: Identify the structure and behavior of existing artifacts for reuse,

and identify areas where an implementation does not meet the design specification.

• Analyze: Ensure the highest quality and consistency of the implementation code itself.

• Resolve: Use automation to help rectify any problems and improve the implementation of the solution.


Instructor Notes:



3

Design: Models and DiagramsDevelop UML models and diagrams in Rational Software Architect to specify, document, and construct artifacts in a software system.

Model templates basedon RUP methodologymodelsUML profiles included for:

Analysis ModelingBusiness ModelingService-Oriented ArchitectureAnd more

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 the 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 UML, different members of the development team can communicate their decisions unambiguously to one another.Rational Software Architect facilitates the management of these models, letting you hide or expose details as necessary. You can develop multiple models that are tailored to the exact needs of the project, and to organizational modeling standards.


Instructor Notes:



4

Generate: Patterns and TransformationsGenerate and construct artifacts in a software system by applying:

Patterns to add details to a modelTransformations to translate elements from one model into elements in a different mode

Build your own custom patterns and transformations

Transformations

ApplyPatterns

While modeling by itself can enhance productivity by improving communication, you can realize greater benefits from modeling when you use models to derive more detailed models, code, and other development artifacts automatically. Rational Software Architect offers design patterns to speed model development, and to mark up the model with UML stereotypes from a profile recognized by a transformation. Transformations can be used to translate model elements from one model to another automatically, to speed the transition of elements from, for example, analysis to design or from design to implementation.Design PatternsDesign patterns allow you to make use of existing solutions developed in the same type of model that you are working on. So, for example, the Observer GoF pattern in Rational Software Architect contains design-level UML classes that can be applied in a design-level UML class model. Patterns have parameters so that you can customize them for a specific context, but patterns do not automatically translate themselves to work in different model types. You cannot, for example, apply a design pattern and get a code-level idiom in Java code without using transformations.TransformationsTransformations take elements from one model and translate them into elements of a different model. For example, you can apply a transformation to move from a platform-independent model to a platform-specific model as you add in details about the platform and get closer to the implementation. When adding levels of refinement, you can transform from a platform-specific model to another, adding more details without changing the model type. Transformations are often applied to whole models, but they can be applied to selections from models as well.


Instructor Notes:



5

Identify: Visualization and Structural ReviewExplore models and code using visualization and architectural discovery

Visualize the architectureUML Visual Development

– Class and Sequence diagrams show structure and behavior

Topic and Browse diagrams– Explore relationships

between model elementsArchitectural Discovery

– Visually inspect critical portions of the architecture to keep them up to date with the code

– Discover important design patterns in the architecture

Architectural Discovery

UML VisualizationCode

Topic and Browse Diagrams UML Models

The following features are used in the task of identifying structures in an existing system, either to better understand the system, or how its implementation compares with its original design specification.

• Architectural Discovery is a set of features used to visually inspect an application’s architecture in order to discover design patterns, object-oriented design patterns, structural patterns, and system patterns.

• Topic and Browse diagrams provide a way to study the relationships between small sets of model and code elements.

• UML Visual Development allows you to study the structure and behavior of sets of code elements. These diagrams can be saved for documentation, used to modify or construct code-level elements, or harvested back into a model.


Instructor Notes:



6

Analyze: Code ReviewUse the results of Architectural Discovery, UML visualization, and Code Review to resolve problems in a selected code base.

Code review addresses problems such as:Design PrinciplesGlobalizationJ2EE Best PracticesJ2EE SecurityJ2SE Best PracticesNamingPerformancePrivate API

Use Architectural Discovery to findstructuralanti-patterns

Code review in Rational Software Architect offers a set of rules that automates the process for a software developer or architect to analyze code for errors, optimize code based on coding best practices, and ensure that implementation code satisfies the design specification for the application.The software architect can also define code review rule sets to enforce project-specific coding standards.


Instructor Notes:



7

Resolve: Reconcile and RefactorReconcile and synchronize higher-level models with lower-level models with traceability and reverse transformationsRefactoring helps make model and system-wide changesApplying quick fixes and improving adherence to code rules and best practices improves code quality

ReconciliationReverse Transformations

Trail of «derive»relationships leftby transformations.

Rational Software Architect offers a range of features for resolving issues in an evolving solution. Transformations can be reversed to synchronize model and code to bring all artifacts in line. Code review offers quick fixes to problems identified in a review. Refactoring allows for change to occur in a controlled way, to avoid introducing problems and errors.


Instructor Notes:



8

Process: Rational Unified Process (RUP) MethodologyRUP methodology process guidance is built in to Rational Software Architect:

Process AdvisorProcess Browser

RUP is:Rooted in philosophies and practices for

successful software developmentA process model and

customizable content libraryA process definition

language

The Rational Unified Process® (RUP®) methodology is a software engineering process and an industry-wide platform for best practices. There is a RUP configuration especially for Rational Software Architect users, which is accessible inside the tool in two ways:

• Process Advisor view: The Process Advisor view presents context-sensitive references to Rational Unified Process Tool Mentors, Artifacts, and Activities. From this view you can also search the RUP product and access Help.

• Process Browser: The Process Browser in Rational Software Architect is a separate window that opens to display the RUP methodology content selected in the Process Advisor view. It also allows you to browse the RUP product.


Instructor Notes:



9

Further Information Web ResourcesArticlesRedbooks

Web Resources• IBM. “Rational Software Architect.” IBM developerWorks. http://www-

128.ibm.com/developerworks/rational/products/rsa/ (Accessed 19 January 2007).

• IBM. “Pattern Solutions.” IBM developerWorks. http://www-128.ibm.com/developerworks/rational/products/patternsolutions/ (Accessed 19 January 2007).

Articles• Lloyd, Aaron. “What's new in IBM Rational Software Architect V7.0” IBM

developerWorks, 2006. http://www-128.ibm.com/developerworks/rational/library/06/1205_lloyd_rsa/

Redbooks• Swithinbank, Peter et al. Patterns: Model-Driven Development Using IBM

Rational Software Architect. IBM Redbooks, 2005 (SG24710500)http://www.redbooks.ibm.com/abstracts/sg247105.html

• ---. Build a Business Process Solution Using Rational and WebSphere Tools. IBM Redbooks, 2006 (SG24663600).http://www.redbooks.ibm.com/abstracts/sg246636.html

• Wahli, Ueli et al. Building SOA Solutions Using the Rational SDP. IBM Redbooks, 2006 (SG24735600 ). http://www.redbooks.ibm.com/redpieces/abstracts/sg247356.html


Instructor Notes:



10