- •Table of Contents
- •Mastering UML with Rational Rose 2002
- •Chapter 1: Introduction to UML
- •Encapsulation
- •Inheritance
- •Polymorphism
- •What Is Visual Modeling?
- •Systems of Graphical Notation
- •Booch Notation
- •Object Management Technology (OMT)
- •Unified Modeling Language (UML)
- •Understanding UML Diagrams
- •Business Use Case Diagrams
- •Use Case Diagrams
- •Activity Diagrams
- •Sequence Diagrams
- •Collaboration Diagrams
- •Class Diagrams
- •Statechart Diagrams
- •Component Diagrams
- •Deployment Diagrams
- •Visual Modeling and the Software Development Process
- •Inception
- •Elaboration
- •Construction
- •Transition
- •Summary
- •Chapter 2: A Tour of Rose
- •What Is Rose?
- •Getting Around in Rose
- •Parts of the Screen
- •Exploring Four Views in a Rose Model
- •Use Case View
- •Logical View
- •Component View
- •Deployment View
- •Working with Rose
- •Creating Models
- •Saving Models
- •Exporting and Importing Models
- •Publishing Models to the Web
- •Working with Controlled Units
- •Using the Model Integrator
- •Working with Notes
- •Working with Packages
- •Adding Files and URLs to Rose Model Elements
- •Adding and Deleting Diagrams
- •Setting Global Options
- •Working with Fonts
- •Working with Colors
- •Summary
- •Chapter 3: Business Modeling
- •Introduction to Business Modeling
- •Why Model the Business?
- •Do I Need to Do Business Modeling?
- •Business Modeling in an Iterative Process
- •Business Actors
- •Business Workers
- •Business Use Cases
- •Business Use Case Diagrams
- •Activity Diagrams
- •Business Entities
- •Organization Unit
- •Where Do I Start?
- •Identifying the Business Actors
- •Identifying the Business Workers
- •Identifying the Business Use Cases
- •Showing the Interactions
- •Documenting the Details
- •Creating Business Use Case Diagrams
- •Deleting Business Use Case Diagrams
- •The Use Case Diagram Toolbar
- •Adding Business Use Cases
- •Business Use Case Specifications
- •Assigning a Priority to a Business Use Case
- •Viewing Diagrams for a Business Use Case
- •Viewing Relationships for a Business Use Case
- •Working with Business Actors
- •Adding Business Actors
- •Adding Actor Specifications
- •Assigning an Actor Stereotype
- •Setting Business Actor Multiplicity
- •Viewing Relationships for a Business Actor
- •Working with Relationships
- •Association Relationship
- •Generalization Relationship
- •Working with Organization Units
- •Adding Organization Units
- •Deleting Organization Units
- •Activity Diagrams
- •Adding an Activity Diagram
- •Adding Details to an Activity Diagram
- •Summary
- •Chapter 4: Use Cases and Actors
- •Use Case Modeling Concepts
- •Actors
- •Use Cases
- •Traceability
- •Flow of Events
- •Relationships
- •Use Case Diagrams
- •Activity Diagrams
- •Activity
- •Start and End States
- •Objects and Object Flows
- •Transitions
- •Synchronization
- •Working with Use Cases in Rational Rose
- •The Use Case Diagram Toolbar
- •Creating Use Case Diagrams
- •Deleting Use Case Diagrams
- •Adding Use Cases
- •Deleting Use Cases
- •Use Case Specifications
- •Naming a Use Case
- •Viewing Participants of a Use Case
- •Assigning a Use Case Stereotype
- •Assigning a Priority to a Use Case
- •Creating an Abstract Use Case
- •Viewing Diagrams for a Use Case
- •Viewing Relationships for a Use Case
- •Working with Actors
- •Adding Actors
- •Deleting Actors
- •Actor Specifications
- •Naming Actors
- •Assigning an Actor Stereotype
- •Setting Actor Multiplicity
- •Creating an Abstract Actor
- •Viewing Relationships for an Actor
- •Viewing an Actor's Instances
- •Working with Relationships
- •Association Relationship
- •Includes Relationship
- •Extends Relationship
- •Generalization Relationship
- •Working with Activity Diagrams
- •The Activity Diagram Toolbar
- •Creating Activity Diagrams
- •Deleting Activity Diagrams
- •Exercise
- •Problem Statement
- •Create a Use Case Diagram
- •Summary
- •Chapter 5: Object Interaction
- •Interaction Diagrams
- •What Is an Object?
- •What Is a Class?
- •Where Do I Start?
- •Finding Objects
- •Finding the Actor
- •Using Interaction Diagrams
- •Sequence Diagrams
- •The Sequence Diagram Toolbar
- •Collaboration Diagrams
- •The Collaboration Diagram Toolbar
- •Working with Actors on an Interaction Diagram
- •Working with Objects
- •Adding Objects to an Interaction Diagram
- •Deleting Objects from an Interaction Diagram
- •Setting Object Specifications
- •Naming an Object
- •Mapping an Object to a Class
- •Setting Object Persistence
- •Using Multiple Instances of an Object
- •Working with Messages
- •Adding Messages to an Interaction Diagram
- •Adding Messages to a Sequence Diagram
- •Deleting Messages from a Sequence Diagram
- •Reordering Messages in a Sequence Diagram
- •Message Numbering in a Sequence Diagram
- •Viewing the Focus of Control in a Sequence Diagram
- •Adding Messages to a Collaboration Diagram
- •Deleting Messages from a Collaboration Diagram
- •Message Numbering in a Collaboration Diagram
- •Adding Data Flows to a Collaboration Diagram
- •Setting Message Specifications
- •Naming a Message
- •Mapping a Message to an Operation
- •Setting Message Synchronization Options
- •Setting Message Frequency
- •End of a Lifeline
- •Working with Scripts
- •Switching Between Sequence and Collaboration Diagrams
- •Exercise
- •Problem Statement
- •Create Interaction Diagrams
- •Summary
- •Chapter 6: Classes and Packages
- •Logical View of a Rose Model
- •Class Diagrams
- •What Is a Class?
- •Finding Classes
- •Creating Class Diagrams
- •Deleting Class Diagrams
- •Organizing Items on a Class Diagram
- •Using the Class Diagram Toolbar
- •Working with Classes
- •Adding Classes
- •Class Stereotypes
- •Analysis Stereotypes
- •Class Types
- •Interfaces
- •Web Modeling Stereotypes
- •Other Language Stereotypes
- •Class Specifications
- •Naming a Class
- •Setting Class Visibility
- •Setting Class Multiplicity
- •Setting Storage Requirements for a Class
- •Setting Class Persistence
- •Setting Class Concurrency
- •Creating an Abstract Class
- •Viewing Class Attributes
- •Viewing Class Operations
- •Viewing Class Relationships
- •Using Nested Classes
- •Viewing the Interaction Diagrams That Contain a Class
- •Setting Java Class Specifications
- •Setting CORBA Class Specifications
- •Working with Packages
- •Adding Packages
- •Deleting Packages
- •Exercise
- •Problem Statement
- •Creating a Class Diagram
- •Summary
- •Chapter 7: Attributes and Operations
- •Working with Attributes
- •Finding Attributes
- •Adding Attributes
- •Deleting Attributes
- •Setting Attribute Specifications
- •Setting the Attribute Containment
- •Making an Attribute Static
- •Specifying a Derived Attribute
- •Working with Operations
- •Finding Operations
- •Adding Operations
- •Deleting Operations
- •Setting Operation Specifications
- •Adding Arguments to an Operation
- •Specifying the Operation Protocol
- •Specifying the Operation Qualifications
- •Specifying the Operation Exceptions
- •Specifying the Operation Size
- •Specifying the Operation Time
- •Specifying the Operation Concurrency
- •Specifying the Operation Preconditions
- •Specifying the Operation Postconditions
- •Specifying the Operation Semantics
- •Displaying Attributes and Operations on Class Diagrams
- •Showing Attributes
- •Showing Operations
- •Showing Visibility
- •Showing Stereotypes
- •Mapping Operations to Messages
- •Mapping an Operation to a Message on an Interaction Diagram
- •Exercise
- •Problem Statement
- •Add Attributes and Operations
- •Summary
- •Chapter 8: Relationships
- •Relationships
- •Types of Relationships
- •Finding Relationships
- •Associations
- •Using Web Association Stereotypes
- •Creating Associations
- •Deleting Associations
- •Dependencies
- •Creating Dependencies
- •Deleting Dependencies
- •Package Dependencies
- •Creating Package Dependencies
- •Deleting Package Dependencies
- •Aggregations
- •Creating Aggregations
- •Deleting Aggregations
- •Generalizations
- •Creating Generalizations
- •Deleting Generalizations
- •Working with Relationships
- •Setting Multiplicity
- •Using Relationship Names
- •Using Stereotypes
- •Using Roles
- •Setting Export Control
- •Using Static Relationships
- •Using Friend Relationships
- •Setting Containment
- •Using Qualifiers
- •Using Link Elements
- •Using Constraints
- •Exercise
- •Problem Statement
- •Adding Relationships
- •Summary
- •Chapter 9: Object Behavior
- •Statechart Diagrams
- •Creating a Statechart Diagram
- •Adding States
- •Adding State Details
- •Adding Transitions
- •Adding Transition Details
- •Adding Special States
- •Using Nested States and State History
- •Exercise
- •Problem Statement
- •Create a Statechart Diagram
- •Summary
- •Chapter 10: Component View
- •What Is a Component?
- •Types of Components
- •Component Diagrams
- •Creating Component Diagrams
- •Adding Components
- •Adding Component Details
- •Adding Component Dependencies
- •Exercise
- •Problem Statement
- •Summary
- •Chapter 11: Deployment View
- •Deployment Diagrams
- •Opening the Deployment Diagram
- •Adding Processors
- •Adding Processor Details
- •Adding Devices
- •Adding Device Details
- •Adding Connections
- •Adding Connection Details
- •Adding Processes
- •Exercise
- •Problem Statement
- •Create Deployment Diagram
- •Summary
- •Chapter 12: Introduction to Code Generation and Reverse Engineering Using Rational Rose
- •Preparing for Code Generation
- •Step One: Check the Model
- •Step Two: Create Components
- •Step Three: Map Classes to Components
- •Step Five: Select a Class, Component, or Package
- •Step Six: Generate Code
- •What Gets Generated?
- •Introduction to Reverse Engineering Using Rational Rose
- •Model Elements Created During Reverse Engineering
- •Summary
- •Chapter 13: ANSI C++ and Visual C++ Code Generation and Reverse Engineering
- •Generating Code in ANSI C++ and Visual C++
- •Converting a C++ Model to an ANSI C++ Model
- •Class Properties
- •Attribute Properties
- •Operation Properties
- •Package (Class Category) Properties
- •Component (Module Specification) Properties
- •Role Properties
- •Generalization Properties
- •Class Model Assistant
- •Component Properties
- •Project Properties
- •Visual C++ and ATL Objects
- •Generated Code
- •Code Generated for Classes
- •Code Generated for Attributes
- •Code Generated for Operations
- •Visual C++ Code Generation
- •Reverse Engineering ANSI C++
- •Reverse Engineering Visual C++
- •Summary
- •Overview
- •Introduction to Rose J
- •Beginning a Java Project
- •Selecting a Java Framework
- •Linking to IBM VisualAge for Java
- •Linking to Microsoft Visual J++
- •Project Properties
- •Class Properties
- •Attribute Properties
- •Operation Properties
- •Module Properties
- •Role Properties
- •Generating Code
- •Generated Code
- •Classes
- •Attributes
- •Operations
- •Bidirectional Associations
- •Unidirectional Associations
- •Associations with a Multiplicity of One to Many
- •Associations with a Multiplicity of Many to Many
- •Reflexive Associations
- •Aggregations
- •Dependency Relationships
- •Generalization Relationships
- •Interfaces
- •Java Beans
- •Support for J2EE
- •EJBs
- •Servlets
- •JAR and WAR Files
- •Automated J2EE Deployment
- •Reverse Engineering
- •Summary
- •Starting a Visual Basic Project
- •Class Properties
- •Attribute Properties
- •Operation Properties
- •Module Specification Properties
- •Role Properties
- •Generalization Properties
- •Generated Code
- •Classes
- •Attributes
- •Operations
- •Bidirectional Associations
- •Unidirectional Associations
- •Associations with a Multiplicity of One to Many
- •Associations with a Multiplicity of Many to Many
- •Reflexive Associations
- •Aggregations
- •Dependency Relationships
- •Generalization Relationships
- •Reverse Engineering
- •Summary
- •Overview
- •Introduction to XML DTD
- •Elements
- •Attributes
- •Entities and Notations
- •Project Properties
- •Class Properties
- •Attribute Properties
- •Role Properties
- •Component Properties
- •Generating Code
- •Generated Code
- •Classes
- •Attributes
- •Reverse Engineering DTD
- •Summary
- •Project Properties
- •Class Properties
- •Attribute Properties
- •Operation Properties
- •Module Properties
- •Association (Role) Properties
- •Dependency Properties
- •Generated Code
- •Classes
- •Attributes
- •Operations
- •Bidirectional Associations
- •Unidirectional Associations
- •Associations with a Multiplicity of One to Many
- •Associations with a Multiplicity of Many to Many
- •Associations with Bounded Multiplicity
- •Reflexive Associations
- •Aggregations
- •Dependency Relationships
- •Generalization Relationships
- •Reverse Engineering CORBA Source Code
- •Summary
- •Chapter 18: Rose Data Modeler
- •Object Models and Data Models
- •Creating a Data Model
- •Logic in a Data Model
- •Adding a Database
- •Adding Tablespaces
- •Adding a Schema
- •Creating a Data Model Diagram
- •Creating Domain Packages and Domains
- •Adding Tables
- •Adding Columns
- •Setting a Primary Key
- •Adding Constraints
- •Adding Triggers
- •Adding Indexes
- •Adding Stored Procedures
- •Adding Relationships
- •Adding Referential Integrity Rules
- •Working with Views
- •Generating an Object Model from a Data Model
- •Generating a Data Model from an Object Model
- •Generating a Database from a Data Model
- •Updating an Existing Database
- •Reverse Engineering a Database
- •Summary
- •Chapter 19: Web Modeling
- •Modeling a Web Application
- •Web Class Stereotypes
- •Relationships
- •Reverse Engineering a Web Application
- •Generating Code for a Web Application
- •Summary
- •Appendix: Getting Started with UML
- •Building a Business Use Case Diagram
- •Building a Workflow (Activity) Diagram
- •Building a Use Case Diagram
- •Building an Interaction Diagram
- •Building a Class Diagram
- •Web Modeling
- •Adding Class Relationships
- •Building a Statechart Diagram
- •Building a Component Diagram
- •Building a Deployment Diagram
Chapter 6: Classes and Packages
Rose will add the selected class(es) to the open diagram.
To add a class to the browser:
1.
Right−click Logical View in the browser. To add a class to a package, right−click the package name.
2.
From the shortcut menu, select New → Class. To add a class utility or an interface, select New → Class Utility or New → Interface. The new class, called NewClass by default, will appear in the browser.
3.
Select the new class and type its name.
4.
To then add the new class to a Class diagram, drag it from the browser to the open diagram.
Class Stereotypes
A stereotype is a mechanism you can use to categorize your classes. Say, for example, you want to quickly find all of the forms in the model. You could create a Form stereotype, and to find your forms later, you would just need to look for the classes with the Form stereotype.
This feature helps you more thoroughly understand the responsibilities of each class in your model. Classes with a Form stereotype are responsible for displaying information to the user and receiving information from the user. Classes with the Visual Basic Collection stereotype are responsible for grouping entities together into a dataset or other type of collection. Each stereotype has its own types of responsibilities.
Stereotypes also help in the code−generation process. When Rose generates code, it looks at the class stereotypes to determine what type of class to create in the target programming language.
Rose comes with a number of built−in stereotypes. Some are used during the analysis process, when you haven't yet determined what language you will be using. Others are specific to a particular language, and are used in the detailed design process. These different types of stereotypes are important; they allow you to start assigning responsibilities to classes in the analysis process without tying the model to a specific language.
In this section, we will discuss the stereotypes for analysis and language−dependent design that come with Rose.
Analysis Stereotypes
During analysis, you may want to categorize your classes according to the functions they perform. There are three primary class stereotypes in UML that are used for analysis: boundary, entity, and control.
212
Chapter 6: Classes and Packages
Boundary Classes
Boundary classes are those classes that lie on the boundary between your system and the rest of the world. These would include all of your forms, reports, interfaces to hardware such as printers or scanners, and interfaces to other systems. The UML representation of a boundary class looks like this:
To find and identify boundary classes, you can examine your Use Case diagram. At a minimum, there must be one boundary class for every actor–use case interaction. The boundary class is what allows the actor to interact with the system.
You don't necessarily have to create a unique boundary class for every actor–use case pair. For example, say you have two actors that both initiate the same use case. They might both use the same boundary class to communicate with the system.
213
Chapter 6: Classes and Packages
Entity Classes
Entity classes hold information that you may save to persistent storage. In our airline reservation system, the Flight class is a good example of an entity class. Entity classes are usually found in the flow of events and in Interaction diagrams. They are the classes that have the most meaning to the user and are typically named using business−domain terminology.
Look at the nouns in your flow of events. Many of these nouns will be the entity classes in the system. Another good place to look is in the database structure. If some database design has already been done, look at the table names. An entity class may need to be created for a table. While the table holds a record's information permanently, the entity class will hold the information in memory while the system is running.
In UML, entity classes are represented by the following symbol:
By tying our database design to the object model, we can trace many of the fields in the database back to a requirement. The requirements determine the flow of events. The flow of events determines the objects, the classes, and the attributes of the classes. Each attribute in an entity class may become a field in the database. Using this approach, we can trace each database field back to a requirement and reduce the risk of collecting information no one uses.
Control Classes
Finally, let's take a look at control classes. Control classes are responsible for coordinating the efforts of other classes. They are optional, but if a control class is used, there is typically one control class per use case, which controls the sequencing of events through the use case. On an Interaction diagram, a control class has coordinating responsibilities, as you can see in Figure 6.7.
Figure 6.7: Control class on a Sequence diagram
214
Chapter 6: Classes and Packages
Notice that the control class doesn't carry out any functionality itself, and other classes don't send many messages to it. Instead, it sends out a lot of messages. The control class simply delegates responsibility to the other classes. Control classes are responsible for knowing and carrying out the business rules of an organization. They execute alternative flows and know what to do in case of an error. For this reason, control classes are sometimes called manager classes. In UML, control classes are drawn using the following symbol:
There may be other control classes that are shared among several use cases. For example, we may have a SecurityManager class that is responsible for controlling events related to security. We may have a TransactionManager class that is responsible for coordinating messages related to database transactions. We may have other managers to deal with other common functionality, such as resource contention, distributed processing, or error handling.
These types of control classes can be a good way to isolate functionality that is used across the system. Encapsulating security coordination, for example, into a SecurityManager can help minimize the impact of change. If the sequencing of the security logic needs to change, only the SecurityManager will be affected.
Additional Class Stereotypes
In addition to the stereotypes mentioned above, you can add your own stereotypes to the model. In the Stereotype field, you can enter the new stereotype, and from that point on, it will be available in your current Rose model.
To assign a class stereotype:
1.
Open the class specification window by right−clicking the class and selecting Open Specification.
2.
Select a stereotype from the drop−down list box or type in the stereotype name.
To display the stereotype name on the diagram:
1.
Right−click a class on a Class diagram.
2.
From the shortcut menu, select Options → Stereotype Display → Label. The stereotype name will appear, enclosed in double angle brackets (<< >>), just above the class name.
215
Chapter 6: Classes and Packages
To display the Stereotype icon on the diagram:
1.
Right−click a class on a Class diagram.
2.
From the shortcut menu, select Options → Stereotype Display → Icon.
3.
The representation of the class will change to the appropriate icon. This example shows the icon for an Interface class:
Note Not all of the stereotypes have icons. If there is no icon for a stereotype, only the stereotype name will appear on the diagram.
To turn off the stereotype display on the diagram:
1.
Right−click a class on a Class diagram.
2.
From the shortcut menu, select Options → Stereotype Display → None. The class will still have a stereotype, visible in the class specification window, but the stereotype will not display on the diagram.
To change the default stereotype display option:
1.
Select Tools → Options.
2.
Select the Diagram tab.
3.
In the Compartments area, as shown in Figure 6.8, select or deselect the Show Stereotypes check box to control whether or not the stereotype will display.
216