Object-Oriented System Analysis

Object-oriented system analysis focuses on

modelling the components of a system as
"objects" that interact with each other.
 A class
A class represents a collection of objects having same characteristic properties that exhibit common
behavior. It gives the blueprint or description of the objects that can be created from it.
A class is a blueprint or template that defines the structure and behavior (attributes/properties and
methods/behaviour) of objects. Creation of an object as a member of a class is called
instantiation. Thus, object is an instance of a class.
A class is a collection of things, or ideas that have the same characteristics. Each of these things or
concepts is named as object.
A dog as a class:
Attributes /properties– Name, Age and breed
Methods/behaviour – bark

A car as a class:
Attributes /properties– brand, colour
Methods/behaviour - drive
Different ways of thinking about a class
 An object
An object is a specific instance of a class. It’s a thing created
based on the blueprint provided by the class.
• Class – Dog
• Object – myDog(an instance of the Dog class) (name: Jack,
breed:…)

• Class – blueprint
• Object – actual thing created using the blueprint

• Objects also have behavior: a car can move from one place to
another and a dog can bark.
Properties/attributes represent the state of an object.
Example: the properties of a car, such as color, manufacturer, and cost, are
abstract descriptions.
 Behavior (Object Behavior and methods)

• We can drive a car, we can ride an elephant, or the

elephant can eat a peanut. Each of these statements is a
description of the object’s behavior.
• The state of an object is basically the condition of an
object, or set of circumstances describing the item. It is
noticed that state of bank account object will cover
latest and available balance.
• In the object model, object behavior is described in
methods or procedures.
• A method implements the behavior of an object.
 Overview of Object Modelling
• Object modelling involves creating visual
representations of objects, their relationships,
and their interactions within a system.
 Encapsulation
• Encapsulation refers to an object hiding its
attributes behind its operations (it seals the
attributes in a capsule, with operations on the
edge).
• Bundling of data and methods in a single unit.
 Relationships
Relationships: Connections between objects (e.g.,
association, aggregation).

No object is an island. All objects are connected to

other objects, directly or indirectly, strongly or loosely.
By connecting objects, we make them more powerful.
Connections allow us to navigate around to find extra
information and behavior. When we’re modeling with
objects, we can connect them in two principal ways:
association or aggregation.
 Association
Association is a weak form of connection: the
objects may be part of a group, or family, of
objects but they’re not completely dependent on
each other.
 Association

For example, consider a car, a driver, a passenger and

another passenger. When the driver and the two
passengers are in the car, they’re associated: they all go in
the same direction, they occupy the same volume in
space, and so on. But the association is loose: the driver
can drop off one of the passengers to go their separate
way, so that the passenger is no longer associated with
the other objects.
 Aggregation
Aggregation means putting objects together to make a bigger
object.
Manufactured items usually form aggregations: for example,
a microwave is made up of a cabinet, a door, an indicator
panel, buttons, a motor, a glass plate, a magnetron, and so on.
Aggregations usually form a part–whole hierarchy.
Aggregation implies close dependency, at least of the whole
to the part; for example, a magnetron is still a magnetron if
you take it out of its microwave, but the microwave would be
useless without the magnetron, because it wouldn’t be able to
cook anything.
This figure shows how we can draw a house
as an aggregation
 A Class hierachy
Classification – grouping things into classes.
Inheritance: Trains inherit the characteristics
of land vehicles.
Generalization/specialization: A train is more
specialized than a land vehicle; a land
vehicle is more generalized than a train.
Parent/child: LandVehicle is the parent of
Train; Train is a child of LandVehicle.
Superclass/subclass: LandVehicle is the
superclass of Train; Train is a subclass of
LandVehicle.
Base/derived: LandVehicle is the base from
which Train is derived.
 Benefits of OO Modelling
• it helps in faster development of software.
• It is easy to maintain. It supports relatively
hassle-free upgrades.
• It enables reuse of objects, designs, and
functions.
• It reduces development risks, particularly in
integration of complex systems.
Unified Modelling Language (UML)
Unified:
• It is to bring together the information systems
and technology industry’s best engineering
practices.
• UML is a standardized modelling language for
designing and visualizing object-oriented
systems.
 UML Background
