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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Table of Contents
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
ii
Table of Contents
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
iii
Essentials of IBM Rational Software Architect

Instructor Notes:
This module will require approximately 30 minutes to complete:
IBM Software Group
DEV396: Essentials of IBM Rational Software Architect, V7

Module 0: About This Course
2007 IBM Corporation
Copyright IBM Corp. 2007
Module 0 - About This Course
0-1
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Instructor Notes:
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.
2
Introductions
Your organization Your role Your background and experience
Software development experience Object technology experience
Course expectations
0-2

Instructor Notes:
The intended audience is the architect and lead developer who designs enterprise applications using model-driven methods.
Intended Audience
The intended audience for this course is software developers who architect and develop enterprise applications, and who:
Use the Unified Modeling Language (UML) for objectoriented 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 modeldriven development, apply patterns and perform model transformations, and develop software with Software Architect as part of a development team.
0-3

Instructor Notes:
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.
Prerequisites
This 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 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.
0-4

Instructor Notes:
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.
Course Goals and Objectives

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

Instructor Notes:
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.
Course Agenda
Day 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
6
0-6

Instructor Notes:
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)
Logistics
Morning 2 15-minute breaks Lunch 1 Hour Afternoon 2 15-minute breaks
0-7

Instructor Notes:
0-8
Essentials of IBM Rational Software Architect, V7

Instructor Notes:
This module will require approximately one hour to complete. The labs will each take 15 minutes.
IBM Software Group
DEV396: Essentials of Rational Software Architect, V7

Module 1: Getting Started with Rational Software Architect
Module 1 - Getting Started with Rational Software Architect
1-1

Instructor Notes:
Module Objectives
After 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
2
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.
1-2

Instructor Notes:
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.
3
Discussion
How much experience do you have with Eclipse or Eclipse-based products?
If some or none of the students are familiar with Eclipse, it is recommended that you cover all of the material in this module.
1-3

Instructor Notes:
Where Are We?

The IBM Rational Software Delivery Platform Basic User Interface Projects and Tasks More on Navigation What is Rational Software Architect?
1-4

Instructor Notes:
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.
1-5

Instructor Notes:
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.
1-6

Instructor Notes:
Where Are We?

1-7

Instructor Notes:
The Workspace
When 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 subdirectories, 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.
1-8

Instructor Notes:
Note that the Whats New function is only available from the Welcome View.
Basic User Interface: The Welcome View

After the workspace dialog, the Welcome view will be the first thing you see.
Overview
Get an overview of the features
First Steps
Make first steps
Workbench Whats New

Find out what is new Go to the workbench
Web Resources
Read more on the web
Samples
Try out the samples
Migrate
Migrate to the new release
The Welcome View
Tutorials
Go through tutorials
Note: You can get the Welcome view back at any time by selecting Help > Welcome.
9
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.
1-9

Instructor Notes:
Basic User Interface: The Workbench

The 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.
The Workbench
10
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.
1 - 10

Instructor Notes:
Perspectives
A 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 Java For working with Java projects CVS Repository Exploring For checking projects in and out securely
Java Browsing For browsing the structure of Java projects Debug For debugging a program Plug-In Development For developing Eclipse plug-ins
11
Tip: The Window > Preferences > General > Perspectives allows you to specify general perspective behavior.
1 - 11

Instructor Notes:
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 or view that is active is the one whose title bar is highlighted. Here, the Navigator view is active.
An editor is used to edit or browse a resource.
12
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.
1 - 12

Instructor Notes:
Editors
Editors 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.
13
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.
1 - 13

Instructor Notes:
More on Perspectives
You 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.
14
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.
1 - 14

Instructor Notes:
Managing Views
Each perspective has a number of associated views that can be resized, dragged, or stacked. A view is either:
Stacked: There are multiple views available by clicking on a tab at the top of the view pane Single: There are no other views at that position in the perspective
You can position views within the perspective by dragging and dropping, or by using the view menus:
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.
15
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.
1 - 15

Instructor Notes:
Tailoring Perspectives
One way to tailor a perspective is by adding and deleting views.
To add a view that is not included in the current perspective, select Window > Show View from the main menu bar.
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.
16
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 > Capabilities preference 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.
1 - 16

Instructor Notes:
Where Are We?

17
1 - 17

Instructor Notes:
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.
18
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.
1 - 18

Instructor Notes:
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.
19
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.
1 - 19

Instructor Notes:
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.
20
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.
1 - 20

Instructor Notes:
Preferences
The 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 can be accessed from the main menu bar by selecting Window > Preferences.
21
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.
1 - 21

Instructor Notes:
Tasks
You 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.
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.
In the editor view, tasks are shown on the editor marker bar as a clipboard with a checkmark.
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.
22
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.
1 - 22

Instructor Notes:
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.
Lab 01: Creating a Project

The instructor will walk through this lab together with the class in order to demonstrate cheat sheet navigation. 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.
23
1 - 23

Instructor Notes:
Where Are We?

24
1 - 24

Instructor Notes:
Running Multiple Windows

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

Instructor Notes:
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.
26
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.
1 - 26

Instructor Notes:
Builders
A 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 Program and click OK.
27
The pages on defining a builder are similar to those used when defining an External Tool, with the exception of the Build Options page.
1 - 27

Instructor Notes:
Help
There are extensive Help resources that include:
Help Contents Tips and Tricks Cheat Sheets Dynamic Help
28
You can access the Help system by selecting Help from the menu bar.
1 - 28

Instructor Notes:
Cheat Sheets
The 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 done Not having to retype content Allowing 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
29
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.
1 - 29

Instructor Notes:
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. Some different kinds of tasks:
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.
Important Note: Students much check off each step in order to move on to the next one.
A choice represents a set of tasks, only one of which should be performed.
If a task is optional it can be skipped
30
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.
1 - 30

Instructor Notes:
Lab 02: Customizing Perspectives

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

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 02 Customize Perspectives. Follow the directions indicated on the Cheat Sheet.
31
1 - 31

Instructor Notes:
Where Are We?

32
1 - 32

Instructor Notes:
Rational Software Architect: For Architects and Developers

For software architects who need to: Model applications Enforce architectural and coding standards Develop and apply patterns and transformations For software developers who need to: Develop using models and code Review code against coding standards Apply patterns and transformations For all who develop as part of a team
33
Software architects and senior developers within a development team are responsible for specifying and maintaining all aspects of an applications software architecture. They need powerful and configurable tools to manage the complexity found in todays applications. Rational Software Architect is a UML model-driven design and development tool for creating well-architected applications and services.
1 - 33

Instructor Notes:
The transformation trail is a traceability link between the transformation source and its target, which can be followed using a model query.
Traceability relationships created as a byproduct of patterns and transformations
Model-Driven Development in Rational Software Architect

Create the domain model
Transformation
Create the use-case model

Transformation
Create the design model

Transformation
Complete the implementation using UML visualization

34
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 platformindependent 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 Designers As 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.
1 - 34

Instructor Notes:
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
35
Review
The 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?
1 - 35

Instructor Notes:
36
1 - 36

Instructor Notes:
This module will require approximately 1 hour to complete. There are no labs in this module.
IBM Software Group

Module 2: Model Structure and Templates
Module 2 - Model Structure and Templates
2-1

Instructor Notes:
Module Objectives
Locate and use the Modeling perspective and views Create and organize projects and models in Rational Software Architect Create Models based on Model templates
2-2

Instructor Notes:
Where Are We?

Introduction to Models Modeling perspective and views Creating and organizing projects and models
2-3

Instructor Notes:
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 model Code Data 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.
2-4

Instructor Notes:
Difference Between Model and Diagram

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.
Diagrams provide a means of visualizing and manipulating the model elements.
2-5

Instructor Notes:
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.
What is a UML Model in Rational Software Architect?

A UML model is only one type of model, which is used for:
Specifying structure, behavior, or both Visualizing an existing system to improve understanding Automating system development (Model-Driven Development)
UML Models in Rational Software Architect:

A resource (.emx) Logical model, the contents of a model file
Closed model Physical File OpenModel model (Logical) 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 systems 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 Extension UML Model .emx UML Model Fragment .efx UML Profile .epx Class Diagram .dnx Topic Diagram .tpx Object Constraint Language (OCL) resource .ocl Transformation Configuration .tc Reusable Asset .ras RAS Manifest .rmd
2-6

Instructor Notes:
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.
ITERATE
Code-based Development
7
Models at Different Levels of Abstraction

Computational Independent Model
Business Use-Cases Business Analysis Business Process Models
Application Use-Cases
PlatformIndependent Model
Application Analysis
Application Design (high abstraction)
Platform-specific model markup

PlatformSpecific Model
Implementation
Model-Driven Architecture
RUP Methodology
2-7

Instructor Notes:
Where Are We?

Introduction to Models Modeling Perspective and Views Creating and Organizing Projects and Models
2-8

Instructor Notes:
Note: the diagram editor is covered in detail later. The palette is part of the diagram editor and not a separate view.
The Modeling Perspective

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

