EXPERIMENT No: 1

1. AIM: Familiarization of Rational Rose Environment

OBJECTIVE:
The purpose of this first UML lab is to familiarize programmers with Rational Rose UML
environment and Java application. We will learn how to work with Rational Rose Enterprise
software, and how to draw development UML diagrams like Class diagrams, use case diagrams,
Sequence diagrams, Collaboration diagrams, Activity diagrams, State chart diagrams,
Component diagrams, Deployment diagrams.
PROCEDURE:
 The Rational Rose toolset provides a complete development environment for using UML
to create executable models.
 When you initially open Rational Rose, a default set of windows appear (as illustrated
below).
 However, you can customize the user interface to suit your modeling needs.
 The Figure shows a typical display of the Rational Rose Graphical User Interface.

1
  The main features of the Rational Rose Graphical user interface are:
(I) Application Window:
 It is a window that contains a title bar, tool bar, menu bar, and a work area for displaying
toolbox, browser, document window, diagram window, and specification window.
(ii) BROWSERS:
 Browser is a window with navigation tool for viewing diagrams and many other model
elements.
 Rational Rose Tool offers four main views located on the Model View browser.
 Each view is related to a software lifecycle phase, and the diagrams are artifacts of those
phases.
 Use-Case View shows what a system (subsystem, class, or interface) does but does not
specify how the system internally performs its tasks.
 Logical View represents the architectural processes as the model moves from analysis,
through design, and into development.
 Component View contains concrete representations of the system. Components realize
the active and passive classes, and provide the components for building an executable model.
 Deployment View shows how the system is to be distributed. It defines the processors,
and contains a diagram of the nodes in the system.
(iii) Documentation Window:
It is a window for preparing text information to describe model elements or relationships.
(iv) Diagram Windows:
It is a window which is used to draw or design or build UML diagrams.
(v) Other windows:
Other Windows such as Log, Edit, can be access through View on menu bar.
 There are different Unified Modeling Language tools available in the market.
 They are as follows:
(1) Rational Rose
(2) Visual Paradigm
(3) Umbrello UML modeller
(4) Lucidchart
(5) ConceptDraw PRO

2
 Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool
intended for visual modeling and component construction of enterprise-level software
applications.
 A software designer uses Rational Rose to visually create (model) the framework for an
application by blocking out classes with actors (stick figures), use case elements (ovals),
objects (rectangles) and messages/relationships (arrows) in a sequence diagram using drag-
and-drop symbols.

 Rational Rose documents the diagram as it is being constructed and then generates code in
the designer's choice of C++, Visual Basic, Java, Oracle8, Corba or Data Definition
Language.

 The Rational Rose Software is an operational tool and uses UML or the Unified Modelling
Language for facilitating the capture of architecture intent or design as well as the domain
semantics.
 Rational Rose is a set of visual modeling tools for development of object oriented software.
 Visual Modeling is the process of graphically depicting the system to be developed,
presenting essential details, filtering out non-essential details, viewing the system from
different perspectives.
 The toolbar for creating class diagrams is represented in the figure given below:

FIGURE: TOOLBAR FOR CLASS DIAGRAM

 Rational Software, Inc. was a company founded by the "three amigos" (Booch, Jacobson,
Rambaugh) , the creators of UML.
 The company's main product was Rational Rose, a CASE Tool to forward and reverse
engineer UML models. It is now a division of IBM.
 A set of visual modeling tools for development of object oriented software is Rational Rose.
3
 ROSE = Rational Object Oriented Software Engineering
 There are different versions of UML like UML1.0, UML1.1, UML1.2, UML1.3, UML1.4,
UML1.5, UML2.0, UML2.1, UML2.2, UML2.3, UML2.4 etc.
 The latest version of UML is UML2.5, officially released in June 2015.
 UML 2.5 provides 14 UML diagrams. They are as follows:
(1) Class Diagrams
(2) Object Diagrams
(3) Use case Diagrams
(4) Sequence Diagrams
(5) Collaboration or Communication diagrams
(6) Activity Diagrams
(7) State Chart Diagrams
(8) Component Diagrams
(9) Deployment Diagrams
(10) Composite structure diagram
(11) Package Diagram
(12) Timing Diagram
(13) Interaction Overview diagram
(14) Profile diagram
 Class diagram, Object Diagram, Package Diagram, Composite Structure Diagram,
Component Diagram, Deployment Diagram, Profile Diagram are called Structural
diagrams or Static diagrams.
 Use case Diagram, Activity Diagram, State Machine Diagram, Sequence Diagram,
Communication Diagram, Timing Diagram, Interaction Overview Diagram are called
Behavioral Diagrams or Dynamic diagrams.
 Sequence Diagram, Communication Diagram, Timing Diagram, Interaction Overview
Diagram are called Interaction diagrams.

UML AND DP LAB

