1. Welcome to CIS 068 ! Lesson 2: Software Engineering or
Why not only code it ?
CIS 068

2. CIS 068

3. Which event happens more frequently ?
Why not only code it ?
Which event happens more frequently ?
Which is deadlier ?
CIS 068

4. Why not only code it ? Famous Software Failures Therac-25 (1985-1987)
Six people were overexposed during radiation treatments for cancer by Canada's Therac-25 radiation therapy machine.  Three patients believed to have died from the overdoses. 
London Ambulance System (1992)
A succession of software engineering failures, especially in project management, caused 2 failures of London's (England) Ambulance dispatch system.  The repair cost was estimated at £9m, but it is believed that people died who would not have died if ambulances had reached them as promptly as they would have done without the failures.
AT&T long distance service fails for nine hours (Wrong BREAK statement in C-Code, 1990)
Shooting Down of Airbus 320 (1988)
US Vicennes shot down Airbus 320 mistaken for an F-14, 290 people dead.
Software bug: cryptic and misleading output displayed by the tracking software
CIS 068

5. 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.
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.
buffer overflow (1998)
Several systems suffer from a "buffer overflow error", when extremely long 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

6. Why not only code it ? Software is But usually
a critically important infrastructure component
a key enabler
militaryly
economically
scientifically
culturally
But usually
expensive
of poor quality
CIS 068

7. 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

8. Past Approaches to Solutions
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 ?
Use more people
Create better programming languages
Write software tools to help create software
Design before writing
Start by baselining requirements
Train people better
CIS 068

9. 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

10. 1968: NATO Software Engineering Conference in Garmisch (Germany):
History
1968: NATO Software Engineering Conference in Garmisch (Germany):
Why cannot bridge-building techniques be used to build operating systems
(‘engineering’) ?
CIS 068

11. 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

12. 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
• Software application horizons expand too fast--with human demands/imagination
• Software problems are unprecedentedly complex (a machine with millions of moving parts)
• Software solutions require unusual rigor
• Software has a discontinuous operational nature
CIS 068

13. The are characteristics analogue to physical engineering processes
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

14. 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,…
Construction
Entering
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
CIS 068

15. Didn’t we forget something ?
The Waterfall Model
System Feasibility
Validation
Plans +
Requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Product Verification
Integration
System Test
Didn’t we forget something ?
Operation + Maintenance
Revalidation
CIS 068

16. The Waterfall Model CIS 068 System Feasibility Validation Plans +
Requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Product Verification
Integration
System Test
Operation + Maintenance
Revalidation
CIS 068

17. The Human Factor
Programmer
User
SOFTWARE
Customer
Designer
CIS 068

18. The Human Factor Programmer‘s view: Some (holy) lines of code
A technical challenge
A pet
...
Programmer
User
SOFTWARE
Customer
Designer
CIS 068

19. The Human Factor User‘s view: A miracle
A wonderful tool making things easier
An incombprehensible tool
unnecessarilly complicating life
Something that simply should work !
Programmer
User
SOFTWARE
Customer
Designer
CIS 068

20. The Human Factor Programmer User SOFTWARE Customer Designer
Customer‘s view:
A hopefully affordable tool to enhance profit.
CIS 068

21. The Human Factor Programmer User SOFTWARE Customer Designer
Designer‘s view:
A reasonably complicated
tool to fulfill the needs
A technical challenge
CIS 068

22. The Human Factor Usually one person plays multiple roles
Separation of different roles needs discipline !
CIS 068

23. 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

24. Total Feedback Too expensive Doesn’t force to discipline
System Feasibility
Validation
Too expensive
Doesn’t force to discipline
Don’t show this to your boss !
Plans +
Requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Product Verification
Integration
System Test
Operation + Maintenance
Revalidation
CIS 068

25. The Unified Model A tradeoff, unifying different models
Shows the basic message of different approaches
CIS 068

26. The Unified Model Time Activities User Customer Designer Programmer
CIS 068

27. And NEVER forget the testing !
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 !
CIS 068

