Diseo del Software

Disear es una forma de resolucin de problemas y juega un papel

clave en el desarrollo de software porque permite a los ingenieros
de software producir diversos modelos que:

Caracterizan la solucin a implementar.

Pueden ser analizados y evaluados con el fin de determinar si
se satisfacen los requisitos.
Facilitan el examen y evaluacin de alternativas.
Sirven para planificar las siguientes actividades del
desarrollo.

Disear es el esfuerzo para definir la arquitectura, componentes,

interfaces y otras caractersticas de un sistema o componente IEEE
610-1990].
El Diseo de Software es la actividad del ciclo de vida del software
en la cual se analizan los requisitos para producir una descripcin
de la estructura interna del software que sirva de base para su
construccin.
La salida o resultado del diseo es un conjunto de modelos y
artefactos que registran las principales decisiones adoptadas.
Un diseo de software describe la arquitectura del software (cmo
est descompuesto y organizado en componentes), las interfaces entre
dichos componentes, y los componentes a un nivel de detalle que
permita su construccin.
El estndar ISO 12207 identifica dos tipos de diseo de software:
1. Arquitectural o Arquitectnico [alto nivel]: Describe la
estructura y organizacin de alto nivel, es decir, los
subsistemas o componentes y sus relaciones
2. Detallado [bajo nivel]: Describe cada componente y su
comportamiento especfico, de forma que puede procederse a su
construccin.

Diseo Arquitectural o Arquitectnico

Es el primer paso en el diseo de un sistema, previo al diseo
detallado, su resultado se conoce como arquitectura del software y
representa el enlace o conexin entre la especificacin de requisitos
y el diseo, puede llevarse a cabo en paralelo con actividades de
especificacin de requisitos. Implica un esfuerzo creativo, de forma
que las actividades a realizar pueden cambiar segn la naturaleza
del sistema a desarrollar.
En el diseo arquitectnico se
decisiones como las siguientes:

hace

necesario

tomar

algunas

Existe una arquitectura genrica que pueda ser usada?

Cmo ser distribuido el sistema?
Qu estilos arquitectnicos son apropiados?
Qu aproximacin se utilizar para estructurar el sistema?
Cmo se descompondr el sistema en mdulos?
Qu estrategia de control se utilizar?
Cmo se evaluar el diseo arquitectnico resultante?
Cmo se documentar la arquitectura?

Principios elementales de diseo

Los principios de diseo son verdades bsicas o leyes generales que
se utilizan como base de razonamiento o como gua para actuar.
Los principios del diseo software son nociones claves consideradas
fundamentales en muchas aproximaciones y conceptos de diseo
diferentes.
Algunos principios bsicos son:
Abstraccin: consideracin aislada de las cualidades esenciales de
un objeto, o del mismo objeto en su pura esencia o nocin.
Acoplamiento: Fortaleza de las relaciones entre mdulos.
Cohesin: cmo estn relacionados los elementos de un mismo mdulo.
Descomposicin: descomponer un software en diversas unidades ms
pequeas, habitualmente con el fin de situar
diferentes
funcionalidades o responsabilidades en diferentes componentes.

Encapsulamiento (ocultamiento de informacin): consiste en agrupar

