4.

1 Estrategias de Diseo Antes de poder resolver el diseo es necesario tomar decisiones generales sobre las estrategias de diseo a seguir. Algunas de las decisiones a tomar son: Arquitectura Se refiere, 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. 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. Un manejador de interface de usuario requiere mayor inteligencia, ya que debe poder administrar la interaccin con el usuario, incluyendo manejo de eventos y manipulaciones sobre las pantallas. Una clase an ms inteligente es el controlador o manejador de la lgica completa de la aplicacin, ya que es responsables de administrar a los propios manejadores de interface de usuario y relacionar su funcionalidad con el resto del sistema. 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. Consideraciones relacionadas con la robustez de un sistema:

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 sistema no debe optimizarse hasta que este funcione de manera correcta. A menudo los programadores le dedican demasiado esfuerzo a mejorar partes del cdigo que se ejecutan poco frecuente.

Edgardo ortega delgado

El sistema debe incluir estructuras de datos que no tengan lmites predefinidos. El sistema debe instrumentar un monitoreo de rendimiento y bsqueda de errores. El encapsulamiento juega un papel fundamental para la robustez del sistema. Ocultar la informacin interna, atributos e implementacin de mtodos, a una clase permite que sta pueda ser cambiada sin afectar al resto del sistema.

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 reuso del diseo:

A travs de la herencia se puede incrementar el reuso de cdigo. Se toman los aspectos comunes a clases similares utilizando superclases comunes. El uso impropio de herencia puede hace que los programas sean difciles de mantener y extender. Como alternativa, la delegacin provee un mecanismo para lograr el reso de cdigo pero sin utilizar 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. El encapsulamiento es muy efectivo para lograr el reso, pudindose aplicar tanto al nivel de los objetos como de componentes desarrollados en otras aplicaciones. Estos componentes pueden ser reutilizables como fueron diseados a simplemente agregando nuevas interfaces.

Extensibilidad La mayora de los sistemas son extendidos en manera no prevista por el diseo original. Por lo tanto, los componentes reutilizables mejorarn tambin la extensibilidad. Las siguientes son algunas de las perspectivas de extensibilidad:

Se debe encapsular clases, ocultando su estructura interna a las otras clases. Slo los mtodos de la clase deben accesar sus atributos. No se debe exportar estructuras de datos desde un mtodo. 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 pblicas.

Edgardo ortega delgado

4.2 Diseo de Objetos. Contratos Un contrato es una mecanismo de diseo 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 abstraccin adicional en el manejo de la complejidad del diseo, ayudando en la asignacin y reasignacin de responsabilidades, donde grupos de responsabilidades funcionalmente relacionadas deben ser comunes a un mismo contrato. A diferencia de los contratos, las responsabilidades representan una visin ms detallada de los servicios provistos por la clase. En general, una clase puede apoyar uno o ms contratos, aunque a menudo una clase con varias responsabilidades apoya un slo 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 pblicamente. Por lo tanto, para un mejor manejo de la complejidad del sistema, se debe posponer la definicin de los aspectos privados de una clase y concentrarse inicialmente en las responsabilidades pblicas. En general, un contrato entre un cliente y un servidor no especfica cmo se hacen las cosas, solo qu se hace. Los contratos especifican quien colabora con quien, y qu se espera de la colaboracin. El contrato cliente-servidor divide los objetos en dos categora 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 slo 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 comn 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 jerarquas de clases maximizando la cohesin de contratos para cada clase. Maximizando la cohesin tender a minimizar el nmero de contratos apoyados por cada clase. Esto es algo deseable, ya que cuanto menos contratos existan, se lograr un sistema ms fcil de comprender. En general, la mejor manera de reducir el nmero de contratos es buscar responsabilidades similares que puedan generalizarse. Esto tambin resultar en jerarquas de clases ms extensibles. Un buen diseo hace un balance entre clases pequeas con pocos contratos, fciles de comprender y reutilizar, con un nmero reducido de clases ms
Edgardo ortega delgado

