B.E. 3/4 - II Semester BIT- 381 OOSD LAB List of Experiments Prescribed by Osmania University Students have to perform the following OOSD steps on the Given Case Study. Use case Modeling Structural Modeling Behavioral Modeling Architectural Modeling The list of Experiments: 1. Use case Diagram 2. Class Diagram 3. Sequence Diagram 4. Collaboration Diagram 5. State Diagram 6. Activity Diagram 7. Component Diagram 8. Deployment Diagram List of innovative experiments (If any) 9. Selection of a Case Study – Problem Statement. 10. Software Requirement Specification. Design based Experiments 1
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
B.E. 3/4 - II Semester
BIT- 381 OOSD LAB
List of Experiments Prescribed by Osmania University
Students have to perform the following OOSD steps on the
Given Case Study.
Use case Modeling
Structural Modeling
Behavioral Modeling
Architectural Modeling
The list of Experiments:
1. Use case Diagram
2. Class Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. State Diagram
6. Activity Diagram
7. Component Diagram
8. Deployment Diagram
List of innovative experiments (If any)
9. Selection of a Case Study – Problem Statement.
10. Software Requirement Specification.
Design based Experiments To design a case study like Road Transport Authority system by using the following UML Diagrams:
Class Diagram Sequence Diagram Collaboration Diagram State chart Diagrams Usecase Diagrams
1
Deployment Diagrams
OOSD LAB
CONTENTS
S.NO Name of the Experiment Page no.
The students have to perform the Use case Modeling step on the
Given case study by using:
1. Use case Diagrams. 3
The students have to perform the Structural Modeling step on the
Given case study by using:
2. Class Diagrams 9
3. Sequence Diagrams 14
4. Collaboration Diagrams 21
The students have to perform the Behavioral Modeling step on the
Given case study by using:
5. Activity Diagrams 24
6. State Diagrams 29
The students have to perform the Architectural Modeling step on the
Given case study by using:
7. Component Diagrams 33
8. Deployment Diagrams 36
9* Assigning of a Case Study - Example: ONLINE EAMCET EXAM.
Writing of Problem Statement to the given Case Study. 39
10* Software Requirement Specification. 40
* Innovative Experiments
*d Class Diagram 44
*d Sequence Diagrams 48
*d Collaboration Diagrams 55
*d State chart Diagrams 59
*d Usecase Diagrams 62
*d Deployment Diagrams 66
2
1. Use case diagrams
AIM: To identify actors, use cases and relationships for representing functional
Requirement of system using Use case diagrams.
SOFTWARE REQUIREMENTS:
Operating system: Windows XP
Software : Rational Rose
HARDWARE REQUIREMENTS:
PROCESSOR : Pentium IV ,2.6 GHz
Memory :256 MB
Hard disk capacity: 80 GB
PROCEDURE:
Actor:
Actors represent system users. They help delimit the system and give a clearer picture
of what the system should do. It is important to note that an actor interacts with, but
has no control over the use cases.
An actor is someone or something that:
· Interacts with or uses the system
· Provides input to and receives information from the system
· Is external to the system and has no control over the use cases
Actors are discovered by examining:
· Who directly uses the system?
· Who is responsible for maintaining the system?
· External hardware used by the system
· Other systems that need to interact with the system
The needs of the actor are used to develop use cases. This insures that the system will
be that the user expected.
3
Graphical Depiction
An actor is a stereotype of a class and is depicted as a "stickman" on a use-case
diagram.
Naming
The name of the actor is displayed below the icon.
Additional information about the actor can be viewed in the Use-Case Specification
which is identical to a Class Specification with the addition of the Stereotype field set
to actor.
Use cases: A use case is a high-level piece of functionality that the system will provide
In its simplest form, a use case can be described as a specific way of using the system
from a user’s (actor’s) perspective. A more detailed description might characterize a
use case as:
· A pattern of behavior the system exhibits
· A sequence of related transactions performed by an actor and the system
· Delivering something of value to the actor
Use cases provide a means to:
· capture system requirements
· communicate with the end users and domain experts
· test the system
Use cases are best discovered by examining the actors and defining what the actor
will be able to do with the system.
Since all the needs of a system typically cannot be covered in one use case, it is usual
to have a collection of use cases. Together this use case collection specifies all the
ways of using the system.
By looking at the use cases, the customer can see what functionality will be provided,
and can agree to the system scope before the project goes any further
4
Graphical Depiction
The basic shape of a use case is an ellipse:
Naming
A use case may have a name, although it is typically not a simple name. It is often
written as an informal text description of the actors and the sequences of events
between objects. Use case names often start with a verb. For example, names of
possible use cases for an ATM machine might include Dispense Cash or Transfer
Funds.
The name of the use case is displayed below the icon.
Additional information about a use case can be viewed in the Use-Case specification.
Relationships
There are four types of relationships
1. Association
2. Includes relationship
3. Extends relationship
4. Generalization relationship.
You can draw an Association relationship from a use case to an actor.
You can draw a Generalize relationship between two use cases and /or two actors
You can draw a Dependency relationship between two use cases.
Association Relationship
The relationship between an actor and a use case is an association relationship.
In UML, association relationships are diagrammed using an arrow:
5
1. Include Relationship
An included relationship allows one use case to use the functionality provided by
another use case. This relationship can be used in one of two cases.
First, if two or more use cases have a large piece of functionality that is identical,
this functionality can be split into its own use case. Each of the other use cases
can then have an include relationship with this new use case.
The second case where an include relationship is helpful is a situation in which a
single use case has an unusually large amount of functionality. An include
relationship can be used to model two smaller use cases instead.
Includes relationships are shown in Rational Rose with dashed arrows and the
word <<include>>
3. Extend Relationship
In contrast, an extend relationship allows one use case the option to extend the
functionality provided by another use case. It is very similar to an include
relationship, because in both of these types of relationships, you separate some
common functionality into its own use case.
In UML, the extend relationship is shown as a dashed arrow with the word
A generalization relationship is used to show that several actors or use cases have
some commonality. For example, you may have two types of customers:
corporate customers and individual customers.
If both types of customers use the same use cases, it's probably not necessary to
show an actor generalization. If both types use the same use cases, but slightly
differently, it still isn't worth including the generalization. The slight differences are
documented in the flow of events
Flow of Events
The purpose of the flow of events is to document the flow of logic through the use
case. This document will describe in detail what the user of the system will do and
what the system itself will do. The flow of events typically includes:
A brief description
Preconditions
Primary flow of events
Alternate flow of events
Post-conditions
Description
Each use case should include a short description that explains what the use case
will do The description should be short and to the point, but should include the
different types of users who will be executing the use case and the end result the
user expects to achieve through the use case.
7
Preconditions
The preconditions for a use case list any conditions that have to be met before the
use case can start at all. For example, a precondition might be that another use
case has been executed or that the user has the necessary access rights to run the
current use case. Not all use cases will have preconditions.
Primary and Alternate Flow of Events
The specific details of the use case are described in the primary and alternate
flow of events. The flow of events describes, step-by-step, what will happen to
execute the functionality in the use case. The flow of events focuses on what the
system will do not how it will do it, and is written from the user's perspective.
The primary and alternate flow of events includes:
How the use case starts
The various paths through the use case
The normal, or primary, flow through the use case
Any deviations from the primary flow, known as alternate flows,
through the use case
Any error flows
How the use case ends
Post-Conditions
Post-conditions are conditions that must always be true after the use case has
finished executing. Like preconditions, post-conditions can be used to add
information about the order in which the use cases are run. If, for example, one
use case must always be run after another use case, you can document this in the
post-conditions. Not every use case will have post-conditions.
USECASE DIAGRAM:
8
Use case Diagram is graphical view of some or all of the actors, use cases, their
interactions identified for a system
Exercise 3:
9
1. Identify actors for your system.2. For each actor write the documentation.3. Identify use cases for your system.4. Document the use cases.5. Write use case specification for each use case identified.6. Link use case documents to Use cases in Rational Rose.7. Identify use case relationships8. Draw a Main and sub use case diagrams for you system.
10
2. Class Diagram
AIM: To identify different classes involve in the system and relationships among
these classes to draw class diagram with all options.
SOFTWARE REQUIREMENTS:
Operating system: Windows XP
Software : Rational Rose
HARDWARE REQUIREMENTS:
PROCESSOR : Pentium IV ,2.6 GHz
Memory :256 MB
Hard disk capacity: 80 GB
PROCEDURE:
Class diagrams are the most common diagrams found in modeling object-oriented
systems. A class diagram shows a set of classes, interfaces, and collaborations and
their relationships. Graphically, a class diagram is a collection of vertices and arcs.
A class diagram is a picture for describing generic descriptions of possible systems.
Class diagrams and collaboration diagrams are alternate representations of object
models. Class diagrams contain classes and object diagrams contain objects, but it
is possible to affix classes and objects when dealing with various kinds of
metadata, so the separation is not rigid.
Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data
structures-or message-passing structures.
Class diagrams contain icons representing classes, interfaces, and their
relationships. You can create one or more class diagrams to depict the classes at
the top level of the current model; such class diagrams are themselves contained by
the top level of the current model. You can also create one or more class diagrams
to depict classes contained by each package in your model; such class diagrams are
themselves contained by the package enclosing the classes they depict; the icons
representing logical packages and classes in class diagrams
We can change properties or relationships by editing the specification or
modifying the icon on the diagram. The associated diagrams or specifications are
automatically updated.
11
Class diagrams are the backbone of almost every object oriented method including
UML. Class diagrams describe the static structure of a system.
Contents:
Class Diagrams commonly contain the following things:
Classes
Interfaces
Collaborations
Dependency, generalization and association relationships
2. Classes & Interfaces:
Class: A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics. A class implements one
or more interfaces.
Graphically a class is rendered as a rectangle, usually including its name,
attributes and operations, as shown below.
Interface:
An interface is a collection of operations that specify a service of a class or
component. An interface describes the externally visible behavior of that
element.
Graphically the interface is rendered as a circle together with its name.
ISpelling
WindowOriginSize
Open ()Close ()Display ()
12
The various classes in our class diagram are:
student system database faculty
Manager
DIAGRAM:
Exercise:
1) Discover the initial – cut classes – Entity, Boundary and Control Classes.
2) Document the classes identified above and observe whether you have given
appropriate name and definition.
3) Group the identified classes into packages.
4) Write Main class diagram of the logical view model.
5) Write Main class diagram for each package identified.
13
3. Sequence Diagram
AIM: To analyze major functionalities and represent communication among objects
with time bound for each operation.
SOFTWARE REQUIREMENTS:
Operating system: Windows XP
Software : Rational Rose
HARDWARE REQUIREMENTS:
PROCESSOR : Pentium IV ,2.6 GHz
Memory :256 MB
Hard disk capacity: 80 GB
PROCEDURE:A sequence diagram is a graphical view of a scenario that shows object interaction in
a time-based sequence what happens first, what happens next. Sequence diagrams
establish the roles of objects and help provide essential information to determine class
responsibilities and interfaces. This type of diagram is best used during early analysis
phases in design because they are simple and easy to comprehend. Sequence diagrams
are normally associated with use cases.
Sequence diagrams are closely related to collaboration diagrams and both are
alternate representations of an interaction. There are two main differences between
sequence and collaboration diagrams: sequence diagrams show time-based object
interaction while collaboration diagrams show how objects associate with each other.
A sequence diagram has two dimensions: typically, vertical placement represents time
and horizontal placement represents different objects.
The following tools located on the sequence diagram toolbox enable you to model
sequence diagrams:
Object
Message Icons
Focus of Control
Message to Self
Note
Note Anchor
14
A sequence diagram consists of the following sequence diagram
behavioral elements.
Element and its description SymbolObject: The primary element involved in a sequence diagram is an object—an instance of a class. A Sequence diagram consists of sequence of interaction among different objects over a period of time. An object is represented by a named rectangle. The name to the left of the “.” Is the object name and to its right is the class name. Message: The interaction between different objects in a sequence diagram is represented as messages. A message is denoted by a directed arrow. Depending on the type of message, the notation differs. In a sequence diagram, you can represent simple messages, Special messages to create or destroy objects, and message responses.
The steps involved in creating a Sequence are:
Identify objects.
Identify actors.
Add messages to the diagram.
Object
An object is something that encapsulates information and behavior. It's a term
that represents some concrete, real-world thing. Examples of objects are:
airplane, a flight, a passenger, a piece of luggage, or a ticket.
Finding Objects
A good way to find some initial objects is to examine the nouns in your flow of
events. Another good place to look is in the scenario documents. A scenario is a
specific instance of a flow of events.
Lifeline
15
It specifies the existence of the Object. Each object has a lifeline, drawn as a
vertical dashed line below the object. The lifeline begins when the object is
instantiated and ends when the object is destroyed.
Focus of Control
In a Sequence diagram, you have the option of showing the focus of control,
which lets you know which object has control at a particular point in time. A
small vertical rectangle represents the focus of control.
Messages
A message is a communication between objects in which one object (the client)
asks another object (the supplier) to do something. By the time you generate
code, a message will translate to a function call. In this example, one form is
asking another to display itself:
Types of Messages:
Simple: This is the default value for messages. This option specifies that the
message runs in a single thread of control. On the Sequence diagram, simple
messages use this symbol.
Synchronous: Use this option when the client sends the message and waits until
the supplier has acted upon the message. On the Sequence diagram, synchronous
pay salary, logout. The sequential states of diagram 3 are idle, login, read problem,
send prescription, take salary.
30
Diagrams:
Student:
Conveyor:
enter id
idle
enter id
enter password
enter password
questions prep
invigialtion
setup test centers
appoint faculty
send results
manage database
questions prep
invigialtion
setup test centers
appoint faculty
send results
manage database
31
Faculty:
idle
enter id
enter password
questions prep
invigialtion
enter id
enter password
questions prep
invigialtion
Exercise:
1. Identify all possible states for any three objects of your
system
2. Draw state chart for each of above objects to represent their
life cycles.
32
7. Component Diagram
AIM: To identify all software components and associations among them and to draw
Component diagram
SOFTWARE REQUIREMENTS:
Operating system: Windows XP
Software : Rational Rose
HARDWARE REQUIREMENTS:
PROCESSOR : Pentium IV ,2.6 GHz
Memory :256 MB
Hard disk capacity: 80 GB
PROCEDURE:
Component diagrams provide a physical view of the current model. A component
diagram shows the organizations and dependencies among software components,
including source code components, binary code components, and executable
components. These diagrams also show the externally-visible behavior of the
components by displaying the interfaces of the components. Calling dependencies
among components are shown as dependency relationships between components and
interfaces on other components. Note that the interfaces actually belong to the logical
view, but they can occur both in class diagrams and in component diagrams.
Component diagrams contain:
· Component packages
· Components
· Interfaces
· Dependency relationships
You can create one or more component diagrams to depict the component packages
and components at the top level of the component view, or to depict the contents of
each component package. Such component diagrams belong to the component
package that they depict.
A Component Package Specification enables you to display and modify the properties
of a component package. Similarly, a Component Specification and a Class
Specification enables you to display and modify the properties of a component and an
interface, respectively. The information in these specifications is presented textually.
33
Some of this information can also be displayed inside the icons representing
component packages and components in component diagrams, and interfaces in class
diagrams.
You can change properties of, or relationships among, component packages,
components, and interfaces by editing the specification or modifying the icon on the
diagram. The affected diagrams or specifications are automatically updated.
Basic Component diagram symbols and Notations
Component
A component is a physical building block of the system. It is represented as a
rectangle with tabs.
Interface
An interface describes a group of operations used or created by components.
Dependencies
34
Draw dependencies among components using dashed arrows.
Diagram:
Exercise:
1. Identify all required components of your system and draw a detail
Component diagram
8. Deployment Diagram
35
AIM: To identify all runtime components and implementation architecture of system
and to draw Deployment diagram
SOFTWARE REQUIREMENTS:
Operating system: Windows XP
Software : Rational Rose
HARDWARE REQUIREMENTS:
PROCESSOR : Pentium IV ,2.6 GHz
Memory :256 MB
Hard disk capacity: 80 GB
PROCEDURE:
A deployment diagram shows processors, devices, and connections. Each model
contains a single deployment diagram which shows the connections between its
processors and devices, and the allocation of its processes to processors.
Processor Specifications, Device Specifications, and Connection Specifications
enable you to display and modify the respective properties. The information in a
specification is presented textually; some of this information can also be displayed
inside the icons.
You can change properties or relationships by editing the specification or modifying
the icon on the diagram. The deployment diagram specifications are automatically
updated.
Basic Deployment diagram symbols and Notations
Node
A node is a physical resource that executes code components.
36
Association
Association refers to a physical connection between nodes, such as Ethernet.
Components and Nodes
Place components inside the node that deploys them.
Diagram:
37
db server
data base.ddl
system
user
sudent.exefaculty.exe
service manager
admin officer.execonveynor.exe
Exercise
1. Identify all implementation nodes of your system and draw deployment diagram for your system
9. Selection of a Case Study – Problem Statement
AIM: Select the problem to be solved as case study by each team and preparation of
38
Technical problem statement for the same .Example: ONLINE EAMCET
EXAM.
PROCEDURE:
The following are the users which can access the database .They are emcee
conveyor, student and faculty. The emcee conveyor issues the notification for the
particular year. After receiving the applications from the students, he issues hall
tickets online .He manages the database and the entire system. He appoints the faculty
and also set up regional test centers with required infrastructure .A regional centre
will have few computers and a local server which will manage the tests. This server
will manage the question bank and as well as results of the test taker.
The faculty has access to the question bank server and they can
only add more questions to it. Some of the faculty is appointed as invigilators for the
test. A student can take only one time in a year at the test center and the score is valid
for two years. Students have to register online for the test with a valid identity proof.
The payment can be made through credit cards or through demand draft. The results
are sending to the test takers through postal mail. Admission offices of all registered
institutions have access to the results through which they can verify the score.
Exercise 1:
Select a system and write the problem statement for the selected system
39
10. Software Requirement Specification
AIM: Preparation of SRS document to understand the system characteristics in detail.
PROCEDURE:
Standard SRS should include the following
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions
1.4 References
1.5 Overview
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 Functional requirements
3.2 Non functional requirements
3.3 Performance requirements
3.4 External interfaces
3.5 Software system attributes
40
1. INTRODUCTION
1.1 Purpose
The purpose of the online emcee exam is to make eamcet online
and make conducting and evaluating the result easy.
1.2 Scope
The main users of the system are conveynor, student, and faculty
and admission officer.
1.3 Definitions, acronyms and abbreviations
Reg-regional
Admn-admission
Ques prep-question preparation
1.4 Overview
General description deals with project perspective, project
function, user characteristics and general constraints. Specific
requirements deal with external interface requirements,
performance requirements and design constraints.
2. GENERAL DESCRIPTION
2.1 Product perspective
The online eamcet exam is used when student wants to join
engineering.
2.2 Product function
The main function of online eamcet exam is to accept request for
the students to write exam and get the results immediately.
2.3 User characteristics
Main users are conveynor,student and faculty
Convey nor:-he should have the knowledge of managing and
conducting the exam.
Student:-he should have the knowledge of applying and writing the
exam.
Faculty:-he should have the knowledge of preparing questions and
conducting exam.
41
2.4 General constraints
It works only on windows.
3. SPECIFIC REQUIREMENTS
3.1 External Interface requirements
3.1.1 User Interfaces
HTML
3.1.2 Hardware Interfaces
Keyboard, Mouse
3.1.3 Software Interfaces
Rational Rose, Windows
3.2 FUNCTIONAL REQUIREMENTS
3.2.1 Login:-It allows the users to use the services. It takes in login
id and password and returns to the next page.
3.2.2 Notification:-conveyor notifies the data for applying hall
tickets and date of exam.
3.2.3 issue hall ticket:-after receiving applications ,conveynor
issues hall tickets for eligible students online.
3.2.4 appoint faculty:-conveynor appoints the faculty for
conducting test.
3.2.5 Manage database:-conveynor manages the database which
consists of question bank and results.
3.2.6 Setup regional test centers:-conveyor setup regional test
centers with infrastructures.
3.2.7 Sendresults:-conveynor sends results to the test takers
through postal mail.
3.2.8 Conduct counseling:-conveyor conducts counseling for the
test takers to join in institutions.
3.2.9 Logout:-the user logout after their work is completed.
3.3.1 Register online:-the students register online for the test with
a valid identity proof.
3.3.2payfees:-the students pay fees through credit card or demand
draft.
42
3.3.3 Take test: - the students write the test.
3.3.4 Questions preparation:-the faculty prepares the questions
bank.
3.3.5 Invigilation:-the faculty conducts the test.
3.3.6 Verify results:-admissions of registered institutions verify the
results.
3.3 NON FUNCTIONAL REQUIREMENTS
The system is dependable, reliable and interoperable.
Static requirements: A limited number of customers can only login
to the hotel based on the no of rooms present in that hotel.
Dynamic requirements: Query processing time is 10 ms.
3.4 DESIGN CONSTRAINTS
The login of conveyor and faculty has to provide their password.
Exercise 2:
Write SRS for the case or system chosen by you.
43
Design Based Experiments
1. Class Diagram
AIM: To design Road Transport Authority System by using class diagram.
SOFTWARE REQUIREMENTS:
Operating system: Windows XP
Software : Rational Rose
HARDWARE REQUIREMENTS:
PROCESSOR : Pentium IV ,2.6 GHz
Memory :256 MB
Hard disk capacity: 80 GB
PROCEDURE:
Class diagrams are the most common diagrams found in modeling object-oriented
systems. A class diagram shows a set of classes, interfaces, and collaborations and
their relationships. Graphically, a class diagram is a collection of vertices and arcs.
A class diagram is a picture for describing generic descriptions of possible systems.
Class diagrams and collaboration diagrams are alternate representations of object
models. Class diagrams contain classes and object diagrams contain objects, but it
is possible to affix classes and objects when dealing with various kinds of
metadata, so the separation is not rigid.
Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data
structures-or message-passing structures.
Class diagrams contain icons representing classes, interfaces, and their
relationships. You can create one or more class diagrams to depict the classes at
the top level of the current model; such class diagrams are themselves contained by
the top level of the current model. You can also create one or more class diagrams
to depict classes contained by each package in your model; such class diagrams are
themselves contained by the package enclosing the classes they depict; the icons
representing logical packages and classes in class diagrams
We can change properties or relationships by editing the specification or
44
modifying the icon on the diagram. The associated diagrams or specifications are
automatically updated.
Class diagrams are the backbone of almost every object oriented method including
UML. Class diagrams describe the static structure of a system.
Contents:
Class Diagrams commonly contain the following things:
Classes
Interfaces
Collaborations
Dependency, generalization and association relationships
2. Classes & Interfaces:
Class: A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics. A class implements one
or more interfaces.
Graphically a class is rendered as a rectangle, usually including its name,
attributes and operations, as shown below.
Interface:
An interface is a collection of operations that specify a service of a class or
component. An interface describes the externally visible behavior of that
element.
Graphically the interface is rendered as a circle together with its name.
WindowOriginSize
Open ()Close ()Display ()
45
ISpelling
The various classes in our class diagram are:
RTA
Employee
Operator
Administrator
Accountant
Officer
Helpdesk
Applicant
Report
46
Diagram:
officernameid
test drive prep()invigilation()issue licence()
Employeenameid
salary()
RTARegionCodePhnoAdd
Provide Facilities()
helpdesknameid
respond to queries()
operatornameid
accept reg()allot pid()
administratornameid
record maintenance()record classification()
applicantnamepid
gets registered()takes test()bill payments()
accountantnameid
accept payments()generate bills()prepare report()
reportno
daily report()monthly report()
verification
certificates
test
2. Sequence Diagram
47
AIM: To design Road transport authority system by using sequence diagram.
SOFTWARE REQUIREMENTS:
Operating system: Windows XP
Software : Rational Rose
HARDWARE REQUIREMENTS:
PROCESSOR : Pentium IV ,2.6 GHz
Memory :256 MB
Hard disk capacity: 80 GB
PROCEDURE:A sequence diagram is a graphical view of a scenario that shows object interaction in
a time-based sequence what happens first, what happens next. Sequence diagrams
establish the roles of objects and help provide essential information to determine class
responsibilities and interfaces. This type of diagram is best used during early analysis
phases in design because they are simple and easy to comprehend. Sequence diagrams
are normally associated with use cases.
Sequence diagrams are closely related to collaboration diagrams and both are
alternate representations of an interaction. There are two main differences between
sequence and collaboration diagrams: sequence diagrams show time-based object
interaction while collaboration diagrams show how objects associate with each other.
A sequence diagram has two dimensions: typically, vertical placement represents time
and horizontal placement represents different objects.
The following tools located on the sequence diagram toolbox enable you to model
sequence diagrams:
Object
Message Icons
Focus of Control
Message to Self
Note
Note Anchor
48
A sequence diagram consists of the following sequence diagram
behavioral elements.
Element and its description SymbolObject: The primary element involved in a sequence diagram is an object—an instance of a class. A Sequence diagram consists of sequence of interaction among different objects over a period of time. An object is represented by a named rectangle. The name to the left of the “.” Is the object name and to its right is the class name. Message: The interaction between different objects in a sequence diagram is represented as messages. A message is denoted by a directed arrow. Depending on the type of message, the notation differs. In a sequence diagram, you can represent simple messages, Special messages to create or destroy objects, and message responses.
The steps involved in creating a Sequence are:
Identify objects.
Identify actors.
Add messages to the diagram.
Object
An object is something that encapsulates information and behavior. It's a term
that represents some concrete, real-world thing. Examples of objects are:
airplane, a flight, a passenger, a piece of luggage, or a ticket.
Finding Objects
A good way to find some initial objects is to examine the nouns in your flow of
events. Another good place to look is in the scenario documents. A scenario is a
specific instance of a flow of events.
Lifeline
49
It specifies the existence of the Object. Each object has a lifeline, drawn as a
vertical dashed line below the object. The lifeline begins when the object is
instantiated and ends when the object is destroyed.
Focus of Control
In a Sequence diagram, you have the option of showing the focus of control,
which lets you know which object has control at a particular point in time. A
small vertical rectangle represents the focus of control.
Messages
A message is a communication between objects in which one object (the client)
asks another object (the supplier) to do something. By the time you generate
code, a message will translate to a function call. In this example, one form is
asking another to display itself:
Types of Messages:
Simple: This is the default value for messages. This option specifies that the
message runs in a single thread of control. On the Sequence diagram, simple
messages use this symbol.
Synchronous: Use this option when the client sends the message and waits until
the supplier has acted upon the message. On the Sequence diagram, synchronous