1. CS350/550 Software Engineering Lecture 1

2. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There will also be homeworks building on each other Class participation is essential

3. Class participation You will need to create documents and present them in class You will need to criticize other people’s presentations –You may need to build on them You will need to ask questions –Because software engineers must ask the right questions of a customer

4. Assignment #1 Think of ideas for the class project –More than one would be great It should be a useful idea (somebody actually can use it) It should be feasible in one semester –Not too big, not too small Due next Tuesday You will have to present them next week

5. Who are you? Good programmer in some language –Survey class for languages –You only wrote programs for your teacher to grade, and then you forgot about it No experience in analyzing or designing systems –what you will probably do in the real world Want to learn technical aspects of designing complex systems

6. Objectives of Class Appreciate Software Engineering –Build complex systems that frequently change Understand how to produce a quality system in time, and deal with complexity and change Acquire technical knowledge Acquire managerial knowledge (a little)

7. Why Software Engineering Why don’t you just sit down and start typing a program? Software systems are so big and complex –And they can change You need these techniques to control the construction of software systems I want you to appreciate the fact that without some rigid process, this is impossible

8. Software is buggy Everybody knows stories of buggy software that can waste lots of money or even kill people If we design things carefully, we can have fewer bugs –Probably not no bugs

9. You will learn How to model a system –UML is a language that was created for this purpose –Object-oriented vs functional decomposition What is the software lifecycle Component based techniques –Using design patterns for reuse How to run projects

10. Software Engineering Definition Collection of techniques (methodology) and tools that help with the production of –A high quality software system –With a given budget –Before a given deadline while change occurs

11. Factors affecting quality Complexity –No single programmer can understand it –Fixing one bug causes another one Change –Each change increases complexity and erodes the structure of a system –At some point, it is too expensive to make a change, and system cannot perform its function

12. Why are software systems complex? The problem domain is difficult The development process is difficult to manage Software offers extreme flexibility Continuous systems are modeled discretely

13. Software Engineering Analysis: Understand problem and break it into pieces Synthesis: Put pieces back together

14. Dealing with complexity 1.Abstraction 2.Decomposition 3.Hierarchy

15. 1. Abstraction Inherent human limitation to deal with complexity Chunking: Group collections of objects Ignore unessential details  Models

16. 2. Decomposition Divide and Conquer Functional Decomposition Object-oriented Decomposition

17. Functional Decomposition System decomposed into modules Each module is a function in application domain Modules can be decomposed into smaller modules

18. Object-oriented Decomposition System decomposed into classes (objects) Each class is a major abstraction in application domain Classes can be decomposed into smaller classes

19. Functional Decomposition Functionality is spread all over the system Maintainer must understand whole system to make a single change Consequence –Code is harder to understand –Complex code is harder to maintain –User interface can be awkward and non- intuitive

20. 3. Hierarchy We got abstractions and decomposition Another way to deal with complexity is to provide relationships between chunks One of the most important relationships is hierarchy –“part-of” hierarchy –“is-kind-of” hierarchy

21. Where are we? 3 ways to deal with complexity –Abstraction, decomposition, hierarchy Object-oriented decomposition is a good methodology –Depending on purpose of system, different objects can be found How to do it right –Our approach is to start with a description of the functionality, then proceed to object model

22. Software Lifecycle Definition Software Lifecycle: –Set of activities and their relationship to each other to support the development of a software system Typical Lifecycle questions: –Which activities should I select? –What are the dependencies between them? –How should I schedule them?

23. Software Lifecycle Activities Requirements Elicitation Analysis System Design Object Design Implementation Testing

24. Requirements Elicitation Client and Developers define the purpose of the system Result is actors and use cases (model) Actor = role somebody or something plays Use Case = sequence of events that describes possible actions of user with system

25. Analysis Developer transforms use cases into an object model that completely describes the system Client should understand result of analysis

26. System Design Developers define design goals and decompose system into smaller subsystems Also select strategies for building system Client cannot understand this

27. Object Design Developer designs solution domain objects Result of object design is detailed object model with constraints and precise descriptions of each element

28. Implementation Developers transform solution domain model into source code Note that only this small part of development involves programming

29. Testing Developers find differences between the system and its model by executing the system with sample input data sets Unit testing, integration testing, system testing

30. Reusability A good software design solves a specific problem but is general enough to address future problems (changing requirements) Software engineers create reusable software, and reuse solutions others have created Using design patterns

31. Design Patterns A set of classes that provide a template solution to a recurring design problem On a higher level than data structures