Using UML, Patterns, and Java
Object-Oriented Software Engineering
Chapter 1: Introduction
Outline



High quality software: State of the art
Modeling complex systems
Dealing with change:
 Software lifecycle

Reuse:
 Design Patterns
 Frameworks
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
Can you develop this?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
3
Limitations of Non-engineered Software
Can we foresee the
requirements?
Requirements
Trial and error?
Ad-hoc approach?
Does it really do what the
users need it to do?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Software
4
Software Production has a Poor Track Record
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".
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
Example: Ariane-5, Flight 501






European Space Agency’s reusable launch vehicle
Cost: 10 years of development and cost of €7 billion
Launched: 4 June 1996
Mission: $500 million payload to be delivered to orbit
Fate: Veered off course and destructed itself 40 sec. after launch
Conclusions about the cause:
 Unhandled floating point exception in Ada Code
 Happened due to software specification and design errors
 The extensive reviews and tests did not include adequate analysis and
testing, which could have detected the potential failure
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
Other Book Examples of SWE Failures

Denver International Airport
 “In 1995, bugs in the automated luggage system ... caused suitcases
to be chewed up. The airport opened 16 months late, $3.1 billion
over budget, with mostly manual luggage system”

Swanick Air Traffic Control System
 Controls Air traffic over England and Wales
 Delivered in 2002, 6 years late
 Substantially over budget (￡623 M versus the planned￡325 M)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
Quality of today’s software….


The average software product released on the market is not
error free.
Software bugs, or errors, are so prevalent and so detrimental
 They cost the U.S. economy an estimated $59.5 billion annually, or
about 0.6% of the gross domestic product, according to a 2002 NIST
Report

Software developers spend approximately 80% of development
costs on identifying and correcting defects
 and yet few products other than software are shipped with such
high levels of errors
 Complexity of building software solutions
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
Software Engineering: A Problem Solving Activity

Goal of Software Engineering
 Produce high quality software to satisfy a set of functional and
nonfunctional requirements
 It
is a problem solving activity
How do we solve a problem?
 Analysis: Understand the nature of the problem (requirements)
and break the problem into pieces (e.g. Object Identification in
OO development)
 Synthesis: Put the pieces together into a large structure
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
Techniques, Methodologies and Tools
For problem solving (Analysis and Synthesis) we use
 Techniques (methods):
 Formal procedures for producing results using some well-defined
notation
 E.g., algorithms, cook book recipes, etc.

Methodologies:
 Collection of techniques applied across software development and
unified by a philosophical approach
 E.g., a cookbook

Tools:
 Instrument or automated systems to accomplish a technique
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
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.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
20
Scientist vs Engineer

Computer Scientist
 Proves theorems about algorithms, designs languages, defines
knowledge representation schemes
 Has infinite time…

Engineer
 Develops a solution for an application-specific problem for a client
 Uses computers & languages, tools, techniques and methods

Software Engineer
 Works in multiple application domains
 Has only 3 months...
 …while changes occurs in requirements and available technology
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
Comment About SWE Tools:
Software/Hardware vs. Grayware vs. Thinkware


Tools can not substitute skill, knowledge and experience
Tool-based analysis is that it is often insufficient or incomplete
 System developers are much better at collecting and documenting
data than they are at interpreting what these data mean
 knowledge and experience, technique skills cannot replace good
analysis - people are still needed to think through the problem
 The real value is not in the tools and tools output but is in the
thought and insight that only the analyst can provide
Being able to use a tool does not mean you understand the
underlying techniques, and understanding the techniques does
not mean you understand the problem.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
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:
 The “Entropy” of a software system increases with each change: Each
implemented change erodes the structure of the system which makes the
next change even more expensive.
 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.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Why are software systems so complex?

The problem domain is difficult
 Developers are not experts in the domain

The development process is very difficult to manage
 Non-linear development process—dependencies that may not be
unless you try the design

Software offers extreme flexibility
 No physical constraints on software complexity
 No physical constraints on change

