4.1 Estrategias de Diseño

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 son: v  Arquitectura Se refiere, 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. 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. Un manejador de interface de usuario requiere mayor inteligencia, ya que debe poder administrar la interacción con el usuario, incluyendo manejo de eventos y manipulaciones sobre las pantallas. Una clase aún más inteligente es el controlador o manejador de la lógica completa de la aplicación, ya que es responsables de administrar a los propios manejadores de interface de usuario y relacionar su funcionalidad con el resto del sistema. v  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. Consideraciones relacionadas con la robustez de un sistema: El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario. Cualquier método que acepte parámetros del usuario debe validar la entrada para evitar problemas. El sistema no debe optimizarse hasta que este funcione de manera correcta. A menudo los programadores le dedican demasiado esfuerzo a mejorar partes del código que se ejecutan poco frecuente. El sistema debe incluir estructuras de datos que no tengan límites predefinidos. El sistema debe instrumentar un monitoreo de rendimiento y búsqueda de errores. El encapsulamiento juega un papel fundamental para la robustez del sistema. Ocultar la información interna, atributos e implementación de métodos, a una clase permite que ésta pueda ser cambiada sin afectar al resto del sistema. v  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 reuso del diseño: A través de la herencia se puede incrementar el reuso de código. Se toman los aspectos comunes a clases similares utilizando superclases comunes. El uso impropio de herencia puede hace que los programas sean difíciles de mantener y extender. Como alternativa, la delegación provee un mecanismo para lograr el reúso de código pero sin utilizar herencia. Esto se basa en el uso de agregación a través de clases intermediarias que ocultan la funcionalidad de las clases a las cuales se delega. El encapsulamiento es muy efectivo para lograr el reúso, pudiéndose aplicar tanto al nivel de los objetos como de componentes desarrollados en otras aplicaciones. Estos componentes pueden ser reutilizables como fueron diseñados a simplemente agregando nuevas interfaces. v  Extensibilidad La mayoría de los sistemas son extendidos en manera no prevista por el diseño original. Por lo tanto, los componentes reutilizables mejorarán también la extensibilidad. Las siguientes son algunas de las perspectivas de extensibilidad: Se debe encapsular clases, ocultando su estructura interna a las otras clases. Sólo los métodos de la clase deben accesar sus atributos. No se debe exportar estructuras de datos desde un método. Una clase debe tener un conocimiento limitado de la arquitectura de clases del sistema. Se debe evitar expresiones de casos (case statements) sobre tipos de objetos. Se debe distinguir entre operaciones privadas y públicas.

4.2 Diseño de Objetos.

Contratos

Un contrato es una mecanismo de diseño para agrupar las responsabilidades de una clase que tienen relaciones entre sí, sirviendo como indicadores de los diversos servicios provistos por cada clase.

El contrato es un elemento de abstracción adicional en el manejo de la complejidad del diseño, ayudando en la asignación y reasignación de responsabilidades, donde grupos de responsabilidades funcionalmente relacionadas deben ser comunes a un mismo contrato. A diferencia de los contratos, las responsabilidades representan una visión más detallada de los servicios provistos por la clase. En general, una clase puede apoyar uno o más contratos, aunque a menudo una clase con varias responsabilidades apoya un sólo contrato.

Un contrato entre dos clases representa una lista de servicios que una instancia de una clase puede solicitar de una instancia de otra clase. Todos los servicios especificados en un contrato particular son la responsabilidad del servidor para ese contrato. Las responsabilidades correspondientes al contrato deben ser ofrecidas públicamente. Por lo tanto, para un mejor manejo de la complejidad del sistema, se debe posponer la definición de los aspectos privados de una clase y concentrarse inicialmente en las responsabilidades públicas.

En general, un contrato entre un cliente y un servidor no específica cómo se hacen las cosas, solo qué se hace. Los contratos especifican quien colabora con quien, y qué se espera de la colaboración. El contrato cliente-servidor divide los objetos en dos categoría aquellos que proveen servicios (servidores), y aquellos que piden servicios (clientes). De tal manera, un contrato es una lista de pedidos que le hace un cliente a un servidor. Ambos deben satisfacer el contrato, el cliente haciendo sólo los pedidos que el contrato especifica, y el servidor respondiendo apropiadamente a estos pedidos.

