2 E STADO DEL ARTE Modelado Lenguajes Formales UML XML Herramientas Específicas de Dominio Aproximaciones a la Integración de Herramientas

Transcripción

1 2 ESTADO S DEL ARTE Este capítulo se concibe como una exposición sobre la situación actual en cuanto al empleo de entornos multidisciplinares en el desarrollo de SW para SCDTR. Esta exposición se hace de forma progresiva. Se inicia con una descripción de la ciencia básica sobre dos conceptos abstractos identificados como necesarios para el entorno en el primer capítulo: el Modelado y el empleo de Lenguajes Formales como mecanismo de expresión de instancias de modelos. Se repasarán, entre otras, nociones como vista, abstracción o instancia, por un lado, y léxico, sintaxis o semántica por el otro. Así mismo, se introducirán los fundamentos de dos tecnologías estándar aplicables en cada uno de estos dos campos: el lenguaje de modelado UML y el lenguaje formal XML, respectivamente. El interés en este punto no va más allá de conocer las ventajas que estas tecnologías pueden aportar para ubicarlas con criterio en el entorno, pero será en otros capítulos donde se profundice sobre las características más específicas de las técnicas seleccionadas. Posteriormente, el estudio se centra en las Herramientas Específicas de Dominio, es decir, en las herramientas más utilizadas en cada una de las disciplinas mencionadas en el primer capítulo. Este recorrido permitirá recoger similitudes y diferencias entre herramientas, que conducirán al enunciado de las necesidades que se le imponen al entorno que las integre. También se describirán algunas Aproximaciones a la Integración de Herramientas o soluciones ofrecidas por otros grupos de investigación que también persiguen la colaboración y comunicación entre herramientas.

2 2.1 Modelado Niveles de Abstracción Modelo de 4+1 vistas UML (Unified Modeling Language) Diagramas utilizados en UML Proceso de Desarrollo Carencias de UML Estándares OMG Model Driven Architecture (MDA) Meta Object Facility (MOF) XML Metadata Interchange (XMI) UML Lenguajes Formales Algunas Definiciones EBNF XML Generación de Gramáticas a partir de Modelos UML 2.3 Herramientas Específicas de Dominio Ingeniería de Control Sistemas Distribuidos Sistemas de Tiempo Real UML para Sistemas de Tiempo Real Ingeniería del SW Modelo de Madurez de Capacidad Software (CMM) El Proceso de Desarrollo del SW Estructura de las Herramientas CASE Lenguajes de Descripción de Arquitecturas 2.4 Aproximaciones a la Integración de Herramientas Soluciones particulares de dominio NetBeans Ptolemy Soluciones genéricas (METAframework) Generic Modelling Environment (GME) Eclipse

3 2..1 MODELADO Sobre la construcción de un modelo como abstracción de la realidad y sobre la jerarquía de las abstracciones. Descripción de las características de UML y otros estándares OMG relacionados con el modelado NIVELES DE ABSTRACCIÓN El modelado es necesariamente un ejercicio de abstracción, entendida ésta como una simplificación y generalización de la realidad. Abstraer significa ignorar, excluir o esconder ciertos detalles de un conjunto de elementos con el objetivo de capturar y resaltar las características comunes a todos esos elementos. Una abstracción es hija y madre a la vez porque primeramente es concebida a partir del análisis de ciertos elementos, pero después sirve como origen para la instanciación o concreción de nuevos elementos que se derivan de ella. Ejemplos típicos de abstracción son los tipos de datos que se usan en programación para agrupar datos con características comunes. El uso de la abstracción permite describir, representar, manejar y resolver problemas complejos, pudiendo después aplicar los resultados a casos concretos (instancias). Normalmente, se construyen jerarquías de abstracción, en las que cada nivel de abstracción se apoya en los inferiores. Cada nivel de abstracción esconde ciertos detalles a los niveles superiores de forma que se simplifica el tratamiento de problemas más complicados. Se dice que la construcción de los niveles de abstracción se hace de abajo hacia arriba (bottom-up), puesto que se parte de lo más concreto y se van agrupando y generalizando características comunes para subir un peldaño más en la pirámide de niveles. Por el contrario, la implementación o puesta en práctica de resultados genéricos se hace de arriba hacia abajo (top-down) porque a partir de una solución genérica deducida desde un nivel de abstracción alto se va descendiendo para poder instanciar esa solución y aplicarla a una realidad concreta. En general, pueden definirse tantos niveles de abstracción como se precise para gestionar adecuadamente un determinado problema. Incluso para un mismo problema pueden existir diferentes aproximaciones de abstracción, por ejemplo los marcos de referencia OSI y TCP/IP emplean respectivamente siete y cuatro niveles de abstracción para representar las capas involucradas en la comunicación de información. La representación abstracta de la información es la base en la que se fundamenta la evolución del conocimiento humano en cualquier área. Concretamente, en el caso de la informática los ejemplos son múltiples: codificación de la información, Pág. 2-1

