OOSE Practical File

Submitted To:
Submitted By:
Name

: Ms. Ruchi Sehrawat

Designation

: Assistant Professor

Institution

: USICT,GGSIPU

Name

: Gaurav Arora

Enrolment No. : 05116404513

Semester

: 4th

Session (2013-2016)
Study Centre:
University School of Information and Communication Technology

Index
S

Topic

Page

Signature
1

no.

no.

THE UNIFIED MODELING

LANGUAGE
2

The Unified Modeling Language (UML) is a standard visual modeling

language intended to be used for modeling business and similar processes,

analysis, design, and implementation of software-based systems

UML is a common language for business analysts, software architects and

developers used to describe, specify, design, and document existing or new
business processes, structure and behavior of artifacts of software systems.
UML can be applied to diverse application domains (e.g., banking, finance,
internet, aerospace, healthcare, etc.) It can be used with all major object and
component
software
development
methods
and
for
various
implementation platforms (e.g., J2EE, .NET).
UML is a standard modeling language, not a software development
process. UML 1.4.2 Specification explained that process:
Provides guidance as to the order of a teams activities.

Specifies what artifacts should be developed.

Directs the tasks of individual developers and the team as a whole.

Offers criteria for monitoring and measuring a projects products and

activities.

UML is intentionally process independent and could be applied in the

context of different processes. Still, it is most suitable for use case driven,
iterative and incremental development processes. An example of such
process is Rational Unified Process (RUP).
A system that allows a software designer to graphically layout and model a
software application. It gives designers a way to literally draw a map of how
a piece of software will be constructed and function.

Basic Building Blocks of Uml

1. Things Four Types

Structural things -- The nouns of UML models. These represent

elements that are conceptual or physical. There are seven kinds of
structural things: Class, Interface, Collaboration, Use Case, Active
Class, Component, and Node.
3

Behavioral things -- Dynamic parts of UML models. The verbs which

represent behavior over time and space. There are two kinds of
behavioral things: Interaction, and State Machine.
Grouping things -- Organizational parts of UML. These are boxes into
which models can be decomposed. There is only one kind of grouping
thing, the Package.
Annotational things -- Explanatory parts of UML. Used to describe,
illuminate, and remark any element of a model. There is only one kind
of annotational thing, the Note.

2. Relationships Four Types

Dependency -- A semantic relationship in which a change on one

thing (the independent thing) may cause changes in the other thing
(the dependent thing).

Association -- A structural relationship describing links between

objects. May also include labels to indicate number and role of the
links. In the example shown below there may be any number of
employees (*) each of which has 0 or 1 employer.

Generalization -- A specialization/generalization relationship. Simply

put this describes the relationship of a parent class (generalization) to
its subclasses (specializations).

Realization -- Defines a relationship in which one class specifies

something that another class will perform. Example: The relationship
between an interface and the class that realizes or executes that
interface.

3. Diagrams Nine Types

Class Diagram -- A set of classes, interfaces, and collaborations and

their relationships. Most often found in modeling Object Oriented
systems.

Object Diagram -- A set of objects and their relationships. Represents

static instances of things found in class diagrams.

Use Case Diagram -- A set of Use Cases and actors.

4

Sequence Diagram -- An interactive diagram (set of objects,

relationships, and messages that may be exchanged) emphasizing the
time-ordering of messages.

Collaboration Diagram -- An interaction diagram emphasizes the

structural organization of the objects that send and receive messages.

Statechart Diagram -- Shows

transitions, events, and activities.

Activity Diagram -- Special type of statechart diagram that shows the

flow from activity to activity within a system.

Component Diagram -- Shows the organizations and dependencies

among a set of components.

Deployment Diagram -- Shows the configuration of run-time

processing nodes and the components that are part of them.

state

machine

with

states,

USE CASE DIAGRAM

Specify the functionality the system has to offer from a users
perspective.

User performs a behaviorally related sequence of transactions in a

dialogue with the system. Such a special sequence is called a use
case.
A use case class is a description, which specifies the transaction of
the use cases.
The set of all use case descriptions specifies the complete
functionality of the system.
When a user inputs a stimulus, the use case instance executes and
starts a transaction belonging to the use case.
Several use cases can begin in a similar way, it is not always
possible to decide what use case has been instantiated until it is
completed. Example A telephone exchange system. Use cases: A
local telephone call, An Order a wakeup call.

