Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" INGENIERIA DE SOFTWARE II Clase

Universidad Politécnica del Oeste “Mariscal Sucre”

© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

INGENIERIA DE SOFTWARE IIClase Nº 7

Bibliografía:Pressman, Roger. Ingeniería de Software. Un enfoque práctico. Cuarta Edición.

McGrawHill.México. 1997.http://www.clikear.com/manuales/uml/diagramascasouso.aspxhttp://www.osmosislatina.com/lenguajes/uml/casos.htm



UNIDAD II. ESPECIFICACIÓN DE REQUERIMIENTOSObjetivos de la Unidad

Al finalizar esta unidad el participante será capaz de:

• Utilizar notaciones y herramientas especializadas para especificar y documentar requerimientos de software.

• Elaborar modelos funcionales, estructurales y dinámicos de una aplicación usando UML.



ANALISIS ORIENTADO A OBJETOS (AOO)

Propósito es definir todas las clases que son relevantes al problema que se estudia.

Método de BoochMétodo de Coad/YourdonMétodo de JacobsonMétodo de RumbaughMétodo de Wirfs-Brock



UML (UNIFIED MODELING LANGUAGE)

• Es un lenguaje de modelado de sistemas que integra y unifica diferentes notaciones y lenguajes formales.

• Facilita la representación del conocimiento acerca de un sistema y la comunicación de dicho conocimiento.

• Es un estándar administrado por el consorcio OMG (Object Management Group – www.omg.org -)

• Ha evolucionado agregando más poder y capacidad semántica a cada nueva versión (UML 1.4, UML 1.5, UML 2.0 y UML 2.1)

• Lenguaje gráfico para visualizar, especificar, construir y documentar las partes de un sistema de software.

• Puede utilizarse a lo largo de todo el ciclo de vida.

NO ES UNA METODOLOGIA

http://www.omg.org/



Es utilizado para:

• Especificar

• Diseñar

• Visualizar

• Comunicar y

• Documentar sistemas.


Características

• Unifica diferentes notaciones

• Intuitiva

• Homogénea

• Coherente

• Genérica

• Extensible

• Configurable

Se emplea directamente en las siguientes actividades del desarrollo de software:

• Modelado de Negocios

• Definición y especificación de

requerimientos.

• Diseño arquitectónico

• Especificación y diseño de

componentes de software

• Diseño detallado de programas

• Diseño de bases de datos

• Diseño de interfaces H/M

• Pruebas de sistemas

• Documentación de sistemas



UML consta de un conjunto de notaciones gráficas y un lenguaje formal


Las notaciones gráficas son usadas para:• Modelar la estructura, funcionalidad, comportamiento e implementación de

un sistema.• Organizar los modelos producidos.

El lenguaje formal es usado para:• Expresar formalmente restricciones acerca de los elementos modelados de

un sistema, permite representar:

‒ Invariantes

‒ Pre y post condiciones

‒ Referencias

‒ Otras restriciones



Diagramas Estructurales

• De Clases

• De Estructuras Compuestas

• De Componentes

• De Despliegues

• De Objetos

• De Paquetes

Diagramas de Comportamiento

• De Actividades

• De Interacción– De Secuencias– De Comunicación– De Vistas de Interacción– Temporales

• De Casos de Uso

• De Máquinas de Estado


Fuente: OMG, 2003a



REQUERIMIENTOS

Técnicas de Recolección

Cliente

Analista

Escenarios

Creados por el Analista

Identifica uso que se le dará al software

Describen como el sistema será usado

DIAGRAMAS DE CASOS DE USO (1)



Los Diagramas de Casos de Uso son utilizados en la Ingeniería de Requerimientos para especificar los requisitos funcionales del sistema

• Los requisitos funcionales de una aplicación se especifican mediante uno o más casos de uso.

• Cada caso de uso es documentado mediante una Descripción Textual.

Cajero Automático

ValidarTarjeta

