UNIT – 2

DESIGN CONCEPT
- Komal Singh

- Reference Book:
- Software Engineering -A Practitioner’s
Approach (Seventh Edition) - Roger S.
Pressman.

(Chapter 8,9,12 )
Introduction
• Mitch Kapor, the creator of Lotus 1-2-3, presented a
“software design manifesto” in Dr. Dobbs Journal. He
said:
• Good software design should exhibit:
• Firmness: A program should not have any bugs that
inhibit its function.
• Commodity: A program should be suitable for the
purposes for which it was intended.
• Delight: The experience of using the program should be
pleasurable one.
What is it?
• Design is what almost every engineer wants to do.
• It is the place where creativity rules—where stakeholder
requirements, business needs, and technical considerations
all come together in the formulation of a product or system.
• Design creates a representation or model of the software,
but unlike the requirements model (that focuses on
describing required data, function, and behavior), the
design model provides detail about software architecture,
data structures, interfaces, and components that are
necessary to implement the system.
• Who does it?
• Software engineers conduct each of the design tasks.
• Why is it important?
• Design allows you to model the system or product that
is to be built.
• This model can be assessed for quality and improved
before code is generated, tests are conducted, and end
users become involved in large numbers. Design is the
place where soft- ware quality is established.
• What are the steps?
• Design depicts the soft- ware in a number of different ways.
First, the architecture of the system or product must be
represented. Then, the interfaces that connect the software
to end users, to other systems and devices, and to its own
constituent components are modeled.
• Finally, the software components that are used to construct
the system are designed.
• Each of these views represents a different design action, but
all must conform to a set of basic design concepts that guide
software design work.
• What is the work product?
• A design model that encompasses architectural,
interface, component- level, and deployment
representations is the primary work product that is
produced during software design.
Design within the concept of
software Engineering
• “The most common miracle of software engineering is the
transition from analysis to design and design to code.”
• Software design sits at the technical kernel of software
engineering and is applied regardless of the software
process model that is used.
• Beginning once software requirements have been
analyzed and modeled, software design is the last
software engineering action within the modeling activity
and sets the stage for construction (code generation
and testing).
D s ig n mo d e l
Cont...
• Each of the elements of the requirements model provides in-
formation that is necessary to create the four design models required
for a complete specification of design.
• The flow of information during software design is illustrated in Figure.
• The data/class design :
• Transforms class models into design class realizations and the
requisite data structures required to implement the software.
• The objects and relationships defined in the CRC diagram and the
detailed data content depicted by class attributes and other notation
provide the basis for the data design action. Part of class design may
occur in conjunction with the design of software architecture. More
detailed class design occurs as each software component is designed.
Cont...
• The architectural design :
• Defines the relationship between major structural
elements of the software, the architectural styles and
design patterns that can be used to achieve the
requirements defined for the system, and the
constraints that affect the way in which architecture can
be implemented [Sha96].
• The architectural design representation the framework
of a computer-based system is derived from the
requirements model.
Cont...
• The interface design:
• describes how the software communicates with systems that
interoperate with it, and with humans who use it. An interface
implies a flow of information (e.g., data and/or control) and a
specific type of behavior.
• Therefore, usage scenarios and behavioral models provide much
of the information required for interface design.
• The component-level :design transforms structural elements of
the software architecture into a procedural description of
software components. Information obtained from the class-based
models, flow models, and behavioral models serve as the basis
for component design.
Cont...
• The importance of software design can be stated with a
single word quality.
• Design is the place where quality is fostered in software
engineering.
• Design provides you with representations of software that
can be assessed for quality.
• Design is the only way that you can accurately translate
stakeholder’s requirements into a finished software product
or system.
• Software design serves as the foundation for all the soft-
ware engineering and software support activities that follow.
Quick note of Design Model
• Data/Class design – transforms analysis classes
into implementation classes and data structures
• Architectural design – defines relationships among the
major software structural elements.
• Interface design – defines how software elements,
hardware elements, and end-users communicate.
• Component-level design – transforms structural
elements into procedural descriptions of
software components
The Design Process
• Software design is an iterative process through which requirements are
translated into a “blueprint” for constructing the software.
• Initially, the blueprint depicts a holistic view of software. That is, the design is
represented at a high level of abstraction— a level that can be directly traced
to the specific system objective and more detailed data, functional, and
behavioral requirements.
• The design must implement all of the explicit requirements contained in the
analysis model, and it must accommodate all of the implicit requirements
desired by the customer.
• The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective.
Quality Guidelines
• A design should exhibit an architecture that (1) has been
created using recognizable architectural styles or patterns, (2)
is composed of components that exhibit good design
characteristics and (3) can be implemented in an evolutionary
fashion.
• A design should be modular that is, the software should be
logically partitioned into elements or subsystems.
• A design should contain distinct representations of data,
architecture, interfaces, and components.
• A design should lead to data structures that are appropriate for
the classes to be implemented and are drawn from
recognizable data patterns.
• A design should lead to components that exhibit independent
functional characteristics.
• A design should lead to interfaces that reduce the complexity of
connections between components and with the external
environment.
• A design should be derived using a repeatable method that is
driven by information obtained during software requirements
analysis.
• A design should be represented using a notation that effectively
communicates its meaning.
• These design guidelines are not achieved by chance. They are
achieved through the application of fundamental design
principles, systematic methodology, and thorough review.
Design Principles
• The design process should not suffer from ‘tunnel
vision.’The design should be traceable to the analysis
model.The design should not reinvent the wheel.
• The design should “minimize the intellectual distance”
[DAV95] between the software and the problem as it
exists in the real world.
• The design should exhibit uniformity and
integration.The design should be structured to
accommodate change.The design should be structured
to degrade gently, even when aberrant data, events, or
operating conditions are encountered.
• Design is not coding, coding is not design.The design
should be assessed for quality as it is being created, not
after the fact.The design should be reviewed to
minimize conceptual (semantic) errors.From Davis
Fundamental Concepts of Design
Process
• Architecture—the overall structure of the software.
• Patterns—”conveys the essence” of a proven design
solution.
• Separation of concerns—any complex problem can be
more easily handled if it is subdivided into pieces.
• Modularity—compartmentalization of data and function.
• Hiding—controlled interfaces.
• Functional independence—single-minded function and low
coupling.
• Refinement—elaboration of detail for all abstractions.
Cont...
• Aspects—a mechanism for understanding how global
requirements affect design.
• Refactoring—a reorganization technique that simplifies
the design.
• OO design concepts—Appendix II.
• Design Classes—provide design detail that will enable
analysis classes to be implemented.
Architecture
• “The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system.” [SHA95a]Structural properties.
• This aspect of the architectural design representation
defines the components of a system (e.g., modules,
objects, filters) and the manner in which those
components are packaged and interact with one another.
• For example, objects are packaged to encapsulate both
data and the processing that manipulates the data and
interact via the invocation of methods
• Extra-functional properties:
• The architectural design description should address how
the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability,
and other system characteristics.
• Families of related systems. The architectural design
should draw upon repeatable patterns that are commonly
encountered in the design of families of similar systems.
• In essence, the design should have the ability to reuse
architectural building blocks.
Patterns Design Pattern
Template
• Pattern name—describes the essence of the pattern in a
short but expressive name
• Intent—describes the pattern and what it does.
• Also-known-as—lists any synonyms for the pattern.
• Motivation—provides an example of the problem.
• Applicability—notes specific design situations in which
the pattern is applicable.
• Structure—describes the classes that are required to
implement the pattern
• Participants—describes the responsibilities of the
classes that are required to implement the pattern.
• Collaborations—describes how the participants
collaborate to carry out their responsibilities.
• Consequences—describes the “design forces” that
affect the pattern and the potential trade-offs that must
be considered when the pattern is implemented.
• Related patterns—cross-references related design
patterns.
Separation of Concerns
• Any complex problem can be more easily handled if it is
subdivided into pieces that can each be solved and/or
optimized independently.
• A concern is a feature or behavior that is specified as
part of the requirements model for the softwareBy
separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and
time to solve.
Modularity
• "modularity is the single attribute of software that allows a
program to be intellectually manageable" [Mye78].Monolithic
software (i.e., a large program composed of a single module)
cannot be easily grasped by a software engineer.
• The number of control paths, span of reference, number of
variables, and overall complexity would make understanding
close to impossible.
• In almost all instances, you should break the design into
many modules, hoping to make understanding easier and as
a consequence, reduce the cost required to build the
software.
Functional Independence
• Functional independence is achieved by developing modules with "single-
minded" function and an "aversion" to excessive interaction with other
modules.
• Cohesion is an indication of the relative functional strength of a module.
• A cohesive module performs a single task, requiring little interaction with other
components in other parts of a program. Stated simply, a cohesive module
should (ideally) do just one thing.
• Coupling is an indication of the relative interdependence among modules.
• Coupling depends on the interface complexity between modules, the point at
which entry or reference is made to a module, and what data pass across the
interface.
• Note: Need to Read all From chapter No.8 (8.2.1 to
8.3.12)
Software Architecture
• What is it?
• Architectural design represents the structure of data and
program components that are re- quired to build a computer-
based system.
• It considers the architectural style that the system will take, the
structure and properties of the components that constitute the
system, and the interrelationships that occur among all
architectural components of a system.
• Ever since the first program was divided into modules,
software systems have had architectures, and programmers
have been responsible for the interactions among the modules
and the global properties of the assemblage.
Cont...
• Historically, architectures have been implicit accidents
of implementation, or legacy systems of the past.
• Good software developers have often adopted one or
several architectural patterns as strategies for system
organization, but they use these patterns informally and
have no means to make them explicit in the resulting
system.
Why is Architecture Important?

