Unit III

Software Engineering
Unit III: Design Engineering

Purpose of Design
• Design is where customer requirements, business needs, and technical
considerations all come together in the formulation of a product or system
• The design model provides detail about the software data structures, architecture,
interfaces, and components
• The design model can be assessed for quality and be improved before code is
generated and tests are conducted
– Does the design contain errors, inconsistencies, or omissions?
– Are there better design alternatives?
– Can the design be implemented within the constraints, schedule, and cost
that have been established?
• A designer must practice diversification and convergence
– The designer selects from design components, component solutions, and

knowledge available through catalogs, textbooks, and experience
– The designer then chooses the elements from this collection that meet the
requirements defined by requirements engineering and analysis modelling
– Convergence occurs as alternatives are considered and rejected until one

particular configuration of components is chosen
• Software design is an iterative process through which requirements are translated

into a blueprint for constructing the software
– Design begins at a high level of abstraction that can be directly traced back
to the data, functional, and behavioral requirements
– As design iteration occurs, subsequent refinement leads to design

representations at much lower levels of abstraction
From Analysis Model to Design Model:

Computer Science Shift II Page 52
• Each element of the analysis model provides information that is necessary to

create the four design models
– The data/class design transforms analysis classes into design classes along
with the data structures required to implement the software
– The architectural design defines the relationship between major structural

elements of the software; architectural styles and design patterns help
achieve the requirements defined for the system
– The interface design describes how the software communicates with

systems that interoperate with it and with humans that use it
– The component-level design transforms structural elements of the software

architecture into a procedural description of software components

Task
k Set for Software Design
Design:
1) Examine the information domain model and design appropriate data structures
for data objects and their attributes
2) Using the analysis model, select an architectural style (and design patterns) that
are appropriate for the software
3) Partition the analysis model into design subsystems and allocate these subsystems
within the architecture
a) Design the subsystem interfaces
b) Allocate analysis classes or functions to each subsystem
4) Create a set of design classes or components
a) Translate each analysis class description into a design class
b) Check each design class against design criteria; consider inheritance issues

c) Define methods associated with each design class
d) Evaluate and select design patterns for a design class or subsystem
5) Design any interface required with external systems or devices
6) Design the user interface
7) Conduct component-level design
a) Specify all algorithms at a relatively low level of abstraction
b) Refine the interface of each component
c) Define component-level data structures
d) Review each component and correct all errors uncovered
8) Develop a deployment model
a) Show a physical layout of the system, revealing which components will be

located where in the physical computing environment
Design Quality:
Quality's Role
• The importance of design is quality
• Design is the place where quality is fostered
– Provides representations of software that can be assessed for quality
– Accurately translates a customer's requirements into a finished software

product or system
– Serves as the foundation for all software engineering activities that follow
• Without design, we risk building an unstable system that
– Will fail when small changes are made
– May be difficult to test

– Cannot be assessed for quality later in the software process when time is
short and most of the budget has been spent
• The quality of the design is assessed through a series of formal technical reviews
or design walkthroughs
Goals of a Good Design
• The design must implement all of the explicit requirements contained in the
analysis model
– It must also accommodate all of the implicit requirements desired by the

customer
• The design must be a readable and understandable guide for those who generate
code, and for those who test and support the software
• The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective
Design Quality Guidelines
1) A design should exhibit an architecture that
a) Has been created using recognizable architectural styles or patterns
b) Is composed of components that exhibit good design characteristics
c) Can be implemented in an evolutionary fashion, thereby facilitating

implementation and testing
2) A design should be modular; that is, the software should be logically partitioned
into elements or subsystems
3) A design should contain distinct representations of data, architecture, interfaces,

and components
4) A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns

5) A design should lead to components that exhibit independent functional
characteristics
6) A design should lead to interfaces that reduce the complexity of connections

between components and with the external environment
7) A design should be derived using a repeatable method that is driven by

information obtained during software requirements analysis
8) A design should be represented using a notation that effectively communicates its

meaning
Design Concepts
• Abstraction
– Procedural abstraction – a sequence of instructions that have a specific and

limited function
– Data abstraction – a named collection of data that describes a data object
• Architecture
– The overall structure of the software and the ways in which the structure
provides conceptual integrity for a system
– Consists of components, connectors, and the relationship between them
• Patterns
– A design structure that solves a particular design problem within a specific

context
– It provides a description that enables a designer to determine whether the

