Tema5 Analisis I 2012

Tema 5. Anlisis de Requisitos

Primera parte

IR y M. Tema 5. Anlisis

Introduccin

Casos de uso

Modelo Entidad-Relacin

Diagramas de Flujo de Datos

Anlisis de Requisitos



Casos de Uso

Propuestos por primera vez por Jacobson en 1986

Cada caso de uso es una historia de uso del sistema

Los casos de uso NO SON ORIENTADOS A OBJETOS

Los casos de uso representan los requisitos (principalmente requisitos funcionales)

Describen un requisito teniendo en cuenta: Interaccin entre el sistema y el exterior

El Punto de vista del usuario

Realizan una nica funcin concreta

Un caso es iniciado por un nico actor


Casos de Uso

La descripcin de un caso de uso debe contener: El actor que lo inicia El objetivo del caso de uso El modo en que interactan actor y caso de uso (comunicacin,

mensajes) Datos que se manejan e intercambian Si el caso es repetitivo o se ejecuta una nica vez Definicin de todas las situaciones posibles que puedan darse durante

la ejecucin del caso de uso

Los Casos de Uso permiten : considerar y organizar los requisitos en el contexto de los objetivos y

escenarios de uso del sistema mejorar la comprensin y cohesin, frente a una lista extensa de

caractersticas inconexas


Casos de Uso Actor

Entidad con comportamiento que es externa al sistema que se est diseando. El propio sistema en estudio puede considerarse un actor (para otros sistemas) cuando solicita sus servicios

Representa a un agente externo que desencadena una secuencia de operaciones

Puede tratarse de: Usuarios que interactan con una aplicacin y que pueden

desarrollar diferentes roles

Otras aplicaciones con las que existe un interfaz

Elementos fsicos (perifricos, sensores, etc.)

El nombre asignado debe describir el papel que el actor desempea


Casos de Uso

Tipos de actores

Principal: tiene objetivos de usuario que se satisfacen mediante el uso del sistema en

estudio. Llevan a cabo la funcionalidad. Son los que desencadenan el caso de uso.

De Apoyo: proporciona servicios al sistema en estudio. Son necesarios por que aportan

informacin necesaria para el desarrollo del caso de uso. Interactan cuando el caso de uso les requiere informacin.

Pasivo: est interesado, afecta o se ve afectado de alguna forma por el

comportamiento del caso de uso, pero no interacta directamente con el sistema. Ej. La Agencia Tributaria que recibe los impuestos recaudados en las ventas.


Casos de Uso

Escenario o Curso de Eventos

Representan una secuencia especfica de acciones e interacciones entre los actores y el sistema objeto de estudio.

Los escenarios pueden utilizarse para definir: escenarios de xito: Ej. Alta de la matrcula de un alumno sin

incidencias

escenarios de fracaso: Ej. Alta de un alumno que ha seleccionado asignaturas cerradas o con incompatibilidades


Casos de Uso

Formatos de Casos de Uso

Alto Nivel o Breve: son vagos y sin comprometerse en decisiones de diseo. Escenario de xito tpico. Un prrafo. Un par de minutos.

Extendido, Expandido o Completo: describen los eventos paso a paso. Consideran el escenario principal de xito y escenarios alternativos


Casos de Uso

Estilos de Casos de Uso

Esencial: muy abstracto, libre de detalles tecnolgicos o de implementacin. Las

decisiones de diseo se difieren, especialmente en lo relacionado con la interfaz de usuario.

Real o Concreto: comprometido con un determinado diseo, una determinada interfaz

de usuario, determinadas tecnologas. Suelen hacer referencia a componentes de la interfaz de usuario e incluso pueden mostrar capturas de pantallas.


Casos de Uso

Formato de Alto Nivel

Nombre

Actores

Tipo: (Primario, Secundario, Opcional)

Descripcin


Casos de Uso

Formato Extendido Nombre Actores: indicando quin es el iniciador del caso de uso (actor principal) Propsito: intencin con la que se realiza el proceso que describe el caso

de uso Visin general: anlogo a la descripcin del caso de uso de alto nivel Tipo: (Primario, Secundario, Opcional), (Esencial, Real) Referencias: a otros casos de uso o a requisitos relacionados. Curso tpico de eventos Cursos alternativos de eventos


Casos de Uso (X)

Escenarios o Cursos de Eventos

