UML&TeoriaObjetos2

246
Lenguaje de Lenguaje de Modelamiento Unificado Modelamiento Unificado Ing. Luis Zuloaga Rotta

description

Lenguaje de Modelamiento Unificado 2

Transcript of UML&TeoriaObjetos2

Page 1: UML&TeoriaObjetos2

Lenguaje de Modelamiento Lenguaje de Modelamiento UnificadoUnificado

Ing. Luis Zuloaga Rotta

Page 2: UML&TeoriaObjetos2
Page 3: UML&TeoriaObjetos2

… … los Requerimientos ?los Requerimientos ?

• Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational Software Corp.].

• Un requerimiento de software puede ser definido como :– Una capacidad del software necesaria por el usuario

para resolver un problema o alcanzar un objetivo.

– Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para satisfacer un contrato, especificación, estándar, u otra documentación formal.

Page 4: UML&TeoriaObjetos2

Los Problemas de la Administración Los Problemas de la Administración de Requerimientosde Requerimientos

• No son siempre obvios y tienen muchas fuentes.• No son siempre fáciles de expresar en palabras.• Hay muchos tipos diferentes a distintos niveles de

detalle.• El número puede llegar a ser inmanejable.• Están relacionados a otros en una variedad de formas.• Hay muchos interesados y partes responsables.• Cambian.• Pueden ser sensibles al tiempo.

Page 5: UML&TeoriaObjetos2

UML

• Un lenguaje estándar mundial para modelar el software a construir similar al que se utiliza para elaborar los planos de construcción de una vivienda.

• Unifica muchos estándares de diagramación conformando un metalenguaje.

• Facilita el modelado de todo tipo de sistema.

Page 6: UML&TeoriaObjetos2
Page 7: UML&TeoriaObjetos2
Page 8: UML&TeoriaObjetos2

Los Tres Amigos

En 1994 Booch, Rumbaugh y Jacobson dieron forma a la primera versión del UML y en 1997 fue aceptado por la OMG, fecha en la que fue lanzada la versión v1.1 del UML. Desde entonces, UML atravesó varias revisiones y refinamientos hasta llegar a la versión actual: UML 2.0.

Ivar Jacobson

James Rumbaugh

Grady Booch

Page 9: UML&TeoriaObjetos2

13 Tipos de Diagramas - UML• Diagramas de Estructura:

– Diagrama de Clases, – Diagrama de Objetos, – Diagrama de Componentes, – Diagrama de Estructura Compuesta, – Diagrama de Paquetes, y – Diagrama de Despliegue.

• Diagramas de Comportamiento: – Diagrama de Casos de Uso, – Diagrama de Actividad, – Diagrama de Transición de Estados, y– Diagramas de Interacción:

• Diagrama de Secuencia, • Diagrama de Comunicación, • Diagrama de Temporización, y • Diagrama General de Interacción.

Page 10: UML&TeoriaObjetos2
Page 11: UML&TeoriaObjetos2

Diagrama Descripción Prioridad

Diagrama de ClasesMuestra una colección de elementos de modelado declarativo (estáticos), tales como clases, tipos y sus contenidos y relaciones.

Alta

Diagrama de Componentes

Representa los componentes que componen una aplicación, sistema o empresa. Los componentes, sus relaciones, interacciones y sus interfaces públicas.

Media

Diagrama de Estructura Compuesta

Representa la estructura interna de un clasificador (tal como una clase, un componente o un caso de uso), incluyendo los puntos de interacción de clasificador con otras partes del sistema.

Baja

Diagrama de Despliegue Físico

Un diagrama de despliegue físico muestra cómo y dónde se desplegará el sistema. Las máquinas físicas y los procesadores se representan como nodos y la construcción interna puede ser representada por nodos o artefactos embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicación es guiada por el uso de las especificaciones de despliegue.

Media

Diagrama de Objetos

Un diagrama que presenta los objetos y sus relaciones en un punto del tiempo. Un diagrama de objetos se puede considerar como un caso especial de un diagrama de clases o un diagrama de comunicaciones.

Baja

Diagrama de Paquetes

Un diagrama que presenta cómo se organizan los elementos de modelado en paquetes y las dependencias entre ellos, incluyendo importaciones y extensiones de paquetes.

Baja

Page 12: UML&TeoriaObjetos2

Diagrama Descripción Prioridad

Diagrama de Casos de Uso

Un diagrama que muestra las relaciones entre los actores y el sujeto (sistema), y los casos de uso.

Media

Diagrama de Actividades

Representa los procesos de negocios de alto nivel, incluidos el flujo de datos. También puede utilizarse para modelar lógica compleja y/o paralela dentro de un sistema.

Alta

Diagrama de Máquinas de Estado

Un diagrama de Máquina de Estados ilustra cómo un elemento, muchas veces una clase, se puede mover entre estados que clasifican su comportamiento, de acuerdo con disparadores de transiciones, guardias de restricciones y otros aspectos de los diagramas de Máquinas de Estados, que representan y explican el movimiento y el comportamiento.

Media

Page 13: UML&TeoriaObjetos2

Diagrama Descripción Prioridad

Diagrama de Comunicaciones (anteriormente: Diagrama de colaboraciones)

Es un diagrama que enfoca la interacción entre líneas de vida, donde es central la arquitectura de la estructura interna y cómo ella se corresponde con el pasaje de mensajes. La secuencia de los mensajes se da a través de un esquema de numerado de la secuencia.

Baja

Diagrama General de Interacción

Este Diagrama se enfoca en la revisión del flujo de control, donde los nodos son Interacciones u ocurrencias de Interacciones. Las Líneas de Vida los Mensajes no aparecen en este nivel de revisión

Baja

Diagrama de Secuencias

Un diagrama que representa una interacción, poniendo el foco en la secuencia de los mensajes que se intercambian, junto con sus correspondientes ocurrencias de eventos en las Líneas de Vida.

Alta

Diagrama de Temporización

El propósito primario del diagrama de tiempos es mostrar los cambios en el estado o la condición de una línea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cuándo se desea mostrar el evento que causa el cambio en la condición o en el estado.

Baja

Page 14: UML&TeoriaObjetos2

RUP

• Proceso Unificado Rational, un marco de trabajo para desarrollar software de calidad.

• Principios:• Modelado con UML• Basado en Casos de Uso• Centrado en la Arquitectura• Iterativo e Incrementable.

Page 15: UML&TeoriaObjetos2

Fases del RUP

Page 16: UML&TeoriaObjetos2

Bibliografía

Page 17: UML&TeoriaObjetos2

Teoría de Objetos

Page 18: UML&TeoriaObjetos2

Analista con enfoquecentrado en los datos

Analista con enfoquecentrado en los objetos

¿ Cuál es su:-marca-kilometraje-nro placa-color-modelo

¿ Cuál es su:-marca-kilometraje-nro placa-color-modelo

¿ Qué hace:•enciende motor•acelera•frena•apaga motor•carga combustible•enciende luces•Actualiza kilometraje

Objeto

En que procesos se

utilizan ?

Page 19: UML&TeoriaObjetos2

Definición de Objeto

• Todo aquello a lo que podemos reconocerle una identidad, un estado y un comportamiento.

• Es una colección de elementos de datos junto con las funciones o métodos asociados para operar sobre ellos y para comunicarse con otros objetos.

Page 20: UML&TeoriaObjetos2

Identidad

• Es la propiedad que diferencia un objeto de otro similar. En esencia la identidad de un objeto caracteriza su propia existencia.

• La identidad hace posible distinguir cualquier objeto sin ambigüedad e independientemente de su estado.

• Esto permite, entre otras cosas, la diferenciación de dos objetos que tengan atributos idénticos.

Page 21: UML&TeoriaObjetos2
Page 22: UML&TeoriaObjetos2

• Cada objeto tiene una identidad única, incluso si tiene las mismas características que otros y se encuentra en el mismo estado.

Identidad

Page 23: UML&TeoriaObjetos2

Estado de un objeto

• Cada uno los objetos de una clase tendrá generalmente un estado particular propio.

• El estado esta relacionado con los valores de algunos de los atributos característicos de un objeto. – Para una botella, su contenido, que establece que

una botella pueda estar llena, medio llena o vacía

• Con algunas operaciones comunes que comparte con otros objetos:– como <<llenar>>, <<vaciar>>, <<destapar>>), y

• Tiene además otros atributos no relacionados con el estado.

• como el color y modelo de una botella

Page 24: UML&TeoriaObjetos2

Estado de un Objeto

Parado Caminando Sentado

• Un objeto se encuentra en un determinado momento en un estado específico como consecuencia de algún evento.

Párate ! Camina ! Siéntate !

Page 25: UML&TeoriaObjetos2

Comportamiento• Los datos describen la abstracción de las características

individuales que poseen todos los objetos.• Las operaciones cambian el objeto (su comportamiento)

de alguna forma, es decir, cambian valores de uno o más atributos contenidos en el objeto. Aunque existen gran número de operaciones que se pueden realizar sobre un objeto, generalmente se dividen en tres grandes grupos:– Operaciones que manipulan los datos de alguna forma

específica (añadir, borrar, cambiar formato, …)– Operaciones que realizan un cálculo o proceso– Operaciones que comprueban un objeto frente a la ocurrencia

de algún evento de control.

Page 26: UML&TeoriaObjetos2

ObjetosObjeto Identidad Estados Comportamiento

Venta Nro 2345601 EmitidaPagadaAnulada

CrearModificarAñadir productoPagarAnularTotalizar

Alumno Cod 1998234 No matriculadoMatriculadoRetiradoEgresado

MatricularRetirarEgresarSancionar

Cita medica Nro 234516 EmitidaPagadaAtendidaSuspendida

CrearPagarAtenderSuspender

Contribuyente RUC 201345678965 HabidoNo habido

CrearSancionarDar bajaClasificar

Page 27: UML&TeoriaObjetos2

Tipos de Objetos

Concretos: Persona – Carro – PC - Libro

Roles: Doctor – Propietario – Maestro - Hijo

Relacional: Sociedad - Club - Matrimonio

Eventos: Venta – Compra - Arribo

Exponibles: Icono – Window – Imagen - Menú

Page 28: UML&TeoriaObjetos2

Estructura interna de un Objeto

• Atributos (datos o valores)• Operaciones (métodos o servicios)

– Los atributos describen el estado del objeto. Un atributo consta de dos partes: un nombre de atributo y un valor de atributo.

– Los métodos describen el comportamiento asociado a un objeto. Representan las acciones que pueden realizarse por o sobre un objeto.

Page 29: UML&TeoriaObjetos2

Características de los Objetos

• Se agrupan en tipos llamados clases.• Tienen datos internos que definen su estado

actual.• Soportan la ocultación de datos.• Pueden heredar propiedades de otros objetos.• Pueden comunicarse con otros objetos

pasando mensajes.• Tienen métodos que definen su

comportamiento.

Page 30: UML&TeoriaObjetos2

• Los Objetos en un Sistema trabajan en conjunto, esto se logra por intermedio de mensajes entre ellos.

• Un Objeto envía a otro un mensaje para realizar una operación y el Objeto receptor recibe dicho mensaje para su ejecución.

Ejemplo: El Televisor y su Control Remoto.

Mensajes

Page 31: UML&TeoriaObjetos2

Métodos y mensajes

• Los procedimientos y funciones, denominados métodos, residen en el objeto y determinan cómo actúan los objetos cuando reciben un mensaje.

