UNIT-3

Chapter -1
Design Concepts

Overview

A software design creates meaningful engineering representation (or model) of some software product that is to
be built. Designers must strive to acquire a repertoire of alternative design information and learn to choose the
elements that best match the analysis model. A design model can be traced to the customer's requirements and
can be assessed for quality against predefined criteria. During the design process the software requirements
model (data, function, behavior) is transformed into design models that describe the details of the data
structures, system architecture, interfaces, and components necessary to implement the system. Each design
product is reviewed for quality (i.e. identify and correct errors, inconsistencies, or omissions, whether better
alternatives exist, and whether the design model can be implemented within the project constraints) before
moving to the next phase of software development.

Software Design

 Encompasses the set of principles, concepts, and practices that lead to the development of a high quality
system or product
 Design principles establish and overriding philosophy that guides the designer as the work is performed
 Design concepts must be understood before the mechanics of design practice are applied
 Goal of design engineering is to produce a model or representation that is bug free (firmness), suitable for
its intended uses (commodity), and pleasurable to use (delight)
 Software design practices change continuously as new methods, better analysis, and broader understanding
evolve

Software Engineering Design /Design within the context of Software engineering:

 Data/Class design - created by transforming the analysis model class-based elements (class diagrams,
analysis packages, CRC models, collaboration diagrams) into classes and data structures required to
implement the software
 Architectural design - defines the relationships among the major structural elements of the software, it is
derived from the class-based elements and flow-oriented elements (data flow diagrams, control flow
diagrams, processing narratives) of the analysis model
 Interface design - describes how the software elements, hardware elements, and end-users communicate
with one another, it is derived from the analysis model scenario-based elements (use-case text, use-case
diagrams, activity diagrams, swim lane diagrams), flow-oriented elements, and behavioral elements (state
diagrams, sequence diagrams)
 Component-level design - created by transforming the structural elements defined by the software
architecture into a procedural description of the software components using information obtained from the
 analysis model class-based elements, flow-oriented elements, and behavioral elements.

Co m p o n e n t -
s c e n a ri o - b a s e d f lo w- o rie n t e d Le v e l D e s ig n
e le me nt s e le me nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
In t e rf a c e D e s ig n
Ana lys is Mode l

A rc h it e c t u ra l D e s ig n
c la ss- ba se d be ha v io ra l
e le me nt s e le me nt s
class diagrams s tate diagrams
analys is packages s equence diagrams
CRC models D a t a / Cla s s D e s ig n
collaboration diagrams

Design Mo del

Software design Process:

Software design is the process of implementing software solutions to one or more sets of problems. One of the
main components of software design is the software requirements analysis (SRA). SRA is a part of the
software development process that lists specifications used in software engineering.

Software design is the process of implementing software solutions to one or more sets of problems. One of the
main components of software design is the software requirements analysis (SRA). SRA is a part of the
software development process that lists specifications used in software engineering.

Software Quality Attributes

A good design must

 implement all explicit requirements from the analysis model and accommodate all implicit requirements
desired by the user
 be readable and understandable guide for those who generate code, test components, or support the system
 provide a complete picture (data, function, behavior) if the software from an implementation perspective.

Design Quality Guidelines

A design should
 exhibit an architecture that
o has been created using recognizable architectural styles or patterns
o is composed of components that exhibit good design characteristics
o can be implemented in an evolutionary manner
 be modular
 contain distinct representations of data, architecture, interfaces, and components (modules)
 lead to data structures that are appropriate for the objects to be implemented and be drawn from
recognizable design patterns
 lead to components that exhibit independent functional characteristics
 lead to interfaces that reduce the complexity of connections between modules and with the external
environment
 be derived using a repeatable method that is driven by information obtained during software requirements
analysis
 be represented using a notation that effectively communicates its meaning

FURPS Quality Factors or Attributes:

 Functionality – is assessed by evaluating the feature set and program capabilities and the security of the
overall system.
 Usability – human factors (aesthetics, consistency, documentation)
 Reliability – frequency and severity of failure, the accuracy of results, the mean -time-to-failure(MTTF),the
ability to recover from failure ,and the predictability of the program.
 Performance – processing speed, response time, throughput, efficiency.
 Supportability – maintainability (extensibility, adaptability, serviceability), testability, compatibility,
configurability.

Generic Task Set for Design