4 programación en lenguajes de alto nivel, generación de compiladores, modularidad del software, etc. En este ámbito de la informática se definen típicamente cuatro niveles de abstracción para el modelado: Tabla 2-1. Niveles de abstracción en el modelado. NIVELES DE ABSTRACCIÓN ENTIDADES MANEJADAS LENGUAJES DEFINIDOS Meta-metamodelo Meta-modelos Lenguaje para la descripción de diferentes tipos de modelos. Lenguaje de modelado Meta-modelo Meta-metadatos ó Modelos Lenguaje para la descripción de diferentes tipos de datos (meta-datos) Modelo Meta-datos Lenguaje para la descripción de datos concretos Información Datos Nivel de Información. Agregación informal de datos a manejar en un entorno concreto (aplicación). Se separa un subconjunto de datos con características comunes o interesantes desde un determinado punto de vista. Nivel de Modelo. Agregación informal de meta-datos (datos sobre los datos) que describen una información concreta. Se describen las características comunes de los datos dando lugar a meta-datos que se agrupan, describiéndose las relaciones entre ellos, para formar un modelo. Nivel de Meta-modelo. Agregación informal de modelos o metametadatos (descripción de meta-datos). Descripciones que definen la estructura y la semántica de los metadatos. Se describen las características comunes de subconjuntos de meta-datos dando lugar a meta-metadatos o modelos que se agrupan, describiéndose las relaciones entre ellos, para formar un meta-modelo. Nivel de Meta-metamodelo. Definición de la estructura y la semántica de los meta-metadatos. Se capturan las características comunes de subconjuntos de modelos dando lugar a meta-modelos que se agrupan, describiéndose las relaciones entre ellos, para formar un meta-metamodelo. Tal y como muestra la Tabla 2-1, en cada nivel de define una nueva entidad (metadato, modelo, meta-modelo, ) que es empleada en el nivel superior para generar otra entidad más abstracta (modelo agrupando meta-datos, meta-modelo agrupando modelos, ). Además, la adecuada expresión de esta jerarquía de abstracciones está directamente relacionada con el uso de lenguajes formales. En cada nivel de abstracción se genera el lenguaje que sirve para describir los elementos del nivel inmediatamente inferior. Por esa razón, un modelo no pasará a constituirse en agregación formal de meta-datos hasta que no exista un meta- Pág. 2-2

5 modelo que defina el lenguaje con el que describir formalmente al modelo, de forma que la especificación de cualquier modelo (instancia del meta-modelo) pueda ser validada. De una manera burda, se pueden asemejar estos niveles de abstracción con los empleados en la definición de los lenguajes de programación de alto nivel, tal y como muestra la Tabla 2-2: Tabla 2-2. Ejemplo de abstracción jerárquica: lenguajes de programación. NIVELES Meta-lenguaje programación ENTIDADES MANEJADAS Lenguajes de programación LENGUAJES Lenguaje para la descripción de diferentes lenguajes de programación Lenguaje programación Sentencias control flujo, variables, tipos, Lenguaje para la descripción de programas como modelos de ejecuciones Tipos de datos Variables TYPE tnombre = string [20]; tcuenta = RECORD... Nombre, Número cuenta,... Lenguaje para la descripción de tipos de datos como modelos de variables Lenguaje para la descripción de variables (y relaciones entre ellas) como modelos de los datos Información bancaria Aitor Pérez, ,... En el caso particular de la programación orientada a objetos se puede decir que los niveles de abstracción más significativos serían: dato, objeto, clase y modelo. En general, se puede aplicar el modelado jerárquico en cualquier ámbito, teniendo claro cuál es el nivel inferior o qué tipo de información se va a modelar y con qué propósito y cuántos niveles de abstracción (por encima del inicial) se van a necesitar. Habitualmente se emplea el término alinear para denotar la acción de definir o fijar la información a modelar, los datos que van a constituir el primer escalón de la jerarquía. A partir de ese punto de denotan los niveles superiores como modelo, metamodelo, meta-metamodelo, etc respecto al más inferior. Pág. 2-3

