Software Engineering Unit 4 .......... 11-August-2021

CSE3005-Software Engineering
 Unit -4 : OBJECT ORIENTED LIFE CYCLE

 02- August - 2021
UNIT -4 : OBJECT ORIENTED LIFE CYCLE
 Overview of Object Oriented Systems Development

 - Object Oriented System Development Methodology
 - Object Orientation
 - Unified Approach
 Object Basics
 Object Oriented Systems Development Life Cycle
 Object Oriented Methodologies
 - Rumbaugh Methodology
 - Booch Methodology
 – Jacobson Methodology Unified Approach.
OVERVIEW OF OBJECT ORIENTED SYSTEMS DEVELOPMENT
 OOSD is way to develop software by building self-contained modules or objects.
 It helps to easily replace, modify, and reuse the development process
 It encourages the view of the world as a system of cooperative and collaborating objects
 Software is a collection of objects, it encapsulates their data as well as the functionality to model real world.
 Each object has attributes (data) and methods (functions)
 Objects are grouped into Classes, each object responsible for itself
 E.g., Windows application (open, close, display)
 visual modeling throughout the development life cycles for better communication and product quality.
 System Development activities consist of

 System Analysis
 Modeling
 Design
 Implementations
 Testing and maintenance
 Benefits of Object Orientation

 Faster development,
 Reusability,
 Increased quality
 modeling the real world and provides us with the stronger equivalence of the real world‘s entities
(objects).
 Raising the level of abstraction to the point where application can be implemented in the same
terms as they are described.
DIFFERENCE B/W TRADITIONAL AND OBJECT ORIENTED
OBJECT ORIENTED APPROACH
 OO Methods enables to develop set of objects that work together to produce software which is similar
to traditional techniques
 It adapts to
 Changing requirements
 Easier to maintain
 More robust
 Promote greater design
 Code reuse
 Higher Level of Abstraction

 OO supports abstraction at the object level.
 Object encapsulate both data (attributes) and functions (methods)
 Development can proceed at the object level, this makes easy designing, coding, testing, and maintaining
 Traditional supports abstraction at the functional level
 Seamless transition among different phases of software development

 OO, uses the same language for analysis, design, programming, and data design.
 It reduces the level of complexity and redundancy and makes for clearer, more robust system development
 Traditional requires different methods and styles for each steps

 Moving from one model to another model it is very difficult
 Encouragement of good programming techniques

 Used to develop Object-oriented projects that depends on object-oriented programming
 Used to develop the traditional projects that uses procedural programming
 Promotion of reusability
 Objects are reusable, each object stand by itself or within a small circle of peers
 Changes impact is very low
UNIFIED APPROACH
 The unified approach (UA) is a methodology for software development
 Booch, Rumbaugh, Jacobson methodologies gives the best practices, processes and guidelines for OO oriented software development.
 Combines with the object management groups in unified modelling language.

 (e.g. open, save, and close)
 Unified Modeling Language developed for software development

 It is a set of notations and conventions used to describe and model an applications
 The heart of UA is Jacobson;s use case

 It is discussing about user and system interaction
UNIFIED APPROACH
 Layered Architecture
 UA uses layered architecture to develop applications.
 Creates object that represent elements to the user through interface or physically stored in database.
 The layered approach consists of user interface, business, access layers.
 This approach reduces the interdependence of the user interface, database access and business control.
 More robust and flexible system.


 Object Basics
 - Jacobson Methodology Unified Approach
OBJECT ORIENTED PHILOSOPHY
 The programming languages provide the programmers the way of describing the process
 These languages are computationally equivalent
 The ease of description, reusability, extensibility, readability, computational efficiency, and ability
to maintain depends on languages used.
 System Software – Machine Understandable language (Integers, floating point numbers, chars,
Addressing Modes,….)
 Financial Investment : Development of Financial Investment Machine directly would reduce
translation.
OBJECT ORIENTED PHILOSOPHY
 Programming languages can bridge the semantic gap between the concepts of the
application and underlying machine
 Object-Oriented Programming Concepts allows closer ideas and terms for the
development of certain applications
 E.g. Financial Investment
 Bond (data type ) : Character
 Buy operation on a bond
TRADITIONAL APPROACH
 The traditional approach to software development tends toward writing a lot of code
to do all the things that have to be done.
 Two types
 Algorithmic centric methodology: you think of an algorithm that can accomplish
the task, then build the data structure
 Data-centric methodology: you think about the data to build a structure based on
the algorithm
 You are the only active entity and the code is just basically a lot of building
