Ivica Crnkovic Mälardalen University Department of Computer Engineering ivica.crnkovic@mdh.se

1. Software Engineering Course Software Design Ivica Crnkovic Mälardalen University Department of Computer Engineering ivica.crnkovic@mdh.se SE course, Software Design

2. Software Design • Deriving a solution which satisfies software requirements • Several levels iteration process • conceptual design • technical design “The user will be able to route messages to any other user on any other network computer.” Network topology Protocol used Prescribed bps rate . . . Conceptual design Technical design SE course, Software Design

3. Stages of design • Problem understanding • Look at the problem from different angles to discover the design requirements • Identify one or more solutions • Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources • Describe solution abstractions • Use graphical, formal or other descriptive notations to describe the components of the design • Repeat process for each identified abstraction until the design is expressed in primitive terms SE course, Software Design

4. Top level Decomposition and Modularity • Decomposition of a system into modules (components). • A good system: • Modular - each well defined activity executed by a separate component • Well - defined - all inputs are essential for the function and all the outputs are produced by the component’s functions First level of decomposition (sub-systems) Second level of decomposition (modules) SE course, Software Design

5. The Design Process • Architectural design Identify sub-systems • Abstract specification Specify sub-systems • Interface design Describe sub-system interfaces • Component design Decompose sub-systems into components • Data structure design Design data structures to hold problem data • Algorithm design Design algorithms for problem functions SE course, Software Design

6. Architectural Design • Establishing the overall structure of a software system • No general process model for the architectural design. • Usual activities in the process: • System structuring - The system is decomposed into several principal sub-systems and communications between these sub-systems are identified • Control modeling - A model of the control relationships between the different parts of the system is established • Modular decomposition - The identified sub-systems are decomposed into modules • Different architectural styles/strategies may be used for these activities SE course, Software Design

7. Design strategies • Functional/structural design • The system is designed from a functional viewpoint. The system state is centralized and shared between the functions operating on that state • Object-oriented design • The system is viewed as a collection of interacting objects. The system state is de-centralized and each object manages its own state. Objects may be instances of an object class and communicate by exchanging methods • Although it is sometimes suggested that one approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary • Good software engineers should select the most appropriate approach for whatever sub-system is being designed SE course, Software Design

8. System structuring models (Architectural Styles) • Repository model • Pipes and Filters • Client-server • Layering model • N-tiers model SE course, Software Design

9. Knowledge source 4 Knowledge source 3 Knowledge source 5 Repository (shared data) Knowledge source 2 Knowledge source 6 Knowledge source 1 The repository model SE course, Software Design

10. Pipes and Filters Pipe - a stream of data Filter - a component SE course, Software Design

11. Client-server architecture SE course, Software Design

12. Tier Boundary Two-Tiers Architecture PresentationLogic BusinessLogic BusinessLogic BusinessLogic DatabaseDriver Presentation / Business Layer Data Layer Database SE course, Software Design

13. Cryptography File interface Key management Authentication Users Layering SE course, Software Design

14. Tier Boundary Tier Boundary N-Tiers Architecture PresentationLogic Presentation Layer BusinessLogic BusinessLogic BusinessLogic DatabaseDriver Business Layer Data Layer Database SE course, Software Design

15. DBMS DBMS DBMS HTTP ADO COMApplications ADO DCOM Microsoft Application Server Technologies VisualInterDev BrowserClient IIS ASPApplications MTS RichClient VBVC++VJ++ Windows NT SE course, Software Design

16. Control models • Are concerned with the control flow between sub-systems. Distinct from the system decomposition model • Centralized control • One sub-system has overall responsibility for control and starts and stops other sub-systems • Event-based control • Each sub-system can respond to externally generated events from other sub-systems or the system’s environment SE course, Software Design

17. Centralized control • A control sub-system takes responsibility for managing the execution of other sub-systems • Call-return model • Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems • Manager model • Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can be implemented in sequential systems as a case statement SE course, Software Design

18. Call-return model SE course, Software Design

19. Real-time system control SE course, Software Design