Instructor Notes:
Views in the Modeling Perspective

Views in the Modeling Perspective:
For exploring modeling projects:
Project Explorer view
Diagrams Models
For exploring resources:

Pattern Explorer view Outline view Inheritance Explorer view Properties view
For getting feedback:

Tasks view Output window
10
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.
2 - 10

Instructor Notes:
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.
Project Explorer View

Used for navigating and organizing models.
Diagram Closed Model Open Model Package Class Relationship Diagram
Attribute
11
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.
2 - 11

Instructor Notes:
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).
12
Properties View
Displays properties and values for the selected element.
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.
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 for searches, visibility, and an option to make the element abstract. Documentation: Used for adding documentation to model elements. Advanced: Displays an Eclipse-style properties page.
2 - 12

Instructor Notes:
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.
Diagram Editor
Drawing Surface
Palette
Drawers
Tools
13
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.
2 - 13

Instructor Notes:
Outline View
When the diagram editor is open, the Outline view can show either:
A thumbnail graphical view of the diagram A tree view listing the elements of the diagram
14
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 (upperright 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.
2 - 14

Instructor Notes:
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.
UML Model Editor
15
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 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 Referenced Models: Shows the models that the open model references. A referenced model contains model information from a referenced component or project.
Details
References
Fragments: Lists fragments of this model
2 - 15

Instructor Notes:
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.
Rational Unified Process Resources

Process guidance is built in the:
Rational Software Architect Process Advisor feature Rational Software Architect Process Browser feature
These resources can guide you in determining what models and diagrams you need.
16
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.
2 - 16

Instructor Notes:
Where Are We?

Introduction to Models Modeling Perspective and Views Creating and Organizing Projects and Models
17
2 - 17

Instructor Notes:
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.
Rational Software Architect Project Types

There are two basic types of projects.
UML projects:
For pre-implementation models Blank or based on a model template UML Project
Implementation projects:
Java, EJB (Enterprise JavaBeans) technology , and so on Implementation projects can contain UML class and sequence diagrams
Java Project
Simple Project
Simple projects can be of either type.
New Project wizard
18
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 codes structure and runtime behavior. A Simple project is an empty project folder, which you can populate with any 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 and static 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).
2 - 18

Instructor Notes:
Model types are mostly selfexplanatory. 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.
Model Templates in Rational Software Architect

UML Project templates are available in the New Project wizard. The following model templates are available:
Analysis Model Blank Model CORBA Template Model DoDAF Model Enterprise IT Design Model Service Design Model Use Case Model XSD Model
19
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.
2 - 19

Instructor Notes:
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.
UML Profiles
UML profiles are often included with module templates Profiles 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 element Tagged values: To add properties that are not supported by the base element Constraints: Constraints enforced on the element or its attributes
20
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 element to 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 elements 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.
2 - 20

Instructor Notes:
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.
How Are Profiles Used?

Profiles are used to model platformor model-specific abstractions, for example:
Enterprise beans Analysis classes
Model Template
Profile added to the template and models created from it. Elements in the model can have stereotypes from the profile, with constraints ensuring correct usage.
Profiles provide a domain-specific language for reusable assets:

Add to model templates Use with domain-specific patterns Use a transformation to create a platform-specific model
Profile
Patterns
May include parameters with stereotypes from the profile. Patterns can be used to add stereotypes to model elements.
Custom profiles can be created in Rational Software Architect and shared with other users
Transformations
Designed to recognize and transform elements with stereotypes from the profile.
21
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.
2 - 21

Instructor Notes:
Populate a Model With Reusable Building Blocks

Create 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

22
Every template contains a modelLibrary package called TemplateName Building 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.
2 - 22

Instructor Notes:
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.
Model Templates: Use-Case Model

A use-case model is a model of the systems intended functions, and of its environment.
Perspective
Has overview diagrams and a package with actors
Use Case
Unit of externally visible functionality
Activity
For gathering activity diagrams for the use case (optional)
Versatile Actors
Actors that participate in multiple functional areas of the application
23
The use-case model is a model of the system's intended functions and its environment. 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.
2 - 23

Instructor Notes:
Model Templates: Analysis Model

An analysis model describes the realization of use cases to analysis classes.
Provides an abstraction of the design model
Boundary Class Controller Class Entity Class
Use-Case Realization
24
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 usecase 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 system Controller Class: Provides the coordinating behavior in the system Entity Class: Reused in many use cases, often with persistent characteristics Use-Case Realization: Shows how a use case is implemented in terms of collaborating objects
2 - 24

Instructor Notes:
Use-case realizations are covered in more detail later.
Model Structure: Enterprise IT Design Model

A design model describes the realization of use cases to design classes.
Provides an abstraction of the implementation of the system
Viewpoints Architectural Layers Use-Case Realization
25
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 codegenerating 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.
2 - 25

Instructor Notes:
Model Template: Service Design Model

A Service Design Model is used to conceive and document the design of the software services.
serviceConsumer serviceProvider serviceSpecification
Message Service
26
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.
2 - 26

Instructor Notes:
Demonstration: Model Structure and Building Blocks

The instructor will now show you how to:
1. 2. 3. 4. Switch to the modeling perspective. Create a UML Project. Add a Model to the Project (using a template). Use Building Blocks to structure a model.
Depending on your instructor, you may follow the same steps on your computer.
27
Watch your instructor create a model with building blocks.
2 - 27

Instructor Notes:
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.
Review
1. 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?
28
2 - 28

Instructor Notes:
Further Information
Web resources Articles
29
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://www128.ibm.com/developerworks/rational/ library/04/r-3155/>
2 - 29

Instructor Notes:
30
2 - 30

Instructor Notes:
This module will require approximately 2 hours to complete: Lecture: 50 minutes. Lab 3: 30 minutes Lab 4: 30 minutes
IBM Software Group

Module 3: Creating UML Diagrams
Module 3 - Creating UML Diagrams
3-1

Instructor Notes:
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.
Module Objectives
After completing this module, you will be able to: Create UML Diagrams
Diagrams in UML models Query diagrams Visual development diagrams
Describe how UML elements can be added to diagrams using:

Action Bars Tool palette Project Explorer view
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.
3-2

Instructor Notes:
Where Are We?

UML Diagrams Creating UML Model Diagrams UML Visual Development Query Diagrams
This section explains how UML diagrams are used in modeling and describes the range of UML diagrams available in Rational Software Architect.
3-3

Instructor Notes:
Be sure to mention that in Rational Software Architect V7, you can open diagrams either from the Models package 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.
UML Diagrams in Rational Software Architect

A model element appears in zero or more diagrams
Diagrams graphically depict a view of a part of your model or code Different 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.
3-4

Instructor Notes:
Someone may ask whether the use-case diagram is a structural rather than a behavioral diagram. They are listed and described in the OMGs UML spec as behavioral diagrams. Use cases are units of behavior.
UML Diagrams in Rational Software Architect

Structural Diagrams
Use-Case Diagrams Sequence Diagrams Class Diagrams Object Diagrams
Communication Diagrams
Model
Component Diagrams
State Machine Diagrams
Composite Structure Diagrams Activity Diagrams

5
Behavioral Diagrams
Deployment Diagrams
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 Diagrams 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 Behavioral Diagrams Rational 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
3-5

Instructor Notes:
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 perspectives No 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 diagram Each diagram provides a different perspective
6
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 wrong diagrams are presented, or when disorganized diagrams are crowded with details.
3-6

Instructor Notes:
Where Are We?

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

Instructor Notes:
Creating UML Model Diagrams

Use diagrams to represent different views of the system or application:
UML diagrams Non-UML (freeform) diagrams
Create diagrams in:

Models Model elements
Packages Components Active classes And 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.
3-8

Instructor Notes:
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.
Review: Diagram Editor

Drawing Surface
Palette
Drawers
Tools
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.
3-9

Instructor Notes:
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.
Adding Model Elements to a Diagram

1
Drag an existing element from the Project Explorer view.
Click a tool in the diagram editors 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).
10
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 rightclicking the diagram surface and then clicking Add UML and selecting the appropriate shape.
3 - 10

Instructor Notes:
Deleting from the Diagram and the Model

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

Remove the item from the diagram and the model
Deleting an Element in the Diagram Editor

11
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.
3 - 11

Instructor Notes:
Diagram Validation: Validating Model Semantics

Examine a model or diagram for broken semantic rules according to the model's language and constraints:
Confirm adherence to UML requirements, logic, structures, and usage Click Run Validation on the Modeling menu to validate all open models
12
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 crossmodel 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.
3 - 12

Instructor Notes:
Use the instructions for Lab 3 as a guide for performing this demo.
Demonstration: Create a UML Diagram

The instructor will now show you how to:
Create a new diagram Add shapes using the Project Explorer view Add shapes and connectors using the:
Action bar Tool palette
Delete from the diagram and the model Validate the model
13
The instructor will show you how to create a UML diagram.
3 - 13

Instructor Notes:
Lab 03: Create UML Diagrams

