Lecture 6 Software Design

1. CS 540 – Quantitative Software Engineering Lecture 6 Software Design Architecture is synthesis Design is analysis

2. It encompasses the requirements, architecture and high level design phases of the typical waterfall diagram. It also continues throughout the life of the project (someone continues to wear the architect’s hat). Prospectus Iterative process until consensus is reached Requirements Carries through the life of the project Architecture High Level Design Software Design in a Project’s Life Cycle Planning and Architecture Phase Discovery Review Low Level Architecture Design Review

3. Software Design Definition • “the process of defining the architecture, components, interfaces, and other characteristics of a system or component.” SWEBOK • “life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction.” • “fits between requirements and construction”

4. Software Design: Knowledge Areas (SWEBOK) • Fundamentals: concept, context, process, and enabling techniques • Key Issues • Software Structure: micro-architecture, patterns • Design Quality Analysis and Evaluation • Software Design Notation • Strategies and Methods

5. Software Design: Design Concepts • Abstraction: generalize without getting lost in details • Refinement: top-down elaboration • Modularity: divide and conquer • Control Hierarchy: flow diagram or tree structure of processes • Data structure description

6. Software Design: Key Issues • Concurrency: processes, tasks and threads • Control: data flow, event handling, sub-component calls • Distribution of components: interfaces, middleware interactions • Error and Exception Handling: fault tolerance and error routing • Interaction and presentation: (not user interface design) • Data Persistence: what is stored, derived, or computed

7. Software Design: Design Patterns • Recurring structure of communicating components • Distributed systems, interactive systems, batch, interpreters, process control • Micro architectures • Differs from architectural style in scope, not structure

8. Pattern Attributes • Different ‘look and feel’ must not impact application code • Capture well-proven design experience • Capture meta abstractions beyond a component • Document, describe and prescribe

9. Component Types

10. Software Design: Desired Attributes • Consistent with architecture • Modular (partitioned) • Consistent with data structures, objects, and patterns • Functional completeness • Interface complexity reduction • Driven by requirements (traceable)

11. Quality of design metrics • Modularity • Information hiding • Coupling • System structure • Run Time: performance, security, functionality, usability) • Non-Run Time: maintainability, testability, portability, reusability

12. Quality Analysis and Evaluation • Software Design Reviews • Initiated by NASA after 1967 Apollo fire • Bell Labs (management layers) and IBM (issue tracking) • Topics: modules, control structure, data flow, performance, interfaces, testability, impacted documentation, effort estimates, simplicity review, schedule review • Static Analysis: pseudo-code flows • Simulation and prototyping

13. Software Design Notation • Structural • Class and object diagrams, entity relationship diagrams, interface descriptor languages (IDLs), structure charts (module calling structure) • Dynamic • Activity • Data Flow diagrams (DFD’s) • Decision tables (conditions and actions) • Flow charts • Sequence, state transitions, pseudo code (program design languages)

14. Software Design: Strategies and Methods • General: top-down, divide and conquer, stepwise refinement, etc • Function oriented structured design (classic) • Data flow diagrams • Transform analysis (I/O) • Transaction analysis • Object-oriented design • Data-Structure Centered Design

15. Design Methods • Functional decomposition • Data flow design - functional decomposition with respect to flow of data. Component is a black box transforming some input stream to an output stream • Design based on data structures - given a correct model of data structures, design of the program is straightforward • Object-oriented design

16. Functional Decomposition • Intended function decomposed into sub functions and continues downward • Start from user end it is top-down, primitives, bottom-up • Parnas method: • Identify sub systems, start with a minimal subset and define minimal extensions (incremental development) • Apply information hiding principles • Define extensions step by step • Apply uses relation and try to develop a hierarchy • Layered approach, use only components at the same or lower level

17. Yourdon and Constantine, 7 (+1) levels of Cohesion Levels are of increasing strength: • Coincidental- modules grouped in haphazard way, no relation • Logical - logically related tasks that do not call each other or pass data between each other - all output routines • Temporal - various independent components activated at same time - initialization • Procedural- group of components executed in a set order • Communicational - components operate on the same temporal data • Sequential- output of one serves as input to another • Functional all components contribute to a single function in the module • + data - modules that encapsulate an abstract data type

18. Coupling Tightest to loosest (worst to best): • Content- one module controls another’s execution • Common- modules share data • External modules communicate through external media (a file) • Control - one module directs execution of another by passing necessary control information via flags • Stamp - complete data structures are passed from one to another • Data only -single data item passed between modules

19. Coupling and cohesion • Advantages of low coupling, high cohesion: • Communication between developers is easier • Correctness proofs are easy to derive and sustain • Changes will not affect other modules, lower maintenance costs • Reusability is increased • Understanding increase • Empirical data shows less errors.

20. Complexity • Attributes of the software that affect effort needed to construct or change a piece of software • 2 classes of complexity metrics • Size based - KLOC • Structure based - complicated control or data structures • Halstead and McCabe

21. System Structure • Types of intermodule relations such as A contains B, A follows B, A delivers data to B, A uses B • The amount of knowledge each uses about the other should be kept to a minimum • Information flow should be limited to procedure calls - no Common data structures • Graph depicting procedure calls is a call graph - we can measure attributes related to the shape of the call graph

22. Module Hierarchies Directed graph Directed non-cyclic graph Layered graph Tree

23. Graph analysis • Some measures: • Size - number of nodes and edges • Depth - longest path from root to leaf • Width - maximum nodes at some level • A good design should have a tree-like call graph • One measure of complexity is to assess tree impurity • Remove edges until you get a tree • Tree impurity = # of extra edges / maximum # of extra edges • If 0 graph is a tree, if 1 it is a complete graph • But trees are not always desirable, does not permit reuse • Fan in fan out measures indicates spots deserving attention, e.g., if a module has high fan in it may indicate little cohesion, excessive increase in information flow from one level to next may indicate missing level of abstraction

24. Design Heuristics for Modularity(Pressman) • Evaluate the first iteration of a program structure to reduce coupling and improve cohesion • Attempt to minimize structures with high fan out; strive for high fan in as depth increases • Keep the scope of effect of a module within the scope of control of that module • Evaluate module interfaces to reduce complexity and redundancy and improve consistency • Define modules whose function is predictable, but avoid modules that are overly restrictive • Strive for controlled entry modules by avoiding pathological conditions (branches or references into the middle of a module)

25. View on Design

26. OO Analysis and Design • Traditional techniques focus on functions of the system • OO focuses on identifying and interrelating the objects that play a role in the system • Convergence to UML, Unified Modeling Language, Booch, Jacobson and Rumbaugh • Heuristic thoughts- keep objects simple and each method should send messages to objects of a very limited set of classes (more when we explore OO metrics)

27. “Schools” of OO • European school, influenced by the Scandinavian school of Programming, OO analysis and design is modeling real world objects both animate and inanimate • American school, OO focuses on data abstraction and component reuse - identifying reusable components and building an inheritance hierarchy. • “What matters is not how closely we model today’s reality but how extensible and reusable our software is”

28. OO views • Modeling view - conceptual model of some part of a real or imaginary world. Object = identity + state + behavior • Philosophical view - objects are existential abstractions and if not instantiated they cannot be changed • Software Engineering view - data abstractions encapsulate data and operations

29. OO Analysis and Design schemes • Common notations of the schemes: • Class diagram - static depiction of objects as nodes and their relations as edges • State diagram - models dynamic behavior of single objects using a variant of a finite state machine representation. Nodes in state diagram represent state of object, edges possible transitions between states • Interaction diagrams - model sequence of messages in an interaction among objects • Sequence diagrams emphasize time orderings • Collaboration diagrams emphasize objects and their relationships relevant to a particular interaction

30. The Class Diagram • Shows the static structure which are elements of the model, usually classes, and relationships between them • Class diagram also represents subclass-superclass hierarchy - a hollow triangle indicates a generalization specialization relationship • Class boxes have 3 parts: name of object, list of attributes and list of services • UML permits indicating semantic constraints between classes {} • Disjoint constraint indicates that a descendant may not be descended from more than one of the superclasses • Overlapping constraints indicate that it may

31. Object hierarchy (12.2) furniture table chair HighChair EasyChair

32. State Diagram • Depict sequence of states an object progresses through • Have local variables and output actions that may be associated with both transitions and states • “Statesmanship” • A state is some condition in the life of an object • A change in state causes a transition to fire • Transition labeled by transition string • States may be nested for ease of exposition

33. State Diagram Rent/N:=N+1 Stop[N=0] is-member cleaning-up End Start/N:=0 Return/N:=N-1

34. Sequence Diagram • Shows time ordering of messages • Diagrams can become quite elaborate showing asynchronous and synchronous message passing, indicate iteration, …

35. Sequence Diagram (12.9) user catalog reservations 1:lookup 2: item name 3: [not available]reserve 4: item returned 5: hold item 5: item available 6: borrow item 6: remove reservation

36. Key Design Constraints • Limit the language features • Insist on Structured Programming • Modularity and Componentry • Provide Fault Containment and Recovery • Restrict Module Size • Perform scenario tests

37. Inspections • Probably the most significant step forward in defect removal prior to delivery which we have yet experienced • The evidence suggests that they are 5-10 times more efficient than any other form of defect removal. • The technology is mature, (some 20 years old), and in trained hands, exceptionally effective.

38. Conditions That Cause Software Instability • Poor Algorithms • Missing Deadlines • Round-off Error Build Up • Memory Leaks • Broken Pointers • Register Misuse