Chapter 1

Introduction

By Sisay N.
 Contents
 What Orthogonal view of Software?
 Software development process models
 Software Process, Software life cycle and process models,
process assessment models
 Software process Metrics
 Object oriented system development methodology
 Why an object oriented, Overview of the unified approach
 An Object orient Methodology
 Basic concepts of an object and Attributes of an object
 Its state and properties

2
 Two Orthogonal view of software

• Refers to two independent perspectives of a system.

• Changes in one view should not affect the other.
• Commonly includes:
• Function-based view – Focuses on operations and
processes.
• Object-oriented view – Emphasizes data and
interactions.
• Ensures separation of concerns for better modularity and
maintainability.

3
 Continued…
 Meaning of "orthogonal":
 In geometry, orthogonal lines are perpendicular, signifying
independence.
 In software, it means that components or features can
be modified without impacting other parts of the system.
 Example of orthogonal views:
 Traditional view (functional): Focuses on the system's
functions and data flow, breaking down the system into
processes and algorithms
 Object-oriented view: Focuses on objects with
encapsulated data and methods, where each object
represents a real-world entity and its interactions with
4 other objects.
 Continued…
 Orthogonal View in Software Development
 In computing, orthogonality means independent
functionality without unintended effects.
 Allow changes in one operation without affecting others.
 Example Executing Operation A has no impact on
Operation B.
 Simplifies debugging by preventing ripple effects in
dependent operations.
 Encourages minimalistic design with a limited set of
combinable components.
 Reduces errors and improves readability and learning for
developers.
5
 Benefits of using orthogonal views
 Improved maintainability:
 By keeping components independent, changes in one part of the
system are less likely to require modifications in other parts.
 Enhanced reusability:
 Well-defined, independent components can be reused in
different parts of the application or even in other projects.
 Simplified debugging:
 Isolating issues to specific components becomes easier when
they have clear boundaries.

6
 Software Process Models
Software process
- Coherent sets of activities for specifying, designing,
implementing and testing software systems
-A structured set of activities required to develop a
software system specification, design, validation and
evolution.
A software process model-
-An abstract representation of a process and presents a
description of a process from some particular perspective.
 Software Development Life Cycle
(SDLC)

8
 Software Development Life Cycle
(SDLC)
 Definition of SDLC
• A Software Life Cycle Model represents the structured
process of software development.
• It ensures systematic execution from inception to
retirement.
• Defines entry and exit criteria for each phase, ensuring
discipline and project monitoring.
 Need for SDLC
• Ensures a systematic and disciplined approach to software
development.
• Prevents chaos and project failure by establishing clear
9
roles and responsibilities, and helps project managers
monitor progress effectively.
 Phases of SDLC
1. Planning and Requirement Analysis
• Senior team members gather input from stakeholders.
• Identifies risks and quality assurance requirements.
• Results in the Software Requirement Specification
(SRS) document.
2. Designing the Software
• Converts requirements into a structured system design.
• Ensures feasibility and alignment with business objectives.
3. Development (Coding Phase)
• Actual programming begins based on the design.
10 • Developers follow coding guidelines and use necessary tools.
 Phases of SDLC
5. Testing
• Ensures the software meets requirements and is bug-free.
• Includes unit testing, integration testing, system testing, and
acceptance testing.
6. Deployment
• Software is deployed to users after certification.
• May include enhancements based on user feedback.
7. Maintenance
• Addresses real-world issues and provides updates.
• Ensures long-term functionality and efficiency.
➢This structured approach enhances software quality, reduces risks,
11 and ensures project success.
 SDLC Models
 More other process models
 Build-and-fix model
 Evolutionary process models
 Rapid prototyping model
 Spiral model
 Object-oriented life-cycle
models
 Unified Process

12
 SDLC Models
 Software Development Life Cycle (SDLC) is a structured
framework used in project management that outlines the stages
involved in developing an information system, from initial
feasibility analysis to ongoing maintenance of the final
product.
 Various SDLC models exist, each defining a unique approach to
software development.
 These models, also known as Software Development Process
Models, follow distinct phases to ensure a systematic and
efficient development process.