20. Event-driven systems • Driven by externally generated events where the timing of the event is outwith the control of the sub-systems which process the event • Two principal event-driven models • Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so • Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing SE course, Software Design

21. Broadcast model • Effective in integrating sub-systems on different computers in a network • Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event • Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them • However, sub-systems don’t know if or when an event will be handled SE course, Software Design

22. Interrupt-driven systems • Used in real-time systems where fast response to an event is essential • There are known interrupt types with a handler defined for each type • Each type is associated with a memory location and a hardware switch causes transfer to its handler • Allows fast response but complex to program and difficult to validate SE course, Software Design

23. Modular decomposition • Another structural level where sub-systems are decomposed into modules • Two modular decomposition models covered • An object model where the system is decomposed into interacting objects • A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model • If possible, decisions about concurrency should be delayed until modules are implemented SE course, Software Design

24. Characteristics of good design • Easy to understand • easy to implement • easy to test • easy to maintain • easy to adapt • requirements easy traceable • Attributes of a good designed product • Components coupling • Components cohesion • Exception handling • Fault prevention and fault tolerance SE course, Software Design

25. Module A A’s data Module B B’s data Module C C’s data Component Independence - coupling between modules Module A Module B Shared data Module C Loose coupling Tight coupling SE course, Software Design

26. The range of coupling measures HIGH COUPLING Content coupling Common coupling Control coupling LOOSE Stamp coupling Data coupling Uncoupled LOW SE course, Software Design

27. Example of a content coupling A B C Component B D E Go to D1 Component D Go to D1 D1: SE course, Software Design

28. Component X Component Y Component Z V1 = V2 + A1 Increment V1 Change V1 to zero Example of common coupling Global: A1 A2 A3 Variables: V1 V2 Common data area and variable names SE course, Software Design

29. Coupling • Control coupling • A component passes parameters to another components to control its activity • Stamp coupling • Passing data structures • Data coupling only data passes ----------------------------------------------------- Messaging coupling SE course, Software Design

30. Cohesion • A measure of how well a component 'fits together' • A component should implement a single logical entity or function • Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component • Various levels of cohesion have been identified SE course, Software Design

31. HIGH COHESION Functional Sequential Communicational Procedural Temporal Logical Coincidental LOW SE course, Software Design

32. TIME T0 FUNCTION A FUNCTION A FUNCTION A TIME T0 + X FUNCTION B FUNCTION C FUNCTION B logic FUNCTION A’ FUNCTION E FUNCTION D TIME T0 + 2X FUNCTION C FUNCTION A” COINCIDENTAL Parts unrelated LOGICAL Similar functions TEMPORAL Related by time PROCEDURAL Related by order of functions DATA FUNCTION A FUNCTION A FUNCTION A - part 1 FUNCTION B FUNCTION B FUNCTION A - part 2 FUNCTION C FUNCTION A - part 3 FUNCTION C COMMUNICATIONAL Access same data SEQUENTIAL Output of one part is input to next FUNCTIONAL Sequential with complete, related functions Cohesion level SE course, Software Design

33. Understandability • Related to several component characteristics • Cohesion. Can the component be understood on its own? • Naming. Are meaningful names used? • Documentation. Is the design well-documented? • Complexity. Are complex algorithms used? • Informally, high complexity means many relationships between different parts of the design. hence it is hard to understand • Most design quality metrics are oriented towards complexity measurement. They are of limited use SE course, Software Design 32

34. Adaptability • A design is adaptable if: • Its components are loosely coupled • It is well-documented and the documentation is up to date • There is an obvious correspondence between design levels (design visibility) • Each component is a self-contained entity (tightly cohesive) SE course, Software Design 33

35. Design traceability SE course, Software Design

36. Exception Identification and Handling • Usually the requirements tell us what to do, not what not to do • How to define what to do but no more? • Identify exceptions - cases not allowed in the system • Typical exceptions • failure to provide a service • providing the wrong service or data • corrupting data • How to handle exceptions? • Retrying - restore the system to its previous state and try again • Correct - restore the system to its previous state, correct the errors and try again • Report - restore the system state to its previous state, report the problem, do not provide the service SE course, Software Design