4
Take three case studies:
(i) Customer Support System (in the Object-Oriented Analysis & Design with the Unified
Process by Satzinger, Jackson & Burd Cengage Learning )
(ii) Point-Of-Sale Terminal (in Larman textbook)
(iii) Library Management System (in the reference book no. 2 i.e. UML toolkit)
(Textbook no.2 i.e. Object-Oriented Analysis & Design with the Unified Process by Satzinger,
Jackson & Burd Cengage Learning will be the primary source for finding templates for
developing different artifacts / diagrams).
CASE STUDY: CUSTOMER SUPPORTING SYSTEM OF RMO (ROCKY MOUNTAIN
OUT FITTERS)
 Any part of a company (or) system that interacts with the customer directly or indirectly can
be called as a customer supporting system.
 A customer supporting system contains four sub systems.
1. Customer maintenance subsystem.
2. Catalog maintenance subsystem.
3. Order – entry subsystem
4. Order – fulfillment subsystem.
 Order – entry subsystem creates new orders for customers.
 Order – fulfillment subsystem handles fulfilling the order, including shipping and back
orders.
 Catalog maintenance subsystem maintains the product catalog database.
 RMO is a sports clothing manufacturer and distributor, Started in 1978.
 They sell the products to the customers in 5 ways.
1. Web order
2. Telephone order
3. Mail order
4. Retail store system.
5. Merchandising/Distribution.
 They sell the products to the customers using book catalog (or) RMO company releases a
book catalog that contains information of every product like size, color, type, unit price, offer
price etc.
EXPERIMENT 2(a)

5
AIM: Analyze and Identify events for RMO (Rocky Mountain Outfitters)-CSS (Customer
Supporting System).
PROCEDURE:
EVENT: An event is an occurrence at a specific time and place that can be described and is
worth remembering.
TYPES OF EVENTS:
There are three types of events
(i) External events
(ii) Temporal events
(iii) State events
External events:
 An external event is an event that occurs outside the system, usually initiated by on external
agent.
 An external agent is a person or organizational unit that supplies or receives data from the
system, hot necessarily the system user.
 The following are the external events for RMO customer support system.
1. Customer wants to check item availability.
2. Customer places an order.
3. Customer changes or cancels order.
4. Customer or management wants to check order status.
5. Shipping fulfills order.
6. Shipping identifies back order.
7. Customer returns item (defective, changed mind, full or partial returns).
8. Prospective customer requests catalog.
9. Customer updates account information.
10. Marketing wants to send promotional materials to customers.
11. Management adjusts customer charges (correct errors, make concessions).
12. Merchandising updates catalog(add, change delete, change prices)
13. Merchandising creates special product promotion
14. Merchandising creates new catalog

Temporal events:
 An event that occurs as a result of reaching a point in time.
6
 The following are the temporal events for an RMO customer support system.
1. Time to produce order summary reports.
2. Time to produce transaction summary reports.
3. Time to produce fulfillment summary reports.
4. Time to produce prospective customer activity reports.
5. Time to produce customer adjustment / concession reports.
6. Time to produce catalog activity reports.
State events:
 An event that occurs when something happens inside the system that triggers the need of
processing.
 The following are the state events for an RMO customer support system.
1. Reorder point reached

EXPERIMENT 2(b)
AIM: Identify use cases for RMO customer supporting system
PROCEDURE:
7
Use Case: A use case is an activity the system carries out, usually in response to a request by a
user.
Actor: An actor is a person or thing that interacts with the system.
 The following figure lists a few Rocky Mountain Outfitter users (also called actors) and some of their
work goals for the customer support system.

USER / ACTOR USER GOAL / USE CASE

Look up item availability
create new order
Telephone order clerk
update order
cancel order
Record order fulfillment
Shipping clerk Record back order
Produce order fulfillment report
Create special promotion
produce catalog activity report
Merchandising Manager
create new catalog
update catalog
Request for catalog
Request for new order
Request for item availability
Customer Request for cancel order
Request for update order
Look for order status.
Request for return order.
Distribute promotional package or materials.
Marketing manager
Create customer charge adjustment.

 The following figure lists a few users (also called actors) and some of their work goals for
the Point-Of-Sale (POS) system.

USER / ACTOR USER GOAL / USE CASE

8
 Process sales
Process rentals
Cashier Handle returns
Cash in
Cash out
Start up
Manager
Shut down
Add users
Modify users
System Administrator Delete users
Manage security
Manage system tables

Analyze sales and performance

Sales Activity System
data

EXPERIMENT 2(c)
AIM: Develop event table for RMO-CSS.
PROCEDURE:
 An Event table includes rows and columns, representing events and their details,
respectively.

9
 Each row in the event 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.
 A trigger is a signal that tells the system that an event has occurred, either the arrival of data
needing processing or a point in time.
 A source is an external agent that supplies data to the system.
 A response is an output, produced by the system, that goes to a destination.
 A destination is an external agent that receives data from the system.
 The following fig represents information about each event and the resulting use case in an
event table.