• Representations of software architecture are an enabler

for communication between all parties (stakeholders)
interested in the development of a computer-based
system.
• The 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.
• Architecture “constitutes a relatively small, intellectually
graspable mode of how the system is structured and how
its components work together” [BAS03].
Architectural Descriptions

• The IEEE Computer Society has proposed IEEE-Std-1471-2000,

Recommended Practice for Architectural Description of
Software-Intensive System, [IEE00]
• to establish a conceptual framework and vocabulary for use during
the design of software architecture,
• to provide detailed guidelines for representing an architectural
description, and
• to encourage sound architectural design practices.
• The IEEE Standard defines an architectural description (AD) as
a “a collection of products to document an architecture.”
• The description itself is represented using multiple views, where each
view is “a representation of a whole system from the perspective of a
related set of [stakeholder] concerns.”
Architectural Genres

• Genre implies a specific category within the overall

software domain.
• Within each category, you encounter a number of
subcategories.
• For example, within the genre of buildings, you would
encounter the following general styles: houses, condos,
apartment buildings, office buildings, industrial building,
warehouses, and so on.
• Within each general style, more specific styles might apply.
Each style would have a structure that can be described using
a set of predictable patterns.
Architectural Styles

• Each style describes a system category that

encompasses: (1) a set of components (e.g., a
database, computational modules) that perform a
function required by a system, (2) a set of connectors
that enable “communication, coordination and
cooperation” among components, (3) constraints that
define how components can be integrated to form the
system, and (4) semantic models that enable a
designer to understand the overall properties of a
system by analyzing the known properties of its
constituent parts.
• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Object-oriented architectures
• Layered architectures
Data-Centered Architecture
Data Flow Architecture
Main Program/Subprogram Architecture
Layered Architecture
Architectural Patterns

