LENGUAJE UNIFICADO DE MODELADO

INTEGRANTES

o JOEL CONDORI LUCANA

o ELMER DANY HUAMANI MELO

o ALEXANDER SAUNI MAUCAYLLA

o ERICK FRANCO DEL CASTILLO DEZA

HISTORIA• Versiones:

Antes de UML 1.x (1994 - 1996)

los Tres Amigos (Rumbaugh, Jacobson y Booch)

El OMT (Object-modeling technique) de Rumbaugh mejor para el análisis orientado a objetos

Ivar Jacobson, creador del método de ingeniería de software orientado a objetos

Método Booch de Grady Booch mejor para el diseño 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 especificación UML 1.0 de UML Partners fue propuesto a la OMG (Object Management Group) en enero de 1997.

Grady Booch Ivar Jacobson James Rumbaugh

HISTORIA

UML 2.x (2005 - Presente)

La revisión mayor UML 2.0 que fue adoptada por el OMG en 2005

Desde el año 2005, UML es un estándar aprobado por la ISO como ISO/IEC 19501:2005

UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y 2.1.2, aparecieron en 2007

UML 2.5 fue lanzado en octubre de 2012 como una versión "En proceso" y todavía tiene que ser formalmente liberada.

¿QUÉ ES UML?Es una herramienta o Lenguaje de Modelamiento Unificado

que permite a los creadores de Sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender y así poder comunicárselas a otras personas.

“UML es un lenguaje visual para especificar, construir y documentar sistemas” (OMG - Object Management Group)

¡UML no es Metodología!

VISTA DE UML

DIAGRAMAS DE UMLLos diagramas expresan gráficamente partes de un modelo.

Diagrama de Secuencia

Diagrama de Caso de Uso

Diagrama de Clases

Diagrama de Objetos

Diagrama de Componentes

Diagrama de DistribuciónDiagrama de

Actividad

Diagrama de Estados

Diagrama de Colaboración

Modelo

¿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 es satisfacer a cada Persona involucrada.

• Cabe recalcar que en UML no es necesario que aparezcan todos los Diagramas.

ORIENTACIÓN A OBJETOS

• La Programación Estructurada tradicional se basa en la

Ecuación de Wirth:

Algoritmos + Estructuras de Datos = Programas

Estos significa que los Datos y el Código se trata por

separado.

• La OOP es una técnica de programación cuyo soporte

es el Objeto.

• Objeto: es una extensión de un Tipo Abstracto de

Datos (TAD).

• El TAD es un tipo definido por el Usuario, que

encapsula un conjunto de datos y las operaciones

sobre estos datos.

OBJETOS Y CLASES• Una clase es una definición abstracta de un objeto

• Define la estructura y el comportamiento compartidos por los objetos

• Sirve como modelo para la creación de objetos

• Los objetos pueden ser agrupados en clases

PILARES DE LA ORIENTACIÓN A

OBJETOS

Polimorfismo

HerenciaAbstracción

Encapsulamiento

ABSTRACCIÓN• Es quitar las Propiedades y Acciones de un Objeto y dejar

solo las necesarias.

• Ignorancia Selectiva

• La abstracción nos ayuda a trabajar con cosas complejas

• Se enfoca en lo importante

• Ignora lo que no es importante (simplifica)

• Una clase es una abstracción en la que:

• Se enfatizan las características relevantes

• Se suprimen otras características

• Una clase debe capturar una y solo una abstracción clave

HERENCIA• Es la Cualidad mas

importante de la OOP.

• Es un mecanismo mediante el cual se puede crear una nueva clase partiendo de una existente, se dice que la nueva clase hereda las características de la clase existente, aunque se le puede añadir mas capacidades o modificar las que tiene.

VehiculoDeMotor

Attributes+ Cilindrada : int+ NumeroDeRueda : int

Operations+ acelelar() : void

Coches

Attributes+ NumeroDePuertas : int

Operations

Motos

Attributes+ TipoCarenado : string

Operations

POLIMORFISMO

• En ocasiones una acción tiene el mismo nombre en diferentes Clases o en la misma, pero realizara una operación diferente.

