1 Unified Modeling Language UMLFernando Pinciroli Solus S.A. -
2 Introducción
3 Red eléctrica inteligenteSin lugar a dudas, una red eléctrica inteligente que permita integrarse con los datos debe ser algo muy diferente a esto…
4 Red eléctrica inteligenteSistema constituido por un conjunto de subsistemas de diversa naturaleza interconectados con el fin de mejorar la producción, la transmisión y la distribución de la energía eléctrica en cuanto a: la eficiencia la confiabilidad la posibilidad de renovación la seguridad la economía y la reducción de costos el control por parte del consumidor la interdependencia entre tipos de energía el cambio climático
5 Marco conceptual de smart grids
6 Un escenario posible La empresa de distribución mide el consumo particular y global instantáneo Se establece el precio de la energía según la oferta y la demanda y los usuarios lo ven en los contadores En los hogares se configura la conexión de artefactos a la red en horas de menor consumo Los artefactos se adecuan a las variaciones en los precios y calidad de la energía Existen incentivos al ahorro de energía y retribución a los usuarios
7 Distancia en la integraciónParte A Parte B No hay estándares; la integración es propia Hay interfaces para transformar Existe un modelo común Existe un modelo definido “plug & play”
8 Integración sin un modelo común
9 Integración con un modelo común
10 La necesidad de un lenguaje común
11 Contenido de la presentación1. Introducción al UML 2. Diagramas del UML 3. Recomendaciones para el modelado 4. Extensiones del UML: SysML 5. Modelos eléctricos con UML 6. Modelado con Enterprise Architect 7. Conclusiones
12 Introducción al UML
13 Evolución del modeladoOrientación a procesos Orient. a datos ‘50 ‘60 ‘70 ‘80 ‘90 Orientación a objetos La evolución de los diferentes paradigmas comenzó primero con la aparición de los lenguajes de programación soportando cada paradigma, luego con las recomendaciones de las mejores prácticas de diseño para la aplicación del paradigma y por último con la aparición de los métodos de elaboraciones de las abstracciones a través de las técnicas y herramientas de análisis. Inicialmente la informática empleaba un enfoque orientado a los procesos, esto es, apuntaba a resolver qué cosas debía hacer un sistema, cómo se debía comportar, sin interesarse demasiado en la forma en la que se almacenarían los datos. Si bien esta corriente aún perdura, comenzó a declinar con el advenimiento de las bases de datos comerciales. La orientación a datos se inició con la aparición del modelo relacional y es el enfoque más difundido en la actualidad. La orientación a objetos se inició en 1969 con la aparición del lenguaje Smalltalk, pero se comenzó a hablar de diseño orientado a objetos durante la primera mitad de los ’80 y de análisis orientado a objetos a fines de esa década. Hoy es el enfoque que superó a los anteriores y que está marcando el rumbo del desarrollo de software.
14 Evolución de la orientación a objetosCaracterísticas UML 1980 1985 1990 1995 2000 Comportamientos Debido a que los objetos poseen características (datos) y comportamientos (procesos), dentro de la orientación a objetos hubo una división entre aquellos que consideraban más importante modelar primero los comportamientos y aquellos que consideraban fundamental apuntar primero a las características. Los autores orientados al comportamiento de los objetos son los que crearon el paradigma, se dedicaban concretamente a la orientación a objetos y trabajaban más en grupos de investigación y en desarrollo orientado a objetos. Los autores orientados a las características de los objetos provenían principalmente de una actividad previa dentro del área del modelado con bases de datos (orientación a datos) antes de pasarse a la orientación a objetos. Igualmente estas diferencias se ven superadas en el congreso OOPSLA de 1994, en donde se inicia la fusión de ambos enfoques.
15 El camino hacia la unificaciónEn 1994 Grady Booch manifiesta la necesidad de unificar criterios James Rumbaugh se une a Booch en octubre de ese año Ambos elaboran la versión 0.8 del Unified Method En 1995 Ivar Jacobson completa el trío de “amigos” y cambia el enfoque: nace el UML
16 El camino hacia la estandarizaciónSe elabora la versión 0.9 del Unified Modeling Language Durante 1996 se realizan sucesivas modificaciones en base a aportes de muchas otras personas (v y 1.0) Se realiza la versión 1.1 en conjunto con otras importantes empresas, que es presentada al OMG El OMG adopta al UML versión 1.1 como estándar a fines de 1997
17 Método vs. lenguaje de modeladoUn método es… Una descripción de los pasos que se deben seguir indicando el orden y las técnicas y herramientas que se deben emplear en cada paso, para lograr un objetivo. Un conjunto de técnicas, herramientas y tareas que, de acuerdo a un enfoque metodológico, se aplican para la resolución de un problema.
18 Método vs. lenguaje de modeladoUn lenguaje es un conjunto de señales que dan a entender una cosa Un lenguaje posee: elementos reglas sintácticas para combinar los elementos semántica dependiente del contexto Un lenguaje de modelado se emplea para expresar ideas por medio de modelos
19 Modelo Un modelo es el cuerpo de información recabadoacerca de un sistema con el fin de estudiarlo Se requiere un modelo cuando no se puede estudiar el sistema en sí mismo por alguna razón (complejidad, tamaño, costo, inexistencia, etc.) El modelo no es el sistema por lo que tiene, necesariamente, diferencias con él Muchas veces es necesario contar con un conjunto de modelos para poder enfocar el sistema desde diferentes perspectivas y así disminuir la brecha entre el modelo y el sistema
20 Objetivos del UML Establecer un lenguaje visual de modelado, expresivoy sencillo en su uso Mantener una independencia de los procesos de modelado y de los lenguajes de programación Establecer bases formales Integrar las mejores prácticas Imponer un estándar mundial
21 Metalenguajes Porción de la notación (diagramas de clases) empleada en el metamodelo Object Constraint Language (OCL) Lenguaje natural
22 Reglas semánticas Nombres: cómo nombrar los elementos en los modelosAlcance: ámbito que da un significado al nombre Especificaciones: cómo definir los elementos Adornos: agregados a la notación básica Divisiones comunes: niveles de abstracción entre un bloque de construcción y su implementación Mecanismos de extensibilidad: para modelar cuestiones no contempladas inicialmente en el UML
23 Modelos y diagramas del UMLModelado de requisitos Modelado de la estructura Modelado de la interacción Modelado del comportamiento Herramientas de diseño Organización del modelo Diagrama de casos de uso Diagrama de clases Diagrama de objetos Diag. de estructura compuesta Diagrama de secuencias Diagrama de comunicaciones Diagrama de tiempos Diag. visión global de interacciones Diagrama de estados Diagrama de actividades Diagrama de componentes Diagrama de despliegue Diagrama de paquetes
24 Del UML 1.5 al UML 2.0 Diagramas del UML 1.5 Diagramas del UML 2.0Casos de uso Clases Objetos Estructura compuesta Comunicaciones Tiempos Visión global de interacciones Secuencias Estados Actividades Componentes Despliegue Paquetes Casos de uso Clases Objetos Secuencias Colaboraciones Estados Actividades Componentes Despliegue Paquetes
25 Arquitectura de los modelosVista de diseño Vista de implementación Vista de casos de uso Vista de procesos Vista de despliegue El UML posee herramientas que permiten construir modelos que provean vistas diferentes de la realidad modelada. Pero todas las vistas están dirigidas por una principal, que es la vista de casos de uso, la que no sólo provee los mecanismos como para realizar una especificación de los requisitos, sino que también permite dirigir el proceso de desarrollo completo a partir de ella.
26 Palabras clave Modelo Modelado del comportamientoOrientación a procesos Orientación a datos Orientación a objetos UML Proceso de desarrollo Lenguaje de modelado Método Metodología Arquitectura 4+1 Modelado de requisitos Modelado de la estructura Modelado de la interacción Modelado del comportamiento Diagrama de casos de uso Diagrama de clases Diagrama de actividades Diagrama de secuencias Diagrama de tiempos Diagrama de comunicaciones Diagrama de revisión de las interacciones Diagrama de estados Diagrama de componentes Diagrama de despliegue Diagrama de paquetes
27 Diagramas del UML
28 Modelado de requisitosEn los primeros estadios de la programación, las aplicaciones se construían a partir de los requisitos prácticamente en lenguaje natural Con el advenimiento de los métodos de análisis, se suponía que los requisitos estaban completamente definidos antes del modelado Con los métodos orientados a objetos comienzan a aparecer técnicas de modelado de requisitos, basados en el empleo de “escenarios” Durante la década de los ’90 comienza a cobrar protagonismo la disciplina de ingeniería de requisitos
29 Diagrama de casos de usoIntroducido formalmente por Ivar Jacobson Aceptado por la comunidad usuaria de tecnología de orientación a objetos y por muchos metodologistas De empleo en la etapa de relevamiento para captar los requerimientos de los usuarios De fácil comprensión por parte de los usuarios de los sistemas Herramienta que precisa otras complementarias para ser utilizada en procesos de modelado OO
30 Empleo de los casos de usoInstrumentos para la captura de los requisitos Proveen la descripción funcional del sistema Facilitan la recolección de los requisitos no funcionales Establecen el límite y el alcance del sistema Son un medio para la comunicación con interlocutores diferentes Permiten expresar tanto la vista de negocios como la de software
31 Empleo de los casos de usoProveen mecanismos de modelado de sistema heredados o para procesos de reingeniería Son la principal fuente de detección de objetos Facilitan el diseño y la organización de las interfaces Son la base para la detección de la interacción entre los objetos y de sus responsabilidades Son el medio para la estimación y el dimensionamiento de un proyecto
32 Empleo de los casos de usoSon la base para las pruebas de aceptación y de integración Definen los casos de prueba Son un medio para la verificación y validación de requisitos Son la base para el desarrollo incremental Facilitan los mecanismos de trazabilidad pre y post especificación de requisitos Son la base para la administración de requisitos
33 Empleo de los casos de usoProveen los principales elementos para la documentación del sistema Constituyen una de las principales herramientas para el control de los proyectos Facilitan la asignación de recursos y la organización del equipo de desarrollo Permiten organizar el proceso de ingeniería de requisitos Proveen mecanismos para trabajar en el nivel de abstracción que sea necesario
34 Diagrama de casos de uso
35 Modelo de casos de uso Funcionalidad completa del sistema desde la perspectiva de los actores que interactúan con él Funcionalidad completa: si hay alguna funcionalidad en el sistema, debe estar incluida en este modelo Desde la perspectiva de los actores: se apunta a la descripción centrada en la vista de los actores más que en los procesos en sí Actores que interactúan con el sistema: los casos de uso describen principalmente la interacción de los actores con el sistema, pero también de lo que se realiza dentro del sistema para responder a los actores
36 Caso de uso Un caso de uso es una porción de la funcionalidad de un sistema descripta en términos de las interacciones de un actor con el sistema, con la finalidad de obtener un resultado de valor La funcionalidad se divide en función de los resultados de valor esperados desde la perspectiva del usuario que interactúa con el sistema Los casos de uso se distribuyen con un criterio adecuado en diagrama de casos de uso El conjunto de diagramas constituye el modelo de casos de uso
37 Actor Toda persona, dispositivo, sistema organización o cosa que interactúa con el sistema con el fin de obtener un resultado de valor Persona, dispositivo, sistema, organización o cosa: en definitiva, todo lo que interactúe con el sistema Interactúa con el sistema: por lo tanto, no es parte del sistema; está fuera de él y permite demarcar la frontera del sistema Para obtener un resultado de valor: la interacción no es para realizar un proceso cualquiera, sino uno que permita alcanzar un objetivo o resultado de valor
38 momento de interactuar con el sistemaRol Un rol es el papel que juega un actor en el momento de interactuar con el sistema Una persona, dispositivo, sistema, organización o cosa: puede jugar diferentes roles, por lo tanto, ser representado con diferentes actores Los roles (actores) tienen la particularidad de que pueden representar tanto conjuntos de objetos como objetos únicos
39 Modelado de asociacionesEntre actores y casos de uso: asociación común con semántica de comunicación Entre actores: generalización Entre casos de uso: dependencias (con semánticas de extensión e inclusión) y generalización
40 Extensión e inclusión
41 Extensión e inclusión «extiende» (extend) se emplea para describir unafuncionalidad que se agrega al caso de uso base en forma excepcional y que sin su existencia el caso de uso base igualmente alcanza su resultado de valor «incluye» (include) se utiliza para extraer las parte comunes de los casos de uso; son casos de uso abstractos Los casos de uso abstractos son ejecutados por actores abstractos obtenidos de una estructura de generalización entre actores
42 Extensión de casos de usoCaso de Uso base Paso del curso normal Paso del curso normal - punto de extensión si se cumple la [condición] Caso de uso de extensión Paso del curso normal
43 Inclusión de casos de usoCaso de Uso común Paso común Caso de Uso base 1 Paso del curso normal Paso común Caso de Uso base 2 Paso del curso normal Paso común
44 Extensión e inclusión Extensión Inclusión
45 Caso de uso utilitario Se trata de casos de uso que nunca se instancian, pudiendo ser casos de uso extensores o incluidos Son casos de uso cuya funcionalidad se lleva a cabo en el contexto de otro caso de uso concreto que se haya instanciado previamente Al no instanciarse, no requieren un camino normal Se recomienda crear un caso de uso genérico denominado
46 Descripción de los casos de usoEmpleo de texto: se realizan descripciones en lenguaje natural explicando la funcionalidad externa empleando el lenguaje del usuario Escenarios: casos particulares de los casos de uso con actores, datos y situaciones reales Diagramas de actividades: aunque hay que tratar de no realizar descripciones demasiado formales Scripting: oraciones estructuradas que destacan objetos y sus responsabilidades y colaboraciones
47 Estrategia de modeladoErrores Funcionalidad deseada Excepciones Camino base Funcionalidad no deseada
48 Construcción de los diagramasPasos recomendados: elaborar una lista de actores y definir sus roles elegir el actor más representativo del sistema para comenzar el diagrama agotar todas las necesidades funcionales del actor incorporando los casos de uso de la funcionalidad base para cada caso de uso, buscar los actores que deban colaborar con él repetir los dos pasos anteriores para cada actor incorporar la funcionalidad necesaria para excepciones y errores factorizar los casos de uso obtener los actores abstractos mediante generalización describir cada casos de uso a medida que se incluye en el modelo validar y verificar el modelo junto con los usuarios
49 Elaboración de los Casos de UsoEncontrar los casos de uso Su objetivo es establecer el alcance del sistema Se deben encontrar los casos de uso fundamentales Se deben describir los casos de uso en lenguaje natural Se debe realizar la verificación de los casos de uso Detallar los casos de uso Su objetivo es lograr una especificación de requisitos completa Se deben completar los pasos de los casos de uso en forma detallada Se deben extender los casos de uso Se debe realizar la validación de los casos de uso Refinar los casos de uso Su objetivo es documentar en detalle los casos de uso Se debe refinar la documentación textual Se deben revisar en detalle los requisitos no funcionales Se debe incorporar la documentación anexa, diagramas, etc.
50 Colaboración Es una sociedad de clases, interfaces y otros elementos que colaboran entre sí de forma sinérgica, proporcionando un comportamiento cooperativo mayor que el de la simple suma de los comportamientos de sus elementos Proporciona un nombre a los bloques de construcción de interacciones del sistema, incluyendo elementos estructurales y de comportamiento Adicionalmente, sirve principalmente para la realización de los casos de uso y las operaciones, aunque puede realizar cualquier clasificador
51 Modelado de negocio Es una técnica que permite modelar los procesos del negocio Apunta a facilitar la comunicación, comprender el negocio al que se le brindará una solución, conocer el valor que se agregará al negocio El modelado de negocios es un subconjunto de la reingeniería de procesos de negocios; no intenta cambiar nada sino tan sólo describir el negocio El modelo de negocios suele ser diferente del modelo de casos de uso, salvo en casos particulares como en los sistemas web
52 Beneficios del modelado de negocioPermite establecer el entorno en el que funcionará el sistema, los roles y responsabilidades de los involucrados y las cosas que se manipulan en el negocio Ayuda a obtener correctamente los requisitos del sistema y así reducir los costos por errores en ellos Provee un lenguaje común entre los usuarios y los miembros del equipo de desarrollo En definitiva, aporta mejoras en dos factores clave como lo son el costo y la calidad
53 Notación del UML para negocio
54 Herramientas del UML empleadasDiagramas de casos de uso: para representar los servicios que el negocio brinda a los actores externos Diagramas de actividades: para representar la lógica del negocio a nivel macro y sin bandas, que se incluye en el modelo de casos de uso; un grupo de diagramas de actividades explicarían cada una de las actividades utilizando bandas y probablemente entidades del negocio Diagramas de clases: para representar la estructura estática entre las entidades y trabajadores de negocio involucrados Diagramas de interacción: para representar los mensajes intercambiados entre los objetos de negocio
55 Doble enfoque empleadoPerspectiva externa: Diagramas de casos de uso Diagrama de actividades de alto nivel Perspectiva interna: Diagramas de actividades detallados Diagramas de clases Diagramas de interacción (secuencias)
56 Casos de prueba La calidad del producto software consiste en haber cumplido con los requisitos explícitos e implícitos de los usuarios de ese software La prueba fundamentada en los requisitos –prueba de aceptación– es un factor clave para la calidad del software Beneficios de los casos de prueba: Permite al equipo de prueba escribir los casos de prueba antes de que exista algún código Proveen un método claro y organizado para las pruebas Fundamentalmente, permiten controlar si lo realizado está de acuerdo con lo especificado Establecen una suerte de contrato con el cliente del producto software
57 Modelo de casos de pruebaUn caso de prueba es un conjunto elaborado de entradas de prueba, condiciones de ejecución, y resultados esperados (salidas), para verificar el cumplimiento de un requisito específico El modelo de casos de prueba debería contemplar tanto los requisitos funcionales como los no funcionales
58 Escenarios en un caso de usoLos escenarios de un caso de uso describen aquello que puede hacer un actor, utilizando el curso normal y los alternativos, desde el principio hasta el final No es válido probar flujos alternativos en forma aislada Curso normal Curso alternativo 1 Curso alternativo 2 Curso alternativo 3 Curso alternativo 4
59 Matriz con lotes de pruebaId. del caso de prueba Nombre del escenario Lotes de prueba Usuario válido Usuario creado Libro existente Lista de espera … Resultado CP1 E1 - Préstamo exitoso LP1 'juan' n/a 'UML - Booch et al.' Préstamo otorgado LP2 'pedro' 'RUP - Jacobson et al.' CP2 E2 - Usuario inexistente LP3 '1234' No se concreta el préstamo LP4 ' ' CP3
60 Palabras clave Requisito Requisito funcional Requisito no funcionalModelo de casos de uso Diagrama de casos de uso Caso de uso Escenario Actor Rol Comunicación con el caso de uso Script Iniciador Acción Colaborador Servicio Extensión de casos de uso Realización de casos de uso Curso normal Excepción Subflujo Paso condicional Realización de casos de uso Colaboración Modelo de negocios Actor de negocio Caso de uso de negocio Trabajador de negocio Entidad de negocio Unidad organizacional Colaboración de negocio Caso de prueba Modelo de casos de prueba Lote de prueba Curso alternativo
61 Diagrama de Clases Proviene de los diagramas de entidad-relación de Chen (‘70) Fueron extendidos con conceptos de AOO, como generalización y agregación (‘80) Incorporados por los autores orientados a las características de los objetos Permiten modelar la estructura estática de los sistemas Utilizados en el UML para la construcción de los metamodelos Aunque también fueron empleados por Booch, conservan el aspecto de la notación propuesta por Rumbaugh en OMT
62 Diagrama de Clases clase generalización navegabilidad asociaciónmultiplicidad asociación clase asociación navegabilidad
63 Objeto y clase Objeto: entidad existente en el mundo real que sedistingue del resto por sus características, comportamientos, relaciones y semántica Clase: abstracción de un conjunto de objetos que poseen características, comportamientos, relaciones y semántica semejantes
64 Miembros de una clase Atributos:[visibilidad] [/] nombre [multiplicidad] [:tipo] [= valor inicial] [{propiedades}] Operaciones: [visibilidad] nombre [(lista de parámetros)] [:tipo de respuesta] [{propiedades}] Visibilidad: existe definición a nivel público (+), privado (-) y protegido (#)
65 Objeto Objetos: Diagrama de objetos: instancia de un diagrama de clases
66 Compartimentos Alumno estereotipos compartimentos adicionales<
67 Clasificador Un clasificador es una abstracción que puede tener instancias El tipo de clasificadores más importante es la clase, que posee la notación de los clasificadores Otros clasificadores son: casos de uso, subsistemas, interfaces, asociaciones, componentes, nodos, etc. Los actores tienen la particularidad de poder ser clasificadores o instancias únicas No son clasificadores: paquetes, asociaciones de generalización, etc.
68 Nombres Pueden ser simples o calificados, para lo que se los acompaña con la cadena de paquetes separados por el operador de resolución de ámbito :: Se emplea notación “PascalCase” para los clasificadores, y notación “camelCase” para los objetos, atributos y operaciones
69 Asociación Asociación: abstracción de los vínculos existentesentre los objetos
70 Elementos de las asociacionesOrden: indica la cantidad clases asociadas (unaria, binaria, ternaria, n-aria) Nombre: es el de un clasificador Sentido del nombre: pueden haber diferentes nombres dependiendo del sentido; se elige uno y se indica con una flecha Extremos: en unarias y binarias son dos, en n-arias son n Multiplicidad: indica la cantidad de instancias asociadas Rol: papel que juegan los objetos en la asociación Navegabilidad: posibilidad de recorrer la asociación en el sentido indicado Cualificación: mecanismo de reducción de la multiplicidad
71 Asociación Ejemplo de asociaciones con navegabilidad,cualificación, multiplicidad, nombre, sentido del nombre y rol: Ejemplos de multiplicidades: 1..* ,3-7,25
72 Asociación Asociaciones n-arias (V n>2):no es posible incluir agregación o cualificación
73 Clase asociación Clase asociación: es una asociación que se modela como clase o viceversa; la clase asociación tiene multiplicidad 1..1 con la asociación
74 Eliminación de redundanciasAsociaciones redundantes: se deben revisar los bucles y analizar la semántica de las asociaciones, las multiplicidades y las restricciones, para así eliminar las asociaciones redundantes En el primer diagrama, la multiplicidad 1 de la asociación LugarDeOperación indica que la asociación LugarDeTrabajo es redundante, mientras que en el segundo diagrama no hay redundancia
75 Generalización Generalización: relación jerárquica entre clases en la que una clase hereda todos los miembros de otra más general (relación “tipo-de”)
76 Criterios para generalizares puede ser subclases intermedias en jerarquías “anchas” Recordar que las generalizaciones tienen como restricción el principio de sustitución de Liskov
77 Principio de sustitución de Liskov“Una clase B es subclase de A si y sólo si un objeto de B puede reemplazar a un objeto de A en cualquier circunstancia sin inconvenientes”
78 Al generalizar… Al definir una generalización se debe especificar si la superclase es abstracta o concreta; una clase abstracta no puede tener instancias propias, mientras que una concreta sí Se deben unir los tallos de las flechas de las subclases que correspondan a un mismo criterio de generalización Se debe verificar el principio de Liskov Se deben agregar las restricciones que correspondan Se debe tener en cuenta que se generalizan no sólo clases, sino también miembros, asociaciones y diagramas
79 Generalización múltiple¡Cuidado con los miembros superpuestos o contradictorios!
80 Clasificación Clasificación múltiple: permite que un mismo objetopertenezca a más de una clase Clasificación dinámica: brinda la posibilidad de que un objeto cambie de clase
81 Agregación Agregación: relación jerárquica entre objetos en la que uno es el todo y los otros son las partes Agregación simple: relación todo-parte, contenedor-contenido, conjunto-elemento Agregación de composición: agregación en la que las partes nacen y mueren con el todo
82 Dependencia y refinamientoDependencia: conexión semántica entre dos elemento de modelado Refinamiento: relación entre dos descripciones de la misma cosa, pero con diferente nivel de abstracción
83 Interfaz Interfaz: clase con declaración de operaciones, sinimplementación y sin atributos Ventana Windows Editor de textos Ventana
84 Construcción del diagramaPasos recomendados: elaborar una lista de clases candidatas a partir de los requisitos detectar clases con diferentes niveles de abstracción definir las clases y colocarles sus atributos y comportamientos realizar pruebas de clases elegir la clase más representativa y colocarla en el centro del modelo asociar una a una el resto de las clases determinar multiplicidad y condicionalidad incorporar clases asociativas eliminar bucles redundantes incorporar agregación y generalización verificar y validar el modelo contra los requisitos
85 Palabras clave Diagrama de clases Objeto Clase Atributo OperaciónVisibilidad Diagrama de objetos Compartimentos de una clase Asociación Orden de una asociación Multiplicidad Rol de un extremo Cualificación Navegabilidad Clase asociación Asociación redundante Generalización Principio de Liskov Generalización múltiple Clasificación múltiple Clasificación dinámica Agregación Composición Refinamiento Dependencia Interfaz Clase parametrizada
86 Modelado dinámico El UML prevé el modelado de los aspectosestructurales, dinámicos y de interacción Para el modelado dinámico están contemplados los diagramas de estados y los de actividades Estos últimos son un subconjunto de los diagramas de estados Los diagramas de actividades se usan para varios propósitos de modelado: desarrollo de diseño de sistemas estructurados, modelado de procesos de negocios, estructuras organizacionales, flujos de trabajo, etc.
87 Actividad Una actividad refleja el control y el flujo de datos deun proceso Las actividades organizan y especifican la participación de comportamientos subordinados, como subactividades o acciones Una actividad es una porción de comportamientos susceptible de ser dividida en otras actividades Una actividad es un proceso que se puede detener o interrumpir durante su desarrollo Una actividad es un estado de actividad
88 Acción Una acción es la mínima unidad de procesamiento,que no puede descomponerse, interrumpirse o detenerse Las actividades están compuestas por otras actividades o por acciones
89 Pseudoestados Debido a que conceptualmente un proceso debe tenerentrada y salida, es necesario contar con los pseudoestados que son casos excepcionales para, por ejemplo, poder dar inicio a un diagrama o finalizarlo
90 Manejo de eventos El evento “enviar” se utiliza paramodelar el disparo de un evento El evento “recibir” se utiliza para modelar la recepción de un evento El evento “recibir” también puede representar la recepción de un evento temporal, causado por el sólo paso del tiempo
91 Flujos múltiples Los flujos de un diagrama deactividad se pueden separar o volver a unir por medio de “barras de sincronización” horizontales o verticales Cuando dos caminos se separan como consecuencia del resultado de una condición, se emplea el elemento “decisión”
92 Región de expansión Se emplea para establecer actividades que afectan a un conjunto de instancias, como por ejemplo, la repetición para un conjunto de ítems de un pedido
93 Organización del diagramaLos mecanismos que se emplean para organizar los diagramas son las “calles” y las “particiones” La división que realizan es solamente lógica y depende de las necesidades de modelado del modelador Las calles pueden ser horizontales o verticales y se pueden combinar con las particiones Las calles son sólo gráficas y las particiones son elementos
94 Cambios de estado de objetosLos diagramas de actividades pueden indicar el cambio de estado de los objetos afectados por las diferentes actividades
95 Diagramas subordinadosLos diagramas de actividades normalmente se ubican en paquetes o subordinados a otros elementos de modelado (casos de uso, colaboraciones, etc.)
96 Palabras clave Diagrama de actividades Actividad Acción PseudoestadosFinal de flujo Evento enviar Evento recibir Evento temporal Barra de sincronización Decisión Calle Partición Flujo de objetos
97 Diagrama de paquetes Permite administrar la complejidad del sistema alsubdividirlo en porciones de menor tamaño Corresponde a las categorías del método de Booch Se pueden aplicar a diferentes elementos de modelado, no sólo a clases Permite establecer las dependencias entre paquetes (que no son de carácter transitivo) a fin de reducirlas También permite reducir los bucles de dependencias
98 Diagrama de paquetes
99 Importación y exportación
100 Generalización de paquetes
101 Elementos de extensión del UMLEl UML pretende ser expresivo y sencillo en su uso Para ser expresivo es necesario contar muchos elementos, pero para ser sencillo deberían existir pocos Los autores decidieron, en lugar de sobremodelar, submodelar y explicar con texto Así, es posible extender al UML en forma estándar con notas, estereotipos, restricciones y valores etiquetados
102 Nota Clase Para ampliar el tema visitar el sitio de Sparx SystemsConfrontar con miPaper.doc Revisar los atributos de esta clase
103 Estereotipo Estereotipos: extienden la semántica de loselementos del UML la idea proviene de Rebecca Wirfs-Brock, que incorporó el objeto «coordinador» Ivar Jacobson mejoró sustancialmente la idea con sus objetos de interfaz, entidad y control El UML prevé un conjunto de estereotipos estándares y la posibilidad de que el usuario incorpore los propios
104 Estereotipo Especificar: notación características que adiciona<
105 Valor etiquetado y restricciónrestricción en OCL {self.esposa.sexo = mujer and self.marido.sexo = hombre}
106 Restricción en asociacionesAsociaciones “xor”: Legajo Empresa Persona {xor} 0..1
107 Criterios para los nuevos elementosPasos recomendados: definir exactamente qué es lo que se pretende modelar asegurarse de que ese elemento no se encuentra previamente definido en el UML tratar de encontrar el elemento del UML semánticamente más cercano al que se quiere incorporar en caso de que ese elemento cercano exista, adornarlo para adaptarlo a las necesidades propias en caso de que ese elemento no exista, crearlo definir claramente el objetivo del nuevo elemento y documentar apropiadamente
108 Diagrama de secuenciasEs uno de los dos diagramas de interacción que propone el UML Describe la forma en que colaboran entre sí los objetos para llevar a cabo sus respectivas responsabilidades Permite ver cómo se suceden cronológicamente los mensajes entre las líneas de vida los objetos Proviene de los diagramas POSA de Buschmann Fueron utilizados por los tres autores del UML en sus respectivos métodos previos
109 Diagrama de secuencias
110 Diagrama de secuencias anidados
111 Diagrama de estados Describe los estados posibles en la vida de los objetos Permite observar cómo cambian de estado los objetos a medida que ocurren los eventos Cada diagrama se utiliza para representar el ciclo de vida de los objetos de una única clase Provienen de las cartas de estado de David Harel Los emplearon Rumbaugh en OMT, Booch en su libro de 1994 y Jacobson con la incorporación de una vasta notación
112 evento(param)[guardia]/acción^mensajeDiagrama de estados estado evento estado final estado inicial subestado “o” subestado “y” indicador histórico Estado1 Estado4 - variables de estado: + On Entry / action Do Action / actividad On Exit / accion Estado5 Estado6 Estado3 Estado2 evento(param)[guardia]/acción^mensaje
113 Diagrama de estados
114 Diagrama de comunicacionesAparece con la versión 2.0 del UML, reemplazando al diagrama de colaboraciones de las versiones anteriores No permite observar gráficamente la cronología de los mensajes, sino que se lo hace con números Destaca la organización y la conexión estática entre los objetos Si bien son diagramas semánticamente equivalentes, mientras el diagrama de secuencias pone énfasis en el tiempo, el de comunicaciones lo hace en el espacio
115 Diagrama de comunicaciones
116 Diagrama de estructura compuestaNuevo diagrama a partir de la versión 2.0 del UML Es un diagrama de estructura estática que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles Incluye partes internas, que son los roles que juegan los objetos al relacionarse, puertas mediante las cuales las partes interactúan entre sí o mediante las que las instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas
117 Diagrama de estructura compuestaLas clases y componentes se presentan con el detalle de sus partes Las interfaces y los puertos presentan la cara visible de las partes internas
118 Diagrama de estructura compuestaSe presentan las necesidades y la provisión de servicios, y la delegación a la parte interna Las colaboraciones presentan roles cooperando para proveer un servicio
119 Diagrama de revisión global de las interaccionesSe emplea para tener una vista global de las interacciones del sistema y de cómo es el curso del flujo de control Es una especialización del diagrama de actividades que posee interacciones Este diagrama se incorpora en la versión 2.0 del UML
120 Diagrama de revisión global de las interacciones
121 Diagrama de tiempos Se utilizan para mostrar las interacciones cuando el objetivo principal es destacar los cambios de estado de los objetos a partir de eventos que se suceden a lo largo del tiempo Puede emplearse para describir las interacciones de un único clasificador o de varios clasificadores Se utiliza para el modelado de sistemas embebidos o de tiempo real Es el cuarto diagrama de interacción y el cuarto que se incorpora como novedad en la versión 2.0 del UML
122 Diagrama de tiempos
123 Diagrama de componentesEste diagrama, junto al de despliegue, corresponde al grupo de herramientas de implementación del UML Un componente representa una parte lógica y reemplazable de un sistema Es importante que cada componente sea equivalente a un paquete; de esta manera, las dependencias entre componentes son las mismas que las existentes entre los paquetes La notación gráfica corresponde a los gradygramas
124 Diagrama de componentes
125 Diagrama de componentesExisten tres tipos de componentes: de compilación (código fuente) de linkeditado (archivos binarios, librerías estáticas) de ejecución (ejecutables, tablas de BD, librerías dinámicas) Los estereotipos básicos son: «file»: código fuente o datos «page»: página Web «document»: texto, imágenes «executable»: puede ejecutarse en un nodo «library»: librería estática o dinámica «table»: tabla de base de datos
126 Diagrama de artefactos
127 Diagrama de despliegueEs la segunda herramienta de implementación del UML Muestra las relaciones entre los componentes de hardware y software del sistema Permite observar dónde se encuentran físicamente los paquetes en el sistema La notación gráfica también proviene de Booch
128 Diagrama de desplieguenodo conexión
129 Diagrama de despliegue
130 Diagrama de despliegue
131 Palabras clave Paquete Dependencia Importación ExportaciónValor y referencia Nota Estereotipo Restricción Valor etiquetado Diagrama de secuencias Línea de vida Mensaje Activación Autodelegación Diagrama de tiempos Diagrama de revisión de la interacción Diagrama de comunicaciones Diagrama de estados Estado Evento Evento histórico Estado concurrente Componente Nodo
132 Recomendaciones para el modelado
133 Fuentes de clases - #1 Inicialmente se debe elaborar la lista de clases candidatas. Se llaman candidatas porque luego se deben verificar para determinar si pertenecen al dominio del problema. Son probables fuentes de clases: Sustantivos: no se debe caer en un análisis lexicográfico, aunque entre los sustantivos se suele encontrar una gran cantidad de clases Roles: por ejemplo, profesor, cliente, proveedor, médico, etc. Eventos de importancia: hechos que se producen en el dominio del problema y que deben ser recordados; por ejemplo, venta, préstamo, examen, despegue, etc.
134 Fuentes de clases - #2 Otras probables fuentes de clases:Clasificaciones: por ejemplo, marcas, modelos, tipos de cosas Colaboraciones: verificar si los objetos necesitan ayuda para cumplir con sus responsabilidades Documentos: revisar los conceptos y elementos contenidos en documentos (facturas, pedidos, etc.)
135 Definición de clases Todas las clases se deben definir indicando:Nombre: se debe dar un nombre adecuado, sencillo y descriptivo, en singular y empleando todos los adjetivos que sean necesarios Definición: se debe dar una definición coherente con el nombre de la clase y que indique explícitamente los criterios de inclusión y exclusión de sus instancias Atributos: se debe indicar una pequeña lista de los atributos más importantes o representativos Responsabilidades: se deben indicar las responsabilidades de los objetos de la clase en el modelo
136 Pruebas de clases - #1 Se debe realizar una prueba a cada una de las clases candidatas a fin de determinar si pertenecen al dominio del problema. No basta que una clase “supere” una prueba; debe cumplir con todas: Objetos: la clase debe poder tener instancias Comportamientos: la clase debe poseer al menos una operación (no importa si no posee atributos) Uniformidad: todos los objetos deben soportar todos los miembros de la clase Lista restringida: las instancias no deben reducirse a un subconjunto de los objetos posibles
137 Pruebas de clases - #2 Otras pruebas:Nombre: la clase debe describir con su nombre los criterios de inclusión y exclusión de sus objetos Adjetivos: si es necesario se deben utilizar adjetivos para el nombre de la clase Abstracción: se debe establecer el nivel de abstracción adecuado de la clase para evitar la “mutación” Tipos: se deben buscar “tipos de” objetos de cada clase y verificar si corresponde herencia Aplicar reglas de modelado: se debe seguir un conjunto de reglas que permitirá obtener un modelo correcto y flexible
138 Regla #1: nivel de abstracciónAlgunas clases pueden tener muchos niveles de abstracción: Regla: es imprescindible determinar cuál es el correcto Probablemente una o todas las clases deberían integrar el modelo
139 Regla #2: atributos como clasesRegla: todo atributo que pueda ser modelado como clase, DEBE ser modelado como clase
140 Regla #3: atributo “DE” claseRegla: los atributos pertenecen naturalmente a las clases que responden a la estructura “atributo DE clase”
141 Regla #4: “tipo de” Regla: los tipos de instancias que no poseen comportamientos diferentes se deben modelar como “tipos de”, caso contrario se debe emplear generalización (o posiblemente agregación en el diseño físico)
142 Regla #5: identificadoresRegla: no se deben incluir atributos identificadores, a menos que existan en la realidad. Algunos identificadores que existen en la realidad son: número de documento (id. de una persona), número de teléfono (id. de una línea telefónica), patente (id. de un auto), etc. Sólo se pueden tener identificadores no existentes en la realidad en los casos en que lo exija el cliente de la aplicación como requisito explícito (por ejemplo: “quiero tener un número de proveedor”)
143 Regla #6: clases asociativasRegla: se debe analizar cada asociación preguntando si es necesario incorporar responsabilidades o información adicional. En caso afirmativo, incorporar una nueva clase intermedia o asociativa para contener esas responsabilidades.
144 Regla #7: dividir el problemaRegla: en el caso en el que el modelado se debe realizar a partir de una especificación de requisitos extensa, es importante dividir el problema en partes y realizar el diagrama de clases para cada una de esas partes en forma independiente e incremental. Aquí es conveniente iniciar el diagrama a partir de la clase más representativa del dominio del problema Cuando se realizan diagramas de clases a partir de casos de uso, la división del problema ya está hecha por caso de uso (se debe realizar un diagrama de clases por cada caso de uso) y la elaboración incremental de cada diagrama se debe hacer basada en los pasos de los casos de uso. Aquí se inicia el diagrama con las clases que aparecen a medida que se avanza a lo largo del caso de uso
145 Regla # 8: asignar multiplicidadRegla: siempre se debe tomar un objeto de la clase de un extremo y preguntarse con cuántos objetos se relaciona en cada uno de los otros extremos, como mínimo y como máximo. Después se repite el procedimiento para cada extremo UN vendedor realiza 0..* ventas UNA venta es realizada por vendedores
146 Regla #9: multiplicidad “1”Regla: cuando el mínimo no sea cero (por ejemplo, 1..*) o cuando el máximo no sea muchos (por ejemplo, 0..1), se debe intentar extender la multiplicidad En el caso del mínimo se debe preguntar si existen casos especiales que exijan cero En el caso del máximo se debe preguntar si es necesario recordar la historia de las asociaciones
147 Regla #10: documentar asociacionesRegla: se deben colocar siempre el nombre de la asociación y las multiplicidades; caso contrario, el modelo no tiene sentido Es conveniente colocar el sentido del nombre de la asociación Es importante indicar los roles en las asociaciones unarias (ayudan a establecer la multiplicidad correcta) y en las asociaciones múltiples entre dos clases (ayudan a comprender mejor el modelo)
148 Patrón #1: transaccionesPara modelar transacciones de negocio, el modelo generalmente se presenta así:
149 Patrón #2: stock sin diferenciarAl modelar stock hay tres posibilidades de modelado; la primera es cuando no es necesario diferenciar un elemento del otro:
150 Patrón #3: stock por individuoLa segunda posibilidad de modelado de stock es cuando es necesario diferenciar unívocamente cada elemento:
151 Patrón #3: stock por loteLa tercera posibilidad de modelado de stock es cuando es necesario diferenciar los elementos por grupo de elementos:
152 Patrón #4: elemento y su usoEs fundamental distinguir entre la descripción de un elemento y el uso del elemento:
153 Patrón #5: atributos variablesEn muchas ocasiones es necesario modelar atributos variables:
154 Patrón #6: valores fijosEn algunas oportunidades, algunos atributos variables pueden requerir valores fijos:
155 Extensiones del UML: SysML
156 SysML El Lenguaje de Modelado de Sistemas es un lenguaje específico de dominio Es una extensión de UML que se concibió para aplicaciones de ingeniería Nació en 2001 como un proyecto open source y derivó en el SysML de OMG en 2006 Hay trece empresas (Lockheed Martin, Motorola, etc.), diez fabricantes de herramientas y una universidad tras el proyecto
157 Necesidad del SysML Necesidad de desarrollo de un lenguaje bien definido para procesos de ingeniería Necesidad de especificar sistemas complejos que incluyan componentes que no sean software Continuar extendiendo el UML en otras áreas específicas, tal como sucedió con las extensiones para desarrollo web, modelado de negocios, etc.
158 Lenguaje estándar de modeladoDiagrama de bloques con Diagrama de componentes símbolos aleatorios e con sintaxis bien definida indefinidos
159 Relación entre SysML y UMLSysML se basa en UML 2, es una extensión suya SysML UML 2 Extensiones de SysML para UML UML no requerido por SysML UML reutilizado por SysML
160 Mejora del SysML al UML SysML reduce las restricciones centradas en el software del UML Elimina diagramas innecesarios y agrega nuevos diagramas específicos
161 Diagramas de SysML
162 Diagramas del SysML vs. UMLDiagrama SysML Propósito Diagrama UML Diagrama de actividades Presenta el comportamiento del sistema como flujos de datos y de control Diagrama de definición de bloques Muestra las estructuras del sistema como componentes junto con sus propiedades, operaciones y relaciones Diagrama de clases Diagrama de bloques internos Presenta las estructuras internas de los componentes, incluyendo sus partes y conectores Diagrama de estructura de composición Diagrama de paquetes Muestra cómo se organiza el modelo en paquetes, vistas y puntos de vista Diagrama de paquietes Diagrama paramétrico Presenta las relaciones entre parámetros No existe
163 Diagramas del SysML vs. UMLDiagrama SysML Propósito Diagrama UML Diagrama de requerimientos Muestra el modelado visual de los requerimientos No existe Diagrama de secuencias Presenta el comportamiento del sistema como interacciones entre sus componentes Diagrama máquina de estados Presenta el comportamiento del sistema como secuencias de estados que sigue un componente en respuesta a eventos Diagrama de máquina de estados Diagrama de casos de uso Muestra los requerimientos funcionales como transacciones que son de interés para los usuarios del sistema
164 Diagrama de definición de bloques
165 Diagrama de requisitosMuestra los requisitos, las condiciones de satisfacción y la verificación Provee la capacidad de relacionar un requisito con otro y éstos con sus respectivos casos de prueba
166 Diagrama de requisitos
167 Diagrama paramétrico Se utiliza para expresar restricciones en los valores de los parámetros del sistema
168 Modelos eléctricos con UML
169 UML en el mercado eléctricoLas compañías eléctricas deben intercambiar modelos tanto interna como externamente Adicionalmente, es necesario modelar las relaciones entre los modelos eléctrico y de sistemas de software de soporte El UML pasa a ser la alternativa más importante a partir de sus características ya descritas Los modelos CIM IEC y IEC soportan respectivamente el intercambio de datos de sistemas eléctricos y de sistemas de software
170 Aporte de los modelos UMLSoporte de datos en múltiples formatos y posibilidad de independizarlos de la plataforma Aporte de un núcleo de información que garantiza la información necesaria para sistemas eléctricos más la posibilidad de extenderla para representaciones específicas Posibilidad de que los proveedores de herramientas puedan tomar el modelo y darle su formato específico independientemente de tecnologías o regulaciones
171 El modelo CIM El Common Information Model de la International Electrotechnical Commission es estándar mundial para la representación de sistemas eléctricos Describe los elementos necesarios para describir los componentes necesarios para las interfaces con sistemas de gestión de energía Es un modelo independiente de cualquier lenguaje, tecnología y formato de datos Si bien puede parecer complejo, simplifica enormemente la interoperabilidad entre aplicaciones de software
172 El modelo CIM El CIM está orientado a sistemas:de gestión y transmisión de energía (EMS y DMS) de planeación de la distribución/transmisión de gestión de bienes de trabajo de información del cliente de información geográfica de gestión de fallas de gestión de personal y cuadrillas “La electricidad fluye de la misma forma en cualquier parte del mundo, por lo tanto, podemos construir un modelo que todos podamos utilizar y del que todos podamos beneficiarnos” (Mackiewicz y Synder, 2008)
173 El modelo CIM: estado del arteActualmente se está trabajando sobre el CIM para modelos dinámicos El Electric Power Research Institute (EPRI) comenzó a trabajar en marzo de 2008 sobre este proyecto Las necesidades de estos modelos son: análisis de contingencia evaluación de contingencias que conducen a un evento catastrófico determinar los puntos donde la red necesita ser actualizada realizar simulaciones sobre modelos más complejos
174 Diagrama de paquetes del CIM
175 Los paquetes del CIM Core: es el paquete central al proveer los objetos principales (PowerSystem-Resource, ConductingEquipment) Domain: define los tipos de datos básicos que usan los atributos Topology: provee los objetos de conectividad entre equipos Meas (measurement): aporta los elementos para representar medidas en sistemas eléctricos Generation: permite modelar los diferentes tipos de generadores de energía
176 Los paquetes del CIM LoadModel: contiene los elementos que describen el consumo eléctrico Protection: aporta los elementos para modelar los dispositivos de protección y sus características EnergyScheduling: permite modelar el intercasmbio de electricidad entre compañías Financial: cubre aspectos legales y de facturación Reservation: incluye información para programación de generación de energía y transmisión
177 Los paquetes del CIM Outage: permite describir programas de planificación para la operación y mantenimiento de los sistemas eléctricos para la prevención y actuación ante apagones SCADA: contiene los elementos para el modelado de la supervisión y el control de la adquisición de datos Wires: contiene los equipos físicos que pueden formar parte de un sistema eléctrico de potencia
178 Estructura de clases del CIMDefiniciones comunes a cualquier clase del modelo Recursos, pudiendo ser un equipamiento o una unidad organizacional Equipamientos, tanto eléctrico como mecánico Equipamientos conductores de electricidad Interruptores Interruptores protegidos, operados por equipos de protección Sub tipos de interruptores protegidos, con atributos específicos
179 Asociaciones en el CIM Carga Línea Cortacircuito Terminal Nodo deconectividad
180 Asociaciones en el CIM
181 Circuito con objetos CIM
182 Transformador con objetos CIM
183 La alianza Gridwise Se trata de una alianza fundada en 2003, integrada por el Ministerio Americano de la Energía, el Pacific Northwest National Laboratory (PNNL) y las principales industrias del mundo (http://www.gridwiseac.org) El PNNL trabaja con los fabricantes de electrodomésticos para integrar en sus modelos un chip desarrollado por el laboratorio A su vez, las compañías de IT proporcionan la infraestructura necesaria para comunicar los equipos con la red de distribución de electricidad y con sus usuarios
184 Interoperabilidad en GridwiseCapa de interés del CIM Gridwise Architecture Council Interoperability (GWAC) Framework
185 El proyecto IntelligridEl proyecto IntelliGrid (antes conocido como el proyecto IECSA) se realiza bajo el patrocinio del EPRI (Electric Power Research Institute) Este proyecto tiene dos objetivos: la identificación de las funciones de los sistemas de energía para hoy y para el futuro, incluyendo conceptos de smart grids el desarrollo de la Arquitectura IntelliGrid que utilice estos requisitos funcionales, de configuración y de performance
186 La arquitectura IntelligridNecesidades del negocio (requisitos funcionales) Visión estratégica Enfoque táctico Estándares, tecnologías y mejores prácticas Metodología Intelligrid
187 La arquitectura Intelligrid
188 El proyecto IntelligridLos casos de uso del proyecto proveen un conjunto inicial de requisitos funcionales, de infraestructura y de comunicaciones de la aplicación Aportan una descripción funcional de la aplicación Describen los actores (dispositivos, personas, sistemas) necesarios para la interacción y la información que deben intercambiar entre ellos Dan una descripción paso a paso de lo que sucede y en qué orden sucede
189 El Smart Grid Maturity ModelThe SGMM es un modelo creado por el SEI de la universidad Carnegie Mellon University El modelo se desarrolló originalmente para organizaciones de energía eléctrica Provee un marco para entender el estado actual del despliegue de una red inteligente y las capacidades que provee una organización para incorporar estrategias y trabajos futuros para implementaciones de redes inteligentes
190 El Smart Grid Maturity ModelEl modelo consta de seis niveles de madurez, de 0 a 5 Evalúa ocho dominios: 1. estrategia, gestión, regulación 2. organización y estructura 3. operaciones de red 4. trabajo y gestión de activos 5. tecnología 6. cliente 7. integración de la cadena de valor 8. sociedad y ambiente
191 Metamodelo del SGMM
192 Modelado con Enterprise Architect
193 Enterprise Architect y el CIMEnterprise Architect es la herramienta de modelado UML más difundida en el mundo y probablemente la más completa y potente En 2008 se completó la migración de modelos del CIM desde diferentes herramientas Sparx Systems de Australia es miembro del UCAIug Solus S.A. es una de las compañías hermanas de Sparx Systems al producir y comercializar la versión en español de EA en el mundo UML 2 : The first UML tool to implement the UML 2 specification UML Profiles : Allow the modeling environment to be used in a domain specific way. XMI : Extensible Metadata Interchange: Open standard published by the OMG. Provides great flexibility and integration options for users that need to access the underlying model data
194 Migración de modelos a EAXML (eXtensible Markup Language) es un lenguaje de etiquetas de intercambio creado por el W3C XMI (XML Metadata Interchange) es una extensión al XML que se utiliza para migrar modelos entre diferentes herramientas Sparx Systems utilizó XMI para migrar los modelos del CIM a EA Es posible migrar modelos hacia EA prácticamente de todas las herramientas de modelado existentes UML 2 : The first UML tool to implement the UML 2 specification UML Profiles : Allow the modeling environment to be used in a domain specific way. XMI : Extensible Metadata Interchange: Open standard published by the OMG. Provides great flexibility and integration options for users that need to access the underlying model data
195 Migración de modelos a EAUna vez migrados, es posible asegurar la integridad y la disposición adecuada de los diagramas adecuadamente con las utilidades de EA
196 Extendiendo el CIM Se deben aprovechar los modelos del CIM y extenderlos con los modelos propios llamados “perfiles”, de modo de poder utilizar futuras actualizaciones del CIM Se debe mantener y potenciar la traza entre elementos de los modelos propios y del CIM, restringiendo asociaciones y multiplicidades Se pueden utilizar otras herramientas open source para explotar aún más el CIM: CIMTool (http://www.cimtool.org) CIMEA (http://www.cimea.org) CIMSpy (http://www.powerinfo.us/opensource/cimspy.html) CIMVian (http://uisol.com/cimvian --> clic en Information)
197 Extendiendo el CIM en EACopiar el modelo base de CIM o importar el XMI en EA Crear un paquete separado en EA para los elementos de la extensión Arrastrar y soltar los elementos estándar del CIM a los diagramas de la extensión Asociar los elemento del CIM con los de la extensión Mantener los mecanismos de seguimiento de traza
198 Agregando la extensión al modelo1. Crear una estructura de modelos, con sus respectivos diagramas, para modelar en ella la extensión
199 Agregando elementos del CIMSuperclase de Switch 2. Arrastrar y soltar el elemento del CIM en el diagrama de la extensión 3. No agregar atributos directamente aquí Atributos CIM de Switch
200 Agregando elementos propios4. Crear el nuevo elemento 5. Relacionar el nuevo elemento con el elemento CIM mediante generalización 6. Agregar los nuevos atributos en el nuevo elemento Nuestros cambios no impactan al CIM y los cambios en el CIM se heredan en nuestro modelo
201 Modelado con perfiles de EAEs posible aprovechar la potencia de EA para crear perfiles propios, con imágenes representativas de los elementos que deseamos utilizar en el modelado Así, los modelos serían más precisos y se potenciaría su semántica, haciéndolos más cercanos a quienes van dirigidos y más interdisciplinarios UML prevé la forma de “salirse del estándar en forma estándar”, de modo de mantener el formalismo de los modelos y puedan ser leídos por cualquier persona que conozca UML
202 Ejemplo de uso de perfiles de EAContador Contador serial Contador PLC Concentrador secundario 1..16 1 primario 1..* Red Plataforma de comunicaciones
203 Conclusiones
204 Conclusiones Las TIC son protagonistas fundamentales de nuestra realidad cotidiana La integración interdisciplinaria es una necesidad y mucho más aún entre el mundo de la electricidad y las TIC Además, el tendido eléctrico es una oportunidad inmejorable para esta integración Adicionalmente, la inteligencia de las smart grids proviene del aporte de las TIC en el campo de la electricidad
205 Conclusiones Para lograr una integración es necesario un lenguaje común La formalidad, la extensibilidad, la difusión y la enorme cantidad de herramientas de soporte existentes para el UML, lo imponen como el estándar más adecuado Las empresas más importantes del mundo, tanto en el campo de la electricidad como en el de las TIC, potencian esta selección
206 Conclusiones Estándares como el CIM son elementos fundamentales para esta integración: porque provee un amplio “diccionario” de datos porque evita que se deba “reinventar la rueda” porque aporta un lenguaje común porque es independiente de la tecnología y se mantiene vigente a pesar de sus permanentes cambios porque fue elaborado para dar soporte a un amplio rango de expertos de dominios y de áreas funcionales porque su independencia de la tecnología permite una mayor facilidad para su implementación y elaboración de herramientas
207 Conclusiones Extensiones del lenguaje, como el SysML, ajustan mucho más al UML como herramienta para las disciplinas vinculadas a la ingeniería El empleo de tecnologías como SOA y otros estándares como el XML y el XMI conforman un conjunto de soluciones de enorme utilidad y amplia aplicación Sólo resta que continúen y se potencien los esfuerzos para promover la interdisciplinariedad en todos los ámbitos: público, privado y académico
208 Muchas gracias por su atención Muchas gracias Colombia, como siempre