Chapter 1

Introduction to Software Engineering

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 1
 Limitations of Non-engineered Software

Requirements

Software

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 3
 Objectives of the Class

 Appreciate Software Engineering:

 Build complex software systems in the context of frequent change
 Understand how to
 produce a high quality software system within time
 while dealing with complexity and change
 Acquire technical knowledge (main emphasis)
 Acquire managerial knowledge

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 2
 Example: Space Shuttle Software

 Cost: $10 Billion, millions of dollars more than planned

 Time: 3 years late
 Quality: First launch of Columbia was cancelled because of a
synchronization problem with the Shuttle's 5 onboard
computers.
 Error was traced back to a change made 2 years earlier when a
programmer changed a delay factor in an interrupt handler from
50 to 80 milliseconds.
 The likelihood of the error was small enough, that the error caused
no harm during thousands of hours of testing.
 Substantial errors still exist.
 Astronauts are supplied with a book of known software problems
"Program Notes and Waivers".

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 4
 Software Engineering Perspectives

 Software Engineering is a:
 Modeling activity: software engineers deals with complexity through
modeling
 Problem solving activity: models are used to search for solutions
within constraints (time and budget)
 Knowledge a acquisition activity: data collection and formalization
from models and solutions
 Rationale activity

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 9
 Software Engineering: A Problem Solving Activity

 Analysis: Understand the nature of the problem and break the

problem into pieces
 Synthesis: Put the pieces together into a large structure

For problem solving we use

 Techniques (methods):
 Formal procedures for producing results using some well-defined
notation
 Methodologies:
 Collection of techniques applied across software development
 Tools:
 Automated systems to accomplish a technique

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 5
 Software Engineering: Definition

Software Engineering is a collection of techniques,

methodologies and tools that help with the production of
 a high quality software system
 with a given budget
 before a given deadline
while change occurs.

 Software engineering is a problem solving activity to develop

quality software for a complex problem within a limited time
while things are changing.

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 6
 Factors affecting the quality of a software system

 Complexity:
 The system is so complex that no single programmer can understand it
anymore
 The introduction of one bug fix causes another bug

 Change:
 As time goes on, the cost to implement a change will be too high, and
the system will then be unable to support its intended task. This is true
of all systems, independent of their application domain or technological
base.

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 7
 Why are software systems so complex?

 The problem domain is difficult

 The development process is very difficult to manage
 Software offers extreme flexibility

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 8
 Modeling

 Modeling consists of building an abstraction of reality.

 Abstractions are simplifications because:
 They ignore irrelevant details and
 They only represent the relevant details.
 Models allow us to visualize and understand systems
 What is relevant or irrelevant depends on the purpose of the
model.

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 10
 Why model software?

Why model software?

 Software is getting increasingly more complex

 Windows XP > 40 mio lines of code
 A single programmer cannot manage this amount of code in its
entirety.
 Code is not easily understandable by developers who did not
write it
 We need simpler representations for complex systems
 Modeling is a mean for dealing with complexity

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 11
 System Models

 Object Model: What is the structure of the system? What are

the objects and how are they related?

 Functional model: What are the functions of the system? How

is data flowing through the system?

 Dynamic model: How does the system react to external events?

How is the event flow in the system ?

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 12
Software Lifecycle Activities ...and their models

Requirements System Object Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented
By
Expressed in Structured By Realized By Verified
Terms Of
By

class...
class...
class... ?
class....?
Application Solution
Use Case Subsystems
Domain Source Test
Model Domain
Objects Code Cases
Objects

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 14
Software Lifecycle Definition

 Software lifecycle:
 Set of activities and their relationships to each other to support the
development of a software system

 Typical Lifecycle questions:

 Which activities should I select for the software project?
 What are the dependencies between activities?
 How should I schedule the activities?

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 15
 Reusability

A good software design solves a specific problem but is general

enough to address future problems (for example, changing
requirements)
 Experts do not solve every problem from first principles
 They reuse solutions that have worked for them in the past

 Goal for the software engineer:

 Design the software to be reusable across application domains and
designs
 How?
 Use design patterns and frameworks whenever possible

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 16
 Design Patterns and Frameworks

 Design Pattern:
 A small set of classes that provide a template solution to a recurring
design problem
 Reusable design knowledge on a higher level than datastructures
(link lists, binary trees, etc)
 Framework:
 A set of classes that collaborate to carry out a set of responsibilities
in an application domain.
⧫ Examples: User Interface Builder

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 17
 Software Engineering Concepts

Project

*
Activity

is produced by * consumes
* *
WorkProduct Task Resources

System Participant

Model Time

Document Equipment

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 18
 Project is composed of number of activities (ex: analysis phase
is an activity)
 Each activity is a set of tasks (ex: determine functional
requirements)
 A task consume recourses and produce a workproduct
 A workproduct (artifact) is a system, model or document (ex:
source code, instruction manuals, specification document..).
 Resources are participants, time, or equipment
 Participants: all people involved in the project, each participant
has a role (ex: manager, client, user, developer).

Be rnd Bruegge & Allen H. Dutoit O bject-Oriented Software Engineering: Using UML, Patterns, and Java 19