pattern is applicable, whether the pattern can be reused, and whether the
pattern can serve as a guide for developing similar patterns
• Modularity
– Separately named and addressable components (i.e., modules) that are

integrated to satisfy requirements (divide and conquer principle)

– Makes software intellectually manageable so as to grasp the control paths,
span of reference, number of variables, and overall complexity
• Information hiding
– The designing of modules so that the algorithms and local data contained
within them are inaccessible to other modules
– This enforces access constraints to both procedural (i.e., implementation)

detail and local data structures
• Functional independence
– Modules that have a "single-minded" function and an aversion to excessive

interaction with other modules
– High cohesion – a module performs only a single task
– Low coupling – a module has the lowest amount of connection needed

with other modules
• Stepwise refinement
– Development of a program by successively refining levels of procedure

detail
– Complements abstraction, which enables a designer to specify procedure

and data and yet suppress low-level details
• Refactoring
– A reorganization technique that simplifies the design (or internal code

structure) of a component without changing its function or external
behavior
– Removes redundancy, unused design elements, inefficient or unnecessary

algorithms, poorly constructed or inappropriate data structures, or any
other design failures
• Design classes

– Refines the analysis classes by providing design detail that will enable the
classes to be implemented
– Creates a new set of design classes that implement a software

infrastructure to support the business solution
Types of Design Classes
• User interface classes – define all abstractions necessary for human-computer

interaction (usually via metaphors of real-world objects)
• Business domain classes – refined from analysis classes; identify attributes and
services (methods) that are required to implement some element of the business
domain
• Process classes – implement business abstractions required to fully manage the

business domain classes
• Persistent classes – represent data stores (e.g., a database) that will persist
beyond the execution of the software
• System classes – implement software management and control functions that

enable the system to operate and communicate within its computing environment
and the outside world

The Design Model
• The design model can be viewed in two different dimensions
– (Horizontally) The process dimension indicates the evolution of the parts

of the design model as each design task is executed
– (Vertically) The abstraction dimension represents the level of detail as each

element of the analysis model is transformed into the design model and
then iteratively refined
• Elements of the design model use many of the same UML diagrams used in the
analysis model
– The diagrams
ams are refined and elaborated as part of the design
– More implementation
mplementation-specific detail is provided
– Emphasis is placed on
• Architectural structure and style
• Interfaces between components and the outside world
• Components that reside within the architectur

architecture

• Design model elements are not always developed in a sequential fashion
– Preliminary architectural design sets the stage
– It is followed by interface design and component-level design, which often

occur in parallel
• The design model has the following layered elements
– Data/class design
– Architectural design
– Interface design
– Component-level design
• A fifth element that follows all of

the others is deployment-level design
Design Elements
• Data/class design
– Creates a model of data and objects that is represented at a high level of

abstraction
• Architectural design
– Depicts the overall layout of the software
• Interface design
– Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the architecture
– Includes the user interface, external interfaces, and internal interfaces
• Component-level design elements
– Describes the internal detail of each software component by way of data

structure definitions, algorithms, and interface specifications

• Deployment-level design elements
– Indicates how software functionality and subsystems will be allocated

within the physical computing environment that will support the software
Pattern-based Software Design
• Mature engineering disciplines make use of thousands of design patterns for such
things as buildings, highways, electrical circuits, factories, weapon systems,
vehicles, and computers
• Design patterns also serve a purpose in software engineering
• Architectural patterns
– Define the overall structure of software
– Indicate the relationships among subsystems and software components
– Define the rules for specifying relationships among software elements
• Design patterns
– Address a specific element of the design such as an aggregation of

components or solve some design problem, relationships among
components, or the mechanisms for effecting inter-component
communication
– Consist of creational, structural, and behavioral patterns
• Coding patterns
– Describe language-specific patterns that implement an algorithmic or data

structure element of a component, a specific interface protocol, or a
mechanism for communication among components
Software architecture
Definitions

• The software architecture of a program or computing system is the structure or
structures of the system which comprise
– The software components
– The externally visible properties of those components
– The relationships among the components
• Software architectural design represents the structure of the data and program
components that are required to build a computer-based system
• An architectural design model is transferable
– It can be applied to the design of other systems
– It represents a set of abstractions that enable software engineers to describe

architecture in predictable ways
Architectural Design Process
• Basic Steps
– Creation of the data design
– Derivation of one or more representations of the architectural structure of

