Software Engineering I

1. TUM Software Engineering I Bernd Brügge Technische Universität München Lehrstuhl für Angewandte Softwaretechnik http://wwwbruegge.in.tum.de 20 October 2004

2. Assumptions and Requirements for this Class • Assumption: • You are proficient in a programming language, but you have no experience in analysis or design of a system • You want to learn more about the technical aspects of analysis and design of complex software systems • Requirements: • You are an enrolled student in • Diplom for Informatik • Bachelor for Informatik • Master program for computational science and engineering • Beneficial: • You have practical experience with maintaining or developing a large software system and have experienced major problems

3. Intended audience • Informatik students (Diplom) • Informatik Aufbaustudium • Informatik students (Bachelor) • Computational Science and Engineering (Master) • Students taking the associated Software Engineering Praktikum CampusTV

4. Times and Locations • Main lecture slot (HS 1, 00.02.001) • Tuesday 13:15-14:45 • Wednesdays 17:00 - 18:30 • Exercises (Room 00.13.009) • Diplom and Bachelor students, interested students • Thursday: 8:30-10:00 • Written Exam: Feb 11, 2005

5. Appreciate Software Engineering: Build complex software systems in the context of frequent change Understand how to produce a high quality software system within time while dealing with complexity and change Acquire technical knowledge (main emphasis) Acquire managerial knowledge Objectives of the Class

6. Understand system modeling Learn a modeling notation (Unified Modeling Language) Learn different modeling methods: Use Case modeling Object Modeling Dynamic Modeling Issue Modeling Learn to use Tools: CASE (Computer Aided Software Engineering) Testing Different testing methods Unit, integration and system testing Move into Component-Based Software Engineering Use Design Patterns and Frameworks Reuse Acquire Technical Knowledge

7. Understand the Software Lifecycle Process vs Product Learn about different software lifecycles Greenfield Engineering, Interface Engineering, Reengineering] Rationale Management Configuration Management Software Lifecycle Methodologies Acquire Managerial Knowledge

8. Outline of Today’s Lecture • High quality software: State of the art • Modeling complex systems • Functional vs. object-oriented decomposition • Dealing with change: • Software lifecycle modeling • Reuse: • Design Patterns • Frameworks • Organizational issues: • Lecture Schedule • Exercise Schedule • Concluding remarks

9. Can you develop this?

10. Limitations of Non-engineered Software Requirements Software Vaporware “Bananaware” = Ripes at the customer site

11. Software Production has a Poor Track Record Example: Space Shuttle Software • Cost: $10 Billion, millions of dollars more than planned • Time: 3 years late • Quality: First launch of Columbia was cancelled because of a synchronization problem with the Shuttle's 5 onboard computers. • Error was traced back to a change made 2 years earlier when a programmer changed a delay factor in an interrupt handler from 50 to 80 milliseconds. • The likelihood of the error was small enough, that the error caused no harm during thousands of hours of testing. • Substantial errors still exist. • Astronauts are supplied with a book of known software problems "Program Notes and Waivers".

12. Quality of today’s software…. • The average software product released on the market is not error free.

13. …has major impact on Users

14. Software Engineering: A Problem Solving Activity • Analysis: Understand the nature of the problem and break the problem into pieces • Synthesis: Put the pieces together into a large structure • For problem solving we use • Techniques(Methods): • Formal procedures for producing results using some well-defined notation • Methodologies: • Collection of techniques applied across software development and unified by a philosphical approach • Tools: • Instrument or automated systems to accomplish a technique

15. Software Engineering: Definition • Software Engineering is a collection oftechniques, • methodologies and tools that help • with the production of • a high quality software system • with a given budget • before a given deadline • while change occurs. 20

16. Oct 27: Modeling with UML II Nov 3: Requirements Elicitation Nov 10: Analysis I Nov 17: Analysis III + Sysiphus Nov 24: System Design II Dec 1: Object Design: Reuse Dec 8: Object Design: Specification Dec 15: Mapping Models-> Code Oct 26: Modeling with UML Nov 2: Project Organization I Nov 9: Project Organization II Nov 16: Analysis II Nov 23: System Design Nov 30: System Design III Dec 7: Object Design: Reuse II Dec 14: Object Design: Specification II Dec 21: Mapping Models -> Code II Tentative Lecture Schedule after Christmas Tuesdays 13:15-14:15 Wednesday 17:00-18:15 • Oct 20: Course Introduction New Schedule is Subject to Change!

17. Jan 11: Exam for CSE Students Jan 18: Unit Testing Jan 25: System Testing Feb 1: Software Lifecycle Feb 8, 2005: CampusDVB Project: Client Acceptance Test (Internet-based presentation) Feb 11, 2005: Exam for Bachelors and anybody who needs a “Schein” (Nebenfach Students, etc) Jan 12: Configuration Management Jan 19: Integration Testing Jan 26: Demo Engineering Feb 2: Miniproject Presentations Lecture Plan for January/February 2005

