Embed Size (px)
Citation preview
1
"Los Diagramas de Casos de Uso de
UML en la Especificación de los
Requerimientos de Sistemas de
Software"
Dr. Máximo López Sánchez
Agenda
• Introducción.
• Los Casos de Uso del UML.
• Los elementos de los Casos de Uso.
• Elementos gramaticales de los Casos de Uso.
• Relaciones válidas.
• Utilización de los Casos de Uso.
• Herramientas comerciales.
• Conclusiones.
Construcción de una casa para “fido”
Puede hacerlo una sola persona
Requiere:
Modelado mínimo
Proceso simple
Herramientas simples
Construcción de una casa
Construida eficientemente y en un tiempo
razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
Construcción de un rascacielos Claves en Desarrollo de SI
Herramientas Proceso
Notación
2
Sistema Computacional
Proceso de Negocios
Orden
Item
envío
“El modelado captura laspartes esenciales del sistema”
Abstracción - Modelado Visual (MV)
II. Notación (Visual) - Beneficios
Interface de Usuario(Visual Basic,
Java, ..)Lógica del Negocio
(C++, Java, ..)
Servidor de BDs(C++ & SQL, ..)
Múltiples Sistemas
Componentes Reutilizados
Manejar la complejidad
“Modelar el sistema independientemente del lenguaje de implementación”
Promover la Reutilización
Decidir que construir
¿Quién sabe que se
necesita?
¿Quién es el usuario?
• El punto clave es identificar correctamente a todos los
usuarios
• Los tipos de usuarios son:
• Usuario final
• Cliente de la organización
• Entidades externas
• Nuevos usuarios
• Analistas, desarrolladores y programadores
• Si queremos tener éxito, deben involucrarse a todos
los afectados o interesados en el trabajo.
El usuario
• El usuario tiene los siguientes comportamientos:
• Visiones parciales o incompletas del sistema.
• Inconsistencias en sus opiniones.
• No sabe qué es lo que sabe.
• No se sabe explicar o expresar lo que sabe.
• Usa terminologías distintas.
• No todos saben todo.
3
El usuario no sabe lo que quiere
• Es frecuente encontrarse en este punto y lo delicado
es que hace peligrar el proyecto final.
• Se recomienda estar pendiente de lo que quiere el
usuario y ayudarlo a identificar sus problemas
potenciales.
• Recuerde que ellos conocen su negocio y nosotros
conocemos nuestra área de trabajo.
¿Que hacer para tener los mejores
resultados?
• Cuidar la terminología utilizada en las pláticas entre
los participantes.
• Explicar y resaltar la importancia de la participación
de todos en la definición y especificación de los
requisitos.
• Hacerles ver cuál es el resultado que se va a obtener y
los beneficios que se van a alcanzar.
• Fijar objetivos y expectativas realistas para todos.
Fuentes de información
• Usuarios.
• Análisis del sistema existente.
• Formas y documentos incluyendo programas.
• Manuales.
• Reportes.
• Entrevistas.
• Cuestionarios.
cenidet
Descripción de un Caso de Uso
• Es una interacción
entre un usuario y
un sistema de
cómputo
Propiedades de los Casos de Uso
• El caso de uso capta alguna función visible
para el usuario.
• El caso de uso puede ser pequeño o grande.
• El caso de uso logra un objetivo discreto para
el usuario.
4
¿Cómo se obtiene un caso de uso? Durante la elaboración
• No trate de tener toda la información o detalles desde el principio.
• Se debe recabar la información cuando la necesite.
• Si el caso de uso tiene ramificaciones arquitectónicas de importancia, es necesario tener más detalles a la mano.
• Se pueden detallar durante la iteración a medida que se construyen.
Diferencias entre los objetivos del
usuario y las interacciones del sistema
Interacciones del sistema:
En un editor de texto tenemos:
• “define estilo”
• “cambia estilo”
• “mueve un estilo de un documento a otro”
Objetivos del sistema:
• Garantizar la consistencia del formato en un documento.
• Hacer que el formato de un documento sea igual que el de otro.
Requisitos funcionales
• Representan las
relaciones entre
entradas, acciones y
salidas.
• Se expresan en
notaciones relacionales.
Actor
• Se utiliza este término cuando algo incide y
desempeña un papel con respecto al sistema.
• Un actor puede ser una persona, sistema,
organización o ente que se relaciona con el sistema.
5
Utilidad de los actores
• En grandes sistemas, definir los casos de uso resulta demasiado complicado, por lo que los actores se convierten en parte importante, ya que primero es conveniente establecer la lista de actores y de ahí, determinar los casos de uso de cada actor.
Casos de uso
• Son la descripción de las acciones requeridas para
llevar a cabo una serie de acciones que satisfagan las
necesidades de requerimientos de los usuarios.
• Pueden ser representadas en varios niveles de
abstracción.
Confusiones y variaciones entre los
usuarios y los diagramas de casos de uso
1. Algunos sienten que todas las interacciones con sistemas remotos deben aparecer en el diagrama.
2. Otros piensan que sólo se deben mostrar los casos de uso con interacción externa, cuando quien inicia el contacto es otro sistema.
3. Hay quienes consideran que deben mostrarse los actores del sistema, sólo cuando ellos necesiten el caso de uso.
4. Otros sienten que constituye un enfoque equivocado considerar que un sistema es un actor.
La fuente para identificar los casos de
uso
Los eventos externos son considerados como una
buena fuente para identificar los casos de uso, ya que
son ante los cuales reaccionamos de manera
inmediata.
extends
• Se utiliza la relación “extends” cuando se
tiene un caso de uso que es similar a otro, pero
que hace un poco más.
Captura
negociación
Límite
excedido
<extends>
Esencia de la relación extends
1. Primero obtenga el caso de uso simple y normal.
2. En cada paso de ese caso de uso, pregúntese: “¿Qué
puede fallar aquí?”, “¿cómo podría funcionar esto
de manera diferente?”
3. Dibuje todas las variaciones como extensiones del
caso de uso dado.
6
Las relaciones “uses”
Cuando se tiene una porción de comportamiento que
es similar en más de un caso de uso y no se quiere
copiar la descripción de tal conducta.
“use”
Analiza
riesgo
Valuación
Negocia
precio
<use>
<use>
Los “extends” y “use”
Ambos implican la factorización de comportamientos
comunes de varios casos de uso, dejando un solo caso
de uso común que es empleado, o extendido por otros
casos de uso. Pero recuerde, la intención es lo que
cambia.
Respecto a los actores
Los dos tipos de relación implican asuntos
diferentes.
• En la relación extends, los actores tienen que ver o
encargar del caso de uso base y sus extensiones.
• En las relaciones uses es frecuente que no haya un
actor asociado con el caso de uso común. Es más,
si existiera, no se considera que esté llevando a
cabo los demás casos de uso.
Reglas de aplicación
• Utilice extends cuando describa una variación
de conducta normal.
• Emplee uses para repetir cuando se trate de
uno o varios casos de uso y desee evitar
repeticiones.
Realizaciones y escenarios
• Cuando se tiene más de una forma de llevar a cabo un caso de uso, se dice que estas son realizaciones.
• Comúnmente es utilizado como un sinónimo de caso de uso. Significa una sola ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso.
7
¿Cuando emplear casos de uso?
• Para capturar requerimientos.
• Para la planificación de proyectos.
• El control de proyectos.
Lo que los Casos de Uso hacen
• Contienen los requerimientos funcionales en un formato fácil de seguir y leer.
• Representa la meta de una interacción entre un actor y el sistema.
• Registra un conjunto de escenarios o caminos por los que sigue un actor, desde un evento de lanzamiento (comienzo del caso de uso) hasta la meta (escenario de éxito).
Lo que los Casos de Uso hacen
• Registrar un conjunto de escenarios que sigue un
actor desde un evento de lanzamiento hacia una meta,
pero no alcanza la meta (escenarios de falla).
• Un caso de uso puede usar/extender la funcionalidad
de otro.
• Muestran sólo requerimientos funcionales.
Lo que los Casos de Uso no hacen
– No especifican el diseño de la interfaz al usuario
– No especifican detalles de implementación
Elementos atómicos y representación
visual
ActorActor: Un actor representa un rol en el sistema, Un actor representa un rol en el sistema,
por lo tanto es un usuario concreto que por lo tanto es un usuario concreto que
interactinteractúúa con el sistema. Cualquier entidad que a con el sistema. Cualquier entidad que
se ajuste a un actor puede actuar como una se ajuste a un actor puede actuar como una
instancia de un actor. (ejemplos: una persona, un instancia de un actor. (ejemplos: una persona, un
subsistema, un servidor, etc).subsistema, un servidor, etc).
Limite del sistema:Limite del sistema: Permite definir los Permite definir los
limites del sistema y las relaciones del sistema limites del sistema y las relaciones del sistema
y su entorno.y su entorno.
8
Elementos atómicos y representación
visual
Caso de Uso:Caso de Uso: Un caso de uso es una secuencia de Un caso de uso es una secuencia de
iteraciones entre un sistema y alguien u algo que iteraciones entre un sistema y alguien u algo que
utiliza sus servicios. Un caso de uso es iniciado por utiliza sus servicios. Un caso de uso es iniciado por
un actor, a partir de ese momento ese actor, junto un actor, a partir de ese momento ese actor, junto
con otros actores intercambian datos o control con el con otros actores intercambian datos o control con el
sistema. sistema. ““Son la totalidad de operaciones Son la totalidad de operaciones
desarrolladas por el sistemadesarrolladas por el sistema””. Va acompa. Va acompaññado de un ado de un
nombre significativo.nombre significativo.
Elementos atómicos y representación
visual
Texto: Es una cadena de Es una cadena de
caracteres, caracteres, éésta comienza con sta comienza con
una letra, y es seguida por una letra, y es seguida por
caracteres alfanumcaracteres alfanumééricos.ricos.
(letra)+ (letra | numero)*(letra)+ (letra | numero)*
letra:= A..Z | a..zletra:= A..Z | a..z
numero := 0..9numero := 0..9
RelaciRelacióón 1n 1(asociaci(asociacióón):n):
Relación entre un actor y un
caso de uso, denota la
participación del actor en el
caso de uso determinado.
Elementos atómicos y representación
visual
RelaciRelacióón 4(Inclusin 4(Inclusióón):n): una instancia del
Caso de Uso origen incluye también el
comportamiento descrito por el Caso de Uso
destino. «include» reemplazó al denominado
«uses».
<<<<includeinclude>>>>
ComentarioComentario:: Se relaciona a un mensaje, Se relaciona a un mensaje,
objeto, actor, lobjeto, actor, líínea de vida o activacinea de vida o activacióón; n;
incluye un texto descriptivo dentro del cuadro incluye un texto descriptivo dentro del cuadro
que lo compone.que lo compone.
RelaciRelacióón 2(extensin 2(extensióón):n): Relación entre
un caso de uso y otro caso de uso. El
Caso de Uso origen extiende el
comportamiento del Caso de Uso
destino. «extend».
RelaciRelacióón 3(Generalizacin 3(Generalizacióón):n):
Relación entre un caso de uso y otro
caso de uso. El Caso de Uso origen
hereda la especificación del Caso de
Uso destino y posiblemente la modifica
y/o amplía.
<<<<extendextend>>>>
Elementos atómicos y
representación visual
Relaciones VálidasRelaciones Válidas
ActorCaso de uso
ActorCaso de uso 1
Caso de uso 2
<<extend>>
ActorCaso de uso 1
Caso de uso 2
<<include>>
Caso de uso 1Actor
Caso de uso 2
<<include>>
9
Relaciones no válidasRelaciones no válidas
Caso de uso 1
Actor Caso de uso 1
Caso de uso 1
Ejemplo
Construir un diagrama de casos de uso para un
sistema que controla una máquina de
reciclamiento de botellas, tarros y jarras.
Características del sistema
• Registrar el número de artículos que ingresan.
• Imprimir un recibo cuando el usuario lo solicita:
� Que describa lo depositado.
� El valor de cada artículo.
� El total.
• Existe un operador que desea saber lo siguiente:
� Cuántos artículos han sido retornados en el día.
� Al final de cada día el operador solicita un resumen de todo lo
depositado en el día.
• El operador debe además poder cambiar:
� Información asociada a los artículos.
Solución*
ClienteRegistrar Item
*Una posible solución
Solución*
Generar Reportes
Registrar Item
Cliente
Operador
Imprimir
<<include>>
<<include>>
10
Solución*
Registrar Item
Registrar Botella
Registrar Tarro
Registrar Jarra
<<extend>>
<<extend>>
<<extend>>
Solución*
G e n e ra r R e p o rt e
O p e ra d o r
C a m b ia r It e m s
Solución*
Registrar Item
Registrar Jarra
Registrar Tarro
Registrar Botella
<<extend>>
<<extend>>
<<extend>>
Cliente
Imprimir
Cambiar Item
Operador
Generar Reporte
<<include>>
<<include>>
Herramientas comerciales
11
Conclusiones
1. Son un gran aporte para llevar a cabo la
planeación de nuestros proyectos.
2. Permite resaltar los requisitos funcionales.
3. Describe la funcionalidad e interacción entre los
elementos externos al sistema con los internos.
4. Se establece un mecanismo de relación entre
acciones, las que hacen posible que se observen
de que manera mantienen comunicación los
elementos participantes.
Conclusiones
5. Se cuenta con un documento de requerimientos.
6. Permite el establecimiento de pruebas a partir de
la definición de los requerimientos.
7. Mantiene organizado nuestro trabajo.
8. Describe el flujo de información entre los
requisitos.
Lo que los Casos de Uso no hacen:
•No especifican el diseño de la interfaz al usuario
•No especifican detalles de implementación
Los Casos de Uso son usados en varias etapas del desarrollo de software:
• Capturar los requerimientos de los sistemas
• Actúan como un comité parala generación del diseño de software
• Para tener contra que validar el diseño del software
• Para las pruebas del software y el aseguramiento de la calidad (las pruebas
son ejecutadas para validar propia y completamente la implementación de
los casos de uso)
• Potencialmente son un framework inicial para la ayuda en línea y el manual
del usuario
1.- Como hacer los Casos de Uso
1.- Identificar los actores y sus metas
Que computadoras, subsistemas y gente manejará nuestro sistema
Que es lo que cada actor necesita que nuestro sistema haga
Resultado: una lista de casos de uso, un diagrama del sistema
2.- Para cada Caso de Uso
2.- Escribe el caso simple: logro de objetivos
El escenario de éxito principal
fácil de leer y entender
Captura cada intención del actor y su responsabilidad, desde el lanzamiento hasta
lograr los objetivos
decir que información pasa entre ellos
numera cada línea
Resultado: descripción legible de la función del sistema
(Cockburn)
12
3.- Escribir condiciones de falla como extensiones
Generalmente, cada paso puede fallar
Notar la condición de falla separadamente, después del escenario
de éxito principal
Resultado: lista de escenarios alternativos
4.- Para cada condición de falla, seguir la falla hasta que termina ó reúne
Extensiones recuperables se reúnen al curso principal
Extensiones no recuperables fallan directamente
Cada escenario va desde su lanzamiento hasta completarlo
Resultado: Casos de uso completos
Algunas extensiones son de demasiado bajo nivel para ser cubiertas aquí
“reembolsa al cliente”
Reembolsa en efectivo, cheque, o crédito de compra?
Variaciones diferidas distinguen casos que pueden ser manejados
eventualmente, por casos de uso de bajo nivel
Resultado: Alimenta información, puesta en un formato fácil de seguir
5.- Anotar las variaciones diferidas
Examinando los objetivos que el sistema apoya, se hacen buenos
requerimientos funcionales
Los objetivos resumen las funciones del sistema en términos de
uso entendibles y verificables
•Coloca una orden
•Obtén dinero de mi cuenta de banco
•Obtén una cotización
•Encuentra la alternativa más atractiva
•Inicia una campaña de publicidad
Enfoque: como hacer los requerimientos legibles y revisables
Los casos de uso ponen los objetivos y los escenarios juntos
Cada escenario descubre una condición
El nombre del caso de uso es la declaración del objetivo
“ordena el producto del catalogo”
escenario1 : cada cosa trabaja bien
escenario2 : crédito insuficiente
escenario3 : producto agotado
Un caso de uso es el objetivo más los escenarios
El nombre del caso de uso es la declaración del objetivo:
“ordena el producto del catalogo”
escenario 1.- cada cosa trabaja bien
escenario 2.- crédito insuficiente
escenario 3.- producto fuera de existencia
El caso de uso es la declaración del objetivo más los escenarios
Diagramas de Casos de Uso
Casos de Uso .-es una interacción típica entre un usuario y un sistema de computo
• es un papel que el usuario desempeña con respecto al sistema
• puede jugar más de un papel
• ejecutan los casos de uso
• un caso de uso puede ser ejecutado por varios actores
• un actor puede ser también un sistema externo que necesita alguna
información del sistema actual
• son entidades externas que interactúan con el sistema para alcanzar
una meta deseada
Actor
Casos de Uso Actor Relaciones de Casos de Uso
Relaciones de Casos de Uso.- estas pueden ser de dos tipos: uses y extends
• Una relación uses de Caso de Uso A a Caso de Uso B, indica que una instancia del caso de uso A incluye también el comportamiento como es especificado en B
• Una relación de extends de Caso de Uso A a Caso de Uso B, indica que una instanciade Caso de Uso B puede incluir el comportamiento especificado por Caso de Uso A
13
Un diagrama de Casos de Uso
muestra la relación entre actores y casos de uso dentro de un sistema
Notación.- un diagrama de casos de uso es una gráfica que representa
actores, un conjunto de casos de uso dentro del límite del sistema, la
comunicación entre los actores y los casos de uso.
Caso de uso.- se muestra como un elipse y dentro de este el nombre del
caso de uso
Actores.- son representados por una figura de persona y el nombre del actor
debajo de ella, sus nombres deben empezar siempre con mayúsculas
Relaciones de Casos de Uso.- las relaciones de casos de uso son representadas
por flechas. Una relación de tipo uses es representada por una flecha que va
del caso de uso que hace uso hacia el otro caso de uso que esta siendo usado.
La relación de tipo extends se muestra por una flecha que va del caso de uso
que va del caso de uso que provee la extensión hacia el caso de uso base
checa status
Cliente
Vendedor
Empacador
Supervisor
coloca orden
llena orden
establece crédito
Diagrama de Casos de Uso
coloca orden
arregla pago
ordena producto
provee datos de
cliente
requiere catalogo
con orden
usesuses
uses
extends
Relaciones de Casos de Uso (uses y extends)
Plantilla básica para Casos de Uso
Caso de Uso: < #> <el nombre debe ser la meta como una frase corta de verbo activo>
Meta en el contexto: < una declaración más larga de la meta en el contexto si es
necesario>
Alcance y nivel:< que sistema esta siendo considerado bajo el diseño de caja negra>
<uno de: resumen, tarea primaria, subfunción>
Precondiciones:< lo que esperamos está ya en el estado del mundo>
Condición final de éxito:< el estado del mundo cuando se completa exitosamente>
Condición final de falla:< el estado del mundo si la meta es abandonada>
Actores primarios y secundarios:<el nombre del rol o descripción del actor primario>
<otros sistemas sobre los que se apoya para completar el caso>
Lanzador:< la acción sobre el sistema que inicia el caso de uso, puede ser un evento
tiempo>
Extensiones
<poner aquí extensiones, una a la vez , cada una refiriendose
al paso de el escenario principal>
<paso alterado><condición>:<acción o sub-caso de uso>
<paso alterado><condición>:<acción o sub-caso de uso>
Sub-variaciones
<poner aquí las subvariaciones que causarán una bifurcación eventual en el escenario>
<paso de variación#><lista de subvariaciones>
<paso de variacion#><lista de subvariaciones>
Escenario de éxito principal:
<poner los pasos del escenario desde el lanzamiento hasta la obtención del objetivo>
Información extra (opcional)
<lista de información acerca de este caso de uso esperando decisión>
Programa de trabajo<fecha o entrega necesaria>
Cualquier otra administración de la información <según sea necesaria>
Información Relacionada (opcional)
Proiridad:<que tan crítico para el sistema/organización>
Comportamiento:<la cantidad de tiempo que este caso de uso debe tomar>
Frecuencia:<que tan seguido se espera que pase>
Caso de uso superior:<opcional, nombre del caso de uso que incluye a este>
Caso de uso suboridinado:<opcional, dependiente de herramientas, ligas a subcasos de uso>
Canal a actor primario:<eg. interactivo, archivos estáticos, bases de datos>
Actores secundarios:<lista de otros sistemas necesarios para completar el caso de uso>
Canal a actores secundarios:<eg. interactivo, archivos estáticos, bases de datos>
14
Ejemplo:
Caso de Uso: 5 Compra de artículos
Información característica
Meta en contexto:el comprador expide una requisición directamente a nuestra
compañía, espera que los artículos sean enviados y cobrados
Alcance: compañía
Nivel: resumen
Precondiciones: se conoce al comprador, su dirección, etc.
Condición final de éxito:comprador obtiene los artículos, nosotros obtenemos el
dinero por los artículos
Condición final de falla: no se han enviado los artículos, el comprador no ha gastado
el dinero
Actor primario: comprador, cualquier agente (o computadora) actuando para el cliente
Lanzador: llega la requisición de compra
Escenario de éxito principal
Información característica
1. El comprador llega con una requisición de compra
2. La compañía captura el nombre del comprador, dirección, artículos requeridos, etc
3. La compañía da información al comprador acerca de artíclos, precios, fecha de
entrega, etc.
4. El comprador firma la orden
5. La compañía crea la orden, envía la orden al comprador
6. La compañía envía la factura al comprador
7. El comprador paga la factura
Extensiones
3a. La compañía no tiene en existencia uno de los artículos ordenados
3a1. Renegociar orden
4a El comprador paga directamente con tarjeta de crédito
4a1 Tomar el pago con tarjeta de crédito (caso de uso 44)
7a El comprador regresa los artículos
7a1Administra el regreso de los artículos caso de uso 105)
Sub-variaciones
1. Comprador puede usar el teléfono, el fax, forma de orden en web, intercambio
electrónico
7. Comprador puede pagar con efectivo, giro postal, cheque, tarjeta de crédito
Información relacionada
Prioridad: la mas alta
Comportamiento: 5 minutos por orden, 45 días hasta pago
Frecuencia: 200/día
Caso de uso superior:administrar la relación con el cliente(caso de uso 2)
Caso de uso subordinado:crear orden (caso de uso 15)
Caso de uso subordinado:tomar pago por tarjeta de crédito (caso de uso 44)
administra el regreso de artículos (caso de uso 105)
Canal a actor primario: puede ser teléfono, archivo o interactivo
Actor secundario: compañía de tarjeta de crédito, banco, servicio de envío
Canal a actor secundario:
Información extra (opcional)
Que pasa si tenemos parte de la orden?
Que pasa si la tarjeta de crédito es robada
Programa de trabajo
Fecha definida: liberación 1.0
Meta: “coloca orden”
Submeta:
establece crédito
.......existencias
sc1 sc2 sc3 sc4 sc5 sc6 sc7
S S F
S F S
S
Escenarios de éxito Escenarios de falla
(Cockburn)
Requerimientos Análisis Diseño Implementación Prueba
Modelo de
casos de uso
Modelos de
análisis y diseño
Modelo de
implementación
Modelo de
pruebas
Diagramas de
casos de uso
Diagramas de
secuencia
Diagramas de
actividad
Diagramas de
estado
Diagramas de
clases
Diagramas de
objetos
Diagramas de
secuencia
Diagramas de
colaboración
Diagramas de
estado
Diagramas de
actividad
Diagramas de
componentes
Diagramas de
despliegue
Diagramas de
secuencia
Diagramas de
colaboración
Todos los otros
modelos y
diagramas
Ivar jacobson- Rational
15
Revisión:
Hacer los escenarios correr desde el evento de lanzamiento hasta
completar el objetivo o abandono
vg. Caso de Uso: “coloca una orden”
Lanzador: la requisición (teléfono, etc)
Fin: inicia o cancela orden
Esc: todo bien
Inicia orden
Esc: insuficiente $ Esc: no producto
Rechaza orden Gira vale
(Cockburn)
Diagrama de Clases
Un diagrama de clases describe los tipos de objetos en el
sistema y las varias clases de relaciones estáticas que existen
entre estas. Un diagrama de clases muestra también los
atributos y operaciones de una clase y las restricciones que
aplican a la forma en que los objetos están conectados
(Fowler 97)
* * *1
• Asociaciones.- representa una relación entre objetos de clases,
pueden ser de la misma clase o de clases diferentes
• Subtipos.- representan un tipo especial de clases de objetos
• Rol.- representa el papel que un objeto o una clase de objetos juega en
una relación con otros objetos
• Multiplicidad.- es la indicación de cuantos objetos pueden participar en
una relación dada
• Navegación.- indica la responsabilidad que tiene un objeto para con otro
• Atributos.- elementos que identifican a un objeto
• Operaciones.- son los procesos que una clase sabe como llevar a cabo
Referencias:
1.- UML DESTILLED
Applying the standard object modeling languaje
Martin Fowler with Kendall Scott
Addison-Wesley 1997
1.- http://members.aol.com.acockburn
Alistair Cockburn, Use Cases, in Theory and Practice
(Lecture Note)
Casos de Uso del Dominio de un Banco
Cliente
Depositadinero
CajeroRetiradinero
Gerente Banco
Checa saldo cuenta
Tomapréstamo
usa
16
Entrada de ordenpor ventana Orden
Línea de
ordenArtículo dealmacén
Artículo
de reorden
Entrega de artículo
prepare()
prepare()
*[para todas laslíneas de orden]
Checaexistencias
Existencias?sacar
necesitareordenar
[necesitareordenar]nuevo
Existenciasnuevo
creación
condición
autodelegación
regreso
Diagrama de secuencia