• Concurrency—applications must handle multiple tasks in a manner

that simulates parallelism
• operating system process management pattern
• task scheduler pattern
• Persistence—Data persists if it survives past the execution of the
process that created it. Two patterns are common:
• a database management system pattern that applies the storage and retrieval
capability of a DBMS to the application architecture
• an application level persistence pattern that builds persistence features into
the application architecture
• Distribution— the manner in which systems or components within
systems communicate with one another in a distributed environment
• A broker acts as a ‘middle-man’ between the client component and a server
component.
Architectural Design

• The software must be placed into context

• the design should define the external entities (other
systems, devices, people) that the software interacts
with and the nature of the interaction
• A set of architectural archetypes should be identified
• An archetype is an abstraction (similar to a class)
that represents one element of system behavior
• The designer specifies the structure of the system by
defining and refining software components that
implement each archetype
Architectural Context
Archetypes
Component Structure
Refined Component Structure
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen
to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute in
isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the
sensitivity analysis conducted in step 5.
Architectural Complexity

• the overall complexity of a proposed architecture is

assessed by considering the dependencies between
components within the architecture [Zha98]
• Sharing dependencies represent dependence
relationships among consumers who use the same
resource or producers who produce for the same
consumers.
• Flow dependencies represent dependence relationships
between producers and consumers of resources.
• Constrained dependencies represent constraints on the
relative flow of control among a set of activities.
ADL