the system
– Analysis of alternative architectural styles to choose the one best suited to

customer requirements and quality attributes
– Elaboration of the architecture based on the selected architectural style
• A database designer creates the data architecture for a system to represent the
data components
• A system architect selects an appropriate architectural style derived during

system engineering and software requirements analysis
Emphasis on Software Components
• A software architecture enables a software engineer to

– Analyze the effectiveness of the design in meeting its stated requirements
– Consider architectural alternatives at a stage when making design changes

is still relatively easy
– Reduce the risks associated with the construction of the software
• Focus is placed on the software component
– A program module
– An object-oriented class
– A database
– Middleware
Importance of Software Architecture
• Representations of software architecture are an enabler for communication

between all stakeholders interested in the development of a computer-based
system
• The software architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows and, as important,
on the ultimate success of the system as an operational entity
• The software architecture constitutes a relatively small, intellectually graspable

model of how the system is structured and how its components work together

Data Design
Purpose of Data Design
• Data design translates data objects defined as part of the analysis model into
– Data structures at the software component level
– A possible database architecture at the application level
• It focuses on the representation of data structures that are directly accessed by

one or more software components
• The challenge is to store and retrieve the data in such way that useful information
can be extracted from the data environment
"Data quality is the difference between a data warehouse and a data garbage dump
Data Design Principles
• The systematic analysis principles that are applied to function and behavior
should also be applied to data
• All data structures and the operations to be performed on each one should be
identified
• A mechanism for defining the content of each data object should be established
and used to define both data and the operations applied to it
• Low-level data design decisions should be deferred until late in the design
process
• The representation of a data structure should be known only to those modules

that must make direct use of the data contained within the structure
• A library of useful data structures and the operations that may be applied to them
should be developed
• A software programming language should support the specification and

realization of abstract data types

Software Architectural Styles
• The software that is built for computer
computer-based
based systems exhibit one of many
architectural styles
• Each style describes a system category that encompasses
– A set of component types that perform a function required by the system
– A set of connectors (subroutine call, remote procedure call, data stream,

socket) that enable communication, coordination, and cooperation among
components
– Semantic constraints that define how components can be integrated to form

the system
– A topological layout of the components indicating their runtime

interrelationships
relationships

Data Flow Style
• Has the goal of modifiability
• Characterized by viewing the system as a series of transformations on successive

pieces of input data
• Data enters the system and then flows through the components one at a time until
they are assigned to output or a data store
• Batch sequential style
– The processing steps are independent components

– Each step runs to completion before the next step begins
• Pipe-and-filter style
– Emphasizes the incremental transformation of data by successive

components
– The filters incrementally transform the data (entering and exiting via
streams)
– The filters use little contextual information and retain no state between
instantiations
– The pipes are stateless and simply exist to move data between filters
• Advantages
– Has a simplistic design in the limited ways in which the components

interact with the environment
– Consists of no more and no less than the construction of its parts
– Simplifies reuse and maintenance
– Is easily made into a parallel or distributed execution in order to enhance

system performance
• Disadvantages
– Implicitly encourages a batch mentality so interactive applications are

difficult to create in this style
– Ordering of filters can be difficult to maintain so the filters cannot

cooperatively interact to solve a problem
– Exhibits poor performance
• Filters typically force the least common denominator of data

representation (usually ASCII stream)

• Filter may need unlimited buffers if they cannot start producing
output until they receive all of the input
• Each filter operates as a separate process or procedure call, thus

incurring overhead in set
set-up and take-down time
Call-and-Return Style
• Has the goal of modifiability and scalability
• Has been the dominant architecture since the start of software development
• Main program and subroutine style
– Decomposes a program hierarchically into small pieces (i.e., modules)
– Typically has a single thread of control that travels through various

components in the hierarchy
• Remote procedure call style
– Consists of main
in program and subroutine style of system that is
decomposed into parts that are resident on computers connected via a
network
– Strives to increase performance by distributing the computations and

taking advantage of multiple processors

– Incurs a finite communication time between subroutine call and response
• Object-oriented or abstract data type system
– Emphasizes the bundling of data and how to manipulate and access data
– Keeps the internal data representation hidden and allows access to the
object only through provided operations
– Permits inheritance and polymorphism
• Layered system
– Assigns components to layers in order to control inter-component

interaction
– Only allows a layer to communicate with its immediate neighbor
– Assigns core functionality such as hardware interfacing or system kernel