18. Lecture Topics in SS 2005 • Configuration Management • Rationale Management • Project Management • Software Lifecycle Modeling • Methodologies: XP, Scrum, Royce • Project Management Workshop

19. Software Engineering means Practice Practice! Practice! Practice!

20. Associated Lecture Project: ARENA • This project will be used in the lectures to illustrate software engineering concepts and artifacts • ARENA specific documents will be made available incrementally • ARENA models and source code will be made available as well. • All artifacts will be placed on the Software Engineering lecture portal • The first document is already available: Problem Statement • http://wwwbruegge.in.tum.de/Lehrstuhl/SoftwareTechnikWiSe2004

21. Playing TicTacToe within ARENA

22. Associated Exercise Project: Asteroids • Main Goal: • Practice and internalize the most important concepts of the lecture • Become proficient in using and applying these concepts • Context: Games • Teaching assistants: • Timo Wolf (iChat Connection) • Korbinian Herrmann • Meeting Time: • Thursday, 8:30-10:00 • Mini-Project • Development a Game : Model-based development of Asteroids: • Integrate Asteroids with ARENA • Example: • Asteroids Example: http://www.surfnetkids.com/games/asteroids-game.htm

23. Exercise Schedule • 8.10.04 Modelling with UML: Use Case and class diagrams • 04.11.04 Modelling with UML: Sequence and activity diagrams • 11.11.04 Requirements Elicitation • 18.11.04 Analysis • 25.11.04 System Design • 02.12.04 Dies Academicus • 09.12.04 Object Design: Using Design Patterns • 16.12.04 Object Design: OCL • 13.01.05 Mapping models to code • 20.01.05 Miniproject: Asteroids (Unlimited playing field) • 27.01.05 Miniproject: Asteroids (ARENA Integration) • 03.02.05 Miniproject: Asteroids (Multi-Player Version)

24. Associated Project Course: InteractiveCampus • Scope • Interactive Teaching with DVB-T and DBH-T • Praktikum Software Technik • Client: Rohde & Schwarz • Manfred Reitmeier • Tuesday 11:00-13:00, Location: • wwwbruegge.in.tum.de/Lehrstuhl/SoftwareEngineeringPraktikumWiSe2004 • Problem Statement (called Handout 1) • The Problem • Visionary scenario • Functional requirements • Nonfunctional requirements • Acceptance test criteria • Video of client presentation http://wwwbruegge.in.tum.de/Lehrstuhl/SoftwareEngineeringPraktikumWiSe2004 • Leads to http://tum.solutionpark.ch/Channels/0000/Archive/2004_10_19-10_40_02/OnDemand/Player/en/QuickTime/VideoHighAndSlides/000/play.html

25. The Vision The Vision: InteractiveCampus George Video Mixer Lecture Video Sender HS1 Garching Laptop Lecture Slides Anna Albert Streaming Server AudiMax TUM PDA Stefan Peter “Interactive Teaching Anywhere” • Location Independent Biergarten • Personal Handy • Interactive • Peer-to-Peer Interaction Server

26. Scientist vs Engineer • Computer Scientist • Proves theorems about algorithms, designs languages, defines knowledge representation schemes • Has infinite time… • Engineer • Develops a solution for an application-specific problem for a client • Uses computers & languages, tools, techniques and methods • Software Engineer • Works in multiple application domains • Has only 3 months... • …while changes occurs in requirements and available technology

27. Factors affecting the quality of a software system • Complexity: • The system is so complex that no single programmer can understand it anymore • The introduction of one bug fix causes another bug • Change: • The “Entropy” of a software system increases with each change: Each implemented change erodes the structure of the system which makes the next change even more expensive (“Second Law of Software Dynamics”). • As time goes on, the cost to implement a change will be too high, and the system will then be unable to support its intended task. This is true of all systems, independent of their application domain or technological base.

28. Why are software systems so complex? • The problem domain is difficult • The development process is very difficult to manage • Software offers extreme flexibility • Software is a discrete system • Continuous systems have no hidden surprises (Parnas) • Discrete systems have!

29. Dealing with Complexity 1. Abstraction 2. Decomposition 3. Hierarchy

30. What is this?

31. 1. Abstraction • Inherent human limitation to deal with complexity • The 7 +- 2 phenomena • Chunking: Group collection of objects • How can we ignore unessential details? => Models

