UML&TeoriaObjetos.ppt

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

Transcript of UML&TeoriaObjetos.ppt

Page 1: UML&TeoriaObjetos.ppt

Lenguaje de Modelamiento Lenguaje de Modelamiento UnificadoUnificado

Ing. Luis Zuloaga Rotta

Page 2: UML&TeoriaObjetos.ppt
Page 3: UML&TeoriaObjetos.ppt

… … 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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt
Page 7: UML&TeoriaObjetos.ppt
Page 8: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt
Page 11: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

Fases del RUP

Page 16: UML&TeoriaObjetos.ppt

Bibliografía

Page 17: UML&TeoriaObjetos.ppt

Teoría de Objetos

Page 18: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt
Page 22: UML&TeoriaObjetos.ppt

• 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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

ObjetosObjeto Identidad Estados Comportamiento

Venta Nro 2345601 EmitidaPagadaAnulada

CrearModificarAñadir productoPagarAnular

Alumno Cod 1998234 No matriculadoMatriculadoRetiradoEgresado

MatriculaRetiroEgreso

Cita medica Nro 234516 EmitidaPagadaAtendidaSuspendida

CrearPagarAtenderSuspender

Contribuyente RUC 201345678965 HabidoNo habido

CrearSancionarDar bajaClasificar

Page 27: UML&TeoriaObjetos.ppt

Tipos de Objetos

Concretos: Persona-Carro-PC Roles: Doctor-Propietario-Maestro Relacional: Sociedad-Hijo-Matrimonio Eventos: Venta-Compra-Arribo Exponibles: Icono-Window-Imagen-Menú

Page 28: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

• 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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

Propiedades de un objeto• Abstracción y clasificación• Encapsulamiento• Herencia• Agregación y composición• Poliformismo o polimorfismo

Page 37: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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

Page 41: UML&TeoriaObjetos.ppt

• 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&TeoriaObjetos.ppt

– ( - ) 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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

CRIATURA

PEZ

MAMIFERO

AVE

PERSONA

HOMBRE MUJER

Jerarquía y Herencia

tipopesohabitat

periodo_gestacion

nombrefecha_nacimientoorigen

esposa esposo

crear( )esperanza_vida( )

Page 45: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

FIGURA

CIRCULO CUADRILATERO TRIANGULO

RECTANGULOTRAPECIO

PERSONA

PROFESOR INVESTIGADOR

PROF_UNIVERSITARIO

Herencia Simple Herencia Múltiple

Page 47: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

Estructura de objetos

compuestosvar 1: obj1var 2: obj2

obj1 obj2

Objetocompuesto

var 1: clientevar 2: articulo

clientearticulo

Ordencompra

var 1: clientevar 2: articulo

articulo

Ordencompra

Page 51: UML&TeoriaObjetos.ppt

Agregación

Page 52: UML&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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.

TransporteAvanzar

Frenar TransporteAvanzar

Frenar

TransporteAvanzar

Frenar

TransporteAvanzar

Frenar

Page 54: UML&TeoriaObjetos.ppt

Diagrama de Casos de Uso

Page 55: UML&TeoriaObjetos.ppt

• 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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

• 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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

Realizar cobro de factura

Realizar venta Realizar cobro

con Tarjeta CréditoVendedor

(actor primario)Banco(actor secundario)

Sistema

incluye

extiende

Page 60: UML&TeoriaObjetos.ppt

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

Page 61: UML&TeoriaObjetos.ppt

• 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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt

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&TeoriaObjetos.ppt
Page 76: UML&TeoriaObjetos.ppt

Caso de Uso: Realizar PedidoActor primario: vendedor

“ Cuando se recibe un pedido, el vendedor comprueba si para cada artículo solicitado existen los stocks suficientes. Si la respuesta es afirmativa, asigna los artículos al pedido. Si esta asignación reduce el stock disponible de un producto por debajo del nivel de reposición (reorden), el vendedor ordena su reposición; mientras se hace esto, se verifica que el pago sea correcto. Si el pago es correcto y hay artículos suficientes en stock, se despacha el pedido. Si el pago es correcto pero no hay stock suficiente, se deja en espera el pedido. Si el pago no es correcto, se anula el pedido ”.