FIG: EVENT TABLE

 The Event table for Rocky Mountain Outfitters-Customer Supporting System is shown in the
fig given below.
EVENT TRIGGER SOURCE USE CASE RESPONSE DESTINATIO
N
1.Customer Item Customer Lookup item Item Customer
wants inquiry Availability availability
to check item details
availability
2.Customer New order Customer Create new Real-time Credit bureau,
places an order order link order customer,
10
 confirmation, shipping, bank
order details,
Transaction
3.Customer Order Customer Update order Change Customer,
changes or change confirmation, Shipping,
cancels order request Order change Bank
details,
Transaction
4.Time to “End of Produce Order Management
produce order week, order summary
summary month, summary reports
reports quarter, reports
and year”
5.Time to “End of Produce Transaction Accounting
produce day” transaction summary
transaction summary reports
summary reports
reports
6.Customer or Order Customer or Lookup order Order Customer or
management status management status Status management
wants to check inquiry Details
order status
7.Shipping Order Shipping Record order
fulfills order fulfillment fulfillment
notice
8.Shipping Back-order Shipping Record back Back Customer
identifies back notice order order
order notification
9.Customer Order Customer Create order Return Customer,
returns item return return confirmation, Bank
notice Transaction
10.Time to “End of Produce Fulfillment Management
produce week, fulfillment summary
fulfillment month, summary reports
summary quarter, reports
reports and year”
11.Prospective Catalog Prospective Provide Catalog Prospective
customer request Customer catalog info customer
requests catalog
12.Time to “End of Produce Prospective Marketing
produce month” prospective customer
prospective customer activity
customer activity Reports
activity reports reports
13.Customer Customer Customer Update
updates account account customer
information update account
notice
11
14.Marketing Promotion Marketing Distribute Promotional Customer and
wants to send package promotional package Prospective
promotional details package customer
materials to
customers

15.Management Customer Management Create charge Customer,

adjusts charge Customer adjustment bank
customer adjustment charge notification,
charges adjustment Transaction
16.Time to “End of Produce customer Management
produce month” customer adjustment
adjustment/conc adjustment reports
ession reports reports
17.Merchandisi Catalog Merchandising Update
ng updates update catalog
catalog details
18.Merchandisi Special Merchandising Create
ng creates promotion special
special product details promotion
promotion
19.Merchandisi New Merchandising Create new Catalog Customer and
ng creates new catalog catalog prospective
catalog details customer
20.Time to “End of Produce catalog Merchandising
produce catalog month” catalog activity
activity reports activity reports
reports

EXPERIMENT 2(d)
AIM: Identify and analyze domain classes for RMO-CSS.
PROCEDURE:
 A useful procedure for identifying and analyzing the domain classes is listing of all nouns
that users mention when talking about the system.

Step 1: Using the event table and information about each event, identify all the nouns.
12
Step 2: Using other information from existing systems, current procedures, and current reports
or forms, add items or categories of information needed.
Step 3: Refine the list and record assumptions or issues to explore.

 The following table lists some of the nouns from the RMO customer supporting system event
table and other sources, with some notes about each one.

IDENTIFIED NOUN NOTES ON INCLUDING NOUN AS A THING TO STORE

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.
Catalog Yes, need to recall them, for different seasons and years. Include
Catalog activity reports An output that can be produced from other information. Not stored.
Catalog details Same as catalog? Or the same as product items in the catalog?
Research
Change request An input resulting in remembering changes to an order.
Charge adjustment An input resulting in a transaction.
Color 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
Fulfillment Reports An output produced from information about shipments. Not stored.
Inventory Quantity One piece of information about a product item. Research.
Product Yes, what RMO includes in a catalog 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. Include
Payment Method Part of an order. Research
Price Part of a product item. Research
Promotional Materials An output or documents stored outside the scope? Research
Prospective Customer Possibly same as customer. Research
Return Yes, the opposite of an order. Include
Return Confirmation An output produced from information about a return. Not stored.
RMO There is only one of these! No need to store.
Season Part of a catalog? Or is there more to it? Research
Shipment Yes, a key thing to track. Include.
Shipper Yes, they vary and we need to track the order. Include.
Shipping Our department. No need to store
Shipping address Part of customer? Or order? Or shipment? Research
Size Part of a product item. Research.
Style Part of a product item. Research.
13
Summary Report An output produced from other information. Not stored.
Transaction Yes, each one is important and must be remembered. Include.
Transaction Report An output produced from transaction information. Not stored.

EXPERIMENT 2(e)
AIM: Represent a domain class diagram using Rational Rose tool.
PROCEDURE:
 The class diagram is used to show classes of objects for a system.
 The notation is from the Unified Modeling Language (UML), which has become the standard
for models used with object oriented system development.
 One type of UML class diagram shows the things in the users’ work domain, referred to as
the domain model class diagram.
 Another type of UML class diagram notation is used to create design class diagrams when
designing software classes.
 A domain class diagram is a diagram that contains a set of domain classes and their