Complete the following tasks:
Task 1: Create a new diagram Task 2: Add shapes and connectors Task 3: Delete from the diagram and the model Task 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.
14
Complete Lab 3: Create UML Diagrams in Rational Software Architect.
3 - 14

Instructor Notes:
Where Are We?

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

Instructor Notes:
UML Visual Development Visualize Java and C++ code in UML diagrams Visualize code with diagrams that are either:
Project resources
Class (.dnx) Sequence (.tpx)
New diagrams in an existing model (.emx)

Class Sequence Freeform Topic
16
You can use UML diagrams to visually represent and develop artifacts of Java and C++ applications in a single, tightly integrated development environment You can use UML diagrams to represent and analyze an existing system to identify the systems components and interrelationships, and to create representations of the system in another form. You can use UML diagrams to automatically abstract the systems 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.
3 - 16

Instructor Notes:
Class Diagrams
Add 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.
17
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.
3 - 17

Instructor Notes:
Sequence Diagrams
Use sequence diagrams to understand and develop behaviors and interactions among source elements.
Visualize behavior or add and edit lifelines, messages, and combined fragments
18
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.
3 - 18

Instructor Notes:
Where Are We?

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

Instructor Notes:
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.
Query Diagrams: Topic and Browse

Use 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 a group of elements from across the model or code Capture a snapshot of the current state of a model or code Create an edit diagram based on the topic diagram
With Browse diagrams, you can:

Explore relationships from a selected element to other elements Navigate the model or code Generate an edit diagram from a browse diagram
20
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.
3 - 20

Instructor Notes:
Using Topic Diagrams

Create Topic diagrams to depict key model elements and their relationships. Topic diagrams are:
Created by querying the model or code Persisted in the model Dynamically updated Most useful for visualizing code Used in architectural discovery
21
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.
3 - 21

Instructor Notes:
Browse Diagrams
Browse diagrams can be used to:
Show the elements related to the selected element Show the dependencies to the selected element Gain 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.
Double-click an element in the diagram to make it the focus of a new browse diagram.
Right-click the diagram surface and click File > Save As to save the diagram as an edit diagram or image file.
22
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.
3 - 22

Instructor Notes:
Lab 04: Create Browse and Topic Diagrams

Task 1: Import Java project Task 2: Visualize Java code in a Browse Diagram view Task 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.
23
Complete Lab 4: Browse and Topic Diagrams in Rational Software Architect.
3 - 23

Instructor Notes:
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 between a topic diagram and a class diagram (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.
Review What is the difference between a topic diagram and browse diagram in Rational Software Architect? What is the difference between a topic diagram and a class diagram (project resource)?
24
3 - 24

Instructor Notes:
This module will require approximately 1 hour, 45 minutes to complete: Lecture: 45 minutes Labs: 1 hour
IBM Software Group

Module 4: Creating UML Diagrams of System Structure
Module 4 - Creating UML Diagrams of System Structure
4-1

Instructor Notes:
Module Objectives
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.
4-2

Instructor Notes:
Structural UML Diagrams

Structural Diagrams
Model
Component Diagrams

3
Behavioral Diagrams
Deployment Diagrams
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
4-3

Instructor Notes:
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.
Discussion
Which structural UML diagrams do you have experience modeling?
4-4

Instructor Notes:
Where Are We?

Class Diagrams Object Diagrams Composite Structure Diagrams Component Diagrams Deployment Diagrams
4-5

Instructor Notes:
Class Diagrams
Class 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
4-6

Instructor Notes:
Class Icon
Class Name Template Class Parameter
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
4-7

Instructor Notes:
Other Class Diagram Model Elements

Signal A signal is a specification of a send request instance communicated between objects Enumeration A data type whose literal values are enumerated in the enumeration Data Type Typically 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 Collaboration Type 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.
4-8

Instructor Notes:
Class Relationships
Class diagrams may contain the following relationships:
Association Aggregation Composition Generalization Dependency Realizes

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

Instructor Notes:
Association
OR
Specifies peer-to-peer relationships between model elements Navigability can be unidirectional or bidirectional
10
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.
4 - 10

Instructor Notes:
Aggregation
OR
Used to model a whole to part relationship between model elements The part element can exist without the whole Navigability can be unidirectional or bidirectional
11
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).
4 - 11

Instructor Notes:
Composition
OR
Aggregation with strong ownership When the container is destroyed, all of its composite objects are destroyed Navigability can be unidirectional or bidirectional
12
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.
4 - 12

Instructor Notes:
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.
Generalization
A 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
13
4 - 13

Instructor Notes:
Dependency
A 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
14
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
4 - 14

Instructor Notes:
The Draw operation of the Shape interface is set to abstract (identified by the italicized font).
Realization
A specialized relationship where the client implements the suppliers specification
15
4 - 15

Instructor Notes:
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.
Lab 05: Create a Class Diagram

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

Review Class Diagram Basics Create a New Class Diagram Challenge 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 05 Create Class Diagrams. Follow the directions indicated on the Cheat Sheet.
16
Complete Lab 05: Create a Class Diagram in Rational Software Architect.
4 - 16

Instructor Notes:
Where Are We?

17
4 - 17

Instructor Notes:
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
Object Diagrams
An 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 Name
Object
Link
Attribute Values
18
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.
4 - 18

Instructor Notes:
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.
More on Object Diagrams

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

Instructor Notes:
Where Are We?

20
4 - 20

Instructor Notes:
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.
Example: Composite Structure Diagram

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

Instructor Notes:
Defining Internal Structure

Some 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.
22
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.
4 - 22

Instructor Notes:
Structured Class Uses

Depends on the semantic level of abstraction Top Level Define the systems layers
Block Level
Define subsystems
Mid Level Low Level
Define message routing infrastructure and control object instantiation Define leaf-level classes that perform productive work
23
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.
4 - 23

Instructor Notes:
An interface is a behavioral Specification, a contract to be fulfilled. A port is a structural feature, mediating communication between the structured class and the world external to it. Ports and interfaces can exist independently from each other.
Ports
A port is a structural feature that encapsulates the interaction between the contents of a class and its environment.
Port behavior is specified by its provided and required interfaces.
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.
24
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.
4 - 24

Instructor Notes:
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).
Port Notation
A 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
Provided Interfaces
Required Interfaces
Mixed Interfaces
25
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.
4 - 25

Instructor Notes:
Connector
A 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.
26
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.
4 - 26

Instructor Notes:
Example: Decomposed Composite Structure Diagram
27
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.
4 - 27

Instructor Notes:
UML Collaboration Element

A 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.
28
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 or roles 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).
4 - 28

Instructor Notes:
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.
Example: Collaboration
Collaboration Collaboration Name
Connector
Role
Role Name
29
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.
4 - 29

Instructor Notes:
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.
Binding
Example: Collaboration Use
Collaboration Use Name : Collaboration Name
Role Name
30
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.
4 - 30

Instructor Notes:
Lab 06: Create Composite Structure Diagrams

Review Composite Structure Diagram Basics Create a New Composite Structure Diagram Challenge 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 Diagrams Follow the directions indicated on the Cheat Sheet.
31
Complete Lab 06: Create Composite Structure Diagrams in Rational Software Architect.
4 - 31

Instructor Notes:
Where Are We?

32
4 - 32

Instructor Notes:
Explain the concept of a component to the students. Remind students that the component notation is backwards compatible.
A Component
A 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.
33
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 systemlevel development, such as compilation and versioning.
4 - 33

Instructor Notes:
Lab 07: Create Component Diagrams

Review Component Diagram Basics Create a New Component Diagram Challenge 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 Diagrams Follow the directions indicated on the Cheat Sheet.
34
Complete Lab 07: Create Component Diagrams in Rational Software Architect.
4 - 34

Instructor Notes:
Where Are We?

35
4 - 35

Instructor Notes:
Deployment has been repositioned in UML 2.0 to apply to artifacts, not model elements.
Deployment Diagrams
Deployment is assigning, or mapping, software artifacts to physical nodes during execution.
Artifacts are the entities that are deployed onto physical nodes Processes are assigned to computers
Artifacts model physical entities.

Files, executables, database tables, web pages, and so on
Nodes model computational resources.

Computers, storage units
36
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.
4 - 36

Instructor Notes:
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.
Node
Represents 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
37
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.
4 - 37

Instructor Notes:
Lab 08: Create Deployments Diagrams

Review Deployment Diagram Basics Create a New Deployment Diagram Challenge 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 Diagrams Follow the directions indicated on the Cheat Sheet.
38
Complete Lab 08: Create Deployment Diagrams in Rational Software Architect.
4 - 38

Instructor Notes:
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?
39
Review
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? 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?
A: Collaboration
4 - 39

Instructor Notes:
Further Information
Books Web resources
40
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/
4 - 40

Instructor Notes:
This module will require approximately 2 hours to complete: Lecture: 1 hour Labs: 1 hour (15 minutes each)
IBM Software Group

