1

Unidad II

Metodología para resolver problemas aplicando la POO

Parte 1

2

Metodología para resolver problemas aplicando la POO

• Fases

I.Definición de requisitos

II.Análisis del problema

III.Diseño de solución

IV.Codificación

3

FASE I. Definición de Requisitos

• Incluye la descripción del problema en términos de los usuarios de la aplicación a elaborar.

• Puede considerarse como el enunciado del problema a resolver.

• Debe mencionar:

– las entradas disponibles,

– las salidas esperadas y

– los métodos o fórmulas específicas a utilizar

4

FASE II. Análisis del problema• Se debe contemplar exactamente lo que debe

hacer el programa y el resultado o solución deseada.– ¿Qué entradas se requieren?

– ¿Cuál es la salida deseada?

– ¿Qué método produce la salida deseada?

• Se tiene en cuenta la especificación de los requisitos dados por los usuarios del sistema.

5

FASE II. Análisis del problema

Incluye:

• Modelo de casos de uso

–Tareas:

• Identificar casos de uso

• Elaborar diagrama de casos de uso

• Describir los casos de uso

• Identificar operaciones del sistema

• Modelo del dominio

6

FASE II. Análisis del problema

Incluye:

• Modelo de casos de uso

• Modelo del dominio–Tareas:

• Identificar clases conceptuales

• Agregar asociaciones

• Agregar atributos

–Resultado: Modelo del dominio o diagrama de clases del análisis (sin métodos)

7

Modelo de Casos de Uso¿Qué es un caso de uso?

• Es una técnica para la captura de requisitos potenciales para un nuevo sistema o actualización.

• Cada caso de uso nos proporciona uno o más escenarios, que nos indica como va interactuar el sistema con el usuario u otros sistemas.

• Normalmente debemos evitar un lenguaje técnico y utilizar un lenguajes más cercano al usuario.

• Es una secuencia de interacciones que se darán entre el sistemas y los usuarios, en respuesta a un evento del actor principal.

8

Modelo de Casos de UsoUn caso de uso debe:

• Describir una tarea del negocio, que nos sirva para alcanzar una meta de este. Por ejemplo:– Inscribir asignaturas, agregar asignaturas, actualizar

asignatura, eliminar asignatura, etc.– Registrar alumno, registrar empleado, agregar docente,

agregar producto, registrar cliente, procesar venta, etc.

• Tener un nivel apropiado de detalle.

• Ser bastante sencillo para que un programador lo trabaje en un único desarrollo.

9

Modelo de Casos de UsoPasos para desarrollarlo:

1. Especificar la misión del sistema u objetivo.

2. Identificar quienes utilizaran el sistema (actores primarios)

3. Averiguar que objetivos desean cumplir los actores al usar el sistema.

4. Identificar los pasos o eventos de cada caso de uso.

10

Modelo de Casos de Uso• Conjunto de todos los casos de uso en un modelo de la

funcionalidad y entorno del sistema• Describe requisitos funcionales en el contexto del

sistema

Caso de Uso

--------------------

--------------------

Caso de Uso

--------------------

--------------------

Caso de Uso

Cambiar PIN

--------------------

--------------------

Caso de Uso

Cambiar PIN

--------------------

--------------------

Caso de Uso

Cambiar PIN

--------------------

--------------------

11

Casos de UsoObjetivos del cliente = Necesidades/requisitos del

y los usuarios cliente y los usuarios

• Describen requisitos de manera simple y entendible para clientes y usuarios finales.

• Por ser objetivos, inician con verbo en infinitivo. Por ejemplo: Agregar, Procesar, Registrar, Eliminar, Iniciar, Inscribir, etc.

12

Ejemplo en formato Breve

• Caso de Uso: Procesar Venta

El Cliente llega a una caja con artículos para comprar. El Cajero utiliza el Sistema para registrar cada artículo comprado. El Sistema presenta la suma parcial y detalles de cada línea de venta. El Cajero introduce los datos de pago. El Sistema válida y registra el pago. El Sistema actualiza el inventario. El Cajero recibe un recibo del Sistema. El Cajero entrega el recibo al Cliente, quien luego se va con los productos.