relationships.
 A domain class or conceptual class is represented using a rectangle with two sections,
whereas a design class or software class is represented using a rectangle with four sections.
 The first section contains the name of the class.
 The second section contains attributes of the class.
 The third section contains operations of a class.
 The fourth section contains responsibilities of a class.
 Class names always begin with a capital letter, and attribute names always begin with a
lowercase letter.
 The following figure shows a symbol for one domain class: Customer.
FIGURE : The UML domain class symbol with name and attributes.
14
 The following diagram represents the domain class diagram for RMO-CUSTOMER
SUPPORTING SYSTEM.

15
 The following figure represents a domain class diagram for a Point-Of-Sale (POS) system.
16
EXPERIMENT NO: 2(f)

17
 AIM: Develop CRUD Matrix to represent relationships between use cases and problem domain
classes.
PROCEDURE:
 The approach which is used to list use cases and domain classes is use case-domain class
matrix.
 This matrix shows which use case requires access to each domain class.
 The following figure shows a use case-domain class matrix for Rocky Mountain Outfitters-
Customer Supporting System.
 The cells of the matrix show additional information to clarify what the use case does to the
domain class.
 The letter ‘C’ means the use case creates new data. ‘R’ means the use case reads data, ‘U’
means the use case updates data, and ‘D’ means the use case might delete the data.
 The acronym CRUD (Create, Read, Update, and Delete) is often used to describe this type of matrix.
USE CASES DOMAIN CLASSES
C C Inventory O O Order P P Return Shipment Shipper
A U Item R R Transaction A R Item
T S D D C O
A T E E K D
L O R R A U
O M I G C
G E T E T
R E
M
Look up item
R
availability
Create new CR
RU C C C R R C R
order U
R R
Update order RU RU U U RUD R R CRUD R
D D
Look up
R R R R R R
order status

18
Record order R
RU
fulfillment U
Record back R
CRU
order U
Create order CR R
C C
return U U
Provide
R R R R
catalog Info
Update
CR
customer
UD
account
Distribute
promotional R R R R R
package
Create
customer
RU CRUD
charge
adjustment
Update R R
R R
catalog U U
Create
special R R R R
promotion
C
Create new
C R R R
catalog
U

EXPERIMENT 3(a)
AIM: Develop Use case diagrams for RMO-CSS.
PROCEDURE:
 The use case diagram serves as a kind of table of contents for the business events activities
that must be supported by the system.
 It is used to identify the “uses”, or use cases, of the new system—in other words, to identify
how the system will be used and which actors will be involved in which use cases.

19
 The UML provides use case diagram notation to illustrate the names of use cases and actors,
and the relationships between them.
 A use case diagram is an excellent picture of the system context; it makes a good context
diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets
used.
 It serves as a communication tool that summarizes the behavior of a system and its actors.
 Use case diagrams are one of the five diagrams in the UML for modeling the dynamic
aspects of systems (Activity diagrams, Statechart diagrams, Sequence diagrams, and
Collaboration diagrams are four other kinds of diagrams in the UML for modeling the
dynamic aspects of systems).
 A use case is a description of set of sequence of actions that a system performs that yields an
observable result of value to a particular actor.
 Informally, an actor is something with behavior, such as a person (identified by role),
computer system, or organization; for example, a cashier.
 An actor represents a coherent set of roles that users of use cases play when interacting with
these use cases.
 Actors can be human or they can be automated systems. For example, in modeling a bank,
processing a loan involves, among other things, the interaction between a customer and a
loan officer.
 Graphically, a use case is rendered as an ellipse with solid lines, usually including only its
name.
 The following diagram represents an use case diagram for an RMO- Customer Supporting
System.

20
EXPERIMENT NO: 3(b)
21
AIM: Develop elaborate use case descriptions and scenarios for Rocky Mountain Outfitters
(RMO)-Customer Supporting System (CSS).
SOLUTION:
Use case descriptions are written at three separate levels of details
(i) Brief use case description
(ii) Intermediate use case description
(iii) Fully developed or Detailed or Elaborated use case description
FULLY DEVELOPED USE CASE DESCRIPTIONS:
 It is the most formal method for documenting a use case.
 The Fully developed description of the telephone order scenario for Create new order is
given below:

Use Case Name Create New Order

Scenario Create new Telephone Order
Triggering Event Customer telephones RMO to purchase items from the catalog.
Brief Description When customer call to order, the order clerk and system verify
customer information, create new order, add items to the order, verify
payment, create the order transaction, and finalize the order.
Actors Telephone Sales Clerk
Related Use Cases Includes: Check Item Availability
Stakeholders Sales Department: To provide primary definition.
Shipping Department: To verify that information content is adequate for
fulfillment.
Marketing Department: To collect customer statistics for studies of
buying patterns
Preconditions Customer must exist.
Catalog, Products, and Inventory items must exist for requested items.
Postconditions Order and Order line items must be created.
Order transaction must be created for the order payment.
Inventory items must have the quantity on hand updated.
The order must be related (associated) to a customer.
Flow of Events ACTOR SYSTEM

