Object Oriented Software Engineering

(CoSc3092)
Chapter One

Introduction to Software Engineering

1. What is s/w Engineering?

2. Software Engineering Concepts

3. Software Engineering Development Activities

4. Managing Software Development

5. SDLC vs OO approach

Why Software Engineering ?

1950s and 1960s, Systems Development was unstructured & unorganized

 Management failure
 Late and over budget delivery
 On-time delivery of incorrect system
 Not anticipating situations
 A person living more than 100 years was invited to attend kindergarten.
 Leap years impacting expiration dates
 Nature of system i.e. complexity
 Generally, quality of software was unacceptably low and deadlines and budgets weren’t being met.
 Leap-year bug
 A supermarket was fined $1000 for having meat around 1 day too long, on February 29, 1988.
 Interface misuse
 On April 10, 1990, in London, an underground train left the station without its driver.
 Security
 On November 2, 1988, a self-propagating program, subsequently called the Internet Worm, An
estimated 10% of all Internet nodes were affected. The infection took several days to eradicate.
 Late and over budget
 In 1995, bugs in the automated luggage system of the new Denver International Airport caused
suitcases to be chewed up. The airport opened 16 months late, $3.2 billion over-budget, with a
mostly manual luggage system.
 On-time delivery
 After 18 months of development, a $200 million system was delivered to a health insurance
company in Wisconsin in 1984. However, the system did not work correctly: $60 million in
overpayments were issued. The system took 3 years to fix.
 Unnecessary complexity
  The C-17 cargo plane by McDonnell Douglas ran $500 million over budget because of problems with
its avionics software. The C-17 included 19 onboard computers, 80 microprocessors, and 6 different
programming languages.

I. What is Software Engineering?

 Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines.

 Software engineering is a modeling activity.

 Software engineering is a problem-solving activity.

 Software engineering is a knowledge acquisition activity.

 Software engineering is a rationale-driven activity.

1. Modeling Activity:

• A model is an abstract representation of a system that enables us to answer questions about the
system.

• Software engineers deal with complexity through modeling, by focusing at any one time on only the
relevant details and ignoring everything else.

• Models are useful when dealing with systems that are too large, too small, too complicated, or too
expensive to experience firsthand.

2.Problem solving

• Engineering is a problem-solving activity. It is not algorithmic.

• In its simplest form, the engineering method includes five steps:

a. formulate the problem

b. analyze the problem
c. search for solutions
d. decide on the appropriate solution
e. specify the solution

3. Knowledge acquisition

a. In modeling the application and solution domain, software engineers collect data, organize it into
information, and formalize it into knowledge.
b. Knowledge acquisition is nonlinear, as a single piece of data can invalidate complete models.
c. A common mistake that software engineers and managers make is to assume that the acquisition of
knowledge needed to develop a system is linear.
4.Rationale management

a. When acquiring knowledge and making decisions about the system or its application domain,
software engineers also need to capture the context in which decisions were made and the
rationale behind these decisions.
 enables software engineers to understand the implication of a proposed change when
revisiting a decision.

2.Software engineering concepts

 Participants and roles

 Clients, developers, Project manager, end users are taken as participants.
 Roles is set of responsibilities in the project or the system
 Systems and models
 model to refer to any abstraction of the reality.
 system to refer to the underlying reality
 Work products
 is an artifact that is produced during the development, such as a document or a piece
of software for other developers or for the client.
 internal work product: e.g test prototype, scenarios
 Deliverable: e.g operation and maintenance manual
 Activities, tasks, and resources
  Activity is a set of tasks that is performed toward a specific purpose. e.g Requirement
elicitation
 A task represents an atomic unit of work that can be managed.
 Resources are assets that are used to accomplish work.
 Goals, requirements, and constraints
 Goal is a high-level principle that is used to guide the project. Goals define the
attributes of the system that are important.
 Requirements are features that the system must have.
 A functional requirement is an area of functionality that the system must support,
whereas a
 nonfunctional requirement is a constraint on the operation of the system.
 Notations, methods, and methodologies
 A notation is a graphical or textual set of rules for representing a model. E. g UML
 A method is a repeatable technique for solving a specific problem. E.g a rational
management is method for justifying change.
 A methodology is a collection of methods for solving a class of problems. E.g Unified
Process

3.Software Engineering Development Activities

• Development activities deal with the complexity by constructing models of the problem
domain or the system. Development activities include:

