- •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 3: Business Modeling
Alternatively, you can complete the business modeling in iterations. This has the advantage of letting you study the organization without delaying the building of the software system. You do, of course, run the risk of misunderstanding the company and building a software system that doesn't quite meet its needs. Or, you may discover a previously unknown business process later in the game that has a significant impact on the system. These types of risks can typically be controlled, but they are the downfalls of using this type of approach with business modeling.
Business−Modeling Concepts
In this section, we will discuss some of the fundamental concepts of business modeling. Ideas such as business actors, business workers, and activity diagrams will help us understand the organization itself. In this section, we will cover the following concepts:
∙
Business actors
∙
Business workers
∙
Business use cases
∙
Business Use Case diagrams
∙
Communication relationships between business use cases and business actors
∙
Business entities
∙
Activity diagrams
Again, it is important to remember that business modeling does not focus on what will and will not be automated (although that information can be found in the workflows). Instead, it focuses on two areas. First, what are the boundaries of the organization and with whom does it need to communicate? And second, what are the workflows within the organization and how can they be optimized?
Business Actors
A business actor is anyone or anything that is external to the organization but interacts with it. For example, a business actor for your organization might be its customers, its creditors, its investors, or its suppliers. Each of these actors has an interest in the actions of the company.
In UML, a business actor is modeled using the following icon:
66
Chapter 3: Business Modeling
Although the icon looks like a person, a business actor does not need to be an individual. It could represent a group of people or a company. We model business actors to understand who and what needs to interact with the business and how they interact with the business. When we are re−engineering processes or building new systems, we must always keep in mind that the organization must still meet the needs of these external entities. What good would it be to a grocery store to streamline its processes by getting rid of the cash registers? An extreme example, of course, but the idea is the same: We must keep in mind why the business is there in the first place. Modeling business actors helps with this effort.
Business Workers
A business worker is a role within the organization. Notice that business workers are roles, not positions. A single person may play many roles but hold only one position. The benefit of being role−based rather than position−based is that positions tend to change over time, while roles remain fairly constant.
In UML, a business worker is modeled using the following icon:
We model business workers to understand the roles within the business and how these roles interact. By describing each business worker, we can understand what the responsibilities of that role include, what skills are required for that role, and other details. At a minimum, think about the following for a business worker:
∙
What are the worker's responsibilities?
∙
What skills does the worker need to carry out those responsibilities?
∙
With what other workers does it interact?
∙
In what workflows does it participate?
∙
What are the worker's responsibilities within each workflow?
67
Chapter 3: Business Modeling
Business Use Cases
A business use case is a group of related workflows within the organization that provide value to the business actors. In other words, the business use cases tell the reader what the organization does. More specifically, they tell someone what the organization does that provides value to the businesses and individuals that interact with it. The set of all business use cases for an organization should completely describe what the business does.
Examples of business use cases for a retail store might include "Restock Inventory," "Price Products," "Sell Products," "Refund Money," or "Deliver Products." For an e−business, they might include "Register New User," "Create/Modify Order," "Fill Order," "Restock Inventory," or "Cancel Order." An investment house might have "Buy Stock" and "Sell Stock," among others.
A company does not even have to be highly automated to use business modeling. A cattle rancher might have business use cases like "Buy Cattle," "Sell Cattle," "Bottle Milk," or "Replenish Feed."
In UML, we use the following icon for business use cases:
The business use cases are typically named in the format "<verb><noun>," as in "Price Products." This is a good standard to follow for several reasons. It keeps the business use cases consistent, even if multiple analysts are defining them. Also, it makes the use cases easier for the end user to understand. "Price" alone doesn't tell the user much about the business, nor would "Products." Finally, and perhaps most importantly, it keeps the focus on what the business is doing—what it's accomplishing—not just what entities it uses.
Of course, even "Price Products" doesn't tell us much without some details. For each business use case, you will want to create some type of report that lets people know specifically what goes on within the use case. Does a clerk use historical prices to set the current price? Do they use surveys to determine what the customers are willing to pay? Do they do an in−depth study of the prices of each product in Egypt and Turkey and then average the two? Or do they just make up product prices as they go along? We won't know for sure unless the specific workflow is documented somewhere.
The workflow can be documented in a couple of ways. The simplest in some situations is just to create a numbered, step−by−step list of what happens as the use case progresses:
1.
The clerk talks to the manager to obtain a list of all new products to be priced.
2.
The clerk checks the store's purchase records to see how much the store paid for each new item.
3.
The clerk adds 10% to the purchase price to find the item's price.
4.
The clerk gives the new prices to the manager for approval.
5.
68
Chapter 3: Business Modeling
If the manager does not approve, the clerk and manager decide upon new prices.
6.
The clerk creates price tags for each new item.
7.
The clerk places price tags on each new item.
The problem with this approach is that if there is a lot of conditional logic, it can confuse the reader. In the simple example above, the condition is fairly straightforward. Unfortunately, though, the real business world isn't always so simple. A business worker may perform some actions if condition A occurs, others if condition B occurs, and still others if condition C occurs. In this situation, it might be more beneficial to use an activity diagram.
An activity diagram shows in graphical form what the steps are in a workflow, the sequence of the steps, and who is responsible for performing each step. A sample activity diagram for the workflow described above would look like Figure 3.1.
Figure 3.1: Activity diagram
We'll discuss activity diagrams, including the different symbols that appear on the diagram, later in this chapter. For now, just look at the message the diagram is conveying. As before, we can see what the steps are in pricing products, but the graphical representation helps in making these steps easier to read and understand. The difference is even more striking with large and complex workflows.
Business Use Case Diagrams
A Business Use Case diagram shows you the business use cases, business actors, and business workers for an organization and the interactions between them. It gives you a complete model of what the company does,
69