UNIDAD 4: MODELO DE DISEO

4.1 Estrategias de diseo

A travs de la historia de la ingeniera de software ha evolucionado un conjunto de conceptos fundamentales de diseo de software. Cada uno ofrece al ingeniero de software un fundamento sobre el cual pueden aplicarse mtodos de diseo ms elaborados. Los conceptos fundamentales del diseo de software ofrecen el marco de trabajo necesario para hacer las cosas del modo correcto. ABSTRACCIN Para un problema determinado se pueden considerar muchos grados de abstraccin. En un alto grado de abstraccin una solucin se establece en trminos generales con el lenguaje de entorno del problema. En los grados de menor abstraccin se proporciona una solucin ms detallada de la solucin. Una abstraccin procedimental se refiere a una secuencia de instrucciones que tiene una funcin especfica y limitada. Una abstraccin de datos es una coleccin nombrada de datos que describe un objeto de datos. Por ejemplo, se puede decir que la abstraccin procedimental abrir empleara la informacin contenida en los atributos de la abstraccin de datos puerta. ARQUITECTURA La arquitectura del software alude a la estructura general del software y las formas en las que la estructura proporciona una integridad conceptual para un sistema. La arquitectura es la estructura u organizacin de los componentes del programa (mdulos), la manera en que estos componentes interactan, y la estructura de datos que utilizan los componentes. PATRONES Un patrn de diseo describe una estructura de diseo que resuelve un problema recurrente de diseo particular dentro de un contexto especfico y en medio de fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el patrn.

MODULARIDAD Los patrones de arquitectura y diseo de software materializan la modularidad; es decir, el software se divide en componentes con nombres independientes y

que es posible abordar en forma individual. Estos componentes llamados mdulos se integran para satisfacer los requisitos del problema. La modularidad se basa en la estrategia divide y vencers (es ms fcil resolver un problema complejo cuando ste se divide en piezas ms manejables).

OCULTACIN DE INFORMACIN

El principio de ocultacin de informacin sugiere que los mdulos se caracterizan por las decisiones de diseo que cada uno oculta a los otros. Los mdulos deben especificarse y disearse de manera que la informacin (procedimientos y datos) que est dentro del mdulo sea inaccesible para otros mdulos que no necesiten esta informacin. INDEPENDENCIA FUNCIONAL Es la suma de directa de la modularidad y de los conceptos de abstraccin y ocultacin de informacin. La independencia funcional se consigue al desarrollar mdulos con una funcin determinante y una aversin a la interaccin excesiva con otros mdulos. Los mdulos independientes son ms fciles de mantener, probar, modificar y se reduce la propagacin de errores. REFINAMIENTO El refinamiento es una estrategia de diseo descendente. El desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle procedimentales. El refinamiento hace que el diseador trabaje sobre el enunciado original y que proporcione ms y ms detalles conforme se realiza cada refinamiento sucesivo. La abstraccin y el refinamiento son conceptos complementarios. ESTRATEGIAS DE DISEO La meta del diseo es crear un modelo de software que implemente todos los requisitos del cliente de manera correcta y complazca a aqullos que lo usen. El proceso de diseo avanza de una visin general del software a una visin ms estrecha que define el detalle requerido para implementar un sistema. El proceso de diseo comienza con un enfoque en la arquitectura. Se definen los subsistemas, se establecen mecanismos de comunicacin entre los subsistemas; se identifican los componentes y se realiza una descripcin detallada de cada componente. Adems, se disean las interfaces internas, externas y del usuario.

4.2 Diseo de Objetos

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.

Todas estas actividades se pueden ver como actividades entrelazadas que influyen entre s. Los objetos se identifican y las interfaces se especifican completa o parcialmente en el momento de definir la arquitectura del sistema.

4.3 DISEO DE SISTEMAS

Durante el diseo de objetos, se ha desarrollado un diseo detallado con base en la arquitectura especificada. En general, el diseo de sistemas incluye aspectos como los siguientes: Seleccin del lenguaje de programacin a utilizarse. Incorporacin de bibliotecas (para interfaces grficas, estructuras de datos, etc.) Incorporacin de una base de datos. Incorporacin de archivos en sus diferentes formatos.