6 Figura 2-1. Arquitectura de metamodelado de UML en 4 niveles. La Figura 2-1 representa la arquitectura de UML (lenguaje de modelado que se describirá en el apartado 2.1.3) tal y como es definida por Medvidovic y Taylor (2000) y basada en cuatro niveles. El nivel de meta-metamodelo define un lenguaje para la especificación de notaciones de modelado, y una de sus instancias es UML. El nivel de metamodelo define las especificaciones legales para un determinado lenguaje de modelado, por ejemplo el metamodelo UML define la notación legal y la semántica de las especificaciones UML. El nivel de modelo se usa para representar sistemas específicos, un modelo será así una instancia del metamodelo que describe un producto específico. Finalmente, se encuentra el nivel de los objetos de usuario. Pág. 2-4

7 2.1.2 MODELO DE 4+1 VISTAS En lo concerniente al modelado de sistemas software desde varios puntos de vista, es obligada la referencia al modelo 4+1 de Kruchten (1995). Este modelo permite describir la arquitectura de grandes sistemas SW desde múltiples vistas para tratar separadamente los requisitos de usuarios finales, desarrolladores, ingenieros de sistemas, gestores de proyecto, etc. Por lo tanto, son diferentes y complementarias las capacidades de cada vista porque detrás de ellas hay perfiles de usuario diferentes. El modelo describe vistas (arquitecturas) a través de elementos (componentes, conectores) y notaciones gráficas específicas para cada vista. Las vistas que se definen son: Vista Lógica. Está pensada para que el usuario final pueda describir la funcionalidad deseada. Se realiza una descomposición del sistema siguiendo la filosofía de Orientación a Objetos (abstracción, encapsulado y herencia). La notación gráfica empleada se compone de diagramas de clases y patrones para la descripción estática y máquinas de estados finitos para describir el comportamiento dinámico. Los elementos de su notación son: o o Componentes: clase, clase parametrizada, categoría de clases Conectores: asociación, agregación, uso, herencia, instancia Vista de Proceso. Los integradores del sistema la emplean para expresar requisitos no funcionales como integridad, rendimiento o escalabilidad. Se realiza la distribución de los objetos diseñados en la vista lógica en procesos (conjunto de tareas concurrentes) en función de los requisitos no funcionales. Se deben reflejar aspectos de concurrencia, sincronización y comunicación entre procesos. Los elementos de su notación son: o Componentes: proceso, proceso simple, periodicidad o Conectores: mensaje, RPC (Remote Procedure Call), mensaje bidireccional, difusión de evento Vista de Desarrollo. Los programadores la emplean para describir la organización estática del SW en el entorno de desarrollo (gestión del SW, descomposición en subsistemas a desarrollar por gente diferente, descripción de interfaces, relaciones de importación y exportación, reutilización, requisitos del lenguaje de programación o herramientas de desarrollo, evaluación de costes, planificación, portabilidad, seguridad). Los elementos de su notación son: o o Componentes: módulo, subsistema, nivel Conectores: referencia, dependencia de compilación Pág. 2-5