Estilos: conversacional entre los actores y el sistema (Wirfs-

Brock). Se define una columna para el sistema y una para cada actor involucrado

Actor Sistema Actor

En una columna o secuencial

Los eventos se numeran para saber en qu orden se producen


Casos de Uso (XI)

Escenarios alternativos o Cursos alternativos Se utilizan para tratar excepciones y casos de fallo

Se tratan alternativas poco frecuentes o probables frente al curso tpico.

Si son complejos pueden dar lugar a otro caso de uso (relacionado con ste)

Se debe hacer referencia a la lnea en la que se produce la variacin respecto al curso tpico (punto de extensin)

Pueden tener a su vez escenarios alternativos anidados


Diagrama de Casos de Uso

Representa la funcionalidad que ofrece el sistema en cuanto a su interaccin externa

Muestra los casos de uso de un sistema y los actores, y las relaciones entre ellos (lneas de comunicacin)

Es una especie de Diagrama de Contexto, en el sentido de que representa los lmites del sistema.


Diagrama de Casos de Uso

Elementos:

Nombre

Nombre del Sistema

Nombre Actores

Casos de Uso

Sistema


Relaciones entre Casos de Uso

Relaciones entre casos de uso Comunicacin: representan el camino desde el que

un actor puede acceder a un caso de uso

Inclusin: determinan que un caso de uso realiza, entre otras, las operaciones expresadas en otro caso de uso, exactamente en el mismo orden. Se expresan como

Extensin: indican que un caso de uso realiza una operacin ms amplia que otro, pero con alto grado de similitud. Se expresan como



Cuando el proceso se repite en varios casos de uso (es como una

subrutina)

Cuando el proceso es largo y complejo

Representacin en el Diagrama de Casos de Uso: Flecha del llamante al llamado etiquetada con

Representacin en el texto del Caso de Uso llamante: nombre del sub-caso de uso subrayado



Cuando no se desea modificar el caso de uso original o base. Caso de uso base:

Puntos de extensin: Punto1,paso X; Punto2,paso Y

Caso de uso que extiende: Condicin de activacin Puntos de extensin: Punto1 en CasoA

Representacin en el Diagrama de Casos de Uso: Flecha del que extiende al base etiquetada con y el

punto de extensin y la condicin En el caso de uso base: enumeracin de los puntos de extensin


Ejemplo casos de uso

Contratar vuelos

Pedir los datos de la ciudad origen y destino Validar los datos de ciudad origen y destino Rellenar la fecha de partida y regreso, as como la clase de pasaje Validar las fechas y el tipo de pasaje Comprobar ocupacin Rellenar datos de tarjeta de crdito Validar formato de tarjeta de crdito Solicitar autorizacin de la operacin Emitir billete

Nombre Contratar vuelos

Actores Turista y pasarela de comercio electrnico

Tipo Primario

Precondiciones Usuario Registrado

Referencias: Especificacin de requisitos punto 2. Modelo de datos. Documentacin de IATA sobre formato de

billete areo

Curso tpico de eventos

Turista Sistema Pasarela Comercio Electrnico

1. Rellenar de ciudad origen y destino

2. Validar origen y destino

3. Rellenar fecha, hora y clase

4. Validar fecha, hora y clase

5. Comprobar ocupacin

6. Rellenar tarjeta de crdito

7. Validar tarjeta de crdito

8. Autorizar transaccin

9. Emitir billete IR y M. Tema 5. Anlisis

Ejemplo caso de uso

Formato extendido de operacin


Ejemplo casos de uso

Cursos alternativos Alternativo al paso 3. Error en origen o destino


Turista Sistema Pasarela Comercio

Electrnico

2. Validar origen y destino

3. Mostrar mensaje de

error indicando que el

origen o el destino no son

correctos

4. Volver al paso 1 del

curso tpico de eventos


Ejemplo de casos de uso

Alternativo al paso 5. Error en fecha, hora o clase de vuelo



Electrnico

4. Validar fecha, hora y clase

5. Mostrar mensaje de error

indicando que la fecha de

partida y regreso no es

correcta o que la clase de

vuelo no es correcta

6. Volver al paso 3 del curso

tpico de eventos



Alternativo al paso 6. No hay plazas disponibles



Electrnico

5. Comprobar ocupacin


indicando que el vuelo est

completo


tpico de eventos



Alternativo al paso 8. Validar tarjeta de crdito