• What are models?
• A complete description of a system from a
particular perspective
• Simplification of reality
 Why models?
Modeling achieves four aims:
• Helps you to visualize a system as you want it to
be.
• Permits you to specify the structure or behavior
of a system.
• Gives you a template that guides you in
constructing a system.
• to better understand the system you are
developing.
 Four Principles of Modeling
• The model you choose influences how the
problem is attacked.
• Every model may be expressed at different
levels of precision.
• The best models are connected to reality.
• No single model is sufficient.
three major elements:
• The Building Blocks
• The Rules
• Some Common Mechanisms
 UML Diagrams
• Diagram is the graphical presentation of a set of elements, most often
rendered as a connected graph of vertices (things) and arcs (relationships).
the UML includes nine such diagrams:
• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Statechart diagram
• Activity diagram
• Component diagram
• Deployment diagram
 A class diagram
• A class diagram shows a set of classes,
interfaces, and collaborations and their
relationships.
• Class diagrams that include active classes
address the static process view of a system.
 Object diagram
• Object diagrams represent static snapshots of
instances of the things found in class diagrams
• These diagrams address the static design view
or static process view of a system
• An object diagram shows a set of objects and
their relationships
 Use case diagram
• A use case diagram shows a set of use cases
and actors and their relationships
• Use case diagrams address the static use case
view of a system.
• These diagrams are especially important in
organizing and modeling the behaviors of a
system.
 Interaction Diagrams
• Both sequence diagrams and collaboration
diagrams are kinds of interaction diagrams
• Interaction diagrams address the dynamic
view of a system
• A sequence diagram is an interaction diagram
that emphasizes the time- ordering of
messages
 Statechart diagram
• A statechart diagram shows a state machine,
consisting of states, transitions, events, and
activities.
• Statechart diagrams address the dynamic view
of a system.
• They are especially important in modeling the
behavior of an interface, class, or
collaboration and emphasize the event-
ordered behavior of an object.
 Activity diagram
• An activity diagram is a special kind of a
statechart diagram that shows the flow from
activity to activity within a system
• Activity diagrams address the dynamic view of
a system
• They are especially important in modeling the
function of a system and emphasize the flow
of control among objects
 A collaboration diagram
• is an interaction diagram that emphasizes the
structural organization of the objects that send
and receive messages
• Sequence diagrams and collaboration
diagrams are isomorphic, meaning that you
can take one and transform it into the other
 Component diagram
• A component diagram shows the
organizations and dependencies among a set
of components.
• Component diagrams address the static
implementation view of a system
• They are related to class diagrams in that a
component typically maps to one or more
classes, interfaces, or collaborations
 Deployment diagram
• A deployment diagram shows the
configuration of run-time processing nodes
and the components that live on them
• Deployment diagrams address the static
deployment view of an architecture
 System Design

• System design involves translating

requirements into a blueprint for building the
system.
 General Design Guidelines
• Ensure the design meets user needs and
business requirements.
• Focus on scalability, maintainability, and
usability.
• Optimize system performance and reliability.
 Output Design
Output design specifies how information is
presented to users. This includes:
• Printed Reports: Detailed documents,
summaries, or summaries with visuals (charts,
tables).
• Screen Outputs: Interactive dashboards or
simple displays showing real-time data.
• Storage Media Outputs: Outputs to tapes,
disks, or databases for archival or backup.
 Input Design
• Input design ensures efficient and accurate
data entry into the system.
• Data Entry Screens: Form fields for user input
with validation rules.
• Help Screens: Provide user guidance, tooltips,
and error messages.
 Real-Life Case Studies
• Banking Systems: Automated Teller Machines
(ATMs) showcasing input (card insertion, PIN
entry) and output (receipts, screen messages).
• E-Commerce Platforms: Managing product
catalogs, customer interactions, and sales
reports.
• Healthcare Systems: Patient record
management, appointment scheduling, and
medical report generation.