1. Requirements Elicitation
2. Analysis
3. System Design
4. Object Design
5. Implementation
 Requirements elicitation
 The client and developers define the purpose of the system.
 The result of this activity is a description of the system in terms of actors and use cases.
 Actors represent the external entities that interact with the system. Users, Other
systems, computers
 Use cases are general sequences of events that describe all the possible actions
between an actor and the system for a given piece of functionality.
 During requirements elicitation, the client and developers also agree on a set of
nonfunctional requirements.
 Analysis
• During analysis, developers aim to produce a model of the system that is correct,
complete, consistent, unambiguous, realistic, and verifiable.
• Developers transform the use cases produced during requirements elicitation into an
object model that completely describes the system.
• During this activity, developers discover ambiguities and inconsistencies in the use
case model that they resolve with the client.
The result of analysis is an object model annotated with attributes, operations, and
associations.
 System design
 During system design, developers define the design goals of the project and decompose the
system into smaller subsystems that can be realized by individual teams.
 Developers also select strategies for building the system, such as the hardware/software
platform on which the system will run.
 The result of system design is a clear description of each of these strategies, a subsystem
decomposition, and a deployment diagram representing the hardware/software mapping of
the system.
 Object design
 developers define custom objects to bridge the gap between the analysis model and the
hardware/ software platform defined during system design. Include:
 restructuring the object model to attain design goals.
 optimizing the object model for performance.
 precisely describing object and subsystem interfaces.
 The result of the object design activity is a detailed object model annotated with constraints
and precise descriptions for each element.
 Implementation
 Developers translate the object model into system that includes implementing the attributes
and methods of each object and integrating all the objects such that they function as a single
system. source code.
 4. Managing software development
• Management activities focus on planning the project, monitoring its status, tracking
changes, and coordinating resources such that a high-quality product is delivered on
time and within budget. It includes:
1. Communication: deal with communication issues
2. Rationale management: Rationale is the justification of decisions.
3. Testing :developers find differences between the system and its models by
executing the system (or parts of it) with sample input data sets.
3.1 During unit testing, developers compare the object design model with each object and
3.2 During integration testing, combinations of subsystem are combined and compare with
the System Design model.

4. Software configuration management :

• This process monitors and controls changes in work products, due to:

• client requests new features

• developers improve their understanding of the application domain.

• Change in new hardware technologies

5. Project management Includes:

• the oversight activities that ensure the delivery of a high-quality system on

time and within budget.

• planning and budgeting the project

• hiring developers and organizing them into teams

• monitoring the status of the project.

6.Software life cycle

• Software life cycle is a general model of the software development process .

 SDLC Phases
 Systems Investigation
o Identify problems or opportunities
 Systems Analysis
o How can we solve the problem
 Systems Design
 o Select and plan the best solution
 Systems Implementation
o Place solution into effect
 Systems Maintenance and Review
o Evaluate the results of the solution
 Weaknesses of SDLC
 Models of processes are unstable
 Output-driven design leads to instability
 User dissatisfaction
 Maintenance workload
 Emphasis on “hard” thinking – simplistic assumptions like “identified facts that need
investigation”, “best solution”, etc
Assumption of “green-field” development – incremental on a clean slate
 Structured Vs. O-O Paradigm
 Structured
Data Flow methodology
Compliments Structured Programming
Can be repeatable, measurable, & automated
(CASE brought significant assistance)
Functional perspective of problem domain
Describes the real world as data flowing
through the information system, being
transformed from inputs to outputs
Separates data from functionality

Object Oriented
Object modeling
Compliments object-oriented
programming
Can be repeatable, measurable, &
automated
Object perspective of the problem
domain
Describes the real world by its
objects, attributes, services, and
relationships
Data & functions are encapsulated
together
 Structured Vs. O-O Paradigm
 Structured Paradigm
o Separates data from functionality
  Data – modeled using a data/persistence model
 Functionality – modeled using a process model
 O-O paradigm
o Defines systems as a collection of interacting parts called objects, which do things
(functionality) and know things (data).
 The Potential benefits of O-O
Increased Reusability
Increased Extensibility
Increased Chance of Project Success
Reduced Maintenance Burden
Managed Complexity
Financial benefit.
 The Potential Drawbacks of O-O
O-O requires greater concentration on requirements analysis and design
Developers must work with users
O-O requires a complete change in mindset on the part of individuals & organizations
Many O-O benefits are long-term
O-O demands upfront investments in training, education and tools
O-O necessitates increased testing
O-O is only part of the solution