Universidad Fidelitas, Costa Rica

UML
Curso: Ingeniería del Software

Andrés Fernández
Carlos Molina
Karla Piedra
28/01/2011
 2

Contenido
Contenido............................................................................................................ 2

Introducción........................................................................................................ 3

Objetivo General..............................................................................................4

Objetivos específicos.......................................................................................4

Alcances y Limitaciones...................................................................................4

Marco Conceptual............................................................................................... 5

Historia del UML...............................................................................................5

¿Qué es UML?...................................................................................................7

Modelado Visual...............................................................................................8

Objetivos de UML.............................................................................................9

Funciones del UML.........................................................................................10

Inconvenientes del UML.................................................................................11

Diagramas de UML.........................................................................................11

Diagrama de Clases....................................................................................13

Diagrama de Componentes........................................................................15

Diagrama de Objetos..................................................................................16

Diagrama de Despliegue.............................................................................17

Diagrama de Paquetes................................................................................18

Diagrama de Actividades............................................................................19

Diagrama de Casos de Uso.........................................................................20

Diagrama de Estados..................................................................................23

Diagrama de Secuencias............................................................................23

Conclusiones..................................................................................................... 26

Material Final.....................................................................................................26
 3

Bibliografía.....................................................................................................26

Introducción
 4

Objetivo General

El presente trabajo permitirá conocer de UML, sus orígenes, los objetivos de UML y los
tipos de diagramas que lo componen y como este proceso de modelado ha ido ganando
tanto adepto en lo que es en el análisis orientado a objetos.

Objetivos específicos
a. Que es UML.

b. Objetivos que persigue UML.

c. Conocer los tipos de diagrama en UML 2.0 y su concepto detrás de

ellos.

Alcances y Limitaciones

Al ser UML una técnica para el modelado de procesos y que apoya el desarrollo del
análisis de un sistema, no se entrará en detalles de qué técnica para el proceso de
desarrollo es mejor, llámese Espiral, Agile, XP, entre otras. El objetivo fundamental es dar
a conocer acerca de UML y la manera en como este puede ayudar en el proceso del
desarrollo del software.

Se describirán los tipos de diagramas que existen, enfocándose en detallar con ejemplo
los diagramas más utilizados.
 5

Marco Conceptual
Historia del UML

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la

compañía Rational fundada por Booch (dos reputados investigadores en el área de
Metodología del software)

Figura1: Logo del UML

El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch
y el OMT (Object Modelling Tool). El primer borrador apareció en octubre de 1995. En esa
misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron
ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este
lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas.
Todas estas colaboraciones condujeron a la definición de la primera versión de UML.

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y

documentar artefactos de un sistema de software. Se usa para entender, diseñar,
configurar, mantener y controlar la información sobre los sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un
sistema. Un sistema se modela como una colección de objetos discretos que interactúan
para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de
modelado e incorporar las mejores prácticas actuales en un acercamiento estándar.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores
de código de UML para una gran variedad de lenguaje de programación, así como
construir modelos por ingeniería inversa a partir de programas existentes.
 6

La notación UML se deriva y unifica las tres metodologías de análisis y diseños más
extendidas.

• Metodología de Grady Booch para la descripción de conjuntos de objetos y sus

relaciones.

• Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object –

Modelling Techinique).

• Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering)

mediante la metodología de casos de uso (use case).

El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh
de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995,
Ivar Jacob son y su compañía Objectory se incorporaron a Rational en su unificación,
aportando el método OOSE.

De las tres metodologías de partida, las de Bco. y Rumbaugh pueden ser descritas como
centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los
objetos que componen el sistema, su relación y colaboración.

Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su
método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como
estándar desde el OMG, que es también el origen de CORBA, el estándar líder en la
industria para la programación de objetos distribuidos.

En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de
facto para el análisis y el diseño orientado a objetos. UML es el primer método en publicar
un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la
información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-
referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de
modelarse a sí mismo).
 7

Figura2: Evolución del UML

¿Qué es UML?
 8

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y

documentar artefactos de un sistema de software. Se usa para entender, diseñar,
configurar, mantener y controlar la información sobre los sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un
sistema. Un sistema se modela como una colección de objetos discretos que interactúan
para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de
modelado e incorporar las mejores prácticas actuales en un acercamiento estándar.

UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores

de código de UML para una gran variedad de lenguaje de programación, así como
construir modelos por ingeniería inversa a partir de programas existentes.

Es un lenguaje de propósito general para el modelado orientado a objetos. UML es

