Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Especificacin de Requisitos
Parte I. Introduccin a la
Ing. de Requisitos. Casos de
Uso
Introduccin a la Ingeniera de Requisitos
Qu entendemos por requisito?
Rational:
Una condicin o capacidad que el sistema en construccin
debe cumplir
IEEE:
Una funcionalidad del software necesaria para que el
usuario resuelva su problema o cumpla sus objetivos
Contenido
Tipos de Requisitos
Un tipo de requisito es simplemente una clase que sirve
para agrupar un conjunto de requisitos con caractersticas
similares
Tipos de Requisitos
Requisitos Funcionales
Son el tema fundamental del sistema y son medidos por
unidades de medida concretas como valores de datos,
lgica de decisin y algoritmos
Vamos a distinguir dos tipos bsicos
Caractersticas bsicas
Su objetivo es enunciar y describir brevemente las
caractersticas funcionales del producto
Son capacidades de alto nivel necesarias para cubrir las
necesidades del clientes.
Cada caracterstica es un servicio externo solicitado del
producto, que normalmente requiere una serie de entradas
para proporcionar un determinado resultado
Casos de uso
El punto de partida inicial son las caractersticas
bsicas (FEATURES en terminologa Rational)
Departamento de Lenguajes y Ciencias de la 29
Computacin.
Curso 02/03
Tipos de Requisitos
Las caractersticas forman parte del Documento General de
Requisitos
Ya que este documento ser revisado por una gran cantidad
de personas, el nivel de detalle tiene que ser lo
suficientemente general para que todo el mundo lo entienda
Sin embargo, hay que proporcionar el suficiente nivel de
detalle para que el equipo de anlisis pueda crear el modelo
de casos de uso.
Como norma general, el nmero de caractersticas no debe
exceder el rango de 25-99.
Estas caractersticas van a ser fundamentales para la
definicin del producto, y de su alcance.
Cada caracterstica ser expandida, incluyendo un mayor
detalle, en el modelo de casos de uso.
Tipos de Requisitos
Su descripcin debe incluir su funcionalidad bsica y
cualquier aspecto relevante relacionado con ella.
Tipos de Requisitos
Requisitos No Funcionales
Se refieren a otras propiedades que deben tener las funciones
especificadas:
Requisitos de Aspecto
Requisitos de Facilidad de Uso y Aprendizaje
Requisitos de Funcionamiento
Requisitos Operacionales
Requisitos de Mantenimiento y Portabilidad
Requisitos de Seguridad
Requisitos Culturales y Polticos
Requisitos Legales
No todos tienen que aplicarse en todos los proyectos
En nuestra plantilla de requisitos vamos a incluirlos bajo un
solo tipo de requisito como requisito adicional (ADC),
identificndolos en su descripcin
En caso de que el nmero de requisitos se vuelva no
manejable se pueden definir nuevos requisitos para algunos
de ellos
Tipos de Requisitos
Los tipos de requisitos en la herramienta se definen a nivel
de proyecto
Puede existir una plantilla de documento para cada tipo de
documento
Trazabilidad
La existencia de distintos tipos de requisitos y la
derivacin de unos a partir de otros, hace necesario que se
establezcan mecanismos de trazabilidad.
Por ejemplo:
Las peticiones de usuario (PET), estn relacionadas con las
caractersticas funcionales bsicas (CAR) y a caractersticas
adicionales (ADC)
Las caractersticas funcionales a su vez son el punto de
partida para los casos de uso
Los casos de prueba, a su vez, estn relacionados con los
requisitos a travs de la prueba de verificacin
Adems los requisitos no son independientes entre si
Para poder determinar el impacto de un cambio en un
requisito, las relaciones entre requisitos deben ser
entendidas, documentadas y mantenidas
Las herramientas como RequisitePro ayudan a mantener la
trazabilidad
Trazabilidad
Trazabilidad
Trazabilidad
Atributos
Cada tipo de atributo puede tener un conjunto de atributos
propio
Los atributos pueden ser utilizados para crear vistas:
Caractersticas que tienen una determinada prioridad
Iteracin a la que pertenecen determinados casos de uso
Los atributos ms comunes son los siguientes:
Estado
Beneficio
Esfuerzo
Riesgo
Estabilidad
Versin objetivo
Asignada a
Atributos
Estado
Se asigna despus de la negociacin y debe ser
revisado por el equipo de seguimiento del proyecto.
El progreso para cada atributo se realizar despus de
la definicin de cada una de las lneas base
Propuesta Indica que una caracterstica est an bajo
discussion y que an no ha sido aceptada de
manera oficial..
Atributos
Beneficio
Atributo establecido por a nivel de direccin de
producto para determinar la prioridad de desarrollo
Crtico Caracterstica esencial. Un fallo en la
implementacin de esta funcionalidad indicar que
el proyecto no cumple las necesidades bsicas del
usuario. Un fallo en la implementacin de alguna
de estas caractersticas implicar un retraso en la
planificacin del proyecto.
Importa Caracterstica importante para la efectividad y
nte eficiencia del sistema y que no puede ser
sustituida de ninguna otra forma. Un fallo en la
inclusin de esta caracterstica puede afectar a la
satisfaccin del cliente, pero la planificacin no
til debe ser afectada..
Caractersticas tiles pero cuya funcionalidad, al
menos temporalmente, no afecta a la utilizacin
efectiva del producto. Si no est lista para la
versin planificada puede ser incluida en una
siguiente iteracin.
Atributos
Esfuerzo
Establecido por el equipo de desarrollo. Debe estar
medido en nmero de personas-semana, lneas de
cdigo o alguna otra mediada de complejidad. Se
utilizar para establecer la prioridad
Riesgo
Establecido por el equipo de desarrollo y basado en la
probabilidad de que el proyecto experimente problemas
no deseados durante su desarrollo (exceso de costes,
retrasos o incluso cancelacin
Se establecen normal mente tres niveles: alto, medio o
bajo, aunque se pueden utilizar graduaciones ms finas.
El riesgo puede ser inferido indirectamente midiendo la
certeza (rango) de las estimaciones de la planificacin
del proyecto por parte del equipo de desarrollo
Departamento de Lenguajes y Ciencias de la 41
Computacin.
Curso 02/03
Atributos
Estabilidad
Establecido por el analista y el equipo de desarrollo a partir de
la probabilidad de que la caracterstica cambia tras un anlisis
posterior de la misma
Se utiliza para establecer prioridades y para seleccionar que
requisitos deben ser analizados en prximas reuniones
Versin objetivo
Versin en la que est planificada la inclusin de esta
caracterstica
Asignada a
Persona o equipo de personas encargadas de escribir los
requisitos definitivos para esta caracterstica y probablemente
para su diseo e implementacin final
Se utiliza como base para el establecimiento de
responsabilidades
Atributos
Atributos
Contenido
1. Introduccin
2. Directivas del Proyecto
3. Descripcin de participantes y usuarios
4. Visin General del Producto
5.Requisitos Funcionales
6.Precendecia y prioridad
7.Requisitos No Funcionales
8.Requisitos de Documentacin
9. Anexo I. Atributos de las
Caractersticas Funcionales
10.Anexo II. Cuestiones Abiertas
Qu es el AR
Para construir algo primero hay que
entenderlo
AR: proceso de comprensin y descripcin
Regla: Comprender qu debe hacer la
aplicacin (retrasar el cmo debe hacerlo)
Es un Req: El sistema permitir al usuario
acceder a la informacin de su cuenta.
No es un Req.: Los balances se almacenarn en
una tabla llamada balanceUsu en una BD
AccessTM.
Qu es el AR
Puntos de vista
Requisitos-C y requisitos-D
Dos visiones del mismo producto
Cliente:
Deseos y necesidades
Lenguaje
Desarrollador:
Tcnicos
Estructurados
Especficos
Nuestra labor: producir especificaciones con
los requisitos del cliente para este y para los
desarrolladores
Casos de Uso
Casos de Uso
Los casos de uso son principalmente
descripciones textuales
La notacin grfica de UML (diagrama de
casos de uso) solo muestra los nombres y
sus relaciones
Al ser textuales, son informales y no son
buenas para razonar acerca del sistema
Para el diseo mejor utilizar los diagramas de
interaccin resultantes de su formalizacin.
Sin embargo stos dependen de los
requisitos.
Casos de Uso
Casos de Uso
Casos de Uso
Casos de Uso
Los casos de uso afectan a diferentes
porciones del sistema en cuestin. Este es
su mbito.
Casos de Uso
Casos de Uso
logout
<<include>> modificar parmetros
<<include>>
acciones instructor
login controlCI
Instructor
control backtrack
sesin alumno
Extensin
Se utiliza para modelar la parte de un caso de uso que
puede ser vista como un comportamiento opcional
Tambin se pueden utilizar para modelar un subflujo
separado que solo se ejecuta bajo ciertas condiciones
Un ejemplo es el modelado de varios flujos que se puedan
dar en un punto dado por la interaccin explicita con un
actor
identificacin
<<include>>
Acciones de Alumno
Nacional
<<includes>>
Marcar Nmero
<<extends>> Internacional
Realizar Llamada
Llamante
<<extends>>
<<extends>>
Numero no existe
<<extends>>
Numero Incorrecto
Comunicando
Recibir Llamada
Llamado
Llamada no atendida
<<includes>>
<<includes>> <<includes>>
<<includes>>
Obtener un Balance
Ingresar Dinero Transferir Dinero Sacar Dinero
<<includes>>
<<includes>>
<<includes>>
Correo
Casos de Uso
Niveles:
Resumen
Ciclo de vida Cuenta
Usuario
Ingresar Dinero
Transferir Dinero
Obtener un Balance
Sacar Dinero
Subfuncin
Identificar Cliente
Identificar Ciente y Cuenta en Cajero Automtico
Caso
Casodedeuso:
uso:Nombre
Nombredel delcaso
casode deuso
uso
Este
Estees
esel
elobjetivo
objetivodeldelcaso
casodedeusousodescrito
descritocon
conuna
una
frase
frasecorta
corta
mbito:
mbito:LaLacaja
cajaconsiderada
considerada
Nivel:
Nivel:Uno
Unodedelos
lostres
tresniveles
nivelesdescritos
descritos
Contexto
Contextodedeuso:
uso:UnaUnafrase
frasems
mslargalargacon
conlala
descripcin
descripcindel
delobjetivo
objetivoyylas
lascondiciones
condicionesnormales
normalesde de
desarrollo,
desarrollo,precondiciones,
precondiciones,... ...
Actor
ActorPrincipal:
Principal:Un Unnombre
nombrede derolroldel
delactor
actorprincipal
principaloo
su
sudescripcin
descripcin
Escenario
Escenariodedexito
xitoPrincipal:
Principal:......
Extensiones:
Extensiones:......
Escenario
Escenariode
dexito
xitoPrincipal:
Principal:
Nmero_de_Paso
Nmero_de_Paso"." "."descripcin_de_accin
descripcin_de_accin
Se
Senumeran
numerantodos
todoslos
lospasos
pasosdel
delescenario
escenariodesde
desde
el
eldisparo
disparoalalobjetivo
objetivo
Se
Sepueden
puedenanidar,
anidar,utilizando
utilizandonumeracin
numeracinde de
Dewey
Dewey(3.1.2)
(3.1.2)
No
Nose
sedeben
debenincluir
incluirsentencias
sentenciascondicionales;
condicionales;las
las
condiciones
condicionesyyalternativas
alternativassesemuestran
muestranen
enlalaparte
parte
de
deextensin
extensin
Extensiones:
Extensiones:...
...
Extensiones:
Extensiones:
Condicin
Condicinespecial
especial":"
":" Descripcin
Descripcinde
deaccin
accin
||sub-caso
sub-casode
deuso
uso
Siempre
Siemprese
serefiere
refiereaaun
unpaso
pasodel
delescenario
escenarioprincipal
principal
Una
Unaextensin
extensinoosustituye
sustituyealalpaso
pasoprincipal
principalooes
esuna
una
alternativa.
alternativa.La
Lanotacin
notacinutilizada
utilizadaes:
es:
Sustitucin:
Sustitucin: 22||||
Alternativa:
Alternativa: 2a2a
Una
Unaalternativa
alternativapuede
puedecorresponder
corresponderaaun
un
comportamiento
comportamientoregular,
regular,excepcional
excepcionalrecuperable
recuperableoo
errneo
errneono
norecuperable
recuperable
Ejemplo
Caso
Casode
deuso:
uso:Ciclo
Ciclode
deVida
Vidade
deCuenta
Cuenta
mbito:
mbito:ElElsistema
sistemacompleto
completo
Nivel:
Nivel:Resumen
Resumen
Contexto
Contextode deuso:
uso:Para
Parainteractuar
interactuarcon
conelelsistema
sistemaelel
cliente
clientees
esrepresentado
representadoporporun
uncajero
cajerooopor
porcajero
cajero
automtico
automtico
Actor
ActorPrincipal:
Principal:Cliente
Cliente
Ejemplo
Escenario
Escenariode dexito
xitoPrincipal:
Principal:
1.1. Un
Uncliente
clienteinforma
informaal alcajero
cajerode deque
quequiere
quiereabrir
abriruna
una
cuenta
cuenta
2.2. En
Enrepresentacin
representacindel delcliente
clienteelelcajero
cajeroinicia
iniciala
la
apertura
aperturadedelalacuenta
cuentaen enelelsistema
sistema
3.3. El
Elsistema
sistemasolicita
solicitaal
alcajero
cajerola lasiguiente
siguiente
informacin:
informacin:
Nombre
Nombre
Direccin
Direccin
DNI
DNI
Tipo
Tipode
deCuenta
Cuenta
4.4. El
Elsistema
sistemavalida
validala
lainformacin
informacinyycrea creala
lacuenta
cuentadel
del
cliente
cliente
Ejemplo
Escenario
Escenariode
dexito
xitoPrincipal:
Principal:
Los
Lospasos
pasosdel
del55al
al88son
sonopcionales,
opcionales,individualmente
individualmenterepetibles
repetibles
yypueden
puedenocurrir
ocurriren
encualquier
cualquierorden
orden
5.5. El
Elcliente
clienteingresa
ingresadinero
dinerosub-caso
sub-casode deuso
uso
6.6. El
Elcliente
clienteobtiene
obtieneun unbalance
balancesub-caso
sub-casode deuso
uso
7.7. El
Elcliente
clientesaca
sacadinero
dinerosub-caso
sub-casode deuso
uso
8.8. El
Elcliente
clientetransfiere
transfieredinero
dinerosub-caso
sub-casode deuso
uso
9.9. Este
Estepaso
pasoseserepite
repiteindefinidamente
indefinidamenteuna unavezvezal
almes
mesdesde
desdela la
fecha
fechadedeapertura
aperturahasta
hastafecha
fechadedecierre
cierre
El
ElSistema
Sistemaenva
envapor
porcorreo
correoordinario
ordinariolalainformacin
informacinde desusu
cuenta
cuentaalalcliente
cliente
10.
10. El
Elcajero,
cajero,representando
representandoal alcliente,
cliente,inicia
iniciael
elcierre
cierrede
delalacuenta
cuenta
11.
11. El
Elsistema
sistemaelimina
eliminalalacuenta
cuenta
12.
12. El
Elsistema
sistemaenva
envaununbalance
balancecon
conlos
losltimos
ltimosmovimientos
movimientos
Departamento de Lenguajes y Ciencias de la 85
Computacin.
Curso 02/03
Ejemplo
Extensiones:
Extensiones:
4a.
4a.El Elsistema
sistemainforma
informaque queel
elcliente
clienteya
yatiene
tieneuna
unacuenta
cuenta
de
deeste
estetipo
tipoabierta
abierta
4a.1.
4a.1.El
Elsistema
sistemasolicita
solicitaal
alcajero
cajeroque
queconfirme
confirmela la
creacin
creacinde delalacuenta
cuenta
4a.2a.
4a.2a.ElElcajero
cajeroconfirma
confirmala lacreacin
creacinyyelelcaso
casodede
uso
usocontinua
continuapor porelelpaso
paso33
4a.2b.
4a.2b.ElElcliente
clientedecide
decidenonocrearla
crearlayyel
elcaso
casodede
uso
usofinaliza
finalizasin
sinningn
ningnefecto
efectosobre
sobreel el
estado
estado
........
........
Fallos Comunes
1. Lmites
2. Punto de vista
3. Actores
4. Demasiados CU
5. Telas de araa
6. Especificaciones laaargas
7. Especificaciones confusas
8. Descripcin funcional errnea
9. Ininteligibles
10. Inacabados
Glosario
Actor: Algo o alguien con un comportamiento.
Parte: Algo o alguien con un inters en el comportamiento del
sistema.
Actor principal: Parte que inicia una interaccin con el
sistema para lograr un objetivo.
Caso de uso: Contrato acerca del comportamiento del
sistema.
mbito: Identifica el sistema que se trata.
Precondiciones y garantas: Lo que debe ser cierto antes y
despus de la ejecucin del caso de uso.
Escenario principal de xito: El caso en que todo sale bien.
Extensiones: Variantes del EPE.
Referencias: Para referenciar un caso de uso en otro se
subraya.
Diferentes lenguajes
Diferentes necesidades
Diferentes intereses
Cmo garantizar que la traduccin es correcta?
Departamento de Lenguajes y Ciencias de la 92
Computacin.
Curso 02/03
Actores y partes
Los casos de uso constituyen un contrato de
funcionalidad
SUD (system under discussion) /SEC (sistema en cuestin)
Los actores tienen objetivos
Las partes tienen intereses
Cada lnea o frase de un caso de uso describe una
accin relevante para los intereses de una parte
Una lnea describe:
Una interaccin entre actores
Lo que el sistema debe hacer para proteger los intereses
de las partes
Actores y partes
Niveles: Las pulgas de las pulgas
Fallo: Los objetivos pueden no cumplirse
Escenario: Una interaccin compuesta (unas
circunstancias determinadas y un resultado)
Un caso de uso agrupa todos los escenarios (xito
y fallo)
La metfora de los pantalones
Un escenario puede contener subcasos de uso
(pasos).
Un paso de un escenario no depende de qu
evolucin del subcaso de uso se dio sino de su
resultado.
Departamento de Lenguajes y Ciencias de la 97
Computacin.
Curso 02/03
Actores y partes
El actor principal y los representantes
Importancia del actor principal Importancia
Actores Objetivos
Actores y Roles
Tabla actores/roles
Requisitos Entrega
Introduccin
Generalizacin (UML)
Descripcin de actores (nombre, alias, perfil)
Actores de Soporte
SEC
Actores Internos y Cajas Blancas
Ejercicio:
Qu son?
Cajero Aut.
Cliente
Tarjeta de crdito
Banco
Panel
Propietario del banco
Personal de servicio
Impresora
Sistema informtico del banco
Cajero (empleado)
Ladrn
Departamento de Lenguajes y Ciencias de la 99
Computacin.
Curso 02/03
Ejercicio:
Qu son?
Cajero Aut. SUD
Cliente Actor Ppal y Parte
Tarjeta de crdito No Actor
Banco No Actor
Panel Componente, No Actor
Propietario del banco Parte
Personal de servicio Actor Ppal
Impresora Componente
Sist. Inform. del banco Actor secundario
Cajero (empleado) ?
Ladrn !
Departamento de Lenguajes y Ciencias de la 100
Computacin.
Curso 02/03
Puntos importantes
Dedicar el mayor esfuerzo a los CU de usuario
Crear algunos CU de resumen para poner en
contexto los de usuario
No enfadarse porque un requisito no llegue
a CU
Ejercicio: criticar
Caso de uso: login
Este caso de uso describe el proceso de conexin al sistema de gestin de pedidos. Adems
establece los permisos para las diferentes categoras de actores.
EPE:
1. El caso de uso se inicia cuando el usuario inicia la aplicacin
2. El sistema presentar la pantalla de login
3. El usuario introduce su nombre y password
4. El sistema verificar la informacin
5. El sistema establecer los permisos de acceso
6. El sistema mostrar la pantalla principal
7. El usuario seleccionar una funcin
8. Mientras el usuario no seleccione SALIR hacer
9. Si el usuario selecciona Crear pedido, Usar Crear pedido
10. Si el usuario selecciona Devolucin, Usar Devolucin
11. Si el usuario selecciona Cancelar Pedido, Usar Cancelar Pedido
12. Si el usuario selecciona Obtener Estado, Usar Obtener Estado
13. Si el usuario selecciona Ver Catlogo, Usar Ver Catlogo
14. Si el usuario selecciona Queja, Usar Queja
15. Si el usuario selecciona Informe de Ventas, Usar Informe de Ventas
16. Fin Si
17. El usuario seleccionar una funcin
18. Fin Mientras
19. El caso de uso finaliza
Ejercicio: criticar
Caso de uso: login
Este caso de uso describe el proceso de conexin al sistema de gestin de pedidos. Adems
establece los permisos para las diferentes categoras de actores.
EPE:
1. El caso de uso se inicia cuando el usuario inicia la aplicacin
2. El sistema presentar la pantalla de login
3. El usuario introduce su nombre y password
4. El sistema verificar la informacin
5. El sistema establecer los permisos de acceso
6. El sistema mostrar la pantalla principal
7. El usuario seleccionar una funcin
8. Mientras el usuario no seleccione SALIR hacer
9. Si el usuario selecciona Crear pedido, Usar Crear pedido
10. Si el usuario selecciona Devolucin, Usar Devolucin
11. Si el usuario selecciona Cancelar Pedido, Usar Cancelar Pedido
12. Si el usuario selecciona Obtener Estado, Usar Obtener Estado
13. Si el usuario selecciona Ver Catlogo, Usar Ver Catlogo
14. Si el usuario selecciona Queja, Usar Queja
15. Si el usuario selecciona Informe de Ventas, Usar Informe de Ventas
16. Fin Si
17. El usuario seleccionar una funcin
18. Fin Mientras
19. El caso de uso finaliza
Cundo acabamos?
Tenemos todos los actores principales y todos los
objetivos de nivel de usuario
Tenemos todos los disparos (como disparos de CU o
como extensiones)
Hemos escrito todos los CU de usuario y los de
resumen y subfuncin que los soportan
Cada CU est descrito de forma que:
Los clientes reconocen que pueden saber si se cumplen
Los usuarios reconocen que son los que queran (o con los
que se conforman)
Los desarrolladores reconocen que pueden proporcionar
esa funcionalidad.
Los clientes reconocen que el conjunto de CU es el
que queran
Departamento de Lenguajes y Ciencias de la 113
Computacin.
Curso 02/03
Colaboraciones
Colaboraciones
Una colaboracin tiene dos aspectos:
Estructural: especifica las clases, interfaces o
componentes
Se organizan utilizando las relaciones normales de UML
(asociaciones, generalizaciones y dependencias)
Al contrario que los paquetes o subsistemas, no contienen
a sus elementos.
Puede hacer referencia o utilizar elementos declarados en
distintos sitios
Se trata de un bloque conceptual de la arquitectura del
sistema
Comportamiento: dinmica de cmo interactan estos
elementos
Se representa mediante diagramas de interaccin
Debe ser consistente con la visin estructural
Colaboraciones
Agente de Transporte
emisor
recibido
IDistribuido
enviarMensaje()
1
1
Cola Mensaje
ID
aadirMensaje() cabecera
quitarMensaje() cuerpo
contar()
colaDeEntrada colaDeSalida
Colaboraciones
1: crear
Colaboraciones
Representacin
Paso de Mensajes
Colaboraciones
Colaboraciones
Interacciones
Definicin
Una interaccin es un comportamiento que implica un
intercambio de de mensajes entre varios objetos en un
contexto determinado con un objetivo determinado
Se utilizan para expresar los aspectos dinmicos
de las colaboraciones
Las interacciones se llevan a cabo entre objetos
no entre clases
Un enlace es una conexin semntica entre
objetos
Para que se pueda enviar un mensaje entre dos objetos
debe existir un enlace
Un enlace es una instancia de una asociacin entre
clases
Departamento de Lenguajes y Ciencias de la 121
Computacin.
Curso 02/03
Interacciones
Persona Empresa
1..* *
Asociacin
Asignar(desarrollo)
P:Persona :Empresa
Enlace
Interacciones
Normalmente basta con indicar que existe un enalce, pero se
puede indicar el tipo de enlace utilizando los estereotipos:
Association
Self
Global
Local
Parameter
Los mensajes tambin pueden ser ms o menos detallados
[Pre] 1:*(expr):mensaje(p,q):Valor
Precondicin Valor de
Retorno
N secuencia Parmetros
Expresin Identificador
Iteracin
Diagramas de Interaccin
Diagramas de Interaccin
Diagramas de Secuencia
Los diagramas de secuencia se suelen asociar a los casos de uso,
mostrando como estos se realizan a travs de interacciones entre
sociedades de objetos
Consola BD
: Instructor Instructor instructores
Foco de
1: login(usuario)
2: leer(usuario) Control
Lnea de
3: usuario correcto
Vida
4: iniciar sesion
5: usuario aceptado
Diagramas de Secuencia
generalmente a 1: login
mtodos de los
objetos 2: crear sesion
Diagramas de Secuencia
Diagramas de Colaboracin
Diagramas de Colaboracin
Diagramas de Colaboracin
Consola BD
: Instructor Instructor instructores
1: login(usuario)
Consola
Instructor 1: login(usuario)
2: leer(usuario)
5: usuario aceptado
: Instructor
3: usuario correcto
3: usuario correcto
4: iniciar sesion
2: leer(usuario)
5: usuario aceptado
BD
instructores
Diagramas de Interaccin
Diagramas de Interaccin
Consola BD
: Instructor Instructor instructores
inicio 1: login(usuario)
2: leer(usuario)
3: usuario correcto
4: iniciar sesion
{Iniciar sesion.executionTime<5s}
5: usuario aceptado
fin
{inicio-fin<10s}
Recursos interesantes
http://www.usecases.org
http://www.object-ideas.com/oouc2/index.htm
http://www.foruse.com
http://www.pols.co.uk/usecasezone/
http://www.omg.org
http://www.software-engin.com/
http://polaris.lcc.uma.es/~amg/ISE/OOP-Java-UML.zip
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
Artculo
Pedido
Descricin
Fecha de emisin
Foto
Direccin de Entrega
1..n Precio
1..n +pagable
Factura
Cuenta
Cantidad +comprador
Saldo
Fecha de Emisin
Titular
Fecha Lmite de Pago 1
: Comprador : Vendedor
3: Enva factura 2: Enva factura
: Gestor de Pagos
: Cuenta
: Factura
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
El Modelo de Anlisis
Un modelo de anlisis tiene la siguiente
estructura descrita en UML
El Modelo de Anlisis
El paquete del sistema es el de ms alto nivel
La utilizacin de otros paquetes tiene como
objetivo organizar el modelo en partes ms
manejables que representan abstracciones de
subsistemas
Las clases de anlisis representan abstracciones
de clases y posiblemente de subsistemas del
diseo del sistema
Las realizaciones de los casos de uso se
describen mediante clases/objetos de anlisis
El Modelo de Anlisis
Clase de Anlisis
Se centran en el tratamiento de los requisitos
funcionales y pospone los no funcionales
Se trata de una clase evidente en el dominio del
problema (ms conceptual que las de diseo)
No contiene operaciones, ni signaturas
Su comportamiento se define mediante responsabilidades
Una responsabilidad es una descripcin textual de un
conjunto cohesivo del comportamiento de una clase
Define atributos de alto nivel (sus tipos son
conceptuales y reconocibles en el dominio del
problema)
Normalmente pasan a ser clases en el modelo de diseo
Las relaciones son conceptuales, no implican nada en
la fase de diseo e implementacin (ej. herencia)
Departamento de Lenguajes y Ciencias de la 156
Computacin.
Curso 02/03
El Modelo de Anlisis
Clase de Anlisis
Siempre encajan en uno de tres estereotipos bsicos:
Clase de Anlisis
Atributos de alto nivel
Responsabilidades()
Entidad Interfaz
Control
El Modelo de Anlisis
Clases de Interfaz
Se utilizan para modelar la interaccin entre el sistema y sus
actores (usuarios y sistemas externos)
La interaccin suele implicar recibir/presentar
informacin/peticiones de/hacia los usuarios y sistemas externos
Modelan las partes del sistema que dependen de sus actores
Clarifican y renen los requisitos en los lmites del sistema
Un cambio en un interfaz de usuario o en un interfaz de
comunicaciones queda aislado en una o ms clases de interfaz
Representan a menudo abstracciones de:
Ventanas
Formularios
Paneles
Interfaces de comunicacin
Sensores
APIS
Deben ser abstractas, describiendo solo la informacin y las
peticiones que se intercambian entre el sistema y sus actores
El Modelo de Anlisis
Clases de Entidad
Modelan informacin persistente
Tambin se usan para modelar la informacin y el
comportamiento asociado de algn fenmeno o
concepto del mundo real
Normalmente se derivan directamente de una clase del
modelo del negocio o del dominio correspondiente
Las diferencias son:
Que su definicin va orientada a los desarrolladores al
disear o implementar el sistema e incluye aspectos como su
soporte de persistencia
En las de dominio existe informacin del entorno del sistema
que puede no tener que manejarse en ste
Una entidad no tiene por qu ser pasiva
Pueden tener un comportamiento complejo
correspondiente a la informacin que respresentan
El Modelo de Anlisis
Clases de Control
Representan coordinacin, secuencia, transacciones y
control de otros objetos
Se utilizan para encapsular el control de un caso de uso
concreto
Modelan los aspectos dinmicos internos del sistema,
no los externos (interaccin con los usuarios), que son
modelados por las clases de interfaz
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
Anlisis de la Arquitectura
Es la primera actividad para definir el modelo de
anlisis
Los pasos bsicos de esta actividad son los
siguientes:
Identificacin de paquetes de anlisis
Identificacin de clases del anlisis
Requisitos especiales comunes
El punto de partida es:
El modelo del negocio
El modelo de casos de uso
La descripcin de los requisitos adicionales obtenida en
el documento general de requisitos
Anlisis de la Arquitectura
Identificacin de paquetes del anlisis
Proporcionan un medio para organizar el modelo de
anlisis en piezas ms pequeas
Pueden identificarse:
Inicialmente como forma de dividir el trabajo de anlisis
Nos basamos en los requisitos funcionales y el dominio del
problema
Asignamos los casos del uso al paquete atendiendo a:
Su relacin en un proceso de negocio
Los necesarios para dar soporte a un actor
Los casos de uso relacionados mediante relaciones de
generalizacin y extensin
Encontrarse a medida que el modelo crece
Qu hacemos en caso de entidades/casos de uso
compartidos?
Paquete independiente
Entidad aislada, con relaciones de traza
Anlisis de la Arquitectura
Identificacin de clases de entidad
Se puede empezar con un conjunto de clases basado en
las del dominio
Se confirma su adecuacin al realizar los casos de uso
El nmero debe ser pequeo para no perdernos en los
detalles al especificar las realizaciones
Para identificar las relaciones, partimos del modelo de
dominio e incluimos nuevas si es necesario para la
realizacin de los casos de uso
Anlisis de la Arquitectura
Identificacin de requisitos adicionales comunes
Se trata de requisitos que aparecen durante el anlisis,
pero no deben ser tratados hasta las fases de diseo o
implementacin
Persistencia
Distribucin y concurrencia
Tolerancia a fallos
Igual que en el caso anterior estos requisitos suelen
aparecer durante la realizacin de los casos de uso
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen
Anlisis de un Paquete
Objetivos:
Garantizar que un paquete sea tan independiente como
sea posible
Garantizar que cumple su objetivo de realizar clases de
dominio o casos de uso
Describir las dependencias de forma que pueda
estimarse el efecto de los cambios futuros
Contenido
Introduccin
Antes de comenzar el anlisis
Modelo de Anlisis
Realizacin de caso de uso-anlisis
Anlisis de la arquitectura
Anlisis de un caso de uso
Anlisis de una clase
Anlisis de un paquete
Resumen