Object oriented

Software Engineering

1
 Object Oriented Paradigm

• The object-oriented paradigm took its shape from the initial

concept of a new programming approach, while the interest
in design and analysis methods came much later.
• The first object–oriented language was Simula (Simulation
of real systems) that was developed in 1960 by researchers
at the Norwegian Computing Center.
• In 1970, Alan Kay and his research group at Xerox PARK
created a personal computer named Dynabook and the first
pure object-oriented programming language (OOPL) -
Smalltalk, for programming the Dynabook.
• In the 1980s, Grady Booch published a paper titled Object
Oriented Design that mainly presented a design for the
programming language, Ada.
• In the ensuing editions, he extended his ideas to a complete
object–oriented design method.
• In the 1990s, Coad incorporated behavioral ideas to object-
oriented methods.
• The other significant innovations were Object Modelling
Techniques (OMT) by James Rumbaugh and Object-
Oriented Software Engineering (OOSE) by Ivar Jacobson.
 Object Oriented System
• In object-oriented software engineering, the software
developer identifies and organizes the application in terms of
object-oriented concepts, prior to their final representation
in any specific programming language or software tools.
 Phases in Object-Oriented Software
Development
• The major phases of software development using object–
oriented methodology are
• Object-oriented analysis,
• Object-oriented design, and
• Object-oriented implementation.
 Object–Oriented Analysis
• In this stage, the problem is formulated, user requirements
are identified, and then a model is built based upon real–
world objects.
• The analysis produces models on how the desired system
should function and how it must be developed.
• The models do not include any implementation details so
that it can be understood and examined by any non–
technical application expert.
 Object–Oriented Design
• Object-oriented design includes two main stages, namely,
system design and object design.
• System Design
• In this stage, the complete architecture of the desired
system is designed.
• The system is conceived as a set of interacting subsystems
that in turn is composed of a hierarchy of interacting
objects, grouped into classes.
• System design is done according to both the system
analysis model and the proposed system architecture.
• Here, the emphasis is on the objects comprising the
system rather than the processes in the system.
• Object Design
• In this phase, a design model is developed based on both
the models developed in the system analysis phase and
the architecture designed in the system design phase.
• All the classes required are identified.
• The designer decides whether −
• new classes are to be created from scratch,
• any existing classes can be used in their original form,
or
• new classes should be inherited from the existing
classes.
• The associations between the identified classes are
established and the hierarchies of classes are identified.
• Besides, the developer designs the internal details of the
classes and their associations, i.e., the data structure for
each attribute and the algorithms for the operations.
 Object–Oriented Implementation and
Testing
• In this stage, the design model developed in the object
design is translated into code in an appropriate programming
language or software tool.
• The databases are created and the specific hardware
requirements are ascertained.
• Once the code is in shape, it is tested using specialized
techniques to identify and remove the errors in the code.
 Object Oriented Principles
The four major principles of Object Oriented System are −
• Abstraction
• Encapsulation
• Modularity
• Hierarchy
 Abstraction
• Abstraction means to focus on the essential features of an
element or object in OOP, ignoring its extraneous or
accidental properties.
• The essential features are relative to the context in which the
object is being used.
• Grady Booch has defined abstraction as follows −
• “An abstraction denotes the essential characteristics of an
object that distinguish it from all other kinds of objects
and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer.”
• Example − When a class Student is designed, the attributes
enrolment_number, name, course, and address are included
while characteristics like pulse_rate and size_of_shoe are
eliminated, since they are irrelevant in the perspective of the
educational institution.
 Encapsulation
• Encapsulation is the process of binding both attributes and
methods together within a class.
• Through encapsulation, the internal details of a class can be
hidden from outside.
• The class has methods that provide user interfaces by which the
services provided by the class may be used.
• Example: In a class representing a bank account, you encapsulate
the account balance and provide methods like "deposit" and
"withdraw" to control access to and manipulation of the balance
data.
 Modularity
• Modularity is the process of decomposing a problem
(program) into a set of modules so as to reduce the overall
complexity of the problem. Booch has defined modularity as
−
• “Modularity is the property of a system that has been
decomposed into a set of cohesive and loosely coupled
modules.”
• Modularity is intrinsically linked with encapsulation.
• Modularity can be visualized as a way of mapping
encapsulated abstractions into real, physical modules having
high cohesion within the modules and their inter–module
interaction or low coupling.
 Hierarchy