Software is a discrete system
 Continuous systems have no hidden surprises
 Discrete systems have!
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
Dealing with Complexity
1.
2.
3.
Abstraction
Decomposition
Hierarchy
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
What is this?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
How about this?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
1. Abstraction

Inherent human limitation to deal with complexity
 The 7 +- 2 phenomena

Chunking: Group collection of objects
Remember the following:
ACD98
Ignore unessential details => Models
10101100110110011000
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Models are used to provide abstractions

System Model:
 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? User’s
point of view.
 Dynamic model: How does the system react to external events? How
is the event flow in the system ?

Task Model:
 PERT Chart: What are the dependencies between the tasks?
 Schedule: How can this be done within the time limit?
 Org Chart: What are the roles in the project or organization?

Issues Model:
 What are the open and closed issues? What constraints were posed
by the client? What resolutions were made? Rationale?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Functional Model Example

Ticket Distribution System
SimpleWatch
ReadTime
WatchUser
SetTime
WatchRepairPerson
ChangeBattery
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Object Model Example
SimpleWatch
2
PushButton
Bernd Bruegge & Allen H. Dutoit
1
1
Display
1
1
1
2
Battery
Object-Oriented Software Engineering: Using UML, Patterns, and Java
1
Time
22
Dynamic Model Example I (Sequence Diagram)
:SimpleWatch
:WatchUser
pressButton1()
:Display
:Time
blinkHours()
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
Dynamic Model Example II (State Diagram)
button1&2Pressed
Blink
Hours
button2Pressed
Increment
Hours
button1Pressed
button1&2Pressed
Blink
Minutes
button2Pressed
Increment
Minutes
button1Pressed
Stop
Blinking
Bernd Bruegge & Allen H. Dutoit
Blink
Seconds
button2Pressed
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Increment
Seconds
24
Task Model Example: Gantt Chart
Gantt Chart of Activities
= Activity,
X = Completed
Task 1: Prototype implementation
Estimate
Duration
Reporting Period
(1-6 months)
Reporting Period
(6-12 months)
Reporting Period
(12-18 months)
Reporting Period
(18-24 months)
23 months
NDMP file access protocol
X
X
Metadata service
X
Distributed file locking
X
Log manager
X
Reconfiguration manager
X
Caching server
X
System manager
X
Integration
Task 2: Algorithm development
Data layout for PND coding
X
9 months
X
X
Deadlock avoidance
X
Data restriping
X
Task 3: Testing & perf. tuning
20 months
Task 4: Research documentation
6 months
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
X
X
25
Task Model Example: PERT Chart
Sto rage sub syst em
sys tem anal ysis
1
5d
Nov 13
Nov 19
Bernd Bruegge & Allen H. Dutoit
Sto rage sub syst em
obj ect desi gn
2
5d
Nov 20
Nov 26
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Sto rage sub syst em
tes t pl an
5
10d
Nov 27
Dec 10
Sto rage sub syst em
imp leme ntat ion
3
15d
Nov 27
Dec 17
26
Example of an Issue: Galileo vs the Church

What is the center of the Universe?
 Church: The earth is the center of the universe. Why? Aristotle says
so.
 Galileo: The sun is the center of the universe. Why? Copernicus
says so. Also, the Jupiter’s moons rotate round Jupiter, not around
Earth.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
27
Issue-Modeling
Issue:
What is the
Center of the
Universe?
Resolution (1998):
The church declares
proposal 1 was wrong
Proposal2:
The sun!
Proposal1:
The earth!
Pro:
Resolution (1615):
The church
decides proposal 1
is right
Con:
Jupiter’s moons rotate
around Jupiter, not
Aristotle
says so.
Pro:
Copernicus
says so.
around Earth.
Pro:
Change will disturb
the people.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Interdependencies of the Models
System Model (Structure,
Functionality,
Dynamic Behavior)
Issue Model
(Proposals,
Arguments,
Resolutions)
Bernd Bruegge & Allen H. Dutoit
Task Model
(Organization,
Activities
Schedule)
Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
The “Bermuda Triangle” of Modeling
System Models
Object Model
Functional
Model
Constraints
Arguments
Issues
Pro Con
Proposals
Issue Model
Bernd Bruegge & Allen H. Dutoit
class...
class...
class...
Forward
Engineering
Code
Reverse
Engineering
Dynamic Model
Org Chart
PERT Chart
Gantt Chart
Task Models
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
Model-based software Engineering:
Code is a derivation of object model
Problem Statement : A stock exchange lists many companies.
Each company is identified by a ticker symbol
Analysis phase results in cbject model (UML Class Diagram):
*
StockExchange
Lists
*
Company
tickerSymbol
Implementation phase results in code
public class StockExchange
{
public Vector m_Company = new Vector();
};
public class Company
{
public int m_tickerSymbol
public Vector m_StockExchange = new Vector();
};
A good software engineer writes as little code as possible
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
2. Decomposition


