Ttulo:

4.1 Estrategias de diseo

Autor:

Jaime Alberto Orozco Toro

El diseo se define como la bsqueda de una solucin en cualquier campo,

sin embargo las soluciones no llegan de una manera simple, muchas veces
realizamos soluciones complejas a problemas sencillos o en otras ocasiones
una
gran
solucin
conlleva
a
otro
problema.
La cuestin est en cmo abordamos esos retos de diseo. Estudios
demuestran que nos enfocamos en resolver los problemas de manera
individual alejndonos cada vez ms del sistema completo en el que
estamos trabajando, es como disear una ventana sin el edificio,
recuerden todo tiene un impacto y en un sistema todo est relacionado.
As que por otro lado qu tal si vemos todo el sistema y as planeamos
mejor nuestro diseo, haciendo que las soluciones de una parte no
perjudiquen a la otra, o mejor que se complementen entre s. Esto nos
ayudara a ver qu lugar social, ambiental y tcnico nuestro producto hace
parte. Se recomienda que tengamos en cuenta: Metas ambiciosas que
resuelvan varios problemas, colaboracin a travs de diferentes disciplinas,
establecer parmetros base, definir la vida til, iniciar desde cero los
diseos, usar datos medibles y no asumir reglas entre otros.
En las siguientes imgenes podemos ver un sencillo pero til flujo de trabajo
para iniciar nuestros diseos o la mejora de ellos

Disear es una tarea que involucra muchos aspectos, disear es divertido

as que si utilizamos las herramientas adecuadas podremos crear productos
de
una
mejor
calidad
Antes de poder resolver el diseo es necesario tomar decisiones generales

sobre las estrategias de diseo a seguir. Algunas de las decisiones a tomar

se presentan a continuacin y se relacionan con aspectos que incluyen la
arquitectura, robustez, reso y extensibilidad del sistema.

ARQUITECTURA
El trmino arquitectura se refiere, en nuestro caso, a la organizacin de las
clases dentro del sistema. Durante el modelo de anlisis se gener una
arquitectura de clases para el sistema y se defini la funcionalidad
conceptual ofrecida por las distintas clases dentro de la arquitectura.
Durante el diseo esta arquitectura debe detallarse, pudindose cambiar los
aspectos considerados inicialmente, como fue la funcionalidad inicialmente
asignada a cada clase, e incluso las propias clases, como hemos
mencionado
al
inicio
del
captulo.
El conocimiento y funcionalidad asignada a cada clase puede ser vista como
la inteligencia de cada clase dentro del sistema. En otras palabras,
algunas clases pueden ser vistas como ms inteligentes que otras segn el
conocimiento y control que tengan sobre las dems clases.
ROBUSTEZ
La robustez de un sistema debe ser uno de los objetivos principales del
diseo. Jams debe agregarse funcionalidad o simplificar cdigo a expensas
de la robustez. El sistema debe estar protegido contra errores y debe al
menos ofrecer diagnsticos para las fallas que an pudiesen ocurrir, en
particular aquellas que son fatales. Durante el desarrollo es a veces bueno
insertar instrucciones internas en el cdigo para descubrir fallas, aunque
luego sean removidas durante la produccin. En general se debe escoger
lenguajes de programacin que apoyen estos aspectos, como son el manejo
de excepciones
RESO
El reso es un aspecto fundamental del diseo. Cuanto ms se pueda
reutilizar el cdigo mejor ser la robustez del sistema. Las siguientes son
algunas estrategias para mejorar las posibilidades de reso del diseo:
A travs de la herencia se puede incrementar el reso de cdigo. Se toman
los aspectos comunes a clases similares utilizando

Ttulo:

4.1 Estrategias de diseo

Autor:

Corts Reyes, Julio Enrique

El modelo de diseo es un refinamiento y formalizacin adicional del modelo

