DISEO DE SOFTWARE Y

DISEO ARQUITECTNICO

CONCEPTOS DE DISEO

Qu es el diseo? Es donde se est con un pie en dos mundos-el de la

tecnologa y el de las personas y los propsitos humanos-que tratan de
unificarse

Vitruvio, romano crtico de arquitectura, afirmaba que los edificios bien diseados
eran aquellos que tenan resistencia, funcionalidad y belleza.

El diseo del software cambia continuamente, conforme evolucionan los

nuevos mtodos, surgen mejores anlisis y se obtiene una compresin ms
amplia.

DISEO EN EL CONTEXTO DE LA
INGENIERA DE SOFTWARE

El diseo de software comienza una vez que se han analizado y modelado los
requerimientos, es la ltima accin de la ingeniera de software dentro de la
actividad de modelado y prepara la etapa de construccin (generacin y
prueba de cdigo).
La importancia del diseo de software se rene en una palabra: calidad. El
diseo es el sitio en el que se introduce calidad en la ingeniera de software.

EL PROCESO DE DISEO

El diseo de software es un proceso iterativo por medio del cual se traducen

los requerimientos en un plano para construir el software.

A medida que tienen lugar las iteraciones del diseo, las mejoras posteriores
conducen a niveles menores de abstraccin. stos tambin pueden rastrearse
hasta los requerimientos, pero la conexin es ms sutil.

LINEAMIENTOS Y ATRIBUTOS DE LA
CALIDAD DE SOFTWARE

A travs del proceso de diseo se evala la calidad de ste de acuerdo con la

serie de revisiones tcnicas. McGlaughlin [McG91] sugiere tres caractersticas
que funcionan como gua para evaluar un buen diseo:

Implementar todos los

requerimientos explcitos y
dar cabida a todos los
requerimientos implcitos
que se desean.

Ser una gua legible y

comprensible para quienes
generan el cdigo y para
los que lo prueban y dan
el apoyo posterior.

Proporcionar el panorama
completo del software, y
abordar los dominios de
los datos, las funciones y el
comportamiento desde el
punto de vista de la
implementacin.

LA EVOLUCIN DEL DISEO DE

SOFTWARE

La evolucin del diseo del software es un proceso continuo que ya ha

cubierto casi seis dcadas.

Sin importar el mtodo de diseo que se utilice, debe aplicarse un conjunto de

conceptos bsicos al diseo en el nivel de datos, arquitectura, interfaz y
componente. En las secciones que siguen se estudian estos conceptos.

CONCEPTOS DE DISEO

Durante la historia de la ingeniera de software, ha evolucionado un conjunto

de conceptos fundamentales sobre su diseo.

Todos ayudan a responder las preguntas siguientes:

Qu criterios se usan
para dividir el software
en sus componentes
individuales?

Cmo se extraen los

detalles de la funcin o
la estructura de datos
de la representacin
conceptual del
software?

Cules son los

criterios uniformes que
definen la calidad
tcnica de un diseo
de software?

CONCEPTO DE DISEO
ABSTRACCIN

Cuando se considera una solucin modular para cualquier problema, es

posible plantear muchos niveles de abstraccin.

En el ms elevado se enuncia una

solucin en trminos gruesos con
el uso del lenguaje del ambiente
del problema.

En niveles ms bajos de
abstraccin se da la descripcin
ms detallada de la solucin

CONCEPTO DE DISEO
ARQUITECTURA

La arquitectura del software alude a la estructura general de ste y a las formas en las que
sta da integridad conceptual a un sistema .

Shaw y Garlan describen un conjunto de propiedades que deben especificarse como parte
del diseo de la arquitectura:

Propiedades estructurales.

Propiedades extra funcionales.

Familias de sistemas relacionados

CONCEPTO DE DISEO
PATRONES

Es una mezcla con nombre propio de puntos de vista que contienen la esencia de una
solucin demostrada para un problema recurrente dentro de cierto contexto de necesidades
en competencia .

El objetivo de cada patrn de diseo es proporcionar una descripcin que permita a un

diseador determinar :

1) si el patrn es aplicable al trabajo en cuestin,

2) si puede volverse a usar (con lo que se ahorra tiempo de diseo)

3) si sirve como gua para desarrollar un patrn distinto en funciones o estructura.

CONCEPTO DE DISEO
DIVISION DE PROBLEMAS

La divisin de problemas es un concepto de diseo que sugiere que cualquier

problema complejo puede manejarse con ms facilidad si se subdivide en
elementos susceptibles de resolverse u optimizarse de manera independiente. .

.Un problema es una caracterstica o comportamiento que se especifica en el