• Architectural description language (ADL) provides a

semantics and syntax for describing a software
architecture
• Provide the designer with the ability to:
• decompose architectural components
• compose individual components into larger
architectural blocks and
• represent interfaces (connection mechanisms)
between components.
Design Pattern
• A design pattern can be characterized as “a three-part
rule which expresses a relation between a certain
context, a problem, and a solution” [Ale79].
• For software design, context allows the reader to
understand the environment in which the problem resides
and what solution might be appropriate within that
environment.
• A set of requirements, including limitations and
constraints, acts as a system of forces that influences
how the problem can be interpreted within its context
and how the solution can be effectively applied.
• Context allows the reader to understand the
environment in which the problem resides and what
solution might be appropriate within that environment.
• A set of requirements, including limitations and
constraints, acts as a system of forces that influences
how the problem can be interpreted within its context
and how the solution can be effectively applied.
Effective Patterns
• Coplien [Cop05] characterizes an effective design
pattern in the following way:
• It solves a problem: Patterns capture solutions, not just
abstract principles or strategies.
• It is a proven concept: Patterns capture solutions with a
track record, not theories or speculation.
• The solution isn't obvious: Many problem-solving
techniques (such as software design paradigms or
methods) try to derive solutions from first principles.
• The best patterns generate a solution to a problem
indirectly a necessary approach for the most difficult
problems of design
• It describes a relationship: Patterns don't just
describe modules, but describe deeper system structures
and mechanisms.
• The pattern has a significant human component (minimize
human intervention).
• All software serves human comfort or quality of life; the
best patterns explicitly appeal to aesthetics and utility.
Kinds of Patterns
• Architectural patterns describe broad-based design problems that are solved using a
structural approach.
• Data patterns describe recurring data-oriented problems and the data modeling solutions
that can be used to solve them.
• Component patterns (also referred to as design patterns) address problems associated
with the development of subsystems and components, the manner in which they
communicate with one another, and their placement within a larger architecture.
• Interface design patterns describe common user interface problems and their solution
with a system of forces that includes the specific characteristics of end-users.
• WebApp patterns address a problem set that is encountered when building WebApps
and often incorporates many of the other patterns categories just mentioned.
Cont...
• Creational patterns focus on the “creation, composition, and representation of
objects, e.g.,
• Abstract factory pattern: centralize decision of what factory to instantiate
• Factory method pattern: centralize creation of an object of a specific type choosing one of
several implementations
• Structural patterns focus on problems and solutions associated with how classes
and objects are organized and integrated to build a larger structure, e.g.,
• Adapter pattern: 'adapts' one interface for a class into one that a client expects
• Aggregate pattern: a version of the Composite pattern with methods for aggregation of
children
• Behavioral patterns address problems associated with the assignment of
responsibility between objects and the manner in which communication is effected
between objects, e.g.,
• Chain of responsibility pattern: Command objects are handled or passed on to other
objects by logic-containing processing objects
• Command pattern: Command objects encapsulate an action and its parameters
Frameworks