22
 1. Sales clerk answers telephone and
connects to a customer.
2. Clerk verifies customer information.
3. Clerk initiates the creation of a new 3.1 Create a new order
order.
4. Customer requests an item be added
to the order.
5. Clerk verifies the item. 5.1 Display item information
6. Clerk adds item to the order. 6.1Add an order item
7. Repeat steps 4, 5 and 6 until all items
are added to the order.
8.Customer indicates end of order; 8.1 Complete order
clerk enters end of order 8.2 Compute totals
9.Customer submits payment; clerk 9.1 verify payment
enters amount 9.2Create order transaction
9.3 Finalize order
Exception Conditions 2.1 If customer does not exist, then the clerk pauses this use case and
invokes Maintain Customer information use case.
2.2 If customer has a credit hold, then clerk transfers the customer to a
customer service representative.
4.1 If an item is not in the stock ,then customer can
a. Choose not to purchase item or
b. Request item be added as a back-ordered item.
9.1 If customer payment is rejected due to bad-credit verification, then
a. Order is cancelled or
b. Order is put on hold until check is received.

The Fully developed description of the Web order scenario for Create new order is given
below:
Use Case Name Create New Order
Scenario Create new web Order
23
Triggering Event Customer logs on to the RMO website and requests to purchase an
item.
Brief Description Customer logs on and requests the new order form. The customer
searches the catalog online and purchases items from the catalog. The
system adds the purchased items to the order. At the end, customer
enters credit card information.
Actors Customer
Related Use Cases Register new customer
Check Item Availability
Stakeholders Sales Department: To provide primary definition.
Shipping Department: To verify that information content is adequate for
fulfillment.
Marketing Department: To collect customer statistics for studies of
buying patterns
Preconditions Catalog, Products, and Inventory items must exist for requested items.
Postconditions Order and Order line items must be created.
Order transaction must be created for the order payment.
Inventory items must have the quantity on hand updated.
The order must be related (associated) to a customer.
Flow of Events ACTOR SYSTEM

24
 1. Customer connects to the RMO
home page and then links to the order
page.
2. If this is a new customer, then 2.1 Create new customer
customer links to the customer account record.
page and adds the appropriate
information to establish a customer
account.
2a. If existing customer, customer logs 2a.1 Validate customer
on. account.
2.2 Create a new shopping
cart order; display order form
with catalog frame
3. Customer searches catalog. 3.1 Display products from
catalog based on searches
and selections.
4. When customer finds the correct 4.1 Add item to shopping cart
item, he/she requests it to be added order.
to the order.
5. Repeat steps 3 and 4.
6. Customer requests end of order. 6.1 Display shopping cart
items, with totals and amount
dues; edit and submit
buttons.
7. Customer makes any changes.
8. Customer requests payment screen. 8.1 Display payment details
screen.
9. Customer enters payment 9.1 Accept payment, finalize
information. order, send confirmation
email.
Exception Conditions 4.1 If an item is not in the stock ,then customer can
a. Choose not to purchase item or
b. Request item be added as a back-ordered item.

25
 8.1 If customer payment is rejected due to bad-credit verification, then
a. Order is cancelled or
b. Order is put on hold until check is received.

EXPERIMENT 3(c)
AIM: Develop prototypes (without functionality) for RMO-CSS.
PROCEDURE:
 Prototypes refers to the window forms, browser forms (also called as web forms) that user
sees on the screen.
 Window forms are programmed in a full-featured programming language such as Visual
Basic, C++, or Java.
 Browser forms are programmed using HTML and script languages such as VBscript or
Javascript.
 The Main Menu form of an RMO-CSS is represented in the figure given below:

26
 The order summary form after the user adds the product is represented in the figure given
below:

27
 The shipping and payment option form for the completed order is represented in the figure
given below:

28
EXPERIMENT 3(d)
AIM: Develop System Sequence Diagram (SSD) for an RMO-CSS system.
PROCEDURE:
29
 A System Sequence Diagram (SSD) is used to describe the flow of information (sending
messages between internal objects, actors etc) into and out of the automated system.
 The following figure illustrates a System Sequence Diagram (SSD) for a Lookup Item
availability use case.
FIG: A SSD for the Look up Item Availability use case

 A SSD is a picture that shows, for one particular scenario of a use case, the events that
external actors generate their order, and inter-system events.
 A SSD is a description of a system behavior. I.e it describes what a system does without
explaining how it does it.
 A SSD is used to document the inputs to and outputs from the system for a single use case or
scenario.
 The following figure illustrates a System Sequence Diagram (SSD) for the telephone order
scenario of the create new order use case.

30
 Fig: SSD for the telephone order scenario of the create new order use case
 A SSD captures the interaction between the system and the external world as represented by
the actor.
 The system itself is treated as a single object named :system.
 The inputs to the system are messages from the actor to the system, and the outputs are