13

Actor• Posee comportamiento

• Puede ser una persona (identificada por un rol), un sistema informático o una organización

<<Actor>>

Sistema Administrador de Cuentas

<<Actor>>

Banco de Crédito

14

Actor

• Tres tipos de actores con relación al sistema bajo estudio:

▬Actor principal: solicita servicios al sistema bajo estudio

▬Actor de apoyo: Proporciona servicios al sistema bajo estudio

▬Actor pasivo: Esta interesado en el comportamiento del sistema bajo estudio, pero no es principal, ni de apoyo.

• Actores principales y de apoyo aparecen en los pasos de acción del texto de los casos de uso

15

Diagrama Incompleto de Casos de Uso de la Caja de Venta

16

Escenario

• Secuencia específica de acciones e interacciones entre los actores y el sistema objeto de estudio

• Instancia de un caso de uso

• Historia particular del uso de un sistema

• Camino a través del caso de uso

• Ejemplos:

• Éxito en la compra de artículos con pago en efectivo

• Fallo al comprar debido al rechazo de la transacción de pago con la tarjeta de crédito

17

Caso de Uso

• Colección de escenarios con éxito y fallo relacionados, que describe a los actores utilizando un sistema para lograr un objetivo

• Ejemplo de caso de uso en formato Informal:

Caso de Uso: Administrar devoluciones

18

Caso de Uso: Administrar devoluciones (Formato Informal)

• Escenario Principal de Éxito:

• Un Cliente llega a una caja con artículos para devolver

• El Cajero utiliza el Sistema para registrar cada uno de los artículo devueltos

• …

19

Caso de Uso: Administrar devoluciones (Informal)

• Escenarios Alternativos:• Si se pagó con tarjeta de crédito, y se rechaza la

transacción de reembolso a su cuenta, informar al Cliente y pagarle en efectivo

• Si el identificador del artículo no se encuentra en el Sistema, notificar al Cajero y sugerir la entrada manual del código de identificación

• Si el sistema detecta fallos en la comunicación con el sistema de contabilidad externo…

20

Tipos de Casos de Uso segúnsu visibilidad

• Según su visibilidad pueden ser:• De Caja negra (esencial)• De Caja blanca (real)

• Casos de Uso de Caja negra describen el sistema en base a responsabilidades, no describen el funcionamiento interno del sistema

• Describen… ¿Qué debe hacer el sistema? Y no ¿Cómo lo va ha hacer?

• Ejemplos:• (Caja negra) El Sistema registra la venta• (Caja blanca) El Sistema escribe la venta en una base de

datos…• (Caja blanca) El Sistema genera una instrucción SQL

INSERT para la venta…

21

Grados de Formalidad delos Casos de Uso

• Breve:• Resumen conciso de un párrafo. Normalmente sólo el

escenario principal de éxito

• Informal:• Múltiples párrafos que comprenden varios escenarios

• Completo:• Escribir con detalle todos los pasos y variaciones, incluye

secciones de apoyo como precondiciones y post-condiciones

22

Contenido deCasos de Uso Completos

• Actor Principal

• Personal Involucrado e Intereses

• Precondiciones

• Post-condiciones (garantías de éxito)

• Escenario Principal de Éxito (o flujo básico)

• Extensiones (ó flujos alternativos)

• Requisitos Especiales

• Lista de Tecnología y Variaciones de Datos

• Frecuencia

Nota: Sólo se estudiarán las partes resaltadas

23

Ejemplo en formato completo

Caso de Uso: Procesar venta (1)

Escenario principal de éxito (o flujo básico):

1. El Cliente llega a una terminal de Caja de Ventas con productos y/o servicios que comprar.

2. El Cajero comienza una nueva venta.

3. El Cajero introduce el identificador del artículo.

4. El Sistema registra la línea de la venta y presenta la descripción del artículo, precio y suma parcial. El precio se calcula a partir de un conjunto de reglas de precios.

