UML-lab Record

GVP College of Engineering for Women
UML(Unified Modeling Language)

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
Diagrams in UML :
 Class Diagram
 Object Diagram
 Usecase Diagram
 Sequence Diagram
 Collaboration Diagram
 Statechart Diagram
 Activity Diagram
 Component Diagram
 Deployement Diagram
Class:
A class is the descriptor for a set of objects with similar structure, behavior, and
relationships.It is represented by a rectangle.
[Type text]
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,
usecase 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, usecase
diagrams.
Symbol:
----------------------------------------------
Class diagrams:
A class diagram is that which represents a set of classes,interfaces,and collobrations
and their relationships,graphically a class diagram is a collection of vertices and arcs.
It consists of three compartments.
Name
Attributes
operations
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
operations
Uses:
An object diagram is used to model the static design view of a system.
UseCase Diagrams:
An usecase diagram shares the common properties as all diagrams.It distinguishes in the
contents of use cases, actors, dependency, generalization relationships.
Actor
Uses:
An Usecase 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
SubmachineState:
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 pseudostate 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:
JunctionPoint:
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.
ActionState:
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:
SubactivityState:
A subactivity 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 subactivity state is a hierarchical action, where an associated subactivity graph is
executed.
Symbol:
Sub Activity
Name
InitalState:
An initial is a kind of pseudostate 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.
Symbol:
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:
An interface is a specifier for the externally-visible operations of a class, component, 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.
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
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
NodeInstance:
A node instance is an instance of a node. A collection of component instances may
reside on the node instance.
Symbol:
Node Name
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.
Symbol:
<<artifact>>
WEEK – 1
Familiarization with 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”
c
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. ouble-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 argname
and a type of argtype
9. With the argname selected, enter the name of the formal argument.
10. Click to select the argtype 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
opration (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.
3. Drag the actor onto the sequence diagram.
4. Click to select the object icon from the toolbar.
5. Click on the sequence diagram window to place the object.
6. While the object is still selected, enter the name of the object.
7. Repeat the preceding steps for each object and actor in the scenario.
8. Click to select the object message icon from the toolbar.
9. Click on the actor or object receiving the message.
10. While the message line is still selected, enter the name of the message.
11. Repeat steps 7 through 9 for each message in the scenario.
Assigning Objects in a Sequence Diagram to Classes
1. Click to select the class in the browser.

2. Drag the class onto the object in the sequence diagram. Rose will add the class name preceded
by a colon to the object name. If the object is unnamed, the name is set to:className.
Mapping Messages to New Operations
1. Assign the objects to classes if that has not been done previously.
2. Right-click on the message arrow to make the shortcut menu visible.
3. Select the <new operation> menu choice. This will open the Operation Specification.
4. Enter the name of the operation in the Operation Specification.
5. Click the OK button to close the Operation Specification.
6. Right-click on the message arrow to make the shortcut menu visible.
7. Select the operation from the list of operations for the class.
Note: If the desired operation already exists for the class, you do not have to recreate the
operation; simply select the operation from the list of operations for the class.
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 NewPackage to the
browser.
3. With the NewPackage 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,3 & 4
a ) Identify and Analyze Events :

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.
1. CUSTOMER SUPPORT SYSTEM
External Events:
• Customer wants to check item availability.

• Customer places an order.
• Customer changes or cancels order.
• Customer or Management wants to check order status.
• Shipping fulfills order.
• Shipping identifies back order.
• Customer returns item (defective, changed mind, full or partial returns).
• Prospective customer requests catalog.
• Customer updates account information.
• Marketing wants to send promotional materials to customers.
• Management adjusts customer charges (corrective errors, make concessions).
• Merchandising updates catalog (add, change, delete, change prices).
• Merchandising creates special product promotion.
• Merchandising creates new catalog.
Temporal Events:
• Time to produce order summary reports.

• Time to produce transaction summary reports.
• Time to produce fulfillments summary reports.
• Time to produce prospective customer activity reports.
• Time to produce customer adjustment/concession reports. Time to produce catalog
activity reports.
2. POINT-OF-SALE TERMINAL
External Events:
• Customer wants to check availability.