modelo de los requerimientos para el software.
Tambin se concluye que cuando se combinan dos problemas, con frecuencia la
complejidad percibida es mayor que la suma de la complejidad tomada por
separado. Esto lleva a la estrategia de divide y vencers.

CONCEPTO DE DISEO
MODULARIDAD

La modularidad es la manifestacin ms comn de la divisin de problemas.

El software se divide en componentes con nombres distintos y abordables por

separado, en ocasiones llamados mdulos, que se integran para satisfacer los
requerimientos del problema.

CONCEPTO DE DISEO
OCULTAMIENTO DE INFORMACIN

El ocultamiento implica que la modularidad efectiva se logra definiendo un

conjunto de mdulos independientes que intercambien slo aquella
informacin necesaria para lograr la funcin del software.

El uso del ocultamiento de informacin como criterio de diseo para los

sistemas modulares proporciona los mximos beneficios cuando se requiere
hacer modificaciones durante las pruebas, y ms adelante, al dar
mantenimiento al software.

CONCEPTO DE DISEO
INDEPENDENCIA FUNCIONAL

El concepto de independencia funcional es resultado directo de la separacin

de problemas y de los conceptos de abstraccin y ocultamiento de
informacin.

La independencia se evala con el uso de dos criterios cualitativos: la cohesin

y el acoplamiento.

CONCEPTO DE DISEO
REFINAMIENTO

Un programa se elabora por medio del refinamiento sucesivo de los detalles

del procedimiento.

En realidad, el refinamiento es un proceso de elaboracin. Inicia con un

enunciado de la funcin (o descripcin de la informacin), definida en un nivel
de abstraccin alto.

La abstraccin y el refinamiento son conceptos complementarios.

CONCEPTO DE DISEO
ASPECTOS

Un aspecto es una representacin de una preocupacin de interferencia.

Es importante identificar aspectos, de modo que el diseo les pueda dar

acomodo conforme sucede el refinamiento y la divisin en mdulos.

En un contexto ideal, un aspecto se implementa como mdulo (componente)

separado y no como fragmentos de software dispersos o regados en
muchos componentes [Ban06].

CONCEPTO DE DISEO
REDISEO

Una actividad de diseo importante que se sugiere para muchos mtodos

giles es el rediseo, tcnica de reorganizacin que simplifica el diseo (o
cdigo) de un componente sin cambiar su funcin o comportamiento.

Cuando se redisea el software, se examina el diseo existente en busca de

redundancias, elementos de diseo no utilizados, algoritmos ineficientes o
innecesarios, estructuras de datos mal construidas o inapropiadas y cualquier
otra falla del diseo que pueda corregirse para obtener un diseo mejor.

CONCEPTO DE DISEO ORIENTADO A OBJETOS

CLASES DE DISEO

Clases de usuario de la interfaz. Definen todas las abstracciones necesarias

Clases del dominio de negocios. Es frecuente que sean refinamientos de las

Clases de proceso. Implantan abstracciones de negocios de bajo nivel que se

Clases persistentes. Representan almacenamientos de datos (por ejemplo, una

Clases de sistemas. Implantan las funciones de administracin y control del

para la interaccin humano-computadora (IHC)

clases de anlisis definidas antes.

requieren para administrar por completo las clases de dominio de negocios.

base de datos) que persistirn ms all de la ejecucin del software.

software que permiten que el sistema opere y se comunique dentro de su

ambiente de computacin y con el mundo exterior.

EL MODELO DEL DISEO

DISEO ARQUITECTONICO

El diseo arquitectnico es la primera etapa en el proceso de diseo.

Bass y otros (Bass et al., 2003) sealan tres ventajas de disear explcitamente y
documentar la arquitectura del software:

Comunicacin con los

stakeholders

Anlisis del sistema

Reutilizacin a gran
escala

DISEO ARQUITECTONICO

Hofmeister y otros (Hofmeister et al., 2000) ponen de manifiesto cmo las

etapas del diseo arquitectnico fuerzan a los diseadores del software a
considerar aspectos de diseo claves en etapas tempranas del proceso.

El estilo y estructura particulares elegidos para una aplicacin puede, por lo

tanto, depender de los requerimientos no funcionales del sistema:
Rendimiento

Proteccin
Disponibilidad

Mantenibilidad

Seguridad

DISEO ARQUITECTONICO

DECISIONES DE DISEO
ARQUITECTNICO

El diseo arquitectnico es un proceso creativo en el que se intenta establecer una

organizacin del sistema que satisfaga los requerimientos funcionales y no funcionales del
propio sistema.

los arquitectos del sistema tienen que responder a las siguientes cuestiones fundamentales:

Existe una arquitectura de aplicacin genrica que pueda actuar como una plantilla para el sistema
que se estn diseando?

