Ingeniera del Software

1
Ingeniería del Software
CLASES y OBJETOS

• TEMA 7 Orientación a Objetos y UML

Profesor Juan Antonio López Quesada. Facultad
de Informática. http//dis.um.es/lopezquesada
2
Clases y Objetos
Programa OO
Colección estructurada de clases
Clase
Implementación de un TAD
Objeto
Una instancia de una clase
Los objetos se comunican mediante mensajes
3
TAD y Clase
Teoría TAD Operaciones Sintaxis y
Semántica
Software Clase Elegir representación e
implementar operaciones
4
TAD y Clase
Teoría TAD Funciones Axiomas Precondi
ciones
Software Clase Atributos y Métodos
Asertos
5
Definición de Clase

• Implementación total o parcial de un tipo
  abstracto de dato (TAD).
• Las clases son entidades sintácticas.
• Una clase describe objetos que van a tener la
  misma estructura y el mismo comportamiento.
• Un programa OO es una colección estructurada de
  clases.

6
Clases Doble naturaleza

• Una clase es un módulo y un tipo de dato
• Módulo (concepto sintáctico)
• Mecanismo para organizar el software
• Encapsula componentes software
• Tipo (concepto semántico)
• Mecanismo de definición de nuevos tipos de datos
  describe una estructura de datos (objetos) para
  representar valores de un dominio y las
  operaciones aplicables.

7
Clases Ejemplo

• Al modelar un banco, encontramos objetos
  cuenta.
• Todos los objetos cuenta tienen unas
  propiedades comunes
• saldo, titular, código, reintegro, ingreso,
• Definimos una clase Cuenta.
• Clases del dominio y clases de diseño/implementaci
  ón
• Principio de Correspondencia Directa

8
Componentes de una clase

• Las propiedades del objeto se pueden representar
  mediante
• espacio ATRIBUTOS
• cálculo RUTINAS (MÉTODOS)
• cómo representamos el saldo de una cuenta?

9
Tipo Modulo
oc Cuenta
Atributos
Ejemplo Clase Eiffel
Operaciones
10
Definición de Objeto

• Es una instancia de una clase, creada en tiempo
  de ejecución
• Es una estructura de datos formada por tantos
  campos como atributos tiene la clase.
• Es una entidad de tiempo de ejecución.
• Cada objeto es instancia de una clase (incluso
  los objetos básicos enteros, booleanos,caracteres
  ,?).
• Durante la ejecución de un programa OO se creará
  un conjunto de objetos.

11
Cada objeto es instancia de una clase
Estructura de datos
Código
Cuenta oc oc new Cuenta()

• Cada objeto es instancia directa de una clase.
• Una clase es una factoría de objetos

12
Identificador de objeto, oid
oid
Existe una tabla que relaciona oid y posición de
memoria
13
Clases en Java

• Lenguaje tipado estáticamente
• Legible
• No separación en fichero interfaz e
  implementación.
• Lenguaje interpretado Máquina Virtual Java
• Atributos y variables de clase
• Métodos de instancia y de clase

14
Paquetes Java

• Clases relacionadas pueden agruparse en paquetes
• package estructurasDatos
• public class Lista ...
• package estructurasDatos
• class Nodo ...
• ...

15
Paquetes Java

• Espacio de nombres evita conflictos de nombres
• Define un ámbito propiedades ocultas al exterior
  pero accesibles a las clases del paquete.
• Jerarquías de paquetes p1.p2.p3pn
• Calificación de nombres java.util.Date
• Importación de paquetes import java.util.Date
• Un fichero (unidad de compilación) no puede
  incluir más de una clase pública.

16
Ejemplo Java
17
Relaciones entre clases

• Cliente
• Una clase A es cliente de una clase B, si A
  contiene una declaración en la que se establezca
  que cierta entidad (atributo, parámetro, variable
  local) e es de tipo B

Ejemplo
titular
CUENTA
PERSONA
Cuenta es cliente de Persona
18
Relaciones entre clases

• Herencia
• Una clase es una versión especializada de otra
  existente

Ejemplo
19
Método

• Está compuesto por
• CABECERA Identificador y Parámetros
• CUERPO Secuencia de instrucciones
• Ejemplo en Eiffel