Si una clase define un contrato que tiene relativamente poco en común con el resto de los contratos definidos por esa clase, este contrato debe ser movido a una clase diferente, usualmente una superclase o subclase. De tal manera, se puede refinar las jerarquías de clases maximizando la cohesión de contratos para cada clase. Maximizando la cohesión tenderá a minimizar el número de contratos apoyados por cada clase. Esto es algo deseable, ya que cuanto menos contratos existan, se logrará un sistema más fácil de comprender. En general, la mejor manera de reducir el número de contratos es buscar responsabilidades similares que puedan generalizarse. Esto también resultará en jerarquías de clases más extensibles.

Un buen diseño hace un balance entre clases pequeñas con pocos contratos, fáciles de comprender y reutilizar, con un número reducido de clases más complejas cuyas relaciones entre ellas se puede comprender mas fácilmente. Una técnica para definir contratos es comenzar definiendo primero los contratos de las clases más arriba en las jerarquías. Posteriormente, se definen nuevos contratos para las subclases que agregan nueva funcionalidad. Se debe examinar las responsabilidades para cada subclase y determinar si estas representan nueva funcionalidad o si son simplemente maneras específicas de expresar responsabilidades heredadas, en cuyo caso serían parte del contrato heredado.

4.3 Diseño de Sistema.

Durante el diseño de sistema se toman condiseraciones 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; §  Inclusión de bibliotecas, como por ejemplo, interfaces gráficas (GUI), bibliotecas numéricas y de estructuras de datos; §  Consideraciones de tiempo real, si las hay; §  Aspectos de procesamiento, como concurrencia, paralelismo y distribución; §  Aspectos transaccionales, típicamente en el acceso a bases de datos; §  Organización del sistema en subsistemas; §  Asignación de subsistemas a componentes de hardware y software. 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. En este capítulo simplificaremos de gran manera el efecto del ambiente de implementación. Utilizaremos a Java como lenguaje de programación bajo un procesamiento secuencial y con interfaces gráficas también escritas en Java. Para el Sistema de Reservaciones de Vuelos también incluiremos integración con bases de datos y archivos externos, algo que será manejador a través de las clases interface. 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. Por ejemplo, en el caso de Java, se debe inicialmente escoger una de sus bibliotecas gráficas, como AWT, para luego utilizar el manejo apropiado a través de clases como Event. El uso de estas bibliotecas también afecta la lógica de diseño, ya que se debe contemplar, por ejemplo, en que momentos es apropiado procesar nuevos eventos y cómo se inicializará el sistema. Estas consideraciones y su efe cto sobre el resto del sistema serán discutidas más adelante durante el diseño de objetos. 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. Simplifcaremos al máximo el diseño de la base de datos para minimizar su efecto sobre el sistema completo. Más bien, demostraremos como es posible diseñar buenas clases que permitan en un futuro cambiar de manejadores de bases de datos.

4.4 Revisión del diseño

Cuando el diseño se completa se mantienen reuniones con los clientes para revisarlo antes de avanzar al desarrollo.

El proceso de revisión se realiza en tres etapas en correspondencia con los pasos del proceso de diseño:

1.- Revisión del diseño preliminar.

Los clientes y usuarios se reúnen para validar el diseño conceptual.

Se asegura que todos los aspectos relativos a los requerimientos han sido apropiadamente contemplados en el diseño.

Se invita a participar a ciertas personas claves:

•           Cliente (s), quien ayuda a definir los requerimientos del sistema.

•           Analista (s), quien colabora para definir los requerimientos del sistema

•           Usuario (s), potenciales del sistema.

•           Diseñador (es) del sistema.

2.- Revisión crítica del diseño.

Realiza una revisión crítica del diseño, donde se presenta una vista general del diseño técnico.

Integrantes:

•          Analista (s), quien colabora para definir los requerimientos del sistema.

•          Diseñador (es) del sistema.

•          Un moderador (solo coordina), un secretario (no se involucra).