13
 Build-and-Fix Model
 Problems
 No specifications
 No design
 Totally unsatisfactory
 High cost
 Difficult maintenance

14
 Waterfall Model

15
 Waterfall Model

 Five distinct phases:

1. Requirements Analysis and Specification – This phase
focuses on gathering and documenting customer
requirements in a Software Requirement Specification
(SRS) document. It defines what the system should do,
not how it should be implemented.
2. Design Phase – The collected requirements are translated
into a Software Design Document (SDD), which outlines
the system architecture, including high-level and detailed
designs to guide implementation.
16
 Waterfall Model
 Five distinct phases:
3. Implementation and Unit Testing – The software is
developed based on the SDD. Individual components are
coded and unit-tested to ensure they function correctly.
4. Integration and System Testing – All modules are combined
and tested for their interactions to ensure the system works
as expected. Comprehensive testing helps improve product
quality and reduce maintenance costs.
5. Operation and Maintenance – Once deployed, the software
enters the maintenance phase, where bug fixes, updates,
17 and improvements are handled based on user feedback.
 When to Use the Waterfall Model?
• The Waterfall Model is best suited when;
• Requirements are well-defined and unlikely to change.
• Projects are short and straightforward.
• The environment is stable, with minimal external
influences.
• Technology and tools remain consistent throughout
development.
• Sufficiently prepared resources are available.

18
 Advantages of the Waterfall Model
 Simple and easy to implement, requiring minimal
resources.
 Clearly defined requirements that remain
unchanged throughout development.
 Well-structured phases with fixed start and end
points, making progress tracking easy.
 Predictable cost and timeline due to predefined
schedules.
 Strict documentation provides clarity and control
over the project.
19
 Disadvantages of the Waterfall Model
 High risk and inflexibility, making it unsuitable for
large or complex projects.
 Changes in requirements are difficult to
accommodate once development starts.
 Going back to previous phases is challenging
once the project progresses.
 Late-stage testing makes it harder to identify and
mitigate risks early.

20
 Rapid Prototyping Model
 Prototyping is defined as the process of developing
a working replication of a product or system that
has to be engineered.
 It offers a small scale replica of the end product and
is used for obtaining customer feedback as
described below:

21
 Rapid Prototyping Model…

22
 Rapid Prototyping Model (contd.)
 Rapid prototype characteristics:
 Used in the requirements phase
 Evaluated by the customer/user
 Then, it is discarded -do not turn into product
 Rapid prototyping model is not proven and has its own
problems
 Possible solution
 Rapid prototyping for defining requirements
 Waterfall model for rest of life cycle

23
 Incremental Model
 Incremental Model is a process of software development where
requirements are broken down into multiple standalone modules
of software development cycle.
 Each iteration passes through the requirements, design, coding
and testing phases.
 Typical product takes from 5 to 25 builds (iterations).

24
 Incremental Model (contd.)

25
 Incremental Model…
 Waterfall and rapid prototyping models
 Deliver complete product at the end
 Incremental model
 Deliver portion of the product at each stage
 Advantages
 The software will be generated quickly during the software
life cycle
 It is flexible and less expensive to change requirements and
scope
 Throughout the development stages changes can be done
 This model is less costly compared to others
 A customer can respond to each building
26
 Errors are easy to be identified
 Incremental Model…
 Disadvantages:
 It requires a good planning designing
 Problems might arise due to system architecture as not all
requirements collected up front for the entire software
lifecycle
 Each iteration phase is rigid and does not overlap each other
 Correcting a problem in one unit requires correction in all
the units and consumes a lot of time

27
 When to use Incremental models?
 Requirements of the system are clearly understood
 When demand for an early release of a product arises
 When software engineering team are not very well
skilled or trained
 When high-risk features and goals are involved
 Such methodology is more in use for web application
and product based companies

28
 Spiral Model
 The spiral model is a risk-driven software
development process model.
 Based on the unique risk patterns of a given project, the spiral
model guides a team to adopt elements of one or more
process models, such as incremental, waterfall, or evolutionary
prototyping.
 Risk Analysis: Identification of potential risk is done while risk
mitigation strategy is planned and finalized
 Precede each phase by
 Alternatives
 Risk analysis
 Follow each phase by
 Evaluation
