Final Umldp Lab Manual

UML & Design Patterns Lab
WEEK – 1
Familiarization with Rational Rose
Theory:
INTRODUCTION TO UML
UML is a language used for visualizing, specifying, constructing and documenting the
artifacts of software intensive system.
UML makes a clear conceptual distinction between models, views and diagrams. A Model is
an element that contains information for a software model. A View is a visual expression of
the information contained in a model, and a Diagram is a collection of view elements that
represent the user’s specific design thoughts.
Building Blocks of UML : Things ,Relationships and diagrams.
Things in UML :
Structural things:
 Classes
 Interfaces
 Collaborations
 Use Cases
 Active Classes
 Components
 Nodes Classes
Behavioral things:
 Interactions
 State machines
Grouping things
 Packages
Annotational things
 Notes
Gayatri Vidya Parishad College of Engineering for Women Page 1

Diagrams in UML :
 Class Diagram
 Object Diagram
 Usecase Diagram
 Sequence Diagram
 Collaboration Diagram
 Statechart Diagram
 Activity Diagram
 Component Diagram
 Deployment Diagram
Class:
A class is the descriptor for a set of objects with similar structure, behavior, and
relationships. It is represented by a rectangle.
Interface:
An interface is a specifier for the externally-visible operations of a class, component,
or other classifier (including subsystems) without specification of internal structure.It is
represented by a circle.
Relations:
 Association
 Dependency
 Generalization
 Realization

In addition to this there are
 Directed Association
 Aggregation and
 Composition
Association:
An association is a structural relationship that specifies the relation between two
objects when they are at the same level (peer level systems).
 An Association can specify the relationship, role of the class and Multiplicty.
 An Association used in class diagram, Component diagram, deployment diagram, usecase
diagrams.
 The multiplicity can be represented as 1-1..*,*,0…1.
It is represented as follows:
Directed Association:
 Links a semantic association between two classes in the UML diagram.
 Directed association is used in class diagram, Component diagram, deployment
diagram, usecase diagrams.
Symbol:
Aggregation:
 Aggregation is used in class diagram.
Symbol:

Composition:

 Composition is used in class diagram.
Symbol:
Generalization:
Generalization is a specification relationship in which objects of the specialized

element (the child ) are substitutable for objects of the generalization element (the parent).It
is used in class diagram.
Symbol:
Dependency:
A dependency is a semantic relationship in which if there is any change occurred in one

object that may effect other object.
 Dependency is used in class diagram, Component diagram, deployment diagram, use

case diagrams.
Symbol:
Realization:
Realization is a Specified tool that can be represented by providing a relationship with

classifier.
 Dependency is used in class diagram, Component diagram, deployment diagram, use case
diagrams.

Symbol:
Class diagrams:
A class diagram is that which represents a set of classes, interfaces and collaborations
and their relationships, graphically a class diagram is a collection of vertices and arcs.
It consists of three compartments.
Name
Attributes
Uses:
A class diagram is used to model the static design view of a system.
Object diagrams:
An object diagram shares the same common properties of all other diagrams.
;Name
Attributes
Uses:
An object diagram is used to model the static design view of a system.
Use Case Diagrams:
An use case diagram shares the common properties as all diagrams. It distinguishes in
the contents of use cases, actors, dependency, generalization relationships.
Actor
Uses:
An Use case diagram is used to model the static design view of a system.

Interaction Diagrams:
An Interaction diagram shares the same common properties as all other diagrams. It
differs in its contents
 Objects
 Links
 Messages
It includes two diagrams – Sequence and Collaboration
Sequence Diagrams:
A sequence diagram emphasizes the time ordering of messages.Sequence diagrams
have two features that distinguish them from collaboration diagrams.
(i) Object life time
(ii)The focus of control
Collaboration Diagrams:
A collaboration diagram emphasizes the organization of the objects that participate in
an interaction
Collaboration diagrams have two features that distinguish them from sequence diagrams.
(i)Path
(ii) The Sequence number
Object:
It is an instance of a class.
Symbol: Object name
Stimulus:
A Stimulus is a communication between two Instances that conveys information with
the expectation that action will ensue. A Stimulus will cause an Operation to be invoked,
raise a Signal, or cause an Instance to be created or destroyed.
Symbol:
It can be annotated by a name. It has a property as Action kind.
Call:

Send:
Return:
Create:
<<create>>
Destroy:
<<destroy>>
Uses:
Interaction diagrams are used to model the dynamic aspects of a system. It is obtained in
two ways:
(i) To model flows of control by time ordering.

(ii) To model flows of control by organization.
State Chart
Diagrams:
State:
A state is a condition during the life of an object or an interaction during which it
satisfies some condition, performs some action, or waits for some event. It is represented by a
rounded rectangle.
Symbol:
State Name

Submachine State:
A submachine state is a syntactical convenience that facilitates reuse and modularity.
It is a shorthand that implies a macro-like expansion by another state machine and is
semantically equivalent to a composite state.
Symbol:
Sub State Name
Initial State:
An initial is a kind of pseudo state that represents the starting point in a region of a
state machine. It has a single outgoing transition to the default state of the enclosing region,
and has no incoming transitions. There can be one (and only one) initial state in any given
region of a state machine. It is not itself a state but acts as a marker.
Symbol:
Final State:
A final state represents the last or "final" state of the enclosing composite state.
There may be more than one final state at any level signifying that the composite state can
end in different ways or conditions. When a final state is reached and there are no other
enclosing states it means that the entire state machine has completed its transitions and no
more transitions can occur.
Symbol:
Junction Point:
Junction Point chains together transitions into a single run-to-completion path. May
have multiple input and/or output transitions. Each complete path involving a junction is
logically independent and only one such path fires at one time. May be used to construct
branches and merges.

Symbol:
Transition:
A transition is a directed relationship between a source state vertex and a target state
vertex. It may be part of a compound transition, which takes the state machine from one state
configuration to another, representing the complete response of the state machine to a
particular event instance.
Symbol:
Activity Diagram:
It represents the different activities in the system.
Action State:
An action state represents the execution of an atomic action, typically the invocation
of an operation. An action state is a simple state with an entry action whose only exit
transition is triggered by the implicit event of completing the execution of the entry action.
The state therefore corresponds to the execution of the entry action itself and the outgoing
transition is activated as soon as the action has completed its execution.
Symbol:
Sub activity State:

A sub activity state represents the execution of a non-atomic sequence of steps that
has some duration; that is, internally it consists of a set of actions and possibly waiting for
events. That is, a sub activity state is a hierarchical action, where an associated sub activity
graph is executed.
Symbol:

Sub Activity Name
Initial State:
An initial is a kind of pseudo state that represents the starting point in a region of a
state machine. It has a single outgoing transition to the default state of the enclosing region,
and has no incoming transitions. There can be one (and only one) initial state in any given
region of a state machine. It is not itself a state but acts as a marker.
Symbol:
FinalState:
A final state represents the last or "final" state of the enclosing composite state. There
may be more than one final state at any level signifying that the composite state can end in
different ways or conditions. When a final state is reached and there areno other enclosing
states it means that the entire state machine has completed its transitions and no more
transitions can occur.
Symbol:
Decision:
A state diagram (and by derivation an activity diagram) expresses a decision when
guard conditions are used to indicate different possible transitions that depend on Boolean
conditions of the owning object.
Component Daigrams:

Package:
A package is a grouping of model elements. Packages themselves may be nested
within other packages. A package may contain subordinate packages as well as other kinds of
model elements. All kinds of UML model elements can be organized into packages.
Symbol:
Interface:
or other classifier (including subsystems) without specification of internal structure.\
Symbol:
Component:
A component represents a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.
Symbol:
Artifact:
An Artifact represents a physical piece of information that is used or produced by a
software development process. Examples of Artifacts include models, source files, scripts,
and binary executable files. An Artifact may constitute the implementation of a deployable
component.
<<artifact>>
Symbol:

Deployment Diagrams:
Package:
A package is a grouping of model elements. Packages themselves may be nested within

other packages. A package may contain subordinate packages as well as other kinds of model
elements. All kinds of UML model elements can be organized into packages.
Symbol:
Node:
A node is a run-time physical object that represents a computational resource, generally
having at least a memory and often processing capability as well, and upon which
components may be deployed.
Symbol:
Node Name
Node Instance:
A node instance is an instance of a node. A collection of component instances may
reside on the node instance.
Symbol:
Node Name
Artifact:

component.
Symbol:
<<artifact>>
Component Diagrams:
Package:
A package is a grouping of model elements. Packages themselves may be nested within other
packages. A package may contain subordinate packages as well as other kinds of model
Symbol:
Interface:
or other classifier (including subsystems) without specification of internal structure.
Symbol:
Component:
A component represents a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.
Symbol:

Artifact:
component.
Symbol: <<artifact>>
Deployment Diagrams:
Package:
A package is a grouping of model elements. Packages themselves may be nested within

other packages. A package may contain subordinate packages as well as other kinds of model
Rational Rose : (Installation)
Step-1: Run Setup file in source folder

Step-2: Select and click on “Install IBM Rational Rose Enterprise Edition”
Step-3: click “Next”

Step-4: Click “Next”

Step-6: Click “Accept”

Step-9: Click “Install”

Step-10: Starting of installing IBM Rational Rose
Step-11: Installation is about to complete

Step-12: click “Next”
Step-13: Click “Browse”

Step-14: Import location of source folder
Step-15: click “Import”

Step-16: File has been successfully imported
Step-17: Following is the IBM Rational License Key Administrator

Step-18: IBM Rational Rose setup has been completed .Click on “Finish”
Introduction to Rational Rose

Introduction:
• ROSE stands for Rational Object-oriented Software Engineering.
• Rational Rose is developed by Rational Corporation which is under IBM.
• Rational Rose is a tool for modeling software systems.
• Rational Rose follows UML.
• Rational Rose is tool that supports round-trip engineering means a tool that supports
conversion of a model to code and from code to a model.
Rational Rose Interface:
Menubar: The menubar consists of several menus like the file menu, edit menu, view menu
etc. All these menus contain several options.
Toolbar: The toolbar contains the most frequently used actions like New, Open, Save etc…
Status bar: The status bar at the bottom displays status messages.

Browser Window: The browser window displays the views: Use Case View, Logical View,
Component View and Deployment View. Each of these views contains the diagrams.
Diagram Toolbar: The diagram toolbar displays the symbols of the respective type of
diagram.
Diagram Window: The diagram window is the place where the user draws the diagrams
using the symbols from the diagram toolbar.
Log Window: This window is used to display error messages, warnings and information
messages.
Documentation Window: This window is used to display the documentation related to the
symbols and other aspects.
Advantages of Rational Rose
• Rational Rose’s main advantage is its flexibility. This flexibility comes in part from its
support for many object-oriented languages including Java, MFC C++, Visual Basic, as well
as Oracle 8i databases.

• Component reuse and a more efficient utilization of software development resources are
additional advantages.
• Supports both round-trip engineering and reverse engineering.
• Round-trip engineering (RTE) is a functionality of software development tool that

synchronizes two or more related software artifacts, such as, source code, models,
configuration files, and other documents.
Disadvantages of Rational Rose
• Code generation is limited to classes only

• No code is generated for interaction diagrams or state diagrams.
• Rose a proprietary s/w so not completely integrated with the Microsoft IDE and other
important development tools.
1. Use Case Diagram
Creating actors
1. Right-click on the Use Case View package in the browser to make the shortcut menu
visible.
2. Select the New:Actor menu option. A new actor called New Class is placed in the browser.
3. With the actor called New Class selected, enter the desired name of the actor.
Documenting Actors
1. If the documentation window is not visible, open the documentation window by selecting
the Documentation menu choice from the View menu.
2. Click to select the Actor in the browser.
3. Position the cursor in the documentation window and enter the documentation.

Creating use cases
1. Right-click on the Use Case View in the browser to make the shortcut menu visible.
2. Select the New: Use Case menu option. A new unnamed use case is placed in the browser.
3. With the use case selected, enter the desired name of the use case.
Creating a use case brief description
1. Click to select the use case in the browser.

2. Position the cursor in the documentation window and enter the brief description for the use
case. If the documentation window is not visible, select the View: Documentation menu
choice to make the window visible.
Linking flow of events documents to use cases
1. Right-click on the use case in the browser to make the shortcut menu visible.
2. Select the specification menu option.
3. Select the Files tab.
4. Right-click to make the shortcut menu visible.
5. Select the Insert File menu option.
6. Browse to the appropriate directory and select the desired file.
7. Click the Open button.
8. Click the OK button to close the specification.
Creating the Main Use Case diagram
1. Double-click on the Main diagram in the use case view in the browser to open the diagram.
2. Click to select an actor in the browser and drag the actor onto the diagram.
3. Repeat step 2 for each additional actor needed in the diagram.
4. Click to select a use case in the browser and drag the use case onto the diagram.
5. Repeat step 4 for each additional use case needed in the diagram.

Note: Actors and use cases may also be created directly on a use case diagram by using the
toolbar.
Creating Communicates Associations
1. Click to select the association icon or the Unidirectional Association icon from the toolbar.
Note: if the association icon is not present on the toolbar, it may be added by right clicking
on the toolbar, selecting the Customize menu choice from the shortcut menu, and adding the
icon to the toolbar.
2. Click on an actor initiating a communication and drag the association line to the desired
use case.
To add the Communicates stereotype (optional):
1. Double-click on the association line to make the Specification visible.
2. If this is the first time the stereotype is being used, enter Communicates in the Stereotype
field. If a Communicates stereotype has already been created, click the arrow in the
Stereotype field to make the drop-down menu visible and Select Communicates.

4. Right-click on the association line to make the shortcut menu visible.
5. Select the Show Stereotype menu choice.
6. Repeat the preceding steps for each additional association relationship.
Creating Uses relationships
1. Click to select the Generalization icon from the toolbar.

2. Click on the using use case and drag the Generalization icon to the used use case.
3. Double-click on the generalization arrow to make the Specification visible.
4. If this is the first time a uses relationship is being created, enter Uses in the Stereotype
field. If a Uses stereotype has been created, click the arrow in the Stereotype field to make
the drop-down menu visible and select Uses.
5. Click the OK button to close the Specification.
6. Right-click on the generalization arrow to make the shortcut menu visible.

Creating Extends Relationships
1. Click to select the Generalization icon from the toolbar.

2. Click on the use case containing the extended functionality and drag the Generalization
icon to the base use case.
3. Double-click on the generalization arrow to make the Specification visible.
4. If this is the first time an extends relationship is being created, enter Extends in the
Stereotype field. If an Extends stereotype has already been created, click the arrow in the
Stereotype field to make the drop-down menu visible and select Extends.
6. Right-click on the generalization arrow to make the shortcut menu visible.
Creating Additional Use Case Diagrams
1. Right-click on the Use Case View in the browser to make the shortcut menu visible.

2. Select the New: Use Case Diagram menu option.
3. While the use case diagram is selected, enter the name of the use case diagram.
4. Open the diagram and add actors, use cases, and interactions to the diagram as needed.
2. Class Diagram
Creating Classes in the Rose browser
1. Right-click to select the Logical View in the browser.

2. Select the New: Class menu choice. A class called New Class is placed in the browser.
3. While the new class is still selected, enter the name of the class.
Creating Stereotypes for Classes in Rational Rose
1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the Specification menu choice.
3. Select the General tab.
4. Enter the name of the stereotype.

Documenting Classes
1. Click to select the class in the browser.

2. Position the cursor in the documentation window and enter the documentation for the class.
Creating packages in the Rose browser
1. Right-click to select the Logical View in the browser.

2. Select the New:Package menu choice.
3. While the package is still selected, enter the name of the package.
Relocating Classes in the Rose browser 1.
1. Click to select the class in the browser.

2. Drag the class to the desired package.

3. Repeat the steps for each class that is to be relocated.
The main Class Diagram
Rose automatically creates the Main class diagram in the Logical View of the model.
To add packages to the Main class diagram:
1. Double-click on the Main diagram in the browser to open it.
2. Click to select the package in the browser.
3. Drag the package onto the diagram.
4. Repeat the preceding steps for each package that is to be added to the diagram.
Creating a Package Main Class Diagram
1. Double-click on the package on a class diagram.

