Modelos Oo Uml1

UNIDAD 1 SIA II
ANALISIS ORIENTADO A OBJETOS - MODELOS

CONCEPTUAL SECUENCIA ESTADOS - COLABORACION
Modelo conceptual
Un modelo conceptual explica los conceptos ms significativos en un dominio del problema, identificando los
atributos y las asociaciones, y es la herramienta ms importante del anlisis orientado a objetos. Los casos de
uso son una importante herramienta para el anlisis de requerimientos, pero realmente no estn orientados a
objetos. Un modelo conceptual representa cosas del mundo real, no componentes del software. En UML se
representa mediante un grupo de diagramas de estructura esttica donde no se define ninguna operacin. En
estos diagramas se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de
conceptos (atributos). La siguiente figura muestra un modelo conceptual parcial del dominio de la tienda y las
ventas.
Un modelo conceptual es una descripcin del dominio de un problema real, no es una descripcin del diseo
del software. Debido a esto, no es conveniente aqu incluir elementos como ventanas o bases de datos.
En el dominio real de comprar productos en una tienda usando una terminal de punto de venta (TPDV),
intervienen tres conceptos principales: tienda, TPDV y una venta.
Por lo general es mejor exagerar un poco y especificar un modelo conceptual con muchos conceptos. Esto
debido a que es frecuente omitir conceptos durante el anlisis, y al descubrirlos ms tarde, es ms difcil
UNIDAD 1 SIA II
incorporarlos.
UNIDAD 1 SIA II
La siguiente lista muestra un conjunto de conceptos idneos para ser incluidos en el modelo conceptual.
Categora del concepto
Objetos fsicos o tangibles
Especificaciones, diseo o descripciones de cosas
Lugares
Transacciones
Lnea o rengln de un elemento de transacciones
Rol de las personas
Contenedores de otras cosas
Cosas dentro de un contenedor
Otros sistemas de cmputo o electromecnicos externos al sistema
Conceptos de nombres abstractos
Organizaciones
Eventos
Procesos (A menudo no estn representados como conceptos, pero
pueden estarlo)
Reglas y polticas
Catlogos
Registros de finanzas, de trabajo, de contratos, de asuntos legales
Instrumentos y servicios financieros
Manuales y libros
Ejemplos
TDPV, Dado
EspecicacindeProducto, ReglasdeJuego
Tienda, MesadeJuego
Venta, Pago, Reservacion, Apuesta
VentasLineadeProducto
Cajero, Gerente, Jugador
Tienda, Cesto, Biblioteca
Producto, Libro
SistemaAutorizacionTarjetasdeCredito
Hambre, Suerte
DepartamentodeVentas, LineaAerea
Venta, Robo, Junta, Vuelo, Accidente,
RodarDados
VentaUnProducto, ReservacionAsiento
PoliticadeReembolso,
PoliticadeCancelaciones
CatalogodeProductos, CatalogodeLibros
Recibo, Mayor, ContratodeEmpleo
LineadeCredito, Existencia
ManualdePersonal, ManualdeReparaciones
Otra forma simple de obtener conceptos, es identificarlos de un anlisis semntico de las descripciones
textuales referentes al dominio del problema. Para hacer esto, los casos de uso expandidos proveen una buena
fuente de conceptos. Por ejemplo, el caso de uso Comprar productos:
Accin de los actores
1. Este caso de uso comienza cuando un Cliente
llega a una caja de TPV con los productos que
desea comprar.
2. El Cajero registra el cdigo de barras de cada
producto. Si hay ms de un producto, el Cajero
puede introducir tambin la cantidad.
Respuesta del sistema
3. Determina el precio del producto y a la transaccin de