Consideraciones de procesamiento, como concurrencia, paralelismo, distribucin y tiempo real. Estos aspectos pueden variar entre un sistema y otro. Adems, pueden afectar de manera importante la arquitectura final del sistema. Existen diferentes enfoques para la incorporacin del ambiente de implementacin a la arquitectura del sistema: Agregar clases abstractas o interfaces que luego se especializarn segn el ambiente de implementacin. Instanciar objetos especializados para la administracin del ambiente de implementacin Configurar mltiples versiones del sistema correspondientes a diferentes plataformas. DISEO DE SISTEMA - LENGUAJES DE PROGRAMACIN Es importante sealar que un diseo orientado a objetos no necesariamente se tiene que implementar mediante un lenguaje orientado a objetos. Sin embargo, es ms natural hacerlo de esta manera. Esto es debido a que los lenguajes orientados a objetos tienen un apoyo directo a los conceptos del anlisis orientado a objetos (encapsulamiento, generalizacin, polimorfismo). Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su conveniencia, mantenimiento y proteccin contra errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y extensin de los programas sea ms fcil y segura. Cabe mencionar que no todos los lenguajes de programacin orientados a objetos implementan de la misma forma los conceptos de la metodologa orientada a objetos. Aspectos como manejo de encapsulamiento, referencias, herencia mltiple varan de manera importante entre los lenguajes de programacin. DISEO DE SISTEMA INTERFACES GRFICAS Las interfaces grficas tienen como objetivo principal administrar la interaccin entre el usuario mediante elementos grficos, como son botones, mens y textos. Las aplicaciones interactivas donde el control del ratn y teclado desempean un papel importante se conocen como sistemas controlados o dirigidos por eventos. Estos eventos comprenden: mover el ratn, oprimir uno de sus botones, oprimir una tecla, etc.

Desarrollar un sistema dirigido por eventos significa que la aplicacin desde un inicio debe considerar un diseo adecuado. Por ejemplo, en Java se escoge alguna de las bibliotecas grficas (AWT o Swing) para utilizar el manejo apropiado de interfaces mediante sus clases (JFrame, Jpanel, JButton). Ms all de estas bibliotecas o clases tambin se afecta la lgica del diseo, ya que se debe contemplar el momento de procesar eventos. Por ejemplo, si se desarrolla un sistema con varias pantallas se puede manejar cada evento mediante una clase para cada pantalla. Otra solucin es usar un JFrame para todas las pantallas y declarar una clase que maneje los eventos del JFrame. En el segundo caso, en lugar de que cada pantalla reciba un evento del usuario, se hace que los eventos sean recibidos por parte de la clase y las pantallas se vuelven ms pasivas y fciles de manipular.

DISEO DE SISTEMA BASES DE DATOS Las bases de datos son fundamentales en los sistemas de informacin. Una decisin estratgica importante en tal contexto es si debe utilizar bases de datos relacionales u orientadas a objetos. En general se consideran tres modelos de bases de datos principales: Modelo relacional: se define una coleccin de tablas donde cada una tiene un nmero especfico de columnas y un nmero arbitrario de filas. Cada objeto se representa como una fila en una tabla y donde cada columna corresponde a un atributo distinto en el objeto. Modelo relacional extendido: el modelo relacional se extiende mediante procedimientos, objetos, versiones y otras nuevas capacidades. No hay un solo modelo relacional extendido, ms bien hay una variedad de ellos, aunque todos comparten las tablas y consultas bsicas del modelo relacional. Modelo orientado a objetos: se define un modelo orientado a objetos donde vara el tipo de encapsulamiento de datos y los procedimientos en el objeto. El trmino orientado a objetos vara segn cada autor. Las bases de datos son depsitos de datos guardados en uno o ms archivos. Existen sistemas de manejo de bases de datos (DBMS) y orientados a objetos (OOBDMS). Las bases de datos dan apoyo en los siguientes aspectos: Mltiples usuarios Mltiples aplicaciones Seguridad Integridad