y empaquetar los elementos y detalles internos de una abstraccin y
hacer que dichos detalles sean inaccesibles desde fuera.
No te repitas: el DRY (Dont repeat yourself) es uno de los
principios ms importantes. Y adems muy simple de entender. No hay
que escribir cdigo duplicado. El cdigo duplicado es propenso a
generar errores y es difcil de mantener. Si se est repitiendo
cdigo, se debe extraer ese cdigo a una funcin para encapsularlo.
Si se tiene que hacer un cambio, este estar localizado en un solo
punto, y no desparramado por todo el cdigo fuente.
Que sea simple, estpido: conocido como KISS (Keep It Simple Stupid)
y se refiere a que el diseo de un programa debe ser sencillo. Cunto
ms sencillo sea, mejor. Hay que evitar la complejidad como norma
general, pero sobre todo la complejidad innecesaria.
El principio YAGNI: muchas veces, para evitar problemas posteriores,
los programadores tienden a desarrollar funcionalidades que no estn
seguros de necesitar. Simplemente lo hacen por si acaso. El
principio YAGNI (You aint gonna need it), viene a decir que no se
debe implementar algo si no se est seguro de necesitarlo. As se
ahorra tiempo y esfuerzo.
La regla del Boy Scout: los diseadores deben hacer como los Boy
Scout, que dejan el campo ms limpio que cundo llegaron. El cdigo
siempre puede mejorar. Si se puede, se debe refactorizar el cdigo
para dejarlo todava ms limpio y simple que antes.
La Ley de Demeter: Segn este principio, una unidad solo debe tener
conocimiento limitado de otras unidades, y solo conocer aquellas que
estn relacionadas. La una unidad solo debe hablar con amigos y nunca
con extraos.
El principio de Hollywood: basado en la tpica respuesta que se les
da a los actores que hacen una prueba para una pelcula: No nos
llame, nosotros le llamaremos. Este principio est relacionado con
el principio de inversin de dependencias de SOLID. Un ejemplo del
principio de Hollywood es la inversin de control (IoC), que hace
que una clase obtenga las referencias a objetos que necesita para
funcionar, a travs de una entidad externa.

Al momento de desarrollar software y en especfico al comenzar con

la fase de diseo se pueden reconocer los siguientes tipos: 1)
arquitectnico, 2) de datos, 3) de interfaz y 4) procedimental.
El diseo arquitectnico se encarga de la definicin de los
componentes estructurales del software, cuando se habla de
componentes estructurales dependiendo de la metodologa de
desarrollo pueden ser mdulo y clases.
El diseo de datos reconoce y transforma la informacin requerida
por el software en estructuras de datos que puedan ser implementadas
durante la fase de codificacin.
El diseo de interfaz establece la relacin que se dar entre hombre
y mquina, a este tipo de diseo se le denomina interfaz externa,
mientras que la relacin que se da entre los componentes internos
del software se denomina interfaz interna.
El diseo procedimental transforma los componentes estructurales del
software en descripciones procedimentales o algortmicas.

Modularidad del software

Un buen diseo debe estar basado en una alta cohesin y un bajo
acoplamiento, dicha regla proviene de la dcada de los ochentas y
fue uno de los primeros principios proclamados del diseo
estructurado, y pas luego a la orientacin a objetos.
La cohesin y acoplamiento tiene que ver con la modularidad.
Modularidad
El aporte ms importante que hizo el diseo estructurado fue la idea
de que, para resolver un problema complejo de desarrollo de software,
conviene separarlo en partes ms pequeas, que se puedan disear,
desarrollar, probar y modificar, de manera sencilla y lo ms
independientemente posible del resto de la aplicacin.

Esas partes, cuando se quiere usar un nombre genrico, habitualmente

se denominan mdulos. De all que otro nombre para la programacin
estructurada, luego cado en desuso, fue programacin modular.
El diseo estructurado, al plantear la separacin del sistema en
mdulos, se bas en las propias funciones del sistema. Esto es, los
mdulos de la programacin estructurada seran los procedimientos y

funciones. Por lo tanto, al modularizar, lo que se hace es tomar la

solucin del problema, y separarla en partes. En programacin
estructurada se modulariza la solucin, el cmo del desarrollo.
En el diseo orientado a objetos, en cambio, la modularizacin
esencial se da a nivel de clases, que no son funciones del sistema,
sino (al menos en una primera aproximacin) entidades del dominio
del problema. Por lo tanto, en el anlisis y diseo orientados a
objetos, no se modulariza la solucin, sino primero el problema (en
el anlisis) y luego, partiendo de esas clases conceptuales, del
dominio del problema, se modulariza la solucin (diseo). Bertrand
Meyer tiene una frase bastante acertada al hablar de cmo obtener
los mdulos en la orientacin a objetos: No pregunte qu hace el
sistema, sino a quin se lo hace.
La orientacin a objetos tambin tiene mdulos funcionales, que
seran los mtodos u operaciones de las clases, pero estos tienen
una importancia menor respecto del mdulo por excelencia, que es la
clase. Finalmente, en el diseo orientado a objetos, suele aparecer
otro tipo de mdulo ms, el paquete, de escasa relevancia semntica,
pero importante para agrupar clases en el diseo de aplicaciones
medianas.
Cohesin
La cohesin tiene que ver con que cada mdulo del sistema se refiera
a un nico proceso o entidad. A mayor cohesin, mejor: el mdulo en
cuestin ser ms sencillo de disear, programar, probar y mantener.
En el diseo estructurado, se logra alta cohesin cuando cada mdulo
(funcin o procedimiento) realiza una nica tarea trabajando sobre
una sola estructura de datos. Un test o prueba que se suele hacer a
los mdulos funcionales para ver si son cohesivos es analizar que
puedan describirse con una oracin simple, con un solo verbo activo.
Si hay ms de un verbo activo en la descripcin del procedimiento o
funcin, e debera analizar su particin en ms de un mdulo, y
volver a hacer el test.

