Diseño de Software I

Programa de Ingeniería de Software

Diseño de Software I
Profesor: Jorge Uriel Liévano Cifuentes
Design Concepts

Jorge Uriel Liévano Cifuentes

Content

• Design Concepts
• Architectural design
• Component level design
• User interface design
• Webapp design

Jorge Uriel Liévano Cifuentes

Objetives
• Have an general overview of the principles, features and
methods of software design.
• Understand the importance of having a correct and adequate
system architecture defined.
• Know the general characteristics of the main architectural
styles.
• Have an overview of the different types of graphic and textual
notations for software design artifacts.
• Know the general characteristics of the main strategies and
design methods

Jorge Uriel Liévano Cifuentes

Design in the context of
Software Engineering

Jorge Uriel Liévano Cifuentes

Design (1/9)

Mitch Kapor, the creator of Lotus 1-2-3, presented a “software

design manifesto” in Dr. Dobbs Journal. He said: A 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.

Jorge Uriel Liévano Cifuentes

Design (2/9)
What is it?
 Design is what almost every engineer wants to do. It is the place where
the rules of creativity - the requirements of the participants - the needs
of the business and the technical considerations - come together to
formulate a product or system.

 The design creates a representation or model of the software, but,

unlike the requirements model (which focuses on describing the data
that is needed, the function and behavior), the design model provides
details about software architecture, structures of data, interfaces and
components that are needed to implement the system.

Jorge Uriel Liévano Cifuentes

Design (3/9)
 In a general sense, design is a way of solving problems. Therefore,
designing uses notions such as
 Goals
 Restrictions
 Alternatives
 Representations
 Solutions

 The design plays a key role in software development because it allows

software engineers to produce various models that:
 Characterize the solution to be implemented.
 They can be analyzed and evaluated in order to determine if the
requirements are met.
 They facilitate the examination and evaluation of alternatives.
 They serve to plan the following development activities.
Jorge Uriel Liévano Cifuentes
Design (4/9)
Perspective of the Process

 Design is the effort to define the architecture, components,

interfaces and other characteristics of a system or
component [IEEE 610-1990].
 Software Design is the activity of the software life cycle in
which the requirements are analyzed to produce a
description of the internal structure of the software that
serves as the basis for its construction.
 The output is a set of models and artifacts that record the
main decisions taken.

Jorge Uriel Liévano Cifuentes

Design (5/9)
Result Perspective

 A design is the result of that effort.

 A software design describes:
 Software architecture (how it is decomposed and
organized into components),
 The interfaces between these components, and
 The components at a level of detail that allows their
construction.

Jorge Uriel Liévano Cifuentes

Design (6/9)
Who does it?
Software engineers carry out each of the design tasks.

Jorge Uriel Liévano Cifuentes

Design (7/9)
Why it is important?
The design allows modeling the system or product that is going to be
built. This model is evaluated with respect to quality and its improvement
before generating code; Afterwards, tests are carried out and many end
users are involved. Design is the place where software quality is
established.

Jorge Uriel Liévano Cifuentes

Design (8/9)
What are the steps?
The design represents the software in several ways.

1. The architecture of the system or product must be represented.

2. The interfaces that connect the software with the end users, with
other systems and devices, and with their own constituent
components are modeled.
3. The software components that are used to build the system are
designed.

Each of these perspectives represents a different design action, but all

must adhere to a basic set of design concepts that guide the work of
software production.
Jorge Uriel Liévano Cifuentes
Design (9/9)
What is the final product?
A design model that groups the architectural representations, interfaces
at the component and deployment level.

How do I make sure I did it right?

The design model is evaluated by the software team in an effort to
determine if it contains errors, inconsistencies or omissions, if there are
better alternatives and if it is possible to implement the model within the
restrictions, deadline and cost that have been established.

Jorge Uriel Liévano Cifuentes

Analysis Model -> Design Model

Co m p o n e n t -
sc e na r i o- ba se d f l ow- or i e nt e d L e v e l D e sig n
e l e me nt s e l e 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 sig n
Analysis Model

A rc h it e c t u ra l D e sig n
c l a ss- ba se d be ha v i or a l
e l e me nt s e l e me nt s
class diagrams state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cla ss D e sig n
collaboration diagrams

Design Model

Jorge Uriel Liévano Cifuentes

Analysis Model -> Design Model

Jorge Uriel Liévano Cifuentes

Guidelines Design and Quality (1/3)
• 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.

Jorge Uriel Liévano Cifuentes

Guidelines Design and Quality (2/3)
• 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.
• For smaller systems, design can sometimes be developed linearly.
• 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.

Jorge Uriel Liévano Cifuentes

Guidelines Design and Quality (3/3)
• 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.
Jorge Uriel Liévano Cifuentes
Architectural Design vs. Detailed
The ISO 12207 standard identifies two types of
Software Design:

 Architectural [high level]

Describe the structure and high-level organization,
that is, the subsystems or components and their
relationships
 Detailed
