UML Taller 2 FPinciroli

El lenguaje comn de las Smart Grids: Unified Modeling Language
Fernando Pinciroli Julio de 2010

Solus S.A. San Martn 1351 piso 1 of. 4 Mendoza +54 261 4294115 http://www.solus.com.ar
Introduccin
Marco conceptual de smart grids
Distancia en la integracin
No hay estndares; la integracin es propia
Hay interfaces para transformar
Parte A
Existe un modelo comn
Parte B
Existe un modelo definido plug & play
Contenido de la presentacin
1. 2. 3. 4. 5. 6. Introduccin al UML Diagramas del UML Extensiones del UML: SysML Modelos elctricos con UML Modelado con Enterprise Architect Conclusiones
Introduccin al UML
Evolucin del modelado

50 60 70 80 90
Orientacin a procesos
Orientacin a objetos
Orient. a datos
Evolucin de la OO
1980 1985 1990
Caractersticas
1995
2000
Comportamientos
UML
El camino hacia la unificacin

En 1994 Grady Booch manifiesta la necesidad de unificar criterios James Rumbaugh se une a Booch en octubre de ese ao Ambos elaboran la versin 0.8 del Unified Method En 1995 Ivar Jacobson completa el tro de amigos y cambia el enfoque: nace el UML
El camino hacia la estandarizacin

Se elabora la versin 0.9 del Unified Modeling Language Durante 1996 se realizan sucesivas modificaciones en base a aportes de muchas otras personas (v. 0.91 y 1.0) Se realiza la versin 1.1 en conjunto con otras importantes empresas, que es presentada al OMG El OMG adopta al UML versin 1.1 como estndar a fines de 1997
Mtodo vs. lenguaje de modelado

Un mtodo es Una descripcin de los pasos que se deben seguir indicando el orden y las tcnicas y herramientas que se deben emplear en cada paso, para lograr un objetivo. Un conjunto de tcnicas, herramientas y tareas que, de acuerdo a un enfoque metodolgico, se aplican para la resolucin de un problema.
Mtodo vs. lenguaje de modelado

Un lenguaje es un conjunto de seales que dan a entender una cosa Un lenguaje posee elementos, reglas sintcticas para combinarlos y una semntica que depende del contexto Un lenguaje de modelado se emplea para expresar ideas por medio de modelos Un modelo es el cuerpo de informacin recabado acerca de un sistema con el fin de estudiarlo
Objetivos del UML
2.2
Establecer un lenguaje visual de modelado, expresivo y sencillo en su uso Mantener una independencia de los procesos de modelado y de los lenguajes de programacin Establecer bases formales Integrar las mejores prcticas Imponer un estndar mundial
Modelos y diagramas del UML

Modelado de requerimientos Modelado de la estructura
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. de revisin de interacciones
Modelado de la interaccin
Modelado del comportamiento Herramientas de diseo Organizacin del modelo
Diagrama de estados Diagrama de actividades Diagrama de componentes Diagrama de despliegue Diagrama de paquetes
Del UML 1.5 al UML 2.0

Diagramas del UML 1.5
Casos de uso Clases Objetos Secuencias Colaboraciones Estados Actividades Componentes Despliegue Paquetes
Diagramas del UML 2.0

Casos de uso Clases Objetos Estructura compuesta Comunicaciones Tiempos Revisin de interacciones Secuencias Estados Actividades Componentes Despliegue Paquetes
Arquitectura de los modelos

Vista de diseo Vista de casos de uso Vista de procesos Vista de despliegue Vista de implementacin
Palabras clave
Modelo Orientacin a procesos Orientacin a datos Orientacin a objetos UML Proceso de desarrollo Lenguaje de modelado Mtodo Metodologa Arquitectura 4+1 Modelado de requisitos Modelado de la estructura Modelado de la interaccin 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 revisin de las interacciones Diagrama de estados Diagrama de componentes Diagrama de despliegue Diagrama de paquetes
Diagramas del UML
Modelado de requisitos
En los primeros estadios de la programacin, las aplicaciones se construan a partir de los requisitos prcticamente en lenguaje natural Con el advenimiento de los mtodos de anlisis, se supona que los requisitos estaban completamente definidos antes del modelado Con los mtodos orientados a objetos comienzan a aparecer tcnicas de modelado de requisitos, basados en el empleo de escenarios Durante la dcada de los 90 comienza a cobrar protagonismo la disciplina de ingeniera de requisitos
Diagrama de casos de uso

Introducido formalmente por Ivar Jacobson Aceptado por la comunidad usuaria de TOO y por muchos metodologistas De empleo en la etapa de relevamiento para captar los requerimientos de los usuarios De fcil comprensin por parte de los usuarios de los sistemas Herramienta que precisa otras complementarias para ser utilizada en procesos de modelado OO
Empleo de los casos de uso