del anlisis, donde se toman en cuenta las consecuencias del ambiente de
implementacin. El resultado del modelo de diseo son especificaciones
muy detalladas de todos los objetos, incluyendo sus operaciones y atributos.
El modelo de diseo se basa en el diseo por responsabilidades.
* Se requiere un modelo de diseo ya que el modelo de anlisis no es lo
suficiente formal para alcanzar el cdigo fuente. Por tal motivo se refinan los
objetos, incluyendo las operaciones y atributos. Adems se debe considerar
aspectos como, los requisitos del rendimiento, tiempo real, concurrencia,
lenguaje de programacin, manejo de base de datos, etc.
* Otro objetivo del diseo es validar los resultados de los modelos de
requisitos y anlisis. Durante el diseo, se ve si los resultados anteriores son
apropiados para la implementacin. Si se descubren aspectos que no estn
claros en algunos de los modelos anteriores, estos se aclaran, posiblemente
regresando a etapas anteriores.
* El modelo del diseo se considera como una formalizacin del espacio del
anlisis extendindolo para incluir una dimensin adicional que corresponde
al ambiente de la implementacin, como se ve en el diagrama de la figura.
Esta nueva dimensin, corresponde al ambiente de implementacin, se
considera al mismo tiempo que se refina el modelo. La meta es refinarlo
hasta que sea fcil escribir el cdigo fuente. Como el modelo del anlisis
define la arquitectura general del sistema, se busca obtener una
arquitectura detallada como resultado del modelo de diseo, de manera que
haya una continuidad de refinamiento entre los dos modelos, como se ve en
el diagrama de la figura.
La transicin de anlisis a diseo debe decidirse por separado por cada
aplicacin en particular. Aunque es posible continuar trabajando sobre el
modelo de anlisis. Incluso durante la incorporacin del ambiente de
implementacin, no es recomendable, ya que aumenta su complejidad. Por
tanto es conveniente tener un modelo de anlisis ideal del sistema durante
el ciclo de vida del sistema dado que mucho de los cambios de los sistemas
proviene de cambios en el ambiente de implementacin. Tales cambios se
incorporan fcilmente ya que el mismo modelo del anlisis sirve de base
para el modelo del diseo. De esta manera, el modelo de diseo se ve como
una especializacin del modelo de anlisis segn el ambiente especifico.

Si los cambios en el modelo del diseo provienen de un cambio en la lgica

del sistema, entonces deben hacerse cambios en el modelo de anlisis. Sin
embargo, si el cambio es una consecuencia de la implementacin, entonces
los cambios no deben incorporarse en el modelo de anlisis.
Las estructuras con las cuales se trabajan en el modelo del diseo son
bsicamente las mismas que en el modelo del anlisis. Sin embargo, el
punto de vista cambia, ya que se toma un paso hacia la implementacin. El
modelo del anlisis debe verse como un modelo conceptual y lgico del
sistema, en tanto que el modelo del diseo debe acercarse al cdigo fuente.
Esto significa que se cambia el punto de vista del modelo del diseo a una
abstraccin del cdigo fuente seal. Por lo tanto, el modelo de diseo debe
ser una descripcin de cmo debe estructurarse
En general, los cambio en la arquitectura del sistema para mejorar su
rendimiento deben proponerse hasta que el sistema este (parcialmente).
Construido.
Se considera dos aspectos principales del modelo de diseo.
* Diseo del objeto. Se refina y formaliza el modelo para generar
especificaciones muy detalladas de todos los objetos, incluyendo sus
operaciones y atributos. Se describe cmo interactan los objetos en cada
caso de uso especfico, especificando que debe hacer cada operacin en
cada objeto. Este paso genera las interfaces de los objetos, las cuales
despus deben implementarse mediante mtodos.
DISEO DE SISTEMA
El modelo se adapta al ambiente de implementacin. Este paso incluye
identificar e investigar las consecuencias del ambiente de implementacin
sobre el diseo. Aqu deben tomarse las decisiones de implementacin
estratgicas: como se incorporara una BD en el sistema: que y como se
usaran las bibliotecas de componentes: que lenguajes de programacin se
utilizaran: como se manejaran los procesos incluyendo comunicacin y
requisitos de rendimiento: como se disearan el manejo de excepciones y
recoleccin de basura,etc.
De manera homognea entre los objetos permite que cada objeto sepa
menos cosas. Esto produce objetos ms pequeos y ms fciles de
comprender. La desventaja es que la inteligencia del sistema va de la mano
con la especializacin de las clases. Si todas las clases son inteligentes, esto
significara que estas sern muy especializadas dificultando la extensibilidad
del sistema que requiere generalizar ms las clases.
El tercer enfoque es encontrar un balance entre los dos primeros. La idea es
homogeneizar la inteligencia del sistema solo entre ciertas clases, como las
de control. El resto de las clases, entidad y borde, sern tontas,
generalmente sobreviviendo a modificaciones en el sistema y manteniendo

