Transcript Modernizacion de la Biblioteca Nacional de Venezuela

Universidad Politécnica del Oeste “Mariscal Sucre”
INGENIERIA DE SOFTWARE II
Clase Nº 7
Bibliografía:
Pressman, Roger. Ingeniería de Software.
Un enfoque
McGrawHill.México. 1997.
http://www.clikear.com/manuales/uml/diagramascasouso.aspx
http://www.osmosislatina.com/lenguajes/uml/casos.htm
práctico.
Cuarta
Edición.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
UNIDAD II. ESPECIFICACIÓN DE REQUERIMIENTOS
Objetivos 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.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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 Booch
Método de Coad/Yourdon
Método de Jacobson
Método de Rumbaugh
Método de Wirfs-Brock
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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 -)
NO ES UNA METODOLOGIA
• 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.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
UML (UNIFIED MODELING LANGUAGE)
Es utilizado para:
• Especificar
Se emplea directamente en
las siguientes actividades
del desarrollo de software:
• Diseñar
• Modelado de Negocios
• Visualizar
• Definición y especificación de
• Comunicar y
requerimientos.
• Documentar sistemas.
• Diseño arquitectónico
Características
• Especificación
• Unifica diferentes notaciones
y
diseño
de
componentes de software
• Intuitiva
• Diseño detallado de programas
• Homogénea
• Diseño de bases de datos
• Coherente
• Diseño de interfaces H/M
• Genérica
• Pruebas de sistemas
• Extensible
• Documentación de sistemas
• Configurable
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
UML (UNIFIED MODELING LANGUAGE)
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
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
UML (UNIFIED MODELING LANGUAGE)
Diagramas Estructurales
Diagramas de Comportamiento
• De Clases
• De Actividades
• De Estructuras Compuestas
• De Interacción
• De Componentes
• De Despliegues
–
–
–
–
De Secuencias
De Comunicación
De Vistas de Interacción
Temporales
• De Objetos
• De Casos de Uso
• De Paquetes
• De Máquinas de Estado
Fuente: OMG, 2003a
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (1)
Cliente
Creados por
el Analista
Identifica uso
que se le dará
al software
Analista
REQUERIMIENTOS
Técnicas de
Recolección
Escenarios
Describen
como el
sistema será
usado
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
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
Descripción Textual
Validar
Tarjeta
Retirar
Efectivo
Usuario
ATM
Transferir
entre Cuentas
Caso de Uso: Validar Tarjeta
Actor: Usuario
Flujo de Eventos:
1. El usuario introduce la
tarjeta.
2. El sistema valida la tarjeta
3. El sistema presenta el menú
de opciones
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)
Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:
Relaciones
entre
Casos de Uso
Relaciones entre Actores
y Casos de Uso
Caso de
Uso 1
Actor 1
<<include>>
Caso de Uso
Include 1
Caso de
Uso 2
Limites del Sistema
Caso de
Uso 3
Relaciones
entre Actores
Actor 2
Casos de Uso
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (2)
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
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Actores
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
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Relaciones entre Actores
Usuario
• Se pueden establecer relaciones
de
generalización
entre
los
puede
ser
actores
• Un
rol
general
heredado por uno o más roles
Piloto
Pasajero
específicos
Pasajero
Frecuente
Administrador
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Casos de Uso
• Expresa una unidad coherente de funcionalidad requerida por el
sistema.
• 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.
• Se representa en el Diagrama de Casos de Uso mediante una elipse
con el nombre del caso de uso en su interior.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Comunicación
• 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.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Límites del Sistema
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.
Nombre del Sistema
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Relaciones entre Casos de Uso
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).
• 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)
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Relaciones entre Casos de Uso
Ejemplo de Generalización
Reservación de Vuelos
Actualizar
Reservación
Línea Aérea
Realizar
Reservación
Modificar
Reservación
Eliminar
Reservación
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Relaciones entre Casos de Uso
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 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.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Relaciones entre Casos de Uso
Ejemplo de Inclusión
Reservación de Vuelos
Usar
Reservación
<<include>>
Registrar el
Vuelo
Pasajero
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Relaciones entre Casos de Uso
EXTENSIÓ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.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO (3)
Relaciones entre Casos de Uso
Ejemplo de Extensión
Reservación de Vuelos
Realizar
Reservación
<<extend>>
Reservar
Multiples
Destinos
Pasajero
Condición: Modo=Múltiples Destinos.
Punto de Extensión: Verificar Modo
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DIAGRAMAS DE CASOS DE USO
1.
Muestra la relación entre los actores y los casos de uso del
sistema.
2.
Representa la funcionalidad que ofrece el sistema en lo que se
refiere a su interacción externa.
3.
Los casos de uso están en el interior de la caja del sistema.
4.
Los actores fuera, y cada actor está unido a los casos de uso en los
que participa mediante una línea
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
PASOS PARA ELABORAR DIAGRAMAS DE CASOS DE USO
PASOS:
• Identificar los límites del sistema.
• Identificar los actores.
• Para cada ACTOR, identificar sus objetivos.
• Definir casos de uso que satisfagan sus objetivos.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
REGLAS DE ESTILO PARA ELABORAR 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.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
DESCRIPCION TEXTUAL DE 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.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
PLANTILLA PARA DESCRIPCION TEXTUAL DE CASOS DE USO
CASO DE USO:
ID: <<N° Caso de Uso>>
NOMBRE: <<Nombre del Caso de Uso>>
ACTORES PARTICIPANTES Y OBJETIVOS
<<Nombre del Actor 1>>:<<Objetivos del Actor 1>>
…
<<Nombre del Actor n>>:<<Objetivos del Actor n>>
PRE-CONDICIONES
<<Pre-condición 1>>
…
<<Pre-condición n>>
FLUJO EVENTOS PRINCIPAL
<<Evento 1>>
…
<<Evento n>>
FLUJO EVENTOS ALTERNATIVOS
<<Evento 1>>
…
<<Evento n>>
POST-CONDICIONES (Garantía de Éxito)
<<Post-condición 1>>
…
<<Post-condición n>>
REQUERIMIENTOS ESPECIALES
<<Requerimiento No funcional o Pseudo-requerimiento 1>>
…
<<Requerimiento No funcional o Pseudo-requerimiento n>>
NOTAS
<<Nota adicional o aclaratoria 1>>
…
<<Nota adicional o aclaratoria n>>
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
EJEMPLO DE CASO DE USO (1)
Punto de venta
Procesar
Venta
<<include>>
Autenticarse
Cajero
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
EJEMPLO DE CASO DE USO (2)
CASO DE USO
IDENTIFICADOR: 1
NOMBRE: Procesar Venta
ACTORES PARTICIPANTES Y OBJETIVOS
1. 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
2.
prueba de compra para justificar devoluciones.
Compañía: Quieren almacenar las transacciones y satisfacer los intereses de los
clientes.
Agencias de impuestos gubernamentales: Quieren recolectar impuestos de cada
4.
venta. Puede que haya varias agencias (nacionales, regionales, etc.)
3.
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.
6. Comercial: Quiere que se le actualicen sus comisiones por venta.
5.
PRE-CONDICIONES
1. El cajero se ha identificado y autentificado.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"
Universidad Politécnica del Oeste “Mariscal Sucre”
EJEMPLO DE CASO DE USO (3)
FLUJO EVENTOS PRINCIPAL
1. Llega un cliente al PV con bienes o servicios que comprar.
2. El cajero comienza una nueva compra.
El cajero introduce un identificador de producto. Se introduce el identificador del
3.
elemento mediante escáner de código de barras o mediante el teclado
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.
5.
6.
7.
8.
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.
El cliente paga y el sistema procesa el pago.
El sistema registra la venta realizada y manda la información a los sistemas
9.
externos de inventario y contabilidad.
10. El sistema genera el recibo.
11. El cliente se va.
FLUJO EVENTOS ALTERNATIVOS
1. En cualquier momento, el sistema falla.
2. 3a. Identificador inválido.
1. El sistema señala un error y rechaza la entrada.
3. 7a. Pago en efectivo.
7b. Pago con tarjeta.
Universidad Politécnica del Oeste “Mariscal Sucre”
EJEMPLO DE CASO DE USO (4)
POST-CONDICIONES (Garantía de Éxito)
1. Se registra la compra en el sistema.
2. Se calcula el impuesto aplicable
Se actualizan los sistemas de inventario y de contabilidad. Se registran las
3.
comisiones.
3. Se genera un recibo.
4. Se registran las aprobaciones de pago por tarjeta.
REQUERIMIENTOS ESPECIALES
1. 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
2.
inventario, impuestos, etc.) falla.
3. Pantalla táctil en panel grande y plano. El texto debe ser visible desde un metro.
NOTAS
1. ¿Cuáles son las posibles variaciones en las leyes sobre impuestos?
2. 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 lo
3.
hace?
Analista: Ing° Rafael Matos
Proyecto: Facturación