1. Examine information domain model and design appropriate data structures for data objects and their
attributes
2. Select an architectural pattern appropriate to the software based on the analysis model
3. Partition the analysis model into design subsystems and allocate these subsystems within the architecture
o Be certain each subsystem is functionally cohesive
o Design subsystem interfaces
o Allocate analysis class or functions to subsystems
4. Create a set of design classes
o Translate analysis class into design class
o Check each class against design criteria and consider inheritance issues
o Define methods and messages for each design class
o Evaluate and select design patterns for each design class or subsystem after considering alternatives
o Revise design classes and revise as needed
5. Design any interface required with external systems or devices
6. Design user interface
o Review task analyses
o Specify action sequences based on user scenarios
o Define interface objects and control mechanisms
o Review interface design and revise as needed
7. Conduct component level design
o Specify algorithms at low level of detail
o Refine interface of each component
o Define component level data structures
o Review components and correct all errors uncovered
8. Develop deployment model
Important Design Questions

 What criteria can be used to partition software into individual components?

 How is function or data structure detail separated from conceptual representation of the software?
 What uniform criteria define the technical quality of a software design?

Design Concepts

 Abstraction – allows designers to focus on solving a problem without being concerned about irrelevant
lower level details (procedural abstraction - named sequence of events and data abstraction – named
collection of data objects)
 Software Architecture – overall structure of the software components and the ways in which that structure
provides conceptual integrity for a system
o Structural models – architecture as organized collection of components
o Framework models – attempt to identify repeatable architectural patterns
o Dynamic models – indicate how program structure changes as a function of external events
o Process models – focus on the design of the business or technical process that system must
accommodate
o Functional models – used to represent system functional hierarchy
 Design Patterns – description of a design structure that solves a particular design problem within a specific
context and its impact when applied
 Separation of concerns – any complex problem is solvable by subdividing it into pieces that can be solved
independently
 Modularity - the degree to which software can be understood by examining its components independently of
one another
 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
o Cohesion - qualitative indication of the degree to which a module focuses on just one thing
o Coupling - qualitative indication of the degree to which a module is connected to other modules and to
the outside world
 Refinement – process of elaboration where the designer provides successively more detail for each design
component
 Aspects – a representation of a cross-cutting concern that must be accommodated as refinement and
modularization occur
 Refactoring – process of changing a software system in such a way internal structure is improved without
altering the external behavior or code design

Object-Oriented Design Concepts:

Design Classes
 Refine analysis classes by providing detail needed to implement the classes and implement a software
infrastructure the support the business solution
 Five types of design classes can be developed to support the design architecture
o user interface classes – abstractions needed for human-computer interaction (HCI)
o business domain classes – refinements of earlier analysis classes
o process classes – implement lower level business abstractions
o persistent classes – data stores that persist beyond software execution
o System classes – implement software management and control functions

Design Class Characteristics

 Complete (includes all necessary attributes and methods) and sufficient (contains only those methods
needed to achieve class intent)
 Primitiveness – each class method focuses on providing one service
 High cohesion – small, focused, single-minded classes
 Low coupling – class collaboration kept to minimum

Design Model

 Process dimension – indicates design model evolution as design tasks are executed during software process
o Architecture elements
o Interface elements
o Component-level elements
o Deployment-level elements
 Abstraction dimension – represents level of detail as each analysis model element is transformed into a
design equivalent and refined
o High level (analysis model elements)
o Low level (design model elements)
 Many UML diagrams used in the design model are refinements of diagrams created in the analysis model
(more implementation specific detail is provided)
 Design patterns may be applied at any point in the design process

Data Design

 High level model depicting user’s view of the data or information

 Design of data structures and operators is essential to creation of high-quality applications
 Translation of data model into database is critical to achieving system business objectives
 Reorganizing databases into a data warehouse enables data mining or knowledge discovery that can impact
success of business itself

Architectural Design

 Provides an overall view of the software product

 Derived from
o Information about the application domain relevant to software
o Relationships and collaborations among specific analysis model elements
 o Availability of architectural patterns and styles
 Usually depicted as a set of interconnected systems that are often derived from the analysis packages with in
the requirements model

Interface Design

 Interface is a set of operations that describes the externally observable behavior of a class and provides
access to its public operations
 Important elements
o User interface (UI)
o External interfaces to other systems
o Internal interfaces between various design components
 Modeled using UML communication diagrams (called collaboration diagrams in UML 1.x)

Component-Level Design

 Describes the internal detail of each software component

 Defines
o Data structures for all local data objects
o Algorithmic detail for all component processing functions
o Interface that allows access to all component operations
 Modeled using UML component diagrams, UML activity diagrams, pseudocode (PDL), and sometimes
flowcharts

Deployment-Level Design

 Indicates how software functionality and subsystems will be allocated within the physical computing
environment
 Modeled using UML deployment diagrams
 Descriptor form deployment diagrams show the computing environment but does not indicate configuration
details
 Instance form deployment diagrams identifying specific named hardware configurations are developed
during the latter stages of design