el lenguaje unificado de modelado · web viewsegundo, que el software no puede entender a menos que...

INSTITUTO PLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y

ELECTRICA SECCION DE ESTUDIOS DE POSGRADO

PROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS

MAESTRIA EN CIENCIAS EN INGENIERIA DE SISTEMAS

SISTEMAS DE INFORMACION

ORIENTADOS A OBJETOS

EL LENGUAJE UNIFICADO DE MODELADORESUMEN DEL LIBRO

PROFESOR:ING. JUAN MANUEL MÁRQUEZ

Marzo, 2003

INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA

SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS

EL LENGUAJE UNIFICADO DE MODELADORESUMEN DEL LIBRO

GRADY BOOCHJAMES RUMBAUGH

IVAR JACOBSON

EDITORIAL ADISON WESLEY

Resumen del libro realizado por los alumnos de Agosto a Diciembre 2002Elvira Amaya Flores

Carlos Estrada EspinosaJoel Manrique Ramirez

Contenido:Página de 97 Ing. Juan Manuel Márquez Vite 2



Sección 1 Introducción.........................................................................................2Capítulo 1 Por qué modelamos..........................................................................3Capitulo 2 Presentación de UML ..................................................................... 6Capitulo 3 ¡Hola Mundo!...................................................................................18

Sección 2 Modelado estructural básico..............................................................19Capítulo 4 Clases.............................................................................................20Capítulo 5 Relaciones......................................................................................26Capítulo 6 Mecanismos Comunes...............................................................….35Capítulo 7 Diagramas...................................................................................…38Capítulo 8 Diagramas de clases..................................................................….40

Sección 3 Modelado estructural avanzado....................................................….47Capítulo 9 Características avanzadas de las clases........................................48Capítulo 10 Características avanzadas de las relaciones..................................51Capítulo 11 Interfaces, tipos y roles...................................................................54Capítulo 12 Paquetes.........................................................................................59Capítulo 13 Instancias........................................................................................64Capítulo 14 Diagramas de objetos.....................................................................69

Sección 4 Modelado básico del comportamiento................................................72Capítulo 15 Interaciones......................................................................................73Capítulo 16 Casos de uso....................................................................................78Capítulo 17 Diagramas de Caso de uso...............................................................82Capítulo 18 Diagramas de interación...................................................................86Capítulo 19 Diagramas de actividades.................................................................92

Página de 97 Ing. Juan Manuel Márquez Vite 3



El LENGUAJE UNIFICADO DE MODELADO

SECCION 1

INTRODUCCION




CAPITULO 1

POR QUÉ MODELAMOS

Una empresa de software con éxito es aquélla que produce de una manera consistente software de

calidad que satisface las necesidades de sus usuarios y la empresa; para producir software que cumpla

su propósito, hay que conocer e involucrar a los usuarios de forma disciplinada con el fin de extraer los

requisitos reales del sistema., hay que idear una sólida base arquitectónica que sea flexible al cambio,

software rápido, eficiente, hay que tener gente apropiada y el enfoque apropiado, hay que disponer de un

proceso de desarrollo sólido que pueda adaptarse a las necesidades cambiantes del problema y la

tecnología.

El modelado es una parte central de todas las actividades que conducen a la producción de buen

software.

Construimos modelos para comunicar la estructura y el comportamiento del sistema.

Construimos modelos para visualizar y controlar la arquitectura del sistema.

Construimos modelos para comprender mejor el sistema que estamos construyendo.

Construimos modelos para controlar el riesgo.

La importancia de modelar

El modelar es una técnica de ingeniería probada y bien aceptada; por eso los arquitectos de casas y

rascacielos ayudan a los usuarios a visualizar el producto final, y no solo es parte de la industria de la

construcción, sino en todos los ámbitos se utiliza el modelado.

Un modelo proporciona los planos de un sistema, y estos pueden involucrar planos detallados, así como

los generales que ofrecen una visión global del sistema. Un buen modelo incluye aquellos elementos que

tienen una gran influencia.

En el modelado, conseguimos cuatro objetivos:

Ayudan a visualizar cómo es o queremos que sea un sistema

Permite especificar la estructura o el comportamiento de un sistema

Proporcionan plantillas que nos guían en la construcción de un sistema

Documentan las decisiones que hemos adoptado.




1. Principios del modelado1.- La elección de qué modelos crear tiene una profunda influencia sobre cómo se acomete un problema

y cómo se da forma a una solución.

En el software, los modelos elegidos pueden afectar mucho a nuestra visión

Si construimos un sistema con la mirada de un desarrollador de bases de datos, nos centraremos en los

modelos entidad-relación.

Si construimos un sistema con la mirada de un analista estructurado, se obtendrán modelos centrados en

los algoritmos.

Si construimos un sistema con mirada de un desarrollador orientado a objetos, se centra en una

arquitectura con un mar de clases y patrones de interacciones.

Por lo tanto cada visión del mundo conduce a un tipo de sistema diferente, con diferentes costos y

beneficios.

2. Todo modelo puede ser expresado a diferentes niveles de precisión.Con los modelos de software, a veces un pequeño y sencillo modelo ejecutable de la interfaz del usuario

es exactamente lo que se necesita; otras veces, hay que bajar y enredarse con los bits, como cuando se

están especificando interfaces entre sistemas o luchando con cuellos de botella en redes por ejemplo.

Un analista o un usuario final se centrará en el qué; un desarrollador se centrará en el cómo. Tanto uno

como otros querrán visualizar un sistema a diferentes niveles de detalle en momentos diferentes.

3. Los mejores modelos están ligados a la realidad.En el software, el talón de aquiles de las técnicas de análisis estructurado es el hecho de que hay una

desconexión básica entre los modelos de análisis y el modelo de diseño de sistema. No poder salvar

este abismo hace que el sistema concebido y el sistema construido diverjan con el paso del tiempo.

En los sistemas orientados a objetos, es posible conectar todas las vistas casi independientes de un

sistema en un todo semántico.




4. Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.Dependiendo de la naturaleza del sistema pueden ser más importantes que otros.

MODELADO ORIENTADO A OBJETOS

En el software hay varias formas de enfocar un modelo. Las dos formas más comunes son la perspectiva

orientada a objetos y la perspectiva algorítmica, esta última tiene una visión conduce a los

desarrolladores a centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros

más pequeños y es algo complejo, mientras la visión orientada o objetos el principal bloque de

construcción de todos los sistemas software es objeto o clase, es decir un objeto es una cosa,

generalmente extraída del vocabulario del espacio del problema o del espacio de la solución; una clase

es una descripción de un conjunto de objetos similares.

Actualmente, el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo de

software, simplemente porque ha demostrado ser válido en la construcción de sistemas en toda clase de

dominios de problemas, abarcando todo el abanico de tamaños y complejidades. (UML)




CAPITULO 2

PRESENTACIÓN DE UML

El Lenguaje Unificado de Modelado (Unified Modeling Language, UML), es un lenguaje estándar para

escribir planos de software.

UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema

que involucra una gran cantidad de software.

Visión general de UML UML es un lenguaje para:

Visualizar

Especificar

Construir

Documentar

UML es un lenguajeUn lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación

conceptual y física de un sistema, por lo tanto es un lenguaje estándar para los planos del software.

UML es un lenguaje para visualizarUn programador cuando esta modelando tiene que pensar en:

Primero, la comunicación de esos modelos conceptuales a otros está sujeta a errores a menos que

cualquier persona implicada hable del mismo lenguaje.

Segundo, que el software no puede entender a menos que se construyan modelos que trasciendan el

lenguaje de programación textual.

Tercero, si el desarrollador que escribió el código no dejó documentación sobre los modelos, esa

información se perderá y será parcialmente reproducible a partir de la implementación.

En UML es algo más que un simple montón de símbolos gráficos, en cada símbolo hay una semántica

definida.




UML es un lenguaje para especificarEspecificar, significa construir modelos precisos, no complejos. Y UML cubre las especificaciones de

todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar un sistema

de gran cantidad de software.

UML es un lenguaje para construirEn UML, sus modelos pueden conectarse en forma directa a gran variedad de lenguajes de

programación, esta correspondencia permite ingeniería directa: la generación de código a partir de un

modelo UML en un lenguaje de programación, también se puede reconstruir a partir de una

implementación.

UML es un lenguaje para documentarUna organización de software que trabaje bien produce:

Requisitos

Arquitectura

Diseño

Código fuente

Planificación de proyectos

Pruebas

Prototipos

Versiones

UML cubre la documentación de la arquitectura y proporciona requisitos y pruebas y las actividades de

planificación de proyectos.

¿Dónde puede utilizarse UML?Sistemas de información de empresas

Bancos y servicios financieros

Telecomunicaciones

Transporte

Defensa / industrias aeroespacial

Comercio

Electrónica médica

Ámbito científico

Servicios distribuidos basados en la Web




Un modelo conceptual de UML Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto se requiere

aprender tres elementos principales:

Los bloques básicos de construcción de UML,

Las reglas que dictan cómo se pueden combinar estos bloques básicos

Y algunos mecanismos comunes que se aplican a través de UMLBloques de construcción de UML UML tiene tres clases de bloques de construcción:

Elementos

Relaciones

Diagramas

Los elementos son abstracciones que son cuidados de primera clase en un modelo, las relaciones ligan

estos elementos entre sí; y los diagramas agrupan colecciones interesantes de elementos

ELEMENTOS ESTRUCTURALESSon los nombres de los modelos, son parte estática de un modelo y representan cosas que son

conceptuales, hay 7:

Primero.- Es una clase es una descripción de un conjunto de objetos que

comparten los mismos atributos, operaciones, relaciones y semántica;

implementa una o más interfaces

Ventana Origen Tamaño Abrir() Cerrar() Mover() Dibujar()

Segundo Una interfaz es una colección de operaciones que especifican un

servicio de una clase o componente, esta describe el comportamiento

visible externamente de ese elemento, puede representar el

comportamiento completo de una clase o componente

Una interfaz define un conjunto de especificaciones de operaciones, pero

nunca un conjunto de implementaciones de operaciones.




Tercero, Una colaboración define una interacción y es una sociedad de

roles y otros elementos que colaboran para proporcionar un

comportamiento cooperativo mayor que la suma de los comportamiento de

sus elementos, tienen dimensión tanto estructural como de comportamiento,

estas representan la implementación de patrones que forman un sistema

Una clase puede participar en varias colaboraciones,

Cadena deresponsabilidad

Cuarto Un caso de uso es una descripción de un conjunto de secuencias

de acciones que produce un resultado observable de interés para un actor

en particular, es estructurar los aspectos de comportamiento de un modelo.

Es realizado por una colaboración

Realizar Pedido

Quinto Clase activa, es una clase cuyos objetos tienen uno o más

procesos o hilos de ejecución y por lo tanto pueden dar origen a actividades

de control, presentan elementos cuyo comportamiento es concurrente con

otros.

GestorEventos

Suspender()VaciarCola()

Sexto Un componente es una parte física y reemplazable de un sistema

que conforma con un conjunto de interfaces y proporciona la

implementación de dicho conjunto. Representa típicamente el

empaquetamiento físico de diferentes elementos lógicos, como clases,

interfaces y colaboraciones.

Séptimo Es un Nodo, un elemento físico que existe en tiempo de ejecución

y representa un recurso computacional que por lo general dispone de algo

de memoria y con frecuencia, capa con capacidad de procesamiento.servidor




Los siete elementos anteriores son los estructurales básicos que se puede incluir en un modelo UML.

También existen variaciones de estos siete elementos, tales como actores, señales, utilidades, procesos

e hilos, y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas

Elementos de comportamiento Son las partes dinámicas de los modelos, son los verbos y representan

comportamiento en el tiempo y el espacio. Hay dos tipos principales de elementos de comportamiento:

Primero Una interacción, es un comportamiento que comprende un conjunto de mensajes

intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito

específico. Una interacción, involucra muchos otros elementos, incluyendo mensajes, secuencias de

acción, y enlaces.

Segundo Una máquina de estados es un comportamiento que especifica las secuencias de estados por

las que pasa un objeto o una interacción durante su vida en respuesta a eventos, junto con sus

reacciones a estos eventos.

El comportamiento de una clase individual o una colaboración de clases pueden especificarse con una

máquina de estado, e involucra a otros elementos, incluyendo estados, transiciones, eventos, y

actividades

Estos dos elementos básicos están conectados normalmente a diversos elementos estructurales,

principalmente clases, colaboraciones y objetos.




Elementos de agrupación Son las partes organizativas de los modelos, son cajas en las que puede

descomponerse un modelo. Un paquete es un mecanismo de propósito general para organizar

elementos en los grupos. Los elementos estructurales, los elementos de comportamiento e incluso otros

elementos de agrupación pueden incluirse en un paquete., también es puramente conceptual.

Reglas del negocio

Elementos de anotación Son las partes explicativas de los modelos., pueden aplicar para describir,

clarificar y hacer observaciones sobre cualquier elemento de un modelo, la Nota es simplemente un

símbolo para mostrar las restricciones y comentarios junto a un elemento o una colección de elementos.

Nota

Devuelve una copia delobjeto receptor

RELACIONES EN UML Hay cuatro relaciones:

Primero Dependencia Es una relación semántica entre dos elementos, en la cual un cambio a un

elemento independiente puede afectar a la semántica del otro elemento dependiente

Depéndencias

Segundo Asociación Es una relación estructural que describe un conjunto de enlaces, los cuales son

conexiones entre objetos. La agregación es un tipo especial de asociación, en que representa una

relación estructural entre un todo y sus partes

0....1 *

patrón empleado

Tercero Generalización Es una relación de especialización / generalización en la cual los objetos del

elemento especializado (hijo) pueden sustituir a los objetos del elemento general (padre). De esta forma,

el hijo comparte la estructura y el comportamiento del padre.




Generalizaciones

Cuatro Realización. Es una relación semántica entre clasificadores, en donde un clasificador especifica

un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización

en dos sitios: entre interfaces y las clases y componentes que las realizan, entre los casos de uso y las

colaboraciones que los realizan.

Realización

Estos cuatro elementos son los básicos relacionales y sus variaciones son como el refinamiento, la traza,

la inclusión y la extensión.

DIAGRAMAS DE UML Un diagrama es la representación gráfica de un conjunto de elementos, visualizado la mayoría de las

veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Son 9 los diagramas que incluye

UML

Diagrama de clases Muestra un conjunto de clases, interfaces y colaboraciones, así como sus

relaciones, cubren la vista de diseño estático de un sistema, incluyen clases activas cubren la vista de

procesos estáticos de un sistema.

Diagrama de objetos Muestra un conjunto de objetos y sus relaciones representan instantáneas de

instancias de los elementos encontrados en los diagramas de clase. Cubren la vista de diseño y proceso

estático de un sistema.

Diagrama de casos de uso Muestra un conjunto de casos de uso y actores y sus relaciones Cubren la

vista de casos de uso estática de un sistema.

Estos diagramas son especialmente importantes en el modelado y organización del comportamiento de

un sistema.




Diagrama de secuencia Es un diagrama de interacciones que resalta la ordenación temporal de los

mensajes. Es importante mencionar que los diagramas de interacción entre un conjunto de objetos y sus

relaciones, incluyendo los mensajes que pueden ser enviados entre ellos.

Diagrama de colaboración Es un diagrama de interacción que resalta la organización estructural de los

objetos que envían y reciben mensajes.

Diagrama de estados (statechart) Muestra una máquina de estados, que consta de estados

transiciones, eventos y actividades. Cubren la vista dinámica de un sistema y el comportamiento de una

interfaz, una clase o una colaboración y resaltan el comportamiento dirigido por eventos de un objeto.

Diagrama de actividades Muestra el flujo de actividades dentro de un sistema. Cubren la vista

dinámica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de

objetos.

Diagrama de componentes Muestra la organización y las dependencias entre un conjunto de

componentes, cubren la vista de implementación estática, se relacionan con diagramas de clase en que

un componente se corresponde con una o más clases, interfaces o colaboraciones.

Diagrama de despliegue Muestra la configuración de nodos de procesamiento en tiempo de ejecución y

los componentes que residen en ellos. Su relación con los diagramas de componentes en que un nodo

incluye, uno o más componentes.

Mecanismos comunes de UML Hay cuatro mecanismos que se aplican de forma consistente a través de todo el lenguaje

1. Especificaciones

2. Adornos

3. Divisiones comunes

4. Mecanismos de Extensibilidad.

Las especificaciones, proporcionan una explicación textual de la semántica de ese bloque de

construcción; se utiliza para visualizar un sistema, y también para detallar el sistema.

Las especificaciones en UML proporcionan una base semántica que incluye a todos los elementos de

todos los modelos de un sistema, y cada elemento está relacionado con otros de manera consistente.




Los diagramas de UML son así simples proyecciones visuales de esa base y cada diagrama revela un

aspecto específico interesante del sistema.

Adornos. La notación de la clase también revela los aspectos más importantes de una clase a saber: su

nombre, atributos y operaciones.

La especificación de una clase puede incluir otros detalles, tales como si es abstracta o la visibilidad de

sus atributos y operaciones. Muchos de estos detalles se pueden incluir como adornos gráficos o

textuales en la notación rectangular básica de la clase.

Transacción

+ Ejecutar()

+ Rollback()

# prioridad()

Divisiones comunes, la primer división entre clase y objeto, una clase es una abstracción; un objeto es

una manifestación concreta de esa abstracción;

Arquitectura

Ciente

NombreDirecciónteléfono

Elisa

La segunda división la tenemos entre interfaz e implementación. Una interfaz declara un contrato, y una

implementación representa una realización concreta de ese contrato, responsable de hacer efectiva la

forma fidedigna la semántica completa de la interfaz




Asistenteortog.dll

Mecanismos de Extensibilidad son: Estereotipos

Valores etiquetados

Restricciones

Estereotipo, extiende el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construcción

que deriven de los existentes pero sean específicos a un problema

Valor etiquetado extiende las propiedades de un bloque de construcción de UML, permitiendo añadir

nueva información en la especificación de ese elemento.

Restricción extiende la semántica de un bloque de construcción de UML, permitiendo añadir nuevas

reglas o modificar las existentes.

ARQUITECTURA

Es el conjunto de decisiones significativas sobre:

La organización de un sistema de software

La elección de los elementos estructurales y sus interfaces a través de los cuales constituye el sistema

Su comportamiento, como se especifica en las colaboraciones entre esos elementos.

La composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente

más grandes.

El estilo arquitectónico que guía esta organización: los elementos estáticos y dinámicos y sus interfaces,

sus colaboraciones y su composición.




Vista de Diseño Vista deimplementación

FuncionamientoCapacidad

De crecimiento,rendimiento Modelado de la arquitectura de un sistema

Topología del sistema,Distribucion,Entregainstalación

Ensamblado del sistemaGestión de configuracionesVocabulario,

funcionalidad

Comportamiento

Vista de procesosVista de

Despliegue

Vista de Casos de uso

Vista de Diseño Vista deimplementación

FuncionamientoCapacidad

De crecimiento,rendimiento Modelado de la arquitectura de un sistema

Topología del sistema,Distribucion,Entregainstalación

Ensamblado del sistemaGestión de configuracionesVocabulario,

funcionalidad

Comportamiento

Vista de procesosVista de

Despliegue

Vista de Casos de uso

La vista de casos de uso, describe el comportamiento del sistema tal y como es percibido por los usuarios

finales, analistas y encargados de las pruebas.

La vista de diseño de un sistema comprende las clases, interfaces y colaboraciones que forman el

vocabulario del problema y su solución. Con UML, los aspectos estáticos de esta vista se capturan en los

diagramas de clases y de objetos; los aspectos dinámicos se capturan en los diagramas de interacción,

diagramas de estados y diagramas de actividades.

La vista de procesos de un sistema comprende los hilos y procesos que forman los mecanismos de

sincronización y concurrencia del sistema. Esta vista cubre principalmente el funcionamiento, capacidad

de crecimiento y rendimiento del sistema.

Con UML los aspectos estáticos y dinámicos de esta vista se capturan en el mismo tipo de diagramas

que la vista de diseño, pero con énfasis en las clases activas que representan estos hilos y procesos.

Vista de implementación de un sistema comprende los componentes y archivos que se utilizan para

ensamblar y hacer disponible el sistema físico, se preocupa de la gestión de configuración de las distintas

versiones de un sistema, a partir de componentes y archivos un tanto independientes y que pueden

ensamblarse de varias formas para producir un sistema en ejecución.




La vista de despliegue de un sistema contiene los nodos que forman la topología hardware sobre la que

se ejecuta del sistema, la distribución, entrega e instalación de las partes que constituyen el sistema

físico. En UML los aspectos estáticos de esta vista se capturan en los diagramas de despliegue; los

aspectos dinámicos de esta vista se capturan en los diagramas de interacción, diagramas de estado y

diagramas de actividades.




Capítulo 3

¡Hola, Mundo

En este capítulo

Clases y componentes.

Modelos estáticos y modelos dinámicos

Conexiones entre modelos

Extensión de UML

UML, no es un lenguaje de programación visual, aunque, como se muestra a continuación UML, permite

un alto acoplamiento con varios lenguajes de programación como Java.

UML, está diseñado para permitir transformar los modelos en código y permitir ingeniería inversa del

código a modelos. Algunas cosas se escriben mejor en la sintaxis de un lenguaje de programación

textual, mientras que en otras se visualizan mejor gráficamente en UML.

HolaMundo

Paint( ) g.drawString(“¡Hola, Mundo!”, 10,10)

Este diagrama de clases captura los aspectos básicos de la aplicación "!Hola Mundo"¡, pero deja afuera

varias cosas. Como especifica el código precedente, otras dos clases ()Applet y Graphics intervienen

en la aplicación y cada una se utiliza de forma diferente.

La clase Applet se utiliza como padre* de Hola Mundo y la Clase Graphics se utiliza en la asignatura e

implementación de una de sus operaciones, paint. Estas clases y sus diferentes relaciones como la clase

Hola Mundo se pueden representar en un diagrama de clases,




SECCION 2

MODELADO ESTRUCTURAL BASICO




CAPITULO 4

C L A S E S

“El modelado de un sistema implica identificar las cosas que son importantes desde un cierto punto de

vista particular. Estas cosas forman el vocabulario del sistema que se está modelando.”

QUE SON?Las clases son los bloques de construcción más importantes de cualquier sistema orientado a objetos.

Como se puede observar en la figura, una clase es una descripción de un conjunto de objetos que

comparten los mismos atributos, operaciones, relaciones y semántica.

Figura

origen

Mover()Suspender()VaciarCola()

Nombre

Operaciones

Atributos

Objetivos:

Se utilizan para capturar el vocabulario del Sistema que esta modelando.

Se pueden utilizar para representar cosas que sean software, hardware o puramente

conceptuales.

Las clases bien estructuradas forman parte de una distribución equilibrada de responsabilidades

en el sistema.

Representación gráfica:Esta notación permite visualizar una abstracción (características esenciales de una entidad que la

distingue entre otras entidades, una abstracción define una frontera) independientemente de cualquier

lenguaje de programación especifico y de forma que permite resaltar las partes más importantes de una

abstracción: su nombre, sus atributos, sus operaciones y responsabilidades.




Nombre:Es aquel nombre que la distinga de otras clases. Este nombre es una cadena de texto, y por lo general

son nombres cortos o expresiones nominales extraídos del vocabulario del sistema , y existen 2 tipos :

Nombre simple: Nombre de camino: Nombre de la clase precedido por el nombre

del paquete en el que se encuentra.

Atributos:

Es una propiedad de una clase identificada con un nombre, que describe un rango de valores que pueden

tomar las instancias de la propiedad.

Esta propiedad es compartida por todos los objetos de esa clase.

En un momento dado un objeto de una clase tendrá valores específicos para cada uno de los atributos

de su clase.

Cliente

nombredirecciónteléfono

atributos

Cliente

Nombre: charDirección: charClave: int

NombredirecciónUn atributo se puede especificar más su clase y su valor

Operaciones:

Una operación es una abstracción de algo que se puede hacer a un objeto y que es compartido por todos

los objetos de la clase.




AltaBajascambios

operaciones

Responsabilidades:

Es un contrato o una obligación de la clase, cuando se crea la clase se especifica que todos los objetos

de ésta tienen el mismo tipo de estado y el mismo tipo de comportamiento.

Al modelar las clases, un buen comienzo consiste en especificar las responsabilidades de los elementos

del vocabulario:

-Solicitar pedidos-Presentardocumentación

responsabilidades

Otras características:

A veces se necesita visualizar o especificar otras características, como la visibilidad de atributos y

operaciones individuales, por ejemplo si es polimórfica o constante, de las cuales se hablará en capítulos

posteriores.

Finalmente se dirá que las clases rara vez se encuentran solas. Al construir los modelos uno se centra en

grupos de clases que interactúan entre si. En UML estas sociedades de clases forman colaboraciones y

normalmente se representan en Diagramas de Clases.

Técnicas comunes de modeladoMODELADO DEL VOCABULARIO DE UN SISTEMA:

Los usuarios identifican las abstracciones, extrayéndolas normalmente de objetos que ellos ya usan para

describir su sistema.

Las técnicas como las tarjetas CRC y el análisis de casos de uso son formas para ayudar a los

usuarios a encontrar esas abstracciones.Página de 97 Ing. Juan Manuel Márquez Vite 25



Para modelar el vocabulario de un sistema:

Identificar aquellas cosas que utilizan los usuarios, para describir el problema o la solución.

Para cada abstracción hay que identificar un conjunto de responsabilidades bien repartidas

Definir los atributos y operaciones necesarias en cada clase para cumplir estas

Al ir aumentando de tamaño los modelos, muchas de las clases tienden a agruparse en grupos

relacionados conceptual y semánticamente.

En UML se pueden utilizar los paquetes para modelar estos grupos de clases.

MODELADO DE LA DISTRIBUCIÓN DE RESPONSABILIDADES DE UN SISTEMA:

Una vez que se ha modelado, habrá que asegurarse que se tenga un equilibrio de responsabilidades.

Esto es que no se desea que ninguna clase sea demasiado grande ni demasiado pequeña. UML ayuda a

visualizar y especificar este reparto de responsabilidades.

1.- Identificar unconjunto de clasesque colaboren entreellas para realizar uncomportamiento

2.- Identificarresponsabilidadespara cada una de lasclases

4.- Equilibrar lasresponsabilidadespara que ningunaclase en colaboración

3.- Dividir las clasescon demasiadasresponsabilidades.Así como meter laspequeñas en otrasmayores

Modelar laDistribución deResponsabilidades en un Sistema

MODELADO DE COSAS QUE NO SON SOFTWARE:

UML tiene como objetivo principal el modelado de sistemas con gran cantidad de software, pero a veces,

las cosas que se modelan pueden no tener un equivalente en el software. Para modelar lo que no es

software:




Hay que modelar la cosa que se esta abstrayendo como una clase.

Para distinguirlos de los bloques de construcción de UML . Crear un nuevo bloque de

construcción utilizando estereotipos para especificar la nueva semántica y proporcionar una

representación visual que lo caracterice.

Si lo que se está modelando según el tipo de hardware que a su vez contiene software ,hay que

considerar modelarlo como un tipo de nodo, de forma que más tarde sea posible completar su

estructura.

MODELADO DE TIPOS PRIMITIVOS:

Las cosas que se modelan pueden extraerse directamente del lenguaje de programación que se utilice

para implementar la solución. Normalmente, estas abstracciones involucrarán tipos primitivos ,como

enteros, cadenas e incluso tipos enumerados ,que uno mismo podría crear.

Para modelar tipos primitivos:

Hay que modelar la cosa que se esta abstrayendo como un tipo o una enumeración ,que se

representa como una clase con el estereotipo adecuado.

Si se necesita especificar el rango de valores asociado al tipo ,hay que utilizar restricciones

<<type>>Int

{valores entre-2**31-1 y +2**31}

Sugerencias y consejos:Cada clase debe corresponderse con una abstracción tangible o conceptual en el dominio del usuario

final.

Una clase bien estructurada:

Proporciona una abstracción precisa de algo extraído del vocabulario del dominio del problema o

del dominio de la solución.

Contiene un pequeño conjunto bien definido de responsabilidades, y las lleva a cabo todas y

bien.




Proporciona una distinción bien definida entre la especificación de la abstracción y su

implementación.

Es comprensible y sencilla a la vez que es extensible y adaptable.