8 Vista Física. Los ingenieros de sistema definen aquí el mapeo del SW en el HW aplicando requisitos como disponibilidad, tolerancia a fallos, rendimiento o escalabilidad. Si existen varios nodos es aquí donde se define la topología del sistema y las comunicaciones y se mapean en diferentes nodos los procesos, tareas y objetos. Pueden existir diferentes configuraciones físicas de un mismo sistema para las fases de pruebas y desarrollo. Se intenta realizar un mapeo flexible y con mínimo impacto en el SW. Los elementos de su notación son: o o Componentes: procesadores, otros dispositivos Conectores: línea de comunicación permanente o no, bidireccional o unidireccional Escenarios ó casos de uso. Ilustran el uso y las relaciones entre el resto de las vistas y permiten abstraer los requisitos más generales. El nombre de 4+1 proviene del uso que se le da a esta quinta vista como vista integradora de las demás, en la que se expresan las relaciones cruzadas. Los elementos de su notación son: o o Componentes: actores, casos de uso Conectores: relaciones Tal y como resume la Figura 2-2, cada vista tiene un perfil de usuario y una notación gráfica especializada (formada siempre por un conjunto de componentes y conectores) para resolver sus necesidades expresivas. Además, se establece un proceso de desarrollo porque está predefinido el orden en el cual se deben utilizar cada una de las vistas para modelar el sistema; se comienza siempre por la vista lógica y se termina en la física, pero se tiene en cuenta en cada vista lo que se haya generado en las anteriores. En definitiva, se avanza hacia una descripción completa del sistema aportando detalles al todo desde perspectivas particulares. Pág. 2-6

9 Cada vista posee diferentes: Usuarios / Objetivos Notación (componentes y conectores) Figura 2-2. Vistas del Modelo 4+1 Pág. 2-7

10 2.1.3 UML (UNIFIED MODELING LANGUAGE) Originalmente, UML fue concebido por Grady Booch, James Rumbaugh e Ivar Jacobson de Rational Software. Posteriormente obtuvo el apoyo de la industria vía el consorcio de socios de UML, y fue presentado al Object Management Group (OMG) y aprobado por éste como estándar (17 de noviembre de 1997). Debido a que UML evolucionó a partir de varios métodos orientados a objeto de segunda generación (en cuanto a nivel de notación), mayoritariamente se cree que sólo es aplicable a sistemas de software orientados a objeto cuando, realmente, UML no es simplemente un lenguaje para modelado orientado a objeto de tercera generación, sino un "lenguaje para modelado unificado" relativo a sistemas en general (ver Figura 2-3). Al ser un lenguaje de modelado y no un método, consiste en una notación principalmente gráfica, que cualquier método puede emplear para expresar su diseño. Booch Rumbaugh Jacobson Odell Shlaer-Mellor Object life cycles UML Meyer Pre- and Post-conditions Harel State Charts Gamma et. al. Frameworks, patterns, notes Wirfs-Brock Embly Responsabilities Singleton classes Fusion Operation descriptions, message numbering Figura 2-3. UML como fusión de varios lenguajes de modelado. UML es un lenguaje de modelado para la especificación, visualización, construcción y documentación de sistemas: Como lenguaje, se emplea para la comunicación, es decir, como medio para capturar el conocimiento (semántica) y expresar el conocimiento (sintaxis) del sistema en estudio. Proporciona un vocabulario y las reglas para combinar las palabras de ese vocabulario con objeto de posibilitar la comunicación, de manera que un desarrollador puede escribir un modelo en UML, y otro desarrollador, que incluso utilice otra herramienta de programación, puede interpretar ese modelo sin ambigüedad. Como lenguaje de modelado, se centra en la comprensión del sistema a través de la formulación de un modelo del mismo (y su contexto respectivo). Se trata de un lenguaje estándar para trazar los planos del sistema, cuyo Pág. 2-8

