El diseo del software es un proceso iterativo mediante el cual los

requisitos se traducen en un plano para construir el software.

A travs del proceso del diseo, la calidad en evolucin de este se
evala con una serie de revisiones tcnicas formales, se sugieren
tres caractersticas que sirven como gua en la evaluacin:
El diseo debe implementar todos los requisitos explcitos
contenidos en el modelo del anlisis, y debe ajustarse a los
requisitos implcitos que desea el cliente.
El diseo debe ser una gua legible y comprensible para quienes
generaran cdigo y quienes realizaran pruebas.
El diseo debe proporcionar una imagen completa del software
desde una perspectiva de implementacin
Arquitectura

Abstraccin

Modularidad

Ocultacin de informacin

Independencia funcional

Re fabricacin
 Diseo de
interfaz
Diseo al
Diseo
nivel de
arquitectni
component
co
es

El
Diseo al
Diseo de modelo
nivel de
datos de
despliegue
Diseo
Descripcin Utilizacin
de un de patrones
patrn de de diseo
diseo Diseo de
software basado
en patrones

Marcos de
trabajo
Fundamentos del Diseo
ABSTRACCIN

Cuando se considera una solucin modular para

cualquier problema, pueden formularse varios niveles
de abstraccin

En el nivel superior de abstraccin se establece una

solucin en trminos generales, en lenguaje natural.
En los niveles inferiores de abstraccin se utiliza una
orientacin ms procedimental. Por ltimo, en el nivel
ms bajo de abstraccin, se establece una solucin,
de forma que pueda implementarse directamente.
6
Fundamentos del Diseo
REFINAMIENTO
La arquitectura de un programa se desarrolla en niveles
sucesivos de refinamiento de los detalles procedimentales
Se desarrolla una jerarqua descomponiendo una funcin de
forma sucesiva hasta que se llega a las sentencias del lenguaje
de programacin
Comenzamos con una declaracin de la funcin (o una
descripcin de la informacin) definida a un nivel superior de
abstraccin. Es decir, la declaracin describe la funcin o la
informacin conceptualmente, pero no proporciona informacin
sobre el funcionamiento interno de la funcin o sobre la
estructura interna de la informacin, sino que se va a realizando
sucesivamente, dando cada vez ms detalles

7
Fundamentos del Diseo
MODULARIDAD (divide y vencers)

El software se divide en componentes con nombres y

ubicaciones determinados, que se denominan
mdulos y que se integran para satisfacer los
requisitos

El software monoltico (es decir, un programa grande

compuesto de un solo mdulo) no puede ser
estudiado fcilmente, ya que el nmero de caminos
de control, el nmero de variables y la complejidad
global haran el cdigo prcticamente indescifrable
8
Fundamentos del Diseo
ARQUITECTURA DEL SOFTWARE, La
arquitectura del software se refiere a dos
caractersticas importantes del software:
La estructura jerrquica de los mdulos
del software
La estructura de los datos

9
Fundamentos del Diseo
JERARQUA DE CONTROL
Tambin se le conoce como estructura del
programa, y representa la organizacin
jerrquica de los mdulos de un programa e
implica una jerarqua de control. La
representacin de jerarqua se suele
representar con diagramas de rbol

10
Fundamentos del Diseo
ESTRUCTURA DE DATOS
La estructura de datos es una representacin de la
lgica que existe entre los elementos individuales de
informacin. Debido a que la estructura de la
informacin afectar de forma determinante al diseo
procedimiental, la estructura de datos es tan
importante como la estructura del programa en la
representacin de la arquitectura del software.
La estructura de datos dicta la organizacin, los
mtodos de acceso, el grado de asociatividad y las
alternativas para el tratamiento de la informacin.
Las estructuras de datos clsicas son los elementos
11 escalares, los arrays, las listas y los arboles
Fundamentos del Diseo
PROCEDIMIENTOS DEL SOFTWARE
La estructura del programa define la jerarqua
de control, independientemente de las
decisiones y secuencias de procesamiento. El
procedimiento del software se centra en los
detalles de procesamiento de cada mdulo
individual