reintegro (cantidad INTEGER) is do if
puedoSacar(cantidad) then saldo saldo -
suma end
20
Métodos

• Qué instrucciones podemos incluir en el cuerpo
  de un método?
• Asignación
• Creación de objetos
• Condicional
• Iteración
• Mensajes (invocación a otro método)

21
Mensaje

• Invocación de la aplicación de un método sobre un
  objeto.
• Mecanismo básico de la computación OO.
• La modificación o consulta del estado de un
  objeto se realiza mediante mensajes.
• Formado por tres partes
• Objeto receptor
• Selector o identificador del método a aplicar
• Argumentos

22
Sintaxis mensajes

• Notación Punto Eiffel, Java

receptor. selector(argumentos)
Si c es de tipo Cuenta c Cuenta c.
reintegro (1000)
23
Semántica mensajes

• Sea el mensaje x.f, su significado es
• Aplicar el método f sobre el receptor x,
  efectuando el paso de parámetros
• NO CONFUNDIR CON LA INVOCACIÓN DE UN
  PROCEDIMIENTO!

24
Creación de Objetos

• Mecanismo explícito de creación de objetos
• Eiffel instrucción de creación, !!
• C, Java instrucción de creación, new
• Smalltalk método de clase new
• Recuperación de memoria
• Smalltalk, Eiffel y Java Recogida de basura
• C Destructores

25
Modelo de ejecución

• La ejecución de un programa OO consiste en
• Creación dinámica de objetos
• Envío de mensajes entre los objetos creados,
  siguiendo un patrón impredecible en tiempo de
  compilación
• Ausencia de programa principal
• Cómo empieza la ejecución de un programa OO?
• Creación de un objeto raíz
• Aplicar mensaje sobre objeto raíz

26
Ingeniería del Software
HERENCIA

• TEMA 7 Orientación a Objetos y UML

Profesor Juan Antonio López Quesada. Facultad
de Informática. http//dis.um.es/lopezquesada
27
Introducción

• Necesitamos un mecanismo que posibilite la
  definición de una nueva clase a partir de otra
  existente
• HERENCIA
• La herencia organiza las clases en una estructura
  jerárquica
• JERARQUIAS DE CLASES
• No es solo un mecanismo para compartir código.
• Consistente con el sistema de tipos del lenguaje

28
Jerarquías de clases Ejemplos
PUBLICACION
LIBRO
REVISTA
MAGAZINE
INVESTIGACION
LIBRO_TEXTO
FIGURA
POLIGONO
CIRCULO
RECTANGULO
29
Introducción
Si B hereda de A entonces B incorpora la
estructura (atributos) y comportamiento (métodos)
de la clase A, pero puede incluir
adaptaciones - B puede añadir nuevos
atributos - B puede añadir nuevos métodos - B
puede redefinir métodos - B puede renombrar
atributos o métodos - B puede implementar un
método diferido en A Adaptaciones
dependientes del lenguaje
30
Clase Raíz

• Puede existir una clase raíz en la jerarquía de
  la cual heredan las demás directa o
  indirectamente.
• Incluye todas las características comunes a todas
  las clases
• Eiffel clase ANY
• Smalltalk clase Object
• Java clase Object
• C no existe

31
Tipos de herencia
A

• Herencia simple
• Una clase puede heredar de una única clase.
• Ejemplos Smalltalk, Java
• Herencia múltiple
• Una clase puede heredar de varias clases.
• Clases forman un grafo dirigido aciclíco
• Ejemplos Eiffel, C

C
B
E
D
B
C
A
32
Terminología

• B hereda de A
• B es descendiente de A (Eiffel)
• A es un ascendiente de B (Eiffel)
• B es subclase de A (Smalltalk,
  Java)
• A es superclase de B (Smalltalk,
  Java)
• B es una clase derivada de A (C)
• A es la clase base de B (C)

33
El proceso de heredar es transitivo
A

• B hereda de A
• C hereda de B y A
• B y C son descendientes (subclases) de A
• B es un descendiente directo de A
• C es un descendiente indirecto de A

B
C
34
Cómo detectar la herencia?

• Generalización (Factorización)
• Se detectan clases con un comportamiento común
  (p.e. Libro y Revista en Publicación )
