MODULE 1 - AN OVERVIEW OF OBJECT-

ORIENTED SYSTEM DEVELOPMENT

PREPARED BY
PAVITHRA A
AP / IT
MODULE 1
• Introduction - Object Oriented System Development Methodology –
Unified process - Object Oriented Basics- UML diagrams-use case-
Case Study: The Next Gen POS system-inception-use case modeling-
relating use cases-When to use Use-cases.

• SELF STUDY TOPIC : 4+1 VIEW

CO1----Explore the processes involved in Object-Oriented System
Development.
OOM
• OOM = OOA + OOD
• Analysis (do the right thing ) emphasizes an investigation of the
problem and requirements, rather than a solution. For example, if a
new online trading system is desired, how will it be used? What are its
functions?
• Design (do the thing right ) emphasizes a conceptual solution (in
software and hardware) that fulfills the requirements, rather than its
implementation. For example, a description of a database schema and
software objects. Design ideas often exclude low-levelor "obvious"
detail.
OO BASICS
• Object : A car is an object a real-world entity, identifiably separate
from its surroundings. A car has a well-defined set of attributes in
relation to other object.
• Attributes: Data of an object ,Properties of an object.
• Methods: Procedures of an object or Behavior of an object.
• When developing an object oriented applications, two basic questions
arise,
What objects does the application need?
What functionality should those objects have?
OO Concepts
• Every object belongs to (is an instance of) a class
• An object may have fields, or variables
• The class describes those fields
• An object may have methods
• The class describes those methods
• A class is like a template, or cookie cutter
• You use the class’s constructor to make objects
Example: A “Rabbit” object

• You could (in a game, for example) create an object representing a rabbit
• It would have data:
• How hungry it is
• How frightened it is
• Where it is
• And methods:
• eat, hide, run, dig
Example
Class Hierarchy
• Classes are arranged in a tree like structure called a hierarchy
• The class at the root is named Object
• Every class, except Object, has a super class
• A class may have several ancestors, up to Object
• When you define a class, you specify its super class
• Every class may have one or more subclasses
Class hierarchy
Fundamental Concepts
Objects: Objects represent an entity and are the basic building block.

Class: Class is the blue print of an object.

Abstraction: Abstraction represents the behavior of an real world entity.

Encapsulation: Encapsulation is the mechanism of binding the data together and hiding
them from outside world.

Inheritance: Inheritance is the mechanism of making new classes from existing one.

Polymorphism: It defines the mechanism to exists in different forms.

Kinds of Access
Java provides four levels of access:

public: available everywhere

protected: available within the package (in the same subdirectory) and to
all subclasses

[default]: available within the package

private: only available within the class itself

The default is called package visibility
Types of Inheritance

Dynamic Inheritance Multiple Inheritance

Utility vehicle inherits the attributes from the Car and Truck
classes.
Building blocks of UML
• The building blocks of UML can be defined as:
• Things
• Relationships
• Diagrams
Things
• Things are the most important building blocks of UML. Things can be:
• Structural
• Behavioral
• Grouping
• Annotational
Structural things
The Structural things define the static part of the model.
They represent physical and conceptual elements.
Class:
Class represents set of objects having similar responsibilities.

Interface:
Interface defines a set of operations which specify the responsibility of a
class

Collaboration:
Collaboration defines interaction between elements.
Structural things
Use case:
• Use case represents a set of actions performed by a system for a specific goal.
Component:
• Component describes physical part of a system.
Node:
• A node can be defined as a physical element that exists at run time.
Behavioral things
• It consists of the dynamic parts of UML models.
Interaction:
• It is defined as a behavior that consists of a group of messages exchanged
among elements to accomplish a specific task.
State machine:
• It is useful when the state of an object in its life cycle is important. It defines
the sequence of states an object goes through in response to events.
Grouping things
• Grouping things can be defined as a mechanism to group elements of a UML
model together. There is only one grouping thing available:

Package:
• Package is the only one grouping thing available for gathering structural and
behavioral things.
Annotational things

• Annotational things can be defined as a mechanism to

capture remarks, descriptions, and comments of UML
model elements.

Note
• It is the only one Annotational thing available.
• A note is used to render comments, constraints etc of an
UML element.
 Relationships
