- •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 18: Rose Data Modeler
So far, we've focused on modeling the application itself—creating the Use Case diagrams, Interaction diagrams, Class diagrams, and other artifacts needed to really understand how the system works. An essential element to nearly every system, however, is some form of persistent storage, typically a database.
Using Rose, you can model not only the application, but also the database or databases that support the application. Rose 2001, 2001A, and 2002 support the data−modeling notation that has been incorporated into UML.
∙
Comparing object models and data models
∙
Creating a data model
∙
Adding logic to a data model
∙
Modeling databases, schemas, tables, fields, stored procedures, triggers, and more
∙
Modeling primary keys, foreign keys, and entity relationships
∙
Modeling views
∙
Generating an object model from a data model
∙
Generating a data model from an object model
∙
Creating the database from a data model
∙
Reverse engineering a database into a data model
Object Models and Data Models
An object model is used for all of the pieces of the application that we have discussed so far—the classes, attributes, operations, relationships, components, and other constructs—except for the data. The primary emphasis of an object model is on memory—what objects will be created in memory, how will these objects communicate, and what is each object responsible for doing? The focus of the data model is, as the name implies, the database rather than the application.
While object modeling is concerned with memory efficiency, data modeling is more concerned with database efficiency. Table 18.1 lists some of the differences in perspective between the data model and the object
610
Chapter 18: Rose Data Modeler
model.
Table 18.1: Concerns in Data Modeling and Object Modeling
Object Model |
Data Model |
How can I design the classes to be memory efficient? |
How can I design the database to be storage efficient? |
What objects need relationships in the object model? |
What tables need relationships in the data model? |
How can I structure the data on the user interface to |
How can I structure the data to speed access times? |
make the most sense to the end user? |
|
How can I package the data with behavior to create |
How can I normalize the data? |
classes? |
|
What data will be used throughout the application, |
What data will be retrieved frequently? |
and what data will be used in only one area? |
|
How can I use generalizations or other design |
How can I incorporate the concept of inheritance into |
strategies to reuse code? |
my data model if my DBMS doesn't directly support |
|
inheritance? |
There is a definite disparity between the data model and the object model. The primary reason for this is the nature of the models themselves; objects are, by definition, focused on behavior and data, while the data model is focused on data. The object model, in most languages, supports inheritance, while the data model does not. Data types in programming languages and database management system (DBMS) packages are different. Join tables do not need to be included in the object model as a general rule (although association classes are sometimes needed). Two classes need to have a relationship if one needs to access attributes or operations of the other; two tables need to have a relationship if there is a logical connection between the data in the two tables. Two entity classes may have a relationship in the object model, but their tables may not be related in the data model.
To account for these natural differences, Rose supports the creation of both an object model and a separate data model. You can create both of these models in a single Rose file so that you have a complete understanding of your application and its database in one place.
So, which comes first: the data model or the object model? In many cases, the two models are developed concurrently. In the Inception phase, the team can develop both a rough data model and a rough object model, or a domain model. As Elaboration and Construction progress, the team can fill in the details of both models. Many of the entity classes from the Class diagrams will become database tables. There is not, however, a one−to−one correspondence. Because of the differences in perspective between the two models, a single
entity class may become two or more database tables. Conversely, a single database table may be supported by two or more classes in the application.
Many projects, especially maintenance projects, begin with some sort of existing data model. Using Rose, you can reverse engineer the existing data model, and you can even automatically generate an object model from it. If you have an object model but no data model, you can automatically generate a data model from your object model.
611
Chapter 18: Rose Data Modeler
Creating a Data Model
In Rose, the Data Model includes constructs in both the Logical view and the Component view. In the Logical view, you can create schemas, which in turn contain stored procedures. You can also create tables, which contain fields, constraints, triggers, primary keys, indexes, and relationships. Finally, you can create domains and domain packages.
In the Component view, you can model the databases themselves. Each database is modeled as a component with a <<database>> stereotype. Rose 2001A and 2002 support DB2, SQL Server, Sybase, Oracle, or ANSI SQL.
The primary steps in the creation of a data model are:
1.
Create a database.
2.
Add a schema to hold the data model and assign the schema to the database.
3.
Create domain packages and domains.
4.
Add tables to each schema.
5.
Add details to the tables (fields, constraints, triggers, indexes, primary key).
6.
Add relationships between the tables and add foreign keys.
7.
Create views.
8.
Create an object model from your data model.
9.
Generate the database.
10.
Keep the database synchronized with the model through the Update feature.
It isn't necessary to follow all of the steps in this order, but creating the database and schema first sets the DBMS that will be used. When you create tables, fields, and other data−modeling elements, the appropriate data types will then be available. In the remainder of this chapter, we will discuss each of these steps. Before we do, however, let's look at what logic might be incorporated into the data model.
612
Chapter 18: Rose Data Modeler
Logic in a Data Model
Database−management systems are becoming more sophisticated every year. It's becoming easier to add logic to the database—so much so that it can be easy to become confused about what logic should go in the
database and what logic should go in the application.
There is no simple way to determine what logic should go where, and a complete analysis of database design principles is outside the scope of this book, but here are some points to consider:
∙
General object−oriented practices suggest keeping at least some of the business logic in an application layer rather than in the database.
∙
In general, only logic related to the data itself should be housed in the database. This would include items such as required fields, valid values for fields, and field lengths.
∙
Many business rules can be enforced directly in the database through the use of constraints. Although the database is an appropriate location for this type of logic, the application must gather information from the end user, pass it through the business layer, and then across a network connection, which may be slow, before the data is validated. Keeping this logic in the business layer can sometimes help reduce unnecessary network traffic.
However, if a number of areas within the application, or even a number of different applications, need to use the same constraint, placing the logic in the database can help ensure that the rule is applied consistently.
∙
Some of the system logic can be carried out directly in the database through the use of stored procedures. There are advantages to this approach; functionality that is very data−intensive might be more appropriate as a stored procedure. If the functionality is strictly data manipulation, programming it as a stored procedure might be significantly faster than loading all the records into memory, having the application do the processing, and then storing the results back to the database.
However, there are some disadvantages to this strategy as well. Using stored procedures to implement any business logic inherently divides the business logic across at least two layers: the business logic layer and the database layer. When business logic changes, you may need to update both of these layers. You also run the risk of duplicate logic across the layers or, even worse, contradictory business logic across the two layers.
Too many stored procedures can also cause difficulties in migrating from one DBMS to another. Many database management packages have slightly different syntax, and migrating from one to another may necessitate rewriting of the stored procedures.
Again, there isn't necessarily an easy way to distinguish between the logic that should reside in the database and the logic that should reside in the application. Once you have decided to place logic in the database, you can model that logic by modeling stored procedures, constraints, and triggers in Rose. First, however, you must create a database and schema.
613