• In Grady Booch’s words, “Hierarchy is the ranking or ordering
of abstraction”.
• Through hierarchy, a system can be made up of interrelated
subsystems, which can have their own subsystems and so on
until the smallest level components are reached.
• It uses the principle of “divide and conquer”.
• Hierarchy allows code reusability.
• The two types of hierarchies in OOA are −
• “IS–A” hierarchy − It defines the hierarchical relationship
in inheritance, whereby from a super-class, a number of
subclasses may be derived which may again have
subclasses and so on. For example, if we derive a class
Rose from a class Flower, we can say that a rose “is–a”
flower.
• “PART–OF” hierarchy − It defines the hierarchical
relationship in aggregation by which a class may be
composed of other classes.
• For example, a flower is composed of sepals, petals,
stamens, and carpel.
• It can be said that a petal is a “part–of” flower.
 Object Oriented
Analysis and Design
 OOA - Object Oriented Analysis

• In the system analysis or object-oriented analysis phase of

software development, the system requirements are
determined, the classes are identified and the relationships
among classes are identified.
• The three analysis techniques that are used in conjunction
with each other for object-oriented analysis are:
• Object modelling,
• Dynamic modelling, and
• Functional modelling.
• The purpose of any analysis activity in the software life-cycle
is to create a model of the system's functional requirements
that is independent of implementation constraints.
• The main difference between object-oriented analysis and
other forms of analysis is that by the object-oriented
approach we organize requirements around objects, which
integrate both behaviors (processes) and states (data)
modeled after real world objects that the system interacts
with.
• In other or traditional analysis methodologies, the two
aspects: processes and data are considered separately.
• For example, data may be modeled by ER diagrams, and
behaviors by flow charts or structure charts.
• Common models used in OOA are use cases and object
models.
• Use cases describe scenarios for standard domain functions
that the system must accomplish.
• Object models describe the names, class relations (e.g. Circle
is a subclass of Shape), operations, and properties of the
main objects.
• User-interface mockups or prototypes can also be created to
help understanding.
 OOD - Object-oriented design
• During object-oriented design (OOD), a developer applies
implementation constraints to the conceptual model
produced in object-oriented analysis.
• Such constraints could include the hardware and software
platforms, the performance requirements, persistent storage
and transaction, usability of the system, and limitations
imposed by budgets and time.
• Concepts in the analysis model which is technology
independent, are mapped onto implementing classes and
interfaces resulting in a model of the solution domain, i.e., a
detailed description of how the system is to be built on
concrete technologies.
• Important topics during OOD also include the design of
software architectures by applying architectural patterns and
design patterns with the object-oriented design principles.
 OOM - Object-oriented modeling
• Object-oriented modeling (OOM) is a common approach to
modeling applications, systems, and business domains by
using the object-oriented paradigm throughout the entire
development life cycles.
• OOM is a main technique heavily used by both OOD and
OOA activities in modern software engineering.
• Object-oriented modeling typically divides into two aspects
of work:
• The modeling of dynamic behaviors like business
processes and use cases, and
• The modeling of static structures like classes and
components.
• OOA and OOD are the two distinct abstract levels (i.e. the
analysis level and the design level) during OOM.
• The Unified Modeling Language (UML) and SysML are the
two popular international standard languages used for
object-oriented modeling.
 Object Modelling

• Object modelling develops the static structure of the

software system in terms of objects.
• It identifies the objects, the classes into which the objects
can be grouped into and the relationships between the
objects.
• It also identifies the main attributes and operations that
characterize each class.
• The process of object modelling can be visualized in the
following steps −
• Identify objects and group into classes
• Identify the relationships among classes
• Create user object model diagram
• Define user object attributes
• Define the operations that should be performed on the
classes
• Review glossary
 Dynamic Modelling
• After the static behavior of the system is analyzed, its
behavior with respect to time and external changes needs to
be examined.
• This is the purpose of dynamic modelling.
• Dynamic Modelling can be defined as “a way of describing
how an individual object responds to events, either internal
events triggered by other objects, or external events
triggered by the outside world”.
• The process of dynamic modelling can be visualized in the
following steps −
• Identify states of each object
• Identify events and analyze the applicability of actions
• Construct dynamic model diagram, comprising of state
transition diagrams
• Express each state in terms of object attributes
• Validate the state–transition diagrams drawn
 Functional Modelling
