Software engineering for computer science

softear engineering

1. CIS 068
Software Engineering
or
Why not only code it ?

2. CIS 068

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

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

5. CIS 068
Why not only code it ?
Famous Software Failures cont’d:
•Mars Climate Orbiter (September 23
rd
, 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.

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

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

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

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

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

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

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

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

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

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

16. 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,…
•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

17. 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
RevalidationDidn’t we forget something ?

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

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

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

21. CIS 068
User
Programmer
SOFTWARE
Customer Designer
Customer‘s view:
• A hopefully affordable tool to enhance profit.

The Human Factor

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

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

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

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

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

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

28. CIS 068
The Unified Model
Time
A
c
t
iv
it
ie
s
Customer
User
Designer
Programmer

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

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

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

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

33. 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 ?
•…

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

35. 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 ?
•…

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

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

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

39. CIS 068
Analysis: Top Down Design
Refinement

40. CIS 068
Analysis: Top Down Design
Refinement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

58. CIS 068
(The following slides differ from the Textbook)

59. CIS 068
Sequence Diagrams
The class structure redefined:

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

61. CIS 068
Use Cases
Again: Use Case 1

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

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

64. CIS 068
Use Cases
Again: Use Case 2

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

66. CIS 068
Use Cases
Again: Use Case 3:

67. CIS 068
Sequence Diagrams
Sequence Diagram of Use Case 3:
Retrieve and Display entry

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

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

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

71. CIS 068
Good Bye !