la lgica introducida durante el modelo de requisitos y el modelo de anlisis

posterior para lograr una mayor robustez del sistema.

La robustez de un sistema debe ser uno de los objetivos principales del

diseo. El sistema debe estar protegido contra errores y ofrecer diagnsticos
que permitan identificar fallas, en particular aquellas que son fatales.
Durante el desarrollo, a veces es bueno insertar instrucciones internas en el
cdigo para descubrir fallas, aunque luego se eliminen durante la
produccin. En general, se debe escoger lenguajes de programacin que
apoyen estos aspectos, como son el manejo de excepciones. Las principales
consideraciones relacionadas con la robustez de un sistema son las
siguientes:
El sistema debe estar protegido contra parmetros incorrectos
proporcionados por el usuario. Cualquier mtodo que acepte parmetros del
usuario debe validar la entrada para evitar problemas. El diseador de
mtodos debe considerar dos tipos de condiciones de error: i) errores
lgicos que se identifican durante el anlisis y ii) errores de implementacin,
incluyendo errores del sistema operativo, como los errores de asignacin de
memoria, o errores de archivos de entrada y salida.
El sistema no debe optimizarse hasta que este funcione de manera correcta.
se debe estudiar las alternativas, como aspectos de memoria, velocidad y
simplicidad de implementacin. No se debe optimizar ms de lo necesario,
ya que la optimizacin compromete la extensibilidad, reus y comprensin
del sistema.
* El sistema debe incluir estructuras de datos de tamao variable, sin lmites
predefinidos. Durante el diseo es difcil predecir la capacidad mxima
esperada para la estructura de datos en la aplicacin. Por tanto, se deben
escoger estructuras de datos como las listas, a diferencia de los arreglos.
* El sistema debe instrumentar un monitoreo de rendimiento y bsqueda de
errores. El esfuerzo para llevarlo a cabo depende del ambiente de
programacin. Si el lenguaje de implementacin no proporciona ningn
apoyo, se aaden mtodos de impresin para cada clase. Tambin se
aaden mensajes de entrada y salida a los mtodos imprimiendo
selectivamente estos valores.
El encapsulamiento es fundamental para la robustez del sistema. Ocultar la
informacin interna, atributos e implementacin de mtodos de una clase,
permite cambiarla sin afectar el resto del sistema. nicamente la interface
de los mtodos afecta a las dems clases.
*REUSO

* El reus es en aspecto fundamental del diseo. Cuanto ms se pueda

reutilizar el cdigo ser mejor la robustez del sistema las siguientes son
algunas estrategias para mejorar las posibilidades del reus de los diseo.
* A travs de la herencia se incrementa el reuso del cdigo. Se toman las
aspectos comunes a clases similares utilizando superficies comunes. Este en
enfoque es efectivo cuando las diferencias entre las clases son pequeas y
las similitudes son grandes. Es importante considerar la naturaleza de cada
herencia para asegurar que no se llegue a extremos donde la aplicacin de
la herencia sea inadecuada.
* El uso impropio de la herencia hace que los programas sean difciles de
mantener y extender. Como alternativa, la delegacin provee un mecanismo
para el reus de cdigo, pero sin utilizar la herencia. Esto se basa en el uso
de agregacin a travs de clases intermediarias que ocultan la funcionalidad
de las clases a las cuales se delega.
Extensibilidad
* Se debe encapsular otra vez la clases, ocultando su estructura internas a
las otras clases. Slo los mtodos de la clase deben accesar a sus atributos.
* No se deben exportar estructuras de datos desde un mtodo. Las
estructuras de datos internas son especficas para el algoritmo del mtodo.
Si se exportan las estructuras se limita la flexibilidad para cambiar el
algoritmo ms adelante.
* Una clase particular debe tener un conocimiento limitado de la
arquitectura de clases del sistema. Este conocimiento abarcar nicamente
las asociaciones entre sta y sus clases vecinas directas. Cualquier
interaccin con un vecino indirecto, se deber hacer mediante llamadas a
los vecinos directos
* Se debe evitar expresiones que requieran un conocimiento explcito de los
tipos de objetos. En su lugar, se debe de aprovechar el polimorfismo a fin de
seleccionar el comportamiento a ejecutarse, basado en el tipo implcito del
objeto.
* Se debe distinguir entre operaciones privadas y pblicas. Se vuelve
costoso cambiar operaciones pblicas, debiendo ser definidas con cuidado.
Las operaciones privadas son internas en la clase y sirven nicamente de
ayuda para implementar operaciones pblicas. Las operaciones privadas
pueden modificarse sin afectar otras clases.