venta le agrega la informacin sobre el producto. Se muestra
la descripcin y el precio del producto actual.
A partir de la lista de categoras de conceptos podemos generar un conjunto de conceptos para nuestro
problema del punto de venta:
TPV
Producto
Tienda
Venta
Pago
CatalogodeProductos
EspecificaciondeProducto
VentasLineadeProductos
Cajero
Cliente
Gerente
Se debera incluir la boleta que imprime el punto de venta? Esta boleta es un informe del sistema, y dado que
toda su informacin proviene de otros objetos, no es necesario incluirlo. Sin embargo, es posible que en una
UNIDAD 1 SIA II
etapa posterior (por ejemplo cuando se implemente devolver productos) se justifique su inclusin.
Por tanto, el modelo conceptual inicial del sistema de punto de venta (sin incluir atributos ni asociaciones)
sera:
Falta ahora agregar los atributos relevantes de cada concepto, y las asociaciones.
Atributos
Un atributo es un valor lgico de un dato de un objeto. Es preferible que los atributos sean simples. Entre los
tipos de atributos ms comunes se encuentran: booleanos (o lgicos), fechas, nmeros, texto y horas. Algunos
tipos comunes son: direccin, color, telfono, RUT, cdigo de barras, cdigo postal.
Los atributos no deberan usarse para relacionar conceptos en el modelo conceptual, solamente para describir
estos conceptos. Una de las violaciones ms comunes a esta regla consiste en agregar atributos como llaves
forneas. Por ejemplo:
Uno de los errores ms frecuentes al crear modelos conceptuales, es representar algo como un atributo,
cuando debera haber sido un concepto aparte. Una regla prctica para evitar esto es: si en el mundo real no
consideramos algn concepto X como nmero o texto, probablemente X sea un concepto y no un atributo.
Por ejemplo, en un dominio de reservaciones en lneas areas, el Destino debera ser un atributo de Vuelo u
UNIDAD 1 SIA II
otro concepto?
En el mundo real, un aeropuerto de destino no se considera nmero ni texto, por lo que debera ser un
concepto.
Sugerencia: En caso de duda, convierta el atributo en un concepto independiente.
Otro error comn, es incluir atributos con multiplicidad mayor que 1. Por ejemplo:
Asociaciones
Una asociacin es una relacin entre dos conceptos que indica alguna conexin significativa entre ellos. Las
asociaciones tiles a determinar, suelen incluir el conocimiento de una relacin que ha de preservarse por
algn tiempo: puede tratarse de milisegundos o de aos (segn el contexto). Por ejemplo, debemos recordar
cuales instancias de VentasLineadeProducto estn asociadas a Venta? Claro que si, porque de lo contrario no
sera posible reconstruir la venta, imprimir la boleta ni calcular el total de la venta. Por otra parte,
necesitamos recordar una relacin entre una Venta y Gerente? Probablemente no es indispensable ni til
dentro del contexto de nuestros requerimientos.
Una asociacin se representa como una lnea entre conceptos, con el nombre de la asociacin. La asociacin
es intrnsecamente bidireccional, es un posible nexo lgico entre los objetos. Este nexo es totalmente
abstracto, no es una afirmacin sobre las conexiones entre las entidades del software. Los extremos de una
asociacin pueden contener una expresin de multiplicidad que indica la relacin numrica entre las
instancias de los conceptos. Opcionalmente se puede poner una flecha que indique la direccin en que debe
UNIDAD 1 SIA II
leerse el nombre de la asociacin (no indica nada ms, es slo una ayuda para leer el diagrama).
Para identificar las asociaciones ms comunes, la siguiente lista es de gran ayuda.

Categora de la asociacin
A es una parte fsica de B
A es una parte lgica de B
A est fsicamente contenido en B
A est contenido lgicamente en B
A es una descripcin de B
A es un elemento de lnea (o rengln) en una transaccin o reporte B
A se conoce/introduce/registra/presenta/captura en B
A es miembro de B
A es una unidad organizacional de B
A usa o dirige a B
A se comunica con B
A se relaciona con una transaccin B
A es una transaccin relacionada con otra transaccin B
A es propiedad de B
Ejemplos
Caja-TPDV
VentasLneadeProducto-Venta
TPDV-Tienda, Producto-Estante
DescripcindeProducto-Catlogo
DescripcindeProducto-Producto
VentasLneadeProducto-Venta
Venta-TPDV
Cajero-Tienda
Departamento-Tienda
Cajero-TPDV
Cliente-Cajero
Pago-Venta
Pago-Venta
TPDV-Tienda
Las asociaciones ms importantes son las siguientes:

A es una parte fsica o lgica de B
A est fsica o lgicamente contenido en B
A est registrado en B
Las asociaciones son importantes, pero no se debe dedicar tiempo excesivo a ellas. Es ms importante
identificar los conceptos que las asociaciones. Muchas asociaciones tienden a confundir el modelo
conceptual, en vez de aclararlo. Se pueden incorporar las que se indican en los casos de uso, y las que se
consideren necesarias para un adecuado entendimiento del problema.
La multiplicidad define cuntas instancias de un tipo A pueden asociarse a una instancia del tipo B en
determinado momento. Las expresiones de multiplicidad son las siguientes:
*
1..*
1..40
5
2,4,6
cero o ms, muchos

uno o ms
de uno a cuarenta
exactamente cinco
exactamente dos, cuatro o seis
Por ejemplo:
UNIDAD 1 SIA II
Los nombres de las asociaciones deben ser lo ms claros posibles, y deben permitir leer y entender fcilmente
las relaciones entre conceptos.
En sntesis, para construir un modelo conceptual se deben aplicar los siguientes pasos:
1. Liste los conceptos idneos usando la lista de categoras de conceptos.
2. Dibjelos en un modelo conceptual.
3. Incorpore las asociaciones necesarias para registrar las relaciones ms importantes (las que se deben
recordar).
4. Agregue los atributos necesarios para cumplir con las necesidades de informacin.
El modelo conceptual de la siguiente figura muestra un conjunto de conceptos, asociaciones y atributos
idneos para la aplicacin de punto de venta.
UNIDAD 1 SIA II
Diagramas de secuencia
El diagrama de secuencia de un sistema muestra grficamente los eventos que originan los actores y que
impactan al sistema. La creacin de los diagramas de secuencia forma parte de la investigacin para conocer
el sistema, por lo que es parte del anlisis del mismo. La creacin de los diagramas de secuencia depende de
la formulacin de los casos de uso. Los casos de uso indican cmo los actores interactan con el sistema.
Durante la operacin del sistema, los actores generan eventos, solicitando alguna operacin a cambio. Por
ejemplo, cuando un cajero ingresa un cdigo de barras de un artculo, est pidiendo al sistema de TPV que
registre esa compra. Con este evento se inicia una operacin en el sistema.
Antes de iniciar el diseo lgico de la aplicacin de software, es necesario investigar y definir su
comportamiento como una "caja negra". Vamos a estudiar el comportamiento del sistema, desde la
perspectiva de qu es lo que hace, y no de cmo lo hace.
Def.: El diagrama de secuencia de un sistema es una representacin que muestra, en determinado escenario
de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. Lo
importante aqu son los eventos originados por los actores, que trascienden las fronteras del sistema. Los
sistemas mismos son cajas negras.
Recordemos el caso de uso Comprar productos:
Caso de
Comprar productos
uso:
Actores:Cliente, cajero
Tipo: Primario
Descrip Un Cliente llega a la caja registradora con los artculos que va a comprar. El Cajero registra el cdigo de
cin: cada producto. Si hay ms de una unidad de un producto, puede registrar la cantidad. El sistema determina
el precio del producto, y agrega la informacin a la transaccin actual de venta. Se muestra la descripcin
del producto y el precio. Esto se repite para todos los artculos. Al final, el cajero cobra el importe. Al
terminar la operacin, el Cliente se marcha con los productos.
El siguiente diagrama de secuencia describe el caso de uso Comprar productos. En estos diagramas el tiempo
avanza hacia abajo, y el orden de los eventos debera seguir el orden indicado en el caso de uso
correspondiente.
UNIDAD 1 SIA II
En el diagrama anterior, se indica que el Cajero es el nico actor, y que se generan los eventos del sistema:
pasarProducto, terminarVenta y efectuarPago.
Def.: Un evento es un hecho externo de entrada, que un actor produce en el sistema. Cada evento da origen a
una operacin del sistema como respuesta. En el ejemplo anterior, se tienen tres eventos: pasarProducto,
terminarVenta y efectuarPago. Los eventos y las operaciones del sistema tienen el mismo nombre, por
ejemplo, cuando el cajero genera un evento de pasarProducto, causa que en el sistema se ejecute la operacin
pasarProducto.
Una vez que se identifican los eventos, se "registran" en la entidad que corresponda, como operaciones. Por
ejemplo:
En esta notacin UML los parmetros son opcionales. Es conveniente que los nombres de los eventos
comiencen con un verbo, pues estn orientados a comandos del sistema.
Dado que los eventos son hechos externos de entrada, es necesario definir la frontera del sistema. Por lo
general la frontera ser el sistema de software (puede tambin incluir el hardware). Es en este contexto que
decimos que un evento del sistema es un hecho externo que estimula directamente al software.
Observe que la representacin del tipo Sistema es muy diferente a lo que se expres en el modelo conceptual.
Los elementos del modelo conceptual representan conceptos del mundo real, en cambio, el tipo Sistema es un
concepto artificial. Adems muestra las operaciones que realiza. Esto se debe a que, a diferencia del modelo
conceptual, que representa informacin esttica, estamos ahora describiendo el comportamiento del sistema,
que es informacin dinmica.
En el caso de uso anterior (Comprar productos) lo primero que se hace es determinar los actores que
interactan directamente con el sistema de software. En este caso, el cliente interacta con el cajero, pero no
directamente con el software TPV. Es el cajero quien interacta con el software. Por tanto, el cliente no genera
eventos en el sistema.
A veces es conveniente mostrar algunos fragmentos del texto del caso de uso dentro del diagrama de
secuencia. Por ejemplo:
UNIDAD 1 SIA II
10
UNIDAD 1 SIA II
11
Contratos para las operaciones

