Unidad 3. Especificación de Requeriientos de Software

Universidad Politcnica del Oeste Mariscal Sucre
INGENIERIA DE SOFTWARE II
Trayecto 3 Trimestre 7
Unidad 3
Bibliografa:
Asteasuain, Fernndo. UML. Users. Argentina. 2009.
Pressman, Roger. Ingeniera de Software. Un enfoque prctico. Cuarta Edicin.
McGrawHill.Mxico. 1997.
http://www.clikear.com/manuales/uml/diagramascasouso.aspx
http://www.osmosislatina.com/lenguajes/uml/casos.htm
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

UNIDAD II. ESPECIFICACIN 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 dinmicos de una aplicacin
usando UML.

UML (UNIFIED MODELING LANGUAGE) (1)
Es un lenguaje de modelado de sistemas que integra y unifica diferentes

notaciones y lenguajes formales.
Facilita la representacin del conocimiento acerca de un sistema y la
comunicacin de dicho conocimiento.
Es un estndar administrado por el consorcio OMG (Object Management
Group www.omg.org -)
NOagregando
Ha evolucionado ES UNA msMETODOLOGIA
poder y capacidad semntica a cada
nueva versin (UML 1.4, UML 1.5, UML 2.0 y UML 2.1)
Permite modelar todas las entidades de un sistema mediante tcnicas
orientadas a objetos.
Es capaz de modelar tanto sistemas pequeos, como sistemas grandes
y complejos.
Utiliza tcnicas grficas a travs de generacin de un lenguaje
fcilmente comprensible, tanto por los humanos como por las
computadoras.

Es utilizado para: Se emplea directamente en las

siguientes actividades del
Especificar desarrollo de software:
Disear Modelado de Negocios
Visualizar Definicin y especificacin de
Comunicar y requerimientos.
Documentar sistemas. Diseo arquitectnico
Caractersticas Especificacin y diseo de
Unifica diferentes notaciones componentes de software
Intuitiva Diseo detallado de programas
Homognea Diseo de bases de datos
Coherente Diseo de interfaces H/M
Genrica Pruebas de sistemas
Extensible Documentacin de sistemas
Configurable

UML consta de un conjunto de notaciones grficas y un lenguaje formal
Las notaciones grficas son usadas para:

Modelar la estructura, funcionalidad, comportamiento e implementacin 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 restricciones

Diagramas Estructurales Diagramas de Comportamiento
De Clases De Actividades
De Estructuras Compuestas De Interaccin

De Secuencias
De Componentes De Comunicacin
De Vistas de Interaccin
De Despliegues Temporales
De Objetos De Casos de Uso
De Paquetes De Mquinas de Estado
Fuente: OMG, 2003a

DIAGRAMAS DE CASOS DE USO (2)
Los Diagramas de Casos de Uso son utilizados en la Ingeniera de

Requerimientos para especificar los requisitos funcionales del sistema
Poseen una naturaleza altamente visual y la interpretacin de sus contenido

es razonable e intuitiva.
Su caracterstica ms distintiva es la pluralidad de sus conceptos, que
pueden ser manejados por todas las partes involucradas en el proyecto sin
necesidad de realizar modificaciones o adiciones, tanto en el discurso como
en el modelo.
Capturan el punto de vista del usuario del sistema y no el punto de vista de
quien lo construye.
No est atada a ni ligada a ningn tipo de modelo ni a ningn tipo de
lenguaje.
Fueron creados por Ivar Jacobson en el ao 1992.
Los Diagramas de Casos de Uso son utilizados en la Ingeniera de

Requerimientos para especificar los requisitos funcionales del sistema
Los requisitos funcionales de una aplicacin se especifican mediante uno o

ms casos de uso.
Cada caso de uso es documentado mediante una Descripcin Textual.
Cajero Automtico
Descripcin Textual
Validar Caso de Uso: Validar Tarjeta
Tarjeta
Actor: Usuario
Flujo de Eventos:
Retirar 1. El usuario introduce la
Efectivo tarjeta.
2. El sistema valida la tarjeta
Usuario 3. El sistema presenta el men
ATM Transferir de opciones
entre Cuentas
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 Comunicacin entre Actores y Casos de Uso.
Los Lmites del Sistema
El Refinamiento o descomposicin de los Casos de Uso.

Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:
Relaciones entre Actores Relaciones entre

y Casos de Uso Casos de Uso
<<include>> Caso de Uso