• Customer chooses an item.
• Customer arrives at checkout.
• Customer changes or cancels order.
• Customer checks order status.
• Cashier records each purchased item. System validates information. System records
payment information System updates inventory.
• Customer receives a receipt.
• Customer requests for items.
• Manager manages salesperson and related problems if exists.
Temporal Events:
• Customer transaction.
• Customer inventory.
• Customer operational report.
• Customer statements and documents.
3. 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,3 & 4
b ) Identify Use Cases :
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 case.
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 behavior 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 optionalbehavior as well. This mostly happens when your modeling
complex behaviors.
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 behavior to be modeled as a separate use case.
Include Relationship Between Two Use Cases:
Include relationship show that the behavior 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 behaviors. Few things to consider when using
the <<include>> relationship.
Includes is usually used to model common behavior
 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.
 Provide catalog information

 Look up for item availability
 Create new order
 Update order
 Produce order summary reports
 Produce transaction summary reports
 Look up order status
 Record under fulfillment
 Record book order
 Produce fulfillment summary reports
 Search for item availability

 Place order
 Update order
 Return items
 Customer requests item
 Cashier gives bill
 Update catalog
 Pay amount
 Receive bill
 Produce item summary report
 Produce transaction report
 Produce discount report
 Produce items damages report
 Search for availability

 Request books
 Return books
 Pay fine
 Update catalog
 Manage Library
 Order Books
 Pay amount
WEEK – 2,3 & 4
c ) Develop event table:

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.
S.NO EVENT TRIGGER SOURCE USE-CASE RESPONSE DESTINATION

customer wants
to check item item inquiry customer look up item item availability
1 customer
availability availability details
real time link

order, credit bureau
customer create new
2 new order customer confirmation ,customer
places an order folder
order details shipping bank
transaction
customer change
changes or order confirmation
cancels the order customer
3 change customer update order
order change details shipping bank
request
transaction
time to produce end of produce order
order summary week, summary order summary
4 - management
report month, reports reports
quarter, year
time to produce produce order
transaction transaction transaction
5 end of day - accounting
summary reports summary reports
report
customer or customer customer or
management order status or look up order order status management
6
wants to check inquiry manageme status details
order status nt
order
record order
7 shipping fullfillment shipping - -
fullfillment
fullfils order notice
shipping
back order record back back order
8 identifies back shipping customer
notice order notification
order
return
order return create order
9 customer customer confirmation customer ,bank
notice return
returns item transaction
time to produce end of produce
fullfillment week, fullfillment fullfillment
10 - management
summary month, summary summary report
report quarter, year reports
prospective prospectiv provide
customer catalog e catalog prospective
11 catalog
requests request customer information customer
catalog
time to
produce
produce prospective
end of the prospective
12 prospective - customer activity marketing
month customer
customer reports
activity reports
activity reports
customer customer
update
updates account
13 customer customer - -
account update
account
information notice
marketing
wants to send promotion distribute customer and
promotional
14 promotional package marketing promotional prospective
package
materials to details package customer
customer
management customer create customer charge
adjusts charge managem charge adjustment
15 customer , bank
customer adjustment ent adjustment notification
charges transaction
time to produce
customer produce
customer
end of customer
16 adjustment or - adjustment Management
month adjustment
concession reports
reports
report
catalog
merchandi
17 merchandising update updates catalog - -
sing
updates catalog details
merchandising special
creates special promotion merchandi create special
18 - -
product details sing promotion
promotion
merchandising customer and
new catalog merchandi create new
19 creates new catalog prospective
details sing catalog
catalog customer
time to produce produce
end of the catalog activity
20 catalog activity - catalog activity Merchandising
month reports
reports reports
S.N
EVENT TRIGGER SOURCE USE-CASE RESPONSE DESTINATION
O
customer
wants to item look up item item availability
1 customer Customer
check item inquiry availability details
availability
customer picking up
2 choose item customer item details Customer
chooses item them
customer
arrival at
3 arrives at arrival customer checkout details Customer
check out
checkout
cashier record
record purchased item
4 each record item cashier Cashier
purchases item details
purchased item
customer enter payment
payment
5 enters payment customer information payment Customer
information
information
system validate
validate
6 validates validate system account System
information
information information
system records record
7 payment informatio system - record payments System
information n
system
update update
8 updates system update details System
details inventory
inventory
customer
receipt receives a
9 receives customer receipt details Customer
details receipt
receipt
customer
request for
item
request for
10 manager item details customer request details Manager
item manager
manages sales
person and
problems
sales person help for
salespers helping the
11 help customer customer details of item Customer
on customer
find items details
calculates
tax calculator tax taxes as per
12 tax details tax details Customer
calculates tax calculator government
rules
manager performs
operation
13 performs mode manager mode of operation details Manager
details
of operation operation
cashier restarts cashier restarts the
14 cashier cashier details System
system details system
time to customer reporting
produce ativity customer produce activity
15 system Customer
customer details activity details details
activity reports
S.N
EVENT TRIGGER SOURCE USE-CASE RESPONSE DESTINATION
O
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,passwor user user login LMS
login user
d
user search for book
book search for
3 availability of user avaialability User
inquiry book
book details
user request for request
request for
4 book issue status user request details LMS
book
details
user view history viewing history book status
5 user User
history details of book details
user request request request for book request
6 user LMS
for librarian book details book details
librarian issue issue book issue of book user gets
7 LMS User
book to user details to user requested book
librarian catalog updated ctalog
8 LMS update catalog LMS
update catalog details details
librarian requested
request
9 request book LMS books for due book details Vendor
book details
for vendor vendor
vendor supply supply book supply books to supplied book
10 vendor Catalog
books details library details
librarians pays paying money
payment
11 money for LMS for money details Vendor
details
books books received
show book book status showing book book status
12 LMS User
status details status details
user apply for renewal applying for book renewal
13 user LMS
renewals details renewal details
librarian
checking status checking due
14 check for due details LMS LMS
of due date details
due date
user returns returning return book to book status

