el lenguaje unificado de modelado · web viewsegundo, que el software no puede entender a menos que...
TRANSCRIPT
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
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
El LENGUAJE UNIFICADO DE MODELADO
SECCION 1
INTRODUCCION
Página de 97 Ing. Juan Manuel Márquez Vite 4
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 5
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 6
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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)
Página de 97 Ing. Juan Manuel Márquez Vite 7
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 8
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 9
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 10
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 11
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 12
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 13
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 14
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 15
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 16
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 17
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 18
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 19
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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,
Página de 97 Ing. Juan Manuel Márquez Vite 20
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
Página de 97 Ing. Juan Manuel Márquez Vite 21
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
SECCION 2
MODELADO ESTRUCTURAL BASICO
Página de 97 Ing. Juan Manuel Márquez Vite 22
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 23
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 24
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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:
Página de 97 Ing. Juan Manuel Márquez Vite 26
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 27
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 28
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 29
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 30
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 31
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 32
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 33
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 34
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 35
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 36
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 37
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 38
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
“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.
Página de 97 Ing. Juan Manuel Márquez Vite 39
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 40
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 41
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 42
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 43
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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:
Página de 97 Ing. Juan Manuel Márquez Vite 44
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 45
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 46
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 47
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 48
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 49
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
SECCION 3
MODELADO ESTRUCTURAL AVANZADO
Página de 97 Ing. Juan Manuel Márquez Vite 50
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 51
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 52
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 53
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 54
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 55
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 56
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 57
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 58
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 59
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 60
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 61
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 62
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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).
Página de 97 Ing. Juan Manuel Márquez Vite 63
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Técnicas comunes de modelado
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.
Página de 97 Ing. Juan Manuel Márquez Vite 64
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 65
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 66
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 67
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 68
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 69
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 70
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 71
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 72
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 73
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
SECCION 4
MODELADO BASICO DEL COMPORTAMIENTO
Página de 97 Ing. Juan Manuel Márquez Vite 75
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 76
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 77
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 78
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 79
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 80
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 81
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 82
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Técnicas comunes de modelado
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:
Página de 97 Ing. Juan Manuel Márquez Vite 83
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 84
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 85
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
Técnicas comunes de modelado
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.
Página de 97 Ing. Juan Manuel Márquez Vite 86
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 87
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 88
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 89
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 90
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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:
Página de 97 Ing. Juan Manuel Márquez Vite 91
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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}).
Página de 97 Ing. Juan Manuel Márquez Vite 92
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 93
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 94
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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
Página de 97 Ing. Juan Manuel Márquez Vite 95
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
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.
Página de 97 Ing. Juan Manuel Márquez Vite 96
INSTITUTO POLITECNICO NACIONALESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADOPROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
Página de 97 Ing. Juan Manuel Márquez Vite 97