LENGUAJE UNIFICADO DE

MODELADO
INTEGRANTES

o
o
o
o

JOEL CONDORI LUCANA

ELMER DANY HUAMANI MELO
ALEXANDER SAUNI MAUCAYLLA
ERICK FRANCO DEL CASTILLO DEZA

HISTORIA

Versiones:

Booch Ivar Jacobson James Rumbaugh

Antes de Grady
UML 1.x (1994 - 1996)
los Tres Amigos (Rumbaugh, Jacobson y Booch)
El OMT (Object-modeling technique) de Rumbaugh mejor para el anlisis
orientado a objetos
Ivar Jacobson, creador del mtodo de ingeniera de software orientado a
objetos
Mtodo Booch de Grady Booch mejor para el diseo orientado a objetos.

UML 1.x (1997 - 2004)

En 1996 Rational Software Corporation encargo a los Tres Amigos que
desarrollaran un Lenguaje Unificado de Modelado abierto
El borrador de la especificacin UML 1.0 de UML Partners fue propuesto a
la OMG (Object Management Group) en enero de 1997.

HISTORIA
UML 2.x (2005 - Presente)
La revisin mayor UML 2.0 que fue adoptada por el OMG en 2005
Desde el ao 2005, UML es un estndar aprobado por la ISO como ISO/IEC
19501:2005
UML 2.1 nunca fue lanzado como una especificacin formal, las versiones
2.1.1 y 2.1.2, aparecieron en 2007
UML 2.5 fue lanzado en octubre de 2012 como una versin "En proceso" y
todava tiene que ser formalmente liberada.

QU ES UML?
Es una herramienta o Lenguaje de Modelamiento Unificado
que permite a los creadores de Sistemas generar diseos
que capturen sus ideas en una forma convencional y fcil de
comprender y as poder comunicrselas a otras personas.

UML es un lenguaje visual para especificar, construir y

documentar sistemas (OMG - Object Management
Group)

UML no es Metodologa!

VISTA DE UML

DIAGRAMAS DE UML

Los diagramas expresan grficamente partes de un modelo.

Diagrama de
Caso de Uso

Diagrama de
Clases

Diagrama de
Secuencia

Diagrama de
Colaboracin

Diagrama de
Estados

Diagrama de
Objetos

Modelo

Diagrama de
Actividad

Diagrama de
Componentes

Diagrama de
Distribucin

POR QU TANTOS
DIAGRAMAS?

Los

Diagramas UML permite examinar un Sistema

desde distintos puntos de vista.

En

necesario contar con diferentes perspectiva en

un Sistema por que se cuenta con diferentes
personas implicadas, los cuales tienen enfoque
particulares en diferentes aspectos del Sistema.

El

Objetivo
involucrada.

Cabe

es

satisfacer

cada

Persona

recalcar que en UML no es necesario que

aparezcan todos los Diagramas.

ORIENTACIN A OBJETOS
La Programacin Estructurada tradicional se basa en la
Ecuacin de Wirth:
Algoritmos + Estructuras de Datos = Programas
Estos significa que los Datos y el Cdigo se trata por
separado.

La

OOP es una tcnica de programacin cuyo soporte

es el Objeto.

Objeto:

es una extensin de un Tipo Abstracto de

Datos (TAD).

OBJETOS Y CLASES

Una clase es una definicin abstracta de un objeto

Define la estructura y el comportamiento
compartidos por los objetos
Sirve como modelo para la creacin de objetos

Los objetos pueden ser agrupados en clases

PILARES DE LA
ORIENTACIN A OBJETOS
Abstraccin

Herencia

Polimorfismo

Encapsulamie
nto

ABSTRACCIN

Es quitar las Propiedades y Acciones de un Objeto y

dejar solo las necesarias.

Ignorancia Selectiva
La abstraccin nos ayuda a trabajar con cosas
complejas
Se enfoca en lo importante
Ignora lo que no es importante (simplifica)

Una clase es una abstraccin en la que:

Se enfatizan las caractersticas relevantes
Se suprimen otras caractersticas
Una clase debe capturar una y solo una abstraccin
clave

 Es

la
Cualidad
importante de la OOP.

HERENCIA

mas

Es

un mecanismo mediante
el cual se puede crear una
nueva clase partiendo de
una existente, se dice que la
nueva clase hereda las
caractersticas de la clase
existente, aunque se le
puede
aadir
mas
capacidades o modificar las
que tiene.