28. Software Life Cycle Activities
Independent of how they are organized, the following activities are involved in the development of software:
CIS 068

29. Example: The Phone Directory
Example will show activities:
Requirements
Analysis
Design
Implementation
CIS 068

30. Phone Directory: Requirements
Interactive Program containing collection of names and phone-numbers
Insert new entries
Retrieve entries
Change Entries
CIS 068

31. 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

32. Phone Directory: Analysis
Requirement – related:
Cluster requirements to different levels of detail
Understand ALL requirements
Explore EVERY uncertainty
CIS 068

33. 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

34. Phone Directory: Analysis
High level design:
Again: make sure you understand the problem !
Different methodologies:
Top Down Design
Object Oriented Approach
CIS 068

35. 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

36. Analysis: Top Down Design
Structure chart, indicating the relationship
CIS 068

37. Analysis: Top Down Design
Refinement
CIS 068

38. Analysis: Top Down Design
Refinement
CIS 068

39. 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

40. 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

41. 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 …
Objects:
Directory
Entry
File
User
CIS 068

42. 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

43. Object Oriented Design
Class Diagram for Phone Book Example:
Defined by UML (Unified Modeling Language)
CIS 068

44. Object Oriented Design
Class Diagram for Phone Book Example:
Defined by UML (Unified Modeling Language)
Actor
Class
Aggregation (“part of”)
Navigability: Source Target
CIS 068

45. Use Case = Closed loop interaction with the user
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

46. 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

47. Detailed Description ( 1 of 5):
Use Cases
Detailed Description ( 1 of 5):
CIS 068

48. Detailed Description ( 2 of 5):
Use Cases
Detailed Description ( 2 of 5):
CIS 068

49. Detailed Description ( 3 of 5):
Use Cases
Detailed Description ( 3 of 5):
CIS 068

50. Detailed Description ( 4 of 5):
Use Cases
Detailed Description ( 4 of 5):
CIS 068

51. Detailed Description ( 5 of 5):
Use Cases
Detailed Description ( 5 of 5):
CIS 068

52. 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

53. … will be continued, let’s first talk
Use Cases
… will be continued, let’s first talk
about abstraction !
CIS 068

54. 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

55. 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

56. Abstraction JAVA interfaces define Abstract Data Types.
Specification of names, parameters, return values
No implementation in interfaces but in classes
CIS 068

57. Abstraction Proceeding with the phone book example
choose language (here JAVA)
look for possible data structures
found: interface map for directory entry
if needed: redesign objects or class structure
we’re still in an analysis – phase, so a redefinition of classes is not only possible but usual !
CIS 068

58. Abstraction
The class structure redefined:
CIS 068

59. Use Cases continued …back to Use Cases !
The use cases didn’t change, their description is independent from objects !
Here they are again:
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

60. Each Use Case corresponds to a
Sequence Diagrams
Each Use Case corresponds to a
Sequence Diagram
shows the flow of messages between classes
defined by UML standard
CIS 068

61. Sequence Diagram of Use Case 1:
Sequence Diagrams
Sequence Diagram of Use Case 1:
Load data from file
CIS 068

62. Sequence Diagram of Use Case 1:
Sequence Diagrams
Sequence Diagram of Use Case 1:
Load data from file
actor
object
Object’s Lifeline:
active / inactive
self call
message
CIS 068

63. Sequence Diagram of Use Case 2:
Sequence Diagrams
Sequence Diagram of Use Case 2:
Insert / change entry
CIS 068

64. Sequence Diagrams Sequence Diagram of Use Case 3:
Retrieve and lookup entry
CIS 068

65. 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

66. From Diagrams to Objects
Collect all messages to define object’s methods !
Phone Directory
CIS 068

67. 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

68. Review
SO WHY NOT ONLY CODE IT ?
CIS 068

69. Good Bye !
For details and implementation of the example refer to textbook:
Software Design & Data Structures in Java By
Elliot B. Koffman + Paul A. T. Wolfgang
most of the figures of the previous slides were taken from this book
CIS 068