• Un mensaje es la acción que hace un objeto. Un método es el procedimiento o función que se invoca para actuar sobre un objeto y especifica cómo se ejecuta un mensaje.

• Los mensajes que recibe o envía un objeto son los únicos conductos que asociacian el objeto con el mundo externo.

• Los datos de un objeto están disponibles sólo para ser manipulados por los métodos del propio objeto.

Page 32: UML&TeoriaObjetos2

Clase y Objeto

• Un objeto es un simple elemento, no importa lo complejo que pueda ser.

• Una clase describe una familia de elementos similares, es un esquema o plantilla que se utiliza para definir o crear objetos.

Page 33: UML&TeoriaObjetos2

Representación gráfica de una Clase (Notación de Ege)

• Un objeto se dibuja como una caja rectangular. La caja se etiqueta con el nombre del objeto y representa el límite o frontera entre el interior y el exterior de un objeto.

• Los campos y funciones miembro en el interior de la caja están ocultos al exterior (encapsulados).

• El acceso a las características de los miembros (datos y funciones) es posible a través del interfaz del objeto

NOMBRE CLASE

ATRIBUTOS(DATOS MIEMBRO)

OPERACIONES(FUNCIONES MIEMBRO)

Page 34: UML&TeoriaObjetos2

Clases• Una clase es la

descripción de un conjunto de objetos; consta de datos y métodos que resumen características comunes de un conjunto de objetos.

• Cada vez que se construye un objeto a partir de una clase estamos creando lo que se llama una instancia de esa clase.

Ejec105 : MaletaViaj325: Maleta

Est1235: Maleta

MaletaMaletaDenominacionDenominacionColorColorPrecioPrecioCapacidadCapacidad

Abrir ( ) Cerrar ( )

Calcular peso ( )

Cobr2154 : Maleta

ATRIBUTOS

OPERACIONES

Page 35: UML&TeoriaObjetos2

Operaciones• Son funciones o

transformaciones que se aplican a todos los objetos de una clase particular.

• La operación puede ser una acción ejecutada por el objeto o sobre el objeto.

• No se debe utilizar el mismo nombre en operaciones que tengan un significado totalmente diferente.

nombre edad

PERSONA

trabajar ( ) votar( )

nombre direccion

UNIVERSIDAD

enseñar ( ) graduar( )

ancho largo /area

RECTANGULO

dibujar ( ) borrar( ) calcular_area( )

Page 36: UML&TeoriaObjetos2

Propiedades de un objeto

• Abstracción y clasificación

• Encapsulamiento

• Herencia

• Agregación y composición

• Poliformismo o polimorfismo

Page 37: UML&TeoriaObjetos2

Abstracción

• Es una de las vías fundamentales por la que los humanos combatimos la complejidad.

• La abstracción surge del reconocimiento de las similitudes entre ciertos objetos, situaciones o procesos del mundo real, y en la decisión de concentrarse en esas similitudes e ignorar por el momento las diferencias.

Page 38: UML&TeoriaObjetos2

La abstracción centra su atención en las característicasLa abstracción centra su atención en las característicasesenciales de un objeto en relación a la perspectiva delesenciales de un objeto en relación a la perspectiva del

observadorobservador

Page 39: UML&TeoriaObjetos2

Encapsulamiento• La encapsulación es una

característica que permite el ocultamiento de la información como un concepto avanzado de la teoría de objetos.

• Es la propiedad que permite incluir en una sola clase los datos y las operaciones que operan sobre esa información.

• La encapsulación de información y operaciones es muy importante. Los métodos de un objeto sólo pueden manipular directamente datos asociados con el objeto.

Datosprivados

Funciones privadas

Funcionespúblicas

Datospúblicos

Objeto

Page 40: UML&TeoriaObjetos2

El encapsulamiento oculta los detalles de laEl encapsulamiento oculta los detalles de laimplementación de un Objetoimplementación de un Objeto

Page 41: UML&TeoriaObjetos2

• Es el ocultamiento de la Funcionalidad interna

de las características y algunas operaciones, a

otros objetos y al mundo exterior.

Encapsulamiento

Page 42: UML&TeoriaObjetos2

– ( - ) Privado: es el más fuerte. Esta parte es visible sólo para los “friends” en terminología C++.

