ING
EN
IER
ÍA D
EL S
OFT
WA
RE
IP
ráctica 3
Modelado de R
equisitos
Un
iv. Can
tabria –F
ac. de Cien
ciasM
aría Sierra y Patricia López
Modelo de D
ominio o conceptual
•¿Q
ué
es?Captura los conceptos (tipos de objetos) m
ás importantes del contexto del
sistema
Desde el punto de vista del problem
a, no de la solución.•
Ob
jetos
“cosas”que existen o eventos que suceden en el entorno en que trabaja el
sistema
•¿O
bten
ción
de o
bjeto
s o clases?
Especificación de requisitos o entrevista•
Clases d
e Do
min
ioO
bjetos del negocio: pedidos, cuentas, contratosO
bjetos del mundo real y conceptos que requieren seguim
iento: aviación enem
iga, misiles, trayectorias
Sucesos: llegada y salida de un avión, hora de comida
•El m
od
elo d
e do
min
iose representa a través de un d
iagram
a de
clases:Con asociaciones entre ellas, pero sin cualificar (sin adornos)Se pueden incluir atributos en las clases (de form
a conceptual)
Ejemplo Práctico de D
esarrollo de Software
El proyecto consiste en el desarrollo de un sistema de
gestión para
una em
presa de
autobusesque
se dedica
al transporte regional, nacional e internacional de viajeros. Las necesidades
de esta
empresa
son la
gestión de
viajes ofertados, trabajadores y gestión de billetes.
(El resto del enunciado lo podeisconsultar en la página w
eb)
Modelo de D
ominio
Modelado con D
iagramas de Casos de U
so
•Los D
iagramas de Casos de U
sosirven para
mo
delar:
El Co
mp
ortam
iento
de u
n E
lemen
toSistem
a, Subsistema, Com
ponente, Clase.
El Co
ntex
to d
el Sistem
a
Los Req
uisito
s del S
istema
Modelado –
Contexto del Sistema
•Identificar los actores,externos al sistem
a pero que interactúan con el, considerando los roles que
requieren ayuda del sistema
para llevar a cabo sus tareas,
son necesariospara ejecutar las funciones del sistem
a,
interactúancon el hardw
are externo o con otros sistemas softw
are, y
realizan funciones secundariasde adm
inistración y mantenim
iento.
•O
rganizarlos actores
similares en jerarquías de
generalización/especialización.
•Introducir esos actores en un D
iagrama de Casos de U
soy
especificar la comunicación de cada actor con los casos de
uso del sistema.
Modelado –
Contexto del Sistema
Modelado –
Requisitos del Sistem
a
•Establecer el contexto del sistem
a, identificando los actores.•
Considerar el comportam
ientodel sistem
aque cada actor
espera o requiere que éste proporcione.•
Nom
brar los comportam
ientos comunes com
o casos de uso.•
Factorizarel com
portamiento com
ún y el comportam
iento variante.
El común en nuevos casos de uso que puedan ser utilizados por otros.
El variante en nuevos casos de uso que extiendan los flujos principales
•M
odelar esos casos de uso, actores y relaciones en un diagram
a de casos de uso.•
Adornar esos casos de uso con notasque enuncien los
requisitos no funcionales.
Modelado –
Requisitos del Sistem
aM
odelado –Com
portamiento de un Elem
ento
•Identificar los actores
que interactúan con el elemento.
•O
rganizar los actoresidentificando tanto los roles m
ás generales com
o los más especializados (generalizaciones).
•Considerar
las formas m
ás importantes
que tiene cada actor de interactuarcon el
elemento.
las formas excepcionales
en las que cada actor puede interactuar con el elem
ento.
las interacciones que implican el cam
bio de estadodel elem
ento o de su entorno o que involucran una respuesta ante
algún evento.
•O
rganizarestos com
portamientos com
o casos de uso.U
tilizando las relaciones de inclusión y extensiónpara factorizar el
comportam
iento común y distinguir el com
portamiento excepcional.
Modelado –
Comportam
iento de un Elemento
•Ejem
plo. Subsistema de G
estión de Billetes.D
efinición Caso de Uso. Com
prar billete OnLine
Descrip
ción
El cliente compra un billete a través de la página w
eb.P
recon
dicio
nes
Se tieneacceso
a la páginaw
eb•
Po
st-con
dicio
nes
El billete ha sido creado y almacenado
•Flu
jo d
e evento
s1.
Si el cliente no estáregistrado =
> Caso de uso registrarse
2.El cliente introduce usuario y contraseña
3.El sistem
a pide los datos del billete: origen, destino y fecha.4.
El cliente introduce los datos 5.
El sistema com
prueba que quedan asientos libres en el viaje elegido.6.
Se informa al cliente de los asientos asignados.
7.Si el cliente elige la opción de asignar asientos =
> Caso de uso Seleccionar Asiento
8.El sistem
a pide datos de pago9.
El cliente introduce los datos de pago10.
El sistema realiza la transacción
11.Se actualiza el núm
ero de asientos disponibles en el viaje12.
Se envía un correo electrónico al cliente con los datos de su billeteFlujo alternativo o de excepcion
El cualquier punto antes de 10 el cliente puede cancelar la operaciónEn 10 el sistem
a puede rechazar los datos del cliente, mostrar un m
ensaje y volver a 8.
Modelado –
Comportam
iento de un Elemento
Diagram
as de casos de uso en VP: CreaciónD
iagramas de casos de uso en VP: Creación
•Los elem
entos se pueden añadir haciendo uso de la interfaz de recursos centrados
Asociación con C
aso de Uso
Asociación H
erencia con otro actor
Agregar una nota
Asociación con A
ctor
Relación <
<include>
> con otro C
DU
Agregar una nota
Relación <
<extend>
> con otro C
DU
Relación herencia con otro C
DU
Diagram
as de casos de uso en VP: Especificación
Plantilla para ladescripción
de escenarios delos casos de uso
Diagram
as de casos de uso en VP: Especificación
Lista de posibles
escenariosdel caso de uso
Se pueden generar diagram
as de secuencia autom
áticamente a partir de
diagramas de casos de uso
Diagram
as de casos de uso en VP