materials
 OO system: the algorithm and the data structure are packaged together as an object
 OO approach is more like creating a lot of helpers
 Take on an active role, a spirit, that form a community whose interactions become the
application
 Reusable
 Modified
 Replaced
OBJECT, ATTRIBUTES AND PROCEDURES
 What is Object?
 The term object was first formally utilized in the Simula language to simulate some
aspect of reality.
 It’s a real-world entity
 Then, What is attribute and procedure?

 Attributes are called as properties of object, it describes the state(data) of objects.
 Procedures are called as methods, it define behavior of objects.
OBJECT, ATTRIBUTES AND PROCEDURES
 E.g.
 Car is a object (real-world-entity) : It known things
 Car has a well-defined attributes,
 Color, model, manufacturer and owner
 Car has a well-defined set of things, : it does things
 drive it, lock it, and carry passenger
OBJECTS ARE GROUPED IN CLASSES
 In OOS , class is a set of objects that share a common structure and common behavior
 The role of a class is to define the attributes and methods (the state and behaviour) of
its instances.
 single object is a simply an instance of class
 Class are distinguish one type of object from another
 E.g. Eagle fly
ATTRIBUTES
 It knows things
 Object state and properties

METHOD & BEHAVIOR & MESSAGE
 It Does things
 Object behavior is described in methods or procedures
 A method implements of an object
ENCAPSULATION AND INFORMATION HIDING
 Information Hiding : concealing the internal data and procedures of an objects and
providing interface to each object in such way as to reveal as little as possible about
its inner workings
 e.g. : data and methods
 Encapsulation : wrapping (encapsulating) the complex data in order to present a
simpler view for the user.
 User Can’t see inside of object but they can use the object by calling methods()
 E.g. : Car break apply
CLASS HIEARCHY
 OOS organizes the objects into subclass and superclass hierarchy
 Top of the class hierarchy talks about general aspects
 Bottom of the class hierarchy talks about specific

CLASS HIEARCHY
 Inheritance
 Inheritance is the property of OOS that allows to be built from other
objects.
 It allows explicitly taking advantage of the commonality of objects
when constructing new class
 It talks about relationship between classes where one class is the
parent of another class
 Parent or super class
 Client or derived class
POLYMORPHISM
 OOS, polymorphism means that the same operation may be behave differently on different class
RELATIONSHIP
 OO Relationships
 Two Types
 Generalization (parent-child relationship)
 Association (student enrolls in course)
RELATIONSHIP
 Generalization
 It talks about how objects relate to each other
 It expresses a parent / child relationship among related classes.
 Used for abstracting details in several layers
 Example :
RELATIONSHIP
 ASSOCIATION
 It talks about relationships between objects and classes
 Example:
 Student enrolls in a course
 Courses have students
 Courses have exams
 Also, it talks about

 Role
 Multiplicity
RELATIONSHIP
 ASSOCIATION (Cont.)
 Multiplicity and Roles
RELATIONSHIP
 Association further classified into
 Composition
 Aggregation
RELATIONSHIP
 Composition
 expresses a relationship among instances of related classes (Part-Of)
 It expresses a relationship where an instance of the Whole-class has the
responsibility to create and initialize instances of each Part-class.
 It may also be used to express a relationship where instances of the Part-
classes have privileged access or visibility to certain attributes and/or
behaviors defined by the Whole-class.
 UML : Filled Diamond
RELATIONSHIP
 Aggregation
 expresses a relationship among instances of related classes. (Has-A)
 It is a specific kind of Container-Containee relationship.
 UML : Empty Diamond.
RELATIONSHIP
 Difference between Aggregation and Composition


 Object Basics
 Object Oriented Systems Development Life Cycle (10/08/2021)
 - Jacobson Methodology Unified Approach
OBJECT ORIENTED SYSTEMS DEVELOPMENT LIFE CYCLE
Software Development Process

The essence of the software process is the transformation of
 Users’ needs to
 The application domain into
 A software solution.
 Stages of SDP : Analysis, Design, Implementation, Testing, and Refinement
Software Development Process (Cont.)

Software development is a process, further the process can be divided into small,
interacting phases – Sub-processes
 Process of Change
 Process of Refinement
 Process of Transformation or Addition to existing product

 Each sub-processes contains the clear statement (abstraction) and it works
independently
 A description in terms of how it works
 Specification of the input required for the process
 Specification of the output to be produced

SDP : can be viewed as series of transformations
 Transformation 1 (Analysis)
 Transformation 2 (Design)
 Transformation 3 (Implementation)

Transformation 1 (Analysis)
 Translate the users’ needs into system requirements and responsibility
 It start with user’s needs
 End with system requirements