Cuando se dibuje una clase:

Hay que mostrar solo aquellas propiedades de la clase que sean importantes para comprender la

abstracción en su conjunto.

Hay que organizar las listas largas de atributos y operaciones, agrupándolos de acuerdo a su

categoría.

Mostrar las clases relacionadas en el mismo diagrama de clases.




CAPITULO 5

R E L A C I O N E S

Las clases son elementos del vocabulario del sistema y no se encuentran aisladas, la mayoría colaboran con otras de varias maneras, es por esto que es importante, modelar como se relacionan estos elementos entre sí.

Que son?

La forma en que las cosas se conectan entre sí, bien lógica o físicamente se modelan como relaciones.

Existen tres tipos de relaciones muy importantes que son: Dependencias, generalizaciones y asociaciones.

Objetivos:

Estos tres tipos de relaciones cubren las formas importantes en que colaboran unas cosas con

otras.

Esta notación permite visualizar relaciones independientemente de cualquier lenguaje de

programación especifico, y de forma que permita destacar las partes mas importantes de una

relación: su nombre, los elementos que conecta y sus propiedades.

Representación gráfica:

Gráficamente una relación se representa por una línea, dependiendo del tipo de relación será el tipo

de línea.

Dependencia

Generalización

Asociación




Dependencias:

Es una relación de uso, en la que un cambio en la especificación de un elemento puede afectar a otro

elemento que la utiliza, pero no necesariamente a la inversa.

Las dependencias se utilizan para indicar que una clase utiliza a otra como argumento en la signatura de

una operación. Se usan cuando se quiera indicar que un elemento utiliza a otro.

Ejemplo:Las tuberías dependen delcalentador para calentar el agua queconducen

Película/Video

Reproducir()Iniciar()

Canal

La clase Película usa o dependede la clase Canal.Si la clase utilizada cambia, laoperación de la otra clase puedeverse también afectada.

Generalización:

Es una relación entre un elemento general (superclase o padre) y un caso más especifico de ese

elemento (subclase o hijo). Se llama a veces “es-un-tipo-de”.

Características:

Los objetos hijos se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a

la inversa.

El hijo puede sustituir al padre, una clase hijos hereda las propiedades de sus clases padres.

El hijo puede añadir atributos y operaciones a los que hereda de sus padres.

Existencia del polimorfismo. Una operación de un hijo con la misma signatura que una operación

del padre redefine la operación del padre.

Una clase puede tener ninguno, uno o más padres.

Una clase sin padre y uno o más hijos se llama clase raíz o clase base.

Una clase sin hijos se llama clase hoja




FiguraorigenMover

cambiarTamaño()dibujar()

RectánguloEsquina:Punto

CirculoRadio:Float

PolígonoPuntos:Lista

cuadrado

generalización

Clase base

Clase hoja

ASOCIACIÓN:

Es una relación estructural que especifica que los objetos de un elemento están conectados con los

objetos de otro.

Las asociaciones se utilizan cuando se quieran representar relaciones estructurales.

Características:

Dada una relación entre dos clases, se puede navegar desde un objeto de una clase hasta un

objeto de la otra clase, y viceversa.

Es posible que ambos extremos de una asociación estén conectados a la misma clase. Esto

significa que, dado un objeto de la clase, se puede conectar con otros objetos de la misma clase.




Binaria Asociación que conecta exactamente dos clases.

Asociaciones

N-arias Asociaciones que conectan más de dos clases.

Adornos que se aplican a las asociaciones:

Nombre:Una asociación puede tener un nombre, que se utiliza para describir la naturaleza de la relación. Se

puede dar una dirección al nombre por medio de una flecha que apunte en la dirección en la que se

pretende que se lea el nombre.

Persona Empresa

Nombre dirección del nombre

Trabaja para

Rol:Una clase tiene un rol especifico que juega en la asociación. Ese rol es la cara que la clase de un

extremo de la asociación presenta a la clase del otro extremo.

Persona Empresa

Se puede nombrar explícitamente el rol que juega una clase, por ejemplo: una personaque juega el rol de empleado esta asociada a una Empresa que juega el rol de patrón.

Empleado patrón

Multiplicidad:

En el modelado es importante señalar “cuantos” objetos pueden conectarse a través de una instancia de

asociación.

“Cuantos” = Multiplicidad del rol de la asociación.

Se escribe como una expresión que se evalúa a un rango de valores o a un valor explicito.




Persona Persona1..* *Empleado patrón

Asociación

Multiplicidad

Agregación:

Una asociación normal entre dos clases representa una relación estructural entre iguales, ambas clases

están al mismo nivel, sin ser ninguna más importante que la otra.

Una agregación representa una relación del tipo “tiene- un” , es decir un objeto del todo tiene objetos de

la parte.

La agregación, es cuando una clase representa una cosa grande (el “todo”), que consta de elementos

más pequeños (las “partes”) .

La agregación es un tipo especial de asociación, y se gráfica añadiendo a una asociación normal un

rombo vació en la parte del todo.

El significado de esta forma es conceptual. El rombo vació distingue el “todo” de la “parte”

Otras características:A veces se necesita visualizar o especificar otras características, como la agregación compuesta,

discriminantes, clases asociación, etc , estas y otras, de las cuales se hablará en capítulos posteriores.

Las dependencias, la generalización y las asociaciones son elementos estáticos que se definen a nivel de

clases.




En UML se muestran normalmente en los “diagramas de clases”.

MODELADO DE DEPENDENCIAS SIMPLES.

El tipo más común de dependencia es la conexión entre una clase que solo utiliza otra como parámetro

de una operación. Para modelar esta relación de uso:

Hay que crear una dependencia que vaya desde la clase con la operación hasta la clase

utilizada como parámetro de la operación.

PlanDelCurso

Añadir(c:Curso)Eliminar(c:Curso) Curso

Iterador

Esta figura muestra unadependencia desdePlanDelCurso hacia Curso,porque Curso se utiliza enlas dos operaciones añadiry eliminar dePlanDelCurso.

MODELADO DE LA HERENCIA SIMPLE

Al modelar el vocabulario de un sistema existen clases similares a otras estructuralmente o en el

comportamiento. Una mejor manera de formar estas es extraer las características comunes de estructura

y comportamiento y colocarlas en clases más generales de las que heredan las clases especializadas.

Para modelar relaciones de herencia:

Dado un conjunto de clases, hay que buscar responsabilidades, atributos y operaciones comunes a

dos o más clases.

Hay que elevar las características anteriores a una clase más general. Si es necesario hay que crear

una nueva, teniendo cuidado de no crear en ella muchos niveles.

Hay que especificar que las clases más específicas heredan de la clase más general, a través de una

relación de generalización, desde cada clase especializada a su padre.




MODELADO DE RELACIONES ESTRUCTURALES.

Cuando se modela con relaciones de asociación, se modelan clases que son del mismo nivel. Dada una

asociación entre dos clases, ambas dependen de la otra de alguna forma y se puede navegar en ambas

direcciones.




Para cada par de clases, si senavega de los objetos de unaa los de otra, hay queespecificar una asociaciónentre las dos (vista dirigidapor datos)

ParaModelar

relacionesestructurales

Si una de las clases es un todo,comparada con las clases en elotro extremo, que parecen laspartes, hay que marcarlas comouna agregación (rombo en eltodo)

Para cada asociación hay queespecificar la multiplicidad(especialmente cuando nosea *, que es el valor pordefecto) así como losnombres de rol.

Si los objetos de una clasenecesitan interactuar con losobjetos de la otra aparte decómo parámetros de unaoperación. Hay queespecificar una asociación.(vista dirigida x comportam)

¿Cómo se sabe cuando deben interactuar los objetos de una clase dada con los objetos de otra

clase? .Las tarjetas CRC y el análisis de casos de uso , son muy útiles pues consideran escenarios

estructurales y de comportamiento. Donde se descubra que dos más clases interactúan, se debe

especificar una asociación.

Ejemplo:

Universidad Departamento

ProfesorCursoEstudiante

1..*

1..*1..*

1..*

1..*

1..*

1..*1 tiene

*0..1director

***

enseña

Asignado AAAAmiembro

asiste

La figura muestra un conjunto de clases en donde:

1. Hay un asociación entre Estudiante y Curso, se detalla que los estudiantes asisten a los cursos.

2. Cada estudiante puede asistir a cualquier número de cursos y cada curso puede tener n-

estudiantes.

3. Existe asociación entre Curso y profesor especificando que los profesores imparten cursos.

4. Para cada curso hay al menos un profesor y cada profesor puede impartir cero o más cursos.

5. Hay relaciones de agregación entre Universidad , Estudiante y Departamento.

6. Una Universidad tiene cero o más estudiantes, cada estudiante puede ser miembro de una o más

universidades.




7. Una Universidad tiene uno o más departamentos y cada departamento pertenece exactamente a

una universidad.

8. Existe la agregación en donde se especifica que Universidad es un todo y que Estudiante y

Departamento son algunas de sus partes

9. Hay dos asociaciones entre Departamento y Profesor. Una de ellas especifica que cada profesor

está asignado a uno o más departamentos y que cada departamento tiene uno o más profesores.

Esto se modela como una agregación, porque organizativa mente los departamentos están a un

nivel superior que los profesores.

10. La otra asociación especifica que para cada departamento hay exactamente un profesor que es

el director del departamento.

Sugerencias y consejos.

Cuando se modelan relaciones en UML:

Hay que usar dependencias solo cuando la relación que se este modelando no sea estructural.

Hay que usar la generalización solo cuando se tenga una relación “es-un-tipo-de”; la herencia

múltiple se puede reemplazar por la agregación.

Hay que tener cuidado de no introducir relaciones de generalización cíclicas.

En general hay que mantener las relaciones de generalización equilibradas.

Hay que usar asociaciones principalmente donde existan relaciones estructurales entre objetos.

Cuando se dibuje una relación en UML:

Hay que utilizar consistentemente líneas rectas u oblicuas. El empleo de ambos tipos de líneas

en el mismo diagrama es útil para llamar la atención sobre diferentes grupos de relaciones.

Hay que evitar los cruces de líneas.

Hay que mostrar solo aquellas relaciones necesarias para comprender una agrupación particular

de elementos. Las relaciones superfluas (especialmente las asociaciones redundantes) deberían

omitirse.




CAPITULO 6MECANISMOS COMUNES

En este capítulo se ve:

Notas, Estereotipo, valores etiquetados y restricciones.

Modelado de comentarios

Modelado de nuevos bloques de construcción.

Modelado de nuevas propiedades.

Modelado de nueva semántica.

Formas de extender UML.

Las notas son el tipo de adorno más importante que pude aparecer aislado. Una nota es un símbolo

gráfico para mostrar restricciones o comentarios asociados a un elemento o a una colección de

elementos.

La nota se utiliza para añadir a un modelo información tal como requisitos, observaciones, revisiones y

explicaciones

Considerar aquí el uso del patrón de diseño

Nota

Los estereotipos, los valores etiquetados y las restricciones son los mecanismos que proporciona UML

para añadir nuevos bloques de construcción, crear nuevas propiedades y especificar nueva semántica.

También permiten introducir nuevos símbolos gráficos, para proporcionar señales visuales en los

modelos, relacionadas con el lenguaje del dominio y la cultura de desarrollo.




“system”Facturación

{versión = 3.2 }

estereotipo

Valor etiquetado

Un valor etiquetado es una extensión de las propiedades de un elemento de UML, permitiendo añadir

nueva información en la especificación de ese elemento. Gráficamente, un valor etiquetado se

representa con una cadena de caracteres entre llaves colocadas debajo del nombre de otro elemento.

Servidor Concentrador{línea > 10M/seg}

Restricción

Nodo estereotipado

Una restricción es una extensión de la semántica de un elemento de UML, que permite añadir nuevas

reglas o modificar las existentes. Gráficamente, una restricción se representa como una cadena de

caracteres entre llaves colocada junto al elemento al que está asociada o conectada a ese elemento por

relaciones de dependencia.

SUGERENCIAS Y CONSEJOS

Cuando se adorne un modelo con notas:

Hay que usar las notas sólo para los requisitos, observaciones, revisiones y explicaciones que no se

puedan expresar de un modo simple y con sentido con las características existentes de UML

Hay que usar las notas como un tipo de notas pos-it electrónicas, para seguir los pasos del trabajo en

desarrollo.

Cuando se dibujen notas.




No hay que complicar los modelos con grandes bloques de comentarios. En vez de ello, si se necesita

realmente un comentario largo, deben usarse las notas como lugar donde enlazar o incluir un documento

que contenga el comentario completo.

Cuando se exista un modelo con estereotipos, valores etiquetados o restricciones:

Hay que homologar un conjunto pequeño de estereotipos, valores etiquetados y restricciones para usar

en el proyecto y evitar que los desarrolladores creen a título individual muchas extensiones nuevas.

Hay que elegir nombres cortos y significativos para los estereotipos y los valores etiquetados.

Donde se pueda relajar la precisión, hay que usar texto libre para especificar las restricciones.

Si es necesario un mayor rigor, puede usar OCL para escribir expresiones de restricciones.




CAPITULO 7

DIAGRAMAS

Diagramas, vistas y, modelos

Modelado de las diferentes vistas de un sistema

Modelado de las diferentes niveles de abstracción

Modelado de vistas complejas

Organización de diagramas y otros artefactos.

Un diagrama es solo una proyección gráfica de los elementos que configuran un sistema.

Normalmente, las partes estáticas de un sistema se representarán mediante uno de los cuatro diagramas

siguientes:

Diagrama de clase

Diagrama de objetos

Diagrama de componentes

Diagrama de despliegue

Para las partes dinámicas

Diagrama de casos de uso

Diagrama de secuencia

Diagrama de colaboración

Diagrama de estado

Diagrama de actividades.

Diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, así como sus

relaciones, cubren la vista de diseño estático de un sistema, incluyen clases activas cubren la vista de

procesos estáticos de un sistema.

Diagrama de objetos muestra un conjunto de objetos y sus relaciones representan instantáneas de

instancias de los elementos encontrados en los diagramas de clase. Cubren la vista de diseño y proceso

estático de un sistema.




Diagrama de casos de uso muestra un conjunto de casos de uso y actores y sus relaciones Cubren la

vista de casos de uso estática de un sistema.