Para ayudar a explicar lo que una operacin (o evento del sistema) se propone hacer, es conveniente usar
contratos. Un contrato de operacin del sistema describe los cambios de estado del sistema total cuando se
llama a una de sus operaciones.
Por ejemplo, para la operacin pasarProducto se puede definir el siguiente contrato:
Contrato
Nombre:
pasarProducto(cdigo:nmero, cantidad:entero)
Responsabil Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar la descripcin y el precio
idades:
del producto.
Tipo:
Sistema.
Referencias Funciones del sistema: R1.1, R1.3, R1.9.
cruzadas: Casos de uso: Comprar productos.
Notas:
Utilizar acceso super-rpido a la base de datos.
Excepciones
Si el cdigo no es vlido, indicar que se cometi un error.
:
Precondicio
El sistema conoce el cdigo.
nes:
Postcondici Si se trata de una nueva venta, se crea una Venta (creacin de instancia).
ones:
Si se trata de una nueva venta, la nueva Venta fue asociada a TPV (asociacin formada).
Se cre una instancia de VentasLneadeProducto (creacin de instancia).
Se asoci una instancia de VentasLneadeProducto a la Venta (asociacin formada).
Se asign cantidad a VentasLneadeProducto.cantidad (modificacin de atributo).
Se asoci una instancia VentasLneadeProducto a la instancia EspecificacindeProducto, basado en la
correspondencia del cdigo (asociacin formada).
Algunas recomendaciones para la elaboracin de los contratos:
1. Identificar las operaciones a partir de los diagramas de secuencia.
2. Elaborar un contrato por cada operacin.
3. Redactar inicialmente la seccin de Responsabilidades. Luego se describe informalmente el propsito
de la operacin.
4. Se completa la seccin de Postcondiciones, describiendo en forma declarativa los cambios de estado
de los objetos en el modelo conceptual.
5. Para decribir las Postcondiciones utilice las siguiente categoras: creacin y eliminacin de instancias,
modificacin de los atributos, asociaciones formadas y canceladas.
Los contratos para terminarVenta, efectuarPago e inicio son los siguientes:
Contrato
Nombre:
terminarVenta( )
Responsabilidad
Resistrar que es el final de la captura de los productos de la venta y desplegar el total de la venta.
es:
Tipo:
Sistema.
Referencias
Funciones del sistema: R1.2.
cruzadas:
Casos de uso: Comprar productos.
Notas:
Excepciones:
Si no est realizndose una venta, indicar que se cometi un error.
Precondiciones: Se est realizando una venta.
Postcondiciones: Estableci Venta.estaTerminada en verdadero (modificacin de atributo).
UNIDAD 1 SIA II
Contrato
Nombre:
efectuarPago(monto:nmero)
Responsabilida
Registrar el pago, calcular el saldo, imprimir la boleta.
des:
Tipo:
Sistema.
Referencias
Funciones del sistema: R2.1.
cruzadas:
Casos de uso: Comprar productos.
Notas:
Excepciones: Si la venta no est concluida, indicar que se cometi un error.
Precondiciones
:
Postcondicione Se cre un Pago (creacin de instancia).
s:
Se asign a Pago.montoOfrecido el valor de monto (modificacin de atributo).
Se asoci el Pago a la Venta (relacin formada).
Se asoci la Venta a la Tienda para agregarla al registro histrico de las ventas terminadas
(relacin formada).
12
UNIDAD 1 SIA II
Otros diagramas de secuencia del sistema son los siguientes:
Pago con tarjeta de crdito
13
UNIDAD 1 SIA II
Pago con cheque
14
UNIDAD 1 SIA II
15
Diagramas de estado
Los diagramas de estado describen grficamente los eventos y los estados de los objetos. Los diagramas de
estado son tiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condicin de un
objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transicin es una relacin
entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.
En UML, los estados se representan mediante valos. Las transiciones se representan mediante flechas con el
nombre del evento respectivo. Se acostumbra poner un estado inicial (crculo negro). Por ejemplo:
Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren, sus transiciones, y
los estados que median entre estos eventos.
En particular, es til hacer diagramas de estado para describir la secuencia permitida de eventos en los casos
de uso. Por ejemplo, en el caso de uso comprarProductos no est permitido efectuar pagoTarjeta mientras no
haya ocurrido el evento terminarVenta.
UNIDAD 1 SIA II
16
Un diagrama de estado que describe los eventos globales del sistema y su secuencia en un caso de uso es un
diagrama de estado para casos de uso. Por ejemplo, una versin simplificada del diagrama de estados para el
caso de uso comprarProductos es el siguiente:
Una versin ms completa del diagrama anterior se muestra en la siguente figura:
El diagrama anterior aun no est completo, pues falta considerar algunos casos excepcionales, como por
UNIDAD 1 SIA II
17
ejemplo, si al rechazar una tarjeta de crdito o un cheque, el cliente decide pagar usando otro mtodo, por
ejemplo pagando en efectivo.
Una transicin puede tener una proteccin condicional, o prueba booleana, que permite pasar al siguiente
estado solemente si esta proteccin es vlida. Estas protecciones se colocan entre parntesis debajo de los
eventos (ver validacin del usuario al descolgar el auricular, en la siguiente figura). Tambin se pueden tener
sub-estados anidados.
UNIDAD 1 SIA II
18
Casos de uso reales