Module 5: Creating UML Diagrams of System Behavior
Module 5 - Behavioral Diagrams
5-1

Instructor Notes:
Module Objectives
Identify the behavioral UML diagrams available in Rational Software Architect Identify UML notation and provide a basic explanation of UML semantics Create 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.
5-2

Instructor Notes:
Behavioral Diagrams in Rational Software Architect

Structural Diagrams
Model
Component Diagrams

3
Behavioral Diagrams
Deployment Diagrams
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
5-3

Instructor Notes:
Where Are We?

Use-Case Diagrams Activity Diagrams Interaction Diagrams State Machine Diagrams
5-4

Instructor Notes:
Use Case Diagrams

Use 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.
5-5

Instructor Notes:
Mention the possible relationships that appear in a use-case diagram.
Use Case
Units of system behavior
Use-Case Diagram Elements
Actor
Someone or something that interacts with the system
6
The use-case model contains the following elements, which are displayed in a usecase 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.
5-6

Instructor Notes:
Lab 9: Create Use-Case Diagrams

Given:
Create Use-Case Diagrams cheat sheet

Review the basics of use-case diagrams Create a new use-case diagram Re-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 Diagrams Follow the directions indicated on the Cheat Sheet.
5-7

Instructor Notes:
Where Are We?

5-8

Instructor Notes:
Activity
Activity 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 lowerlevel 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.
5-9

Instructor Notes:
Activity Diagrams
10
Activity diagrams are particularly useful in describing workflow, and a use cases 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.
5 - 10

Instructor Notes:
Action
An action is a fundamental unit of executable functionality It represents some transformation or processing in the modeled system
An action is a UML Element that you put INTO activity diagrams An action represents behavior that you do NOT want to model in more detail it is fundamental or atomic
11
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.
5 - 11

Instructor Notes:
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.
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 action Double-click a call behavior action to open the linked activitys diagram
12
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.9 CallBehaviorAction 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.
5 - 12

Instructor Notes:
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.
A Call Operation Action

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

Instructor Notes:
Accept Event and Send Signal Actions

Accept event
An action waiting for an event Actions that may be used by themselves, or may be paired with send signal actions
Send signal
An action that creates a signal instance and transmits it to the target object, where it may cause an activity to execute
14
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.
5 - 14

Instructor Notes:
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.
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
15
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.
5 - 15

Instructor Notes:
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.
Partitions
16
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.
5 - 16

Instructor Notes:
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 flows Properties > General tab. The guard condition will be displayed enclosed in square brackets, for example [Yes] and [No].
Control Flow
Control flow:
Is the set of lines connecting the activities and actions (activity nodes) Represents the flow of control from one node to another Can have guard conditions
Control Flow
17
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].
5 - 17

Instructor Notes:
Control Nodes
Control nodes coordinate the flow in an activity
Initial
Fork/Join
Flow Final
Decision/Merge
18
Activity End
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.
5 - 18

Instructor Notes:
Object Flow
Object flow models the data flow within an activity Object flow can only be attached to object nodes Object nodes and object flow provide the capabilities for explicit data flow modeling
19
Official definition: an activity edge that can have objects or data passing along it.
5 - 19

Instructor Notes:
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 behavior An object node is an abstract class, and is specialized by the following object nodes:
Pins Activity parameter nodes Central buffer Data stores
20
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.
5 - 20

Instructor Notes:
Pins
Pins are either input pins or output pins. Pins model where actions and activities are sending and receiving data
Activity Parameter Nodes

Represent the data parameters coming into or going out of an activity Can send and receive May have an associated data type (such as a class or interface)
21
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 Type field in the pins Property page and select the data type.
5 - 21

Instructor Notes:
Central buffer node
An object node for managing flows from multiple sources and destinations
Data store node

Used to model persistent data, such as saving information to a database or retrieving information from a database
22
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.
5 - 22

Instructor Notes:
Putting Data Flow Together

UML2 lets you model both control and data flow:
Object flows only connect object nodes. They cannot be directly connected to activities or actions.
23
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 SaveOrder activity (which receives it with an InputPin). Finally, the SaveOrder activity sends the Order to the database via the Order Database data store node.
5 - 23

Instructor Notes:
Lab 10: Create Activity Diagrams

Given:
Create Activity Diagrams cheat sheet

Review the basics of activity diagrams Create a new activity diagram Re-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 Diagrams Follow the directions indicated on the Cheat Sheet.
24
5 - 24

Instructor Notes:
Where Are We?

25
5 - 25

Instructor Notes:
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.
Interaction Diagrams (1 of 2)
Interaction diagrams show how objects interact, and the order of their interactions There are several types of interaction diagrams that emphasize object interactions, including the messages that may be dispatched among them:
Sequence diagram Communication diagram Interaction overview diagram
26
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.
5 - 26

Instructor Notes:
The interaction overview diagram is a variety of an activity diagram incorporating sequence diagram fragments in place of actions and activities.
Interaction Diagrams (2 of 2)
Sequence diagram
Time-oriented view of interactions
comm sd
Communication diagram
Structural view of messaging roles or parts
Interaction overview diagram

High-level view of interaction sets combined with logic
27
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.
5 - 27

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.
Sequence Diagrams Versus Communication Diagrams

Sequence Diagrams
Show the explicit sequence of messages Better for visualizing overall flow Better for real-time specifications Better for complex scenarios
Show relationships in addition to interactions Better for visualizing patterns of collaboration Better for visualizing all of the effects on a given role or part Easier to use for brainstorming sessions
28
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 realtime 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.
5 - 28

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.
The Anatomy of Sequence Diagrams

Lifeline Message Role Reflexive Message
Event Occurrence
Execution Occurrence
29
Hierarchical Message Numbering
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.
5 - 29

Instructor Notes:
The messages shown here are asynchronous (identified by their open arrow head). An interaction use is a type of interaction fragment.
Example: Sequence Diagram
30
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.
5 - 30

Instructor Notes:
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.
Combined Fragments
Combined fragments represent a grouping of behavior shown as a nested region within a sequence diagram:
Define conditional structures in interactions Describe several traces in a compact and concise manner
Interaction Operator
Combined Fragment
Guard Expression
Interaction Operand
Combined Fragment
31
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.
5 - 31

Instructor Notes:
The most common types of interaction operators are alternative, loop, and optional.
An Interaction Operator
An interaction operator identifies the type of combined fragment
The loop operand indicates that the Fragment is executed repeatedly The alternative operand identifies a set of behaviors from which only one will execute on any one pass through the interaction
32
The alt interaction operator represents a dynamic choice among several subfragments (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.
5 - 32

Instructor Notes:
In sequence diagrams, a guard condition is also called an interaction constraint.
The Guard Expression

The guard expression is a Boolean conditional expression that guards an interaction operand:
Appears at the start of the operand Is used to determine if, or how long, the operand will be executed Its absence equates to a true condition
33
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.
5 - 33

Instructor Notes:
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.
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
34
5 - 34

Instructor Notes:
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.
Example: Alternative Combined Fragment
35
The alt interaction operator represents a dynamic choice among several subfragments. 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.
5 - 35

Instructor Notes:
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).
Role Message Hierarchical Message Numbering
36
The Anatomy of Communication Diagrams

Link Reflexive Message
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:classname rolename :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.
5 - 36

Instructor Notes:
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.
Example: Communication Diagram
37
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.
5 - 37

Instructor Notes:
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.
Interaction Overview Diagram

Uses 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 classes Allows focus at a higher level, where details are filtered out
Interaction Use
Control nodes and flow

38
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.
5 - 38

Instructor Notes:
Lab 11: Create Sequence Diagrams

Given:
Create Sequence Diagrams cheat sheet

Review the basic editor, tools, and elements in a sequence diagram. Create a new sequence diagram Re-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 Diagrams Follow the directions indicated on the Cheat Sheet.
39
5 - 39

Instructor Notes:
Lab 12: Create Communication Diagrams

Given:
Create Communication Diagrams cheat sheet

Review the basics of communication diagrams Create a new communication diagram Re-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 Diagrams Follow the directions indicated on the Cheat Sheet.
40
5 - 40

Instructor Notes:
Where Are We?

41
5 - 41

Instructor Notes:
A State Machine Diagram

State: a recognizable situation that exists over an interval of time ~ Hassan Gomaa 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
42
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 objectbased variant of Harel statecharts.
5 - 42

Instructor Notes:
States
States 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
43
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.
5 - 43

Instructor Notes:
Transitions
A transition is the path taken during a change of state from one state to the next in response to a triggering event Guard condition: Optional condition to be evaluated; if false, the transition is not taken
44
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.
5 - 44

Instructor Notes:
Regions
Regions 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
45
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.
5 - 45

Instructor Notes:
Composite States
Composite states are states that contain other states and regions
46
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 substates and 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.
5 - 46

Instructor Notes:
Orthogonal States
Orthogonal states
Are composite states with two or more regions within the state.
47
Orthogonal states are an extension of composite states.
5 - 47

Instructor Notes:
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.
Submachine State
A 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
48
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.
5 - 48

