View
30
Download
0
Category
Preview:
DESCRIPTION
Introducción al análisis y diseño orientado a objetos. ¿Por qué la Orientación a Objetos?. Proximidad de los conceptos de modelado respecto de las entidades del mundo real Mejora captura y validación de requisitos Acerca el “espacio del problema” y el “espacio de la solución” - PowerPoint PPT Presentation
Citation preview
Depto de Lenguajes y Sistemas Informáticos. AESI
1
Introducción al análisis y diseño orientado a objetos
Depto de Lenguajes y Sistemas Informáticos. AESI
2
¿Por qué la Orientación a Objetos?
• Proximidad de los conceptos de modelado respecto de las entidades del mundo real– Mejora captura y validación de requisitos
– Acerca el “espacio del problema” y el “espacio de la solución”
• Modelado integrado de propiedades estáticas y dinámicas del ámbito del problema
• Facilita construcción, mantenimiento y reutilización
Depto de Lenguajes y Sistemas Informáticos. AESI
3
¿Por qué la Orientación a objetos?
• Conceptos comunes de modelado durante el análisis, diseño e implementación
•Facilita la transición entre distintas fases
•Favorece el desarrollo iterativo del sistema
•Disipa la barrera entre el “qué” y el “cómo”
• Sin embargo, existen problemas ...
Depto de Lenguajes y Sistemas Informáticos. AESI
4
“...Los conceptos básicos de la OO se conocen desde hace dos décadas, pero su aceptación todavía no está tan extendida como los beneficios que esta tecnología puede sugerir”
“...La mayoría de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretendía. Esta práctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados” --Wolfgang
Strigel
Problemas en OO
Depto de Lenguajes y Sistemas Informáticos. AESI
5
Introducción• Basado en el concepto de OBJETO• Objeto = unidad atómica que integra estado y
comportamiento• OBJETO = ATRIB. + OPERACIONES• Un objeto puede caracterizar una entidad física (coche) o
concepto (ecuación matemática)• Principios de Ing. del Software
– Abstracción– Ocultamiento de Información– Modularidad
• La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento
Depto de Lenguajes y Sistemas Informáticos. AESI
6
Objetivos
Productividad Calidad
– minimiz. Errores
– facilidad de uso
– portabilidad
– modificabilidad
• Misma represent. en fases del ciclo de vida
Depto de Lenguajes y Sistemas Informáticos. AESI
7
Beneficios
• Reusabilidad– Crear nuevos sistemas utilizando los ya existentes
• Extensibilidad– Fácil ampliación sin necesidad de retocar módulos
Depto de Lenguajes y Sistemas Informáticos. AESI
8
Mitos
• Todos los programas OO son automáticamente reutilizables y extensibles
• La POO rompe con la programación procedural• Un LOO no puede obtenerse como evolución de
uno no OO
Depto de Lenguajes y Sistemas Informáticos. AESI
9
Conceptos Previos
• Clase:– conj. de objetos que comparten una estructura y
comportamiento comunes
• Metaclase– clase cuyas instancias son a su vez otras clases
• Objeto– entidad abstracta o real con un papel definido en el
dominio de un problema
Depto de Lenguajes y Sistemas Informáticos. AESI
10
Objetos I
• Zona visible ( métodos )• Zona no visible ( atributos o variables instancia )• Caracteristicas:
– estado: propiedades del objeto. Valores actuales de sus atributos
– comportamiento: expresa cómo se producen los cambios de estado.
– Identidad: identificador unívoco de un objeto
Depto de Lenguajes y Sistemas Informáticos. AESI
11
Objetos II
• Paso de mensajes– expresa la acción que un objeto realiza sobre otro
• Métodos– operaciones sobre los atributos de un objeto
– tipos de operaciones:– modificadoras
– selectoras
– iteradoras
– constructoras y destructoras
Depto de Lenguajes y Sistemas Informáticos. AESI
12
Características OO
• Encapsulación• Herencia• Paso de Mensajes• Enlace Dinámico• Polimorfismo
Depto de Lenguajes y Sistemas Informáticos. AESI
13
Encapsulación
• También llamado abstracción• agrupar bajo una misma entidad los datos y las funciones
(métodos) que trabajan con esos datos
• Efecto– independiza la implementación interna del interface del
objeto
Depto de Lenguajes y Sistemas Informáticos. AESI
14
Herencia
• Sirve para construir clases a partir de clases ya existentes.
• Las nuevas clases incorporan estructura y comportamiento de la clase de la que heredan
• Superclase/Subclase, Clase Padre/Clase Hija, Clase Base/Clase Derivada
Depto de Lenguajes y Sistemas Informáticos. AESI
15
Paso de Mensajes
• El único mecanismo para modificar el estado actual de un objeto son sus METODOS o SERVICIOS.
• Los objetos se comunican entre sí mediante el paso de mensajes.
• Consiste en pedir a un objeto que ejecute un servicio.– Objeto_Destino.servicio(parámetros)
Depto de Lenguajes y Sistemas Informáticos. AESI
16
Enlace Dinámico
• Mecanismo que permite determinar o identificar el trozo de código a ejecutar en un tiempo dado.– T. Compilación: el código a ejecutar se conoce en
tiempo de compilación• averia.clasificar()
– T. Ejecución: el código no se conoce hasta la ejecución del servicio
• documento.salto_de_linea()
Depto de Lenguajes y Sistemas Informáticos. AESI
17
Polimorfismo
• Mecanismo que permite definir el mismo interface para un conj. de objetos con comportamiento totalmente distinto– figura.area()
– figura = cuadrado, rectángulo, triángulo, círculo.
Depto de Lenguajes y Sistemas Informáticos. AESI
18
Análisis OO
• Identificar objetos y clases• Diccionario de datos• Identificar asociaciones entre objetos• Identificar atributos y operaciones• Refinar mediante Herencia
Depto de Lenguajes y Sistemas Informáticos. AESI
19
Identificar clases y objetos
• Tener en cuenta entidades físicas y conceptos• Se suelen corresponder con sustantivos• Agrupar objetos por estructura y comportamiento
común
Depto de Lenguajes y Sistemas Informáticos. AESI
20
Diccionario de datos
• Describir con precisión cada clase de objetos• También se describirán
– asociaciones
– atributos
– operaciones
Depto de Lenguajes y Sistemas Informáticos. AESI
21
Identificar asociaciones
• Asociacion = dependencia y/o referencia entre dos o mas clases
• Se suelen corresponder con verbos de estado– acciones dirigidas: “conduce”
– ubicación física: “junto a, contenido en”
– comunicaciones: “habla con”
– propiedad: “tiene, parte de”
– cumpl. de condicion: “trabaja para, casado con”
Depto de Lenguajes y Sistemas Informáticos. AESI
22
Identificar atributos y operaciones
• Propiedades de los objetos• Se suelen corresponder con nombres seguidos por
frases posesivas– el color del coche
• Operaciones sobre el estado de los atributos• Se suelen corresponder con verbos relacionados
con actividades sobre los atributos– clasificar los partes de avería
Depto de Lenguajes y Sistemas Informáticos. AESI
23
Refinar mediante Herencia
• Organizar las clases que compartan estructura común.
• Concretizar aspectos comunes en una superclase• Refinar clases existentes en clases especializadas• Pistas: adjetivos relacionados con los nombres de
las clases.
Depto de Lenguajes y Sistemas Informáticos. AESI
24
Ejercicio “La Biblioteca”
• “Una biblioteca tiene libros que presta a sus socios. Los socios se caracterizan por un código de socio y su nombre. Los libros, por su ISBN, título y autor. Un préstamo relaciona la acción de prestar un libro a un socio en una fecha y tiene un código de préstamo. Cuando un socio devuelve un libro el bibliotecario disminuye su cantidad de libros prestados. Un socio con tres o mas libros prestados es un socio no fiable...”
Depto de Lenguajes y Sistemas Informáticos. AESI
25
Ejercicio “La Biblioteca”
socio libro
prestamo
socio no fiable
bibliotecario
codSocionombre
ISBNtituloautor
codPrestamofecha
diasDePenalizacion
DNInombre
crearSociodestruirSocio crearLibro
destruirLibro
crearPrestamodestruirPrestamo
hacerSocioNoFiable
despenalizar
crearBibliotecariodestruirBibliotecario
Depto de Lenguajes y Sistemas Informáticos. AESI
26
UML como lenguaje de análisis y diseño de software
Depto de Lenguajes y Sistemas Informáticos. AESI
27
Construir la casita del perro
Una persona puede realizarlaRequiere
Mínimo esfuerzo de modeladoProceso simpleHerramientas simples
Depto de Lenguajes y Sistemas Informáticos. AESI
28
Construir una casa
Un equipo la construye de forma más eficiente y en menos tiempoRequiere
ModeladoProceso bien definidoHerramientas potentes
Depto de Lenguajes y Sistemas Informáticos. AESI
29
Construir un rascacielos
Depto de Lenguajes y Sistemas Informáticos. AESI
30
Modelar una casa
Depto de Lenguajes y Sistemas Informáticos. AESI
31
Sistema Informáticoo
Reglas de Negocio
Item
PedirA
“ Un modelo captura los aspectos
esenciales de un sistema”James Rumbaugh
El modelado visual es la construcción de modelos usando herramientas gráficas estándar.
¿El modelado visual?
Depto de Lenguajes y Sistemas Informáticos. AESI
32
El Modelado Visual es una Herramienta de Comunicación
El modelado visual se usa para analizar y diseñar una aplicación.
Con él capturamos la lógica del problema
Depto de Lenguajes y Sistemas Informáticos. AESI
33
El Modelado Visual y la Complejidad de un Sistema
Depto de Lenguajes y Sistemas Informáticos. AESI
34
Inteefaz Usuario(Visual Basic,
Java)Logica del Problema
(C++, Java)
Sevidor de Bases deDatos
(C++ & SQL)
Modelar el sistema independientemente del lenguaje de programación
Arquitectura del Software
Depto de Lenguajes y Sistemas Informáticos. AESI
35
El lenguaje de modelado unificado
• UML significa Lenguaje de Modelado Unificado (Unified Modeling Language)
• Un lenguaje de propósito general para el modelado orientado a objetos.
• The UML combina– Conceptos de Modelado de Datos (Entity Relationship Diagrams)– Modelado de Objetos– Modelado de Componentes
• UML es el lenguaje estándar para visualizar, especificar, construir y documentar aplicaciones software.
• Puede ser usado a través de diferentes ciclos de vida y de diferentes tecnologías de implementación.
• Basado en la experiencia y necesidades de los usuarios.
Depto de Lenguajes y Sistemas Informáticos. AESI
36
Situación de Partida
• Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas notaciones
• Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc.
• Pugna entre distintos enfoques (y correspondientes gurús)
• => Necesidad de una notación estándar
Depto de Lenguajes y Sistemas Informáticos. AESI
37
Creación de UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther methods
UML 0.9Web - June ´96
publicfeedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1OMG Acceptance, Nov 1997
UML 1.3
UML 1.0UML partners
Depto de Lenguajes y Sistemas Informáticos. AESI
38
Meyer
Before and after conditions
Harel
StatechartsGamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and message numbering
Embley
Singleton classes andhigh-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE
Contribuciones a UML
Depto de Lenguajes y Sistemas Informáticos. AESI
39
Características de UML
• UML es un lenguaje para– visualizar– specificar– construir– documentar
los artefactos de un sistema software
Depto de Lenguajes y Sistemas Informáticos. AESI
40
Métodos Formales en Modelado• Tipos de enfoques: no-formales, semi-formales y
formales• Las principales mejoras al utilizar métodos
formales son:– Mayor rigor en la especificación– Mejores condiciones para realizar la verificación y
validación en forma más exhaustiva– Mejores condiciones para automatización de
procesos para la generación automática de prototipos y/o código final
Depto de Lenguajes y Sistemas Informáticos. AESI
41
Inconvenientes en UML• Definición del proceso de desarrollo usando UML. UML no
es una metodología.
• Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc.
• Ejemplos aislados
• “Monopolio de conceptos, técnicas y métodos entorno a UML
Depto de Lenguajes y Sistemas Informáticos. AESI
42
Perspectivas de UML• UML será el lenguaje de modelado orientado a
objetos estándar predominante los próximos años• Razones:
– Participación de metodólogos influyentes– Participación de importantes empresas– Aceptación del OMG como notación estándar
• Evidencias:– Herramientas que proveen la notación UML– “Edición” de libros– Congresos, cursos, “camisetas”, etc.
Depto de Lenguajes y Sistemas Informáticos. AESI
43
Diagramas
• Un diagrama es una vista del modelo– Proporciona una representación parcial del sistema
– Semánticamente consistente con las otras vistas
• En UML, hay 9 tipos de diagramas– vistas de estructura: casos de uso, clases, objetos,
componentes, implantación
– vistas de comportamiento: secuencia, colaboración, estados, actividad
Depto de Lenguajes y Sistemas Informáticos. AESI
44
Diagramas de UML
Use CaseDiagramsUse Case
DiagramsDiagramas deCasos de Uso
ScenarioDiagramsScenario
DiagramsDiagramas deColaboración
StateDiagramsState
DiagramsDiagramas deComponentes
ComponentDiagramsComponent
DiagramsDiagramas deImplantación
StateDiagramsState
DiagramsDiagramas deObjetos
ScenarioDiagramsScenario
DiagramsDigramas deEstados
Use CaseDiagramsUse Case
DiagramsDiagramas deSecuencia
StateDiagramsState
DiagramsDiagramas deClases
Diagramas deActividad
Un modelo es una descripción completa de un sistema desdeuna perspectiva particular
Modelos
Depto de Lenguajes y Sistemas Informáticos. AESI
45
Casos de Uso• Los Casos de Uso (Ivar Jacobson) describen bajo la
forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario.
• Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
• Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación.
• Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.
Depto de Lenguajes y Sistemas Informáticos. AESI
46
… Casos de Uso
• Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo.
• Están basado en el lenguaje natural, es decir, es accesible por los usuarios.
Depto de Lenguajes y Sistemas Informáticos. AESI
47
Ejemplo de Casos de Uso
Caso de Uso: Comprar productos
Actores: Cliente, Cajero
Tipo: Primario
Descripción: Un cliente llega a la caja registradora con los artículos que comprará. El cajero registra los artículos y cobra el importe. Al terminar la operación el cliente se marcha con los productos.
comprar productos
Depto de Lenguajes y Sistemas Informáticos. AESI
48
… Casos de Uso• Ejemplo:
Sistema
Actor A
Caso de uso X
Actor B
Caso de uso Y
Depto de Lenguajes y Sistemas Informáticos. AESI
49
… Casos de Uso
• Actores:– Principales: personas que usan el sistema– Secundarios: personas que mantienen o administran el
sistema– Material externo: dispositivos materiales imprescindibles
que forman parte del ámbito de la aplicación y deben ser utilizados
– Otros sistemas: sistemas con los que el sistema interactúa• La misma persona física puede interpretar varios papeles
como actores distintos• El nombre del actor describe el papel desempeñado
Depto de Lenguajes y Sistemas Informáticos. AESI
50
… Casos de Uso• Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario
• Un escenario es una instancia de un caso de uso
• Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso
Depto de Lenguajes y Sistemas Informáticos. AESI
51
Casos de Uso: Relaciones
• UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
– Comunicación:
Caso de Uso
Actor
Depto de Lenguajes y Sistemas Informáticos. AESI
52
… Casos de Uso: Relaciones
Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino
En UML se estereotipa como <<include>>
Caso de uso origen
Caso de uso destino
<<include>>
Depto de Lenguajes y Sistemas Informáticos. AESI
53
… Casos de Uso: Relaciones
Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino
Caso de uso origen
Caso de uso destino
<<extend>>
Depto de Lenguajes y Sistemas Informáticos. AESI
54
… Casos de Uso: Relaciones
Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía.
Caso de uso origen
Caso de uso destino
Depto de Lenguajes y Sistemas Informáticos. AESI
55
… Casos de Uso: Relaciones•Ejemplo:
Identificación
Trnasferencia por Internet
Cliente
Transferencia
<<extends>>
<<includes>>
Depto de Lenguajes y Sistemas Informáticos. AESI
56
Casos de Uso: Construcción• Un caso de uso debe ser simple, inteligible, claro y conciso
• Generalmente hay pocos actores asociados a cada Caso de Uso
• Preguntas clave:•¿cuáles son las tareas del actor?
•¿qué información crea, guarda, modifica, destruye o lee el actor?
•¿debe el actor notificar al sistema los cambios externos?
•¿debe el sistema informar al actor de los cambios internos?
Depto de Lenguajes y Sistemas Informáticos. AESI
57
… Casos de Uso: Construcción• La descripción del Caso de Uso comprende:
– el inicio: cuándo y qué actor lo produce?– el fin: cuándo se produce y qué valor devuelve?– la interacción actor-caso de uso: qué mensajes
intercambian ambos?– objetivo del caso de uso: ¿qué lleva a cabo o intenta?– cronología y origen de las interacciones– repeticiones de comportamiento: ¿qué operaciones son
iteradas?– situaciones opcionales: ¿qué ejecuciones alternativas se
presentan en el caso de uso?
Depto de Lenguajes y Sistemas Informáticos. AESI
58
RF- <id del requisito> <nombre del requisito funcional> Versión <numero de versión y fecha> Autores <autor> Fuentes <fuente de la versión actual> Objetivos asociados <nombre del objetivo> Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}
Precondición <precondición del caso de uso> Paso Acción
1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>
3 4 5 6
Secuencia Normal
n Postcondición <postcondición del caso de uso>
Paso Acción 1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta}
2
Excepciones
3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales>
Depto de Lenguajes y Sistemas Informáticos. AESI
59
PARTE IIPARTE II
FASE DE ANÁLISIS
Depto de Lenguajes y Sistemas Informáticos. AESI
60
Contenido
• PARTE II: Fase de Análisis• Modelado de Casos de Uso
• Modelado Estático
• Estructuración en Clases y Objetos
• Diagramas de Transición de Estados
• Modelado Dinámico
Depto de Lenguajes y Sistemas Informáticos. AESI
61
Modelado de
Casos de Uso
Depto de Lenguajes y Sistemas Informáticos. AESI
62
Introducción
•Los requisitos funcionales define lo que el sistema hará para el usuario.
•El sistema es visto como una caja negra: •Sólo se consideran las características externas.
Depto de Lenguajes y Sistemas Informáticos. AESI
63
Los Casos de Uso (cdu)
• Los requisitos funcionales se definen en términos de actores y casos de uso.
• Un actor participa en un caso de uso.
• Un caso de uso define una secuencia de interacciones entre uno o más actores y el sistema.
• El modelo de casos de uso incorpora a actores y casos de uso.
Depto de Lenguajes y Sistemas Informáticos. AESI
64
Actores• Actor: uno o más usuarios que interactúan con el
sistema.
• Puede ser un dispositivo externo I/O o un timer.
• En sistemas empotrados los actores son sólo
sensores y actuadores.
• Actor Primario y actores Secundarios.
• Actor beneficiario.
Depto de Lenguajes y Sistemas Informáticos. AESI
65
Actores• El actor es el ser humano aun cuando éste
interactúa mediante dispositivos periféricos.
• Ej. de un actor dispositivo I/O que
interactúa vía un sensor.
Depto de Lenguajes y Sistemas Informáticos. AESI
66
Actores• Un actor puede ser también un timer que
periódicamente manda eventos al sistema.
• En aplicaciones de tiempo real es aconsejable
tener a los timer como externos al sistema.
Depto de Lenguajes y Sistemas Informáticos. AESI
67
Actores
• Un sistema externo también puede participar
como actor (primario o secundario) en un
caso de uso.
Depto de Lenguajes y Sistemas Informáticos. AESI
68
Identificando casos de uso
• Secuencia de eventos iniciada por un actor donde se especifica la interacción entre éste y el sistema.
• No se busca la descomposición funcional del sistema sino secuencias de eventos que proporcionan un resultado a algún actor.
Depto de Lenguajes y Sistemas Informáticos. AESI
69
Identificando casos de uso
• Por ejemplo, el cliente ATM interactúa con 3 casos de uso que son distintos pues proveen resultados distintos:
Depto de Lenguajes y Sistemas Informáticos. AESI
70
Documentando casos de uso• Nombre del cdu: único.
• Resumen: una o dos frases.
• Dependencias: de otros casos de uso (opcional).
• Actores: que participan.
• Precondiciones: ciertas antes del cdu.
• Descripción: secuencia de pasos. El sistema es visto como una
caja negra.
Depto de Lenguajes y Sistemas Informáticos. AESI
71
Documentando casos de uso
• Alternativas: narrativa de las alternativas a la
secuencia principal.
• Postcondiciones: ciertas tras terminar.
• Cuestiones adicionales: planteadas por discusión
con los usuarios reales.
• visto como una caja negra.
Depto de Lenguajes y Sistemas Informáticos. AESI
72
Ej. Sacar dinero ATM (1/4)• Nombre del cdu: sacar dinero.
• Resumen: El cliente sacar una cantidad específica de dinero
del cajero de su cuenta bancaria.
• Dependencias: ninguna.
• Actores: Cliente ATM.
• Precondiciones: El ATM está listo con el mensaje de
bienvenida.
Depto de Lenguajes y Sistemas Informáticos. AESI
73
Ej. Sacar dinero ATM (2/4)• Descripción:
1. El cliente inserta la tarjeta en el lector del ATM.2. Si la tarjeta es reconocida se lee el número de la misma.3. El sistema pide la clave al cliente.4. El cliente introduce la clave (PIN).5. El sistema verifica la fecha de caducidad y si es robada o
extraviada.6. Si es válida el sistema comprueba la clave introducida con la
que lleva la tarjeta escrita.7. Si el PIN es válido el sistema ve qué cuentas están disponibles
para dicha tarjeta.8. El sistema muestra las cuentas disponibles y le solicita al cliente
elija entre “sacar dinero”, “consultar saldo” y “transferencia”.
Depto de Lenguajes y Sistemas Informáticos. AESI
74
Ej. Sacar dinero ATM (3/4)• Descripción:
9. El cliente selecciona “sacar dinero”, introduce la cantidad y selecciona el número de la cuenta.
10. El sistema comprueba si el cliente tiene suficiente dinero en dicha cuenta y si ha sobrepasado el límite diario.
11. Si todo es correcto el sistema autoriza dispensar el dinero.12. El sistema dispensa el dinero.13. El sistema muestra un recibo incluyendo el número de
operación, el tipo, la cantidad y el número de la cuenta.14. El sistema devuelve la tarjeta.15. El sistema muestra su mensaje de bienvenida.
Depto de Lenguajes y Sistemas Informáticos. AESI
75
Ej. Sacar dinero ATM (4/4)• Alternativas:
– Si el sistema no reconoce la tarjeta entonces es devuelta.
– Si la tarjeta ha caducado es confiscada.
– Si la tarjeta está extraviada o robada es confiscada.
– Si el PIN no es correcto se vuelve a pedir.
– Si se introduce el PIN tres veces mal la tarjeta es confiscada.
– Si el sistema determina que no hay suficiente dinero entonces muestra un
mensaje y devuelve la tarjeta.
– Si el cajero no tiene dinero se muestra un mensaje, se devuelve la tarjeta y se
apaga el cajero.
– Si el cliente introduce “cancelar” se cancela la transacción y se devuelve la
tarjeta.
Depto de Lenguajes y Sistemas Informáticos. AESI
76
Relaciones entre casos de uso
• Cuando los casos de uso se hacen complejos pueden definirse dependencias entre ellos.
• Vimos se distinguen en UML tres relaciones de dependencia:– Incluye.– Extiende.– Generaliza.
Depto de Lenguajes y Sistemas Informáticos. AESI
77
Diagrama de casos de uso
• Especifica una interacción entre el usuario y la aplicación para alcanzar un objetivo concreto. Imaginemos un sistema de información para una empresa de alquiler de coches algunos de los casos de uso serían:
– Cliente reserva coche
– Cliente recoge coche
– Cliente entrega coche
Depto de Lenguajes y Sistemas Informáticos. AESI
78
Diagrama de casos de uso
• Cliente reserva cocheEl cliente contacta con la agencia y hace la petición. La agencia acepta o no la petición según la disponibilidad de coches o el historial del cliente. Caso de aceptación la agencia completa el formulario con los datos relevantes del cliente. Finalmente el cliente paga un depósito para formalizar la reserva.
Depto de Lenguajes y Sistemas Informáticos. AESI
79
Diagrama de casos de uso
• Cliente recoge cocheCuando el cliente llega a la agencia , ésta localiza el model de coche solicitado. Después de pagar la fianza el cliente recibe el coche para su uso.
• Cliente recoge cocheEl cliente devuelve el coche a la agencia en el día establecido según el contrato de alquiler.
Depto de Lenguajes y Sistemas Informáticos. AESI
80
Diagrama de casos de uso
Depto de Lenguajes y Sistemas Informáticos. AESI
81
Arquitectura y UML
Vista de diseño Vista de implementación
Vista de proceso
Componentes Clases, interfaces,colaboraciones
Clases activas
Vista de implantación
Nodos
Vista casos usoCasos de uso
Depto de Lenguajes y Sistemas Informáticos. AESI
82
Ejemplo del caso de una Máquina Recicladora :
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
•Registrar el número de ítemes ingresados. •Imprimir un recibo cuando el usuario lo solicita:
a.Describe lo depositado b.El valor de cada item c.Total
•El usuario/cliente presiona el botón de comienzo •Existe un operador que desea saber lo siguiente:
a.Cuantos ítemes han sido retornados en el día. b.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: a.Información asociada a ítemes. b.Dar una alarma en el caso de que:
i.Item se atora. ii.No hay más papel.
Depto de Lenguajes y Sistemas Informáticos. AESI
83
Como una primera aproximación identificamos a los actores que interactuan con el sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:
Depto de Lenguajes y Sistemas Informáticos. AESI
84
Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Depto de Lenguajes y Sistemas Informáticos. AESI
85
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.
Depto de Lenguajes y Sistemas Informáticos. AESI
86
El diseño completo del diagrama Caso de uso es:
Depto de Lenguajes y Sistemas Informáticos. AESI
87
Ejemplo: casos de uso de un sistema de financiación
Recommended