Transformation 2 (Design)
 It begins with problem statement
 End with detailed design (that can transformed into operational system)
It contains bulk of SD activity
 Definition of how to build (Development & Testing)
 Design Descriptions (Program & testing tools)

Transformation 3 (Implementation)
Refines the detailed design into system deployment that will satisfy the users’ needs
 It considers
 Equipment
 Procedures
 Peoples

SDP is the traditional waterfall approach.
BUILDING HIGH-QUALITY SOFTWARE
Software Quality(Cont.)
Quality Measures
Transformed user needs via the application domain to a software solution
We have to see if it is free of bugs
Meets the user’s needs and expectations
Software Quality (Cont.)

Two basic approaches to system testing,
1. We can test a system according to how it has been built
2. We can test the system with respect to what it should do
Quality Measures
Systems can be evaluated in terms of four quality measures
 Correspondence
 Correctness
 Verification
 Validation
Quality Measures (Cont.)

Correspondence : measures how well the delivered system corresponds
to the needs of the operational environment.
 It cannot be determined until the system is in place (validation is the
task of predicting correspondence)

Correctness : measures the consistency of the product requirements
with respect to the design specification.
Verification is the exercise of determining correctness

Verification : Am I building the product right?
Validation : Am I building the right product?

 Object Basics
 Object Oriented Systems Development Life Cycle (11/08/2021)
OBJECT_ORIENTED SYSTEM DEVELOPMENT APPROACH
A Use-Case Driven Approach

 OO-SDLC consists of three macro processes
 Object-Oriented Analysis
 Object-Oriented Design
 Object-Oriented Implementation
A Use-Case Driven Approach

 Most of the OOSD - Object Oriented
Software Development activities are
developed by using use-case model
 Jacobson (model)
 A Use-Case Driven Approach(Cont.)

 Object Oriented System development activities
 Object-oriented analysis.
 Object-oriented design.
 Prototyping.
 Component-based development.
 Incremental testing
A Use-Case Driven Approach(Cont.)

Object Oriented System development activities (Cont.)

Object Oriented Analysis (Use Case Driven)
 OO analysis concerns with determining the system requirements and
identifying classes and their relationships that make up an application
 To understand the requirements we need to identify the actors or users
 Who are all users?
 How do they use the systems?

Object Oriented Analysis (Cont.)
 Use Case, is a name for a scenario to describe the user-computer system interaction
 Through interaction it captures the users goals and needs
 It is a primary element of system development
 Collaboration, It talks about interrelationships

 Who does, what in the interaction, what role they play
 Object Oriented System development activities (Cont.)

 Object Oriented Design
 The goal of object-oriented design (OOD) is to design:
• The classes identified during the analysis phase,
• The user interface and Data access
 Identifying and adding additional objects and classes

 First, build Object model (objects and their relationships)
 Then iterate and refine e model
 Design and refine classes.
 Design and refine attributes.
 Design and refine methods.
 Design and refine structures.
 Design and refine associations.
 Design User Interface or View layer classes.

 Design data Access Layer classes

 Guidelines
 Reuse, rather than build, a new class
 Design a large number of simple classes
 Design methods
 Analyze what you have proposed, refine it, if possible

Prototyping
 A Prototype enables you to fully understand how easy or difficult it will be to
implement some of the features of the system.
 It can also give users a chance to comment on the usability and usefulness of the
design

Prototyping (cont.)
Types
 A horizontal prototype is a simulation of the interface.
 A vertical prototype is a subset of the system features with complete
functionality
 An analysis prototype is an aid for exploring the problem domain.
 A domain prototype is an aid for the incremental development of the ultimate software solution.

 Component-based development (CBD)
 CBD is an industrialized approach to the software development process.
 Application development moves from custom development to assembly of pre-built,
pre-tested, reusable software components that operate with each other.

 Rapid Application Development (RAD)
 RAD is a set of tools and techniques that can be used to build an application faster
than typically possible with traditional methods.
 RAD does not replace SDLC but complements it, since it focuses more on process
description and can be combined perfectly with the object-oriented approach.

 Incremental Testing
 Software development and all of its activities including testing are an iterative
process.
 If you wait until after development to test an application for bugs and performance,
you could be wasting thousands of dollars and hours of time.

 Object Basics
OBJECT-ORIENTED METHODOLOGIES
 OOMs are developed in-between 1980-1995

 Starts from,
 1986 – Booch methods – Object Oriented Design Concepts
 1987 – Sally Shlaer and Steve Mellor - Recursive design approach
 1989 – Beck and Cunningham – Class-responsibility cards
 1990 – Wrifs-Brock, Wilkerson, and Wiener – Responsibility driven design