11 vocabulario y reglas se centran en la representación conceptual y física de un sistema. En cuanto a cómo se aplica para especificar sistemas, se puede utilizar para comunicar "qué" se requiere de un sistema y "cómo" puede ser construido. Dado que especificar significa construir modelos precisos, UML cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar e implementar un sistema. En cuanto a cómo se aplica para visualizar sistemas, se puede usar para describir visualmente un sistema antes de ser construido. Un modelo explícito facilita la comunicación. En cuanto a cómo se aplica para construir sistemas, se puede emplear para guiar la construcción de un sistema (similar a los "planos"). Además, UML es lo suficientemente expresivo y no ambiguo como para permitir, a través de herramientas que lo integran, la ejecución directa de modelos, la simulación de sistemas y la instrumentación de sistemas en ejecución. En cuanto a cómo se aplica para documentar sistemas, se puede utilizar para capturar conocimiento de un sistema a lo largo de todo el proceso de su ciclo de vida. UML cubre la documentación de la arquitectura de un sistema y todos sus detalles, también proporciona un lenguaje para modelar las actividades de planificación de proyectos y gestión de versiones. Además, cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y de sistemas de información pasando por todos los tipos de sistemas (software y no software), dominios (negocios versus software) y procesos de ciclo de vida. También es importante destacar que UML NO es: Un lenguaje de programación visual, sino un lenguaje de modelado visual. No obstante, existen herramientas CASE que conectan de forma directa los modelos UML a una gran variedad de lenguajes de programación. Una herramienta de especificación, sino un lenguaje para modelado de especificación. Un proceso, sino que habilita procesos. En resumen, UML posibilita la captura y comunicación del conocimiento y facilita la adaptación al posible aumento de complejidad o cambio. Este lenguaje para modelado (estandarizado en ciertas industrias), no es un lenguaje cerrado, sino más bien, un lenguaje abierto y totalmente extensible. Pág. 2-9

12 Diagramas utilizados en UML UML describe cualquier tipo de sistema en términos de diagramas orientados a objetos. Un diagrama es la representación gráfica de un conjunto de elementos, normalmente mostrado como un grafo conexo de nodos (elementos) y arcos (relaciones). UML permite representar un sistema desde diferentes perspectivas, obteniendo diferentes modelos en forma de diagramas. Por tanto, un diagrama es tan sólo una proyección gráfica de los elementos que configuran un sistema. UML incluye los siguientes diagramas: Diagrama de Casos de Uso Diagrama de Clases (incluyendo Diagrama de Objetos) Diagramas de Comportamiento: o o o Estados Actividad Interacción (Diagramas de Secuencia y de Colaboración) Diagramas de Implementación: o o Componentes Despliegue La Figura 2-4 muestra las relaciones que se establecen entre estos tipos de diagramas. Otra posible clasificación de los diagramas UML los divide en: Estructurales: de clases, objetos, componentes y despliegue. De comportamiento: de casos de uso, estados, actividad, secuencia y colaboración De gestión de modelos: de paquetes, de modelos y de subsistemas Pág. 2-10

13 Casos de Uso Diagramas de Secuencia Diagramas de Clases Diagramas de Distribución Diagramas de Componentes C Ó D I G O Diagramas de Colaboración Diagramas de Estados Diagramas de Actividad Diagrama de Casos de Uso Figura 2-4. Relación entre diagramas. Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación.esta técnica permite capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje. No pertenece realmente al enfoque orientado a objeto, más bien es una técnica para el modelado de escenarios (un escenario es una instancia de un Caso de Uso) en los cuales el sistema debe operar. El modelo de los Casos de Uso comprende los actores (agente, persona o cosa que solicita un servicio al sistema o actúa como catalizador para que ocurra algo), el sistema y los propios Casos de Uso. Un Caso de Uso describe una situación de uso del sistema interactuando con actores. Se determinan observando y precisando, actor por actor, las secuencias de interacción desde el punto de vista del usuario. Examinando estas secuencias de interacción, que expresan las necesidades funcionales de los actores, se determina el conjunto de funcionalidades del sistema. La Figura 2-5 ilustra un ejemplo de diagrama de casos de uso. La descripción del Caso de Uso incluye: El inicio: cuándo y qué actor lo produce? El fin: cuándo se produce y qué valor devuelve? La interacción actor-caso de uso: qué mensajes intercambian ambos? Objetivo del caso de uso: qué lleva a cabo o intenta? Cronología y origen de las informaciones Repeticiones de comportamiento: qué operaciones son iteradas? Pág. 2-11