32. Models are used to provide abstractions • System Model: • Object model: What is the structure of the system? What are the objects and how are they related? • Functional model: What are the functions of the system? How is data flowing through the system? • Dynamic model: How does the system react to external events? How is the event flow in the system ? • Task Model: • PERT Chart: What are the dependencies between the tasks? • Schedule: How can this be done within the time limit? • Org Chart: What are the roles in the project or organization? • Issues Model: • What are the open and closed issues? What constraints were posed by the client? What resolutions were made?

33. Analysis phase results in object model (UML Class Diagram): * * Company StockExchange Lists tickerSymbol Implementation phase results in code public class StockExchange { public Vector m_Company = new Vector(); }; public class Company { public int m_tickerSymbol public Vector m_StockExchange = new Vector(); }; Model-based Software Engineering:Code is a derivation of the Object Model Pr oblem Statement : A stock exchange lists many companies. Each company is identified by a ticker symbol A good software engineer tries to write as little code as possible

34. Interdependencies of the Models System Model (Structure, Functionality, Dynamic Behavior) Issue Model (Proposals, Arguments, Resolutions) Task Model (Organization, Activities Schedule)

35. Object Model Forward Engineering Code Reverse Engineering Functional Model Dynamic Model Constraints class... class... class... Arguments Org Chart Issues Pro Con Proposals Interdependencies of the Models System Models PERT Chart Gantt Chart Issue Model Task Models

36. Example of an Issue What is the center of the Universe? • Church: The earth is the center of the universe. Why? Aristotle says so. • Galileo: The sun is the center of the universe. Why? Copernicus says so. Also, the Jupiter’s moons rotate round Jupiter, not around Earth.

37. Resolution (1615): The church decides proposal 1 is right Resolution (1998): The church declares proposal 1 was wrong Proposal1: The earth! Proposal2: The sun! Pro: Aristotle says so. Pro: Copernicus says so. Con: Jupiter’s moons rotate around Jupiter, not around Earth. Pro: Change will disturb the people. Issue-Modeling Issue: What is the Center of the Universe?

38. 2. Decomposition • A technique used to master complexity (“divide and conquer”) • Functional decomposition • The system is decomposed into modules (“functions”) • Each module is a major processing step (function) in the application domain • Modules can be decomposed into smaller modules • Object-oriented decomposition • The system is decomposed into classes (“objects”) • Each class is a major abstraction in the application domain • Classes can be decomposed into smaller classes Which decomposition is the right one?

39. Produce Output Transform Read Input Produce Output Transform Read Input Add R1, R10 Load R10 Functional Decomposition System Function Top Level functions Level 1 functions Level 2 functions Machine Instructions

40. Functional Decomposition • Functionality is spread all over the system • Maintainer must understand the whole system to make a single change to the system • Consequence: • Codes are hard to understand • Code that is complex and impossible to maintain • User interface is often awkward and non-intuitive • Example: Microsoft Powerpoint’s Autoshapes • How do I change the square into a circle?

41. First Attempt: Check the Format Menu: Autoshape

42. Second Attempt: From the Help Assistant • Change one AutoShape to another • 1. Select the AutoShape you want to change. • 2. On the Drawing toolbar, click Draw , click Change AutoShape, point to a category, and then click the shape you want.

43. Draw Change Mouse click Change Circle Change Oval Change Rectangle Draw Circle Draw Oval Draw Rectangle Functional Decomposition: Autoshape Autoshape

44. What is This?

45. * Shoe Size Color Type Wear() Coat Size Color Type Wear() Model of an Eskimo Eskimo Size Dress() Smile() Sleep()

46. Eskimo Size Dress() Smile() Sleep() lives in Outside Temperature Light Season Hunt() Organize() moves around Cave Lighting Enter() Leave() * Entrance MainEntrance Size Windhole Diameter Iterative Modeling then leads to .... but is it the right model?

47. Indian Hair Dress() Smile() Sleep() Mouth NrOfTeeths Size open() speak() Face Nose smile() close_eye() Ear Size listen() Alternative Model: The Head of an Indian *

48. Class Identification • Class identification is crucial to object-oriented modeling • Basic assumption: • 1. We can find the classes for a new software system: We call this Greenfield Engineering • 2. We can identify the classes in an existing system: We call this Reengineering • 3. We can create a class-based interface to any system: We call this Interface Engineering • Why can we do this? Philosophy, science, experimental evidence • What are the limitations? Depending on the purpose of the system different objects might be found • How can we identify the purpose of a system?

49. 3. Hierarchy 10/20/2004 • We got abstractions and decomposition • This leads us to chunks (classes, objects) which we view with object model • Another way to deal with complexity is to provide simple relationships between the chunks • One of the most important relationships is hierarchy • 2 important hierarchies • "Part of" hierarchy • "Is-kind-of" hierarchy

50. CPU I/O Devices Memory Cache ALU Program Counter Part of Hierarchy Computer