Metodología ADOOSI Versión 6: Metodología para el desarrollo de aplicaciones utilizando notación UML y extensiones para
Views 145 Downloads 10 File size 494KB
Metodología ADOOSI Versión 6: Metodología para el desarrollo de aplicaciones utilizando notación UML y extensiones para Web y servicios Web Autor: Dra. Sofía Alvarez Cárdenas Se presenta la metodología ADOOSI-UML versión 6 para el desarrollo de aplicaciones con tecnología orientada a objetos utilizando notación UML (Unified Modeling Language) y la extensión de UML para aplicaciones Web (UML WAE: Web Application Extension). Se utiliza la extensión para aplicaciones Web y se incluyen elementos para la aplicación de los Servicios Web. El ciclo de vida utilizado es el iterativo e incremental y se basa en la utilización de componentes. Se considera los Servicios Web como parte de los posibles componentes a utilizar o desarrollar y se brindan recomendaciones para su uso. En el diseño se incluye la utilización de los patrones GRASP (General Responsibility Assignment Software Patters) y GoF (Gang of Four) y otros. La metodología da un peso importante a la definición de la arquitectura de la aplicación e incluye los patrones para el desarrollo de esta en las aplicaciones Web. La presente guía metodológica incluye toda la documentación a obtener para la aplicación desarrollada, así como la explicación de cada etapa haciendo uso de ejemplos ilustrativos. La documentación propuesta por la metodología se corresponde con la establecida en la norma ISO 19 112. Se incluye el mapa de navegación como instrumento de diseño del comportamiento del prototipo y específicamente como instrumento de diseño de la interfaz Web. Esta metodología se basa también en la experiencia de aplicar ADOOSI (Metodología para el desarrollo orientado a objetos de sistemas informáticos).
Introducción
5
1.1
7
Ciclo de vida del Proyecto.
1.2 Fases y pasos de la metodología 1.2.1 Flujos dentro de cada ciclo de desarrollo 1.2.2 Fase Inicio 1.2.3 Fase de Elaboración 1.2.4 Fase Construcción 1.2.5 Fase de Transición
7 8 8 9 9 9
1.3 Fase Inicio 1.3.1 Obtención del modelo del negocio 1.3.2 Definición del alcance de la aplicación 1.3.2.1 Identificación de los involucrados 1.3.2.2 Formular el problema a resolver 1.3.2.3 Definición de las facilidades del software 1.2.3.4 Definir los requisitos no funcionales 1.3.3 Confección de un prototipo de interfaz 1.3.4 Definición de los casos de uso 1.3.4.1 Identificar los actores 1.3.4.2 Identificar los casos de uso 1.3.4.3 Describir los casos de uso 1.3.5 Selección de los casos de uso para cada ciclo 1.3.5.1 Identificación del núcleo central de la aplicación 1.3.5.2 Identificación de los casos de uso del núcleo central de la aplicación y los de cada ciclo 1.3.6 Analisis de factibilidad 1.3.6.1 Análisis de la factibilidad económica 1.3.6.2 Análisis técnico 1.3.7 Planificación. Obtención del cronograma general de la aplicación 1.3.8 Balance de los artefactos 1.3.9 Revisión y completamiento de la documentación 1.3.9.1 Obtención del modelo del negocio 1.3.9.2 Definición del alcance de la aplicación 1.3.9.3 Requisitos no funcionales 1.3.9.4 Casos de uso 1.3.9.5 Análisis de factibilidad 1.3.9.6 Cronograma general de la aplicación
9 10 10 10 10 10 11 14 14 14 15 15 15 16 16 16 16 17 17 17 17 18 18 18 18 18 18
2
19 19 19 19 24 29 32 38 39 39 39
Fases 2.1 Flujo o disciplina de requisitos 2.2 Flujo o disciplina de análisis 2.2.1 Obtención de los casos de uso detallados 2.2.2 Definición de las clases preliminares y de las asociaciones 2.2.3 Definición del diagrama de clases del análisis 2.2.4 Definición de los diagramas de secuencia y asignación de servicios o responsabilidades 2.2.3 Definición de las operaciones de las clases 2.2.4 Balanceo de los artefactos 2.2.5 Revisión y completamiento de la documentación 2.2.5.1 Paquetes de los casos de uso
2.3 Flujo o disciplina de diseño 2.1.1 Definicion de la arquitectura 2.1.1.1 Definición del patrón de arquitectura
43 43 43
2.1.1.2 Definición del modelo de mini arquitectura (framework) 2.1.1.3 Identificar subsistemas 2.1.1.4 Definición de servicios Web 2.1.1.5 Definición del Diagrama de subsistemas funcionales 2.1.1.6 Definición de las clases y paquetes más significativos 2.3.2 Obtención de los diagramas de clases del diseño 2.3.2.1 Refinamiento de las clases 2.3.2.2 Refinamiento de las asociaciones e inclusión de dependencias 2.3.3 Refinamiento de los diagramas de interacción 2.3.4 Refinamiento de los atributos y responsabilidades de las clases 2.3.4.1 Refinamiento de los atributos 2.3.4.2 Refinamiento de las responsabilidades 2.3.5 Aplicación de patrones de diseño 2.3.5.1 Patrón Polimorfismo 2.3.5.2 Patrón Fábrica Abstracta 2.3.5.3 Patrón Indirección 2.3.5.4 Patrón Publicar-Suscribir u Observador 2.3.5.5 Patrón No hables con extraños 2.3.5.6 Patrón Método Factoría 2.3.5.7 Patrón Solitario (Singleton) 2.3.5.8 Patrón Adaptador (Adapter/Wrapper) 2.3.5.9 Patrón Composición (Composite) 2.3.5.10 Patrón Decorador (Decorator 2.3.5.11 Patrón Fachada (Facade) 2.3.5.12 Patrón “Proxy” 2.3.5.13 Patrón Comando (Command) 2.3.5.14 Patrón Mediador (Mediator) 2.3.5.15 Patrón Estado (State) 2.3.5.16 Patrón Estrategia (Strategy) 2.3.5.17 Patrón Método Plantilla (Template Method) 2.3.5.18 Patrón Transacción (script transaction) 2.3.5.19 Patrón Modelo del Dominio (Domain Model) 2.3.5.20 Patrón “Record Set” 2.3.5.21 Patrón “Gateway” 2.3.5.22 Patrón “Data Mapper” 2.3.5.23 Patrón Modulo Tabla (Table Module) 2.3.5.24 Patrón Objeto de Transferencia de Datos (Data Transfer Object) 2.3.5.25 Patrón “Assembler” 2.3.6 Definición de los diagramas de Transición de Estado 2.3.7 Confección de los diagramas de componentes 2.3.8 Definición de la base de datos relacional 2.3.9 Balanceo de los artefactos 2.3.10 Revisión y completamiento de la documentación 2.3.10.1 Diagramas de capas. 2.3.10.2 Diagramas de paquetes 2.3.10.3 Definición de las clases 2.3.10.4 Base de datos relacional 2.4 Flujo o disciplina de Implementación • Revisión y completamiento de la documentación 2.4.1 Programación y prueba de cada clase del subsistema 2.4.2 Integración de cada subsistema 2.4.3 Integración del software y prueba de la integración de éste 2.4.4 Revisión y completamiento de la documentación 2.4.4.1 Manual del usuario 2.4.4.2 Manual de instalación
47 49 50 50 51 52 53 57 64 64 64 64 65 66 67 67 68 69 70 71 72 73 74 74 75 76 77 78 79 80 81 82 82 82 83 83 84 85 85 89 90 93 93 93 94 95 95 96 96 96 96 96 96 97 99
2.4.4.3
Manual de operación
99
2.5 Disciplina o flujo de prueba 2.5.1 Prueba de validación del software 2.5.2 Prueba del sistema 2.5.2.1 Prueba de recuperación 2.5.2.2 Prueba de seguridad 2.5.2.3 Prueba de resistencia 2.5.2.4 Prueba de rendimiento 2.5.3 Balanceo de artefactos y planificación del próximo ciclo
101 101 101 101 101 101 102 102
2.6 Fase de Transición 2.6.1 Preparación de condiciones 2.6.2 Implantación o despliegue del sistema 2.6.2.1 Implantación en Paralelo 2.6.2.2 Implantación directa
103 103 103 103 103
3
BIBLIOGRAFÍA
105
Metodología ADOOSI Versión 6: Metodología para el desarrollo de aplicaciones utilizando notación UML y extensiones para Web y servicios Web Autor: Dra. Sofía Alvarez Cárdenas Introducción Se presenta la metodología ADOOSI-UML versión 6 para el desarrollo de aplicaciones con tecnología orientada a objetos utilizando notación UML (Unified Modeling Language) ) [Booch, 1997 ] y la extensión de UML para aplicaciones Web (UML (WAE: Web Application Extension) [Conallen 99]. La notación UML se ha convertido en un estándar internacional para el desarrollo de aplicaciones por lo que la notación ha sido tomada de forma rigurosa en la metodología propuesta. Se utiliza la extensión para aplicaciones Web y se incluyen elementos para la aplicación de los Servicios Web. El ciclo de vida utilizado es el iterativo e incremental y se basa en la utilización de componentes. Se considera los Servicios Web como parte de los posibles componentes a utilizar o desarrollar y se brindan recomendaciones para su uso. En el diseño se incluye la utilización de los patrones GRASP (General Responsibility Assignment Software Patters) [Larman] y a los GoF (Gang of Four) [Gamma]. La metodología da un peso importante a la definición de la arquitectura de la aplicación e incluye los patrones para el desarrollo de esta en las aplicaciones Web. Como se especificó antes, la metodología se basa en el desarrollo incremental e iterativo lo que significa que el desarrollo no se realiza de una sola vez para toda la funcionalidad de la aplicación sino que se realiza por ciclos en cada uno de los cuales se agrega una funcionalidad adicional, se comienza con la funcionalidad correspondiente al núcleo central de la aplicación (de manera general el núcleo central de la aplicación se corresponde con la funcionalidad que determina la arquitectura de la aplicación) y se van agregando funcionalidades en cada ciclo hasta alcanzar la aplicación final. Por tanto el desarrollo se realiza de forma incremental e iterativo tal y como se especifica en las mejores prácticas de elaboración de proyectos informáticos [Pressman, 1997] y es recomendado en el proceso de Rational [Kruchten, 1999]. La presente guía metodológica incluye toda la documentación a obtener para la aplicación desarrollada, así como la explicación de cada etapa haciendo uso de ejemplos ilustrativos. La documentación propuesta por la metodología se corresponde con la establecida en la norma ISO 19112. Los artefactos (diagramas, documentos y productos asociados al desarrollo en general utilizados son los correspondientes a la notación UML [OMG] y UML (WAE) para el análisis y el diseño pero con algunas modificaciones para tener en cuenta las características especiales del desarrollo de la aplicación. Se incluye el mapa de navegación como instrumento de diseño del comportamiento del
prototipo y específicamente como instrumento de diseño de la interfaz Web. Esta metodología se basa también en la experiencia de aplicar ADOOSI (Metodología para el desarrollo orientado a objetos de sistemas informáticos) [Alvarez]. ADOOSI contempla el hecho de que existe una coexistencia entre el modelo Orientado a Objetos y el relacional por lo que tiene en cuenta la posibilidad de utilizar Bases de Datos relacionales aunque el diseño sea Orientado a Objetos y se trabaje en un ambiente Orientado a Objeto. El desarrollo se centra en la concepción de la arquitectura de la aplicación y para ello se hace uso de las técnicas de prototipos. En los medios de programación disponibles se posibilita, en general, la confección de un prototipo del sistema [Boar, 1984] e inclusive evolucionar este prototipo en el software final, por esta razón se basa en la filosofía de trabajo que hace uso de prototipos [Connell,1989]. Un prototipo no es más que “una versión de un producto de software desarrollado en los primeros estadios del ciclo de vida de un producto elaborado para propósitos específicos y experimentales” [Currie, 1998]. Un prototipo de software tiene las siguientes características: •
es barato de construir
•
enfatiza en la interfaz del usuario
•
es un sistema vivo de trabajo.
•
es un sistema de software que se crea rápidamente.
•
suministra un medio de comunicación efectivo con el usuario
•
puede ser evaluado por un diseñador y/o los usuarios finales
Uno de los cambios introducidos en ADOOSI Versión 6 es lo referente al uso de patrones de diseño. Christopher Alexander de profesión Arquitecto definió el término patrón para representar problemas de diseño y sus soluciones generales. Luego de trabajar sobre la obra de Christopher Alexander [Coplien 96], los investigadores descubrieron problemas recurrentes y sus respectivas soluciones en el desarrollo de software. Es desde entonces, que el concepto de patrón se extiende al mundo de la información. Existe una tendencia en determinadas compañías de, querer continuamente reinventar; esto puede verse fácilmente en proyectos que dan solución a problemas que anteriores proyectos habían solucionado también. Esto da al traste con buenos diseños y provoca, frecuentemente, el fracaso en el desarrollo del proyecto. Es aquí donde intervienen los patrones, los cuales son una solución extremadamente flexible para la reutilización de código. Un buen número de patrones que documenten buenas prácticas, podrían solucionar grandes problemas en un dominio determinado. El poder de este tipo de documentación es que el conocimiento, previamente adquirido por desarrolladores con experiencia, es capturado en una forma aceptable y puesto al alcance de todos. Los patrones son objetos que han sido
descubiertos en más de un sistema existente, son soluciones exitosas a problemas recurrentes [Rising 98]. A pesar que la mayoría de los estudios realizados han sido dirigidos al desarrollo orientado a objetos, y la mayoría de publicaciones y descubrimiento de patrones se ha realizado sobre este paradigma, la noción de patrones no se encuentra ligada a ninguna metodología o lenguaje. Muchos trabajos sobre patrones han sido desarrollados en sistemas no orientados a objetos. “Los patrones no son un concepto orientado a objetos” [Rising, 1998]. Los principales patrones cuyo uso se recomienda en ADOOSI son: Experto, Creador, Bajo Acoplamiento, Alta Cohesión, Controlador, Polimorfismo, Fabricación pura, Indirección, No hables con extraños, Publicar-Suscribir, Método abstracto, Constructor, Solitario, Composición, Fachada, Proxy, Decorador y Adaptador. Específicamente para las aplicaciones Web se recomienda los patrones: Modelo-Vista-Controlador, Controlador de página, Controlador de fachada, Plantilla de Vista y Vista Transformada. También se utilizan los patrones de Mini arquitectura. Se tiene una experiencia de nueve años en la utilización de ADOOSI, por lo que la presente metodología hereda los instrumentos y procedimientos de ADOOSI e incluye nuevos instrumentos y procedimientos para el desarrollo visual de aplicaciones orientadas a objetos. 1.1 Ciclo de vida del Proyecto. A continuación se detallan las fases de las etapas de la metodología propuesta. 1.2 Fases y pasos de la metodología Las fases de ADOOSI son: Inicio: Definición del alcance del trabajo, del plan y de los requisitos de la aplicación Elaboración: Definición de la arquitectura de la aplicación y del analisis de la aplicación Construcción: Se construye el software en varias iteraciones Transición: Implantación y distribución de la aplicación Se toman estas fases acorde con los nombres utilizados por RUP: Rational Unified Process [Booch] por considerarse un estándar de facto internacionalmente. A continuación se detallan los pasos de cada fase de la metodología, pero como se trata de un enfoque iterativo e incremental en el que se realizan varias iteraciones, se define como ciclo la realización de una iteración. En las iteraciones de Arquitectura se trabaja con un prototipo ejecutable. Una representación gráfica de los ciclos o iteraciones en las fases se muestra en la figura 1.
Entregas
Inicio
Iteración Preliminar
Iteraciones
Elaboración
Construcción
Transición
Iteración de Iteración de Iteración de Iteración de Iteración de Iteración de Iteración de Arquitectura ArquitecturaConstrucció Construcció Construcció Transición Transición
internas
externas
Figura 1 Iteraciones por fase recomendado para proyecto mediano. Para proyecto pequeño la definición de arquitectura puede hacerse en una sola iteración. A continuación se define los flujos de procesos que incluye un ciclo de desarrollo: 1.2.1 Flujos dentro de cada ciclo de desarrollo Análisis: Incluye definir nuevos requisitos: funcionales y no funcionales. Refinar, completar e incluir nuevos casos de uso. Se utiliza además los diagramas de actividad. Definir los diagramas de clases, de interacción, de transición de estado de forma lógica sin incluir los elementos propios de la arquitectura definida ni los elementos de los requisitos no funcionales. Se desarrolla además el grafo de navegación. Diseño: Modificar los diagramas de clases y de secuencia. Incluir interfaces a las clases, paquetes y servicios Web. Incluir los elementos propios de la arquitectura y de los requisitos no funcionales. Lo anterior tiene en cuenta a los elementos propios de la aplicación Web. Se modifica el resultado del analisis con la aplicación de patrones de diseño. Definición de los componentes y su vinculación con las clases. Implementación: Se realiza la codificación de lo diseñado teniendo en cuenta la distribución por componentes. Se utilizan los estándares de codificación disponibles. Prueba: Se realiza las pruebas contra requisitos y casos de uso definidos. Para ello se utilizan los casos de prueba definidos previamente 1.2.2 Fase Inicio Los pasos en esta fase son: • Definición de los requisitos del sistema a nivel general (facilidades) de manera de poder describir el alcance de la aplicación. • Definición de los casos de uso, solo registrar el resumen de cada uno • Estimación de tiempo esfuerzo y costo mediante COCOMO II [Bohem] • Planificación. Obtención del cronograma general de la aplicación
1.2.3 Fase de Elaboración Los pasos en esta fase son: • Detallar los casos de uso • Definición de los casos de uso mas significativos para la aplicación y de la prioridad de todos • Definición de los casos de uso a realizar en cada ciclo • Realización de uno o dos ciclos de desarrollo hasta completar el desarrollo de los casos de uso seleccionados como mas significativos • Definición de los componentes a desarrollar como servicios Web y de los servicios Web de terceros a emplear • Definición de la arquitectura de la aplicación teniendo en cuenta los patrones de las mini arquitectura 1.2.4 Fase Construcción Los pasos en esta fase son: • Realización de tantos ciclos como sea necesario para completar la realización de todos los casos de uso • Realización de las pruebas de unidad y de integración. • Obtención del resultado de un ejecutable válido para realizar la prueba Beta de la aplicación. 1.2.5 Fase de Transición Los pasos en esta fase son: • Distribuir la aplicación en el medio físico • Entrenar a los usuarios • Realizar actividades de cambio en la organización • Evaluar el producto instalado contra el alcance del producto • Liberar el producto y evaluar extensiones y modificaciones
1.3 Fase Inicio La etapa de estudio preliminar permite especificar los objetivos y el rendimiento del software, la interfaz con otros elementos del sistema y las restricciones de diseño que debe considerar el software • Obtención del modelo del negocio • Definición del alcance de la aplicación • Confección de un prototipo de interfaz • Definición de los casos de uso • Selección de los casos de uso para cada ciclo • Análisis de factibilidad • Planificación. Obtención del cronograma general de la aplicación • Balance de los artefactos • Revisión y completamiento de la documentación
1.3.1 Obtención del modelo del negocio La obtención del modelo del negocio es opcional, normalmente solo se realiza si este trabajo es renumerado de forma independiente. Este modelo consiste en la descripción mediante Casos de uso y Diagramas de actividad de la forma en que la gestión se realiza en el objeto a automatizar, puede ser un sistema manual o tener algo informatizado. En el anexo 1 se describen los diagramas de actividad. 1.3.2 Definición del alcance de la aplicación Esta fase implica la identificación de las necesidades del usuario por lo que el analista debe utilizar todas las técnicas de obtención de información que considere apropiadas tales como entrevistas, encuestas, revisión de documentos, técnicas de trabajo en grupo, etc. Se realizan cuatro pasos: • Identificación de los involucrados. • Formular el problema a resolver • Definir las facilidades del sistema • Definir los requisitos no funcionales 1.3.2.1 Identificación de los involucrados Se debe identificar los usuarios finales (hacen uso del sistema que será construido) y los expertos (patrocinadores y consultantes conocedores del dominio del sistema), los clientes, así como las áreas de actividades fundamentales del sistema (se refiere a las áreas que requieren análisis de sistema). 1.3.2.2 Formular el problema a resolver Debe definirse el problema a resolver de manera general mediante un párrafo reflejando los antecedentes correspondientes, existencia o no de sistemas automatizados o manuales. Debe identificar las dificultades actuales que provocan la realización del sistema. Se requiere describir el lugar y el entorno donde será realizado el sistema. Debe definir las restricciones impuestas por el usuario y las técnicas impuestas por el hardware, software o tecnología productiva y de servicio así como las restricciones financieras que limitan los gastos del proyecto y los límites de tiempo para el desarrollo del proyecto. Se debe definir las fronteras del sistema. Es necesario profundizar sobre la información que se maneja en cuanto a características, volúmenes y calidad de ésta. Se detalla el funcionamiento del objeto de estudio. Para ello se debe describir los procesos que serán automatizados. 1.3.2.3 Definición de las facilidades del software El analista, de forma conjunta con el usuario, definirá las facilidades del sistema (producto a obtener): la información que se va a generar, lo que se va a suministrar y el rendimiento requerido. Debe distinguirse lo que "necesita" el usuario (los elementos críticos) y lo que el usuario "quiere" (los elementos deseables pero no esenciales).
Se debe profundizar, partiendo del problema a resolver, para definir las facilidades del sistema. De manera general una facilidad es una capacidad que el sistema debe cumplir. Por ejemplo para el sistema de transplante renal se pueden definir los siguientes requisitos funcionales: 1. Mantener información sobre los pacientes Para obtenerlas se pregunta. ¿ Qué debe hacer el sistema ?. Se trata de la determinación clara y concisa de qué debe ser capaz de hacer el sistema y como lo debe hacer. Cada facilidad debe enunciarse mediante oraciones simples. Ejemplo de facilidades para un sistema de Ventas puede ser: • Poder mantener la información de los clientes y de sus cuentas asociadas • Garantizar la seguridad por perfiles de usuario Observe que las facilidades pueden ser funcionales y no funcionales y que poseen un carácter general. El analista debe evaluar las facilidades del sistema de acuerdo a los siguientes elementos: • Disponibilidad de la tecnología necesaria. • Recursos de fabricación y de desarrollo especiales que se requieren. • Dificultades actuales en el objeto de estudio. • Límites de costo y de tiempo de desarrollo. • Si se trata de un software para la venta: -. Mercado potencial para el producto -. Comparación del producto con otros similares. -. Lugar del producto dentro de la línea de productos de la empresa. . 1.2.3.4 Definir los requisitos no funcionales Se debe definir los requisitos no funcionales del software a desarrollar. Implica la determinación de los atributos no funcionales asociadas a las facilidades y de características generales del software como controles necesarios para garantizar la confiabilidad del sistema , seguridad propuesta, requisitos de la calidad, interfaces con otros sistemas de procesamiento manual o automatizado, ambiente de software y hardware. Los requisitos no funcionales más importantes se describen a continuación: Apariencia o interfaz externa Se debe obtener respuesta a la pregunta: ¿Cómo debe ser la interfaz? Las características deseadas mas comunes se presentan a continuación: Muy legible Simple Interactiva Autoritaria para que los usuarios se sientan confiados Colorida y atractiva para niños De tipo Profesional o ejecutivo Usabilidad
Describe los niveles apropiados de usabilidad teniendo en cuenta los siguientes elementos. ¿Qué tipo de personas son? ¿Qué tipo de producto necesitan para realizar su trabajo? ¿Qué tipo de requisito de usabilidad haría el producto apropiado para ellos? Debe definirse además: Por ciento de aceptación requerido de la aplicación Productividad a ganar en la introducción Proporción de errores admisibles Facilidad de uso por personas sin experiencia o por extranjeros Consistencia en la interfaz requerida con otras aplicaciones Documentación de usuarios requerida Rendimiento Se deben describir las características siguientes: • Velocidad de procesamiento • Eficiencia • Disponibilidad • Precisión • Tiempo de respuesta • Tiempo de recuperación • Aprovechamiento de los recursos Requisito de Soporte Se debe considerar todos los aspectos que influyan en el soporte de software a realizar como servicio de posventa. Entre esos factores se encuentran: Necesidades de la instalación del software Posibilidad de extensibilidad del software Necesidad de adaptabilidad Necesidad de mantenimiento Necesidad de compatibilidad Tipos de pruebas requeridas Otros servicios de soporte Necesidad de internacionalización del software Requisito de Portabilidad Debe usarse para especificar que el producto de software podrá ser usado en diferentes plataformas Requisitos de Seguridad Debe especificarse los siguientes factores: Confidencialidad: Información protegida de acceso y divulgación Integridad: Protección contra corrupción o estados inconsistentes Disponibilidad: Los usuarios autorizados tienen acceso garantizado a la información Requisitos Políticos culturales
Debe tenerse en cuenta factores especiales que pudieran hacer al producto no utilizable debido a costumbres humanas, preferencias o prejuicios Requisitos Legales Requisitos que estipulan la forma en que el software cumple las leyes vigentes o estándares. Requisitos de confiabilidad Debe tenerse en cuenta los límites para los siguientes factores: Respuesta del sistema ante fallas Frecuencia y severidad admisible de las fallas Protección contra fallos Recuperación ante errores Predicción de fallos Tiempo medio entre fallas Requisito de interfaz interna Debe tenerse en cuenta cómo interactuar con el sistema a través de software. Se considera interfaces a componentes comprados o reusados de otras aplicaciones o estándares como CORBA, DCOM, COM, ETC. Requisito de ayuda y documentación en línea Debe tenerse en cuenta los siguientes elementos: Fichero README:TXT Se requiere instrucciones de instalación Existen derechos de autor Se tiene logos corporativos Se tiene iconos y otros elementos de la interfaz Requisito de Software Debe considerarse de cuales software se debe disponer. Requisito de Hardware Debe considerarse de cuales elementos de hardware se debe disponer. Restricciones en el diseño y la implementación Debe considerar las vinculadas a los siguientes elementos: • Estándares requeridos • Lenguajes de programación a usar • Herramientas de desarrollo a usar • Restricciones en la arquitectura • Bibliotecas de clases
1.3.3 Confección de un prototipo de interfaz El objetivo es construir una versión inicial del prototipo donde se muestre un esqueleto del sistema con las responsabilidades como quedarían aunque no se llegue a los últimos detalles de implementación. En este punto debe diseñarse las pantallas de interacción con los usuarios. No se requiere que se incluya como parte de la documentación las pantallas correspondientes. Se recomienda que se implemente en el medio de programación a utilizar o en uno similar dichas pantallas. Este prototipo debe mostrar los datos de forma estática (No se permite realizar las transformaciones de los datos de entrada en los de salida) El objetivo de la prueba del prototipo inicial es revisar, observar, criticar y dar experiencia por parte de otros sobre si están reflejados los requisitos. Las primeras interacciones pueden concentrarse en: - le resulta familiar lo que ve? - se pasó algo por alto? - es cómodo y familiar al usuario el trabajo con el modelo? Esta fase se puede dar por terminada cuando cada cosa que el usuario quería que hiciera el sistema ha sido revisada por él. Se describe la interfaz mediante un grafo conversacional, ver anexo 1 1.3.4 Definición de los casos de uso Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. Los casos de uso describen los procesos y no son instrumentos que se correspondan con el enfoque orientado a objetos por lo que pueden ser utilizados para la obtención de los requisitos del sistema y para comunicar la funcionalidad y el comportamiento al cliente, al usuario y al equipo de proyecto. Un Caso de Uso es una secuencia de acciones que obtienen resultados de valor para un actor y un Actor representa cualquier cosa que interactúa con el sistema que puede ser un humano o un software o hardware. Este paso se realiza según el siguiente orden: • Identificar los actores • Identificar los casos de uso • Describir los casos de uso 1.3.4.1 Identificar los actores Los actores se caracterizan por: • No son parte del sistema, son roles de un usuario • Pueden intercambiar información con el sistema • Pueden ser un recipiente pasivo de información • Pueden representar a un humano a una máquina o un software Para identificar los actores en el contexto de la aplicación deben realizarse las siguientes preguntas: • Quien está interesado en cierto requisito? • Dónde en la organización es usado el sistema?
• • • • • •
Quienes usan, eliminan o suministran información? Quien usa una función? Quien soporta y mantiene el sistema? Usa el sistema un recurso externo? Cuáles actores necesitan el caso de uso? Un actor juega diferentes roles o varios actores juegan el mismo rol?
1.3.4.2 Identificar los casos de uso Se tiene dos métodos para identificar los casos: • Método basado en los Actores • Método basado en Eventos En el método basado en los actores se tiene en cuenta lo siguiente: • Se relacionan los actores relacionados con un sistema o empresa • Para cada actor, se identifican los procesos que inician o en que participan En el método basado en los eventos se tiene en cuenta lo siguiente: • Se identifican los eventos externos a los que un sistema debe responder • Se relacionan los eventos con los actores y con los casos de uso 1.3.4.3 Describir los casos de uso Para cada caso de uso se realiza la descripción utilizando el siguiente formato: Caso de Uso
Actores
Descripción
Facilidades:
Ejemplo: Para una aplicación de control de transplantes renales, se tendría: Caso de Uso: Transplantar un riñón Actores: Cirujano, paciente, forense Descripción Un riñón es analizado por el forense, el cual lo envía a cirugía donde el equipo de cirujanos solicita a medicina interna que les envíe los datos de los posibles receptores. Admisión se encarga de localizar a los receptores. Los cirujanos valoran los receptores posibles y operan el paciente seleccionado. Toda la información producto del transplante es guardada en el expediente del paciente y en el registro de transplantes Facilidades: 1, 2, 3 1.3.5 Selección de los casos de uso para cada ciclo Se realiza en los siguientes pasos: • Identificación del núcleo central de la aplicación • Identificación de los casos de uso del núcleo central de la aplicación y los de cada ciclo
1.3.5.1 Identificación del núcleo central de la aplicación Se deben seleccionar los casos de uso que influyan profundamente en la arquitectura básica, dando soporte al dominio y a las capas de servicio de alto nivel o los que presenten el máximo riesgo, funciones urgentes o complejas Se deben seleccionar los casos de uso que: • requieran investigación a fondo o nueva tecnología • representen procesos primarios de la línea de negocio • apoyen directamente el aumento de ingresos o la reducción de costos Además se debe incluir un caso de uso de inicio o arranque de la aplicación. Debe tener en cuenta que un caso de uso puede abordarse en varios ciclos. Identificación de los casos de uso del núcleo central de la aplicación y los de cada ciclo Se debe registrar los casos de uso que se correspondan con el núcleo central de la aplicación y luego definir los subconjuntos de casos de uso que deben ir adicionándose en cada ciclo de desarrollo. Para estos últimos se debe priorizar la funcionalidad a incluir de acuerdo a los intereses del usuario y del cliente.
1.3.5.2
1.3.6 Analisis de factibilidad El estudio de factibilidad conlleva la realización de los siguientes pasos: • Análisis de la factibilidad económica. • Análisis de la factibilidad técnica. 1.3.6.1 Análisis de la factibilidad económica La justificación económica de un producto de software incluye un amplio rango de aspectos entre los que se encuentran el análisis de costo-beneficio, las estrategias de ingreso a largo plazo, el impacto en los centros de explotación, el costo de los recursos que se necesitan para el desarrollo y el crecimiento potencial del mercado. El análisis de costo-beneficio consiste en contrastar los costos de desarrollo del proyecto con los beneficios tangibles e intangibles del sistema. Para el cálculo del costo de desarrollo de un proyecto orientado a objetos, se recomienda realizar este cálculo mediante las técnicas de COCOMO II [Boehm, 1981] y [Boehm, 2000]. La obtención de los beneficios del sistema se realiza de acuerdo a las características de éste. Para los sistemas de proceso de datos los beneficios principales son: una mejor cantidad, rapidez y organización de la información. Los beneficios que se puedan asociar a programas de análisis científicos y de ingeniería difieren substancialmente y requieren un análisis casuístico. Los beneficios de un sistema nuevo siempre se determinan comparando el modo de trabajo manual ya existente con el automatizado propuesto. Debe estimarse el costo de desarrollo, la economía anual, la eficiencia económica y el tiempo de recuperación.
1.3.6.2 Análisis técnico El análisis técnico es difícil de evaluar debido a que los objetivos, las funciones y el rendimiento son de alguna manera confusos, cualquier cosa puede parecer posible si se hacen las consideraciones adecuadas. Debe tener en cuenta los siguientes elementos: Riesgo de desarrollo: Delimite si se alcanzan los objetivos y el rendimiento requerido dentro de las restricciones determinadas al identificar las necesidades del usuario. Disponibilidad de recursos: Delimite si se posee el personal calificado. Tecnología: Delimite si se dispone de la tecnología para soportar el sistema. Análisis de alternativas de sistemas Cada responsabilidad del sistema con su rendimiento requerido y sus características de interfaz es asignada a uno o más elementos del sistema (software, hardware o personas). Hay diferentes formas de realizar esta asignación por lo que da lugar a distintas alternativas de solución. Para cada alternativa o variante de solución se hace una evaluación teniendo en cuenta los resultados de los análisis de la factibilidad económica y el análisis técnico. Para la mejor variante revise las responsabilidades antes obtenidas y obtenga un nuevo listado donde coloque las responsabilidades del software. 1.3.7 Planificación. Obtención del cronograma general de la aplicación Se debe confeccionar un plan por etapas, indicando fecha de inicio y de terminación. Utilice COCOMO II [Bohem, 2000] para este fin. 1.3.8 Balance de los artefactos En esta fase se debe garantizar que todos los artefactos desarrollados estén libres de inconsistencias. Los artefactos con que se cuenta son los casos de uso definidos de forma general, la definición de cuales se corresponden con el ciclo a desarrollar, el prototipo, los requisitos funcionales y los atributos correspondientes. Debe realizar las siguientes comprobaciones: • La definición general de cada caso de uso debe corresponderse con las facilidades asociadas. Debe tener en cuenta la definición de cada facilidad según la última revisión realizada a estas. En caso de inconsistencias debe mejorar la definición general del caso de uso. • Los casos de uso definidos para cada ciclo debe corresponderse con la justificación de los casos de uso en cuanto al orden de riesgo 1.3.9 Revisión y completamiento de la documentación Los resultados obtenidos en esta fase son sometidos a gestión de configuración y por tanto serán cambiados de acuerdo al procedimiento de gestión de configuración establecido.
1.3.9.1 Obtención del modelo del negocio • Casos de uso del modelo del negocio: Descritos en forma detallada • Diagramas de actividad • Diagramas de casos de uso 1.3.9.2 Definición del alcance de la aplicación • Identificación de los involucrados: Para cada uno nombre, ubicación y tareas que realiza • Formular el problema a resolver: Descripción de los problemas fundamentales detectados en el analisis, Sistemas automatizados o manuales existentes, ubicación, descripción de las características del lugar donde se hace el sistema y del entorno donde esta ubicado el sistema. • Listar las facilidades del sistema 1.3.9.3 Requisitos no funcionales Se trata de un texto con los requisitos no funcionales numerados. 1.3.9.4 Casos de uso Para cada caso de uso debe aparecer Caso de Uso (1) Actores (2) Descripción: (3) Referencias
(4)
Leyenda (1) Indica el Nombre del caso de uso (2) Lista de los actores que participan (3) Descripción en un párrafo del proceso (4) Número de las facilidades asociadas al caso de uso 1.3.9.5 Análisis de factibilidad Debe justificarse indicando costo, personal involucrado, esfuerzo requerido y los beneficios tangibles e intangibles 1.3.9.6 Cronograma general de la aplicación Una tabla indicando fases y fechas acorde con el esfuerzo requerido
2 Fases Las fases de la metodología tal y como fueron identificadas anteriormente son Inicio, Elaboración, Construcción y Transición. Cada una de las ultimas tres fases se realiza de forma iterativa e incremental por lo que a continuación se detallan los flujos o disciplinas que se efectúan en cada iteración o ciclo. En cada iteración o ciclo se puede realizar los siguientes flujos o disciplinas: • Requisitos • Análisis • Diseño • Implementación • Prueba 2.1 Flujo o disciplina de requisitos Se incluyen nuevas facilidades y/o casos de uso de acuerdo a los criterios recibidos de la prueba del ciclo o iteración anterior. Se deben someter a gestión de cambios puesto que las facilidades y casos de uso definidos en inicio fueron sometidos a gestión de configuración.. 2.2 Flujo o disciplina de análisis En el flujo de análisis orientado a objetos se examinan los requisitos desde la perspectiva de las clases y los objetos encontrados en el dominio del problema. Los pasos que se proponen son: 1. Obtención de los casos de uso detallados 2. Definición de las clases y de las asociaciones 3. Definición del diagrama de clases del análisis 4. Definición de los diagramas de secuencia 5. Balance de los artefactos 2.2.1 Obtención de los casos de uso detallados La obtención de los casos de uso detallados implica profundizar en el conocimiento del problema a resolver. Para estructurar mejor los casos de uso se recomienda dividirlos en partes que se llamaran subsistemas preliminares de manera que sea mas fácil su entendimiento para ello se utilizan los paquetes. Definición de paquetes La clasificación de casos de uso por subsistemas preliminares da una agrupación de casos de uso en paquetes. La definición de los subsistemas preliminares se realiza en base a un análisis de la funcionalidad manejada en cada caso de uso. Se agrupan en un mismo subsistema a aquellos casos de uso que se correspondan con funcionalidades que manejen la misma información o información similar. Un paquete en un mecanismo de propósito general para organizar elementos en grupos. En los paquetes se agruparan en esta fase los casos de uso, pero en el diseño se agruparan diagramas de clases y en la construcción componentes de software etc. Un paquete se identifica por el símbolo mostrado en la figura 2.
Figura 2 Símbolo del paquete Confección de los diagramas de casos de uso Un diagrama de casos de uso representa un conjunto de casos de uso para un sistema, los actores y la relación entre casos de uso y Actores es similar a un Diagrama de Contexto del enfoque estructurado. Los diagramas de casos de uso se deben realizar por paquetes de casos de uso, es decir cada paquete implica uno o varios diagramas de caso de uso. La simbología que se utiliza se muestra en la figura 3 y en la figura 4 un ejemplo.
Actor
Caso de uso
Figura 3 Símbolos del diagrama de casos de uso
Figura 4 Ejemplo de diagrama de casos de uso Casos de uso detallados Para cada caso de uso del ciclo se debe detallar lo más posible para ello debe utilizar el formato siguiente: Caso de Uso.
Actores Resumen Flujo principal Acción del actor 1 2 4 5
Respuesta del sistema 3 5 6 7
Flujo alternativo Acción del actor 1 2 4
Respuesta del sistema 3
Por supuesto el llegar a ese nivel de detalle implica profundizar con los usuarios y clientes a través de técnicas de recopilación de información, debe además utilizar el prototipo luego de realizar el refinamiento de éste de forma sucesiva a medida que va realizando el detalle de los casos de uso. A continuación se muestra un ejemplo de caso de uso detallado para el ejemplo de transplantes renales: Caso de Uso Transplantar un riñón Actores Forense, médico interno, cirujano, paciente Resumen Un riñón es analizado por el forense, el cual lo envía a cirugía donde el equipo de cirujanos solicita a medicina interna que les envíe los datos de los posibles receptores. Admisión se encarga de localizar a los receptores. Los cirujanos valoran los receptores posibles y operan el paciente seleccionado. Toda la información producto del transplante es guardada en el expediente del paciente y en el registro de transplantes Flujo principal Acción del actor 1 Comienza cuando un riñón producto de un accidente llega a medicina legal y el forense determina que puede ser empleado en un transplante 3 El médico interno solicita al sistema los 10 pacientes receptores posibles para el riñón dado 5 En Admisión se recogen pacientes posibles receptores
los
6 Se realiza un análisis del estado de cada posible receptor y se registra el paciente a operar por el médico interno y se solicita transplantar 8 Al terminar el transplante el cirujano introduce los resultados del transplante realizado y registra al paciente como transplantado
Respuesta del sistema 2 El sistema registra el riñón donado y avisa al equipo de cirugía y al médico interno que se tiene un riñón disponible 4 Determina los pacientes posibles receptores y muestra sus identificaciones, prioridades, ubicaciones en centro laboral y vivienda. Genera un aviso a Admisión para que recojan a los receptores
7 Al iniciarse el transplante se muestra a los cirujanos el historial clínico del paciente a operar 9 Al terminar registran los transplante
el
transplante se resultados del
2.2.2 Definición de las clases preliminares y de las asociaciones Esta fase se divide en tres pasos: • Definición de las clases preliminares • Definición de las asociaciones • Definición de los atributos de las clases Los elementos incluidos en este epígrafe han sido tomados del proceso de RUP [Kruchten, 1999] y de las recomendaciones incluidas en ADOOSI V5 [Alvarez, 2000] Definición de las clases preliminares Hacer una lista de clases de acuerdo a las categorías entidad, frontera y control. Clases Frontera: Sirven para modelar la interacción entre el sistema y sus actores, esto es, usuarios, sistemas externos y dispositivos. Clase Entidad: Utilizada para modelar información de larga duración y usualmente persistentes. Clases de Control: Representa el comportamiento específico de uno o varios casos de uso (si están fuertemente relacionados). Los objetos de estas clases controlan a otras clases o las coordinan Esta clasificación además de ayudar a definir las clases permite obtener un modelo robusto ya que los cambios solo afectan un área limitada. Los cambios del contexto externo a la aplicación solo afectan a las clases Frontera. Los cambios en el flujo de control a las de control y los cambios a la información de largo plazo a las clases entidad. Clases Frontera Esta clase recibe y presenta información y peticiones de y hacia los usuarios, dispositivos (sensor) y sistemas externos. Representan a menudo ventanas, formularios, paneles, protocolos de comunicaciones, interfaces de impresoras, sensores, terminales,… Como clase de análisis es muy conceptual, solo basta con describir la información y peticiones intercambiadas, sin interesar la forma física como se haga. No se debe modelar partes de la interfaz como botones como clases separadas, solo la ventana. La representación gráfica se representa en la figura 5.
Cl ie nteL inea
Pedido
(f ro m Ac to rs )
Figura 5 Representación grafica de las clases frontera. Ejemplo clase Frontera Pedido Para detectar las clases fronteras se debe revisar: • Clases Frontera con usuarios: Una clase para cada par Caso de uso con actor humano. Puede haber varias clases a la que la primaria le delegue responsabilidades, por ejemplo en Windows una clase por cada Windows o
•
•
formulario. Utilizar clases solo para fenómenos del sistema o cosas mencionadas en el flujo de eventos de los casos de uso Clases de interfaz con sistemas: Una clase para cada actor que represente a un Sistema. La responsabilidad de estas clases se deriva de la definición de la interfaz que ya existe. Un servicio Web debe considerarse como una aplicación externa. Clases de interfaz con dispositivos: Una clase para cada Actor que represente a un dispositivo. La responsabilidad de estas clases se deriva de las responsabilidades del dispositivo. Pueden ser equipos con los que se interactúa, bien intercambiando información o controlándolos. Por ejemplo: un radar en el sistema de control aéreo.
Clases Entidad Usada para modelar información de larga duración y usualmente persistentes. Modela fenómenos o conceptos, es decir, objetos del mundo real o eventos. Los valores de sus atributos y relaciones son actualizados por un actor con frecuencia. La representación grafica se muestra en la figura 6.
Cliente
Retiro
Cuenta
(f rom Actors)
Figura 6 Representación gráfica de la clase entidad Cuenta. Para detectar las clases de entidad se debe revisar: • Una clase para cada término definido en el Glosario o definido en el modelo del negocio (si fue realizado). Si la clase no es usada por ninguna otra clase debe modelarse como atributo o relación y no como una clase • Una clase para cada evento a recordar Un evento es un hecho del mundo real a recordar por el sistema. En este caso debe tenerse información sobre: quién, qué, cuando, donde, como, por qué. Por ejemplo: cambio de una solicitud de reservación o la rotura de un avión en el sistema de control de reservaciones serían posibles clases. • Una clase para cada proceso a recordar. Un proceso debe ser recordado por el sistema también así como las reglas del negocio utilizados en éste. Ejemplo: El Proceso Reservación de Asiento debe ser recordado así como las reglas utilizadas para ello como la .Política de Cancelación. • Una clase para cada rol o papel de persona. Puede generar clases -. representando a usuarios que interactúan con el sistema o clases representando a personas que aunque no interactúan con el sistema se mantiene información sobre ellas. Ejemplo del primer caso tenemos a los jefes de turno y de brigada que interactúan sobre el sistema y en el segundo al chofer que, aunque no interactúa con el sistema de control de transporte, se tiene información sobre este.
•
Una clase por cada lugar físico a recordar. Se refiere a los lugares físicos sobre los que el sistema necesita conocimiento. Por ejemplo, en el Sistema de Control de Transporte se requiere información sobre los centros turísticos incluidos en las programaciones de los viajes (distancia en km, provincia, etc.). El centro turístico es una clase posible. • Una clase por cada unidad organizativa a recordar. Se refiere a las unidades organizativas con las que el sistema interactúa y sobre las cuales se requiere tener información. Por ejemplo en el sistema de control del transporte se requiere información sobre las subbases de transporte existentes en el país, siendo ésta una posible clase • Una clase por cada transacción a recordar. Para las transacciones del negocio se puede definir clases así como para los detalles de transacciones que usualmente se tienen. Por ejemplo: Venta es una clase preliminar por tratarse de una transacción y DetalleProdVenta es el detalle de la transacción Venta, tanto Venta como DetalleProdVenta son ambas clases preliminares. Clases de Control Representa el comportamiento específico de uno o varios casos de uso (si están fuertemente relacionados). Los objetos de estas clases controlan a otras o las coordinan. Estas clases coordinan la actividad de otros objetos que implementan la funcionalidad que delegan. No todos los casos de uso requieren clase controladora. Si el flujo de evento en un caso de uso esta relacionado solamente con un objeto entidad, una clase Frontera puede hacer el caso de uso en cooperación con la clase entidad. Estas clases desacoplan los objetos de la clase interfaz de los objetos entidad haciendo el sistema tolerante a cambios del contexto. Por estas razones desacopla el comportamiento del Caso de uso de los objetos entidad haciéndolos mas reutilizables. La representación grafica se muestra en la figura 7.
Pedido
Confirmacion de pedido
Cliente en Linea Gestor de Pedidos
(f rom Actors)
Solicitud de productos Factura
Figura 7 Representación gráfica de la clase de control Gestor de Pedidos. Para detectar las clases de control se debe tener en cuenta: • Una clase para el flujo principal del caso de uso, otra para cada flujo alternativo y de excepción. Ayuda a que el sistema sea fácil de mantener y extender • No se necesita Clase de Control si el flujo puede ser manejado por la clase interfaz y entidad
•
Un flujo de evento que entre información primaria, la recupera, la muestra o modifica no justifica una clase de control • Dividir la clase controladora si dos actores compartan la misma clase de control. La clase de control interactúa a través de la clase Frontera con los actores En la definición de clases es útil seguir las recomendaciones de Wirfs-Brock [Wirfs, 1990], que se presentan a continuación: • Si se utiliza más de una palabra para el mismo concepto, se selecciona una que sea la más importante en términos del resto del sistema. Esto es parte de la construcción de un vocabulario común para el grupo de trabajo. • Ser cuidadoso con el uso de los adjetivos: pueden ser usados de muchas formas y puede sugerir diferentes tipos de clases, un uso diferente de una misma clase o pudiera ser irrelevante. Si el uso del adjetivo señala que el comportamiento de la clase es diferente, entonces se hace una nueva clase. • Modelar los valores de los atributos de las clases, no los atributos. Por ejemplo, en la clase viaje existe un atributo que es tipo de viaje, cuyos valores son excursión, recorrido y transfer, no se debe modelar clases para tipo de viaje, que es el atributo, pero sí para sus valores: excursión, recorrido y transfer. Definición de las asociaciones Una asociación representa una relación estructural entre objetos de diferentes clases. Las asociaciones son inherentemente bidireccionales. El nombre de una asociación se establece a partir de una oración que comienza con uno de los objetos de la asociación se concatena con una frase verbal y luego por el otro objeto componente de la asociación, tal y como se refleja a continuación: Frase Verbal Deben registrarse las asociaciones en que el conocimiento de la relación se debe preservar durante algún tiempo. No debe incluirse asociaciones redundantes ni derivables de otras. Para encontrar las asociaciones se utilizarán las reglas dadas por Larman ,Larman, 1999] • A es una parte física de B Por ejemplo: Ala es parte física de avión • A es una parte lógica de B . Por ejemplo: LíneaVenta es parte lógica de Venta • A está físicamente contenido en B Por ejemplo: Pasajero en Avión • A está lógicamente contenido en B Por ejemplo: Vuelo está logicamente contenido en Descripción de Vuelo • A es una descripción de B Por ejemplo: Descripción de Vuelo es una descripción de Vuelo • A es una línea en una transacción o reporte Por ejemplo: LineaProducto es una línea en la transacción Venta • A se conoce/introduce/registra/ presenta/ captura en B .Por ejemplo: Reservación introduce en ListaPasajeros
• A es miembro de B Por ejemplo: Piloto es miembro del Avión • A es subunidad organizativa de B Por ejemplo: Mantenimiento es una unidad organizativa de Linea Aerea • A usa o dirige B Por ejemplo: Piloto usa el Avión • A se comunica con B Por ejemplo: Cliente se comunica con el Vendedor • A se relaciona con una transacción B Por ejemplo: Pasajero se relaciona con el Boleto • A es una transacción que se relaciona con otra transacción B Por ejemplo: Boleto y Venta son ambos transacciones • A está contiguo a B Por ejemplo: Asiento y Asiento • A es propiedad de B Por ejemplo: Avión es propiedad de Línea Aérea • A es análoga a B Por ejemplo: Avión es análogo a Aeroplano • A es un tipo de B Por ejemplo: Avión es un tipo de Vehículo Definición de los atributos de las clases Los atributos deben corresponderse con los necesarios para representar los objetos del mundo real y no con componentes de software. Por ejemplo la clase Riñón no debe incluir un atributo Formato de impresión, ya que este se corresponde con una característica del software y no con el concepto Riñón del mundo real. Reglas para la definición de los atributos [Larman, 1999]: 1. Debe utilizarse como atributo todas las propiedades que tengan valores simples asociadas. Ejemplo para la clase Paciente son atributos que se corresponden con propiedades simples Nombre, edad, sexo, etc. 2. No debe utilizarse atributos complejos. Si se necesita en la definición de una clase un objeto como atributo, esto es una indicación de que se requiere definir una asociación. Ejemplo: Paciente requiere tener la información del Riñón Donado. No debe utilizar un atributo de tipo Riñón Donado sino una asociación entre Paciente y Riñón Donado. 3. No debe utilizar atributos que sean llaves foráneas. Si se necesita en la definición de una clase una llave foránea como atributo, esto es una indicación de que se requiere definir una asociación. Ejemplo: Paciente requiere tener el Código del Médico que lo atiende. Se debe utilizar una asociación entre Paciente y Médico para garantizar esta información. 4. No debe utilizarse atributos no primitivos. No obstante si el concepto correspondiente al atributo no primitivo no tiene suficiente importancia como para mantenerlo como una clase independiente, se mantiene como atributo de la clase. Un atributo no primitivo puede ser un código que tiene varias secciones diferentes o se asocian a él operaciones como la validación o posee atributos asociados a él o tiene una unidad de medida. Ejemplo: Si en la clase Paciente el
atributo Dirección se trata como una cadena de texto y no se asocia con otras clases de forma independiente y sólo se requiere como descripción de Paciente se debe tomar como un atributo. 2.2.3 Definición del diagrama de clases del análisis Esta vista del sistema muestra los conceptos básicos de éste: sus partes y relaciones. Para ello se utiliza el diagrama de clases de la notación UML de forma simplificada. El diagrama de clases es la representación mediante un grafo de las clases y las asociaciones que la conectan mediante un grafo. Se utilizan las clases y asociaciones definidas antes, esto puede hacerse a la vez, definiendo las clases y asociaciones y atributos sobre el propio diagrama. Lo anterior suministra una vista estática del sistema. En el diagrama de clases del analisis se representan: • Las clases preliminares • Las asociaciones entre éstas • La multiplicidad o cardinalidad para cada asociación • Los nombres para las clases y las asociaciones Representación de las clases preliminares Las clases preliminares se representan mediante rectángulos. Se especifica el nombre de cada clase. La notación se muestra en la figura 8. El tipo de clase: entidad, de control o frontera se indica como estereotipo de la clase y en un CASE (Computer Aided Software Engineering) puede ser representada mediante iconos como se representó anteriormente.
> >
Figura 8 Representación de la clase Se define como atributos las propiedades que caracterizan a los objetos de la clase y como servicios las acciones que los objetos de una clase para satisfacer las demandas o solicitudes de otros objetos. Representación de las asociaciones Las asociaciones se representan mediante líneas que unen a los símbolos de las clases involucradas. Las asociaciones son inherentemente bidireccionales, es decir, la mayoría de las veces interesa moverse en ambos sentidos. Por ejemplo entre las clases riñón donado y paciente se puede indicar una asociación bidireccional ya que dado un riñón donado interesa saber cuales son los pacientes que pueden receptarlo y dado un paciente interesa también saber cual es el riñón donado que le corresponde. En el diagrama de clases del análisis se representan
todas las asociaciones como bidireccionales. Esta característica será refinada posteriormente en el diagrama de clases del diseño. La asociación se refleja mediante una línea continua que une a los símbolos de las clases involucradas. En la figura 9 se muestra un ejemplo. A
B
Figura 9 Asociación entre las clases A y B. Representación de la cardinalidad o multiplicidad La cardinalidad o multiplicidad se coloca en ambos extremos de la línea que representa a la asociación. La multiplicidad define cuántos objetos de un tipo A pueden ser asociados con un objeto de un tipo B, donde A y B son clases. La multiplicidad se refleja en cada extremo de la asociación por uno de los siguientes rangos: Multiplicidad Muchos Exactamente uno Cero o muchos Uno o muchos Cero o uno
Rango * 1 0..* 1..* 0..1
En la figura 10 se muestra la representación de la multiplicidad en una asociación. A 0..1
0..*
B
Figura 10 Asociación con multiplicidad especificada. Un objeto de la clase B tiene asociado cero o un objeto de A y un objeto de la clase A tiene asociado cero o muchos objetos de B Representación de los nombres para las clases y las asociaciones Los nombres de las clases se colocan dentro del rectángulo correspondiente a la clase y el nombre de la asociación se escribe sobre la línea que representa la asociación. El nombre de la clase es un sustantivo y puede tener adjetivos que lo describan. En la figura 11 se muestra un ejemplo de diagrama de clases del análisis.
IClientes
ICatalogoCuentas DevCuentas_SubCategoria() Crear_Analisis_Subsistemas()
CClientes Captar_DatosCliente() Asociar_Cliente_Grupo() Generar_Grupo() Asociar_Cliente_Categoria() Captar_Datos_Categoria() Asociar_Cuentas_Cliente() Seleccionar_Cuentas_Cliente() Buscar_Cliente() ModificarCliente() Modificar_Categoria() Buscar_Asociacion_Grupo() Buscar_Cuentas_Grupo()
EGrupoCliente IdGrupo : Single Codigo : String Descripcion : String
EImpuestoCliente CodImpuesto : String Descripcion : String Valor : Double
0..1 1
1
0..*
EEmpresa Nombre : String Direccion : String Email : String Telefonos : String Fax : String Correo : String Pais : String Descripcion : String CodigoPostal : String Ciudad : String Estado : String SitioWeb : String
0..*
EIncobrabilidadCliente Antiguedad : Single FechaTope : Date
ECondPagoCobro CodTipoPago : String Dias : Single Descuento : Byte
ETipoPagoCobro CodTipoPago : String TipoPago : String
ECategoriaCliente
0..*
ERepresentante Nombre : String Apellidos : String Cargo : String
1
1
ACategoriaClienteProveedor Codigo : String Descripcion : String IdTipoGrupo : Single TipoGrupo : String
ECliente 1 Crear_Cliente() Validar_Datos_Cliente() Buscar_Cliente() ModificarCliente() factoryMethod()
AClienteProveedor Codigo : String Apellidos : String Comentarios : String Nombre : String Direccion1 : String Email : String Telefonos : String Fax : String Correo : String Pais : String Descripcion : String CodigoPostal : String Ciudad : String Id : Single Estado : String SitioWeb : String Direccion2 : String factoryMethod()
1..*
1 AGrupoClienteProveedor Codigo : String Nombre : String IdGrupo : Single Descripcion : String 1 0..*
EAnalisisCuentasGrupo
1..*
Crear_Analisis_Grupo() Buscar_Cuentas_Grupo() 1 0..*
EAnalisisCuentasCliente
AAnalisis
Crear_Analisis_Cliente() Buscar_Cuentas_ Cliente()
Figura 11 Diagrama de clases del análisis. No aparecen los nombres de las asociaciones y servicios. Aparecen asociaciones propias del diseño
2.2.4 Definición de los diagramas de secuencia y asignación de servicios o responsabilidades Los diagramas de interacción constituyen uno de los artefactos mas importantes y a su construcción se dedica gran parte del tiempo, la función fundamental de estos artefactos es que permiten asignar las responsabilidades o servicios a cada clase. El diagrama de secuencia permite describir cómo funcionará la aplicación es decir cuál es su comportamiento, se refiere a qué hará el sistema Los diagramas de secuencia muestran como los objetos se comunican unos con otros en secuencia de tiempo y para ello contienen objetos con sus ciclos de vida y los mensajes que se envían entre ellos ordenados secuencialmente. En el diagrama de secuencia se reflejan: • los actores (se obtienen de los casos de uso) • los eventos y las operaciones • los objetos de las clases El evento es un hecho del mundo real (externo), producido por un actor al que un sistema debe responder y la operación es la acción que este realiza en respuesta a un evento y que hace que el sistema en general cambie de estado y en particular que varios objetos cambien su estado. Por ejemplo el evento puede ser que el Cliente solicita Introducir sus datos y la operación del sistema en respuesta es Introducir Cliente. En UML se define dos diagramas de interacción: • Diagrama de Colaboración • Diagrama de Secuencia En la figura 12 se muestra el formato para el diagrama de secuencia y en la figura 13 el formato para el diagrama de colaboración.
:
: Clase 1
mensaje 1( )
: Clase 2
Objeto 3 : Clase 3
mensaje 2( )
mensaje 3( ) Enfatiza la secuencia
Ciclo de vida
Foco
Figura 12 Diagrama de secuencia. Formato general Los objetos se dibujan en rectángulos con los nombres subrayados y pueden aparecer con uno de los formatos siguientes: NombreObjeto o :NombreClase o NombreObjeto:NombreClase El ciclo de vida de cada objeto se representa con líneas discontinuas que descienden de los rectángulos representativos de cada objeto. Los mensajes aparecen mediante líneas que enlazan la línea de vida del objeto cliente con la línea de vida del objeto servidor. Los mensajes pueden numerarse indicando la secuencia en tiempo opcionalmente. El orden de los mensajes se indica por la posición vertical comenzando por la parte superior hacia abajo. En los diagramas se puede representar el foco de control, es decir el tiempo en que el flujo de control está centrado en un objeto, es el tiempo en que el objeto está enviando mensajes a otros objetos. A la izquierda del diagrama pueden agregarse descripciones con los pasos a realizar en la interacción correspondiente. El formato general de los mensajes se muestra a continuación: VarRetorno:=mensaje(parámetro: TipoParámetro, ):TipoRetorno
1: mensaje 1( ) : Clase 1
:
3: mensaje 3( ) 2: mensaje 2( )
: Clase 2
Objeto 3 : Clase 3
Figura 13 Diagrama de colaboración. Formato general El formato del diagrama de colaboración es idéntico en cuanto al tratamiento de los mensajes y de los nombres de los objetos. Se tiene enlaces de un objeto a otro con los mensajes correspondientes, se pueden indicar en los enlaces saetas indicando cliente y servidor del mensaje y no aparece la línea de vida de cada objeto. La secuencia sólo se conoce a través de la numeración de los mensajes. El diagrama de la figura 13 se obtuvo mediante la transformación del diagrama de secuencia de la figura 12. Reglas para elaborar los diagramas de interacción • Se identifican los actores que interactúan directamente con el sistema. Se puede observar que en los casos de uso aparecen actores que no interactúan directamente con el sistema como es el caso de Cliente en una terminal de punto de venta. • Se identificar los eventos que estos actores generan. • Se nombran los eventos de manera que estén desprovistos del medio físico de entrada o de elementos de la interfaz, para ello debe utilizarse verbos en infinitivo. Por ejemplo debe colocarse el evento TerminarVenta en lugar de OprimirTeclaEnter ya que capta el propósito de la operación y no se define en función de la interfaz. El propósito debe reflejarse en el mayor nivel de abstracción posible. • Se confecciona un diagrama de interacción por cada operación del sistema, es decir por cada solicitud de un actor que provoca una respuesta del sistema. En RUP se recomienda utilizar un diagrama para el flujo principal y uno por cada flujo alternativo pero al criterio del autor eso provoca diagramas poco claros. • Se utiliza indistintamente diagramas de secuencia o de colaboración pero se recomienda el diagrama de secuencia • Un diagrama se divide en varios diagramas si es muy grande • Se diseña los diagramas de interacción a partir de la descripción de los casos de uso. Los diagramas de interacción constituyen una herramienta fundamental para la asignación de las responsabilidades a cada clase. Existen patrones generales a seguir en la asignación de las responsabilidades a las clases, esos patrones se conocen como patrón experto, patrón creador, patrón bajo acoplamiento, patrón alta cohesión y patrón controlador [Larman, 1999]. Existen otros patrones que
serán aplicados en el diseño estos permiten definir una estrategia en la asignación de responsabilidades a las clases en el análisis. A continuación se describen estos patrones o reglas generales: 1. Patrón experto: Asignar una responsabilidad al experto en información es decir a la clase que cuenta con la información necesaria para cumplir con la responsabilidad. Lo anterior garantiza mayor encapsulamiento. Una clase debe tener acceso a todos los valores de datos que necesite para llevar a cabo sus responsabilidades y sólo a ellos. El acceso a los datos debe quedar tan restringido como sea posible. Si una clase no necesita en absoluto el acceso a cierta parte de la información para llevar a cabo sus tareas, no debe buscar ni tener tal acceso. 2. Patrón creador: Asignar a la clase B la responsabilidad de crear una instancia de A si: B agrega los objetos A B contiene los objetos A B registra las instancias de los objetos A B utiliza específicamente los objetos A B tiene los datos de inicialización que serán trasmitidos a A cuando sea creado 3. Patrón bajo acoplamiento: Asignar las responsabilidades de manera que se mantenga bajo el acoplamiento. Una clase que recurre a muchas No es buena porque los cambios de las otras ocasionan cambios locales y en general son más difíciles de entender y de reutilizar. Una clase que interactúa con muchas se dice que tiene un excesivo centralismo de control, esta situación es negativa por las razones antes apuntadas. Se recomienda, basado en los trabajos de Miller que: Una clase no debe tener mas de 7±2 clases con las cuales interactuar. En los niveles superiores de la jerarquía el límite es usualmente entre 4 y 8, pues en los niveles altos se supervisa el trabajo de otras clases y en los niveles bajos se delega la realización de tareas específicas, lo que es más simple. Se busca independencia entre los módulos 4. Patrón alta cohesión: Asignar las responsabilidades de manera que la cohesión siga siendo alta para cada clase. Una clase que hace muchas cosas no afines o muchas tareas no es buena porque: • Son difíciles de entender • Son difíciles de reutilizar • Son difíciles de conservar • Son delicadas las afectan constantemente los cambios Una clase con buena cohesión es buena porque: • Mejoran la claridad y la facilidad de uso • Se simplifica el mantenimiento • A menudo se genera un bajo acoplamiento • Son mas fáciles de reutilizar 5. Patrón controlador: Asignar una responsabilidad del manejo de un mensaje de un evento del sistema a una clase que represente:
• • • •
El sistema global (Controlador de Fachada) La empresa u organización (“) Un manejador artificial de todos los eventos Algo activo del mundo real y que pueda participar en una tarea (Controlador de tareas) Cada diagrama de interacción debe iniciarse con una clase de este tipo que recibe el evento correspondiente compatible.
Figura 14 Ejemplo de diagrama de interacción para el caso del catalogo de cuentas. : FClientes
Inscribir_Categori...
Asociar_Cliente_Categoria( )
: C FC lientes
: IClientes : CClientes
: ECategoriaCliente
Error_Datos_Categ...
Validar_Datos_Categori...
Crear_CategoriaClient...
Asociar_Cliente_Categoria(Clie...
Captar_Datos_Categori...
Inscribir_Categoria( )
Categoria_NoCr...
Asociar_Cliente_Categoria(Cliente)
Asociar_Cliente_Categoria(Clie...
Inscribir_Categori...
Validar_TipoDatos_Categori...
Asociar_ClienteACategori...
: FCategoriaCliente
El proceso de confección de los diagramas de interacción y de asignación de responsabilidades a las clases debe realizarse de forma concurrente con el refinamiento del diagrama de clases del análisis. Si una clase requiere información o acción de otra para completar su comportamiento debe existir una asociación entre ellas reflejada en el diagrama de clases del análisis. En el diagrama de la figura 14 se muestran los parámetros, esta es una información que no siempre es útil en estos diagramas pues los hace difícil de utilizar para la comunicación con los diseñadores. Si se requiere generar con un CASE los programas esta información será indispensable e inclusive los tipos de los parámetros. 2.2.3 Definición de las operaciones de las clases Las operaciones contribuyen a definir el comportamiento de un sistema; definen el efecto que sobre el sistema tienen los eventos del mundo real. Se utilizará para describir las operaciones a las precondiciones, poscondiciones, excepciones definidas en UML. El formato de los contratos es el siguiente: Nombre: Descripcion: Tipo: Nombre del tipo (Publico, Protegido y Privado) Excepciones: Situaciones excepcionales Precondiciones: Suposiciones acerca del estado del objeto de la clase antes de la operación Poscondiciones: El estado del objeto de la clase después de la operación A continuación se describen las reglas para construir las operaciones: • Se identifican las operaciones a partir del diagrama de secuencia • Se elabora una descripción para cada operación • Se completa las precondiciones, se describe en forma declarativa los cambios de las clases del diagrama de clases • Se completa las poscondiciones, se utiliza la ocurrencia de las siguientes situaciones: ♦ Creación y eliminación de objetos de las clases ♦ Modificación de los atributos de las clases ♦ Asociaciones formadas y canceladas Las poscondiciones constituyen, después de la descripción de la operación, el elemento más y no se corresponden con acciones que deben efectuarse en la operación se trata de declaraciones sobre el estado del objeto una vez que se realizó la operación. Deben ser redactadas con los verbos en pasado. Las poscondiciones se relacionan con el diagrama de clases y deben estar balanceadas adecuadamente, no puede haber una asociación o clase en las poscondiciones que no aparezca en el diagrama de clases. Como producto de esta fase el diagrama de clases puede ser refinado. Las precondiciones son suposiciones sobre el estado de los objetos al iniciarse la operación, cosas que son importantes probar en el software en algún momento de
la ejecución o que no serán sometidas a pruebas pero de las cuales depende el éxito de la operación. En la figura 14 se muestra la operación Registrar cliente Nombre: Registrar cliente Descripción: Registrar datos del cliente, tales como: nombre, dirección, teléfono, e mail, empresa y representante. Se asocia a un grupo cliente Excepciones: Tiene que tener todos los datos Precondiciones: Se aprobó su registro por Comercial Poscondiciones: Se creo cliente Se asocio con Categoría cliente Proveedor y se tomo la categoría de cliente en no moroso Se creó el objeto Representante y la asociación con este Se creo la asociación con Empresa Figura 15 Ejemplo de documentación de operación 2.2.4 Balanceo de los artefactos En esta fase se debe garantizar que todos los artefactos desarrollados estén libres de inconsistencias. Los artefactos con que se cuenta son los casos de uso detallados, la definición de cuales se corresponden con el ciclo a desarrollar, los diagramas de clases del analisis, la definición de clases y de los atributos de las clases, la definición de las operaciones de las clases Debe realizar las siguientes comprobaciones: • Los casos de uso detallados deben corresponderse, al menos, con los casos de uso del ciclo realizado. • Las clases definidas deben corresponderse con las que aparecen en los diagramas de clases del análisis. • Los diagramas de secuencia del sistema deben corresponderse con eventos iniciados por actores que interactúan con el sistema en los casos de uso y todos los actores que interactúan con el sistema deben aparecer en algún diagrama de secuencia • Las poscondiciones de las operaciones deben corresponderse con la creación o eliminación de objetos de clases o asociaciones contenidas en los diagramas de clases del análisis. Si existe alguna inconsistencia se deben realizar los arreglos necesarios 2.2.5 Revisión y completamiento de la documentación Se presenta la documentación a modo de guía puesto que las herramientas CASE garantizan a esta automáticamente. 2.2.5.1 Paquetes de los casos de uso Nombre del paquete Descripción del paquete
2.2.5.2 Casos de uso detallados Para cada caso de uso se define: Caso de Uso Actores Resumen: (3)
(1) (2)
Acción del actor
Respuesta del sistema
(4)
(5)
Leyenda (1) Indica el Nombre del caso de uso (2) Lista de los actores que participan (3) Resumen del caso de uso. Casi siempre coincide con la descripción del caso de uso no expandido (4) Pasos numerado y secuenciales de las acciones del actor (5) Pasos numerado y secuenciales de las acciones de respuesta del sistema al actor. Existe una numeración única para actor y sistema. 2.2.5.3 Diagramas de casos de uso Diagrama de caso de uso
Paquete (1)
(2)
Leyenda: (1) Deberá ser colocado un número de acuerdo al formato siguiente: DCU- ## donde DCU significa Diagrama de Casos de Uso; y ##, es un número consecutivo único de identificación para el paquete correspondiente al caso de uso.
(2) Deberá ser colocada la representación gráfica del diagrama de casos de uso. 2.2.5.4 Diagrama de clases del análisis Puede tratarse de uno o varios diagramas Diagrama de clases (1) del análisis (2) Leyenda (1) Nombre del paquete o del caso de uso al que se asocia (2) Diagrama correspondiente 2.2.5.5 Diccionario de datos Clase: (1) Significado: (2) Nombre del Descripción Tipo Atributo (3) (4) (5) Leyenda (1) incluido en el diagrama (2) Significado del concepto o mediante una oración simple o frase nominal (3) Nombre del atributo asociada a la clase (4) Significado del atributo (5) Tipo de datos (caracteres, entero, real, alfabético) 2.2.5.6 Diagramas de secuencia Son varios diagramas Diagrama de Secuencia del sistema
Paquete (1)
(2)
Leyenda: (1) Deberá ser colocado un número de acuerdo al formato siguiente: DSS- ## donde DSS significa Diagrama de Secuencia del Sistema; y ##, es un número consecutivo único de identificación para el paquete correspondiente. (2) Deberá ser colocada la representación gráfica del diagrama de Secuencia 2.2.5.7 Operaciones Para cada operación se describe:
Nombre: Responsabilidades o métodos: Tipo: Excepciones: Precondiciones: Postcondiciones
(1) (2) (3) (4) (5) (6)
(1) (2) (3) (4) (5) (6)
2.3
Flujo o disciplina de diseño
El diseño orientado a objetos es un método de diseño que se basa en el concepto de que el modelo del sistema es una colección de objetos que cooperan entre si para garantizar los requisitos del usuario y donde cada objeto es una instancia de una clase en una jerarquía de clases. Las fases que se proponen son: 1. Definición de la arquitectura 2. Obtención de los diagramas de clases del diseño 3. Refinamiento de los diagramas de interacción 4. Refinamiento de los atributos y responsabilidades de las clases 5. Aplicación de patrones de diseño 6. Definición de los diagramas de transición de estado 7. Confección de los diagramas de componentes 8. Definición de la base de datos relacional 9. Balanceo de los artefactos 10.Revisión y completamiento de la documentación Definicion de la arquitectura La definición de la Arquitectura es una actividad de diseño que se realiza de forma iterativa e incremental. Esto se hace en los ciclos o iteraciones de la Etapa de Elaboración. Primeramente se comienza con la definición del orden de realización de los casos de uso de la aplicación, esta es una decisión arquitectónica. Usualmente en uno o dos ciclos de la Elaboración se realizan los casos de uso que determinan la arquitectura de la aplicación y por tanto en el diseño de esos dos ciclos se realiza la definición de la arquitectura de la aplicación. Esta actividad es realizada por el Arquitecto de la Aplicación de forma independiente de los Analistas y otros diseñadores. Los pasos son: • Definición del patrón de arquitectura • Definición del modelo de mini arquitectura (framework) a emplear • Identificación de los subsistemas • Definición de servicios Web de terceros a emplear y servicios Web a ofertar • Definición del Diagrama de subsistemas funcionales • Definición de las clases y paquetes más significativos 2.1.1.1 Definición del patrón de arquitectura La definición del patrón de arquitectura requiere de un análisis de las diferentes variantes disponibles y de los requisitos no funcionales de la aplicación. Las variantes mas utilizadas son: 2.1.1
Cliente servidor: Se basa en un conjunto de nodos que realizan la función clientes y de otros que realizan la función de servidores. Los clientes son consumidores de servicios suministrados por un servidor. Un cliente frecuentemente sirve a un solo usuario y maneja una interfaz GUI (Graphics User Interface) mientras que un servidor normalmente brinda servicios a varios clientes siumultaneamente; los servicios son de Base de Datos, Seguridad e impresión. La lógica del negocio esta distribuido entre clientes y el servidor. Los clientes llaman a los servicios de los
servidores. Por lo general son subsistemas. Existe varias ocurrencias de un programa cliente. Se debe resolver los problemas de concurrencia. La representación gráfica se muestra en la figura 16
Cliente 1
Cliente 2
Cliente 3
Red de comunicacion
Servido r de catalogos
Servido r de videos
Servi dor de Fotografias
Hipertexto
Figura 16 Ejemplo de aplicación cliente servidor. Varios servidores y clientes. Aplicación Web: Asociada a las aplicaciones Web hay varios patrones de arquitectura que se presentan a continuación. Para profundizar sobre el tema se recomienda el texto de Jim Conallen [Conallen, 2003] • Cliente Web Delgado: Para aplicaciones basadas en internet. Poco control de la configuración del cliente. Toda la lógica en el servidor. Vista de diseño: Mover todo el proceso del negocio al servidor. Los componentes son: Browser Cliente, Web Server, HTTP, Página estática y dinámica. En la figura 17 se muestra los elementos que la componen y sus relaciones y en la figura 18 la distribución física de los nodos.
Crea da/modificada: Ru del Herna ndez Date: Junio 2003 Aprobado: Sofia Alvarez Date: Noviemb re 2003
Browser Cliente
Servidor de Aplicacion
Servi dor Web
HTTP
Sistema de ficheros
Capa Persistente (BD)
Paginas dinamicas
Paginas Estaticas
Figura 17. Elementos de Cliente delgado Cliente
Red de trabajo
Web Server
Server Appli...
BD Server
preemptive HTML Browser
•
Figura 18 Distribución fisica de los nodos para Cliente Delgadoi Cliente Web Grueso: Significativa cantidad de la lógica del negocio se realiza en el cliente. Usa Applet o controles ActiveX para la lógica. En la figura 19 se muestra los elementos que la componen y sus relaciones y en la figura 20 la distribución física de los nodos.
Script del cliente
Pagina Web Java Applet
Brow ser Cl ie nte
DOM HTTP Invoca operacion()
Servidor de Aplicacion
Servidor Web
Capa Persistente (BD)
Figura 19 Elementos y relaciones en Cliente Grueso Cliente
Red de trabajo
Web Server
Server Appli...
BD Server
preemptive HTML Browser
Figura 20 Distribución en nodos de Cliente Grueso • Web Distribuido (Web Delivery): Además de HTTP usa otros protocolos como IIOP y DCOM para los objetos distribuidos. Adicionalmente SOAP y web services. Apropiada para cuando se puede suponer cierta configuración en el cliente y versión del navegador. Mejora la interfaz usuario para ejecutar lógica del negocio en el cliente. En la figura 21 se muestra los elementos que la componen y sus relaciones y en la figura 22 la distribución física de los nodos.
HTTP
Browser Cliente
Servidor Web
Servido r BD
Servidor de Aplicacion Paginas Web
Servidor de objetos remotos RMI/DCOM
Figura 21. Elementos y relaciones en Web Distribuido
Red de tra b...
Web Server
Server Application
Cliente BD Server p ree mp tive HTML Browser most ran do objet os remot os
Servidor de Objetos rem otos RMI/DC OM
Figura 22. Distribución en nodos de Web Distribuido 2.1.1.2 Definición del modelo de mini arquitectura (framework) La realización de software en la actualidad se realiza sobre ambientes de programación que incluyen una mini arquitectura. Una mini arquitectura es un esqueleto de los elementos fundamentales de la estructura de una aplicación “Una mini arquitectura de software abarca un conjunto de clases que cooperan entre sí” [Johnson, 1988]. “El diseño de alto nivel del sistema, el cual define los componentes de la solución, sus interfaces y sus interacciones, es reutilizado dentro de la mini arquitectura, y a medida que las clases o métodos completos pasen a formar parte de los aspectos fijos de éste, el código y el diseño detallado podrán ser también reutilizados” [Jacobson, 1997]. Las mini arquitecturas facilitan altos grados de reutilización. En el mercado existen diferentes mini arquitecturas disponibles, entre ellas las que están en la punta de la tecnología son .NET y Java
2 Enterprise Edition (J2EE) [Booch, 2003]. Las razones de selección de una u otra son más políticas y comerciales que técnicas. Cada mini arquitectura da la posibilidad de implementar un conjunto de patrones de arquitectura. Estas mini arquitecturas se apoyan en distribuir las componentes de la aplicación en capas, siendo usual la existencia de modelos de tres o más capas en la actualidad. Las capas son agrupaciones lógicas de los componentes de software que constituyen una aplicación o negocio 1. Ayudan a diferenciar entre la clase de tareas desarrolladas por las componentes 2. Hacen fácil el diseño de la reusabilidad Cada capa contiene un número de componentes agrupados en subcapas y cada subcapa realiza un tipo de tarea. Una distribución por capas seria la propuesta en la figura 23, la que se corresponde con la de .NET
Usuarios
Servicio de llamadas
Presentación Negocio
Datos
BD
Servicios
Figura 23 Distribución por capas. Propuesta de .NET En la figura 24 se muestra el detalle de los contenidos de las capas
Interfaz Usuario Interfaz tradicional
Lógica del negocio Componentes del negocio
Interfaz Web Flujos de proceso del negocio
Controlador de interfaz
Acceso a los datos Logica de acceso a los datos
Agentes de servicios
Componentes de entidades del negocio
Figura 24 Capas de la aplicación en .NET El significado de las capas se indica a continuación. 1. Componente de la lógica. Orquesta las tareas del negocio a desarrollar 2. Componentes de las entidades del negocio. Contiene comportamiento que implementa la lógica del negocio del servicio 3. Flujos de proceso del negocio. Se refiere a componentes que permiten el uso de un motor de flujos de proceso 4. Componentes del acceso a los datos: Acceden a los servicios de los datos almacenados 5. Agentes de servicio. Permite la búsqueda de los servicios Web 6. Interfaz de servicio. Se usa para exponer su funcionalidad 2.1.1.3 Identificar subsistemas El concepto de subsistema es usado para distinguirlo de un paquete ordinario, los que son contenedores de elementos del modelo, el subsistema es un paquete especial que posee comportamiento de forma similar a las clases. Las colaboraciones con un subsistema son aisladas a través del uso de interfaces, de forma tal que el cliente del subsistema solo dependa de la interfaz. El diseñador del subsistema esta totalmente aislado de dependencias externas, el diseñador solo es requerido para definir como la interfaz será realizada. Los clientes del subsistema ignoran el diseño interno, solo usan sus servicios. Por estas razones crea una capa de encapsulamiento. La figura 28 muestra la representación gráfica de los subsistemas.
Clientes
Figura 28 Representación de los subsistemas
2.1.1.4 Definición de servicios Web El término servicio es usado para indicar cualquier componente de Software externo que brinde servicios. Incluye los Web Services XML pero no esta limitado a ellos. Los servicios tienen interfaz y contratos. Puede ser tratado como un subsistema especial. • Interfaz: A la cual los mensajes “inboind” son enviados. Fachada que muestra la lógica del negocio implementada en el servicio a los clientes potenciales • Contrato: Conjunto de mensajes que pueden ser intercambiados con un servicio para desarrollar una tarea especifica del negocio Desde la perspectiva del consumidor, los servicios son similares a los componentes tradicionales, excepto que: 1. Los servicios encapsulan sus propios datos (Si la componente se deriva de clases también se cumple) 2. No son estrictamente hablando parte de la aplicación Utilizan técnicas basadas en mensajería para dar robustez y escalabilidad. Una aplicación esta compuesta de múltiples servicios, comunicándose a través de mensajes. Conceptualmente un servicio equivale a una componente, es decir, un Servicio esta compuesto de múltiples componentes de software, similar a otra aplicación. Los servicios son diseñados para comunicarse unos con otros con el menor acoplamiento posible. Entre sus ventajas se tiene: 1. La comunicación a través de mensajes disminuye el acoplamiento, aumenta la disponibilidad y escalabilidad 2. La seguridad puede implementarse mas simple 3. El servicio Web no posee interfaz usuario sino solo interfaz bajo control de programa o programática. Lo anterior facilita la reutilización de estas componentes puesto que se pueden enlazar con otros componentes y vincularlos a disímiles interfaces usuario. Por tanto, estas componentes permiten una utilización muy flexible. 4. Esto ha habilitado también una forma de vender y reutilizar componentes en Internet. 5. Usar servicios Web XML permite integrar con otras plataformas y tecnologías Sin embargo, el uso de estas componentes aumenta la lentitud de la aplicación resultante por lo que debe ser analizado en el caso de aplicaciones simples su conveniencia de uso. En base a los criterios antes mencionados se define si se utilizará algún servicio Web de terceras partes o si se abordara el desarrollo de servicios Web como parte de las componentes de la aplicación. 2.1.1.5 Definición del Diagrama de subsistemas funcionales La definición de subsistemas funcionales se define en el análisis de forma general y se refina en el diseño de la arquitectura de acuerdo a los siguientes criterios: • En el analisis se definen subsistemas funcionales que se corresponden con la división de acuerdo a áreas de responsabilidad o lugares.
•
En el diseño de la arquitectura se particiona a los subsistemas en subsistemas o paquetes de acuerdo a criterios de la mini arquitectura seleccionada o de reutilización o de división de capas • Los paquetes inferiores son paquetes de clases, el enfoque no es funcional sino de objetos relacionados. En la figura 25 se muestra un ejemplo de diagrama de subsistemas
Facturación y cobro
WS Producto
Cuenta por Cobrar
WS Cliente
Figura 25 Ejemplo de particionamiento en Subsistemas. WS Cliente y WS Producto son Servicios Web desarrollados por terceras partes. La aplicación de Venta del ejemplo ha sido desarrollada como un servicio Web buscando la flexibilidad que esta tecnología brinda por lo que Facturación y cobro es un Servicio Web. En la figura 26 se muestra el diagrama correspondiente Facturación y Cobro y su vinculacion con la interfaz.
Facturación y cobro
Interfaz Web
Figura 26 Estructura de capas 2.1.1.6 Definición de las clases y paquetes más significativos Es necesario definir por paquetes y/o subsistemas las clases y componentes mas importantes y sus relaciones. En la figura 27 se muestra la estructura interna de Facturación y cobros
Clase Interfaz Web Sevice
Control del negocio
Clases del negocio
Typed Dataset
Acceso a los datos
Agentes de Servicios
Figura 27 Estructura interna de Facturación y cobros. Objetos del tipo Typed Dataset se utilizan para comunicar una capa con otra en .NET. La clase interfaz Web representa la interfaz del servicio Web 2.3.2 Obtención de los diagramas de clases del diseño Los diagramas de clase se obtienen como resultado del refinamiento de los diagramas de clases del análisis, teniendo en cuenta la arquitectura y los requisitos no funcionales, se confeccionan por subsistemas o paquetes. El resultado seria: • Clases definidas en el análisis completas • Clases propias de la implementación agregadas El objetivo es lograr que el modelo del diseño se corresponda con el codigo a desarrollar, tal y como se muestra en la figura 28. Directo Modelo del diseño
Código
Figura 28 Correspondencia del modelo del diseño con el código El proceso se realiza en los siguientes pasos:
• •
Refinamiento de las clases Refinamiento de las asociaciones e inclusión de dependencias 2.3.2.1 Refinamiento de las clases El refinamiento de las clases incluye la inclusión de clases e interfaces dependientes de aspectos físicos. Entre estas están: • Identificar las interfaces de los subsistemas. Un ejemplo se muestra en la figura 29 o Definen un conjunto de operaciones las cuales son realizadas por algún cliente o Son importantes porque ellas permiten la separación de la declaración del comportamiento (Interfaces) de la realización del comportamiento (las especificas clases en el subsistema que realizan el comportamiento) • Clases para garantizar la comunicación entre las capas. Por ejemplo en el caso de .NET se recomienda utilizar clases del tipo Typed Dataset para este fin. • Clases intermediarias para garantizar la comunicación con servicios Web y/o aplicaciones externas. • Clases para definir la interfaz de los servicios Web internos a desarrollar (como un servicio Web es una aplicación independiente, cualquier solicitud de información debe realizarse a través de su interfaz haciendo uso de un método del servicio) y otras clases para garantizar la utilización de los servicios Web en la aplicación. Es necesario incluir siempre una clase intermediaria para garantizar la independencia. • Clases intermediarias para los servicios Web con uso de Base de Datos. Los servicios Web utilizarán una Base de Datos independiente o un segmento de Base de Datos donde no hay relaciones entre las tablas del servicio Web y el resto de la Base de Datos. Lo anterior genera un trabajo de programación mas complejo pues inclusive la integridad referencial entre estas las tablas del servicio Web con el mundo externo tiene que ser logrado a nivel de programa. Este problema provoca la creación de clases intermediarias para poseer la información requerida de otro WS para su uso posterior. • Clases intermediarias para el acceso a la base de datos. Esto se corresponde con las clases en una de las capas de la arquitectura • Clases activas que permiten representar hilos en el sistema. Puede haber composición entre ellas. En Sistemas de TR las cápsulas comparten características de las clases activas y de los subsistemas y sustituyen a las primeras. Buscar en los casos de uso cuales objetos interactúan cuando un evento ocurre y agrupar en autónomas conjuntos de colaboraciones de objetos esto forma las clases activas compositivas. Si el evento tiene atributos se modelan como clases con el estereotipo de activa • Interfaces permite capturar y examinar los empates del sistema definiendo de forma precisa como las partes del sistema ínter opera. Puede haber composición entre ellas.
Cuenta
Caja
Fluj o
Figura 29 Ejemplo de interfaz También se deben transformar clases e incluir otras para garantizar la implementación de las aplicaciones Web. Se debe modelar las páginas, los enlaces de unas con otras, todo el contenido dinámico asociado a la creación y el contenido dinámico de las páginas en el cliente. • Definir páginas en el cliente (indica la funcionalidad a realizar en el cliente mediante el navegador correspondiente) y página en el servidor donde se incluye toda la funcionalidad para la construcción de la página en el cliente. También se definen paginas Formularios para representar los formularios normalmente incluidos en las paginas en el cliente. En la figura 30 se muestra la representación de estos tipos de páginas. • Incluir los tipos de asociaciones propias de las aplicaciones Web. En las figuras 31, 32, 33 y 34 se muestran ejemplos. Las asociaciones poseen los tipos que aparecen a continuación: o hipervínculos (“link”) o construcción de pagina (“built”) o envío de datos al servidor desde un formulario (“submit”) o entre una página en el servidor y otra o con una cliente se envía un comando al cliente para requerir otro recurso(“redirect”) o para indicar que la página en el servidor incluye un objeto al construir la pagina en el cliente (“include”) o una asociación de composición entre una página en el cliente a una clase lógica que representa un componente embebido, que puede ser un ActiveX, un Applet u otro componente (Object).
Página en el cliente
Formulario
Página en el servidor
Figura 30 Representación grafica de los iconos para representar paginas en el cliente, servidor y formularios
homepage
Busqueda
Home