• Functional Modelling is the final component of object-
oriented analysis.
• The functional model shows the processes that are
performed within an object and how the data changes as it
moves between methods.
• It specifies the meaning of the operations of object
modelling and the actions of dynamic modelling.
• The functional model corresponds to the data flow diagram
of traditional structured analysis.
• The process of functional modelling can be visualized in the
following steps −
• Identify all the inputs and outputs
• Construct data flow diagrams showing functional
dependencies
• State the purpose of each function
• Identify constraints
• Specify optimization criteria
 Structured Analysis vs. Object
Oriented Analysis
• Analysis simple means to study or examine the structure of
something, elements, and system requirements in detail,
and methodical way.
• Structured analysis and Object-oriented analysis both are
important for software development and are analysis
techniques used in software engineering.
• But both are different from each other.
• Structured Analysis and Object-Oriented Analysis (OOA) are
two software development methodologies that are used to
design and develop software systems.
• While they have some similarities, they differ in a number of
key ways.
 Structured Analysis
• Focus on processes:
• Structured Analysis focuses on the processes involved in a
software system, modeling them as a series of connected
steps.
• Top-down approach:
• Structured Analysis follows a top-down approach,
breaking down complex systems into smaller, simpler
parts that can be more easily understood.
• Data-centered:
• Structured Analysis focuses on the data that a software
system manipulates, modeling it as data flows between
processes.
• Emphasis on functional decomposition:
• Structured Analysis emphasizes the functional
decomposition of a software system into smaller,
independent functions.
• Structured analysis is a method of development that allows
and gives permission to the analyst to understand and know
about the system and all of its activities in a logical way.
• It is simply a graphic that is used to specify the presentation
of the application.
 Object-Oriented Analysis (OOA)
• Focus on objects:
• OOA focuses on the objects involved in a software system,
modeling them as instances of classes that encapsulate
both data and behavior.
• Bottom-up approach:
• OOA follows a bottom-up approach, building complex
systems from smaller, simpler objects that can be more
easily understood.
• Object-centered:
• OOA focuses on the objects that make up a software
system, modeling their relationships and interactions.
• Emphasis on object-oriented design patterns:
• OOA emphasizes the reuse of objects and object-oriented
design patterns, reducing the amount of code that needs
to be written and improving the quality and consistency of
the software.
• Object-Oriented Analysis (OOA) is a technical approach
generally used for analyzing and application designing,
system designing, or even business designing just by applying
object-oriented programming even with the use of visual
modeling throughout the process of development to just
simply guide the stakeholder communication and quality of
the product.
• It is actually a process of discovery where a team of
developers understands and models all the requirements of
the system.
 Object Oriented Design and
Modeling
• Most modern software systems are developed using object
oriented techniques.
• The requirements are usually Expressed mainly with use
case.
• Most documentation for object oriented projects is
presented in the form of UML diagram.
• The UML is a graphical design notation, standardized by the
Object Management Group(OMG), with wide industry and
academic support.
• During the design step, you will decide on exactly which class
to create, documenting each one with the class diagram.
• You may need to refine your user class, and produce other
diagrams to document the behavior of your objects.
• UML 2.0 (The latest UML version is 2.5) defines 13 diagram
types divided into three categories (and one subcategory) as
shown in the following list:
• Structure Diagram
• Behavior Diagram
 Structure Diagrams