15 user LMS
book book details library details
librarian
calculating
16 calculates fine details LMS fine details LMS
fine
fine
user pays paying fine to fine payment

17 fine details user LMS
fine librarian details
payment is acknowledge
payment
payment correct or not ment
18 acknowledm LMS -
details payment
ent
details
WEEK – 2,3 & 4
d ) Identify & Analyze Domain Classes
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 behaviors, 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 arethose 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.
1.CUSTOMER SUPPORT SYSTEM
Accounting We know who they are. No need to store

Back order A special type of order? Or a value of order status? Research
Back order Information An output that can be produced from other information
Bank Only one of them. No need to store
CatLog Yes, need to recall them, for different reasons and years
CatLog activity reports An output that can be produced from other information. Not stored
CatLog Details Same as CatLog? Or the same as product items in the CatLog
Research
Change Request An input resulting in the remaining changes to an order
Charge Adjustment An input resulting in a transaction
Colour One piece of information about a product item
Confirmation An output produced from other information. Not stored
Credit Card Information Part of an order? Or part of customer information? Research
Customer Yes, A key thing with lots of details required. Include
Customer Account Possibly required if an RMO payment plan is included research
Fulfilment Reports An output produced from information about shipments. Not stored
Inventory Quantity One piece of Information about the product item. Research
Product item Yes, what RMO includes in a CatLog and sells. Include
Management We know who they are. No need to store
Marketing We know who they are. No need to store
Merchandising We know who they are. No need to store
Order Yes, a key System responsibility
Price Part of a product item. Research
Prospective customer Possibly same as customer. Research
Season Part of CatLog? Or it is there more to it? Research
Shipment Yes, A key thing to back. Include
2.POINT-OF-SALE TERMINAL
Inventory One point of Information about a product item Research
CatLog Yes, need to recall them
CatLog activity Reports An output that can be produced from another information
Item Request An input resulting an item
Confirmation An output that can be produced from another information
Credit Card Information Part of an order? or a part of customer Information? Research
Marketing We know who they are. No need to store
Management We know who they are. No need to store
Customer Yes, a key thing with lot of details.

Customer Account Possibly Required if RMO payment plan Included
Transaction Report An output that can be produced from another information
3.LIBRARY MANAGEMENT SYSTEM
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.

LIBRARY MANAGEMENT SYSTEM
POINT-OF-SALE TERMINAL
CUSTOMER SUPPORT SYSTEM
WEEK – 2,3 & 4
f ) Develop CRUD matrix to represent relationships between use cases and

problem domain classes.
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).
Inventory Order Order Product Return

Usecases Catalog Customer Order Package Shipment Shipper
item item Transaction item item
Look up
item
availabilty R
Create new
order CRU RU C C C R R C R
Update
order RU RU RUD RUD RUD R R CRUD R
Look up
order status R R R R R R
Record
order
fulfillment RU RU
Record
back order RU CRU
Create
order return CRU RU C C
Provide
catalog
information R R R R
Update
account of
customer CRUD
Distribute
promotional
package R R R R R
Create
customer RU CRUD
charge
adjustment
Update
catalog RU R RU R
Creates new
catalog C R CRU R
Usecases Inventory Manager Sales person System Customer Cashier