Instructor Notes:
Pseudostates
Initial State: Marks the start of the machine Choice Point: Supports dynamic branches Junction Point: Supports static branches Deep History: Return to the most recent substate Shallow History: Return to the most recent state Join, Fork: Similar to activity diagram Entry, Exit Point: Used to designate a default entry or exit into a composite state or state machine Terminate: Marks the end of the state machines execution
49
Combine and direct transitions
When a pseudostate is active, a state machine has not completed its run-tocompletion 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.
5 - 49

Instructor Notes:
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.
Choice Points
Choice 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
50
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.
5 - 50

Instructor Notes:
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.
51
Junctions
Junctions 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 transitions 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.
5 - 51

Instructor Notes:
History
Deep History
Represents the most recent active configuration of the composite state that directly contains this pseudostate A 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.
52
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.
5 - 52

Instructor Notes:
Lab 13: Create State Machine Diagrams

Given:
Create State Machine Diagrams cheat sheet

Review the basics of state machine diagrams Create a new state machine diagram Recreate 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 Diagrams Follow the directions indicated on the Cheat Sheet.
53
5 - 53

Instructor Notes:
1. These diagrams are particularly useful in describing workflow, and a use cases flow of events. Actor 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. 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.
Review
1. 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. Whats 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?
54
2. 3.
4.
5 - 54

Instructor Notes:
Further Information
Web resources Books
55
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.
5 - 55

Instructor Notes:
56
5 - 56
Essentials of Rational Software Architect, V7

Instructor Notes:
This module will require approximately 1 hour, 30 minutes to complete: Lecture: 30 minutes Labs: 1 hour
IBM Software Group
DEV396: Essentials of Rational Software Architect, V7

Module 6: Team Development
Module 6 - Team Development
6-1

Instructor Notes:
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.
6-2

Instructor Notes:
Software Architect and Team Development

Architect
Create and publish models
Developer
Consult published models and artifacts
Transform design model into code
Elaborate the code
Verify architecture and code with structural code review
Repository
Verify code with code review
The following Rational Software Architect features facilitate collaboration between architects and developers: Transformation Rational Software Architects 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 Review The code review feature is used to analyze code against the projects 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 code Web Publisher While creating detailed implementation code, the developer can refer to Webpublished models and UML-injected Javadocs, which Rational Software Architect can generate automatically.
6-3

Instructor Notes:
Where Are We?

Configuration Management in Rational Software Architect Compare and Merge Models Combine Models Model 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.
6-4

Instructor Notes:
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
Business.emx src
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.
5
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.
6-5

Instructor Notes:
VOB stands for Versioned Object Base.
CM with IBM Rational ClearCase

Use 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
VOB
1
Check Out
e
a Ch
ng
Check In Local File System

6
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 Architects Compare and Merge features. When team members work with versioncontrolled 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.
6-6

Instructor Notes:
Note that when a model is partitioned, shortcuts to the partitions appear in the model where the original packages were.
SCM Best Practices: Model Partitioning

Partition 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 subsystems 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.
6-7

Instructor Notes:
Model Partitioning
To partition a model, you can: Create fragments
An element that has been converted into a fragment has this icon:
Create new models from packages

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

Instructor Notes:
Partition and Fragment Files

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

Instructor Notes:
NOTE: You can make a fragment from an interaction but not from a sequence diagram. An interaction contains a sequence diagram.
Fragments
Fragments model elements into separate files Model Element Fragments:
All model elements down to the class level Activity Diagrams Composite Structure Diagrams State Machine Diagrams Communication Diagrams
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.
Diagrams that cannot be made into Fragments:

Class Diagram Object Diagram Freeform Diagram Deployment Diagram Component Diagram
10
Actions and commands applied to a model propagate across fragments. Compare-merge functionality works with models consisting of multiple fragments.
6 - 10

Instructor Notes:
Where Are We?

11
6 - 11

Instructor Notes:
Compare and Merge Models

Rational 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 occurs Alternative approaches are explored Circumstances dictate
Avoid situations that require frequent merging.

12
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.
6 - 12

Instructor Notes:
Merging Models
Begin with a base contributor, the common ancestor of the models you wish to merge.
Base Contributor
1
Contributor 1 Contributor 2
Have up to three contributors (modified versions of the base model) in a merge session.
1 2 1
Merge
13
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 colleagues changes. The SCM system attempts to merge your changes into the latest version (BC version 3) in the repository.
6 - 13

Instructor Notes:
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 employeeinfo attribute to Timecard. Contributor 2 (right) has added the getNumberhours operation. 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.
Left Contributor Right Contributor
Compare Editor
Merged Model Structural Differences Accept or Reject changes
14
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 merges During 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 merges During 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
6 - 14

Instructor Notes:
Compare and Merge Features

Diagram 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
15
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 dont 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.
6 - 15

Instructor Notes:
Lab14: Compare and Merge a Model

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

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 14 Compare and Merge Models. Follow the directions indicated on the Cheat Sheet.
16
6 - 16

Instructor Notes:
Where Are We?

17
6 - 17

Instructor Notes:
Combine Models
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.
Pending Changes Mark changes from source model to be applied to target model.
Source Model
Target Model
Change Description
18
The combine dissimilar models feature is also used when you apply a transformation to update a conceptual model from Java or C++ code.
6 - 18

Instructor Notes:
Lab15: Combine Models

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

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 15 Combine Models. Follow the directions indicated on the Cheat Sheet.
19
6 - 19

Instructor Notes:
Where Are We?

20
6 - 20

Instructor Notes:
Model Publishing
Publish the entire model to HTML Publish reports to PDF
Model diagram report Sample UML metric report
21
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 crosstool 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.
6 - 21

Instructor Notes:
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
22
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.
6 - 22

Instructor Notes:
With the Modeling Perspective open, import the ACMEPayrollApplication solution 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. 1.
Demo: Model Publishing

The instructor will now show you how to: Publish a model to HTML Explore the published model
Start page Packages Elements Diagrams
23
Watch your instructor publish a model in Rational Software Architect.
6 - 23

Instructor Notes:
Lab16: Publish a Model and Generate a Model Report

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

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 16 Publish and Generate Reports. Follow the directions indicated on the Cheat Sheet.
24
6 - 24

Instructor Notes:
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.
Review
Why 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.
25
6 - 25

Instructor Notes:
Further Information
RUP methodology topics Books
26
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.
6 - 26

Instructor Notes:
This module will require approximately 2 hours to complete: Lecture: 1 hour Lab 18: 30 minutes Lab 19: 30 minutes
IBM Software Group

Module 7: Applying Patterns and Transformations
Module 7 - Applying Patterns and Transformations
7-1

Instructor Notes:
Module Objectives
Apply reusable assets in the development process.
Apply a pre-built design pattern in Rational Software Architect. Perform model transformations
Forward transformations Reverse 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.
7-2

Instructor Notes:
Where Are We?

Asset- and Pattern-based Development Applying Design Patterns Applying Transformations Packaging Reusable Assets
This section describes asset-based development and the role of patterns.
7-3

Instructor Notes:
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 problem Requires a strategy for applying the pattern in its context. Comes with consequences (advantages and disadvantages) of applying the pattern.
Grady Boochs 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.
7-4

Instructor Notes:
Pattern Specifications
Pattern specifications are:
Patterns described in books and documentation
Capture best practices Used for educational and communication purposes Have to be implemented manually
How patterns have been traditionally 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.
7-5

Instructor Notes:
Pattern Implementations
A pattern implementation is an artifact that automates the application of a pattern in a particular environment
Automates applying a pattern in the IDE Provides realized solutions to real problems Makes patterns sharable and reusable Has points of variability that make every pattern application unique
Patterns 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.
7-6

Instructor Notes:
Benefits of Using Pattern Implementations

Patterns:
Increase productivity
Simplify and accelerate building and testing Eliminate repetitive work Make development easier and more instructive for beginners
Improve software governance, for:

Achieving architecture consistency Enforcing architectural decisions Enforcing design and coding standards
Increase quality
Apply best practices for functional and non-functional requirements Leverage expert skills within the development organization
Increase openness
Reuse and share existing architectural specifications Create less dependency on a specific tools vendor or platform
7
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 organizations 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.
7-7

Instructor Notes:
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.
Patterns in Rational Software Architect

Three 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 pattern Session Facade pattern
Transformations: Translate elements from one model into elements in a different model
1. Model-to-model 2. Model-to-code 3. Code-to-model
Pattern
1
Java Emitter Templates (JET) transformations: a type of transformation that provides customizable, text-based transformations and code templates
8
Transformations
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 Patterns Design 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. Transformations Transformations 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.
7-8

Instructor Notes:
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.
The Pattern Explorer view

Right-click to apply, copy, move, or configure the pattern, or to view documentation.
Design Pattern
Transformation
JET Transformation
Icons in the Pattern Explorer view
9
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 patterns 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.
7-9

Instructor Notes:
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.
ITERATE
Accelerating Model-Driven Development