Especificación corta de Caso de Uso

Page 77: UML&TeoriaObjetos.ppt
Page 78: UML&TeoriaObjetos.ppt
Page 79: UML&TeoriaObjetos.ppt
Page 80: UML&TeoriaObjetos.ppt
Page 81: UML&TeoriaObjetos.ppt

Diagrama de Secuencia

Page 82: UML&TeoriaObjetos.ppt

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 83: UML&TeoriaObjetos.ppt

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 84: UML&TeoriaObjetos.ppt

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 85: UML&TeoriaObjetos.ppt

SD mensajes

mensaje(retorno)

mensaje(parametros)

retorne:=mensaje(parametros)

Origen Destino

mensaje(retorno)

mensaje(parametros)

retorne:=mensaje(parametros)

Page 86: UML&TeoriaObjetos.ppt

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 87: UML&TeoriaObjetos.ppt

SD self

recursion

mensaje self

origen

recursion

mensaje self

Page 88: UML&TeoriaObjetos.ppt

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 89: UML&TeoriaObjetos.ppt

SD padre e hijo

borrar

crear

Padre

Hijo

borrar

crear

Page 90: UML&TeoriaObjetos.ppt

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 91: UML&TeoriaObjetos.ppt
Page 92: UML&TeoriaObjetos.ppt

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 93: UML&TeoriaObjetos.ppt

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 94: UML&TeoriaObjetos.ppt

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 95: UML&TeoriaObjetos.ppt

Fragmento que combina un loop (opt)

Page 96: UML&TeoriaObjetos.ppt

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 97: UML&TeoriaObjetos.ppt

Fragmento LOOP

Page 98: UML&TeoriaObjetos.ppt

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 99: UML&TeoriaObjetos.ppt
Page 100: UML&TeoriaObjetos.ppt

• 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 101: UML&TeoriaObjetos.ppt
Page 102: UML&TeoriaObjetos.ppt
Page 103: UML&TeoriaObjetos.ppt

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 104: UML&TeoriaObjetos.ppt
Page 105: UML&TeoriaObjetos.ppt

Diagrama de Interacción General

Page 106: UML&TeoriaObjetos.ppt

: 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 107: UML&TeoriaObjetos.ppt

Diagrama de Actividad

Page 108: UML&TeoriaObjetos.ppt

• 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 109: UML&TeoriaObjetos.ppt

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 110: UML&TeoriaObjetos.ppt

• 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 111: UML&TeoriaObjetos.ppt
Page 112: UML&TeoriaObjetos.ppt

• 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 113: UML&TeoriaObjetos.ppt

• 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 114: UML&TeoriaObjetos.ppt

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

Page 115: UML&TeoriaObjetos.ppt

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 116: UML&TeoriaObjetos.ppt

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 117: UML&TeoriaObjetos.ppt
Page 118: UML&TeoriaObjetos.ppt

Diagrama de Paquetes

Page 119: UML&TeoriaObjetos.ppt

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 120: UML&TeoriaObjetos.ppt

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 121: UML&TeoriaObjetos.ppt

Stma Inf. Gestión Hospitalario

ATENCION MEDICA

LABORATORIO CITAS

PROGRAMACION

CAJA

Page 122: UML&TeoriaObjetos.ppt

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 123: UML&TeoriaObjetos.ppt

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 124: UML&TeoriaObjetos.ppt

Diagrama de Clases

Page 125: UML&TeoriaObjetos.ppt

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 126: UML&TeoriaObjetos.ppt

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 127: UML&TeoriaObjetos.ppt

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

Page 128: UML&TeoriaObjetos.ppt
Page 129: UML&TeoriaObjetos.ppt

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 130: UML&TeoriaObjetos.ppt