Instrumentos para la captura de los requisitos Proveen la descripcin funcional del sistema Facilitan la recoleccin de los requisitos no funcionales Establecen el lmite y el alcance del sistema Son un medio para la comunicacin con interlocutores diferentes Permiten expresar tanto la vista de negocios como la de software

Proveen mecanismos de modelado de sistema heredados o para procesos de reingeniera Son la principal fuente de deteccin de objetos Facilitan el diseo y la organizacin de las interfaces Son la base para la deteccin de la interaccin entre los objetos y de sus responsabilidades Son el medio para la estimacin y el dimensionamiento de un proyecto

Son la base para las pruebas de aceptacin y de integracin Definen los casos de prueba Son un medio para la verificacin y validacin de requisitos Son la base para el desarrollo incremental Facilitan los mecanismos de trazabilidad pre y post especificacin de requisitos Son la base para la administracin de requisitos

Proveen los principales elementos para la documentacin del sistema Constituyen una de las principales herramientas para el control de los proyectos Facilitan la asignacin de recursos y la organizacin del equipo de desarrollo Permiten organizar el proceso de ingeniera de requisitos Proveen mecanismos para trabajar en el nivel de abstraccin que sea necesario

actor caso de uso
Modelo de casos de uso

Funcionalidad completa del sistema desde la perspectiva de los actores que interactan 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 descripcin centrada en la vista de los actores ms que en los procesos en s Actores que interactan con el sistema: los casos de uso describen principalmente la interaccin de los actores con el sistema, pero tambin de lo que se realiza dentro del sistema para responder a los actores
Caso de uso
Un caso de uso es una porcin de la funcionalidad de un sistema descripta en trminos de las interacciones de un actor con el sistema, con la finalidad de obtener un resultado de valor La funcionalidad se divide en funcin de los resultados de valor esperados desde la perspectiva del usuario que interacta 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
Actor
Toda persona, dispositivo, sistema organizacin o cosa que interacta con el sistema con el fin de obtener un resultado de valor Persona, dispositivo, sistema, organizacin o cosa: en definitiva, todo lo que interacte con el sistema Interacta 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 interaccin no es para realizar un proceso cualquiera, sino uno que permita alcanzar un objetivo o resultado de valor
Rol
Un rol es el papel que juega un actor en el momento de interactuar con el sistema Una persona, dispositivo, sistema, organizacin 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
Descripcin de los casos de uso

Empleo 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
Modelado de asociaciones
Entre actores y casos de uso: asociacin comn con semntica de comunicacin Entre actores: generalizacin Entre casos de uso: dependencias (con semnticas de extensin e inclusin) y generalizacin
Estrategia de modelado
Funcionalidad deseada Errores Excepciones
Camino base Funcionalidad no deseada
Extensin e inclusin
Extensin e inclusin
extiende (extend) se emplea para describir una funcionalidad 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 generalizacin entre actores
Extensin de casos de uso

Caso de Uso base 1. Paso del curso normal 2. Paso del curso normal 3. Paso del curso normal SI [condicin] funcionalidad excepcional 4. Paso del curso normal 5. Paso del curso normal 6. Paso del curso normal 7. Paso del curso normal 8. Paso del curso normal 9. Paso del curso normal
Caso de Uso excepcional 1. 2. 3. 4. 5. 6. 7. 8. Paso del curso normal Paso del curso normal Paso del curso normal Paso del curso normal Paso del curso normal Paso del curso normal Paso del curso normal Paso del curso normal
Inclusin de casos de uso

Caso de Uso base 1 1. 2. 3. 4. 5. 6. 7. 8. 9. Paso del curso normal Paso del curso normal Paso del curso normal Caso de Uso base 2 Paso comn Paso comn 1. Paso del curso normal Paso del curso normal 2. Paso del curso normal Paso del curso normal 3. Paso del curso normal Paso del curso normal 4. Paso del curso normal Paso del curso normal 5. Paso del curso normal 4. Paso comn 5. Paso comn 6. Paso del curso normal Caso de Uso comn 1. Paso comn 2. Paso comn
Construccin de los diagramas

Pasos recomendados: elaborar una lista de actores y definir sus roles elegir el actor ms 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 generalizacin describir cada casos de uso a medida que se incluye en el modelo validar y verificar el modelo junto con los usuarios
Elaboracin de los Casos de Uso

