1. 9/21/2015CPSC-4360-01, CPSC-5360-01, Lecture 11 Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 1 Stefan Andrei

2. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 2 Software Engineering CPSC-4360-01 and CPSC-5360-01 are 3 credits points modules:  Midterm exam (Monday, March 14, 10:00am): 20%  CPSC-4360-01 : Project: 30% (10% - Analysis & Design – Report, 20% - Implementation & Test – Demonstration)  CPSC-5360-01 : Project: 15% (5% - Analysis & Design – Report, 10% - Implementation & Test – Demonstration) Paper Presentation: 15%  Written final exam (May 9, 11:00am-1:30pm): 50%

3. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 3 Software Engineering Module homepage  http://galaxy.lamar.edu/~sandrei/CPSC-4360-01/ http://galaxy.lamar.edu/~sandrei/CPSC-4360-01/ Teaching  Lectures: Monday, Wednesday, Friday, 10:10-11:00, MA111

4. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 4 Course Etiquette Code of conduct  no copying  for details, see webpage You are encouraged to attend to all lectures, tutorials, and so on. You are encouraged to ask questions. You are encouraged to offer answers.

5. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 5 Consultation and Recommended Books Dr. Stefan Andrei, sandrei@cs.lamar.edu (please send an email to make an appointment - MA2, #69)sandrei@cs.lamar.edu Lectures based of the book (chapters available at the course website):  Bimlesh Wadhwa, Stefan Andrei, Soo Yuen Jien. Software Engineering: An object-oriented approach. McGraw Hill, 2007, ISBN: 978-007-126610-9 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

6. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 6 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

7. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 7 Tutorials Objectives Purposes  for self-assessment  use material from lectures  answer questions  help deep understanding  prepare projects  save your time!

8. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 8 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

9. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 9 Recommendations For CPSC-4360-01 and CPSC-5360-01:  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; Furthermore, CPSC-5360-01 students need to present a research paper presentation.  Best way to appreciate the course: Read up relevant topics; Attend the lectures and tutorials; Do the relevant part for the project right after.

10. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 10 Useful Software Pre-requisites software:  Java Programming Language (http://java.sun.com/).http://java.sun.com/ Recommended software:  ArgoUML ( http://argouml.tigris.org/) is a UML design tool with cognitive support, released on September, 2003; http://argouml.tigris.org/  JUnit (http://junit.sourceforge.net/) is a simple framework to write repeatable tests, released on August, 2002.http://junit.sourceforge.net/

11. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 11 Lecture Structure Reminder of last lecture Overview Content (new notions + examples) Summary Reading suggestions Coming up next

12. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 12 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

13. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 13 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/

14. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 14 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.

15. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 15 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.

16. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 16 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).

17. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 17 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…

18. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 18 Famous Software Disaster Ariane 5 expendable launch system:  Spacecraft launching system improved from Ariane 4. First test flight took place on June 4, 1996.

19. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 19 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.

20. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 20 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

21. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 21 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.

22. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 22 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.

23. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 23 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

24. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 24 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

25. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 25 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

26. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 26 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.”

27. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 27 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

28. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 28 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.

29. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 29 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).

30. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 30 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.

31. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 31 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.

32. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 32 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

33. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 33 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).

34. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 34 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.

35. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 35 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.

36. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 36 Simple Software Process Example In the simplest cases, code is written directly from some statements of requirements. Process Artifact

37. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 37 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.

38. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 38 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.

39. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 39 A More Complex Software Process It is better to design before you code.  On larger projects, intermediate pieces of documentation are produced.

40. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 40 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.

41. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 41 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.

42. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 42 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.

43. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 43 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.

44. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 44 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

45. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 45 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).

46. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 46 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)

47. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 47 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.

48. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 48 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).

49. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 49 What’s in CPSC-4360 and CPSC-5360? 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.

50. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 50 What’s NOT in CPSC-4360 and CPSC-5360? Aspects of Project Management:  Scheduling  Risk Assessment  Quality Assessment  Documentation  Human Resource Management  Etc…. Communication and Inter-Personal Skills:  Other than communicating with your team mate and tutor  Not formally covered.

51. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 51 Object Thinking

52. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 52

53. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 53 Class Representation: Example Informal representation:  Define a class for representing students who can be identified by name may be enrolled in some program of some level.

54. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 54 Class Representation: Example Student - name : String - program : String - level : int + Student(n:String, p:String, lv:int) + printDetails() : void UML class

55. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 55 Class Representation: Example public class Student { private String name; private String program; private int level; public Student(String n, String p, int lv) { name = n; program = p; level = lv; } public void printDetails() { System.out.println("\nDetails for student " + name); System.out.println("\tProgram: " + program); System.out.println("\tLevel: " + level); }

56. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 56 Summary 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.

57. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 57 Reading suggestions From [Wadhwa, Andrei, Soo; 2007]  Chapter 1 From [Priestley; 2004]  Chapter 1  Appendix A  Exercises 1.1-1.4 From [Sommerville; 2004]  Chapters 1, 2 From [Larman; 2005]  Chapter 1

58. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 58 Coming up next Software Development Process Models:  [Wadhwa, Andrei, Soo; 2007], Chapter 2  [Priestley, 2004], Chapter 3 UML Overview:  [Wadhwa, Andrei, Soo; 2007], Chapter 2  [Priestley, 2004], Chapters 1, 2

59. 9/21/2015 CPSC-4360-01, CPSC-5360-01, Lecture 1 59 Thank you for your attention! Questions?