complejas cuyas relaciones entre ellas se puede comprender mas fcilmente. Una tcnica para definir contratos es comenzar definiendo primero los contratos de las clases ms arriba en las jerarquas. 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 especficas de expresar responsabilidades heredadas, en cuyo caso seran parte del contrato heredado.

4.3 Diseo de Sistema. Durante el diseo de sistema se toman condiseraciones en base al ambiente de implementacin teniendo como objetivo lograr una buena rastreabilidad de la arquitectura de objetos al cdigo final. Estos objetos deben ser vistos como abstracciones del cdigo a ser escrito donde, por ejemplo, un tpico objeto sera 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 implementacin. En general, el diseo de sistema incluye diversos aspectos como:

Seleccin del lenguajes de programacin a utilizarse, tpicamente estructurados u orientados a objetos; Incorporacin de una base de datos, tpicamente relacionales, relacionales extendidos u orientados a objetos; Acceso a archivos, en sus diferentes formatos; Inclusin de bibliotecas, como por ejemplo, interfaces grficas (GUI), bibliotecas numricas y de estructuras de datos; Consideraciones de tiempo real, si las hay; Aspectos de procesamiento, como concurrencia, paralelismo y distribucin; Aspectos transaccionales, tpicamente en el acceso a bases de datos; Organizacin del sistema en subsistemas; Asignacin de subsistemas a componentes de hardware y software.

Estos aspectos pueden variar radicalmente entre uno y otro sistema y tambin pueden afectar de gran manera la arquitectura resultante del sistema. En general existen diversos enfoques para la incorporacin del ambiente de implementacin a la arquitectura del sistema:

Agregando clases abstractas o interfaces que luego sern especializadas segn el ambiente de implementacin particular. Esto es posible hacer, por ejemplo, cuando el lenguaje de programacin, como en el caso de Java, es comn a los diversos ambientes.

Edgardo ortega delgado

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

Configurando mltiples versiones del sistema correspondientes a diferentes plataformas. Este es el enfoque ms flexible, aunque por lo general el de mayor costo de desarrollo. Por ejemplo, cambios radicales en los lenguajes de programacin incluyendo diseos para lenguajes estructurados.

En este captulo simplificaremos de gran manera el efecto del ambiente de implementacin. Utilizaremos a Java como lenguaje de programacin bajo un procesamiento secuencial y con interfaces grficas tambin escritas en Java. Para el Sistema de Reservaciones de Vuelos tambin incluiremos integracin con bases de datos y archivos externos, algo que ser manejador a travs de las clases interface. Interfaces Grficas Las interfaces grficas tienen como aspecto esencial que toda interaccin con el usuario es a travs de elementos grficos, como lo son los botones, mens y textos. En lo que se refiere a la aplicacin, todo sistema que interacte mediante interfaces grficas est dirigido por eventos. Estos eventos corresponden al movimiento del ratn, 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 aplicacin debe desde un inicio considerar un diseo adecuado. Por ejemplo, en el caso de Java, se debe inicialmente escoger una de sus bibliotecas grficas, como AWT, para luego utilizar el manejo apropiado a travs de clases como Event. El uso de estas bibliotecas tambin afecta la lgica de diseo, ya que se debe contemplar, por ejemplo, en que momentos es apropiado procesar nuevos eventos y cmo se inicializar el sistema. Estas consideraciones y su efe cto sobre el resto del sistema sern discutidas ms adelante durante el diseo de objetos. Bases de Datos El aspecto de bases de datos siempre juega un papel fundamental en los sistemas de informacin. La decisin estratgica ms importante en nuestro contexto es si utilizar bases de datos relacionales o las orientadas a objetos. Dado su amplia utilizacin y la situacin actual en el mercado, escogeremos para nuestro

Edgardo ortega delgado

desarrollo una base de datos relacional utilizando el lenguaje SQL estndar. Simplifcaremos al mximo el diseo de la base de datos para minimizar su efecto sobre el sistema completo. Ms bien, demostraremos como es posible disear buenas clases que permitan en un futuro cambiar de manejadores de bases de datos. 8.3 Diseo de Objetos