29  Planning of next phase
 Simplified Spiral Model

30
 When to use Spiral Methodology?
 When project is large
 When releases are required to be frequent
 When creation of a prototype is applicable
 When risk and costs evaluation is important
 For medium to high-risk projects
 When requirements are unclear and complex
 When changes may require at any time
 When long term project commitment is not feasible due to
changes in economic priorities

32
 Advantages of Spiral Model
 Additional functionality or changes can be done at a later
stage
 Cost estimation becomes easy as the prototype building
is done in small fragments
 Continuous or repeated development helps in risk
management
 Development is fast and features are added in a
systematic way
 There is always a space for customer feedback

33
 Disadvantages of Spiral Model
 Risk of not meeting the schedule or budget
 It works best for large projects only also demands risk
assessment expertise
 For its smooth operation spiral model protocol needs to
be followed strictly
 Documentation is more as it has intermediate phases
 It is not advisable for smaller project, it might cost them
a lot

34
 Agile Process Models

35
 Agile Process Models
 Agile software engineering combines a philosophy and a set
of development guidelines
 Philosophy
 Encourages customer satisfaction and early incremental
delivery of the software
 Small highly motivated project teams
 Informal methods
 Minimal software engineering work products
 Overall development simplicity
 Development guidelines
 Stress delivery over analysis and design
 Active and continuous communication between
36
developers and customers
 Agile Process Models
 The term Agile means swift and versatile. The Agile process
model is a software development approach that emphasizes
iterative development, breaking tasks into smaller iterations
without long-term planning.
 The scope and requirements of the project are established at the
start, and the number of iterations, their duration, and scope are
predefined.
 Each iteration typically lasts between one to four weeks, ensuring
faster delivery and risk minimization.
 Agile follows a full software development cycle in each
iteration, including planning, requirements analysis, design,
coding, and testing, before presenting a working product to the
37 client.
 Phases of the Agile Model
1. Requirements Gathering – Identify business opportunities,
evaluate technical and economic feasibility, and define project
requirements.
2. Design the Requirements – Collaborate with stakeholders to
refine requirements using user flow diagrams or UML diagrams.
3. Construction/Iteration – Developers and designers build an
initial version with minimal functionality, gradually improving the
product.
4. Testing/Quality Assurance – The QA team verifies product
performance and resolves bugs.
5. Deployment – The software is released for user implementation.
38
6. Feedback – Gather user feedback and iterate on improvements.
 Agile Testing Methods

39
 Agile Process Models…

40
 When to use Agile model…
 When new changes need to be implemented. The freedom
agile gives to change is very important. New changes can be
implemented at very little cost because of the frequency of new
increments that are produced.
 To implement a new feature the developers need to lose only the
work of a few days, or even only hours, to roll back and
implement it.
 Both system developers and stakeholders alike, find they also get
more freedom of time and options than if the software was
developed in a more rigid sequential way.
 Having options gives them the ability to leave important decisions
until more or better data or even entire hosting programs are
available; meaning the project can continue to move forward
without fear of reaching a sudden standstill.

41
 When to Use the Agile Model (in short)?
• Frequent requirement changes are expected.
• A highly experienced team is available.
• Clients can engage regularly with developers.
• Project size is small to medium.

42
 Advantages/Disadvantages of Agile
Model
 Advantages of Agile Model  Disadvantages of Agile
 Frequent Delivery of Model
functional software.  Lack of formal
 Direct Communication with documentation may cause
clients. confusion.
 Efficient design that meets  Key decisions can be
business needs. misinterpreted at different
 Flexibility for changes at stages.
any stage.  Project maintenance
 Reduced development challenges if original
time. developers leave.

43
 Agile vs. Waterfall Method
Agile Model Waterfall Model
Agile method proposes incremental and Development of the software flows
iterative approach to software design sequentially from start point to end point.

The agile process is broken into individual The design process is not broken into an
models that designers work on individual models

The customer has early and frequent The customer can only see the product at the
opportunities to look at the product and make end of the project
decision and changes to the project

Agile model is considered unstructured Waterfall model are more secure because they
compared to the waterfall model are so plan oriented

44
 Agile vs. Waterfall Method (contd.)