también un lenguaje de modelamiento visual que permite una abstracción del sistema y
sus componentes.

Existían diversos métodos y técnicas Orientadas a Objetos, con muchos aspectos en

común pero utilizando distintas notaciones, se presentaban inconvenientes para el
aprendizaje, aplicación, construcción y uso de herramientas, etc., además de pugnas
entre enfoques, lo que genero la creación del UML como estándar para el modelamiento
de sistemas de software principalmente, pero con posibilidades de ser aplicado a todo tipo
de proyectos

El UML debe entenderse como un estándar para modelado y no como un estándar de

proceso software. Aunque UML debe ser aplicado en el contexto de un proceso, la
experiencia ha mostrado que organizaciones diferentes y dominios del problema
diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un
meta-modelo común (que unifica las semánticas) y una notación común que proporcione
una representación de esas semánticas. De todas formas, los autores de UML fomentan
un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental.
Bajo estas líneas genéricas proponen el proceso software definido en una de las
extensiones del UML (Objectory Extension for Software Enginnering) , pero en general el
proceso software es fuertemente dependiente de la organización y del dominio de
aplicación

Modelado Visual
 9

Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una

simplificación de la realidad. El objetivo del modelado de un sistema es capturar las partes
esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se
plasma en una notación gráfica. Esto se conoce como modelado visual.

El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar.

De la misma forma que para construir una bodega en la parte trasera de una casa no
hace falta un modelo, cuando se intenta construir un sistema complejo como un
rascacielos, es necesario abstraer la complejidad en modelos que el ser humano pueda
entender.

UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los
sistemas software como para la arquitectura hardware donde se ejecuten.

Otro objetivo de este modelado visual es que sea independiente del lenguaje de
implementación, de tal forma que los diseños realizados usando UML se pueda
implementar en cualquier lenguaje que soporte las posibilidades de UML (principalmente
lenguajes orientados a objetos).

UML es además un método formal de modelado. Esto aporta las siguientes ventajas:

• Mayor rigor en la especificación.

• Permite realizar una verificación y validación del modelo realizado.

• Se pueden automatizar determinados procesos y permite generar código a partir

de los modelos y a la inversa (a partir del código fuente generar los modelos). Esto
permite que el modelo y el código estén actualizados, con lo que siempre se
puede mantener la visión en el diseño, de más alto nivel, de la estructura de un
proyecto.

Objetivos de UML

Durante su desarrollo los padres del UML tuvieran en cuenta lo siguiente:

• UML es un lenguaje de modelado de propósito general que pueden usar todos los
modeladores. No tiene propietario y está basado en el común acuerdo de gran
parte de la comunidad informática.

• UML no pretende ser un método de desarrollo completo. No incluye un proceso de

desarrollo paso a paso. UML incluye todos los conceptos que se consideran
 10

necesarios para utilizar un proceso moderno iterativo, basado en construir una

sólida arquitectura para resolver requisitos dirigidos por casos de uso.

• Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda
la gama de sistemas que se necesita construir. UML necesita ser lo
suficientemente expresivo para manejar todos los conceptos que se originan en un
sistema moderno, tales como la concurrencia y distribución, así como también los
mecanismos de la ingeniería de software, como son la encapsulación y
componentes.

• Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.

• Imponer un estándar mundial.

Funciones del UML

UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas para
permitir una comunicación. En este caso, este lenguaje se centra en la representación
gráfica de un sistema. Sus funciones son las siguientes:

• Visualizar: UML permite expresar de una forma gráfica un sistema de forma que
otro lo puede entender.

• Especificar: UML permite especificar cuáles son las características de un sistema

antes de su construcción.

• Construir: A partir de los modelos especifica-dos se pueden construir los sistemas

diseñados.

• Documentar: Los propios elementos gráficos sirven como documentación del

sistema des-arrollado que pueden servir para su futura revisión.

Aunque UML está pensado para modelar sistemas complejos con gran cantidad de
software, el lenguaje es los suficientemente expresivo como para modelar sistemas que
no son informáticos, como flujos de trabajo (workflow ) en una empresa, diseño de la
estructura de una organización y por supuesto, en el diseño de hardware.

Un modelo UML está compuesto por tres clases de bloques de construcción:

• Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos,

acciones, etc.)

• Relaciones: relacionan los elementos entre sí.

 11

• Diagramas: Son colecciones de elementos con sus relaciones.

Inconvenientes del UML

Ya que nada es perfecto en la vida y como trae sus ventas, UML presenta una serie de
inconvenientes, de las cuales las dos más importantes son:

• Falta de integración con otras técnicas. Ejemplo: diseño de interfaces de usuarios.