• Es la posibilidad de que dos Métodos implementen distintas acciones, aun teniendo el mismo nombre, dependiendo del Objeto que lo ejecuta o de los parámetros que recibe.

• La Sobrecarga es un tipo especial del Polimorfismo.

• Varios Métodos con el mismo nombre, siempre y cuando que el tipo de parámetros que recibe o el numero sean diferentes.

POLIMORFISMO - EJEMPLO

• La definición del método reside en la clase base

• La implementación del método reside en la clase derivada

• La invocación es resuelta al momento de ejecución

Transporte

Avanzar

Frenar Transporte

Avanzar

Frenar

Transporte

Avanzar

Frenar

Transporte

Avanzar

Frenar

ENCAPSULAMIENTO• Es el ocultamiento de la Funcionalidad interna de

sus operaciones, de otros objetos y del mundo exterior.

ENCAPSULAMIENTO• Principio 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 de la complejidad de la implementación interna

• Permite exponer el estado del objeto sólo a través del comportamiento que le hayamos definido mediante miembros públicos

• ¿Por qué es útil?

• Punto de Control/Validación

• Mejor respuesta ante los Cambios

DIAGRAMAS DE UML

CONCEPCIÓN DE CLASES• La Clase se representa con un Rectángulo.

• Existen diferentes tipo de Clases:

• Abstracta.

• Base.

• Contenedora o Compuesta.

• Derivada.

• Hija.

• Padre.

• Super-Clase.

• Sub-Clase.

Ejemplo de una Clase:

VehiculosDeMotorCilindradaNumero de Ruedas

acelelar()

VehiculoDeMotor

Attributes

+ Cilindrada : int

+ NumeroDeRueda : int

Operations

+ acelelar() : void

RELACIONES• Todo sistema abarca muchas clases y objetos

• Los objetos contribuyen en el comportamiento de un sistema colaborando entre si

• La colaboración se logra a través de las relaciones

• Existen dos tipos principales de relaciones

• Asociación

• Agregación

ASOCIACIONES

• Son las relaciones entre los Objetos (Clases).

• Es una relación estructural que especifica que los Objetos de un elemento están conectados con los Objetos de otro.

• Los Objetos se pueden asociar con otro en mas de una forma y dirección.

• Un Objeto se puede asociar con mas de un Objeto y de diferentes Clase o Característica.

• Es posible que la Asociación se dé de manera recursiva en un Objeto

ASOCIACIONES• Existen cuatro adornos que se aplican a las

asociaciones para facilitar su comprensión:

• Nombre.

• Rol.

• Multiplicidad.

• Agregación.

• Composición.

Es la Asociación entre un Jugador y un Equipo

Es el papel que representa cada Clase en la Asociación

ASOCIACIONES

Diferente Característi

ca

Relaciones Complejas

RESTRICCIONES EN LAS ASOCIACIONES

• En Asociaciones entre Clases pueden existir ciertas reglas.

• Se establece una Restricción en una Asociación. En este caso, la Asociación “Atiende“ está restringida para que el Cajero atienda al Cliente en turno.

• Otro tipo de Restricción es la relación O (distinguida como {Or}) en una línea discontinua que conecte a dos líneas de Asociación.

CLASE DE ASOCIACIÓN• Una Asociación igual que una Clase, puede

contener Atributos y Métodos. Esto se llama Clase de Asociación.

• Una Clase de Asociación puede tener asociaciones con otras Clases.

Jugador

Attributes

Operations

Equipo

Attributes

Operations

Participa en >>

Attributes

Operations

DirectorGeneral

Attributes

Operations

Participa en >>

Negociado por >>

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 Relación consigo mismo.

HERENCIA Y GENERALIZACIÓN• La Herencia y Generalización es lo mismo.

• Es cuando una SubClase o Clase Secundaria puede heredar los Atributos y Métodos de otra Clase (Clase Principal o SuperClase).

• La Clase Principal es mas genérica en su definición.

DEPENDENCIA• Una relación de dependencia significa que una

clase es dependiente de otra por algún servicio.

• Una relación 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 a las instancias de la clase

proveedora.

• Es cuando una Clase utiliza a otra Clase.