El Cajero repite los pasos 3 y 4 hasta que se indique.

24

Caso de Uso: Procesar venta (2)

5. El Sistema presenta el total con los impuestos calculados.

6. El Cajero le dice al Cliente el total y pide que le pague.

7. El Cliente paga y el Sistema gestiona el pago.

8. El Sistema registra la venta completa y envía la información de la venta y el pago al sistema de Contabilidad externo (para la contabilidad y las comisiones) y al sistema de inventario (para actualizar el inventario).

9. El Sistema presenta el recibo.

10.El Cliente se va con el recibo y las mercancías (si es el caso).

25

Cómo Identificar los Casos de Uso?

• La identificación de los Casos de Uso debe basarse en los procesos y objetivos elementales del negocio (EBP)

• ¿Cuáles son Casos de Uso?

• Negociar contrato con proveedor

• Administrar devoluciones

• Iniciar sesión

• Todos son casos de uso a diferente nivel dependiendo de los límites del sistema, actores y objetivos

26

Guía: El Caso de Uso EBP

• EBP: Procesos Elementales del Negocio

• Procesos EBP:

• Tarea realizada por una persona en un lugar, en un instante, como respuesta a un evento del negocio, que agrega un valor cuantificable para el negocio y deja los datos en un estado consistente

27

Guía: El Caso de Uso EBP

• Ejemplos de Casos de Uso EBP:

• Autorizar créditos

• Solicitar precio

• Características de los Casos de Uso EBP

• Incluye de 5 a 10 pasos

• Pueden involucrar más de una persona

• Se realiza en pocos minutos o hasta una hora

• Se realiza en una sesión

28

Casos de Uso yObjetivos del Usuario

• Los actores (usuarios) tienen objetivos

Casos de uso -> Casos de Uso

a nivel EBP a nivel de objetivo de usuario

• Un Caso de Uso a nivel EBP sirve para satisfacer un objetivo de un usuario del sistema o actor principal

29

Objetivos y Casos de Uso de Subfunción (subobjetivos)

• “Iniciar sesión”, no es un objetivo de usuario, es un subobjetivo u objetivo de subfunción, que es parte de un objetivo de usuario.

• Los casos de uso que representan objetivos de subfunción, agregan complejidad al modelo de casos de uso.

• El número y granularidad de los casos de uso influyen en el tiempo y la dificultad para entender, mantener y gestionar los requisitos.

• La razón válida más común para representar un objetivo de subfunción como un caso de uso es: “Cuando la subfunción se repite o es una precondición de muchos casos de uso de nivel de objetivos de usuario”

30

Objetivos y Casos de Uso Compuestos

• Un objetivo de alto nivel o nivel de empresa (por ej. ser rentable) incluye muchos objetivos de nivel intermedio o nivel de usuario (por ej. Procesar ventas, procesar devoluciones, analizar actividad de ventas, etc.) que a su vez incluyen objetivos de subfunción dentro de las aplicaciones (por ej. Validar entrada)

• Los diferentes niveles de objetivos pueden generar confusión en la identificación del nivel adecuado de los casos de uso de una aplicación.

• La guía EBP orienta para eliminar casos de uso de nivel excesivamente bajo.

31

Aplicación de Guía EBP

• Se puede aplicar la Guía EBP para decidir si un objetivo o caso de uso se encuentra a un nivel adecuado.

• Preguntar a los usuarios:

• Qué hace?

• Cuáles son sus objetivos?

• Cuál es el objetivo de más alto nivel de X objetivo mencionado?

32

Ejemplo de Aplicación de Guía EBP

Conversación entre Analista de Sistemas (A) y Cajero (C)

• A: ¿Cuáles son sus objetivos en el contexto del sistema de la Caja de Ventas?

• C: Uno, iniciar la sesión rápidamente. También Capturar ventas

• A: ¿Cuál cree que es el objetivo de más alto nivel que motiva el inicio de la sesión?

33

Ejemplo de Aplicación de Guía EBP