• Especialización (Abstracción)
• Se detecta que una clase es un caso especial de
  otra (p.e. Rectangulo de Poligono)

No hay receta mágica para crear buenas
jerarquías Pueden existir diversos criterios
Problemas con la evolución de la jerarquía
35
Doble aspecto de la herencia
36
Herencia y Subtipos
Circulo
Elipse
(a)
(a), (c), (d) herencia para compartir
código (b) herencia para especializar un tipo
37
Herencia y sistema de tipos
A
metodo1
C
B
F
E
D

• oa A ob B oc C od D
• Son legales las siguientes asignaciones?
• oa ob oc ob oa od
• Es legal el mensaje od.metodo1?

38
Polimorfismo

• Capacidad de una entidad de referenciar en tiempo
  de ejecución (t.e.) a instancias de diferentes
  clases.
• Sean las declaraciones
• ox X haceAlgo (oyY)
• En un lenguaje con monomorfismo (Pascal, Ada, ..)
  en t.e. ox y oy denotarán valores de los tipos X
  e Y, respectivamente.
• En un lenguaje con polimorfismo (Eiffel, C,
  Java,..) en t.e. ox y oy pueden refeenciar
  objetos de varios tipos diferentes.
• tipo estático vs. tipo dinámico

39
Polimorfismo

• Polimorfismo es restringido por la herencia
• Cada entidad puede estar conectada a instancias
  de la clase asociada en su declaración o de
  cualquiera de sus subclases.
• Cada entidad tiene un tipo estático y un conjunto
  de tipos dinámicos.
• Sistema de tipos más flexible.
• Siempre que se espera un objeto de una clase
  puede llegar uno de cualquiera de sus subclases
• Importante para escribir código genérico

40
Rutina polimorfa

• Posee entidades polimorfas parámetros, variables
  locales.
• Objeto actual (Current, this, self) puede ser una
  entidad polimorfa.
• Un mismo código con diferentes implementaciones
  variación en implementación
• maximo (v NUMERIC)
• mezclar (s SECUENCIAG)
• buscar (v G)

41
Polimorfismo

• Tipo estático
• Tipo asociado en la declaración
• Tipo dinámico
• Tipo correspondiente a la clase del objeto
  conectado a la entidad en tiempo de ejecución
• Conjunto de tipos dinámicos
• Conjunto de posibles tipos dinámicos de una
  entidad

42
Polimorfismo
A
C
B
F
E
D

• oa A ob B oc C
• te(oa) A ctd(oa) A,B,C,D,E,F
• te(ob) B ctd(ob) B, D, E
• te(oc) C ctd(oc) C,F

43
Sobrecarga

• Nombre de una rutina es polimorfo.
• Se resuelve en tiempo de compilación, según la
  signatura de la rutina.
• No es necesario que exista similitud semántica.
• En los lenguajes OO puede existir sobrecarga
• dentro de una clase
• entre clases de una jerarquía (redefinición, es
  fundamental)
• entre clases no relacionadas
• C y Java proporcionan sobrecarga
• Polimorfismo complica la resolución de la
  sobrecarga.

44
p Poligono r Rectangulo c
Cuadrado asignación polimorfa p r
p.visualizar p.rotar (..) p.
perimetro pc
45
Ligadura dinámica

A
fA
redefine f
C
B
fB
redefine f
D
fD
Supuesto oa A, sea el mensaje oa.f(..), la
versión de f que se ejecuta depende del tipo
dinámico de oa.
46
Ligadura dinámica
fA
A
?

redefine f
C
fC
?
B
fB
?
redefine f
D
fD
?
!!ob !!oc !!od oa ob oa.f oa oc
oa.f oa od oa.f
?
?
?
47
Clases abstractas o diferidas

• Sea la declaración
• of FIGURA op POLIGONO
• y el código
• !!op
• ofop
• of.dibujar Sería legal?
• Cómo se implementa dibujar en la clase FIGURA?

48
Clases abstractas

• Al aplicar la herencia, como mecanismo de
  clasificación, aparecen clases que representan
  categorías generales o conceptos abstractos, como
  son "figura", colección, publicación",
  dispositivo,...