It shows how elements are associated with each other and this association
describes the functionality of an application.
There are four kinds of relationships available.
Dependency:
Dependency is a relationship between two things in which change in one
element also affects the other one.
Association:
Association is basically a set of links that connects elements of an UML
model. It also describes how many objects are taking part in that
relationship.
Relationships
Generalization:
• Generalization can be defined as a relationship which connects a specialized
element with a generalized element. It basically describes inheritance
relationship in the world of objects.
Realization:
• Realization can be defined as a relationship in which two elements are
connected. One element describes some responsibility which is not
implemented and the other one implements them. This relationship exists in
case of interfaces.
Notations
Notations
UML
• UML stands for “Unified Modeling Language”
• It is a industry-standard graphical language .
• UML is a pictorial language used to make software blue prints
• It is used for specifying, visualizing, constructing, and documenting the artifacts
of software systems
• UML is different from the other common programming languages
• It uses mostly graphical notations.
• Simplifies the complex process of software design
Why UML for Modelling?
• Use graphical notation to communicate more clearly than
natural language (imprecise) and code(too detailed).
• Help acquire an overall view of a system.
• Tools can be used to generate code in various languages using
UML diagrams
• UML is not dependent on any one language or technology.
• A picture is worth than thousand words
• UML can be defined as a simple modeling mechanism to model
all possible practical systems in today’s complex environment.
Types ( 9 UML Diagrams)
• Use case diagram
• Class Diagram
• Behavior Diagram
• Interaction Diagram – Sequence Diagram, Communication / Collaboration
Diagram
• State chart Diagram
• Activity Diagram
• Implementation Diagram
• Component Diagram
• Deployment Diagram
3 ways to apply UML
• UML as Sketch
• Informal and incomplete diagrams created to explore difficult parts of the
problem or solution space, exploiting the power of visual languages.
• UML as Blueprint
• Relatively detailed design diagrams used either for
• Reverse Engineering or Forward Engineering
• UML as Programming Languages
• Complete executable specification of a softwaresystem in UML. Executable
code will be automatically generated
3 Perspectives to apply UML
• Conceptual Perspective
• The diagrams are interpreted as describing things in a situation of the real
world or domain of interest.
• Specification Perspective
• The diagrams (using the same notation as in the conceptual perspective)
describe software abstractions or components with specifications and
interfaces, but no commitment to a particular implementation
• Implementation Perspective
• The diagrams describe software implementations in a particular technology
 Structural Diagrams

• They represent the static aspect of the system. These static

aspects represent those parts of a diagram which forms the
main structure and therefore stable

The four structural diagrams are:

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram
Behavioral diagrams

Any system can have two aspects, static and dynamic.

A model is considered as complete when both the aspects are covered
fully.
It basically capture the dynamic aspect of a system.
Dynamic aspect can be further described as the changing/moving parts
of a system.

UML has the following five types of behavioral diagrams:

Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
Object Relationships and
Associations
• Association represents the relationships between objects and classes.
• Associations are bi- directional.
• The directions implied by the name are the forward direction and the
opposite is the inverse direction.
Aggregation
• Breaking down objects in to the objects from which they are
composed is de composition.
• Object attributes need not be simple data fields, attributes can
reference other objects.
• Since each object has an identity, one object can refer to other
objects. This is known as aggregation.
Static and Dynamic Binding
• Determining which function has to be involved at compile time is
called static binding. Static binding optimized the calls. (Ex) function
call.
• The process of determining at run time which functions to involve is
termed dynamic binding. Dynamic binding occurs when polymorphic
call is issued. It allows some method invocation decision to be
deferred until the information is known.
OOAD
• Object-Oriented Analysis : It emphasis on finding and describing the
objects or concepts in the problem domain.
• For example, in the case of the flight information system, some of the
concepts include Plane, Flight, and Pilot.
• Object-Oriented Design: It emphasis on defining software objects and
how they collaborate to fulfill the requirements.
• For example, a Plane software object may have a tail Number attribute and a
get Flight History method
 UML Development - Overview