12
Fundamentos del Diseo
OCULTAMIENTO DE INFORMACIN
El concepto de modularidad nos lleva a la pregunta: cmo
descomponer una solucin de software en el mejor conjunto de
mdulos?
El principio de ocultamiento de la informacin sugiere que los mdulos
deben especificarse de forma que la informacin (procedimientos y
datos) contenida dentro de un mdulo sea inaccesible a otros mdulos
que no necesiten tal informacin.
Por tanto se trata de definir una serie de mdulos independientes que
se comuniquen slo a travs de la informacin necesaria para realizar la
funcin de software.
El uso de ocultamiento de informacin en el diseo facilitar las
modificaciones, prueba y mantenimiento del software, ya que como la
mayora de los datos y de los procedimientos estn ocultos a otras
partes del software, ser menos probable que los errores que se
introduzcan durante la modificacin se propaguen a otros mdulos del
13 software.
Diseo Modular
Independencia Funcional

La independencia funcional es una derivacin

directa de la modularidad, de la abstraccin y
del ocultamiento de informacin

La independencia se mide con dos criterios

cualitativos que son la cohesin y el
acoplamiento.
14
Pasando del Anlisis al Diseo
[Pressman 05]

15
Diseo

Es el proceso de aplicar varias

tcnicas y principios con el propsito
de definir un dispositivo, proceso o
sistema con suficiente detalle que
permita su realizacin fsica.

Diseo es mas que programar o

escribir cdigo

16
Guas para un Diseo de Calidad

.. .Hay una diferencia entre hacer que

un software trabaje, y hacerlo que
trabaje correctamente. . .

17
Guas para un Diseo de Calidad (cont.)
1. Un buen diseo debe tener una arquitectura que:
1. Se ha creado utilizando estilos o patrones reconocidos
2. Esta hecho de componentes
3. Se puede implementar de una manera evolutiva, facilitando la
implementacin y las pruebas
2. Un buen diseo es modular, es decir, puede partirse de
manera lgica en elementos o subsistemas.
3. Un buen diseo contiene representaciones
diferenciales de datos, arquitectura, interfaces y
componentes.

18
Guas para un Diseo de Calidad (cont.)

4. Un buen diseo debe conducir a estructuras

de datos que son apropiadas para las clases a
implementarse, y que resultan de patrones
reconocidos.
5. Un buen diseo debe llevar a componentes
que presentan caractersticas funcionales
independientes.
6. Un buen diseo debe conducir a interfaces que
reducen la complejidad de las conexiones
entre componentes y el medio externo.
19
Guas para un Diseo de Calidad
(cont.)

Un buen diseo debe llevarse a cabo

utilizando mtodos repetibles y que es
conducida por la informacin obtenida en el
anlisis.
Un buen diseo debe representarse usando
una notacin que es efectiva en la manera que
comunica el significado del diseo.

20
Atributos de Calidad en el Diseo

Funcionalidad
Usabilidad
Confiabilidad
Desempeo
Sustentabilidad y que significa todo esto??

21
Conceptos fundamentales de Diseo
1. Abstraccin
2. Refinamiento
3. Arquitectura
4. Modularidad
5. Patrones
6. Clases del diseo

22
Conceptos fundamentales de diseo:
Abstraccin y Refinamiento

1. ABSTRACCIN
La solucin a cualquier problema se presenta en
varios niveles de abstraccin. En el nivel mas alto se
presenta una solucin general. En el nivel mas bajo se
presenta una solucin que puede implementarse
directamente.

2. REFINAMIENTO
La arquitectura de un programa se desarrolla a travs
del detallado sucesivo de niveles.

23
Conceptos fundamentales de diseo:
3. Arquitectura
La arquitectura de software se refiere a la estructura
global del software y la manera en que esta estructura
proporciona integridad conceptual al sistema.
Representa los componentes que tiene el software,
como interactan y la estructura de los datos que usan
estos componentes
El uso de patrones arquitectnicos permitirn a los
diseadores reutilizar componentes
La arquitectura del diseo se puede representar
utilizando diferentes modelos: Estructurales, Plantillas,
Dinmicos, de procesos, y funcionales.