2. Rose will open the package and create (or display) the Main class diagram for the package.
3. Click to select a class in the browser and drag the class onto the diagram.
4. Repeat step 3 for each additional class that is to be placed on the diagram.
Creating a View of Participating Classes
1. Right-click on the use case in the browser to make the shortcut menu visible.
2. Select the New:Class Diagram menu choice.
3. While the diagram is still selected, enter the name of the class diagram.
4. Double-click on the diagram in the browser to open the diagram.
5. Click to select a class in the Logical view of the browser and drag the class onto the
diagram.
6. Repeat step 5 for each additional class that is to be placed onto the diagram.

To Set the Visibility Display

1. Select the Tools: Options menu choice.
2. Select the Diagram tab.
3. Select the Show Visibility checkbox to set the default to show the visibility of all classes.
To set the visibility for a selected class:
1. Right-click to select the class on a diagram and make the shortcut menu visible.
2. Click to select or deselect the Show Visibility menu choice.
To Show the Stereotype
1. Right-click on the class in a class diagram to make the shortcut menu visible.

Creating an Association Relationship
1. Click to select the association icon from the toolbar.

2. Click on one of the associated classes in a class diagram.
3. Drag the association line to the other associated class
Creating an Aggregation Relationship
1. Select the aggregation icon from the toolbar.

2. Click on the class playing the role of the “part” in a class diagram and drag the aggregation
line to the class playing the role of the “whole”.
Naming Relationships
1. Click to select the relationship line on a class diagram.

2. Enter the name of the relationship.
Creating Role Names
1. Right-click on the relationship line near the class that it modifies to make the shortcut
menu visible.
2. Select the Role Name menu choice.
3. Enter the name of the role.
Creating Multiplicity
1. Double-click on the relationship line to make the Specification visible.

2. Select the Detail tab for the role being modified (Role A Detail or Role B Detail).
3. Enter the desired multiplicity.

Creating a Reflexive Relationship
1. Select the association (or aggregation) icon from the toolbar.

2. Click on the class and drag the association (or aggregation) line outside the class.
3. Release the mouse button
4. Click and drag the association (or aggregation) line back to the class.
5. Enter the role names and multiplicity for each end of the reflexive association (or
aggregation).
Creating Package Relationships
1. Select the dependency relationship icon from the toolbar.

2. Click on the dependent package and drag the arrow to the package it depends upon.
Documenting Operations
1. Click the + next to the class in the browser to expand the class.

2. Click to select the operation.
3. Position the cursor
Creating Attributes
1. Right-click to select the class in the browser and make the pop-up menu visible.
2. Select the New:Attribute menu choice. This will create an attribute called Name in the
browser.
3. With the new attribute selected, enter the desired name.
Documenting Attributes
1. Click the + next to the class in the browser to expand the class
2. Click to select the attribute.
3. Position the cursor in the documentation window and enter the documentation for the
attribute.
Creating a Class diagram to show the Attributes and Operations for a Package
1. Right-click to select the package in the browser and make the shortcut menu visible.
2. Select the New:Class Diagram menu choice. A class diagram called NewDiagram will be
added to the browser.
3. With the new diagram selected, enter the name of the diagram.
Adding Classes to a Diagram Using the Query Menu

2. Select the Query: Add Classes menu choice.
3. Select the desired package.
4. Click to select the desired classes and click the >>> button to add the classes to the
diagram or click the All >> button to add all the classes to the diagram.

Filtering Relationships

2. Select the Query:Filter Relationships menu choice.
3. Click the None button in the Type field to hide all relationships shown on the open
diagram.
4. Click the OK button to close the Relations window.
Displaying some Attributes or Operations
1. Right-click to select the class on an opened class diagram and make the shortcut menu
visible.
2. Select the Edit compartment menu choice.
3. Click to select the attributes and operations to be displayed.
4. Click the >>>> button.
5. Click the OK button to close the Edit Compartment window.
Showing all Attributes and Operations
1. Right-click on the class in the class in a diagram to make the shortcut menu visible.
2. Select the Show All Attributes menu choice to display all the attributes for the class.
3. Repeat step 1 and select the Show All Operations menu choice to display all the operations
for the class.

Note: to always display the attributes and operations for a class, you can set the Show All
Attributes and Show All Operations selections using the Tools: Options menu.

Creating Association Classes
1. Click to select the class icon from the toolbar.

2. Click on the diagram to place the class.
3. With the class selected, enter the name of the class.
4. Add the attributes and operations to the class.
5. Click to select the Link attribute icon from the toolbar.
6. Click on the association class and drag the link attribute line to the association it modifies.
7. Create any additional relationships for the association class.
Creating Inheritance
1. Open the class diagram that will display the inheritance hierarchy.
2. Click to select the class icon from the toolbar and click on the open class diagram to draw
the class.
3. With the class still selected, enter the name of the class.
Note: The class could also be created in the browser and added to the opened class diagram.
4. Click to select the Generalization icon on the toolbar.
5. Click on a subclass and drag the generalization line to the superclass.
6. Repeat step 5 for each additional subclass.
Creating an Inheritance Tree
1. Open the class diagram that will display the inheritance hierarchy.
2. Click to select the class icon from the toolbar and click on the opened class diagram to
draw the class.
3. With the class still selected, enter the name of the class.
Note: The class could also be created in the browser and added to the opened class diagram.
4. Click to select the Generalization icon on the toolbar.
5. Click on one subclass and drag the generalization line to the superclass.
6. For each subclass that is part of the inheritance tree, select the Generalization icon from the
toolbar, click on the subclass, and drag the generalization line to the inheritance triangle.

Note: an inheritance tree may be created from two separate generalization arrows by
selecting one arrow and dragging it onto the other arrow.
Relocating Attributes and Operations
1. Click the + sign next to one subclass in the browser to expand the class.
2. Select the attribute or operation to be relocated.
3. Drag the attribute or operation to the superclass.
4. Delete the attribute or operation from all other subclasses.
5. Repeat steps 2 through 4 for each additional attribute or operation to be relocated.
Creating Parameterized Classes
1. Click to select the Parameterized class icon from the toolbar. You may have to add this
icon to the toolbar using the Customize option.
2. Click on a class diagram to place the parameterized class.
3. While the parameterized class is still selected, enter its name.
4. Right-click to select the class in the browser or on a class diagram.
6. Select the Detail tab.
7. Right-click on the Formal Arguments field to make the pop-up menu visible.
8. Select the Insert menu choice, which will insert a formal argument with a name of arg
name and a type of arg type
9. With the arg name selected, enter the name of the formal argument.
10. Click to select the arg type and enter the type of the formal argument.
11. Repeat steps 7 through 10 for each argument.

Creating Instantiated Parameterized Classes
1. Click to select the class icon from the toolbar.

2. Click on the class diagram to place the class.
3. With the class still selected, select the Edit: Change Into: Instantiated Class menu choice.
4. Right-click on the instantiated class to make the pop-up menu visible.
7. Right-click on the Actual Arguments field to make the pop-up menu visible.
8. Select the Insert menu choice, which will add an argument with name = argname and type
= argtype.
9. With the argname still selected, enter the name of the argument.
10. Click to select the argtype and blank it out.
11. Repeat steps 7 through 10 for each actual argument.
13. Click to select the Dependency icon from the toolbar.
14. Draw a dependency relationship between the instantiated class and the parameterized
class.

15. Add relationships to the instantiated class as needed.
Setting Attribute Data Types and Initial Values
1. Right-click to select in the browser or on a class diagram and make the shortcut menu
visible.
3. Select the Attributes tab.
4. Attributes will have a data type set to type and an initial value set to initval. Click to select
the type or initval and place the field in edit mode.
5. Enter the desired data type or initial value.
Setting Operation Signatures
1. Right-click to select a class in the browser or on a class diagram and make the shortcut
menu visible.

3. Select the Operations tab.
4. Double-click on an operation to make the Operation Specification visible.
5. Enter the return class on the General tab.
6. Select the detail tab.
7. Right-click on the Arguments field to make the shortcut menu visible.
8. Select the Insert menu choice. This will add an argument. Enter the name, data type, and
default value for the argument.
9. Click the Ok button to close the Operation Specification.
10. Click the Ok button to close the Class Specification.
Note: Attribute and Operation detail may also be set on a class diagram by selecting the
displayed item and using the following format: attribute: type = initial value
operation (argname: argtype = default): return class .
Creating Virtual Operations
1. Click the + next to the class in the browser to expand the class.
2. Right-click on the operation to make the shortcut menu visible.
4. Select the cg tab.