• Otras veces, dos clases comparten funcionalidad
  pero no pueden ser declaradas una como subclase
  de la otra
• Qué operaciones incluyen?
• La rutina dibujar no puede ser implementada en
  Figura pero of.dibujar es dinámicamente
  correcto!
• Solución MÉTODOS ABSTRACTOS
• (RUTINAS DIFERIDAS)

49
Clases abstractas

• Contienen métodos abstractos que deben ser
  implementados en sus subclases.
• Puede ser total o parcialmente abstractas.
• Especifica una funcionalidad que es común a un
  conjunto de subclases aunque no es completa.
• No es posible crear instancias de una clase
  abstracta, pero si declarar entidades de estas
  clases.
• Importantes para escribir código genérico.

50
Las clases abstractas son un elemento del
lenguaje en los lenguajes tipados estáticamente
51
Ejemplo
trasladar, rotar, ..
Figura

• En Figura
• trasladar (a,b REAL) is
• deferred
• end

Figura_Abierta
Figura_Cerrada
Segmento
Poligono
Elipse
Triangulo
Rectangulo
Circulo
Cuadrado
52
Herencia y Ocultación de Información

• La herencia expone los detalles de
  implementación a las subclases
• La herencia rompe la ocultación de información

Herencia (reutilización de caja blanca)
Cliente (reutilización de caja negra)
53
Herencia y Ocultación de Información en C y Java

• class A
• public
• // públicas accesibles desde todas las clases
• protected
• // protegidas sólo accesibles por la clase y
  sus descendientes
• private
• // privadas sólo visibles en la propia clase
• end

54
OO y Objetivos Iniciales

• La combinación de clases, genericidad, herencia,
  redefinición, polimorfismo, ligadura dinámica y
  clases diferidas permite satisfacer los
  principios/ reglas/ criterios de modularidad y
  los requisitos para la reutilización, planteados
  en el primer tema.

55
Categorías de herencia

• Herencia de modelos
• Herencia para crear subtipos (subtyping)
• Herencia de vistas
• Herencia por restricción
• Herencia por extensión
• Herencia de variación
• Herencia por variación funcional
• Herencia variación de tipos
• Herencia de software
• Herencia de materialización
• Herencia de estructura
• Herencia de de implementación
• Herencia de facilidades (de constantes u
  operaciones)

56
Herencia de subtipos

• Supondremos una jerarquía en la que la clase B
  hereda de la clase A
• Herencia de subtipos se aplica si A y B
  representan ciertos conjuntos A y B de objetos
  externos tales que B es un subconjunto de A y
  el conjunto modelado por cualquier otro heredero
  (subtipo) de A es disjunto de B. A debe ser
  diferida

57
Herencia de subtipos
Figura
Figura_Abierta
Figura_Cerrada
Segmento
Poligono
Elipse
Circulo
58
Herencia por Restricción

• Se aplica si las instancias de B son aquellas
  instancias de A que satisfacen una cierta
  restricción, expresada si es posible como parte
  del invariante de B y no incluida en el
  invariante de A.
• Cualquier propiedad introducida por B debe ser
  una consecuencia lógica de la restricción
  añadida. A y B deben ser o bien diferidas o bien
  efectivas.

59
Herencia por Restricción
POLIGONO
RECTANGULO

ELIPSE
RECTANGULO
CUADRADO
CIRCULO
60
Herencia por extensión

• Se aplica cuando B introduce propiedades no
  presentes en A y que no son aplicables a
  instancias directas de A. La clase A debe ser
  efectiva.

PUNTO
DOCUMENTO
PARTICULA
CAPITULO
61
Herencia por variación

• Se aplica cuando B redefine alguna propiedad de
  A A y B son ambas diferidos o ambas son
  efectivos, y B no debe introducir nuevas
  propiedades excepto por necesidades surgidas de
  las redefiniciones. Hay dos casos
• Variación funcional alguna de las
  redefiniciones afecta a la
  implementación
• Variación de tipos todas son redefiniciones de
  signaturas

62
Variación de tipos
DISPOSITIVO
alternativa DISPOSITIVO
IMPRESORA
alternativa IMPRESORA
63
Herencia por materialización

