1. MADALINA CROITORU croitoru@lirmm.fr Software Engineering week 4 Madalina Croitoru IUT Montpellier

2. MADALINA CROITORU croitoru@lirmm.fr Waterfall model

3. The requirements document Specify external behavior Specify constraints on implementation MADALINA CROITORU croitoru@lirmm.fr

4. Requirements definition A high - level, customer – oriented statement of what system is to do Two types of requirements: –Functional: services the systems should provide, how it responds to inputs, how it behaves, what is should NOT do –Non-functional: constraints the system should operate under (Pentium, X RAM, Y hard disk) MADALINA CROITORU croitoru@lirmm.fr

5. Kinds of requirements MADALINA CROITORU croitoru@lirmm.fr

6. MADALINA CROITORU croitoru@lirmm.fr Waterfall model

7. Software design Computer programs are composed of multiple, interacting modules The goal of system design is to: –Decide what the modules are –Decide what the modules should contain –Decide how the modules should interact MADALINA CROITORU croitoru@lirmm.fr

8. Modules Autonomous Coherent Robust MADALINA CROITORU croitoru@lirmm.fr

9. Procedural abstraction Procedures represent distinct logical functions in a program: –Display menu –Get user option MADALINA CROITORU croitoru@lirmm.fr

10. Programs as Functions X -> f -> f(x) The program is views as a function from a set of legal inputs to a set of outputs Example: LISP Well suited for certain applications: compilers etc. Less suited for distributed, non terminating systems: ATMs, certain OSs MADALINA CROITORU croitoru@lirmm.fr

11. Five criteria for design methods Modular decomposability Modular composability Modular understandability Modular continuity Modular protection MADALINA CROITORU croitoru@lirmm.fr

12. Modular decomposability The method supports the decomposition of a problem into smaller sub problems which can be solved independently The method is usually repetitive Example: top-down design methods Initialization modules do NOT meet this criterion MADALINA CROITORU croitoru@lirmm.fr

13. Modular composability Production of modules that may be freely combined to produce new systems Directly related to the issue of reusability Composability usually at odds with decomposability (top down leads to modules with a specific function and not a general one) MADALINA CROITORU croitoru@lirmm.fr

14. Modular Understandability Encourage the development of modules which are easily understandable Counter example: GOTO MADALINA CROITORU croitoru@lirmm.fr

15. Modular Continuity Leads to production of software such that a small change in a problem specification leads to a change in just one module Example: symbolic constants used Counter example: static arrays MADALINA CROITORU croitoru@lirmm.fr

16. Modular Protection Yields architectures in which the effect of an abnormal condition at run time, only affects one module Example: validating input at source Counter example: int instead of short types MADALINA CROITORU croitoru@lirmm.fr

17. Criteria for design MADALINA CROITORU croitoru@lirmm.fr

18. Five principles for good design Linguistic modular units Few interfaces Small interfaces Explicit interfaces Information hiding MADALINA CROITORU croitoru@lirmm.fr

19. Linguistic Modular Units Modules must correspond to linguistic units in the language used Example: Java modules and classes Counter Example: Subroutines in BASIC are given a line number MADALINA CROITORU croitoru@lirmm.fr

20. Few interfaces Overall number of communication channels between modules should be as small as possible For a system with n modules the minimum is n-1 and the max is n(n-1)/2. MADALINA CROITORU croitoru@lirmm.fr

21. Small interfaces (loose coupling) If two modules communicate they should exchange as little information possible Counter example: declaring all instance variables public (why?) MADALINA CROITORU croitoru@lirmm.fr

22. Explicit interfaces If modules A and B communicate this must be obvious from the text of A or B or both If we change a module we need to be able to see what other modules are affected by these changes MADALINA CROITORU croitoru@lirmm.fr

23. Information hiding All information about a module (how the module does what it does) should be private to the module unless it is specifically declared otherwise Default Java rule: make everything private MADALINA CROITORU croitoru@lirmm.fr

24. Reusability A major obstacle to the production of cheap quality software is reusability Obstacles: –Economic –Organisational –Psychological MADALINA CROITORU croitoru@lirmm.fr

25. Object oriented design Suitable for complex systems (why?) We will focus on one particular OO design approach (UML) MADALINA CROITORU croitoru@lirmm.fr