Estos diagramas son especialmente importantes en el modelado y organización del comportamiento de

un sistema.

Diagrama de secuencia Es un diagrama de interacciones que resalta la ordenación temporal de los

mensajes. Es importante mencionar que los diagramas de interacción entre un conjunto de objetos y sus

relaciones, incluyendo los mensajes que pueden ser enviados entre ellos.

Diagrama de colaboración es un diagrama de interacción que resalta la organización estructural de los

objetos que envían y reciben mensajes.

Diagrama de estados (statechart) muestra una máquina de estados, que consta de estados

transiciones, eventos y actividades. Cubren la vista dinámica de un sistema y el comportamiento de una

interfaz, una clase o una colaboración y resaltan el comportamiento dirigido por eventos de un objeto.

Diagrama de actividades muestra el flujo de actividades dentro de un sistema. Cubren la vista

dinámica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de

objetos.

Diagrama de componentes muestra la organización y las dependencias entre un conjunto de

componentes, cubren la vista de implementación estática, se relacionan con diagramas de clase en que

un componente se corresponde con una o más clases, interfaces o colaboraciones.

Diagrama de despliegue muestra la configuración de nodos de procesamiento en tiempo de ejecución y

los componentes que residen en ellos. Su relación con los diagramas de componentes en que un nodo

incluye, uno o mas componentes.




CAPITULO 8

DIAGRAMAS DE CLASES

Los diagramas de clases son los más utilizados en el modelado de sistemas orientados a objetos. Un

diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones.

Los diagramas de clases se utilizan para modelar la vista de diseño estática de un sistema.

Principalmente, esto incluye modelar el vocabulario del sistema, modelar las colaboraciones o modelar

esquemas. Los diagramas de clases también son la base para un par de diagramas relacionados: los

diagramas de componentes y los diagramas de despliegue.

Los diagramas de clases son importantes no sólo para visualizar, especificar y documentar modelos

estructurales, sino también para construir sistemas ejecutables, aplicando ingeniería directa e inversa.

Cuando se construye una casa, se comienza con un vocabulario que incluye bloques de construcción

básicos, tales como paredes, suelos, ventanas, puertas, techos y vigas.

Estos elementos son principalmente estructurales (las paredes tienen una altura, una anchura y un

grosor), pero también tienen algo de comportamiento (diferentes tipos de paredes pueden soportar

diferentes cargas, las puertas se abren y cierran, hay restricciones sobre la extensión de un suelo sin

soporte).

La construcción de software coincide en muchas de estas características con construcción de una casa,

excepto que, dada la fluidez del software, es posible definir bloques de construcción básicos desde cero.

Con UML, los diagramas de clases emplean para visualizar el aspecto estático de estos bloques y sus

relaciones y para especificar los detalles para construirlos, como se muestra en la Figura 8.1.




FIGURA 8.1 Un diagrama de clases

Definición Un diagrama de clases es un diagrama que muestra un conjunto de interfaces,

colaboraciones y sus relaciones. Gráficamente, un diagrama de clases es una colección nodos y arcos.

Propiedades comunesLos diagramas de clases contienen normalmente los siguientes elementos:

Clases. Interfaces. Colaboraciones. Relaciones de dependencia, generalización y asociación.

Los diagramas de clases se utilizan en las siguientes tres formas:




1. Para modelar el vocabulario de un sistema.

2. Para modelar colaboraciones simples.

3. Para modelar un esquema lógico de base de datos.

Para modelar una colaboración:

Hay que identificar los mecanismos que se quieren modelar. Un mecanismo representa una

función o comportamiento de la parte del sistema que se modelando que resulta de la interacción

de una sociedad de clases, interfaces y otros elementos.

Para cada mecanismo, hay que identificar las clases, interfaces y otras colaboraciones que

participan en esta colaboración. Asimismo, hay que identificar relaciones entre estos elementos.

Hay que usar escenarios para recorrer la interacción entre estos elementos. Durante el recorrido,

se descubrirán partes del modelo que faltaban y partes que semánticamente incorrectas.

Hay que asegurarse de rellenar estos elementos con su contenido. Para las clases hay que

comenzar obteniendo un reparto equilibrado de responsabilidades, Después, a lo largo del

tiempo, hay que convertir éstas en atributos y operaciones concretos.

Por ejemplo, la Figura 8.2 muestra un conjunto de clases extraídas de la implementación de un robot

autónomo.

La figura se centra en las clases implicadas en el mecanismo para mover el robot a través de una

trayectoria. Aparece una clase abstracta (Motor) dos hijos concretos, MotorDireccion y MotorPrincipal.

Ambas clases heredan cinco operaciones de la clase padre, motor. A su vez, las dos clases se muestran

como partes de otra clase, Conductor. La clase AgenteTrayectoria tiene una asociación uno a uno con

Conductor y una asociación uno a muchos con SensorColision. No se muestran atributos ni operaciones

para AgenteTrayectoria, aunque sí se indican sus responsabilidades.




Figura 8.2. Modelado de colaboraciones simples.

Modelado de un esquema lógico de base de datosPara modelar un esquema:

Hay que identificar aquellas clases del modelo cuyo estado debe trascender el tiempo de vida de

las aplicaciones.

Hay que crear un diagrama de clases que contenga estas clases y marcarlas como persistentes

(un valor etiquetado estándar). Se puede definir un conjunto propio de valores etiquetados para

cubrir detalles específicos de bases de datos.

Hay que expandir los detalles estructurales de estas clases. En general, esto significa especificar

los detalles de sus atributos y centrar la atención en las asociaciones que estructuran estas

clases y en sus cardinalidades.

Hay que buscar patrones comunes que complican el diseño físico de bases de datos, tales como

asociaciones cíclicas, asociaciones uno a uno y asociaciones n-arias. Donde sea necesario,

deben crearse abstracciones intermedias para simplificar la estructura lógica.

Hay que considerar también el comportamiento de las clases persistentes expandiendo las

operaciones que sean importantes para el acceso a los datos y la integridad de los datos. En

general, para proporcionar una mejor separación de intereses, las reglas del negocio relativas a

la manipulación de conjuntos de estos objetos deberían encapsularse en una capa por encima de

estas clases persistentes.

Donde sea posible, hay que usar herramientas que ayuden a transformar un diseño lógico en un

diseño físico.




La Figura 8.3 muestra un conjunto de clases extraídas de un sistema de información de una universidad.

Esta figura es una extensión de un diagrama anterior, y ahora se muestran las clases a un nivel

suficientemente detallado para construir una base de datos física.

Comenzando por la parte inferior y a la izquierda de este diagrama, se encuentran las clases Estudiante,

Curso y Profesor. Hay una asociación entre

Estudiante y curso, que especifica que los estudiantes asisten a los cursos. Además, cada estudiante

puede asistir a cualquier número de cursos y cada curso puede tener cualquier número de estudiantes.

Figura 8.3. Modelado de un esquema.




Ingeniería directa e inversaPara hacer ingeniería directa con un diagrama de clases:

Hay que identificar las reglas para la correspondencia al lenguaje o lenguajes de implementación

elegidos. Esto es algo que se hará de forma global para el proyecto o la organización.

Según la semántica de los lenguajes escogidos, quizás haya que restringir el uso de ciertas

características de UML. Por ejemplo, UML permite modelar herencia múltiple, pero Smalltalk

sólo permite herencia simple. Se puede optar por prohibir a los desarrolladores el modelado con

herencia múltiple (lo que hace a los modelos dependientes del lenguaje) o desarrollar

construcciones específicas del lenguaje de implementación para transformar estas características

más ricas (lo que hace la correspondencia más compleja).

Hay que usar valores etiquetados para especificar el lenguaje destino. Se puede hacer esto a

nivel de clases individuales si se necesita un control más preciso. También se puede hacer a un

nivel mayor, tal como colaboraciones o paquetes.

Hay que usar herramientas para hacer ingeniería directa con los modelos.

La Figura 8.4 ilustra un sencillo diagrama de clases que especifica una instanciación del patrón cadena

de responsabilidad. Esta instanciación particular involucra a tres clases:

Cliente, GestorEventos y GestorEventosGUI. Cliente y GestorEventos se representan como clases

abstractas, mientras que GestorEventosGUI es concreta. GestorEventos tiene la operación que

normalmente se espera en este patrón (gestionarSolicitud), aunque se han añadido dos atributos

privados para esta instanciación.

Figura 8.4. Ingeniería directa.




Para hacer ingeniería inversa sobre un diagrama de clases:

Hay que identificar las reglas para la correspondencia desde el lenguaje o lenguajes de

implementación elegidos. Esto es algo que se hará de forma global para el proyecto o la

organización.

Con una herramienta, hay que indicar el código sobre el que se desea aplicar ingeniería inversa.

Hay que usar la herramienta para generar un nuevo modelo o modificar uno existente al que se

aplicó ingeniería directa previamente.

Con la herramienta, hay que crear un diagrama de clases inspeccionando el modelo. Por

ejemplo, se puede comenzar con una o más clases, después expandir el diagrama, considerando

relaciones específicas u otras clases vecinas. Se pueden mostrar u ocultar los detalles del

contenido de este diagrama de clases, según sea necesario, para comunicar su propósito.

Sugerencias y consejosUn diagrama de clases bien estructurado:

Se centra en comunicar un aspecto de la vista de diseño estática de un sistema.

Contiene sólo aquellos elementos que son esenciales para comprender ese aspecto.

Proporciona detalles de forma consistente con el nivel de abstracción, mostrando sólo aquellos

adornos que sean esenciales para su comprensión.

No es tan minimalista que deje de informar al lector sobre la semántica importante.

Cuando se dibuje un diagrama de clases:

Hay que darle un nombre que comunique su propósito.

Hay que distribuir sus elementos para minimizar los cruces de líneas.

Hay que organizar sus elementos espacialmente de modo que los que estén cercanos

semánticamente también lo estén físicamente.

Hay que usar notas y colores como señales visuales para llamar la atención sobre características

importantes del diagrama.

Hay que intentar no mostrar demasiados tipos de relaciones. En general, un tipo de relación

tenderá a dominar cada diagrama de clases.




SECCION 3

MODELADO ESTRUCTURAL AVANZADO




CAPITULO 9

CARACTERISTICAS AVANZADAS DE LAS CLASES

Las clases son solo un tipo de clasificador, los clasificadores son los bloques de construcción mas

general en el UML , estos tienen tanto características estructurales como de comportamiento. Así cada

instancia de un clasificador comparten unas mismas características. Los tipos de clasificadores son:

Interfase. Una colección de operaciones

Tipo de dato. Valores no identificados

Señal. Comunicación asíncrona entre las instancias

Componente. Una parte física y reemplazable de un sistema

Nodo. Representa un recurso computacional que posee memoria y capacidad de proceso

Caso de Uso. Secuencia de acciones

Subsistema. Grupo de elementos

Visibilidad

La visibilidad es una característica que indica si puede ser usado por otro clasificador, se dividen en:

public. Puede usarlo cualquiera lo precede un símbolo +

Protected. Solamente los descendientes pueden usarlos lo precede el símbolo #

Private. Unicamente el mismo clasificador puede usarlo

Al realizar diagramas se acostumbra poner solo aquellas características que se emplean en ese momento

no es necesario dibujar las todas a menos que se vayan a usar.

Alcance

Para determinar si una característica de algún clasificador tiene alcance en sus instancias o solo esta

presente en ese clasificador se denota por un una línea, si la característica esta subrayada entonces solo

aparece en el clasificador si no entonces esta presente también en todas las instancias.

Elementos abstractos, raíces, hojas y polimorficos

Si una clase no tiene instancias se dice que es abstracta y se representa con letras itálicas, si la clase no

tiene hijos entonces es una clase hoja. Si la clase no tiene padres entonces se trata de una clase raíz; y




si la clase es polimorfica indica que cualquier mensaje enviado en tiempo de ejecución el tipo de dato es

escogido polimórfica mente.

Multiplicidad

Se refiere al numero de instancias que una clase puede tener como máximo, se especifica con un

numero entero en la parte superior derecha del recuadro de la clase.

Atributos

El nombre del atributo contiene varias características:

Visibilidad

Alcance

Multiplicidad

tipo

Valor inicial

De acuerdo a la nomenclatura establecida anteriormente, existen otros tres atributos:

changeable. No hay restricciones para modificar el valor del atributo

addOnly. Se puede añadir valores, aunque una vez creado ya no es posible deshacer el

cambio

frozen. Inicializado el objeto el valor del atributo no es posible modificarlo

Operaciones

Los nombres de las operaciones también pueden especificar las siguientes características:

Visibilidad

Alcance

Parámetros

Tipo de retorno

Concurrencia

En su forma completa la sintaxis de una operación en UML es

{dirección} nombre: tipo [= valor por default]dirección puede tomar cualquiera de los siguiente valores

in parámetro de entrada. No se puede modificar




out. Parámetro de salida. Puede modificarse para comunicar información de invocador

inout. Parámetro de entrada. Puede ser modificado.

Además de la propiedad left hay otras cuatro que pueden ser usadas con las operaciones

isQuery la ejecución de la operación no cambia el estado del sistema

sequential Los invocadores deben coordinarse para que en el objeto exista un único flujo

guarded La integridad del objeto es asegurada en presencia de múltiples flujos

concurrent Pueden ocurrir múltiples llamadas la integridad del objeto se conserva

Clases plantilla

Definen una familia de clases que pueden ser instanciadas por elementos específicos. Para modelar una

clase plantilla en UML se procede como una clase normal solo que se dibujo un recuadro en la parte

superior derecha que contendrá los parámetros de la plantilla

Técnicas comunes de modelado

Una vez que se han identificado todas las abstracciones el siguiente paso es especificar su semántica.

Se debe decidir el nivel apropiado de detalle para comunicar su modelo. Si usted quiere comunicarse con

usuarios le conviene manejar un nivel bajo, si usted desea establecer un flujo entre los modelos y el

código sus diagramas deben ser formales. Si usted quiere describir matemáticamente un modelo sus

diagramas deben ser muy formales.

Para modelar la semántica de una clase se sigue el siguiente procedimiento

especificar las responsabilidades de cada clase

especificar la semántica de la clase por medio de español estructurado

especificar el cuerpo de cada método

especificar las condiciones de cada operación

especificar una maquina de estados para cada clase

especificar el diagrama de colaboración

