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

2. Design Models – 1 Data Design Architectural Design Interface 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
11/11/2018

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
11/11/2018

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
11/11/2018

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
11/11/2018

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
11/11/2018

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
11/11/2018

8. Design Concepts -1 Abstraction Software Architecture
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
11/11/2018

9. Design Concepts -2 Design Patterns Modularity
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
11/11/2018

10. Design Concepts -3 Information Hiding Functional Independence
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/11/2018

11. Design Concepts -4 Refinement Refactoring
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
11/11/2018

12. Design Concepts - 4 Objects Class Inheritance
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
11/11/2018

13. Design Concepts - 5 Messages Polymorphism
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
11/11/2018

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)
11/11/2018

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
11/11/2018

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

17. Control Terminology - 1 Span of control Depth Fan-out or width
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
11/11/2018

18. Control Terminology - 2 Fan-in Visibility Connectivity
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
11/11/2018

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
11/11/2018

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).
11/11/2018

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

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.
11/11/2018

23. Cohesion Coincidental cohesion. Logical cohesion. Temporal cohesion.
Procedural cohesion.
Communicational cohesion.
Sequential cohesion.
Functional cohesion.
11/11/2018

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.
11/11/2018

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).
11/11/2018

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.
11/11/2018

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).
11/11/2018

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
11/11/2018

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
11/11/2018

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)
11/11/2018

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
11/11/2018

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