A technique used to master complexity (“divide and conquer”)
Functional decomposition
 The system is decomposed into modules
 Each module is a major processing step (function) in the application
domain
 Modules can be decomposed into smaller modules

Object-oriented decomposition
 The system is decomposed into classes (“objects”)
 Each class is a major abstraction in the application domain
 Classes can be decomposed into smaller classes
Which decomposition is the right one?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
Functional and OO Decomposition
main
Account
credit
debit
perform transaction
credit
debit
compute interest
if checking
then xxx
if sav ings
then xxx
etc.
Bernd Bruegge & Allen H. Dutoit
compute fees
if checking
then xxx
if sav ings
then xxx
etc.
CheckingAccount Sav ingsAccount
compute interest
compute f ees
Object-Oriented Software Engineering: Using UML, Patterns, and Java
compute interest
compute f ees
33
Functional Decomposition
System
Function
Read Input
Open File
Set Pointer
Load R10
Bernd Bruegge & Allen H. Dutoit
Transform
Top Level functions
Produce
Output
Level 1 functions
Level 2 functions
Read line
Add R1, R10
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Machine Instructions
34
Functional Decomposition



Functionality is spread all over the system
Maintainer must understand the whole system to make a single
change to the system
Consequence:
 Codes are hard to understand
 Code that is complex and impossible to maintain
 User interface is often awkward and non-intuitive

Example: Microsoft Powerpoint’s Autoshapes
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
35
Functional Decomposition: Autoshape
Autoshape
Mouse
click
Change
Rectangle
Draw
Change
Change
Oval
Change
Circle
Draw
Rectangle
Bernd Bruegge & Allen H. Dutoit
Draw
Oval
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Draw
Circle
36
What is This?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
37
Model of an Eskimo
Eskimo
Size
Dress()
Smile()
Sleep()
*
Shoe
Size
Color
Type
Wear()
Bernd Bruegge & Allen H. Dutoit
Coat
Size
Color
Type
Wear()
Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
Iterative Modeling then leads to ....
lives in
Cave
Lighting
Enter()
Leave()
Eskimo
Size
Dress()
Smile()
Sleep()
moves
around
Outside
Temperature
Light
Season
Hunt()
Organize()
*
Entrance
Windhole
Diameter
MainEntrance
Size
but is it the right model?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
39
Alternative Model: The Head of an Indian
Indian
Hair
Dress()
Smile()
Sleep()
Ear
Size
listen()
*
Bernd Bruegge & Allen H. Dutoit
Face
Nose
smile()
close_eye()
Mouth
NrOfTeeths
Size
open()
speak()
Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
Class Identification


Class identification is crucial to object-oriented modeling
Basic types of class identification activities:
1. Find the classes for a new software system (from scratch): We call
this Greenfield Engineering
2. Identify the classes in an existing system (redesign): We call this
Reengineering
3. Create a class-based interface to any system (redesign interface
and keep the core): We call this Interface Engineering

What are the limitations? Depending on the purpose of the
system different objects might be found
 How can we identify the purpose of a system?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
What is this Thing?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
42
Modeling a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
A new Use for a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
SitOnIt()
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
Questions

Why did we model the thing as “Briefcase”?