Agile Model Waterfall Model
Small projects can be implemented very All sorts of project can be estimated and
quickly. For large projects, it is difficult to completed.
estimate the development time.

Error can be fixed in the middle of the Only at the end, the whole product is tested. If
project. the requirement error is found or any changes
have to be made, the project has to start from
the beginning
Development process is iterative, and the The development process is phased, and the
project is executed in short (2-4) weeks phase is much bigger than iteration. Every
iterations. Planning is very less. phase ends with the detailed description of the
next phase.
Documentation attends less priority than Documentation is a top priority and can even
software development use for training staff and upgrade the software
with another team
45
 Agile vs. Waterfall Method (contd.)
Agile Model Waterfall Model
In agile testing when an iteration end, All features developed are delivered at once
shippable features of the product is delivered after the long implementation phase.
to the customer. New features are usable right
after shipment. It is useful when you have good
contact with customers.

Testers and developers work together Testers work separately from developers

At the end of every sprint, user acceptance is User acceptance is performed at the end of
performed the project.
It requires close communication with Developer does not involve in requirement and
developers and together analyze requirements planning process. Usually, time delays between
and planning tests and coding
46
 Advantages of Agile Model
 Customer satisfaction by rapid, continuous delivery of useful
software.
 People and interactions are emphasized rather than process and
tools. Customers, developers and testers constantly interact with
each other.
 Working software is delivered frequently (weeks rather than
months).
 Face-to-face conversation is the best form of communication.
 Close, daily cooperation between business people and developers.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed.
47
 Disadvantages of Agile model
 In case of some software deliverables, especially the large ones, it
is difficult to assess the effort required at the beginning of the
software development life cycle.
 There is lack of emphasis on necessary designing and
documentation.
 The project can easily get taken off track if the customer
representative is not clear what final outcome that they want.
 Only senior programmers are capable of taking the kind of
decisions required during the development process. Hence it has
no place for newbie programmers, unless combined with
experienced resources.
48
 How to Choose between SDLC
Methods?

49
 How to Choose between SDLC
Methods?
 To know which is the best model out of all the different types
of SDLC models, it is important to understand that
each of these approaches are suitable for different
projects, environments, and requirements.
 For example, if your project is simple and straightforward
with set requirements that do not need to be changed, then
Waterfall is best suited for it.
 However, if your project is large-scale and consists of
multiple components and segments, then choosing Iterative
or Spiral methodology would suit your project better.

50
 How to Choose between SDLC
Methods?
 To answer the question simply, there is no ONE model
is best from all the SDLC models discussed.
 A preference of one method over the others cannot be
determined.
 However, to select the right SDLC methodologies, you
should know all the types of SDLC models, assess the
requirements of all the stakeholders and then decide on a
method that best fits your needs.

51
 Criteria for deciding on a model include
 Criteria for deciding on a model include
 Product Complexity
 Product Size
 Magnitude of Changes
 Frequency of Changes
 Skills of the Dev Team
 Time constraints
 Access to Users

52
 Software process metrics
 Software process metrics refer to quantitative measures
that are used to assess, analyze, and improve the software
development process.
 Designed to help development teams understand and control
various aspects of the software engineering process, including
efficiency, quality, cost, and performance.
 The primary goal is to make informed decisions, identify
potential areas for improvement, and ensure that the
software development process is effective, predictable, and
capable of meeting the desired outcomes.

53
 Key Purposes of Software Process
Metrics
1. Monitoring and Control: By tracking different metrics, teams can
assess the health of the development process and ensure that projects stay
on track in terms of budget, timeline, and quality.
2. Continuous Improvement: Metrics provide insights that can be used to
refine and improve the software development processes over time. This can
lead to better software quality, increased productivity, and more efficient
use of resources.
3. Decision Making: Metrics provide objective data that assist project
managers, developers, and other stakeholders in making informed
decisions regarding process adjustments, resource allocation, or risk
management.
4. Predictability: Metrics help teams understand patterns in their
development process, enabling them to predict project timelines, costs,
54 and potential issues based on historical data.
 Types of Software Process Metrics