• UML es excesivamente complejo. Es tan así que solo el 80% de los problemas se
pueden modelar usando alrededor del 20% de UML.

Diagramas de UML
Dentro de la versión de UML 2.0, podemos encontrar 13 diagramas que nos permitirán
elaborar y representar toda nuestra construcción del software, desde la representación de
un proceso de pago hasta la elaboración de las diferentes vistas arquitectónicas de un
sistema. La siguiente muestra un resumen de la división de los diagramas.
 12

Figura 3: diagramas de UML

Existen dos grandes agrupaciones que acogen los diferentes diagramas, las cuales son:
estructurales y de comportamiento.

Los diagramas estructurales presentan elementos estáticos del modelo, tales como
clases, paquetes o componentes; en tanto que los diagramas de comportamiento
muestran la conducta en tiempo de ejecución del sistema, tanto visto como un todo como
de las instancias u objetos que lo integran.

Por otra parte, en la figura se ve que hay tres tipos de diagramas señalados en un color
distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interacción.
Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los
menos conocidos.

Hay que tener en cuenta, que cada diagrama sirve para documentar un aspecto distinto
del sistema; el criterio para usarlos es el de tener algo que decir, una historia sobre
nuestro sistema que debe ser contada; el tipo de diagrama que usemos será el que nos
dé mayor poder expresivo y solo muy difícilmente, la construcción de una serie de
diagramas puede ser explícitamente ordenada por un método de desarrollo. Algunos
sistemas simples serán bien documentados con pocos diagramas, en tanto que algunos
sistemas grandes bien podrían beneficiarse de un conjunto mayor.
 13

Diagrama de Clases

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un

sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de
clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se
crea el diseño conceptual de la información que se manejará en el sistema, y los
componentes que se encargaran del funcionamiento y la relación entre uno y otro.

Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura

conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de
software orientados a objetos

Algunas definiciones que se manejan dentro de un diagrama de clases:

• Propiedades también llamados atributos o características, son valores que

corresponden a un objeto, como color, material, cantidad, ubicación.
Generalmente se conoce como la información detallada del objeto. Suponiendo
que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y
peso.

• Operaciones comúnmente llamados métodos, son aquellas actividades o verbos

que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar,
buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un
atributo, el nombre de una operación se escribe con minúsculas si consta de una
sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida
a la anterior y comenzará con una letra mayúscula, a excepción de la primera
palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta,
buscarPuerta, etc.
• Interfaz es un conjunto de operaciones que permiten a un objeto comportarse de
cierta manera, por lo que define los requerimientos mínimos del objeto. Hace
referencia a polimorfismo.

• Herencia se define como la reutilización de un objeto padre ya definido para

poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas
las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona
puede especializarse en Proveedores, Acreedores, Clientes, Accionistas,
Empleados; todos comparten datos básicos como una persona, pero además cada
uno tendrá información adicional que depende del tipo de persona, como saldo del
cliente, total de inversión del accionista, salario del empleado, etc.

Al diseñar una clase se debe pensar en cómo se puede identificar un objeto real, como
una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de
objetos reales, es sobre lo que un sistema se diseña. Durante el proceso del diseño de las
clases se toman las propiedades que identifican como único al objeto y otras propiedades
adicionales como datos que corresponden al objeto. Con los siguientes ejemplos se
definen tres objetos que se incluyen en un diagrama de clases:
 14

Ejemplo 1: Una persona tiene número de documento de identificación, nombres,

apellidos, fecha de nacimiento, género, dirección postal, posiblemente también tenga
número de teléfono de casa, del móvil, FAX y correo electrónico.

Ejemplo 2: Un sistema informático puede permitir administrar la cuenta bancaria de una

persona, por lo que tendrá un número de cuenta, número de identificación del propietario
de la cuenta, saldo actual, moneda en la que se maneja la cuenta.

Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dónde las operaciones bancarias
de una cuenta (como en el ejemplo 2) se manejarán realizando diferentes operaciones
que en el diagrama de clases de balurdes sólo se representan como operaciones, que
pueden ser:

• Abrir
• Cerrar
• Depósito
• Retiro
• Acreditar Intereses

Estos ejemplos constituyen diferentes clases de objetos que tienen propiedades y/u
operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son
clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el
sistema se pueden unir los datos con las operaciones.

El diagrama de clases incluye mucha más información como la relación entre un objeto y
otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades
que son implementadas para una interfaz.
 15

Figura 4: Diagrama de Clases

Diagrama de Componentes

