Rational Rose 2000 Class Diagrams

(1)

Rational Rose 2000

Class Diagrams

(2)

Module Objectives

 Define analysis classes. (already done)

 Define view of participating classes (VOPC) class diagram.

 Use Rational Rose to add a class and create a VOPC diagram.

 Run a script auto generate VOPC diagram.

 Run reports to show class instances and

usage.

(3)

Where Are We?

The Analysis and Design Workflow

Classes and class diagram are initially identified and created respectively during the elaboration phase of this workflow. Some classes may be identified as late as the construction phase for use cases that were not previously analyzed.

(4)

Where Are We? – Use Case Analysis

Classes and class diagrams are identified and refined during the activities outlined ahead.

Use case analysis

Identify classes that perform a use case’s flow of events. (analysis classes)

Distribute use case behavior to those classes, using use case realizations.

Identify the responsibilities, attributes, and associations of the classes.

Input artifacts

Glossary • Use case model Supplementary specifications

• Use case realizations Use case modeling guidelines

(5)

Where are we? – We will be doing: - Use Case Design

 Use case design

Replace analysis classes with design subsystems and classes.

 Refine requirements on the operations of subsystems and/or their interfaces.

 Input artifacts

Supplementary specifications Design subsystems

Use cases Interfaces

Use case realizations Design classes

(6)

Then: Subsystem Design

Subsystem design

Define realizations between the subsystem's interfaces and contained classes Document internal structure of the subsystem.

Define realizations between the subsystem’s interfaces and contained classes

Determine dependencies on other subsystems.

Input artifacts

Use case realizations

Design subsystem with interface definitions

(7)

Then Class Design

Class design

Ensures that the class provides the behavior the use case realizations need

Ensures that sufficient information is provided to unambiguously implement the class Handles non-functional requirements related to the class.

Incorporates the design mechanisms used by the class.

Ensures that the class provides the behavior the use case realizations need Input artifacts

Supplementary specifications Use cases Design Guidelines Use case realizations Design classes Design model

(8)

Key Concepts

 Analysis classes

 Represent the prototypical classes of the system.

 Stereotyped as boundary, control, and entity.

 Boundary classes used to model interactions between a system’s surroundings and its inner workings. This class models parts of the system that depend on its surroundings, such as printer interfaces.

 Control classes are used to model control behavior specific to one or a few use cases. Models

parts of the system that are independent of the system’s surroundings.

 Entity – used to model information and associated Behavior that must be stored. Entities represent the key concepts of the system.

As we move to class design, analysis classes may be refined into design classes or drop out entirely.

(9)

Key Concepts: Analysis vs Design Classes

Analysis classes represent functional

requirements of the problem domain.

Design classes represent the non functional requirements of the solution domain.

Again, we move from what the system

should do to how the system will do

it.

(10)

 Class diagram

 VOPC (classes only shown here)

Key Concepts

Class Diagrams:

. Show a set of classes, interfaces, and collaborations and relationships . Modeled to show static view (logical view) of system;

. Primarily supports functional requirements of the system View of Participating Classes:

. A class diagram that shows a use case realization’s participating classes and their relationships. Shows all classes whose instances collaborate to perform use case.

. Ensures consistency in use case implementation across subsystem boundaries.

(11)

 Multiplicity

 Role names

 Aggregation

Key Concepts

Multiplicity: Defines number of objects that participate (and are linked) in relationship;

Aggregation: Specialized form of association where a whole is related to its part(s).

Is known as a ‘part of’ or containment relationship. Has open diamond next to class denoting the aggregate (whole).

Role Names: Can be used instead of association names; Is a noun indicating purpose or capacity wherein one class associates with another; Placed on association near class it modifies; Can be placed on one or both ends of association line.

(Not necessary to use both.)

(12)

Build Classes:

 Objectives

 Add a class.

 Create VOPC class diagram.

 Create a VOPC diagram from a script.

 Run a report to show class instances

 Run a report to show usage.

(13)

Add a Class

Documentation added

Stereotype indicated

Entity class added to browser

In Logical View, right click Design Model; New; Class; type Student (namespace warning) Right click Student; Open Specification; In stereotype list: entity; In Documentation field type: A person enrolled in classes at the university;

Analysis mechanism: persistency, security.

Click OK. Notice what happens to the class in the browser; Keep model open…

(14)

Attribute added Operation added Attributes added to class specification Operations added to class specification

Add a Class (continuing)

Add Attributes: Right click Student; New; type Address over Name

Repeat steps for additional attributes. When done adding attributes, Right click Student class; Open Specs; Click Attributes to view your additions.

Add Operations: Right click Student; New; Click operation, then type: //get tuition over opname. Continue to add additional operations.

At end, Right click Student class, Open Specs, click Operations to view additions.

(15)

Introduction to Rational Rose 2000 v6.5

Create a VOPC Class Diagram

VOPC class diagram added to browser

Add the class diagram

In the browser, expand Logical View, Design Model, and expand Use Case Realizations.

Expand Use Case Realizations – Register for Courses

Right click Register for Courses. New; click Class Diagram (note class diagram symbol.) Type Register for Courses - Basic Flow (VOPC) over NewDiagram.

Double-click on Register for Courses - Basic Flow (VOPC).

The class diagram window is displayed.

(16)

Classes added to diagram

Bird’s eye view

Create a VOPC Class Diagram

Add participating classes

In the browser, drag the RegisterForCoursesForm boundary class onto the diagram.