Item availability R R
Record purchased item U RU
Enters payment information R CR
Validate information R
Updates inventory CRU RU
Request item R R
Restart system U U
Tax calculation U
Payment R R
Order
Order Transaction Return
Usecases Catalog User Request Librarian Order Payment Vendor
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 – 5 & 6
a ) Develop Use case diagram


WEEK – 5 & 6
b ) Develop elaborate Use case descriptions & scenarios
Use case description and scenario for “Create new order”:
Use case Name Create new order

Scenario Create new web order
Triggering event Customer logs on to the web site and requests to purchase an item
Brief Description Customer logs in and requests new order form. Customer searches
catalogue. System adds purchased items to the order. At end, customer
enters credit card information.
Actors Customer
Related use case Register new customer, Check item availability
Stakeholders Sales department: to provide primary definition
Shipping department: to verify that information content is adequate for
fulfilment
Marketing department: collect customer statistics
Preconditions Catalogue, products and inventory items must exist for requested items
Post conditions Order and order line items must be created
Order transaction must be created
Inventory items must have the quantity updated
Order must be related to the customer
Flow of events Actor System
1. Customer connects to
home page and links to
order page
2. If new customer, then 2.1 Create new customer record
he is linked account 2a.1 Validate customer account
page to create an 2.2 Create new shopping cart order
account
2a. If existing customer,
he logs in
3. Customer searches 3.1 Display products based on searches
catalogue
4. When correct item 4.1 Add item to shopping cart order
found, it is added to cart
5. Repeat steps 3 and 4
6. Customer requests 6.1 Display cart items, total and submit buttons
end of order
7. Customer makes any
changes
8. Customer requests 8.1 Display payment details screen
payment screen
9. Customer enters 9.1 Accept order, finalize payment and send
payment information confirmation e-mail
Exception conditions 4.1 If item not in stock, customer can:

a. chooses not to purchase item, or
b. request to add item as back-ordered item
8.1 If customer payment is rejected due to bad credit information, then
a. Order cancelled, or
b. Order put on hold till check is received
Use case description and scenario for “Search For Items”:
Use case Name Look up item availability

Scenario search for items
Triggering event customer wants to check whether the required item
available or not
Brief customer wants to buy items. So, he search for the
Description item he need, when look for availability of item.
Actors Customer
Related use case include - register new customer, order new item.
Stakeholders Sales department : to provide catalog information.
Marketing department : tocollect customer statics for studies of buying patterns.
Preconditions catalog, products & inventory items must exist for requested items.
Post conditions must be able to order the selected items
1. customer connects to site

2.1. create new customer
2. If the customer is new, he should be registered record
2.a. If customer existing, login 2.2. validation customer
record
3. Customer searches for the item 2.3. create new card
4. Select the item he wants
Exception . If an item is not in stock, then customer can:

conditions a. choose not a purchase item
b. request item be added as a back-ordered item
Use case description and scenario for “Dissatisfaction of the item”:
Use case create order return

Name
Scenario Dissatisfaction of the item
Triggering order change request
event
Brief Customer looks in to the site he orders the item. But due to some reasins he
Description don’t want the item.So, he returned the order.
Actors customer, clerk
Related use create order, maintain customer account information.
case
Stakeholders Sale department: to provide primary definition Shipping department: to verify
the information content is adequate for fulfillment. Marketing department: to
collect customer statistics for studies of buying patterns.
Preconditions The item should already delivered to the customer
Post Takes the order return & update the account
conditions information.
1. Customer login to the system
2. search for the system
3. he selects the item
4. create new order
2.1. show catalog
5. make payment
information
6. create order return
3.1. add to cart
.
4.1. order taken
5.1. order successful
6.1. accept return required
Exception If the sale person does not accept the return ,then customer cannot return the
conditions item recovery of previous state.
Use case description and scenario for “Account Maintenance”:
Use case maintains customer does not accept the return, then customer cannot return
Name the item
Scenario As the customer places/return order, account should be maintained.
Triggering Accepts order or accepts return
event
Brief Whenever the customer places an order or return the order, his account
Description information should be updated.
Actors Customer, clerk
Related use Accounting departments updates the account information.
case
Stakeholders Accounting departments: updates the account information
Preconditions Customers should place an order or return the order.
Post Account information should be updated.
conditions
Flow of Actor System
events
1. Customer logs into the site
2. Searches for the item
3. Select the item

4. Make payment 2.2. provide catalog
information
3.3. add tp cart
5. Request for return 4.1. Account information
should
be updated
5.1. Accepts return update