Un diagrama de componentes representa cómo un sistema de software es dividido en

componentes y muestra las dependencias entre estos componentes. Los componentes
físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o
paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar cualquier arquitectura de
sistema.

Debido a que estos son más parecidos a los diagramas de casos de usos estos son
utilizados para modelar la vista estática y dinámica de un sistema. Muestra la
organización y las dependencias entre un conjunto de componentes. No es necesario que
un diagrama incluya todos los componentes del sistema, normalmente se realizan por
partes. Cada diagrama describe un apartado del sistema.
 16

En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte

del sistema.

Uno de los usos principales es que puede servir para ver qué componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.

Figura 5: Diagrama de Componentes

Diagrama de Objetos

Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los
sistemas informáticos en la metodología UML.
 17

Se puede considerar un caso especial de un diagrama de clases en el que se muestran

instancias específicas de clases (objetos) en un momento particular del sistema. Los
diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase.
Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es
similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la

forma Nombre de objeto: Nombre de clase.

Diagrama de Despliegue

Se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las

relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un
prisma), componentes (representados como una caja rectangular con dos protuberancias
del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber
artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de
datos construida o modificada en un proyecto. Estos artefactos implementan colecciones
de componentes. Los nodos internos indican ambientes, un concepto más amplio que el
hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de
programación, a un sistema operativo, un ordenador o un cluster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar la

topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje
de especificación hardware de propósito general, se ha diseñado para modelar muchos
de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero
software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

• Sistemas empotrados: Un sistema empotrado es una colección de hardware con

una gran cantidad de software que interactúa con el mundo físico.
• Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del
espectro de los sistemas distribuidos y requieren tomar decisiones sobre la
conectividad de red de los clientes a los servidores y sobre la distribución física de
los componentes software del sistema a través de nodos.
• Sistemas completamente distribuidos: En el otro extremo encontramos aquellos
sistemas que son ampliamente o totalmente distribuidos y que normalmente
incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias
versiones de componentes software, alguno de los cuales pueden incluso migrar
de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que
permitan un cambio continuo de la topología del sistema.
 18

S e rv i d o r W e b W in d o w s 2 0 0 3 S e rv i d o r D B W in d o w s 2 0 0 3
C lie n te

IIS SQ L SERVER 2005

N a v e g a d o r d e In te rn e t

C o n n e x i ó n T C P /IP
C o n e x ió n H T T P /H T T P S
<<ASPX>>
T a b la s
L ó g i c a d e P e se n ta c i ó n
< < P á g in a s H T M L > >
P re se n t a c i ó n

<<DLL>> <<DLL>> P ro c e d i m i e n to s A l m a c e n a d o s
L ó g ic a d e A c c e so a D a to s
L ó g ic a d e N e g o c io

Figura 6: Diagrama de Despliegue

Diagrama de Paquetes

Muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las

dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado
como un directorio, los diagramas de paquetes suministran una descomposición de la
jerarquía lógica de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia interna

dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con
estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión.
Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre
ellos pueden indicar el orden de desarrollo requerido.
 19

Figura 7: Diagrama de Paquetes

Diagrama de Actividades

Los diagramas de actividades son particularmente útiles para la descripción del

comportamiento que tiene una gran cantidad de proceso paralelo. Permite seleccionar el
orden en que se harán las cosas. Indica las reglas esenciales de secuenciación que tengo
que seguir. Ésta es la diferencia clave entre un diagrama de actividades y un diagrama de
flujo. Los diagramas de flujo se limitan normalmente a procesos secuenciales; los
diagramas de actividades pueden manejar procesos paralelos. Los diagramas de
actividades también son útiles para los programas concurrentes, ya que se pueden
plantear gráficamente cuáles son los hilos y cuándo necesitan sincronizarse
 20

El cliente se identifica

Obtener datos reservacion

Verificar Posibilidad Reservacion

Posibilidad = Verdadera
[Posibilidad = Falsa]

Reservar Vehiculo

Confirmar Reservacion

Figura 7: Diagrama de Actividades

Diagrama de Casos de Uso

Se define como cada interacción supuesta con el sistema a desarrollar, donde se

representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer
un sistema y como. En la siguiente figura se muestran tres actores (los clientes, los
taquilleros, y los jefes de taquilla) y las operaciones que pueden realizar (roles).
 21

Figura 8: Diagrama de casos de uso.

El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de
uso llamada modelo de casos de uso. UML no define estándares para que el formato
escrito describa los casos de uso, y así mucha gente no entiende que esta notación
gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede
solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los
diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los
dos conceptos están relacionados, los casos de uso son mucho más detallados que los
diagramas de casos de uso.

Las tres relaciones principales entre los casos de uso son soportadas por el estándar
UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas
a continuación:

• Inclusión (include o use)

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro.
El primer caso de uso a menudo depende del resultado del caso de uso incluido.
Esto es útil para extraer comportamientos verdaderamente comunes desde
múltiples casos de uso a una descripción individual, desde el caso El estándar de
Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar
diagramas de casos de uso, pero no el formato para describir casos de uso.
Mucha gente sufre la equivocación pensando que un caso de uso es una notación
gráfica (o es su descripción). Mientras la notación gráfica y las descripciones son
importantes, ellos forman parte de la documentación de un caso de uso --un
 22

propósito para el que el actor puede usar el sistema. La notación es de una flecha
de punta abierta con línea discontinua desde el caso de uso que lo incluye hasta el
caso de uso incluido, con la etiqueta "«include»". Este uso se asemeja a una
expansión de una macro, donde el comportamiento del caso incluido es colocado
dentro del comportamiento del caso de uso base. No hay parámetros o valores de
retorno. Aquí también podemos decir q este va de padre a hijo.

• Extensión (Extend)
Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender
a otro. Esta relación indica que el comportamiento del caso de La Extensión se
utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión
o inclusión. La Extensión puede ser insertada en el caso de uso extendido bajo
ciertas condiciones. La notación, es una flecha de punta abierta con línea
discontinua, desde el caso de uso extensión al caso de uso extendido, con la
etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para
acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.

La extensión, es el conjunto de objetos a los que se aplica un concepto. Los

objetos de la extensión son los ejemplos o instancias de los conceptos.

• Generalización
Es la actividad de identificar elementos en común entre conceptos y definir las
relaciones de una superclase (concepto general) y subclase (concepto
especializado). Es una manera de construir clasificaciones taxonómicas entre
conceptos que entonces se representan en jerarquías de clases. Las subclases
conceptuales son conformes con las superclases conceptuales en cuanto a la
intención y extensión.

En la tercera forma de relaciones entre casos de uso, existe una relación

generalización/especialización. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notación es una línea sólida
terminada en un triángulo dibujado desde el caso de uso especializado al caso de
uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la
práctica puede ser útil factorizar comportamientos comunes, restricciones al caso
de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en
los casos de uso especializados.

La siguiente presenta los componentes de un caso de uso.

 23

Figura 9: Componentes de un caso de uso

Diagrama de Estados

Es un diagrama utilizado para identificar cada una de las rutas o caminos que puede
tomar un flujo de información luego de ejecutarse cada proceso.

Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué
momento podrían tener una variación.

El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada

uno de los procesos.

Diagrama de Secuencias

Muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y

se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el
modelado de una vista business del escenario, el diagrama de secuencia contiene
 24

detalles de implementación del escenario, incluyendo los objetos y clases que se usan
para implementar el escenario, y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos

son necesarios para la implementación del escenario. Si se dispone de la descripción de
cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar
sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir
los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario
con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas
horizontales.

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se

corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que
envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes
se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan
inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se
representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

 25

Figura 10: Diagrama de Secuencia

 26

Conclusiones

UML es una notación que a resultado de la evolución de las notaciones previas en

ingeniería de software, tomando aspectos de tres metodologías anteriores: OMT, Booch y
OOSE.

Dado que UML se fundamenta en los principios de modelado se torna sumamente

importante para toda implementación en un sistema de información.

Adicional a lo anterior UML permite modelar procesos, que utilizado de forma adecuada
permite disminuir el riesgo de fracaso de un proyecto y facilita el levantamiento de
requerimientos, desarrollo, documentación, pruebas y soporte.

UML debería evolucionar para poder brindar soporte al análisis de interfaces gráficas,
con esto permitir una escenario previo de lo que tendrá el usuario.

Material Final
Bibliografía

Booch, Grady. 1996. Análisis y Diseño Orientado a Objetos. 2da edición. Ed. Addison-
Wesley / Díaz de Santos.

Pressman, Robert. 1998. Ingeniería de Software.

I.Jacobson, G. Booch, J. Rumbaugh, “El Proceso de Unificado de Desarrollo” Addision

Wesley, 2000.

http://agamenon.uniandes.edu.co/~pfigueroa/soo/uml.

http://www.rational.com/uml/.

http://www2.uah.es/jcaceres/uploaded/capsulas/DiagramaSecuencia.pdf