1. Process Metrics: These focus on the overall performance of the development
process itself. They include measurements like defect density, cycle time, and
process efficiency.
2. Product Metrics: These assess the quality and characteristics of the software
product being developed. Examples include lines of code (LOC), defect removal
efficiency, and code churn.
3. Project Metrics: These measure the overall progress and success of a software
project. Metrics such as effort estimation, schedule variance, and cost
performance index (CPI) fall under this category.
4. Quality Metrics: These metrics measure the quality of the software, including
test coverage, defect arrival rate, and mean time to failure (MTTF).
5. Team Performance Metrics: These focus on the effectiveness and
productivity of the development team, such as velocity in Agile teams, work in
progress (WIP), and team collaboration.
55
 Examples of Software Process
Metrics
 Defect Density: Number of defects per unit of software
size (e.g., defects per 1000 lines of code).
 Cycle Time: The time it takes to complete a specific
software development phase (e.g., design, coding, testing).
 Velocity: The amount of work completed by a team in a
given period (e.g., number of user stories completed in an
Agile sprint).
 Test Coverage: Percentage of the code that is covered by
automated tests.

56
 Software process metrics
1. Process Metrics
 These metrics focus on monitoring and assessing the efficiency, effectiveness, and quality of the
software development process itself.
 Defect Density: Measures the number of defects (bugs) in the software relative to its size (usually
in lines of code or function points).
 Formula:

 Process Efficiency: Measures the effectiveness of the development process in delivering the
desired outcome. It can be assessed using various process improvement models like CMMI
(Capability Maturity Model Integration).
 Formula :

A lower value indicates good efficiency.

 Cycle Time: The amount of time it takes to complete a particular phase of the software
development process, such as requirements gathering, design, or testing.

57
 Software process metrics
 Process Compliance: Measures how strictly the
development process adheres to defined standards and
practices, including coding standards, testing procedures, and
quality assurance protocols.
2. Product Metrics
 These metrics measure the quality and characteristics of the
software product produced by the development process.
 Lines of Code (LOC): Measures the size of the software by
counting the total lines of code. While it’s a simple metric, it
can be used to estimate complexity and productivity.

58
 Software process metrics
2. Product Metrics…
 Function Points: A measure of the functionality delivered by the
software, focusing on the inputs, outputs, user interactions, data, and
external interfaces. This is more reflective of the software's
complexity and functionality than LOC. Read more
 Defect Removal Efficiency (DRE): Measures the efficiency of
the software testing process in detecting and removing defects.

 Higher DRE indicates that the testing process is effective in removing

defects.

59
 Software process metrics
2. Product Metrics…
 Code Churn: Measures the frequency with which code
changes. High code churn may indicate instability or frequent
modifications, which could affect the software’s reliability
and maintenance.

60
 Software process metrics
3. Project Metrics
These metrics measure the overall progress, cost, and
effectiveness of the software project.
 Effort Estimation: Tracks the amount of time and effort
required to complete a project or a phase. It helps in
forecasting future resource requirements. Formula:

 Schedule Variance (SV): Measures the difference between

the planned and actual progress of a project in terms of time.
Formula:

61
 Software process metrics
3. Project Metrics
 Cost Performance Index (CPI): Measures cost efficiency
by comparing the work performed to the actual costs
incurred.

 A CPI greater than 1 indicates that the project is under

budget.
 Schedule Performance Index (SPI): Measures schedule
efficiency by comparing the work performed to the planned
schedule.

62
 Software process metrics
4. Quality Metrics
Quality metrics help assess the reliability, maintainability, and
performance of the software product.
 Defect Arrival Rate: Measures how often defects are
identified during testing. It helps to determine whether the
software is improving or getting worse over time. Formula:

 Test Coverage: Measures the percentage of the software

code that is tested by unit tests. Higher test coverage means
more of the code is being tested, which typically results in
higher software quality.

63
 Software process metrics
4. Quality Metrics…
 Mean Time to Failure (MTTF): Measures the average
time between failures in the system. It is used to assess the
reliability of the software.

 Mean Time to Repair (MTTR): Measures the average

time taken to fix defects after they are identified. It helps
evaluate the maintainability of the software.

64
 Software process metrics
5. Team Performance Metrics
These metrics focus on how well the development team is
performing and how efficiently they are collaborating.
 Velocity: In Agile projects, this metric measures the amount of