Encontrar 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 verificacin de los casos de uso Detallar los casos de uso Su objetivo es lograr una especificacin 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 validacin de los casos de uso Refinar los casos de uso Su objetivo es documentar en detalle los casos de uso Se debe refinar la documentacin textual Se deben revisar en detalle los requisitos no funcionales Se debe incorporar la documentacin anexa, diagramas, etc.
Modelado de negocio
Es una tcnica que permite modelar los procesos del negocio Apunta a facilitar la comunicacin, comprender el negocio al que se le brindar una solucin, conocer el valor que se agregar al negocio El modelado de negocios es un subconjunto de la reingeniera de procesos de negocios; no intenta cambiar nada sino tan slo 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
Beneficios del modelado de negocio

Permite 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, a reducir los costos por errores en los requisitos Provee un lenguaje comn 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
Notacin del UML para negocio
Herramientas del UML empleadas

Diagramas de casos de uso: para representar los servicios que el negocio brinda a los actores externos Diagramas de actividades: para representar la lgica del negocio a nivel macro y sin bandas, que se incluye en el modelo de casos de uso; un grupo de diagramas de actividades explicaran cada una de las actividades utilizando bandas y probablemente entidades del negocio Diagramas de clases: para representar la estructura esttica entre las entidades y trabajadores de negocio involucrados Diagramas de interaccin: para representar los mensajes intercambiados entre los objetos de negocio
Doble enfoque empleado

Perspectiva externa: 9 Diagramas de casos de uso 9 Diagrama de actividades de alto nivel Perspectiva interna: 9 Diagramas de actividades detallados 9 Diagramas de clases 9 Diagramas de interaccin (secuencias)
Casos de prueba
La calidad del producto software consiste en haber cumplido con los requisitos explcitos e implcitos de los usuarios de ese software La prueba fundamentada en los requisitos prueba de aceptacin 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 algn cdigo Proveen un mtodo 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
Modelo de casos de prueba

Un caso de prueba es un conjunto elaborado de entradas de prueba, condiciones de ejecucin, y resultados esperados (salidas), para verificar el cumplimiento de un requisito especfico El modelo de casos de prueba debera contemplar tanto los requisitos funcionales como los no funcionales
Escenarios en un caso de uso

Los 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 vlido probar flujos alternativos en forma aislada
Curso normal Curso alternativo 3 Curso alternativo 4 Curso alternativo 1
Curso alternativo 2
Matriz con lotes de prueba