• Patterns themselves may not be sufficient to develop a

complete design.
• In some cases it may be necessary to provide an implementation-
specific skeletal infrastructure, called a framework, for design work.
• That is, you can select a “reusable mini-architecture that provides the
generic structure and behavior for a family of software abstractions,
along with a context … which specifies their collaboration and use within
a given domain.” [Amb98]
• A framework is not an architectural pattern, but rather a
skeleton with a collection of “plug points” (also called hooks and
slots) that enable it to be adapted to a specific problem domain.
• The plug points enable you to integrate problem specific classes or
functionality within the skeleton.
Describing a Pattern

• Pattern name—describes the essence of the pattern in a short but expressive name
• Problem—describes the problem that the pattern addresses
• Motivation—provides an example of the problem
• Context—describes the environment in which the problem resides including application domain
• Forces—lists the system of forces that affect the manner in which the problem must be solved;
includes a discussion of limitation and constraints that must be considered
• Solution—provides a detailed description of the solution proposed for the problem
• Intent—describes the pattern and what it does
• Collaborations—describes how other patterns contribute to the solution
• Consequences—describes the potential trade-offs that must be considered when the pattern
is implemented and the consequences of using the pattern
• Implementation—identifies special issues that should be considered when implementing the
pattern
• Known uses—provides examples of actual uses of the design pattern in real applications
• Related patterns—cross-references related design patterns
Pattern-Based Design

• A software designer begins with a requirements model

(either explicit or implied) that presents an abstract
representation of the system.
• The requirements model describes the problem set,
establishes the context, and identifies the system of
forces that hold sway.
• Figure: Next Slide
Thinking in Patterns

• Shalloway and Trott [Sha05] suggest the following approach that

enables a designer to think in patterns:
• 1. Be sure you understand the big picture—the context in which the
software to be built resides. The requirements model should
communicate this to you.
• 2. Examining the big picture, extract the patterns that are present at
that level of abstraction.
• 3. Begin your design with ‘big picture’ patterns that establish a context
or skeleton for further design work.
• 4. “Work inward from the context” [Sha05] looking for patterns at lower
levels of abstraction that contribute to the design solution.
• 5. Repeat steps 1 to 4 until the complete design is fleshed out.
• 6. Refine the design by adapting each pattern to the specifics of the
software you’re trying to build.
Design Task
The following design tasks are applied when a pattern-based design philosophy is used:
1. Examine the requirements model and develop a problem hierarchy.
2. Determine if a reliable pattern language has been developed for the
problem domain.
3. Beginning with a broad problem, determine whether one or more
architectural patterns are available for it.
4. Using the collaborations provided for the architectural pattern, examine
subsystem or component level problems and search for appropriate
patterns to address them.
5. Repeat steps 2 through 5 until all broad problems have been addressed.
6. If user interface design problems have been isolated (this is
almost always the case), search the many user interface design
pattern repositories for appropriate patterns.
7. Regardless of its level of abstraction, if a pattern language
and/or patterns repository or individual pattern shows promise,
compare the problem to be solved against the existing pattern(s)
presented.
8. Be certain to refine the design as it is derived from patterns
using design quality criteria as a guide.
Building a Pattern-Organizing
Table
• A pattern-organizing table can be implemented as a
spreadsheet model using the form shown in the figure.
• An abbreviated list of problem statements, organized by
data/content, architecture, component-level, and user
interface issues, is presented in the left-hand (shaded)
column.
• Four pattern types database, application,implementation,
and infrastructure are listed across the top row.
• The names of candidate patterns are noted in the cells of
the table.
Pattern Organizing Table