Cmo se distribuir el sistema entre varios procesadores?

Qu estilo o estilos arquitectnicos son apropiados para el sistema?

Cul ser la aproximacin fundamental utilizada para estructurar el sistema?

Cmo se descompondrn en mdulos las unidades estructurales del sistema?

Qu estrategia se usar para controlar el funcionamiento de las unidades del sistema?

Cmo se evaluar el diseo arquitectnico?

Cmo debera documentarse la arquitectura del sistema?

DECISIONES DE DISEO
ARQUITECTNICO

El resultado del proceso de diseo arquitectnico es un documento de diseo

arquitectnico.

Los modelos arquitectnicos que pueden desarrollarse pueden incluir:

Un modelo
estructural esttico

Un modelo de
proceso dinmico

Modelos de
relaciones

Un modelo de
interfaz

Un modelo de
distribucin

ORGANIZACIN DEL SISTEMA

La organizacin de un sistema refleja la estrategia bsica usada para

estructurar dicho sistema.

En esta seccin, se incluyen tres estilos organizacionales ampliamente usados:

un estilo de repositorio de datos, un estilo de servicios y servidores
compartidos y una mquina abstracta o estilo por capas en donde el sistema
se organiza en un conjunto de capas funcionales.

El MODELO DE REPOSITORIO

Los subsistemas que forman un sistema deben intercambiar informacin para

que puedan trabajar conjuntamente de forma efectiva. Esto se puede
conseguir de dos formas fundamentales:

Todos los datos compartidos se almacenan en una base de datos central a la que
puede acceder por todos los subsistemas.

Cada subsistema mantiene su propia base de datos. Los datos se intercambian con
otros subsistemas mediante el paso de mensajes entre ellos.

EL MODELO DEL REPOSITORIO

EL MODELO DE REPOSITORIO
VENTAJAS

Los subsistemas que producen datos no

necesitan conocer cmo se utilizan sus
datos por otros subsistemas.

Sin embargo, los subsistemas deben

estar acordes con el modelo de datos
del repositorio.

Las actividades tales como copias de

seguridad, proteccin, control de
acceso y recuperacin de errores estn
centralizadas.

Sin embargo, la evolucin puede ser

difcil a medida que se genera un gran
volumen de informacin de acuerdo
con el modelo de datos establecido.

Sin embargo, diferentes subsistemas

pueden tener distintos requerimientos
de proteccin, recuperacin y polticas
de seguridad.

Sin embargo, puede ser difcil distribuir

el repositorio sobre varias mquinas.

Es una forma eficiente de compartir

grandes cantidades de datos.

DESVENTAJAS

El modelo de comparticin es visible a

travs del esquema del repositorio.

EL MODELO CLIENTE - SERVIDOR

El modelo arquitectnico cliente-servidor es un modelo de sistema en el que

dicho sistema se organiza como un conjunto de servicios y servidores
asociados, ms unos clientes que acceden y usan los servicios.

Un conjunto de servidores

Un conjunto de clientes

Una red

EL MODELO CLIENTE - SERVIDOR

EL MODELO DE CAPAS

El modelo de capas de una arquitectura (algunas veces denominada modelo

de mquina abstracta) organiza el sistema en capas, cada una de las cuales
proporciona un conjunto de servicios.

Un ejemplo del modelo de capas es el modelo de referencia OSI de protocolos

de red (Zimmermann, 1980).

Otro ejemplo que ha tenido cierta influencia fue propuesto por Buxton
{Buxton, 1980), quien sugiri un modelo de tres capas para un Entorno de
Soporte de Programacin en Ada (APSE).

EL MODELO DE CAPAS

ESTILOS DE DESCOMPOSICION
MODULAR

Despus de que se haya elegido la organizacin del sistema en su totalidad, es

necesario decidir la aproximacin a usar para descomponer los subsistemas en
mdulos.

No hay una distincin clara entre subsistemas y mdulos, pero resulta til
pensar sobre ellos de la siguiente forma:
Un subsistema es un sistema en s
mismo, cuyo funcionamiento no
depende de los servicios
proporcionados por otros
subsistemas.

Un mdulo es normalmente un
componente de un subsistema
que proporciona uno o ms
servicios a otros mdulos.

ESTILOS DE DESCOMPOSICION
MODULAR

Hay dos estrategias principales que se pueden usar cuando se descomponga

un subsistema en mdulos:

Descomposicin orientada a
objetos

Descomposicin orientada a
flujos de funciones

DESCOMPOSICION ORIENTADA A
OBJETOS

DESCOMPOSICION ORIENTADA A
FLUJOS DE FUNCIONES