1. Design (1) Design involves decisions on how to deliver the agreed functionality to the users. Design involves development of a clear, unambiguous and consistent user-interface. (Remember that users are already likely to have been involved in user-interface design where prototyping or some form of iterative development has been used - such as in the Agile approach) System design should be done in the context of the McCall factors, in particular - Will the software be maintainable? Will software be usable? Will software be testable? Design involves decisions on how to “package” the units of code.

2. Design (2)  Large systems are always made up of smaller sub-systems.  A system architecture shows how a system is organised and how the component parts inter-operate.  Thus, the system architecture is the basic structural framework and it provides the foundation for essential communication & control between the system components.  Each sub-system or component part provides some related set of services to the user  A similar architecture is often suitable for different systems from within the same domain area – as a result of this a good architecture can support large-scale reuse.  Architecture affects performance, robustness (reliability), and maintainability of a a system  Different kinds of systems may require different architectures, e.g. transaction-processing systems, real-time systems, web-based systems

3. Design (3) I will look briefly at 3 key aspects of design:  Different alternative architectures  Component-level design considerations  User interface

4. Design (4) The Concept of Architecture Get A, B Let C = A*B Output C Get A, B Let C = A*B A, B C C Get A, B Let C = A*B Output C A, B C 132

5. Design (5) The “call-return” architecture: A module can call one of several other modules. Control is passed to the called module From Sommerville, “Software Engineering”

6. Design (6) Example of architecture for a real-time system: From Sommerville, “Software Engineering”

7. Design (7) Architecture for a multi-processor traffic control system: From Sommerville, “Software Engineering”

8. Design (8) Weather Mapping system – an OO approach 1: Overall architecture From Sommerville, “Software Engineering”

9. Design (9) Weather Mapping system – an OO approach 2: Subsystems Weather station The architecture of each collection of objects can be modelled in turn From Sommerville, “Software Engineering”

10. Design (10) Weather Mapping system – an OO approach 3: The Weather Station architecture From Sommerville, “Software Engineering”

11. Design (11) Weather Mapping system – an OO approach 4: Some object classes in the weather station system WeatherStation object class provides basic interface of weather station with its environment This object class encapsulates all operations involving collection & sumarising of data These object classes are concerned with controlling hardware instruments From Sommerville, “Software Engineering”

12. Design (12) Weather Mapping system – an OO approach 5: From the abstract to the physical – packaging components: From Sommerville, “Software Engineering”

13. Design (13) Weather Mapping system – an OO approach 6: OO allows a consistent & seamless progression from analysis through to design: Example From Sommerville, “Software Engineering”

14. Design (14) Architectural Design for Web-based Applications 1 From Pressman, “Software Engineering”

15. Design (15) Architectural Design for Web-based Applications 2 From Pressman, “Software Engineering” There may be a trad-off between ease of navigation and risk of confusion to unfamiliar users There may be a trade-off between ease of navigation and risk of confusion to unfamiliar users

16. Component-level design considerations Design (16) Whether the analysis & design approach is OO or not, every effort should be made to ensure that:  all code within a module is concerned with a single discrete function  the minimum interaction between modules, i.e. we should avoid modules passing unnecessary data to one another or having read/write access to the same data Functional cohesion within modules Minimum coupling between modules

17. Component-level design considerations Module Cohesion Design (17) Modified from Schach, “OO & Classical Software Engineering” Repetition of same task Two tasks that occur at the same time Two tasks packaged together just because they are both “editing” tasks Single specific task Temporal Two unrelated tasks

18. Component-level design considerations Module Cohesion Design (18) the aim is to produce software modules where all the code elements within a particular module are concerned with the execution of a single discrete task So - Code elements should not be bundled into the same module simply because they relate to operations that  happen at the same time  are the same kind of task, e.g. editing, verifying etc  “convenient” to put into one module Temporal cohesion Logical cohesion Coincidental cohesion Functional cohesion Avoid these last 3 forms of cohesion as they have a serious negative effect on both testability and maintainability – modules should only have functional cohesion

19. Component-level design considerations Module Coupling Design (19) “ Coupling ” is the degree of interaction between two modules The type and extent of module coupling can have a very significant impact on -  potential for re-use of modules in future products  testing & debugging  reliability  maintainability (future modification) Good software systems have the least interaction between modules That is, we aim for the least possible (loosest) coupling

