Slide 1: CIS 068 Welcome to CIS 068 ! Lesson 2:
Why not only code it ? Slide 2: CIS 068 Why not only code it ? : CIS 068 Why not only code it ? Which event happens more frequently ?
Which is deadlier ? Why not only code it ? : 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) Why not only code it ? : 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. Why not only code it ? : 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. Why not only code it ? : 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. Why not only code it ? : CIS 068 Why not only code it ? Software is
a critically important infrastructure component
a key enabler
of poor quality Common Software Problems : 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 Past Approaches to Solutions : 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 ? The Software Crisis : CIS 068 The Software Crisis Summary: Millions are spent for an
incomprehensible tool that comes
late just to cause trouble, and we don’t
THE SOFTWARE CRISIS
(1968) History : CIS 068 History 1968: NATO Software Engineering Conference in Garmisch (Germany):
Why cannot bridge-building techniques be used to build operating systems
(‘engineering’) ? The Nature of Software : 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 The Nature of Software : CIS 068 The Nature of Software Software is extremely malleable – we can modify the product all too easily
• Software construction is human-intensive, 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 The Nature of Software : 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 Engineering Example : CIS 068 Engineering Example Building a house:
Land and finances
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, orientation of the driveway, size of the garage …
type of bricks, colour of the walls,…
Living in the house
Fixing minor problems, leaking in the roof … System Feasibility Software Plans and Requirements Product Design Detailed Design Code Integration (Product Verification) Integration (System Test) Operations and Maintenance The Waterfall Model : CIS 068 The Waterfall Model System Feasibility Validation Plans +
Requirements Validation Product Design Verification Detailed Design Verification Code Unit Test Integration Product Verification Integration System Test Operation + Maintenance Revalidation Didn’t we forget something ? The Waterfall Model : CIS 068 The Waterfall Model System Feasibility Validation Plans +
Requirements Validation Product Design Verification Detailed Design Verification Code Unit Test Integration Product Verification Integration System Test Operation + Maintenance Revalidation Slide 19: CIS 068 User SOFTWARE Customer Programmer Designer The Human Factor Slide 20: CIS 068 User Programmer SOFTWARE Customer Designer Programmer‘s view:
Some (holy) lines of code
A technical challenge
... The Human Factor Slide 21: CIS 068 User Programmer SOFTWARE Customer Designer User‘s view:
A wonderful tool making things easier
An incombprehensible tool
unnecessarilly complicating life
Something that simply should work ! The Human Factor Slide 22: CIS 068 User Programmer SOFTWARE Customer Designer Customer‘s view:
A hopefully affordable tool to enhance profit. The Human Factor Slide 23: CIS 068 User Programmer SOFTWARE Customer Designer Designer‘s view:
A reasonably complicated
tool to fulfill the needs
A technical challenge The Human Factor The Human Factor : CIS 068 The Human Factor Usually one person plays multiple roles
Separation of different roles needs discipline ! Slide 25: 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 Slide 26: CIS 068 Total Feedback System Feasibility Validation Plans +
Requirements Validation Product Design Verification Detailed Design Verification Code Unit Test Integration Product Verification Integration System Test Operation + Maintenance Revalidation Too expensive
Doesn’t force to discipline
Don’t show this to your boss ! Slide 27: CIS 068 The Unified Model A tradeoff, unifying different models
Shows the basic message of different approaches Slide 28: CIS 068 The Unified Model Time Activities Customer User Designer Programmer Models: Review : CIS 068 Models: Review There are a lot of models, each with it’s strong- and 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 ! Software Life Cycle Activities : CIS 068 Software Life Cycle Activities Independent of how they are organized, the following activities are involved in the development of software: Example: The Phone Directory : CIS 068 Example: The Phone Directory Example will show activities:
Implementation Phone Directory: Requirements : CIS 068 Phone Directory: Requirements Phone Directory:
Interactive Program containing collection of names and phone-numbers
Insert new entries
Change Entries Phone Directory: Detailed Req’s : 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 ?
… Phone Directory: Analysis : CIS 068 Phone Directory: Analysis Requirement – related:
Cluster requirements to different levels of detail
Understand ALL requirements
Explore EVERY uncertainty Phone Directory: Analysis : 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 ?
… Phone Directory: Analysis : CIS 068 Phone Directory: Analysis High level design:
Again: make sure you understand the problem !
Top Down Design
Object Oriented Approach Analysis: Top Down Design : 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 Analysis: Top Down Design : CIS 068 Analysis: Top Down Design Structure chart, indicating the relationship Analysis: Top Down Design : CIS 068 Analysis: Top Down Design Refinement Analysis: Top Down Design : CIS 068 Analysis: Top Down Design Refinement Analysis: Top Down Design : 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) How to go on ? : 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 Object Oriented Design : CIS 068 Object Oriented Design 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 …
User Object Oriented Design : 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 Object Oriented Design : CIS 068 Object Oriented Design Class Diagram for Phone Book Example:
Defined by UML (Unified Modeling Language) Object Oriented Design : CIS 068 Object Oriented Design Class Diagram for Phone Book Example:
Defined by UML (Unified Modeling Language) Actor Class Aggregation (“part of”) Navigability: Source Target Abstraction : CIS 068 Abstraction Definition:
Abstraction = process of separating inherent
qualities or properties of something from the
actual physical representation.
separate what a procedure does from how it is done
describe what information is stored, not how
logical view instead of physical view Abstraction : CIS 068 Abstraction Leads to Information Hiding:
Abstract data types are only defined by their
methods, the actual implementation is hidden.
separation of definition and
Data protected by methods Abstraction : CIS 068 Abstraction JAVA interfaces define Abstract Data Types.
Specification of names, parameters, return values
No implementation in interfaces but in classes Use Cases : 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” Use Cases : 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 Use Cases : CIS 068 Use Cases Detailed Description ( 1 of 5): Use Cases : CIS 068 Use Cases Detailed Description ( 2 of 5): Use Cases : CIS 068 Use Cases Detailed Description ( 3 of 5): Use Cases : CIS 068 Use Cases Detailed Description ( 4 of 5): Use Cases : CIS 068 Use Cases Detailed Description ( 5 of 5): Use Cases : 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
Use Cases contain messages, these messages contain
implicit information about data
Use Cases and objects do not need explicit information
Data structures should even be hidden to other classes ! Use Cases : CIS 068 Use Cases (The following slides differ from the Textbook) Abstraction : CIS 068 Abstraction The class structure redefined: Sequence Diagrams : CIS 068 Sequence Diagrams Each Use Case corresponds to a
shows the flow of messages between classes
defined by UML standard Use Cases : CIS 068 Use Cases Again: Use Case 1 Sequence Diagrams : CIS 068 Sequence Diagrams Sequence Diagram of Use Case 1:
Load data from file Sequence Diagrams : CIS 068 Sequence Diagrams Sequence Diagram of Use Case 1:
Load data from file actor object Object’s Lifeline:
active / inactive message self call Use Cases : CIS 068 Use Cases Again: Use Case 2 Sequence Diagrams : CIS 068 Sequence Diagrams Sequence Diagram of Use Case 2:
Insert / change entry Use Cases : CIS 068 Use Cases Again: Use Case 3: Sequence Diagrams : CIS 068 Sequence Diagrams Sequence Diagram of Use Case 3:
Retrieve and Display entry From Diagrams to Objects : 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 From Diagrams to Objects : CIS 068 From Diagrams to Objects Collect all messages to define object’s methods ! Phone Directory Review : CIS 068 Review reasons for thinking about software
different views of software
software life cycle models
phone directory example:
top down (divide and conquer)
sequence diagrams to objects Good Bye ! : CIS 068 Good Bye !