5. Click to select the value for the property Operation Kind. This will place the value in edit
mode.
6. Select virtual to make the operation virtual. Select abstract to make the operation pure
virtual.
3. Interaction Diagrams
Creating a Sequence Diagram
1. Right-click to select the use case in the browser and make the shortcut menu visible.
2. Select the New: Sequence Diagram menu choice. An unnamed sequence diagram is added
to the browser.
3. With the new sequence diagram selected, enter the name of the sequence diagram.
Creating Objects and Messages in Sequence Diagrams
1. Double-click on the sequence diagram in the browser to open the diagram.

2. Click to select the actor in the browser.

Creating Collaboration Diagrams from Sequence Diagrams
1. Double-click on the sequence diagram in the browser to open the diagram.

2. Choose the Browse:Create Collaboration Diagram menu choice or press the F5 key.
3. Rearrange the objects and messages on the diagram as needed.
4. State Transition Diagram
Creating State Transition Diagrams
1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the State Diagram menu choice. This will automatically create and open the
diagram.
3. To open the diagram at another time, click the + to expand the class in the browser, and
double-click on its state transition diagram in the browser.
Creating States
1. Click to select the state icon from the toolbar

2. Click to place the state on the state transition diagram.
3. With the state still selected, enter the name of the state.
Creating State Transitions
1. Click to select the state transition icon from the toolbar.

2. Click to select the originating state on the state transition diagram.
3. Drag the state transition to the successor state.
4. If the state transition is a named transition, enter the name while the state transition arrow
is still selected.

Creating Start States
1. Click to select the start icon from the toolbar.

2. Click on the state transition diagram to draw the start icon.
4. Click on the start icon and drag the arrow to the desired state.
Creating Stop States
1. Click to select the stop icon from the toolbar.

2. Click on the state transition diagram to draw the stop icon.
4. Click on the stop icon and drag the arrow to the desired state.
Adding State Transition Details
1. Right-click on the state transition arrow to make the shortcut

2. Select the specification menu choice.
4. Enter the action, guard, and/or the event to be sent.

Creating Entry Actions, Exit Actions, and Activities
1. Right-click on the state to make the shortcut menu visible.

2. Select the specification menu choice.
4. Right-click on the Action field to make the shortcut menu visible.
5. Select the Insert menu choice. This will create an action called entry.
6. Double-click on entry to make the Action Specification visible.
7. Select the type of action: simple or send event.
8. Enter the action or send event information.
9. Select when the action should occur: on entry, on exit, entry until exit, or upon event.
10. Click the OK button to close the Action Specification.
11. Click the OK button to close the State Specification.

5.Architectural Diagrams
Making a Package Global
1. Right-click to select the package on a class diagram.

4. Click to select the global checkbox.

Creating Component View Packages
1. Right-click to select the Component View package on the browser and make the shortcut
menu visible.
2. Select the New: Package menu choice. This will add an item called New Package to the
browser.
3. With the New Package still selected, enter the name of the package.
The Main Component Diagram
1. Double-click on the Main Diagram under the Component View package on the browser to
open the diagram.
2. Click to select a package and drag the package onto the diagram.
3. Repeat step 2 for each additional package.
4. Dependency relationships are added by selecting the dependency icon from the toolbar,
clicking on the package representing the client, and dragging the arrow to the package
representing the supplier.

Mapping Logical Packages to component Packages
1. Right-click to select the component package on the browser and make the shortcut menu
visible.
3. Select the Packages tab.
4. Right-click to select the logical package and make the shortcut menu visible.
5. Select the Assign menu choice.
Creating Components
1. Open a component diagram.

2. Click to select the Package Specification icon on the toolbar.
3. Click on the diagram to place the component. This will also add the component to the
Browser.
4. While the component is still selected, enter the name of the component.
Mapping Classes to Components
1. Right-click to select the component on the browser and make the shortcut menu visible.
3. Select the Classes tab.
4. Right-click to select the class and make the shortcut menu visible.
5. Select the assign menu choice.

Creating the Deployment Diagram
1. Rose automatically creates the deployment diagram. To open the diagram, double-click on
the Deployment Diagram on the browser.
2. To create a node, click to select the Processor icon, and click on the diagram to place the
node.
3. With the node still selected, enter the name of the node.
4. To create a connection between nodes, click to select the connection icon from the toolbar,
click on one node on the deployment diagram, and drag the connection to the other node.
Setting Aggregation Containment
1. Right-click on the aggregation diamond to make the shortcut menu visible.

2. Select the desired containment: By value or By Reference.
Creating Dependency Relationships
1. Click to select the dependency relationship icon on the toolbar.

2. Click on the class playing the role of the client.
3. Drag the dependency relationship line to the class playing the role of the supplier.
Code generation Steps
1. Create Needed Property Sets

2. Create Body Components in the Component Diagram
3. Attach Property Sets to Classes
4. Select the Components and Generate the Code
5. Evaluate the Code Generation Errors
Reverse Engineering Steps
1. Create a project
2. Add Project Caption
3. Add Referenced Libraries and Base Projects
4. Set the File Type and Analyze the Files
5. Evaluate the Errors
6. Select Export Options and export to Rose 7. Update Rose Model.

WEEK – 2
a ) Identify and Analyze Events.
Theory:
Event:
An event is an occurrence at a specific time and place that can be described and
should be remembered by the system. Events drive or trigger all processing that a system
does, so listing events and analyzing events makes sense when you need to define system
requirements by identifying use cases.
Event Decomposition is a technique analysts use to identify use cases by first

focusing on the events a system must respond to and then looking at how the system
responds. The initial view helps keep your focus on a high-level view of the system rather
than on the inner workings of the system. The external focus on events is appropriate when
working with users. Focusing on events gives you a way to divide the system requirements
into use cases so you can study each separately.
The importance of the concept of events for defining system requirements was first
emphasized for modern structured analysis when this concept was adapted to real-time
systems in the early 1980s. Use cases for business systems are now identified by using the
event decomposition approach.
Types of Events:
There are three types of events to consider:
1) External Events
2) Temporal Events
3) State Events
External Event:
An external event is an event that occurs outside of the system, usually initiated by an
external agent. An external agent is a person or organizational unit that supports or receives
data from the system, not necessarily the system user. To identify the external events, the

analyst first tries to identify all of the external agents that might want something from the
system.
When describing external events, analysts need to name the event so that the external
agent is clearly defined. The description should also include the action that the external agent
wants to pursue. Important external events can also result from the wants and needs of people
or organizational units inside the company.
Another type of external event occurs when external entities provide new information
that the system simply needs to store for later use.
Temporal Events:
A second type of event is a temporal event, an event that occurs as a result of reaching
a point in time.Many information systems produce outputs at defined intervals, such as
payroll systems that produce a paycheck every two weeks.
These events are different from external events in that the system should
automatically produce the required output without being told to do so.
Temporal events do not have to occur on a fixed date. They can occur after a define
period of time has elapsed.
State Events:
A State Event is an event that occurs when something happens inside the system that
triggers the need for processing.
Often State Events occur as a consequence of external events. Sometimes they are
similar to Temporal Events, except that the point in time cannot be defined.
Identifying Events:
Events Versus Prior Conditions and Responses
It is sometimes difficult to distinguish between an event and part of a sequence of

prior conditions that leads up to the event. In other situations it is not easy to distinguish
between an external event and the system’s response.

The way to determine whether an occurrence is an event or part of the interaction
following the event is by asking whether any long pauses or intervals occur.
The Sequence of Events:
Tracing a Transaction’s Life Cycle
It is always useful in identifying events to trace the sequence of events that might
occur for a specific external agent.
Technology-Dependent Events and System Controls
Sometimes the analyst is concerned about events that are important to the system but
do not directly concern users or transactions. Such events typically involve design choices or
system controls. When defining requirements, the analyst should temporarily ignore these
events. They are important for the design discipline, however.
Events that affect design issues include external events that involve actually using the
physical system, such as logging on. Most of these events include system controls, which are
checks or safety procedures put in place to protect the integrity of the system.
One technique used to help decide which events apply to controls is to assume that
technology is perfect. The perfect technology assumption states that events should be
included during the definition of requirements only if the system would be required to
respond under perfect conditions.

Analysis:
LIBRARY MANAGEMENT SYSTEM
External Events:
• Student wants to check book availability.
• User requests for books.
• Librarian issues books.
• User returns books.
• Librarian collects fine.
• User pays fine.
• User requests catalog.
• Librarian creates new catalog.
• Librarian makes order for books.
• Supplier receives order.
• Librarian checks order status.
• Librarian makes payment.
• Supplier receives payment.
• Librarian updates catalog.
Temporal Events:
• Time taken to return book.