Ttulo:

4.2 Diseo de objetos

Autor:

Marcello Visconti

Un sistema orientado a objetos est compuesto de objetos que interactan,

los cuales mantienen ellos mismos su estado local y proveen operaciones
sobre su estado. La representacin del estado es privada y no se puede
acceder a ella directamente desde fuera del objeto. El proceso de diseo de
objetos comprende el diseo de clases de objetos y las relaciones entre
estas
clases. El
diseo
orientado a objetos comprende el desarrollo de un modelo orientado a
objetos de un sistema de software para implementar los requerimientos
identificados.

Los objetos en un diseo orientado a objetos estn relacionados con el

problema
a
resolver.
Un proceso general para el diseo orientado a objetos puede contener las
siguientes etapas:

Comprender y definir el contexto y los modos de utilizacin del

sistema

Disear la arquitectura del sistema

Identificar los objetos principales del sistema

Desarrollar los modelos de diseo

Especificar las interfaces de los objetos

Ttulo:

4.2 Diseo de objetos

Autor:

Hernn Astudillo

Este numeral contiene las definiciones completas de los casos de uso de la

solucin, el modelo de clases y las asociaciones que se utilizarn en la
implementacin, as como las interfaces y algoritmos de los mtodos
utilizados para implementar las operaciones.

Se recomienda elaborar y documentar los siguientes modelos:

En esta seccin se describir el lmite y la interaccin entre el sistema y los
usuarios mediante casos de uso. Un Caso de Uso es una capacidad funcional
simple e indivisible de un sistema de software, que permite que un usuario
que interacta con el sistema obtenga un resultado til. A continuacin se
aclaran algunos elementos importantes de esta definicin:
Por simple se entiende que, ante varias alternativas para llegar a un mismo
objetivo, se usar el mecanismo ms sencillo que est al alcance del usuario
y que cumpla los requerimientos planteados. Por ejemplo, ante varias
alternativa de autenticacin de un usuario (login/password, reconocimiento
de la huella dactilar, reconocimiento del iris, reconocimiento del DNA, etc.),
se escoger la mas sencilla que garantice el objetivo que se busca.
Por indivisible se entiende que el Caso de Uso maneja una clase de datos
que puede ser tratada de manera uniforme. Lo contrario de indivisible
sera que la clase de datos que se maneja en el Caso de Uso deba ser
primero clasificada en una de varias alternativas, y que dependiendo de
cual sea la alternativa resultante, tenga un tratamiento significativamente
diferente al de otras alternativas. Por ejemplo un Caso de Uso Registrar
contrato laboral puede considerarse indivisible si todos los contratos que
se van a registrar son de la misma naturaleza jurdica, y en consecuencia,
reciben el mismo tratamiento. Por el contrario, si los contratos son de
naturaleza diferente (p. ej. contrato a trmino indefinido, contrato por
prestacin de servicios, contrato de aprendiz del Sena, etc.), en realidad
habr un Caso de Uso por cada una de las clases de contrato, puesto que el
tratamiento de cada uno de estos es significativamente distinto.
Por resultado til se entiende llegar a un estado (p. ej., el contrato laboral
fue verificado y guardado en la Base de datos), u obtener un resultado (p.
ej. para un contrato dado se obtuvo la lista de descuentos y retenciones por
efectuar) que satisface una de las necesidades para las cuales se construye
el sistema.