Caso de
Uso 1 Include 1
Caso de
Actor 1 Uso 2
Limites del Sistema

Caso de
Uso 3
Relaciones
entre Actores
Actor 2
Casos de Uso

Actores
Representan papeles ejecutados por entidades (personas o

dispositivos) cuando el sistema est en operacin.
Es cualquier entidad que interacte con nuestro sistema y que sea
externo al mismo.
Un actor es algo con comportamiento, como una persona
(identificada por un rol), un dispositivo, sistema automatizado u
organizacin, y que realiza algn tipo de interaccin con el sistema.
Se representa mediante una figura humana (Stick Man). Esta
representacin 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 comn (un grupo de personas).
El smbolo es usado para representar el rol

Representacin que objetos externos, de una misma clase,
icnica juegan cuando interactan con el sistema


Actores
ACTORES PRIMARIOS
Interactan 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


Relaciones entre Actores
Persona
Se pueden establecer relaciones de

generalizacin entre los actores
Un rol general puede ser heredado
por uno o ms roles especficos
Profesor Alumno Administrativo
Alumno Nuevo

Casos de Uso
Expresa una unidad coherente de funcionalidad requerida por el sistema.

Abstraen una secuencia de pasos que lleva a completar con xito una accin
del sistema.
Tienen un nombre nico, generalmente compuesto por un verbo en infinitivo
junto con un sustantivo que representa el objeto en cuestin.
Tienen uno o varios actores que los inician y son los que impulsan su
desarrollo.
Tienen dos partes. Por un lado la informacin mostrada grficamente y, por
otro, la especificacin o descripcin textual de los pasos.
Se representan grficamente mediante valos en cuyo interior se especifica
el nombre.
Notacin


Comunicacin
Los actores se relacionan con los casos de uso mediante asociaciones.
Una asociacin modela la comunicacin bidireccional entre un actor y un caso

de uso.
Envo de seales
Envo de datos e informacin
La comunicacin es representada simplemente por una lnea recta que se

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


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

rectngulo con color de fondo distintivo.
La identificacin del sistema se coloca en la parte superior izquierda.
Nombre del Sistema


Relaciones entre Casos de Uso
Generalizacin
Una generalizacin indica que un caso de uso (ovalo) es un caso especial de

otro caso, en otros trminos, representa una relacin padre-hijo, donde el hijo
puede ser suplido directamente por el padre en cualquier momento. Esta
relacin es representado por una lnea 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 ms casos de uso especializados
(hijos)


Ejemplo de Generalizacin
Sistema Bancario
Abrir Cuenta
Cliente
Cuenta de Cuenta Cuenta en

Ahorros Corriente Divisas


Inclusin
Una inclusin 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 lnea
punteada con flecha y comentario <<include>> que se extiende del caso de
uso base hacia el caso de uso de inclusin.
Modelan relaciones en las cuales uno o ms casos de uso incluyen (usan) el

comportamiento de un caso de uso comn.
Son usados para compartir comportamiento comn entre varios casos de uso.


Ejemplo de Inclusin
Cajero Automtico (ATM)
Retirar <<include>> Autenticar

Efectivo Usuario
Cliente


Extensin
Una extensin representa una variacin de un caso de usos a otro, aunque

similar a una generalizacin, una extensin representa una dependencia
especifica, mientras una generalizacin no implica que los casos de uso
dependen uno del otro. Esta relacin es representado por una lnea
punteada con flecha y comentario <<extend>> que se origina del caso de
uso de extensin 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 ms puntos de su
flujo de eventos.
Estos puntos se denominan puntos de extensin.
Tienen asociado una condicin 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.


Ejemplo de Extensin
Solicitud de Pedidos
Realizar <<extend>>
Agregar Cliente
Pedido
Cliente
Condicin: Modo = Cliente Nuevo

Punto de Extensin: Verificar Cliente

Muestra la relacin entre los actores y los casos de uso del sistema.
Representa la funcionalidad que ofrece el sistema en lo que se refiere a su

interaccin externa.
Los casos de uso estn en el interior de la caja del sistema.
Los actores fuera, y cada actor est unido a los casos de uso en los que participa
mediante una lnea