• C: ¿Intento identificarme en el sistema, de este modo puede validar que estoy autorizado para utilizar el sistema que captura ventas y otras tareas?

• A: ¿Más alto que ese?

• C: Evitar robos, alteración de datos, y mostrar información privada de la compañía.

34

Ejemplo de Aplicaciónde Guía EBP (Conclusión)

• “Evitar robos” es un objetivo a nivel de la empresa y no es un EBP

• “Identificarme en el sistema y ser validado” se acerca más a un objetivo de usuario, pero...

• No agrega valor observable o cuantificable al negocio. Si el dueño pregunta ¿Qué hiciste hoy?, no va ha responder “Inicie la sesión 20 veces”. No es un EBP

• Identificación y validación es un objetivo secundario; no así, capturar las ventas, que es un EBP

35

Descubrir Actores principales, objetivos y casos de uso

• Casos de uso se definen para satisfacer los objetivos de usuario (actores principales).

• El procedimiento básico es:

1) Elegir límites del sistema

2) Identificar los actores principales

3) Identificar objetivos de usuario (Lista actor-objetivo)

4) Definir un caso de uso por cada objetivo de usuario y nombrarlo de acuerdo con el objetivo

• La lista Actor-Objetivo, presenta los actores principales y sus objetivos de usuario

36

Ejemplo de Lista Actor-ObjetivoActor Objetivo

Cajero Procesar ventasProcesar alquileresAdministrar las devolucionesAbrir cajaCerrar caja, …

Director Poner en marchaSuspender operación, …

Administrador delSistema

Agregar usuariosModificar usuariosEliminar usuariosGestionar seguridadGestionar las tablas del sistema, …

Sistema de Actividad deVentas (Sistema de Inf.)

Analizar los datos de ventas y rendimiento,…

… …

37

Actor principal y objetivos de usuario dependen del límite del sistema

• En el ejemplo de la Caja de Ventas, el límite del sistema determina si el actor principal es el cliente o el cajero.

• Por ejemplo, la Caja de Ventas con diferentes límites del sistema...

38

Excepción de un Caso de Uso por Objetivo

• Agrupar objetivos separados CRUD

• CRUD: Create, Retrieve, Update, Delete; es decir, crear, recuperar, actualizar y borrar una entidad; implica “Gestionar Entidad”.

• Por ejemplo, los siguientes casos de uso se agrupan en el caso de uso “Gestionar cliente”:• Editar cliente

• Eliminar cliente

• Consultar cliente

• Agregar nuevo cliente

39

Diagrama de Casos de Uso• Son parte del UML

• Ilustran los nombres de los casos de uso y los actores; así como, la relación entre ellos

40

Diagrama de Casos de Uso (DCU)

• Elaborar diagrama de casos de uso (DCU) y relaciones entre casos de uso es secundario en el trabajo con los casos de uso

• Casos de uso son documentos de texto

• El DCU es un conciso diagrama de contexto visual del sistema, que muestra actores externos y como utilizan el sistema

• SUGERENCIA: dibujar un DCU sencillo con la lista Actor-Objetivo.

41

Sugerencias para la realizaciónde los Diagramas de Casos de Uso

• Utilizar el estilo de caja para representar actores externos que son otros sistemas de información, y agregar el estereotipo «actor»

• Para un diagrama de contexto, limitar los casos de uso a casos de uso de nivel de objetivos de usuario

• Actores principales a la izquierda, y actores de apoyo a la derecha

42

Casos de Uso no son Orientados a Objetos (OO)

• Al escribir casos de uso, no se está realizando un análisis OO

• Los casos de uso constituyen una herramienta para el análisis de requisitos

• No todos los casos de uso se escriben en formato completo durante la fase de Definición de Requisitos

• Pasos para construir un DCU:

1. Identificar objetivos y personal involucrado, y estimar lo que queda dentro y fuera del alcance del sistema bajo estudio

2. Escribir lista Actor-Objetivo

3. Elaborar DCU

• La mayor parte de Casos de Uso interesantes, complejos o arriesgados se escriben en formato breve