operations to the lowest layer
– Builds each successive layer on its predecessor, hiding the lower layer and
providing services for the upper layer
– Is compromised by layer bridging that skips one or more layers to improve

runtime performance
• Use this style when the order of computation is fixed, when interfaces are
specific, and when components can make no useful progress while awaiting the
results of request to other components

Data-Centered Style
• Has the goal of integrating the data
• Refers to systems in which the access and update of a widely accessed data store
occur
• A client runs on an independent thread of control
• The shared data may be a passive repository or an active blackboard
– A blackboard notifies subs

subscriber
criber clients when changes occur in data of
interest
• At its heart is a centralized data store that communicates with a number of clients
• Clients are relatively independent of each other so they can be added, removed,
or changed in functionality
• The data store is independent of the clients

• Use this style when a central issue is the storage, representation, management,
and retrieval of a large amount of related persistent data
• Note that this style becomes client/server if the clients are modeled as
independent
ent processes
Virtual Machine Style
• Has the goal of portability
• Software systems in this style simulate some functionality that is not native to the
hardware and/or software on which it is implemented
– Can simulate and test hardware platforms that have not yet been built
– Can simulate "disaster modes" as in flight simulators or safety

safety-critical
systems that would be too complex, costly, or dangerous to test with the
real system
• Examples include interpreters, rule

rule-based
based systems, and command language
processors
• Interpreters
– Add flexibility through the ability to interrupt and query the program and
introduce modifications at runtime

– Incur a performance cost because of the additional computation involved in
execution
• Use this style when you have developed a program or some form of computation
but have no make of machine to directly run it on
Architectural Design Process
Architectural Design Steps
1) Represent the system in context
2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system
1. Represent the System in Context
• Use an architectural context diagram (ACD) that shows
– The identification and flow of all information into and out of a system
– The specification of all interfaces
– Any relevant support processing from/by other systems
• An ACD models the manner in which software interacts with entities external to
its boundaries
• An ACD identifies systems that interoperate with the target system
– Super-ordinate systems
• Use target system as part of some higher level processing scheme
– Sub-ordinate systems

• Used by target system and provide necessary data or processing
– Peer-level systems
• Interact on a peer-to-peer basis with target system to produce or

consume data
– Actors
• People or devices that interact with target system to produce or

consume data
2. Define Archetypes
• Archetypes indicate the important abstractions within the problem domain (i.e.,
they model information)
• An archetype is a class or pattern that represents a core abstraction that is critical
to the design of an architecture for the target system
• It is also an abstraction from a class of programs with a common structure and
includes class-specific design strategies and a collection of example program
designs and implementations
• Only a relatively small set of archetypes is required in order to design even
relatively complex systems
• The target system architecture is composed of these archetypes
– They represent stable elements of the architecture
– They may be instantiated in different ways based on the behavior of the
system
– They can be derived from the analysis class model
The archetypes and their relationships can be illustrated in a UML class diagram

Example Archetypes in Software Architecture
• Node
• Detector/Sensor
• Indicator
• Controller
• Manager
• Moment-Interval
• Role
• Description
• Party, Place, or Thing
3. Refine the architecture into components
• Based on the archetypes, the architectural designer refines the software

architecture into components to illustrate the overall structure and architectural
style of the system
• These components are derived from various sources
– The application domain provides application components, which are the
domain classes in the analysis model that represent entities in the real
world
– The infrastructure domain provides design components (i.e., design
classes) that enable application components but have no business
connection
• Examples: memory management, communication, database, and task
management
– The interfaces in the ACD imply one or more specialized components that
process the data that flow across the interface
• A UML class diagram can represent the classes of the refined architecture and
their relationships

4. Describe Instantiations of the System
• An actual instantiation of the architecture is developed by applying it to a specific

problem
• This demonstrates that the architectural structure, style and components are
appropriate
• A UML component diagram can be used to represent this instantiation
The Software Component
• A software component is a modular building block for computer software

– It is a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces
• A component communicates and collaborates with
– Other components
– Entities outside the boundaries of the system
• Three different views of a component
– An object-oriented view
– A conventional view
– A process-related view
Object-oriented View
• A component is viewed as a set of one or more collaborating classes

• Each problem domain (i.e., analysis) class and infrastructure (i.e., design) class is
elaborated to identify all attributes and operations that apply to its
implementation
– This also involves defining the interfaces that enable classes to
communicate and collaborate
• This elaboration activity is applied to every component defined as part of the
architectural design