VehiculoDeMotor
A ttributes
+ Cilindrada : int
+ NumeroDeRueda : int
Operations
+ acelelar() : void

Coches

Motos

A ttributes
+ NumeroDePuertas : int

A ttributes
+ TipoCarenado : string

Operations

Operations

POLIMORFISMO
En

ocasiones una accin tiene el mismo nombre

en diferentes Clases o en la misma, pero realizara
una operacin diferente.

Es la posibilidad de que dos Mtodos implementen

distintas acciones, aun teniendo el mismo nombre,
dependiendo del Objeto que lo ejecuta o de los
parmetros que recibe.

La

Sobrecarga
Polimorfismo.

Varios

es

un

tipo

especial

del

Mtodos con el mismo nombre, siempre y

cuando que el tipo de parmetros que recibe o el

POLIMORFISMO EJEMPLO
La definicin del mtodo reside en la clase base
La implementacin del mtodo reside en la clase
derivada
La invocacin es resuelta al momento de ejecucin
Transporte
Avanzar
Frenar

Transporte
Avanzar
Frenar

Transporte
Avanzar
Frenar

Transporte
Avanzar
Frenar

 Es

ENCAPSULAMIENTO

el ocultamiento de la Funcionalidad interna de

sus operaciones, de otros objetos y del mundo
exterior.

 Principio

ENCAPSULAMIENTO

que establece que los atributos propios de

un objeto no deben ser visibles desde otros objetos
Deben ser declarados como privados

Permite

abstraer al resto del mundo

complejidad de la implementacin interna

Permite

de

la

exponer el estado del objeto slo a travs

del comportamiento que le hayamos definido
mediante miembros pblicos

Por qu es til?
Punto de Control/Validacin
Mejor respuesta ante los Cambios

DIAGRAMAS DE UML

CONCEPCIN DE CLASES
La Clase se representa con un Rectngulo.
Existen diferentes tipo de Clases:
Abstracta.
Base.
Contenedora o Compuesta.
Derivada.
Hija.
Padre.
Super-Clase.
Sub-Clase.
Ejemplo de una Clase:

VehiculosDeMotor

VehiculoDeMotor

Cilindrada
Numero de Ruedas

A ttributes
+ Cilindrada : int
+ NumeroDeRueda : int

acelelar()

Operations
+ acelelar() : void

RELACIONES

Todo sistema abarca muchas clases y objetos

Los objetos contribuyen en el comportamiento
un sistema colaborando entre si
La colaboracin se logra a
relaciones

travs

Existen dos tipos principales de relaciones

Asociacin
Agregacin

de

de
las

ASOCIACIONES
Son las relaciones entre los Objetos (Clases).
Es una relacin estructural que especifica que

los
Objetos de un elemento estn conectados con los
Objetos de otro.

Los Objetos se pueden asociar con otro en mas de

una forma y direccin.

Un

Objeto se puede asociar con mas de un Objeto

y de diferentes Clase o Caracterstica.

Es

posible que la Asociacin se d de manera

recursiva en un Objeto

 Existen

ASOCIACIONES

cuatro adornos que se aplican a las

Es
la
Asociacin
asociaciones para facilitar su comprensin:

Nombre.
Rol.
Multiplicidad.
Agregacin.
Composicin.

entre un Jugador y
un Equipo

Es
el
papel
que
representa cada Clase en
la Asociacin

ASOCIACIONES
Diferente
Caractersti
ca

Relaciones Complejas

RESTRICCIONES EN
LAS ASOCIACIONES

En Asociaciones entre Clases pueden existir ciertas reglas.

Se establece una Restriccin en una Asociacin. En este caso,

la Asociacin Atiende est restringida para que el Cajero

atienda al Cliente en turno.

Otro tipo de Restriccin es la relacin O (distinguida como

{Or}) en una lnea discontinua que conecte a dos lneas de
Asociacin.

 Una

CLASE DE ASOCIACIN

Asociacin igual que una Clase, puede

contener Atributos y Mtodos. Esto se llama Clase
de Asociacin.

Una Clase de Asociacin puede tener asociaciones

con otras Clases.
Jugador

Partic ipa en >>

Equipo

A ttributes

A ttributes

Operations

Operations

Participa en >>

Negoc iado por >>

DirectorGeneral

A ttributes

Attributes

Operations

Operations

MULTIPLICIDAD

Indica

la cantidad de Objetos de una Clase que se

relacionan con otro Objeto particular de la Clase
Asociada.