Electrnico

7. Validar formato de tarjeta de

crdito


indicando que el formato de la

tarjeta de crdito no es correcto


tpico de eventos



Alternativo al paso 9. Emisin de billete



Electrnico

8. Autorizar transaccin


indicando que la operacin no

est autorizada por la pasarela de

comercio de electrnico


tpico de eventos



Diagrama de casos de uso

Cliente 'Pasarela C.E.'

Contratar_vuelo

'Validar tarjeta de crdito'

Validar tarjeta de crdito aparece como un caso de uso porque es utilizado tambin en otro escenario del sistema, distinto al de este ejemplo.


Desarrollado por P.P. Chen en 1976

Representacin a travs de entidades y relaciones

Son diagramas que representan el modelo de datos del problema en estudio

Muy intuitivo y con numerosas adaptaciones



Ocurrencia de entidad y entidad

Ocurrencia - Objeto que existe por s mismo y que se puede diferenciar de los otros objetos.

Concha Queta con DNI 36061281W

Entidad - Conjunto de ocurrencias del mismo tipo

Personas

No tienen por qu ser disjuntos


Entidad

Atributo - Caracterstica propia de una entidad y es comn para todas las ocurrencias del mismo tipo

Dominio - Conjunto de valores permitidos para un atributo

Para cada atributo hay que definir: Nombre

Descripcin

Funcin

Dominio


Entidad

Ejemplo:

Entidad: Empleado

Nombre Atributo: codE

Descripcin: Cdigo nico por empleado asignado por la empresa

Funcin: Identificacin (Descripcin)

Dominio: Nmeros positivos de dos cifras


Entidades

Concha Queta

NIF: 36061281W

Gran Va 9

Contratistas

Cdigo: 02

Ocurrencias de entidad

Empleado Departamento

NIF

Domicilio

Nombre

Cdigo

Descrip.

Entidades


Relaciones y ocurrencias

Ocurrencia de relacin - Asociacin entre ocurrencias de entidades

A Concha Queta se le asocia el departamento Contratistas a travs de la relacin Trabaja en

Concha Queta Contratistas Trabaja en


Relacin

Conjunto de ocurrencias de relacin del mismo tipo

Empleado Departamento Trabaja en


Relaciones

Las relaciones tambin pueden tener atributos

Producto Cliente Compra

Fecha


Relaciones

Es importante el rol o papel de cada ocurrencia

Se denomina grado de una relacin al nmero de entidades que relaciona

Empleado Es Jefe de

Jefe

Subordinado


Cardinalidad

Nmero de ocurrencias de entidad que se pueden asociar a otra a travs de una relacin

A B a1

a2

an

b1

b2

bm

... ...

1:1

Ej.:Una persona tiene un coche y un coche es de una sola persona


Cardinalidad

A B a1

a2

an

b1

b2

bm

... ...

1:N

Ej.:Una persona tiene varios coches y un coche es de una sola persona


Cardinalidad

A B a1

a2

an

b1

b2

bm

... ...

N:1

Ej.: Una persona tiene un coche y un coche es de varias personas


Cardinalidad

B a1

a2

an

b1

b2

bm

... ...

N:M

A

Ej.:Una persona tiene varios coches y un coche es de varias personas


Cardinalidad mnima

Nmero mnimo de ocurrencias de entidad que se pueden asociar a otra a travs de una relacin

Sus valores pueden ser 0 1

En otras tcnicas de modelado de datos pueden tener otros valores.


Cardinalidad

Ejemplo:

Empleado Departamento Trabaja en

Compaa Pertenece

(0,M) (1,1)

(1,M)

(1,1)


Claves

Dependencia de Identificacin (ID) - La entidad no tiene clave primaria

Cliente Factura Tiene (1,1) (0,N)

C#

Nombre

Domicilio

Num

Importe

Si la factura tiene cdigos que se repiten por cliente, no

tendr clave, pero s un discriminador

Facturas tiene dependencia de ID respecto de Cliente


Claves

Dependencia de existencia - La existencia de una ocurrencia de entidad dependiente de la existencia de otra

Cliente Factura Tiene

(1,1)

(0,N)

C#

Nombre

Domicilio

Cdigo

Importe

Aunque Factura tenga clave, si se da de

baja un cliente hay que dar de baja todas

sus facturas


Variaciones

E#

Nombre

Categora

Empleado