• Time to collect order from vendor.
• Time to produce catalog activity reports.
• Time to produce user activity reports.
• Time to produce transaction summary reports.

WEEK – 2
b ) Identify Use Cases.
Theory:
Use Case Diagrams
Use case diagrams are a set of use cases, actors and their relationships. They
represent the use case view of a system.A use case diagram is a graphic depiction of the
interactions among the elements of a system.
Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. So when a
system is analyzed to gather its functionalities use cases are prepared and actors are
identified.
So in brief, the purposes of use case diagrams can be as follows:
 Used to gather requirements of a system.

 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interacting among the requirements are actors.
Actor:
An actor specifies a role played by a user or any other system that interacts with the
subject.
Primary Actor:
The primary actor of a use case is the stakeholder that calls on the system to deliver
one of its services. It has a goal with respect to the system – one that can be satisfied by its
operation. The primary actor is often, but not always, the actor who triggers the use case.
Supporting Actors:
A supporting actor in a use case in an external actor that provides a service to the
system under design. It might be a high-speed printer, a web service, or humans that have to
do some research and get back to us.

Secondary Actors:
Secondary actors may or may not have goals that they expect to be satisfied by the
use case, the primary actor always has a goal, and the use case exists to satisfy the primary
actor.
Use Case:
A use case is a methodology used in system analysis to identify, clarify, and

organize system requirements. The use case is made up of a set of possible sequences of
interactions between systems and users in a particular environment and related to a particular
goal. It consists of a group of elements (for example, classes and interfaces) that can be used
together in a way that will have an effect larger than the sum of the separate elements
combined. The use case should contain all system activities that have significance to the
users. A use case can be thought of as a collection of possible scenarios related to a particular
goal, indeed, the use case and goal are sometimes considered to be synonymous.
Use cases can be written in different formats and levels of formality:
Brief: It is a one paragraph summary, usually of the main success scenario.
Casual: It is an informal paragraph format. Here multiple paragraphs covers various formats.
Fully dressed: In this all the steps and variations are written in detail, and there also
supporting sections like preconditions and success guarantees.
Use case Diagrams Relationships:
When it comes to drawing use case diagrams one area many struggle with is
showing various relationships in use case diagrams. In fact many tend to confuse
<<extend>>, <<include>> and generalization.
There can be 5 relationship types in a use case diagram.
 Association between actor and use case

 Generalization of an actor
 Extend between two use cases
 Include between two use cases
 Generalization of a use case

Association Between Actor and Use Case

This one is straightforward and present in every use case diagram. Few things to
note.
 An actor must be associated with at least one use case.

 An actor can be associated with multiple use cases.
 Multiple actors can be associated with a single use cases
Different ways association relationship appears in use case diagrams.
Generalization of an Actor:
Generalization of an actor means that one actor can inherit the role of an other actor. The
descendant inherits all the use cases of the ancestor. The descendant have one or more use
cases that are specific to that role.
Lets expand the previous use case diagram to show the generalization of an actor.

Extend Relationship Between Two Use Cases:
Many people confuse the extend relationship in use cases. As the name implies it
extends the base use case and adds more functionality to the system. Here are few things to
consider when using the <<extend>> relationship.
Extend relationship in use case diagrams
 The extending use case is dependent on the extended (base) use case. In the below
diagram the “Calculate Bonus” use case doesn’t make much sense without the
“Deposit Funds” use case.
 The extending use case is usually optional and can be triggered conditionally. In the
diagram you can see that the extending use case is triggered only for deposits over
10,000 or when the age is over 55.
 The extended (base) use case must be meaningful on its own. This means it should
be independent and must not rely on the behaviour of the extending use case.
Although extending use case is optional most of the time it is not a must. An
extending use case can have non optional behaviour as well. This mostly happens when your

modelling complex behaviours.
For example in an accounting system one use case might be “Add Account Ledger
Entry”. This might have extending use cases “Add Tax Ledger Entry” and “Add Payment
Ledger Entry”. These are not optional but depend on the account ledger entry. Also they have
their own specific behaviour to be modelled as a separate use case.
Include Relationship Between Two Use Cases:
Include relationship show that the behaviour of the included use case is part of the
including (base) use case.
The main reason for this is to reuse the common actions across multiple use cases.
In some situations this is done to simplify complex behaviours. Few things to consider when
using the <<include>> relationship.
Includes is usually used to model common behaviour
 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.

Analysis:

 Search for availability
 Request books
 Return books
 Pay fine
 Update catalog
 Manage Library
 Order Books
 Pay amount

WEEK – 2
c ) Develop event table:

Theory:
Event Table :
A catalogue of use cases that lists events in rows and key pieces of information about
each event in columns is an event table. Each row in the table records information about one
event and its use case. Each column in the table represents a key piece of information about
that event and use case.
An event table consists of the following: event, trigger, source, use case, response and
destination.
Event:
An event is the specification of a significant occurrence that has a location in time and
space. Anything that happens is modelled as an event. In the context of state machines, an
event is an occurrence of a stimulus that can trigger a state transition of an object or a group
of objects. Events can, but do not necessarily, cause state transitions from one state to another
in state machines represented by state machine diagrams.
There are three types of events. They are:
 External events: these are the events that pass between the system and its actors.
 Internal events: these are the events that pass among the objects that live inside the
system.
 Temporal events: these are the events that pass through or produced by time.
Trigger:
A signal that tells the system that an event has occurred, either the arrival of data
needing processing or a point in time. It is a named element which is used to relate specific
event to a behaviour that may affect an instance of the classifier.
Events may cause execution of behaviours. A trigger specifies the event that may

trigger a behaviour execution. Each trigger is associated with exactly one event.
Source:
An external agent that supplies data to the system is source.
Use case:
It is a list of actions or event steps defining the interactions between a role (actor) and
a system to achieve a goal.
Response:
An output, produced by the system that goes to a destination is response.
Destination:
An external agent that receives data from the system is destination. It is the place
where any response (output) is sent, again an external event.
Analysis:
S.N DESTINATIO
O EVENT TRIGGER SOURCE USE-CASE RESPONSE N
user should enter user registration of user will get
1 user LMS
register details the user credentials
enter user
user should should be valid
2 id, user user login LMS
login user
password
user search
book
for book search for
3 user availability user
availability inquiry book
details
of book
user request request
request for
4 for book issue status user request details LMS
book
details
viewing
user view history book status
5 user history of user
history details details
book
request
user request request for book request
6 book user LMS
for librarian book details
details

librarian issue issue book issue of book user gets

7 LMS user
book to user details to user requested book
librarian
catalog update updated catalog
8 update LMS LMS
details catalog details
catalog
librarian request requested
due book
9 request book book LMS books for vendor
details
for vendor details vendor
supply
vendor supply books supplied book
10 book vendor catalog
supply books to library details
details
librarians paying
pays payment money for
11 LMS money details vendor
money for details books
books receive
d
book
show book showing book status
12 status LMS user
status book status details
detail
s
user apply renewal applying for book renewal
13 user LMS
for renewals details renewal details
checking
librarian check checking due
14 due LMS status of LMS
for due date details
details due date
returnin
user returns return book book status
15 g book user LMS
book to library details
details
librarian
fine calculating
16 calculates LMS fine details LMS
details fine
fine
fine paying fine to fine payment
17 user pays fine user LMS
details librarian details
payment is acknowledge
payment
payment correct or not m ent
18 acknowledgm LMS -
details paymen
ent
t details

WEEK – 3
a ) Identify & Analyze Domain Classes.
Theory:
Domain Class
A domain class or domain model is a visual representation of conceptual classes or

real situation objects in a domain. These are also called as conceptual models or domain
object models and analysis object models.
Each domain class denotes a type of object. It is a descriptor for a set of things that
share common features. Classes can be:-
 Business objects - represent things that are manipulated in the business e.g. Order.
 Real world objects – things that the business keeps track of e.g. Contact, Site.
 Events that transpire - e.g. sale and payment.
A domain model illustrates conceptual classes or vocabulary in the domain and a

conceptual class is an idea , thing or an object.
It may be considered in terms of its symbol , intention and extension.

 Symbol denotes the words or images representing a conceptual class.
 Intention denotes the definition of a conceptual class.
 Extension denotes the set of examples to which the conceptual class applies.