Apply Patterns Forward Transform
(embedded patterns)
Computational Independent Model
Reverse Transform
(embedded patterns)
Business Use-Cases Business Analysis Business Process Models
Apply Patterns
Application Use-Cases
Forward Transform
(embedded patterns)
Reverse Transform
(embedded patterns)
Apply Patterns
PlatformIndependent Model
Application Analysis
Forward Transform
(embedded patterns)
Reverse Transform
(embedded patterns)
Apply Patterns
Application Design (high abstraction)
Forward Transform
(embedded patterns)
Platform-specific model markup

Reverse Transform
(embedded patterns)
PlatformSpecific Model
Implementation RUP Methodology
Code-based Development
10
Model-Driven Architecture
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 OMGs 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.
7 - 10

Instructor Notes:
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).
Reuse Sets of Artifacts: Reusable Assets A reusable asset is an organized collection of artifacts that provides a solution to a problem for a given context. A reusable asset contains: Problem
Artifacts: Patterns, transformations, profiles, pluglets, model templates, and so on. Solution Variability points: Allow users to customize Artifact the asset for a specific Artifact Artifact project
Artifact
Variability Point
11
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). IBMs 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.
7 - 11

Instructor Notes:
Asset-Driven Development Reuse requirements, design, test, and deployment assets to develop new or enhance existing applications Program Management Supported by IBM Rational Asset Candidate Asset Identification products with:
Process guidance Tooling Standards Assets
Asset Production
Feedback
Asset Management
Feedback
Asset Consumption
12
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.
7 - 12

Instructor Notes:
Where Are We?

13
This section introduces applying design patterns in Rational Software Architect.
7 - 13

Instructor Notes:
Design Patterns in Rational Software Architect

A design pattern in Rational Software Architect adds details to a model automatically. Use design patterns to add:
Model elements and relationships
Classes, packages, and so on
Details to model elements

Attributes, operations
Markup to the model

Stereotypes from a UML profile recognized by transformations
A design pattern:
Has parameters that are used to bind the pattern to the model Can be reapplied to or unbound from the model Usually affect small areas of the model when applied
14
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.
7 - 14

Instructor Notes:
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).
Parameters
Design Pattern Notation

Pattern Instance
A UML Collaboration
Multiplicity
Bound Arguments Binding Indicator
Parameter Type
15
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 parameters 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.
7 - 15

Instructor Notes:
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.
Drag an existing class from the diagram or Project Explorer view to a pattern parameter to make it an argument of the pattern, or
16
Applying a Design Pattern

1
Create 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.
Use the action bar to create an argument value for a parameter.
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 patterneither 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 an open 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 instances 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.
7 - 16

Instructor Notes:
Gang of Four (GoF) Design Patterns

Rational Software Architect has the 23 GoF design patterns built in:
Can be used as the basis for custom patterns These patterns support widely recognized best practices Help seed the code with transformation extensions
Example
Observer is a GoF behavioral design pattern:
One-to-many dependency between objects When one object changes state, observers are notified and updated automatically
17
The 23 Gang of Four design patterns are included with Rational Software Architects 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 a ConcreteSubject 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. 293303).
7 - 17

Instructor Notes:
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 GoF patterns 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.
Demo: Applying a Design Pattern

The instructor will now show you how to: Select the pattern Create a pattern instance Bind new elements to the pattern Bind existing elements to the pattern
18
Watch your instructor demonstrate how to apply a pattern in Rational Software Architect.
7 - 18

Instructor Notes:
Lab 17: Apply Patterns

Examine the Observer design pattern Create the UML modeling project Select a Pattern Apply a Pattern View 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.
19
Complete Lab 17: Apply Patterns in Rational Software Architect.
7 - 19

Instructor Notes:
Where Are We?

20
This section introduces applying transformations in Rational Software Architect.
7 - 20

Instructor Notes:
Transformations
Transformations 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 standard Based on the analysis model, create a design model that incorporates elements of the companys security and persistence frameworks, and follows a modeling standard Starting with a UML model, apply a builtin transformation to create code elements Take existing code and apply a transformation to abstract out the design elements.
Transformations
21
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.
7 - 21

Instructor Notes:
Transformations in Rational Software Architect

The following transformations are built in to Rational Software Architect:
UML to UML
UML to LDM
UML to code
UML to Java V1.4 UML to Java V5.0 UML to C++ UML to EJB UML to WSDL UML to XSD
Code to UML
C++ to UML Java to UML
Transformations can be custom built using the Plug-in Development Environment.

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

Instructor Notes:
Running a Transformation
Create a new instance (configuration) of the transformation Choose an appropriate project target Choose how to manage source-to-target traceability
Transformation
Source
Transformation Configuration
23
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.
7 - 23

Instructor Notes:
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.
Create a Transformation Configuration

A transformation configuration is an instance of a transformation with a specific:
Name Source Target
24
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.
7 - 24

Instructor Notes:
Source to Target Relationships

Create source to target relationships
Create derived relationships from generated Java elements to their UML source model element.
Replace UML elements

Make the generated code the focus of development efforts by replacing UML elements with pointers to the code.
25
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.
7 - 25

Instructor Notes:
You will recall that a reversetransformation 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.
Reverse Transformations
Java and C++ transformations can be reversed Enable a reverse transformation in the transformation configuration Allows you to synchronize changes between UML models and C++ and Java code
If necessary, compare and merge session starts when transformation is run
26
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.
7 - 26

Instructor Notes:
This reconciliation step in version 7 is a new feature. It makes it possible to use reverse transformations to synchronize code and models.
Reconciliation: Merge the Transformed Model

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

Instructor Notes:
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.
UML Visual Development

C++ and Java code can be visualized with class and sequence diagrams
Changes to the code update the diagram Changes to the diagram update the code Harvest classes into UML models
28
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.
7 - 28

Instructor Notes:
Concurrent Code and Model Development Reverse transformations allow for the concurrent development of UML models and code
Architecture V1.0 Iterate Architecture V1.1 Forward Transformation Implementation V1.0 Iterate Implementation V1.1 Introduce an architectural deviation
Reconcile
Model Combine Accepted change Architecture V1.1+
UML Model of Implementation v1.1 Reverse Transformation
Forward Transformation (omit rejected change)

29
Implementation V1.1+
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 finegrained management of architectural conformance.
7 - 29

Instructor Notes:
Follow Lab Apply Transformation to show students how they will create a transformation configuration and apply a UML to Java transformation.
Demo: Apply a Transformation

The instructor will now show you how to: Create a UML to Java transformation Transform UML classes to Java classes Review the code
30
Watch your instructor perform a UML to Java code transformation.
7 - 30

Instructor Notes:
Lab 18: Run a UML to Java Transformation

Task 1: Create the UML modeling project Task 2: Create UML Classes Task 3: Transform UML Classes to Java Classes Task 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.
31
Complete Lab 18: Apply a UML to Java Transformation.
7 - 31

Instructor Notes:
Where Are We?

32
This section describes the features in Rational Software Architect for packaging assets, including custom pattern libraries.
7 - 32

Instructor Notes:
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.
Building Custom Artifacts
UML Profiles
Design Patterns
Transformations
Model Templates
Plug-ins
Pluglets
Supporting creation of these artifacts in Rational Software Architect are:

The Plug-in Development Environment (PDE) Reusable Asset Specification (RAS) Import and Export
33
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.
7 - 33

Instructor Notes:
Describe the extensibility topic as part of a larger objective to achieve efficiency and interoperability.
Sources for Artifacts Patterns, transformations, and other artifacts are not limited to artifacts you create for yourself. They can come from a variety of sources.
IBM Rational Software
Your Group
Third-Party Software Companies
Peer Groups
Solution in Rational Software Architect
34
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.
7 - 34

Instructor Notes:
Patterns and Transformations As Reusable Assets

Related 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.
RAS Asset
Eclipse Plug-in Eclipse Plug-in Patterns Library Patterns Library
35
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.
7 - 35

Instructor Notes:
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.
Review
How 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?
36
7 - 36

Instructor Notes:
Further Information
Web Sites Books Articles
37
Web Sites IBM, Patterns Solutions. IBM developerWorks, accessed 15-January-2007. http://www128.ibm.com/developerworks/rational/products/patternsolutions/assets.html Books Buschmann, Frank et al. PatternOriented 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://www128.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/
7 - 37

Instructor Notes:
38
7 - 38

Instructor Notes:
This module will require approximately 1 hours to complete: Lecture: 1 hour Lab 20: 30 minutes
IBM Software Group

Module 8: Traceability
Module 8 - Traceability
8-1

Instructor Notes:
Module Objectives
Ensure that solutions are connected to requirements (in other words, traceability) Create traceability to IBM Rational RequisitePro Create traceability to IBM WebSphere Business Modeler Use topic and browse diagram to investigate traceabilities.
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.
8-2

Instructor Notes:
Traceability
Traceability 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.
8-3

Instructor Notes:
Product Integrations with Rational Software Architect

WebSphere Business Modeler
RequisitePro
UML (contract) BPEL

