Chapter 16: Analysis and Design (a short introduction)

1. Chapter 16: Analysis and Design (a short introduction) • As engineers in other desciplines do, it necessary for real projects to “analyse” and “design” before (or in parallel to) coding • There are many methodolgies that have been introduced for full life-cycle of software: • Waterfall • Rational Unified Process • Extreme Programming • Interaction design • etc. • However, we can recognise some phases (deciplines) which are usally done for any methodology

2. Phase 0 – Make a plan • Before starting any real project we should have a plan for building it. • A plan says things like following to us: • Statement of work (mission) • Tasks and times for each • Resources • Deliverables

3. Phase 1- What we are making (a.k.a. Requirement analysis and specification) • In OOP we normally create use case diagrams and use case specifications for this phase. Those diagrams specify following: • Who will use the system (Actors) • What can those actors do with the system • How does this actor do that with the system • What problems may happen when doing this with the system

4. Use case diagram example

5. Phase 2: how we build this • We should create a solution for each use case. • Solutions are provided by: • Designing classes (interfaces) • Specifying relationships between classes (class diagrams) • Providing a solution for a use case with the use of designed classes (Sequence diagrams or collaboration diagrams)

6. Object design stages 1. Object discovery. 2. Object assembly. 3. System construction. 4. System extension. 5. Object reuse.

7. Phase 3: build the core • Establishing core of the system architecture that needs to be implemented to have a running system • This is an initial framework that you can build on with further iterations • For example we may only produce user interfaces with little or no functionality • This helps find any misunderstandings, errors and problems in specification or design

8. Phase 4: Iterate the use cases • At each iteration, we add some functionality to the core • Then we build the (new) system, test it and will be ready for next iteration • An iteration is a 1 to 3 weeks period • It is better to start with critical parts of the system at the early iterations: • Parts that maybe not well understood • Those that needs some sophisticated algorithm/protocol • Part that the team is not well suited with it

9. Phase 5: Evolutions (AKA maintenance) • This includes following activities: • Adding new functionality to the system • Changing functionality • Debugging • Code re-factoring • For better performance • To make library of reusable components

10. Extreme programming idioms • Write tests first: • This helps to find missing functionalities • Also helps in finding misunderstandings • Pair programming • One person types the code • Other one watches him/her and notify problems (thinker) • The value is that thinker creates a big picture in mind while the other one is coding • There is less chance that tests left behind