• Se aplica si A representa alguna categoría
  general de estructura de datos, y B representa
  una implementación parcial o completa para
  estructuras de datos de esa categoría. A es
  diferida y B puede ser bien diferida, dejando
  abierta la posibilidad de reificación a sus
  descendientes, o bien efectiva.

64
Herencia por materialización
TABLAG
TABLA_HASHG
TABLA_SECUENCIAL G
TABLA_FIJAG
TABLA_ENLAZADAG
65
Herencia de Estructura

• Se aplica si A, una clase diferida, representa
  una propiedad estructural general y B, que puede
  ser diferida o efectiva, representa cierto tipo
  de objetos que poseen dicha propiedad.
• A puede ser COMPARABLE, NUMERIC, TRAVERSABLE, ..

66
Herencia de Estructura
NUMERIC
COMPARABLE
INTEGER
STRING
67
Herencia de Implementación

• Se aplica si B obtiene de A un conjunto de
  propiedades (que no son constantes o funciones
  once) necesarias para la implementación de la
  abstracción asociada con B. Tanto A como B deben
  ser efectivas.
• Ejemplo
• El caso del matrimonio por conveniencia
  combina herencia por materialización con herencia
  por implementación

68
Herencia de Implementación
DICCIONARIO G
ARRAY G
PILA G
PILA_FIJA G
TABLA_SIMBOLOS
PILA_FIJA y TABLA_SIMBOLOS ocultan todas las
propiedades heredadas de ARRAY y DICCIONARIO.
69
Herencia de Implementación

• Tipo de herencia muy criticado.
• Una pila_fija es-un array, ya que tienen la
  misma representación.
• Adecuada cuando la implementación elegida es una
  parte esencial de la nueva clase.
• La librería Base no hubiese sido posible sin
  ella (Meyer, 1994)

70
Herencia de facilidades

• Se aplica si A existe con el único propósito de
  proporcionar un conjunto de propiedades
  lógicamente relacionadas a sus descendientes
  tales como B. Dos variantes frecuentes son
• Herencia de constantes
• Constantes y funciones once (objetos
  compartidos)
• Herencia Maquina
• Rutinas

71
Herencia de facilidades

• Ejemplos
• Clase ASCII
• objetos que tienen acceso a las propiedades
  del conjunto de caracteres ASCII
• Clase LINEAR_ITERATORG
• objetos capaces de recorrer secuencialmente
  una estructura linear

72
Herencia de Vistas

• Varios descendientes de una clase representan
  subconjuntos no disjuntos de instancias, sino
  formas distintas de clasificar las instancias.
• Necesidad de herencia múltiple y repetida.
• No recomendada a principiantes
• Alternativa Elegir un criterio como principal y
  los otros tratarlos mediante propiedades.

73
Ingeniería del Software
El Lenguaje Unificado de Modelado, UML

• TEMA 7 Orientación a Objetos y UML

Profesor Juan Antonio López Quesada. Facultad
de Informática. http//dis.um.es/lopezquesada
74
Métodos de Análisis OO

• Booch Coad/Yourdon
• OMT Champeaux
• Jacobson Martin/Odell
• Shlaer-Mellor OOram
• Wirfs-Broks BON
• Fusion Open
• Catalysis
• Y muchos más!

75
El lenguaje unificado de modelado, UML

• A mediados de los noventa existían muchos métodos
  de análisis y diseño OO.
• Mismos conceptos con distinta notación.
• Mucha confusión.
• Guerra de los métodos
• En 1994, Booch, Rumbaugh (OMT) y Jacobson
  (Objectory) deciden unificar sus métodos
• Unified Modeling Language (UML)
• Proceso de estandarización promovido por el OMG

76
Objetivos en el diseño de UML

• Modelar sistemas, desde los requisitos hasta los
  artefactos ejecutables, utilizando técnicas OO.
• Cubrir las cuestiones relacionadas con el tamaño
  propias de los sistemas complejos y críticos.
• Lenguaje utilizable por las personas y las
  máquinas
• Encontrar equilibrio entre expresividad y
  simplicidad.

77
Por qué modelamos?
Una empresa software con éxito es aquella que
produce de manera consistente software de
calidad que satisface las necesidades de los
usuarios
El modelado es la parte esencial de todas las
actividades que conducen a la producción de
software de calidad
78
Por qué modelamos?