• Once this is completed, the following steps are performed
– Provide further elaboration of each attribute, operation, and interface
– Specify the data structure appropriate for each attribute
– Design the algorithmic detail required to implement the processing logic
associated with each operation
– Design the mechanisms required to implement the interface to include the
messaging that occurs between objects
Conventional View
• A component is viewed as a functional element (i.e., a module) of a program that

incorporates
– The processing logic
– The internal data structures that are required to implement the processing
logic
– An interface that enables the component to be invoked and data to be
passed to it
• A component serves one of the following roles
– A control component that coordinates the invocation of all other problem
domain components
– A problem domain component that implements a complete or partial
function that is required by the customer
– An infrastructure component that is responsible for functions that support
the processing required in the problem domain
• Conventional software components are derived from the data flow diagrams
(DFDs) in the analysis model
– Each transform bubble (i.e., module) represented at the lowest levels of the
DFD is mapped into a module hierarchy
– Control components reside near the top
– Problem domain components and infrastructure components migrate
toward the bottom
– Functional independence is strived for between the transforms
• Once this is completed, the following steps are performed for each transform

– Define the interface for the transform (the order, number and types of the
parameters)
– Define the data structures used internally by the transform
– Design the algorithm used by the transform (using a stepwise refinement
approach)
Process-related View
• Emphasis is placed on building systems from existing components maintained in

a library rather than creating each component from scratch
• As the software architecture is formulated, components are selected from the
library and used to populate the architecture
• Because the components in the library have been created with reuse in mind, each
contains the following:
– A complete description of their interface
– The functions they perform
– The communication and collaboration they require
Component-level Design Principles
• Open-closed principle
– A module or component should be open for extension but closed for
modification
– The designer should specify the component in a way that allows it to be
extended without the need to make internal code or design modifications to
the existing parts of the component
• Liskov substitution principle
– Subclasses should be substitutable for their base classes
– A component that uses a base class should continue to function properly if
a subclass of the base class is passed to the component instead
• Dependency inversion principle
– Depend on abstractions (i.e., interfaces); do not depend on concretions

– The more a component depends on other concrete components (rather than
on the interfaces) the more difficult it will be to extend
• Interface segregation principle
– Many client-specific interfaces are better than one general purpose
interface
– For a server class, specialized interfaces should be created to serve major
categories of clients
– Only those operations that are relevant to a particular category of clients
should be specified in the interface
Component Packaging Principles
• Release reuse equivalency principle

– The granularity of reuse is the granularity of release
– Group the reusable classes into packages that can be managed, upgraded,
and controlled as newer versions are created
• Common closure principle
– Classes that change together belong together
– Classes should be packaged cohesively; they should address the same
functional or behavioral area on the assumption that if one class
experiences a change then they all will experience a change
• Common reuse principle
– Classes that aren't reused together should not be grouped together
– Classes that are grouped together may go through unnecessary integration
and testing when they have experienced no changes but when other classes
in the package have been upgraded
Cohesion
• Cohesion is the “single-mindedness’ of a component

• It implies that a component or class encapsulates only attributes and operations
that are closely related to one another and to the class or component itself
• The objective is to keep cohesion as high as possible

• The kinds of cohesion can be ranked in order from highest (best) to lowest
(worst)
– Functional
• A module performs one and only one computation and then returns a
result
– Layer
• A higher layer component accesses the services of a lower layer
component
– Communicational
• All operations that access the same data are defined within one class
Kinds of cohesion
– Sequential
• Components or operations are grouped in a manner that allows the
first to provide input to the next and so on in order to implement a
sequence of operations
– Procedural
• Components or operations are grouped in a manner that allows one
to be invoked immediately after the preceding one was invoked,
even when no data passed between them
– Temporal
• Operations are grouped to perform a specific behavior or establish a
certain state such as program start-up or when an error is detected
– Utility
• Components, classes, or operations are grouped within the same
category because of similar general functions but are otherwise
unrelated to each other
Coupling
• As the amount of communication and collaboration increases between operations

and classes, the complexity of the computer-based system also increases

