1. DE?!GN software

2. COMP2110 Software Design in 2004 Chris Johnson 1.Software Requirements and Software Design in a framework for Software Engineering 2.The Software Engineering ideas and concepts in comp2110 3.Organisation of the course comp2110 in 2004 It's similar to 2003 but the time schedule is different

3. Industrial Design? Philippe Starck www.philippe-starck.com DE?!GN

4. Engineering design?

5. Software Design Part of a Software Engineering process: ● analyse ● design ● implement ● test ● maintain

6. The Waterfall Software Process time Requirements Analysis Design Milestone(s) Phases (activities) Implementation Testing Maintenance Release product X Two phases may occur at the same time for a short period Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

7. The Framework: main phases of the Software Process 1. Requirements Analysis (answers “WHAT?”) Specifying what the application must do 2. Design (answers “HOW?”) Specifying what the parts will be, and how they will fit together 3. Implementation (alias “CODING”) Writing the code 4. Testing (a type of VERIFICATION) Executing the application with test data for input 5. Maintenance (REPAIR or ENHANCEMENT) Repairing defects and adding capability Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

8. Software Process Phases: Personal Finance Example  Requirements Analysis: Text produced e.g., “ … The application shall display the balance in the user’s bank account. …”  Design: Diagrams and text e.g., “ … The design will consist of the classes CheckingAccount, SavingsAccount, …”  Implementation: Source and object code e.g., … class CheckingAccount{ double balance; … } …  Testing: Test cases and test results e.g., “… With test case: deposit $44.92 / deposit $32.00 / withdraw $101.45 / … the balance was $2938.22, which is correct. …”  Maintenance: Modified design, code, and text e.g., Defect repair: “Application crashes when balance is $0 and attempt is made to withdraw funds. …” e.g., Enhancement: “Allow operation with Euro currency.” Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

9. The Waterfall Software Process time Requirements Analysis Design Implementation Testing Maintenance Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

10. Why a Pure Waterfall Process is Usually Not Practical 1.We don’t know up front everything wanted and needed Usually hard to visualize every detail in advance 2. We can only estimate the costs of implementing requirements (and the feasibility of the project) 1. To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones 2. We will probably need to modify requirements as a result 3.We often need to execute intermediate builds of programs 1. Stakeholders (clients, managers) need to gain confidence 2. Designers and developers need confirmation they're building what’s needed and wanted (use frequent incremental building and testing) 4. Team members are not idle while others do requirements Typically put people to work on several phases at once Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. See also: in comp2110 eBrick. Parnas and Clements, A Rational Design Process, How and Why to Fake It

11. Another way(1): Spiral development process complete targeted requirements Step n: Analyze requirements Step n+3: Test Step n+2: Implement Step n+1: Design Product:class models + Product: requirements specifications Product: code +Product: test results + Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12. The Spiral Process time 1 Requirements analysis Design Coding Testing 1 Iteration # 1 1 2 2 2 3 3 3 Product released X M I L E S T O N E S 23 2 3 1 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Intermediate version (prototype) X Intermediate version (2 nd prototype) X

13. Another way(2): overlapping phases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

14. The Four “P’s” of Software Engineering People (by whom it is done) * * Symbology from Ivar Jacobson, O-O Software Engineering a Case Driven Approach Addison-Wesley 1994 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. Process (the manner in which it is done) The Four “P’s” of Software Engineering People (by whom it is done) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

16. Project (the doing of it) The Four “P’s” of Software Engineering People (by whom it is done) Process (the manner in which it is done) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

17. The Four “P’s” of Software Engineering People (by whom it is done) Process (the manner in which it is done) Project (the doing of it) Product (the application artifacts) * Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. Product (the application artifacts) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. Software Engineering Product – the artifacts Design model - a document in UML, for example Source code program and object code Software requirements specification - a document in legalistic English, and UML, for example Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Product (the application artifacts) c2110 concerns

20. What's in the course? comp2110 components ● core content – specifications of requirements for software – methods for designing software for a given purpose – technical "design ideas" to use ● at high level ● at detailed level ● supporting concepts – notational methods for describing software design – notations for specification of requirements – software lifecycle framework – "quality" – what makes it a good design (or not)

21. What's in the course? comp2110 components (2) ● core content: methods, design ideas, specification ● supporting concepts: notations, framework, quality ● not what you might have hoped for: – not user interface design – a specialised topic ● not what you might have feared: – not rigid "methodology" or recipes for cookbook design ● develops your skills in doing design by making descriptions and by criticising existing designs

22. COMP2110 Organisation ● people ● lectures ● tutorials and laboratories ● textbook ● assignments ● exam ● assessment scheme

23. COMP2110 course organisation (1) ● People – Lecturer and tutor: Chris Johnson – Tutors: Tamiru Jarso and (tbc) ● Lecturessee web course-plan – 3 per week: total 26 Mon, Tues, Fri (week 5 M only, week 13 M&T) – no lectures in weeks 6 & 8 (before the break) – week 7: no lectures, group work presentations in labs ● Tutorials & laboratoriessee web course-plan – weeks 2-6, 8-12 learning by practising ● Textbook Eric Braude, Software Design the green book

24. COMP2110 course organisation (2) ● assignments no programming 1) criticise and create requirements 2) in small groups (3 or 4): create requirements, criticise existing design, start creating project design Groups will make 1 presentation and submit 1 report. 3) individual: detailed design and modified requirements for project ● final exam yes: sit down; written; open book ● assessment scheme details: Friday 23 July