14 Situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso? Caso de uso Actor Caso de uso Actor Actor Caso de uso Caso de uso Actor Figura 2-5. Diagrama de casos de uso. La realización de los Casos de Uso es la transformación de los distintos pasos y acciones que lo describen en clases, operaciones y relaciones entre clases.en resumen, los Casos de Uso describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario, permitiendo definir los límites del sistema y las relaciones del sistema con el entorno Diagrama de Clases Un Diagrama de Clases presenta las clases y objetos del sistema con sus relaciones estructurales y de herencia. El Diagrama de Clases (ver Figura 2-6) es el diagrama principal para el análisis y diseño, aunque el trabajo realizado en los Diagramas de Casos de Uso, de Secuencia y de Colaboración aporta información para establecer las clases, objetos, atributos y métodos. Pág. 2-12

15 Clase Clase Clase 1 1 Clase 1 * * Clase 1 * * Clase {disjunta, completa} * 1 Clase Clase Clase Figura 2-6. Diagrama de Clases. Los Diagramas de Clases y los Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una parte del dominio, mientras que un Diagrama de Objetos representa una situación concreta del dominio, dado que cada objeto es una instancia de una clase y cada enlace es una instancia de una relación (los enlaces vinculan objetos, las asociaciones vinculan clases). Los Diagramas de objetos que contienen objetos y enlaces son instancias de los Diagramas de Clases que contienen clases y asociaciones. Por lo tanto, debe existir coherencia entre ambos Diagramas de Interacción Los Diagramas de Interacción muestran cómo se comunican los objetos en una interacción. Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. De ahí que se modelen las interacciones. Existen dos tipos de Diagramas de Interacción: los Diagramas de Secuencia y los Diagramas de Colaboración. Los Diagramas de Secuencia están bien adaptados para representar interacciones, mientras que los Diagramas de Colaboración se prestan más al descubrimiento de abstracciones pues permiten representar los objetos en una disposición próxima a la realidad. Es frecuente empezar por uno de Colaboración y pasar después a Secuencia Diagrama de Secuencia El Diagrama de Secuencia muestra el orden cronológico de mensajes entre objetos durante un escenario concreto.el Diagrama de Secuencia se emplea para establecer un escenario del sistema, determinando los objetos y mensajes involucrados. Presenta los objetos de un escenario mediante líneas verticales y los Pág. 2-13

16 mensajes entre objetos como flechas conectando objetos. Además, refleja de manera indirecta las opciones de control. :Actor Mensaje :Actor :Objeto :Objeto :Objeto :Objeto Mensaje Mensaje Mensaje Mensaje Mensaje Mensaje Mensaje Figura 2-7. Diagrama de Secuencia. Son de gran utilidad para: La documentación de un Caso de Uso: en términos próximos al usuario y sin detallar la sincronización existente. La representación precisa de las interacciones entre objetos.diagrama de Colaboración El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso. La colaboración es mediante el intercambio de mensajes.el Diagrama de Colaboración se emplea para establecer un escenario del sistema, determinando los objetos y mensajes involucrados. Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección. Así, la estructura estática viene dada por los enlaces, mientras que la estructura dinámica está representada mediante el envío de mensajes por los enlaces. Además, la distribución de los objetos en el diagrama permite representar una disposición espacial. Son útiles en la fase exploratoria para identificar objetos. En realidad, el Diagrama de Colaboración (ver Figura 2-8) ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema. Pág. 2-14

17 N: mensaje :Objeto Actor N: mensaje :Objeto N: mensaje N: mensaje N: mensaje Actor N: mensaje N: mensaje N: mensaje :Objeto :Objeto Diagrama de Estados Figura 2-8. Diagrama de Colaboración. El Diagrama de Estados modela el comportamiento de una parte del sistema a través del tiempo. Típicamente se elabora un Diagrama de Estados para cada clase que tenga un comportamiento significativo; para el resto se puede considerar que tienen un único estado. El comportamiento es modelado en términos del estado en el cual se encuentra el objeto, qué acciones se ejecutan en cada estado y cuál es el estado al que transita después de un determinado evento. Los Diagramas de Estados representan autómatas de estados finitos desde el punto de vista de los estados y las transiciones. El formalismo es el de los Statecharts (Harel et al 1990). Los Statecharts son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos. Cada objeto sigue el comportamiento descrito en el Statechart asociado a su clase, y el estado en el que se encuentran caracterizas sus condiciones dinámicas. El estado está caracterizado parcialmente por los valores de los atributos del objeto. Cada objeto está en un estado en cierto instante y la transición entre estados, que es instantánea, se debe a la ocurrencia de eventos. Los estados inicial y final están diferenciados del resto. Los Statecharts de UML son deterministas y son complementarios a los escenarios (ver Figura 2-9). Pág. 2-15