BPEL has only stuff that is to be automated one-way flow
IBM WebSphere Integration Developer
WSDL Rational Software Architect
IBM WebSphere Business Monitor
IBM WebSphere Process Server IBM WebSphere Application Server

RUNTIME
4
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 businessdriven, 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).
8-4

Instructor Notes:
Where Are We?

Integration with RequisitePro Integration with WebSphere Business Modeler Exploring Traceability Relationships
This section introduces the RequisitePro integration with Rational Software Architect.
8-5

Instructor Notes:
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.
Traceability from Requirements to Design

Problem Problem Needs Features Software Requirements Design The system to be built Traceability
Problem Space
Solution Space
Test Procedures
6
User Doc
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, and show how policies are traced to initiatives that allow you to comply with those policies.
8-6

Instructor Notes:
Rational RequisitePro Integration

Rational RequisitePro
A requirements management tool Enables you to track relationships between requirements Provides functionality to analyze the impact of changes to requirements
Features and Vision

Vision Document FEAT 1 FEAT 3 FEAT 7
The Requirements perspective in Rational Software Architect:

Provides an effective interface to requirements managed in RequisitePro, including:
Documents
Vision, use-case specifications
Requirements Requirement Properties Views
All Features
Use Cases
Allows requirements to be traced to model elements
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.
8-7

Instructor Notes:
Views of the Requirement Perspective
Requirement Explorer
Requirements Properties
Requirements Trace
Link Clipboard
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.
8-8

Instructor Notes:
RequisitePro
Requirements Explorer
9
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.
8-9

Instructor Notes:
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.
?
RequisitePro Requirements Traceability Model

System Requirements
FEAT (Feature)
<<trace to>> <<trace to>>
UC (Use Case)
SUPP (Supplementary Requirement)

<<trace to>>
<<link>>
PROXY Requirement
<<link>>
Domain Element (Use Case)

10
Domain Element (Other Model Element)
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.
8 - 10

Instructor Notes:
Associating Requirements and Model Elements

Creating a new model element
Associating with an existing element
Drag a requirement to a diagram to create a model element in the model that is linked to the requirement in RequisitePro. By default, use-case requirements create use cases in the model, all other requirements create classes.
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).
11
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).
8 - 11

Instructor Notes:
Associating Requirements and Model Elements

When a requirement is dropped onto a model element, a proxy is created for the model element in RequisitePro.
Use cases are always directly linked Proxies are RequisitePro requirements Mapping between model elements and requirement types are managed using the RequisitePro project properties Additional attributes may be added to the proxy requirement types.
12
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 usecase artifacts based on rules, which you can configure.
8 - 12

Instructor Notes:
Trace Between Elements

Examine traceability relationships between requirements in the Requirements Trace view
Trace from focus element to requirements Trace to focus element from requirements
13
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.
8 - 13

Instructor Notes:
Lab 19: Create Traceability Links

Given:
Existing RequisitePro project

Explore Requirement Perspective Link Folders and Files to Requirements Link UML Model Elements to Requirements Link Java Classes to Requirements Review 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.
14
Complete Lab 19: Create Traceability Links in Rational Software Architect.
8 - 14

Instructor Notes:
Where Are We?

Traceability Integration with RequisitePro Integration with WebSphere Business Modeler Exploring Traceability Relationships
15
This section describes the integration between Rational Software Architect and WebSphere Business Modeler.
8 - 15

Instructor Notes:

People who know the business create the models
Model Resources, roles, organization information, business metrics Enables teamwork, communication, versioning and Web publication
Clean Hand-off to IT
Business modeling is the starting point for rapid and accurate IT process deployment and application development
16
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.
8 - 16

Instructor Notes:
Introducing Business Driven Development

Process Modeling and Simulation
Process Automation
Process Management
WebSphere Business Monitor
WebSphere Process Server
Rational Software Architect IBM Rational Software Modeler
Design and Construction

17
Complex processes, choreographed or not, must be architected and designed WebSphere Business Modeler defines the contract for design and implementation of those tasks Rational Software Architect reads WebSphere Business Modeler models so that the contract can be implemented Other tasks are automated in WebSphere Integration Developer
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 organizations 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.
8 - 17

Instructor Notes:
WebSphere Business Modeler and Rational Software Architect

1. Business analyst creates business model 2. Software Architect views business model as UML
View as UML Contract
Rational Software Architect
3. Requirements analyst gathers requirements based on business model 4. Software Architect creates UML design model
Business Process Model
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
Business Process models serve as contracts for software implementation of roles / tasks
18
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.
8 - 18

Instructor Notes:
Business Process Model Elements

Process diagram generated by WebSphere Business Modeler Stop
Decision Task Node
Alternate paths
Control flow
Business Item Annotation

