4.1 ESTRATEGIAS DE DISEÑO

El diseño se define como la búsqueda de una solución 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 solución conlleva a otro problema.

La cuestión está en cómo abordamos esos retos de diseño. Estudios demuestran que nos enfocamos en resolver los problemas de manera individual alejándonos cada vez más del sistema completo en el que estamos trabajando, “es como diseñar una ventana sin el edificio”, recuerden todo tiene un impacto y en un sistema todo está relacionado.

Así que por otro lado que tal si vemos todo el sistema y así planeamos mejor nuestro diseño, haciendo que las soluciones de una parte no perjudiquen a la otra, o mejor que se complementen entre si. Esto nos ayudara a ver qué lugar social, ambiental y técnico nuestro producto hace parte. Se recomienda que tengamos en cuenta: Metas ambiciosas que resuelvan varios problemas, colaboración a través de diferentes disciplinas, establecer parámetros base, definir la vida útil, iniciar desde cero los diseños, usar datos medibles y no asumir reglas entre otros.

En las siguientes imágenes podemos ver un sencillo pero útil flujo de trabajo para iniciar nuestros diseños o la mejora de ellos

Diseñar es una tarea que involucra muchos aspectos, diseñar es divertido así que si utilizamos las herramientas adecuadas podremos crear productos de una mejor calidad!



Antes de poder resolver el diseño es necesario tomar decisiones generales sobre las estrategias de diseño a seguir. Algunas de las decisiones a tomar se presentan a continuación y se relacionan con aspectos que incluyen la arquitectura, robustez, reúso y extensibilidad del sistema.

ARQUITECTURA 

El término arquitectura se refiere, en nuestro caso, a la organización de las clases dentro del sistema. Durante el modelo de análisis 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 diseño esta arquitectura debe detallarse, pudiéndose 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 capítulo.

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 más inteligentes que otras según el conocimiento y control que tengan sobre las demás clases.

ROBUSTEZ 

La robustez de un sistema debe ser uno de los objetivos principales del diseño. Jamás debe agregarse funcionalidad o simplificar código a expensas de la robustez. El sistema debe estar protegido contra errores y debe al menos ofrecer diagnósticos para las fallas que aún pudiesen ocurrir, en particular aquellas que son fatales. Durante el desarrollo es a veces bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego sean removidas durante la producción. En general se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones

REÚSO 

El reúso es un aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código mejor será la robustez del sistema. Las siguientes son algunas estrategias para mejorar las posibilidades de reúso del diseño:

A través de la herencia se puede incrementar el reúso de código. Se toman los aspectos comunes a clases similares utilizando

4.2 DISEÑO DE OBJETOS

¿Qué es el diseño? Es el proceso previo de configuración mental en la búsqueda de una solución en cualquier área.

Durante el diseño de objetos, se ejecuta la estrategia seleccionada durante el diseño del sistema y se rellenan los detalles. Se produce un desplazamiento del énfasis pasando de los conceptos del dominio de la aplicación a los propios de las computadoras. Los objetos descubiertos durante el análisis sirven como esqueleto del diseño, pero el diseñador debe escoger distintas formas de implementarlos con el objetivo de minimizar el tiempo de ejecución, la memoria y el costo. 

En particular, las operaciones identificadas durante el análisis deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones internas más sencillas.

Las clases, atributos y asociaciones del análisis deben de implementarse en forma de estructuras de datos específicas. Es necesario introducir nuevas clases de objetos para almacenar resultados intermedios durante la ejecución del programa y para evitar la necesidad de recalcularlos. 

La optimización del diseño no debería llevarse a extremos exagerados porque la facilidad de implementación y mantenimiento y la extensibilidad son también objetivo importantes. La fase de análisis determina lo que debe hacer la implementación y la fase de diseño del sistema determina el plan de ataque. 

La fase de diseño de objetos determina las definiciones completas de las clases y asociaciones que se utilizarán en la implementación, así como las interfaces y algoritmos de los métodos utilizados para implementar las operaciones. La fase de diseño de objetos añadirá objetos internos para la implementación y optimizará las estructuras de datos y los algoritmos. El diseño de objetos es análogo a la fase preliminar de diseño del ciclo de vida de desarrollo de software tradicional.

4.3 DISEÑO DE SISTEMAS

Se adapta el modelo al ambiente de implementación. Este paso incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. Aquí deben ser tomadas las decisiones de implementación estratégicas:

•  cómo se incorporará una base de datos en el sistema, 
•  qué bibliotecas de componentes se usarán y cómo, 
•  qué lenguajes de programación se utilizarán, 
•  cómo se manejarán los procesos, incluyendo comunicación y requisitos de rendimiento, 

Durante el diseño se debe decidir cómo mecanismos abstractos como la asociación, serán implementados. Similarmente, si el lenguaje de programación no ofrece ninguna técnica para apoyar herencia, se debe especificar cómo ésta será implementada. 

Durante el diseño de sistema se toman consideraciones en base al ambiente de implementación teniendo como objetivo lograr una buena rastreabilidad de la arquitectura de objetos al código final. Estos objetos deben ser vistos como abstracciones del código a ser escrito donde, por ejemplo, un típico objeto sería representado por un archivo en el sistema, como es el caso de Java. En otros lenguajes, como C++, en lugar de un archivo se escriben dos, uno correspondiente a la interface del objeto y el otro a su implementación. En general, el diseño de sistema incluye diversos aspectos como:

•  Selección del lenguajes de programación a utilizarse, típicamente estructurados u orientados a objetos;
•   Incorporación de una base de datos, típicamente relacionales, relacionales extendidos u orientados a objetos; 
•  Acceso a archivos, en sus diferentes formatos; 

