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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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