•          Diseñador (es) de programas para este proyecto.

•          Probador del sistema.

Este grupo es más técnico que el anterior. Ya que la revisión trata de aspectos técnicos.

El moderador conduce la reunión para que se traten dos puntos: si el diseño implementa todos los requerimientos y si es un diseño de calidad.

3.- Revisión del diseño de programas.

Cuando el diseño técnico resulta satisfactorio, los diseñadores de programas estarán en posición de interpretarlo como el conjunto  de descripciones de diseño para los componentes reales, que deben ser codificados y probados.

Después de completar los diseños de programas, pero antes de comenzar la codificación, presentan sus planes.

Integrantes:

•          Analista (s), que produjeran los requisitos del sistema.

•          Diseñador (es) del sistema.

•          Diseñador (es) del programa.

•          Un moderador (solo coordina), un secretario (no se involucra).

•          Diseñador (es) de programas para este proyecto.

•          Probador del sistema.

Este proceso se centra en la detección de defectos más que en su corrección. Además se está evaluando el diseño no a los diseñadores.

El proceso beneficia a todos al encontrar defectos y problemas cuando aún son fáciles y poco costosos de corregir. 

4.5 Diagramas de secuencia.

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.

Ejemplo:

4.6 Herramientas case para el diseño

      El AltovaDatabaseSpy ® 2013 Diseño de base de datos gráfica Editor le permite ver y editar las estructuras de todas las bases de datos a través de una interfaz gráfica de usuario.Puede examinar las tablas y relaciones en una base de datos existente para entender con mayor facilidad, puede editar tablas de bases de datos existentes para satisfacer mejor sus necesidades, o puede agregar tablas enteras y especificar todos los atributos de columna y las relaciones con otras tablas a partir de cero.

Precio licencia: €149

Editor gráfico de diseño de base de datos que permite ver y editar las estructuras de todos sus bases de datos a través de una interfaz gráfica de usuario.

Ventajas:
• Puede examinar las tablas y relaciones en una base de datos existente para comprenderlas más fácilmente.
• Puede editar las tablas de base de datos existentes para satisfacer mejor sus necesidades, o puede agregar tablas enteras y especificar todos los atributos de columna y las relaciones con otras tablas desde cero.
• Permite concentrarse en la estructura subyacente de los datos y las modificaciones requeridas en lugar de los comandos SQL necesarios para ponerlas en práctica.
• Crea automáticamente las sentencias SQL que se necesitan y permite decidir cuando ejecutar dichos scripts.

      DB DesignerFork
Es un sistema de base de datos de diseño visual que integra el diseño entidad relación y la creación de bases de datos.
DB Designer está pensado principalmente para trabajar con MySQL.

Licencia: FREE
Ventajas:
• Está a la altura de aplicaciones comerciales de uso profesional
Desventajas:
• Diseñado para base de datos no muy grandes. Ejemplo: biblioteca, videoclub.

      DB Designer
Es un sistema totalmente visual de diseño de bases de datos, que combina características y funciones profesionales con un diseño simple, muy clara y fácil de usar, a fin de ofrecerte un método efectivo para gestionar tus bases de datos.
Te permite administrar la base de datos, diseñar tablas, hacer peticiones SQL, manuales, ingeniería inversa en MySQL, Oracle, MSSQL y otras bases de datos ODBC, modelos XML y soporte para la función drag-and-drop.
El programa dispone además de una interfaz profesional y de detallados manuales de uso.
Licencia: FREE

Ventajas:

·         Exportar el diseño visual a sentencias SQL

·         Sincronizar con mySQL desde la interfaz

Ingenieria inversa, es decir, si ya tienes una base de datos creada en mysql puedes hacer ingenieria inversa en DBdesignerconectandote a ella y con un solo click crear el modelo entidad-relacion de la misma. 

hh

Bibliografia:

*  http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ANALISIS_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20VIII/8.1.htm

*  http://www.slideshare.net/Ire1711/diseo-de-objetos-y-de-espacios-el-proceso-de-creacin

*  http://www.portalcalidad.com/foros/3602-que_es_revision_del_diseno