DISEÑO

DE
SISTEMAS
 Es una representación significativa
de algo que se va a construir.
(Modelo)

El diseño es un “plano” de una

solución para el sistema.
DISEÑO
Durante el diseño se refina la
arquitectura.

Diseño Orientado a Objetos,

Diseño Orientado a Funciones y
Diseño Ágil

Creado por : Lic. Vviana Sánchez 2

 DEFINICIÓN DISEÑO SOFTWARE

Es el proceso de aplicar distintas

técnicas y principios con el
propósito de definir un dispositivo,
proceso o sistema con los
suficientes detalles como para
permitir su realización física.
Creado por : Lic. Vviana Sánchez 3
DEFINICIÓN DISEÑO DE SISTEMAS

01 02 03
Es el arte de definir la Se encuentra por Forma parte del núcleo
arquitectura de encima del diseño de técnico de la Ingeniería
hardware y software, software. de software.
componentes, módulos
y datos de un sistema,
para satisfacer ciertos
requerimientos.

Creado por : Lic. Vviana Sánchez 4

 OBJETIVOS

El diseño de un sistema es correcto si un sistema construido

de acuerdo a ese diseño satisface los requerimientos del
sistema

Pero el objetivo del diseño no es encontrar el diseño correcto

sino
• Encontrar el mejor diseño posible
• Dentro de las limitaciones impuestas por
• los requerimientos,
• el ambiente físico del sistema
• y el ambiente social donde el mismo va a operar
• ¿otras limitaciones?

Creado por : Lic. Vviana Sánchez

 CONSTA DE TRES ACTIVIDADES
TÉCNICAS

Diseño

Generación Requeridas para

construir y verificar
de código software.

Pruebas

Creado por : Lic. Vviana Sánchez 6

 EL DISEÑO DEBE SER

Un diseño claramente debe ser:

“Rastreable”. Se puede rastrear

Completo (implementa toda la
Verificable hacia los requerimientos que
especificación)
diseña (“traceable”)

Sin embargo, las dos cosas más importantes concernientes a los

diseñadores es que el diseño sea:

Eficiente Simple ¿Por qué?

Creado por : Lic. Vviana Sánchez 7

 LA TAREA DE DISEÑO
Crear un diseño simple y
eficiente de un sistema
“grande” puede ser una
tarea extremadamente
compleja
Si se logra manejar la
complejidad
Creado por : Lic. Vviana Sánchez
• Actividad básicamente creativa
• No puede reducirse a una serie de pasos a
seguir
• Sin embargo, se pueden dar guías
• Se reducen los costos del diseño
• Se reduce la posibilidad de introducir
defectos durante el diseño
8
 PRINCIPIOS DEL DISEÑO

Iterativo

Dividir y conquistar

Abstracción

Modularidad

Calidad

Creado por : Lic. Vviana Sánchez 9

 ITERATIVO

A partir de los requisitos se elabora un plano para

construir el software.

Cada actividad transforma la información de manera

que de lugar a un software validado.

Este proceso es incremental, o sea en cada iteración

se revisa lo que se hizo y se agrega o mejora esto.

Más iteraciones (refinamiento) se hacen, se logra un

nivel de abstracción mucho más bajo.

El refinamiento implica Decisiones de Diseño

Creado por : Lic. Vviana Sánchez 10

 La resolución de un problema con D&C tiene
tres partes:
• Dividir el problema en k subproblemas del
mismo tipo, pero más chicos.
• Conquistar resolviendo los subproblemas,
DIVIDIR Y recursivamente o directamente (si son lo
suficientemente fáciles o chicos).
CONQUISTAR
• Combinar las soluciones obtenidas para
resolver el problema original.

• Dividir en piezas con esta propiedad

es una tarea compleja para el diseño
de software

Creado por : Lic. Vviana Sánchez 11

 Las piezas
• Están relacionadas, juntas forman el
sistema
• Existe comunicación y cooperación
DIVIDIR Y entre las mismas
CONQUISTAR • Esto agrega complejidad, que surge
(2) de la propia partición
• Cuando el costo de particionar
sumado la complejidad agregada
supera los ahorros logrados por
particionar se debe detener el
proceso.

Creado por : Lic. Vviana Sánchez 12

 DIVIDIR Y CONQUISTAR (3)
• ¿De qué sirve lograr la mayor cantidad de piezas
independientes respecto a otras?

13
Creado por : Lic. Vviana Sánchez
 • Permite al diseñador considerar un