work a team can complete in a given iteration or sprint. It's often
measured in story points or user stories.
 Burndown Chart: A visual representation showing the amount
of work left versus time. It is used in Agile to track progress
during sprints.
 Work In Progress (WIP): Measures the amount of work the
team is actively working on at any given time. It helps identify if
the team is overloaded or if there are bottlenecks in the process.

65
 Process Assessment Models
(PAMs)
• are frameworks used to evaluate and improve processes in various
domains, such as software development, business operations, or
manufacturing.
• These models provide structured methodologies for assessing the
maturity, efficiency, and effectiveness of processes within an
organization.
• Key Aspects of Process Assessment Models:
1. Standardized Framework – PAMs are often based on international
standards like ISO/IEC 330xx (formerly ISO/IEC 15504, also
known as SPICE) or CMMI (Capability Maturity Model
Integration).
2. Maturity Levels – Many PAMs use maturity levels to indicate how well
a process is defined, implemented, and optimized.
3. Process Capability Evaluation – They assess whether a process meets
certain performance criteria and how it can be improved.

66
 Process Assessment Models
(PAMs) …
4. Gap Analysis – Identifies strengths and weaknesses in current
processes and provides recommendations for improvement.
5. Continuous Improvement – Helps organizations refine their
processes over time for better efficiency and quality.
 Examples of Process Assessment Models:
 ISO/IEC 330xx (SPICE) – Used for software process improvement
and capability determination.
 CMMI (Capability Maturity Model Integration) – Measures
process maturity in software and systems development.
 ITIL (Information Technology Infrastructure Library) –
Assesses IT service management processes.
 Lean Six Sigma – Focuses on process efficiency and reducing waste.
 Business Process Maturity Model (BPMM) – Evaluates
business processes.

67
 Object oriented system development
methodology
 Object-Oriented System Development Methodology
(OOSDM) is an approach to system development that integrates
object-oriented principles throughout the software development
lifecycle.
 It emphasizes modular, reusable, and maintainable software design by
treating both data and behavior as encapsulated objects.
 Advantages of OOSDM
➢ Reusability – Objects and classes can be reused in multiple projects
➢ Scalability – Supports complex system expansion with minimal code changes.
➢ Maintainability – Easier debugging and modification due to modularity.
➢ Flexibility – Supports iterative and incremental development.
➢ Better Real-World Mapping – Aligns well with real-world entities, making system modeling
intuitive.
68
 Object oriented system development
methodology…
 Key Principles of OOSDM
1. Encapsulation – Bundling data and methods together into
objects.
2. Abstraction – Hiding implementation details and exposing
only necessary features.
3. Inheritance – Enabling new classes to reuse existing class
properties and methods.
4. Polymorphism – Allowing a single interface to represent
different underlying implementations.
5. Modularity – Structuring a system as a collection of
independent and reusable objects.

69
 Object oriented system development
methodology…
 Phases of Object-Oriented System Development
1. Object-Oriented Analysis (OOA)
 Identifies system requirements.
 Defines key objects and their relationships.
 Uses UML (Unified Modeling Language) diagrams like use case
diagrams and class diagrams.
2. Object-Oriented Design (OOD)
 Transforms analysis models into a system design.
 Defines class structures, object behaviors, and interactions.
 Uses design patterns to improve reusability and efficiency.
3. Object-Oriented Programming (OOP)
 Implements the design using object-oriented programming languages
(e.g., Java, Python, C++).
70  Encapsulates functionalities within classes and objects.
 Object oriented system development
methodology…
 Phases of Object-Oriented System Development…
4. Object-Oriented Testing (OOT)
 Validates individual objects, class interactions, and system
functionalities.
 Uses techniques like unit testing (for classes),
integration testing (for object interactions), and
system testing.
5. Object-Oriented Maintenance
 Enhances and updates the system while preserving object integrity.
 Uses version control and refactoring techniques for long-term
sustainability.

71
 Object oriented system development
methodology…
 Popular Object-Oriented Methodologies