Las Multiplicidad pueden ser: 1 a 1, 1 a muchos, 1

a 5, etc.

ASOCIACIONES REFLEXIVAS
Esto ocurre cuando una Clase tiene
Objetos que pueden jugar diversos
papeles.

Es una Relacin consigo mismo.

HERENCIA Y GENERALIZACIN

La Herencia y Generalizacin es lo mismo.

Es cuando una SubClase o Clase Secundaria puede

heredar los Atributos y Mtodos de otra Clase

(Clase Principal o SuperClase).

La

Clase Principal
definicin.

es

mas

genrica

en

su

 Una

DEPENDENCIA

relacin de dependencia significa que una

clase es dependiente de otra por algn servicio.

Una relacin de dependencia se indica si:

Las operaciones de la clase cliente

crean

objetos de la clase proveedora

Las

operaciones de la clase cliente pasan

argumentos
proveedora.

las

instancias

de

la

Sistema

clase

A ttributes
Operations
+ mostrarFormulario() : void

Es cuando una Clase utiliza a otra Clase.

Formulario

 Es

AGREGACIN

una estrecha relacin que existen entre varios

Objetos.

En un Objeto que se conforma de una combinacin

de diversos tipos de objetos.

Una Clase consta de otra.

COMPOSICIONES

Es cuando un componente se considera como tal

solo como parte del Objeto compuesto.

Ejemplo: Una Camisa que esta compuesta por:

Cuerpo, manga, cuello, botones, etc.

Las partes puede crearse despus de la parte

que representa el Todo (la parte compuesta),
una vez creada pertenecen a ella de manera
que viven y mueren con ella.

Las partes pueden ser eliminadas antes que el

Todo sea destruido, pero una vez sea eliminado
el Todo, es destruido todas sus partes.

El Todo es encargado de administrar o

gestionar
todas
sus
partes
mantenimiento, disposicin, etc).

MesaDeCafe
1