RetirarEfectivo

Transferir entre Cuentas

Usuario ATM

Caso de Uso: Validar TarjetaActor: UsuarioFlujo de Eventos:1. El usuario introduce la

tarjeta.2. El sistema valida la tarjeta3. El sistema presenta el

menú de opciones

Descripción Textual



Los Diagramas de Casos de Uso modelan:

• Los Actores del sistema

• Los Casos de Uso

• Las Relaciones entre Actores

• Las Relaciones entre Casos de Uso

• Las Relaciones de Comunicación entre Actores y Casos de Uso.

• Los Límites del Sistema

• El Refinamiento o descomposición de los Casos de Uso.



Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:

Elementos

Actor 1

Limites del Sistema

Caso de UsoInclude 1

<<include>>

Relaciones entre Casos de Uso

Casos de Uso

Caso de Uso 1

Caso de Uso 2

Caso de Uso 3

Actor 2

Relaciones entre Actores

Relaciones entre Actores y Casos de Uso



Actores

• Representan papeles ejecutados por personas (o dispositivos) cuando el sistema está en operación.

• Es cualquier cosa que se comunique con el sistema y que sea externo al mismo.

• Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.

• Se representa mediante una figura humana. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.

• Un actor en un clasificador y no una ocurrencia, es decir, no se refieren a un individuo en particular, sino a una clase de individuos que tienen un rol común (un grupo de personas).


Representación icónica

El símbolo es usado para representar el rol que objetos externos, de una misma clase, juegan cuando interactúan con el sistema



ACTORES PRIMARIOS

• Interactúan para lograr el funcionamiento requerido del sistema a fin

de alcanzar el objetivo propuesto.

• Trabajan directamente con el software

ACTORES SECUNDARIOS

• Dan soporte al sistema de tal forma que los actores primarios puedan

hacer su trabajo

ActoresDIAGRAMAS DE CASOS DE USO (3)


• Se pueden establecer relaciones

de generalización entre los

actores

• Un rol general puede ser

heredado por uno o más roles

específicos

Relaciones entre ActoresDIAGRAMAS DE CASOS DE USO (3)

Usuario

PasajeroFrecuente

Piloto AdministradorPasajero



• Expresa una unidad coherente de funcionalidad requerida por el sistema.

• Se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior.

• Aportan una descripción acerca de cómo el sistema será usado.

• El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.

Casos de UsoDIAGRAMAS DE CASOS DE USO (3)



• Los actores se relacionan con los casos de uso mediante

asociaciones.

• Una asociación modela la comunicación bidireccional entre un actor y

un caso de uso.

• Envío de señales

• Envío de datos e información

• La comunicación es representada simplemente por una línea recta

que se extiende de la figura del actor hacia el ovalo del caso de uso.

ComunicaciónDIAGRAMAS DE CASOS DE USO (3)



Empleado para delimitar los limites del sistema, y representado por un

rectángulo con color de fondo distintivo.

La identificación del sistema se coloca en la parte superior izquierda.

Límites del SistemaDIAGRAMAS DE CASOS DE USO (3)

Nombre del Sistema



• Una generalización indica que un caso de uso (ovalo) es un caso

especial de otro caso, en otros términos, representa una relación

padre-hijo, donde el hijo puede ser suplido directamente por el padre

en cualquier momento. Esta relación es representado por una línea

con flecha que se extiende del caso de uso hijo hacia el caso de uso

padre (general).

• Modela las relaciones en las cuales el comportamiento de un caso de

uso general (padre) es heredado por uno o más casos de uso

especializados (hijos)

Relaciones entre Casos de UsoDIAGRAMAS DE CASOS DE USO (3)

GENERALIZACIÓN



Reservación de Vuelos

ActualizarReservación

RealizarReservación

Modificar Reservación

Línea Aérea


EliminarReservación

Ejemplo de Generalización



• Una inclusión es utilizada para indicar que un caso de uso (ovalo)