Use case diagram symbols:

Actor : Stick figure

Use case: oval labeled with name.
Line: Interaction b/w actor and use case
Line with arrow: Unidirectional association (requester to provider)
Double headed arrow:
Actor can generate request of the system or can request the actor
to take some action.
Use case and actor generalization / specialization: The line
originates from the specialization and point with the triangle with
the generalization.

What are Actors?

What interacts with the system.

Define the role a user can play.
Represent everything that needs to exchange information with the
system.
6

They constitute anything that is external to the system we are to

develop.
Types of actors :o Primary actors: The actors who are going to use the system
directly are called primary actors. e.g. customer. Primary actors
will govern the system structure.
o Secondary actors: The actors supervising and maintaining the
system. They exist so that primary actor can use the system.

Difference between actors and users:An actor can make a service request of the system, be requested to
provide a service, and interact with the system.

CLASS DIAGRAM
Class diagram is UML structure diagram which shows structure of the
designed system at the level of classes and interfaces, shows their
features, constraints and
relationships
associations, generalizations, dependencies, etc.
The main symbols shown on class diagrams are:
Classes
- represent the types of data themselves
Associations
- represent linkages between instances of classes
Attributes
- are simple data found in classes and their instances
Operations
- represent the functions performed by the classes and
their instances
Generalizations
- group classes into inheritance hierarchies
Associations and Multiplicity
An association is used to show how two classes are related to each
other.
Symbols indicating multiplicity are shown at each end of the
association

Reflexive associations
It is possible for an association to connect a class to itself

Generalization
8

Specializing a superclass into two or more subclasses

A generalization set is a labeled group of generalizations with a
common superclass
The label (sometimes called the discriminator) describes the
criteria used in the specialization

INTERACTION DIAGRAMS
In UML, interaction diagram is of two types:
sequence diagram and
collaboration diagram

SEQUENCE DIAGRAM
A sequence diagram shows the interaction amongst objects with respect
to time. In a sequence diagram, the objects appear on X-axis and the time
lines are shown in Y-axis.
An object is an instance of a class and is depicted by:
Objectname:classname
The dashed line appearing on the vertical axis is known as the lifeline
of the object.
The lifeline of an object depicts the amount of time the object is alive
in the use case. The lifeline of the object begins as soon as the actor
sends some message to the object.
There is a focus of control which is represented by rectangle.
The rectangle starts with the beginning of a set of procedure, or action
and ends when the procedure is completed.
Messages are an important element in a sequence diagram. Messages
represent interaction between objects, in which sending object asks
the receiving object to perform some operation. Messages are
represented by arrows from the sending objects to the receiving object
Types of messages:o Asynchronous messages: When asynchronous type of
message is sent, the sending object does not wait to receive as
response from the receiving object.
o Synchronous messages: When synchronous type of message
is sent, the sending object waits to receive a response from the
receiving object.

COLLABORATION DIAGRAM

A collaboration diagram depicts the sequence in which the objects send

or receive messages amongst themselves.
Unlike sequence diagrams, in collaboration diagrams the sequence of
events is not time ordered.
10

Collaboration diagrams depict the flow of events of a scenario in a use

case.
It shows the interaction between objects by organizing them.

Components of collaboration diagram: Similar to the sequence diagrams, objects are depicted by rectangles
(objectname:classname).
The links between objects are depicted by arrows and the direction of
the link is depicted by directional arrow.
The directional arrow shows the numbered message sent from the
sending object to the receiving object
A link in a collaboration diagram can represent multiple messages
whereas a link in the sequence diagram can depict only one single
message.

11

ACTIVITY DIAGRAM

The dynamic aspects of a system are modeled through activity

diagrams.
Activity diagrams are used to model the working of a process or an
operation.
The activities carried out in a process/workflow or operation are depicted
in an activity diagram.
Activity diagrams enable to visualize, understand, and document the
flow of activities in an operation or process.

Components of activity diagram