18 Estado Transición Transición Estado Transición Transición Estado Diagrama de Actividad Figura 2-9. Diagrama de Estados. El Diagrama de Actividad es una variante de los Diagramas de Estados, organizado respecto a las acciones. Caso especial de Diagrama de Estados donde: Todos (o la mayoría de) los estados son estados de acción. Todas (o la mayoría de) las transiciones son disparadas como consecuencia de la finalización de la acción. El Diagrama de Actividad (Figura 2-10) puede estar asociado a una clase, a la implementación de una operación (representación del comportamiento interno de un método) o a un Caso de Uso. Las actividades se enlazan por transiciones automáticas, es decir, cuando una actividad termina se desencadena el paso a la siguiente actividad. Las actividades no poseen transiciones internas ni transiciones desencadenadas por eventos. Actor Actor Actor Actividad Actividad Actividad Actividad Actividad Actividad Actividad Actividad Actividad Actividad Figura Diagrama de Actividad. Pág. 2-16

19 Diagrama de Componentes Los Diagramas de Componentes describen los elementos físicos y sus realizaciones en el entorno de realización. Un Diagrama de Componentes permite modelar la estructura del software y la dependencia entre componentes. Normalmente, un componente es un grupo de clases que trabajan estrechamente, pudiendo corresponder a código fuente, binario o ejecutable. Pero en general, los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas; pueden ser: simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Por ejemplo: cada clase del modelo lógico se realiza en dos componentes: la especificación y el cuerpo.la especificación contiene el interfaz de la clase, mientras que el cuerpo contiene la realización de dicha clase. Las relaciones de dependencia se utilizan en los Diagramas de Componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente (ver Figura 2-11). Por otra parte, los distintos componentes pueden agruparse en paquetes, según un criterio lógico, para simplificar la implementación. Son paquetes estereotipados en <<subsistemas>> para incorporar la noción de biblioteca de compilación y de gestión de configuración. Los subsistemas organizan la vista de realización de un sistema. Cada subsistema puede contener componentes y otros subsistemas (la descomposición en subsistemas no es una descomposición funcional). La relación entre paquetes y clases en el nivel lógico es la correspondiente entre subsistemas y componentes en el nivel Componente Componente Componente Componente Componente físico. Figura Diagrama de Componentes. Pág. 2-17

20 Diagrama de Distribución Los Diagramas de Distribución muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. El Diagrama de Distribución modela la distribución en tiempo de ejecución de los elementos de procesamiento y componentes de software, con los procesos y objetos asociados. Modelan los nodos y la comunicación entre ellos. Nodo Componente Componente Componente Nodo Componente Componente Nodo Componente Componente Componente Proceso de Desarrollo Figura Diagrama de Distribución. UML no es una metodología. Dentro del proceso de solución de un problema, es el método subyacente el que sugiere cómo se utiliza el conocimiento para construir una solución. Esto incluye el sugerir qué diagramas se deben usar, y la perspectiva y el nivel de abstracción a emplear para trazar e interpretar dichos diagramas. Los métodos deberían considerarse como sugerencias y recomendaciones que organizan y facilitan el proceso de solución de un problema, más que ser considerados como reglas rígidas e inflexibles que restringen al arte de resolver problemas. UML no prescribe ningún enfoque en particular para resolver un problema, es muy flexible y personalizable para adaptarse a cualquier enfoque. Permite y promociona (pero no requiere ni ordena) un proceso conducido por casos de uso, centrado en la arquitectura, reiterativo, e incremental que sea orientado al objeto y basado en componentes: Los Casos de Uso se emplean para administrar y proveer de un enfoque a un problema. Expresan interacciones entre los roles de los usuarios del sistema (actores) y los subconjuntos de funcionalidad (casos de uso). Pág. 2-18