Slide 1:CIS 068 Welcome to CIS 068 ! Lesson 2: Software Engineering or 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 militaryly economically scientifically culturally But usually expensive 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 have answers or: 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,… 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


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 A pet ... The Human Factor


Slide 21: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


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: Requirements Analysis Design Implementation


Phone Directory: Requirements :CIS 068 Phone Directory: Requirements Phone Directory: Interactive Program containing collection of names and phone-numbers Insert new entries Retrieve 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 ! Different methodologies: 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 … Objects: Directory Entry File 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. 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


Abstraction :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


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


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 Sequence Diagram 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 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


Good Bye ! :CIS 068 Good Bye !