Describe each component and its specific behavior,
so that construction can proceed

Jorge Uriel Liévano Cifuentes

Architectural Design vs. Detailed
Architectural Design
 It is the first step in the design of a system, prior to the
detailed design.
 Its result is known as software architecture. [presents
after]
 Represents the link between the requirements
specification and the design.
 Can be carried out in parallel with requirements
specification activities.
 It implies a creative effort, so that the activities to be
carried out can change according to the nature of the
system to be developed.
Jorge Uriel Liévano Cifuentes
Architectural Design vs. Detailed
 During the architectural design it is necessary to adopt
some decisions:
 ¿Is there a generic architecture that can be used?
 ¿How will the system be distributed?
 ¿What architectural styles are appropriate?
 ¿What approach will be used to structure the system?
 ¿How will the system break down into modules?
 ¿What control strategy will be used?
 ¿How will the resulting architectural design be
evaluated?
 ¿How will the architecture be documented?

Jorge Uriel Liévano Cifuentes

Design Principles (1/3)

 Principle
Basic truths or general laws that are used as a
basis for reasoning or as a guide to act.

 Principles of Software Design

Key notions considered fundamental in many
different approaches and design concepts

Jorge Uriel Liévano Cifuentes

Design Principles (2/3)
• 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”
between the software and the problem as it exists in
the real world.
• The design should exhibit uniformity and integration.

Jorge Uriel Liévano Cifuentes

Design Principles (3/3)
 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.

Jorge Uriel Liévano Cifuentes

Fundamental Concepts (1/2)
• Abstraction—data, procedure, control
• Architecture—the overall structure of the software
• Patterns—”transmits the essence” of a proven design solution
• Separation of concerns—(Decomposition) any complex problem
can be more easily handled if it is subdivided into pieces
• Modularity—compartmentalization of data and function
• Hiding—(encapsulation) controlled interfaces
• Functional independence—single-minded function and low
coupling

Jorge Uriel Liévano Cifuentes

Fundamental Concepts (2/2)
• Refinement—elaboration of detail for all abstractions
• Aspects—a mechanism for understanding how global
requirements affect design
• Refactoring—a reorganization technique that simplifies the
design
• OO design concepts
• Design Classes—provide design detail that will enable
analysis classes to be implemented

Jorge Uriel Liévano Cifuentes

Abstraction
 Forget information that differentiates certain things and
thus treat them as if they were similar.

 In Software the basic mechanisms of abstraction are:

 Parameterization
 Specification
o Procedural Abstraction
o Data abstraction
o Control Abstraction (iteration)

Jorge Uriel Liévano Cifuentes

Abstraction Vs Encapsulation
Abstraction referes to the act of representing essential features
without including the background details of explanation.

Abstraction Encapsulation

 Used for hiding the  Means hiding the code and

unwanted data and giving data into a single unit to
relevant data. protect data from outside
 What the object does. world.
 Outer layout used in terms  How the object does.
of design.  Inner layout, used in terms of
Eg. Out look the mobile phone implementation.
Eg. Inner implementation details of
mobile how
Jorge Uriel Liévano Cifuentes
Data Abstraction

door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

Jorge Uriel Liévano Cifuentes

Procedural Abstraction (1/2)
Definition: It’s the idea that each method should have a coherent
conceptual description that separates its implementation from its
users.

Reasons to choose to encapsulate a part of the behavior

 It's a big, ugly function and you want to hide the "how it works"
details from code that might use it. How doest it?: Giving it a name
allows the user to ignore how it's done.
 It's a common thing to do, and you don't want to have to replicate the
code in several places. How doest it? Giving it a name allows multiple
users to rely on the same (common) implementation.
 It's conceptually a separate "task", and you want to be able to give it a
name.

Jorge Uriel Liévano Cifuentes

Procedural Abstraction (2/2)

open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter

Jorge Uriel Liévano Cifuentes

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.

Jorge Uriel Liévano Cifuentes

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.

Jorge Uriel Liévano Cifuentes

Separation of Concerns (Decomposition)
• 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 software
• By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time to solve.

Jorge Uriel Liévano Cifuentes

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.

Jorge Uriel Liévano Cifuentes

Modularity: Trade-offs
What is the "right" number of modules
for a specific software design?
module development cost

cost of
software

module
integration
cost

optimal number number of modules

of modules

Jorge Uriel Liévano Cifuentes

Information Hiding
module
• algorithm
controlled
interface • data structure

• details of external interface

• resource allocation policy

clients
"secret"

a specific design decision

Jorge Uriel Liévano Cifuentes
Why Information Hiding?
• Reduces the likelihood of “side effects”

• Limits the global impact of local design decisions

• Emphasizes communication through controlled interfaces

• Discourages the use of global data

• Leads to encapsulation—an attribute of high quality design

• Results in higher quality software

Jorge Uriel Liévano Cifuentes

Stepwise Refinement
open

walk to door;
reach for knob;

open door; repeat until door opens

turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

