Instructivo de UML - Parte 1

El Lenguaje Unificado de Modelado se ha convertido rpidamente en el estndar de facto para construir software orientado a objetos. Este breve instructivo provee una introduccin al UML muy por encima y sugiere algunas lecturas recomendadas adicionales. Pero primero...Que es UML? La especificacin del OMG: "El Lenguaje de Modelado Unificado (UML) es un lenguaje grfico para visualizar, especificar, construir y documentar los artefactos de un sistema intensivo en software. EL UML ofrece una forma estndar para escribir un plano del sistema, incluyendo cosas conceptuales tales como procesos de negocios y funciones del sistema, como as tambin cosas concretas tales como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes de software reutilizables" El punto importante para notar aqu es que el UML es un "lenguaje" para especificar y no un mtodo o un proceso. El UML se usa para definir un sistema de software; para detallar los artefactos en el sistema, para documentar y construir -es el lenguaje en el que est escrito el plano-. El UML se puede usar en una gran variedad de formas para soportar una metodologa de desarrollo de software (tal como el Proceso Unificado de Rational) -pero no especifica en s mismo qu metodologa o proceso. El UML define la notacin y las semnticas para los siguientes dominios: - El Modelo de Interaccin del Usuario o Modelo de Casos de Uso -describe el lmite y la interaccin entre el sistema y los usuarios-. Se corresponde en cierta manera a un modelo de requisitos. - El Modelo de Interaccin o de Colaboracin -describe cmo interactuarn los objetos en el sistema entre s para realizar el trabajo. - EL Modelo de Estado o Modelo Dinmico -las cartas de estados describen los estados o condiciones que las clases asumen a travs del tiempo-. Los grafos de actividad describen los flujos de trabajo que implementar el sistema. - El Modelo Lgico o de Clases -describe las clases y los objetos que conformarn el sistema. - El Modelo de Componentes Fsico -describe el software (y algunas veces los componentes de hardware) que conforman el sistema. - EL Modelo de Despliegue Fsico -describe la arquitectura fsica y el despliegue de componentes en esa arquitectura de hardware. El UML tambin define mecanismos de extensin para extenderlo a fin de cumplir con necesidades especficas (por ejemplo, extensiones de Modelado de Procesos de Negocios). La parte 2 de este instructivo se explaya en cmo usted usa el UML para definir y construir sistemas reales.

Vea tambin Modelado de Procesos de Negocios

Instructivo de UML - Parte 2