4.4 revisin del diseo Cuando el diseo se completa se mantienen reuniones con los clientes para revisarlo antes de avanzar al desarrollo. El proceso de revisin se realiza en tres etapas en correspondencia con los pasos del proceso de diseo: 1.- Revisin del diseo preliminar. Los clientes y usuarios se renen para validar el diseo conceptual. Se asegura que todos los aspectos relativos a los requerimientos han sido apropiadamente contemplados en el diseo. 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. Diseador (es) del sistema.

2.- Revisin crtica del diseo. Realiza una revisin crtica del diseo, donde se presenta una vista general del diseo tcnico. Integrantes: Analista (s), quien colabora para definir los requerimientos del sistema. Diseador (es) del sistema. Un moderador (solo coordina), un secretario (no se involucra). Diseador (es) de programas para este proyecto. Probador del sistema. Este grupo es ms tcnico que el anterior. Ya que la revisin trata de aspectos tcnicos. El moderador conduce la reunin para que se traten dos puntos: si el diseo implementa todos los requerimientos y si es un diseo de calidad.

Edgardo ortega delgado

3.- Revisin del diseo de programas. Cuando el diseo tcnico resulta satisfactorio, los diseadores de programas estarn en posicin de interpretarlo como el conjunto de descripciones de diseo para los componentes reales, que deben ser codificados y probados. Despus de completar los diseos de programas, pero antes de comenzar la codificacin, presentan sus planes. Integrantes: Analista (s), que produjeran los requisitos del sistema. Diseador (es) del sistema. Diseador (es) del programa. Un moderador (solo coordina), un secretario (no se involucra). Diseador (es) de programas para este proyecto. Probador del sistema.

Este proceso se centra en la deteccin de defectos ms que en su correccin. Adems se est evaluando el diseo no a los diseadores. El proceso beneficia a todos al encontrar defectos y problemas cuando an son fciles y poco costosos de corregir.

4.5 Diagramas de secuencia.

Hemos terminado de estudiar los refinamientos que se hicieron sobre las abstracciones. En esta etapa, las clases tienen ya definidas las operaciones que en la parte de anlisis eran slo 'frases'. A continuacin se presentan nuevos diagramas de secuencia en donde se aplican las modificaciones que acabamos de realizar. Para empezar, se muestra el diagrama de inicio de la aplicacin.

Edgardo ortega delgado

En este diagrama podemos ver como la aplicacin crea las instancias del manejador, del procesador y del stack con el que se va a trabajar. Enseguida, la aplicacin le pide al manejador que se cree la ventana correspondiente, y esta entra en su ciclo de espera. Cuando la aplicacin termina, se ve como se destruyen los objetos.

Edgardo ortega delgado

4.6 herramientas case para el diseo El Altova DatabaseSpy 2013 Diseo de base de datos grfica Editor le permite ver y editar las estructuras de todas las bases de datos a travs de una interfaz grfica 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 grfico de diseo de base de datos que permite ver y editar las estructuras de todos sus bases de datos a travs de una interfaz grfica de usuario. Ventajas: Puede examinar las tablas y relaciones en una base de datos existente para comprenderlas ms fcilmente. 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 prctica. Crea automticamente las sentencias SQL que se necesitan y permite decidir cuando ejecutar dichos scripts.

DB Designer Fork Es un sistema de base de datos de diseo visual que integra el diseo entidad
Edgardo ortega delgado

relacin y la creacin 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: Diseado para base de datos no muy grandes. Ejemplo: biblioteca, videoclub.

DB Designer Es un sistema totalmente visual de diseo de bases de datos, que combina caractersticas y funciones profesionales con un diseo simple, muy clara y fcil de usar, a fin de ofrecerte un mtodo efectivo para gestionar tus bases de datos. Te permite administrar la base de datos, disear tablas, hacer peticiones SQL, manuales, ingeniera inversa en MySQL, Oracle, MSSQL y otras bases de datos ODBC, modelos XML y soporte para la funcin drag-and-drop. El programa dispone adems de una interfaz profesional y de detallados manuales de uso. Licencia: FREE Ventajas: Exportar el diseo 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 DBdesigner conectandote a ella y con un solo click crear el modelo entidad-relacion de la misma.

Edgardo ortega delgado

Edgardo ortega delgado