Jorge Uriel Liévano Cifuentes

Sizing Modules: Two Views
What's How big
inside?? is it??

MODULE

Jorge Uriel Liévano Cifuentes

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.

Jorge Uriel Liévano Cifuentes

Aspects
 As the requirements analysis proceeds, a set of "concerns" arise that
"include requirements, use cases, characteristics, data structures, quality of
service, variants, boundaries of intellectual properties, collaborations,
patterns and contracts"
 Ideally, a requirements model is organized in a way that allows to isolate
each concern (requirement) in order to consider it independently. However,
in practice, some of these concerns cover the entire system and it is not
easy to divide them into compartments.
 E.g. Consider two requirements, A and B. Requirement A crosscuts
requirement B “if a software decomposition [refinement] has been chosen in
which B cannot be satisfied without taking A into account”. [Ros04]
 An aspect is a representation of a cross-cutting concern.
 In an ideal context, one aspect is implemented as a separate module
(component) and not as "scattered" software fragments in many
components [Ban06].
Jorge Uriel Liévano Cifuentes
Refactoring
 Fowler [FOW99] defines refactoring in the following manner:
"refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code [design] yet improves its
internal structure.”
 When software is refactored, the existing design is examined for
 Redundancy
 Unused design elements
 Inefficient or unnecessary algorithms
 Poorly constructed or inappropriate data structures
 Or any other design failure that can be corrected to yield a better design.

Jorge Uriel Liévano Cifuentes

OO Design Concepts
• Design classes

• Entity classes

• Boundary classes

• Controller classes

• Inheritance—all responsibilities of a superclass is immediately inherited by all

subclasses

• Messages—stimulate some behavior to occur in the receiving object

• Polymorphism—a characteristic that greatly reduces the effort required to extend the
design

Jorge Uriel Liévano Cifuentes

Design Classes
• Analysis classes are refined during design to become entity classes
• Boundary classes are developed during design to create the
interface (e.G., Interactive screen or printed reports) that the user
sees and interacts with as the software is used.
• Boundary classes are designed with the responsibility of
managing the way entity objects are represented to users.
• Controller classes are designed to manage
• The creation or update of entity objects;
• the instantiation of boundary objects as they obtain information
from entity objects;
• complex communication between sets of objects;
• validation of data communicated between objects or between
the user and the application.
Jorge Uriel Liévano Cifuentes
Taller 1

Jorge Uriel Liévano Cifuentes

Jorge Uriel Liévano Cifuentes
Design Model Elements
• Data elements
• Data model --> data structures
• Data model --> database architecture
• Architectural elements
• Application domain
• Analysis classes, their relationships, collaborations and behaviors are
transformed into design realizations
• Patterns and “styles”
• Interface elements
• The user interface (UI)
• external interfaces to other systems, devices, networks or other producers or
consumers of information
• Internal interfaces between various design components.
• Component elements
• Deployment elements
Jorge Uriel Liévano Cifuentes
Architectural Elements
The architectural model [Sha96] is derived from three
sources:
information about the application domain for the
software to be built;
specific requirements model elements such as data
flow diagrams or analysis classes, their relationships
and collaborations for the problem at hand, and
the availability of architectural patterns and styles.

Jorge Uriel Liévano Cifuentes

Interface Design Elements
These interface design elements allow the
software to communicate externally and enable
internal communication and collaboration among
the components that populate the software
architecture.

Jorge Uriel Liévano Cifuentes

Interface Elements

Jorge Uriel Liévano Cifuentes

Component-Level Design Elements
• The component-level design for software is the equivalent to a set of
detailed drawings (and specifications) for each room in a house.
• These drawings depict wiring and plumbing within each room, the
location of electrical receptacles and wall switches, faucets, sinks,
showers, tubs, drains, cabinets, and closets.
• The component-level design for software fully describes the internal
detail of each software component.
• To accomplish this, the component-level design defines data structures
for all local data objects and algorithmic detail for all processing that
occurs within a component and an interface that allows access to all
component operations (behaviors).

Jorge Uriel Liévano Cifuentes

Component Elements

SensorManagement
Sensor

Jorge Uriel Liévano Cifuentes

Deployment Elements
Deployment-level
design elements
indicate how software
functionality and
subsystems will be
allocated within the
physical computing
environment that will
support the software.
Jorge Uriel Liévano Cifuentes
Bibliography
 Basic Bibliography
o IEEE Computer Society (2004)
 SWEBOK - Guide to the Software Engineering Body of
Knowledge, 2004 Version.
 Chapter 3.
 http://www.swebok.org/
o Caps 8 and 11 of Sommerville's book (2005).
 Further reading
o chap. 14 from Sommerville's book (2005).
o Caps 8 and 9 of Pressman's book (2005).
o chap. 6 and 7 of the book by Piattini (2007).
o chap. 5 from Pfleeger's book (2002).

Jorge Uriel Liévano Cifuentes

Gracias

Jorge Uriel Liévano Cifuentes