37. Fault Prevention and Fault Tolerance • Difference between fault and failure ?! can lead to can lead to error human fault failure SE course, Software Design

38. Special systems require special design • Safety-critical real-time embedded systems • Safety - “Absence of catastrophic consequences on the users and the environment” • Property depends on • Environment • Use of the system • Consequently, software is only hazardous in a context • It is a system behavior Safety is an attribute of a more general property: Dependability SE course, Software Design

39. Dependability • Ability of a system to deliver service that can justifiably be trusted • Ability of a system to avoid failures that are more frequent or more severe than is acceptable to user(s) Related to • Trustworthiness (assurance that a system will perform as expected) SE course, Software Design

40. Ability to Undergo repairs and evolutions Absence of improper system alternations Absence of unauthorized disclosure of information Absence of catastrophic consequences Continuity of services Readiness for usage Availability Reliability Safety Confidentiality Integrity Maintainability Dependability Attributes of Dependability SE course, Software Design

41. Dependability (Extension definition) Dependability Safety-critical systems Mission-critical systems Business-critical systems NASA Arianne Industrial systems Information systems Traffic control systems Airplanes Cars Nuclear power stations …… Traffic control systems Energy supply and distribution systems?? Telecommunication systems??? SE course, Software Design

42. Availability Reliability Safety Confidentiality Integrity Maintainability Attributes Faults Errors Failures Dependability Threats Fault Prevention Fault Tolerance Fault Removal Fault Forecasting Means SE course, Software Design

43. The means to attain the dependability Fault Prevention How to prevent occurrence or introduction of faults Fault Tolerance How to deliver correct service in the presence of faults Fault Removal How to reduce the number of severity of faults Fault Forecasting How to estimate the present number, the future incidents, the probability of different consequences SE course, Software Design

44. Fault Tolerance Error detection concurrent error detection preemptive error detection Recovery error handling (rollback, rollforward) Fault handling fault diagnosis Fault isolation System reconfiguration system re-initialization Fault masking (redundancy) SE course, Software Design

45. Fault detection and Fault management • Passive fault detection - when we design the system and do some actions when a failure occurs during the code execution • Active fault detection - we periodically check for symptoms of faults • mutual suspicion - each component assumes that the other components contain faults • Avoid faults by using redundancy • n-version programming - different teams design and implement the same system /space shuttle) • Fault correction • Fix the problems - design the system to fix the faults (wrong data - checksum,…) • Fault tolerance • Correcting a fault is to expensive and risky - we minimize the damage SE course, Software Design

46. isTriangle(X1,X2,X3) • {Xi, Xj ,Xk} : Xi+Xj >Xk i,j,k Î {1,2,3}, i ≠k ≠j, Xi Î R+ SE course, Software Design

47. Fault-tree analysis • Look for situations where a failure can occur (wrong name fault-tree!) • Build fault trees that display the logical path from effect to cause • Steps • identify possible failures (guidewords can be used) • Build a graph whose nodes are failures • Create a tree designated as “cut-set” tree to find single points of failure SE course, Software Design

48. Guidewords for identifying possible failures Guideword Interpretation no No data or signal was sent or received more The volume of data is too much or too fast less The volume of data is too low or too slow part of The data or signal is incomplete other then The data or signal has another component early The signal arrives too early late The signal arrives too late … …. SE course, Software Design

49. OR AND Failure graphs Cooling systemOverflow Failure Either event can occur Fill mode remains on Valve stuck in open position Both events must occur Basic events Timeoutcontrolfails Sensor fails SE course, Software Design

50. G1 G4 G5 G1 G3 G3 G2 G2 Cut-set graphs Cut-set is the set of leaf nodes of the cut-set tree, with duplicates removed or and G4,G5 A4,A5 A5 A1,G5 A2,G5 A1 A2 A3 A4 A1,A3 A1,A4 A2, A3 A2, A4 Ai, Aj Happens only when both Ai and Aj occur SE course, Software Design