account information
Exception If payment is rejected due to bad-credit verification then:
conditions a. Order is cancelled,
b. Order is put on hold until check is recorded.
Use case description and scenario for “Handle Returns”:
Use case Name Handle Returns

Scenario Return of an item
Triggering event Customer requests for return of an item
Brief Description A customer arrives at a checkout with
items to return. The cashier uses the POS system to record each
returned item.The system presents a running total and line item details.
The customer enters customer information, which the system validates
and records.
The system updates inventory. The customer receives a receipt for
return and amount to make new purchase
Actors Cashier
Related use case Search For Order ,Update Product Quantities,Update Account
Stakeholders Cashier: Wants accurate, fast entry
Customer: Wants return and fast service with minimal effort and fast
refund
Manager: Wants to be able to quickly perform override operations
Preconditions Cashier is identified and authenticated.
Post conditions return line must be created
return transaction must be created
1. Customer arrives at
POS checkout with
goods and/or services
to return
2. Cashier starts a 2.1 The system will display the selected order
return transaction after in the Return Products Screen.
searching for the order
3. The cashier will 3.1 System gives item description based on
select the products to identifier.
return.
4.1 Item is added to list of items returned
4. Enter the list of
items to be returned. 5.1 The system starts processing the
5. The cashier will transaction
select submit. 5.2 System update the inventory
5.3 System update the Acccount
6.1 Transaction is recorded in the system
database.
7.1 System generates receipt with transaction
details.
Exception conditions At any time, System fails. To support recovery and correct accounting:
1. Cashier restarts System, login,&requests recovery of previous state.
2. System reconstructs previous state.
Use case description and scenario for “Process Sale”:
Use case Name Process sale

Scenario Purchase of an item
Triggering event Customer requests for purchase of an item
Brief Description A customer arrives at a checkout with items to purchase. The cashier uses
the POS system to record each purchase. The cashier uses the POS system
to record each purchased item. The system presents a running total and line
item details. The customer enters payment information, which the system
validates and records. The system updates inventory. The customer
receives a receipt from the system and then leaves with the items.
Actors Cashier
Related use case Register new customer, Check item availability
Stakeholders Cashier: Wants accurate, fast entry, and no payment errors
Salesperson: Wants sales commissions updated.
Customer: Wants purchase and fast service with minimal effort
Manager: Wants to be able to quickly perform override operations
Preconditions Cashier is identified and authenticated.
Post conditions Order and order line items must be created
Order transaction must be created
Order must be related to the customer
1. Customer arrives at
POS checkout with
goods and/or services to
purchase.
2. Cashier starts a new 2.1 System creates new transaction.
sale.
3. Cashier enters item 3.1 System gives item description based on
identifier. identifier.
4. System records sale 4.1 Item is added to list of items purchased.
line item and presents
item details.
5. System presents total 5.1 Total amount is generated by the system.
with taxes calculated.
6. Cashier tells
Customer the total, and
asks for payment.
7. Customer pays 7.1 payment details are validated.
amount.
8. System logs
completed sale. 8.1 Transaction is recorded in the system
9. System presents database.
receipt. 9.1 System generates bill with transaction
10. Customer leaves details.
with receipt and goods.
Exception conditions At any time, System fails. To support recovery and correct accounting:
1. Cashier restarts System, logs in, and requests recovery of previous state.
2. System reconstructs previous state.
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
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
6. Maintainence of books and catalog 3.1 Produce bill for the list
. of books
4.1 Collect the payment
4.2 Supply the books
.
Exception Books unavailable, Payment issues
conditions
WEEK – 5 & 6
d ) Develop system sequence diagrams
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 are:
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.
Lifelines:
When drawing a sequence diagram, lifeline notation elements are placed across the top
of the diagram. Lifelines represent either roles or object instances that participate in the
sequence being modeled. [Note: In fully modeled systems the objects (instances of classes) will
also be modeled on a system's class diagram.] Lifelines are drawn as a box with a dashed line
descending from the center of the bottom edge (Figure 3). The lifeline's name is placed inside
the box.
Example:
- The sequence diagram is having four objects (Customer, Order, SpecialOrder

and NormalOrder).
The following diagram has shown the message sequence for SpecialOrder object and
the same can be used in case of NormalOrder object. Now it is important to understand the time
sequence of message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call isconfirm
() which is a method of SpecialOrder object and the last call is Dispatch () which is a method of
SpecialOrder object. So here the diagram is mainly describing the method calls from one object
to another.
\

WEEK – 7,8,9 & 10
a ) Develop high-level sequence diagram for each use-case
Order process
Order type
Shipment
Process Sale
Issue Books
Renewal Books
Return Books
Supply Books
WEEK – 7,8,9 & 10
b ) Identify MVC classes/objects for each use case
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.
Order place:
<<view>> <<model>> <<controller>>