19
WebSphere Business Modeler notation is based on BPMN (Business Process Metamodel 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.
8 - 19

Instructor Notes:
Business Processes to Business Use Cases

WebSphere 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

20
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.
8 - 20

Instructor Notes:
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.
Business Processes
In Rational Software Architect, a business process maps to:
A use case and realization (black box) view An activity diagram (white box) view
21
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.
8 - 21

Instructor Notes:
Mapping Roles to Interfaces

A role is a characteristic of a resource Roles are shown in WebSphere Business Modeler in the swim-lane view Methods in the interface are responsibilities of the role that need to be implemented

22
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.
8 - 22

Instructor Notes:
Mapping Business Items to Classes
Business Item in WebSphere Business Modeler

23
Business Entities in Rational Software Architect
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.
8 - 23

Instructor Notes:
Where Are We?

Traceability Integration with RequisitePro Integration with WebSphere Business Modeler Exploring Traceability Relationships
24
This section describes ways to explore traceability relationships between model elements using UML diagrams in Rational Software Architect.
8 - 24

Instructor Notes:
Modeling Traceability Relationships

Model traceability among model elements with dependencies
Using model transformations Manually added in diagrams
Use derive or use dependency relationship
These relationships can be explored using topic and browse diagrams
25
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.
8 - 25

Instructor Notes:
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.
Exploring Traceability Relationships

Use 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 documentation Saved in the model
Browse Diagrams:
Explore traceability relationships among model elements Are not saved in the model
26
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.
8 - 26

Instructor Notes:
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.
Review
How is traceability between models useful in modeldriven 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 in Rational Software Architect?
27
8 - 27

Instructor Notes:
Further Information
Web Resources Articles Related Courses
28
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://www128.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/T raceabilitySep02.pdf Miller, Jeff. Model Rational RequisitePro requirements in Rational Software Architect. IBM developerWorks, 2006. http://www128.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/wsbdd/index.html Related Courses REQ370: Essentials of IBM Rational RequisitPro (ILT) or REQ310: Essentials of IBM Rational RequisitPro (WBT)
8 - 28

Instructor Notes:
This module will require approximately 1 hour, 30 minutes to complete: Lecture: 60 minutes Lab 21: 30 minutes
IBM Software Group

Module 9: Static Analysis
Module 9 - Static Analysis
9-1

Instructor Notes:
An overview of the static analysis features is coming right up. No need to introduce them in detail here.
Module Objectives
After completing this module you will be able to:
Perform static analysis on Java 2 Platform, Standard Edition (J2SE) and J2EE systems using:
Architectural Discovery UML Model Analysis Code Review
Explore the architecture of a system visually using code modeling

Class and sequence diagrams Topic 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.
9-2

Instructor Notes:
The Challenge of Software Maintenance

Enterprise applications are too large and complex for traditional code review Design and code standards are often subjective, hard to enforce across large teams
Business Requirements
Complex Business Requirements Unstable Unreliable Unpredictable
Rewrite
3
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 to develop 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.
9-3

Instructor Notes:
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.
Addressing the Challenges

Throughout development, Rational Software Architect provides key features to detect and fix potential problems
Identify
Architectural Discovery UML Model Analysis
Identify
Analyze
Analyze
Architectural Discovery Code Review UML Visual Development
Resolve
Code Review Quick Fix Visual code development
Resolve
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 Architects 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 Architects 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.
9-4

Instructor Notes:
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.
Static Analysis in Rational Software Architect

Static analysis: Analyze components and resources of an application without having to run the application.
Automated static analysis
Architectural 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 analysis

Explore relationships with topic and browse diagrams Model code with class and sequence diagrams
5
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 Architects 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++.
9-5

Instructor Notes:
Where Are We?

Automated Static Analysis Manual Static Analysis
This section describes how to use the automated static analysis features available in Rational Software Architect.
9-6

Instructor Notes:
This analysis configuration dialog is new with version 7.
Running an Automated Analysis: Analysis Configuration

Create an analysis configuration with:
Scope of analysis
Project Resource set Whole workspace
Rules or rule sets to apply

Architectural Discovery Code review for Java UML Model Analysis
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.
9-7

Instructor Notes:
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.
Running an Analysis: Analysis Results The Analysis Results view displays the findings of all analysis sessions View 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.
9-8

Instructor Notes:
This is a new feature in version 7.
Export Analysis Results

Results of each analysis are available in the Analysis Results view until deleted Results 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.
9-9

Instructor Notes:
Architectural Discovery Four categories of rules:

Design Patterns
Discover familiar design patterns in the architecture
Object-Oriented Patterns
Find the inheritance tree and interfaces
Structural Patterns
Find structural patterns and anti-patterns in the architecture
System Patterns
Explore the structure of the model
10
Architectural Discovery is a set of features used to visually inspect an applications 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
9 - 10

Instructor Notes:
Structural Patterns
Has a lot of immediate dependents If changed, may affect many components 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
Has a lot of immediate dependencies and dependents Group of interdependent components: changes to one affects all
11
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.
9 - 11

Instructor Notes:
Architectural Discovery Analysis Results
Select View Result in the Analysis Results view.

12
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.
9 - 12

Instructor Notes:
Note that you can apply whole groups of rules at once by selecting the rule category.
Code Review
Code 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.
13
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.
9 - 13

Instructor Notes:
Rule Severity Levels

Code review rules have associated severity levels. There are three levels of severity:
14
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.
9 - 14

Instructor Notes:
This approach to creating rules is new in version 7.
Create a New Analysis Rule

Process for creating a custom rule:
Add rule category (if necessary) and new rule in Analysis preferences Select rule template Select basic properties:
Name Severity
15
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.
9 - 15

Instructor Notes:
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.
Code Review Best Practices

Do:
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.
Dont
Create 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.
16
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
9 - 16

Instructor Notes:
Code Review Analysis Results

Examine and work with findings in the Code Review and Code Review Details views. Apply quick fixes.
Quick Fix Available
17
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.
9 - 17

Instructor Notes:
Applying Quick Fixes

Review the quick fix in context Click Quick Fix
18
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.
9 - 18

Instructor Notes:
Follow the instructions for Lab 21 or have the students perform the lab along with you.
Demo: Code Review

The instructor will now show you how to: Perform a code review. Examine findings. Apply a Quick Fix.
19
Watch your instructor perform a code review and apply a Quick Fix.
9 - 19

Instructor Notes:
Lab 20: Perform Static Analysis

Given:
Existing project

Task 1: Import Java Project Task 2: Create Analysis Configuration Task 3: Review Design Patterns Task 4: Fix Circular Dependencies Task 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.
20
Complete Lab 20: Static Analysis in Rational Software Architect.
9 - 20

Instructor Notes:
UML Model Analysis Use UML Model Analysis to discover issues with traceability relationships between model elements:
No traceability path to an implementation or a specification Broken trace relationships Circular trace relationships Implied access violations
21
UML Model Analysis is used to discover issues with traceability relationships between model elements. Broken Trace Relationships The 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 Relationships Circular trace relationships occur when one or more model elements have abstraction dependencies on each other. Access Violations Between Model Elements With Implied Dependency Relationships An 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 elements package has a Permission, Import Package, or Import Element relationship to the target model elements package Each model element is in a different package, and the source model elements 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 elements package is an access violation that might not be resolvable.
9 - 21

Instructor Notes:
UML Model Analysis Results Use the results in the Analysis Results view to navigate to model elements in the Project Explorer view.
22
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 Result to navigate directly to the issue in the model.
9 - 22

Instructor Notes:
Where Are We?

Automated Static Analysis Manual Static Analysis
23
This section discusses how you can use tools for manual static analysis, topic and browse diagrams, and UML visualization features.
9 - 23

Instructor Notes:
Manual Static Analysis

Use visualization to explore and modify code structure, relationships, and behavior using UML
Explore, analyze, and document
Topic 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 edit

Class diagrams
For visual code modeling and editing
Sequence diagrams
Visually explore and edit code behavior
24
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 models In 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 models In 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.
9 - 24

Instructor Notes:
Exploring Structure Use browse and topic diagrams to understand the relationships and associations among Java or C/C++ classes Modify the code visually using class diagrams
25
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.
9 - 25

Instructor Notes:
Static Method Analysis: Exploring Behavior

Generate a static method sequence diagram to interpret existing code and discover problems with:
Method Length Method Complexity Private API calls
26
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.
9 - 26

Instructor Notes:
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.
27
Review
What 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?
9 - 27

Instructor Notes:
28
9 - 28

Instructor Notes:
This module will require approximately 20 minutes to complete. There are no labs in this module.
IBM Software Group

Module 10: Summary
Module 10 - Summary
10 - 1

Instructor Notes:
Software Development with Rational Software Architect

Generate Identify
Process Guidance
Design
Analyze
Resolve
2
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.
Module 10 - Summary
10 - 2

Instructor Notes:
Design: Models and Diagrams

Develop UML models and diagrams in Rational Software Architect to specify, document, and construct artifacts in a software system.
Model templates based on RUP methodology models UML profiles included for:
Analysis Modeling Business Modeling Service-Oriented Architecture And 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.
Module 10 - Summary
10 - 3

Instructor Notes:
Generate: Patterns and Transformations

Generate and construct artifacts in a software system by applying:
Patterns to add details to a model Transformations to translate elements from one model into elements in a different mode
Build your own custom patterns and transformations

Transformations
Apply Patterns
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 Patterns Design 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. Transformations Transformations 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.
Module 10 - Summary
10 - 4

Instructor Notes:
Identify: Visualization and Structural Review

Explore models and code using visualization and architectural discovery
Visualize the architecture
UML Visual Development
Class and Sequence diagrams show structure and behavior
Topic and Browse diagrams

Explore relationships between model elements Topic and Browse Diagrams
UML Models
Visually inspect critical portions of the architecture to keep them up to date with the code Discover important design patterns in the architecture
Code
5
UML Visualization
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 applications 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.
Module 10 - Summary
10 - 5

Instructor Notes:
Analyze: Code Review

Use 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 Principles Globalization J2EE Best Practices J2EE Security J2SE Best Practices Naming Performance Private API
Use Architectural Discovery to find structural anti-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 projectspecific coding standards.
Module 10 - Summary
10 - 6

Instructor Notes:
Resolve: Reconcile and Refactor

Reconcile and synchronize higher-level models with lower-level models with traceability and reverse transformations Refactoring helps make model and system-wide changes Applying quick fixes and improving adherence to code rules and best practices improves code quality
Trail of derive relationships left by transformations.
Reconciliation Reverse Transformations

7
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.
Module 10 - Summary
10 - 7

Instructor Notes:
Process: Rational Unified Process (RUP) Methodology RUP methodology process guidance is built in to Rational Software Architect:
Process Advisor Process Browser
RUP is:
Rooted in philosophies and practices for successful software development A process model and customizable content library A process definition language
8
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.
Module 10 - Summary
10 - 8

Instructor Notes:
Further Information
Web Resources Articles Redbooks
Web Resources IBM. Rational Software Architect. IBM developerWorks. http://www128.ibm.com/developerworks/rational/products/rsa/ (Accessed 19 January 2007). IBM. Pattern Solutions. IBM developerWorks. http://www128.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://www128.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
Module 10 - Summary
10 - 9

Instructor Notes:
10
Module 10 - Summary
10 - 10

IBM-RationalSwArchManual Rd541gv1 Insman

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IBM-RationalSwArchManual Rd541gv1 Insman

Hochgeladen von

Copyright:

Verfügbare Formate

IBM Rational University

Essentials of IBM Rational Software Architect v7.0

DEV396 Essentials of IBM Rational Software Architect V7

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

DEV396 Essentials of IBM Rational Software Architect V7

Module 5 Creating UML Diagrams of System Behavior

Module 6 Team Development

Module 7 Applying Patterns and Transformations

DEV396 Essentials of IBM Rational Software Architect V7

Module 9 Static Analysis and Code Review

Essentials of IBM Rational Software Architect

IBM Software Group

DEV396: Essentials of IBM Rational Software Architect, V7

2007 IBM Corporation

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect

Course Goals and Objectives

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect

Morning 2 15-minute breaks Lunch 1 Hour Afternoon 2 15-minute breaks

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect

Copyright IBM Corp. 2007

Module 0 - About This Course

Essentials of IBM Rational Software Architect, V7

IBM Software Group

DEV396: Essentials of Rational Software Architect, V7

2007 IBM Corporation

Copyright IBM Corp. 2007

Module 1 - Getting Started with Rational Software Architect

Essentials of IBM Rational Software Architect, V7

Copyright IBM Corp. 2007

Module 1 - Getting Started with Rational Software Architect

Essentials of IBM Rational Software Architect, V7

Copyright IBM Corp. 2007

Module 1 - Getting Started with Rational Software Architect

Essentials of IBM Rational Software Architect, V7

Where Are We?

Copyright IBM Corp. 2007

Module 1 - Getting Started with Rational Software Architect

Essentials of IBM Rational Software Architect, V7

The IBM Rational Software Delivery Platform

Copyright IBM Corp. 2007

Module 1 - Getting Started with Rational Software Architect

Essentials of IBM Rational Software Architect, V7