Welcome to CIS 068 !
Lesson 2:
Software Engineering
or
Why not only code it ?
CIS 068
CIS 068
Why not only code it ?
• Which event happens more frequently ?
• Which is deadlier ?
CIS 068
Why not only code it ?
Famous Software
Failures
• AT&T long distance service
fails for nine hours
(Wrong BREAK statement in C-Code, 1990)
CIS 068
Why not only code it ?
Famous Software Failures cont’d:
• Mars Climate Orbiter (September 23rd, 1999)
The 125 million dollar Mars Climate Orbiter is assumed lost by officials at NASA. The failure
responsible for loss of the orbiter is attributed to a failure of NASA’s system engineer
process. The process did not specify the system of measurement to be used on the project.
As a result, one of the development teams used Imperial measurement while the other used
the metric system of measurement. When parameters from one module were passed to
another during orbit navigation correct, no conversion was performed, resulting in the loss
of the craft.
CIS 068
Why not only code it ?
Famous Software Failures cont’d:
• Hi-tech toilet swallows woman (2001)
[Source: Article by Lester Haines, 17 Apr 2001] A 51-year-old woman was subjected to a
harrowing two-hour ordeal when she was imprisoned in a hi-tech public convenience. She
was captured by the toilet, which boasts state-of-the-art electronic auto-flush and door
sensors, which steadfastly refused to release it’s victim, and further resisted attempts by
passers-by to force the door. Finally the fire brigade ripped the roof off the cantankerous
crapper.
CIS 068
Why not only code it ?
Famous Software Failures cont’d:
• E-mail buffer overflow (1998)
Several E-mail systems suffer from a "buffer overflow error", when extremely long e-mail
addresses are received. The internal buffers receiving the addresses do not check for
length and allow their buffers to overflow causing the applications to crash. Hostile hackers
use this fault to trick the computer into running a malicious program in its place.
CIS 068
Why not only code it ?
Software is
• a critically important infrastructure component
• a key enabler
–
–
–
–
militaryly
economically
scientifically
culturally
But usually
• expensive
• of poor quality
CIS 068
Common Software Problems
– Software can cost hundreds or thousands
of dollars per line
– Lifetime maintenance costs are higher still
– Software is late or fails
– Software is not performant (too slow)
– Software is incomprehensible
– Software is more trouble to use than it is
worth
CIS 068
Past Approaches to Solutions
•Use more people
•Create better
programming languages
•Write software tools to
help create software
•Design before writing
•Start by baselining
requirements
•Train people better
•Create more chaos
•Bad programs can be
written in any language
•(who finds the error in
reasoning in here ?)
•Are you designing the
right program ?
•but they change !
•…to do what ?
CIS 068
The Software Crisis
Summary:
Millions are spent for an
incomprehensible tool that comes
late just to cause trouble, and we don’t
have answers
or:
THE SOFTWARE CRISIS
(1968)
CIS 068
History
1968: NATO Software Engineering
Conference in Garmisch (Germany):
Why cannot bridge-building techniques
be used to build operating systems
(‘engineering’) ?
CIS 068
The Nature of Software
• It is a component of a larger system
that “fits” with hardware, people,
mechanical devices
• It transforms data using computers
• It has a complex structure
• It is usually very large, expensive, and
lengthy to build
CIS 068
The Nature of Software
• Software is extremely malleable – we
can modify the product all too easily
• Software construction is humanintensive, there are no real costs of
materials
• Software is intangible: no laws of
physics are applicable
• Software is not detectable by any of
the five human senses
CIS 068
The Nature of Software
But:
The are characteristics analogue to physical
engineering processes
Studying such analogs can be useful:
•
•
•
•
Help us learn about computer software
Find points of similarity
Suggest successful approaches to be emulated
Avoid known mistakes
CIS 068
Engineering Example
Building a house:
System Feasibility
•Land and finances
Software
Plans
and Requirements
•garden, garage,
you are
used
to age wine, enjoy to
sit by the fireplace, lots of storage, don’t like bauhaus
•Architect will define number of floors and rooms,
Productsize
Design
orientation of the driveway,
of the garage …
•type of bricks, colourDetailed
of the walls,…
Design
•Construction
Code
•Entering
Integration (Product Verification)
•Living in the house
Integration (System Test)
•Fixing minor problems, leaking in the roof …
Operations and Maintenance
CIS 068
The Waterfall Model
System Feasibility
Validation
Plans +
Requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Product
Verification
Integration
Didn’t we forget something ?
Operation +
Maintenance
System Test
Revalidation
CIS 068
The Waterfall Model
System Feasibility
Validation
Plans +
Requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Product
Verification
Integration
Operation +
Maintenance
System Test
Revalidation
CIS 068
The Human Factor
User
Programmer‘s view:
• Some (holy) lines of code
• A technical challenge
Programmer
• A pet
• ...
SOFTWARE
Customer
Designer
CIS 068
The Human Factor
User‘s view:
• A miracle
• A wonderful tool making things easier
• An incombprehensible tool
User complicating life
unnecessarilly
• Something that simply should work !
Programmer
SOFTWARE
Customer
Designer
CIS 068
The Human Factor
Programmer
User
SOFTWARE
Designer
Customer
Customer‘s view:
• A hopefully affordable tool to enhance profit.
CIS 068
The Human Factor
Programmer
User
SOFTWARE
Customer
Designer
Designer‘s view:
• A reasonably complicated
tool to fulfill the needs
• A technical challenge
CIS 068
Review of Waterfall Model
Weaknesses:
– Usually requirements change, are
incomplete or even not known
– Communication ! (…see Mars Orbiter…)
Result: ‘That’s not what I meant !’ ( go back
to last step )
WF-Model reacts very statically:
– Each stage must be completed before next
one starts
CIS 068
Total Feedback
System Feasibility
•Too expensive
•Doesn’t force to discipline
•Don’t show this to your boss !
Validation
Plans +
Requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Product
Verification
Integration
Operation +
Maintenance
System Test
Revalidation
CIS 068
The Human Factor
Programmer
User
SOFTWARE
Customer
Designer
CIS 068
The Human Factor
• Usually one person plays multiple roles
• Separation of different roles needs discipline !
CIS 068
The Unified Model
• A tradeoff, unifying different models
• Shows the basic message of different
approaches
CIS 068
The Unified Model
Time
Customer
User
Designer
Activities
Programmer
CIS 068
Models: Review
•There are a lot of models, each with it’s strongand weaknesses
•Keep in mind:
• There is a necessity to manage the workflow
• There are different views of software
• Smaller projects can be managed by the
waterfall model
• Review your programming process, check
which phase you are in
• Play different roles by yourself
• And
NEVER forget the testing !
CIS 068
Software Life Cycle Activities
Independent of how they are organized, the following
activities are involved in the development of software:
CIS 068
Example: The Phone Directory
Example will show activities:
• Requirements
• Analysis
• Design
• Implementation
CIS 068
Phone Directory: Requirements
Phone Directory:
• Interactive Program containing
collection of names and phonenumbers
• Insert new entries
• Retrieve entries
• Change Entries
CIS 068
Phone Directory: Detailed Req’s
•
•
•
•
•
•
•
•
•
•
•
Import existing data ?
Read from file or enter interactively
If file: file-type ?
If text-file: comma separated ?
Final directory: filetype spec’s ?
Limited namelength ?
Numbers as string ?
Order alphabetically ?
Printout required ?
Double entries possible ?
…
CIS 068
Phone Directory: Analysis
Requirement – related:
• Cluster requirements to different levels of
detail
• Understand ALL requirements
• Explore EVERY uncertainty
CIS 068
Phone Directory: Analysis
Implementation-strategy:
•
•
•
•
•
•
Use commercial software ?
Design specific or reusable software ?
Outsource different tasks (if specified) ?
Which language ?
Impact on existing software-packages ?
…
CIS 068
Phone Directory: Analysis
High level design:
• Again: make sure you understand the
problem !
• Different methodologies:
• Top Down Design
• Object Oriented Approach
CIS 068
Analysis: Top Down Design
Stepwise Refinement,
Divide and Conquer
• Start at top level
• Divide into subproblems
• For each subproblem:
• Divide into subproblems, solving the
higher level problem
CIS 068
Analysis: Top Down Design
Structure chart, indicating the relationship
CIS 068
Analysis: Top Down Design
Refinement
CIS 068
Analysis: Top Down Design
Refinement
CIS 068
Analysis: Top Down Design
Question:
When should we stop the refinement ?
Answer:
Each subproblem should be RESPONSIBLE
for exactly ONE activity
(…in it’s description, there’s no AND)
CIS 068
How to go on ?
What happens if proceeding with
refinement, e.g. going down to flowchart ?
• the problem description then will focus on
PROCEDURES
• Definition of data structures ?
This is a major problem in procedural driven
design !
Alternative: Object Oriented Design
CIS 068
Object Oriented Design
1. Identify objects participating in the system
• Look at nouns in the problem statement
to identify objects:
…create phone directory …containing entries… read
from/write to file… interact with user …
Objects:
• Directory
• Entry
• File
• User
CIS 068
Object Oriented Design
2. Identify INTERACTIONS between objects
• Messages between objects
• Look at verbs in the problem statement
to identify interactions:
…create phone directory …containing entries… read
from/write to file… interact with user …
• Messages must be processed by
object’s methods
CIS 068
Object Oriented Design
Class Diagram for Phone Book Example:
Defined by UML (Unified Modeling Language)
CIS 068
Object Oriented Design
Class Diagram for Phone Book Example:
Actor
Class
Aggregation (“part of”)
Navigability: Source Target
Defined by UML (Unified Modeling Language)
CIS 068
Use Cases
Definition:
Use Case = Closed loop interaction with the
user
The refinement process of the top down approach
is replaced by listing all use cases, or: “write down
everything the system is supposed to do”
CIS 068
Use Cases
Use Cases for phone book example:
The program must be able to:
• load initial directory from file
• insert new entry or change existing one
• retrieve and display entry
• save modified directory back to file
• exit
CIS 068
Use Cases
Detailed Description ( 1 of 5):
CIS 068
Use Cases
Detailed Description ( 2 of 5):
CIS 068
Use Cases
Detailed Description ( 3 of 5):
CIS 068
Use Cases
Detailed Description ( 4 of 5):
CIS 068
Use Cases
Detailed Description ( 5 of 5):
CIS 068
Use Cases
Compare Use Cases to results of refinement
• of course they seem similar (this is a simple example !)
• refinement didn’t contain any data-structure related
information
• Use Cases contain messages, these messages contain
implicit information about data
• Use Cases and objects do not need explicit information
about data
• Data structures should even be hidden to other classes !
CIS 068
Abstraction
Definition:
Abstraction = process of separating inherent
qualities or properties of something from the
actual physical representation.
• Procedural Abstraction
• separate what a procedure does from how it is done
• Data Abstraction
• describe what information is stored, not how
• logical view instead of physical view
CIS 068
Abstraction
Leads to Information Hiding:
Abstract data types are only defined by their
methods, the actual implementation is hidden.
Advantage:
•separation of definition and
implementation
•Maintenance simplification
Data protected by methods
CIS 068
Abstraction
• JAVA interfaces define Abstract Data
Types.
• Specification of names, parameters,
return values
• No implementation in interfaces but in
classes
CIS 068
(The following slides differ from the Textbook)
CIS 068
Sequence Diagrams
The class structure redefined:
CIS 068
Sequence Diagrams
Each Use Case corresponds to a
Sequence Diagram
• shows the flow of messages between
classes
• defined by UML standard
CIS 068
Use Cases
Again: Use Case 1
CIS 068
Sequence Diagrams
Sequence Diagram of Use Case 1:
Load data from file
CIS 068
Sequence Diagrams
Sequence Diagram of Use Case 1:
actor
object
Load data from file
Object’s Lifeline:
active / inactive
self call
message
CIS 068
Use Cases
Again: Use Case 2
CIS 068
Sequence Diagrams
Sequence Diagram of Use Case 2:
Insert / change entry
CIS 068
Use Cases
Again: Use Case 3:
CIS 068
Sequence Diagrams
Sequence Diagram of Use Case 3:
Retrieve and Display entry
CIS 068
From Diagrams to Objects
Remind:
• all messages must be processed by object’s
method
• the message-processing requires data types
• the messages received and sending from an
object in all use cases define the object’s methods
explicitely
• data structures for implementation are defined by
the needs of methods, hidden to other objects
• the objects are defined by collecting all
messages for/from each object
CIS 068
From Diagrams to Objects
Collect all messages to define object’s methods !
Phone
Directory
CIS 068
Review
reasons for thinking about software
software 'engineering'
different views of software
software life cycle models
waterfall model
unified model
phone directory example:
requirements
analysis
top down (divide and conquer)
object oriented
use cases
abstraction
sequence diagrams to objects
CIS 068
Good Bye !
CIS 068