Distribucin de datos La tarea del diseo se simplifica, creando una tabla correspondiente a cada clase entidad del dominio del problema y manteniendo las asociaciones entre clases. Obviamente el diseo de tablas puede optimizarse para un acceso ms eficiente. DISEO DE SISTEMA ARCHIVOS Aunque es ms efectivo trabajar con bases de datos, es posible utilizar archivos, sobre todo cuando la especificacin del sistema as lo requiera. En el caso de usar una base de datos, regularmente una clase se comunica con el DBMS para hacer solicitudes a cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe por lo que el proceso se hace manualmente.

4.4 Revisiones del diseo

Revisin crtica 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: Revisin del diseo preliminar. Revisin crtica del diseo. Revisin del diseo de programas. REVISIN DEL DISEO PRELIMINAR Los clientes y usuarios se renen para validar el diseo conceptual. Se asegura que todos los aspecto 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 req. del sistema. Analista (s), quien colabora para definir los req. del sistema Usuario (s), potenciales del sistema. Diseador (es) del sistema. Un moderador (solo coordina), un secretario (no se involucra). Otros desarrolladores (entregan perspectiva externa

Se recomienda que el nmero de integrantes sea pequeo de modo que facilite las discusiones. Durante la revisin se presenta a la audiencia el diseo conceptual. Al hacerlo, se demuestra que el sistema tiene la estructura requerida, las funciones y las caractersticas especificadas por los documentos de anlisis. Todos los participantes, en conjunto, verifican que el diseo propuesto incluya el hardware necesario, interfaces con otros sistemas, entradas y salidas. Los clientes aprueban los dilogos y mens, los formatos de los informes y el tratamiento de defectos propuestos 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 req. 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. Analista que escribir la documentacin del sistema. Otros desarrolladores (entregan perspectiva externa). 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. Usando diagramas, datos o ambas cosas, se explican las estrategias de diseo alternativa y como y porque se han tomado las principales decisiones de diseo. Si se identifican problemas mayores el diseo se rehace. 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 req. 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. Analista que escribir la documentacin del sistema. Otros desarrolladores (entregan perspectiva externa). 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. Documentando el diseo Una parte de la documentacin est dirigida a clientes y usuarios, en lenguaje natural para describir que es lo que el sistema har. La segunda parte usa la terminologa tcnica para escribir la estructura del sistema, datos y funciones. Pauta de los informes: Justificacin racional del diseo: donde se delinean las cuestiones crticas y compromisos que fueron considerados en la generacin del diseo. Descripcin de los componentes del sistema: una de las secciones debera indicar como interactan los usuarios con el sistema incluyendo: Finalmente se realiza un referencia cruzada del diseo y los requerimientos.

4.5. Diagramas de secuencias del Diseo.

El Diagrama de Secuencia de un sistema muestra grficamente los eventos que fluyen de los actores al sistema. Su creacin forma parte de la investigacin para conocer el sistema; se incluye dentro de la etapa del anlisis. En UML los Diagrama de Secuencia muestran grficamente los eventos que pasan de los actores al sistema. ACTIVIDADES Y DEPENDENCIAS Los Diagramas de Secuencia de un sistema se preparan durante la fase del anlisis. Para su creacin, debemos formular antes los Casos de Uso. COMPORTAMIENTO DEL SISTEMA Antes de iniciar el diseo lgico de cmo funcionar una aplicacin de software, es necesario investigar y definir su comportamiento como una caja negra. El comportamiento del sistema es una descripcin de lo que

hace, sin explicar la manera en que lo hace. Una parte de la descripcin es un Diagrama de la Secuencia del sistema. DIAGRAMA DE SECUENCIA DEL SISTEMA Los casos de uso indican cmo los actores interactan con el Sistema de Software. Durante esa interaccin un actor genera eventos dirigidos al sistema, solicitando alguna operacin a cambio.

Conviene aislar y explicar grficamente las operaciones que un actor solicita al sistema, porque ello contribuye a entender el comportamiento del sistema. En UML los Diagramas de Secuencia dan una descripcin grfica de las interacciones del actor y de las operaciones que las mismas originan. DIAGRAMA DE SECUENCIA => Representacin que muestra, en un determinado Caso de Uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. A todos los sistemas se los trata como una caja negra; los diagramas se centran en los eventos que trascienden las fronteras del sistema y que fluyen desde los actores hacia los sistemas. El Diagrama de Secuencia debe prepararse para el curso normal de los eventos de un caso de uso y los cursos opcionales ms interesantes.

4.6 Herramientas CASE para el diseo

Las herramientas de diseo, permiten al desarrollador crear un modelo del sistema que se va a construir y tambin la evaluacin de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representacin del anlisis y ayudan a eliminar errores con anticipacin. Herramientas de anlisis y diseo (Modelamiento). Herramientas de creacin de prototipos y de simulacin. Herramientas para el diseo y desarrollo de interfaces. Mquinas de anlisis y diseo (Modelamiento). El sistema experto podra incluir herramientas de diseo asistido por computadora (CAD) con el fin de materializar las expectativas de los clientes y

las aptitudes de la empresa en el diseo final. Esto se lograra implementando una base de datos histrica (Data Warehouse) con referencias al desarrollo de otros filtros con el fin de comparar problemas, inconvenientes o ventajas que se tuvieron al desarrollar dichos productos. De igual forma, para la parte de los clientes se podra implementar una interfaz inteligente entre el sistema CAD y la base de datos del marketing que generara un diseo base del filtro que implicara las preferencias ms significativas de los clientes. A partir de este diseo, los expertos de cada rea podran empezar a buscar un punto de balance entre lo que el cliente quiere y lo que ms le conviene a la empresa para as obtener un diseo final de nuestro filtro. Produccin. Ventas. Ventajas de utilizar un Sistema Experto en la IC Los sistemas expertos propician la efectividad de la empresa en todos sus departamentos, al automatizar algunas de las tareas de la empresa y al concentrar toda la informacin competente al proceso de desarrollo del producto. De esta forma podemos apreciar las siguientes ventajas al usar los sistemas expertos en la ingeniera concurrente lo que generalmente se conoce como ingeniera concurrente asistida por computadora (CACE): Informacin integrada. Este aspecto es el que persigue principalmente el sistema experto, pues se pretende juntar una gran cantidad de informacin que nos sirva de base para desarrollar nuestro producto. Esto promueve el hecho de que todos los participantes del equipo multidisciplinario tengan acceso a la informacin de los dems de manera previa, con el fin de que las juntas se lleven a cabo lo ms rpido posible. La arquitectura del sistema experto podra disearse como una arquitectura cliente/servidor con el fin de que los participantes puedan acceder la informacin en cualquier momento e inclusive al mismo tiempo. Comunicacin eficaz. La gran cantidad de informacin que se encuentra al alcance de los participantes del equipo, propicia que todos conozcan a cierto nivel el proceso de desarrollo visto desde el punto de vista cada departamento, con esto, se evitan discusiones sobre aspectos poco comprendidos en el proceso de diseo. Con el conocimiento general del proceso de desarrollo del producto, la comunicacin se vuelve entonces ms eficaz, pues cada participante conoce los inconvenientes y las ventajas que se tendran para cada departamento en funcin de algn cambio en el diseo del producto. Rpida toma de decisiones. Con la informacin integrada en un solo ncleo y con la agilizacin de la comunicacin entre los participantes del proyecto, se obtiene una aceleracin en la toma de decisiones, producto de tener un equipo de expertos en cada rea pero conocen y comprenden a las dems. La Ingeniera Concurrente (IC) es una filosofa orientada a integrar sistemticamente y en forma simultnea el diseo de productos y procesos, para que sean considerados desde un principio todos los elementos del ciclo de vida de

un producto, desde la concepcin inicial hasta su disposicin final, pasando por la fabricacin, la distribucin y la venta.