Why did we not model it as a chair?
What do we do if the SitOnIt() operation is the most
frequently used operation?
 The briefcase is only used for sitting on it. It is never
opened nor closed.

 Is it a “Chair”or a “Briefcase”?

How long shall we live with our modeling mistake?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
45
3. Hierarchy

We got abstractions and decomposition
 This leads us to chunks (classes, objects) which we view with object
model



Another way to deal with complexity is to provide simple
relationships between the chunks
One of the most important relationships is hierarchy
2 important hierarchies
 "Part of" hierarchy
 "Is-kind-of" hierarchy
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
46
Part of Hierarchy
Computer
I/O Devices
CPU
Memory
Cache
ALU
Program
Counter
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
47
Is-Kind-of Hierarchy (Taxonomy)
Cell
Muscle Cell
Striate
Bernd Bruegge & Allen H. Dutoit
Smooth
Blood Cell
Red
White
Nerve Cell
Cortical
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Pyramidal
48
So where are we right now?

Three ways to deal with complexity:
 Abstraction
 Decomposition
 Hierarchy

Object-oriented decomposition is a good methodology
 Unfortunately, depending on the purpose of the system, different
objects can be found

How can we do it right?
 Many different possibilities
 Our current approach: Start with a description of the functionality
(Use case model), then proceed to the object model
 This leads us to the software lifecycle
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
49
Software Lifecycle Activities
Requirements
Elicitation
Analysis
Expressed in
Terms Of
System
Design
Structured By
...and their models
Object
Design
Implementation
Implemented
By
Realized By
Verified
By
class...
class...
class...
Use Case
Model
Bernd Bruegge & Allen H. Dutoit
Application
Subsystems
Domain
Objects
Testing
Solution
Domain
Objects
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Source
Code
?
class.... ?
Test
Cases
50
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?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
51
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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
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 data structures
(link lists, binary trees, etc.)

Framework:
 A moderately large set of classes that collaborate to carry out a set
of responsibilities in an application domain.



Examples: User Interface Builder
Provide architectural guidance during the design phase
Provide a foundation for software components industry
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
53
Patterns are used by many people

Chess Master:

 Openings
 Middle games
 End games

Writer
 Tragically Flawed Hero
(Macbeth, Hamlet)
 Romantic Novel
 User Manual

Software Engineer
 Composite Pattern: A collection
of objects needs to be treated
like a single object
 Adapter Pattern (Wrapper):
Interface to an existing system
 Bridge Pattern: Interface to an
existing system, but allow it to
be extensible
Architect
 Office Building
 Commercial Building
 Private Home
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
Composite Design Pattern I


Problem: Represent a hierarchy of objects so that leaves and
composites are treated uniformly through a common interface
Examples:
 Groups of drawable elements. Elements can be grouped into groups.
Groups can contain other groups. Elements and groups are
operated on (Move, Resize, etc.) uniformly
 Hierarchy of files and directories. Directories can contain files and
other directories. Same operations are available on files and
directories (Move, Copy, Delete, Rename, etc.)
 Hierarchy of tasks and subtasks. Tasks (composites) contain smaller
subtasks and action items (leaves). Same operations (add, delete,
modify, etc.) are applied on tasks, subtasks, and action items.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
Composite Design Pattern II


The Component interface specifies the services that are shared among
leaf and composite (e.g., move for a drawable element).
A Composite has an aggregation relationship with Component and
implements each service by iterating over each contained component.


E.g., Composite .move calls Component.move for each of its contained
components
The leave services do the actual work

E.g., Leave.move modifies the coordinates and redraws the leaf
Component
Leaf
*
Composite
Notice the advantages:
Client can use same code to deal with Leaves and Composites
Leaf behavior can independently be changed
New classes of leaf can be added
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
Summary

Software engineering is a problem solving activity
 Developing quality software for a complex problem within a limited
time while things are changing

There are many ways to deal with complexity





Modeling, decomposition, abstraction, hierarchy
Issue models: Show the negotiation aspects
System models: Show the technical aspects
Task models: Show the project management aspects
Use Patterns: Reduce complexity even further
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
57