Formulario

Sistema

Attributes

Operations

+ mostrarFormulario() : void

AGREGACIÓN• Es una estrecha relación que existen entre varios

Objetos.

• En un Objeto que se conforma de una combinación 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 después 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 (creación, mantenimiento, disposición, etc).

MesaDeCafe

SuperficieDeLaMesa Pata

1

1 4

DIAGRAMA DE CONTEXTO• El Diagrama de Contexto es como el mapa detallado de

alguna sección de un mapa de mayores dimensiones.

• Pueden ser necesarias varias secciones para capturar toda la información.

• Cuando se modele un Sistema puede producirse, con frecuencia, agrupamiento de Clases, como Agregaciones o Composiciones.

Manga

Botonadura

Talla Cuello

Boton Ojal

11 1

0,2,3

[1]

<< esta cosida en5,6

1<< esta cosida en

1

1

<< esta cosida en

2 2esta cosida en >> 11 << esta cosido en

1 1se abotona en >>

INTERFACES• Es un conjunto de operaciones (Métodos) que especifica cierto

aspecto de la funcionalidad de una Clase, y es un conjunto de operaciones (Métodos) que una Clase presenta a otras.

• Permite que clases que no están estrechamente relacionadas entre sí deban tener el mismo comportamiento.

• La implementación de una interfaz es un contrato que obliga a la clase a implementar todos los métodos 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

Attributes+ marca : string+ cantidadDeTeclas : int

Operations+ Ctrl() : void+ Alt() : void+ RePag() : void+ AvPag() : void

<<interface>>

MaquinaDeEscribir

Attributes

Operations+ Teclazo() : void

VISIBILIDAD • Identifica la visibilidad de un Atributo o Método.

• Tipos de Visibilidad:oPúblicos (+).

oPrivados (-).

oProtegidos (#)

CONSTRUCTORES Y DESTRUCTORES

• Constructores: Para poder utilizar un Objeto, previamente debemos crearlo mediante el Constructor de la Clase. Este Método nos devuelve un objeto nuevo de una Clase. Normalmente el los lenguajes de programación estos Métodos 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 símbolos, liberar la memoria ocupada, etc.

ATRIBUTOS

• Es una propiedad o característica 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 ningún atributo.

• Todo Objeto de la Clase tiene un valor especifico en cada atributo.

• UML da la opción de indicar información adicional a los Atributos como su tipo o valor Default.

OPERACIONES O MÉTODOS

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

• Así como es posible adicionar información a los Atributos, también se puede hacer en los Métodos.

• Entre los paréntesis que preceden al nombre podrán mostrar el parámetro con que funcionara y su tipo de dato. Si devuelve un valor, también se puede mostrar el tipo de dato a devolver. Esto se conoce como la Firma de la Operación o del Método.

ATRIBUTOS, MÉTODOS Y CONCEPCIÓN

• En ocasiones para no saturar un Diagrama de Clase de tantos Atributos y Métodos, se puede representar la Clase sin sus Características.

• En ocasiones solo se necesite mostrar algunas de ellas o las mas Importantes para el Diseño.

RESPONSABILIDADES Y RESTRICCIONES

• En un área o cuadro abajo de los Métodos se puede mostrar la responsabilidad de la Clase.

• La Responsabilidad es una descripción 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 restricción es con un texto libre bordeado por llaves donde especifica los valores a contener.

NOTAS ADJUNTAS• Por encima de los Atributos, Métodos,

responsabilidades y restricciones se pueden adicionar mas información por intermedio de las Notas Adjuntas.

• Una Nota puede contener tanto texto como imagen.

casos de uso

CASOS DE USO• Los Casos de Uso es una técnica para capturar

información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje.

• Ayuda a obtener requerimientos desde el punto de vista del Usuario (actor), modelando la funcionalidad del sistema.

• Es 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 más bien la labor que realiza frente al sistema.

Caso de Uso:l Operación o tarea específica que se

realiza tras una orden de algún agente externo, originada por una petición de un actor o bien desde la invocación desde otro caso de uso

RELACIONES DE LOS CASOS DE USO

• Asociaciones

• Dependencia o Instanciación

• Inclusión

<<include>>

• Extensión

<<extend>>

• Generalización.

Cliente

Encontrar porTitulo

Encontrar porActor

Buscar en la BDPeliculas

<<include>>

<<include>>

Dependencia

Cajero

Apuntar PeliculaContabilizar

Ingresos

<<extend>>

Estereotipo

Comprar GaseosaComprar un Vaso

de Gaseosa

Agente Proveedor

Rebastecedor Recolector

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 cómo lo hace.• 1º) Sirven para intercambiar opiniones los expertos del