24
Conceptos fundamentales de diseo:
4. Modularidad

Es un atributo del software que permite que un programa

sea manejable intelectualmente hablando.
Tericamente el aumento en el nmero de mdulos
disminuye la complejidad, y por lo tanto el esfuerzo de
resolver un problema; entonces con un nmero infinito
de mdulos tendramos un problema de complejidad
cero.
Sin embargo el aumento en el nmero de mdulos
genera un aumento en el costo por comunicacin entre
mdulos.

25
Nmero de mdulos vs. costo

COSTO O ESFUERZO
costo por
interface

Regin de
mnimo costo

costo por mdulo

NMERO DE MDULOS

26
Otras caractersticas de modularidad
COHESIN
Es la medida de la fuerza funcional de un mdulo o
clase. Se busca que la clase tenga la cohesin mas
alta posible, lo cual ocurre cuando todos sus
elementos contribuyen a la ejecucin de una misma
tarea.
ACOPLAMIENTO
Es la medida de la interdependencia relativa entre
clases. Se busca que exista el mnimo posible de
acoplamiento entre clases, lo cual sucede cuando
las clases se comunican solamente por medio de
mensajes.

27
Cohesin
Grados de Cohesin
Cohesin.
Baja cohesin.
Cohesin coincidente. El mdulo hace muchas cosas sin relacin.
Cohesin lgica. El mdulo hace muchas cosas relacionadas lgicamente.
Cohesin temporal. El mdulo hace muchas cosas relacionadas por el hecho
que deben hacerse al mismo tiempo.
Cohesin moderada.
Cohesin procedimental. El mdulo hace varias cosas relacionadas que
deben ejecutarse en cierto orden.
Cohesin de comunicacin. El mdulo hace varias cosas que trabajan sobre
una sola estructura de datos.
Alta cohesin.
Cohesin funcional. El mdulo hace una sola cosa.
Se busca una moderada o alta cohesin.
Grados de Cohesin
Funcional

30
Grados de Cohesin
Comunicacional

31
Grados de Cohesin
Procedimental

32
Grados de Cohesin
Temporal

33
Grados de Cohesin
Lgica

34
Grados de Cohesin
Coincidental

35
Acoplamiento
Grados de Acoplamiento
Grados de Acoplamiento
Grados de Acoplamiento
Grados de Acoplamiento
Tipo de acoplamiento.
Bajo acoplamiento.
Sin acoplamiento. El mdulo es independiente.
Acoplamiento de datos. El mdulo recibe una lista de argumentos de quien
lo llama.
Acoplamiento moderado.
Acoplamiento de control. El mdulo recibe una bandera de quien lo llama y
se comporta de una manera u otra dependiendo del valor de la bandera.
Alto acoplamiento.
Acoplamiento externo. El mdulo esta acoplado a un dispositivo de I/O
externo. Este tipo de acoplamiento debe limitarse a unos pocos mdulos.
Acoplamiento comn. El mdulo utiliza variables globales o comunes.
Acoplamiento de contenido. El mdulo usa datos contenidos dentro de los
lmites de otro mdulo.
Se busca un bajo o moderado acoplamiento y limitar el uso de
variables globales.
Grados de Acoplamiento
Ej.: Acoplamiento Normal

41
Grados de Acoplamiento
Ej.: Acoplamiento normal

42
Grados de Acoplamiento
Ej.: Acoplamiento por datos

43
Grados de Acoplamiento
Ej.: Acoplamiento de control

44
Grados de Acoplamiento
Ej.: como se resuelve el caso anterior

45
 Conceptos fundamentales de diseo:
5. Patrones

Un patrn de diseo describe una estructura de

diseo que resuelve un problema de diseo
particular, dentro de un contexto especfico.
Un patrn de diseo provee informacin que
permite al diseador determinar si el patrn es
aplicable, si puede re-usarse y si se puede usar
como gua para desarrollar algn patrn similar
con estructura diferente.