An activity represents execution of a step or set of steps in a process or
an operation.
Activity may be atomic or may consist of multiple steps.
An activity either manual or automated is used to complete a given task.
Transition represents the path from one activity to another activity.
An activity is represented by an oval shaped circle with rounded ends
and a transition is represented by a directed line.
Branching
Branching is used for making decisions in an activity diagram.
A branch consists of a guard condition that is used to control which
activity should be followed from a set of alternative activities once the
current activity is completed.
Similar to a flowchart, a boolean expression (guard condition) depicted
in brackets is used to take decision about which alternative path to
follow.
The decision branch is represented by a diamond with one incoming
transition and more than one outgoing transitions.
On each outgoing transition a guard condition is specified.
The activity corresponding to the outgoing transition that meets the
guard condition will be executed.
Modeling Concurrency
When modeling a process, we may encounter concurrent flows. In UML,
concurrent flows are depicted by synchronization bar to represent fork
and join of parallel activities.
A synchronization bar is represented by a thick horizontal line. Fork
divides the activities into two or more concurrent sub activities.
12

A fork may consist of one incoming transition and more than one
outgoing transitions. Join combines the two or more concurrent flows
when they are completed. Join is used for synchronization of concurrent
activities.

Swimlanes
A swimlane groups all the activities that are carried by the owner of the
swimlane.
Swimlanes are used to determine which business entity is responsible
for carrying out a specific activity.
Each swimlane is represented by a unique name. The transitions may
cross between entities in the swimlanes. Swimlanes are represented by
vertical lines that divide each group from its neighbours

13

STATECHART DIAGRAMS

Likewise activity diagrams, statechart diagram also models the dynamic

aspects of the system.
These diagrams are used to model the life cycle of the object, from the
time it is created until the object is destroyed.
The difference between activity diagrams and statechart diagrams is that
statechart diagrams are based on states and activity diagrams are based
on activities.
A statechart diagram models the states of an objects lifetime whereas
activity diagrams are used to model the sequences of activities in a
process or an operation.

States and state transition:

A state is one of the conditions that an object may satisfy during its
lifetime. In the given state, the object may perform some activity or waits
for some event to happen.
The state of the object may be determined by one of the possible value of
the attributes of the class.

Components of State Diagram:

A state is represented by a rectangle with rounded ends.

State transitions represent the change of an object from one state to
another state.
Likewise activity diagrams, the state transition are represented by a
directed line. In UML, state may also consist of entry action, do activity
and exit action.
Entry action takes place when the object enters a given state.
The do specifies the task/activities that must be performed while in the
current state and continues until the state is exited.
The entry and exit actions are preceded by a word entry/exit followed by a
/(slash)

14

Open for issue

issueBook( memberBarcodeID, bookBarcodeID ) /
updateBookStatus
Close for issue

15

DEPLOYMENT DIAGRAM

A deployment
diagram in
the Unified
Modeling
Language models
the physical deployment of artifacts on nodes. To describe a web site, for
example, a deployment diagram would show what hardware components
("nodes") exist (e.g., a web server, an application server, and a database
server), what software components ("artifacts") run on each node (e.g., web
application, database), and how the different pieces are connected.

Components of Deployment Diagram:

The nodes appear as boxes, and the artifacts allocated to each node

appear as rectangles within the boxes. Nodes may have subnodes, which
appear as nested boxes. A single node in a deployment diagram may
conceptually represent multiple physical nodes, such as a cluster of
database servers.
There are two types of Nodes:

o Device Node
o Execution Environment Node
Device nodes are physical computing resources with processing memory
and services to execute software, such as typical computers or mobile
phones. An execution environment node (EEN) is a software computing
resource that runs within an outer node and which itself provides a service
to host and execute other executable software elements.

16

COMPONENT DIAGRAM
In the Unified Modeling Language, a component diagram depicts
how components are wired together to form larger components and
or software systems. They are used to illustrate the structure of arbitrarily
complex systems.
Components:

A component is something required to execute a stereotype function.

Examples of stereotypes in components include executables, documents,
database tables, files, and library files.

Components are wired together by using an assembly connector to connect

the required interface of one component with the provided interface of
another component. This illustrates the service consumer - service
provider relationship between the two components.

An assembly connector is a "connector between two components that

defines that one component provides the services that another component
requires. An assembly connector is a connector that is defined from a
required interface or port to a provided interface or port.

