1. Software Engineering, CSC- 221 1

2. 2 Software Engineering Teaching  Lectures: Sunday, Tuesday, Thursday 10-11

3. 3 Course Teaching You are encouraged to attend to all lectures, tutorials, and so on. You are encouraged to ask questions. You are encouraged to offer answers.

4. 4 Consultation and Recommended Books Recommended books:  Mark Priestley: Practical Object-Oriented Design with UML, McGraw Hill, 2004  Ian Sommerville: Software Engineering, Pearson – Addison Wesley, 7 th Edition, 2004  Craig Larman: Applying UML and Patterns, Pearson – Prentice Hall, 2005  Robert Binder: Testing Object-Oriented Systems, Addison Wesley, 2000

5. 5 Overview of This Course Software Development Process Modelling with Objects  Analysis Model Analysis Model  Use Case Modelling Use Case Modelling  Analysis Class Modelling Analysis Class Modelling  Object States Object States Design Model  Design Class Modelling Design Class Modelling  Object Interactions Object Interactions Implementation Issues Testing and Integration Design Patterns Software Life Cycle Models / Methodologies

6. 6 Tutorials Objectives Purposes  for self-assessment  use material from lectures  answer questions  help deep understanding  prepare projects  save your time!

7. 7 Students are given a problem specification  Vague, misleading, ambiguous, conflicting It has two parts:  Report (i) Sort out what to do - analyse (ii) Sort out how to do it - design  Demonstration (i) Do it ! - code (ii) Verify - test Group size is 3 or 4. Strict deadline – the last week of teaching. The Project

8. 8 Recommendations For CSC 221  Walkthrough the software development process: Lectures give the theory background; Tutorials allow you to explore the theory; Project gives the opportunity to apply what you have learned;  Best way to appreciate the course: Read up relevant topics; Attend the lectures and tutorials; Do the relevant part for the project right after.

9. 9 Lecture Structure Reminder of last lecture Overview Content (new notions + examples) Summary Reading suggestions Coming up next

10. 10 Overview of This Lecture Overview of Software Engineering  SE definitions  Quality of Good Software Overview of Software Process  Activities and associated stages Overview of Software Engineering Method  Structured Analysis  Object-Oriented Method