especificar las condiciones de cada operación




CAPITULO 10

CARACTERISTICAS AVANZADAS DE LAS RELACIONES

Al modelar sistemas se necesitan de relaciones. Una relación es una conexión entre elementos, se

clasifican en dependencias generalizaciones y asociaciones.

Dependencia

Una dependencia especifica que un cambio en un elemento puede afectar a otro elemento que lo utiliza.

Hay ocho estereotipos que se aplican a las dependencias entre objetos y clases

Bind la dependencia instancia a la plantilla destino con los parámetros reales dados

Derive el origen puede calcularse a partir del destino

Friend el origen tiene una visibilidad especial en el destino

InstanceOf el objeto origen es una instancia del clasificador destino

Instantiate el origen crea instancias del destino

Powertype el destino es un supratipo del origen; un supratipo es u clasificador cuyos objetos son todos los

hijos de un padre dado.

Refine el origen esta en un grado de abstracción más detallado que el destino

Use la semántica del elemento origen depende de la semántica de la parte publica del destino.

Hay dos estereotipos que se aplican a las dependencias entre paquetes

access el paquete origen tiene permiso para referenciar elementos del paquete destino

import los contenidos públicos del paquete destino entran en el espacio de nombres del origen.

Dos estereotipos se aplican a las relaciones de dependencia entre casos de uso

extend el caso de uso destino extiende el comportamiento del origen

include el caso de uso origen incorpora explícitamente el comportamiento de otro

caso de uso.

Hay tres estereotipos que surgen al modelar interacciones entre objetos

become el destino es el mismo objeto que el origen, pero en un instante posterior y

posiblemente con diferentes valores, estados o roles.

call la operación origen invoca a la operación destino

copy el objeto destino es un acopia exacta, pero independiente del origen.




Un estereotipo que aparece en el contexto de las maquinas de estado es send. Especifica que la

operación origen envía el evento destino

Por último hay un estereotipo que aparecerá en el contexto de la organización de los elementos de u

sistema en subsistemas y modelos: trace especifica que el destino es un antecesor histórico del origen.

Generalización

Una generalización es una relación entre un elemento general y un tipo mas especifico de ese elemento

llamado subclase o hijo, este heredara la estructura y comportamiento del padre, aunque puede añadir

nueva estructura y comportamiento, en ocasiones esta herencia es múltiple. UML define un estereotipo

y cuatro restricciones para las generalizaciones.

El estereotipo es implementation, hereda la implementación del padre pero no hace públicas ni soporta

sus interfaces.

Las restricciones son

complete todos los hijos en la generalización se han especificado en el modelo y no se

permiten hijos adicionales

incomplete no se han especificado todos los hijos en la generalización

disjoint los objetos del padre no pueden tener mas de uno de los hijos como tipo

overlapping los objetos del padre pueden tener mas de uno de los hijos como tipo

Asociación

Especifica que los elementos de un objeto se conectan a los objetos de otro. Por ejemplo, una clase

biblioteca podría tener una asociación uno a muchos con una clase libro.

Hay cuatro adornos básicos que se aplican a las asociaciones: nombre, rol en cada extremo de la

asociación, multiplicidad en cada extremo y agregación. Para usos avanzados, hay otras propiedades

que permiten modelar detalles sutiles, como la navegación, calificación y algunas variantes de la

agregación.

Navegación. Se puede representar de forma explícita la dirección de la navegacion con una flecha que

apunte en la dirección de recorrido

Visibilidad Los objetos de una clase pueden ver y navegar hasta los objetos de la otra




Calificación Es un calificador, es un atributo de una asociación cuyos valores particionan el conjunto

de objetos relacionados con un objeto a través de una asociación. Se puede evidenciar el tipo con la

sintaxis

Composición Es realmente una asociación

Clases asociación Es un elemento de modelado con propiedades tanto de asociación como de clase

Restricciones UML define cinco restricciones que se aplican a las asociaciones.

implicitLa relación es solo conceptual

ordered el conjunto de objetos en un extremo de una asociación sigue un orden explícito

changeable Se pueden añadir, eliminar y modificar libremente los enlaces entre los objetos

addOnly se pueden añadir nuevos enlaces

frozen Un enlace, una vez añadido desde un objeto del otro extremo de la asociación, no se puede

modificar ni eliminar.

Realización

Es una relación en la cual un clasificador especifica un contrato que otro clasificador garantiza que

cumplirá. La mayoría de las veces empleara la realización para especificar la relación entre una interfaz y

la clase o el componente que proporciona una operación o servicio para ella. También se utiliza la

realización para especificar la relación entre un caso de uso y la colaboración que realiza ese caso de

uso.

Técnicas comunes de modeladoModelado de redes de relacionesCuando modele redes de relaciones considere que:

No hay que comenzar de manera aislada

comenzar modelándolas relaciones estructurales que estén presentes

Identificar las posibles relaciones de generalización/especialización

buscar dependencias

Hay que comenzar con su forma básica

no es deseable ni necesario modelar un diagrama único

La clave para tener éxito al modelar redes complejas de relaciones es hacerlo de forma incremental




CAPITULO 11INTERFACES, TIPOS Y ROLES

Las interfaces definen una línea entre la especificación de lo que una abstracción hace y la

implementación de cómo lo hace. Una interfaz es una colección de operaciones que sirven para

especificar un servicio de una clase o componente.

Las interfaces se utilizan para visualizar, especificar, construir y documentar las líneas de separación

dentro de un sistema. Los tipos y los roles proporcionan un mecanismo para modelar la conformidad

estática y dinámica de una abstracción con una interfaz en un contexto específico.

Una interfaz bien estructurada proporciona una clara separación entre las vistas externa e interna de una

abstracción, haciendo posible comprender y abordar una abstracción sin tener que sumergirse en los

detalles de su implementación.

INTRODUCCIÓN

No tendría sentido construir una casa donde hubiese que romper los cimientos cada vez que hubiese que

pintar las paredes. Asimismo, nadie desearía vivir en un sitio donde hubiese que reinstalar los cables

cada vez que se cambiara una lámpara. Por ejemplo tenemos que hay tamaños estándar para bloques

de madera, que hacen fácil construir paredes que sean múltiplos de un tamaño común. Hay tamaños

estándar de puertas y ventanas, lo que significa que no hay que construir artesanalmente cada abertura

en el edificio. Incluso hay estándares para los enchufes eléctricos y de teléfono que hacen fácil combinar

y acoplar equipos electrónicos.

Además al elegir las interfaces apropiadas, se pueden tomar componentes estándar, bibliotecas y

frameworks para implementar interfaces, sin tener que construirlas uno mismo. Al ir descubriendo

mejores implementaciones, se pueden reemplazar las viejas sin afectar a sus usuarios.

En UML , las interfaces se emplean para modelar las líneas de separación de un sistema. Una interfaz

es una colección de operaciones que sirven para especificar un servicio de una clase o un componente.

Al declarar una interfaz, se puede anunciar el comportamiento deseado de una abstracción independiente

de una implementación de ella. Los clientes pueden trabajar con esa interfaz, y se puede construir o

comprar cualquier implementación de la misma, siempre que esta implementación satisfaga las

responsabilidades y el contrato indicado en la interfaz.




UML proporciona una representación gráfica de la interfaces, como se muestra en la figura 1. Esta

notación permite ver la especificación de una abstracción separada de cualquier implementación.

TERMINOS Y CONCEPTOSUna interfaz es una colección de operaciones que se usa para especificar un servicio de una clase o de

un componente. Un tipo es un estereotipo de una clase utilizado para especificar un dominio de objetos,

junto a las operaciones aplicables al objeto. Un rol es el comportamiento de una entidad participante en

un contexto particular. Gráficamente, una interfaz se representa como un circulo; de forma expandida,

una interfaz se puede ver como una clase estereotipada para mostrar sus operaciones y otras

propiedades.

NombresCada interfaz ha de tener un nombre que la distinga de otras interfaces. Un nombre es una cadena de

texto. Ese nombre sólo se denomina nombre simple; un nombre de camino consta del nombre de la

interfaz precedido por el nombre del paquete en el que se encuentra. Una interfaz puede dibujarse

mostrando sólo su nombre.

OperacionesCuando se representa una interfaz en su forma normal como un círculo, por definición, se omite la

visualización de estas operaciones. Sin embargo, si es importante para entender el modelo actual, se

puede dibujar una interfaz como una clase estereotipada, listando sus operaciones en el comportamiento

apropiado. Las operaciones se pueden representar sólo con su nombre o pueden extenderse para

mostrar la signatura completa y otras propiedades.




RelacionesAl igual que una clase, una interfaz puede participar en relaciones de generalización, asociación y

dependencia. Además, una interfaz puede participar en relaciones de realización. La realización es una

relación semántica entre dos clasificadores en la que un clasificador especifica un contrato que el otro

clasificador garantiza llevar a cabo.

Una interfaz especifica un contrato para una clase o un componente sin dictar su implementación. Una

clase o un componente puede realizar muchas interfaces. Una interfaz especifica un contrato, y el cliente

y el proveedor de cada lado pueden cambiar independientemente, siempre que cada uno cumpla sus

obligaciones en el contrato.

Comprender una interfazEn UML se puede proporcionar mucha más información a una interfaz para hacerla comprensible y

manejable. En primer lugar, se pueden asociar pre y poscondiciones a cada operación e invariantes a la

clase o componente.

Tipos y rolesUna clase puede realizar muchas interfaces. Una instancia de sea clase debe, por tanto, soportar todas

esas interfaces, ya que una interfaz define un contrato, y cualquier abstracción que conforme con la

interfaz debe, por definición, llevar a cabo fielmente ese contrato.

Por ejemplo, considérese una instancia de la clase persona. Según el contexto, esa instancia de persona

puede jugar el papel de Madre, Asistente Contable, Empleado, Cliente, Directivo, Piloto, Cantante, etc.

En UML se puede especificar el rol que una abstracción presenta a otra abstracción adornando el

nombre de un extremo de la asociación con una interfaz especifica.

Para modelar formalmente la semántica de una abstracción y su conformidad con una interfaz específica,

se utilizará el estereotipo type. Type es un estereotipo de clase, y se emplea para especificar un dominio

de objetos, junto a las operaciones aplicables a los objetos de ese tipo.




Técnicas comunes de ModeladoMODELADO DE LAS LÍNEAS DE SEPARACIÓN DE UN SISTEMA

Cuando se reutiliza un componente de otro sistema o cuando se adquiere a terceros, probablemente lo

único que se tiene es un conjunto de operaciones con alguna documentación mínima sobre el significado

de cada una.

Para modelar las líneas de separación de un sistema:

Dentro de la colección de clases y componentes del sistema, hay que dibujar una línea alrededor

de aquello que tienden a acoplarse estrechamente con otros conjuntos de clases y componentes.

Hay que refinar la agrupación realizada considerando el impacto del cambio. Las clases o

componentes que tienden a cambiar juntos deberían agruparse juntos como colaboraciones.

Hay que considerar las operaciones y las señales que cruzan estos límites, desde instancias de

un conjunto de clases y componentes hacia instancias de otros conjuntos de clases y

componentes.

Hay que empaquetar los conjuntos lógicamente relacionados de estas operaciones y señales

como interfaces.

Para cada colaboración del sistema, hay que identificar las interfaces en las que se basa

(importa) y las que suministra a otros (exporta). Se debe modelar la importación de interfaces con

relaciones de dependencia y la exportación de interfaces con relaciones de realización.

Para cada interfaz del sistema, hay que documentar su dinámica mediante pre y poscondiciones

para cada operación, y casos de uso y máquinas de estados para la interfaz como un todo.

MODELADO DE TIPOS ESTÁTICOS Y DINÁMICOSPara modelar un tipo dinámico:

Hay que especificar los diferentes tipos posibles del objeto, representando cada tipo como una

clase estereotipada con type( si la abstracción requiere estructura y comportamiento) o interfaces

(Si la abstracción sólo requiere comportamiento).

Hay que modelar todos los roles que puede asumir la clase del objeto en cualquier momento.

Esto se puede hacer de dos formas:

1. Primera, en un diagrama de clases, asociar explícitamente un tipo a cada rol que la clase juega en su

asociación con otras clases. Al hacer esto se especifica el aspecto que presentan las instancias de

esa clase en el contexto del objeto asociado.




2. Segunda, también en un diagrama de clases, especificar las relaciones de clases a tipos mediante

generalizaciones.

En un diagrama de interacción, hay que representar apropiadamente cada instancia de la clase

tipada dinámicamente. Debe mostrarse el rol de la instancia entre corchetes debajo del nombre

del objeto.

Para mostrar el cambio del rol de un objeto, hay que dibujar el objeto una vez por cada rol que

juega en la interacción, y conectar estos objetos con un mensaje estereotipado, como become.

Sugerencias y ConsejosAl modelar una interfaz en UML, hay que recordar que cada interfaz debe representar una línea de

separación en el sistema, separando especificación de implementación. Una interfaz bien estructurada:

Es sencilla, aunque completa, y proporciona todas las operaciones necesarias y suficientes para

especificar un único servicio.

Es comprensible, proporcionando suficiente información tanto para permitir su uso como para su

realización sin tener que examinar algún uso ya existente o alguna implementación.

Es manejable, proporcionando información para guiar al usuario hacia sus propiedades claves sin

estar sobrecargado por los detalles de un gran número de operaciones.

Cuando se dibuje una interfaz en UML:

Hay que emplear la notación en forma de pirueta cuando sólo sea necesario especificar la

presencia de una línea de separación en el sistema. La mayoría de las veces esto es lo que se

necesitará para los componentes, no para las clases.

Hay que emplear la forma expandida cuando sea necesario visualizar los detalles del propio

servicio. La mayoría de las veces esto es lo que se necesita para especificar las líneas de

separación en un sistema asociado a un paquete o a un subsistema.




CAPITULO 12PAQUETES

Visualizar, especificar, construir y documentar grandes sistemas conlleva manejar una cantidad de

clases, interfaces, componentes, nodos, diagramas y otros elementos que puede ser muy elevada.

Conforme va creciendo el sistema hasta alcanzar un gran tamaño, se hace necesario organizar estos

elementos en bloques mayores. En UML el paquete es un mecanismo de propósito general para

organizar elementos de modelado en grupos.