Id. del caso de prueba Nombre del escenario Lotes de prueba
LP1 CP1 E1 Prstamo exitoso
Usuario vlido
'juan'
Usuario creado
n/a
Libro existente
'UML Booch et al.' 'RUP Jacobson et al.' n/a
Lista de espera
n/a
Resultado
Prstamo otorgado Prstamo otorgado No se concreta el prstamo
LP2
'pedro'
n/a
n/a
LP3
'1234'
n/a
n/a
CP2
E2 - Usuario inexistente
LP4
' '
n/a
n/a
n/a
No se concreta el prstamo
CP3
Palabras clave
Requisito Requisito funcional Requisito no funcional Modelo de casos de uso Diagrama de casos de uso Caso de uso Escenario Actor Rol Comunicacin con el caso de uso Script Iniciador Accin Colaborador Servicio Extensin de casos de uso Realizacin de casos de uso Curso normal Excepcin Subflujo Paso condicional Realizacin de casos de uso Colaboracin Modelo de negocios Actor de negocio Caso de uso de negocio Trabajador de negocio Entidad de negocio Unidad organizacional Colaboracin de negocio Caso de prueba Modelo de casos de prueba Lote de prueba Curso alternativo
Diagrama de Clases
Proviene de los diagramas de entidad-relacin de Chen (70) Fueron extendidos con conceptos de AOO, como generalizacin y agregacin (80) Incorporados por los autores orientados a las caractersticas de los objetos Permiten modelar la estructura esttica de los sistemas Utilizados en el UML para la construccin de los metamodelos Aunque tambin fueron empleados por Booch, conservan el aspecto de la notacin propuesta por Rumbaugh en OMT
Diagrama de Clases
clase generalizacin
asociacin clase asociacin
navegabilidad
multiplicidad
Objetos y clases
Objeto: entidad existente en el mundo real que se distingue del resto por sus caractersticas, comportamientos, relaciones y semntica Clase: abstraccin de un conjunto de objetos que poseen caractersticas, comportamientos, relaciones y semntica semejantes
Miembros de una clase
Atributos: [visibilidad] [/] nombre [multiplicidad] [:tipo] [= valor inicial] [{propiedades}] Operaciones: [visibilidad] nombre [(lista de parmetros)] [:tipo de respuesta] [{propiedades}] Visibilidad: existe definicin a nivel pblico (+), privado (-) y protegido (#)
Objetos
Objetos:
Diagrama de objetos: instancia de un diagrama de clases
Compartimentos
Alumno
<<constructor>> nuevoAlumno( ) nuevoAlumno(Registro as int) <<proceso>> calcularPromedio( ) ... <<consulta>> puedeRendir( ) puedeObtenerPrestamos( ) ...
estereotipos
compartimentos adicionales
Responsabilidades -- establecer si cumpli con todos los requisitos para rendir materias -- establecer si est en condiciones de obtener prstamos de material de biblioteca
Diferente nivel de abstraccin

Algunas clases pueden tener diferentes niveles de abstraccin:
Es imprescindible distinguirlos y determinar cul es el correcto:
Probablemente una o todas las clases deberan integrar el modelo

Asociaciones
Asociacin: abstraccin de los vnculos existentes entre los objetos
Elementos de las asociaciones

Orden: 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 asociacin Navegabilidad: posibilidad de recorrer la asociacin en el sentido indicado Cualificacin: mecanismo de reduccin de la multiplicidad
Asociaciones
Ejemplo de asociaciones con navegabilidad, cualificacin, multiplicidad, nombre, sentido del nombre y rol:
Ejemplos de multiplicidades: 1..*
2..4
1,3-7,25
Asociaciones
Asociaciones n-arias (V n>2):
no es posible incluir agregacin o cualificacin
Clase asociacin
Clase asociacin: es una asociacin que se modela como clase o viceversa Importante: la clase asociacin tiene multiplicidad 1..1 con la asociacin
Eliminacin de redundancias
Asociaciones redundantes: se deben revisar los bucles y analizar la semntica de las asociaciones, las multiplicidades y las restricciones, para as eliminar las asociaciones redundantes En el primer diagrama, la multiplicidad 1 de la asociacin LugarDeOperacin indica que la asociacin LugarDeTrabajo es redundante, mientras que en el segundo diagrama no hay redundancia
Generalizacin
Generalizacin: relacin jerrquica entre clases en la que una clase hereda todos los miembros de otra ms general (relacin tipo-de)
objPrestador.crear( ) objPrestador.apellido = Prez
Criterios para generalizar
es
puede ser
subclases intermedias en jerarquas anchas
Recordar que las generalizaciones tienen como restriccin el principio de sustitucin de Liskov
Principio de sustitucin de Liskov

Una clase B es subclase de A si y slo si un objeto de B puede reemplazar a un objeto de A en cualquier circunstancia sin inconvenientes
Generalizacin mltiple
Cuidado con los miembros superpuestos o contradictorios!
Clasificacin
Clasificacin mltiple: permite que un mismo objeto pertenezca a ms de una clase Clasificacin dinmica: brinda la posibilidad de que un objeto cambie de clase
Agregacin
Agregacin: relacin jerrquica entre objetos en la que uno es el todo y los otros son las partes Agregacin simple: relacin todo-parte, contenedorcontenido, conjunto-elemento Agregacin de composicin: agregacin en la que las partes nacen y mueren con el todo
Dependencia y refinamiento
Dependencia: conexin semntica entre dos elemento de modelado
Refinamiento: relacin entre dos descripciones de la misma cosa, pero con diferente nivel de abstraccin
Interfaz
Interfaz: clase con declaracin de operaciones, sin implementacin y sin atributos
Editor de textos
Ventana
Ventana Windows
Construccin del diagrama

Pasos recomendados: elaborar una lista de clases candidatas a partir de los requisitos detectar clases con diferentes niveles de abstraccin definir las clases y colocarles sus atributos y comportamientos realizar pruebas de clases elegir la clase ms 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 agregacin y generalizacin verificar y validar el modelo contra los requisitos
Palabras clave
Diagrama de clases Objeto Clase Atributo Operacin Visibilidad Diagrama de objetos Compartimentos de una clase Asociacin Orden de una asociacin Multiplicidad Rol de un extremo Cualificacin Navegabilidad Clase asociacin Asociacin redundante Generalizacin Principio de Liskov Generalizacin mltiple Clasificacin mltiple Clasificacin dinmica Agregacin Composicin Refinamiento Dependencia Interfaz Clase parametrizada
Modelado dinmico
El UML prev el modelado de los aspectos estructurales, dinmicos y de interaccin Para el modelado dinmico estn 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 propsitos de modelado: desarrollo de diseo de sistemas estructurados, modelado de procesos de negocios, estructuras organizacionales, flujos de trabajo, etc.
Actividad
Una actividad refleja el control y el flujo de datos de un proceso Las actividades organizan y especifican la participacin de comportamientos subordinados, como subactividades o acciones Una actividad es una porcin 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
Accin
Una accin es la mnima unidad de procesamiento, que no puede descomponerse, interrumpirse o detenerse Las actividades estn compuestas por otras actividades o por acciones
Pseudoestados
Debido a que conceptualmente un proceso debe tener entrada y salida, es necesario contar con los pseudoestados que son casos excepcionales para, por ejemplo, poder dar inicio a un diagrama o finalizarlo
Manejo de eventos
El evento enviar se utiliza para modelar el disparo de un evento El evento recibir se utiliza para modelar la recepcin de un evento El evento recibir tambin puede representar la recepcin de un evento temporal, causado por el slo paso del tiempo
Flujos mltiples
Los flujos de un diagrama de actividad se pueden separar o volver a unir por medio de barras de sincronizacin horizontales o verticales
Cuando dos caminos se separan como consecuencia del resultado de una condicin, se emplea el elemento decisin
Organizacin del diagrama

Los mecanismos que se emplean para organizar los diagramas son las calles y las particiones La divisin que realizan es solamente lgica 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 slo grficas y las particiones son elementos
Cambios de estado de objetos

Los diagramas de actividades pueden indicar el cambio de estado de los objetos afectados por las diferentes actividades
Diagramas subordinados
Los diagramas de actividades normalmente se ubican en paquetes o subordinados a otros elementos de modelado (casos de uso, colaboraciones, etc.)
Palabras clave
Diagrama de actividades Actividad Accin Pseudoestados Final de flujo Evento enviar Evento recibir Evento temporal Barra de sincronizacin Decisin Calle Particin Flujo de objetos
Diagrama de paquetes
Permite administrar la complejidad del sistema al subdividirlo en porciones de menor tamao Corresponde a las categoras del mtodo de Booch Se pueden aplicar a diferentes elementos de modelado, no slo a clases Permite establecer las dependencias entre paquetes (que no son de carcter transitivo) a fin de reducirlas Tambin permite reducir los bucles de dependencias
Diagrama de paquetes
Importacin y exportacin
Generalizacin de paquetes
Elementos de extensin del UML

El UML pretende ser expresivo y sencillo en su uso Para ser expresivo es necesario contar muchos elementos, pero para ser sencillo deberan existir pocos Los autores decidieron, en lugar de sobremodelar, submodelar y explicar con texto As, es posible extender al UML en forma estndar con notas, estereotipos, restricciones y valores etiquetados
Nota
Nota
Para ampliar el tema visitar el sitio de Sparx Systems
Clase
Confrontar con miPaper.doc Revisar los atributos de esta clase
Estereotipo
Estereotipos: extienden la semntica de los elementos 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 estndares y la posibilidad de que el usuario incorpore los propios
Estereotipo
Estereotipo
<<empleado>> Administrativo <<empleado>> Administrativo Administrativo
Especificar: notacin caractersticas que adiciona semntica particular (con restricciones en lenguaje natural u OCL)
Valor etiquetado y restriccin

Valores etiquetados y restricciones
valor etiquetado
{self.esposa.sexo = mujer and self.marido.sexo = hombre}
restriccin en OCL
Restriccin en asociaciones
Asociaciones o:
Criterios para los nuevos elementos

Pasos 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 semnticamente ms 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
Diagrama de secuencias
Es uno de los dos diagramas de interaccin que propone el UML Describe la forma en que colaboran entre s los objetos para llevar a cabo sus respectivas responsabilidades Permite ver cmo se suceden cronolgicamente los mensajes entre las lneas de vida los objetos Proviene de los diagramas POSA de Buschmann Fueron utilizados por los tres autores del UML en sus respectivos mtodos previos
Diagrama de secuencias
objeto 1 a {b-a>0} b objeto 2 objeto 3 objeto 4
inicio de un mtodo etiquetas
[obj3 free] oper(param)
activacin
retorno guardia destruccin de un objeto auto-delegacin

Diagrama de estructura compuesta

Nuevo diagrama a partir de la versin 2.0 del UML Es un diagrama de estructura esttica 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 interactan entre s o mediante las que las instancias de la clase interactan con las partes y con el mundo exterior, y conectores entre partes o puertas
Diagrama de comunicaciones
Aparece con la versin 2.0 del UML, reemplazando al diagrama de colaboraciones de las versiones anteriores No permite observar grficamente la cronologa de los mensajes, sino que se lo hace con nmeros Destaca la conexin esttica entre los objetos Mientras el diagrama de secuencias pone nfasis en el tiempo, el de colaboracin lo hace en el espacio
Diagrama de revisin de interacciones
Se emplea para tener una vista global de las interacciones del sistema y de cmo es el curso del flujo de control Es una especializacin del diagrama de actividades que posee interacciones Este diagrama se incorpora en la versin 2.0 del UML
Diagrama de tiempos
Se utilizan para mostrar las interacciones cuando el objetivo principal es destacar los cambios en funcin del tiempo transcurrido Puede emplearse para describir las interacciones de un nico clasificador o de varios clasificadores Se utiliza para mostrar los cambios de estado de un elemento estructural Es el cuarto diagrama de interaccin y el cuarto que se incorpora como novedad en la versin 2.0 del UML
Diagrama de estados
Describe los estados posibles en la vida de los objetos Permite observar cmo 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 incorporacin de una vasta notacin
Diagrama de estados
subestado o
Estado1 Estado5 Estado4 + + + variables de estado: On Entry / action Do Action / actividad On Exit / accion Estado3
subestado y indicador histrico
Estado6
evento(param)[guardia]/accin^mensaje
estado inicial estado
Estado2
estado final evento
Diagrama de estados
Diagrama de componentes
Este diagrama, junto al de despliegue, corresponde al grupo de herramientas de implementacin del UML Representa mdulos fsicos de cdigo Es importante que cada componente sea equivalente a un paquete De esta manera, las dependencias entre componentes con las mismas que las existentes entre los paquetes La notacin grfica corresponde a los gradygramas
dependencia componente
Existen tres tipos de componentes:
de compilacin (cdigo fuente) de linkeditado (archivos binarios, libreras estticas) de ejecucin (ejecutables, tablas de BD, libreras dinmicas)
Los estereotipos bsicos son:

file: cdigo fuente o datos page: pgina Web document: texto, imgenes executable: puede ejecutarse en un nodo library: librera esttica o dinmica table: tabla de base de datos
Diagrama de despliegue
Es la segunda herramienta de implementacin del UML Muestra las relaciones entre los componentes de hardware y software del sistema Permite observar dnde se encuentran fsicamente los paquetes en el sistema La notacin grfica tambin proviene de Booch
conexin nodo
Palabras clave
Paquete Dependencia Importacin Exportacin Valor y referencia Nota Estereotipo Restriccin Valor etiquetado Diagrama de secuencias Lnea de vida Mensaje Activacin Autodelegacin Diagrama de tiempos Diagrama de revisin de la interaccin Diagrama de comunicaciones Diagrama de estados Estado Evento Evento histrico Estado concurrente Componente Nodo
Extensiones del UML: SysML
SysML
El Lenguaje de Modelado de Sistemas es un lenguaje especfico de dominio Es una extensin de UML que se concibi para aplicaciones de ingeniera 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
Necesidad del SysML

Necesidad de desarrollo de un lenguaje bien definido para procesos de ingeniera Necesidad de especificar sistemas complejos que incluyan componentes que no sean software Continuar extendiendo el UML en otras reas especficas, tal como sucedi con las extensiones para desarrollo web, modelado de negocios, etc.
Lenguaje estndar de modelado
Diagrama de bloques con smbolos aleatorios e indefinidos
Diagrama de componentes con sintaxis bien definida
Relacin entre SysML y UML

SysML se basa en UML 2, es una extensin suya
Extensiones de SysML para UML
SysML UML 2
UML no requerido por SysML
UML reutilizado por SysML
Mejora del SysML al UML

SysML reduce las restricciones centradas en el software del UML Elimina diagramas innecesarios y agrega nuevos diagramas especficos
Diagramas de SysML
Diagramas del SysML vs. UML

Diagrama SysML Diagrama de actividades Propsito Presenta el comportamiento del sistema como flujos de datos y de control Muestra las estructuras del sistema como componentes junto con sus propiedades, operaciones y relaciones Presenta las estructuras internas de los componentes, incluyendo sus partes y conectores Muestra cmo se organiza el modelo en paquetes, vistas y puntos de vista Presenta las relaciones entre parmetros Muestra el modelado visual de los requerimientos Diagrama UML Diagrama de actividades
Diagrama de definicin de bloques Diagrama de bloques internos
Diagrama de clases Diagrama de estructura de composicin
Diagrama de paquetes Diagrama paramtrico Diagrama de requerimientos
Diagrama de paquietes No existe No existe
Diagramas del SysML vs. UML

Diagrama SysML Diagrama de secuencias Propsito Presenta el comportamiento del sistema como interacciones entre sus componentes Presenta el comportamiento del sistema como secuencias de estados que sigue un componente en respuesta a eventos Muestra los requerimientos funcionales como transacciones que son de inters para los usuarios del sistema Diagrama UML Diagrama de secuencias
Diagrama mquina de estados
Diagrama de mquina de estados
Diagrama de definicin de bloques
Diagrama de requerimientos
Muestra los requerimientos, las condiciones de satisfaccin y la verificacin Provee la capacidad de relacionar un requerimiento con otro y stos con sus respectivos casos de prueba
Diagrama de requerimientos
Diagrama paramtrico
Se utiliza para expresar restricciones en los valores de los parmetros del sistema
Modelos elctricos con UML
UML en el mercado elctrico

Las compaas elctricas deben intercambiar modelos tanto interna como externamente Adicionalmente, es necesario modelar las relaciones entre los modelos elctrico y de sistemas de software de soporte El UML pasa a ser la alternativa ms importante a partir de sus caractersticas ya descritas Los modelos CIM 61970-301 and 61968-11 soportan respectivamente el intercambio de datos de sistemas elctricos y de sistemas de software
Aporte de los modelos UML

Soporte de datos en mltiples formatos y posibilidad de independizarlos de la plataforma Aporte de un ncleo de informacin que garantiza la informacin necesaria para sistemas elctricos ms la posibilidad de extenderla para representaciones especficas Posibilidad de que los proveedores de herramientas puedan tomar el modelo y darle su formato especfico independientemente de tecnologas o regulaciones
El modelo CIM
El Common Information Model de la International Electrotechnical Commission es estndar mundial para la representacin de sistemas elctricos Describe los elementos necesarios para describir los componentes necesarios para las interfaces con sistemas de gestin de energa Es un modelo independiente de cualquier lenguaje, tecnologa y formato de datos Si bien puede parecer complejo, simplifica enormemente la interoperabilidad entre aplicaciones de software
El modelo CIM
El CIM est orientado a sistemas: de gestin y transmisin de energa (EMS y DMS) de planeacin de la distribucin/transmisin de gestin de bienes de trabajo de informacin del cliente de informacin geogrfica de gestin de fallas de gestin 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)
El modelo CIM: estado del arte