Trabaja

Fecha

Entidad con atributos

Relacin con atributos


Variaciones: Notacin Martin

E#

Nombre

Categora

Empleado

Trabaja

Fecha

Empleado

Trabaja



E#

Nombre

Categora

Empleado Trabaja

Fecha

Trabaja

P#

Nombre

Descrip

proyecto (0,N) (1,1)

Empleado proyecto



E#

Nombre

Categora

Empleado Trabaja

Fecha

Tiene

P#

Nombre

Descrip

proyecto (0,N) (1,M)

Empleado proyecto Partes de

trabajo

Tiene


Ejemplo

Cliente Producto Compra

(0,M)

C#

Nombre

Domicilio

Cdigo

Precio

Empleado Trabaja Departamento

(1,1)

(1,N)

(1,M)

(0,M) (0,N)

Fecha

(0,N)

(0,M)

Nombre

E#

D# Descripcin



Ejemplo (Requisitos) Departamentos: cdigo nico por departamento y el nombre

Proyectos: cdigo nico por proyecto y nombre. Cada proyecto se gestiona por un solo depto y un depto puede gestionar varios

Empleados: cdigo nico de empleado, nombre y apellidos, direccin, telfono, fecha de nacimiento, sexo, si est casado o no y sueldo que percibe.

Un empleado pertenece a un solo depto y en un depto puede haber varios empleados. Por otro lado cada departamento tiene un empleado como jefe.

Los empleados pueden participar en varios proyectos y en un proyecto pueden participar varios empleados, pero interesa saber el tiempo (en horas) que dedica cada empleado a los proyectos en los que participa.



Ejemplo (Diagrama Entidad-Relacin)

EMPLEADO E# Nombre Apellidos Direccin Telefono FechaNac Sexo Casado Sueldo

DEPARTAMENTO

D# NombreDep

PROYECTO

P# NombreP

ES JEFE DE (1,1)

(0,1)

REALIZA

(0,N)

(1,1)

PERTENECE (0,N)

(1,1)

PARTICIPA

(0,N)

(0,M) Tiempo



Carencias del modelo:

No hay posibilidad de definir restricciones entre relaciones:

Para ser jefe de un departamento hay que pertenecer al mismo?

EMPLEADO

E# Nombre Apellidos Direccin Telefono FechaNac Sexo Casado Sueldo

DEPARTAMENTO

D# NombreDep ES JEFE DE

(1,1) (0,1)

PERTENECE (0,N)

(1,1)


Modelo Entidad-Relacin Carencias del modelo:

Dos entidades pueden relacionarse a travs de dos o ms caminos de relaciones sin que se puedan establecer restricciones a estos caminos.

EMPLEADO

E# Nombre Apellidos Direccin Telefono FechaNac Sexo Casado Sueldo

DEPARTAMENTO

D# NombreDep

PROYECTO

P# NombreP

REALIZA

(0,N)

(1,1)

PERTENECE (0,N) (1,1)

PARTICIPA

(0,N)

(0,M)

Tiempo

Puede un empleado participar en un proyecto no realizado por el departamento al que pertenece dicho empleado?



Carencias del modelo:

Es importante fijarse en las carencias para completar los requisitos de forma textual.

Por lo general, la revisin de estas carencias desvelan requisitos de informacin importantes.

Dos entidades unidas por una relacin con dos cardinalidades mnimas 1 no ofrecen solucin para el estado inicial de la base de datos.

Diagrama de Flujo de Datos (DFD)

Representacin grfica en red

Los nodos representan procesos

Las aristas representan flujos de datos que se producen dentro de la organizacin o el sistema

No muestra elementos ni datos de control: no persigue representar la lgica del negocio.


DFD: componentes


Flujo de Datos Datos en movimiento

Proceso Transformacin de los datos

Almacn de Datos Datos en reposo

Entidad Externa Origen / Destino

YOURDON / DE MARCO

GANE & SARSON

SSADM METRICA

Representacin Grfica

DFD: Entidad Externa

Concepto Cualquier entidad que origina o recibe datos del sistema

(p.e. persona, entidad organizativa, otro sistema, etc.) Definen la frontera del sistema con el mundo exterior

(alcance) IMPORTANTE: Son las nicas fuentes y sumideros de datos.

Representacin Siempre aparece en el DFD de mayor nivel (Diagrama de

Contexto). Puede representarse en otros diagramas para mejorar la legibilidad.