Los casos reales de uso representan un diseo concreto de cmo se va a realizar el caso, a partir de una
tecnologa particular. Por ejemplo, si se necesita una interfaz grfica de usuario, se deben incluir diagramas de
las ventanas requeridas. Los diagramas de ventanas de todos los casos de uso, as como el modelo de
navegacin de stas, constituye la versin "en papel" del primer prototipo del sistema. Para la creacin de los
casos de uso reales, se refinan los casos esenciales creados en la etapa de anlisis.
Diagramas de colaboracin
Los contratos muestran qu hacen las operaciones del sistema, pero no muestran cmo los objetos de software
van a cumplir con ellas. Los diagramas de interaccin (diagramas de secuencia o diagramas de colaboracin)
explican grficamente cmo los objetos interactan a travs de mensajes para realizar las tareas. Antes de
definir estos diagramas, hay que generar el modelo conceptual, los contratos de operacin y los casos de uso
reales (estos ltimos se generan a partir de los casos de uso definidos en el anlisis).
Los diagramas de colaboracin explican grficamente las interacciones entre las instancias del modelo
(objetos). Por ejemplo:
El punto de partida de las interacciones son las postcondiciones de los contratos de operacin. El siguiente
ejemplo muestra el diagrama de colaboracin de la operacin efectuarPago.
Los diagramas de interaccin constituyen una de las herramientas ms importantes para el anlisis y diseo
orientado a objetos. El tiempo y esfuerzo dedicado a la preparacin de stos, correponde a un porcentaje
considerable de la actividad total del proyecto.
UNIDAD 1 SIA II
19
Notacin: Para representar grficamente el hecho de que un mensaje devuelva un valor, se puede hacer de la
siguiente manera:
Notacin: Un objeto puede enviarse un mensaje a si mismo:
Tambin es posible indicar el nmero de veces (iteraciones) que un mensaje va a ser enviado. Por ejemplo, el
siguiente mtodo:
msg1() {
for i := 1 to 10 {
miB.mens2();
miC.mens3();
}
}
puede ser representado mediante el siguiente diagrama:
UNIDAD 1 SIA II
Notacin: El siguiente ejemplo muestra la forma de definir la secuencia de los mensajes dentro de un
diagrama de colaboracin.
Notacin: Es posible definir mensajes condicionales. Para esto, se define la condicin entre corchetes, y el
mensaje se enva solamente si la condicin es verdadera. Por ejemplo:
20
UNIDAD 1 SIA II
Notacin: Es posible definir trayectorias condicionales mutuamente excluyentes. Por ejemplo:
Notacin: Un multiobjeto, o conjunto de instancias (por ejemplo un arreglo en Java), se dibuja en forma de
pila. Por ejemplo
De esta forma, tambin podemos enviar mensajes a multiobjetos. Por ejemplo:
21
UNIDAD 1 SIA II
22
La siguiente figura muestra cmo enviar mensajes para crear una instancia de un objeto, y agregarla a un
multiobjeto.
Tambin es posible enviar mensajes a la clase y no a una instancia, con el fin de llamar a mtodos de la clase.
Por ejemplo:
Las herramientas utilizadas en las etapas anteriores se pueden resumir en la siguiente tabla:
Herramienta
Requerimientos
Casos de uso
Modelo conceptual
Diagramas de secuencia
Contratos
Diagramas de estado
Diagramas de colaboracin
Preguntas que responde