usually return messages showing the data being returned.
 In a SSD, since there are only two objects with lifelines, the source and destination are
constrained.
 In a SSD, the system was treated as a black box, and we could not see the internal
processing.
 The UML does not define something called a “system” sequence diagram but simply a
“sequence diagram”.
DETAILED SEQUENCE DIAGRAM (OR) SEQUENCE DIAGRAM
 A detailed sequence diagram uses all the same elements as an SSD.
 The difference between SSD and detailed sequence diagram is that the :system object is
replaced by all of the internal objects and messages within the system.
 The objective of detailed sequence diagram is to open up the black box and determine the
internal processing that must occur within the automated system.
31
 When we get to detailed sequence diagrams, some of the most critical decisions to be made
are the source and the destination objects for the messages.
 The syntax of an input message is
*[true/false condition] return-value :=message-name(parameter-list).
 For the output message, we normally only provide the parameter list without parentheses.
 The following figure illustrates a sequence diagram for Look up Item availability use case

EXPERIMENT 4(a)
AIM: Develop high-level sequence diagrams for each use case.
PROCEDURE:
 The following figure represents a three-level detailed design for create new customer use
case (It shows the classes associated with each of the three layers).
 This use case has two view layer objects—the :MainMenu and :CustForm objects.
 Notice that the input messages from the external actor always go to the view layer objects.
 The purpose of the design process is to take each input message and determine what the
system must do to respond to the message.
 For the first message, createNewCustomer(), the system simply opens the :CustForm screen.

32
 For the second message, setValues (...), the system accepts the data and perhaps edits it.

EXPERIMENT 4(b)
AIM: Identify MVC classes/objects for each use case.
PROCEDURE:
 View layer ( also called user interface) classes should have programming logic to:
(i) Display electronic forms and reports
(ii) Capture input—such events as clicks, rollovers, and key entry
(iii) Display data fields
(iv)Accept input data
(v) Edit and validate input data
(vi)Forward input data to the domain layer classes
(vii) Start up and shut down the system

33
 The View layer classes for an RMO system are:
(i) MainWindow
(ii) OrderWindow
(iii) NewItemWindow
(iv) ProductQuery
 Domain layer (also called Controller or Business logic or middle tier ) classes should have
the following responsibilities:
(i) Create problem domain (persistent) classes
(ii) Process all business rules with appropriate logic
(iii) Prepare persistent classes for storage to the data base
 The Domain layer classes for an RMO system are:
(i) OrderHandler
(ii) AvailabilityHandler
(iii) Catalog
(iv)CatalogProduct
(v) ProductItem
(vi)InventoryItem
(vii) Customer
(viii) Order
(ix)OrderItem
(x) OrderTransaction
 Data access layer(also called Model or Back end ) classes should perform the following:
(i) Establish and maintain connections to the data base
(ii) Contain all Structured Query Language (SQL) statements
(iii) Process result sets (the results of SQL executions) into appropriate domain
objects
(iv)Disconnect gracefully from the database
 The Data access layer classes for an RMO system are:
(i) CatalogDA
(ii) CatalogProductDA
(iii) ProductItemDA
(iv) InventoryDA
(v) CustomerDA
34
 (vi) OrderDA
(vii) OrderItemDA
(viii) OrderTransactionDA

EXPERIMENT 4(c)
AIM: Develop Communication diagrams for each use case showing interactions among all
the three-layer objects.
PROCEDURE:
 There are two types of Interaction diagrams
(i) Sequence diagram
(ii) Collaboration diagram or Communication diagram
 Collaboration diagram is an interaction diagram that emphasizes the structural organization
of the objects that send and receive messages.
 A collaboration diagram shows a set of objects, links among those objects, and messages sent
and received by those objects.
 You use collaboration diagrams to illustrate the dynamic view of a system.
35
 The following figure illustrates a communication diagram for Look Up Item Availability use
case.
FIGURE: A communication diagram for look up item availability

 Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take
one and transform it into the other.
 Collaboration diagrams have two features that distinguish them from sequence diagrams.
(1) Path: To indicate how one object is linked to another, you can attach a path stereotype
to the far end of a link.
(2) Sequence number: To indicate the time order of a message, you prefix the message
with a number (starting with the message numbered 1), increasing monotonically for each new
message in the flow of control (2, 3, and so on).
 The following figure illustrates a communication diagram for Create new order use case.
FIGURE: A Communication diagram for create new order

36
EXPERIMENT 4(d)
AIM: Develop detailed design class model (use GRASP patterns for responsibility
assignment).
PROCEDURE:

37
EXPERIMENT 4(e)
AIM: Develop three-layer package diagrams for each case study.
PROCEDURE:
 Package diagram is UML structure diagram which shows packages and dependencies
between the packages.

38
 Package is a namespace used to group together elements that are semantically related and
might change together.
 It is a general purpose mechanism to organize elements into groups to provide better