dominio, los usuarios finales y los desarrolladores.

• 2º) El creador del elemento comunica cómo se debería usar.

El elemento puede ser complejo y tener muchas operaciones.

• 3º) Sirven de base para probar el sistema una vez implementado.

CASOS DE USOPasos a seguir:

• Identificar los actores que interactúan con el elemento.

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

• Considerar las formas más 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 utilizando las relaciones entre casos de uso vistas.

• Especificar cada caso de uso con texto y trazas de eventos.

CASOS DE USOSugerencias y consejos:

• Cada caso de uso debe representar un comportamiento distinto e identificable del sistema (razonablemente atómico).

• Factorizar el comportamiento común: include.

• Factorizar las variantes de comportamiento: extends.

• Describir el flujo de eventos de manera suficientemente clara para que alguien externo lo entienda.

• Mostrar sólo los importantes para comprender el comportamiento del sistema.

• Mostrar sólo 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 notación UML de un objeto es similar a una clase:oSe muestran valores de los atributos

oLos métodos no están incluidos.

oAdemás del nombre de la clase, podemos dar un nombre al objeto.

DIAGRAMAS DE SECUENCIA• Un diagrama de secuencia 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.

• Los elementos del Diagrama de Secuencia son:oObjetos

oMensajes

oTiempo

oRecursividad

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

• Transición

• Estado Inicial

• Estado Final

DIAGRAMA DE ESTADOS

DIAGRAMAS DE ACTIVIDADES

Un Diagrama de Actividades no es más que un caso especial de un diagrama de estados, en el que todos los estados (o la gran mayoría) son actividades

• ¿Qué es una actividad y cuál es la diferencia con un estado?• ¿Si estoy contento, eso es un estado o una actividad?• ¿Cuál es la diferencia entre estar contento o preparar una torta?• ¿Cómo paso de contento a triste?• ¿Qué sucede después de que termino de preparar la torta?

Notación

La notación del diagrama de actividades es el siguiente:

• Actividades

• Acciones

• Restricciones de Acción

• Flujo de Control

• Nodo Inicial

• Nodo Final

• Flujos de Objetos y Objeto

• Nodos de Decisión y Combinación

• Nodos de Bifurcación y Unión

• Región de Expansión

• Gestores de Excepción

• Región de Actividad Interrumpible

• Partición

DIAGRAMAS DE ACTIVIDADES

DIAGRAMAS DE ACTIVIDADES

DIAGRAMA DE COLABORACIÓN

Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere).

• Objetos o Roles: nodos del grafo.

• Enlaces o comunicaciones: arcos del grafo.

• Mensajes: llevan número de secuencia y flecha dirigida.

• Anidamiento: se utiliza la numeración decimal Ej: 1, 1.1, 1.1.1 ........

• Iteración: colocar un * antes del número de secuencia y una cláusula de condición, si es necesario. ej. *[x>0].

• Bifurcación: los caminos alternativos tendrán el mismo número de secuencia, seguido del número de subsecuencia, y se deben distinguir por una condición.

DIAGRAMA DE COLABORACIÓN

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 DISTRIBUCIÓN

• Muestra la estructura física de un sistema, las máquinas, los dispositivos, las interconexiones entre dispositivos y las piezas de software que se encontrarán en cada máquina.

• El elemento primordial de este esquema es el nodo, que es el nombre genérico que recibe cualquier tipo de recurso. Este nodo, se representa como un cubo.

DIAGRAMA DE DISTRIBUCIÓN

GRACIAS!

WEB GRAFÍA

• 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-de-datos/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