CH 01 Lect 1
CH 01 Lect 1
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1
Object-Oriented Software Engineering
Using UML, Patterns, and Java Chapter 1: Introduction
Objectives of the Class
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
Acquire Technical Knowledge
Understand System Modeling
Learn About Modeling
Using (~20% and some) Aspects of UML (Unified Modeling Language)
Lecture
LectureNotes
Noteswill
willadapt
adaptBruegge’s,
Bruegge’s,
but
butwith
withadditional
additionalpoints
pointsand
andquestions
questions
possibly
possiblyfrom
fromvery
verydifferent
differentperspectives.
perspectives.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5
Outline of Today’s Lecture
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
Why Software Engineering?
Used as delivered
2%
Usable w. rework
Paid for, but
3% not delivered
Used w. extensive rework, 30%
but later abandoned
20%
Take
Takeaalook
lookat
atthe
theStandish
StandishReport
Report(The
Bernd Bruegge & Allen H. Dutoit
(The“Chaos”
“Chaos”Report)
Report)
Object-Oriented Software Engineering: Using UML, Patterns, and Java 7
Software Engineering: A Problem Solving Activity
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 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 10
Factors affecting the quality of a software system
Complexity:
The system is so complex that no single programmer can understand it
anymore
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 (“Second Law of Software
Dynamics”).
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 11
Complex Server Connections
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
Complex Message Flow
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
Dealing with Complexity
1. Abstraction
2. Decomposition
3. Hierarchy
What is this?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14
1. Abstraction
1. Models are used to provide abstractions 2. Decomposition
3. Hierarchy
Inherent human limitation to deal with complexity
The 7 +- 2 phenomena
Chunking: Group collection of objects
Ignore unessential details: => Models
What does this refer to?
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? 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 ? In UML?
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?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
Model-based software Engineering:
Code is a derivation of object model Is this a “problem”?
};
AAgood
goodsoftware
softwareengineer
engineerwrites
writesas
aslittle
littlecode
codeas
aspossible
possible
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
Example of an Issue: Galileo vs the Church
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Issue-Modeling
Issue:
What is the Resolution (1615):
Resolution (1998): Center of the The church
The church declares Universe? decides proposal 1
proposal 1 was wrong is right
Proposal1: Proposal2:
The earth! The sun!
Pro: Pro:
Aristotle Con: Copernicus
says so. Jupiter’s moons rotate says so.
around Jupiter, not
around Earth.
Pro:
Change will disturb
the people. Anything
Anythingmissing?
missing?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
1. Abstraction
2. Decomposition 2. Decomposition
3. Hierarchy
Produce
Read Input Transform Level 1 functions
Output
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
Functional Decomposition: Autoshape
Autoshape
Then, depending on the purpose, could a functional decomposition be better than an OO decomposition?
Which is UML
Bernd Bruegge for,
& Allen functional- or OO-decomposition?
H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
Model of an Eskimo
Eskimo
Size
Dress()
Smile()
Sleep()
Shoe
* Coat
Size Size
Color Color
Type Type
Wear() Wear()
*
Entrance
Windhol MainEntrance
e Size
Diamete
r but is it the right model?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
Alternative Model: The Head of an Indian
Indian
Hair
Dress()
Smile()
Sleep()
Face Mouth
Ear Nose NrOfTeet
Size * smile() hs
Size
listen() close_eye(
) open()
speak()
2 important hierarchies
"Part of" hierarchy
"Is-kind-of" hierarchy
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
Part of Hierarchy
Computer
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29
Is-Kind-of Hierarchy (Taxonomy)
Cell
Any issue?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
So where are we right now?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
Software Lifecycle Definition
Software lifecycle:
Set of activities and their relationships to each other to support the
development of a software system
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
Software Lifecycle Activities
Deliverable 0
Deliverable 1 Deliverable 2 Deliverable 3 Deliverable 4 Deliverable 5 Deliverable 6
Implemente
Expressed in d
Structured Realized By By
Terms Of By Verified
By
class...
class...
class... ?
class.... ?
Use Case Applicatio Solution
n SubSystems Source Test
Model Domain
Domain Code Cases
Objects
Objects
EachBernd
activity produces one
Bruegge & Allen H. Dutoit
or more models
Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
Reusability: 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 34
Summary
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
Additional Slides
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
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".
Take
Takeaalook
lookat
atthe
theStandish
StandishReport
Bernd Bruegge & Allen H. Dutoit
Report(The
(The“Chaos”
“Chaos”Report)
Report)
Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
Reusability
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
Patterns are used by many people
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39