structure for system model.
 A package is rendered as a tabbed folder - a rectangle with a small tab attached to the left
side of the top of the rectangle.

Figure: Package org.hibernate

 If the members of the package are not shown inside the package rectangle, then the name of
the package should be placed inside which is shown in the figure given below.
 The members of the package may be shown within the boundaries of the package. In this
case the name of the package should be placed on the tab which is shown in the figure given
below.

Figure: Package org.hibernate contains SessionFactory and Session

 Members of the package may be shown outside of the package by branching lines from the
package to the members.
 A plus sign (+) within a circle is drawn at the end attached to the namespace (package)
which is shown in the figure given below:

39
 Figure: Package org.hibernate contains interfaces SessionFactory and Session.

 This notation for packages is semantically equivalent to composition (which is shown using
solid diamond).
 Package diagrams represents the system at a higher abstraction level.
 Package diagram is used to
(i) Depict a high-level overview of your requirements.
(ii) Depict a high-level overview of your architecture/design.
(iii) To logically modularize a complex diagram.
The different relationships used in package diagrams are:
(i) Dependency
(ii) Generalization
(iii) Refinement
 The following figure illustrates a package diagram for a three-layer object-oriented design for
an RMO-CUSTOMER SUPPORTING SYSTEM.

40
41
EXPERIMENT 5(a)
AIM: Develop use case packages.
PROCEDURE:
 The following diagram represents a Package diagram for the four RMO subsystems.

42
EXPERIMENT 5(b)
AIM: Develop Component diagrams.
PROCEDURE:
COMPONENT DIAGRAMS
 A component diagram shows the organizations and dependencies among a set of components.
 Component diagrams are one of the two kinds of diagrams found in modeling the physical
aspects of object-oriented systems.
 Deployment diagrams, the second kind of diagram used in modeling the physical aspects of
an object- oriented system.
 You use component diagrams to model the static implementation view of a system.
 Component diagrams commonly contain
(i) Components
(ii) Interfaces
(iii) Dependency, generalization, association, and realization
relationships
 A component is a physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces.
 You use components to model the physical things that may reside on a node, such as
executables, libraries, tables, files, and documents.
 In software, many operating systems and programming languages directly support the
concept of a component.
 Object libraries, executables, COM+ components, and Enterprise Java Beans are all
examples of components that may be represented directly in the UML by using components.
 The UML provides a graphical representation of a component (a rectangle with tabs), which
is shown in the figure given below.
Figure: Component

43
EXPERIMENT 5(c)
AIM: Identify relationships between use cases and represent them.
PROCEDURE:
 Two types of relationships can be used between uses cases
(i) Dependency (include, extend)
(ii) Generalization
(i) Dependency:
 Two stereotypes are used to model dependency relationship between use cases.
(i) Include
(ii) Extend
 Let us discuss include relationship in detail.
 Use case include is a directed relationship between two use cases which is used to show that
behavior of the included use case (the addition) is inserted into the behavior of the including
(the base) use case.
 The include relationship could be used:
(i) to simplify large use case by splitting it into several use cases,
(ii) to extract common parts of the behaviors of two or more use cases.
 Include relationship between use cases is shown by a dashed arrow with an open arrowhead
from the including (base) use case to the included (common part) use case.
 The arrow is labeled with the keyword «include».
 The following figure illustrates include relationship in a Point-Of-Sale (POS) system.

Figure: Checkout use case includes several use cases - Scan Item, Calculate Total and Tax, and
Payment

44
 Large and complex Checkout use case has several use cases extracted, each smaller use case
describing some logical unit of behavior.
 Note, that including Checkout use case becomes incomplete by itself and requires included
use cases to be complete.

FIGURE: Deposit Funds and Withdraw Cash use cases include Customer Authentication
use case.
 Let us discuss extend relationship in detail.
 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.
(i) 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.
(ii) 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.
(iii) 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.
 Lets expand our current example to show the <<extend>> relationship.

FIGURE: Extend relationship in use case diagrams

(iii) Generalization or Specialization or Inheritance or “Is-a-Kind-Of” Relationship:
45
  Generalization is used when there are common behavior, structure, and purpose between two
use cases and also specialized behavior specific to each use case.
 The behavior of the ancestor is inherited by the descendant-- child use case inherits properties
and behavior of the parent use case and may override the behavior of the parent.
 A child inherits all structure, behavior, and relationships of the parent. Children of the same
parent are all specializations of the parent.
 A parent use case may be specialized into one or more child use cases that represent more
specific forms of the parent.
 Neither parent nor child is necessarily abstract, although the parent in most cases is abstract.
 The following diagram represents a generalization relationship between two use cases.

FIGURE: Generalization relationship between two use cases in Customer supporting system
COMPARISON AMONG THREE RELATIONSHIPS
Generalization Extend Include

Base use case could be abstract Base use case is complete