• A structure diagram describes things that will be in the
system you are designing.
• For example,
• The class diagram (one type of structure diagram) shows
relationships among the classes that will represent objects
in the system such as inventory items, vehicles, expense
reports, and coffee requisition forms.
• The following list summarizes UML’s structure diagrams:
• Class Diagram — Describes the classes that make up the
system, their properties and methods, and their
relationships.
• Object Diagram — Focuses on a particular set of objects
and their relationships at a specific time
• The most basic of the structure diagrams is the class
diagram.
• In a class diagram, a class is represented by a rectangle.
• The class’s name goes at the top, is centered, and is in bold.
• Two sections below the name give the class’s properties and
methods.
• A method is a routine that makes an object do something.
• For example, the Student class might have a DoAssignment
method that makes the Student object work through a
specific class assignment.
• The figure bellow shows a simple diagram for the Student
class
• Some people add annotations to class representations to
give you more detail.
• Most class diagrams include the data types of properties and
parameters passed into methods, as shown in Figure above.
• You can also add the symbols shown in Table bellow to the
left of a class member to show its visibility within the
project.
Class Diagram Visibility Symbols
• Class diagrams also often show relationships among classes.
• Lines connect classes that are related to each other.
• A variety of line styles, symbols, arrowheads, and
annotations give more information about the kinds of
relationships.
• The simplest way to use relationships is to draw an arrow
indicating the direction of the relationship and label the
arrow with the relationship’s name.
• For example, in a school registration application, you might
draw an arrow from the Student class to the Course class to
indicate that a Student is associated with the Courses that
student is taking.
• You could label that arrow “is taking.”
• At the line’s endpoints, you can add symbols to indicate how
many objects are involved in the relationship.
• Table bellow shows symbols you can add to the ends of a
relationship.
Class Diagram Multiplicity Indicators
• The class diagram in following figure shows the “is taking”
relationship between the Student and Course classes.
• In that relationship, 1 Student object corresponds to 1 or
more Course objects.
The relationship in this class diagram indicates
that 1 Student takes 1 or more Courses
• Another important type of class diagram relationship is
inheritance.
• In object‐oriented programming, one class can inherit the
properties and methods of another.
• For example, an honors student is a type of student.
• To model that in an object‐oriented program, you could
define an HonorsStudent class that inherits from the Student
class.
• The HonorsStudent class automatically gets any properties
and methods defined by the Student class (Name, Grade,
HomeRoom, and DoAssignment).
• You can also add new properties and methods if you like.
• Perhaps you want to add a GPA property to the
HonorsStudent class.
• In a class diagram, you indicate inheritance by using a hollow
arrowhead pointing from the child class to the parent class.
• Figure bellow shows that the HonorsStudent class inherits
from the Student class.
A class diagram indicates inheritance
with a hollow arrowhead.
• Class diagrams for complicated applications can become cluttered and
hard to read if you put
• everything in a single huge diagram. To reduce clutter, developers
often draw multiple class
• diagrams showing parts of the system. In particular, they often make
separate diagrams to show
• inheritance and other relationships.
 Class Diagram Relationships
• Classes are interrelated to each other in specific ways.
• In particular, relationships in class diagrams include different
types of logical connections.
• The following are such types of logical connections that are
possible in UML:
• Association
• Directed Association
• Reflexive Association
• Multiplicity
• Aggregation
• Composition
• Inheritance/Generalization
• Realization
 Association

• Association is a broad term that encompasses just about any

logical connection or relationship between classes.
• For example, passengers and airline may be linked as above.
 Directed Association
• Directed Association refers to a directional relationship represented
by a line with an arrowhead.
• The arrowhead depicts a container-contained directional flow.
 Reflexive Association

• This occurs when a class may have multiple functions or

responsibilities.
• For example, a staff member working in an airport may be a
pilot, aviation engineer, ticket dispatcher, guard, or
maintenance crew member.
• If the maintenance crew member is managed by the aviation
engineer there could be a managed by relationship in two
instances of the same class.
 Multiplicity
• Multiplicity is the active logical association when the
cardinality of a class in relation to another is being depicted.
• For example, one fleet may include multiple airplanes, while
one commercial airplane may contain zero to many
passengers.
• The notation 0..* in the diagram means “zero to many”.
 Aggregation
• Aggregation refers to the formation of a particular class as a result of
one class being aggregated or built as a collection.
• For example, the class “library” is made up of one or more books,
among other materials.
• In aggregation, the contained classes are not strongly dependent on
the lifecycle of the container.
• In the same example, books will remain so even when the library is
dissolved.
• To show aggregation in a diagram, draw a line from the parent class to
the child class with a diamond shape near the parent class.
• To show aggregation in a diagram, draw a line from the parent class to
the child class with a diamond shape near the parent class.
 Composition
• The composition relationship is very similar to the aggregation
relationship.
• with the only difference being its key purpose of emphasizing the
dependence of the contained class to the life cycle of the container
class.
• That is, the contained class will be eliminated when the container
class is destroyed.
• For example, a shoulder bag’s side pocket will also cease to exist once
the shoulder bag is destroyed.
• To show a composition relationship in a UML diagram, use a
directional line connecting the two classes, with a filled diamond
shape adjacent to the container class and the directional arrow to the
contained class.
 Inheritance/Generalization
• Inheritance refers to a type of relationship wherein one
associated class is a child of another by virtue of assuming
the same functionalities of the parent class.
• In other words, the child class is a specific type of the parent
class.
• To show inheritance in a UML diagram, a solid line from the
child class to the parent class is drawn using an unfilled
arrowhead.
 Behavior Diagrams

• UML defines three kinds of basic behavior diagrams: activity