customer inventory system
Order payment:

customer inventory
Order clerk
Shipment:
<<view>> <<controller>>
<<controller>>
. customer Order clerk
shipping
Order process:
<<model>> <<controller>>
inventory Order processing
handler
Process sale:

customer store cashier
Fax calculation:
<<view>> <<model>> <<controller>> <<controller>>

customer store cashier Tax calculator
Accounting:
manager cashier
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:
user librarian
WEEK – 7,8,9 & 10
d) Develop detailed design class model (use GRASP patterns for

responsibility assignment)
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
 Generalisation
 ------------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:
a)Customer Support System

b)Point of Sales Terminal
c) Library Management System

WEEK – 7,8,9 & 10
e) Develop three-layer package diagrams for each case study
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.
a) Customer Support System
View Layer
MainWindow
ProductQuery OrderWindow NewItemWindow
Domain Layer
OrderHandler1 AvailabilityHandller
catalogl Catalog1Product ProductlItem Inventory1Item
cutomer Order1 OrderIItem OrderlTransaction
Data Access Layer
catalogDA CatalogProductDA ProductItemDA InventoryDA
CustomerDA OrderDA OrderItemDA OldTransactionDA

b) Point of Sales System
c)Library Management System

WEEK – 11 & 12
a ) Develop Use case Packages
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.

b)Point of Sales System

WEEK – 11 & 12
b ) Develop Component Diagrams

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.
\

WEEK - 11& 12
c)Identify relationships between use cases and represent them
1)Customer Support System

b)Point of Sales Terminal
look up item availability
make line item
<<include>> cashier
scan item
customer
checkout <<include>>
total with tax

payment
cheque
credit
cash
<<include>>
update inventory
manager
check inventory
<<include>>
summary report
USECASE RELATIONSHIPS-POINT OF SALE


WEEK – 11 & 12
d ) Refine domain class model by showing all the associations among classes .


WEEK – 13
a ) Develop sample diagrams for other UML diagrams – state chart diagrams,
activity diagrams and deployment diagrams.
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.


b)Point of sales System
b)pos
c)lms

b)Library Management System

UML-lab Record

Uploaded by

Copyright:

Available Formats

UML-lab Record

Uploaded by

Document Information

Original Title

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

UML-lab Record

Uploaded by

Copyright:

Available Formats

GVP College of Engineering for Women

UML(Unified Modeling Language)

Symbol: Object name

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

State Chart Diagrams:

Sub State Name

Familiarization with Rational Rose : (Installation)

Step-1: Run Setup file in source folder

Step-3: click “Next”

Step-4: Click “Next”

Step-6: Click “Accept”

Step-7: Click “Next”

Step-8: Click “Next”

Step-10: Starting of installing IBM Rational Rose

Step-11: Installation is about to complete

Step-12: click “Next”

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

Introduction to Rational Rose

Rational Rose Interface:

Advantages of Rational Rose

Disadvantages of Rational Rose

1. Use Case Diagram

Creating use cases

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

Creating Communicates Associations

1. Click to select the Generalization icon from the toolbar.

Creating Extends Relationships

1. Click to select the Generalization icon from the toolbar.

Creating Additional Use Case Diagrams

Creating Classes in the Rose browser

1. Right-click to select the Logical View in the browser.

Creating Stereotypes for Classes in Rational Rose

1. Click to select the class in the browser.

Creating packages in the Rose browser

1. Right-click to select the Logical View in the browser.

Relocating Classes in the Rose browser 1.

1.Click to select the class in the browser.

The main Class Diagram

Creating a Package Main Class Diagram

1. Double-click on the package on a class diagram.

Creating a View of Participating Classes

To Set the Visibility Display

To Show the Stereotype

Creating an Association Relationship

1. Click to select the association icon from the toolbar.

Creating an Aggregation Relationship

1. Select the aggregation icon from the toolbar.

1. Click to select the relationship line on a class diagram.

Creating Role Names

1. Double-click on the relationship line to make the Specification visible.

Creating a Reflexive Relationship

1. Select the association (or aggregation) icon from the toolbar.

Creating Package Relationships