20. Component-level design considerations Module Coupling Design (20) Module B Module A Module B Module A X Y Here Module A calls Module B. Control is passed back to A after B executes. No data is exchanged NO COUPLING Module A calls Module B and passes data “X” to it. When B returns control to A, it passes back the data “Y” to A MODULES ARE COUPLED

21. Component-level design considerations Module Coupling Design (21)  Data coupling  Content coupling  Common coupling  Control coupling  Stamp coupling Types of coupling Good – often necessary Very bad

22. Component-level design considerations Module Coupling Design (22) Data Coupling Two modules are data coupled if all of the elements of the data passed between these modules is used by the called module. The data passed between modules may be a simple argument i.e. a simple variable, or it may be a data structure. Data coupling means that a change made to one module is less likely to cause a knock-on fault in another module All parts of a data structure must be used

23. Component-level design considerations Data Coupling Design (23) Stamp Coupling Two modules are stamp coupled if a data structure is passed as an argument but the called module operates on only some of the individual components of that data structure. In other words, the called module doesn’t need all the data that is being passed to it Stamp coupling slightly increases the chances of knock-on errors when changes are made to modules and it makes debugging more difficult

24. Component-level design considerations Data Coupling Design (24) Control Coupling Two modules are control coupled if one passes an element of control to the other module; that is, one module explicitly controls the logic of the other If module P calls module Q and Q passes a flag back to P that says: “I am unable to complete my task” then Q is passing data (i.e. data coupled). But – if the flag means: “I am unable to complete my task and, therefore, display error message # 43” then P and Q are control coupled. Module Q Module P flag The problem here is that Module Q has to be aware of the internal structure and logic of Module P

25. Component-level design considerations Data Coupling Common Coupling Two modules arecommon coupled if both have access to the same global data area Design (25) Module B Module A global_variable The most common situation in which this arises is when both Module A and Module B have access to the same database and both can read and write to the database. Both modules have read-write access to global_variable

26. Component-level design considerations Data Coupling The Problems with Common Coupling - Design (26) As a consequence of common coupling, modules may be exposed to more data than they need. Control of data access may be more difficult and this can increase the risk of computer crime. The introduction of new modules which can alter a global variable can result in an exponential increase in the instances of common coupling. Module re-use becomes difficult because an identical list of global variables has to be supplied each time the module is re-used If a maintenance change is made in one module to the declaration of a global variable then every module that can access that global variable has to be changed also. If a run-time failure occurs it may be difficult to reconstruct what happened because any one of a number of modules could have changed the value of a variable

27. Component-level design considerations Data Coupling Design (27) Content Coupling Two modules are content coupled if a calling module directly references the code of the called module.... Get p If p = 1 then r= 1, call B (r) else if p = 2 then r = 2, call B (r) else r = 3, call B (r) endif ModuleB ModuleA r... If r = 1 then do routine_1 else if r = 2 then do routine_2 else do routine_3 endif goto end Routine_1... goto end Routine_2... goto end Routine_3... goto end... end Module A decides which part of Module B will execute. Content coupling is also known as pathological coupling and is the worst possible type.

28. Component-level design considerations Data Coupling – Diagrammatic View Design (28)

29. Component-level design considerations Data Coupling Content Coupling & Coincidental Cohesion Software which exhibits content coupling between modules and coincidental cohesion within modules has no proper design structure. Such software frequently arises as a result of ongoing maintenance of legacy systems. Design (29) Testing, debugging and maintenance becomes increasingly more difficult and expensive. Component re-use becomes impossible Software becomes less stable and less reliable

30. User interface Design A poorly designed user interface means that the potential benefits of the system are unlikely to be achieved. Four key principles: Place the user in control Reduce the user’s memory load Make the interface consistent Control the use of colours e.g. design user interaction to be Interruptible & reversible Hide technical details from user Design for direct interaction with objects that appear on screen The system should “remember” details of interaction scenarios rather than forcing the user to recall details. Use appropriate default values Design an interface with a consistent look, “feel” and behaviour across the whole system Use colours to highlight & emphasise Excessive use of colour can cause fatigue and irritation Design (30)