• Un modelo es una simplificación de la realidad
• Construimos modelos para comprender mejor el
  sistema que estamos desarrollando
• Cuatro utilidades de los modelos
• Visualizar cómo es o queremos que sea el sistema
• Especificar la estructura y comportamiento del
  sistema
• Proporcionan plantillas que guían la construcción
  del sistema
• Documentan las decisiones
• Equivalen a los planos de un edificio

79
Utilidad de UML

• Permite especificar todas las decisiones de
  análisis, diseño e implementación, construyéndose
  modelos precisos, no ambiguos y completos.
• UML puede conectarse a lenguajes de programación
• Ingeniería directa e inversa
• Permite documentar todos los artefactos de un
  proceso de desarrollo (requisitos, arquitectura,
  pruebas, versiones,..)

80
Diagramas de UML

• Diagramas de Casos de Uso
• Diagramas de Clases
• Diagramas de Objetos
• Diagramas de Interacción
• Diagrama Secuencia
• Diagrama Colaboración
• Diagramas de Estados
• Diagramas de Actividades
• Diagramas de Componentes
• Diagramas de Despliegue

81
Modelado de Casos de Uso

• Un caso de uso especifica el comportamiento
  deseado del sistema.
• Representan los requisitos funcionales del
  sistema.
• Un caso de uso especifica una secuencia de
  acciones, incluyendo variantes, que el sistema
  puede ejecutar y que produce un resultado
  observable de valor para un particular actor
• Describen qué hace el sistema, no cómo lo hace.

82
Casos de Uso
83
Otras definiciones de caso de uso

• Describe un conjunto de interacciones entre
  actores externos y el sistema en consideración
  orientadas a satisfacer un objetivo de un actor.
  D. Bredemeyer
• Es una colección de posibles secuencias de
  interacciones entre el sistema en discusión y sus
  actores externos, relacionado con un objetivo
  particular. A. Cockburn
• Es una descripción de un conjunto de secuencias
  de acciones, incluyendo variantes, que ejecuta un
  sistema para producir un resultado observable de
  valor para un actor
• UML

84
Ejemplo Caso de Uso
actor
caso de uso
Procesar Préstamo
ResponsablePrestamos
asociacion
85
Actores

• Un actor representa un conjunto coherente de
  roles que juegan los usuarios de los casos de uso
  al interaccionar con el sistema.
• Roles jugados por personas, dispositivos, u otros
  sistemas.
• No forman parte del sistema

86
Actores

• Un usuario puede jugar diferentes roles.
• En la realización de un caso de uso pueden
  intervenir diferentes actores.
• Un actor puede intervenir en varios casos de uso.
• Un actor necesita el caso de uso y/o participa en
  él.

87
Actores

• A. Cockburn distingue dos tipos de actores
• Primarios
• Requieren al sistema el cumplimiento de un
  objetivo
• Secundarios
• El sistema necesita de ellos para satisfacer un
  objetivo

88
Propiedades de los casos de uso

• Son iniciados por un actor con un objetivo en
  mente y es completado con éxito cuando el sistema
  lo satisface.
• Puede incluir secuencias alternativas que llevan
  al éxito y fracaso en la consecución del
  objetivo.
• El sistema es considerado como una caja negra y
  las interacciones se perciben desde fuera.
• El conjunto completo de casos de uso especifica
  todas las posibles formas de usar el sistema,
  esto es el comportamiento requerido.

89
Escenarios y Casos de Uso

• Un caso de uso describe un conjunto de
  secuencias de interacciones o escenarios flujo
  principal y flujos alternativos o excepcionales.
• Un escenario es una instancia de un caso de uso.
• Especificación con diagramas de secuencia o
  Interacción.

90
Comprar Articulos
Cajero
Cliente
Sistema
Cajero
introducirItem(upc,cantidad)
finalizarVenta()
hacerPago(cantidad)
91
Descripción de un caso de uso

• Describir el flujo de eventos
• Texto estructurado informal
• Texto estructurado formal (pre y postcondiciones)
• Pseudocódigo
• Notaciones gráficas Diagramas de Secuencia
• Debe ser legible y comprensible para un usuario
  no experto.