Los paquetes bien diseñados agrupan elementos cercanos semánticamente y que suelen cambiar juntos.

Por tanto, los paquetes bien estructurados son cohesivos y poco acoplados, estando muy controlado el

acceso a su contenido.

INTRODUCCIÓNTodos los sistemas grandes se jerarquizar en niveles de esta forma. De hecho, quizás la única forma de

comprender un sistema complejo sea agrupando las abstracciones en grupos cada vez mayores.

UML proporciona una representación gráfica de lo paquetes. Esta notación permite visualizar grupos de

elementos que se pueden manipular como un todo y en una forma que permite controlar la visibilidad y el

acceso a elementos individuales.

Términos y conceptoUn paquete es un mecanismo de propósito general para organizar elementos en grupos. Gráficamente,

un paquete se representa como una carpeta.

NombresCada paquete ha de tener un nombre que lo distinga de otros paquetes. Un nombre es una cadena de

texto. El nombre solo denomina nombre simple; un nombre de camino consta del nombre del paquete

precedido por el nombre del paquete en el que se encuentra, si es el caso. Un paquete se dibuja

normalmente mostrando sólo su nombre.




Elementos contenidos

Un paquete pueden contener otros elementos, incluyendo clases, interfaces, componentes, nodos,

colaboraciones, casos de uso, diagramas e incluso otros paquetes. Si el paquete se destruye, el

elemento es destruido. Cada elemento pertenece exclusivamente a un único paquete.

Sin los paquetes, se acabaría con grandes modelos planos en los que todos los elementos eberían tener

nombre únicos (una situación inimaginable, especialmente cuando se compran clases y otros elementos

desarrollados por varios equipos). Los paquetes ayudan a controlar los elementos que componente un

sistema mientras evolucionan a diferentes velocidades a lo largo del tiempo.

Visibilidad

Se puede controlar la visibilidad de lo elementos contenidos en un paquete del mismo modo que se

puede controlar la visibilidad de loa atributos y operaciones de una clase.

Importación y exportación

Supongamos que tenemos dos clases llamadas A y B, que se conocen mutuamente. Al ser compañeras,

A puede ver a B y B puede ver A, así que cada una depende de la otra. Dos clases tan sólo constituyen

un sistema trivial, así que realmente no se necesita ningún tipo de empaquetamiento.

Generalización

Existen dos tipos de relaciones que pueden darse entre paquetes: las dependencias de acceso e

importación, utilizadas para importar en un paquete los elementos exportados por otro, y las

generalizaciones, para especificar familias de paquetes.

La generalización entre paquetes es muy parecida a la generalización entre clases. Por ejemplo tenemos

que el paquete windowsGUI hereda de GUI, de forma que incluye las clases GUI::Ventana y

GUI::GestorEventos. Además, windowsGUI redefine una clase (Formulario) y añade otra nueva

(VBForm).




Elementos estándarTodos los mecanismos de extensibilidad de UML se aplican a los paquetes.

UML define cinco estereotipos estándar que se aplican a los paquetes:

1. facade Especifica un paquete que es sólo un vista de algún otro

paquete.

2. framework Especifica un paquete que consta principalmente de patrones.

3. Stub Especifica un paquete que sirve de proxy para el contenido público de otro

paquete.

4. Subsystem Especifica un paquete que representa una parte independiente del sistema

completo que se está modelando.

5. System Especifica un paquete que representa el sistema completo que se está

modelando.

UML no especifica iconos para ninguno de estos estereotipos. Además de estos cinco estereotipos de

paquetes, también se emplearán las dependencias con la importación estándar de estereotipos.


MODELADO DE GRUPOS DE ELEMENTOS

El objetivo más frecuente para l que se utilizan los paquetes es organizar elementos de modelado en

grupos a los que se puede dar un nombre y manejar como un conjunto.

Hay una distinción importante entre clases y paquetes: las clases son abstracciones de cosas

encontradas en el problema o en la solución; los paquetes son los mecanismos que se emplean para

organizar los elementos del modelo.

Los paquetes también se pueden emplear para agrupar diferentes tipos de elementos.

Por ejemplo, en un sistema en desarrollo por un equipo distribuido geográficamente, se podría utilizar los

paquetes como las unidades básicas para la gestión de configuraciones, colocando en ellos todas las

clases y diagramas que cada equipo puede registrar y verificar independientemente.




Para modelar grupos de elementos.

Hay que examinar los elementos de modelado de una determinada vista arquitectónica en busca

de grupos definidos por elementos cercanos entre sí desde un punto de vista conceptual o

semántico.

Hay que englobar cada uno de esos grupos en un paquete.

Para cada paquete, hay que distinguir los elementos que podrán ser accedidos desde fuera.

Deben marcarse estos elementos como públicos, y los demás como protegidos o privados. En

caso de duda debe ocultarse el elemento.

Hay que conectar explícitamente los paquetes que dependen de otros a través de dependencias

de importación.

En el caso de familias de paquetes, hay que conectar los paquetes especializados con sus partes

más generales por medio de generalizaciones.

MODELADO DE VISTAS ARQUITECTÓNICAS

El uso de paquetes para agrupar elementos relacionados es importante; no se pueden desarrollar

modelos complejos sin utilizarlos.

Recuérdese que una vista es una proyección de la organización y estructura de un sistema, centrada en

un aspecto particular del sistema.

Para modelar vistas arquitectónicas:

Hay que identificar el conjunto de vistas arquitectónicas que son significativas en el contexto del

problema. En la práctica, normalmente se incluyen una vista de diseño, una vista de procesos,

una vista de implementación, una vista de despliegue y una vista de casos de uso.

Hay que colocar en el paquete adecuado los elementos (y diagramas) necesarios y suficientes

para visualizar, especificar, construir y documentar la semántica de cada vista.

Si es necesario, hay que agrupar aún más estos elementos en sus propios paquetes.

Normalmente existirán dependencias entre los elementos de diferentes vistas. Así que, en

general, hay que permitir a cada vista en la cima del sistema estar abierta al resto de vistas en el

mismo nivel.




SUGERENCIAS

Cuando se modelan paquetes en UML hay que recordar que existen sólo para ayudar a organizar los

elementos del modelo. Si se tienen abstracciones que se manifiestan como objeto en el sistema real, no

se deben utilizar paquetes. En vez de ello, se utilizarán elementos de modelado, tales como clases o

componentes. Un paquete bien estructurado:

Es cohesivo, proporcionando un límite bien definido alrededor de un conjunto de elementos

relacionados.

Está poco acoplado, exportando sólo aquellos elementos que otros paquetes necesitan ver

realmente, e importando sólo aquellos elementos necesarios y suficientes para que los elementos

del paquete hagan su trabajo.

No está profundamente anidado, porque las capacidades humanas para comprender estructuras

profundamente anidadas son limitadas.

Posee un conjunto equilibrado de elementos; los paquetes de un sistema no deben ser

demasiado grandes en relación a los otros (si es necesario, deben dividirse) ni demasiado

pequeños (deben combinarse los elementos que se manipulen como un grupo).

Cuando se dibuje un paquete en UML:

Hay que emplear la forma simple del icono de un paquete a menos que sea necesario revelar

explícitamente el contenido.

Cuando se revele el contenido de un paquete, hay que mostrar sólo los elementos necesarios

para comprender el significado del paquete en el contexto.

Especialmente si se están usando los paquetes para modelar elementos sujetos a una gestión de

configuraciones, hay que revelar los valores de las etiquetas asociadas a las versiones.




Capítulo 13

I n s t a n c i a s

Una instancia es una manifestación concreta de una abstracción a la que se puede aplicar un conjunto de

operaciones y que posee un estado que almacena el efecto de las operaciones. Instancia y Objeto son

sinónimos.

Los objetos son instancias de clases, todos los objetos son instancias aunque algunas instancias no son