46
Conceptos Fundamentales del diseo (cont.)
6. Clases de Diseo
Las clases generadas en el anlisis definen el dominio
del problema.
En el diseo, las clases se definen de manera que se
refinan las clases obtenidas en el anlisis a fin de que se
puedan implementar,
El diseo crea un nuevo conjunto de clases que permiten
implementar la infraestructura de software que va a
sostener la solucin.

47
Niveles de clases del diseo

Se sugieren 5 niveles de clases de diseo:

Clases para el manejo de la interfaz con el
usuario
Clases para el dominio del negocio
Clases para el proceso
Clases para la persistencia
Clases de administracin y control del sistema

48
Caractersticas de clases bien
formadas
Completa y suficiente. Una clase de diseo debe tener
todos los atributos y mtodos razonablemente esperados para
existir.
Primitividad. Los mtodos se deben enfocar en resolver UN
servicio de la clase. Una vez que se ha implementado un
servicio a travs de un mtodo, la clase no debe proveer
ninguna otra manera de hacer la misma cosa
Alta cohesin. Una clase con un diseo cohesivo tiene un
conjunto pequeo y enfocado de responsabilidades y enfoca
exclusivamente sus atributos y mtodos a cumplir esas
responsabilidades
Bajo acoplamiento. Aunque las clases tienen que colaborar
entre s, esta colaboracin debe ser lo mnimo necesario

49
El modelo de diseo
Puede verse desde 2 posibles dimensiones: proceso y
abstraccin
La dimensin del proceso indica la evolucin del modelo
confirme se van ejecutado el proceso de desarrollo de
software
La dimensin de abstraccin representa el nivel de
detalle que surge cuando cada elemento del modelo de
anlisis se va transformando en su equivalente de
diseo, y posteriormente se va refinando iterativamente
La lnea punteada en la figura indica la frontera (difusa)
entre anlisis y diseo

50
Dimensiones del modelo de diseo
[Pressman 05]

51
Elementos de diseo de datos
Crea el modelo de datos e informacin,
representado en un nivel de abstraccin alto, y
se va refinando progresivamente
En la implementacin este modelo de datos se
traduce en bases de datos, las cuales en un
futuro formarn warehouses que permitirn el
manejo de sistemas administradores de
conocimiento de la empresa

52
Elementos de diseo de arquitectura
El modelo de arquitectura se obtiene
principalmente de 3 fuentes:
1. Informacin acerca del dominio de
aplicacin del software a construirse
2. Elementos del modelo de anlisis tales
como diagramas de flujo o clases generadas
en el anlisis sus relaciones y
colaboraciones
3. Disponibilidad de patrones de arquitectura

53
Elementos de diseo de interfaz
Los elementos de diseo de interfaz describen
como la informacin fluye entrando y saliendo del
sistema, y como se comunican a travs de los
componentes definidos como parte de la
arquitectura
Hay 3 elementos importantes en el diseo de
interfaces:
1. Interfaz con el usuario
2. Interfaces externas con otros sistemas, dispositivos,
redes u otros productores o consumidores de
informacin
3. Interfaces internas entre los diferentes componentes
de diseo
54
Diseo de interfaces externas
Requiere informacin definitiva sobre la
entidad a la cual la informacin se manda
o recibe.
Debe incluir pruebas de errores y
caractersticas de seguridad

55
Diseo de interfaces internas
Est fuertemente relacionado con el diseo a nivel
componentes (diseo detallado)
En algunos casos, una interface se disea de igual
manera que una clase.
Segn la OMG una interfaz es un especificador
de operaciones externamente visibles (publicas)
de una clase, componente u otro clasificador
(incluyendo subsistemas) sin la especificacin de
una estructura interna
Una interfaz es un conjunto de operaciones que
describe alguna parte del comportamiento de un
sistema y las operaciones necesarias para
accesar esas operaciones
56
 La ingeniera de diseo comienza cuando la primera
iteracin de la ingeniera de requisitos llega a su fin.
La finalidad del diseo de software es aplicar un
conjunto de principio, conceptos y practicas que
conducen al desarrollo de un sistema o producto de
calidad.
La meta del diseo es crear un modelo de software
que implemente todos los requisitos del cliente de
manera correcta y complazca a aquellos que lo usen