How to Identify Domain Classes
1) Reuse an existing domain model

There are many published, well-crafted domain models.
2)Use a conceptual class category list
Make a list of all candidate conceptual classes
3) Identify noun phrases
Identify nouns and phrases in textual descriptions of a domain ( use cases, or other
documents)

Conceptual Class Category List
Start the creation of a domain model by making a list of candidate conceptual

classes. Table contains many common categories that are usually worth considering, though
not in any particular order of importance. Examples are drawn from the store and airline
reservation domains.
Identify noun phrases
Another useful technique (because of its simplicity) suggested in [Abbot83] is

linguistic analysis: identify the nouns and noun phrases in textual descriptions of a domain,
and consider them as candidate conceptual classes or attributes.
Care must be applied with this method; a mechanical noun-to-class mapping isn't possible,
and words in natural languages are ambiguous. Nevertheless, it is another source of
inspiration. The fully dressed use cases are an excellent description to draw from for this
analysis .
Vision and Scope, Glossary and Use Cases are good for this type of linguistic
analysis
Noun phrases may also be attributes or parameters rather than classes:
If it stores state information or it has multiple behaviours, then it’s a class

If it’s just a number or a string, then it’s probably an attribute
The domain model is a visualization of noteworthy domain concepts and vocabulary.

Where are those terms found? In the use cases. Thus, they are a rich source to mine via noun
phrase identification.

Some of these noun phrases are candidate conceptual classes, some may refer to
conceptual classes that are ignored in this iteration and some may be attributes of conceptual
classes.
A weakness of this approach is the imprecision of natural language; different noun

phrases may represent the same conceptual class or attribute, among other ambiguities.
Nevertheless, it is recommended in combination with the Conceptual Class Category
Listtechnique.
Analysis:

Accounting We know who they are. No need to store
Bank Only one of them. No need to store
CatLog Yes, we need to recall them
CatLog Activity Reports An output that can be performed from another information
CatLog Details Same as CatLog? Or same as books in CatLog? Research
Change Request An input resulting in remembering changes to an order
Confirmation An output produced from another information
Credit Card Information Part of an order? Or part of Librarian
Librarian Account Possibly required if an RMO payment plan is included. Research
Librarian Yes, a key thing with lots of details required. Include

User Yes, a key thing with lots of details required
Summary Report An output produced from other information
Transaction Yes, each one is important and must be remembered
Transaction Report An output produced from transaction information. Not stored.

WEEK –3
b ) Represent use cases and a domain class diagram using Rational
Rose. Design:

WEEK – 3
c) Develop CRUD matrix to represent relationships between use cases and problem
domain classes.
Theory:
CRUD Matrix:
In computer programming, create, read, update and delete (as an acronym

CRUD) are the four basic functions of persistent storage.Alternate words are sometimes used
when defining the four basic functions of CRUD, retrieve instead of read, modify instead of
update, or destroy instead of delete. CRUD is also sometimes used to describe user interface
conventions that facilitate viewing, searching, and changing information; often using
computer-based forms and reports.
Another variation of CRUD is BREAD, an acronym for "Browse, Read, Edit, Add,
Delete".This extension is mostly used in context with data protection concepts, when it is
legally not allowed to delete data directly. Locking the data prevents the access for users
without destroying still needed data. Yet another variation, used before CRUD became more
common, is MADS, an acronym for "Modify, Add, Delete, Show.
Database Applications:
The acronym CRUD refers to all of the major functions that are implemented in
relational database applications. Each letter in the acronym can map to a standard SQL
statement, HTTP method .
(this is typically used to build RESTful APIs.
Operation SQL HTTP DDS
Create INSERT Put/Post Write
Read Select get Read/take

(Retrieve)
Update Update Post/Put/Patch Write
(Modify

Delete Delete Delete Dispose

(Destroy
Although a relational database provides a common persistence layer in software

applications, numerous other persistence layers exist. CRUD functionality can be
implemented with an object database, an XML database, flat text files, custom file formats,
tape, or card, for example.
User Interface:
CRUD is also relevant at the user interface level of most applications. For example, in
address book software, the basic storage unit is an individual contact entry. As a bare
minimum, the software must allow the user to
 Create or add new entries

 Read, retrieve, search, or view existing entries
 Update or edit existing entries
 Delete/deactivate/remove existing entries
Without at least these four operations, the software cannot be considered complete.
Because these operations are so fundamental, they are often documented and described under
one comprehensive heading, such as "contact management", "content management" or
"contact maintenance" (or "document management" in general, depending on the basic
storage unit for the particular application).

Analysis:

Order
Transactio
Order n Return
Libraria Paymen Vendo
Usecases Catalog User Request n Order t r
item Item
Look up item
availabilty R
Create book
request CRU R R C C C
Update book
request RU RUD RUD
Provide catalog
information R R CRUD
Creates new
catalog C C
Receives new
order R R CR CRU R

Look up order
status R R R R
Update catalog CRUD

Create return
request R R R
Collect payment RU RU

WEEK – 4
a ) Develop Use case diagram
Design:

WEEK – 4
b ) Develop elaborate Use case descriptions & scenarios
Use case description and scenario for “Order Books”:
Use case Order Books

Name
Scenario To order books required for the students
Triggering To order books and update the catalog
event
Brief Order suggested books or any latest editions that may be ordered to fill the catalog
Description which may be more informative and useful to users
Actors Librarian, Vendor

Related use Supply books
case
Preconditions Order required books. Send a request to the vendor
Post Update the catalog
conditions
Flow of events Actor System
1. Send request for books to vendor
2. Details about the books ordered 1.1 Accept request

3. Check the details and finalize the list
1.2 Verify details of the

4. Payment for the books
required books
2.1 Information about the
5. Update catalog with the new collection of

books ordered books
3.1 Produce bill for the
6. Maintainence of books and catalog list
. of books
4.1 Collect the payment
4.2 Supply the books
Exception Books unavailable, Payment issues

conditions

WEEK – 4
c ) Develop Prototypes(Without functionality).
Theory
A prototype is an initial, working model of a larger more complex entity. prototypes are used
for many different purosees.
Discovery Prototype: It is used for a single discovery objective and then discarded once the
concept has been tested.
Example: if you use a prototype to determine screen formats and processing sequences, once
you have finished that definition you will throw away the protype.
Evolving Protypes: These are the prototypes that grow and change and may eventually be
used as the final, live system.
Characteristics of effective prototypes.
Operative: A prototype should be a working model with the emphasis on working. A simple
start to a protype called a mock-up,is an electronic form (such as a screen) that shows what it
looks like but it is not capable of executing an activity. Later, a working prototype will
actually execute and provide both “look and feel” characteristics but may lack some
functionality.
Focused: To test a specific concept or verify an approach, a prototype should be found on a

single objective. Extraneous execution capability, not part of the specific objective should be
excluded. It may be possible to combine several simple prototypes into a larger prototype, the
focused objective still applies. Later the project team can combine prototypes to test the
integration of several components.
Quick: Tools, such as CASE tools, are needed to develop a prototype so that it can be built
and modified quickly. Since a prototypes purpose is to validate an approach, if the approach
is wrong, then the tools must be available to modify and test quickly to determine the correct

approach.
WEEK – 5
a) Develop system sequence diagrams.
Theory:
UML provides two types of diagrams for the representation of interactions: the
sequence diagram and the communication diagram. Both diagrams visualize the exchange of
information. However, the emphasis is different: communication diagrams emphasize the
relationships of individual objects and their topology; sequence diagrams emphasize the
chronological course of exchanged information. In the external view, we opt for the
representation through sequence diagrams and do without communication diagrams for two
reasons:
Sequence diagrams are easier to understand for developers and readers. In our
practical work in projects we have observed a much higher acceptance of sequence
diagrams because of their simplicity.
We avoid using unnecessarily many diagram types for the same facts. Less is often
more.
System sequence diagrams are actually a subtype of sequence diagrams, whose

style andnotation is dictated by the Unified Modeling Language. This language
provides a toolkit for diagram creators to make and read diagrams that are
comprehensible regardless of location or industry.
Sequence diagrams show the progression of events over a certain amount of time,
while system sequence diagrams go a step further and present sequences for specific use
cases.Use cases are simply another diagram type which represent a user's interaction with the

