1. Midterm ReviewSummer 2003 1 ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Midterm Review Partially based on lecture notes written by Sommerville, Frost, Easterbrook & Tonne.. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

2. Midterm ReviewSummer 2003 2 Exam Information l The exam will be given in lecture, so you’ll have 120 minutes. l The exam is closed book, closed notes, closed laptops and of course you can’t consult your classmates. l Try to space yourselves out

3. Midterm ReviewSummer 2003 3 Exam coverage l Lecture topics 1-8 l Sommerville, chapters 1-3, 5-12, 14

4. Midterm ReviewSummer 2003 4 Software Engineering Basics (Topic 1) l What is Software Engineering? l What is software (other than just programs) l What is the goal of software engineering (Why do it?) What is the software crisis l How does it differ from… Programming Architecture (how is it like this too?)

5. Midterm ReviewSummer 2003 5 The five P’s l People l Product l Project l Process l Professionalism

6. Midterm ReviewSummer 2003 6 Software Qualities (Topic 2) l Correctness l Reliability l Robustness l Performance l Usability l Maintainability Corrective Adaptive Perfective l Repairability l Evolvability l Reusability l Portability l Safety l Verifiability l Why not have them all?

7. Midterm ReviewSummer 2003 7 Software Process (Topic 2) l What is it? l Fundamental Activities of a software lifecycle Requirements/Specification Architecture/Design Implementation Integration Operation/Maintenance

8. Midterm ReviewSummer 2003 8 Software Lifecycle Model l What are the Models? Stepwise Development Waterfall Rapid Prototyping Spiral Incremental Synchronize-and-Stabilize Evolutionary – in book chpt 3 (pg 46) l What are the pros and cons of each

9. Midterm ReviewSummer 2003 9 Software Principles (Topic 3) l What are they? Rigor & Formality – to be exact or precise Separation of Concerns – “Divide & Conquer” Modularity – divide into smaller pieces/modules Abstraction – abstract away unnecessary details Anticipation of Change Generality – focus on discovering a more general problem Incrementality – proceed in stepwise fashion (increments Use more indepth definitions in lecture slides

10. Midterm ReviewSummer 2003 10 Software Principles l How do they apply to Requirements? l How do they apply to Design? l Know the benefits of them and why they are necessary

11. Midterm ReviewSummer 2003 11 Requirements Engineering (Topic 4) l What is Requirements Engineering? What is the process? »Feasibility study »Requirements elicitation and analysis »Requirements specification »Requirements Validation l What is a feasibilty study? l What are the problems with Requirements Analysis? (What makes it hard?) Domain issues Communication issues Details in slides

12. Midterm ReviewSummer 2003 12 Requirements Specification l What does a requirements specification say about the system? What does is describe? l Why is it important to get them right? l What is the difference between a functional and non-functional requirement? l What is an acceptance test plan? l How do we measure non-functional requirements?

13. Midterm ReviewSummer 2003 13 Requirements continued l What are the different techniques we discussed? l What is wrong with Natural language documents? What are our alternatives? (topic 5) l What are some of the problems we typically run into with requirements (topic 5) l What are enduring vs. volatile requirements? l What are some basic guidelines for writing requirements? l How can we verify them?

14. Midterm ReviewSummer 2003 14 Alternatives to NL l Structured Language l Form-based Specifications l PDL-Based l Formal Specifications Abstract model Algebraic State Transition Axiomatic

15. Midterm ReviewSummer 2003 15 Requirements l You should know how to interview a customer to elicit requirements. l You should know how to write a textual (non-formal) requirements document. l You should understand the structure of a requirements document and know the appropriate kinds of information in such a document.

16. Midterm ReviewSummer 2003 16 Alternatives to NL l For each you should know… l What they are. l Why we use them. l When do we use them? l Pros/Cons l Can we only use one style for a system?

17. Midterm ReviewSummer 2003 17 Software Architecture l Know the difference between Architectural Design and Module Design (Topic 6) l What is Architectural Design? What is its purpose? What does it describe l Why do we do it & advantages l Know the different parts of the Architectural Design Process System Structuring Control Modeling Modular Decomposition l Differences between Subsystems and Modules

18. Midterm ReviewSummer 2003 18 More on S/w Arch (Topic 6) l Can one model work for everything? l Should you only use 1 model for an entire system? l What does a model consist of? Components Connectors Constraints Interfaces

19. Midterm ReviewSummer 2003 19 Know the Models (Topics 6 & 7) l General Models Structural »Repository  MVC – Model View Controller (Good for UIs) »Client-Server »Layered (or Abstract Machine) Model Control Models »Centralized Control Models  Call-return Model  Real-Time system Control Model »Event Driven  Broadcast Model  Interrupt-Driven Control Modular Decomposition »DataFlow  Pipe & Filter (DataFlow Model)  Object Models l Domain Specific Generic (Bottom-Up) Reference (Top-Down)

20. Midterm ReviewSummer 2003 20 Models continued l Know what type of models they are General »System Structuring »Control Modeling »Modular Decomposition Domain Specific l Pros/Cons

21. Midterm ReviewSummer 2003 21 Design (Topic 7&8) l What makes a good design? How do the principles apply? l What is a Module? l What is an Abstract Data type? What is the goal… why use them? What is information hiding? l Interfaces Why do we need them? – why are they important? What do they do?

22. Midterm ReviewSummer 2003 22 Module Basics (Topic 8) l Information Hiding l Reusable Modules l Designing for Program Families What is a program family? Why should we design for it? l Why are these important? l What are the Cons

23. Midterm ReviewSummer 2003 23 Design Continued (Topic 8) l Know Uses diagrams What do they represent? Is it the same as an invokes diagram? »A diagram that shows all calls between modules l What is fan-in and fan out (with respect to diagrams)? Which is more desirable and why? l Know what is-component-of relationship is How does it relate to is-composed-of Or Comprises diagram

24. Midterm ReviewSummer 2003 24 Design continued l What is Stepwise refinement? Top-down, bottom-up Pros/Cons l What are the tools of the trade or techniques for design? Apply Information Hiding Use the Requirements Document Anticipate Change Design for incrementality/generality (Reuse) Design for Program families Determine usage patterns

25. Midterm ReviewSummer 2003 25 Architecture/Design l Are architectures reusable? l What is coupling? l What is cohesion? l Try to keep in mind what the underlying goals of software engineering are… Why do we do this? l Remember there are pros & cons to everything l There are cost trade-offs.. What are they?

26. Midterm ReviewSummer 2003 26 Basic Format l Short Answer l Long Answer l Multiple choice l Maybe some T/F l Some Tips Don’t wait until the last minute to study Study Groups »Come prepared you’ll get more out of it. »Study on your own again after study group Get a good nights sleep and don’t starve yourself the day of the test »Good brain food – nuts.. Not so good – carbs If you don’t know the answer off the top of your head--- move on to the next question Go for the points – balance your time