ALUMNOALUMNODNI : char[10]DNI : char[10]nombre : char[50]nombre : char[50]fecha_nacimiento : datefecha_nacimiento : datenumero_expediente : intnumero_expediente : intcredito_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 131: UML&TeoriaObjetos.ppt

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 132: UML&TeoriaObjetos.ppt

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 133: UML&TeoriaObjetos.ppt

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 134: UML&TeoriaObjetos.ppt

Implementación de una Clase en Java

Page 135: UML&TeoriaObjetos.ppt

• 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 136: UML&TeoriaObjetos.ppt

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 137: UML&TeoriaObjetos.ppt

• 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"

* muchos0..* cero a muchos1..* uno a muchos

Multiplicidad de una Asociación

Empresa Personaejecutivoejecutivo

obreroobreroempleadorempleador

**1

0..1

Page 138: UML&TeoriaObjetos.ppt

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 139: UML&TeoriaObjetos.ppt

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 140: UML&TeoriaObjetos.ppt

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 141: UML&TeoriaObjetos.ppt

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 142: UML&TeoriaObjetos.ppt

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 143: UML&TeoriaObjetos.ppt

• 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 01Atributo 02Atributo 02

Operacion 1 ( )Operacion 1 ( )Operacion 2 ( )Operacion 2 ( )

ItemItem

Clase Parametrizada

Page 144: UML&TeoriaObjetos.ppt

• 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 145: UML&TeoriaObjetos.ppt

• 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 146: UML&TeoriaObjetos.ppt

• 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 147: UML&TeoriaObjetos.ppt

• 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 01Atributo 02Atributo 02

Operacion 1 ( )Operacion 1 ( )Operacion 2 ( )Operacion 2 ( )

ItemItem

Clase UtilidadClase Utilidad

Operacion 01 ( )Operacion 02 ( )

Item

Metaclase

Page 148: UML&TeoriaObjetos.ppt

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 149: UML&TeoriaObjetos.ppt

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 150: UML&TeoriaObjetos.ppt

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 151: UML&TeoriaObjetos.ppt

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 152: UML&TeoriaObjetos.ppt

Ejemplo de sobrecargaEmpleado

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 153: UML&TeoriaObjetos.ppt

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 154: UML&TeoriaObjetos.ppt

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 155: UML&TeoriaObjetos.ppt

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 156: UML&TeoriaObjetos.ppt

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 157: UML&TeoriaObjetos.ppt

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 158: UML&TeoriaObjetos.ppt

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 159: UML&TeoriaObjetos.ppt

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 160: UML&TeoriaObjetos.ppt

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 161: UML&TeoriaObjetos.ppt

• 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 162: UML&TeoriaObjetos.ppt

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 163: UML&TeoriaObjetos.ppt

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

TemaTemaNombreNombreRealiza >Realiza >

Page 164: UML&TeoriaObjetos.ppt

• 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 165: UML&TeoriaObjetos.ppt

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 166: UML&TeoriaObjetos.ppt

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 167: UML&TeoriaObjetos.ppt

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 ()cl iente ()

: 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 168: UML&TeoriaObjetos.ppt

• 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*1derechoderechoId usuarioId usuario

Dirección de navegavilidad

…. Navegabilidad

Page 169: UML&TeoriaObjetos.ppt

• 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 170: UML&TeoriaObjetos.ppt

• 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.

PERSONAPERSONAnombrenombre

padre

hijo 1..*

2PERSONAPERSONAnombrenombre

padre

hijo 1

2id persona

Page 171: UML&TeoriaObjetos.ppt
Page 172: UML&TeoriaObjetos.ppt
Page 173: UML&TeoriaObjetos.ppt
Page 174: UML&TeoriaObjetos.ppt

Diagrama de Transición de Estados

Page 175: UML&TeoriaObjetos.ppt

• 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 176: UML&TeoriaObjetos.ppt

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

periodoAcadseccionnumVacantnumInscritestadoadicionar( )cerrar( )

periodoAcad = 2011- Iseccion = AnumVacant = 30 numInscrit = 24estado = abiertoadicionar( )cerrar( )