depende de otro caso, dicho de otra manera, significa que la

funcionalidad de determinado caso se requiere para realizar las tareas

de otro. Es representada por una línea punteada con flecha y

comentario <<include>> que se extiende del caso de uso base hacia

el caso de uso de inclusión.

• Modelan relaciones en las cuales uno o más casos de uso incluyen

(usan) el comportamiento de un caso de uso común.

• Son usados para compartir comportamiento común entre varios casos

de uso.


INCLUSIÓN




UsarReservación

Pasajero


Registrar elVuelo

<<include>>

Ejemplo de Inclusión



• Una extensión representa una variación de un caso de usos a otro, aunque similar

a una generalización, una extensión representa una dependencia especifica,

mientras una generalización no implica que los casos de uso dependen uno del

otro. Esta relación es representado por una línea punteada con flecha y

comentario <<extend>> que se origina del caso de uso de extensión hacia el caso

de uso base.

• Modelan relaciones en las cuales un caso de uso base incluye el comportamiento de una caso de uso extendido en uno o más puntos de su flujo de eventos.

• Estos puntos se denominan puntos de extensión.• Tienen asociado una condición que determina cuando el caso de uso extendido es invocado por el

caso de uso base.

• Son usadas para modelar separadamente el comportamiento excepcional del

caso de uso base.


EXTENSIÓN




RealizarReservación

Pasajero


ReservarMultiples Destinos

<<extend>>

Condición: Modo=Múltiples Destinos. Punto de Extensión: Verificar Modo

Ejemplo de Extensión



DIAGRAMAS DE CASOS DE USO

1. Muestra la relación entre los actores y los casos de uso del sistema.

3. Los casos de uso están en el interior de la caja del sistema.

2. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.

4. Los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea



PASOS:

• Identificar los límites del sistema.

• Identificar los actores.

• Para cada ACTOR, identificar sus objetivos.

• Definir casos de uso que satisfagan sus objetivos.

PASOS PARA ELABORAR DIAGRAMAS DE CASOS DE USO



• Cada actor y caso de uso debe tener un nombre único.

• Todos los actores se representan por una figura humana y deben tener nombres representativos.

• Los nombres deben indicar roles.

• El nombre de un caso de uso debe indicar acción y debe ser claro y conciso.

• Forma general = Verbo + Predicado

• Ejemplo: Actualizar Itinerarios

• Los casos de uso de un diagrama deben estar todos a un mismo nivel de abstracción.

• Evite el cruce de líneas.

• Evite tener demasiados casos de uso en un mismo diagrama.

• Use la regla 7 ± 2.

• Evite el uso complejo de relaciones de extensión e inclusión.

REGLAS DE ESTILO PARA ELABORAR CASOS DE USO



• La simplicidad de los diagramas de casos de uso tienen un costo

asociado

• Baja expresividad:• El conjunto de acciones que ocurren entre un actor y el caso de uso no se pueden

capturar con los símbolos de los diagramas.

• Cada caso de uso tiene asociado un flujo de eventos que indica el

orden en que sus acciones se ejecutan.

• Este Flujo establece los detalles de la comunicación entre el caso de

usos y los actores.

• Los flujos de eventos se describen separadamente usando

DESCRIPCIONES TEXTUALES de casos de uso.• Flujo de eventos principal (flujo feliz)

• Flujo de eventos alternativos.

DESCRIPCION TEXTUAL DE CASOS DE USO



PLANTILLA PARA DESCRIPCION TEXTUAL DE CASOS DE USO

<<Requerimiento No funcional o Pseudo-requerimiento n>>

NOTAS

<<Nota adicional o aclaratoria 1>>…

<<Nota adicional o aclaratoria n>>

CASO DE USO:

ID: <<N° Caso de Uso>> NOMBRE: <<Nombre del Caso de Uso>>

<<Post-condición 1>>…

<<Post-condición n>>

REQUERIMIENTOS ESPECIALES