componente a un cierto nivel de
abstracción sin preocuparse por los
ABSTRACCIÓN detalles de implementación de
dicho componente
• Se describe el comportamiento
exterior sin describir los detalles
internos

Creado por : Lic. Vviana Sánchez 14

 ABSTRACCIÓN

3 Niveles:

Procedimental De Control
De Datos
(Métodos) (Flujo de
(Atributos)
comunicación)

15

Creado por : Lic. Vviana Sánchez

 Un sistema se considera modular si
El sistema El cambio en
consiste en Se pueden uno tiene
diversos implementar mínimos
componentes separadamente impactos en
otros

La modularidad es donde se unen

MODULARIDAD la abstracción y la partición

Estructura global del software

(Arquitectura)

Creado por : Lic. Vviana Sánchez 16

 MODULARIDAD

Un buen Reduce la complejidad.

diseño
modular: Facilita los cambios.

Implementación sencilla.

Permite desarrollo paralelo de diversas

partes.

17

Creado por : Lic. Vviana Sánchez

 • Módulos Secuenciales:
Se ejecutan sin interrupción aparente
por parte del software de la
aplicación.

TIPOS DE • Módulos incrementales:

MÓDULOS Pueden ser interrumpidos y

reestablecidos por el software de la
aplicación.
• Módulos Paralelos:
Se ejecutan juntos en entornos
multiproceso.

Creado por : Lic. Vviana Sánchez 18

 • La calidad se evalúa teniendo en
cuenta tres características:
• El diseño deberá
• Implementar todos los requisitos
explícitos del modelo de análisis y
ajustarse a todos los requisitos

CALIDAD implícitos que desea el cliente.

• Ser una guía legible y comprensible
para todos los actores involucrados.
• Proporcionar una imagen completa
del software tanto en funcionalidad
como en implementación.

Creado por : Lic. Vviana Sánchez 19

 • Tres conceptos claves para la
calidad de un diseño (además de
ser correcto, claro)
• Acoplamiento (bajo)
CALIDAD
• Cohesión (alta)

• Principio abierto-cerrado (cumplir

con el principio)

Creado por : Lic. Vviana Sánchez 20

 Medida de interconexión entre los
módulos de una estructura de
programa.
• Cuánto más acoplados más
dependientes entre si.
• Entonces, más difícil comprenderlos
ACOPLAMIENTO y modificarlos.
• El grado de acoplamiento entre
módulos depende de:
• Cuánta información se necesita
sobre el otro módulo para
entenderlo.
• Qué tan compleja y. explícita es esta
información

Creado por : Lic. Vviana Sánchez 21

 • Interacción
• Métodos de una clase que invocan a
métodos de otra clase:
• La peor forma es si se interactúa
TIPOS DE con partes internas del método.
ACOPLAMIENTO
• La del “medio” es si se accede
directamente a atributos del objeto.
• La menor es si se accede al método
mediante intercambio de
parámetros.

Creado por : Lic. Vviana Sánchez 22

 • Componente
• Una clase tiene variables de otra
clase.
• Tres formas:
• Existe un atributo de la clase que es
TIPOS DE
de otra clase.
ACOPLAMIENTOS
• Existe un método que recibe como
parámetro otra clase.
• Existe un método con una variable
local de otra clase. (la menos
deseada)

Creado por : Lic. Vviana Sánchez 23

 COHESIÓN

Se focaliza en conocer
porqué los elementos
de un módulo están
juntos en ese módulo.
Módulos más fáciles de
entender.
El objetivo es tener en
un mismo módulo
elementos que están
fuertemente
vinculados.
Más fáciles de
modificar.

24

Creado por : Lic. Vviana Sánchez

 Método
• Más alta cohesión cuando el método
implementa una única función
claramente definida.
• Todas las sentencias contribuyen a
esa función.
TIPOS DE Clase
COHESIÓN • Se focaliza en porqué distintos
atributos y métodos están en una
misma clase.
• Una clase implementando un único
concepto o abstracción.
• Todos sus elementos contribuyendo a
soportar ese concepto o abstracción.

Creado por : Lic. Vviana Sánchez 25

 • Herencia
• Se focaliza en conocer porqué las
clases están agrupadas en una
jerarquía.
TIPOS DE • Se considera que la cohesión es
COHESIÓN baja si la jerarquía es usada sólo por
reuso de código.
• No existe una relación de
generalización-especialización.

Creado por : Lic. Vviana Sánchez 26

 • Objetivo : Promover la construcción de