adicionar( )cerrar( )

Page 177: UML&TeoriaObjetos.ppt

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 178: UML&TeoriaObjetos.ppt

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 179: UML&TeoriaObjetos.ppt

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 180: UML&TeoriaObjetos.ppt

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

CEv2

Super Estado

Sub Estado

Page 181: UML&TeoriaObjetos.ppt

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 182: UML&TeoriaObjetos.ppt

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 183: UML&TeoriaObjetos.ppt

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 184: UML&TeoriaObjetos.ppt

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 185: UML&TeoriaObjetos.ppt

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 186: UML&TeoriaObjetos.ppt

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 187: UML&TeoriaObjetos.ppt

CREADOdo: 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 188: UML&TeoriaObjetos.ppt

Diagrama de Estados

para los objetos de la Clase EJEMPLAR

EJEMPLAREJEMPLAR

Codigo : integerCodigo : integerCantidad : integerCantidad : integerEstado : 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 189: UML&TeoriaObjetos.ppt
Page 190: UML&TeoriaObjetos.ppt

Diagrama de Componentes

Page 191: UML&TeoriaObjetos.ppt

• 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 192: UML&TeoriaObjetos.ppt

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 193: UML&TeoriaObjetos.ppt

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

Page 194: UML&TeoriaObjetos.ppt
Page 195: UML&TeoriaObjetos.ppt
Page 196: UML&TeoriaObjetos.ppt
Page 197: UML&TeoriaObjetos.ppt
Page 198: UML&TeoriaObjetos.ppt
Page 199: UML&TeoriaObjetos.ppt
Page 200: UML&TeoriaObjetos.ppt

Diagrama de Despliegue

Page 201: UML&TeoriaObjetos.ppt

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 202: UML&TeoriaObjetos.ppt

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 203: UML&TeoriaObjetos.ppt

• 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 204: UML&TeoriaObjetos.ppt
Page 205: UML&TeoriaObjetos.ppt

Componentes y Nodos

Page 206: UML&TeoriaObjetos.ppt
Page 207: UML&TeoriaObjetos.ppt
Page 208: UML&TeoriaObjetos.ppt

Otros Diagramas ….

Page 209: UML&TeoriaObjetos.ppt
Page 210: UML&TeoriaObjetos.ppt
Page 211: UML&TeoriaObjetos.ppt
Page 212: UML&TeoriaObjetos.ppt
Page 213: UML&TeoriaObjetos.ppt
Page 214: UML&TeoriaObjetos.ppt

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 215: UML&TeoriaObjetos.ppt

Módulos integrantes de SIGEAC

Page 216: UML&TeoriaObjetos.ppt
Page 217: UML&TeoriaObjetos.ppt
Page 218: UML&TeoriaObjetos.ppt
Page 219: UML&TeoriaObjetos.ppt
Page 220: UML&TeoriaObjetos.ppt
Page 221: UML&TeoriaObjetos.ppt
Page 222: UML&TeoriaObjetos.ppt
Page 223: UML&TeoriaObjetos.ppt
Page 224: UML&TeoriaObjetos.ppt
Page 225: UML&TeoriaObjetos.ppt

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 226: UML&TeoriaObjetos.ppt

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

Page 227: UML&TeoriaObjetos.ppt
Page 228: UML&TeoriaObjetos.ppt

Arquitectura del Sub Sistema de Admisión

Page 229: UML&TeoriaObjetos.ppt
Page 230: UML&TeoriaObjetos.ppt

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 231: UML&TeoriaObjetos.ppt
Page 232: UML&TeoriaObjetos.ppt

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 233: UML&TeoriaObjetos.ppt
Page 234: UML&TeoriaObjetos.ppt
Page 235: UML&TeoriaObjetos.ppt
Page 236: UML&TeoriaObjetos.ppt

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 237: UML&TeoriaObjetos.ppt
Page 238: UML&TeoriaObjetos.ppt
Page 239: UML&TeoriaObjetos.ppt