• As complexity rises, the difficulty of implementing, testing, and maintaining
software also increases
• Coupling is a qualitative measure of the degree to which operations and classes
are connected to one another
• The objective is to keep coupling as low as possible
• The kinds of coupling can be ranked in order from lowest (best) to highest
(worst)
– Data coupling
• Operation A() passes one or more atomic data operands to operation
B(); the less the number of operands, the lower the level of coupling
– Stamp coupling
• A whole data structure or class instantiation is passed as a parameter
to an operation
– Control coupling
• Operation A() invokes operation B() and passes a control flag to B
that directs logical flow within B()
• Consequently, a change in B() can require a change to be made to
the meaning of the control flag passed by A(), otherwise an error
may result
– Common coupling
• A number of components all make use of a global variable, which
can lead to uncontrolled error propagation and unforeseen side
effects
– Content coupling
• One component secretly modifies data that is stored internally in
another component
Designing Conventional Components

• Conventional design constructs emphasize the maintainability of a
functional/procedural
unctional/procedural program
– Sequence, condition, and repetition
• Each construct has a predictable logical structure where control enters at the top
and exits at the bottom, enabling a maintainer to easily follow the procedural
flow
• Various notations depict the use of these constructs
– Graphical design notation
• Sequence, if if-then-else, selection, repetition
ion (see next slide)
– Tabular design notation (see upcoming slide)
– Program design language
• Similar to a programming language; however, it uses narrative text
embedded directly within the program statements
Graphical Design Notation

Tabular Design Notation
1) List all actions that can be associated with a specific procedure (or module)
2) List all conditions (or decisions made) during execution of the procedure
3) Associate specific sets of conditions with specific actions, eliminating impossible
combinations of conditions; alternatively, develop every possible permutation of
conditions
4) Define rules by indicating what action(s) occurs for a set of conditions

Conditions 1 2 3 4
Condition A T T F
Condition B F T
Condition C T T
Actions
Action X
Action Y
Action Z

Unit III

Uploaded by

Copyright:

Available Formats

Unit III

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit III

Uploaded by

Copyright:

Available Formats

Software Engineering

Unit III: Design Engineering

– Does the design contain errors, inconsistencies, or omissions?

– Are there better design alternatives?

• A designer must practice diversification and convergence

– The designer selects from design components, component solutions, and

– Convergence occurs as alternatives are considered and rejected until one

• Software design is an iterative process through which requirements are translated

– As design iteration occurs, subsequent refinement leads to design

From Analysis Model to Design Model:

• Each element of the analysis model provides information that is necessary to

– The architectural design defines the relationship between major structural

– The interface design describes how the software communicates with

– The component-level design transforms structural elements of the software

Computer Science Shift II Page 53

a) Design the subsystem interfaces

b) Allocate analysis classes or functions to each subsystem

4) Create a set of design classes or components

a) Translate each analysis class description into a design class

Computer Science Shift II Page 54

d) Evaluate and select design patterns for a design class or subsystem

5) Design any interface required with external systems or devices

6) Design the user interface

7) Conduct component-level design

a) Specify all algorithms at a relatively low level of abstraction

b) Refine the interface of each component

c) Define component-level data structures

d) Review each component and correct all errors uncovered

8) Develop a deployment model

a) Show a physical layout of the system, revealing which components will be

• The importance of design is quality

• Design is the place where quality is fostered

– Provides representations of software that can be assessed for quality

– Accurately translates a customer's requirements into a finished software

• Without design, we risk building an unstable system that

– Will fail when small changes are made

– May be difficult to test

Computer Science Shift II Page 55

Goals of a Good Design

– It must also accommodate all of the implicit requirements desired by the

Design Quality Guidelines

1) A design should exhibit an architecture that

a) Has been created using recognizable architectural styles or patterns

b) Is composed of components that exhibit good design characteristics

c) Can be implemented in an evolutionary fashion, thereby facilitating

3) A design should contain distinct representations of data, architecture, interfaces,

Computer Science Shift II Page 56

6) A design should lead to interfaces that reduce the complexity of connections

7) A design should be derived using a repeatable method that is driven by

8) A design should be represented using a notation that effectively communicates its

– Procedural abstraction – a sequence of instructions that have a specific and

– Data abstraction – a named collection of data that describes a data object

– Consists of components, connectors, and the relationship between them

– A design structure that solves a particular design problem within a specific

– It provides a description that enables a designer to determine whether the

– Separately named and addressable components (i.e., modules) that are

Computer Science Shift II Page 57

– This enforces access constraints to both procedural (i.e., implementation)

– Modules that have a "single-minded" function and an aversion to excessive

– High cohesion – a module performs only a single task