Upload
adelita-lucido
View
28
Download
1
Embed Size (px)
Citation preview
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
INGENIERIA DE SOFTWARE II
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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.
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Es utilizado para:
• Especificar
• Diseñar
• Visualizar
• Comunicar y
• Documentar sistemas.
UML (UNIFIED MODELING LANGUAGE)
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
UML consta de un conjunto de notaciones gráficas y un lenguaje formal
UML (UNIFIED MODELING LANGUAGE)
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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
UML (UNIFIED MODELING LANGUAGE)
Fuente: OMG, 2003a
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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)
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (2)
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
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
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.
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (4)
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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.
DIAGRAMAS DE CASOS DE USO (2)
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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)
Universidad Politécnica del Oeste “Mariscal Sucre”
• 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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
• 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)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Este elemento representa la relación que existe entre un Caso de Uso y
un Actor, dicho elemento es representado 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)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Empleado para delimitar los limites del sistema, y representado por un
rectángulo con color de fondo distintivo.
Límites del SistemaDIAGRAMAS DE CASOS DE USO (3)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
GENERALIZACIÓN
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).
Relaciones entre Casos de UsoDIAGRAMAS DE CASOS DE USO (3)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
INCLUSIÓ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
uso caso de inclusión.
Relaciones entre Casos de UsoDIAGRAMAS DE CASOS DE USO (3)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
EXTENSIÓN
Una extensión representa una variación de un uso-caso 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 origina del caso de
uso base hacia el caso de uso de extensión.
Relaciones entre Casos de UsoDIAGRAMAS DE CASOS DE USO (3)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Nombre del Sistema
Caso de Uso 1
Caso de Uso 2
Caso de Uso 3
Actor 1
Actor 2
Relaciones entre Casos de UsoDIAGRAMAS DE CASOS DE USO (3)
Comunicación
Caso de UsoInclude 1
Caso de UsoInclude 1
<<include>>
<<extend>>
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Diagramas de Casos de Uso (2)
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
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
PASOS:
• Identificar los límites del sistema.
• Identificar los actores.
• Para cada ACTOR, identificar sus objetivos.
• Definir casos de uso que satisfagan sus objetivos.
Diagramas de Casos de Uso (1)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Ejemplo Diagramas de Casos de Uso (1)
Punto de venta
ProcesarVenta
ProcesarDevoluciones
GestionarUsuarios
Cajero
Administradordel Sistema
Acceder alSistema
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
CASO DE USO 1: Procesar venta
Actor Primario: • Cajero.
Interesados y objetivos:• Cajero: Quiere anotaciones precisas y rápidas de precios, sin errores.• Cliente: Quiere que el pago sea rápido con el mínimo esfuerzo. Quiere
una prueba de compra para justificar devoluciones.• Compañía: Quieren almacenar las transacciones y satisfacer los
intereses de los clientes.• Comercial: Quiere que se le actualicen sus comisiones por venta.• Agencias de impuestos gubernamentales: Quieren recolectar impuestos
de cada venta. 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.
Precondiciones: El cajero se ha identificado y autentificado.
Ejemplo Diagramas de Casos de Uso (2)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Garantía de éxito (Postcondiciones):• Se registra la compra en el sistema. • Se calcula el impuesto aplicable. • Se actualizan los sistemas de inventario y de contabilidad. Se
registran las comisiones. • Se genera un recibo. • Se registran las aprobaciones de pago por tarjeta.
Escenario principal de Exito:1. Llega un cliente al PV con bienes o servicios que comprar.2. El cajero comienza una nueva compra.3. El cajero introduce un identificador de producto.4. El sistema registra el elemento y presenta una descripción del mismo, su
precio y 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.
5. El sistema presenta el total con los impuestos calculados.6. El cajero le dice el total al cliente, y le pide que pague.7. El cliente paga y el sistema procesa el pago.8. El sistema registra la venta realizada y manda la información a los
sistemas externos de inventario y contabilidad.9. El sistema genera el recibo.10. El cliente se va.
Ejemplo Diagramas de Casos de Uso (3)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Extensiones (Flujos alternativos):a*. En cualquier momento, el sistema falla.
3a. Identificador inválido.1. El sistema señala un error y rechaza la entrada.
7a. Pago en efectivo.7b. Pago con tarjeta.
Requisitos especiales:• Pantalla táctil en panel grande y plano. El texto debe ser visible desde un
metro.• Respuesta de autorización de crédito en menos de 30 secs, el 90% de
las veces.• Recuperación robusta cuando el acceso a sistemas externos (tales como
el inventario, impuestos, etc.) falla.• Posibilidades de internacionalización de texto.• Reglas de negocio insertables en los pasos 3 y 7.
Ejemplo Diagramas de Casos de Uso (4)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Lista de variaciones de tecnología y datos:3a. Se introduce el identificador del elemento mediante escáner de código
de barras o mediante el teclado.3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU.7a. La información sobre el pago con tarjeta se puede introducir mediante el
teclado o lector.7b. Se pide firma en papel. En dos años, creemos que muchos clientes van
a querer captura de firma digital.
Frecuencia de ocurrencia: Puede ser casi continua.
Temas abiertos:• ¿Cuáles son las posibles variaciones en las leyes sobre impuestos?• Explorar el tema de recuperación en caso de fallo de sistemas externos.• ¿Qué modificaciones se necesitan para negocios distintos?• ¿Debe el cajero extraer el cajón con la recaudación al terminar?• ¿Puede el cliente usar directamente el lector de tarjetas o es el cajero el
que lo hace?
Ejemplo Diagramas de Casos de Uso (5)
Universidad Politécnica del Oeste “Mariscal Sucre”
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
1. Determinación de Requerimientos: Por lo general nuevos requerimientos de sistema generan nuevos casos de uso, conforme se va analizando y diseñando el sistema.
2. Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto
3. Generación de pruebas de Sistemas: A través de los diagramas de casos de uso se pueden generar una serie de pruebas de sistema.
Casos de Uso (2)
Cuándo usar diagramas de casos de uso