En la Parte 1 establecimos que el UML es un lenguaje para especificar los artefactos y las interacciones de un sistema de software. Tambin vimos que trata con seis dominios principales desde los modelos de Casos de Uso, a travs de los modelos dinmico y lgico hasta el modelo de despliegue fsico final- y que se incluyeron mecanismos de extensin para permitir agregados especializados a la notacin del modelo. Entonces... Cmo usar el UML? El UML tpicamente se usa como parte de un proceso de desarrollo de software, con el soporte de una herramienta CASE adecuada, para definir los requisitos, las interacciones y los elementos del sistema de software propuesto. La naturaleza exacta del mtodo depende de la metodologa de desarrollo que se use. Un proceso de ejemplo podra lucir algo as como el que sigue: 1. Capture un Modelo de Procesos de Negocio. Esto se usar para definir las actividades y procesos de alto nivel que ocurren en una organizacin y para proveer los fundamentos para el modelo de Casos de Uso. El Modelo de Procesos de Negocio tpicamente captura ms que lo que implementar un sistema de software (por ejemplo, incluye procesos manuales y otros). 2. Trace un Modelo de Casos de Uso al Modelo de Procesos de Negocio para definir exactamente qu funcionalidad est intentando proveer desde la perspectiva del usuario de negocio. A medida que se agrega cada caso de uso, cree un vnculo trazable desde el proceso de negocio apropiado al caso de uso (por ejemplo, una conexin de realizacin). Esta traza establece claramente qu funcionalidad proveer el Nuevo sistema para cumplir con los requisitos de negocio descriptos en el modelo de procesos. Tambin asegura que no existirn casos de uso sin un propsito. 3. Refinar los casos de uso -incluye requisitos, restricciones, tasas de complejidad, notas y escenarios-. Esta informacin describe sin ambigedades qu hace el caso de uso, cmo se ejecuta y las restricciones en su ejecucin. Asegrese de que el caso de uso an cumple con los requisitos del proceso de negocio. Incluya la definicin de las pruebas de sistema para cada caso de uso para definir el criterio de aceptacin de cada uno de ellos. Incluya tambin algunas descripciones de las pruebas de aceptacin de los usuarios para definir cmo probar l esta funcionalidad y qu son los criterios de aceptacin. 4. Comience a construir un modelo de dominio (objetos de negocio de alto nivel), diagramas de secuencia, diagramas de colaboracin y modelos de interfaces de usuario a partir de las entradas y salidas del Modelo de Procesos de Negocio y de los detalles de los casos de uso. Ellos describen las 'cosas' en el Nuevo sistema, la forma en la que tales cosas interactan y la interfaz que utilizar un usuario para ejecutar los escenarios de los casos de uso. 5. Cree el Modelo de Clases a partir del modelo del dominio, del modelo de interfaz de usuario y de los diagramas de escenario. Es una especificacin precisa de los objetos en el sistema, de sus datos o atributos y de su comportamiento u operaciones. Los objetos del dominio se pueden abstraer en jerarquas de clases utilizando herencia. Los mensajes de los diagramas de escenario tpicamente pasarn a ser operaciones de clases. Si se va a utilizar un framework existente o patrones de diseo, es posible importar elementos de modelado existentes para usar en el nuevo sistema. Defina pruebas unitarias y de integracin para probar a fondo en cada clase: i) que la clase funciona internamente como se especific y que ii) la clase interacta como se esperaba con otras clases y componentes relacionados. 6. A medida que se desarrolla, el Modelo de Clases se puede dividir en paquetes y componentes discretos. Un componente representa una porcin de software desplegable que contiene el comportamiento y los datos de una o ms clases y expone una interfaz estricta a otros consumidores de sus servicios. Entonces se construye un Modelo de Componentes a partir del Modelo de Clases para definir el empaquetamiento lgico de las clases. Defina las pruebas de integracin para cada componente para confirmar que su interfaz cumple con la especificacin que se dio en su relacin con otros elementos de software. 7. Deberan haber capturado y documentado requisitos adicionales en forma concurrente con el trabajo que ya hizo. Por ejemplo, requisitos no funcionales, de performance, de seguridad,

responsabilidades, planes de entrega. Recopile esto junto con el modelo y mantngalo actualizado a medida que madura el modelo. 8. The Modelo de Despliegue define la arquitectura fsica del sistema. Este trabajo se puede comenzar en forma temprana para capturar las caractersticas fsicas del despliegue -qu hardware, sistemas operativos, capacidades de la red, interfaces y software de soporte constituirn el sistema, dnde se desplegar y qu parmetros aplicar para recuperacin ante desastres, confiabilidad, copia de seguridad y soporte. La arquitectura fsica se actualizar a medida que se desarrolla el sistema para reflejar el sistema real que se est proponiendo. 9. Construya el sistema: tome porciones discretas del modelo y asgnelas a un desarrollador o ms. En una construccin dirigida por casos de uso esto significar asignar un caso de uso al equipo de desarrollo, hacindolos construir las pantallas, objetos de negocio, tablas de la base de datos y componentes relacionados necesarios para ejecutar ese caso de uso. A medida que se construye cada caso de uso se lo debera acompaar con pruebas de completitud, de integracin y de sistema. Una construccin dirigida por componentes puede ver componentes de software que se asignan para su construccin a equipos de desarrollo. 10. Siga la pista de los defectos que surgen en las fases de prueba en los elementos relacionados del modelo -por ejemplo, los defectos de las pruebas de sistema en los casos de uso, los defectos de las pruebas unitarias en las clases, etc. Siga la pista de cualquier cambio en los elementos de modelado relacionados a fin de administrar el 'avance del alcance'. 11. Actualice y refine el modelo a medida que procede el trabajo -aplicando siempre el impacto de los cambios y del refinamiento del modelo en el trabajo posterior-. Utilice un enfoque iterativo para trabajar en porciones discretas durante el diseo, aplicando siempre a la construccin actual, los requisitos que surjan y cualquier descubrimiento que salga a la luz durante el desarrollo. 12. Entregue el software completo y probado para una prueba en el ambiente de produccin. Si se est llevando a cabo una entrega en fases, esta migracin desde la prueba a la produccin del software que se construy puede ocurrir muchas veces durante la vida del proyecto. Nota: Tenga en cuenta que el proceso de arriba es, necesariamente, breve en su descripcin, deja muchas cosas sin decir y puede no trabajar o seguir el proces que Ud. adopt. Se dio como un ejemplo de cmo se usa el UML para dar soporte a un proyecto de desarrollo de software.