Estos aspectos pueden variar radicalmente entre uno y otro sistema y también pueden afectar de gran manera la arquitectura resultante del sistema. En general existen diversos enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:

Agregando clases abstractas o interfaces que luego serán especializadas según el ambiente de implementación particular. Esto es posible hacer, por ejemplo, cuando el lenguaje de programación, como en el caso de Java, es común a los diversos ambientes.

Instanciando objetos especializados que administren los aspectos particulares del ambiente de implementación particular. Esto puede significar una integración parcial o completa de componentes adicionales a la arquitectura del sistema. Por ejemplo, una integración con las interfaces nativas de Java (JNI) para manejo de aspectos de bajo nivel del ambiente. 

Configurando múltiples versiones del sistema correspondientes a diferentes plataformas. Este es el enfoque más flexible, aunque por lo general el de mayor costo de desarrollo. Por ejemplo, cambios radicales en los lenguajes de programación incluyendo diseños para lenguajes estructurados.

INTERFACES GRÁFICAS 

Las interfaces gráficas tienen como aspecto esencial que toda interacción con el usuario es a través de elementos gráficos, como lo son los botones, menús y textos. En lo que se refiere a la aplicación, todo sistema que interactúe mediante interfaces gráficas está dirigido por eventos. Estos eventos corresponden al movimiento del ratón, el oprimir o soltar uno de sus botones, el oprimir una tecla, junto con los que no son directamente iniciados por el usuario, como los eventos de desplegar una pantalla o interrumpir un programa. 
El desarrollar un sistema dirigido por eventos significa que la aplicación debe desde un inicio considerar un diseño adecuado. 

BASES DE DATOS 

El aspecto de bases de datos siempre juega un papel fundamental en los sistemas de información. La decisión estratégica más importante en nuestro contexto es si utilizar bases de datos relacionales o las orientadas a objetos. Dado su amplia utilización y la situación actual en el mercado, escogeremos para nuestro desarrollo una base de datos relacional utilizando el lenguaje SQL estándar. Simplificaremos al máximo el diseño de la base de datos para minimizar su efecto sobre el sistema completo. Más bien, demostraremos cómo es posible diseñar buenas clases que permitan en un futuro cambiar de manejadores de bases de datos.

4.4 REVISIÓN DE DISEÑO

La revisión se desarrolla según la planificación para determinar si el diseño satisface los requisitos, identificar cualquier problema percibido y proponer acciones de rectificación.

También es una actividad emprendida para asegurar la convivencia, adecuada y eficiencia. 

El propósito de la revisión es entender y analizar con atención el diseño, es porque se debe dedicar a la revisión la mitad del tiempo en planear el diseño. 

•  Verificación del diseño.- El auditor deberá comprobar que: 

Se realiza la verificación del diseño de acuerdo con la planificación para asegurarse de los resultados del diseño cumplan con dichos requisitos de los elementos de entrada del diseño.

•  Validación del diseño.- El auditor deberá comprobar que: 

Se realiza la validación del diseño de acuerdo con planificación para asegurarse del producto.

•  Control de los cambios.- Los cambios el diseño y desarrollo: 

se identifican antes en su implementación del diseño, los cambios se revisan y validan del mismo.

4.5 DIAGRAMA DE SECUENCIAS DE DISEÑO

 En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.

Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que llamo subcaso de uso). En nuestro ejemplo de ajedrez, podemos hacer diagramas de secuencia para "jugar partida" o bien para partes de "jugar partida", como puede ser "mover pieza". 

El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable. 

Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métdos van a implementar, que deben llamar de la clase del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qué datos y en qué orden los tiene que meter en el programa y vea qué salidas y resultados le va a dar el programa. 

El siguiente puede ser un diagrama de secuencia de nuestro ejemplo del ajedrez a un nivel de diseño muy preliminar

Aquí ya hemos decidido que vamos a hacer tres librerías/paquetes, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimiientos válidos y demás) y otra para el algoritmo de juego del ordenador. Hemos puesto una clase representando cada uno de los paquetes y hemos representado el caso de usa "mover pieza".

En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer. El diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y particularidades. Si se quiere dejar muy claro que un determinado error se contempla, por ejemplo, un movimiento no válido por el usuario, entonces sí se puede poner en el diagrama de secuencia, siempre que no "embarulle" demasiado.

En este diagrama sencillo ya vamos dejando algunas cosas claras, como por ejemplo, que la interface de usuario hace llamadas y, por tanto, ve a los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa si seguimos un patrón modelo-vista-controlador, así que ese "Refresca pantalla" lo implementaremos con un patrón observador, pero eso son detalles que quizás no vienen al caso ahora.

4.6 HERRAMIENTAS CASE PARA EL DISEÑO

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, Implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.

Las Herramientas de Ayuda al Desarrollo de Sistemas de Información, surgieron para intentar dar solución a los problemas inherentes a los proyectos de generación de aplicaciones informáticas: plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad de los desarrollos, entre otros. Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE.

Actualmente existe un gran desarrollo y una gran cantidad de este tipo de herramientas, por lo que se hace difícil la elección de una de ellas para el trabajo, tanto personal como corporativo.

En el presente trabajo se describen las funcionalidades y características más relevantes de las principales herramientas CASE existentes en la actualidad, entre ellas: Microsoft Project, Rational Rose, JDeveloper, Magic Draw, Visual Paradigm, Microsoft Visio, BoUML.

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.

Otras definiciones:

           •Las Herramientas CASE son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.

           •La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.

          •Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

           •Análisis de datos y procesos integrados mediante un repositorio.

           •Generación de interfaces entre el análisis y el diseño.

           •Generación del código a partir del diseño.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.