(creacin,
1

SuperficieDeLaMesa

Pata

DIAGRAMA DE CONTEXTO

El Diagrama de Contexto es como el mapa detallado de

alguna seccin de un mapa de mayores dimensiones.

Pueden ser necesarias varias secciones para capturar toda

la informacin.

Cuando se modele un Sistema puede producirse, con

frecuencia, agrupamiento de Clases, como Agregaciones o
Composiciones.
2

Manga

esta c osida en >> 2

Talla
1

1
<< esta c osida en

<< esta c osido en

<< esta c osida en

5,6
1

Botonadura

0,2,3

1
1
1

[1]

<< esta c osida en

Boton

se abotona en >>
1

Ojal

Cuello

INTERFACES
Es un conjunto de operaciones (Mtodos) que especifica cierto
aspecto de la funcionalidad de una Clase, y es un conjunto de
operaciones (Mtodos) que una Clase presenta a otras.

Permite que clases que no estn estrechamente relacionadas

entre s deban tener el mismo comportamiento.

La implementacin de una interfaz es un contrato que obliga a

la clase a implementar todos los mtodos definidos en la

interfaz.

Una vez que se hayan creado varias Clases, tal vez se de cuenta

que no pertenecen a una Clase Principal, pero en su

comportamiento debe incluir algunas de las mismas operaciones
con las mismas firmas de la primera Clase.
Teclado

A ttributes
+ marca : string
+ cantidadDeTeclas : int
Operations
+ Ctrl() : void
+ Alt() : void
+ RePag() : void
+ AvPag() : void

<<interface>>
MaquinaDeEscribir
A ttributes
Operations
+ Teclazo() : void

VISIBILIDAD

Identifica la visibilidad de un Atributo o Mtodo.

Tipos de Visibilidad:
o Pblicos (+).
o Privados (-).
o Protegidos (#)

CONSTRUCTORES Y DESTRUCTORES
Constructores:

Para poder utilizar un Objeto,

previamente debemos crearlo mediante el
Constructor de la Clase. Este Mtodo nos
devuelve un objeto nuevo de una Clase.
Normalmente el los lenguajes de programacin
estos Mtodos se conocen como New().

Destructores:

La funcionalidad del destructor

por defecto es deshacer todo lo que el
constructor por defecto realiz: eliminar las
referencias en la tabla de smbolos, liberar la
memoria ocupada, etc.

ATRIBUTOS
Es una propiedad o caracterstica de una Clase y
describe un rango de valores que la propiedad
podr contener en los Objetos (esto es instancias)
de la Clase.

Una Clase podr tener uno, varios o ningn

atributo.

Todo Objeto de la Clase tiene un valor especifico

en cada atributo.

UML da la opcin de indicar informacin adicional

a los Atributos como su tipo o valor Default.

OPERACIONES O MTODOS
Es lo que la Clase puede realizar, o que usted
(u otra Clase) pueden hacer a una Clase.

As como es posible adicionar informacin a los

Atributos, tambin se puede hacer en los
Mtodos.

Entre los parntesis que preceden al nombre

podrn mostrar el parmetro con que
funcionara y su tipo de dato. Si devuelve un
valor, tambin se puede mostrar el tipo de
dato a devolver. Esto se conoce como la Firma
de la Operacin o del Mtodo.

ATRIBUTOS, MTODOS
Y CONCEPCIN
En

ocasiones para no saturar

un Diagrama de Clase de
tantos Atributos y Mtodos,
se puede representar la Clase
sin sus Caractersticas.

En ocasiones solo se necesite

mostrar algunas de ellas o las
mas Importantes para el Diseo.

RESPONSABILIDADES
Y RESTRICCIONES
En un rea o cuadro abajo de los
Mtodos
se
puede
mostrar
responsabilidad de la Clase.

la

La Responsabilidad es una descripcin

breve de lo que har la Clase.

Las Restricciones son reglas que llevan

los Atributos para la capacidad de

contener uno o tres posibles valores.

La forma de representar una restriccin

es con un texto libre bordeado por

llaves donde especifica los valores a
contener.

NOTAS ADJUNTAS

Por encima de los Atributos, Mtodos, responsabilidades

y restricciones se pueden adicionar mas informacin por
intermedio de las Notas Adjuntas.

Una Nota puede contener tanto texto como imagen.

casos de uso

 Los

CASOS DE USO

Casos de Uso es una tcnica para capturar

informacin de cmo un sistema o negocio
trabaja, o de cmo se desea que trabaje.

Ayuda a obtener requerimientos desde el punto de

vista
del
Usuario
(actor),
funcionalidad del sistema.

Es

modelando

la

el poderoso concepto que ayuda al analista a

comprender la forma en que un Sistema deber
comportarse.

ELEMENTOS DE LOS
CASOS DE USO
Actor:

rol

que juega un
usuario con respecto
al sistema.

un

Actor
no
necesariamente
representa
a
una
persona
en
particular, sino ms
bien la labor que
realiza
frente
al
sistema.

Caso de Uso:
l
Operacin o tarea especfica que se realiza
tras una orden de algn agente externo,
originada por una peticin de un actor o
bien desde la invocacin desde otro caso de
uso

RELACIONES DE LOS
CASOS DE USO

Enc ontrar por

Titulo

Asociaciones
Dependencia o Instanciacin
Inclusin

Busc ar en la BD
Pelic ulas

Cliente
Enc ontrar por
Ac tor

<<include>>

Dependenci
a

<<include>>

Estereotipo

Extensin
<<extend>>

<<include>>

Apuntar Pelic ula

<<extend>>

Cajero

Generalizacin.
Agente Proveedor

Comprar Gaseosa

Comprar un Vaso
de Gaseosa
Rebastecedor

Recolector

Contabilizar
Ingresos

RELACIONES DE LOS
CASOS DE USO

CASOS DE USO - UTILIDAD

Modelar el comportamiento de un elemento (sistema,

subsistema, clase):
Centrarse en qu hace el elemento, NO en cmo lo hace.
1) Sirven para intercambiar opiniones los expertos del
dominio, los usuarios finales y los desarrolladores.

2) El creador del elemento comunica cmo se debera

usar.
El elemento puede ser complejo y tener muchas
operaciones.

3) Sirven de base para probar el sistema una vez

implementado.

Pasos a seguir:

CASOS DE USO

Identificar los actores que interactan con el elemento.

Organizar los actores (roles generales, roles
especializados, ).

Considerar las formas ms importantes que tiene cada

actor de interactuar con el elemento.

Considerar

las formas excepcionales que tiene cada

actor de interactuar con el elemento.

Organizar

estos comportamientos
relaciones entre casos de uso vistas.

Especificar
eventos.

utilizando

las

cada caso de uso con texto y trazas de

Sugerencias y consejos:

CASOS DE USO

Cada

caso
de
uso
debe
representar
un
comportamiento distinto e identificable del sistema
(razonablemente atmico).

Factorizar el comportamiento comn: include.