When using a component diagram to show the internal structure of a

component, the provided and required interfaces of the encompassing
component can delegate to the corresponding interfaces of the contained
components.

A delegation connector is a "connector that links the external contract of a

component (as specified by its ports) to the internal realization of that
behavior by the components parts.

The example above illustrates what a typical Insurance policy administration

system might look like. Each of the components depicted in the above
diagram may have other component diagrams illustrating its internal
structure.

This may have a visual stereotype in the top right of the rectangle of a
small rectangle with two even smaller rectangles jutting out on the left.

17

The lollipop, a small circle on a stick represents an implemented or

provided interface. The socket symbol is a semicircle on a stick that can fit
around the lollipop. This socket is a dependency or needed interface.

Case Study: The Library Management

System

The library management system, from here on called the system,

consists of a library of books. A person, from here on called a
customer, interacts with the system and, among other functions,
should be able to borrow books for a period of time. An authorized
person, called a librarian, is the only person allowed to add or
remove books from the library. The librarian should be able to make
an entry in the system whenever a book is lost. Customers should be
able to borrow books from the library. When a customer borrows a
book or returns it, the librarian will update the loan information of
the library system to keep the system consistent. A customer should
be able to request a list of books he or she has on loan at the
moment. The librarian should be able to provide such a list for any
customer. Both the librarian and the customer should be able to
search the library for book titles. All searches are performed on titles
and not on physical copies of a title. But when a physical book is
loaned that copy will be identified. Note the difference between a
book title and a physical book copy. Each title in the library will have
one or more physical copiesbooksavailable for loan. A customer
searches for the title of a book and then borrows a physical copy of
that title. Each title will record the number of copies of the book it
18

represents that are available in the library. The system should

provide the capability of running an end-of-day process that includes
going through the existing reservations and verifying whether they
are still active. This task is triggered by the system timer.

Use Case Diagram:- Library Management System

19

Activity Diagram for Issue Book in Library :20

Activity Diagram for Return Book in Library:21

Class Diagram for Library System:22

23

State diagram for Book:

State diagram for Librarian:

Collaboration diagram for issuing Book:

24

Collaboration diagram for returning Book:

Sequence diagram for issuing book:

25

26

Sequence diagram for returning book:

27

Component diagram for Library Management System:

Deployment Diagram for Library management system:

28

Case Study: Online Ticket

Reservation System
To book a ticket for a user online ticket reservation system software and
to confirm the ticket booking, making the payment, printing the tickets has to
designed.
2.

OVERALL DESCRIPTION
1. LOGIN

Before entering the system, users have to login

Get the username and password from existing users.

Give new users the option to sign up.

2. AVAILABILITY

Get the source and destination.

Provide a dropdown box for the date.

Check availability of tickets.

3. RESCHEDULE

If tickets are available, get the number of passengers.

Get the name and age of all passengers.

If tickets are not available, reschedule.

4. PAYMENT DETAILS

Print the cost of the tickets.

Get the payment details from the user.

Confirm the details and the ticket.

Display confirmed ticket to the user.

29

Use Case Diagram

Choose source, destination

Check availability

Customer

Booking Server

Enter details

Request booking

Make payment

Bank System

Confirm booking

30

Activity Diagram

Display
availability

Get booking
request

Display
payment details

Get user's
payment details
No
If complete

Print ticket

31

CLASS DIAGRAM
Booking
Booking_no
Date
Total
Status
name

CustomerDetails
Name
Address
Email
Age
book()

Payment
Date
Amount

Pay()

SEQUENCE DIAGRAM
Customer

Server

Bank

Check availability
Yes
If no, reschedule
Enter information

Reconfirm booking

Payment
Confirm payment
Get ticket

32

COLLABORATION DIAGRAM

2: Yes

1: Check availability
4: Enter information
Customer

Server

3: If no, reschedule
5: Reconfirm booking
8: Get ticket
7: Confirm payment
6: Payment

Bank

33

STATE CHART DIAGRAM

Displaying
availability

Request
booking

Check availability

Displaying
payment details

User's payment
details

Print Ticket

34

COMPONENT DIAGRAM

Bank

Online
Booking Server

Customer

DEPLOYMENT DIAGRAM

Server Update

Railway
Database

User PC

35