Cules son las necesidades o deseos del producto?
Cules son los procesos del dominio?
Cules son los conceptos, los trminos?
Cules son los eventos y las operaciones del sistema?
Qu hacen las operaciones del sistema?
Cules son los estados de los objetos en los eventos?
Cmo hacen los objetos para cumplir con las operaciones?
Un sistema orientado a objetos se compone de objetos que envan mensajes a otros objetos para que lleven a
cabo ciertas operaciones. Cada clase de objetos tiene ciertas responsabilidades, que son cumplidas a travs de
sus mtodos, y por la forma en que colabora con las otras clases de objetos.
Decisiones poco acertadas sobre la asignacin de responsabilidades de cada clase, dan origen a sistemas y
componentes frgiles y difciles de mantener, entender, reutilizar o extender.

Modelos Oo Uml1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelos Oo Uml1

Cargado por

Copyright:

Formatos disponibles

UNIDAD 1 SIA II

ANALISIS ORIENTADO A OBJETOS - MODELOS

Respuesta del sistema

3. Determina el precio del producto y a la transaccin de

Para identificar las asociaciones ms comunes, la siguiente lista es de gran ayuda.

Las asociaciones ms importantes son las siguientes:

cero o ms, muchos

Contratos para las operaciones

Pago con cheque

Una versin ms completa del diagrama anterior se muestra en la siguente figura:

Casos de uso reales

Notacin: Un objeto puede enviarse un mensaje a si mismo:

De esta forma, tambin podemos enviar mensajes a multiobjetos. Por ejemplo:

Preguntas que responde

También podría gustarte