Modelo Conceptual de UML

Mecanismos comunes De UML

Bloques bsicos de construccin UML

UML

Reglas de UML para Combinar los Bloques bsicos

Bloques bsicos de construccin UML

Elementos
Estructurales De Comportamiento De Agrupacin De Anotacin Dependencia Asociacin Generalizacin Realizacin Casos de Uso Clases Objetos Secuencia

Relaciones

Diagramas de

Colaboracin Estados Actividades Componentes Despliegue

Modelos y Diagramas
Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle.
Diagrama: una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos

Antecedentes
Metodologa orientada a Datos (DFDs)
Los procesos de anlisis y diseo de sistemas se hacan basndose en mtodos desarrollados por personas como Tom de Marco, Edward Yourdon entre muchos. Esta metodologa consideraba primordialmente a los procesos y los flujos de informacin que existan entre cada uno de ellos. Por supuesto antes de stas existan otras tales como HIPO y Warnier que tomaban en cuenta ms a los datos.

Antecedentes
Metodologa Orientada a objetos
Con la modernizacin y actualizacin de los conceptos de programacin orientada a objetos, la fase de anlisis requera una modernizacin hacia esta nueva tendencia Autores como James Rumbaugh, Grady Booch y Jacobson, trabajaron cada uno por su cuenta en la elaboracin de metodologas orientadas a objetos

Antecedentes
As trabajaron durante algn tiempo hasta que OMG (Object Management Group) los invita a participar en el proyecto de unificacin de cada una de las metodologas, que si bien gozaban de su propia individualidad, tenan varios puntos en comn. De esta manera estos tres autores se hacen cargo de combinar las metodologas y bajo la supervisin de OMG desarrollan lo que actualmente conocemos como UML ( Unified Modeling Languaje ) Lenguaje Unificado de Modelado.

Surgimiento de UML
Por qu UML? Las razones para usar UML difieren de acuerdo al contexto. Si alguno pregunta por qu cambiar de alguno de los mtodos anteriormente desarrollados por Rumbaught, Booch o Jacobson, la respuesta sera debido a que UML es un de los ms desarrollados, es un real sucesor de los 3 mtodos anteriores. La mayora de los nuevos desarrollos de software soportan herramientas basadas en UML. Si la pregunta se hace en el contexto de que se est iniciando un desarrollo utilizando cualquier mtodo de anlisis orientado a objetos, la respuesta es simple sese cualquier mtodo.

Hay algunos beneficios, los cuales no son tan obvios y similares para todos los mtodos anteriormente mencionados.

Surgimiento de UML
Comunicacin mejorada Ocultando/resaltando hechos Seleccionando la vista para la interfaz/implementacin Buena estandarizacin

OBJETOS
POSEE ATRIBUTOS, POSEE IDENTIDAD, ESTADO Y COMPORTAMIENTO.

Qu es un objeto? Un objeto es un componente de software que contiene variables y mtodos y que es usado para modelar algn aspecto de la vida real. Es una abstraccin de la realidad.

Los objetos son representaciones (simples/complejas), (reales/imaginarias) de cosas: reloj, avin empleado, etc. No todo puede ser considerado como un objeto, algunas cosas son simplemente caractersticas o atributos de los objetos: color, velocidad, etc.

EN LOS OBJETOS PODEMOS DETERMINAR LO SIGUIENTE:

1. ABSTRACCIN FUNCIONAL:

Hay cosas que sabemos que los coches hacen pero no como lo hacen: avanzar parar girar a la derecha girar a la izquierda
2. ABSTRACCIN DE DATOS:

Un coche tiene adems ciertos atributos: color velocidad tamao etc...

REPRESENTACIN DE UN OBJETOS
Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, segn la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre especfico, entonces slo aparece el nombre de la clase.

NOMBRE DEL OBJETO

NOMBRE DEL OBJETO NOMBRE DE LA CLASE

:NOMBRE DE LA CLASE

OBJETO ANNIMO

Garcia Lorca: Persona nombre: Federico direccin: Huerta de san V ciudad: Granada

Cervantes
: Persona Objeto sin nombre De clase Objeto annimo de La clase persona

MTODOS Y MENSAJES
UN PROGRAMA O.O CONSISTE EN UN NMERO DE OBJETOS QUE SE COMUNICAN UNOS CON OTROS LLAMANDO A FUNCIONES MIEMBROS. LAS FUNCIONES MIEMBROS EN UN OBJETO SE DENOMINAN MTODOS LOS MTODOS O FUNCIONES MIEMBROS (PROCEDIMIENTOS Y FUNCIONES), RESIDEN EN EL OBJETO Y DETERMINAN CMO ACTAN LOS OBJETOS CUANDO RECIBEN UN MENSAJE.

UN MENSAJE ES LA ACCIN QUE HACE UN OBJETO.

UN MTODO ES EL PROCEDIMIENTO O FUNCION QUE SE INVOCA PARA ACTUAR SOBRE UN OBJETO. ESPECIFCA CMO SE EJECUTA UN MENSAJE.

ESTRUCTURALMENTE UN MENSAJE CONSTA DE TRES PARTES:

IDENTIDAD DEL RECEPTOR (OBJETO QUE RECIBE). EL MTODO QUE SE HA DE EJECUTAR. INFORMACION PARA REALIZAR EL MTODO INVOCADO.

CARCULAR_PRECIO()

VENTAS

PRODUCTOS

CARACTERSTICAS ALREDEDOR DE UN OBJETO:

Estado:
El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objeto.

Persistencia:
La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruya.

Comunicacin:
Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico. El comportamiento global se basa pues en la comunicacin entre los objetos que la componen.

CATEGORAS DE OBJETOS 1. Activos o Pasivos 2. Cliente Servidores 3. Agentes Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad. Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio. Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitado. Los agentes renen las caractersticas de clientes y servidores. Son la base del mecanismo de delegacin. Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente.

Clases
QU ES UNA CLASE? Una clase es un plano o prototipo que define las variables y los mtodos comunes a todos los objetos de un cierto tipo. Las clases se pueden utilizar para capturar el vocabulario del sistema que se est desarrollando El modelado de un sistema implica identificar las cosas que son importantes desde un cierto punto de vista particular Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.

Nombres, Atributos, Operaciones Organizacin de operaciones y atributos Responsabilidades: es un contrato o una obligacin de una clase. Se pueden expresar en comportamientos separados al final del icono de la clase.

Hay una serie de tipos de clases recurrentes en la construccin de modelos. Uno se centra ms bien en grupos de clases que interactan entre s. En UML, estas sociedades de clases forman colaboraciones y normalmente se representan en diagramas de clases.

CLASE

NOMBRE DE LA CLASE

+ PBLICA # PROTEGIDA -PRIVADA

+ PBLICA # PROTEGIDA -PRIVADA

NOMBRE DE LA CLASE Atributo Atributo: tipo_dato Atributo: tipo_dato=valor_i Operacin()

NOMBRE DE LA CLASE Atributo Atributo: tipo_dato Atributo: tipo_dato=valor_i

ATRIBUTOS Y MTODOS DE UNA CLASE:

Atributos: Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son: public ( + ): Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
private ( - ): Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar). protected ( # ): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de las subclases que se deriven.

MTODOS:

Los mtodos u operaciones de una clase son la forma en como sta interacta con su entorno, stos pueden tener las caractersticas: public ( + ): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
private ( - ): Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden accesar). protected ( # ): Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de mtodos de las subclases que se deriven.

Clases - Atributos
Cules de las siguientes declaraciones son vlidas?
Origen + origen & origen *Cabeza: Item Nombre [0..+] : String Id: Integer {frozen} Id: Integer = {0,0} OK OK NO NO

NO
OK

OK

Clases - Operaciones
Cules de las siguientes declaraciones son vlidas?
mostrar + mostrar set(n: nombre, s: string) (0,0) obtenerID() :Integer reiniciar() :{concurrent} OK

OK
NO

OK
NO

Ejemplo de Clases de Un Sistema

ABSTRACCIN.
Caracterizacin de un objeto de acuerdo a las propiedades que nos interesen en un instante de tiempo. Las caractersticas escogidas son relativas a la perspectiva del observador.

Abstraccin:
cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin.

Encapsulamiento:
tambin llamado "ocultacin de la informacin". Cada objeto est aislado del exterior, es un mdulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cmo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas.

Polimorfismo:
comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en una referencia producir el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin tarda o asignacin dinmica.
Polimorfismo El concepto de Polimorfismo es uno de los fundamentos para cualquier lenguaje orientado a Objetos, las mismas races de la palabra pueden ser una fuerte pista de su significado: Poli =
Multiple, morfismo= Formas

, esto implica que un mismo Objeto

puede tomar diversas formas. A travs del concepto de Herencias ("Inheritance") es posible ilustrar este comportamiento

EXPLICITO

ES UNA FIGURA IMPLICITO

es una Figura (" fuera de un tipo El poder manipular un Objeto como si ste
genrico otorga mayor flexibilidad al momento de programar con Objetos, el trmino Polimorfismo tambin es asociado con un concepto llamado Late-Binding (Ligamiento Tardo), observe el siguiente fragmento de cdigo:

Figura a = new Circulo(); Figura b = new Triangulo();

Inicialmente se puede pensar que este cdigo generara un error debido a que el tipo de referencia es distinta a la instancia del objeto, sin embargo, el fragmento anterior es correcto

HERENCIA
las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementar su comportamiento. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un objeto pertenece a ms de una clase se llama herencia mltiple; esta caracterstica no est soportada por algunos lenguajes (como Java).

LA HERENCIA SUPONE UNA CLASE BASE Y UNA JERARQUA DE CLASES QUE CONTIENEN LAS CLASES DERIVADAS DE LA CLASE BASE. LAS CLASES DERIVADAS HEREDAN CARACTERSTICAS DE SU CLASE BASE, PERO AADEN OTRAS CARACTERSTICAS PROPIAS NUEVAS.

CARACTERISTICA A

CARACTERISTICA B

CARACTERISTICA A
CARACTERISTICA B

CARACTERISTICA A
CARACTERISTICA B

CARACTERISTICA A
CARACTERISTICA B

CARACTERISTICA X

CARACTERISTICA Y CARACTERISTICA Z

CARACTERISTICA W

TIPOS DE HERENCIA
HERENCIA SIMPLE (HERENCA JERRQUICA): EN ESTA JERARQUA CADA CLASE TIENE COMO MXIMO UNA SOLA SUPERCLASE. LA HERENCIA SIMPLE PERMITE QUE UNA CLASE HEREDE LAS PROPIEDADES DE SU SUPERCLASE EN UNA CADENE JERRQUICA.
ARTCULO

VIDEO AUDIO

ALTAVOCES

RADIO

CASSETTE

CD

AMPLIFICADOR

VEHCULO

AUTO
CAMION

AUTOBUS

CAMIONETA

REMOLQUE

TRAILER

HERENCIA MLTIPLE (HERENCIA EN MALLA):

UNA MALLA CONSTA DE CLASES, CADA UNA DE LAS CUALES PUEDE TENER UNA O MS SUPERCLASES INMEDIATAS.

UNA HERENCIA MLTIPLE ES AQUELLA EN LA QUE CADA CLASE PUEDE HEREDAR MTODOS Y VARIABLES DE CUALQUIER NMERO DE SUPERCLASE.
PERSONA

ESTUDIANTE

EMPLEADO

ESTUDIANTE_TRABAJADOR

RELACIONES ENTRE CLASES:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o ms clases (cada uno con caractersticas y objetivos diferentes). Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relacin y stas pueden ser: uno o muchos: 1..* (1..n) 0 muchos: 0..* (0..n) nmero fijo: m (m denota el nmero).

OPCIONES DE CARDINALIDAD
1 EXACTAMENTE 1

N
0..N 1..N 3..8 1..4,7

NMERO ILIMITADO
CERO O MS UNO O MS RANGO ESPECIFICADO RANGO ESPECIFICADO O NMERO EXACTO

Relaciones
Una relacin es una conexin entre elementos. Una dependencia es una relacin de uso que declara que un cambio en la especificacin de un elemento puede afectar a otro elemento que la utiliza, pero no a la inversa. La mayora de las veces, las dependencias se utilizarn en el contexto de las clases, para indicar que una clase utiliza a otra como argumento en la signatura de una operacin.

RELACIONES ENTRE CLASES

GENERALIZACIN / ESPECIALIZACION (ES_UN) AGREGACIN (TODO_PARTE, TIENE_UN) ASOCIACIN

USO
INSTACIACIN (PLANTILLAS)

METACLASES.

LAS RELACIONES QUE SE PUEDEN UTILIZAR EN UML SON: ASOCIACIN GENERALIZACIONES DEPENDENCIAS Y REFINAMIENTOS

DEFINICIONES DE UML: ASOCIACIN: EN UML, UNA ASOCIACIN SE DEFINE COMO LA RELACIN QUE DESCRIBE UN CONJUNTO DE ENLACES, DONDE ENLACE SE DEFINE COMO UNA CONEXIN SEMNTICA ENTRE UNA TABLA DE OBJETOS.
GENERALIZACIN: EN UML, UNA GENERALIZACIN SE DEFINE COMO LA RELACIN ENTRE UN ELEMENTO GENERAL Y UNA MS ESPECFICO. DEPENDENCIA: EN UML, SE DEFINE COMO UNA RELACIN ENTRE ELEMENTOS, UNO DEPENDIENTE Y OTRO INDEPENDIENTE. UN CAMBIO EN EL ELEMENTO INDEPENDIENTE AFECTARA AL ELEMENTO DEPENDIENTE. REFINAMIENTO: EN UML, SE DEFINE COMO LA RELACIN ENTRE DOS DESCRIPCIONES DE LA MISMA COSA EN DIFERENTES NIVELES DE ABSTRACCIN. AGREGACIN: ES UNA FORMA DE ASOCIACIN EN LA QUE UN ELEMENTO CONTIENE OTRO ELEMENTO

GENERALIZACIN / ESPECIALIZACIN
UNA SUPERCLASE REPRESENTA UNA GENERALIZACIN DE LA CLASE SUPERIOR.
UNA SUBCLASE REPRESENTA UNA ESPECIALIZACIN DE LA CLASE SUPERIOR. DONDE LA CLASE DERIVADA ES_UN TIPO DE CLASE DE LA CLASE BASE O SUPERCLASE.

COMO POR EJEMPLO:

UNA MARGARITA ES_UN TIPO (UNA CLASE) DE FLOR.

UNA ROSA ES_UN TIPO (DIFERENTE) DE FLOR. UN PTALO ES_UNA PARTE DE DIFERENTES TIPOS DE FLORES.

JERARQUA DE GENERALIZACIN DE EMPLEADOS

EMPLEADO

ES_UN

ES_UN

ES_UN

TEC. MANTENI..

INFORMTICO

GERENTE

ES_UN

ES_UN

ES_UN

ANALISTA

PROGRAMADOR

OPERADOR

JERARQUA DE GENERALIZACIN MULTIPLE DE EMPLEADOS

EMPLEADO

ES_UN

ES_UN

ES_UN

TEC. MANTENI..

INFORMTICO

GERENTE

ES_UN

ES_UN

ES_UN

ANALISTA

PROGRAMADOR

OPERADOR

ANALISTA SENIOR

AGREGACIN: UNA AGREGACION EN UML SE CONSIDERA TAMBIEN COMO CASO ESPECIAL DE ASOCIACIN. EL AGREGADO INDICA QUE LA RELACIN ENTRE LAS CLASES ES UN TIPO DE TODO_PARTE. SE PUEDEN UTILIZAR TAMBIEN EN UML CONSTA_DE; CONTIENE; ES PARTE_DE; ES DECIR; PALABRAS QUE INDICAN RELACIN TODO / PARTE.

EN UML SE DISTINGUEN DOS TIPOS ESPECIALES DE AGREGACIN: AGREGADO COMPARTIDO AGREGADO DE COMPOSICIN.

EXISTE TAMBIEN AGREGACIN CON CONTENIDO FSICO Y AGREGACIN SIN CONTENIDO FSICO.

AGREGACIN CON CONTENIDO FSICO

COCHE
PARTE_DE

PARTE_DE

MOTOR

CHASIS

RUEDAS

TRANSMISIN

AGREGACIN SIN CONTENIDO FSICO

COMPAA

TIENE
DEPARTAMENTO

TIENE
SECCIN

AGREGACIN COMPARTIDA:
ES AQUELLA EN QUE LAS PARTES PUEDEN SER PARTES EN CUALQUIER OTRO TODO. LA AGREGACIN EST COMPARTIDA S LA MULTIPLICIDAD EN EL LADO TODO ES DISTINTA DE UNO (1).

CLASE TODO

*
CONTIENE

CLASE PARTE

EQUIPO

*
MIEMBROS

PERSONA

AGREGACIN COMPARTIDA

UNIVERSIDAD

*
TIENE

FACULTAD

UNA UNIVERSIDAD TIENE MUCHAS FACULTADES O ESCUELAS

AGREGACIN DE COMPOSICIN COMPUESTA:

UNA AGREGACIN COMPUESTA POSEE SUS PARTES; ES DECIR, EXISTE UN ALTO GRADO DE PERTENENCIA. LAS PARTES <<VIVEN>> DENTRO DEL TODO; Y SE DESTRUYEN JUNTO CON EL TODO.
LA MULTIPLICIDAD EN EL LADO CERO DEBE SER CERO O UNO (0..1), PERO EN EL LADO PARTE PUEDE SER UN INTERVALO

CLASE TODO

*
CONTIENE

CLASE PARTE

*
VENTANA CONTIENE

TEXTO BOTON MEN

CUADRO DE DIALOGO

* * *

ASOCIACIN (

ES UNA CONEXIN ENTRE CLASES, (ENLACE). UNA ASOCIACIN ES BIDIRECCIONAL, LO QUE SIGNIFICA ES QUE AL ASOCIARCE MBOS OBJETOS SE CONOCEN ENTRE S, Y REPRESENTAN UNA RELACIN ESTRUCTURAL ENTRE OBJETOS DE CLASES DIFERENTES.

PRODUCTO

VENTA

USA
PROGRAMADOR

COMPUTADORA

RECIBE_UN
ESTUDIANTE

CURSO

ETIQUETA (

ASOCIACION NABEGABLE, QUE SE UTILIZA EN UN EXTREMO DE LA ASOCIACION, UTILIZANDO EL SENTIDO DE LA FLECHA PARA HACERLO.

UTILIZA
USUARIO

COMPUTADORA

TIENE

UN USUARIO PUEDE UTILIZAR UNA O MAS COMPUTADORAS, Y UNA COMPUTADORA TIENE UNO O MAS USUARIOS

MULTIPLICIDAD
REPRESENTA EL NUMERO DE OBJETOS (RANGO), QUE INDICA CUANTOS OBJETOS SE PUEDEN ENLAZAR. EL RANGO PUEDE SER TODAS LAS OPCIONES DE LA CARDINALIDAD. LA MULTIPLICIDAD SE MUESTRA EN LOS EXTREMOS DE LOA ASOCIACION, EN LA CLASE DONDE ES APLICABLE.

MULTIPLICIDAD

EMPRESA

TRABAJA_PARA EMPLEA_A

1..N
EMPLEADO

PERSONA

EMPLEADOR NOMBRE DEL ROL (PAPEL)

NOMBRE DE LA ASOCIACION

MULTIPLICIDAD

PERSONA Nombre Fecha-nacim sexo

LicenciaCondu Direccin

NAVEGABILIDAD

Fechavencimi.

Multiplicidad 1: una licencia de conducir slo pertenece a una persona. Multiplicidad *: una persona puede tener muchas licencias de conducir.

ASOCIACIN NAVEGABLE:
UNA ASOCIACIN NAVEGABLE INDICA POR EJEMPLO QUE UNA PERSONA PUEDE POSEER MUCHOS CARROS, PERO NO INDICA NADA SOBRE CUNTAS PERSONAS PUEDEN POSEER LICENCIAS DE CONDUCIR. OTRO EJEMPLO SERIA EL SIGUIENTE:

POSEE
PERSONA

0..*
CARROS

CLASE ASOCIACION
UNA ASOCIACION PUEDE SER OTRA CLASE EN S MISMA; LA CLASE ASOCIACION EN NINGUNO DE LOS EXTREMOS DE LA ASOCIACION, SINO QUE SE CONECTA A LA ASOCIACION PROPIA. ESTA SE UTILIZA PARA AADIR INFORMACION EXTRA EN LOS ENLACES

CAJERO AUTOMATICO PROPIETARIO DIRECCION

OPERACIN

CLIENTE NOMBRE CLAVE

OPERACIN C.A TIPO_OPERAC FECHA HORA

CLASE ASOCIACIN

COMPANA NOMBRE DIRECCIN

TRABAJA_PARA

PERSONA NOMBRE NUMERO SS

TRABAJO SALARIO DEPARTAMENTO GERENTE

CLASE ASOCIACIN

ASOCIACIN CUALIFICADA: ESTAS SE UTILIZAN CON ASOCIACIONES UNO-A-MUCHOS, O MUCHOSA-MUCHOS. EL CUALIFICADOR DISTINGUE ENTRE EL CONJUNTO DE OBJETOS EN EL EXTREO MUCHOS DE UNA ASOCIACIN. EL CUALIFICADOR ESPECIFCA CMO UN OBJETO ESPECFICO SE IDENTIFICA EN EL EXTREMO MUCHO DE LA ASOCIACIN Y SE PUEDE VER COMO UN TIPO DE CLAVE PARA SEPARAR TODOS LOS OBJETOS DE LA ASOCIACIN.

CONSORCIO BANCO

Cdigo Banco

BANCO

UN CONSORCIO DE BANCOS QUE SE COMPONE DE MUCHOS BANCOS, SE PUEDE CUALIFICAR CON EL CUALIFICADOR CDIGO BANCO, QUE DEFINE SIN DUDA ALGUNA AL BANCO CORRESPONDIENTE.

COMPOSICIN
UNA AGREGACIN DE COMPOSICIN ES AQUELLA QUE POSEE (<<CONTIENE>>) A SUS PARTES Y ENTRAA UNA FUERTE DEPENDENCIA DE PROPIEDAD. LAS PARTES VIVEN EN EL TODO, Y SE DESTRUYEN CUANDO SE DESTRUYE EL TODO. LA MULTIPLICIDAD EN EL LADO TODO DEBE SER CERO O UNO (0..1), EN EL LADO PARTE PUEDE SER CUALQUIER INTERVALO.

AVIN 4 MOTOR

*
ASIENTOS

1..3 BAOS

2..6 BODEGA

AGREGADO AVIN

VENTANA

CONTIENE

*
MEN

*
BOTN

*
CUADRO DE DIALOGO

*
TEXTO

AGREGADO VENTANA CON UNA RELACIN CONTIENE

ESTEREOTIPOS
SE UTILIZA PARA ESPECIALIZAR LA SEMNTICA DE ELEMENTOS YA DEFINIDOS EN UML. UN ESTEREOTIPO PUEDE SER ESPECIFICADO EN UNA CLASE DELANTE DEL NOMBRE DE LA CLASE. SE INDICA CON UNOS CORCHETES DE NGULOS (<< >>), DONDE SE ENCIERRA DICHO ESTEREOTIPO Y SE SITA ENCIMA O DELANTE DEL NOMBRE DEL ELEMENTO.
<<ACTOR>> CLIENTE

<<IGU>> VENTANA PRINCIPAL

<<EXCEPCIN>> VENTANA

<<NICO>> GERENTECOLAPRIORIDAD

EL ESTEREOTIPO IGU, SIGNIFICA QUE TIENE UNA VENTANA GRFICA COMO PRESENTACIN VISUAL.
EL ESTEROTIPO ACTOR, SE PUEDE APLICAR A OTRAS CLASES, YA QUE ACTOR PUEDE TENER ATRIBUTOS, OPERACIONES Y RELACIONES DE OTRAS CLASES. EL ESTEREOTIPO EXCEPCIN SIGNIFICA QUE LA CLASE SE UTILIZAR EN GESTIN DE EXCEPCIONES. EL ESTEREOTIPO UNICO, DE LA CLASE GERENTECOLAPRIORIDAD INDICA QUE ES UNA CLASE NICA (SLO SE CREA UN OBJETO DE ESA CLASE).

A TODO ESTO SE LES LLAMA ESTEREOTIPO DE CLASE

CLASES ABSTRACTAS
UNA CLASE ABSTRACTA ES UNA CLASE QUE NO TIENE NINGN OBJETO, ES DECIR, DE LA CUAL NO SE PUEDEN CREAR INSTANCIAS (OBJETOS). SLO SE UTILIZA PARA HEREDAR DE ELLAS ATRIBUTOS Y COMPORTAMIENTOS COMUNES. UNA CLASE SE PUEDE ESPECFICAR EXPLCITAMENTE COMO ABSTRACTA PONIENDO LA ETIQUETA BASTRACT DENTRO DE LA BANDA DE NOMBRE DE LA CLASE Y DEBAJO DEL MISMO. UNA CLASE ABSTRACTA SE REPRESENTA CON EL NOMBRE EN CURSIVA. CUALQUIER OPERACIN SE INDICA TAMBIN EN CURSIVA Y A SU DERECHA SE INDICA TAMBIN LA EXPRESIN ABSTRACT

VEHCULO abstract

CONDUCIR( ) abstract

PiezaAjedrez Color Identidad Posicin( ) MoverA( )

VEHCULO (abstract)

CARRO

AVIN

DEPORT.

AUTOBUS

CAMIN

MILITAR

TRANSPORTE

PASAJEROS

LA CLASE VEHICULO ES UN EJEMPLO DE CLASE ABSTRACTA QUE NO TIENE NINGN OBJETO, PERO SE UTILIZA SLO PARA HEREDAR DE ELLA

... Diagramas de UML

Los diagramas expresan grficamente partes de un modelo
Use Case Use Case Diagramas de Diagrams Diagrams Casos de Uso

Use Case Use Case Diagramas de Diagrams Diagrams Secuencia Scenario Scenario Diagramas de Diagrams Diagrams Colaboracin Scenario Scenario Diagramas de Diagrams Diagrams Estados

State State Diagramas de Diagrams Diagrams Clases

State State Diagramas de Diagrams Diagrams Objetos State State Diagramas de Diagrams Diagrams Componentes

Modelos

Diagramas de Actividad

Component Component Diagrams Diagramas Diagrams de

Distribucin

Diagramas
Un diagrama es una representacin grfica de un conjunto de elementos, que la mayora de las veces se dibuja como un conjunto conexo de nodos (elementos) y arcos (relaciones). Los buenos diagramas hacen comprensibles y accesibles el sistema. UML define nueve tipos de diagramas, que se pueden mezclar y conectarse para componer cada vista.

Diagramas estructurales
Se pueden ver los aspectos estticos de un sistema como aquellos que representan su esqueleto y su andamiaje, ambos relativamente estables. Diagramas de clases, diagramas de objetos, diagramas de componentes, diagramas de despliegue.

Introduccin a Interfaces (I)

Las interfaces definen una lnea entre la especificacin de lo que una abstraccin hace y la implementacin de cmo lo hace. Es una coleccin de operaciones que sirven para especificar un servicio de una clase o de un componente. Se utilizan para visualizar, especificar, construir y documentar las lneas de separacin dentro de un sistema.

Paquetes
Es un mecanismo de propsito general para organizar elementos de modelado en grupos. La visibilidad de estos elementos puede controlarse para que algunos sean visibles fuera del paquete mientras que otros permanezcan ocultos. Los paquetes bien diseados agrupan elementos cercanos semnticamente y que suelen cambiar juntos.

II. Breve Tour por UML

Paquetes en UML
Los paquetes ofrecen un mecanismo general para la organizacin de los modelos/subsistemas agrupando elementos de modelado Se representan grficamente como:
Nombre de paquete

 Paquetes en UML
Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema) Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento pertenece a (est definido en) slo un paquete Una clase de un paquete puede aparecer en otro paquete por la importacin a travs de una relacin de dependencia entre paquetes

 Paquetes en UML
Todos los elementos no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa El operador :: permite designar una clase definida en un contexto distinto del actual

UML est compuesto por los siguientes diagramas:

rea Vista Diagramas Conceptos Principales

Vista Esttica

Diagrama de Clases

Clase, asociacin, generalizacin, dependencia, realizacin, interfaz.

Vista de Casos de Uso Estructural Vista de Implementacin

Diagramas de Casos de Uso

Caso de Uso, Actor, asociacin, extensin, generalizacin.

Diagramas de Componentes

Componente, interfaz, dependencia, realizacin.

Vista de Despliegue

Diagramas de Despliegue

Nodo, componente, dependencia, localizacin.

Vista de Estados de mquina

Diagramas de Estados

Estado, evento, transicin, accin.

Vista de actividad Dinmica

Diagramas de Actividad

Estado, actividad, transicin, determinacin, divisin, unin.

Diagramas de Secuencia Vista de interaccin Diagramas de Colaboracin

Interaccin, objeto, mensaje, activacin.

Colaboracin, interaccin, rol de colaboracin, mensaje.

Administracin o Gestin de modelo

Vista de Gestin de modelo

Diagramas de Clases

Paquete, subsistema, modelo.

Extensin de UML

Todas

Todos

Restriccin, estereotipo, valores, etiquetados.

CASO DE USO
Caso de Uso:
Descripcin de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor

Actor:
Se refiere a los distintos roles que los usuarios juegan al interactuar con los casos de uso.

Contienen:
Casos de Uso, Actores y Relaciones de dependencia, generalizacin y asociacin

Usos comunes:
Para modelar el contexto del sistema Para modelar los requisitos del sistema

DIAGRAMAS DE CASOS DE USO

UN DIAGRAMA DE CASOS DE USO (USE CASE DIAGRAM) ES UNA REPRESENTACIN GRFICA DE PARTE O EL TOTAL DE LOS ACTORES Y CASOS DE USO DEL SISTEMA, INCLUYENDO SUS INTERACCIONES. TODO SISTEMA TIENE COMO MNIMO UN DIAGRAMA MAIN USE CASE, QUE ES UNA REPRESENTACIN GRFICA DEL ENTORNO DEL SISTEMA (ACTORES) Y SU FUNCIONALIDAD PRINCIPAL (CASOS DE USO). UN DIAGRAMA DE CASOS DE USO MUESTRA, POR TANTO, LOS DISTINTOS REQUISITOS FUNCIONALES QUE SE ESPERAN DE UNA APLICACIN O SISTEMA Y CMO SE RELACIONA CON SU ENTORNO (USUARIOS U OTRAS APLICACIONES). SE MUESTRA COMO EJEMPLO LOS CASOS DE USO DE UNA MQUINA DE CAF

UN CASO DE USO, DENOTANDO UN REQUISITO FUNCIONAL EXIGIDO AL SISTEMA, SE REPRESENTA EN EL DIAGRAMA POR UNA ELIPSE Y UN NOMBRE SIGNIFICATIVO, . EN EL CASO DEL EJEMPLO SE TIENEN COMO CASOS DE USO DE LA MQUINA DE CAF RECIBIRDINERO, PEDIRAZUCAR, PEDIRPRODUCTO, DARVUELTAS Y CANCELAR.

Figura: Representacin de un actor

FIGURA: EJEMPLO DE CASOS DE USO DE UNA MQUINA DE CAF

ENTRE LOS ELEMENTOS DE UN DIAGRAMA DE CASOS DE USO SE PUEDEN PRESENTAR TRES TIPOS DE RELACIONES, REPRESENTADAS POR LNEAS DIRIGIDAS O NO ENTRE ELLOS:

``COMUNICA'' (<<COMMUNICATES>>): RELACIN (ASOCIACIN) ENTRE UN ACTOR Y UN CASO DE USO QUE DENOTA LA PARTICIPACIN DEL ACTOR EN DICHO CASO DE USO.
EN EL DIAGRAMA DEL EJEMPLO DE LA FIGURA TODAS LAS LNEAS QUE SALEN DEL ACTOR DENOTAN ESTE TIPO DE ASOCIACIN (EN REALIDAD ESTEREOTIPADA COMO <<COMUNICATES>>).

``USA'' ( <<USES>>) (O <<INCLUDE>> EN LA NUEVA VERSIN DE UML): RELACIN DE DEPENDENCIA ENTRE DOS CASOS DE USO QUE DENOTA LA INCLUSIN DEL COMPORTAMIENTO DE UN ESCENARIO EN OTRO.

EN EL CASO DEL EJEMPLO EL CASO DE USO CANCELAR INCLUYE EN SU COMPORTAMIENTO AL DE DARVUELTAS Y PEDIRPRODUCTO INCLUYE TAMBIN DARVUELTAS.

``EXTIENDE'' (<< EXTENDS>>): RELACIN DE DEPENDENCIA ENTRE DOS CASOS DE USO QUE DENOTA QUE UN CASO DE USO ES UNA ESPECIALIZACIN DE OTRO. POR EJEMPLO, PODRA TENERSE UN CASO DE USO QUE EXTIENDA LA FORMA DE PEDIR AZCAR, PARA QUE PERMITA ESCOGER EL TIPO DE AZCAR (NORMAL, DIETTICO O MORENO) Y ADEMS LA CANTIDAD EN LAS UNIDADES ADECUADAS (CUCHARADAS O BOLSAS).

FIGURA: CASOS DE USO CON RELACIN `` EXTENDS''

SE UTILIZA UNA RELACIN DE TIPO <<EXTENDS>> ENTRE CASOS DE USO CUANDO NOS ENCONTRAMOS CON UN CASO DE USO SIMILAR A OTRO PERO QUE HACE ALGO MS QUE STE (VARIANTE).

POR CONTRA, UTILIZAREMOS UNA RELACIN TIPO << USES>> CUANDO NOS ENCONTRAMOS CON UNA PARTE DE COMPORTAMIENTO SIMILAR EN DOS CASOS DE USO Y NO QUEREMOS REPETIR LA DESCRIPCIN DE DICHO COMPORTAMIENTO COMN.

EN UNA RELACIN << EXTENDS>>, UN ACTOR QUE LLEVE A CABO EL CASO DE USO BASE PUEDE REALIZAR O NO SUS EXTENSIONES. MIENTRAS, EN UNA RELACIN <<INCLUDE>> EL ACTOR QUE REALIZA EL CASO DE USO BASE TAMBIN REALIZA EL CASO DE USO INCLUIDO.

EN GENERAL UTILIZAREMOS <<EXTENDS>> CUANDO SE PRESENTA UNA VARIACIN DEL COMPORTAMIENTO NORMAL, Y <<INCLUDE>> CUANDO SE REPITE UN COMPORTAMIENTO EN DOS CASOS DE USO Y QUEREMOS EVITAR DICHA REPETICIN.

POR LTIMO EN UN DIAGRAMA DE CASOS DE USO, ADEMS DE LAS RELACIONES ENTRE CASOS DE USO Y ACTOR (ASOCIACIONES) Y LAS DEPENDENCIAS ENTRE CASOS DE USO (<<INCLUDE>> Y <<EXTENDS>>), PUEDEN EXISTIR RELACIONES DE HERENCIA YA SEA ENTRE CASOS DE USO O ENTRE ACTORES.

Caso de Uso - Ejemplo

CASO DE USO MODELADO DE UN CONTEXTO

CASO DE USO MODELADO DE REQUERIMIENTOS

CASOS DE USO

SISTEMA
uses Actor1 UseCase1
extends

UseCase3

uses

UseCase2
Actor2

UseCase4 Actor3

Casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cmo se implementa ese comportamiento. Proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensin comn del sistema.

CASOS DE USO
La primera actividad en los caso de uso es la identificacin de los actores. Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso cuando interactan con stos.

Persona Sistemas Mquinas

Actor

Interactan con el sistema que estamos construyendo

Externo al sistema

Identificando a los actores estamos comenzando a delimitar al sistema y a definir su alcance. Un proyecto sin alcance jams podr cumplir sus objetivos

CASOS DE USO

El nombre de un caso de uso se expresa con un verbo en gerundio seguido por un objeto o entidad del sistema

ingresando pedido

empleado de venta

CASOS DE USO

Caractersticas de los casos de uso Estn expresados desde el punto de vista del actor y son iniciados por un nico actor.

Caso de uso
El actor desencadena el caso de uso

Actor

CASOS DE USO

Describe tanto lo que hace el actor como lo que hace el sistema cuando interacta con el, aunque el nfasis esta puesto en la interaccin. Estn acotados al uso de una determinada funcionalidad, claramente diferenciada, del sistema. una funcin es un caso de uso si se debe indicar explcitamente al sistema que uno quiere acceder a esa funcin

CASOS DE USO
Curso normal Se documentan el texto informal. Se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema. Es difcil especificar el comportamiento interno, las iteraciones y decisiones. Alternativas Expresan errores o excepciones durante la ejecucin de un caso de uso Representan un error o excepcin en el curso normal del caso de uso. No tienen sentido por s mismas, fuera del contexto del caso de uso en el que ocurren.

CASOS DE USO
Relaciones de Extensin La funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren slo en algunas oportunidades. La excepcin consiste en interrumpir el caso de uso B y pasar a ejecutar otro caso de uso A. El caso de uso A extiende el caso de uso B

UseCase A

extends

UseCase B

CASOS DE USO
Se representa por una lnea desde el caso que extiende a al caso que es extendido. Representan un parte de la funcionalidad del caso que no ocurre siempre. Son un caso de uso en s mismas. No necesariamente provienen de un error o excepcin

extends
ingresando pedido

Revisando nuevos productos

Empleado de venta

CASOS DE USO
Relaciones de Uso Es comn que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso Los casos usados son casos de uso en s mismos.

UseCase A

uses

UseCase B

El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones, que son opcionales

CASOS DE USO
Este tipo de relaciones se llama relaciones de uso y se representa por una lnea desde el caso que usa a al caso que es usado.
obteniendo reporte de ventas uses ingresando pedido Empleado de ventas uses buscando datos de pedido Gerente

CASOS DE USO
Cmo encontrar un actor?
Identifique los usuarios del sistema Porqu se disea el sistema? Cules son los actores que el sistema va a beneficiar? Qu actores van a interactuar directamente con el sistema? (actores primarios) Qu actores van a supervisar, mantener, recibir informacin del sistema? (actores secundarios) Identifique los roles que juegan esos usuarios desde el punto de vista del sistema. Identifique otros sistemas con los cuales exista comunicacin.

CASOS DE USO
Cmo encontrar un caso de uso? Identifique las operaciones importantes del sistema a construir. Cules son las principales tareas de un actor? Qu informacin tiene el actor que consultar? ... .... actualizar?, modificar?, cmo? Qu cambios del exterior debe informar el actor al sistema? Qu informacin debe informrsele al actor, con respecto a los cambios del sistema?

Presentacin del sistema Tutorial a travs de UML

DIAGRAMA DE CASO DE USO

Nio

Sistema Tutorial
Aplica Evaluacin

Selecciona Elemento Gramatical

<<uses>> despliega <<uses> > evala Revisa Evaluacin Desarrolla Ejemplos Muestra Definicin <<uses>> despliega

Profesor

Diagrama de Clases Describe 1

1 Gestor Guin PresentarDefinicin PresentarEjemplo PresentarEjercicio PresentarEvaluacin 1 Muestra

Presenta

Despliega

1..*

1..* Ejercicio del Elemento Gramatical Tipo

1..*

1..* Evaluacin Final

Elemento Gramatical

Ejemplo

Definicin Tipo DesplegarElemento

Oracin Resultado DesplegarEjercicio

Oracin

Oracin Tipo

MostrarEjempl o

DesplegarEvaluaci n Evaluar

78

Diagrama de secuencia

Usuario

Seleccin del Elemento Gramatical

Ejemplo del Elemento Gramatical

Ejercicio del Elemento Gramatical

Evaluacin del Elemento Gramatical

Selecciona elemento

Describe funcin Solicita ejemplo Presenta ejemplo Solicita ejemplo Muestra ejemplo

Solicita ejemplo

Realiza evaluacin

Diagrama de Transicin de Estado

Iniciar Sesin Inicia

Identifica Elemento Gramatical

Terminar Sesin Termina

Elige

Verifica

Selecciona Elemento Gramatical

Nueva Seleccin

Describe Muestra Definicin

Nueva Definicin

Termina

Estructura Nuevo Elemento Muestra Ejemplos

Prepara

Realiza Evaluacin
Repetir