PASOS PARA ELABORAR DIAGRAMAS DE CASOS DE USO
Pasos:
Identificar los lmites del sistema.
Identificar los actores.
Para cada ACTOR, identificar sus objetivos.
Definir casos de uso que satisfagan sus objetivos.
Especificar los casos de uso mediante una descripcin textual

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 accin 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 abstraccin.
Evite el cruce de lneas.
Evite tener demasiados casos de uso en un mismo diagrama.
Use la regla 7 2.
Evite el uso complejo de relaciones de extensin e inclusin.

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 smbolos 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 comunicacin 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.

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-condicin 1>>

<<Pre-condicin n>>
FLUJO EVENTOS PRINCIPAL
<<Evento 1>>

<<Evento n>>
FLUJO EVENTOS ALTERNATIVOS
<<Evento 1>>

<<Evento n>>
POST-CONDICIONES (Garanta de xito)
<<Post-condicin 1>>

<<Post-condicin 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>>

EJEMPLO DE CASO DE USO (1)
Punto de venta
Procesar <<include>>
Autenticarse
Venta
Cajero

CASO DE USO
IDENTIFICADOR: 1 NOMBRE: Procesar Venta
ACTORES PARTICIPANTES Y OBJETIVOS
1. Cajero: Quiere anotaciones precisas y rpidas de precios, sin errores.
Cliente: Quiere que el pago sea rpido con el mnimo esfuerzo. Quiere una
2.
prueba de compra para justificar devoluciones.
Compaa: Quieren almacenar las transacciones y satisfacer los intereses de los
3.
clientes.
Agencias de impuestos gubernamentales: Quieren recolectar impuestos de cada
4.
venta. Puede que haya varias agencias (nacionales, regionales, etc.)
Servicios de Autorizacin de Pagos (por tarjetas de crdito/dbito): Quiere recibir
5.
peticiones digitales de autorizaciones en el formato y protocolo correcto.
6. Comercial: Quiere que se le actualicen sus comisiones por venta.
PRE-CONDICIONES
1. El cajero se ha identificado y autentificado.

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 escner de cdigo de barras o mediante el teclado
El sistema registra el elemento y presenta una descripcin del mismo, su precio
4.
y total actual. Se calcula el precio de una lista de reglas.
5. El cajero repite los pasos 3-4 hasta que no hay ms elementos.
6. El sistema presenta el total con los impuestos calculados.
7. El cajero le dice el total al cliente, y le pide que pague.
8. El cliente paga y el sistema procesa el pago.
El sistema registra la venta realizada y manda la informacin 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 invlido.
1. El sistema seala un error y rechaza la entrada.
3. 7a. Pago en efectivo.
7b. Pago con tarjeta.
POST-CONDICIONES (Garanta 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 autorizacin de crdito en menos de 30 secs, el 90% de las veces
Recuperacin robusta cuando el acceso a sistemas externos (tales como el
2.
inventario, impuestos, etc.) falla.
3. Pantalla tctil en panel grande y plano. El texto debe ser visible desde un metro.
NOTAS
1. Cules son las posibles variaciones en las leyes sobre impuestos?
2. Explorar el tema de recuperacin 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?
Proyecto: Facturacin Analista: Ing Rafael Matos
EJERCICIOS PROPUESTOS
Lnea de Taxis
La empresa de Radiotaxis ha solicitado el desarrollo de un sistema automatizado que le apoye en sus
procesos claves. El resultado de las reuniones con los diferentes usuarios arroja como resultado los
siguientes requerimientos:
Los Administrativos de la empresa de Radiotaxis podrn:
Gestionar clientes.
Ingresar reservas de viajes indicando el cliente, el chofer solicitado, la direccin de origen, de destino
y la hora de salida. Se ha solicitado que si al ingresar una reserva, el cliente no existe en el sistema
se debe ingresar directamente. Cuando se hace una reserva se debe chequear la disponibilidad de
los choferes.
Consultar, confirmar o cancelar las reservas ya ingresadas. Si al momento de confirmar una reserva,
el chofer o el cliente no pueden realizar el viaje se debe cancelar la misma.
Los Choferes de la empresa de Radiotaxis podrn consultar las reservas que tienen asignadas para el
da de la fecha.
Todos los clientes pueden consultar su reservas pero slo un cliente registrado puede hacer una reserva.
En este caso se enva un mensaje de texto al administrador para que lo confirme.
El gerente podr realizar todas las operaciones que pueden realizar los Administrativos. Adems podrn
gestionar choferes al sistema y calcular las comisiones de los choferes mensualmente tomando como
base las reservas confirmadas.
Los Representantes de la empresa aclararon que era deseable que el sistema avise a los
Administrativos, a travs de un mensaje de texto, cuando se acerca el momento de realizar un viaje, en
funcin de las reservas, con 2 horas de anticipacin para poder realizar la confirmacin del viaje con el
cliente.
EJERCICIOS PROPUESTOS
Administracin de Hotel
El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y dos tipos de clientes:
habituales y espordicos. Una reservacin almacena datos del cliente, de la habitacin reservada,
la fecha de comienzo y el nmero de das que ser ocupada la habitacin.
El recepcionista del hotel debe poder hacer las siguientes operaciones:
Obtener un listado de las habitaciones disponible de acuerdo a su tipo
Consultar el precio de una habitacin de acuerdo a su tipo
Consultar el descuento ofrecido a los clientes habituales
Preguntar por el precio total para un cliente dado, especificando su nmero de RUT, tipo de
habitacin y nmero de noches.
Dibujar en pantalla la foto de un habitacin de acuerdo a su tipo
Reservar una habitacin especificando el nmero de la habitacin y nombre del cliente.
Eliminar una reserva especificando el nmero de la habitacin
El administrador puede usar el programa para:
Cambiar el precio de una habitacin de acuerdo a su tipo
Cambiar el valor del descuento ofrecido a los clientes habituales
Calcular las ganancias que tendrn en un mes especificado (considere que todos los meses
tienen treinta das).
El hotel posee informacin sobre cuales clientes son habituales. Esta estructura puede manejarla
con un diccionario, cuya clave sea el nmero de cdula y como significado tenga los datos
personales del cliente.
El diseo a desarrollar debe facilitar la extensibilidad de nuevos tipos de habitacin o clientes y a
su vez permitir agregar nuevas consultas.

Unidad 3. Especificación de Requeriientos de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 3. Especificación de Requeriientos de Software

Cargado por

Copyright:

Formatos disponibles

Universidad Politcnica del Oeste Mariscal Sucre

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

UNIDAD II. ESPECIFICACIN DE REQUERIMIENTOS

Al finalizar esta unidad el participante ser capaz de:

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

UML (UNIFIED MODELING LANGUAGE) (1)

Es un lenguaje de modelado de sistemas que integra y unifica diferentes

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

UML (UNIFIED MODELING LANGUAGE) (2)

Es utilizado para: Se emplea directamente en las

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

UML (UNIFIED MODELING LANGUAGE) (3)

UML consta de un conjunto de notaciones grficas y un lenguaje formal

Las notaciones grficas son usadas para:

El lenguaje formal es usado para:

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

UML (UNIFIED MODELING LANGUAGE) (4)

Diagramas Estructurales Diagramas de Comportamiento

De Estructuras Compuestas De Interaccin

Fuente: OMG, 2003a

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (2)

Los Diagramas de Casos de Uso son utilizados en la Ingeniera de

Poseen una naturaleza altamente visual y la interpretacin de sus contenido

DIAGRAMAS DE CASOS DE USO (2)

Los Diagramas de Casos de Uso son utilizados en la Ingeniera de

Los requisitos funcionales de una aplicacin se especifican mediante uno o

DIAGRAMAS DE CASOS DE USO (3)

Los Diagramas de Casos de Uso modelan:

Los Actores del sistema

DIAGRAMAS DE CASOS DE USO (4)

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

Relaciones entre Actores Relaciones entre

<<include>> Caso de Uso

Limites del Sistema

DIAGRAMAS DE CASOS DE USO (5)

Representan papeles ejecutados por entidades (personas o

El smbolo es usado para representar el rol

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (6)

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (7)

Se pueden establecer relaciones de

DIAGRAMAS DE CASOS DE USO (8)

Expresa una unidad coherente de funcionalidad requerida por el sistema.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (9)

Los actores se relacionan con los casos de uso mediante asociaciones.

Una asociacin modela la comunicacin bidireccional entre un actor y un caso

Envo de datos e informacin

La comunicacin es representada simplemente por una lnea recta que se

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (10)

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

La identificacin del sistema se coloca en la parte superior izquierda.

Nombre del Sistema

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (11)

Una generalizacin indica que un caso de uso (ovalo) es un caso especial de

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

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

DIAGRAMAS DE CASOS DE USO (12)

Cuenta de Cuenta Cuenta en

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"