Base use case is incomplete
use case (incomplete) or (concrete) by itself, defined
(abstract use case).
independently.
concrete (complete).
Specialized use case is Extending use case is Included use case
optional, supplementary. required, not optional.
required, not optional, if base
use case is abstract.
EXPERIMENT 5(d)
AIM: Refine domain class model by showing all the associations among classes.
46
PROCEDURE:

EXPERIMENT 6

47
AIM: Develop sample diagrams for other UML diagrams-state chart diagrams, activity
diagrams and deployment diagrams.
PROCEDURE:
ACTIVITY DIAGRAMS:
 An activity diagram shows the flow from activity to activity within a system.
 An activity shows a set of activities, the sequential or branching flow from activity to
activity, and objects that act and are acted upon.
 We use activity diagrams to illustrate the dynamic view of a system.
 Activity diagrams are especially important in modeling the function of a system.
 There are two types of State machine diagrams in UML. They are
(iv) State chart diagrams
(v) Activity diagrams
 It may be applied to any purpose (such as visualizing the steps of a computer algorithm), but
is considered especially useful for visualizing business workflows and processes, or use
cases.
 An activity diagram is considered a special kind of UML state chart diagram in which the
states are actions, and event transition is automatically triggered by action completion.
 An activity diagram is essentially a flowchart, showing flow of control from activity to
activity.
 Activity diagrams commonly contain
(iv) Activity states and action states
(v) Transitions
(vi) Objects
 You represent an action state using a lozenge shape (a symbol with horizontal top and bottom
and convex sides) which is shown in the figure given below.
Figure: Action state

 There's no notational distinction between action and activity states, except that an activity
state may have additional parts, such as entry and exit actions and submachine specifications.
FIGURE: ACTIVITY DIAGRAM FOR TELEPHONE ORDER SCENARIO
48
FIGURE: ACTIVITY DIAGRAM FOR WEB ORDER SCENARIO

49
STATE CHART DIAGRAMS

50
 A UML state chart diagram illustrates the interesting events and states of an object, and the
behavior of an object in response to an event.
 Transitions are shown as arrows, labeled with their event.
 Graphically, a state is rendered as a rectangle with rounded corners.
 It is common to include an initial pseudo-state, which automatically transitions to another
state when the instance is created.
 You use state machines to model the dynamic aspects of a system.
 There are two types of State machine diagrams in UML. They are
(vi) State chart diagrams
(vii) Activity diagrams
 You can visualize a state machine in two ways:
(1) By emphasizing the flow of control from activity to activity (using activity diagrams), or
(2) By emphasizing the potential states of the objects and the transitions among those states
(using state chart diagrams).
 State chart diagrams commonly contain
(3) States
(4) Transitions
(5) Events
 A state is a condition or situation during the life of an object during which it satisfies some
condition, performs some activity, or waits for some event.
 An object remains in a state for a finite amount of time.
 An event is the specification of a significant occurrence that has a location in time and space.
 In the context of state machines, an event is an occurrence of a stimulus that can trigger a
state transition.
 A transition is a relationship between two states indicating that an object in the first state will
perform certain actions and enter the second state when a specified event occurs and
specified conditions are satisfied.
 An activity is ongoing non atomic execution within a state machine.
 The following diagram represents a state chart diagram for Order

FIGURE: State Chart for Order

51
DEPLOYMENT DIAGRAMS
 A deployment diagram shows the placement of various physical nodes across different
locations.
 A node can be thought of as a computer, or a bank of computers, representing a single
computing resource.
 A node is a physical entity at a specific location.
 The following Figure illustrates the symbol that is used for a node—a cube including its
name.

FIGURE: Notation for node in Deployment diagram

52
 A node is a physical element that exists at run time and represents a computational resource,
generally having at least some memory and, often, processing capability.
 Graphically, a node is rendered as a cube.
 Deployment diagrams are one of the two kinds of diagrams used in modeling the physical
aspects of an object-oriented system.
 A deployment diagram shows the configuration of run time processing nodes and the
components that live on them.
 You use deployment diagrams to model the static deployment view of a system.
 Deployment diagrams commonly contain
(i) Nodes
(ii) Dependency and association relationships
 There are two types of nodes
(i) Device Node
(ii) Execution Environment Node (EEN)
Device node(or device):
It is a physical (e.g., digital electronic) computing resource with processing and memory services
to execute software, such as a typical computer or a mobile phone.
Execution Environment Node (EEN):
 It is a software computing resource that runs within an outer node (such as a computer) and
which itself provides a service to host and execute other executable software elements.
 Examples of EEN include:
(i) an operating system (OS) is software that hosts and executes programs.
(ii) a virtual machine (VM, such as the Java or .NET VM) hosts and executes programs.
(iii) a database engine (such as PostgreSQL) receives SQL program requests and
executes them, and hosts/executes internal stored procedures (written in Java or a
proprietary language).
(iv) a Web browser hosts and executes JavaScript, Java applets, Flash, and other executable
technologies.
(v) a workflow engine.
(vi) a servlet container or EJB container.

53