diagrams, use case diagrams, and state machine diagrams.
• The following sections provide brief descriptions of these
kinds of diagrams and give a few simple examples.
• After eight minutes, you check the cookies.
• If the cookies aren’t done, you bake them for one more
minute.
• You continue checking and baking for one more minute as
long as the cookies are not done.
• When the cookies are done, you enter the stopping state
indicated by the circled black circle.
 Activity Diagrams

• An activity diagram represents work flows for activities.

• They include several kinds of symbols connected with arrows
to show the direction of the work flow.
• Table bellow summarizes the symbols.
Activity Diagram Symbols
• Figure bellow shows a simple activity diagram for baking
cookies.
• The first thick bar starts three parallel activities: Start oven,
mix dry ingredients, and mix wet ingredients.
• If you have assistant cookie chefs (perhaps your children, if
you have any), those steps can all proceed at the same time
in parallel.
• When the three parallel activities all are done, the work flow
resumes after the second thick bar.
• The next step is to combine all the ingredients.
• A test then checks the batter’s consistency.
• If the batter is too sticky, you add more flour and recheck the
consistency.
• You repeat that loop until the batter has the right
consistency.
• When the batter is just right, you roll out the cookies, wait
until the oven is ready (if it isn’t already), and bake the
cookies for eight minutes.
An activity diagram is a bit like a flowchart
showing how work flows.
 Sequence Diagram
• A sequence diagram shows how objects collaborate in a particular
scenario.
• It represents the collaboration as a sequence of messages.
• Objects participating in the collaboration are represented as rectangles
or sometimes as stick figures for actors.
• They are labeled with a name or class.
• If the label includes both a name and class, they are separated by a
colon.
• Below each of the participants is a vertical dashed line called a lifeline.
• The lifeline basically represents the participant sitting there waiting for
something to happen.
• An execution specification (called an execution or informally an
• Figure bellow shows a customer, a clerk, and the Movie class interacting to print a
ticket for a movie.
• The customer walks up to the ticket window and requests the movie from the clerk.
• The clerk uses a computer to ask the Movie class whether tickets are available for
the desired show.
• The Movie class responds.
• Notice that the Movie class’s response is asynchronous.
• The class fires off a response and doesn’t wait for any kind of reply.
• Instead it goes back to twiddling its electronic thumbs, waiting for some other
request.
• If the class’s response is false, the interaction ends. (This scenario covers only the
customer
• successfully buying a ticket.)
• If the response is true, control returns to the clerk, who uses the computer to ask
the Movie class to select a seat.
• This causes another execution to run on the Movie class’s lifeline.
• The Movie class in turn asks the customer to pick a seat from those
that are available.
• The customer is still waiting for the initial request to finish, so this is
an overlapping execution for the customer.
• After the customer picks a seat, the Movie class issues a ticket to the
clerk.
• The clerk then prints the ticket and hands it to the customer.
• The point of this diagram is to show the interactions that occur
between the participants and the order in which they occur.
 Use Case Diagram

• A use case diagram represents a user’s interaction with the system.

• Use case diagrams show stick figures representing actors (someone or
something that performs a task) connected to tasks represented by
ellipses.
• To provide more detail, you can use arrows to join subtasks to tasks.
• Use the annotation <<include>> to mean the task includes the
subtask. (It can’t take place without the subtask.)
• If a subtask might occur only under some circumstances, connect it to
the main task and add the annotation <<extend>>.
• If you like, you can add a note indicating when the extension occurs.
• (Usually both <<include>> and <<extend>> arrows are dashed.)
• Figure bellow shows a simple online shopping use case
diagram.
• The customer actor performs the “Search site for products”
activity.
• If he finds something he likes, he also performs the “Buy
products” extension.
• To buy products, the customer must log in to the site, so the
“Buy products” activity includes the “Log on to site” activity.
A use case diagram shows actors and the tasks
they perform (possibly with subtasks and
extensions)
• The website’s search engine also participates in the “Search
site for products” activity.
• When the customer starts a search, the engine performs the
“Find matching products” activity.
• The “Search” activity cannot work without the “Find”
activity, so the “Find” activity is included in the “Search”
activity.
• In the diagram, these are represented as gray or white
rectangles drawn on top of the lifeline.
• You can draw overlapping rectangles to represent
overlapping executions.
• Labeled arrows with solid arrowheads represent
synchronous messages.
• Arrows with open arrowheads represent asynchronous
messages.
• Finally, dashed arrows with open arrowheads represent
return messages sent in reply to a calling message.
A sequence diagram shows the timing of
messages between collaborating objects.