objetos (por ejemplo, una instancia de una asociación no es un objeto es solo una instancia llamada

enlace. Una abstracción denota la esencia ideal de una cosa;

Una instancia denota una manifestación concreta así en una instancia habrá una abstracción que

especifique las características más comunes a todas las instancias.

Las instancias no aparecen aisladas están ligadas a una abstracción en la mayoría de las instancias que

se modelen en UML serán instancias de clases (estas se llama objetos. Para identificar una instancia se

subraya el nombre.

Instancias:

Teclas pulsadas: ColaInstancia con nombre

Instancia anónima: Marco

Una clase abstracta no pudo tener instancias directas sin embargo se pueden modelar instancias

indirectas; Cuando se modelan instancias, estás se colocan en los diagramas de objetos o en diagramas

de interacción y de actividades para esto se necesita.

NOMBRES

Cada instancia debe tener un nombre que la distinga de las otras instancias dentro de su contexto, un

nombre es una cadena de texto de una operación. Cuando se da nombre a un objeto se puede dar

nombre simple a un objeto tal como un cliente.




En muchos casos el nombre real de un objeto sólo es conocido por el computador en el que existe en

tales casos se representa un objeto anónimo tal como Multimedia: :AudioStream , Incluso si se conoce la

abstracción asociada al objeto se le puede dar un nombre explícito tal como agente.

Especialmente cuando se modelan grandes colecciones de objetos se denominan multiobjetos(tal como:

código clave) como se muestra a continuación.

: Multimedia:: AudioStream

mi cliente

Instancia anónima

Instancia con nombre

T: Transacción

Instancia huérfanaAgente :: código clave: código clave

multiobjeto

El nombre de una instancia puede ser texto formado por cualquier número de letras excepto signos como

los dos puntos que se utilizan para separar el nombre de una instancia del nombre de su abstracción.

OperacionesLas operaciones que se pueden ejecutar sobre un objeto se declaran en la abstracción del objeto se

puede definir la operación commit() entonces dada la instancias cual sea t se puede escribir las

expresiones como t.commit() donde commit es la (operación.

EstadoUn objeto también tiene estado, este incluye todas las propiedades (normalmente estáticas. Estas

propiedades incluyen los atributos del objeto.

Ejemplo:

Mi Cliente

Id: SSN =”432-89-1783”Activo =True

C: teléfono[esperando Respuesta]

Instancia con estado explícito

Instancia con valores de atributos




Otras características

Los procesos e hilos con un elemento de la vista de procesos de un sistema, proporcionan una señal

visual para distinguir los elementos activos (aquellos que representan una raíz de un flujo de control)de

los pasivos. La mayoría de las veces utilizarán los objetos activos que modelan múltiples flujos de control.

Y puede utilizarse para nombrar a distintos flujos.

Por lo tanto un enlace es una conexión semántica entre objetos. Una instancia de una asociación es por

tanto un enlace, un enlace se representa con una línea, al igual que una asociación puede distinguirse

porque los enlaces sólo conectan objetos. Un atributo o una operación de clase. Una característica de

clases es un objeto de clase compartido para todas las instancias de la clase.

Elemento estándar

Normalmente no se aplica un estereotipo directamente a una instancia ni se le da un valor etiquetado

propio. En vez de eso se derivan del estereotipo y valores etiquetados de su abstracción asociada.

UML define dos estereotipos:

1. -InstanceOf Especifica que el objeto origen es una instancia del clasificador destino

2. -Instantiate Especifica que la clase origen crea instancias de la clase destino.

También hay dos estereotipos relacionados:

1. -become Especifica que el destino es le mismo pero en un instante posterior y con valor,

estados o roles posiblemente diferentes.

2. -Copy Especifica que el objeto destino es una copia exacta pero independiente del origen.

UML define una restricción:

Transient Especifica que una instancia del rol es creada durante la ejecución de la interacción

que lo engloba pero se destruye antes de complementar la ejecución.




Técnicas comunes de Modelado.

MODELADO DE INSTANCIAS CONCRETAS

Una de las cosas para las cosas para las que se emplean los objetos es para modelar instancias

concretas éste podría mostrar las relaciones estructurales entre instancias dibujando un diagrama de

objetos.

Para modelar instancias concretas:

Hay que identificar aquellas instancias necesarias para visualiza especificar, construir o documentar el

problema que se está modelando.

Hay que representar objetos en UML como instancias sea posible, hay que dar un nombre a cada

objeto. Si no hay un nombre significativo puede representarse como un objeto anónimo.

Hay que mostrar el estereotipo, los valores etiquetados y los tributos y suficientes para modelar el

problema.

Hay que representar estas instancias y sus relaciones en un diagrama de objetos u otro diagrama

apropiado al tipo de instancia (nodo, componente, etc.). Ejemplo

Actual : Transacción

Agente Principal

[trabajando]

Agente Fraudes

: Transacción: Transacción

<<instanceOf>

MODELO DE INSTANCIAS PROTOTÍPICAS

La utilización más importante que se hace de las instancias es modelar las interacciones dinámicas entre

objetos. Generalmente cuando se modelan tales interacciones, no se están modelando instancias

concretas. Más bien modelan objetos conceptuales son básicamente proxies o sustitutos estos son

objetos prototípicos por tanto son con los que conforman instancias.




La diferencia semántica entre objetos concretos y objetos prototípicos solamente importante para

modeladores avanzados. UML utiliza el término rol clasificador para denotar un rol con el que conforman

algunas instancias, los objetos concretos aparecen en lugares estáticos, tales como diagramas de

objetos, diagramas de componentes, de despliegue. Los objetos prototípicos aparecen como los

diagramas de interacción y los diagramas de actividades.

Para modelar instancias prototípicas:

Hay que identificar aquellas instancias prototípicas para visualizar, especificar, construir o documentar el

problema.

Representar objetos en UML como instancias.

Hay que mostrar las propiedades de cada instancia necesarias y suficientes para modelar el problema.

Hay que representar estas instancias y sus relaciones en un diagrama de interacción o de actividades.

Ejemplo

A : Agente LlamadaC: Conexión

T1 : Terminal T2 : Terminal

2: activar Conexión

1 : crear2.1: Iniciar CostoLlamada

1.1 : añadir1.2: añadir

Toda instancia debe denotar una manifestación concreta de alguna abstracción, normalmente una clase

componente nodo caso de uso o asociación.




Capítulo 14

Diagramas de Objetos

Un diagrama de objetos es un diagrama que representa la parte estática de una interacción consistiendo

en los objetos que colaboran pero sin ninguno de los mensajes enviados entre ellos, este también

representa un conjunto de objetos y sus relaciones en un momento concreto. Gráficamente, un diagrama

de objetos es una colección de nodos y arcos o enlaces.

Sus propiedades es un tipo especial de diagrama que comparte las propiedades comunes al resto de los

diagramas (un nombre y un contenido grafico para el desglose para proyección del modelo) Lo que puede

distinguir al diagrama de objetos de entre los demás es su contenido particular.

Para los diagramas de objetos normalmente contienen:

Objetos

Enlaces

Y la igual puede tener notas y restricciones.

Los diagramas de Objetos pueden contener paquetes o subsistemas los que se usan para agrupar

elementos de un modelo en partes más grandes

Usos comunes

En los diagramas de objetos se emplean usualmente para darle una perspectiva de instancias reales o

prototípicas.

Al modelar la vista diseño estática o la vista de procesos estática de un sistema normalmente los

diagramas de objetos se utilizan para modelar estructuras de objetos, esto implica tomar los objetos en

un sistema en cierto momento. Un diagrama de objetos representa una escena estática dentro de la

historia representada por un diagrama de interacción.

Los Diagramas se emplean para especificar, construir documentar ciertas instancias en el sistema con

sus relaciones.




Técnicas comunes de modeladoModelado de estructuras de Objetos

Con los diagramas de objetos no se puede especificar completamente la estructura de objetos del

sistema puede existir una multitud de posibles instancias de una clase particular y para un conjunto de

clases con relaciones entre ellas pueden existir muchas más configuraciones posibles de esos objetos. Al

utilizar diagramas de objetos se pueden mostrar significativamente conjuntos interesantes de objetos

concretos o prototípicos.

Para modelar una estructura de Objetos:

Hay que identificar el mecanismo que se desea modelar, un mecanismo representa alguna

función o comportamiento de la parte del sistema que se está modelando.

Cada mecanismo hay que identificar las clases, interfaces y otros elementos que participan en la

colaboración del mecanismo.

Considerar el escenario en le que intervenga este mecanismo así también cada objeto que

participe en el mecanismo.

Hay que mostrar el estado y valores de los atributos de cada uno de los objetos.

Mostrar los enlaces entre estos objetos que representan las instancias.

R: Robot[movimiento]

m : Mundo : Elemento

A1 : Área A1 : Área

P1: Pared

Anchura = 36

P3: Pared

Anchura = 96

D8: Puerta

Anchura = 36

P2: Pared

Anchura = 96

<<global>>

sin Asignar




INGENIERÍA DIRECTA E INVERSA.

Hacer Ingeniería Directa es la creación de un código a partir de un modelo esto con un diagrama de

objetos, aunque a veces este limitado ya que las instancias son creadas y destruidas por la aplicación en

tiempo de ejecución por lo tanto se puede instanciar los objetos desde el exterior.

La Ingeniería Inversa es algo muy distinto es mientras sé esta depurando el sistema, esto es algo que el

programador o las herramientas están haciendo continuamente ir tomando seguimientos para verificar el

recorrido del proceso en ciertos pasos o tiempos para reconocer donde se invalida el proceso y así poder

corregir el estado de los objetos.

Para hacer Ingeniería inversa con un diagrama de objetos:

Hay que elegir el objetivo este se establecerá en el contexto dentro de una operación.

Detener la ejecución en un determinado instante utilizando herramientas o simplemente

recorriendo un escenario.

Hay que identificar el conjunto de objetos que colaboran en le texto representarlos en el diagrama

de objetos.

Mostrar el estado de estos objetos

Si el diagrama termina complicándose hay que recortarlo eliminando aquellos objetos que no

sean pertinentes para las cuestiones sobre los escenarios. Si el diagrama es demasiado simple

hay que expandir los vecinos de objetos interesantes para mostrar una mayor profundidad de los

objetos.

En los diagramas de objetos en UML para que estén bien estructurados deben tomarse en cuenta

El diagrama se centra en un aspecto de diseño estática o la vista de un proceso estática de un

sistema.

Representa una escena histórica presentada por un diagrama de interacción.

Solo elementos esenciales que comprenden ese aspecto.

Forma consistente en el nivel de abstracción mostrando solo aquellos valores de atributos y otros

procesos para su comprensión.

Darle un nombre que comunique su propósito. , Minimizar los cruces de las líneas organizar los

elementos de manera semántica utilizar comentarios y relevantes.

Hay que incluir los valores, estado y rol de cada objeto, si es necesario para comunicar su

propósito.Página de 97 Ing. Juan Manuel Márquez Vite 74



SECCION 4

MODELADO BASICO DEL COMPORTAMIENTO




Capítulo 15

I N T E R A C C I O N E SIntroducción

En UML, los aspectos estáticos de un sistema se moderan mediante elementos tales como los diagramas

de clases y los diagramas de objetos. Estos diagramas permiten especificar, construir y documentar los

elementos del sistema, incluyendo clases, interfase es, componentes, nodos y casos de uso e instancias

de ellos, así como la forma en la que estos elementos se relacionan entre sí.

En UML, los aspectos dinámicos de un sistema se modelan mediante interacciones. Al igual que un

diagrama de objetos, una interacción tiene una naturaleza estática, ya que establece el escenario para un

comportamiento del sistema introduciendo todos los objetos que colaboran para realizar alguna acción.

Pero, a diferencia de los diagramas de objetos, las interacciones incluyen los mensajes enviados entre

objetos. La mayoría de las veces, un mensaje implica la invocación de una operación o el envío de una

señal; un mensaje también puede incluir la creación o la destrucción de objetos.

Las interacciones se utilizan para modelar el flujo de control dentro de una operación, una clase, un

componente, un caso de uso o el propio sistema.

t : Planif icadorTraf icoAereo p: PlanDeVuelo1: obtenerPosicion

1.1: obtenerUlt imoControl()

objeto

Número de Secuencia

Enlace Mensaje

Figura 1 Mensajes, enlaces y secuenciamiento

Términos y conceptos

Una interacción es un comportamiento que comprende un conjunto de mensajes intercambiados entre un

conjunto de objetos dentro de un contexto que alude a un propósito. Un mensaje es la especificación de

una comunicación entre objetos que transmite información, con la expectativa de que se desencadenara

una actividad.




Contexto

Una interacción puede aparecer siempre que unos objetos estén enlazados a otros.

Objetos y roles

Los objetos que participan en una interacción son o bien elementos concretos o bien elementos

prototípicos. Como elemento concreto, un objeto representa algo del mundo real. Por ejemplo, una

instancia de la clase persona, podría de notar a una persona particular.

Enlace

Un enlace es una conexión semántica entre objetos. En general, un enlace es una instancia de una

asociación.

Un enlace especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro (o

asimismo).

Mensajes

Un mensajero es la especificación de una comunicación entre objetos que transmite información, con la

expectativa de que se desencadenara una actividad. La recepción de una instancia de un mensaje puede

considerarse una instancia de un evento.

Cuando es un mensaje, la acción resultante es una instrucción ejecutable que constituye una abstracción

de un procedimiento computacional. Un acción puede producir un cambio en el estado.

En UML , se puede modelar varios tipos de acciones.

Llamada Invoca una operación sobre un objeto; un objeto puede enviarse un mensaje a sí

mismo, lo que resulta en la invocación local de una operación.

Retorno Devuelve un valor al invocador.

Envío Enviar una señal a un objeto.

Creación Crear un objeto.

Destrucción Destruye un objeto; un objeto puede suicidarse al destruirse asimismo.

Secuenciación




Cuando un objeto envía un mensaje a otro, el objeto receptor puede, a su vez, enviar un mensaje a otro

objeto, el cual puede enviar un mensaje a otro objeto diferente, etc. este flujo de mensajes forma una

secuencia.

Creación modificación y destrucción

La mayoría de las veces, los objetos que participan en una interacción existen durante todo el tiempo que

dura la interacción. Sin embargo, algunas interacciones pueden conllevar la creación y destrucción de

objetos. Para especificar si un objeto un enlace aparece y/o desaparece durante una interacción, se

puede asociar una de las siguientes restricciones al elemento:

new Especifica que la instancia o el enlace se crea durante la ejecución de la

interacción que la contiene.

destroyed Especifica que la instancia o el enlace se destruye antes de completarse la

ejecución de la interacción que la contiene.

transient Especifica que en la instancia o el enlace se crea durante la ejecución de la

interacción que la contiene, pero se destruye antes de completarse su ejecución

Representación

Dándose mote la una interacción, normalmente se incluirán tanto objetos como mensajes.

Los objetos y mensajes implicados en una interacción se pueden visualizar de dos formas: destacando la

ordenación temporal de sus mensajes, o destacando la organización estructural de los objetos que

envían y reciben los mensajes. En UML , el primer tipo de representación se llama diagrama de

secuencia; el segundo tipo de representación se llama diagrama de colaboración, siendo estos dos del

tipo de diagramas de interacción.




Técnicas comunes de modeladoMODELADO DE UN FLUJO DE CONTROL

Para modelar un flujo de control:

Hay que establecer el contexto de la interacción, si es el sistema global, una clase o una operación

individual.

Hay que establecer el escenario para la interacción, identificando que objetos juegan un rol; deben

establecer sus propiedades iniciales, los valores de sus atributos, estado y rol.

Si el modelado destaca la organización estructural de esos objetos, hay que identificar los enlaces

que los conectan y que sean relevantes para los trayectos de comunicación que tienen lugar en la

interacción. Si es necesario, hay que especificar la naturaleza de los enlaces con los estereotipos de

estándar y las restricciones de UML .

Hay que especificar los mensajes que pasan de 1 objetó otro mediante una ordenación temporal. Si

es necesario, hay que distinguir los diferentes tipos de mensajes; se deben incluir parámetros y

valores de retorno para expresar los detalles necesarios de las interacciones.

Para expresar los detalles necesarios de la interacción, hay que adornar cada objeto con su estado y

rol, siempre que sea preciso.

Sugerencias y consejos

Cuando se modelan interacciones en UML, hay que recordar que cada interacción representa los

aspectos dinámicos de una sociedad de objetos. Una interacción bien estructurada:

Es sencilla y debe incluir sólo aquellos objetos que colaboran para llevar a cabo algún

comportamiento mayor que la suma de los comportamientos de esos elementos.

Tiene un contexto claro y puede representar la interacción de objetos en el contexto de una

operación, una clase o el sistema completo. Es eficiente y debe llevar a cabo su comportamiento con

un equilibrio óptimo de tiempo y recursos.

Es adaptable y los elementos más proclives a cambiar deberían al separar que puedan ser fácilmente

modificados.




Es comprensible y debería ser sencilla, y no debe incluir trucos, efectos laterales ocultos ni semántica

oscura.

Cuando se dibuje una interacción en UML:

Hay que elegir el aspecto destacar que en la interacción. Se puede destacar la ordenación temporal

de los mensajes con la secuencia de los mensajes en el contexto de alguna organización estructural

de objetos. No se pueden hacer ambas cosas al mismo tiempo.

Hay que mostrar sólo aquellas propiedades de cada objeto (valores de atributos, rol y estado) que

sean importantes para comprender la interacción en su contexto.

Hay que mostrar sólo aquellas propiedades de los mensajes (parámetros, semántica de

concurrencia, valor de retorno) que sean importantes para comprender la interacción en su contexto.




Capítulo 16

CASOS DE USO

Los casos de uso bien estructurados denotan sólo comportamientos esenciales del sistema o de un

subsistema.

Introducción

Un caso de uso describe un conjunto de secuencias donde cada secuencia representa la interacción de

los elementos externos al sistema (sus actores) con el propio sistema(y con sus abstracciones claves).

En realidad, un estos comportamientos son funciones a nivel del sistema que se utilizan durante la

captura de requisitos y la análisis para visualizar, especificar, construir y documentar el comportamiento

esperado del sistema.

Un caso de uso involucra la interacción de actores y el sistema. Un acto representa un conjunto

coherente de roles que juegan los usuarios de los casos de uso al interactuar con estos. Los actores

pueden ser personas o puede ser sistemas mecánicos.

Los casos de uso se pueden aplicar al sistema completo. También se pueden aplicar a partes del

sistema, incluyendo sus sistemas e incluso clases de interfases individuales.

ResponsablePrestamos Procesar préstamo

nombre

actor caso de uso

Figura 2 Actores y casos de uso




Términos y conceptosNombres

Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso.

Casos de uso y actoresUn actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan en

interacción con estos. Normalmente, un acto representa un rol que es jugado por una persona, un

dispositivo hardware o incluso otro sistema al intelectual con nuestro sistema.

Los actores sólo se pueden conectar a los casos de uso a través de asociaciones. Una asociación entre

un actor y un caso de uso indican que el actor y el caso de uso se comunican entre sí, y cada uno puede

enviar y recibir mensajes.

Cliente comercial

Cliente

actor

actor

generalización

Figura 3 Actores

Casos de uso y flujo de eventosUn caso de uso describe que hace un sistema pero no especifica cómo lo has.

El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma

textual, lo suficientemente claro para que alguien ajeno al sistema lo entienda fácilmente.

Nota: el flujo de lentos de un caso de uso se puede especificar de muchas formas, incluyendo texto

estructurado y formal(como el ejemplo anterior), un texto estructurado formal (con pre y poscondiciones) y

pseudo código.

Casos de uso y escenarios

Normalmente, primeros se describe el flujo de eventos de un caso de uso mediante texto. Se usa un

diagrama de secuencia para especificar el flujo principal de un caso de uso, y se usan variaciones de ese

diagrama para especificar los flujos excepcionales del caso de uso.




Casos de uso y colaboraciones

El objetivo de la arquitectura de un sistema es encontrar el conjunto mínimo de colaboración es bien

estructuradas que satisfacen el flujo de eventos, especificado en todos los casos de uso del sistema.

Organización de casos de usoLos casos de uso también pueden organizarse especificando relaciones de generalización, inclusión y

extensión de entre ellos. Que estas relaciones se utilizan para factor izar el comportamiento común y

para factores a variantes. La generalización entre casos de uso es como la generalización entre clases.

Una relación de inclusión entre casos de uso significa que un caso de uso base incorpora explícitamente

comportamiento de otro caso de uso en el lugar especificado en el caso base. Una relación de extensión

entre casos de uso significa que un caso de uso base incorpora implícitamente comportamiento de otro

caso de uso en el lugar de especificados indirectamente por el caso de uso que extiende a la base.

Otras características

Los casos de uso también son clasificadores, de forma que pueden tener operaciones y atributos que se

pueden representar igual que en las clases.

Como clasificador es que son, también se pueden asociar máquinas de Estados a los casos de uso. Las

máquinas de Estados se pueden usar como otra forma de describir el comportamiento representado por

un caso de uso.


MODELADO DEL COMPORTAMIENTO DE UN ELEMENTO

Cuando se modelan comportamiento de estos elementos, es importante centrarse en lo que hace el

elemento, no en como lo hace.

Para modelar el comportamiento de un elemento:

Hay que identificar los actores que interactúan con el elemento.

Hay que organizar los actores identificando tanto los roles más generales como los más

especializados.

Hay que considerar las formas más importantes que tiene cada actor de interactuar con el elemento.

Hay considerar también las formas excepcionales en las que cada actor puede interactuar con el

elemento.

Hay que organizar estos comportamientos como casos de uso.

Sugerencias y conceptos

Un caso de uso bien estructurado:




Nombra un comportamiento simple, identificable y razonablemente atómico del sistema o parte

del sistema.

Factoriza el comportamiento común, incorporando ese comportamiento desde otros casos de uso

que incluye.

Factoriza las variantes, colocando ese comportamiento en otros casos de uso que lo extiende.

Describe el flujo de eventos de forma suficientemente clara para que alguien externo al sistema

no entienda fácilmente.

Se describe por un conjunto mínimo de escenarios que especifica la semántica normal y de las

variantes del caso de uso.

Cuando se dibuje un caso de uso en UML :

Hay que mostrar sólo aquellos casos de uso que sean importantes para comprender el

comportamiento del sistema o parte del sistema en su contexto.

Hay que mostrar sólo aquellos factores relacionados con ese caso de uso.




Capítulo 17DIAGRAMAS DE CASOS DE USO

Los diagramas de casos de uso son uno de los cinco tipos de diagramas en UML que se utilizan para el

modelado de los aspectos dinámicos de un sistema (los otros cuatro tipos son los diagramas de

actividades, de Estados, de secuencia y de colaboración). Los diagramas de casos de uso son

importantes para modelar el comportamiento de un sistema, un subsistema o una clase. Cada uno

muestra un conjunto de casos de uso, un actor y sus relaciones.

Teléfono móvi l

Usuario

Usar agenda

Red telef ónica

actor

Realizar llamada de conf erenciaRealizar llamada teléf onica

Recibir llamada adicionalRecibir llamada teléf onica

casos de uso

frontera del sistema

Figura 4 Un diagrama de casos de uso

Términos y conceptos

Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus

relaciones.

Usos comunes

Se emplean para modelar la vista de casos de uso estática de un sistema. Esta vista cubre

principalmente el comportamiento del sistema.





MODELADO DEL CONTEXTO DE UN SISTEMA

En UML se puede modelar el contexto de un sistema con un diagrama de casos de uso o, destacando los

actores en torno al sistema. La decisión sobre que incluir como una todos es importante, porque al hacer

esos especifica un tipo de cosas que entre actúan con el sistema. Para modelar contexto del sistema:

Hay que e identificar los actores en torno al sistema.

Hay que organizar los actores similares en jerarquías de generalización/ especialización.

Hay que proporcionar un estereotipo para cada uno de esos actores, si así se ayuda a entender

el sistema.

Hay que Introducir esos actores en un diagrama de casos de uso y especificar las vías de

comunicación de cada toro con los casos de uso del sistema.

MODELADO DE LOS REQUISITOS DE UN SISTEMA

Un requisito es una característica de diseño, una propiedad o un comportamiento de un sistema. Cuando

se enuncia los requisitos de un sistema se están estableciendo un contrato entre los elementos externos

al sistema y el propio sistema, que establece lo que se espera que haga el sistema.

Para modelar los requisitos de un sistema:

Hay que establecer el contexto del sistema.

Hay que considerar el comportamiento que cada actor espera del sistema por requiere que éste

le proporcione.

Hay que nombrar esos comportamientos comunes como casos de uso.

Hay que factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados

por otros.

Hay que modelar esos casos de uso, actores y relaciones en un diagrama de casos de uso.

Hay que adornar esos casos de uso con notas que en un siendo requisitos no funcionales.

INGENIERÍA DIRECTA E INVERSA

La mayoría de los otros diagramas de UML, incluyendo los diagramas de clase, de componentes y

Estados, son claros candidatos para la ingeniería directa e inversa, porque cada uno tiene un análogo en

un sistema ejecutable.

La ingeniería directa es el proceso de transformar un modelo en código a través de una correspondencia

con un lenguaje de implementación.




Para ser ingeniería directa con un diagrama de casos de uso:

Hay que identificar el flujo de eventos de cada caso de uso, y su flujo de eventos excepcional.

Según el grado en el que se desee profundizar con las pruebas.

Si es necesario, hay que generar una estructura de prueba para representar cada actor que

interactúa con el caso de uso.

Hay que usar herramientas que ejecuten estas pruebas a la vez que se genere una nueva

versión del elemento al que se aplica el diagrama de casos de uso.

La ingeniería inversa es el proceso de transformar código en un modelo a través de una correspondencia

a partir de un lenguaje de implementación específico.

Para ser un diagrama de casos de uso mediante ingeniería inversa:

Hay que identificar a cada actor sin que actúa con el sistema.

Hay que considerar la forma indicada actor interacción tuba con el sistema, cambio de estado del

sistema o de su entorno, corresponde a algún evento.

Hay que trazar el flujo de eventos del sistema ejecutable en relación con cada actor.

Hay que agrupar los flujos relacionados declarando el correspondiente caso de uso.

Hay que representar esos actores y casos de uso en un diagrama de casos de uso, y establecer

sus relaciones.

Sugerencias y consejos

Un diagrama de casos de uso bien estructurado:

Se ocupa de modelar un aspecto de la vista de casos de uso de estática de un sistema.

Contiene sólo aquellos casos de uso y actores que esenciales para comprender ese aspecto.

Proporciona detalles de forma consistente con su nivel de abstracción.




No es tan minimalista que no ofrezca información al lector sobre los aspectos importantes de la

semántica.

Cuando se dibuja un diagrama de casos de uso:

Hay que darle un nombre que comunique su propósito.

Hay que distribuir sus elementos para minimizar los cruces de líneas.

Hay que organizar sus elementos espacialmente para que los comportamientos y roles

semánticamente cercanos se encuentren cercanos físicamente.

Hay que utilizar las notas y los colores como señales visuales para llamar la atención sobre las

características importantes del diagrama.

Hay que intentar no mostrar demasiados tipos de relaciones.




CAPITULO 18

DIAGRAMA DE ITERACION

Los diagramas de secuencia y los diagramas de colaboración ambos llamados Diagramas de Interacción, son dos de los cincos tipos de di agramas de UML que se utilizan para modelar los aspectos dinámicos del sistema

Qué es una Interacción?Es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles de

asociación. Un mensaje es una comunicación unidireccional entre dos objetos, un flujo de objeto con la

información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores

entre objetos. Un mensaje puede ser una señal (comunicación explícita entre objetos, con nombre y

asíncrona) o una llamada (la invocación síncrona de una operación con un mecanismo para el control,

que retorna posteriormente al remitente). Un patrón de intercambios de mensajes que se realizan para

lograr un propósito específico es lo que se denomina una interacción.

Lo diagramas dinámicos son:

Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones

que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que

se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del

sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.

Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos.

Son útiles en sistemas que reaccionen a eventos.

Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los

objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.

Los diagramas de interacción muestran cómo se comunican los objetos en una interacción.




Existen dos tipos de diagramas de interacción:

El Diagrama de Colaboración y el Diagrama de Secuencia.

El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las

interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo

real y para escenarios complejos.

El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los enlaces de comunicación

entre objetos, muestra las relaciones entre objetos y son mejores para comprender todos los efectos que

tiene un objeto y para el diseño de procedimientos. El diagrama de Colaboración puede obtenerse

automáticamente a partir del correspondiente diagrama de Secuencia (o viceversa).

Normalmente los diagramas de interacción contienen:

Objetos Enlaces Mensajes

Nota: Un diagrama de Interacción es básicamente una proyección de los elementos de una interacción.

La vista de interacción describe secuencias de intercambios de mensajes entre los roles que

implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la

descripción de un objeto, que desempeña un determinado papel dentro de una interacción, distinto de los

otros objetos de la misma clase. Esta visión proporciona una vista integral del comportamiento del

sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista de interacción se

exhibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos

individuales y centrados en objetos cooperantes.

Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones.




Diagrama de Secuencia Muestra la secuencia de mensajes entre objetos durante un escenario

concreto.

Cada objeto viene dado por una barra vertical

El tiempo transcurre de arriba abajo

Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua

Diagrama que muestra las interacciones entre los objetos organizadas en una secuencia temporal.

En particular muestra los objetos participantes en la interacción y la secuencia de mensajes

intercambiados. Un uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un

caso de uso.

Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica, pero las

relaciones son implícitas.

Un diálogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa

los objetos que participan en la interacción. En general, el tiempo avanza hacia abajo dentro de la página

(se pueden invertir los ejes si se desea). Con frecuencia sólo son importantes las secuencias de

mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una métrica. La ordenación

horizontal de los objetos no tiene ningún significado.

Ejemplo:




Es imposible representar en un solo diagrama de secuencia todas las secuencias posibles del sistema,

por ello se escoge un punto de partida. El diagrama se forma con los objetos que forman parte de la

secuencia, estos se sitúan en la parte superior de la pantalla, normalmente en la izquierda se sitúa al que

inicia la acción. De estos objetos sale una línea que indica su vida en el sistema. Esta línea simple se

convierte en una línea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando

el esta activo.

Diagramas de colaboración Un diagrama de colaboración no muestra el tiempo como una dimensión aparte, por lo que resulta

necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos

concurrentes.

Un diagrama de colaboración es también un diagrama de clases que contiene roles de clasificador y roles

de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación

describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una

instancia de la colaboración. Cuando se instancia una colaboración, los objetos están ligados a los roles

de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por

varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del

procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La colaboración

muestra los parámetros y las variables locales de la operación, así como asociaciones más permanentes.

Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de

llamadas anidadas y el paso de señales del programa.

Un diagrama de colaboración muestra relaciones entre roles geométricamente y relaciona los mensajes

con las relaciones, pero las secuencias temporales están menos claras. Es útil marcar los objetos en

cuatro grupos: los que existen con la interacción entera;

los creados durante la interacción (restricción {new}); los destruidos durante la interacción (restricción

{destroyed}); y los que se crean y se destruyen durante la interacción (restricción {transient}).




Aunque las colaboraciones muestran directamente la implementación de una operación, pueden también

mostrar la realización de una clase entera. En este uso, muestran el contexto necesario para implementar

todas las operaciones de una clase. Esto permite que el modelador vea los roles múltiples que los objetos

pueden desempeñar en varias operaciones.

MensajesLos mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un

número de secuencia, una lista opcional de mensajes precedentes, una condición opcional de guarda, un

nombre y una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el

nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencial mente. Los

mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explícita.

FlujosGeneralmente, un diagrama de colaboración contiene un símbolo para un objeto durante una operación

completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explícitos.

Técnicas comunes de ModeladoMODELADO DE FLUJOS DE CONTROL POR ORDENACIÓN TEMPORAL

Para modelar un flujo de control que discurre entre objetos y roles se utiliza un diagrama de interacción:

Para modelar un flujo de control por ordenación temporal:

Hay que establecer el contexto de la interacción

Hay que establecer el escenario de la interacción, identificando que objetos juegan un rol de ellas.

Hay que establecer la línea de vida de cada objeto




A partir del mensaje que inicia la interacción hay que ir colocando los mensajes subsiguientes.

MODELADO DE FLUJOS DE CONTROL POR ORGANIZACIÓNPara modelar un flujo de control por organización:

Hay que establecer el contexto de la interacción

Hay que establecer el escenario de la interacción, identificando que objetos juegan un rol de ellas.

Hay que establecer las propiedades iniciales de cada uno de los objetos.

Hay que especificar los enlaces entres esos objetos, junto a los mensajes que pueden pasar.

Ingeniería directa o Inversa

(Creación de código a partir de un modelo) es posible para los diagramas de secuencia como los de

colaboración.




CAPITULO 19

DIAGRAMA DE ACTIVIDADES

El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las

acciones y usado para especificar:

Un método

Un caso de uso

Un proceso de negocio (Workflow)

Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una

operación. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los

grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por

transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad.

Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecución

de un sistema, sin profundizar en los detalles internos de los mensajes. Los parámetros de entrada y

salida de una acción se pueden mostrar usando las relaciones de flujo que conectan la acción y un

estado de flujo de objeto.

Un grafo de actividades contiene estados de actividad que representa la ejecución de una secuencia en

un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un

evento, como en un estado de espera normal, un estado de actividad espera la terminación de su

cómputo. Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad

dentro del diagrama. una transición de terminación es activada en un diagrama de actividades cuando se

completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explícitos,

peor pueden ser abortados por transiciones en estados que los incluyen.

Un grafo de actividades puede contener también estados de acción, que son similares a los de actividad

pero son atómicos y no permiten transiciones mientras están activos.

Los estados de acción se deben utilizar para las operaciones cortas de mantenimiento.

Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en hilos

concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente

por los diversos objetos o personas. La concurrencia se representa a partir de la agregación, en la cual

cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o en




cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el

control de concurrencia además del control secuencial.

Notación

Un estado de actividad se representa como una caja con los extremos redondeados que contiene una

descripción de actividad.

Las transacciones simples de terminación se muestran como flechas.

Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con múltiples

flechas de salida etiquetadas.

Una división o una unión de control se representan con múltiples flechas que entran o salen de la barra

gruesa de sincronización.

Cuando es necesario incluir eventos externos, la recepción de un evento se puede mostrar como un

disparador en una transición, o como un símbolo especial que denota la espera de una señal.

A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase de

asignación puede mostrarse organizando las actividades en regiones distintas separadas por líneas en el

diagrama. Debido a su aspecto, esto es conocido como Calles.

Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para un valor de salida, se

dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja

una flecha con línea discontinua desde el objeto a una actividad.


el lenguaje unificado de modelado · web viewsegundo, que el software no puede entender a menos que...

Documents