Aoo Uml 08 10 SR PDF

Anlisis Orientado a
Objetos con UML

Elaborado por: Alan Caldern Castro
Universidad de Costa Rica
Preparadopor: Alan Caldern Castro (UCR)
Objetivos del curso
Al finalizar el curso el participante ser
capaz de:
Comprender y usar UML para hacer anlisis
orientado a objetos.
Elaborar especificaciones de sistemas de
software.
Usar con fluidez las facilidades
correspondientes de una herramienta apropiada.
Contenidos del curso
Generalidades de UML.
Caractersticas generales del modelo de proceso.
Modelo de Casos de Uso y objetos de frontera
(RUP).
Rastreabilidad entre casos de uso y
requerimientos.
El Modelo del Negocio (RUP):
El Modelo de Procesos Organizacionales (RUP).
El Modelo del Dominio (RUP y Larman).
El Modelo Relacional para la Persistencia de
Objetos.
Introduccin al UML
(Para qu sirve?)
El Unified Modeling Language o Lenguaje Unificado de
Modelaje sirve para:
Visualizar el diseo de sistemas: facilita la comunicacin entre
los desarrolladores y la toma de decisiones de diseo en forma
colaborativa.
Especificar el diseo de sistemas: permite crear descripciones
precisas de un sistema de software, que puedan ser fcilmente
comprendidas por todos los miembros de un equipo de
desarrollo.
Construir el diseo de sistemas: aunque no es un lenguaje de
programacin visual, es fcil generar programas a partir de las
especificaciones precisas que se pueden elaborar con UML.
Documentar el diseo de sistemas: Todas las decisiones pueden
quedar bien documentadas por medio de artefactos de UML.
Introduccin al UML
(En qu consiste?)
Es un lenguaje grfico elaborado para facilitar el modelaje
de sistemas de software.
Se compone de un conjunto amplio de bloques de
construccin (o primitivas semnticas) y un conjunto de
reglas para interrelacionarlos, que permiten modelar tanto
los aspectos estticos como los dinmicos de un sistema de
software.
Se compone de mecanismos de extensin (los estereotipos)
que permiten ampliar el conjunto de las primitivas semnticas
para modelar de manera ms precisa dominios de aplicacin
especficos.
Introduccin al UML
(Cules son sus antecedentes?)
Fue elaborado por los tres amigos: Rumbaugh, Booch y
Jacobson, patrocinados por la empresa Rational.
La OMT (Object Modeling Technique) de Rumbaugh aport
los modelos de objetos, los diagramas de estado transicin y
ciertas especializaciones orientadas a sistemas de
informacin de gran tamao.
El mtodo de Booch aport las primitivas semnticas
relevantes a nivel del diseo fsico de los sistemas.
El OOSE (Object Oriented Software Engineering) de
Jacobson aport el concepto de caso de uso til en el
modelaje de los requerimientos de un sistema.
La nueva versin (2.0) ha sido adoptada por Object
Managment Group y se denomina OMG UML.
Introduccin al UML
(Visin arquitectnica de los sistemas que propone el UML)
Los creadores de UML proponen que para la construccin de sistemas
complejos y crticos no basta una sola perspectiva. Son necesarias
cinco perspectivas.
Vista lgica
Vista de procesos
Vista de componentes
Vista de implantacin
Vista de casos de uso
Introduccin al UML
(La vista de casos de uso)
No indica cmo se organiza el sistema, pero ms bien lo que
debe hacer.
Abarca los requerimientos del sistema descritos en forma de
casos de uso, tal y como son vistos por los usuarios finales,
los analistas y los encargados de las pruebas.
Los aspectos estticos es especifican mediante diagramas de
casos de uso.
Los aspectos dinmicos se especifican mediante diagramas
de secuencias de eventos y diagramas de actividades
principalmente.
Introduccin al UML
(La vista de lgica)
Abarca las clases, interfaces y colaboraciones que forman el
vocabulario o marco conceptual del problema y su solucin.
Esta vista permite visualizar cmo se soporta la
funcionalidad del sistema, es decir los requerimientos.
Los aspectos estticos se especifican mediante los
diagramas de objetos y de instancias.
Los aspectos dinmicos se especifican mediante los
diagramas de secuencias de eventos, de colaboracin, de
estados y de actividades.
Introduccin al UML
(La vista de procesos)
Abarca los procesos e hilos que conforman los mecanismos de
sincronizacin y concurrencia del sistema modelado.
diagramas de objetos y de instancias, pero se hace nfasis
en los objetos activos.
diagramas de secuencias de eventos, de colaboracin, de
estados y de actividades, pero se hace nfasis en los
objetos activos.
Los objetos activos son los que representan a procesos e
hilos de un sistema.
Introduccin al UML
(La vista de componentes)
Abarca los archivos que se utilizan para construir el sistema,
as como los mdulos a que dan origen despus de la
compilacin y el linking.
Esta vista tambin permite la gestin de la configuracin del
sistema pues se pueden representar versiones de archivos y
mdulos y correlacionarlos con las versiones del sistema.
Los aspectos estticos se especifican por medio de los
diagramas de componentes.
Los aspectos dinmicos se pueden especificar mediante
diagramas de secuencias de eventos y colaboracin, pero
raramente se usan en este contexto.
Introduccin al UML
(La vista de implantacin)
Abarca la topologa del hardware sobre el cual se implanta el
sistema, as como la distribucin de componentes entre los
distintos nodos de la topologa del hardware.
diagramas de implantacin.
diagramas de secuencias de eventos, de colaboracin y de
actividades, aunque es poco usual que se usen en este
contexto.
Caractersticas generales
de un modelo de proceso
iterativo
Modelo de proceso del desarrollo
de software
Notacin de modelaje basada en Unified
Modeling Language (UML).
Iterativo e incremental.
Controlado por casos de uso.
Proceso orientado a la arquitectura.
Control de calidad mediante revisiones
tcnicas formales.
Caractersticas del modelo de
proceso de desarrollo de software
Modelado Orientado a Objetos.
Diseo Orientado a Componentes.
Herramientas a usar:
Alguna herramienta adecuada para el
diagramado de las vistas.
MS-WORD.
Plantillas y listas de chequeo disponibles.
Fase Preliminar del
Proceso de desarrollo
Al principio se hace un anlisis de
requerimientos del sistema que tpicamente
abarca aspectos del contexto,
identificacin de requerimientos
funcionales y no funcionales.
Con base en el documento se identifican
casos de uso (CU) y se hace una
especificacin preliminar no detallada.
Luego se inicia la primera iteracin.
Modelo de Proceso
Iterativo e Incremental
Las actividades de cada iteracin son:
Planeamiento.
Elaboracin de la Vista de Casos de Uso y los
objetos de frontera.
Elaboracin de casos de prueba.
Elaboracin del modelo detallado de clases de
anlisis segn se requiera.
Modelo de Proceso
Iterativo e Incremental
Actividades de cada iteracin (cont.):
Diseo detallado de objetos (orientado a
tecnologa especfica).
Programacin orientada a objetos.
Empaquetamiento de objetos en Componentes.
Verificaciones intercaladas.
Pruebas y depuracin.
Modelo de Proceso
Controlado por Casos de Uso
En cada planeamiento se hace lo siguiente:
Se agregan, modifican o eliminan casos de uso.
Se priorizan (o re-priorizan) los CU pendientes.
Se escogen unos CU para su especificacin.
Con base en el subconjunto de casos de uso
escogido, se realizarn todas las dems
actividades mencionadas.
Al final de cada iteracin, la funcionalidad
cubierta por los casos de uso escogidos
deber ser completamente operativa.
Documento Preliminar
El proceso en este curso arranca con un
anlisis de requerimientos parcial:
Requerimientos Funcionales.
Requerimientos no Funcionales, por ejemplo:
Requerimientos de Desempeo.
Requerimientos de Mantenibilidad y Reutilizacin.
Restricciones Tecnolgicas.
Otros.
Otras consideraciones del contexto organizacional.
Modelo de Casos de Uso (MCU)
1. Notacin bsica y vista preliminar
Casos de Uso y Actores
Un casode usorepresentaun proceso
de interaccinhumano-
sistema,relevanteparael negocioen el
queintervienenactoreshumanosu
otrossistemas.
Un actor puederepresentar a un
usuarioo a otrosistemacon el
queel sistemainteracta.
Casos de Uso y Actores
Un caso se caracteriza como:
un fragmento de funcionalidad del sistema
que proporciona al usuario un resultado
importante. Los casos de uso representan los
requisitos funcionales (Jacobson, Booch y
Rumbaugh).
Una secuencia o ciclo de interacciones finito
entre un sistema y uno o ms usuarios que
ofrece un resultado relevante para los usuarios
al participar en los procesos del negocio.
Relaciones tpicas
entre casos de uso
Un caso de uso X extiende a
otro Y:
Un caso de uso X extiende a otro Y: bajo
ciertas condiciones, el proceso de X se
puede ejecutar como parte de Y. Los
procesos de varios casos de uso que
extienden a Y pueden presentarse durante
su ejecucin.
Por ejemplo, en un caso de uso tpico de
mantenimiento de Expedientes Acadmicos,
el caso de uso principal que da entrada a
los casos tpicos es extendido por medio
operaciones tpicas.
<<extend>>
Y
X
Relaciones tpicas
entre casos de uso
Un caso de uso X incluye a otro
Y:
Un caso de uso X usa a otro Y: indica que la
ejecucin de X siempre incluir la ejecucin
de Y.
Por ejemplo cuando un usuario intenta entrar
al caso de uso de mantenimiento de
expedientes, primero debe pasar por el
procedimiento de autorizacin.
<<include>>
Y
X
Ejemplo de diagrama
de casos de uso
Casos de uso abstractos
y concretos
En los ejemplos anteriores, todos son casos
de uso concretos, es decir implementan un
fragmento de funcionalidad de un producto
de software especfico.
Un caso de uso abstracto est constituido
por una secuencia o ciclo de interacciones
genrica y por ende reutilizable.
Un caso de uso concreto puede heredar y
extender las interacciones de uno
abstracto.
Casos de uso abstractos
y concretos
En este caso Registrar
transaccin genrica est
constituido por una secuencia o
ciclo de interacciones que es
reutilizable a la hora de
especificar casos de uso
concretos como Registrar
factura.
La reutilizacin de casos es una
tcnica muy poderosa orientada
al desarrollo rpido y fiable de
software.
Registrar transaccin genrica
Registrar factura
Para qu sirven los
casos de uso?
En resumen, un caso de uso:
Describe una secuencia o ciclo finito de
interacciones entre actores y el sistema.
Provee al actor(es) algn resultado importante.
Describe un proceso importante para el negocio.
Implementa requerimientos funcionales del
sistema.
Identificacin de Casos de uso
Por medio de los actores
Identificar primero los actores relacionados
con el sistema o la organizacin.
Para cada actor identificar los procesos en que
participarn.
Por medio de los eventos
Identificar los eventos externos a los que el
sistema debe responder.
Relacionar dichos eventos con actores y luego
con casos de uso.
Identificacin de Casos de uso
A partir del anlisis del documento de
requerimientos:
Los casos de uso siempre proveen
requerimientos ms especficos que los que
aparecen en el documento de requerimientos.
Por tanto, no existe una relacin 1:1 entre
requerimientos funcionales y casos de uso, ms
bien lo normal es que sea n:m.
Nombres de casos de uso
y de actores
Los nombres de los casos de uso:
Deben representar procesos de interaccin, por lo que es
conveniente usar verbos en su forma infinitiva.
Tpicamente proveen operaciones sobre documentos u otro tipo
de objetos; en tal caso su nombre debe incluir sustantivos
(Registrar Compra, Editar Expediente, Obtener Documento
web).
Los nombres de los actores pueden representar:
Tipos de personas, cargos o funcionarios (Encargado, Jefe,
Digitador).
Algn sistema especfico con que el sistema objetivo
interactuar.
Una organizacin con la que la organizacin meta interactuar.
Ejemplificar la elaboracin de
un modelo de casos de uso
A continuacin un ejemplo:
Se discute un documento de anlisis de
requerimientos.
Se crea un modelo de casos de uso apropiado.
Paquetes de casos de uso
Es conveniente organizar jerrquicamente
los casos de uso porque:
En un sistema suficientemente complejo, puede
que se definan muchos casos de uso, lo cual
hara difcil la navegacin cuando se quiere
consultar o modificar las especificaciones.
Su agrupamiento puede ser el primer indicio
para la identificacin de subsistemas.
Su agrupamiento puede facilitar la divisin del
trabajo de su especificacin detallada en
equipos.
Cada agrupamiento se debe asociar con un
paquete.
Un paquete puede contener:
Otros paquetes.
Uno o ms diagramas (al menos uno Principal).
Casos de uso y relaciones entre ellos.
caso de uso
Paquete
Subpaquete
Macro proceso
Proceso
Micro proceso
As es como el Modelo de Casos de Uso (MCU) se
organiza jerrquicamente.
Es conveniente adoptar reglas de estilo para la
estructuracin de la MCU.
Casos de Uso del Negocio
A diferencia de los casos de uso del sistema de
software, los casos de uso del negocio describen,
por analoga, cmo los clientes del negocio usan el
negocio para obtener servicios.
Los casos de uso del negocio son parte
fundamental del Modelo del Negocio.
Los casos de uso del negocio son flujos de
trabajo que representan procesos
organizacionales.
Los procesos organizacionales incluyen casos de
uso del sistema y otras actividades que no van a
ser soportadas por el sistema de software.
Casos de Uso del Negocio
Los paquetes de casos de uso que representan
procesos tpicamente incluyen un flujo de trabajo
que abarca a todos los casos de uso del paquete.
Los procesos organizacionales se especifican mejor
con diagramas de actividades.
Nombres tpicamente apropiados para procesos
organizacionales son: Administracin de,
Gestin de, Actualizacin de, Inscripcin
de, etc.
Reglas importantes a recordar:
Un CU pertenece solo a un paquete.
Un diagrama pertenece solo a un paquete.
Un paquete pertenece solo a un paquete.
Pero un CU puede aparecer en muchos
diagramas de distintos paquetes.
Cuando un CU aparece en diagramas de varios
paquetes, se generan dependencias entre
paquetes.
Dependencias entre paquetes
de casos de uso
Paquete 02
Paquete 01
Indica que algn caso de uso
que pertenece al Paquete 02
aparece en algn diagrama del
Paquete 01
Dependencias entre paquetes
de casos de uso
Dependencia de datos entre subsistemas.
Dados dos paquetes que representan subsistemas A
y B, si A requiere datos que encapsula B, se traza
una lnea de dependencia (flecha punteada) desde A
hacia B.
Dependencia de procesamiento entre
subsistemas.
Dados dos paquetes que representan subsistemas A
y B, si A requiere que ciertos datos sean procesados
por una operacin que encapsula B, se traza una lnea
de dependencia (flecha punteada) desde A hacia B.
Priorizacin de casos de uso
Criterios a considerar en la priorizacin:
Impacto del caso de uso en el diseo del
sistema en trminos de cantidad de entidades,
clases o tablas adicionales en la base de datos.
El caso de uso est asociado con funciones
cuyos tiempos de respuesta son crticos, o son
muy complejas, o son muy importantes para el
cliente o tienen asociados riesgos.
Priorizacin de casos de uso
Criterios a considerar en la priorizacin:
El caso de uso est asociado con el uso de
tecnologa poco conocida o que todava se
encuentra en fase de diseo experimental o de
pruebas preliminares.
El caso de uso permite profundizar mucho en la
comprensin del diseo del sistema con un
esfuerzo relativamente pequeo. Esto sucede
cuando el caso de uso revela muchas entidades o
las ms importantes.
2. Detallando la vista preliminar con
datos y operaciones
Datos y operaciones en el MCU
Durante una segunda versin ms elaborada del
MCU, es til representar de forma estructurada
los datos (de entrada y de salida) y las operaciones
que los actores podrn realizar en cada caso de
uso.
Todos los autores coinciden en que esta
representacin no debe caer en el diseo de
maquetas de pantalla ni de reportes, sino que
debe ser una descripcin que se abstraiga de tales
detalles.
La razn es que las maquetas de pantalla y los
reportes de salida suelen variar mucho a lo largo
del proceso de desarrollo.
Una forma de representar los datos y
operaciones para cada caso de uso consiste
simplemente en presentar sendas listas en
la especificacin de cada caso de uso. Esto
sin embargo siempre quedar fuera de los
diagramas del MCU.
A travs de los objetos de frontera
(boundary objects) es posible lograr una
representacin grfica que en muchos caso
ser ms simple y ms precisa.
Segn Rumbaugh, Jacobson y Booch, los objetos de
frontera se utilizan para modelar la interaccin
entre el sistema y sus actores (es decir, usuarios y
sistemas externos). Esta interaccin a menudo
implica recibir (y presentar) informacin y
peticiones de (y hacia) los usuarios y los sistemas
externos.
Estos autores agregan que los objetos de frontera
representan a menudo abstracciones de
ventanas, formularios, paneles, interfaces de
comunicaciones, interfaces de impresoras,
sensores, terminales.
Segn Bruegge , los <<objetos de frontera>>
representan la interaccin entre los
actores y el sistema y agrega Los
objetos de frontera modelan la interfaz de
usuario a un nivel burdo. NO describen con
detalle los aspectos visuales de la interfaz
de usuario.
Este cono ha sido
adoptado como
representacin grfica del
estereotipo estndar
<<boundary object>> u
<<objeto de frontera>>.
Al modelar la gran mayora de los sistemas de
software se puede encontrar dos grandes
categoras de <<objetos de frontera>>:
<<documentos virtuales>>: por medio de los cuales el
sistema captura y presenta datos persistentes.
<<tableros de control>>: por medio de los cuales el sistema
permite al usuario ejercer el control con operaciones
especficas.
Ambos categoras de <<objetos de frontera>>
pueden contener datos y operaciones, pero el
nfasis de los <<documentos virtuales>> es en los
datos, mientras que el nfasis de los <<tableros de
control>> est en las operaciones.
Objeto de frontera
Documento virtual
Tablero de operaciones
Qu es un <<documento virtual>>?
Ms ampliamente un <<documento
virtual>> (o <<VDoc>>) es:
Un conjunto estructurado de datos relevantes que
requieren persistencia y de operaciones para su
manipulacin por parte de actores que intervienen en uno
o ms casos de uso.
El uso de todo <<documento virtual>> est asociado a una
identificacin unvoca.
El uso que hace un actor de un <<documento virtual>>
constituye parte esencial de su participacin concreta en
los as llamados procesos del negocio o procesos
organizacionales.
Tipos de <<documentos virtuales>>
Documento virtual
FRM Formulario
TBL Tabulador
GrfFig Grfico de figuras
FNG Fonograma
VDO Vdeo
TXT Texto
Un ejemplo de <<documento virtual>>
Un ejemplo tpico de <<documento virtual>>
es el formulario (prefijo FRM) que permite
capturar y presentar los datos bsicos de
un Expediente Estudiantil en el SEA del
SIGUA.
Tipos de <<documento virtual>>
<<FRM>>: se usa cuando un caso de uso
permite visualizar o editar un agrupamiento
de datos, atributos o campos. Provee
ciertas operaciones bsicas (como limpiar
formulario o seleccionar valor de un
campo).
Ejemplo: un documento para estructurar los
datos de un afiliado de un club, los datos de un
empleado de una empresa o los datos de un
expediente.
<<TBL>> o tabuladores: se usa cuando un
caso de uso permite visualizar o editar una
secuencia de lneas, cada una con la misma
cantidad y tipo de atributos o columnas. Por
ejemplo la lista de productos que conforma
una factura. Proporciona operaciones para
la edicin de las filas as como de la
coleccin de filas en s y su visualizacin
(scrolling).
<<TXT>>: se usa cuando un caso de uso
permite visualizar o editar un texto libre,
en forma similar a los documentos de los
editores de texto. Proporciona las
operaciones tpicas de edicin, bsqueda y
visualizacin (scrolling).
Ejemplo: un documento que permite visualizar y
editar un editor de textos cualquiera.
<<GrfFig>>: se usa cuando un caso de uso
permite visualizar o editar un dibujo libre
como el que tpicamente se maneja a travs
de editores especializados para hacer
dibujos o esquemas de diferentes tipos
como grafos. Proporciona las operaciones
tpicas de edicin y visualizacin
(scrolling).
Ejemplo: un documento que permite visualizar y
editar un editor de dibujos cualquiera (Visio).
<<VDO>>: se usa cuando un caso de uso permite
visualizar un registro electrnico de un vdeo o
vdeo en formato digital. Este tipo de archivo
puede ser visto a travs de programas especiales
que los reproducen y permiten operaciones de
consulta basadas en la secuencia de pistas
(siguiente, anterior, principio, final, pausa, etc).
Tpicamente, solo software especializado permite
la edicin de VDOs.
Ejemplo: los archivos que permiten visualizar
herramientas como Quick Time Player.
<<FNG>>: se usa cuando un caso de uso permite
escuchar un registro electrnico de un sonido o
archivo de sonido en formato digital. Este tipo de
archivo puede ser escuchado a travs de
programas especiales que los reproducen y
permiten operaciones de consulta basadas en la
secuencia de pistas (siguiente, anterior, principio,
final, pausa, etc).
Tpicamente, solo software especializado permite
la edicin de FNGs.
Ejemplo: los archivos que permiten escuchar
herramientas como Windows Media.
<<tableros de operaciones>>
Ms ampliamente un <<tablero de
operaciones>> o <<tablero>> es:
Un agrupamiento de operaciones relevantes e
interdependientes que usan actores en forma
conjunta en uno o ms casos de uso, con el fin
de:
Navegar y hacer bsquedas en colecciones de
<<VDoc>>.
O arrancar, terminar, controlar o monitorear procesos
en el sistema.
Los <<tableros>> pueden contener datos que son
parmetros para los procesos correspondientes.
<<tableros>> para navegacin y bsqueda
Tablero de operaciones
DIR Directorio de VDocs
J RQ J erarqua de VDocs RED Red de VDocs
BUS Buscador de VDocs
<<DIR>>: se usa cuando un caso de uso permite
organizar linealmente el acceso a <<VDocs>>. Puede
soportar una o ms relaciones de orden sobre el
conjunto de documentos y consecuentemente
varios recorridos alternativos.
Tpicamente provee operaciones como obtener el
primer documento, obtener el ltimo documento,
siguiente documento, anterior documento,
agregar documento, modificar documento,
eliminar documento y similares. Tpicamente se
provee el acceso a paneles de bsqueda sobre el
archivo que se recorre.
Un ejemplo tpico de <<tablero>> tipo <<DIR>> es un
navegador lineal sobre la coleccin de expedientes
estudiantiles en el SEA que permite recorrer en
orden alfabtico o por carnet todo la coleccin y
que da acceso a un <<tablero>> para bsquedas
basadas en parte del carnet, parte del nombre u
otros criterios relevantes.
En este caso los <<VDoc>> organizados por el
<<DIR>> son los expedientes estudiantiles.
<<JRQ>>: se usa cuando un caso de uso permite organizar
jerrquicamente el acceso a <<documentos virtuales>>. Un
<<tablero>> tipo <<JRQ>> est constituido tanto por <<VDocs>>
como por paquetes de VDocs o <<Carpetas de VDocs>>.
Una <<Carpeta de VDocs>> puede contener otras carpetas y
documentos virtuales.
A travs de las <<Carpetas de VDocs>> un <<JRQ>>
tpicamente ofrece operaciones como abrir una carpeta de
documentos, cerrar una carpeta, visualizacin de la
jerarqua (scrolling vertical y horizontal), agregar una
carpeta, eliminar una carpeta, agregar un VDoc, eliminar
un VDoc, modificar un VDoc.
Aunque no es frecuente, puede ser que provea el acceso a
paneles de bsqueda.
Un ejemplo tpico de <<JRQ>> es un sistema de
clasificacin de tipos de productos en un sistema
de catlogo de productos. Este tipo de sistemas
permiten agregar nuevas clases de tipos y nuevos
tipos, as como trasladar clases o tipos de una
clase a otra, eliminar clases y tipos.
En este caso los <<VDoc>> organizados por el
<<JRQ>> son las especificaciones de los tipos de
producto. Las <<Carpetas de VDoc>> son las clases
de tipos de productos.
En este y otras aplicaciones de <<JRQ>> las
carpetas estn asociadas a <<VDocs>> que las
describen, aparte de los <<VDoc>> contenidos.
<<RED>>: se usa cuando un caso de uso permite
organizar una coleccin de <<VDocs>> en forma de red.
Los nodos de la red son los <<VDoc>> y las conexiones de
la red son asociaciones relevantes entre los <<VDoc>>.
Las operaciones tpicas permiten navegar en la red
mediante hipervnculos u operaciones sobre la ruta
seguida por el actor durante su navegacin previa.
Tpicamente provee acceso a paneles de bsqueda.
En algunos casos, una <<RED>> permite agregar o
eliminar <<VDocs>> o conexiones entre <<VDocs>> a la
red. En algunos casos, un nodo de la red puede
representar a otra red.
Un ejemplo tpico de <<tablero de operaciones>>
tipo <<RED>> es el conjunto de operaciones que
permiten a un usuario navegar en una pgina-web.
En este caso los <<VDoc>> organizados por la
<<RED>> son los documentos html de la pgina y
las conexiones los hipervnculos entre los
documentos. Las conexiones con otras pginas que
abordan temas afines hacen que un documento
html sea un representante de otra red.
Otros <<tableros de operaciones>>
<<LGN>>: se usa cuando un caso de uso
permite identificar a un usuario que
desea acceder a un sistema, cargar el
perfil de derechos del usuario o
rechazar a un usuario que no tiene
autorizacin para usar el sistema.
Tpicamente todo sistema de
informacin empresarial tiene al menos
un caso de uso basado en un <<LGN>>.
<<SLA>>: se usa cuando un caso de uso
permite buscar un archivo para cargarlo
como datos de entrada a un sistema.
Tpicamente permite al usuario navegar por
un sistema de archivos que en realidad
consiste en una <<JRQ>> de carpetas de
archivos y archivos. Por esto las operaciones
tpicas de un <<SLA>> incluyen operaciones
tpicas de una <<JRQ>>.
Un ejemplo tpico de <<tablero>> tipo
<<SLA>> es la ventana que permite a
cualquier usuario de una herramienta de
ofimtica cargar un archivo para editarlo.
<<SLC>>: se usa cuando un caso de uso
permite buscar una carpeta para guardar un
archivo.
Tpicamente permite al usuario navegar por
un sistema de archivos que en realidad
consiste en una <<JRQ>> de carpetas de
archivos y archivos. Por esto las operaciones
tpicas de un <<SLC>> incluyen operaciones
tpicas de una <<JRQ>>.
<<SLC>> es la ventana que permite a
cualquier usuario de una herramienta de
ofimtica guardar un archivo previamente
editado.
<<MNU>>: se usa cuando en un caso de
uso se permite a los actores escoger
una entre varias opciones de
interaccin subsecuente.
Tpicamente se representa en la
interfaz grfica humano-sistema
mediante un pull-down menu o pop-up
menu o una barra de botones.
<<APR>>: se usa cuando un caso de uso
permite arrancar o activar un proceso
computacional.
Tpicamente este tipo de <<tablero>>
incluye una descripcin del proceso, sus
consecuencias y las advertencias del
caso. Se incluyen operaciones como
arrancar proceso o cancelar para
cerrar el <<tablero>>.
<<APR>> es un panel para buscar archivos en
un sistema de archivos.
<<MPR>>: se usa cuando un caso de uso
permite monitorear el avance de un proceso
computacional previamente arrancado.
Tpicamente provee operaciones para
detener momentneamente el avance del
proceso o cancelar abruptamente su
ejecucin. Adems tpicamente el panel
incorpora datos que indican el avance
alcanzado hasta el momento.
<<MPR>> es el panel para monitorear el
desempeo de un computador personal.
<<VDocs>> versus <<tableros>>
La diferencia entre <<VDocs>> y <<tableros>>
es difusa.
Tanto los <<VDocs>> como los <<tableros>>:
Incluyen atributos y operaciones.
Abstraen los mecanismos de interaccin
humano-sistema.
Presentan datos y permiten realizar operaciones
sobre los datos.
En qu consiste la diferencia?
<<VDocs>> versus <<tableros>>
<<VDocs>> <<tableros>>
Los datos sirven
para:
Representar
instancias de
entidades o vistas
de entidades
Controlar o
parametrizar
procesos
Las operaciones
sirven para:
Editar, guardar,
borrar e iniciar los
datos de los
<<VDocs>>
Navegar en
colecciones de
<<VDocs>> o
monitorear y
controlar procesos
<<documentos virtuales>> compuestos
Un <<documento virtual subordinado>> es:
Un <<documento virtual>> que no tiene una identificacin
unvoca y que forma parte integral de otro <<documento
virtual>>, de tal forma que no tiene existencia lgicamente
independiente. Esto significa que siempre es usado como
parte de otro <<documento virtual>> que se podra
denominar padre o dueo, de ah que no posea una
identificacin unvoca.
En algunos casos un <<documento virtual>> subordinado
puede tener un atributo identificador cuyo valor se
deriva mecnicamente de la identificacin del
<<documento virtual>> padre para satisfacer algn
requerimiento puramente computacional y no
organizacional o de uso por parte de actores.
Composicin de <<documentos virtuales>>
Un <<documento virtual>> compuesto es un tipo de
<<documento virtual>> que se usa cuando:
En un caso de uso se requiere una composicin de una
cantidad fija y mayor o igual a dos <<documentos
virtuales>> subordinados. Un <<documento virtual>>
compuesto provee una operacin para seleccionar cada
uno de los <<documentos virtuales subordinados>>.
Un ejemplo tpico es un expediente de estudiante que se
compone de varios <<documentos virtuales subordinados>>
como: FRM Datos generales, TBL Registro de notas y
TBL Registro de anotaciones.
En adelante se abreviar con <<VDocCmp>>.
Arreglos de <<documentos virtuales>>
Un arreglo de <<documentos virtuales>> es un tipo
de <<documento virtual>> que se usa cuando:
En un caso de uso se requiere visualizar o editar una
coleccin variable de <<documentos virtuales>>
subordinados. Un arreglo de <<documentos virtuales>>
tpicamente se compone de un <<documento virtual>> que
lo describe y de la coleccin o arreglo de <<documentos
virtuales>> en s.
Un ejemplo tpico es una agregacin de hojas electrnicas
como los libros de Excel de Microsoft.
Un arreglo de <<documentos virtuales>> proveer
operaciones para el recorrido lineal de la coleccin de
<<documentos virtuales>> subordinados.
En adelante se abreviar con <<VDocArr>>.
Datos y operaciones en la VCU
Arreglos y composiciones de <<documentos virtuales>>
Diferencias entre <<VDocCmp>> y <<VDocArr>>:
Estructuralmente, la diferencia esencial entre un
<<VDocCmp>> y un <<VDocArr>> es que la clase de un
<<VDocCmp>> especifica una cantidad fija, definida
estticamente, de <<documentos virtuales subordinados>>,
mientras que la clase de un <<VDocArr>> especifica una
cantidad variable, definible dinmicamente, de
<<documentos virtuales>> subordinados contenidos o
miembros.
Adems tpicamente los <<VDocArr>> se componen de
<<documentos virtuales>> de una misma clase, mientras
que los <<documentos virtuales compuestos>> en cambio se
componen tpicamente de <<documentos virtuales>>
subordinados de distintas clases.
Por tanto, las operaciones proporcionadas difieren.
Objetos de frontera
abstractos y concretos
En forma anloga a la reutilizacin de casos de uso
abstractos por medio de la herencia en casos de
uso concretos, se puede dar la reutilizacin de
objetos de frontera abstractos por medio de la
herencia en objetos de frontera concretos.
Un objeto de frontera abstracto est constituido
por un conjunto de atributos y operaciones bsico,
extendible y personalizable.
Un objeto de frontera concreto puede heredar,
extender y personalizar los atributos y las
operaciones de uno abstracto.
Objetos de frontera
abstractos y concretos
En este caso FRM
Transaccin Genrica
est constituido por
atributos y operaciones
que son reutilizables en
objetos de frontera
concretos como FRM
Factura.
La reutilizacin de casos
de uso y objetos de
frontera es una tcnica
muy poderosa orientada al
desarrollo rpido de
software fiable.
VDoc Transaccin genrica
+id: String
+idCliente: String
+nombreCliente: String
+fecha: FECHA
+actualizar()
VDocCmp Factura
+slcSubVDoc()
+actualizar()
FRM Encabezado de factura
+subtotal
+impuestos
+descuentos
+total
TBL Detalle de factura
+UPC
+descripcion
+cantidad
+precioUnitario
+subtotal
1
1
Ejemplificar uso de
objetos de frontera
A continuacin un ejemplo:
Con base en un documento de anlisis de
requerimientos se refina la vista de casos de
uso elaborada previamente.
Se introducen todos los objetos de frontera
con sus datos y operaciones.
3. Elaboracin de las especificaciones
de los casos de uso
Especificacin de casos de uso
Existen por lo menos dos formas de
especificar detalladamente los casos de uso
que conforman un modelo:
Especificaciones tradicionales: que son
descripciones estructuradas basadas en
lenguaje natural.
Especificaciones formales: que son
descripciones basadas en diagramas de
actividades de UML y en objetos de frontera
(boundary objects en Rational Rose).
Especificaciones tradicionales
Nombre del caso de uso.
Actores involucrados.
Propsito: para qu sirve el CU?
Resumen del FTI.
Requerimientos asociados (funcionales/no funcionales).
Precondiciones.
Poscondiciones.
Flujo tpico de interacciones (FTI).
Flujos alternativos de interacciones (FAI).
Flujos excepcionales de interacciones (FEI).
Maquetas de pantallas.
Diseo de salidas impresas o de reportes electrnicos.
Las pre/pos-condiciones deben redactarse
en presente perfecto: Se ha.
Las pre/pos-condiciones deben visualizarse
como guas para el proceso de pruebas
basado en casos de uso.
Las precondiciones son condiciones en el
sistema o su entorno (procesos
organizacionales o del medio en que
funcionar el sistema) necesarias, pero no
suficientes para que un caso de uso, y por
ende alguno de sus casos de prueba, tenga
xito, es decir que termine con el FTI o con
algn FAI.
Las poscondiciones son condiciones que se
deben verificar en el sistema o en el
entorno en que ste funciona cuando se
pruebe la implementacin de un caso de uso
del sistema y este termine con el FTI o con
algn FAI.
Nombre del caso de uso: Registrar compra de artculos
Actores involucrados: Cliente, Cajero, Agencia de
verificacin de cheques y Agencia de verificacin de tarjetas
de crdito.
Propsito: Permite mostrar la interaccin del sistema al
pagar un cliente.
Resumen: Un cliente llega a la caja. El cajero registra los
artculos uno a uno indicando la cantidad. El cajero registra
el pago y el cliente abandona el sitio.
Algunas funciones asociadas:
Registrar artculo vendidos usando un lector de
cdigo de barras.
Desplegar la descripcin y el precio de cada
artculo comprado.
Calcular el monto de la venta incluyendo impuestos.
Curso tpico de eventos:
Accin de un act or Accin del sist ema
1. Este caso de uso empieza
cuando un cliente llega al punto
de venta a registrar su compra.
2. El cajero registra el identificador
de cada artculo. Si hay ms de
uno para algn artculo, registra
la cantidad.
3. Determina el precio del artculo y
agrega la informacin a la
transaccin en proceso.
4. El cajero indica al sistema
cundo ha terminado el registro
de todos los artculos.
5. Calcula y despliega el total de la
venta.
6. El cajero indica al cliente el total.
7. El cliente entrega su pago en
efectivo.
8. El cajero registra el monto
entregado por el cliente.
9. Muestra el cambio a devolver al
Cliente.
10. El cajero deposita el efectivo y
entrega el cambio y la factura.
11. Registra en bitcora la venta.
Nombre del negoci o
UPC
Precio
Total de
venta
Monto
entregado
Cantidad
Descripcin
Cambio
Registrar artculo Finalizar venta Registrar pago
Las ECU basadas en lenguaje natural
tienden a ser poco precisas y ambiguas.
Cada analista establece un nivel detalle
arbitrario y es difcil estandarizarlo a nivel
de un equipo de trabajo.
No es fcil establecer criterios de
verificacin para este tipo de ECUs.
Por tanto, se recomiendan las ECU
formales.
Especificaciones Formales
Para lograr mayor precisin,
estandarizacin y verificabilidad de las
ECU se representan formalmente:
Los documentos usados en los casos de uso
mediante objetos de frontera.
Las secuencias o ciclos de interaccin a travs
de diagramas de actividades del UML y ciertos
estereotipos bsicos.
ECUs Formales
A continuacin el ejemplo de Registrar
Compra de Artculos:
Modelo de casos de uso.
Diagrama de actividades.
Este diagrama se podra extender un nivel ms.
ECUs Formales
A continuacin un diagrama de actividades que
representa el flujo tpico de eventos del caso de
uso Registrar Compra de Artculos.
ECUs Formales
ECUs Formales
Ventajas:
Se logra un anlisis detallado de los datos y de los
documentos.
Se maneja un identificador a nivel de todo el equipo de
trabajo para datos, secciones y documentos.
Se evitan imprecisiones y ambiguedades en las ECU.
Se uniformiza el nivel de detalle de las ECU.
Se uniformiza el lenguaje para la descripcin de las
interacciones.
Se facilita la verificacin posterior para establecer la
calidad de las ECU.
ECUs Formales
Actividades tpicas del sistema sobre vDocs
ESTEREOTIPO SIGNIFICADO PRECISO
<<MOSTRAR VDOC>> Accin del sistema que muestra los datos de un VDoc un actor. En este caso el
VDoc aparece lleno con valores vlidos y el sistema no permite su edicin. El
sistema queda a la espera de una accin del actor.
<<CAPTURAR VDOC>> Accin del sistema que captura los datos de un VDoc. El sistema queda en estado
de espera a que el usuario registre cada tem del VDoc. En este caso el VDoc
aparece vaco.
<<EDITAR VDOC>> Estado del sistema en que muestra al usuario un VDoc y a la vez le permite
editarlo. En este caso el VDoc se muestra con valores vlidos y el sistema
permite su edicin. El sistema queda a la espera de que el usuario modifique
valores para distintos temes del VDoc.
<<VALIDAR VDOC>> Accin del sistema que valida un VDoc previamente registrado o modificado por el
actor.
<<GUARDAR VDOC>> Accin del sistema que asegura la persistencia de un VDoc (normalmente mediante
un sistema de base de datos). Puede tratarse de un VDoc nuevo o de una
modificacin.
<<ELIMINAR VDOC>> Accin del sistema que elimina un VDoc (normalmente guardado en una base de
datos).
<<CARGAR VDOC>> Accin del sistema que consiste en cargar, de una base de datos o archivo, la
estructura de datos que representa un VDoc para eventualmente mostrarlo al
actor.
ECUs Formales
Actividades de control tpicas del sistema
<< ACTIVAR TABLERO >> Accin del sistema que enfoca el control sobre un tablero de operaciones.
As el usuario, en la siguiente accin, podr realizar cualquiera de las
operaciones que el tablero incluye. Si el tablero incluye datos, el usuario
podr dar valor a los datos como parte de la ejecucin de las operaciones
del tablero.
<<DESACTIVAR TABLERO>> Accin del sistema que deshabilita todas las operaciones de un <<Tablero
de operaciones>>.
<<EJECUTAR_CU SR>> Accin del sistema que traslada el control a otro caso de uso. El control se
traslada y no retorna ("SR" = sin retorno) al punto donde aparece la accin
de tipo <<EJECUTAR_CU SR>>.
<<EJECUTAR_CU CR>> Accin del sistema que traslada el control a otro caso de uso. El control se
traslada y s retorna ("CR" = con retorno) al punto donde aparece la accin
de tipo <<EJECUTAR_CU CR>>.
<<EJECUTAR_FAI>> Accin del sistema que traslada el control a un flujo alternativo de
interacciones del caso de uso actual. El control se traslada y retorna a la
actividad que aparece de seguido a la accin de tipo <<EJECUTAR_FAI>>.
<<EJECUTAR_FEI>> Accin del sistema que traslada el control a un flujo excepcional de
interacciones del caso de uso actual. El control se traslada y retorna a la
actividad que aparece de seguido a la accin de tipo <<EJECUTAR_FEI>>.
ECUs Formales
Actividades de control tpicas del sistema
<<DESPLEGAR MSJ>> Accin del sistema que muestra al actor un mensaje. El actor solo puede oprimir
un botn de tipo OK en respuesta.
<<DESPLEGAR PRG>> Accin del sistema que muestra al actor una pregunta que determina el curso a
seguir en la interaccin. El actor podr responder con una de dos posibles
respuestas, tpicamente SI o NO.
<<HABILITAR OPR>> Accin del sistema que muestra al actor barras de mens, barras de botones,
mens o botones con operaciones disponibles. Puede referenciarse el
nemnico de una sola operacin, varias operaciones aisladas o toda una lista
denominada de operaciones.
<<DESHABILITAR
OPR>>
Accin del sistema que desactiva barras de mens, barras de botones, mens o
botones con operaciones disponibles. Se puede usar por ejemplo para
efectos de ajustar las funciones del sistema al perfil de derechos de un
actor.
ECUs Formales
Actividades tpicas de un actor
<<COMPLETAR
TABLERO>>
Accin de un actor para completar los datos de un <<Tablero de operaciones>>
que previamente ha sido activado por medio de <<ACTIVAR TABLERO>>.
<<COMPLETAR VDOC>> Accin de un actor para llenar un formulario o construir un grfico que
previamente ha sido presentado por el sistema por medio de una accin de tipo
<<CAPTURAR VDOC>>.
<<MODIFICAR VDOC>> Accin de un actor para modificar un formulario o un grfico que previamente
ha sido presentado por el sistema por medio una accin de tipo <<EDITAR
VDOC>>.
<<CONSULTAR VDOC>> Accin de un actor para consultar un formulario o navegar en un grfico que
previamente ha sido presentado por el sistema por medio de una accin de tipo
<<MOSTRAR VDOC>>.
<<ESCOGER OPR>> Accin de un actor en que escoge activar operacin habilitada por el sistema
por medio de una accin de tipo <<ACTIVAR TABLERO>> o <<HABILITAR OPR>>,
o que pertenece a un VDoc previamente mostrado por el sistema o en proceso
de edicin.
<<ESCOGER SubVDOC>> Accin de un actor que le da acceso a una parte (o SubVDoc) de un VDoc
compuesto o arreglo de VDocs que previamente el sistema ha cargado. Esta
accin normalmente consiste en un click sobre una cejilla, o sobre un campo
de un formulario desplegado pero que todava no ha sido activado, o sobre una
ventana desplegada pero que todava no ha sido activada.
Diagramas de Actividades
Diagramas de actividades
(Para qu sirven?)
En el AOO los diagramas de actividades sirven para:
Representar un flujo de trabajo en el contexto organizacional
para el que ha sido diseado un sistema.
Representar las interacciones entre actores y sistema en el
contexto de un caso de uso.
En otras etapas, los diagramas de actividades pueden servir
para:
Modelar la dinmica que sigue un grupo de objetos para brindar
cierta funcionalidad.
Modelar la dinmica de un mtodo u operacin de una clase en el
contexto de un sistema.
(Actividades y acciones)
Una actividad es un procedimiento (computacional o humano)
cuyo anlisis amerita su descomposicin en trminos de otras
actividades o acciones.
Una accin es un procedimiento cuyo anlisis no amerita su
descomposicin, sino que se considera atmica.
La duracin y complejidad de una accin computacional debe
ser negligible comparado con lo que dura una actividad.
En el caso de acciones humanas, la duracin debe ser mucho
ms breve comparada con la de una actividad.
En ambos casos (acciones y actividades) se habla de estados.
(Actividades y Estados)
Las diferencias entre actividades y estados son:
Las actividades se descomponen en secuencias de
actividades o acciones.
Los estados se pueden descomponer en actividades y
acciones asincrnicas, es decir, donde no hay una
secuencia pre-establecida.
Una actividad concluye cuando termina la secuencia de
actividades y acciones que la conforman.
Un estado concluye cuando se presenta un evento que
interrumpe el estado, no se aplica la idea de terminar la
secuencia de acciones o actividades.
(Ejemplos de actividades y acciones computacionales)
Actvidad Accin
La sumarizacin
de una cuenta es
una accin que se
da como parte de
la actividad de
mayorizacin.
Sumarizacin
de cuenta
Mayorizacin
(La transicin entre estados)
Este grfico representa la transicin entre dos estados, ya
sea de actividad o de accin.
Un estado
inicial
Un estado
subsiguiente
(El estado inicial)
Todo diagrama de actividades debe tener al menos un estado
inicial:
Un estado
(El estado final)
Todo diagrama de actividades debe tener al menos un estado
final:
Un estado
(Las transiciones condicionadas)
Una transicin condicionada representa que se pasar de un
estado a otro si la condicin se cumple al completarse el
estado origen:
Pasa del primer estado a
algn otro dependiendo de
la condicin que se
verifique al terminar el
primero.
Estado
Inicial
Segundo
estado
Tercer
estado
Cuarto
estado
[ condicin 1 ] [ condicin 2 ]
[ condicin 3 ]
(Las divisiones concurrentes)
Las divisiones concurrentes muestran la posibilidad de que al
terminarse un estado se ejecuten varios estados en forma
concurrente:
Un estado
Primer estado
concurrente
Segundo
estado
concurrente
(Las uniones concurrentes)
Una unin concurrente representa que hasta que se terminen
varios estados, el sistema entrar en nuevo estado que une
los distintos flujos de control concurrentes:
Primer estado
concurrente
Segundo
estado
concurrente
Un estado
(Los flujos de objetos)
Un flujo de objetos muestra el papel que juega un objeto
durante una actividad ya sea como insumo o como producto:
Un estado
Un objeto
producido
Un estado
Un objeto
que entra al
estado
Diagrama de actividades
(Un ejemplo para representar un mtodo)
Sumarizar
la venta
Devolver el
monto del
cambio
Devolver
mensaje
de error
[ total >pago ]
[ total <=pago ]
Estado de espera o
aceptacin de evento
Estado en un proceso que espera la
ocurrencia de un evento para que se
ejecute la actividad subsiguiente.
Actividad de generacin de evento
Actividad en un proceso que genera la ocurrencia
de un evento para que se ejecute la actividad o
estado subsiguiente.
Estado de espera
de seal de tiempo
Estado en un proceso que espera la ocurrencia de
un evento de tiempo para que se ejecute la
actividad subsiguiente.
La Vista Lgica
en el anlisis
La Vista Lgica en el anlisis
En la Vista Lgica se pueden incluir cuatro
modelos:
El Modelo del Dominio - MD (RUP y Larman).
El Modelo del Negocio - MN (RUP).
El Modelo de Objetos de Anlisis MOA (RUP).
La Vista Lgica
en el anlisis
1. El Modelo del Dominio (MD)
El modelo del Dominio
Tanto en la primera edicin del libro de
Larman como en el RUP se habla del
modelo del dominio o modelo conceptual.
Un Modelo del Dominio captura los tipos
ms importantes de objetos en el contexto
del sistema. Los objetos del dominio
representan las cosas que existen o los
eventos que suceden en el entorno en el que
trabaja el sistema (RUP).
Las clases del dominio aparecen en tres
formas tpicas:
Objetos del negocio: cosas que se manipulan en
el negocio como pedidos, cuentas y contratos.
Objetos del mundo real: y conceptos de los que
el sistema debe hacer un seguimiento como la
aviacin enemiga, misiles y trayectorias.
Sucesos que ocurrirn o han ocurrido, como la
llegada de un avin, su salida y la hora de la
comida. (RUP)
El modelo del negocio
(Modelo del Dominio)
Las clases/objetos del dominio y el
glosario de trminos se utilizan en el
desarrollo de los modelos de casos de uso y
de anlisis:
Al describir los casos de uso y al disear la
interfaz de usuario,...
Para sugerir clases internas al sistema en
desarrollo (Modelo de Objetos del Anlisis),...
(RUP)
Muy especialmente, este modelo
representa:
Entidades relevantes del dominio.
Conexiones entre entidades tales como es un,
compuesto por y otras.
Multiplicidad de las conexiones.
Atributos de las entidades
Una entidad es un objeto persistente de
relevancia directa o indirecta para los
usuarios, clientes o expertos del dominio.
El estereotipo
estndar del UML
<<business entity>> se
usa para representar
entidades relevantes
para los procesos del
negocio. Adems se
pueden representar:
Asociaciones o
conexiones.
Atributos para cada
entidad.
Asociaciones tpicas entre entidades:
Composicin (totalidad-parte)
Agregacin (contenido en).
Generacin (es un tipo de, es un ejemplo de).
Entidad_1 Entidad_2 Entidad_3
Entidad_4 Entidad_5 Entidad_6
Composicin versus agregacin
Composicin (totalidad/parte):
Entidad fuerte/entidad dbil.
El ciclo de vida de la totalidad determina el ciclo de vida
de la parte.
Una instancia de clase de parte slo puede pertenecer a
una instancia de una clase de totalidad.
Agregacin (contenido en):
El ciclo de vida de la totalidad NO determina el ciclo de
vida de la parte.
Una instancia de clase de contenido puede pertenecer a
varias intancias de diversas clases de continente.
Un ejemplo de MD del RUP:
Artculo
descripcin
foto
precio
Pedido
fecha de emisin
direccin de entrega 1..n 0..n 1..n 0..n
Factura
cantidad
fecha de emisin
fecha lmite de pago
1..n
+pagable
1..n
Cuenta
saldo
titular
1
+comprador
1
1
+vendedor
1
1. . *
1
0. . 1 *
Pago Clie nt e
describe
usado por
Caj ero
Administrador Sist ema de pun to de venta
regist ra vent as en
iniciado por
Cat alogo
Almac en
usa
Vent a
f echa : Dat e
hora
pagada por iniciada por
regist ra en bit cora
capt urada por
Art iculo
guarda
*
1
1 1
1 1
1 1
1
1
1 1
1
1. . *
1 *
*
1
1
1
*
1 1. . *
Linea de fact ura
cant idad : I nt eger
cont enida en
regist ra la vent a de
Especificacion
descripcion
precio
UPC
cont iene
desc rita por
1
Un ejemplo de MD de
Larman
Reglas de estilo para el MD
Un objeto no necesariamente corresponde con una tabla, por
eso se recomienda que los nombres de los objetos sean en
singular.
Use los nombres que usa el usuario.
Si los nombres que usa el usuario son especializados
documntelos en un glosario especializado del dominio.
Omita atributos referenciales. En general es mejor
representarlos por medio de conexiones grficas.
Igualmente, omita objetos que guardan referencias,
represente esto por medio de la multiplicidad de las
conexiones.
El MD es esencialmente una herramienta de
comunicacin entre analistas y usuarios, clientes y
expertos en el dominio.
Alguna informacin redundante puede ser til con
el usuario, a veces conviene representar atributos
derivados.
Para la comunicacin con el usuario no hace falta
que aparezcan claves.
No muestre conexiones que son irrelevantes para los
usuarios, clientes o expertos del dominio cuando use un MD
para verificar requerimientos.
Para la comunicacin con el usuario, muestre un modelo
sencillo, solo los atributos que sean relevantes para l. Evite
aqullos atributos que son tiles en la programacin.
En un diagrama se distribuyen los objetos de tal manera que
las asociaciones se puedan leer de arriba hacia abajo y de
izquierda a derecha. Si esto no es posible se introduce una
flecha en la asociacin para indicar otra direccin .
Minimice conexiones para las cuales no es necesario guardar
informacin, a menos que sean relevantes para los usuarios,
clientes o expertos del dominio.
Es ms til identificar objetos que conexiones.
No muestre conexiones que se pueden deducir o derivar, a
menos que un cliente, usuario o experto en el dominio lo
solicite.
Nombre a las asociaciones para que sean legibles segn el
esquema Clase1 frase verbal Clase2.
Las asociaciones ms importantes son del tipo:
A es una parte fsica o lgica de B.
A est contenido fsica o lgicamente en B.
A se registra en B.
Objeto o Atributo?: Nunca pensamos un objeto en la forma
de un nmero o un texto, pero si hay duda es mejor definir
un objeto.
Para atributos que no se representan bien con tipos de datos
primitivos puede ser necesario crear un objeto.
Tome en cuenta los siguientes criterios:
que el atributo est compuesto de secciones separadas,
que sea necesario programar funciones que actan sobre las
partes,
que en s mismo, el atributo contenga otros atributos,
que tenga asociado una unidad de medida o monetaria.
Identificacin de objetos
Larman provee una lista de chequeo que puede ser
til para identificar objetos en los distintos
modelos, pero principalmente en el MD y el MOA.
Larman tambin provee una lista de chequeo que
puede ser til para identificar asociaciones o
conexiones entre objetos de dichos modelos.
Ideas para encontrar objetos de Craig Larman:
Objetos fsicos o tangibles. Ejemplos: caja de pago, objetos
pedidos.
Especificaciones, diseos o descripciones de cosas. Ejemplos:
especificacin de un producto, descripcin de una cuenta contable.
Lugares. Ejemplos: Almacn, banco.
Transacciones. Ejemplos: Conjunto de datos de una venta, un pago o
un pedido.
Lneas de temes de una transaccin. Ejemplos: Lneas de una
factura, conceptos de pago en un desglose salarial.
Roles de personas. Ejemplos: En una relacin X jefe de Y, X es el
jefe y Y el empleado, ambos podran ser objetos relevantes.
Contenedores de otros objetos. Ejemplos: Avin, camin,
contenedor.
Cosas contenidas en otras. Ejemplos: Pasajero, producto.
Sistemas computacionales o electromecnicos externos al sistema.
Ejemplos: sistema de autorizacin de tarjetas de crdito, lector de
cdigo de barras.
Conceptos o sustantivos abstractos. Ejemplos: cuenta, tipo de
cuenta.
Organizaciones. Ejemplos: Departamento de ventas, Empresa
Proveedora, Empresa cliente.
Eventos o sucesos. Ejemplos: Venta, pago o un pedido.
Procesos. Frecuentemente se escogen otros mecanismos para su
representacin, pero algunas veces conviene verlos como objetos.
Ejemplos: Mayorizacin de cuentas, Conciliacin bancaria.
Normas, reglas y polticas. Ejemplos: poltica de devolucin de
artculos previamente vendidos, poltica de resarcimiento por
errores cometidos en el cobro de servicios.
Catlogos. Ejemplos: Catlogo de artculos, catlogo de cuentas
contables.
Documentos, registros de finanzas, contratos y dems documentos
legales. Ejemplos: Recibo, diario, contrato de empleo, bitcora de
mantenimiento.
Instrumentos financieros y servicios. Ejemplos: lnea de crdito,
inventario.
Libros y manuales. Ejemplos: Manual de deberes y derechos del
empleado, manual de mantenimiento.
Identificacin de conexiones
Ideas para encontrar conexiones de Craig Larman:
A es una parte fsica de B. Ejemplos: Motor es una parte de
Automvil. CPU es una parte de Computadora.
A es una parte lgica de B. Ejemplos: Unas lneas de temes de una
factura son parte lgica de una factura. La introduccin es una
parte lgica de un texto. Un prrafo es una parte lgica de un
texto.
A est fsicamente contenido en B. Ejemplos: Un artculo est
fsicamente contenido en un estante. Un pasajero est fsicamente
contenido en un avin.
A est lgicamente contenido en B. Ejemplos: Una descripcin de un
artculo est lgicamente contenida en un catlogo. Un vuelo est
lgicamente contenido en un itinerario.
A es una descripcin de B. Ejemplos: la descripcin de un artculo o
de un vuelo, sostienen esta relacin con el artculo o vuelo
correspondiente.
A es una lnea de detalle de una transaccin o reporte B. Ejemplos:
Una lnea de factura es una lnea de detalle de una factura. Una
lnea de deduccin de un reporte de pago es una lnea de detalle del
reporte de pago
A es registrado o reportado o capturado en B. Ejemplos: Una venta
es registrada en un punto de venta. Un pedido es capturado o
registrado en la entrada de una bodega.
A es un miembro de B. Ejemplos: Un cajero es miembro del personal
de un negocio. Un piloto es miembro de la tripulacin de un avin.
A es una suborganizacin de B. Ejemplos: El departamento de ventas
es una suborganizacin de una empresa. La escuela de computacin
es una suborganizacin de la universidad.
A usa o maneja B. Ejemplos: Un cajero usa o maneja el punto de
venta de un negocio. Un piloto maneja un avin.
A se comunica con B. Ejemplos: Un cliente se comunica con un
cajero. Un vendedor se comunica con un cliente.
A est relacionado con una transaccin B. Ejemplos: Un cliente est
relacionado con un pago. Un pasajero est relacionado con un
tiquete.
A es una transaccin relacionada con otra transaccin B. Ejemplos:
Un pago est relacionado con una factura. Una cancelacin est
relacionada con una reservacin.
A est junto a B. Ejemplos: Una ciudad est junto a otra ciudad. Un
libro est junto a otro en un estante.
A es propiedad de B. Ejemplos: Un automvil es propiedad de una
persona. Un telfono es propiedad de B.
La Vista Lgica
en el anlisis
2. El Modelo del Negocio segn el
(MN) RUP
El modelo del negocio busca comprender los
procesos del negocio como entorno para el
producto de software en construccin.
Al comprender el entorno en que funcionar
el producto de software, se comprende
mejor las funciones del producto.
Segn los autores del RUP el modelo del negocio
es ms poderoso y abarca ms aspectos que el
modelo del dominio.
El Modelo del negocio incluye:
Entidades y unidades de trabajo que los trabajadores
del negocio usan en los casos de uso.
Un conjunto de flujos de trabajo que modelan procesos
en la organizacin que conforman el entorno para el
producto de software a construir.
Estos se conocen como casos de uso del negocio.
MD versus MN
Difiere con el modelo del dominio en que:
Las entidades y unidades de trabajo del
modelo del negocio incluyen operaciones,
mientras que las entidades del modelo del
dominio no (entidad-relacin tradicional).
El modelo del dominio se construye como una
representacin del conocimiento de expertos en
el dominio y no necesariamente a partir de
casos de uso, como s sucede con el modelo del
negocio.
MD versus MN
Al construir el MN se incluirn entonces:
Entidades y procesos fundamentales.
Correspondencia entre <<VDocs>> y <<tableros de
operaciones>> y las entidades y procesos
relevantes del dominio.
Flujos de trabajo que representan a los casos
de uso del negocio o procesos organizacionales.
(Modelo del Dominio)
(Flujos de Trabajo)
El modelo del negocio tambin describe los procesos
organizacionales en que intervienen actores del sistema en
construccin, otros trabajadores, <<documentos virtuales>> y
entidades que van a ser representados y organizados por el
producto de software o que quedarn en el entorno del
producto.
Los flujos de trabajo se representan por medio de diagramas
de actividades.
Las actividades en un flujo de trabajo pueden ser casos de
uso del producto de software en construccin u otras
actividades que no van a ser directamente soportadas por el
producto pero son parte de su entorno.
(Flujos de Trabajo)
(Flujos de Trabajo)
La Vista Lgica
en el anlisis
3. El Modelo de Objetos de Anlisis
(MOA)
El Modelo de Objetos de Anlisis
El Modelo de Objetos de Anlisis MOA (RUP) y el
Modelo Relacional para la Persistencia de Objetos
MRPO son para coordinar el trabajo entre
analistas y programadores.
En la segunda edicin de su libro Larman reporta
que el MOA casi no se acostumbra hacer. No
obstante, puede ser muy til como modelo de
objetos independiente de la tecnologa de
desarrollo.
Ambos modelos anticipan el diseo detallado y
corresponden con una visin ms bien tcnica del
sistema en construccin.
Un modelo de anlisis:
... Ofrece una especificacin ms precisa de los
requisitos que la que tenemos como resultado de
la captura de requisitos, incluyendo el modelo de
casos de uso.
... Se describe utilizando el lenguaje de los
desarrolladores, y puede por tanto introducir un
mayor formalismo y ser utilizado para razonar
sobre los funcionamientos internos del sistema.
Un modelo de anlisis:
... Estructura los requisitos de un modo que
facilita su compresin, su preparacin, su
modificacin, y en general, su mantenimiento.
... Puede considerarse como una primera
aproximacin al modelo de diseo (aunque es un
modelo por s mismo), y es por tanto una
entrada fundamental cuando se da forma al
sistema en el diseo y en la implementacin.
(RUP).
El MOA representa :
Objetos de frontera.
Objetos de control.
Objetos de lgica de aplicacin.
<<entities>> que se encargan de la persistencia.
Adems:
Conexiones entre tales objetos.
Atributos y operaciones.
Multiplicidad de conexiones.
Navegabilidad entre los objetos.
(Objetos de Control)
Un objeto de control
representa (<<control>> o
<<controlador>>):
Comportamiento del
sistema que soporta uno o
ms casos de uso
interconectados.
Por lo anterior tpicamente
son objetos que controlan
a otros objetos
implementar las acciones
del sistema en un grupo de
casos de uso
interconectados.
Controlador
(Objetos de Control)
Gomaa clasifica los
<<controladores>> en
tres:
Coordinador: define el
control sobre otros
objetos por medio de
una secuencia de
mensajes que no
muestra dependencias
de estado.
Control de Estados:
define el control por
medio de una mquina
finita de estados.
Temporizador: define
el control por medio
de un reloj.
Controlador
Temporizador
Control de Estados Coordinador
(Objetos de lgica de aplicacin)
Estos objetos se necesitan cuando es
deseable ocultar la lgica de la aplicacin
separadamente respecto de los datos que
se manipulan porque se considera probable
que la lgica cambie en forma
independiente a los datos (Gomaa).
(Objetos de lgica de aplicacin)
Gomaa clasifica los objetos de
<<lgica de aplicacin>> en tres:
Lgica de Negocio: representa
reglas de negocio, condiciones
para su aplicacin y relaciones.
Algoritmo: representa un
algoritmo que se deriva del
anlisis de los requerimientos.
Agente Inteligente:
representa un objeto que usa
alguna tcnica de IA, adapta
su interface de acuerdo con el
objeto cliente y genera un
servicio en colaboracin
dinmica con otros agentes u
objetos.
Lgica de Aplicacin
Lgica de Negocio Algoritmo Agente Inteligente
(<<entity>>)
Tpicamente una <<entity>> corresponde a una
<<bussiness entity>> del dominio.
Los objetos <<entity>> encapsulan la interaccin con
la base de datos. De ah se derivan
responsabilidades como:
Manejo del objeto de conexin a la base de datos.
Manejo de cachs.
Aplicacin de operaciones sobre la base de datos
(insert, update, erase, search).
Verificacin de reglas de negocio que requieren la
base de datos.
Conversin de objetos a filas de tablas y viceversa
(database wrappers).
Ocultamiento de la tecnologa especfica para la
persistencia de objetos (database wrappers).
(<<ADT>>)
Aparte de las <<entities>>, en el MOA conviene
representar otros objetos asociados a estas en
tiempo de ejecucin.
Abstracciones de datos(<<ADT>>): objetos que
representan estructuras de datos en RAM que
estn asociadas al manejo de las <<entities>>.
Este estereotipo se aplica a los objetos que
representn en RAM a una entidad especfica
(una Cuenta, un Cliente o un Tipo de Producto en
particular).
(<<ADT>>)
Este estereotipo se aplica a listas, pilas,
colas, rboles, arreglos o directorios
basados hashing.
Muchos <<ADT>> han sido de hecho
implementados por los framework
asociados a las herramientas de desarrollo.
En la etapa de diseo detallado, estos
objetos podran ser sustituidos por
elementos reutilizables de un framework.
El Modelo Relacional
para la persistencia de objetos
(MRPO)
El MRPO
El Modelo Relacional
de Persistencia de
Objetos presenta :
Tablas principales.
Tablas intermedias.
Campos de tablas.
Claves primarias.
Claves forneas.
Triggers.
Store-Procedures.
Notacin para el MRPO
Una tabla se representa como un objeto
con el estereotipo <<table>>.
Los tipos de los atributos se restringen a
los SQL estndar:
Se usan estereotipos <<FK>> y <<PK>>
Las operaciones del objeto que representa
la tabla son:
<<TRG>>: triggers y
<<STP>>: store procedures.
Construccin del MRPO
Cada una de las <<entities>> puede
transformarse en una o ms tablas
(<<table>>) del MRPO.
Al aplicar BCNF siempre podran aparecer
ms tablas para una <<entity>> del MD.
Por lo anterior, es necesario representar
en el MRPO conexiones de rastreo con las
<<entities>>.
Notacin genrica
de clases en el UML
Objetos y asociaciones en UML
En UML el concepto de objeto se usa para
modelar:
Conceptos del dominio relevantes para la
comprensin de los procesos del negocio
(<<bussiness entities>>).
Fragmentos o artefactos de la interaccin
humano-sistema (<<objetos de frontera>>).
Fragmentos o artefactos del producto de
software en construccin (<<entities>>, <<ADT>>,
<<controladores>>, <<tablas>>, objetos que
representan lgica del negocio).
En esta seccin se describe la notacin
UML que se usa para representar objetos y
asociaciones de los modelos estticos de la
Vista Lgica (Modelo del Dominio,
Modelo del Negocio, Modelo de Objetos
de Anlisis y Modelo Relacional para la
Persistencia de Objetos).
Para un objeto se pueden especificar los atributos y
mtodos pblicos, privados y protegidos:
Objeto
Atributo privado : Date
Atributo pblico : Currency
Atributo protegido : Byte
Mtodo pblico()
Mtodo privado()
Mtodo protegido()
Una asociacin entre objetos se representa por medio de
una lnea continua:
Objeto2
Atributo1
Atributo2
Mtodo 1()
Mtodo 2()
Objeto1
Mtodo pblico()
Mtodo privado()
Mtodo protegido()
nombre de la relacin
Se puede indicar la multiplicidad de la asociacin en ambos
lados, con un solo caracter:
1 *
Obj eto2
Atributo1
Atributo2
Mtodo 1()
Mtodo 2()
Obje to1
Mtodo pblico()
Mtodo privado()
Mtodo protegido()
Se puede indicar la multiplicidad de la asociacin en ambos
lados, con un rango:
0..1 3. .*
Obj eto2
Atributo1
Atributo2
Mtodo 1()
Mtodo 2()
Obje to1
Mtodo pblico()
Mtodo privado()
Mtodo protegido()
Se puede indicar la multiplicidad de la asociacin en
ambos lados, con varios rangos:
0..1, 3..6 3..* , 7..*
Obj eto2
Atributo1
Atributo2
Mtodo 1()
Mtodo 2()
Obje to1
Mtodo pblico()
Mtodo privado()
Mtodo protegido()
Se pueden especificar los roles de los objetos en una asociacin.
El Rol 1 es el papel que juega el Objeto 1 en la asociacin y
el Rol 2 es el papel del Objeto 2:
Objeto2
Atributo1
Atributo2
Mtodo 1()
Mtodo 2()
Objeto1
Mtodo pblico()
Mtodo privado()
Mtodo protegido()
+Rol 1 +Rol 2
La flecha es usada para denotar una asociacin
unidireccional. Indica direccionalidad lgica en la asociacin
(relacin asimtrica). Admite todos los detalles descritos de
una asociacin simple o bidireccional.
Estudiante
Registro de notas
<<tiene>>
Aparte de las conexiones comentadas, existen otros tipos de
relaciones entre objetos:
Generalizacin: para representar la relacin entre objetos
abstractos y concretos o diferentes niveles de abstraccin.
Agregacin: para representar relaciones de composicin (parte-
todo).
Dependencia: para representar distintos tipos de interacciones.
Asociaciones n-arias: para representar asociaciones entre ms
de dos objetos.
Ejemplo de generalizacin entre <<business entities>>:
T ransaccin de autorizacin de pago
fecha
hora
Solicitud de autorizacin de pago Respuesta de autorizacin de pago
Ejemplo de composicin entre <<business
entities>>.
Permite representar la composicin (todo-parte)
entre clases.
El padre no existe sin la parte. La parte no existe
sin el padre.
El diamante relleno de negro indica que una
instancia de la clase parte solo pertenece a una
instancia de la clase todo. El diamante vaco
indica pertenencia compartida, pero se puede
aclarar con la nota de multiplicidad.
La flecha punteada es usada para denotar
interacciones entre objetos del MOA. Puede
indicar:
Que un objeto es cliente y otro suplidor, uno va
a requerir los servicios del otro.
Que un objeto es registrado por otro.
Que un objeto es generado o producido por
otro.
Que un objeto es procesado por otro.
Punto de
Venta
Venta
<<registra>>
La flecha punteada tambin puede
usarse para interacciones entre actores
y documentos en la VCU ampliada con
<<objetos de frontera>>:
Un actor captura un documento.
Un actor tramita un documento.
Un actor verifica un documento.
Administrador
Factura de
Crdito
aprueba
Las asociaciones n-arias son poco comunes pero al
identificarlas se pueden simplificar los modelos.
Ao
Equipo
J ugador
temporada
portero
Es posible introducir dependencias entre relaciones
para representar cierto tipo de restricciones. Aqu un
ejemplo del MD.
Profesor
director de
ensea en
Escuela
Esta dependencia entre
asociaciones indica que si X es un
profesor de una escuela entonces x
tambin ensea en la Escuela.
Los objetos de asociacin permiten representar
informacin relevante a una asociacin (ejemplo del MD):
Profesor
1..n
ha dictado
1..n
Curso
Rendimiento por Grupo
El profesor X ha dictado varios
cursos. Cada curso lo puede
haber dictado varios semestres
con distintos resultados de
rendimiento por grupo.
Dependiendo del modelo, se pueden agregar
mayores detalles a las asociaciones u
objetos tales como:
Uso o semntica.
Estereotipos UML.
Tipos de atributos o de parmetros de
operaciones.
Reglas de negocio.

Aoo Uml 08 10 SR PDF

Cargado por

Información del documento

Título original

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

Aoo Uml 08 10 SR PDF

Cargado por

Copyright:

Formatos disponibles

Anlisis Orientado a

Objetos con UML

También podría gustarte