11. 11 What is ‘Software Engineering’?... A term used occasionally in 1950s, 1960s Popularized in 1968 at NATO Software Engineering Conference (http://homepages.cs.ncl.ac.uk/brian.randell/NATO/)http://homepages.cs.ncl.ac.uk/brian.randell/NATO/

12. 12 What is Software? More than computer programs. The collection of programs, documentation and configuration data that ensures correct execution. Three major types:  Generic Product: Stand alone, Sold on open market.  Customized Product: For specific customer.  Embedded Product: Built into hardware.

13. 13 The Nature of Software Intangible:  Opposite of physical artifacts, e.g., Computer vs Windows XP  Hard to understand the development process. Easy to Reproduce:  Costly design and construction, cheap manufacturing. Malleable (طيع):  Easy to change, even without full understanding.  Untrained people can “hack” something together.

14. 14 Software Development Problems “Software is not constrained by materials, or governed by physical laws, or by manufacturing process” ---- (Sommerville, Software Engineering) Allows almost unbounded complexity:  Exponential growth of complexity w.r.t. to the size of a program: twice the size, four times the complexity;  Example: Windows XP has 40millions lines of source code (estimation).

15. 15 Software Development Problems Difficulty in understanding and managing the complexity causes:  Late completion: “vaporware” that are announced but never produced  Overrunning Cost: Denver Airport Automated Baggage System, 2 billions US dollar over budget  Unreliable  Difficult to maintain  Etc…

16. 16 Famous Software Disaster كارثة Ariane 5 expendable launch system:  Spacecraft launching system improved from Ariane 4. First test flight took place on June 4, 1996.

17. 17 Famous Software Disaster (cont) US $5 hundred millions worth of payload destroyed. Reason:  Main Navigation Computer crashes after 37 seconds.  Caused by a conversion overflow: converting floating point number to integer number.  Reuse of specification of Ariane 4 without taking into consideration the new capability.

18. 18 More Software Disasters Denver Airport Automated Baggage System. Therac-25: Massive overdose of radiation. Link to History's Worst Software Bug: http://wired.com/news/technology/bugs/0,69355-1.html?tw=wn_story_page_next1 http://wired.com/news/technology/bugs/0,69355-1.html?tw=wn_story_page_next1 http://www.comlab.ox.ac.uk/archive/safety.html http://www.csl.sri.com/risks.html

19. 19 What is Engineering? Systematically identify, understand, and integrate the constraints on a design to produce a successful result. Constraints may include:  available resources,  physical or technical limitations,  flexibility for future modifications and additions,  cost, manufacturability, and serviceability. Deduce specifications from the limits. Ethical Practices.

20. 20 Quality of Good Software Usability  Easy to learn and use. Efficiency  Does not waste resources such as CPU time and memory. Dependability  Reliable, secure and safe. Maintainability  Easily evolved (modified) to meet changing requirement. Reusability  Parts can be reused, with minor or no modification.

21. 21 Quality of Good Software Can be quite different based on your viewpoint: Customer: - Solves problems at acceptable cost (time and resource). Developer: - Easy to design and maintain User: - Easy to learn - Efficient to use - Get work done Developer Manager: - Sells more and pleases customers - Costing less to develop and maintain

22. 22 So, ‘Software Engineering’ is IEEE Standard 610.12: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software. “Designing, building and maintaining large software systems”. - I. Sommerville “Multi-person construction of multi-version software”. - D. L. Parnas

23. 23 What is Software Engineering?... “Technological and managerial discipline of software products that are developed and modified on time and within cost estimates”. – R. Fairley “Software development is not simply a case of sitting down at a terminal and typing in the program code”. – M. Priestley A discipline that guides the process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints. – our definition

24. 24 Software Engineering Myths ( اسطورة )  A general statement of objectives is sufficient to begin writing programs - we can fill in the details later.  Poor Up-front definition is the major cause of failed software efforts.  If we get behind schedule, we can add more programmers and catch up.  Brooks Law: “Adding people to a late project makes it later.”

25. 25 Software Engineering Myths Project requirements continually change, but change can be easily accommodated because software is flexible. Cost Impact Severe Moderate Minor PlanningDesignImplementation Occurrence of Change

26. 26 Software Process The steps involved in creating a software system  Software Process. The guideline or overall principle used during the Software Process  Software Engineering Method.

27. 27 Software Process The set of activities and associated results that produce a software product. Four fundamental process activities:  Software Specification  Software Development  Software Validation  Software Evolution Can be organized in different ways, described at varying level of details → different software development process models (lecture 2).

28. 28 Activity 1: Software Specification Customers and Software Engineers  Define the software to be produced  Define the constraints on its operations Typical Stages:  Feasibility Study: Is it possible with the current technologies + within budget?  Domain Analysis: What is the background for the software?  Requirements Gathering and Analysis: What is it that the user wants?  Requirements Specification: Formal documentation on User and System requirements.  Requirements Validation: Check for realism, consistency, and completeness.

29. 29 Activity 2: Software Development Consists of Design and Programming System Analysts  Design: decide how the requirement can be implemented. Programmers  Coding: translate high level design into real code in a chosen programming language.

30. 30 Activity 2: Software Development Typical Stages (Design):  Architectural Design: Split into subsystems  Abstract Specification: High level specification on the services and constraints for each subsystem  Interface Design: Interface with other subsystems are defined  Component Design: Split the services and allocate to components within a subsystem  Data Structure Design: Choose appropriate data structure  Algorithm Design: Design and specify algorithm used to provide services High Level Low Level

31. 31 Activity 2: Software Development Typical Stages (Programming):  Data structure and algorithm design (from the design stage) may be delegated to the programmer.  Personal activity. Usually without a predefined process.  Debugging: Low level testing of code. Reveals program defects (bugs).

32. 32 Activity 3: Software Validation Software Engineer (or dedicated tester) and Customer:  Check the software to ensure it meets the customers’ requirements. Typical Stages:  Component Testing: Independent testing of individual components in subsystem.  System Testing: Testing of integrated components. Can be multi-levels, e.g., subsystem → system.  Acceptance Testing: Tested with customer supplied data. Final test before operation. Interactive activity that feedback to previous stages:  E.g., an error in component testing triggers re-coding.

33. 33 Activity 4: Software Evolution Customers and Software Engineers:  Define changing requirements.  Modify the software system to adapt. Typical Work:  Update the system for minor new requirements, e.g., changing the telephone number from 7 digits to 8 digits, changing the date representation (the Millennium Bug).  Could be drastic, more like redevelopment, e.g., windows95 →windows98 → windowsXP.

34. 34 Simple Software Process Example In the simplest cases, code is written directly from some statements of requirements. Process Artifact

35. 35 Simple Software Process Example  Two processes:  ‘Analyze requirements’  ‘Write code’  Two artifacts:  ‘Requirements specification’  ‘Source code’  ‘Requirements specification’ can be written as:  an informal outline or  a highly detailed description.

36. 36 Simple Software Process Example Software Specification:  Analyze Requirement → Requirement Documentation Software Development:  Design: Data structure and algorithm  Programming: Write Code → Source Code Debugging Software Validation:  Compare against sample outputs Software Evolution:  Not applicable.

37. 37 A More Complex Software Process It is better to design before you code.  On larger projects, intermediate pieces of documentation are produced.

38. 38 A More Complex Software Process  One new process:  ‘Design module structure’ - splitting the program into modules and subroutines  One new artifact:  ‘Structure chart’ – is based on the information contained in the ‘requirements specification’  Both the ‘requirements specification’ and the ‘structure chart’ are used when writing the final code.

39. 39 A More Complex Software Process Software Specification:  Analyze Requirement → Requirement Documentation Software Development:  Design: Structure Chart of the functions/modules/classes  Programming: Write Code → Source Code Debugging Software Validation:  Compare against sample outputs Software Evolution:  Not applicable.

40. 40 Modeling the System The structure chart is an example of system model. A powerful and useful technique. Give abstract view of the actual system  Usually in graphical notation  Easier to understand  Easier to manipulate The semantic, usage and notation used in modeling is part of Software Engineering Method, described next.

41. 41 Software Engineering Method A strategy for successfully developing software. A guiding principle throughout the Software Process. Based on the idea of developing graphical models (abstract representation) of a system, which can be used as specification or design. No best method: depends on type of system. Two popular methods are described next.

42. 42 Structured Analysis One of the earliest methods, developed in 1970s. Essence:  Function Oriented: Identify process (function) that transform data.  Good match for procedural languages like C, Pascal, Fortran, etc. Example (Data Flow Diagram - DFD): Push Value on to Stack Stack New Value Stack with New Value

43. 43 Structured (Procedural) Methods Structured methods = structured analysis and structured design. Characteristic model = data flow diagram (description of the system’s data and how the data interact with the system). Structured methods refer to software systems where data are processed by functions external to data. In other words, the system’s data are stored in one place, and functions (operations) are essentially separated by the data. Structured methods are appropriate for the design of data-rich systems (e.g., relational databases).

44. 44 Object-Oriented Methods Recently developed in 1990s. Essence:  Object-Oriented: Identify entity (object) that contains natural collection of both data and the process (function) that operates on them.  Good match for OO languages like C++, JAVA, SmallTalk, etc. Example (UML Class Diagram): Stack - Items: Integer[ ] +push(value: integer)

45. 45 Object-Oriented Methods Most operations in real-world only use a small fraction of the total data of the system, and most pieces of data will be accessed by a small number of operations. So, there was a need to split the data repository and integrate pieces of data with the operations that directly manipulate those data = object-oriented approaches. Example: scanners and printers are (in) separate (rooms), as they provide different operations.

46. 46 Structured and Object-Oriented Methods: Comparison Compared with structured approaches, in the object- oriented approaches the operations are localized together with the data that they affect, instead of being part of a large and global structure. Programs using object-oriented structures are easy to understand and maintain (incremental software development). In the structured approach, each operation has the responsibility of choosing the necessary data from the central repository (i.e., global place where the data is stored).

47. 47 What’s in CSC-221? Subsequent lectures resemble a walkthrough of the software development process using Object-Oriented Method. Software Specification -Domain Analysis -Requirements Gathering and Analysis -Requirements Specification -Requirements Validation -Feasibility Study Software Development -Architectural Design -Abstract Specification -Interface Design -Component Design -Data Structure Design -Algorithm Design Software Validation -Component Testing -System Testing -Acceptance Testing Software Evolution -Maintenance -Redevelopment Those in Bold Font will be covered by lectures and project.

48. 48 Thank you for your attention! Questions?