• Debe indicarse inicio y final, actores, objetos
  que fluyen, flujo principal y flujos
  excepcionales.

92
Descripción de un caso de uso

• Comprar articulos (en un terminal de punto de
  venta)
• Flujo Principal Un cliente llega al TPV con un
  conjunto de articulos. El Cajero registra los
  artículos y se genera un ticket. El cliente paga
  en efectivo y recoge los artículos.
• 1. El cliente llega al TPV con los artículos.
• 2. El cajero registra el identificador de cada
  artículo.
• 3. El sistema obtiene el precio de cada artículo
  y añade la información a la transacción de venta.
• 4. Al acabar el cajero indica la finalización de
  la introducción de artículos.
• 5. El sistema calcula el total de la compra y lo
  muestra.

93
Descripción de un caso de uso

• Comprar articulos (en un terminal de punto de
  venta)
• 6. El Cajero le dice al cliente el total.
• 7. El cliente realiza el pago.
• 8. El cajero registra la cantidad de dinero
  recibida.
• 9. El sistema muestra la cantidad a retornar al
  cliente y genera un recibo.
• 10. El cajero deposita el dinero recibido y saca
  la cantidad a devolver que entrega al cliente
  junto al ticket de compra.
• 11. El sistema almacena la compra completada.
• 12. El cliente recoge los artículos comprados.

94
Descripción de un caso de uso

• Validar Usuario (contexto de un cajero
  automático)
• Flujo Principal El sistema pide el NIP. El
  cliente lo introduce a través del teclado y pulsa
  Enter. El sistema comprueba la validez del NIP.
  Si es válido el sistema acepta la entrada y
  finaliza el caso de uso.
• Flujo Excepcional El cliente puede cancelar la
  transacción en cualquier momento, pulsando el
  botón Cancelar, reiniciando el caso de uso.
• Flujo Excepcional Si el NIP introducido es
  inválido entonces se reinicia el caso de uso. Si
  esto ocurre tres veces, el sistema cancela la
  transacción completa y se queda con la tarjeta.

95
Diagrama de Casos de uso
Realizar transacción con tarjeta
Cliente
Comercio
Procesar factura cliente
Cliente Individual
Cliente Corporativo
Ajustar transacciones
Entidad financiera
Gestionar cuentas clientes
96
Diagrama de Casos de uso
Reservar Libro
Prestamo revista
Profesor
Prestamo Libro
Devolver revista
Socio
Devolver libro
Actualizar catalogo
Bibliotecario
Extender Prestamo
Consultar
Socio
97
Diagrama de Casos de Uso
98
Obtención de casos de uso

• 1) Identificar los usuarios del sistema.
• 2) Encontrar todos los roles que juegan los
  usuarios y que son relevantes al sistema.
• 3) Para cada role identificar todas las formas
  (objetivos) de interactuar con el sistema.
• 4) Crea un caso de uso por cada objetivo.
• 5) Estructurar los casos de uso.
• 6) Revisar y validar con el usuario.

99
Ejemplo
100
Por qué casos de uso?

• Ofrecen un medio sistemático e intuitivo para
  capturar los requisitos funcionales, centrándose
  en el valor añadido para el usuario
• Dirigen todo el proceso de desarrollo puesto que
  la mayoría de actividades (planificación,
  análisis, diseño, validación, test,..) se
  realizan a partir de los casos de uso.
• Mecanismo importante para soportar trazabilidad
  entre modelos.

101
Crítica a los casos de uso (B.Meyer, E. Berard)

• Los casos de uso no son adecuados en el modelado
  orientado a objetos porque
• i) Favorecen un enfoque funcional, basado en
  procesos
• ii) Se centran en secuencias de acciones
• iii) Se basan en los escenarios actuales del
  sistema
• Solo deben ser usados por equipos expertos en
  desarrollo OO
• Utiles para validación

102
Utilidad de los casos de uso

• Hay consenso en considerar casos de uso como
  esenciales para capturar requisitos y guiar el
  modelado.
• Pero existe mucha confusión sobre cómo usarlos.
• Diferentes opiniones sobre el número de casos de
  uso conveniente
• 20 para un proyecto 10 personas/año (Jacobson)
• depende de la granularidad