• Example: every house (and every architectural style for houses)

employs a Kitchen pattern.
• The Kitchen pattern and patterns it collaborates with address
problems associated with the storage and preparation of food, the
tools required to accomplish these tasks, and rules for placement of
these tools relative to workflow in the room.
• In addition, the pattern might address problems associated with
counter tops, lighting, wall switches, a central island, flooring, and so
on.
• Obviously, there is more than a single design for a kitchen, often
dictated by the context and system of forces. But every design can
be conceived within the context of the ‘solution’ suggested by the
Kitchen pattern.
Common Design Mistakes

• Not enough time has been spent to understand the

underlying problem, its context and forces, and as a
consequence, you select a pattern that looks right, but is
inappropriate for the solution required.
• Once the wrong pattern is selected, you refuse to see your
error and force fit the pattern.
• In other cases, the problem has forces that are not
considered by the pattern you’ve chosen, resulting in a poor
or erroneous fit.
• Sometimes a pattern is applied too literally and the required
adaptations for your problem space are not implemented.
Patterns Repositories

• There are many sources for design patterns available on

the Web. Some patterns can be obtained from
individually published pattern languages, while others
are available as part of a patterns portal or patterns
repository.
• A list of patterns repositories is presented in the sidebar
near Section 12.3 (from Refeference book)
Component-Level Patterns

• Component-level design patterns provide a proven

solution that addresses one or more sub-problems
extracted from the requirement model.
• In many cases, design patterns of this type focus on
some functional element of a system.
• For example, the SafeHomeAssured.com application
must address the following design sub-problem: How
can we get product specifications and related
information for any SafeHome device?
• Having enunciated the sub-problem that must be solved,
consider context and the system of forces that affect the
solution.
• Examining the appropriate requirements model use case, the
specification for a SafeHome device (e.g., a security sensor or
camera) is used for informational purposes by the consumer.
• However, other information that is related to the specification (e.g.,
pricing) may be used when e-commerce functionality is selected.
• The solution to the sub-problem involves a search. Since
searching is a very common problem, it should come as no
surprise that there are many search-related patterns.
• See Section 12.4
User Interface (UI) Patterns

• Whole UI. Provide design guidance for top-level structure and navigation throughout the
entire interface.
• Page layout. Address the general organization of pages (for Websites) or distinct screen
displays (for interactive applications)
• Forms and input. Consider a variety of design techniques for completing form-level
input.
• Tables. Provide design guidance for creating and manipulating tabular data of all kinds.
• Direct data manipulation. Address data editing, modification, and transformation.
• Navigation. Assist the user in navigating through hierarchical menus, Web pages, and
interactive display screens.
• Searching. Enable content-specific searches through information maintained within a
Web site or contained by persistent data stores that are accessible via an interactive
application.
• Page elements. Implement specific elements of a Web page or display screen.
• E-commerce. Specific to Web sites, these patterns implement recurring elements of e-
commerce applications.
WebApp Patterns

• Information architecture patterns relate to the overall structure of the information

space, and the ways in which users will interact with the information.
• Navigation patterns define navigation link structures, such as hierarchies, rings,
tours, and so on.
• Interaction patterns contribute to the design of the user interface. Patterns in this
category address how the interface informs the user of the consequences of a specific
action; how a user expands content based on usage context and user desires; how to
best describe the destination that is implied by a link; how to inform the user about the
status of an on-going interaction, and interface related issues.
• Presentation patterns assist in the presentation of content as it is presented to the
user via the interface. Patterns in this category address how to organize user interface
control functions for better usability; how to show the relationship between an interface
action and the content objects it affects, and how to establish effective content
hierarchies.
• Functional patterns define the workflows, behaviors, processing, communications,
and other algorithmic elements within a WebApp.
Note: chapter 8, Chapter 9, Chapter 12 from Reference
book

THANK YOU