Repeat step 1 for the remaining classes. Arrange the diagram. Keep model open

For large diagrams like this one, use the bird’s eye view. Click the small hand in the lower right corner of diagram. Now scroll freely around the diagram.

To show class attributes and/or operations, right-click the class. Click Options;

then click Show All Attributions and/or Show All Operations.

(17)

Create a VOPC Class Diagram - more

Unidirectional

associations added

Bi-directional associations Aggregation

Generalization

Add associations and relationships

Make sure all associations and relationships are on your toolbar. (IF not, add them) Add all associations and relationships as appropriate.

Note two bi-directional associations between Schedule & CourseOffering classes.

Bi-directional associations allow information to flow in both directions.

Classes can have more than one message passing between them. You can apply the “by value” adornment to an aggregate relationship between two classes to show that an instance of one class allocates storage for and has within it an instance of the other class.

(18)

Create a VOPC Class Diagram - more…

Multiplicity

added

Role name added

Add role names

Double-click the association between the RegistrationController and Student classes.

The Association Specification is displayed.

In the Role A field, type registrant. Click OK. Note that you’ve used Role A because registrant modifies the Student class.

Repeat steps 1 and 2 for the role name modifying the Schedule class.

(19)

Create a VOPC Class Diagram - more…

Add multiplicity

Double-click the association between the RegistrationController & CourseCatalogSystem The Association Specification is displayed.

Click the Role A Detail tab. In the Multiplicity list, click 1.

Click the Role B Detail tab. In the Multiplicity list, click 0..n. Click OK.

.Common multiplicity indicators

 1 Exactly one 0..1 Zero or one

 0..* Zero or more 5.. 8 Specific range (5, 6, 7, or 8)

 1..* One or more 4..7,9 Specific range (4, 5, 6, 7, or 9)

Multiplicity added

Role name added

(20)

Introduction to Rational Rose 2000 v6.5

Run Script to Generate VOPC Diagram

Green start

arrow is pressed VOPC diagram name added

Run a script to add VOPC diagram

Expand Logical View; Expand Design Model; expand Use Case Realizations;

Double-click Traceabilities.

In the diagram window, click the Register for Course use case realization.

On the Tools menu, click Open Script.

Open C:\RoseSolutions\Scripts, then double-click VOPC.ebs.

.On the toolbar, click the green start arrow to run script. The Class Diagram window is displayed.

Type Register For Courses - Basic Flow (VOPC), then click OK.

In the browser, expand Use Case Realization - Register for Courses VOPC diagram.

(21)

Show Instances

Class selected

Show Instances selected

List of

diagrams is displayed

If your model is large, you may want list of all the interaction diagrams on which a class appears. The Show Instances report is an easy way to view this information.

Run the Show Instances report

Browser; expand the Logical View; expand Design Model; expand Use Case Realizations.

Expand Use Case Realizations - Register for Courses, then expand Register for Courses.

Double-click the Register for Courses - Basic Flow (VOPC) class diagram. Click a class.

On the Report menu, click Show Instances. The Show Instances window is displayed.

Browse through the window to view the interaction diagrams on which the class appears.

(22)

Show Usage

Class selected

Show Usage selected

List of locations is displayed

Again, if your model is large, you may want a list of where a selected element is used in the model. Note that this report can be run for actors, use cases, use case realizations,….

Run the Show Usage report 1. Click a class.

2. On the Report menu, click Show Usage. The Show Usage window is displayed.

3. Browse through the window to view where the selected class is used in the model.

Pause a moment and review our preferred practices.

(23)

Preferred Practices

 Class Design

 Relationships

• Generalization

 Use for “is a” relationships.

 Don’t use simply to make definitions visible, except for

<<interface>> classes.

• Aggregation

 Use for “part of” relationships.

 Don’t use in place of dependency between loosely coupled classes.

• Navigability

 Reduce bi-directional to unidirectional relationships, where possible.

(24)

 Relationships

• Names

 Name roles and/or name associations when meaningful for the associations.

 You don’t need to name everything.

 Name associations or roles, not both.

 Know there are different choices for different associations.

 Multiplicity (cardinality)

• Explicitly, specify multiplicity.

Preferred Practices

(25)

 Completion Specification

• Descriptions

 On creation, enter brief descriptions for all elements—

class, attribute, and operation.

 Use for data dictionary.

 Include to convey a clear purpose to multiple readers.

• Attribute specifications during design

 A type

 A default value, when possible

 Private access (rarely need public access)

Preferred Practices

(26)

 Completion Specification

• Operation specifications during design

 Return type

 Parameter definitions

 Parameter default values

 Limit use of public access

Preferred Practices

Operations

The primary mechanism to access attributes is through operations.

Rose defaults all operations to public access. During analysis, this is appropriate. During design, however, limit the use of public

access to only where it is needed. The more limited the public

interface, the more freedom there is to change the implementation.

(27)

 Dependencies

• Create dependency relationships for

 Attributes whose types is a class use association (field visibility.

 Operations whose return type is a class use dependency (parameter visibility).

 Operations whose parameters are classes’ uses dependencies (parameter visibility).

 Operations whose implementation creates objects of class uses dependencies (local visibility).

Preferred Practices

(28)

 VOPC class diagram

 Create diagram in its use case realization package.

 Create at least one diagram for each use case realization.

 Show classes and relationships needed to support interactions.

Preferred Practices

(29)