Actualmente se est trabajando sobre el CIM para modelos dinmicos El Electric Power Research Institute (EPRI) comenz a trabajar en marzo de 2008 sobre este proyecto Las necesidades de estos modelos son: anlisis de contingencia evaluacin de contingencias que conducen a un evento catastrfico determinar los puntos donde la red necesita ser actualizada realizar simulaciones sobre modelos ms complejos
Diagrama de paquetes del CIM
Estructura de clases del CIM
Asociaciones en el CIM
Carga Terminal
Nodo de conectividad
Nodo de Cortacircuito conectividad
Lnea
Asociaciones en el CIM
Circuito con objetos CIM
Transformador con objetos CIM
El proyecto Intelligrid
El 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 identificacin de las funciones de los sistemas de energa para hoy y para el futuro, incluyendo conceptos de smart grids el desarrollo de la Arquitectura IntelliGrid que utilice estos requisitos funcionales, de configuracin y de performance
La arquitectura Intelligrid
Necesidades del negocio

(requisitos funcionales)
Visin estratgica Enfoque tctico Estndares, tecnologas y mejores prcticas Metodologa Intelligrid
La arquitectura Intelligrid
El proyecto Intelligrid
Los casos de uso del proyecto proveen un conjunto inicial de requisitos funcionales, de infraestructura y de comunicaciones de la aplicacin Aportan una descripcin funcional de la aplicacin Describen los actores (dispositivos, personas, sistemas) necesarios para la interaccin y la informacin que deben intercambiar entre ellos Dan una descripcin paso a paso de lo que sucede y qu orden sucede
Modelado con Enterprise Architect
Enterprise Architect y el CIM