Puede representarse varias veces en un DFD


CLIENTE

DFD: Proceso

Concepto Es una funcin que transforma flujos de datos de entrada en uno o

ms flujos de datos de salida La transformacin puede ser tan simple como aumentar el valor de la

informacin de entrada (p.e. validar un nmero de tarjeta de crdito) Puede representar una funcionalidad en diferentes niveles de

abstraccin (en funcin del nivel en que aparezcan)

Representacin Tienen un nombre y un nmero nico: el nmero suele representar el

nivel que ocupa en la jerarqua Tiene un nombre representativo de la funcin (verbo + sustantivo)


1.2 Validar tarjeta

DFD: Almacn de Datos

Concepto Representa informacin almacenada de forma

temporal y que est en reposo.

Puede representar un fichero, una tabla, etc.

Es preferible que represente una entidad o una relacin del Modelo Entidad-Relacin

Representacin Deben llevar un nombre y un identificador

Pueden representarse varias veces en un DFD


EMPLEADO

DFD: Flujo de Datos Concepto

Camino por el que fluyen paquetes de informacin de composicin conocida

Datos diferentes fluyendo entre procesos no constituyen un paquete

No son activadores de procesos

Representacin Cada flujo de datos tiene un nombre que representa la

informacin que fluye a travs de l No requieren nombres los flujos de datos que entran y

salen de almacenes simples


Parte de horas

DFD: Tipo de Flujos FLUJO DE CONSULTA

Utiliza valores de uno o ms atributos de una ocurrencia del almacn

Comprueba si valores de atributos seleccionados cumplen determinados criterios

FLUJO ACTUALIZACIN Crea nueva ocurrencia en el almacn Borra una o ms ocurrencias del almacn Modifica el valor de un atributo

FLUJO DE DILOGO Flujo de consulta y actualizacin


EMPLEADO

1.1 Listar

empleados

1.2 Contratar empleado

1.3 Asignar primas

DFD: Flujo de Datos Sncronos / Asncronos


ALMACEN TEMPORAL

PROCESO

A

PROCESO

A

PROCESO

B

PROCESO

B

Paso sncrono de informacin

entre procesos

Paso asncrono de informacin

entre procesos

Entidad E Proceso A

Proceso A Proceso B

Proceso A Almacn Z

DFD: Conexiones Permitidas


Entidad E Entidad A

Almacn A Almacn Z

Flujo F Proceso A Flujo F

Entidad A Almacn Z

DFD: Conexiones Prohibidas


Los DFDs se construyen de forma Top-down.

Primer nivel (nivel 0): Diagrama de contexto

Define los lmites del sistema

Define las entradas y salidas de datos a nivel general

El sistema se representa como un solo proceso

Contiene las entidades externas

No contiene los almacenes de datos.

DFD: Construccin


DFD: Construccin


El diagrama de contexto se descompone en el diagrama de nivel 1. Contiene los procesos principales del sistema

No Contiene las entidades externas: los flujos de entrada y salida del proceso principal aparecen como flujos de entrada y salida del diagrama de nivel 1 y deben ir conectados a procesos.

Los flujos del nivel 0 pueden descomponerse en subflujos en el nivel 1.

En este nivel ya pueden aparecer los almacenes de datos.

DFD: Construccin


DFD: Construccin


Cada uno de los procesos pueden descomponerse a su vez en otros diagramas.

Los procesos intermedios en la jerarqua slo sirven para aportar niveles de abstraccin.

Los procesos elementales o no descomponibles son los que realizan las funciones del sistema.

Los procesos elementales pueden aparecer en cualquier nivel

Una descomposicin funcional equilibrada debera mostrar 5 +- 2 procesos por diagrama.

DFD: Construccin


DFD: Construccin


Diagrama de descomposicin funcional Permiten visualizar toda la jerarqua de procesos en un solo diagrama.

DFD: Construccin


Podemos asumir que los almacenes de datos utilizados en un DFD corresponden con las entidades de el modelo entidad-relacin (notacin Martin) correspondiente al sistema analizado.

Los elementos de datos que componen los almacenes corresponden con los atributos de las entidades.

DFD: Relacin con el modelo de datos


Date post:	06-Sep-2015
Category:	Documents
Upload:	pisof
View:	228 times
Download:	0 times

Tema5 Analisis I 2012

Documents