OBJECT-ORIENTED METHODOLOGIES
 OOMs are developed in-between 1980-1995

 Ends to,
 1991 – Jim Rumbaugh and his team – Object Modeling Technique –
General Electric
 1991 – Peter Coad and Ed Yourdon – Coad Lightweight and prototype-
oriented methods
 1994 – Ivar Jacobson – Use case and Object Oriented Software Engineering
RUMBAUGH METHODOLOGY
 It was developed around 1991 by Rumbaugh, Blaha,

remerlani, Eddy and Lorensen as a method to develop object-
oriented systems and to support object-oriented programming
 OMT (Object Modeling Technique) describes a method for
the analysis, design, and implementation of a system using an
object-oriented technique.
 OMT is a fast, intuitive approach for identifying and modeling
all the objects
RUMBAUGH METHODOLOGY
 Which are all, Class attributes, method, inheritance, and association also
can be expressed easily
 It allows, to specify detailed state transitions and their descriptions within
system.
 Finally, Process description and customer – producer relationships can
been expressed
PHASES OF OMT
 OMT consists of four phases, which can be performed iteratively:

 Analysis -The results are objects and dynamic and functional models
 System Design - The result is a structure of the basic architecture of the system.
 Object Design - This phase produces a design document, consisting of detailed objects and dynamic
and functional models Implementation-
 This activity produces reusable, extendible, and robust code
OMT - MODELING
OMT separates modeling into three different parts:

Object Model
Dynamic Model
Functional Model
OMT - MODELING
Object Model
 It Describes structure of objects in a system.
 And their, Identity, relationships to other objects, attributes and operations.
 It is represented graphically with an object diagram
 Object diagram contains classes
interconnected by association lines
 Classes represents a set of individual objects
 Association lines established, it represents
relationship among classes (i.e., objects of
one class to objects of another class)
OMT - MODELING
Dynamic Model
 Reflects the state diagrams and event
flow diagrams..
 State transition diagram is a network of
states and events
 One state can receives one or more
evets
 Next state depends on the current state
OMT - MODELING
Functional Model
 Shows the flows of data between different process
 Primary symbols
 Process – function being performed
 Data flow – direction of data element movement
 Data store – location of where data stored
 External entity – source and destination of data elements
 Summary of Rumbaugh (OMT)
 It provides the strongest tool sets for the analysis and design of Object Oriented system
 Object Model (structure)
 Dynamic Model (behavior)
 Functional Model (function)
BOOCH METHODOLOGY
 The Booch method is a method for object-oriented software
development.
 It is composed of an object modeling language an iterative object-
oriented development process, and a set of recommended practices
 The method was authored by Grady Booch when he was working for
Rational Software (acquired by IBM), published in 1992 and revised
in 1994.
 It was widely used in software engineering for object-oriented analysis
and design and benefited from sufficient documentation and support
tools.
BOOCH METHODOLOGY
 The notation aspect of the Booch method was

superseded by the Unified Modeling
Language (UML), which features
 Graphical elements from the Booch method
along with
 Elements from the object-modeling technique
(OMT) and
 Object-oriented software engineering
(OOSE).
BOOCH METHODOLOGY
 The Booch method consists of several diagrams,
c
BOOCH METHODOLOGY
 Booch Methodology prescribes two development processes

 Macro development process
 Micro development process
BOOCH METHODOLOGY
 Macro Development Process

 Aim of macro process is technical management of the system
 It serves as a controlling framework of micro process
 it takes week or even months
 It preserve the traditional phases of analysis and design
BOOCH METHODOLOGY
 The macro process consists of following steps:

 Conceptualization : establish core requirements (goals & development prototype)
 Analysis and develop of the model : role & responsibility (class diagram), behavior of
system (object diagram)
 Design or create an architecture : explains the relationship between classes (class
diagram)
 Evolution or implementation : successively refine the system through many iterations.
 Maintenance : for evolution after the delivery - make localized changes (add new
requirements and eliminate bugs )
BOOCH METHODOLOGY
Micro Development process

 Each micro process has its own micro development processes
 It is a description of the day-to-day activities by a single or small group
of team
 Which could blurry to an outside viewer, since analysis and design
phases are not cleared
BOOCH METHODOLOGY
 The micro process consists of following steps:

 Identify classes and objects
 Identify class and objects semantics
 Identify class and relationships
 Identify class and object interfaces and implementations
 Example :
 https://www.conceptdraw.com/examples/the-booch-methodology-example
JACOBSON METHODOLOGY
 The Jacobson et al. methodologies cover the entire life cycle and