Factorizar las variantes de comportamiento: extends.
Describir el flujo de eventos de manera
suficientemente clara para que alguien externo lo
entienda.

Mostrar slo los importantes para comprender el

comportamiento del sistema.

Mostrar slo los actores implicados.

DIAGRAMA DE OBJETOS
Un diagrama de objetos es una instancia de un diagrama de
clases; muestra una 'foto' del estado de un sistema en un
punto de tiempo determinado.

La notacin UML de un objeto es similar a una clase:

o Se muestran valores de los atributos
o Los mtodos no estn incluidos.
o Adems del nombre de la clase, podemos dar un nombre al objeto.

DIAGRAMAS DE SECUENCIA
Undiagrama de secuenciamuestra la interaccin de un
conjunto de objetos en una aplicacin a travs del tiempo y
se modela para cada caso de uso.

Los elementos del Diagrama de Secuencia son:

o Objetos
o Mensajes
o Tiempo
o Recursividad

DIAGRAMA DE ESTADOS
Un diagrama de estados muestra el flujo de control entre

estados (en qu estados posibles puede estar cierto algo y

como se producen los cambios entre dichos estados).

Estado
Transicin
Estado Inicial
Estado Final

DIAGRAMA DE ESTADOS

DIAGRAMAS DE ACTIVIDADES
Un Diagrama de Actividades no es ms que un caso especial de
un diagrama de estados, en el que todos los estados (o la gran
mayora) son actividades
Qu es una actividad y cul es la diferencia con un estado?

Si estoy contento, eso es un estado o una actividad?

Cul es la diferencia entre estar contento o preparar una
torta?
Cmo paso de contento a triste?
Qu sucede despus de que termino de preparar la torta?

DIAGRAMAS DE ACTIVIDADES
Notacin
La notacin del diagrama de actividades es el siguiente:

Actividades
Acciones
Restricciones de Accin
Flujo de Control
Nodo Inicial
Nodo Final
Flujos de Objetos y Objeto
Nodos de Decisin y Combinacin
Nodos de Bifurcacin y Unin
Regin de Expansin
Gestores de Excepcin
Regin de Actividad Interrumpible
Particin

DIAGRAMAS DE ACTIVIDADES

DIAGRAMA DE COLABORACIN
Un Diagrama de Colaboracin muestra una interaccin organizada basndose
en los objetos que toman parte en la interaccin y los enlaces entre los
mismos (en cuanto a la interaccin se refiere).

Objetos o Roles: nodos del grafo.

Enlaces o comunicaciones: arcos del grafo.
Mensajes: llevan nmero de secuencia y flecha dirigida.
Anidamiento: se utiliza la numeracin decimal Ej: 1, 1.1, 1.1.1 ........
Iteracin: colocar un * antes del nmero de secuencia y una clusula de
condicin, si es necesario. ej. *[x>0].

Bifurcacin: los caminos alternativos tendrn el mismo nmero de secuencia,

seguido del nmero de subsecuencia, y se deben distinguir por una condicin.

DIAGRAMA DE COLABORACIN

DIAGRAMA DE COMPONENTES
El objetivo del diagrama de componentes es modelar el sistema o
subsistema que se implementara tal cual es.
Normalmente los diagramas de Componentes contienen:
Componentes
Interfaces
Relaciones
Paquetes o subsistemas

DIAGRAMA DE COMPONENTES

DIAGRAMA DE DISTRIBUCIN
Muestra la estructura fsica de un

sistema, las mquinas, los dispositivos,

las interconexiones entre dispositivos y
las piezas de software que se
encontrarn en cada mquina.

El elemento primordial de este esquema

es el nodo, que es el nombre genrico
que recibe cualquier tipo de recurso.
Este nodo, se representa como un cubo.

DIAGRAMA DE DISTRIBUCIN

C
A
R
G

!
S
IA

WEB GRAFA
https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado
http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html
http://es.slideshare.net/d-draem/diagramas-de-colaboracion-8052167
http://ocw.unizar.es/ciencias-experimentales/modelos-matematicos-en-bases-dedatos/uml/02UML_DiagramaActividades.pdf

http://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.pdf
http://www.docirs.cl/uml.htm
http://www.milestone.com.mx/articulos/el_lenguaje_unificado_de_modelado.htm
http://users.dcc.uchile.cl/~psalinas/uml/introduccion.html
https://msdn.microsoft.com/es-es/library/dd409390.aspx
http://wikiuml.wikispaces.com/Diagrama+de+Componentes