TUM
Software Engineering
Bernd Brügge
Technische Universität München
Lehrstuhl für Angewandte Softwaretechnik
http://www12.in.tum.de
11 May 1999
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 1
Objectives of the Class
v Appreciate Software Engineering
v Understand how to
w produce a high quality software system within time
w while dealing with complexity and change
v Acquire technical knowledge
v Acquire managerial knowledge
v Use this knowledge in the WS 1999/2000 Programmier
Praktikum
w Distributed project with a real client (Daimler Chrysler)
w Two development teams (Carnegie Mellon University and
Technische Universität München)
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 2
Acquire Technical Knowledge
v Understand System Modeling
v Learn UML (Unified Modeling Language)
v Learn different modeling methods:
u Use Case modeling
u Object Modeling
u Dynamic Modeling
v Learn to use Tools:
w CASE Tool: Together-J
w Configuration Management: CVS
v Move into Component-Based Software Engineering
w Use Design Patterns and Frameworks
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 3
Acquire Managerial Knowledge
v Understand the Software Lifecycle
w Process vs Product
w Learn about different software lifecycles
w Greenfield Engineering, Interface Engineering, Reengineering
v Project Management
w Planning a Project
u Project Initiation
w Different Project Management Styles
u Team-based Project Management
w Communication Management (Meetings, Reviews)
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 4
Assumptions and Requirements for this Class
v Assumption:
w You are proficient in a programming language such as C++ or
(preferrably) Java, but you have no experience in analysis or
design of a system
w You have access to a Web Browser
u Course Schedule with lecture slides is on the web:
u http://www12.in.tum.de/teaching/SS99/CBSE/schedule.html
v Requirements:
w You have completed your Vor-Diplom or
w You have practical experience with maintaining or developing
a large software system
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 5
Readings
v Required:
w Bernd Brügge, Allen Dutoit:
u “Object-Oriented Software Engineering: Mastering
Complexity and Change”, Prentice Hall, 1999, Preprint
available from Fachschaft
w Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides:
u “Design Patterns”, Addison-Wesley 1996, ISBN 0-201-633
v Recommended:
w Grady Booch, James Rumbaugh, Ivar Jacobsen, “The Unified
Modeling Language User Guide”, Addison Wesley, 1999
w K. Popper, “Objective Knowledge, an Evolutionary Approach,
Oxford Press, 1979.
v Additional books are recommended during each lecture
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 6
Outline of Today’s Lecture
v A few announcements
v High quality software: State of the art
v Modeling complex systems
w Functional vs. object-oriented decomposition
v Dealing with change:
w Software lifecycle modeling
v Reuse:
w Design Patterns
w Frameworks
v Transatlantic Project: WS 1999/2000
v Concluding remarks
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 7
Ferienakademie Sarntaal
v Where and When:
w Sarntal, Südtirol, 19.September - 1. Oktober 1999:
v Introduction by Dr. Ehler
w Flyer and Sign Up Sheet
v For more information:
w General:
u http://www5.informatik.tu-muenchen.de/FA/
w Kurs 11 on Augmented Reality
u http://www12.in.tum.de/teaching/FA99/index.html
v What is Augmented Reality?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 8
Visting Professor Roy Maxion, Carnegie
Mellon University, SS 1999
v Dependable System Design
v Bereich Informatik I (Praktische Informatik),
Vertiefungsvorlesung, Sonstige prüfbare Vorlesung
v Note: Lecture also in English
v URL:
w http://www12.in.tum.de/teaching/SS99/DSD.html
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 9
Can you develop this?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 10
Limititations of Non-engineered Software
Requirements
Software
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 11
Software Production has a Poor Track Record
Example: Space Shuttle Software
v Cost: $10 Billion, millions of $$ more than planned
v Time: 3 years late
v Quality: First launch of Columbia was cancelled because
of synchronization problem with the Shuttle's 5 onboard
computers.
w 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.
w The likelihood of the error was small enough, that the error
caused no harm during thousands of hours of testing.
v Substantial errors still exist. Astronauts are still supplied
with a book of known software problems "Program
Notes and Waivers".
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 12
Quality of today’s software….
v The average software product released on the market is
not error free.
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 13
…has major impact on Users
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 14
Software Engineering is A Problem Solving
Activity
v Analysis: Understand the nature of the problem and
break the problem into pieces
v Synthesis: Put the pieces together into a large structure
v To solve the problems we use
w Techniques(Methods): Formal procedures for producing
results using some well-defined notation
w Methodologies: Collection of techniques applied across the
software development lifecycle and unified by some general
philosphical approach
w Tools: Instrumentsor automated systems to accomplish a
technique
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 15
Software Engineering: Definition
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.
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 16
20
Scientist vs Engineer
v Computer Scientist
w Proves theorems about algorithms, designs languages, defines
knowledge representation schemes
w Has infinite time…
v Engineer
w Develops solution for application-specific problem for a client
w Uses computers & languages, tools, techniques and methods
v Software Engineer
w Works in multiple application domains
w Has only 6 months...
w …while changes occurs in requirements and available
technology
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 17
Factors affecting the quality of a software
system
v Change:
w “Entropy” of the 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”).
w 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.
v Complexity
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 18
Why are software systems so complex?
v The problem domain is difficult
v The development process is very difficult
to manage
v Software offers extreme flexibility
v Software is a discrete system
wContinuous systems have no hidden
surprises (Parnas)
wDiscrete systems have!
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 19
Dealing with Complexity
1. Abstraction
2. Decomposition
3. Hierarchy
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 20
What is this?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 21
1. Abstraction
v Inherent human limitation to deal with
complexity
wThe 7 +- 2 phenomena
v Chunking: Group collection of objects
v Ignore unessential details: => Models
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 22
Models are used to provide abstractions
v System Model:
w Object Model: What is the structure of the system? What are
the objects and how are they related?
w Functional model: What are the functions of the system? How
is data flowing through the system?
w Control model: How does the system react to external events?
How is the event flow in the system ?
v Task Model:
w PERT Chart: What are the dependencies between the tasks?
w Schedule: How can this be done within the time limit?
w Org Chart: What are the roles in the project or organization?
v Issues Model:
w What are the open and closed issues? What constraints were
posed by the client? What resolutions were made?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 23
Model-based software Engineering:
Code should be 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 * * Company
Lists 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
Agood
goodsoftware
softwareengineer
engineerwrites
writesas
aslittle
littlecode
codeas
aspossible
possible
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 24
The Bermuda Triangle of Modeling
System Models Object Model
class...
class... Code
Functional class...
Model
Control Model
Constraints
Arguments Org Chart
Issues Pro Con
PERT Chart
Proposals Gantt Chart
Issue Model Task Models
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 25
Example of an Issue: Galileo vs the Church
What is the center of the Universe?
wChurch: The earth is the center of the
universe. Why? Aristotle says so.
wGalileo: The sun is the center of the universe.
Why? Copernicus says so. Also, the Jupiter’s
moons rotate round Jupiter, not around
Earth.
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 26
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.
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 27
2. Decomposition
v Another technique used to master complexity (“divide
and conquer”)
v Functional decomposition
w The system is decomposed into modules
w Each module is a major processing step (function) in the
application domain
w Modules can be decomposed into smaller modules
v Object-oriented decomposition
w The system is decomposed into classes (“objects”)
w Each class is a major abstraction in the application domain
w Classes can be decomposed into smaller classes
Which decomposition is the right one?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 28
Functional Decomposition
System
Function Top Level functions
Produce
Read Input Transform Level 1 functions
Output
Produce Level 2 functions
Read Input Transform
Output
Load R10 Add R1, R10 Machine Instructions
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 29
Functional Decomposition
v Functionality is spread out all over the system
v Maintainer must understand the whole system to make a
single change to the system
v Consequence:
w Code that is complex and impossible to maintain
w User interfaces that are hard to understand
v Example: Autoshapes
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 30
Functional Decomposition
System
Function Top Level functions
Produce
Read Input Transform Level 1 functions
Output
Produce Level 2 functions
Read Input Transform
Output
Load R10 Add R1, R10 Machine Instructions
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 31
What is This?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 32
Model of an Eskimo
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 33
Iterative Modeling then leads to ....
but is it the right model?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 34
Alternative Model: The Head of an Indian
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 35
Class Identification
v Class identification is crucial to object-oriented modeling
v Basic assumption:
w 1. We can find the classes for a new software system
(Greenfield Engineering)
w 2. We can identify the classes in an existing system
(Reengineering)
w 3. We can create a class-based interface to any system (Interface
Engineering)
v Why can we do this? Philosophy, science, experimental
evidence
v What are the limitations? Depending on the purpose of
the system different objects might be found
u How can we identify the purpose of a system?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 36
What is this Thing?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 37
Modeling a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 38
A new Use for a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
SitOnIt()
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 39
Questions
v Why did we model the thing as “Briefcase”?
v Why did we not model it as a chair?
v What do we do if the SitOnIt() operation is the
most frequently used operation?
v The briefcase is only used for sitting on it. It is
never opened nor closed.
w Is it a “Chair”or a “Briefcase”?
v How long shall we live with our modeling
mistake?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 40
3. Hierarchy
v We got abstractions and decomposition
w This leads us to chunks (classes, objects) which we view with
models
v Another way to deal with complexity is to provide
simple relationships between the chunks
v One of the most important relationships is hierarchy
v 2 important hierarchies
w "Part of" hierarchy
w "Is-kind-of" hierarchy
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 41
Part of Hierarchy
Computer
I/O Devices CPU Memory
Cache ALU Program
Counter
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 42
Is-Kind-of Hierarchy
Cell
Muscle Cell Blood Cell Nerve Cell
Striate Smooth Red White Cortical Pyramidal
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 43
So where are we right now?
v Three ways to deal with complexity:
w Abstraction
w Decomposition
w Hierarchy
v Object-oriented decomposition is a good methodology
w Unfortunately, depending on the purpose of the system,
different objects can be found
v How can we do it right?
w Many different possibilities
w Our current approach: Start with functional model (Use case
model), then proceed to the object model
w This leads us to the software lifecycle
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 44
Software Lifecycle Activities
Requirements Requirements System Object Implemen-
Testing
Elicitation Analysis Design Design tation
class...
class...
class...
class....
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 45
Software Lifecycle Definition
v Software lifecycle:
w Set of activities and their relationships to each other to support
the development of a software system
v Typical Lifecycle questions:
w Which activities should I select for the software project?
w What are the dependencies between activities?
w How should I schedule the activities?
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 46
What is ahead?
ProgrammierPraktikum WS 1999/2000
v Real client: DaimlerChrysler
v Communication infrastructure based on Lotus Notes
w Replication to ensure efficient access to communication threads
v Distributed configuration management with a shared
repository
v Development, reviews and delivery via the Internet
v Project Duration: 3 months
v Organization: 3 interleaved projects
w Fall 1999: Carnegie Mellon University (CMU)
w Winter 1999/2000: Technical University Munich (TUM)
w Spring 2000 Semester: CMU
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 47
Example of a Transatlantic Project WS 98/99
JAMES: Java Architecture for Mobile Extended Services
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 48
JAMES Cardlets and Viewlets
u s
B
a rd
B o
O n
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 49
Project Communication Infrastructure
Web Configuration Domino
Servers Management Servers
Server
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 50
Reuse
v A good software design solves a specific problem but is
general enough to address future problems (for example,
changing requirements)
v Experts do not solve every problem from first principles
w They reuse solutions that have worked for them in the past
v Goal for the software engineer:
w Design the software to be reusable across application domains
and designs
v How?
w Use design patterns and frameworks whenever possible
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 51
Design Patterns and Frameworks
v Design Pattern:
w A small set of classes that provide a template solution to a
recurring design problem
w Reusable design knowledge on a higher level than
datastructures (link lists, binary trees, etc)
v Framework:
w A moderately large set of classes that collaborate to carry out a
set of responsibilities in an application domain.
u Examples: ET++, Web Objects
v Architectural guidance during design
v Foundation for software components industry
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 52
Patterns are used by many people
v Chess Master: v Software Engineer
w Openings w Composite Pattern: A
w Middle games collection of objects needs to
be treated like a single object
w End games
w Adapter Pattern (Wrapper):
v Writer Interface to an existing system
w Tragically Flawed Hero w Bridge Pattern: Interface to an
(Macbeth, Hamlet) existing system, but allow it
w Romantic Novel to be extensible
w User Manual w ….
v Architect
w Office Building
w Commercial Building
w Private Home
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 53
Using a Bridge
v Provides multiple implementations under the same
interface.
v Interface to a component that is incomplete, not yet
known or unavailable during testing
Seat Interface Seat Implementation
VIP
(in Simulation Facade)
Simulated
Stub Code Real Seat
Seat
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 54
What to do next?
v Bookmark the course schedule:
w http://wwwbruegge.informatik.tu-
muenchen.de/teaching/SS99/CBSE/schedule.html
w All lectures will be available online in PDF format
v Get the course manuscript
w Fachschaft
v Questions about the course?
w My office hours
u Mondays 15:00 - 16:00, Hauptgebäude, Room 1209
w Preferred:
u Send me e-mail: bruegge@in.tum.edu
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 55
Lecture Schedule
Tuesdays 15:15-16:45 Thursdays 15:15-16:45
May vv May
May13:13:NoNolecture
vv May11:11:Introduction
Introduction lecture
May vv May
May20:20:Software
SoftwareLifecycle
vv May18:18:Modeling
Modelingwith
withUMLUML Lifecycle
May vv May
May27:27:Requirements
RequirementsElicitation
vv May25:25:NoNolecture
lecture Elicitation
June vv June
June3:3:NoNolecture
vv June1:1:Requirements
RequirementsAnalysis
AnalysisII lecture
June vv June
June10:
10:System
SystemDesign
vv June8:8:Requirements
RequirementsAnalysis
AnalysisIIII Design
June vv June
June17:
17:Configuration
vv June15:
15:Rationale
Rationale Management
Configuration
June Management
vv June22:
22:Design
DesignPatterns
PatternsII June
June
vv June24:
24:Design
DesignPatterns
PatternsIIII
vv June29:
29:Frameworks
Frameworks(Web-
(Web- July
Objects)
Objects)
vv July1:1:Object
ObjectDesign
DesignII
July vv July
July8:8:CASE
CASETools
vv July6:6:Object
ObjectDesign
Design IIII Tools
July vv July
July15:
15:Testing
TestingIIII
vv July13:
13:Testing
TestingII
July vv July
July22:
22:Software
SoftwareLifecycle
vv July20:
20:Project
ProjectManagement
Management Revisited
Lifecycle
Revisited
vv July 27: :Project
July27 ProjectCommunication
Communication vv July 29: :CVS
July29 CVSTutorial
Tutorial
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 56
Summary
v Software engineering is a problem solving activity
w Developing quality software for a complex problem within 6
months while things are changing
v Many ways to deal with complexity
w Modeling, decomposition, (abstraction, hierarchy)
w Issue models: Negotiation aspects
w System models: Technical aspects
w Task models: Project management aspects
w Use Patterns
v Many ways to do deal with change
w Tailoring the software lifecycle
w Use a nonlinear software lifecycle based on issue modeling
w Provide configuration management
Copyright 1999 Bernd Bruegge Sofgtware Engineering 1999 57