system.
Most element used in SS
Objects
-this box shape with an underlined title represents a class, or object, in UML. Within a
SSD, this shape models the system as a black box (a system with inner workings that are not
immediately visible).
Actors
-shown by stick figures, actors are entities that interact with the system, and
yet are external to it.
Events
-the system events that the actors generate in the sequence. A dashed line, known as
a lifeline, represents events in an SSD. Lifelines may begin with a labeled rectangle shape
or an actor symbol.When to Draw a System Sequence DiagramSSDs are ideal for
demonstrating when and how tasks are completed in a system, especially as those tasks are
related to use case.
Gayatri Vidya Parishad College of Engineering for Women 91

Page 104

WEEK – 5
a ) Develop high-level sequence diagram for each use-case.
Design:
LIBRARY MANAGEMENT SYSTEM Issue
Books
Renewal Books

Return Books
Supply Books

WEEK – 5
b ) Identify MVC classes/objects for each use case
Theory:
Model View Controller or MVC as it is popularly called, is a software design

pattern for developing web applications. A Model View Controller pattern is made up of the
following three parts:
 Model - The lowest level of the pattern which is responsible for maintaining data.
 View - This is responsible for displaying all or a portion of the data to the user.
 Controller - Software Code that controls the interactions between the Model and
View.
MVC is popular as it isolates the application logic from the user interface layer and
supports separation of concerns. Here the Controller receives all requests for the application
and then works with the Model to prepare any data needed by the View. The View then uses
the data prepared by the Controller to generate a final presentable response. The MVC
abstraction can be graphically represented as follows.

MODEL:
The model is responsible for managing the data of the application. It responds to the
request from the view and it also responds to instructions from the controller to update itself.
VIEW:
A presentation of data in a particular format, triggered by a controller's decision to
present the data. They are script based templating systems like JSP, ASP, PHP and very easy
to integrate with AJAX technology.
CONTROLLER:
The controller is responsible for responding to user input and perform interactions on
the data model objects. The controller receives the input, it validates the input and then
performs the business operation that modifies the state of the data model.
Design:
1. LIBRARY MANAGEMENT SYSTEM
Issue books:
<<view>> <<controlling>> <<model>>
user librarian catalogue
Return books:
<<view>> <<control>> <<model>> <<model>>
user librarian catalogue Database
Order books:
<<control>> <<control>>
librarian vender

Supply books:
<controller>> <<controller>>
librarian vender
Renewal:
<<controller>>
<<view>>
librarian
user

WEEK – 5
(c) Develop Detailed Sequence Diagrams/Communication diagrams for

each use case showing interactions among all the three-layer objects
Library Management System
Book_Query
Book_Query Inquiry_Handler bc:Book_Name
bc:Book_Name book_name:Da bc:book_author
bc:book_author book_author:da
book_author:d bc:book_public
bc:book_public book_publicatio
book_publicatio
a ation n:da
: Mentor 1: init book_name(book_edition)
2: inquiry on(b_name,b_auth,b_pub)
3: inquiry on b_name,b_auth,b_pub
4: read book description from database
5: init book_author
6: read book_author
7: init book_publication
8: read book_publication

WEEK – 6
a) Develop detailed design class model (use GRASP patterns for responsibility
assignment).
Theory:
A class diagram in the unified modelling language (UML) is a type of static

structure diagram that describes the structure of a system by showing the system’s classes,
their attributes, operations (or methods), and the relationships among objects.
The class diagram is the main building block of object-oriented modelling. It is used
both for general conceptual modelling of the systematic of the application, and for detailed
modelling translating the models into programming code. Class diagrams can also be used for
data modelling. The classes in a class diagram represent both the main elements, interactions
in the application, and the classes to be programmed.
Classes are represented with boxes that contain three compartments:
 The top compartment contains the name of the class. It is printed in bold and centred,
and the first letter is capitalized.
 The middle compartment contains the attributes of the class. They are left-aligned and
the first letter is lowercase.
 The bottom compartment contains the operations the class can execute. They are also
left-aligned and the first letter is lowercase.
Fig: representation of a class diagram example
In the design of a system, a number of classes are identified and grouped together in a
class diagram that helps to determine the static relations between them. With detailed
modelling, the classes of the conceptual design are often split into a number of subclasses.

The class diagrams are linked by relationship. A relationship is a general term
covering the specific types of logical connections found on class and objects diagrams. They
are of 5 types. They are:
 Association
 Generalization
→Dependency
Realization
Attribute:
An attribute is a specification that defines a property of an object, element, or file. It

may also refer to or set the specific value for a given instance of such. Attributes for clarity
should more correctly be considered as metadata.
Operation (Method):
A method is a procedure associated with a message and an object. An object is made

up of data and behaviour, which form the interface that an object presents to the outside
world.
Below is the example (figure) of detailed class diagram model for Simplified Banking
system:


Design

WEEK – 6
b) Develop three-layer package diagrams for each case study.
Theory:
Package diagram is UML structure diagram which shows structure of the designed
system at the level of packages. The following elements are typically drawn in a package
diagram: package, packageable element, dependency, element import, package import,
package merge.(UML Package Diagram is a type of Structure Diagrams that represents the
packages of the model and dependencies between them.)
Package Diagrams are used to illustrate the layered architecture of a software system.
The packages depict the different layers of a software system. To indicate the types of
dependencies between the packages are used the stereotypes.
There are two special types of dependencies between the packages in UML:
package import and package merge.
To design UML Package Diagrams use the following shape types:-
1. Package: a general purpose mechanism for organizing model elements & diagrams into
groups. It provides an encapsulated namespace within which all the names must be unique. It
is used to group semantically related elements. It is a namespace as well as an element that
can be contained in other packages' namespaces.
2. Class: a representation of an object that reflects its structure and behavior within the
system. It is a template from which running instances are created. Classes usually
describe the logical structure of the system.
3. Interface: a specification of behavior. An implementation class must be written to support

the behavior of an interface class.
4. Object: an instance of a class. It is often used in analysis to represent an artifact or

other item.
5. Table: a stereotyped class.

Usage:-
Package diagrams can use packages containing use cases to illustrate the
functionality of a software system.
* It is used in large scale systems to picture dependencies between major elements in the
system
* Package diagrams represent a compile time grouping mechanism.
Design:

WEEK – 7
a ) Develop Use case Packages.
Theory:
Use Case Package:
A Use-Case package is a collection of use cases, actors, relationships, diagrams, and

other packages. It is used to structure the use-case model by dividing it into smaller parts.
Explanation
A model structured into smaller units is easier to understand. It is easier to show

relationships among the model's main parts if you can express them in terms of packages. A
package is either the top-level package of the model, or stereotyped as a use-case package.
You can also let the customer decide how to structure the main parts of the model.
 If there are many use cases or actors, you can use use-case packages to further structure
the use-case model. A use-case package contains a number of actors, use cases, their
relationships, and other packages; thus, you can have multiple levels of use-case packages
(packages within packages).
 The top-level package contains all top-level use-case packages, all top-level actors, and all
top-level use cases.
Use
You can partition a use-case model into use-case packages for many reasons:
 You can use use-case packages to reflect order, configuration, or delivery units in the
finished system.
 Allocation of resources and the competence of different development teams may require
that the project be divided among different groups at different sites. Some use-case
packages are suitable for a group, and some for one person, which makes packages a
naturally efficient way to proceed with development. You must be sure, however, to
define distinct responsibilities for each package so that development can be performed
in parallel.

 You can use use-case packages to structure the use-case model in a way that reflects the
user types. Many change requirements originate from users. Use-case packages ensure that
changes from a particular user type will affect only the parts of the system that correspond
to that user type.
 In some applications, certain information should be accessible to only a few people. Use-
case packages let you preserve secrecy in areas where it is needed.

Design:

WEEK – 7
b ) Develop Component Diagrams.

Theory:
Component diagrams are different in terms of nature and behaviour. Component
diagrams are used to model physical aspects of a system.
Now the question is what are these physical aspects? Physical aspects are the
elements like executables, libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships

among components in a system. These diagrams are also used to make executable systems.
Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also
different from all other diagrams discussed so far. It does not describe the functionality of
the system but it describes the components used to make those functionalities.
So from that point component diagrams are used to visualize the physical
components in a system. These components are libraries, packages, files etc.
Component diagrams can also be described as a static implementation view of a

