Upload
volien
View
226
Download
2
Embed Size (px)
Citation preview
1
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
LENGUAJE UML 2
2
Título: Lenguaje UML 2Autor: Manuel ImazLocalidad y Año de impresión: Madrid, 2004
3
LENGUAJE UML 2
1) Modelos. Formas efectivas de modelado. Conocimiento y aprendizajeimplícitos en el proceso de modelado.Documentos y diagramas
2) Breve resumen de Orientación al Objeto. Fases del desarrollo de software:requisitos, análisis, diseño, implementación y pruebas. Las primerasmetodologías y el surgimiento de UML. Cambios relevantes de UML 2 respectode UML 1
3) El Proceso Unificado. Fases. Iteraciones. Diversos enfoques: dirigido porCasos de Uso, centrado en la arquitectura, iterativo, incremental. Herramientas:diagramas, generación de código, integración, ingeniería inversa, intercambiode modelos
4) Visión general: Vistas, Diagramas, elementos de modelado, mecanismos,extensiones a UML (estereotipos, valores etiquetados, restricciones)
5) Diagramas de Actividad. Modelado a distintos niveles: procesos de negocio–con flujo de datos- y lógica del sistema. Importancia de los workflows
6) Modelado de Casos de Uso. Actores. Relaciones entre Casos de Uso.Organización y Descripción. Relación con los requisitos. Evaluación de CdU.
7) Diagrama de clases. Clases y objetos. Relaciones. Asociaciones: diversostipos. Generalización y especialización. Dependencias y abstracciones.Interfaces y puertos. Paquetes. Plantillas (templates)
LENGUAJE DE MODELADO UML 2
4
LENGUAJE UML 2 (Continuación)
8) Diagrama de secuencia –para modelar la lógica secuencial, el orden temporalde mensajes entre diversos clasificadores. Forma genérica y con instancias,concurrencia, creación y destrucción de objetos, recursión. Diagrama decomunicación
9) Diagramas de máquinas de estado. Estados y transiciones. Marca deevento. Custodia de Condición. Expresión de Acción. Cláusula de envío
10) Extensiones a UML. Valores etiquetados. Ejemplos estándares. Valoresetiquetados de un perfil. Estereotipos. Ejemplos. Metainformación. Estereotiposde dependencia, de Casos de Uso, Señales. Restricciones: de asociación y deroles
11) Representación de Arquitecturas. Estructura lógica. Componentes.Colaboraciones. Diagramas de estructura de compuestos. Diagrama decomponentes
12) Patrones en arquitecturas. Mostrar patrones en los diagramas. Patrones yCasos de Uso. Los patrones Proxy. Compuesto y Estrategia
13) Diagrama de despliegue. Nodos. Caminos de comunicación. Asignaciónde artefactos a nodos. Lenguaje para expresar restricciones.
14) Limitaciones de UML: Modelos de Datos y Diseño de Interfaz de Usuario.Representación del comportamiento. Una forma de modelar datos con UML.Una forma de modelar páginas Web con UML
15) Arquitecturas dirigidas por Modelos (MDA). UML ejecutable: evaluación depromesas y limitaciones. Estado actual de la cuestión. Ejemplos
LENGUAJE DE MODELADO UML 2
5
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
1. MODELOS
6
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DEFINICIÓN
Hay definiciones clásicas de modelos:
“Un modelo es un conjunto coherente de elementos formales que describenalgo (por ejemplo, un sistema, un banco, un teléfono o un tren) construido conun propósito que es adecuado para una forma particular de análisis” (Mellor,Clarck y Futagami)
7
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: RESERVAS
La definición anterior tiene una serie de aspectos discutibles:
• Elementos formales: ¿Un modelo debe ser realmente formal?
• Describe algo…construido con un propósito…una forma particular de análisis
Hay otro aspecto y es la correspondencia que se establece casi como obviaentre un elemento de modelado y un elemento del ‘mundo real’. Al concebirsede esta forma, parece que existiera una correspondencia natural entre ambos
“Fórmula 1”
8
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: EL MODELO ES PRODUCTO DEL PENSAMIENTO
En realidad, deberíamos cambiar el dibujo anterior -que intenta ser un modelodel proceso de modelado- y asociar el modelo a un producto del pensamientode un modelador o grupo de desarrolladores
Es la persona la que produce el modelo, por lo quees incorrecto asociar directamente el modelo y elobjeto modelado
9
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DEFINICIÓN ALTERNATIVA
Una definición alternativa de modelo podría ser:
“Un modelo es una interpretación simplificada de la realidad” (Eric Evans)
Aunque también podría ser considerada como difusa en cierto sentido, pero almenos es satisfactoriamente breve
Además, enuncia el hecho de que se trata de una ‘interpretación’, y no de unacorrespondencia objetiva entre el modelo y el trozo de realidad que se modela
Otro aspecto que señala el autor de dicha definición es que el mecanismo demodelado puede ser un diagrama, un código cuidadosamente escrito, o ellenguaje natural
10
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: LENGUAJE HABLADO
Se añade una consideración respecto de la utilidad de un determinado nivel deformalización, dado que el modelo representa un lazo común de comunicaciónentre el desarrollador y los expertos del dominio
Aquí ya hemos entrado de lleno en la cuestión del modelado de sistemas desoftware con desarrolladores y expertos en un determinado dominio, que es elsector de la realidad que se va a modelar
11
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: RELACIÓN CON EL CONOCIMIENTO
Dos ideas centrales de esta concepción del proceso de modelado:
• El modelo es la columna vertebral de un lenguaje utilizado por todos losintegrantes del equipo (desarrolladores, expertos del dominio, usuarios, etc)
Esto permite que todos puedan comunicarse en ese lenguaje, sin necesidad de‘traducciones’ (analistas entre el experto del dominio y los programadores).Como el lenguaje está basado en el modelo, nuestras habilidades lingüísticasnaturales pueden utilizarse para refinar el propio modelo
• El modelo es conocimiento depurado
Un modelo captura cómo elegimos hablar sobre un dominio a medida queseleccionamos términos, descomponemos conceptos y los relacionamos. Estelenguaje compartido permite a los integrantes colaborar eficientemente
12
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: APRENDIZAJE CONTINUO
“Cuando se trata de desarrollar software, nunca sabemos lo suficiente” es otrafrase que ilustra el tema que estamos tratando
El conocimiento sobre un proyecto está fragmentado, repartido entre muchaspersonas y documentos, y está mezclado con otra información de tal maneraque ni siquiera conocemos cuáles son los fragmentos de información querealmente necesitamos
13
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: TIPOS DE CONOCIMIENTO
Una diferenciación importante que podemos hacer sobre el conocimiento, esque viene en dos ‘presentaciones’ distintas:
• conocimiento implícito
• conocimiento explícito
Conocimiento implícito
Conocimiento explícito
14
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: CONOCIMIENTO EXPLÍCITO E IMPLÍCITO -O TÁCITO-
Una breve descripción de ambos tipos de conocimiento
• conocimiento explícito: este conocimiento puede expresarse en palabras ynúmeros y compartido en la forma de datos, fórmulas científicas,especificaciones, manuales, etc.
Puede transmitirse entre las personas formal y sistemáticamente
• conocimiento implícito -o tácito-: es en gran medida personal y muy difícil deformalizar, dificultando mucho la comunicación o el ser compartido por otros.Los pálpitos subjetivos, las intuiciones, los presentimientos caen dentro deesta categoría
Es difícil de verbalizar, dado que está íntimamente enraizado en las acciones yexperiencias de una persona, además de los ideales, valores o emociones queesa persona pueda adoptar
15
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: CONOCIMIENTO EXPLÍCITO E IMPLÍCITO -O TÁCITO-
Relación -de acuerdo a varios autores- entre conocimiento tácito y explícito
10% Conocimiento visible, comunicable, formalizable (Explícito)
90% Conocimiento oculto, ligado a la experiencia (Tácito)
Iceberg
16
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: CONOCIMIENTO IMPLÍCITO -O TÁCITO- Y EXPLÍCITO
Visión de la empresa como máquina procesadora de información. Está basadaen una metáfora industrial, de la misma manera que la concepción de laingeniería de software también lo está
Esta concepción, sin embargo, es incapaz de capturar la esencia de laorganización como una entidad creadora de conocimiento, no sólo capaz deresolver problemas sino de crear y definir otros y desarrollar nuevosconocimientos para resolver los nuevos problemas de forma interactiva
17
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: CONOCIMIENTO IMPLÍCITO -O TÁCITO- Y EXPLÍCITO
En esta nueva visión de la ‘gestión del conocimiento’ no hay que limitarse a unagestión estática de la información o del conocimiento existente, sino apuntar auna gestión dinámica del proceso de crear conocimiento a partir de lo anterior
De esta manera, la creación organizativa de conocimiento es un procesocontinuo de auto-organización, que requiere un nuevo tipo de gestión que vamás allá de los modelos tradicionales (Nonaka y otros, Knowledge Emergence,Oxford University Press, 2001)
18
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DISEÑO RICO EN CONOCIMIENTO
El tipo de conocimiento capturado en un modelo y que se propugna -y ocurremuchas veces- es uno que va más allá de “encontrar nombres”
Las actividades y reglas de negocio son tan importantes en un determinadodominio como lo son las entidades involucradas. Cualquier dominio tiene variascategorías de conceptos
Esta búsqueda más allá de las entidades y los valores es lo que puede detectarinconsistencias entre las reglas de negocio. Los expertos del dominio no sonconcientes de hasta qué punto pueden ser complejos sus procesos mentales
Esto determina que deban -durante el curso de sus actividades- ‘ejecutar’ estasreglas, reconciliar las contradicciones y rellenar los huecos con sentido común
Pero el software no puede realizar estos mismos procesos sin problemas
19
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DOCUMENTOS Y DIAGRAMAS
La primera percepción de la utilidad de un diagrama UML -un diagrama declases u objetos- puede ser cuando discutimos sobre un diseño de software
Mucha gente es naturalmente visual y los diagramas ayudan a captar cierto tipode información: los diagramas UML son muy útiles para comunicar relacionesentre objetos y para mostrar interacciones
Pero no transmiten la definición conceptual de estos objetos. En una discusióndeberemos rellenar estos significados hablando mientras vamos dibujandoestos diagramas, o surgirán en un diálogo con otros participantes
Es decir que un diagrama UML no puede transmitir dos de los aspectos másimportantes de un modelo: el significado de los conceptos que representa yqué se supone que hacen los objetos
Esta es la función complementaria del lenguaje hablado
20
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DIAGRAMAS
Los diagramas son un medio de comunicación y de explicación y facilitan elproceso de creación de ideas (brainstorming)
Pero sirven a este fin si son mínimos: diagramas completos -aunque seancomprensibles- del modelo total de objetos fracasan en su intento decomunicar o explicar. Agobian al lector con detalles al mismo tiempo quecarecen de los significados más importantes
Algunos prefieren utilizar los diagramas UML al revés: en vez de un diagramacon anotaciones en forma de texto que aclaren detalles, prefieren undocumento escrito ilustrado con diagramas seleccionados y simplificados
Siempre debemos recordar que el modelo no es el diagrama (lo mismo que elmapa no es el territorio), el propósito del mismo es ayudar a comunicar yexplicar el modelo
21
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DOCUMENTOS
La comunicación hablada complementa el rigor de los diagramas y del código,pero aunque sea vital para conectar a todos con el modelo, a partir de unacierta cantidad de integrantes de un equipo se necesita la estabilidad y el podercompartir que ofrecen los documentos escritos
• Los documentos deben complementar al modelo y a las conversaciones
• Un documento no debería intentar hacer lo que el código hace perfectamente
• Los documentos deberían servir para seguir funcionando y estar actualizados
• Un documento debe estar involucrado en las actividades del proyecto
22
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
2. ANTECEDENTESY
FASES DEDESARROLLO
23
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: BREVE REPASO DE LA ORIENTACIÓN AL OBJETO
Veamos un resumen de las principales características de la OO:
• Uno de los objetivos de la OO era definir una tecnología para producirmodelos que reflejen un dominio, tal como un dominio de negocio u otro demáquinas, de una manera natural, utilizando la terminología del dominio
• Los cinco conceptos en los que se basa la OO son:
• Objetos, mensajes, clases, herencia y polimorfismo
• Cada objeto es una instancia de una clase, que es un tipo de plantilla que sirvepara definir las características de un objeto y se dice que las clases tienenasociaciones si los objetos que se instancian de ellas están vinculados a otros
24
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: BREVE REPASO DE LA ORIENTACIÓN AL OBJETO (I)
• Cuando están bien construidos, los sistemas basados en la tecnología OO sonflexibles al cambio, tienen una arquitectura bien definida y brindan laoportunidad de crear e implementar componentes reutilizables. También esposible rastrear -trazabilidad- desde el modelo hasta el código del sistema
• Los modelos OO se implementan convenientemente utilizando lenguajes deprogramación OO, sin embargo, la ingeniería de software OO es mucho másque un par de mecanismos asociados al lenguaje de programación
• La OO no es sólo una teoría sino una tecnología bien probada utilizada en unagran cantidad de proyectos y para implementar muchos tipos diferentes desistemas. OMG intenta estandarizarla para lograr una industrialización
• La OO requiere un método que integre un proceso de desarrollo y un lenguajede modelado con técnicas y herramientas adecuadas de construcción
25
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: FASES DEL DESARROLLO
Ingeniería de Negocio
El modelado OO también se ha aplicado a la ingeniería de negocios, donde hademostrado ser un método excelente para modelar los procesos de negocio
Las empresas suelen emplear técnicas tales como Business ProcessReengineering (BPR) o Total Quality Management (TQM) para analizar, mejorar eimplementar los procesos de la empresa
El hecho de utilizar un lenguaje de modelado OO para esta disciplina facilita eluso de esos modelos y documentos para construir los sistemas de informaciónde la empresa
Esta podría ser considerada como una fase previa -o paralela- a las otras fasesde desarrollo de software
26
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: UN MODELO DE PROCESO DE NEGOCIO
27
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: FASES DEL DESARROLLO
Existen numerosos métodos y procesos aplicados al desarrollo de software.Independientemente de las fases, hitos o artefactos que se generan, podemosconsiderar una serie de disciplinas que se aplican:
• Requisitos
• Análisis
• Diseño
• Implementación
• Pruebas
28
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DISCIPLINAS
Podemos definir una disciplina como una colección de actividades relacionadascon un área de interés importante dentro del proyecto global.
El flujo de trabajo -workflow- de una disciplina es una secuencia semi-ordenadade actividades que se ejecutan para lograr un resultado determinado
La naturaleza semi-ordenada de los flujos de trabajo de una disciplina acentúanel hecho de que estos flujos de trabajo no pueden mostrar los verdaderosmatices de planificar un “trabajo real”, ya que son incapaces de presentar lasopciones de las actividades o la naturaleza iterativa de los proyectos reales
A pesar de esto, son útiles como un medio de comprender el proceso aldescomponerlo en áreas de interés más pequeñas. Cada una de ellas tieneasociados uno o más modelos, que se componen a su vez de artefactos
29
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: DISCIPLINAS Y MODELOS
Las disciplinas tienen asociados modelos y éstos están constituidos porartefactos
30
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: VISIÓN GENERAL DE LA DISCIPLINA
Para cada disciplina se presenta una visión general de las actividades. Estavisión general muestra todas las actividades además del rol que las ejecuta
31
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: VISIÓN GENERAL DE LA DISCIPLINA
Para cada disciplina se presenta -además- una visión general de los artefactos
32
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: LA DISCIPLINA DE REQUISITOS
El propósito de la disciplina de Requisitos es:
• Establecer y mantener un acuerdo con los involucrados respecto de lo quedeberá hacer el sistema
• Suministrar a los desarrolladores del sistema una buena comprensión de losrequisitos del sistema
• Definir los límites -o delimitar- el sistema
• Suministrar una base para planificar el contenido técnico de las iteraciones
• Suministrar una base para estimar el coste y el plazo de desarrollo del sistema
• Definir una interfaz de usuario para el sistema, centrándose en lasnecesidades y objetivos de los usuarios
33
Tecnología OO (UML)
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: LA DISCIPLINA DE REQUISITOS
La disciplina de Requisitos consiste en:
El sistemadebería tener…
Involucrado
Analista de Sistemas
Especificaciónde Requisitos
Modelo deCasos de Uso
34
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: LA DISCIPLINA DE ANÁLISIS
El propósito de la disciplina de Análisis es:
• Transformar los requisitos en modelos útiles para la disciplina de Diseño
• Se ocupa de las abstracciones principales (clases y objetos) de losmecanismos que se presentan en el dominio del problema
• Se identifican las clases que modelan estos mecanismos y las relacionesentre ellas, que se describen en un diagrama UML
• Sólo se describen en el análisis las clases que pertenecen al dominio delproblema, dejando de lado aquellas clases técnicas que definen detalles ysoluciones del sistema de software, tales como las vinculadas con la interfaz deusuario, base de datos, comunicaciones, concurrencia, etc
35
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: LA DISCIPLINA DE ANÁLISIS
La disciplina de Análisis consiste en:
Dominio del Problema
Cliente
Pedido
Tecnología OO (UML)
ClaseAsociación
Diagrama de Clases
Cliente
tiene1 *
Pedido
Conceptos
36
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: LA DISCIPLINA DE DISEÑO
El propósito de la disciplina de Diseño es:
• Transformar los resultados del Análisis en una solución técnica
• Añadir nuevas clases para suministrar la infraestructura técnica
• Las clases del dominio del problema provenientes del análisis se incrustan enla infraestructura tecnológica
• Esta mezcla posibilita el cambio tanto del dominio del problema como de lainfraestructura
• El diseño estará constituido por especificaciones detalladas para lasactividades de implementación
37
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: LA DISCIPLINA DE DISEÑO
La disciplina de Diseño consiste en:
Infraestructura TecnológicaDiagrama de Clases
Cliente
tiene1 *
Pedido
BD Interfaz Comun.
Modelo de Diseño
38
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: MOTIVACIONES PARA LA CREACIÓN DE UML
No existía un lenguaje líder de modelado
La mayoría de los lenguajes compartían un conjunto de conceptos
Los conceptos se expresaban de manera diferente
Esta falta de coincidencia desmotivaba a los nuevos usuarios de OO
Los proveedores de herramientas de modelado debían soportarvarios lenguajes ligeramente diferentes
El coste constante de utilizar y soportar varios lenguajes determinaron quevarias empresas usuarias o proveedoras de tecnología OO impulsaran ysoportaran el desarrollo de UML
OMT
OOSE
OMT 2
Booch ‘93
39
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: OBJETIVOS DE UML
Suministrar un lenguaje visual de modelado expresivo con el cual se pudierancrear e intercambiar modelos inteligibles
Proveer mecanismos de extensión y especialización para ampliar los conceptosbásicos
Ser independiente de cualquier lenguaje de programación y de cualquierproceso de desarrollo
Incluir los fundamentos formales para entender el lenguaje
Impulsar el desarrollo del mercado de herramientas oo
Soportar los conceptos de desarrollo de alto nivel, tales como colaboraciones,marcos (frameworks), patrones (patterns) y componentes
OMT
40
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: INFLUENCIAS EN UML OMT
UML
RumbaughJacobson
Meyer
Harel
Wirfs-Brock
FusionEmbly
Gamma y otros
Shlaer-Mellor
Odell
Booch
Clasificación
Ciclo de vida del objeto
Patrones, marcos, notas
Clases singletonDescripción de operaciones,Numeración de mensajes
Responsabilidades
Diagramas de estado
Pre y post condiciones
41
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: CAMBIOS RELEVANTES DE UML 2 RESPECTO DE UML 1
De las especificaciones de requisitos para definir UML han aparecido cuatrohilos conductores para la evolución de dicho lenguaje:
• Hacer que lenguaje para modelar entidades de software sea más ejecutable
• Proveer mecanismos más robustos para modelar flujos de trabajo y acciones
• Crear un estándar para la comunicación entre las diversas herramientas
• Incluir UML dentro de un marco estándar de modelado
OMT
42
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: CAMBIOS RELEVANTES DE UML 2 RESPECTO DE UML 1
UML 2 se ha construído sobre UML 1.x, intentándose no reemplazar elementosbajo ninguna razón. Los cambios debían tener el menor impacto posible en losusuarios actuales de las versiones anteriores
Podemos resumir las metas de las especificaciones de requisitos como sigue:
• Soportar el desarrollo basado en componentes, incluyendo una definicióncompleta para la reemplazabilidad de enchufes (plugs)
• Permitir un modelado más completo del contexto de ejecución decomponentes, especialmente necesarios ante la proliferación de middleware yaplicaciones Web
• Suministrar perfiles estándar o extensiones para los lenguajes importantes
• Soportar la implementación automatizada de patrones comunes de interacción
OMT
43
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
MODELOS: CAMBIOS RELEVANTES DE UML 2 RESPECTO DE UML 1
• Mejorar UML para la arquitectura de ejecución, incluyendo soporte para elmodelado de estructura interna, en especial caminos de comunicación, ademásde la descripción del comportamiento dinámico de esta estructura interna
• Mejorar las máquinas de estado, con una especificación más clara de losenlaces al comportamiento y reglas de especialización
• Mejorar los gráficos de actividad con un mejor control y carácterísticas deflujo de datos
• Soportar la composición de mecanismos de interacción, definir secuencias einteracciones, alternar interacciones y ejecución paralela
OMT
44
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
3. PROCESOUNIFICADO
45
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
46
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL PROCESO
Un proceso es un conjunto de pasos parcialmente ordenados dirigidos haciauna meta. En ingeniería de software, la meta es construir un producto softwareo mejorar uno existente; en ingeniería de proceso, la meta es desarrollar omejorar un proceso
En RUP, los pasos están organizados en un conjunto de disciplinas que definenmás detalladamente los flujos de trabajo y otros elementos del proceso
47
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL PROCESO
El proceso de desarrollo de software es un proceso de negocio y RUP es unproceso de negocio genérico para ingeniería de software OO
Describe una familia de procesos de desarrollo relacionados que compartenuna estructura y una arquitectura de proceso común; suministra un enfoquepara asignar tareas y responsabilidades dentro de la organización
El objetivo es asegurar la producción de software de alta calidad que se ajusta alas necesidades de los usuarios, dentro de un unos plazos y un presupuestosdeterminados
Cuando un sistema de software se desarrolla desde sus comienzos, el procesoes el de crear un sistema a partir de sus requisitos. A medida que el sistema vatomando forma -es decir que ha pasado a través de su ciclo inicial de desarrollo-cualquier desarrollo adicional es el proceso de conformar el sistema a losrequisitos nuevos o modificados
48
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
Descripción de RUP Mejores Prácticas Descripción
Dirigido por Casos de Uso
Guiado por las interacciones entre el sistema y sus usuarios.
Centrado en la Arquitectura
Basado en una arquitectura definida, con relaciones claras entre los componentes de la arquitectura
Iterativo
El problema y la solución se organizan en pequeñas piezas, de tal forma que cada iteración resuelve específicamente una de esas piezas.
Incremental
Cada iteración construye incrementalmente sobre la base construida en iteraciones previas.
Controlado
El control respecto del proceso significa que siempre sabemos lo que vamos a hacer a continuación; el control respecto de la gestión significa que todos los entregables, artefactos y código están bajo la gestión de configuración.
49
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
Requisitos
Implementación
Pruebas
Revisión
Planificación Inicial
Modelado de Negocio
Análisis y Diseño
Despliegue
Gestión de Configuración y Cambios
Entorno
50
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
Inicio ElaboraciónConstrucción
1 2 3 ...
Transición
51
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
52
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
4. VISIÓNGENERAL
53
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTAS
Es imposible mostrar -con un único diagrama- la definición completa de unsistema
Un sistema tiene diversos aspectos:
• Funcionales (estructura estática y comportamiento dinámico)
• No-funcionales (requisitos de tiempos, fiabilidad, despliegue, etc)
• Aspectos organizativos (organización del trabajo, correspondencia conmódulos de código, etc)
Por lo tanto, una descripción de un sistema requiere diversas vistas, cada unade las cuales representa una proyección del sistema completo para mostrardicho aspecto
OMT
54
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTAS COMO PROYECCIÓN OMT
estructura
comportamiento
55
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTAS USADAS POR UML
Las vistas usadas por UML son:
• Vista de Casos de Uso. Muestra la funcionalidad del sistema tal como laperciben los actores externos
• Vista Lógica. Muestra cómo la funcionalidad del sistema está diseñadadentro del sistema
• Vista de Implementación. Muestra la organización del código y el códigoejecutable
• Vista de Despliegue. Muestra el despliegue del sistema en la arquitecturafísica con computadoras y dispositivos denominados nodos
OMT
56
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTA DE CASOS DE USO
Muestra la funcionalidad del sistema tal como la perciben los actores externos
Un actor interactúa con el sistema, siendo el actor un usuario u otro sistema
Se describe en diagramas de casos de uso, que se usan además para validar elsistema probando la vista de casos de uso con los usuarios
Actor 1 Actor 2Sistema
Sistema
=
57
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTA DE CASOS DE USO
Un diagrama de casos de uso puede tener un aspecto similar al siguiente:
Sistema de Seguros
Contratar Póliza
Estadísticas de Ventas
Estadísticasde Clientes
ClienteVendedor
58
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTA LÓGICA
Esta vista describe cómo se suministra la funcionalidad del sistema
Es fundamentalmente para los diseñadores y desarrolladores y, por lo tanto,muestra el interior del sistema
Muestra la estructura estática (clases, objetos y relaciones) y las interaccionesdinámicas que ocurren cuando los objetos envían mensajes a otros objetospara ofrecer una función determinada
También se definen propiedades tales como la persistencia y la concurrencia,así como también las interfaces y la estructura interna de las clases
Estructura estática: diagramas de clases y de objetos
Modelado dinámico: máquinas de estado, diagramas de interacción y actividad
59
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTA DE IMPLEMENTACIÓN
Describe los módulos principales y sus dependencias
Es fundamentalmente para los desarrolladores y consiste en los principalesartefactos de software
Los artefactos abarcan diferentes tipos de módulos de código que se muestrancon sus estructuras y dependencias
También puede añadirse información adicional sobre los componentes, talescomo asignación de recursos (responsabilidad de un componente) u otrainformación administrativa, tal como un informe de avance del trabajo
La vista de implementación requerirá probablemente el uso de extensiones paraun entorno específico de ejecución
60
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTA DE PROCESO
Trata de la división del sistema en procesos y procesadores
Este aspecto -que no es una propiedad funcional del sistema- permite un usoeficiente de recursos, ejecución paralela y el manejo de los eventos asíncronosdel entorno
Además de dividir al sistema en hilos de control de ejecución concurrente, estavista debe considerar los aspectos de comunicación y sincronización de estoshilos de ejecución
61
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: EJEMPLO DE VISTA DE PROCESO
objetoA:ClaseA :ClaseB
Mensaje Síncrono
Mensaje Asíncrono
Mensaje Respuesta
Mensaje Reflexivo
EmpaquetandoPedido
RellenandoEtiqueta de
envío
ContactandoCourier
AsentandoImporte total
a Contabilidad
CargandoTarjeta de Crédito
de Cliente
EnviandoFisico
Financiero
EsperaEjecuciónSin util izar
EsperaEjecuciónSin util izar
:Objeto 1
:Objeto 2
62
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTA DE DESPLIEGUE
Esta vista muestra el despliegue físico del sistema, tales como lascomputadoras y dispositivos (nodos) y cómo están conectados entre sí
También se puede especificar los diferentes entornos de ejecución dentro delos procesadores
Esta vista es utilizada por los desarrolladores, integradores y probadores y estárepresentada por el diagrama de despliegue
Esta vista muestra además cómo los artefactos se despliegan en la arquitecturafísica, por ejemplo, qué programas u objetos se ejecutan en cada computadora
63
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: EJEMPLO DE VISTA DE DESPLIEGUE
: ServidorAplicacionesBiblioteca
: NodoCualquierCliente
: ServidorBDBiblioteca
«artefacto»
prestatario.jar
«artefacto»
bibliotecario.jar
«artefacto»
comun.jar
64
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VISIÓN GENERAL: VISTAS
Es imposible mostrar -con un único diagrama- la definición completa de unsistema
Un sistema tiene diversos aspectos:
• Funcionales (estructura estática y comportamiento dinámico)
• No-funcionales (requisitos de tiempos, fiabilidad, despliegue, etc)
• Aspectos organizativos (organización del trabajo, correspondencia conmódulos de código, etc)
Por lo tanto, una descripción de un sistema requiere diversas vistas, cada unade las cuales representa una proyección del sistema completo para mostrardicho aspecto
OMT
65
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
5. DIAGRAMA DEACTIVIDAD
66
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
Es similar a un diagrama de estado -pero con un propósito diferente- y es el decapturar acciones (trabajo y actividades que deben realizarse, modelados comonodos de actividad ejecutable) y sus resultados en términos de cambios deestado de objetos
Pueden usarse con distintos propósitos, entre los cuales:
• Capturar las acciones que deben realizarse cuando una operación se ejecuta• Capturar el trabajo interno de un objeto• Mostrar cómo se puede realizar un conjunto de acciones relacionadas y cómoafectan a los objetos que están a su alrededor• Mostrar cómo una instancia de un caso de uso puede realizarse en términosde acciones y cambios de estado de objetos• Mostrar cómo funciona una empresa en términos de empleados (actores),flujos de trabajo (workflows), organización y objetos (factores físicos eintelectuales utilizados en el negocio)
67
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
TURISTA: Tarea de hacer una reserva de hotel
• Julia quiere salir de vacaciones de la ciudad a un lugar que no conozca
• Le gustaría que la trataran muy bien durante su estadía de 2 noches
• Normalmente se aloja en hoteles de grandes cadenas, pero le gustaríaconsiderar un hotel independiente con buenas referencias
• Le preocupan el acceso desde el aeropuerto, la proximidad a las principalesatracciones y la seguridad
• Ha encontrado algunos hoteles a tener en cuenta y va a visitar los sitios webde todos ellos
68
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Estado inicial
Actividad
Calle
69
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
70
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Punto dedecisión
71
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Estado final
72
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Recibimos pedidos de los clientes para nuestra librería
Cuando llega el pedido tenemos que ocuparnos del envío, de actualizar laspreferencias del cliente y de contabilizar el pedido
Una vez realizadas todas las actividades, enviamos el paquete con los libros
73
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA OMT Barra
sincronizadora
74
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
A veces puede haber algún objeto que está involucrado en un diagrama deactividad
75
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
6. MODELADO DECASOS DE USO
76
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
En este tipo de modelado, el sistema es visualizado como una “caja negra” quesuministra casos de uso. Por lo tanto no importa cómo lo hace el sistema, cómoestán implementados los casos de uso o cómo funcionan internamente
Los propósitos más importantes de los casos de uso son:
• Decidir y describir los requisitos funcionales del sistema, que serán el acuerdoentre los intervinientes y los desarrolladores del sistema• Dar una descripción clara y consistente de lo que deberá hacer el sistema• Dar una base para realizar las pruebas del sistema para verificar que funcionaadecuadamente y validarlo• Brindar la posibilidad de rastrear los requisitos funcionales hasta las clasesreales y las operaciones. Para simplificar los cambios y extensiones del sistemamodificando el modelo de casos de uso y luego contrastando los casos de usoafectados con el diseño y la implementación del sistema
77
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
VIAJES DE NEGOCIO: Tarea de hacer una reserva de hotel
• Juan necesita hacer un viaje a Córdoba por una reunión de negocio de 2 días• Juan viaja frecuentemente, normalmente varias veces por mes• En los últimos 4 años ha ido a las mismas 7 ciudades y ha creado una rutina• Tiene una línea aérea favorita, una cadena de hoteles y ubicaciones de hotelesen cada ciudad• Normalmente alquila un coche, pero si va a hacer mal tiempo prefiere un taxi• Prefiere hablar directamente con un agente de viajes y es muy exigente paraque todo esté tal como lo ha pedido
78
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Modelar los usuarios: Significa crear definiciones precisas de grupos deusuarios cuya base de distinción se convierte en una diferenciación valiosapara los propósitos del DISEÑO
Usuario: Persona que interactúa directamente con el sistema
Los clientes y usuarios no siempre son los mismos (ejemplo?)
79
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Al revisar las historias -escenarios- encontramos nombres de personas y suscaracterísticas que nos dan pistas para ir definiendo actores -las figuras deabajo- como elementos del modelo de casos de uso
80
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Al revisar las historias -escenarios- encontramos nombres de personas y suscaracterísticas que nos dan pistas para ir definiendo actores -las figuras deabajo- como elementos del modelo de casos de uso
Relación “tipo de”
81
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Puede haber otro tipo de usuarios
82
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UNA POSIBLE HISTORIA
Diagrama de clase de usuarios: Descripción detallada de cada clase, puestoque un actor no es sino una clase «estereotipada» (Un estereotipo es unmecanismo de extensión de UML que permite definir un nuevo tipo de elementode modelo basado en otro existente)
83
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Definir quién tiene qué metas a efectos de validar las distinciones entre gruposde usuarios y ubicar las tareas en el contexto de las metas
Meta: Un fin que debe lograrse independientemente de cómo se obtenga
Criterio de éxito de la meta: Es importante no sólo definir las metas sino loscriterios de éxito para lograr cada meta
84
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
85
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Problema con el diagrama anterior: No resulta de mucha ayuda para el diseño elhecho de que todos los actores tengan la misma meta
Por lo tanto debemos fijarnos si hay sub-metas que sean una base de distinciónentre los grupos de usuarios y que definirían porqué los usuarios querrán usarel sistema para realizar determinadas tareas
86
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
87
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Un caso de uso es una secuencia de acciones realizadas por un actor y elsistema que deriva en un resultado -o conjunto de resultados- de valor para unoo varios actores
El texto de un caso de uso describe caminos posibles a través del caso de uso.Se asocian dos clases de flujos de eventos dentro de los casos de uso:
• El flujo principal de eventos (a veces llamado el curso básico de acción), quees el camino de principio a fin que el actor y el sistema siguen en condicionesnormales
• Un flujo de eventos de excepción (o curso de acción alternativo), que es elcamino a través del caso de uso que representa una condición de error ocamino tomado menos frecuentemente
88
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Las siguientes orientaciones son útiles para producir casos de uso sólidos yfáciles de comprender en una gran variedad de contextos
• Usar una voz activa y hablar desde la perspectiva del actor: evitar -aunque esmenos frecuente en castellano- expresiones del tipo “la opción es seleccionadapor el usuario”. Diremos “el usuario selecciona la opción”
• Usar el presente: Es común oír expresiones en futuro, del tipo “el sistema haráesto o aquello”. El caso de uso estará expresado en presente: “el usuarioselecciona el ítem”, “el sistema efectúa la conexión”
89
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
• Expresar el texto en la forma de “llamada y respuesta”. El esquema básicoserá del tipo: “el actor hace esto”, “el sistema hace lo otro”. Tanto el actorcomo el sistema podrán hacer más de una cosa consecutivamente, pero el textodeberá reflejar el hecho de que el actor realiza una acción y el sistema respondede acuerdo a ello
• Escribir el texto en no más de 3 párrafos. De la misma manera que uno de losprincipios de OO debe hacer -bien- un pequeño número de cosas, los casos deuso también deberían ajustarse a este principio
• Nombrar las clases. Hay dos tipos básicos de clases que se prestan a serincluidas en el texto de los casos de uso: i) las del modelo del dominio y ii) y lasclases límite -o frontera- que abarcan las ventanas, páginas HTML, etc que losusuarios utilizan cuando interactúan con el sistema. Será más fácil diseñar contextos del tipo “el cliente cambia una o más cantidades en Editar Contenidos dela página Carro de la Compra” o “el sistema crea una Cuenta para el Cliente”
90
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
• Establecer el contexto inicial. Tenemos que especificar dónde está el actor y loque pretende al comienzo del caso de uso. Hay dos maneras de hacerlo: Laprimera implica especificar el contexto como parte de la primera oración “Elcontable introduce su ID de usuario y palabra clave en la ventana de acceso alsistema”. La segunda manera implica definir una precondición: “El contable haaccedido al sistema”
• Asegurarse de que cada caso de uso produce al menos un resultado de valorpara uno o más actores, incluso si el resultado es negativo. Normalmenteocurre algo positivo: “El actor accedió al sistema”, “el sistema completa latarea del usuario actualizando la base de datos”, “el sistema genera uninforme”. Pero puede ocurrir que se ejecute un curso alternativo de acción: “elsistema bloqueó al usuario y envió un mail al administrador”
• Ser exhaustivo en describir cursos alternativos de acción. Una maneraefectiva es cuestionar cada oración del curso básico con preguntas del tipo“cómo puede actuar el usuario de forma diferente o errónea?”
91
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
UML ofrece tres estructuras para construir el comportamiento común y loscaminos alternativos de los casos de uso
Incluye (Include) es una relación por la cual un caso de uso explícitamenteincluye el comportamiento de otro en un determinado momento del curso deacción:
92
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Extiende (Extend) es una relación por la cual un caso de uso baseimplícitamente incluye el comportamiento de otro en uno o más puntosespecificados. Estos puntos se denominan puntos de extensión
93
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
La generalización funciona de la misma manera para casos de uso que paraclases en general: un caso de uso padre define un comportamiento que loshijos pueden heredar, añadiendo a o ignorando este comportamiento
94
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Los casos de uso para nuestro ejemplo del hotel serán:
95
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Hemos modelado lo que hemos descubierto sobre:
UsuariosMetasTareas
Hemos declarado explícitamente: los Casos de Uso
Ahora debemos ver las clases involucradas con sus atributos, operaciones yestados
Vistas en las que se usan las clases y posteriormente las interacciones
Nos quedaría por ver un diagrama que modele los aspectos de despliegue
96
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Modelo de los aspectos de despliegue:
97
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
7. DIAGRAMAS DECLASE
98
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DESCRIPCIÓN GENERAL
Hemos visto los siguientes diagramas:Modelo de las tareas actuales de los usuarios Diagrama de clase de usuarios
Metas de usuarios Casos de uso de experiencias de usuarios
99
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMA DE CLASES
El propósito de este diagrama es el de representar los objetos fundamentalesdel sistema, es decir los que percibe el usuario y con los que espera tratar paracompletar su tarea en vez de objetos del sistema o de un modelo deprogramación
Objetos de usuario: Son aquellos conceptos o cosas (concretas o abstractas)que los usuarios perciben y con las que interactúan para realizar sus tareas
Hotel
Cliente
Reserva
Entrada
LlaveHabitación
Estadía
100
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMA DE CLASES
1. Identificar los objetos -revisar los nombres encontrados en los modelos detareas
2. Se pueden clasificar utilizando una tabla simple (opcional)3. Definir cada objeto con una frase de forma que los usuarios puedan
entenderlos4. Colocar los objetos en el modelo (incluyendo definiciones, atributos y
operaciones) y las relaciones entre ellos
Concretos Gente Formularios Usuarios Abstractos
Cosas reales que podemos tocar o llevarnos - Hotel - Habitación - Tarjeta de crédito - Llave
Aquellas que son gestiona-das por el sistema - Cliente
Información escrita u otro sistema - Reserva - Hoja
Aquellos que operan el sistema o que interactúan directamente con él - Cliente - Reservas - Registro
Cualquier otra cosa - Autorización - Estadía - Fechas
101
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMA DE CLASES Clase
Atributos
Operaciones
Relación(compuesto de)
Definición: La partedel edificio donde reside el cliente
Una clase es una plantilla quedefine una colección de cosaso conceptos con las mismascaracterísticas
A un objeto que pertenece auna determinada clase se lodenomina una instancia deesa clase
102
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
La clase es la estructura fundamental dentro de UML. Eso se debe a que:
• Las clases definen el vocabulario básico del sistema a modelarse. El usar unconjunto de clases como el glosario básico de un proyecto tiende a facilitar engran medida la comprensión y el acuerdo sobre el significado de los términos
• Las clases sirven como base del modelado de datos. Lamentablemente, noexiste un estándar para establecer una correspondencia entre un conjunto declases y otro de tablas de base de datos pero existen algunos trabajos sobre eltema
• Las clases son también la base a partir de la cual las herramientas visualesgeneran código
103
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Diagramas que pueden resultar útiles (afinidad) al agrupar conceptos deacuerdo a criterios de similitud, dependencia, proximidad, vinculación
Cliente
Libro
104
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Distintas formas de representar clases. Los nombres de las clases y de losatributos son nombres simples o frases nominales y los de las operaciones sonverbos simples
Cuenta
direccionEmailIDclave
verificarClave()
Libro
titulo: StringCliente
Revision
asignarValoracion( valor: Int)calcularValorMedia(): Double
Revisor
nombre
Responsabilidades- escribir revisión del libro-valorar revisión existente
105
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
La notación para los objetos tiene básicamente la misma forma que para lasclases. Sin embargo, hay algunas diferencias:
• El nombre de la clase aparece después del objeto y dos puntos, pero elnombre del objeto puede no existir• El contenido del compartimiento de nombre está subrayado• Cada atributo tiene un valor específico
Objeto : Clase
Atributo1 = valor1Atributo2 = valor2
: Clase
atributo = valor
106
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
UML ofrece una serie de elementos para especificar detalles para los atributos ylas operaciones:
Visibilidad: El encapsulado es el principio para ocultar datos (data hiding).Desde fuera de un objeto sólo se puede manipular los datos por medio dellamadas a las operaciones -métodos- del objeto. La visibilidad puede ser:
• De paquete: Indicada como [~] significa que los objetos pertenecientes acualquier clase del mismo paquete al que pertenece la clase en cuestiónpueden verlo y utilizarlo• Público: (+) significa que los objetos pertenecientes a cualquier clase puedeutilizar el atributo u operación• Protegido: (#) significa que sólo los objetos de las subclases de la clase a laque pertenece el atributo u operación pueden utilizarlo• Privado (-) significa que sólo se puede usar en los objetos donde está definidoel atributo u operación
107
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
La operación asignarValoracion de la clase RevisionCliente es pública, es decirque los objetos de cualquier otra clase pueden utilizarla
La operación grabar de Revision está protegida, por lo que podrán utilizarla losobjetos RevisionCliente y RevisionEditorial (y los pertenecientes a subclases deéstas), pero no los que están fuera de esta jerarquía
Al ser direccionEmail, ID y clave privados, sólo los objetos Cuenta losacceden
Cuenta
- direccionEmail- ID- clave
RevisionCliente
+ asignarValoracion - calcularValorMediaRevision
# grabar()
108
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
La clase Revision y su operación grabar son abstractas y se las diferenciaporque los nombres están en cursiva (Revision y grabar). Una clase abstractano puede tener instancias
RevisionCliente
+ asignarValoracion - calcularValorMedia
Revision
# grabar()
RevisionEditorial
109
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
El formato completo de una declaración UML de atributo es como sigue:
[ visibilidad ] [/] nombre [: tipo] [multiplicidad] [= omisión] [{cadena-propiedad}]
Los corchetes significan que el elemento es opcional, por lo que sólo el nombrees obligatorio
Cuenta
direccionEmail [1..3]ID: String {readOnly}Clave = 1234
110
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
El formato completo de una declaración UML de operación es como sigue:
[ visibilidad ] nombre [{lista-parámetros}] [{cadena-propiedad}]
Los parámetros de una operación -que aparecen en una lista separados porcomas- representan los datos suministrados por el que llama a la operación, losdatos que la operación devuelve al que la llama, o ambos. Declaración:
[ dirección ] nombre : tipo [multiplicidad] [= valor-por-omisión]
in (la operación puede modificar el parámetro y el que llama no necesita volver a verlo)out (la operación coloca o cambia el parámetro y lo devuelve al que llama)inout (la operación utiliza el parámetro y puede cambiarlo para devolverlo)
111
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PROPÓSITO DE MODELAR LAS METAS DE USUARIOS
Una propiedad que se puede añadir a una declaración de operación es isQuery,que indica que la operación no cambia el valor de ningún atributo
Hay otras 3 propiedades relacionadas con la concurrencia, que tienen que vercon la manera de que un método que implementa una operación responde a losmúltiples hilos de actividad:
• concurrent (pueden entrar múltiples llamadas al método provenientes de otrostantos hilos y todas ellas se atienden concurrentemente)
• guarded (pueden llegar varias llamadas simultáneamente, pero sólo puedeatenderse una por vez)
• sequential (sólo puede llegar una llamada por vez)
112
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DECLARACIÓN DE OPERACIONES
La operación verificarDisponibilidad de la clase Pedido recibe un objetoLibro y devuelve un valor del tipo -definido por el usuario- EstadoPedido
La operación estaCumplido es una consulta que devuelve el valor True si todolo que pidió el cliente está en orden, y False en caso contrario
Una clase activa representa un flujo de control independiente, tal como unproceso o un hilo de control (sus instancias son objetos activos)
Pedido
verificarDisponibilidad (in b: Libro) : EstadoPedidoestaCumplido(): Boolean {isQuery}
Pedido
ID: StringhaSidoEnviado : Booleanestado: estadoPedido
113
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
RELACIONES ENTRE LAS CLASES
Existen varios tipos de relaciones entre clases
ASOCIACIONES
Una asociación es una conexión estructural simple entre clases. Las instanciasde las clases implicadas en una asociación estarán probablementecomunicándose en el momento de ejecución
Revision
asignarValoracion(valor: Int)calcularValorMedia(): Double
Libro
titulo: String
Editorial
Courier
nombre: StringInfoEnvio
114
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ASOCIACIONES: DIRECCIONALIDAD
Se asume que una asociación es bidireccional, es decir que se puede navegardesde cualquiera de clases implicadas a la otra, pero es posible indicar que lanavegación ocurrirá en una sola dirección
Al establecer la direccionalidad de la asociación indicamos que el Cliente puedeacceder a su Clave, pero nadie puede usar la Clave para identificar a un Cliente
Cliente Clave
115
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ASOCIACIONES: ADICIONES
Podemos agregar adiciones -detalles o adornos- a las asociaciones:
Un nombre que indica la naturaleza de la asociación y que puede estaracompañado de un triángulo que apunta en la dirección que debe leerse
La asociación también puede tener roles, que son las caras que presentan lasclases a las demás
AutorLibro
titulo: String
escribió
Revisor Revisiónescribe
es escrita por
116
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ASOCIACIONES: MULTIPLICIDAD
Una asociación puede mostrar la multiplicidad
Cuenta
direccionEmailIDclave
verificarClave()
Cliente
InformacionFacturacion
1
1
1*
117
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
RELACIONES
AGREGACIÓN
Es una asociación especial, una relación del tipo “todo/parte” dentro de la cualuna o más clases son partes de un conjunto
Equipo
Miembro
Todo
Parte 1 Parte 2Todo
Parte 1 Parte 2
118
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
RELACIONES
COMPOSICIÓN
La composición es una forma ‘fuerte’ de agregación. Se diferencian en:
• En la composición tanto el todo como las partes tienen el mismo ciclo de vida
• Un objeto puede pertenecer solamente a una composición
Contabilidad
Cuenta
Ventana
Texto ListaBoton
119
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
RELACIONES
GENERALIZACIÓN
Una generalización se refiere a una relación entre una clase general (superclaseo padre) y una versión más específica de dicha clase (subclase o hija)
Revision
RevisionCliente
Revision
RevisionCliente RevisionEditorial
120
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
RELACIONES
POWERTYPE
La clase Marca de Coche actúa como powertype respecto de la clase Coche.Las instancias de la superclase Marca de Coche incluyen a las clases Volvo,Ford y Opel, que son subclases de la clase Coche
«powertype»Marca de Coche
Volvo
Coche
Ford Opel
1*
(incompleto)
121
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DEPENDENCIAS
Una dependencia es una relación de “uso” en la que un cambio en uno de lostérminos -por ejemplo, una clase- puede afectar a otro (otra clase)
Pedido ItemPedido«usa»
Pedido AsientoContable«crea»
ManejadorPaginaHTML PaginaLogin
«instancia»
122
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DEPENDENCIAS
.
CarritoCompra «session bean»SCarritoCompra
«abstraccion»
Pedido«componente»Pedido Fisico
«realiza»
Pedido Pedido«refina»
registrarEnvio()
123
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMAS DE CLASES A NIVEL DE DOMINIO
OrdenCompra Envio
Stock
Libro
Categoria Catalogo
Ejemplar
CarritoCompra
Pedido Cliente
CuentaContable
Cuenta
InfoFacturacion
Autor
124
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMAS DE CLASES A NIVEL DE ANÁLISIS
OrdenCompra
IDautorizadaPorvencimiento
Stock
Libro
Categoria
Ejemplar
CarritoCompra
Pedido
IDtotalfecha
CuentaContable
Cliente
Cuenta
IDdireccionEmailClave(cifrada)
125
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EXPANSIÓN DEL DIAGRAMA DE CLASES A NIVEL DE ANÁLISIS
OrdenCompra
IDautorizadaPorvencimiento
Stock
Libro
Categoria
Ejemplar
CarritoCompra
Pedido
IDtotalfecha
CuentaContable
Cliente
CuentaIDdireccionEmailClave(cifrada)
autorizar() calcularMin()
clasificar()
tituloisbnpalabraClave
CalcularPrecio()
nombrenumerodebitoCredito
seguir()calcularSubtotal()
cambiarEmail()
cambiarEmail()
«pagina HTML»CarritoCompra
«formulario»Comprar
«applet»ActualizarForm
«JSP»PedidoCandidato
«session bean»SCarritoCompra
«entity bean»EPedido
DIAGRAMA DE CLASES DE DISEÑODE ALTO NIVEL
126
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
INTERFACES
Una interfaz es una colección de operaciones que representan serviciosofrecidos por una clase o componente. Por definición, todas estas operacionestendrán una visibilidad pública
La interfaz especifica algo similar a un contrato a la que la clase se comprometela clase realiza (o suministra una realización de) una o varias interfaces
UML define dos tipos de interfaces: interfaz suministrada e interfaz requeridaLos dos ejemplos que se muestran son interfaces suministradas
Cuenta
IManejadorClave
Inventario
«interfaz»IManejadorInventario
almacenar()buscar()
127
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
INTERFACES REQUERIDAS Y SUMINISTRADAS
Las interfaces requeridas son aquellas que necesita una clase para realizar sucometido. El símbolo utilizado para representarla es un semi-círculo
Las instancias de la clase Pedido utilizan Buscar Libros para cumplimentar elpedido especificado, y Buscar Informacion Seguimiento si el cliente que realizóel pedido quiere seguir la historia del envío del pedido
El último ejemplo muestra una interfaz requerida/suministrada
Pedido
IBuscarLibros
IBuscarInformacionSeguimiento
Pedido
BuscarLibros
Inventario
128
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PUERTOS Y CONECTORES
Un puerto especifica un punto claro de interacción entre una clase y su entornoLos puestos agrupan interfaces suministradas y/o interfaces requeridas
Por un lado sirven como puntos focales a través de los cuales se pueden hacerpeticiones para invocar las operaciones que ofrece la clase. Por otro, sirvencomo puente para las llamadas que hace la clase a operaciones que ofrecenotras clases
Pedido
BuscarLibros
SuministrarInformacionSeguimiento
RealizarEjecucion
BuscarInformacionSeguimiento
Seguimiento
129
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PAQUETES
Un paquete es un agrupamiento de pieza del modelo y son muy útiles paragestionar modelos
Un paquete se representa en UML como una carpeta con lengüeta y hay tresvariantes:
• El nombre del paquete aparece en el cuerpo de la carpeta y el contenido estáoculto
Pedido
Pedido
InfoFactura InfoEnvio
Courier Pedido
Pedido
InfoFactura InfoEnvio Courier Pedido
+
130
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PAQUETES
Un paquete puede añadir elementos externos del modelo por referencia. Si lavisibilidad de una elemento dado es pública, el paquete realiza un importa, y sila visibilidad es privada, el paquete realiza un accede
IU Alto Nivel
Cliente
Cliente
AccesoAdministracion
Cuenta
«importa»
«accede»
131
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PLANTILLAS (TEMPLATE)
Una plantilla es un descriptor para un elemento de modelado que tiene uno omás parámetros formales que pueden usarse para crear una familia deelementos de modelado relacionados
incluir(in c: TipoCliente, in t: TipoItem
borrar(in i: Item)
ListaMeGustariaTipoClienteTipoItem
MeGustaria
«ligar» <TipoCliente -> Vacaciones, TipoItem -> CD>
132
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
8. DIAGRAMA DESECUENCIA
133
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
INTERACCIONES, LÍNEAS DE VIDA Y MENSAJES
Una interacción es un comportamiento que se centra en los intercambiosobservables de información entre los objetos
Una línea de vida representa la participación de un objeto dado en unadeterminada interacción
objeto:Clase :Cuenta
«crea»
134
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
Los objetos comunican a través de mensajes entre líneas de vida. La notaciónpara el mensaje siempre es una flecha, pero el tipo de flecha y la punta varía enfunción del tipo de mensaje:
• una llamada síncrona aparece como una línea sólida con una punta tambiénsólida• una llamada asíncrona aparece como una línea sólida con una mitad de punta• un mensaje respuesta aparece como una línea punteada con una punta sólida• un mensaje de creación de objeto aparece como una línea punteada con unapunta emplumada• una mensaje “perdido” (uno en que se conoce el remitente pero no elreceptor) tiene un pequeño círculo negro siguiendo a la punta• un mensaje “encontrado” (uno en que se conoce el receptor pero no elremitente) tiene un pequeño círculo negro justo antes de la punta
135
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
Los objetos comunican a través de mensajes entre líneas de vida. La notaciónpara el mensaje siempre es una flecha, pero el tipo de flecha y la punta varía en
objetoA:ClaseA :ClaseB
Mensaje Síncrono
Mensaje Asíncrono
Mensaje Respuesta
Mensaje Perdido
Mensaje Encontrado
Mensaje Reflexivo
136
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
Los objetos comunican a través de mensajes entre líneas de vida. La notaciónpara el mensaje siempre es una flecha, pero el tipo de flecha y la punta varía en
instancia
crea
destruye
137
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
La operación oper() se llama a sí misma. Habrá una condición en la operaciónque parará la recursión. Se muestra explícitamente la respuesta
nombre objeto:clase
oper()
oper()
sd DemoRecursion
138
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
Un diagrama de secuencia muestra el orden temporal de los mensajes
pulsarAcceso()
:PaginaAcceso :Cuenta:PaginaPrincipal:Cliente
mostrar()
Introducir ID de usuario y clavepulsarOK()
validarAcceso(IDUsuario,clave)
accesoOK()
mostrar()
sd Acceder a IC
El Cliente pulsa el botónAcceso en PaginaPrincipal
El sistema muestra laPaginaAcceso
El cliente introduce su IDy Clave y luego el botónOK
El sistema valida la informa-ción de acceso respecto delos datos persistentes deCuenta
…y luego devuelve al Clientea la página principal
139
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
FRAGMENTOS DE INTERACCIÓN
Un fragmento de interacción es una pieza distinguible de interacción. Hay sietetipos distintos de fragmentos de interacción:
• Fragmentos combinados• Continuaciones• Ocurrencias de eventos• Ocurrencias de Ejecución• Ocurrencias de Interacción• Decomposiciones en partes• Invariantes de estado
140
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
FRAGMENTOS COMBINADOS
Un fragmento combinado es una combinación de uno o más operandos deinteracción, cada uno de los cuales contiene uno o más fragmentos deinteracción y un operador de interacción:
• alt, en el que el fragmento combinado representa una elección decomportamiento: cada fragmento tiene un resguardo, que significa que sólo seejecutará uno de los operandos
:Objeto 2:Objeto 1
Mensaje1
Mensaje2
Mensaje3
Mensaje4
sd NombreDiag
alt
[guard 1]
[guard 2]
141
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
FRAGMENTOS COMBINADOS
• assert, en el que el fragmento combinado representa una aserción: elfragmento debe ocurrir tal como se especifica
• loop, en el que el fragmento combinado representa un bucle: el operandobucle se repite el número especificado de veces
:Objeto 2:Objeto 1
Mensaje1
Mensaje2
Mensaje3
Mensaje4
sd NombreDiag
loop1..7
142
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OCURRENCIAS DE INTERACCIÓN
Una ocurrencia de interacción representa la ocurrencia de una pieza de unainteracción particular con valores específicos y que reemplaza al ocupantedefinido para la interacción. Se utilizan generalmente para factorizar elcomportamiento común que existe dentro de un número de interacciones
:Objeto 2:Objeto 1
Mensaje1
Mensaje2
Mensaje2
sd NombreDiag
ref
NombreInteraccion(argumento,…)
143
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
FRAGMENTOS COMBINADOS
Un fragmento combinado es una combinación de uno o más operandos deinteracción, cada uno de los cuales contiene uno o más fragmentos deinteracción y un operador de interacción:
• alt, en el que el fragmento combinado representa una elección decomportamiento: cada fragmento tiene un resguardo, que significa que sólo seejecutará uno de los operandos• Continuaciones• Ocurrencias de eventos• Ocurrencias de Ejecución• Ocurrencias de Interacción• Decomposiciones en partes• Invariantes de estado
144
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
Un diagrama de secuencia muestra el orden temporal de los mensajes
pulsarAcceso()
:PaginaAcceso :Cuenta:PaginaPrincipal:Cliente
mostrar()
Introducir ID de usuario y clavepulsarOK()
validarAcceso(IDUsuario,clave)
accesoOK()
mostrar()
sd Acceder a IC
El Cliente pulsa el botónAcceso en PaginaPrincipal
El sistema muestra laPaginaAcceso
El cliente introduce su IDy Clave y luego el botónOK
El sistema valida la informa-ción de acceso respecto delos datos persistentes deCuenta
…y luego devuelve al Clientea la página principal
145
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
Un diagrama de comunicación
:PaginaAcceso:Cuenta
:PaginaPrincipal
Cliente
1: pulsarAcceso()
2: mostrar()6: mostrar()
3: introducir ID y clave
4: pulsarOK()
5: validarAcceso(ID, clave)
146
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
9. DIAGRAMA DEESTADO
147
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ESTADOS Y TRANSICIONES
Un estado es una condición en la que puede estar un objeto en algún momentode su ciclo de vida, durante un cierto tiempo
Mientras está en un determinado estado, el objeto puede realizar algunas -otodas- de las siguientes acciones:
• Realizar una actividad
• Esperar un evento
• Satisfacer una o más condiciones
Contabilizando BuscandoLibros Enviado
148
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ESTADOS Y TRANSICIONES
Una transición es un cambio del objeto desde un estado (estado fuente) a otro(estado destino). También puede haber una auto-transición cuandos ambosestados coinciden
Empaquetando Enviando
EnviadoEnviando
confirmacionEnvio/colocarIndCumplimentado()
RecibiendoLibros
149
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
El símbolo de estado puede contener además la siguiente información:
• Una acción de entrada es aquella que el objeto realiza siempre inmediatamentedespués de entrar al estado. Aparece como entrada/NombreAcción
• Una acción de salida, de forma similar, es aquella que siempre realiza el objetoinmediatamente antes de abandonar el estado en que se encuentra
Empaquetando
entry/asentarEnCG
Enviando
exit/colocarSeñalCumplido
150
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
OTRA POSIBLE HISTORIA
Una bifurcación -fork- divide la transición en dos o más. En la figura vemos lanotación para una bifurcación que opera en la transición proveniente del estadoEmpaquetando el Pedido
EmpaquetandoPedido
RellenandoEtiqueta de
envío
ContactandoCourier
AsentandoImporte total
a Contabilidad
CargandoTarjeta de Crédito
de Cliente
Enviando
Fisico
Financiero
151
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
SUBESTADOS SECUENCIALES
Es un sub-estado en el que se encuentra un objeto con exclusión de cualquierotro en el mismo nivel dentro del estado compuesto
Empaquetando
ContactandoCourier
EsperandoPedido deReposición
Acumulandodesde
Reposición
Buscando Libros
llegadaLibros
[pedido pendiente]
[todos los libros encontrados]
salida/asentarCG
152
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
10. EXTENSIONESA UML
153
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
VALORES ETIQUETADOS
Los tres principales elementos de extensión son los valores etiquetados(propiedades), las restricciones y los estereotipos
• Los valores etiquetados son propiedades adjuntadas a elementos UML. Porejemplo, una etiqueta de autor con un valor del autor de la clase
• Las restricciones son reglas que restringen la semántica de uno o máselementos de UML. Las restricciones se pueden adjuntar a las clases u objetosy con frecuencia se las añade a las relaciones, con lo que se restringe lasclases o los objetos que participan en la relación
• Un estereotipo representa el principal mecanismo de extensión. Ofrece unaforma de extender una metaclase, creando un nuevo elemento de metamodelo
154
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EJEMPLOS DE VALORES ETIQUETADOS
{ estado = ‘en construcción’ , analista = ‘Juan Pérez’ }
Coche
+ velMedia+ velMax+ propietario+ pasajero
+ arrancar()+ parar()
Coche de Carreras
+ velCrucero {redefine <velMedia>}+ velocidadMax = 300+ conductor
+ pasar()
Taxi
+ cliente {redefine <pasajero>}+ conductor {redefine <propietario>}
+ cargar()
155
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
SEÑALES
Una señal es una notificación de algún tipo que un objeto envía asíncronamentea uno o más objetos
«signal»CancelarPedido
IDPedido: String
Pedido
SignalsCancelarPedido
«interface»ManejadorInventario
«signal» almacenar«signal» recuperar
:GestorAcceso
Acceso(IDUsuario,clave)
:GestorSeguridad
maneja3Intentos()
«envía»
156
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DISPARADORES (TRIGGERS)
Un disparador representa una ocurrencia de un evento, que es algo designificación para uno o más objetos para provocar la ejecución de algúncomportamiento asociado con el/los objetos
• Un disparador de llamada representa la recepción de una petición para llamaruna operación específica perteneciente a una clase dada (que se convierte enuna llamada a un método de un objeto)
• Un disparador de cambio representa un evento que ocurre cuando unaexpresión booleana es verdadera como resultado de un cambio en el valor deuno o más atributos o asociaciones. Expresamos un evento de cambioutilizando la palabra cuando (por ejemplo, cuando es medianoche o cuando elbucleMaximo = 100)
• Un disparador señal representa la recepción de una señal particular
157
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DISPARADORES (TRIGGERS)
• Un disparador de tiempo representa un evento que ocurre después de unperíodo específico de tiempo. Expresamos un evento de tiempo usando lapalabra después seguida de una expresión de tiempo absoluto o relativo (porejemplo, después de 5 segundos o después de [15 minutos desde la últimaacción de teclado o ratón])
158
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ACCIONES
Una acción es una asignación primitiva ejecutable -o computación- que recibeun conjunto de valores de entrada y produce un cambio de estado y/o el retornode valores de salida (Un cambio de estado de un objeto se ve reflejado en loscambios a los valores de uno o más de sus atributos)
La notación para una acción es un rectángulo con los ángulos redondeados:
Buscar el códigode país
Calcular elCosto de envío
Colocar indicadorde cumplimentado
159
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ACCIONES CON PRE Y POST CONDICIONES
Una precondición local es aquella que debe ser verdadera cuando comienza laejecución de una acción
Una post-condición es una condición que debe ser verdadera cuando finaliza laejecución de una acción
Buscar el códigode país
Colocar indicadorde cumplimentado
«precondiciónLocal»{todos los libros encontrados}
«postcondiciónLocal»{incluida la etiqueta de envío}
«pin»elemento de entrada -izquierda-
o salida -derecha-
160
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
11.REPRESENTACIÓN
DEARQUITECTURAS
161
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DEFINICIÓN DE ARQUITECTURA
Existen diversas definiciones del concepto de arquitectura, dependiendo delpunto de vista que se adopte y del alcance que implique dicho punto de vista
Arquitectura es la estructura organizativa y el comportamiento asociado de unsistema. Una arquitectura puede descomponerse recursivamente en partes queinteractúan a través de interfaces, relaciones que conectan las partes yrestricciones para ensamblar dichas partes
Una arquitectura de software es una descripción de los subsistemas ycomponentes de un sistema de software y las relaciones entre ellos. Lossubsistemas y los componentes se especifican normalmente en vistasdiferentes para mostrar las propiedades relevantes tanto funcionales como nofuncionales del sistema. La arquitectura de software de un sistema es unartefacto. Es el resultado de la actividad de diseño de software
162
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DEFINICIÓN DE ARQUITECTURA
Una arquitectura típica es la de las tres capas: 1) Capa de presentación, 2) Capade aplicación y 3) Capa de dominio
Capa de
Presentación
Capa de
Aplicación
Capa de
Dominio
163
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DEFINICIÓN DE COMPONENTE
Un componente es una unidad auto-contenida que encapsula el estado y elcomportamiento de un conjunto de clasificadores
Un clasificador es un elemento general de modelado para indicar una entidadque tiene instancias con características comunes. Las clases, interfaces,señales y nodos son ejemplos de clasificadores
«component»
TituloImpleTitulo java.sq.Connection
164
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DEFINICIÓN DE COMPONENTE
El siguiente diagrama muestra lo que se ha implementado dentro del paqueteTitulo. Hay una decisión arquitectónica para resaltar la separación de interesesentre capas
«component»
:GestorTitulo
AccesoTitulo java.sql.Connection
Titulo
«component»
:TituloDaoMySql
AccesoTitulo
Titulo
Titulo«delega»
«delega»
java.sql.Connection
DAO: Patrón Data Access Objectpara abstraer y encapsular todoslos accesos a los datos
165
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMA DE COMPONENTES
Un diagrama de componentes se centra en un conjunto de componentes y larelación estructural entre ellos, aunque también puede mostrar interfaces
«servlet»
Compra
«servlet»
Pagina Principal
«servlet»
Acceso
«servlet»
Vista Carro Compra
«servlet»
Catalogo
«servlet»
Base de Libros
«servlet»
Detalle Libros
166
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
COLABORACIONES
Una colaboración dinámica es una parte clave de una arquitectura quecomunica cómo debe diseñarse el sistema dentro de ella
comprador vendedor
Venta
Venta
Cliente SuministradorServicio
comprador vendedor
167
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMA DE ESTRUCTURA DE COMPUESTOS
Una colaboración dinámica es una parte clave de una arquitectura quecomunica cómo debe diseñarse el sistema dentro de ella
frenteIzquierda: Llanta
Automovil
frenteDerecha: Llanta
atrasIzquierda: Llanta atrasDerecha: Llanta
168
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
12. PATRONES ENARQUITECTURAS
169
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PATRONES
Los patrones han recibido mucha atención por parte de la comunidad OOporque han representado una ruptura en el desarrollo de software. Lasprincipales características de los patrones son:
• Inteligencia. Los patrones de diseño son soluciones elegantes que a unnovicio no se le ocurrirán inmediatamente
• Genéricos. No dependen de ningún tipo determinado de sistema, lenguaje deprogramación o dominio de aplicación; son genéricos para un problemaespecífico
• Probados. Se han identificado en sistemas reales, orientados al objeto. No sonel resultado de un desarrollo académico sino que han sido probados en variossistemas
170
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PATRONES (I)
• Simples. Generalmente son bastante pequeños, implicando sólo unas cuantasclases. Para construir soluciones más complejas, es posible combinar ymezclar patrones con código de aplicación
• Reutilizables. Están documentados de tal manera que son fáciles de usar. Hayque tener en cuenta que la reutilización es a nivel de diseño, no de código (noestán en librerías de clases porque son para arquitectos de sistemas)
• Orientados al objeto. Están construidos con los mecanismos básicos de laorientación al objeto, tales como clases, generalizaciones y polimorfismo
171
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
LOS PATRONES SUMINISTRAN:
• Soluciones reutilizables a problemas comunes. Estas soluciones estánbasadas en experiencias concretas de desarrollo de sistemas reales
• Nombres de abstracciones por encima de la clase y objeto. De estaforma es posible discutir soluciones a un alto nivel: “Te sugiero que uses unPuente o un Adaptador para resolver eso” (nombres de patrones)
• Manejo de los aspectos funcionales y no-funcionales del desarrollo.Muchos patrones resuelven específicamente algunas áreas en que losprogramas orientados al objeto son especialmente buenos: separación de lainterfaz y la implementación, dependencias débiles entre partes, aislamientoentre las plataformas software y hardware y la potencial reutilización de diseñoy código
172
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
LOS PATRONES SUMINISTRAN: (I)
• Una base para desarrollar marcos y herramientas de trabajo. Son lasestructuras básicas utilizadas en diseñar marcos reutilizables
• Soporte de formación para los que están aprendiendo programación ydiseño orientados al objeto. Al estudiar patrones de diseño, se puede lograruna comprensión de las propiedades básicas del buen diseño, que luego sepueden emular en los diseños propios
173
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL PATRÓN PROXY
Es uno de los incluidos en el libro de Design Patterns (Gamma y otros)
«interface»Subject
+ Peticion()
Client
RealSubject
+ Peticion()
Proxy
+ Peticion()
se refiere a
…seRefiereA.Peticion()
…
174
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL PATRÓN PROXY COMO COLABORACIÓN
Aplicación del patrón Proxy a un ejemplo de Cliente, Pedido y ProxyPedido
Client: Cliente Subject: InterfazPedido
Proxy
RealSubject:Pedido
Proxy: ProxyPedido
175
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL CONTEXTO DEL PATRÓN PROXY
El contexto del patrón Proxy descrito en términos de un diagrama de objetos
unCliente: ClientunRealSubject:
RealSubjectunProxy: Proxy
176
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
LA INTERACCIÓN EN EL PATRÓN PROXY
La interacción en el patrón Proxy descrita como un diagrama de secuencia
unCliente:Client
sd DemoProxy
unProxy:Proxy unRealSubject:RealSubject
Peticion()
Peticion()
177
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL PATRÓN FAÇADE
Provee una interfaz unificada a un conjunto de interfaces en un subsistema.Define una interfaz de alto nivel que facilita el uso del subsistema
Façade
clases cliente
clases subsistema
178
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
ESTRUCTURA DEL PATRÓN FAÇADE
Participantes:
• Façade: Conoce qué clases subsistema son responsables de cada petición ydelega las peticiones de los clientes a los objetos apropiados del subsistema• Clases subsistema: implementan la funcionalidad del subsistema, manejan eltrabajo asignado por el objeto façade y no tienen conocimiento de la façade
Façade
179
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
13. DIAGRAMA DEDESPLIEGUE
180
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL DIAGRAMA DE DESPLIEGUE
Muestra la arquitectura en el momento de ejecución de los dispositivos,entornos de ejecución y artefactos que residen en dicha arquitectura. Es ladescripción física de la topología del sistema, que describe la estructura de lasunidades hardware y el software que se ejecuta en cada unidad
NODOS:
Son recursos de computación sobre los que se puede desplegar artefactos parasu ejecución (incluyen dispositivos tales como computadoras, dispositivosmóviles, lectoras de tarjetas, etc)
ServidorMedio ServidorPruebas:ServidorMedio
181
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
NODO DISPOSITIVO CON ENTORNOS DE EJECUCIÓN
Un modo puede mostrar un tipo o una instancia (puesto que es un clasificador),en el que un tipo describe las características de un tipo de procesador odispositivo y una instancia representa una máquina concreta. El siguientediagrama representa un tipo recurso físico de computación y dos tipos derecursos de software
«entorno ejecución»J2EEServer
«dispositivo»ServidorRangoMedio
«entorno ejecución»DBServer
182
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
NODO DISPOSITIVO CON ENTORNOS DE EJECUCIÓN
Un modo puede mostrar un tipo o una instancia (puesto que es un clasificador),en el que un tipo describe las características de un tipo de procesador odispositivo y una instancia representa una máquina concreta. El siguientediagrama representa un tipo recurso físico de computación y dos tipos derecursos de software
ClienteB:Compaq Pro PC
ClienteA:Compaq Pro PC
ServidorAplicaciones:SiliconGraphics O2
ServidorBaseDatos:VAX
«TCP/IP»
«TCP/IP»
«DecNet»
183
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
NODO DISPOSITIVO CON ENTORNOS DE EJECUCIÓN
Un modo puede mostrar un tipo o una instancia (puesto que es un clasificador),en el que un tipo describe las características de un tipo de procesador o
:AppServer
«artifact»AplicacionCompra.ear
«artifact»CarritoCompra.jar
«artifact»Pedido.jar
«deployment spec»ejb-jar.xml
«deployment spec»application.xml
184
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PORQUÉ OCL?
Un diagrama UML, tal como un diagrama de clases, no está suficientementerefinado como para brindar todos los aspectos relevantes de unaespecificación. Existe, entre otras cosas, la necesidad de describir restriccionesadicionales sobre los objetos del modelo
Profesor
cursornombre
Curso
contenidotítulo
1..*
1
Departamentonombre
dicta
dirige
0..11
{un director es un Profesorque dirige un Departamento}{un no.director es un Profesorque no dirige un Departamento}
{nro.cursos.director < nro.cursos.no.director}
185
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PORQUÉ OCL?
Las restricciones se describen normalmente en lenguaje natural, pero lapráctica ha mostrado que esto deriva siempre en ambiguedades. A efectos deescribir restricciones no ambiguas se han desarrollado leguajes formales
La desventaja de estos lenguajes formales es que pueden ser utilizados porpersonas con una buena formación matemática, pero son difíciles de usar parael modelador medio de negocios o sistemas
OCL se ha desarrollado para salvar esta carencia, dado que es un lenguajeformal que es al mismo tiempo fácil de leer y escribir
186
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UN LENGUAJE DE RESTRICCIONES (OCL: OBJECT CONSTRAINT LANGUAGE)
187
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
UN LENGUAJE DE RESTRICCIONES (OCL: OBJECT CONSTRAINT LANGUAGE)
UML ya utilizaba en las versiones anteriores OCL, una forma estándar paraexpresar restricciones de tal manera que fuera interpretable por lasherramientas
Como ahora también tiene su meta-modelo, es la manera adecuada de declararlas restricciones si se quiere utilizar MDA o hacer que los modelos seanejecutables
Tanto UML como OCL están definidos a través de MOF (Meta Object Facility)una especificación de tecnología estandarizada por OMG (Object ManagementGroup) en 1997
MOF es un marco orientado al objeto para la especificación de la sintaxisabstracta de lenguajes de modelado
188
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
INVARIANTES, PRECONDICIONES Y POSTCONDICIONES
Una invariante se refiere a un tipo, y especifica una propiedad que se mantienea lo largo del ciclo de vida de una instancia del tipo
Por ejemplo, referido a la clase Coche, podemos decir que la velocidad es uninvariante:
Context coche inv:VelocidadCoche >= 0
Una precondición se aplica a una operación, y es una condición que debe serverdadera antes de que se invoque la operación
189
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
14. LIMITACIONESDE UML
190
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EL DIAGRAMA DE DESPLIEGUE
• UML soporta en ciclo de vida completo del desarrollo de software
• Mejora la calidad del software
• La representación gráfica del diseño se traduce en código fuente (por ejemplo,Rational Rose --> Java, C++, Ada, etc)
• Disminuye el costo de desarrollo y mantenimiento
• Ayuda en la gestión de riesgos y en la productividad del equipo
• Promueve el desarrollo basado en componentes
• Permite la ingeniería inversa
191
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EXTENSIONES A UML
Un mecanismo utilizado para extender UML es el de Perfil (UML Profile), queconsiste en un conjunto de estereotipos, valores etiquetados y restriccionesdedicados a adaptar UML a un determinado dominio tal como modelado denegocio o de componentes
Los perfiles especializan a UML de tal manera que se pueden construir modelosutilizando conceptos de un determinado dominio. Por ejemplo, en el dominio demodelos de negocio podemos tener conceptos tales como paso de negocio,actor de negocio, etc, por lo que resultará muy útil definir un meta-modelopreciso del dominio con el que se quiere trabajar
Por ejemplo, podremos representar los pasos de negocio como actividadesestereotipadas «paso de negocio». Generalmente los conceptos de un dominiose corresponden con un clasificador UML estereotipado, y los atributos delconcepto con valores etiquetados
192
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
EXTENSIONES A UML
El modelado de datos todavía no stá cubierto por el lenguaje UML, a pesar deque los temas relacionados con la persistencia es un aspecto importante de losproyectos orientados al objeto
Algunos autores han insistidos durante varios años sobre este particular(Ambler) y han llegado a proponer un perfil específico con este fin
193
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PERFIL PARA MODELADO DE DATOS (PROPUESTO POR AMBLER)
Estereotipo Tipo de Modelo<<Class Model>> Modelo OO u objeto-relacional<<Conceptual Data Model>> Modelo Conceptual de datos<<Logical Data Model>> Modelo Lógico de datos (LDM)<<Physical Data Model>> Modelo físico de datos (PDM)
<<Associative Table>> Físico<<Entity>> Lógico, Conceptual<<Index>> Físico <<Lookup Table>> Físico<<Stored Procedures>> Físico<<Table>> Físico<<View>> Físico
194
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PERFIL PARA MODELADO DE DATOS (PROPUESTO POR AMBLER)
195
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PERFIL PARA MODELADO DE DATOS (PROPUESTO POR AMBLER)
196
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PERFIL PARA MODELADO DE DATOS (PROPUESTO POR AMBLER)
197
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PERFIL PARA MODELADO DE DATOS (PROPUESTO POR AMBLER)
Algunas de las carencias de UML han sido paliadas por RUP (Rational UnifiedProcess, proveniente de una organización que propugnó UML), incluyendoexplícitamente artefactos no-UML tales como reglas de negocio, modelos dedatos y diagramas de flujo de interfaz de usuario
Usemos entonces un enfoque pragmático, tomando a UML como una colecciónde técnicas base que debe suplementarse con otras técnicas para ajustarse alas necesidades específicas de los proyectos
198
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
PERFIL PARA MODELADO DE DATOS (PROPUESTO POR AMBLER)
El siguiente diagrama muestra algunos estereotipos propuestos por Rational.Sería preferible tener esta definición estandarizada por UML puesto que no esprevisible que todo el mundo utilice los mismos estereotipos para definir IU
199
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
DIAGRAMA DE FLUJO DE INTERFACES
200
REFERENCIAS
UML 2 Toolkit by Hans-Erik Eriksson et al.Fast Track UML 2.0 by Kendall ScottUML in Practice by Pascal RoquesUML Distilled: A Brief Guide to the StandardObject Modeling Language, Third Edition by Martin FowlerThe Object Primer: Agile Modeling-Driven DevelopmentWith Uml 2.0 by Scott W. AmblerMDA Distilled: Principles of Model-Driven Architectureby Stephen J. Mellor et al.The Unified Modeling Language User Guide by Grady Booch,Ivar Jacobson, James Rumbaugh
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
http://www.uml.org/http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UMLhttp://www-306.ibm.com/software/rational/uml/resources/uml2/index.html