– ( # ) Protegido: están visibles sólo para los friends y para las clases derivadas de la original.

– ( + ) Público: son visibles a todas las clases (se pierde la encapsulación).

Encapsulamiento

Reglas de visibilidad

+ Atributo público : int# Atributo protegido : int- Atributo privado : int

+ "Operación pública"# "Operación protegida"- "Operación privada"

Page 43: UML&TeoriaObjetos2

Herencia• La herencia es la propiedad que

permite a los objetos ser construidos a partir de las características de otros objetos.

• El objetivo de la herencia es la reutilización del código previamente desarrollado, siendo esta la real potencia de la POO.

• La herencia supone una clase base y una jerarquía de clases que contienen las clases derivadas de la clase base.

Page 44: UML&TeoriaObjetos2

CRIATURA

PEZ

MAMIFERO

AVE

PERSONA

HOMBRE MUJER

Jerarquía y Herencia

tipopesohabitat

periodo_gestacion

nombrefecha_nacimientoorigen

esposa esposo

crear( )esperanza_vida( )

Page 45: UML&TeoriaObjetos2

Tipos de Herencia

• Herencia simple (jerárquica)– La simple es aquel tipo de herencia en la cual un

objeto puede tener sólo un ascendiente, o dicho de otro modo, una subclase puede heredar datos y métodos de una única clase así como añadir o quitar comportamiento de la clase base.

• Herencia múltiple (en malla)– La múltiple es aquel tipo de herencia en la cual una

clase puede tener más de un ascendiente inmediato, o lo que es igual, adquirir datos y métodos de más de una clase.

Page 46: UML&TeoriaObjetos2

FIGURA

CIRCULO CUADRILATERO TRIANGULO

RECTANGULOTRAPECIO

PERSONA

PROFESOR INVESTIGADOR

PROF_UNIVERSITARIO

Herencia Simple Herencia Múltiple

Page 47: UML&TeoriaObjetos2

Agregación y composición• A los objetos que pueden contener otros

objetos se conocen como objetos compuestos.

• En la mayoría de los sistemas los objetos no “contienen” en el sentido estricto a otros objetos, sino que contienen referencias a otros objetos.

• Un objeto compuesto consta de una colección de dos o más objetos componentes, los cuales tienen una relación del tipo “parte-de” con el objeto compuesto.

• Cuando un objeto compuesto se instancia para producir una instancia del objeto, todos sus objetos componentes se deben instanciar al mismo tiempo.

Page 48: UML&TeoriaObjetos2

nro_cilindrospotenciacilindradavalvulas_cilindro

MOTOR

tipoproveedornivel_liquido

SISTEMA FRENOS

tipo_embraguecaja_cambio

SISTEMATRANSMISION

tipocolor

CHASIS

codAutonroPlacamarcacolorañokilometraje

AUTO

tipoproveedorsiLucesnivelSonido

SISTEMA ALARMA

Todo

Parte

Parte

Parte

Page 49: UML&TeoriaObjetos2

Un ejemplo de un objeto compuesto es la clase auto. Un auto consta de diversas partes tales como un motor, un sistema de frenos, un sistema de transmisión, un sistema de alarma y un chasis. Estas partes constituyen los objetos componentes del objeto auto de modo que cada uno de estos objetos componentes pueden tener atributos y métodos que los caracterizan.

Atributos nro_autos_disponibles nro_autos_vendidosAtributos compartidos concesionarioAtributos de instancia modelo color precio añoObjetos componentes motor sistema_frenos sistema_transmision chasis

AUTO

nro_cilindrospotenciacilindradavalvulas_cilindro

MOTOR

tipoproveedornivel_liquido

SISTEMA FRENOS

tipo_embraguecaja_cambio

SISTEMATRANSMISION

tipocolor

CHASIS

Page 50: UML&TeoriaObjetos2

Estructura de objetos

compuestos

var 1: obj1var 2: obj2

obj1 obj2

Objetocompuesto

var 1: clientevar 2: articulo

clientearticulo

Ordencompra

var 1: clientevar 2: articulo

articulo

Ordencompra

Page 51: UML&TeoriaObjetos2

Agregación

Page 52: UML&TeoriaObjetos2

Polimorfismo

• Propiedad por la cual un mismo objeto u objetos de una misma clase u objetos de clases diferentes, responden de distinta manera a un mismo mensaje.

• • La utilización de operadores o funciones de formas

diversas, dependiendo de cómo estén operando se denomina polimorfismo.

• La sobrecarga es una clase de polimorfismo.

• La gran ventaja ofrecida por el polimorfismo y la sobrecarga es permitir que los nuevos tipos de datos sean manipulados de forma similar que los tipos de datos predefinidos, logrando así ampliar el lenguaje de programación.

Page 53: UML&TeoriaObjetos2

Polimorfismo• Es la propiedad que tienen los objetos de permitir

invocar genéricamente un comportamiento (método) cuya implementación será delegada al objeto correspondiente recién en tiempo de ejecución.

Transporte

Avanzar

Frenar Transporte

Avanzar

Frenar

Transporte

Avanzar

Frenar

Transporte

Avanzar

Frenar

Page 54: UML&TeoriaObjetos2

Diagrama de Casos de Uso

Page 55: UML&TeoriaObjetos2

• Secuencia de interacciones entre un actor cumpliendo un rol y el sistema con la finalidad de que el actor pueda satisfacer un requerimiento.

Caso Uso 3

Caso Uso 1

Caso Uso 2

Caso Uso 4

Caso Uso 5

Actor (rol1) Actor

(rol2)

Actor(rol3)

Sistema

Caso de Uso

Page 56: UML&TeoriaObjetos2

Actor

• Persona, unidad organizacional, mecanismo, u otro sistema que deseando satisfacer un requerimiento inicia la interacción con el sistema.

• Actor primario es quien inicia la interacción y actor secundario es de quien se vale el sistema para satisfacer el requerimiento del actor primario.

Page 57: UML&TeoriaObjetos2

• Los casos de uso se identifican hablando con los usuarios habituales y analizando con ellos las distintas cosas que desean hacer con el sistema (requerimientos).

• Se debe abordar cada uso concreto que quieran realizar, darle un nombre y escribir un texto descriptivo breve (forma corta).

• La mayoría de los casos de uso se pueden detallar durante las iteraciones con los usuarios, a medida que se construyen (forma extendida).

Caso de Uso

Page 58: UML&TeoriaObjetos2

Asociaciones entre Casos de Uso

• Inclusión– Cuando un caso de uso esta incluido dentro

de otro y al ser “factorizado” puede ser reutilizado por otros casos de uso; también se utiliza para mejorar la comprensión del caso de uso.

• Extensión– Cuando un caso de uso opcionalmente puede

extenderse hacia otro caso de uso.

Page 59: UML&TeoriaObjetos2

Realizar cobro de factura

Realizar venta Realizar cobro

con Tarjeta CréditoVendedor

(actor primario)

Banco(actor secundario)

Sistema

incluye

extiende

Page 60: UML&TeoriaObjetos2

Tipificación de casos de uso

• El ordenamiento de los casos de uso que expresan la forma de satisfacer los requerimientos de un actor se tipifican como:

– Definir - Consultar– Seleccionar - Realizar– Ingresar o Entrar - Actualizar– Imprimir - Calcular– Vincular - Autorizar– Validar - Procesar

Page 61: UML&TeoriaObjetos2

• Una Entidad representa un Objeto de negocio que forma parte de una Organización.

• Actor fija, determina, y decide cuales son los atributos distintivos de una Entidad; señala sus límites y sus responsabilidades, discrimina lo que es esencial de lo que es circunstancial.

• Ej. Definir Agente, Cliente, Contribuyente, Organización, Sub Sistema, Lugar, Punto de Actuación, Dispositivo, Parámetros de Aplicación, Item, Artículo, Catálogo de …, Acta de Examen, Cuenta, Cartera de, Plantilla de Documento, Mensaje entre Entidades, …

Definir Entidad

Definir Cta Ahorro

Page 62: UML&TeoriaObjetos2

Realizar Actuación• Una Actuación representa algo que ha sucedido, está

sucediendo, o puede suceder en el futuro, gracias a la combinación de varias Entidades.

• Actor pone en acción diversas Entidades dentro de un flujo de trabajo que está bajo su control.

• Ej. Realizar Transacción, Mensaje, Venta, Arqueo de Caja, Apertura, Cierre, Transferencia, Declaración Anual, pedido, Inventario, Regularización de Stock, Solicitud, Devolución de Item, Pago, Remesa, Abono, Orden de Transferencia, Activación, Notificación, Configuración, Modificación, Observación, Matricula, Subasta, Evaluación, …

Realizar Abono en

Cta

Page 63: UML&TeoriaObjetos2

Ingresar o Entrar Item• Representa el ingreso del detalle de la estructura de una

Entidad o una Actuación.

• Actor ingresa o entra partes correspondientes a una Entidad o, a una Actuación.

• Ej. Entrar Rol de un Agente, Línea de Transacción, Item en una Cartera, Línea de venta, Calificaciones en un Acta de Notas, Lote de, Factura de Agente, Variable, Previsiones, Propiedades, Estados, Composición de un Item, Regla de Negocio, Representante, Incidencia de un Proceso, …

Realizar Abono en

Cta

Ingresar monto a abonar

<<Incluye>>

Page 64: UML&TeoriaObjetos2

Procesar Item

• Representa un cambio de estado en una Entidad o una Actuación, a partir de una transformación.

• Por orden de un Actor, el sistema realiza una serie de transformaciones en una o varias Entidades y/o Actuaciones, dentro de unas coordenadas espacio-tiempo y con una cadencia determinada.

• Ej. Procesar Cuentas, mailings, pedidos, Facturas, Movimientos de Almacén, Notas de Entrega (Albarán), Incidencias, items en una cartera, Contenido de un Documento, …

Procesar Ctas Ahorro

Ingresar periodo

<<Incluye>>

Page 65: UML&TeoriaObjetos2

Actualizar Item

• Representa un cambio de estado en una Entidad o una Actuación, a partir de un movimiento entre Emisor y Receptor.

• Por orden de un Actor, sistema realiza una transferencia (emisor – receptor) de Entidades y/o Actuaciones dentro de unas coordenadas espacio-tiempo y con una cadencia determinada.

• Ej. Actualizar Catálogo, Cuenta, Venta, Artículo, Cartera de …, Canal de Noticias, Nivel de Riesgo, Localización de Artículo, …

Procesar Ctas Ahorro

Calcular intereses del

mes

<<Incluye>>Actualizar

Ctas Ahorro

<<Incluye>>

Page 66: UML&TeoriaObjetos2

Consultar Item

• Representa la construcción de un Query.

• Actor busca información sobre Entidades y/o Actuaciones a través de unas condiciones de consulta.

• Ej. Condiciones referidas a Fechas, Códigos, Estados, …

Realizar Retiro de Cta Ahorro

Consultar Fondos de Cta Ahorro

<<extend>>

Page 67: UML&TeoriaObjetos2

Seleccionar Item

• Representa el resultado de una Query.

• Actor escoge Entidades y/o Actuaciones de un conjunto delimitado por el resultado de una búsqueda.

• Ej. Clientes, Alumnos, Pacientes, Ventas, Artículos, Matriculas,…

Realizar Retiro de

Cta Ahorro

Seleccionar Nro Cta Ahorro

<<Incluye>>

Page 68: UML&TeoriaObjetos2

Imprimir Documento

• Representa la justificación o resultado de una Actuación.

• Actor ordena fijar o reproducir en un documento de negocio un conjunto de atributos pertenecientes a la estructura de una o varias Entidades y/o Actuaciones.

• Ej. Imprimir Ticket de, Notas de Entrega, Contratos, Cuentas, Expedientes, Listas de Arqueo, Relación de Items, Formulario, Orden de Trabajo, Lista de Alumnos, …

Realizar Abono en Cta Ahorro

Ingresar monto a abonar

<<Incluye>> Seleccionar Nro Cta Ahorro

Imprimir Voucher de

Abono

<<Incluye>>

<<Incluye>>

Page 69: UML&TeoriaObjetos2

Calcular Importe, Promedio, …

• Representa un algoritmo complejo de cálculo por parte del Sistema.

• Sistema determina un valor numérico a partir de unos parámetros y una expresión matemática predefinida.

• Ej. Calcular Importe de Línea, Descuento de, Impuesto de, Total Factura, Riesgo Comercial, Retribuciones, Primas de Venta-Producción, Número de Lotes, …

Procesar Ctas Ahorro

Calcular intereses del

mes

<<Incluye>>

Page 70: UML&TeoriaObjetos2

Validar

• Representa una certificación o verificación de una Entidad por parte del Sistema.

• Sistema declara la conformidad de una Entidad, o una Actuación, a partir de unos parámetros y una expresión lógica predefinida.

• Ej. Validar Existencia de Entidad (Cliente, Alumno, Usuario, Trabajador, etc), Regla de Negocio, Entrada de un campo (datatype), Nivel de Acceso, Umbral de Tiempo, …

Validar Cta

Realizar Retiro de

Cta Ahorro Seleccionar Nro Cta Ahorro

<<Incluye>>

<<Incluye>>

Page 71: UML&TeoriaObjetos2

Vincular Items

• Representa un Grupo relacionado de Items.

• Actor ordena relacionar de una manera persistente a un conjunto restringido de Entidades y/o Actuaciones.

• Ej. Vincular Agentes, Items, Actuaciones, Expedientes, Pacientes, Diagnósticos, Procedimientos, Prestaciones, Incidencias, Productos, Servicios, Pagos, …

Realizar Auditoria a

Cta

Vincular Operaciones

en Cta

<<Incluye>>

Page 72: UML&TeoriaObjetos2

Autorizar • Representa una habilitación para que una Entidad pueda

actuar, o para que una Actuación siga su curso.

• Actor acredita a una Entidad para que pueda participar en una Actuación con un Rol y una responsabilidad determinada como Participante. Actor desencadena la realización de una Actuación controlada.

• Ej. Autorizar Agente habilitado, Transacción, Acceso, Habilitación de un Punto de Actuación. Afiliación, Solicitud, Prestación, Pago, Transferencia, Tramitación, …

Realizar Transferencia

Fondos

Seleccionar Cta Origen y Cta

Destino<<Incluye>>

Autorizar Transferencia

<<Incluye>>

Page 73: UML&TeoriaObjetos2

ESPECIFICACIÓN DE UN CASO DE USO

<Identificador> <nombre descriptivo>

Descripción El sistema deberá permitir a [lista actores] en [instante en el que se puede realizar el caso de uso] [funcionalidad que define el caso de uso] según se describe en el siguiente caso de uso:

Precondiciones <precondición del caso de uso>: Lo que tiene que cumplirse o ser verdadero para que el caso de uso se ejecute con éxito.

Secuencia Normal

Paso Acción 1 {<acción a realizar>, realizar el caso de uso [caso de uso]} 2 <Situación que produce una alternativa> 2a Si [Situación que produce una alternativa] el sistema deberá

{<acción a realizar>, realizar el caso de uso [caso de uso]} 2b Si [Situación que produce una alternativa] el sistema deberá

{<acción a realizar>, realizar el caso de uso [caso de uso]} … ….

… … n ….

Postcondición <postcondición del caso de uso>: Lo que tiene que cumplirse o ser verdadero cuando finalice el caso de uso.

Extensiones Paso Acción p En el caso de que [situación opcional que provoca la extensión] el

sistema deberá {<acción a realizar>, realizar el caso de uso [caso de uso]}

… … q …

Excepciones {Esta sección describe todas las condiciones de error que pueden presentarse en el caso de uso.} Lista de cualquier excepción que debería hacer que el caso de uso se ejecute inadecuadamente y que genera un mensaje de error.

Rendimiento El sistema deberá realizar la/s acción /es descrita/s en {los pasos [primer paso] al [último paso], el paso [número de paso]} en un máximo de [cota de tiempo]

Frecuencia Este caso de uso se espera que se lleve a cabo una media de [número de veces] al [unidad temporal]

Importancia {vital, importante,quedaría bien}

Urgencia {inmediatamente, hay presión, puede esperar}

Comentarios <otras consideraciones en formato libre>

Page 74: UML&TeoriaObjetos2

1.- Caso de Uso del Sistema

2.- Descripción del caso de uso

3.- Actor(es)

4.- Precondiciones

5.- Post condiciones

6.- Pasos (Flujo de Eventos) Nro Acción del Actor Respuesta del Sistema

1

2 Escenario 1.-

3

4 Escenario 2.-

5

6 Escenario 2.1:

7

8 Invoca al CU nro …

9 Escenario 2.2.-

10 Invoca al CU nro …

11 Escenario 3: Selecciona Finalizar

12 Cierra la Interface nro … y termina el caso de uso.

7.- Requerimiento asociado

8.- Prototipo de Interface de usuario

Page 75: UML&TeoriaObjetos2
Page 76: UML&TeoriaObjetos2

Especificación corta de Caso de Uso

Especificación de casos de Uso: Forma Corta

El registrador ingresa DNI o código de socio. El sistema valida habilitación del socio. El sistema muestra formulario para registro de nueva solicitud de préstamo con los datos básicos del socio. El registrador verifica deuda de socio. El sistema muestra deuda a la fecha. Si el socio mantiene deuda no se registra solicitud. Si no presenta deuda pendiente el registrador procede a ingresar datos del préstamo. El registrador selecciona socio garante. El registrador solicita registrar nueva solicitud. El sistema registra la solicitud de préstamo.

Realizar Registro Solicitud prestamo

Page 77: UML&TeoriaObjetos2
Page 78: UML&TeoriaObjetos2
Page 79: UML&TeoriaObjetos2
Page 80: UML&TeoriaObjetos2
Page 81: UML&TeoriaObjetos2
Page 82: UML&TeoriaObjetos2
Page 83: UML&TeoriaObjetos2
Page 84: UML&TeoriaObjetos2
Page 85: UML&TeoriaObjetos2
Page 86: UML&TeoriaObjetos2

Diagrama de Secuencia

Page 87: UML&TeoriaObjetos2

Diagrama de secuencia

• Es una representación que muestra, en un determinado escenario, los eventos generados por actores externos al sistema y su orden secuencial.

• En un primer momento al sistema se le trata como caja negra; los diagramas se centran en los eventos que fluyen de los actores al sistema.– En el diagrama el tiempo avanza hacia abajo, y el

ordenamiento de los eventos debe seguir el orden indicado en el caso de uso.

– Los eventos del sistema pueden incluir parámetros.

Page 88: UML&TeoriaObjetos2

Eventos, mensajes y operaciones

• El evento de un sistema es un hecho externo de entrada que un actor produce sobre un sistema.

• La operación de un sistema son las acciones que éste lleva acabo a través de las clases en respuesta al evento externo y ejecutadas por una secuencia de mensajes.

• El nombre del evento y de la operación son idénticos; la distinción reside en que el evento es el estímulo nombrado y la operación es la respuesta (lo mismo sucede con los mensajes y los métodos).

Page 89: UML&TeoriaObjetos2

Mensajes

• Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; síncronos o asíncronos; llamadas o señales.

• En el siguiente diagrama:– el primer mensaje es un mensaje síncrono

(denotado por una punta de flecha oscura), completo con un mensaje de retorno implícito;

– el segundo mensaje es asíncrono (denotado por una punta de flecha en línea), y

– el tercero es un mensaje de retorno asíncrono (denotado por una línea punteada).

Page 90: UML&TeoriaObjetos2

SD mensajes

mensaje(retorno)

mensaje(parametros)

retorne:=mensaje(parametros)

Origen Destino

mensaje(retorno)

mensaje(parametros)

retorne:=mensaje(parametros)

Page 91: UML&TeoriaObjetos2

Mensaje Self

• Un mensaje self puede representar una llamada recursiva de una operación, o un método llamando a otro método perteneciente al mismo objeto.

• Este se muestra cuando crea un foco de control anidado en la ocurrencia de ejecución de la línea de vida.

Page 92: UML&TeoriaObjetos2

SD self

recursion

mensaje self

origen

recursion

mensaje self

Page 93: UML&TeoriaObjetos2

Inicio y final de línea de vida

• Una línea de vida se puede crear o destruir durante la escala de tiempo representada por un diagrama de secuencia.

• En el último caso, la línea de vida se termina por un símbolo de destrucción, representado como una cruz.

• En el primer caso, el símbolo al inicio de la línea de vida se muestra en un nivel más bajo de la página que el símbolo del objeto que causó la creación.

• El siguiente diagrama muestra un objeto que fue creado y destruido.

Page 94: UML&TeoriaObjetos2

SD padre e hijo

borrar

crear

Padre

Hijo

borrar

crear

Page 95: UML&TeoriaObjetos2

Restricciones de tiempo y duración

• En forma predeterminada, un mensaje se muestra como una línea horizontal.

• Ya que la línea de vida representa el pasaje de tiempo hacia abajo, cuando se modela un sistema en tiempo real, o incluso un proceso de negocios en tiempo límite, puede ser importante considerar el tiempo que toma realizar las acciones.

• Al configurar una restricción de duración para un mensaje (delay), el mensaje se mostrará como una línea inclinada.

Page 96: UML&TeoriaObjetos2
Page 97: UML&TeoriaObjetos2

Fragmentos combinados

• No se espera que los diagramas de secuencia muestren lógicas de procedimientos complejos.

• Siendo este el caso, hay un número de mecanismos que permiten agregar un grado de lógicas de procedimientos a los diagramas y que a la vez vienen bajo el encabezado de fragmentos combinados.

• Un fragmento combinado es una o más secuencias de procesos incluidas en un marco y ejecutadas bajo determinadas circunstancias nombradas y específicas.

Page 98: UML&TeoriaObjetos2

Fragmentos disponibles– El fragmento Alternative (denotado “alt”) modela estructuras if…then…else.– El fragmento Option (denotado “opt”) modela estructuras switch.– El fragmento Break modela una secuencia alternativa de eventos que se procesa

en lugar de todo del resto del diagrama.– El fragmento Parallel (denotado “par”) modela procesos concurrentes.– El fragmento de secuenciado Weak (denotado “seq”) incluye un número de

secuencias para las cuales todos los mensajes se deben procesar en un segmento anterior, antes de que el siguiente segmento pueda comenzar, pero que no impone ningún secuenciado en los mensajes que no comparten una línea de vida.

– El fragmento de secuenciado Strict (denotado “strict”) incluye una serie de mensajes que se deben procesar en el orden proporcionado.

– El fragmento Negative (denotado “neg”) incluye una serie de mensajes inválidos.– El fragmento Critical incluye una sección crítica. – El fragmento Ignore declara un mensaje o mensajes que no son de ningún interés

si este aparece en el contexto actual.– El fragmento Consider es el opuesto del fragmento Ignore: cualquier mensaje que

no se incluya en el fragmento Consider se debería ignorar.– El fragmento Assertion (denotado “assert”) designa que cualquier secuencia que

no se muestra como un operando de la aserción es inválida.– El fragmento Loop incluye una serie de mensajes que están repetidos.

Page 99: UML&TeoriaObjetos2

Tipo de fragmento Descripción

Opt Opcional. Alberga una secuencia que puede o no producirse. Modela estructuras tipo switch. En la protección, puede especificar la condición en la que se produce.

Alt Alternative. Contiene una lista de fragmentos que contienen secuencias de mensajes alternativos. modela estructuras if…then…else. Solo se produce una secuencia en cada ocasión ya sea que la condición a verificar es verdadera o falsa.

Loop

El fragmento se repite cierto número de veces. Puede indicar en la protección la condición que debe darse para que se repita. Los fragmentos combinados de bucle tienen las propiedades Min y Max, que indican el número mínimo y máximo de veces que el fragmento se puede repetir. El valor predeterminado es la ausencia de restricciones.

InterInterrupt. Si se ejecuta este fragmento, se abandona el resto de la secuencia. Puede utilizar la protección para indicar la condición en la que se producirá la interrupción.

Par Paralelo. Modela procesos concurrentes. Se pueden intercalar eventos en los fragmentos.

Crítico Se utiliza en los fragmentos Par o Seq. Indica que los mensajes de este fragmento no deben intercalarse con otros mensajes.

Seq

Sequence. Hay dos o más fragmentos de operandos. Los mensajes relacionados con la misma línea de vida deben producirse en el orden de los fragmentos. Si no están relacionados con las mismas líneas de vida, los mensajes de fragmentos diferentes se pueden intercalar en paralelo.

Strict incluye una serie de mensajes que se deben procesar en el orden proporcionado.

Fragmentos que describen el flujo de control

Page 100: UML&TeoriaObjetos2

Tipo de fragmento

Descripción

Consider

Es el opuesto del fragmento Ignore: cualquier mensaje que no se incluya en el fragmento Consider se debería ignorar.Pueden producirse otros mensajes en el sistema en ejecución, pero no son significativos para los propósitos de esta descripción, solo hay que considerar los que aparecen en el fragmento.

Ignore

Declara o lista los mensajes que no son de interés en este fragmento. Pueden presentarse en el diagrama en ejecución, pero no son significativos para los propósitos de esta descripción. Especifique la lista en la propiedad Messages.

Assert

El fragmento de operando especifica las únicas secuencias válidas. Designa que cualquier secuencia que no se muestra como un operando de la aserción es inválida. Normalmente se utiliza en un fragmento Consider o Ignore.

Neg Negative. La secuencia que se muestra en este fragmento no debe producirse. Normalmente se utiliza en un fragmento Consider o Ignore.

Fragmentos relativos a la interpretación de la secuencia

Page 101: UML&TeoriaObjetos2

Fragmento que combina una

Alternancia (alt)

Las alternativas se utilizan para designar una opciones mutuamente excluyentes entre dos o más secuencias de mensajes. Alternativas permiten el modelado de la clásica lógica “If … Then … Else" .

Page 102: UML&TeoriaObjetos2

Fragmento que combina un loop (opt)

Page 103: UML&TeoriaObjetos2

Combinación de un LOOP

• En ocasiones, necesitaremos modelar una secuencia repetitiva. En UML 2, el modelado de una secuencia repetitiva se ha mejorado con la adición de bucles.

• El uso de la combinación de un bucle es muy similar en apariencia al uso de la combinación de una opción.

• En un loop o bucle, una condición guarda puede tener dos condiciones especiales de prueba en contra además de la prueba Booleana estándar; las condiciones son minint y maxint para el mínimo y máximo número de iteraciones en la repetición de mensajes..

Page 104: UML&TeoriaObjetos2

Fragmento LOOP

Page 105: UML&TeoriaObjetos2

Fragmento que combina una opción (opt)

Es usada para modelar una secuencia que, dada una cierta condición, se ejecutará; en otro caso, la secuencia no se ejecutará. Una opción es usada para modelar una simple sentencia (if …. Then …..)Opt es similar al fragmento que combina la alternancia, salvo que sólo tiene un operando y no existe la condición “else“ (simplemente no tiene sentido aquí).

Page 106: UML&TeoriaObjetos2
Page 107: UML&TeoriaObjetos2

• Sentencias de control de flujo de ejecución en los diagramas de secuencia– alt: Equivale a un

if/else – loop: Equivale a un for– Existen más

sentencias

Page 108: UML&TeoriaObjetos2
Page 109: UML&TeoriaObjetos2
Page 110: UML&TeoriaObjetos2

Sistema

Seleccionar producto (codigo)

TerminarVenta ( )

EfectuarPago (monto)

:cajeroIniciarVenta ( )

ActorComo caja negra

Evento del sistema inicia una operación del sistema

IniciarVenta ( )

Mostrar stock(codigo)

Ingresar producto

Ingresar cantidad producto

cantidad producto (codigo,z)

Actualizar stock (codigo,z)

Ingresar nuevo producto

Loop

Page 111: UML&TeoriaObjetos2
Page 112: UML&TeoriaObjetos2

Diagrama de Interacción General

Page 113: UML&TeoriaObjetos2

: Jefe de obra : CI-Menú : CC-Aceptar/Rechazar proyecto

: CI-Aceptar/Rechazar : Maestro de

proyectos : Proyecto

Aceptar/Rechazar un proyecto( )Aceptar/Rechazar proyecto( ) Proyectos:=Obtener todos los proyectos evaluados técnica y económicamente( )

Proyecto:=Obtener datos del proyecto( )

Técnicamente:=Verificar si está evaluado técnicamente( )

Económicamente:=Verificar si está evaluado económicamente( )

Mostrar todos los proyectos(Proyectos )

Indica resultados de análisis de un proyecto( )

Registrar Aceptación/Rechazo( Proyecto,Aceptación/Rechazo)

Registrar Aceptación/Rechazo( Proyecto,Aceptación/Rechazo)

Cambiar estado( Proyecto,Aceptación/Rechazo)

Verificar si es proyecto(Proyecto )

Cambiar estado( Aceptado)

Cambiar estado( Rechazado)

Solo se devuelven los datos si el tiene ambas evaluaciones

Si no es el proyecto, no se cambia el estado

Se ejecuta uno u otro método

Page 114: UML&TeoriaObjetos2

Diagrama de Actividad

Page 115: UML&TeoriaObjetos2

• Son particularmente útiles para la descripción del comportamiento

• Permite recoger o definir el orden en que se hacen o se harán las cosas. Esto es, establece las reglas esenciales de secuenciación ha seguir.

• Los diagramas de flujo se limitan normalmente a procesos secuenciales; los diagramas de actividades pueden manejar procesos paralelos.

• Ésta es la diferencia clave entre un diagrama de actividades y un diagrama de flujo.

Diagrama de Actividad

Page 116: UML&TeoriaObjetos2

Elementos de un Diagrama de Actividad

• Los elementos más habituales son:– Nodos inicio y final– Actividades / acciones.– Decisiones.– Swimlanes o carriles.

• También se puede utilizar:– Objetos.– Barras de sincronización (Fork/Join)

Page 117: UML&TeoriaObjetos2

• Podemos utilizar diagramas de actividades para:

• Definir el comportamiento de casos de uso.

• Modelar procesos de negocio.

• Definir el comportamiento de un método.

• Definir estados complejos.

Usos del Diagrama de Actividad

Page 118: UML&TeoriaObjetos2
Page 119: UML&TeoriaObjetos2

• Esta última característica es importante para el modelado de negocios. Los negocios con frecuencia establecen procesos secuenciales innecesarios.

• Una técnica como ésta, que promueve el comportamiento paralelo, es valiosa en estas situaciones, porque auspicia que las personas se aparten de las secuencias innecesarias en su comportamiento y descubran oportunidades para hacer cosas en paralelo.

• Esto puede mejorar la eficiencia y capacidad de respuesta de los procesos del negocio.

Diagrama de Actividad

Page 120: UML&TeoriaObjetos2

• Los diagramas de actividad deben mostrar qué se hace y quien lo hace. Esto significa que el diagrama especifica cuáles son los roles o unidades organizacionales responsables de cada actividad.

• Los carriles(swimlanes) son una forma de subsanar esta deficiencia.

• Para usar los carriles, el diagrama de actividad se debe organizar en zonas verticales separadas por líneas similares a los de una piscina. Cada zona representa la responsabilidad de una clase o de un rol o, el de una unidad organizacional(departamento) en particular.

Swimlanes o carriles

Page 121: UML&TeoriaObjetos2

Diagrama de actividad para retirar dinero de cta a través de cajero automático

Page 122: UML&TeoriaObjetos2

Buscar Bebida

Poner café en filtro Añadir agua al depósito Coger taza

Poner filtro en máquina

Encender máquina

Café en preparación

Servir café

Coger zumo

Beber

[no hay café]

[hay café]

[no zumo]

[hay zumo]

^cafetera.On

indicador de fin

Diagrama de actividad para servir y tomar bebida

Page 123: UML&TeoriaObjetos2

Emitir billete

Vendedor Airline

Solicitar pago Reservar asiento

Confirmar asiento reservadoPagar pasaje

Informar alternativas y precios

Verificar existencia vuelo

Dar detalles vuelo

Solicitar pasaje

Seleccionar vuelo

Pasajero

Diagrama de actividad para compra un pasaje aéreo

Page 124: UML&TeoriaObjetos2
Page 125: UML&TeoriaObjetos2

Diagrama de Paquetes

Page 126: UML&TeoriaObjetos2

Que es un Paquete?

• Un paquete representa una forma de agrupar elementos del modelado del SI muy cohesionados ( o muy relacionados) para mostrar un mayor orden y organización para la construcción del SI.

Page 127: UML&TeoriaObjetos2

Diagrama de Paquetes

• Diagrama que muestra la asociación de dependencia entre los distintos paquetes definidos para un SI.

• Los paquetes pueden representar sectores de actividad, áreas de negocio o módulos del sistema de información.

Page 128: UML&TeoriaObjetos2

Stma Inf. Gestión Hospitalario

ATENCION MEDICA

LABORATORIO CITAS

PROGRAMACION

CAJA

Page 129: UML&TeoriaObjetos2

Elementos de Paquete

• Actores: – Responsable Programación de servicios– Medico

• Casos de Uso– Realizar Registro Programación servicios médicos– Realizar Registro de disponibilidad horaria

• Diagramas de secuencia• Diagramas de Actividad• Diagramas de transición de estados• Diagramas de clases

PROGRAMACION

Page 130: UML&TeoriaObjetos2

GUI

DEFINIR CONSULTORIO

Stma. Gestión Hospitalaria

Código Consultorio Pabellón Piso

Muebles

Escritorio

Sillas

Archivador

Estante

Camilla

Equipos

Balanza

Lámpara

PC

Comunicador

Teléfono

Muebles y Equipos

Registrar

Page 131: UML&TeoriaObjetos2

Diagrama de Clases

Page 132: UML&TeoriaObjetos2

Clases de Análisis

• Clase Frontera, Borde o Interfaz, es aquella clase con la que interactúa un usuario al utilizar el sistema.

• Clase Gestora, Administradora o Controladora, es aquella clase que se encarga de ejecutar las operaciones activadas o disparadas desde las clases Interfaz.

• Clase Entidad, es aquella clase que reúne el conjunto de datos procesados por las operaciones ejecutadas por la clase Gestora.

Page 133: UML&TeoriaObjetos2

Diagrama de Comunicación

• Uno de los primeros pasos en la creación de un diagrama de clases es obtener de un caso de uso, las clases que participan en su realización, y construir un diagrama de Comunicación (o Colaboración).

• El actor interacciona con la clase interfaz, la cual dispara las operaciones públicas de la clase gestora para operar con los datos de la o las clases entidad.

Page 134: UML&TeoriaObjetos2

Diagrama de clases de análisis o de comunicación

Page 135: UML&TeoriaObjetos2
Page 136: UML&TeoriaObjetos2

Jefe de obra CI-Menú

Aceptar/Rechazar un proyecto()

CI-Aceptar/Rechazar

Mostrar todos los proyectos()Indica resultados de análisis de un proyecto()

CC-Aceptar/Rechazar proyecto

Aceptar/Rechazar proyecto()Registrar Aceptación/Rechazo()

Maestro de proyectos

opname()Obtener todos los proyectos evaluados técnica y económicamente()Registrar Aceptación/Rechazo()

Proyecto

Obtener datos del proyecto()Verificar si está evaluado técnicamente()

Verificar si está evaluado económicamente()Cambiar estado()

Verificar si es proyecto()Cambiar estado()

0..n0..n

Page 137: UML&TeoriaObjetos2

ALUMNOALUMNODNI : char[10]DNI : char[10]

nombre : char[50]nombre : char[50]

fecha_nacimiento : datefecha_nacimiento : date

numero_expediente : intnumero_expediente : int

credito_educativo : money = 0credito_educativo : money = 0

alta ( )

poner_nota (asignatura: char[5], año: int, nota: float )

matricular (curso: asignatura, año: int)

listar_expediente ( )( )

Atributo

Tipoatributo

Valor inicial de atributo

Operación Argumentosde operación

Especificación detallada de una clase

Page 138: UML&TeoriaObjetos2

Propiedades fundamentales• Sirven para definir a un

objeto de modo inequívoco: – una identidad (nroSerie), – un estado (desenchufada), y – un comportamiento (que

depende del estado).

nroSerie = 23456Amarca = ostertipo = vaporcolor = rosadavolumenAgua = 0temperatura = 10estado = desenchufada

PLANCHA

crearPlancha( )enchufar( )desenchufar( )regular_temperatura( )llenar_agua( )flujo_vapor( )

Page 139: UML&TeoriaObjetos2

Datos y métodos

• Dentro de los objetos residen los datos así como los métodos que operan sobre ellos.

• Los datos y los métodos asociados se dice que están encapsulados y ocultos; si se desea modificar los datos de un objeto se debe conocer exactamente cuales son las funciones que interactúan con los mismos ya que ninguna otra función puede acceder a ellos.

Page 140: UML&TeoriaObjetos2

Ejemplos de Objetos• Desde el punto de vista informático los objetos son tipos

abstractos de datos (tipos que encapsulan datos y funciones que operan sobre esos datos).

• Ejemplos de objetos:– Numero racional

• Dato (valor actual)• Operaciones (sumar, multiplicar, …)

– Vehículo• Datos (velocidad, kilometraje, posición, precio,…)• Operaciones (acelerar, frenar, parar, …)

– Avión• Datos (fabricante, modelo, matricula, capacidad, …)• Operaciones (aterrizar, despegar, volar, …)

– Conjunto• Dato (numero elementos)• Operaciones (adicionar, quitar, visualizar, …)

Page 141: UML&TeoriaObjetos2

Implementación de una Clase en Java

Page 142: UML&TeoriaObjetos2

• Expresa una conexión semántica bidireccional entre clases.

• Una asociación es una abstracción de los enlaces que existen entre los objetos instancias de las clases asociadas.

Asociación entre Clases

Clase AClase A Clase BClase B

Asociación

Page 143: UML&TeoriaObjetos2

Rolenames para una Asociación entre Clases

• Al extremo de una asociación se llama rol o función. Cada asociación binaria posee dos roles, uno en cada extremo.

• El rol describe como una clase ve a otra clase a través de la asociación.

• Para una sola asociación, los nombres de las clases bastan para identificar el rol o función; el nombrado de los roles tiene mayor interés cuando existe mas de una asociación entre dos clases.

EMPRESAEMPRESA

PERSONAPERSONA

Empleador

Empleado

AVIONAVION

PERSONAPERSONAPiloto

Pasajero

Page 144: UML&TeoriaObjetos2

• Los roles contienen también una información de multiplicidad que precisa el número de instancias que participan en la asociación.

1 uno y sólo uno0..1 cero o unom..n de "m" a "n"

* muchos

0..* cero a muchos

1..* uno a muchos

Multiplicidad de una Asociación

Empresa Personaejecutivoejecutivo

obreroobreroempleadorempleador

**1

0..1

Page 145: UML&TeoriaObjetos2

Comunicación entre objetos: los mensajes

• A los objetos sólo se puede acceder a través de su interfaz público.

• Un objeto accede a otro objeto enviándole un mensaje.

• Un mensaje es una petición de un objeto a otro objeto al que le solicita ejecutar uno de sus métodos.

• No todos los mensajes de un objeto se pueden invocar; sólo los que pertenecen al interfaz accesible.

AUTO

MODELO: explorerPUERTAS: 2KILOMETRAJE: 80000COLOR: plataAÑO PROD: 2003NRO PLACA: LJ3456PRECIO: 12500VOLUMENTANQUE:10ESTADO: Detenido

AUTO( )FIJAR PRECIO AUTO ( )LLENARTANQUE ( )ACTUALIZARKILOMETRAJE()ENCENDER( )

FIJAR PRECIO AUTO ( )

Page 146: UML&TeoriaObjetos2

Partes de un Mensaje

• Identidad del receptor.

• El método que se ha de ejecutar.

• Información especial necesaria para realizar el método invocado (argumentos o parámetros requeridos).

Page 147: UML&TeoriaObjetos2

Nombre de un mensaje

• Un mensaje incluye el nombre de una operación y cualquier argumento requerido por esa operación.

• Con frecuencia es útil referirse a una operación por su nombre sin considerar sus argumentos.

Page 148: UML&TeoriaObjetos2

Mensajes y Métodos• Cuando un objeto recibe un mensaje se

realiza la operación solicitada ejecutando un método.

• Un método es el algoritmo ejecutado en respuesta a la recepción de un mensaje cuyo nombre se corresponde con el nombre del método.

Page 149: UML&TeoriaObjetos2

Paso de Mensajes• Los objetos se comunican entre sí a través del uso de

mensajes.• Esencialmente el protocolo de un mensaje implica dos

partes: el emisor y el receptor. Cuando un objeto emisor envía un mensaje a un objeto receptor especifica lo siguiente:– Un receptor (objeto receptor).– Un nombre de mensaje (en relación al método invocado).– Argumentos o parámetros (si se necesitan).

• Los parámetros o argumentos pueden ser:– Datos utilizados por el método invocado– Un mensaje propiamente dicho

acción <objeto>.<método (parámetro 1, …,parámetro n)>

Page 150: UML&TeoriaObjetos2

• Son modelos de clases. Una clase parametrizable es una clase que es usada para crear una familia de otras clases.

• Una clase parametrizable no puede ser utilizada tal cual. Conviene primero instanciarla, a fin de obtener una clase concreta que podrá a su vez ser instanciada en objetos.

Clase Clase ParametrizadParametrizad

aaAtributo 01Atributo 01

Atributo 02Atributo 02

Operacion 1 ( )Operacion 1 ( )

Operacion 2 ( )Operacion 2 ( )

ItemItem

Clase Parametrizada

Page 151: UML&TeoriaObjetos2

• Una clase parametrizable es alguna suerte de contenedor, y también es conocida como un template(plantilla), como los templates de C++.

• Este tipo de clases no aparece generalmente en el análisis.

• Las clases parametrizables se utilizan sobre todo en diseño detallado para incorporar, por ejemplo, componentes reutilizables.

ListaLista

AtributoAtributo

Adicionar ( )Adicionar ( )

Remover ( )Remover ( )

ItemItem

ListaLista<<EmpleadosEmpleados>>

AtributoAtributo

Adicionar ( )Adicionar ( )

Remover ( )Remover ( )

ListaLista<<OrdenesOrdenes>>

AtributoAtributo

Adicionar ( )Adicionar ( )

Remover ( )Remover ( )

… Clase Parametrizada

Page 152: UML&TeoriaObjetos2

• Es una colección de sólo operaciones.• Aquellas operaciones de uso general

que no pueden acomodarse dentro de una clase particular, se encapsulan dentro de una clase utilidad para uso por las otras clases del sistema.

• Son clases que no pueden ser instanciadas, y que son útiles para agrupar elementos dentro de un módulo, como por ejemplo las funciones de una biblioteca matemática.

Clase Utilidad

Operacion 01 ( )Operacion 02 ( )

Clase utilidad

Page 153: UML&TeoriaObjetos2

• Es una clase parametrizada que contiene sólo un conjunto de operaciones.

• Representa la plantilla (template) que es utilizado para crear clases utilidad.

Clase Utilidad

Operacion 01 ( )Operacion 02 ( )

Item

Clase parametrizada utilidad

Page 154: UML&TeoriaObjetos2

• Es una clase cuyas instancias son clases en lugar de objetos.

• Las clases parametrizadas y las clases parametrizadas utilidad son ejemplos de metaclases.

Clase Clase ParametrizadParametrizad

aaAtributo 01Atributo 01

Atributo 02Atributo 02

Operacion 1 ( )Operacion 1 ( )

Operacion 2 ( )Operacion 2 ( )

ItemItem

Clase UtilidadClase Utilidad

Operacion 01 ( )Operacion 02 ( )

Item

Metaclase

Page 155: UML&TeoriaObjetos2

Herencia múltiple (problemas)• La propiedad

referida sólo está en una de las clases padre.

• La propiedad concreta existe en más de una superclase.

• Diferentes tipos de conflictos:– De nombres– De valores– Por defecto– Por dominio– Por restricciones

ESTUDIANTE EMPLEADO

PROFESOR ESTUDIANTE

Atributos-nombre estudiante-direccion-campus-carrera-año

Atributos-nombre empleado-direccion-estudios-campus-salario-dias_vacaciones

Métodos-Aumento_salario( )

Atributos-nombre-direccion-campus-salario-estudios-carrera-año-dias_vacaciones

Métodos heredados-Aumento_salario( )

Page 156: UML&TeoriaObjetos2

Ejemplos de conflictos

• Conflicto de nombres:– nombre_estudiante– nombre_empleado

• Conflicto de valores:– campus (atributos con igual nombre tienen

valores en cada clase)

ESTUDIANTE EMPLEADO

PROFESOR ESTUDIANTE

PERSONA

CLASE DERIVADA POR HERENCIA MÚLTIPLE

Page 157: UML&TeoriaObjetos2

Clases Abstractas• Con frecuencia cuando se diseña un modelo

orientado a objetos es útil introducir clases a cierto nivel que pueden no existir en la realidad pero que son construcciones conceptuales útiles. Estas clases se conocen como clases abstractas.

• Una clase abstracta normalmente ocupa una posición adecuada en la jerarquía de clases que le permite actuar como un depósito de métodos y atributos compartidos para las subclases del nivel inmediato inferior.

• Las clases abstractas no tienen instancias directamente. Las clases derivadas de una clase abstracta se conocen como clases concretas y pueden ser instanciadas.

Impresora

Tinta

Matricial

Laser

Page 158: UML&TeoriaObjetos2

Sobrecarga

• Es una propiedad que describe una característica adecuada que utiliza el mismo nombre de operación para representar operaciones similares que se comportan de modo diferente cuando se aplican a clases diferentes.

• Los nombres de las operaciones se pueden sobrecargar, esto es, las operaciones se definen en clases diferentes y pueden tener nombres idénticos, aunque su código programado puede diferir.

• Si los nombres de una operación se utilizan para nuevas definiciones en clases de una jerarquía, la operación a nivel inferior se dice que anula la operación a un nivel más alto (overriding), es decir se redefine la operación heredada.

Page 159: UML&TeoriaObjetos2

Ejemplo de sobrecarga

Empleado

Administrativo Ingeniero

Atributos - nombre- salario- edadOperacion- Incrementar salario = salario*inflacion + comision

Atributos - beneficios- salario [40 – 80]- edad [25 – 65]Operaciones-Incrementar salario = (salario+comision)*inflacion-Comision = 0.03*presupuesto

Atributos - especialidadOperacion- comision = 0.05*presupuesto

• La sobrecarga puede estar situada entre dos clases que no están relacionadas jerárquicamente.

• Lenguajes como C y Pascal soportan este tipo de operaciones a través de los operadores aritméticos, operaciones de E/S y operadores de asignación de valores.

Page 160: UML&TeoriaObjetos2

Estado• Agrupa los valores de

todos los atributos de un objeto en un momento dado, en donde un atributo es una pieza de información que califica el objeto contenedor.

• El estado de un objeto, en un momento dado, se corresponde con una selección determinada de valores a partir de valores posibles de los diversos atributos.

modelo color precio año motor estado

AUTO

Audi azul 25000 US$ 2010 1200cc nuevo

un AUTO

Fiat plateado 5500 US$ 1990 1200cc viejo

un AUTO

Page 161: UML&TeoriaObjetos2

Notación extendida de una clase• Los objetos no incluyen ninguna información sobre sus

operaciones a diferencia de las clases, ya que las operaciones son idénticas para todos los objetos de una misma clase, en cambio si de los atributos ya que varían entre objetos en relación con su valor.

Atributo1 : Tipo1 = Valor-Omision1 Atributo2 : Tipo2 = Valor-Omision2 …

NOMBRE DE LA CLASE

Operacion1 (Lista –Tipo -- Arg1) : Tipo -- Result1 Operacion2 (Lista –Tipo – Arg2) : Tipo – Result2 …

Page 162: UML&TeoriaObjetos2

Argumentos de una Operación

• Las operaciones pueden tener argumentos, es decir una lista de parámetros, cada uno con un tipo, y pueden también devolver resultados, cada uno con un tipo.

• Las operaciones se incorporan en la tercera sección de la clase, como se muestra en la figura.

posicion color

FIGURA

mover (v : Vector) : Boolean rotar(angulo) : Boolean …

nombre extensión tipo

ARCHIVO

imprimir(d: dispositivo, n : entero) : Boolean borrar( ) : Boolean …

Page 163: UML&TeoriaObjetos2

Otros conceptos relacionados con operaciones

• Consultas (query): operaciones que no alteran al objeto.

• Accesos: operaciones para leer o escribir los atributos de un objeto.

• Métodos: especificación de bajo nivel para implementar una operación.

• Poliformismo: una misma operación que se implementa en formas diferentes.

• Parametrización: definida por el número y tipo de argumentos de un método.

• Firmas: definida por el tipo y número de argumentos y el tipo de resultados que devuelve.

Page 164: UML&TeoriaObjetos2

Operaciones: Vida de los objetos• Los objetos son entidades que existen en el

tiempo; por ello deben ser creados o instanciados.

• Esta creación se hace a través de operaciones especiales llamadas constructores o inicializadores que se ejecutarán implícitamente por el compilador o explícitamente por el programador mediante la invocación a los citados constructores.

Page 165: UML&TeoriaObjetos2

Operaciones: Constructor y destructor

• Un método constructor de una clase es un método especial que:– tiene el mismo nombre que la clase,– crea un objeto y/o inicializa estado del objeto, – no tiene tipo de retorno.

• Un método destructor, en contraposición al constructor, elimina el vínculo y libera el espacio de memoria de un objeto, para que pueda ser ocupado nuevamente.

Page 166: UML&TeoriaObjetos2

Constructor y Destructor

• Los objetos ocupan un espacio en memoria y en consecuencia existen en el tiempo y deberán crearse o instanciarse. Por la misma razón se debe liberar el espacio ocupado por los objetos en la memoria.

• Los constructores y destructores se declaran como parte de la definición de una clase.

Page 167: UML&TeoriaObjetos2

Herencia

esposa : mujer

HOMBRE

tipo : string peso: real habitat: tipohabitat

CRIATURA

criatura () predadores( ) esperanza_vida( ) …

periodo_gestacion: real alimentacion: tipoalimento

MAMIFERO

nombre: string fecha_nacimiento: date origen: pais estado_civil: char=S

PERSONA

esposo : hombre nombre: string habitat: habitat

MUJER

Page 168: UML&TeoriaObjetos2

• clase criatura// atributosstring : tiporeal : pesotipoHabitat : habitat// operacionesconstructor criatura( )inicio…fin_constructormetodo predadores(E criatura: predador)inicio…fin_metodoentero función esperanza_vida( )inicio…fin_funcion…fin_clase // fin criatura

• Clase mamifero hereda_de criatura// atributosreal : periodo_gestacion// operaciones…fin_clase // fin mamifero

• Clase persona hereda_de mamifero // atributos string : apellidos, nombre date : fecha_nacimiento pais : origen

…// operaciones…fin_clase // fin persona

• Clase hombre hereda_de persona// atributos

mujer : esposa string : nombre

…// operaciones…fin_clase // fin hombre

• Clase mujer hereda_de persona// atributoshombre : esposostring : nombre…// operaciones…fin_clase // fin mujer

Page 169: UML&TeoriaObjetos2

Reglas de Visibilidad

• Privada ( - ): visible sólo para la clase y para las clases amigas (C++).

• Protegida( # ): visible sólo para las clases derivadas (subclases).

• Pública ( + ): visible para todas las clases con las que esta asociada.

Page 170: UML&TeoriaObjetos2

Clase asociación

• La asociación entre la clase Alumno y la clase Trabajo es del tipo n a n. La clase Trabajo describe el tema, la solución aportada por el Alumno no se conserva.

• En el caso de los controles de conocimientos, cada Alumno escribe individualmente sobre un Trabajo dado y la nota obtenida no puede almacenarse en un Alumno en particular (porque éste realiza varios trabajos) ni en un Trabajo (porque hay que registrar tantas notas como alumnos). La nota es un atributo de la relación entre la clase Alumno y la clase Trabajo.

DIPLOMADIPLOMA

HABITACIONHABITACION

0..*

ALUMNOALUMNO TRABAJOTRABAJO

NotaNota

0..*0..*1

1

1

MencionMencion

NumeroNumero

TemaTemaNombreNombre

Realiza >Realiza >

Page 171: UML&TeoriaObjetos2

• Consiste en seleccionar un subconjunto de objetos entre el conjunto de objetos que participan en una asociación.

• Se realiza por medio de una tupla de atributos particulares (llamada clave) y se utiliza conjuntamente con un objeto de la clase de partida.

• La clave se representa sobre el rol de la clase de partida bajo el nombre de cualificador o calificador. La clave pertenece a la asociación y no a las clases asociadas.

• El cualificador es un atributo especial que reduce la multiplicidad efectiva de una asociación. Las asociaciones uno a muchos y muchos a muchos pueden ser cualificadas.

DIRECTORIODIRECTORIO FILEFILE

0..*1..*nombrenombrepathpath

Contiene >Contiene >pathpath ID_fileID_fileDIRECTORIODIRECTORIO FILEFILE

1nombrenombre

Calificador

1..*

Cualificador

Page 172: UML&TeoriaObjetos2

Cualificador

• Si el valor de un atributo depende de un contexto particular, hay que pensar recalificar el atributo como cualificador.

• Por ejemplo, ID_empleado no es una propiedad única para una persona que tenga dos trabajos, lo que hace es cualificar la asociación Empresa a Persona nombrada como Emplea>.

EMPRESAEMPRESA PERSONAPERSONA

0..*0..*nombrenombredirecciondireccion

Emplea>Emplea>direcciondireccion ID_emplID_emplEMPRESAEMPRESA PERSONAPERSONA

1nombrenombre

Cualificador

0..*

Page 173: UML&TeoriaObjetos2

Navegabilidad

• Dada una asociación simple entre dos clases, es posible navegar de los objetos de un tipo a los del otro tipo. A menos que se indique lo contrario, la navegación a través de una asociación es bidireccional.

• Esto conceptualmente es correcto pero existen ocasiones en donde se desea restringir este mecanismo y trabajar de forma unidireccional para dotar de mayor detalle a nuestro modelo.

Page 174: UML&TeoriaObjetos2

Diagrama de clases mostrando navegabilidad

1

1..*

0..*

1

0..*

1

1

0..*

ORDEN VENTA

----

nro ventafecha ventamonto ventaestado venta

: Number: Date: Double: String

++++

venta ()detalle ()totalizar venta ()selecc cliente ()

: int: int: int: int

DETALLE ORDEN

---

cantidadpreciodescuento

: int: float: float

+ adic item () : int

CLIENTE

-------

ID clientenombredirecciontelefonoRUCcategoriaestado

: char: char: char: String: char: char: String

+++

historiaCredito ()poner categoria ()cliente ()

: int: int: int

PERSONA NATURAL

- nro tarjeta credito : int

PERSONA JURIDICA

- limite credito : int

PRODUCTO

---

ID productodenominacionstock minimo

: char: char: int

+ producto () : int

EMPLEADO

-----

ID empleadonombretelefonofecha ingresoestado

: char: char: char: Date: String

++

empleado ()nueva venta ()

: int: int

Page 175: UML&TeoriaObjetos2

• Las asociaciones describen la red de relaciones estructurales que existen entre las clases y que dan lugar a los enlaces entre los objetos.

• Los enlaces pueden ser vistos como canales de navegación entre los objetos.

• En principio, las asociaciones son navegables en ambas direcciones. En ciertos casos sólo es útil una dirección de navegación.

• La navegabilidad se representa por una flecha orientada hacia la clase sobre la que es pósible la navegación.

USUARIOUSUARIO PASSWORDPASSWORD*1

derechoderechoId usuarioId usuario

Dirección de navegavilidad

…. Navegabilidad

Page 176: UML&TeoriaObjetos2

• La sintaxis de las expresiones de navegación viene dada por las cuatro reglas siguientes :

– destino::=conjunto ‘.’ selector– destino::=conjunto ‘.’ ‘~’ selector– destino::=conjunto ‘[‘ expresion_booleana ‘]’– destino::=conjunto ‘.’ selector ‘[‘ valor_de_clave ‘]’

• El selector corresponde bien a un nombre de atributo de los objetos del conjunto, bien a un nombre de asociación de la clase de objetos, o bien a un nombre de rol opuesto sobre un enlace que concierne a los objetos del conjunto. El destino es un conjunto de valores o de objetos cuyo número depende de la multiplicidad del conjunto y de la asociación.

Expresiones de Navegabilidad

Page 177: UML&TeoriaObjetos2

• UnaPersona.Hijos designa todos los hijos de una persona dada.

• UnaPersona. ~Hijos designa los padres de una persona dada.• UnaPersona.Hijos[edad>=18años] designa todos los hijos

mayores de edad de una persona dada.• UnaPersona.Hijo[UnNombre] identifica un hijo dado de manera

no ambigua.

PERSONAPERSONA

nombrenombre

padre

hijo 1..

*

2

PERSONAPERSONA

nombrenombre

padre

hijo 1

2id persona

Page 178: UML&TeoriaObjetos2
Page 179: UML&TeoriaObjetos2
Page 180: UML&TeoriaObjetos2
Page 181: UML&TeoriaObjetos2

Diagrama de Transición de Estados

Page 182: UML&TeoriaObjetos2

• Mostrar los distintos estados por los que pueden atravesar los objetos de una clase como consecuencia de eventos externos.

• En general los estados están asociados con parte de los requerimientos de información exigidos al producto software.

Finalidad

Page 183: UML&TeoriaObjetos2

Los Estados

• Cada objeto está en un momento determinado en un estado particular.

• Los estados se caracterizan por la noción de duración y de estabilidad. Un objeto está siempre en un estado dado por un cierto tiempo y un objeto no puede estar en un estado desconocido o no definido.

ABIERTO CERRADO

Secc Fisica I : Secc Fisica I : CURSO SECCIONCURSO SECCION

El máximo nro de inscritos por sección es 30

numInscrt <30 numInscrit =30

CURSO SECCIONCURSO SECCION

periodoAcadseccionnumVacantnumInscritestado

adicionar( )cerrar( )

periodoAcad = 2011- Iseccion = AnumVacant = 30 numInscrit = 24estado = abierto

adicionar( )cerrar( )

adicionar( )cerrar( )

Page 184: UML&TeoriaObjetos2

Estado inicial y final

• Los autómatas usados por UML son deterministas.

• Ello significa que siempre hay que describir el estado inicial del objeto, el cual es único y aparece cuando el objeto es creado.

• El estado final indica el fin de la vida de un objeto.Es posible tener varios estados finales que corresponden cada uno a una condición de fin distinta.

A

estado inicial

B

estado final

Page 185: UML&TeoriaObjetos2

Las Transiciones• Los estados están vinculados por conexiones

unidireccionales llamadas transiciones.• El paso de un estado a otro se efectúa cuando se

desencadena una transición por un evento que aparece en el ámbito del problema.

• Las transiciones no vinculan necesariamente estados distintos.

Transición

ABIERTO CERRADO

numInscrt <30

numInscrit =30adicionar( )cerrar( )

cerrar

Page 186: UML&TeoriaObjetos2

Los Eventos

• Un evento sirve de desencadenante para pasar de un estado a otro.

• Los eventos determinan que caminos deben seguirse. Los eventos, las transiciones y los estados son indisociables en la descripción del comportamiento dinámico.

A BEv1

ABIERTO

CERRADO

CANCELADO

Cancelar Curso

Adicionar alumno

CerrarCurso

Page 187: UML&TeoriaObjetos2

Super y sub estados

• Super estados son los estados mas generales, los estados mas especifícos se llaman sub estados.

• Un estado puede descomponerse en varios sub estados disyuntivos (estados anidados).

• Los sub estados heredan características de su super estado, en particular las variables de estado y las transiciones externas.

A B

C

Ev1

Ev2 Ev2

A BEv1

C

Ev2

Super Estado

Sub Estado

Page 188: UML&TeoriaObjetos2

Estados anidados con Historia

Ev2MINIMIZADA

ABIERTA

MAXIMIZADA

CUSTOMIZADA

H

• El uso de la característica de historia H señala que al retornar un objeto a un super estado, este ingresará al último estado en el que estuvo dentro del super estado.

• Si la característica de historia no es utilizada siempre el sub estado inicial del super estado será asignado al objeto retornante.

Estados para los objetos de la clase Ventana cuyo estado ABIERTA tiene historia

Page 189: UML&TeoriaObjetos2

Agregación de Estados

• La agregación de estados es la composición de un estado a partir de otros varios estados independientes.

• La composición es de tipo conjuntiva lo que implica que el objeto debe estar simultáneamente en todos los estados que componen la agregación de estados

A

C

Ev1

Ev2

BEv3

X

Y

Ev1 Ev4[en C]

ESTADO AGREGADOESTADO AGREGADO

Page 190: UML&TeoriaObjetos2

Los Guardas

• Un guarda es una condición booleana que valida o no el desencadenamiento de una transición a partir de la ocurrencia de un evento.

A Ev1[condicion] B

CerrarInscripción [numInscrit =30]

ABIERTO

CERRADO

Un objeto Secc MAT I de la clase CURSO pasará del estado ABIERTO a CERRADO si :

Guarda

Page 191: UML&TeoriaObjetos2

Acciones de la Transición

• Cada transición puede ir acompañada del nombre de una acción a ejecutar cuando la transición es desencadenada por un evento.

• La acción corresponde a una de las operaciones declaradas en la clase del objeto destinatario del evento.

• Estas acciones son operaciones asociadas a la transición de un estado a otro:

– Toma una cantidad insignificante de tiempo completarla.

– Considerada ininterrumplible– El evento que produce la transición

puede generar el envío de otro evento.

ABIERTO

CERRADO

CANCELADO

Cancelarcurso

Adicionaralumno

CerrarCurso [numInscrit =30]

CREADOAbrir Inscripción/ Inicializar numInscrit to 0

^ReporteCurso.CreateReporte

Acción

Page 192: UML&TeoriaObjetos2

Acciones de Estado• Los estados pueden contener

también acciones que se ejecutan al entrar o salir del estado, mientras esta en el estado o al ocurrir un evento mientras el objeto está en ese estado.• La acción de entrada (entry:) se

ejecuta de manera instantánea y atómica al entrar en el estado.

• La acción de estado (do:) se ejecuta mientras se encuentra en el estado.

• La acción de salida (exit:) se ejecuta al salir del estado.

• La acción sobre el evento interno (on:) se ejecuta al ocurrir un evento que no conduce a otro estado.

CREADO

PROGRAMADO

ABIERTO

CERRADO

do: inicializarCursoSección

do: asignar Profesor Curso

entry: inscribir Alumno

do: reportar Curso Cerrado

AbrirInscripciones

Adicionaralumno

Cerrarregistro

Asignarprofesor

Page 193: UML&TeoriaObjetos2

Puntos de ejecución de las Operaciones

• Existen seis puntos, cuyo orden es :– La acción asociada a la transición de

entrada (Op1)– La acción de entrada de estado (Op2)– La actividad en el estado (Op3)– La acción de salida del estado (Op4)– La acción asociada a los eventos internos

(Op5)– La acción asociada a la transición de salida

del estado (Op6)

entry: Op2 Do: Op3 exit : Op4On UnEvento : Op5

Un estado

/ Op1

/ Op6

Page 194: UML&TeoriaObjetos2

CREADO

do: Inicializar CursoSección

PROGRAMADOdo: Asignar Profesor Curso

ABIERTOentry: inscribir un alumno

CERRADOdo: reportar CursoSección cerrado

Abrir inscripción/nroInscritos=0

Adicionar Alumno/nroInscritos=nroInscritos+1

CerrarRegistro[nroInscritos=30]

Asignarprofesor

CANCELADOdo: reportar cancelación curso

Cancelar curso[nroInscritos <5]

Cancelar curso

Cancelarcurso

Cancelarcurso

Page 195: UML&TeoriaObjetos2

Diagrama de Estados

para los objetos de la Clase EJEMPLAR

EJEMPLAREJEMPLAR

Codigo : integerCodigo : integer

Cantidad : integerCantidad : integer

Estado : integerEstado : integer

exponer ( )exponer ( )

reservar ( )reservar ( )

borrarReserva ( )borrarReserva ( )

prestar ( )prestar ( )

devolver ( )devolver ( )

retirar ( )retirar ( )

reponer ( )reponer ( )

En Proceso

En Circulación

Disponible

Reservado

Prestadoprestar( )

reservar( )

borrarReserva( )

devolver( )

prestar( )

retirar( )exponer( )

constructor( ) destructor( )

Page 196: UML&TeoriaObjetos2
Page 197: UML&TeoriaObjetos2

Diagrama de Componentes

Page 198: UML&TeoriaObjetos2

• Un componente es una unidad autónoma reemplazable de un sistema

• Los componentes indican los interfaces públicos para que otros componentes los usen (relación de realización)

• Los componentes pueden indicar los interfaces requeridos en otros componentes (relación de uso)

Componente

Page 199: UML&TeoriaObjetos2

Componente

• Describen los elementos físicos y sus relaciones en el entorno de realización.

• Muestran las dependencias del compilador y del “runtime” entre los componentes del software; por ejemplo, los archivos del código fuente y los DLL.

• Es un módulo físico de código.• Los componentes pueden incluir librerias de

código fuente y “run time” files (archivos exe, DLL’s y tareas).

Page 200: UML&TeoriaObjetos2

• En un mismo diagrama pueden aparecer varios componentes conectados mediante interfaces

Page 201: UML&TeoriaObjetos2
Page 202: UML&TeoriaObjetos2
Page 203: UML&TeoriaObjetos2
Page 204: UML&TeoriaObjetos2
Page 205: UML&TeoriaObjetos2
Page 206: UML&TeoriaObjetos2
Page 207: UML&TeoriaObjetos2

Diagrama de Despliegue

Page 208: UML&TeoriaObjetos2

Diagrama de Despliegue

• Muestra la disposición física de los distintos dispositivos (nodos) que entran en la composición de un sistema y el reparto de los programas ejecutables sobre estos nodos.

• Muestra la configuración de los nodos de procesamiento “run time” y los componentes que residen sobre ellos.

Page 209: UML&TeoriaObjetos2

Nodos

• Cada dispositivo o recurso se representa por un cubo que evoca la presencia física del equipo en el sistema. Todo sistema se describe por un pequeño número de diagramas de despliegue; a menudo basta con un sólo diagrama.

• Los diagramas de despliegue pueden mostrar clases de nodos o instancias de nodos.

NODO

MODEM PC DISCO

<<Dispositivo>> <<Procesador>> <<Memoria>>

Representación gráfica de los nodos.

Estereotipos de nodo

Page 210: UML&TeoriaObjetos2

• Muestra las partes físicas del sistema – PCs, Servidores

– Impresoras, scanners

– PDAs, móviles

• Que están conectadas por líneas de comunicación – Internet, LAN, USB,

Bluethoot

En general …..

Page 211: UML&TeoriaObjetos2
Page 212: UML&TeoriaObjetos2

Componentes y Nodos

Page 213: UML&TeoriaObjetos2
Page 214: UML&TeoriaObjetos2
Page 215: UML&TeoriaObjetos2

Otros Diagramas ….

Page 216: UML&TeoriaObjetos2
Page 217: UML&TeoriaObjetos2
Page 218: UML&TeoriaObjetos2
Page 219: UML&TeoriaObjetos2
Page 220: UML&TeoriaObjetos2
Page 221: UML&TeoriaObjetos2

SIGEAC

• El Sistema de Gestión Académica (SIGEAC) es una solución Web integrada de gestión administrativa, académica y pedagógica, diseñada a partir de un análisis de benchmarking de un grupo de las soluciones más reconocidas en el mercado internacional para el sector educativo . Esta solución tiene por objetivo cubrir efectivamente los procesos y servicios requeridos para la gestión educativa y su diseño le permite integrarse fácilmente a instituciones de todos los niveles de enseñanza.

Page 222: UML&TeoriaObjetos2

Módulos integrantes de SIGEAC

Page 223: UML&TeoriaObjetos2
Page 224: UML&TeoriaObjetos2
Page 225: UML&TeoriaObjetos2
Page 226: UML&TeoriaObjetos2
Page 227: UML&TeoriaObjetos2
Page 228: UML&TeoriaObjetos2
Page 229: UML&TeoriaObjetos2
Page 230: UML&TeoriaObjetos2
Page 231: UML&TeoriaObjetos2
Page 232: UML&TeoriaObjetos2

Sub Sistemas• Subsistema Seguridad: Encargado de brindar los mecanismos de seguridad que

permitan una correcta autenticación y autorización de los usuarios de SIGEAC. • Subsistema Administración de Notas: Encargado de la calificación de todo tipo de

evaluaciones. • Subsistema Programación de Actividades: Encargado del control de la programación

de las actividades y la asignación apropiada de los recursos. • Subsistema Matrícula: Encargado de la administración de la matrícula de los

alumnos. • Subsistema Administración del Sistema: Encargado de la administración general de

SIGEAC. • Subsistema Diseño Instruccional: Encargado de definir las características de las

evaluaciones. • Subsistema Facturación: Encargado del registro de pagos de los postulantes y

alumnos. • Subsistema Registro Institucional del Educando: Encargado del registro de la

información académica y extraacadémica de los educandos.

Page 233: UML&TeoriaObjetos2

Interacción entre el Subsistema de Admisión y subsistemas miembros de SIGEAC

Page 234: UML&TeoriaObjetos2
Page 235: UML&TeoriaObjetos2

Arquitectura del Sub Sistema de Admisión

Page 236: UML&TeoriaObjetos2
Page 237: UML&TeoriaObjetos2

Capas del Sub sistema de Admisión

• La arquitectura del Subsistema de Admisión, como la de todos los miembros de SIGEAC, se ha basado en esta propuesta a fin de obtener un producto escalable, de fácil mantenimiento y seguro; separando así las lógicas destinadas a la presentación, reglas del negocio y datos.

• Capa Presentación: Expone una interfaz permitiendo al usuario u otro módulo externo interactuar con el subsistema.

• Capa Lógica del Negocio: Reúne las reglas propias del negocio. Además, contiene la lógica que le permite atender los requerimientos de servicios de otros subsistemas.

• Capa Datos: Permite consumir y modificar la información de la base de datos. También permite consumir información expuesta por otros subsistemas.

• Además, el subsistema de Admisión contará con una serie de capas de apoyo, las mismas que se describen a continuación:

• Capa de Seguridad: Brinda los mecanismos para garantizar la seguridad de la aplicación. • Capa de Estructura de Datos: Brinda las estructuras que permiten el transporte de los datos a

través de las diferentes capas de la solución. • Capa de Administración de Parámetros: Permite la configuración de los parámetros utilizados por la

aplicación. • Capa de Administración de Excepciones: Permite registrar las excepciones y mensajes de auditoría

de la aplicación en un archivo de Log. • Capa de Encriptación: Brinda los mecanismos que garantizan la confidencialidad de la información

sensitiva de la aplicación.

Page 238: UML&TeoriaObjetos2
Page 239: UML&TeoriaObjetos2

Subsistema de programación de actividades

• Objetivo General – Desarrollar un producto software que sirva de soporte y apoyo para la

programación de actividades académicas, extraacadémicas o extracurriculares y administrativas en una institución de educación básica (inicial, primaria y secundaria) y superior (técnico y universitario).

• Objetivos Específicos – Aperturar períodos académicos en la institución educativa; indicando las fechas de duración del período. – Establecer los días no laborables que van a haber a lo largo del período académico. – Programar productos de estudio y ciclos académicos que van a estar vigentes a lo largo del período

académico. – Programar los cursos o asignaturas que se van a dictar a lo largo del período académico. – Programar las actividades que se van a desarrollar durante los procesos de admisión y matrícula por cada

período académico. – Programar las evaluaciones que van a rendir los alumnos a lo largo de un período académico. – Programar el calendario de actividades, es decir, las actividades que se van a desarrollar a lo largo del

período académico. – Integrarse con los subsistemas de Admisión, Asistencia, Matrícula y Administración de Notas; brindándoles

servicios que muestre información ofrecida por el subsistema de Programación de Actividades.

Page 240: UML&TeoriaObjetos2
Page 241: UML&TeoriaObjetos2
Page 242: UML&TeoriaObjetos2
Page 243: UML&TeoriaObjetos2

Componentes del Sistema• Web: Componente que permite la comunicación entre el subsistema y el usuario final. En este componente se exponen

las funcionalidades del subsistema a través de páginas Web. • ModelAdmision: Componente que brinda las estructuras de información que facilite el transporte de la data entre las

distintas capas. • BLLAdmision: Componente que contiene la lógica del negocio para atender cada requerimiento al subsistema, se trate de

usuarios o subsistemas externos. • WebServices: Componente que permite exponer los servicios del Subsistema de Admisión a través de la interfaz

WS_Admision. • DALFactory: Componente que selecciona en tiempo de ejecución el componente de acceso a datos configurado (DAL)

para que se conecte a la fuente de datos. • ADALAdmision: Componente que permite abstraer el acceso a los datos de manera que si se requiere cambiar la fuente

de datos sólo se necesite cambiar el componente SqlServerDAL para especializarlo a dicha fuente. • AS_Admin: Componente conocido como Agente de Servicios que permite consumir los servicios expuestos por otros

subsistemas. • SQLServerDAL: Componente que contiene la lógica de acceso a la base de datos de Admisión (BD_Admision). Este

componente ha sido desarrollado para interactuar con una base de datos en Microsoft SQL Server 2000. • OracleServerDAL: Componente que contiene la lógica de acceso a la base de datos de Admisión implementada en

Oracle. Este componente no ha sido desarrollado en la presente versión del producto. • Microsoft Data Access Application Block: Componente distribuído por Microsoft que implementa un patrón de acceso a

datos, cuyo uso permite reutilizar código y realizar un fácil mantenimiento. • Enterprise Library Cryptography Application Block: Componente con bloques de código para realizar la encriptación de

información confidencial. • ADMParams: Componente que permite la administración de parámetros y mensajes de Admisión. • LogManager: Componente que permite la administración de excepciones y auditoría del subsistema.

Page 244: UML&TeoriaObjetos2
Page 245: UML&TeoriaObjetos2
Page 246: UML&TeoriaObjetos2