- •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 16: XML DTD Code Generation and Reverse Engineering
Introduction to XML DTD
XML evolved as the need arose to structure data on the Web. HTML is very useful for displaying information, but it contains only a limited number of tags that you can use when creating a document. XML is much more flexible; you can create whatever tags you need to effectively describe the data in the document.
The tags are defined in the DTD file for the XML file. A DTD document is comprised of elements that define the types of data that can be included in the XML file.
Elements
An element is defined in three key pieces. The first is the ELEMENT keyword, which indicates that the text to follow defines an element. The second is the name of the element. Each element name must be unique. Further, XML does not allow an element to begin with the characters "xml" in upper or lower case. Finally, the content model defines the items that make up the element. For example, here we have an element called "book" that is made up of a title, table of contents, introduction, and section.
<!ELEMENT book (title, tableofcontents, introduction, section)>
The title, tableofcontents, introduction, and section make up the content model. An element can also contain text in its content model. We can indicate this by using the notation #PCDATA in the content model. For example:
<!ELEMENT title (#PCDATA)>
Here we have an element called title, which is simply a string of text. An element may contain other elements, text (PCDATA), or both in its content model.
This is useful, but it doesn't let us know whether the items in the content model are required or how many items can be contained within the element. There are three symbols we can use here to get more information:
∙
A plus sign (+) indicates that the item is required and that there may be more than one.
∙
An asterisk (*) indicates that the item is not required and that there may be more than one.
∙
A question mark (?) indicates that the item is not required and that there can be only one.
Using these symbols, we return to our example:
<!ELEMENT book (title+, tableofcontents?, introduction?, section+)>
Our example says that a book must have a title. It may or may not have a table of contents or introduction, and will never have more than one table of contents or introduction. It must have at least one section, but can have more than one.
As you can see, we can get a lot of information about the element by including these three symbols in the content model. They are included in the DTD to spell out the rules that apply to the elements and the items in
542
Chapter 16: XML DTD Code Generation and Reverse Engineering
their content models.
Notice that the items in the content model are separated by commas. Commas indicate that the items must appear in the order they are listed in the content model. Our book must first have a title, then a table of contents, then an introduction, and finally its sections.
In some situations, however, you may want to indicate that there is a choice involved. To show a choice, you can use a choice operator (|). The notation would then be:
<!ELEMENT A (B|C)>
This notation suggests that element A is comprised of B or C.
Attributes
An element may have one or more attributes. An attribute is simply a piece of information about the element. Like attributes in the object model, an entity's attribute has a name, data type, and optional default value.
An attribute is declared using the following notation:
<!ATTLIST ElementName AttributeName DataType DefaultValue>
For example:
<!ATTLIST Author Name CDATA> <!ATTLIST Employee EmpID ID>
If an element has more than one attribute, they are listed as follows:
<!ATTLIST Employee Name CDATA Address CDATA Phone CDATA>
There are three additional keywords that can be added to an attribute. The keyword #REQUIRED indicates that the attribute is mandatory. The #IMPLIED keyword indicates that the attribute is not required. Finally, the #FIXED keyword indicates that the attribute's value cannot change. If the attribute is fixed, it must be given a default value.
To assign a default value to an attribute, enter the value at the end of the attribute declaration. For example:
<!ATTLIST book language CDATA "Spanish">
This declaration assigns the default value "Spanish" to a book's language.
Sometimes you want to set a list of valid values for an attribute. In our example, let's assume books must be in Spanish, English, or Japanese. We would specify this as follows:
<!ATTLIST book language CDATA (Spanish | English | Japanese) "Spanish">
Here, the language must be Spanish, English, or Japanese, and the default is Spanish.
Entities and Notations
An entity is used when you want to use a simple word to represent a more complex string. It is a way to enter
543
Chapter 16: XML DTD Code Generation and Reverse Engineering
a lot of information by simply typing the entity name. Entities help simplify documents and keep you from repetitive typing.
An entity may be internal or external. An internal entity is defined in the DTD. An external entity is defined outside the DTD and corresponding XML document (for example, in another XML document). The SYSTEM keyword indicates that the entity is an external entity. External entities may be parsed or unparsed.
Some examples of entities include text strings, external files, and special characters.
Text Strings
If there is a long text string that is repeated many times, an entity can be used to represent the string. For example, instead of typing "the quick brown fox jumps over the lazy dog," you can just type "&lazydog." The format of this type of entity looks like this:
<!ENTITY EntityName "entity text">
For example,
<!ENTITY lazydog "the quick brown fox jumps over the lazy dog">
We define the entity "lazydog" as the string "the quick brown fox jumps over the lazy dog." Now to use the entity, all we have to do is type an ampersand (&) followed by the entity name. Anywhere we type "&lazydog," the XML parser will replace "&lazydog" with the full phrase.
External Files
An entity can be used to represent an external XML file. In this situation, we need to add the SYSTEM keyword. The entity declaration looks like this:
<!ENTITY EntityName SYSTEM "entity location">
For example, if you have the text from the Declaration of Independence in another file, you can define an entity and use that entity name rather than type all of the text. Our entity declaration would look like this:
<!ENTITY Independence SYSTEM "/independence.xml">
Now all we need to do is use the keyword &Independence wherever we want a reference to the external file.
Special Characters
When you need to use a special character, such as ®, you can define an entity that, when used, will be replaced by that special character. This saves you the headache of trying to remember the decimal value of the special character.
Parsed and Unparsed Entities and Notations
An entity may be parsed or unparsed. A parsed entity is one that follows the rules we described earlier in this section; when the XML parser encounters the entity, it replaces the entity name with the text or file the entity represents.
544
Chapter 16: XML DTD Code Generation and Reverse Engineering
The XML parser will ignore an unparsed entity. So why use unparsed entities? They provide a way to include things such as graphics files, video, audio, or other files that are not in XML format. When the XML parser sees an unparsed entity, it will call an application that can process the entity. For example, it may call an application to run the video, which will have an entity declaration that looks like this:
<!ENTITY MyVideo SYSTEM "C:\Videos\Vacation.vid">
The XML parser knows which application to call on to process the entity because of a construct called a notation. A notation identifies the application to be used to process a particular entity, and provides the application location. A notation is documented as follows:
<!NOTATION NotationName SYSTEM "notation location">
For example:
<!NOTATION Video SYSTEM "C:\MyVideoPlayer.exe">
The picture is almost complete, but we're still missing one piece. How does the XML parser know that the Video notation applies to the MyVideo entity? We need to add one last piece to the entity declaration, to tie it to the Video notation. We use the NDATA keyword, followed by the notation name. So now our example contains the two lines:
<!ENTITY MyVideo SYSTEM "C:\Videos\Vacation.vid" NDATA Video> <!NOTATION Video SYSTEM "C:\MyVideoPlayer.exe">
DTD−to−UML Mapping
When reverse engineering or generating DTD, Rose will map the different DTD constructs to classes with the appropriate stereotype. In the remainder of this chapter, we will discuss in detail how the DTD constructs map to Rose model elements. Table 16.1 lists the XML DTD constructs and their corresponding model elements.
Table 16.1: DTD−to−Rose Mapping
DTD Construct |
Rose Element |
Element |
Class with stereotype DTDElement |
Attribute |
Attribute of element class |
Entity |
Class with stereotype DTDEntity |
Notation |
Class with stereotype DTDNotation |
Empty element type |
Class with stereotype DTDElementEmpty |
Any element type |
Class with stereotype DTDElementAny |
Parsed character element type |
Class with stereotype DTDElementPCDATA |
Content model with items separated by "," |
Class with stereotype DTDSequenceGroup |
Content model with items separated by "&" |
Class with stereotype DTDSet |
Content model with items separated by "|" |
Class with stereotype DTDChoiceGroup |
545