LENGUAJE UML 2 - horacioamorena.com.arhoracioamorena.com.ar/PAG DE MATERIAS Y LIBROS/LIBROS TODOS... · 4 LENGUAJE UML 2 (Continuación) 8) Diagrama de secuencia –para modelar la

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


1. MODELOS

6


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


2. ANTECEDENTESY

FASES DEDESARROLLO

23


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


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


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


MODELOS: UN MODELO DE PROCESO DE NEGOCIO

27


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


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


MODELOS: DISCIPLINAS Y MODELOS

Las disciplinas tienen asociados modelos y éstos están constituidos porartefactos

30


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


MODELOS: VISIÓN GENERAL DE LA DISCIPLINA

Para cada disciplina se presenta -además- una visión general de los artefactos

32


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)


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


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


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


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


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


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


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


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


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



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



• 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


3. PROCESOUNIFICADO

45


DESCRIPCIÓN GENERAL

46


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


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



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



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



Inicio ElaboraciónConstrucción

1 2 3 ...

Transición

51



52


4. VISIÓNGENERAL

53


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


VISIÓN GENERAL: VISTAS COMO PROYECCIÓN OMT

estructura

comportamiento

55


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


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


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


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


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


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


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


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


VISIÓN GENERAL: EJEMPLO DE VISTA DE DESPLIEGUE

: ServidorAplicacionesBiblioteca

: NodoCualquierCliente

: ServidorBDBiblioteca

«artefacto»

prestatario.jar

«artefacto»

bibliotecario.jar

«artefacto»

comun.jar

64


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


5. DIAGRAMA DEACTIVIDAD

66



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


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



Estado inicial

Actividad

Calle

69



70



Punto dedecisión

71



Estado final

72



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


UNA POSIBLE HISTORIA OMT Barra

sincronizadora

74



A veces puede haber algún objeto que está involucrado en un diagrama deactividad

75


6. MODELADO DECASOS DE USO

76



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


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



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



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



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



Puede haber otro tipo de usuarios

82



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


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



85



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



87



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



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



• 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



• 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



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



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



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



Los casos de uso para nuestro ejemplo del hotel serán:

95



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



Modelo de los aspectos de despliegue:

97


7. DIAGRAMAS DECLASE

98



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


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


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


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



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



Diagramas que pueden resultar útiles (afinidad) al agrupar conceptos deacuerdo a criterios de similitud, dependencia, proximidad, vinculación

Cliente

Libro

104



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



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



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



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



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



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



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



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


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


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


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


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


ASOCIACIONES: MULTIPLICIDAD

Una asociación puede mostrar la multiplicidad

Cuenta

direccionEmailIDclave

verificarClave()

Cliente

InformacionFacturacion

1

1

1*

117


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


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


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


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


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


DEPENDENCIAS

.

CarritoCompra «session bean»SCarritoCompra

«abstraccion»

Pedido«componente»Pedido Fisico

«realiza»

Pedido Pedido«refina»

registrarEnvio()

123


DIAGRAMAS DE CLASES A NIVEL DE DOMINIO

OrdenCompra Envio

Stock

Libro

Categoria Catalogo

Ejemplar

CarritoCompra

Pedido Cliente

CuentaContable

Cuenta

InfoFacturacion

Autor

124


DIAGRAMAS DE CLASES A NIVEL DE ANÁLISIS

OrdenCompra

IDautorizadaPorvencimiento

Stock

Libro

Categoria

Ejemplar

CarritoCompra

Pedido

IDtotalfecha

CuentaContable

Cliente

Cuenta

IDdireccionEmailClave(cifrada)

125


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


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


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


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


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


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


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


8. DIAGRAMA DESECUENCIA

133


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



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



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



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



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



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


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


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



• 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


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



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



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



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


9. DIAGRAMA DEESTADO

147


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


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



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



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


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


10. EXTENSIONESA UML

153


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


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


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


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


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


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


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


11.REPRESENTACIÓN

DEARQUITECTURAS

161


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


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


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


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


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


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


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


12. PATRONES ENARQUITECTURAS

169


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


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


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


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


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


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


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


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


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


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


13. DIAGRAMA DEDESPLIEGUE

180


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


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



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



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


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


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


UN LENGUAJE DE RESTRICCIONES (OCL: OBJECT CONSTRAINT LANGUAGE)

187


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


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


14. LIMITACIONESDE UML

190


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


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


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


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



195



196



197



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



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


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


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

Documents

LENGUAJE UML 2 - horacioamorena.com.arhoracioamorena.com.ar/PAG DE MATERIAS Y LIBROS/LIBROS TODOS... · 4 LENGUAJE UML 2 (Continuación) 8) Diagrama de secuencia –para modelar la