stress traceability between the different phases both forward and
backward.
 (example Object – Oriented Business Engineering (OOBE), Object
Oriented Software Engineering (OOSE) and Objectory)
 This traceability enables reuse of analysis and design work,
possibly much bigger factors in the reduction development time
then reuse of code.
 At the heart of their methodologies is the use-case concept,
which devolved with Objectory (Object Factory for Software
Development).
 Use case: It is a scenarios for understanding system requirements.

 A use case is an interaction between users and the system.
 The use case model captures the goal of the user and the responsibility of the system
to its users.
 Use cases are described as
 Non-formal text with no clear flow of events
 Text, easy to read but clear flow of events to follows
 Formal style using pseudo code.
JACOBSON MEATHODOLOGY
 The use case description must contain

 How and when the use case begins and ends.
 The interaction between the use case and its actors including when the interaction occurs and what
is exchanged.
 How and When the use case will need data stored in the system or will store data in the system.
 Exceptions to the flow of events.
 How and when concepts of the problem domain are handled.
 Every single use case should describe one main flow of

events.
 An exceptional or additional flow of events could be added
 The use-case model employs extend and uses relationships.
 The user’s relationship reuses common behavior in different
use cases.
Object oriented software engineering

Objectory, is a method of OO development with
a specific aim to fit the development or large, real-
time systems
The development process called use-case driven
development, stresses that use cases are involved
in several phases of the development including
analysis, design, validation, and testing.
 The use-case scenario begins with a user of the system initiating a
sequence of interrelated events.
 The system development method on OOSE, Objectory, is a disciplined
process for the industrialized development of software, based on the use-
case driven design that centers on understanding the ways in which the
system actually is used.
 By organizing the analysis and design models around sequences of user
interactions and actual usage scenarios, the method produces system that
are both most usable and more robust, adapting more easy to change in
usage.

Software Engineering Unit 4 .......... 11-August-2021

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering Unit 4 .......... 11-August-2021

Uploaded by

Copyright:

Available Formats

CSE3005-Software Engineering

 Unit -4 : OBJECT ORIENTED LIFE CYCLE

 Overview of Object Oriented Systems Development

 OOSD is way to develop software by building self-contained modules or objects.

 It helps to easily replace, modify, and reuse the development process

 Each object has attributes (data) and methods (functions)

 E.g., Windows application (open, close, display)

 System Development activities consist of

 Benefits of Object Orientation

 Higher Level of Abstraction

 Traditional supports abstraction at the functional level

 Seamless transition among different phases of software development

 Traditional requires different methods and styles for each steps

 Encouragement of good programming techniques

 The unified approach (UA) is a methodology for software development

 Combines with the object management groups in unified modelling language.

 Unified Modeling Language developed for software development

 The heart of UA is Jacobson;s use case

 The layered approach consists of user interface, business, access layers.

 More robust and flexible system.

 Overview of Object Oriented Systems Development

 Then, What is attribute and procedure?

 Object state and properties

 OOS organizes the objects into subclass and superclass hierarchy

 Top of the class hierarchy talks about general aspects

 Bottom of the class hierarchy talks about specific

 Also, it talks about

 Difference between Aggregation and Composition

 Overview of Object Oriented Systems Development

Software Development Process

Software Development Process (Cont.)

Software Development Process (Cont.)

Software Development Process (Cont.)

Software Development Process (Cont.)

Software Development Process (Cont.)

Software Development Process (Cont.)

Software Development Process (Cont.)

Software Quality (Cont.)

Quality Measures (Cont.)

Quality Measures (Cont.)

Quality Measures (Cont.)

 Overview of Object Oriented Systems Development

A Use-Case Driven Approach

A Use-Case Driven Approach

 A Use-Case Driven Approach(Cont.)

A Use-Case Driven Approach(Cont.)

Object Oriented System development activities (Cont.)

Object Oriented System development activities (Cont.)

 Collaboration, It talks about interrelationships

 Object Oriented System development activities (Cont.)

 Object Oriented System development activities (Cont.)

 Design User Interface or View layer classes.

 Object Oriented System development activities (Cont.)

Object Oriented System development activities (Cont.)

Object Oriented System development activities (Cont.)

 Object Oriented System development activities (Cont.)

 Object Oriented System development activities (Cont.)

 Object Oriented System development activities (Cont.)

 Overview of Object Oriented Systems Development

 OOMs are developed in-between 1980-1995

 OOMs are developed in-between 1980-1995

 It was developed around 1991 by Rumbaugh, Blaha,

 OMT consists of four phases, which can be performed iteratively: