Software Design

1. Software Design CIS 375 Bruce R. Maxim UM-Dearborn

2. Design Models – 1 • Data Design • created by transforming the data dictionary and ERD into implementation data structures • requires as much attention as algorithm design • Architectural Design • derived from the analysis model and the subsystem interactions defined in the DFD • Interface Design • derived from DFD and CFD • describes software elements communication with • other software elements • other systems • human users

3. Design Models – 2 • Component-level design • created by transforming the structural elements defined by the software architecture into procedural descriptions of software components • Derived from information in the PSPEC, CSPEC, and STD

4. A Good Design Should - 1 • exhibit good architectural structure • be modular • contain distinct representations • data • architecture • interfaces • components (modules) • lead to data structures that are appropriate for the objects to be implemented

5. A Good Design Should - 2 • lead to interfaces that • reduce complexity of module connections • reduce complexity of connections to the external environment • be derived using a method driven by information during software requirements analysis

6. Design Principles - 1 • Process should not suffer from tunnel vision • Design should be traceable to analysis model • Do not try to reinvent the wheel • Try to minimize intellectual distance between the software and the real world problem • Design should exhibit both uniformity and integration • Should be structured to accommodate changes

7. Design Principles - 2 • Design is not coding and coding is not design • Should be structured to degrade gently, when bad data, events, or operating conditions are encountered • Needs to be assessed for quality as it is being created • Needs to be reviewed to minimize conceptual (semantic) errors

8. Design Concepts -1 • Abstraction • allows designers to focus on solving a problem without being concerned about irrelevant lower level details • procedural abstraction • data abstraction • Software Architecture • overall structure of the software components and the ways in which that structure • provides conceptual integrity for a system

9. Design Concepts -2 • Design Patterns • description of a design structure that solves a particular design problem within a specific context and its impact when applied • Modularity • the degree to which software can be understood by examining its components independently of one another

10. Design Concepts -3 • Information Hiding • information (data and procedure) contained within a module is inaccessible to modules that have no need for such information • Functional Independence • achieved by developing modules with single-minded purpose and an aversion to excessive interaction with other models

11. Design Concepts -4 • Refinement • process of elaboration where the designer provides successively more detail for each design component • Refactoring • process of changing a software system in such a way internal structure is improved without altering the external behavior or code design

12. Design Concepts - 4 • Objects • encapsulate both data and data manipulation procedures needed to describe the content and behavior of a real world entity • Class • generalized description (template or pattern) that describes a collection of similar objects • Inheritance • provides a means for allowing subclasses to reuse existing superclass data and procedures; also provides mechanism for propagating changes

13. Design Concepts - 5 • Messages • the means by which objects exchange information with one another • Polymorphism • a mechanism that allows several objects in an class hierarchy to have different methods with the same name • instances of each subclass will be free to respond to messages by calling their own version of the method

14. Design Concepts - 6 • Design Classes • refine analysis classes by providing detail needed to implement the classes and implement a software infrastructure the support the business solution (i.e. user interface classes, business domain classes, process classes, persistent classes, system classes)

15. Modular Design Methodology Evaluation - 1 • Modular decomposability • provides systematic means for breaking problem into subproblems • Modular composability • supports reuse of existing modules in new systems • Modular understandability • module can be understood as a stand-alone unit

16. Modular Design Methodology Evaluation - 2 • Modular continuity • module change side-effects minimized • Modular protection • processing error side-effects minimized

17. Control Terminology - 1 • Span of control • number of control levels within a software product • Depth • distance between the top and bottom modules in program control structure • Fan-out or width • number of modules directly controlled by a particular module

18. Control Terminology - 2 • Fan-in • number of modules that control a particular module • Visibility • set of program components that may be called or used as by a given component (either indirectly or directly) • Connectivity • set of components that are called directly or are used as data by a given component

19. Effective Modular Design • Functional independence • modules have high cohesion and low coupling • Cohesion • qualitative indication of the degree to which a module focuses on just one thing • Coupling • qualitative indication of the degree to which a module is connected to other modules and to the outside world

20. Types of Coupling • No direct coupling. • Data coupled (data structures). • Stamp coupling (parts of data structure). • Control coupling (flags, etc.). • External coupling (file format, database). • Common coupling. • Content coupling (references cross component boundaries).

21. Coupling Factors • Type of connection between modules. • Complexity of the interface. • Type of information flow. • Binding time of the connection.

22. Decoupling? • Start early in design process. • Convert implicit references. • Standardize connections. • Localize your variables. • Use buffers to moderate I/O to modules. • Avoid race conditions, no waiting.

23. Cohesion • Coincidental cohesion. • Logical cohesion. • Temporal cohesion. • Procedural cohesion. • Communicational cohesion. • Sequential cohesion. • Functional cohesion.

24. Promoting High Cohesion and Low Coupling • Small modules. • Control "fan out" (width of tree). • Focus on "fan in" (fan in = reuse). • Scope of effect should be a subset of scope of control. • Don’t make a major decision in the lower modules. • Control Depth.

25. Design Heuristics • Evaluate "first cut" to reduce coupling and increase cohesion. • Minimize "fan out" and focus on "fan in". • Scope of effect should be subset of scope of control. • Reduce complexity of interfaces and improve consistency. • Define modules with predictable behavior, but don’t be overly restrictive. • Strive for single entry, single exit modules. • Package software based on design constraints and portability requirements (e.g. how the modules fit together and work with one another).

26. Data Design Principles - 1 • Systematic analysis applied to functional behavior, can be applied to data. • Data structures and operations should be identified. • Establish a data dictionary and use it to guide both data and program design. • Defer low level data structure decisions until late in the design.

27. Data Design Principles - 2 • Information hiding. • Libraries of useful data structures and operators is developed. • Environment must support creation of ADT’s (abstract data types).

28. Architectural Design • Derived from • Information about the application domain relevant to software • Relationships and collaborations among specific analysis model elements • Availability of architectural patterns and styles • Usually depicted as a set of interconnected systems that are often derived from the analysis packages

29. Interface Design • Interface is a set of operations that describes the externally observable behavior of a class and provides access to its operations • Important elements • User interface (UI) • External interfaces to other systems • Internal interfaces between various design components • Modeled using UML collaboration diagrams

30. Component Level Design • Describes the internal detail of each software component • Defines • Data structures for all local data objects • Algorithmic detail for all component processing functions • Interface that allows access to all component operations • Modeled using UML component and activity diagrams, and pseudocode (PDL)

31. Using Patterns in Design • Architectural patterns • define overall structure and relationships of software components (classes, packages, subsystems) • Design patterns • address specific design elements (component aggregations, component relationships, or communication) • Idioms (coding patterns) • language specific implementations for algorithms or communications mechanisms

32. Design Pattern Template • Name • Intent • Aliases • Motivation • Applicability • Structure • Participants • Collaborators • Consequences • Related patterns