1. Booch Method – Emphasizes iterative development with object
modeling.
2. Rumbaugh’s Object Modeling Technique (OMT) – Focuses on
analysis, design, and implementation using object models.
3. Jacobson’s Object-Oriented Software Engineering (OOSE) –
Introduced the Use Case Model for requirement analysis.
4. Unified Process (UP) – A widely used methodology that integrates
OOA, OOD, and OOP.
5. Agile and Object-Oriented Development – Modern Agile
methodologies often incorporate object-oriented design principles.

72
 Object oriented system development
methodology…
 Why Use an Object-Oriented Approach?
 The Object-Oriented Approach (OOA, OOD, OOP) is widely used in software
development because it models real-world entities more naturally, leading to reusable,
scalable, and maintainable software systems. Reason for preferred:
1. Real-World Modeling – Objects represent real-world entities, making systems
intuitive and easier to design.
2. Encapsulation – Data and behavior are bundled together, improving security and
modularity.
3. Reusability – Code can be reused across different parts of a system or in new
projects, reducing development time.
4. Scalability and Flexibility – The system can grow by adding new objects and
relationships without affecting existing components significantly.
5. Maintainability – Well-structured object-oriented code is easier to debug, update,
and extend.
6. Improved Software Quality – Concepts like inheritance and polymorphism
73
allow efficient reuse and reduce redundancy, leading to a more structured and efficient
codebase.
 Object oriented system development
methodology…
 Overview of the Unified Approach (UA)
 The Unified Approach (UA) is a software development
methodology that integrates different object-oriented techniques
into a structured framework.
 It combines concepts from various object-oriented methodologies,
such as Booch Method, Rumbaugh’s Object Modeling
Technique (OMT), and Jacobson’s Object-Oriented
Software Engineering (OOSE), leading to what is now known
as the Unified Process (UP).

74
 Object oriented system development
methodology…
 Key Characteristics of the Unified Approach
 Iterative and Incremental Development – Software is
developed in multiple cycles (iterations) instead of a single phase.
 Unified Modeling Language (UML) – Uses standardized
UML diagrams for analysis, design, and implementation.
 Use Case Driven – Focuses on defining system behavior through
use cases.
 Architecture-Centric – Emphasizes a well-defined software
architecture using object-oriented design principles.
 Risk-Driven – Addresses high-risk aspects early in the
development cycle.
75
 Object oriented system development
methodology…
 Phases of the Unified Approach (Unified Process)
1. Inception Phase – Define system goals, feasibility, and scope.
2. Elaboration Phase – Identify system architecture, use cases,
and potential risks.
3. Construction Phase – Implement and develop the system in
iterations.
4. Transition Phase – Deploy the system and provide user
training.

76
 Object oriented system development
methodology…
 Advantages of the Unified Approach
 Combines Best Practices – Integrates multiple object-oriented
methodologies.
 Flexible and Scalable – Adapts well to complex and evolving
software projects.
 Well-Defined Process – Uses UML and a structured development
cycle.
 Minimizes Risks – Addresses project risks early through an iterative
approach.
 Ensures High-Quality Software – Focuses on architecture,
testing, and gradual refinement.

77
 Object oriented system development
methodology…
 Basic Concepts of an Object
 In Object-Oriented Programming (OOP), an object is a self-
contained unit that represents a real-world entity.
 It consists of attributes (data) and methods (behaviors) that
define its characteristics and functionalities.
 Key Characteristics of an Object:
1. Identity – Each object has a unique identity, distinguishing it from other
objects.
2. State – The values stored in an object's attributes at a given time.
3. Behavior – The methods or functions that define what an object can do.
 For example, consider an object: "Car“
 Attributes (Properties): color, brand, model, speed
 Methods (Behaviors): accelerate(), brake(), turn()
78
 Object oriented system development
methodology…
 Attributes of an Object
 An attribute (also known as a property or field) represents data
associated with an object. Attributes define an object's state
and properties.
 Example: "Car" Object and its Attributes

 State of an Object ,, next slides

79
 Object oriented system development
methodology…
 State of an Object
 The state of an object refers to the current values of its attributes at a
specific point in time. It changes when the object undergoes
modifications through methods.
 Properties of an Object
 The properties of an object refer to its characteristics that help
define it. These properties are stored as attributes.

80
 Object oriented system development
methodology…

81