sistemas que sean fáciles de modificar.
• Módulos abiertos para la extensión
• El comportamiento puede ser
PRINCIPIO extendido.
ABIERTO- • Módulos cerrados para la modificación
CERRADO • Extremo: cuando se hacen mejoras no
es necesario tocar el código existente.
• La interfaz no debe cambiar y se debe
asegurar que se mantiene el
comportamiento.

27

Creado por : Lic. Vviana Sánchez

 PRINCIPIO ABIERTO-CERRADO

Se dice que un módulo está abierto si se

puede extender.
• Ejemplo, se deberían poder añadir campos a la
estructura de datos que contiene dicho módulo o nuevas
funcionalidades a su comportamiento.

Se dice que un módulo queda cerrado si queda

utilizable para otros módulos.
• Esto implica que dicho módulo goza de una descripción
estable y bien definida.

Creado por : Lic. Vviana Sánchez 28

APROXIMACIONES
PARA DISEÑO DE
SOFTWARE
 DISEÑO TOP DOWN
TIPOS
DISEÑO BOTTOM UP

Creado por : Lic. Vviana Sánchez 30

 DISEÑO TOP DOWN

Toma la totalidad del sistema software

como una entidad.

Lo descompone para conseguir más de

un sub sistema o componente basado en
algunas características.

Cada sub sistema o componente es

tratado como un sistema descompuesto
adicional.

Este proceso continúa funcionando hasta

llegar al nivel más bajo del sistema en la
jerarquía 'top-down'.

31

Creado por : Lic. Vviana Sánchez

 DISEÑO TOP DOWN

Empieza con un modelo generalizado de sistema y continúa

definiendo las partes más específicas de éste.

Cuando todos los componentes están formados, el sistema

empieza a existir.

El Diseño Top-down es más recomendable cuando la solución

software necesita ser diseñada desde el inicio y los detalles
específicos son desconocidos.

Creado por : Lic. Vviana Sánchez 32

 DISEÑO BOTTOM UP

Empieza con componentes más básicos y

específicos.

Continua formando un mayor nivel de

componentes usando un nivel básico o bajo de
componentes.
Sigue creando componentes de alto nivel hasta el
punto en el que el sistema deseado no ha
evolucionado en un solo componente.
Cuánto mayor sea el nivel más incrementará la
abstracción.

La estrategia de Bottom-up es más recomendable

cuando un sistema necesita ser creado desde uno
ya existente, donde los elementos primos pueden 33
usarse para el sistema nuevo.
Creado por : Lic. Vviana Sánchez
 LA TAREA DEL DISEÑO
PRODUCE

Diseño de Datos.

Diseño Arquitectónico.

Diseño de Interfaz.

Diseño de Componentes.

Creado por : Lic. Vviana Sánchez 34

 Transforma el modelo de dominio de
DISEÑO información que se crea durante el
análisis en las estructuras de datos
DE DATOS que se necesitarán para implementar
el software.

Creado por : Lic. Vviana Sánchez 35

 • Define la relación entre los
elementos estructurales principales
DISEÑO
ARQUITECTÓNICO del software.
• Incluye los componentes, sus
propiedades e interacciones.

Creado por : Lic. Vviana Sánchez 36

 • Describe la manera de comunicar el
software dentro de si mismo, con
DISEÑO sistemas que interoperan dentro de
DE él y las personas que lo utilizan.
INTERFAZ • Una interfaz implica un flujo de
información y un tipo específico de
comportamiento.

Creado por : Lic. Vviana Sánchez 37

 Transforma los elementos
DISEÑO A NIVEL estructurales de la arquitectura del
DE software en una descripción
COMPONENTES
procedimental de los componentes
del mismo.

Creado por : Lic. Vviana Sánchez 38

 BIBLIOGRAFÍA

• Ingeniería de software, un enfoque práctico. – Roger S. Pressman –

Ed. Mc Graw Hill – Sexta Edición: 2006. ISBN: 9701054733

Principal • Ingeniería de software, teoría y práctica. – Shari Lawrence Pfleeger

– Ed. Prentice Hall- Primera edición – 2002. ISBN: 987-9460-71-5
• Ingeniería de software – Ian Sommerville – Ed Pearson – Novena
edición – 2009. ISBN 9786073206037

UML Y PATRONES: Introducción al análisis y Diseño orientado a

objetos y el proceso unificado. – Graig Larman – Prentice Hall;
Complementaria Pearson- 2da. Edición -
ANÁLISIS Y DIEÑO DE SISTEMAS.- Keneth Kendall & Julie Kendall-
Prentice Hall- 8° Edición

39

Creado por : Lic. Vviana Sánchez