Enterprise Architect es la herramienta de modelado UML ms difundida en el mundo y probablemente la ms completa y potente En 2008 se complet la migracin de modelos del CIM desde diferentes herramientas Sparx Systems de Australia es miembro del UCAIug Solus S.A. es una de las compaas hermanas de Sparx Systems al producir y comecializar la versin en espaol de EA en el mundo
Migracin de modelos a EA
XML (eXtensible Markup Language) es un lenguaje de etiquetas de intercambio creado por el W3C XMI (XML Metadata Interchange) es una extensin 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 prcticamente de todas las herramientas de modelado existentes
Migracin de modelos a EA
Una vez migrados, es posible asegurar la integridad y la disposicin adecuada de los diagramas adecuadamente con las utilidades de EA
Extendiendo el CIM
Se deben aprovechar los modelos del CIM y extenderlos con los modelos propios, minimizando el impacto de las futuras actualizaciones del CIM Se debe mantener y potenciar la traza entre elementos de los modelos propios y del CIM Se pueden utilizar otras herramientas open source para explotar an ms el CIM: CIMTool (http://www.cimtool.org) CIMSpy (http://www.powerinfo.us/opensource/cimspy.html) CIMVian (http://uisol.com/cimvian --> clic en Information)
Extendiendo el CIM
Copiar el modelo base de CIM o importar el XMI en EA Crear un paquete separado en EA para los elementos de la extensin Arrastrar y soltar los elementos estndar del CIM a los diagramas de la extensin Asociar los elemento del CIM con los de la extensin Mantener los mecanismos de seguimiento de traza
Agregando la extensin al modelo

1. Crear una estructura de modelos, con sus respectivos diagramas, para modelar en ella la extensin
Agregando elementos del CIM

Superclase de Switch
2. Arrastrar y soltar el elemento del CIM en el diagrama de la extensin 3. No agregar atributos directamente aqu
Atributos CIM de Switch
Agregando elementos propios

4. Crear el nuevo elemento 5. Relacionar el nuevo elemento con el elemento CIM mediante generalizacin 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
Modelado con perfiles

Es posible aprovechar la potencia de EA para crear perfiles propios, con imgenes representativas de los elementos que deseamos utilizar en el modelado As, los modelos seran ms precisos y se potenciara su semntica, hacindolos ms cercanos a quienes van dirigidos y ms interdisciplinarios UML prev la forma de salirse del estndar en forma estndar, de modo de mantener el formalismo de los modelos y puedan ser ledos por cualquier persona que conozca UML
Ejemplo de modelado con perfiles

1..16 1 1.. 1
Contador Concentrador secundario Concentrador primario

1..
Contador serial
Contador PLC
Red
Plataforma de comunicaciones
Conclusiones
Conclusiones
Las TIC son protagonistas fundamentales de nuestra realidad cotidiana La integracin interdisciplinaria es una necesidad y mucho ms an entre el mundo de la electricidad y las TIC Adems, el tendido elctrico es una oportunidad inmejorable para esta integracin Adicionalmente, la inteligencia de las smart grids proviene del aporte de las TIC en el campo de la electricidad
Conclusiones
Para lograr una integracin es necesario un lenguaje comn La formalidad, la extensibilidad, la difusin y la enorme cantidad de herramientas de soporte existentes para el UML, lo imponen como el estndar ms adecuado Las empresas ms importantes del mundo, tanto en el campo de la electricidad como en el de las TIC, potencian esta seleccin
Conclusiones
Extensiones del lenguaje, como el SysML, ajustan mucho ms al UML como herramienta para las disciplinas vinculadas a la ingeniera El empleo de tecnologas como SOA y otros estndares como el XML y el XMI conforman un conjunto de soluciones de enorme utilidad y amplia aplicacin Slo resta que continen y se potencien los esfuerzos para promover la interdisciplinariedad en todos los mbitos: pblico, privado y acadmico
Muchas gracias por su atencin

UML Taller 2 FPinciroli

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

UML Taller 2 FPinciroli

Caricato da

Copyright:

Formati disponibili

El lenguaje comn de las Smart Grids: Unified Modeling Language

Fernando Pinciroli Julio de 2010

Marco conceptual de smart grids

Hay interfaces para transformar

Existe un modelo definido plug & play

Evolucin del modelado

El camino hacia la unificacin

El camino hacia la estandarizacin

Mtodo vs. lenguaje de modelado

Mtodo vs. lenguaje de modelado

Objetivos del UML

Modelos y diagramas del UML

Modelado del comportamiento Herramientas de diseo Organizacin del modelo

Del UML 1.5 al UML 2.0

Diagramas del UML 2.0

Arquitectura de los modelos

Diagramas del UML

Diagrama de casos de uso

Empleo de los casos de uso

Empleo de los casos de uso

Empleo de los casos de uso

Empleo de los casos de uso

Diagrama de casos de uso

Modelo de casos de uso

Descripcin de los casos de uso

Camino base Funcionalidad no deseada

Extensin de casos de uso

Inclusin de casos de uso

Construccin de los diagramas

Elaboracin de los Casos de Uso

Beneficios del modelado de negocio

Notacin del UML para negocio

Herramientas del UML empleadas

Doble enfoque empleado

Modelo de casos de prueba

Escenarios en un caso de uso

Curso normal Curso alternativo 3 Curso alternativo 4 Curso alternativo 1

Matriz con lotes de prueba

asociacin clase asociacin

Miembros de una clase

Diagrama de objetos: instancia de un diagrama de clases

Diferente nivel de abstraccin

Es imprescindible distinguirlos y determinar cul es el correcto:

Probablemente una o todas las clases deberan integrar el modelo

Elementos de las asociaciones

Ejemplos de multiplicidades: 1..*

objPrestador.crear( ) objPrestador.apellido = Prez

Criterios para generalizar

subclases intermedias en jerarquas anchas

Principio de sustitucin de Liskov

Cuidado con los miembros superpuestos o contradictorios!

Construccin del diagrama

Organizacin del diagrama

Cambios de estado de objetos

Elementos de extensin del UML

Confrontar con miPaper.doc Revisar los atributos de esta clase

Valor etiquetado y restriccin

{self.esposa.sexo = mujer and self.marido.sexo = hombre}

Criterios para los nuevos elementos

inicio de un mtodo etiquetas

[obj3 free] oper(param)

retorno guardia destruccin de un objeto auto-delegacin

Diagrama de estructura compuesta

Diagrama de revisin de interacciones