En el diseo orientado a objetos las cosas son ms complejas. Como

se dijo, hay tres tipos de mdulos: clases, mtodos y paquetes. Con
los mtodos, se puede adoptar las mismas definiciones y recetas que
para los procedimientos y funciones del diseo estructurado. Qu
ocurrira con los otros dos?

Las clases tendrn alta cohesin cuando se refieran a una nica

entidad. Se puede garantizar una fuerte cohesin disminuyendo al
mnimo las responsabilidades de una clase: si una clase tiene muchas
responsabilidades probablemente haya que dividirla en dos o ms. Y
el test a aplicar sera ver si se puede describir a la clase con una
oracin simple que tenga un nico sustantivo en el sujeto. Si la
clase estuviera representando alguna operacin (por la aplicacin de
algn patrn de diseo, por ejemplo), tambin habra que tratar de
sustantivarla y aplicarle la prueba para ver si es cohesiva. Una
clase con alta cohesin suele cumplir el principio de nica
responsabilidad.
En los paquetes no es usual analizar cohesin. Sin embargo, nadie
impide aplicarle los mismos tests que a las clases. Sin embargo, lo
crucial en los paquetes es el acoplamiento.
Acoplamiento
El acoplamiento mide el grado de relacionamiento de un mdulo con
los dems. A menor acoplamiento, mejor: el mdulo en cuestin ser
ms sencillo de disear, programar, probar y mantener.
En el diseo estructurado, se logra bajo acoplamiento reduciendo las
interacciones entre procedimientos y funciones, reduciendo la
cantidad y complejidad de los parmetros y disminuyendo al mnimo
los parmetros por referencia y los efectos colaterales.
De nuevo, el diseo orientado a objetos complica las cosas con sus
tres tipos de mdulos. A los mtodos, como pas con la cohesin, se
puede analizarlos con los mismos criterios que a los mdulos del
diseo estructurado.
Una clase, en cambio, tendr bajo acoplamiento cuando tenga la menor
dependencia posible de otras clases. Esta dependencia significa que
si bien puede haber muchas clases que dependen de una debera
haber pocas dependencias hacia otras clases desde una sola.

Las
dependencias
que
importan
son,
de
mayor
a
menor:
generalizacin/herencia, composicin, asociacin y dependencia
dbil. Para visualizar estas cuestiones, los diagramas de clases son
herramientas fundamentales.
Y los paquetes? Un paquete debe cumplir con estos mismos requisitos,
en el sentido de que debe tener vinculaciones mnimas con otros

paquetes. Se dice que hay dependencia entre paquetes cuando hay

clases de un paquete que dependen de clases de otro paquete, sea por
herencia, asociacin o simple dependencia dbil. En este caso, uno
se puede apoyar con un diagrama de paquetes, ya que este muestra
dependencias entre conjuntos de clases y sirve para eliminar
problemas de acoplamiento.
A modo de resumen, la modularidad es la capacidad que tiene un
sistema de ser estudiado, visto o entendido como la unin de varias
partes que interactan entre s y que trabajan para alcanzar un
objetivo comn, realizando cada una de ellas una tarea necesaria
para la consecucin de dicho objetivo. Cada una de esas partes en
que se encuentre dividido el sistema recibe el nombre de mdulo.
Idealmente un mdulo debe poder cumplir las condiciones de caja
negra, es decir, ser independiente del resto de los mdulos y
comunicarse con ellos (con todos o slo con una parte) a travs de
unas entradas y salidas bien definidas.