system. Static implementation represents the organization of the components at a particular
moment.
A single component diagram cannot represent the entire system but a collection of
diagrams are used to represent the whole.
So the purpose of the component diagram can be summarized as:
 Visualize the components of a system.
 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.

Where to use Component Diagrams?
We have already described that component diagrams are used to visualize the static
implementation view of a system. Component diagrams are special type of UML diagrams
used for different purposes.
These diagrams show the physical components of a system. To clarify it, we can
say that component diagrams describe the organization of the components in a system.
Organization can be further described as the location of the components in a system.

These components are organized in a special way to meet the system requirements.
As we have already discussed those components are libraries, files, executables etc. Now
before implementing the application these components are to be organized. This component
organization is also designed separately as a part of project execution.
Component diagrams are very important from implementation perspective. So the

implementation team of an application should have a proper knowledge of the component
details.
Now the usage of component diagrams can be described as:
 Model the components of a system.
 Model database schema.
 Model executables of an application.
 Model system's source code.

Design:

WEEK – 7
c) Identify relationships between use cases and represent them.
Design:

WEEK – 7
d ) Refine domain class model by showing all the associations among

classes.
Design:

WEEK – 8
Develop sample diagrams for other UML diagrams – state chart

diagrams, activity diagrams and deployment diagrams.
Theory:
State Chart Diagram:
The name of the diagram itself clarifies the purpose of the diagram and other details.
It describes different states of a component in a system. The states are specific to a
component/object of a system. A State Chart diagram describes a state machine.
Now to clarify it state machine can be defined as a machine which defines different
states of an object and these states are controlled by external or internal events. As State
Chart diagram defines states it is used to model lifetime of an object.
Purpose:
Following are the main purposes of using State Chart diagrams:
To model dynamic aspect of a system.

To model life time of a reactive system.
To describe different states of an object during its life time.
Define a state machine to model states of an object.
Steps for Drawing State Chart Diagram:
Before drawing a State Chart diagram we must have clarified the following points:
Identify important objects to be

analyzed. Identify the states.
Identify the events.
The following is an example of a State Chart diagram where the state of Order object
is analyzed.
The first state is an idle state from where the process starts. The next states are arrived
for events like send request, confirm request, and dispatch order. These events are
responsible for state changes of order object.

The initial and final state of an object is also shown below.
Main Usage of State Chart Diagram:
So the main usages can be described as:
To model object states of a system.

To model reactive system. Reactive system consists of reactive
objects.
To identify events responsible for state changes.
Forward and reverse engineering.
Activity Diagram:
Activity diagram is another important diagram in UML to describe dynamic aspects of

the system. Activity diagram is basically a flow chart to represent the flow form one activity
to another activity. The activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. This flow can be
sequential, branched or concurrent. Activity diagrams deals with all type of flow control by
using different elements like fork, join etc.

Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. Other
four diagrams are used to show the message flow from one object to another but activity
diagram is used to show message flow from one activity to another. Activity is a particular
operation of the system. It captures the dynamic behaviour of the system. Activity diagrams
are not only used for visualizing dynamic nature of a system but they are also used to
construct the executable system by using forward and reverse engineering techniques. The
only missing thing in activity diagram is the message part.
Steps for Drawing Activity Diagram:
So before drawing an activity diagram we should identify the following elements:
Activities
Association
Conditions
Constraints
The following diagram is drawn with the four main activities:
Send order by the customer

Receipt of the order
Confirm order
Dispatch order
After receiving the order request condition checks are performed to check if it is
normal or special order. After the type of order is identified dispatch activity is performed
and that is marked as the termination of the process.

Main Usage of State Chart Diagram:
Following are the main usages of activity diagram:
Modeling work flow by using activities.

Modeling business requirements.
High level understanding of the system's functionalities.
Investigate business requirements at a later stage.
Deployment Diagram:
Deployment diagrams are used to visualize the topology of the physical components of
a system where the software components are deployed.So deployment diagrams are used to
describe the static deployment view of a system. Deployment diagrams consist of nodes and
their relationships.
Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment
diagrams are used for describing the hardware components where software components are
deployed. Component diagrams and deployment diagrams are closely related. Component

diagrams are used to describe the components and deployment diagrams shows how they are
deployed in hardware.
The purpose of deployment diagrams can be described as:
Visualize hardware topology of a system.

Describe the hardware components used to deploy software components.
Describe runtime processing nodes.
Steps for Drawing Deployment Diagram:
Deployment diagrams are useful for system engineers. An efficient deployment

diagram is very important because it controls the following parameters.
Performance
Scalability
Maintainability
Portability
So before drawing a deployment diagram the following artifacts should be identified:
Nodes
Relationships among nodes

MAIN USAGE OF DEPLOYMENT DIAGRAM:
So the usage of deployment diagrams can be described as follows:
To model the hardware topology of a system.

To model embedded system.
To model hardware details for a client/server system.
To model hardware details of a distributed application.
Forward and reverse engineering.

Design:
Library Management System - Deployment Diagram
Database Server
client1
client2
Application Server printer
Terminal
clientN
State Chart Diagrams
1. Library Management System

Final Umldp Lab Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Umldp Lab Manual

Uploaded by

Copyright:

Available Formats

UML & Design Patterns Lab

Building Blocks of UML : Things ,Relationships and diagrams.

Gayatri Vidya Parishad College of Engineering for Women Page 1

Gayatri Vidya Parishad College of Engineering for Women Page 2

Gayatri Vidya Parishad College of Engineering for Women Page 3

 Links a semantic association between two classes in the UML diagram.

Generalization is a specification relationship in which objects of the specialized

A dependency is a semantic relationship in which if there is any change occurred in one

 Dependency is used in class diagram, Component diagram, deployment diagram, use

Realization is a Specified tool that can be represented by providing a relationship with

Gayatri Vidya Parishad College of Engineering for Women Page 4

Use Case Diagrams:

Gayatri Vidya Parishad College of Engineering for Women Page 5

Symbol: Object name

It can be annotated by a name. It has a property as Action kind.

Gayatri Vidya Parishad College of Engineering for Women Page 6

(i) To model flows of control by time ordering.

Gayatri Vidya Parishad College of Engineering for Women Page 7

Sub State Name

Gayatri Vidya Parishad College of Engineering for Women Page 8

Sub activity State:

Gayatri Vidya Parishad College of Engineering for Women Page 9

Sub Activity Name

Gayatri Vidya Parishad College of Engineering for Women Page 10

Gayatri Vidya Parishad College of Engineering for Women Page 11

A package is a grouping of model elements. Packages themselves may be nested within

Gayatri Vidya Parishad College of Engineering for Women Page 12

Gayatri Vidya Parishad College of Engineering for Women Page 13

A package is a grouping of model elements. Packages themselves may be nested within

Rational Rose : (Installation)

Step-1: Run Setup file in source folder

Gayatri Vidya Parishad College of Engineering for Women Page 14

Step-3: click “Next”

Gayatri Vidya Parishad College of Engineering for Women Page 15

Step-5: Click “Next”

Gayatri Vidya Parishad College of Engineering for Women Page 16

Step-7: Click “Next”

Gayatri Vidya Parishad College of Engineering for Women Page 17

Step-9: Click “Install”

Gayatri Vidya Parishad College of Engineering for Women Page 18

Step-11: Installation is about to complete

Gayatri Vidya Parishad College of Engineering for Women Page 19

Step-13: Click “Browse”

Gayatri Vidya Parishad College of Engineering for Women Page 20

Step-15: click “Import”

Gayatri Vidya Parishad College of Engineering for Women Page 21

Step-17: Following is the IBM Rational License Key Administrator

Gayatri Vidya Parishad College of Engineering for Women Page 22

Introduction to Rational Rose

Rational Rose Interface:

Gayatri Vidya Parishad College of Engineering for Women Page 23

Advantages of Rational Rose

Gayatri Vidya Parishad College of Engineering for Women Page 24

• Supports both round-trip engineering and reverse engineering.

• Round-trip engineering (RTE) is a functionality of software development tool that

Disadvantages of Rational Rose

• Code generation is limited to classes only

1. Use Case Diagram

Gayatri Vidya Parishad College of Engineering for Women Page 25

Creating a use case brief description

1. Click to select the use case in the browser.

Linking flow of events documents to use cases

Creating the Main Use Case diagram

Gayatri Vidya Parishad College of Engineering for Women Page 26