ACTORS
REQUIREMENTS USE CASES Time
ELICITATION
SCENARIOS D
Requirements System/Object A
SEQUENCE
Engineering DIAGRAMS T
ANALYSIS A
ANALYSIS StateChart
Specify Domain CLASS DIAGRAM(S) DIAGRAMs
Objects D
I
OPERATION CONTRACTS
C
T
Architectural I
Design SUBSYSTEM CLASS/ DESIGN SEQUENCE DIAG.
DEPLOYMENT DIAGRAM O
Include OR COMPONENT
Design Objects DIAGRAMS N
DESIGN DIAGRAMS A
Detailed DESIGN R
Object Y
IMPLEMENTATION IMPLEMENTATION
Design Activity DIAGRAMS
CHOICES

IMPLEMENTATION
PROGRAM
Use case Diagram
Use cases diagrams describes the behavior of the target system from an
external point of view. Use cases describe "the meat" of the actual
requirements.
• Use cases. A use case describes a sequence of actions that provide
something of measurable value to an actor and is drawn as a horizontal
ellipse.
• Actors. An actor is a person, organization, or external system that plays
a role in one or more interactions with your system. Actors are drawn as
stick figures.
• Associations. Associations between actors and use cases are indicated
by solid lines. An association exists whenever an actor is involved with
an interaction described by a use case.
Use Case Diagrams
Use Case Diagram Rules
• Use a “stick man” figure for an actor, and show the actor’s name below the
stick man
• The UML standard allows for the option of using a class rectangle with
the stereotype «actor»

<<Stereotype>>
Command End
Item Hardware «actor»
Sensor
User
 Use Case Diagram Rules
• The only valid relationship between an actor and another actor is
generalization

Run Applications Install Applications

A User can Run Applications.

A Super User can Install
Applications and Run
Applications, since a Super
User is a specialization of
User.

User Super User

Use Case Diagram Rules
• Use only the following relationships between use cases
• Use the include relationship to show that the behavior of one use case is
wholly and unconditionally used in another use case
• Use the generalization relationship to show that a use case is a specialization
of another use case
Use Case Diagram Rules
• the include relationship

The Perform Transaction

use case includes the
Perform Transaction
processing specified by
both the Send Command
and Receive Response
Application «include» «include» use cases.

Send Command Receive Response

Use Case Diagram Rules
• the generalization relationship

Identify by retinal scan

Validate Identity Identify by fingerprint scan

Customer

Identify by badge scan

Use Case Diagram Rules
• Use the extend relationship to show that one use case conditionally
augment (or extend) the behavior of another use case.
Example of Extends relationship
Use Case Diagram Rules
• Extension points for a base use case are identified within the
specification of that base use case
• These are the locations where another use case may extend the base
use case. These extension points are optionally shown in a diagram by
listing them in a compartment of the base use case bubble under the
heading “extension points
• The extending relationship identifies, within parenthesis, the
extension point(s) in the use case being extended
Identify, within brackets, the condition
under which the extension is executed

Log In
extension pt::
Set Privileges

User

<<extends>>
(Set Privileges)
[Administrator Login event]]

Grant Administrator Privledges

Example of Extends, includes, and generalization
relationships
Use Case Diagram Rules
• There must be one extension point listed for each segment identified
in the extension use case
• Although considered optional, it is recommended that the extending
relationship also identify, within brackets, the condition under which
the extension is executed
Examples of Usecase
Diagram
Example : E-Commerce Application (Incomplete)
Missing a link between “Place Requisition” and “Supplier”
and missing use case relationships

Browse Catalog Process Delivery Order

Confirm Shipment

Customer Supplier

Place Requisition Send Invoice

Bank
Confirm Delivery
Example : Coffee Maker, “waiting state”
Not a good name for a use-case (bad example)
Example : Anesthesia System
(Incomplete)
Example :
Automated
Air
Traffic
Control
System
(AATCS)
Example : Elevator Control System
Example: Airport Check-in
Use-Case Modeling
• In use-case modeling, the system is looked upon as a black box whose boundaries are defined by
its functionality to external stimuli.
• The actual description of the use-case is usually given in plain text. A popular notation promoted
by UML is the stick figure notation.
• We will look into the details of text representation later. Both visual and text representation are
needed for a complete view.
• A use-case model represents the use-case view of the system. A use-case view of a system may
consist of many Use-case diagrams.
• An use-case diagram shows (the system), the actors, the use-cases and the relationship among
them.

06/12/2025 B.Ramamurthy 59
Components of Use-case Model
• The components of a Use-case model are:
• System Modeled
• Actors System Name

• Use-cases
• Stimulus
name

Use-case