<<Requerimiento No funcional o Pseudo-requerimiento 1>>…

FLUJO EVENTOS ALTERNATIVOS

<<Evento 1>> …

<<Evento n>>

POST-CONDICIONES (Garantía de Éxito)

<<Evento n>> …

PRE-CONDICIONES <<Pre-condición 1>>

… <<Pre-condición n>>

<<Nombre del Actor 1>>:<<Objetivos del Actor 1>>

<<Nombre del Actor n>>:<<Objetivos del Actor n>>

FLUJO EVENTOS PRINCIPAL

<<Evento 1>>

ACTORES PARTICIPANTES Y OBJETIVOS

…



EJEMPLO DE CASO DE USO (1)

Punto de venta

ProcesarVenta

Cajero

Autenticarse<<include>>



1.

2.

3.

4.

5.

6.

1.

NOMBRE: Procesar Venta

Cliente: Quiere que el pago sea rápido con el mínimo esfuerzo. Quiere unaprueba de compra para justificar devoluciones.

Cajero: Quiere anotaciones precisas y rápidas de precios, sin errores.

Compañía: Quieren almacenar las transacciones y satisfacer los intereses de losclientes.

PRE-CONDICIONES

Agencias de impuestos gubernamentales: Quieren recolectar impuestos de cadaventa. Puede que haya varias agencias (nacionales, regionales, etc.)

Servicios de Autorización de Pagos (por tarjetas de crédito/débito): Quiere recibir peticiones digitales de autorizaciones en el formato y protocolo correcto.Comercial: Quiere que se le actualicen sus comisiones por venta.

El cajero se ha identificado y autentificado.

ACTORES PARTICIPANTES Y OBJETIVOS

CASO DE USO

IDENTIFICADOR: 1



1.2.

3.

4.

5.6.7.8.

9.

10.11.

1.2.

3.1. El sistema señala un error y rechaza la entrada.

El cajero introduce un identificador de producto. Se introduce el identificador delelemento mediante escáner de código de barras o mediante el teclado

El sistema registra el elemento y presenta una descripción del mismo, su precioy total actual. Se calcula el precio de una lista de reglas.

El cajero repite los pasos 3-4 hasta que no hay más elementos.El sistema presenta el total con los impuestos calculados.El cajero le dice el total al cliente, y le pide que pague.

FLUJO EVENTOS PRINCIPAL

En cualquier momento, el sistema falla.3a. Identificador inválido.

7a. Pago en efectivo.7b. Pago con tarjeta.

FLUJO EVENTOS ALTERNATIVOS

Llega un cliente al PV con bienes o servicios que comprar.El cajero comienza una nueva compra.

El cliente se va.

El cliente paga y el sistema procesa el pago.El sistema registra la venta realizada y manda la información a los sistemasexternos de inventario y contabilidad.El sistema genera el recibo.



1.2.

3.

3.

4.

1.

2.

3.

1.2.

3.

Proyecto: Facturación Analista: Ing° Rafael Matos

Se genera un recibo.

Recuperación robusta cuando el acceso a sistemas externos (tales como elinventario, impuestos, etc.) falla.Pantalla táctil en panel grande y plano. El texto debe ser visible desde un metro.

¿Cuáles son las posibles variaciones en las leyes sobre impuestos?Explorar el tema de recuperación en caso de fallo de sistemas externos¿Puede el cliente usar directamente el lector de tarjetas o es el cajero el que lohace?

NOTAS

Se registra la compra en el sistema. Se calcula el impuesto aplicable

Se registran las aprobaciones de pago por tarjeta.

Se actualizan los sistemas de inventario y de contabilidad. Se registran lascomisiones.

Respuesta de autorización de crédito en menos de 30 secs, el 90% de las veces

POST-CONDICIONES (Garantía de Éxito)

REQUERIMIENTOS ESPECIALES


Documents

Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" INGENIERIA DE SOFTWARE II Clase