06/12/2025 B.Ramamurthy 60
System
• As a part of the use-case modeling, the boundaries of the system are
developed.
• System in the use-case diagram is a box with the name appearing on
the top.
• Define the scope of the system that you are going to design with your
MyRo. (software scope)
MyRo Software Appln.

06/12/2025 B.Ramamurthy 61
Actors
• An actor is something or someone that interacts with
the system.
• Actor communicates with the system by sending and
receiving messages.
• An actor provides the stimulus to activate an Use-case.
• Message sent by an actor may result in more messages
to actors and to Use-cases.
• Actors can be ranked: primary and secondary; passive
and active.
• Actor is a role not an individual instance.

06/12/2025 B.Ramamurthy 62
Finding Actors
• The actors of a system can be identified by answering a number of
questions:
• Who will use the functionality of the system?
• Who will maintain the system?
• What devices does the system need to handle?
• What other system does this system need to interact?
• Who or what has interest in the results of this system?

06/12/2025 B.Ramamurthy 63
Use-cases
• A Use-case in UML is defined as a set of sequences of
actions a system performs that yield an observable result
of value to a particular actor.
• Actions can involve communicating with number of actors
as well as performing calculations and work inside the
system.
• A Use-case
• is always initiated by an actor.
• provides a value to an actor.
• must always be connected to at least one actor.
• must be a complete description.

06/12/2025 B.Ramamurthy 64
Finding Use-cases
• For each actor ask these questions:
• Which functions does the actor require from the system?
• What does the actor need to do?
• Could the actor’s work be simplified or made efficient by new functions in the
system?
• What events are needed in the system?
• What are the problems with the existing systems?
• What are the inputs and outputs of the system?

06/12/2025 B.Ramamurthy 65
Describing Use-cases
• Use-case Name:
• Use-case Number: system#.diagram#.Use-case#
• Authors:
• Event(Stimulus):
• Actors:
• Overview: brief statement
• Related Use-cases:
• Typical Process description: Algorithm
• Exceptions and how to handle exceptions:

06/12/2025 B.Ramamurthy 66
Example
• Number: A.132.4
• Name: Buy book online
• Author: B.Ramamurthy
• Event: Customer request one or more books
• System: Amazon.com
• Overview: Captures the process of purchasing one or more books
and the transactions associated with it.
• Related Use-case: A.132.5, A.132.8
• Typical Process Description with exceptions handled.
NOTE : All these can be in a tabular form, say, in an Excel worksheet
for example.

06/12/2025 B.Ramamurthy 67
Realizing Use-cases
• Validation is done up front. As soon as the model is ready it has to be
presented and discussed with the customers.
• Use-cases are implementation independent descriptions of the
functionality of the system.
• Use-case can be realized in the next stages of software development
using, say, a class diagram.

06/12/2025 B.Ramamurthy 68
Use case modeling

• The basic requirements of the system are called the functional requirements
• In order to understand the working of these functional requirements, the
developers and users create a set of scenarios .these scenarios are nothing but the
text stories. these text stories are called as use cases.
• The use cases are the textual representation of particular scenario whereas the use
case model is the graphical representation of the scenario.
USE CASE TEMPLATE
Use case Write the name of the scenario
Primary actor Specify the role of the entity who interacts with the system

Goal in context Specify the purpose of this use case scenario

preconditions The condition that is to be satisfied before the use case start

scenario Sequence of steps that describe the main scenario

Triggers The triggering event due to which the function starts is described.
extension points The extension points describe the extend relationship

exceptions Describe the exceptional situations that may occur during the execution
of the use case

priority Describe the necessity of the system to be implemented

Open issues Certain additional issues that are required for execution of the scenario
and that are not specified in the main scenario.
When to use Usecase Diagram?
• Gather user requirements: Use case diagrams help identify and clarify user needs.
• Communicate with non-technical stakeholders: Use case diagrams are a simple
way to convey system functionality to non-technical stakeholders.
• Plan features: Use case diagrams help ensure that the system design meets user
needs.
• Define system boundaries: Use case diagrams help clarify what is included in the
system and what is external.
• Model system flow: Use case diagrams help model the basic flow of events in a use
case.
• Define functional requirements: Use case diagrams help define and organize the
functional requirements of a system.
 CASE STUDY
NEXTGEN POS SYSTEM