1

CAPTURA DE REQUISITOS COMO CASOS DE USO

SANDRA MILENA SNCHEZ LPEZ
ALEJANDRO VARGAS GARCA
HANNER PADILLA ANDRADE
LEIDY MILENA SOLANO
WENDY GUALGUAN




INSTRUCTOR
ING. JULIO CSAR SIERRA GONZLEZ










CENTRO DE DISEO Y METROLOGA SENA
TECNLOGO ANLISIS Y DESARROLLO DE SISTEMAS DE
INFORMACIN
COLOMBIA, BOGOT D.C
2014
2
TABLA DE CONTENIDO


Pg.


1 ACTORES Y ESCENARIOS ................................................................. 4
1.1 Actores .................................................................................................. 4
1.1.1 Los actores son el entorno del sistema ................................................. 4
1.2 Escenario .............................................................................................. 5
2 CASO DE USO ..................................................................................... 6
2.1 Flujo de sucesos ................................................................................... 6
2.1.1 Contenidos del flujo de sucesos ............................................................ 7
2.1.2 Creacin de un flujo de sucesos ........................................................... 8
2.1.3 Seguimiento de flujos de sucesos ....................................................... 10
2.1.4 Interaccin con los procesos en WBE User Console .......................... 11
2.2 Requisitos especiales .......................................................................... 13
2.2.1 Requisitos de rendimiento ................................................................... 13
2.2.1.1 Requisitos especiales para el caso de uso pagar factura ...... 13
2.2.2 Prototipo de interfaz de usuario .......................................................... 13
3 REFINACIN DE CASOS DE USO. HEURSTICAS. ......................... 15
3.1 Refinacin ........................................................................................... 15
3.2 Refinacin de casos de uso ................................................................ 15
3.3 Heurstica ............................................................................................ 17
4 RELACIN ENTRE CASOS DE USO: INCLUSIN Y EXTENSIN .. 18
4.1 Relacin de Inclusin .......................................................................... 18
4.2 Relacin de extensin ......................................................................... 21
5 OBJETOS INICIALES DE ANLISIS. ................................................. 26
3
6 REQUISITO NO FUNCIONAL ............................................................ 27
CONCLUSIONES .............................................................................. 29































4
1 ACTORES Y ESCENARIOS


1.1 Actores

Los actores representan un tipo de usuario del sistema. Se entiendo como
usuario cualquier cosa externa que interacta con el sistema. No tiene por qu
ser un ser humano, puede ser otro sistema informtico o unidades
organizativas o empresas.

Siempre hay que intentar independizar los actores de la forma en que se
interacta con el sistema. Por ejemplo un teclado no es un actor en la mayor
parte de los casos, slo un medio para introducir informacin al sistema. Suele
ser til mantener una lista de los usuarios reales para cada actor.

Un actor en un diagrama de casos de uso representa un rol que alguien puede
estar jugando, no un individuo particular por lo tanto puede haber personas
particulares que puedan estar usando el sistema de formas diferentes en
diferentes ocasiones: socio de biblioteca y bibliotecario.


1.1.1 Los actores son el entorno del sistema

No lodos los actores representan a personas. Pueden ser actores otros
sistemas o hardware externo que interactuar con el sistema. Cada actor
asume un conjunto coherente de papeles cuando interacta con el sistema. Un
usuario fsico puede actuar como uno o varios actores, desempeando los
papeles de esos actores en su interaccin con el sistema. Varios usuarios
concretos pueden actuar como diferentes ocurrencias del mismo actor. Por
ejemplo, puede haber miles de personas que actan como el actor Cliente de
Banco.

Los actores se comunican con el sistema mediante el envo y recepcin de
mensajes (Apndice A) hacia y desde el sistema segn ste lleva a cubo los
5
casos de Uso. A medida 111W definimos lo que hacen los actores y lo que
hacen los casos de uso trazaremos tina clara separacin entre las
responsabilidades de los actores y las del sistema. Esta separacin nos ayuda
a delimitar el alcance del sistema.

Podemos encontrar especificar todos los actores examinando los usuarios que
utilizarn el sistema y a otros sistemas que deben interactuar con l. Cada
categora de usuarios o sistemas que interactan se representan por tanto
como actores.


1.2 Escenario

Un caso de uso debe especificar un comportamiento deseado, pero no imponer
cmo se llevar a cabo ese comportamiento, es decir, debe decir QU pero no
CMO. Esto se realiza utilizando escenarios.

Un escenario es una interaccin entre el sistema y los actores, que puede ser
descrito mediante una secuencia de mensajes. Un caso de uso es una
generalizacin de un escenario.


Webgrafa

http://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media=pr
incipal:csof5101-requerimientos.pdf
http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf







6
2 CASO DE USO


2.1 Flujo de sucesos

Un flujo de sucesos es una representacin grfica de un conjunto de sucesos
relacionados, bloques de interaccin contenidos en conjuntos de interaccin
que se evaluarn cuando los sucesos se disparen, y acciones que pueden
desencadenarse como resultado de esos bloques de interaccin y son
verdaderas. Los pasos en un flujo de sucesos especifican otros sucesos que se
espera que sigan a las acciones desencadenadas. WebSphere Business
Events Runtime utiliza flujos de sucesos para establecer un mbito para
bloques de interaccin de proceso de sucesos complejos y para producir
estadsticas con el fin de documentar el estado de los contextos que se estn
ejecutando en un flujo de sucesos. En un entorno empresarial, los flujos de
sucesos pueden ser los pasos necesarios para realizar una comprobacin de
crdito para una solicitud de prstamo o los pasos que se llevan a cabo para
cambiar una reserva de avin cuando se cancela un vuelo.

Los flujos de sucesos normalmente estn compuestos tanto por pasos
manuales (humanos) como por pasos automatizados (sistema). Por ejemplo, si
se cancela un vuelo, el sistema de asistencia advertir a un empleado de la
compaa area que se encuentre en el centro de atencin al cliente de dicha
cancelacin, y ste recibir una lista de pasajeros. A continuacin, el empleado
se pondr en contacto con cada pasajero por va telefnica para notificarles la
cancelacin y ofrecerles un vuelo alternativo. De acuerdo con la respuesta de
cada pasajero, el empleado realizar una reserva para otro vuelo o efectuar
un reembolso.

WebSphere Business Events: Design se utiliza para definir y gestionar flujos de
sucesos.


7
2.1.1 Contenidos del flujo de sucesos

Cada flujo de sucesos contiene uno o varios conjuntos de interaccin. Los
conjuntos de interaccin que hacen que se inicie el flujo de sucesos se
denominan conjuntos de interaccin iniciales. (En un flujo de sucesos puede
haber ms de un conjunto de interaccin inicial).

En el siguiente diagrama, el recuadro "Solicitud de cambio de contrasea de
cuenta" muestra el suceso al que hace referencia el filtro complejo; el recuadro
Solicitud de cambio de contrasea de proceso muestra el conjunto de
interaccin; el recuadro Alerta por posible fraude muestra los dos bloques de
interaccin.

Las lneas de puntos rojas indican una relacin compleja entre sucesos. Los
filtros de bloques de interaccin en el conjunto de interaccin Alerta por posible
fraude hacen referencia al suceso Solicitud de cambio de contrasea de
cuenta.

Un flujo de sucesos tambin puede contener pasos empresariales. Un paso de
empresarial indica un suceso que se espera que siga a una accin en un
proceso de negocio. Los pasos empresariales se crean automticamente en un
flujo de sucesos cuando una accin de un conjunto de interaccin del flujo de
sucesos est en el mismo punto de contacto que un suceso en otro conjunto de
interaccin. Los pasos empresariales tambin se pueden crear de forma
manual arrastrando un suceso sobre una accin.


8



Se cre un paso empresarial arrastrando la accin Retirar dinero sobre el
suceso Cambiar contrasea de cuenta. El paso empresarial describe lo que se
espera en este proceso: que se pueda producir una retirada de dinero tras
cambiar la contrasea. Si el suceso y la accin estuvieran en el mismo punto
de contacto, el paso empresarial se habra creado automticamente. El paso
empresarial predeterminado se puede renombrar.

2.1.2 Creacin de un flujo de sucesos

Por qu y cundo se efecta esta tarea?, para crear un flujo de sucesos en
WBE Design, resalte la carpeta donde quiere guardar el flujo de sucesos y
pulse el botn Flujo de sucesos. Una vez creado el flujo de sucesos, puede
realizar las siguientes acciones:

Agregar conjuntos de interaccin arrastrndolos desde el rbol de
activos al espacio de trabajo. Si una accin de un conjunto de interaccin se
encuentra en el punto de contacto como un suceso en otro punto de contacto,
se crea automticamente un paso empresarial.
9

Cree manualmente un paso de negocio arrastrando un suceso de un
conjunto de interaccin en un punto de contacto a una accin de un conjunto
de interaccin en otro punto de contacto distinto (o viceversa)

Para modificar la ubicacin de los objetos, pulse en ellos y arrstrelos
hasta la posicin deseada.

Ejemplo de construccin de un flujo de sucesos en WBE Design:





Despus de pulsar el botn Flujo de sucesos para crear un espacio de trabajo,
se construye el flujo de sucesos arrastrando un conjunto de interaccin (1) al
espacio de trabajo (2). Al arrastrar conjuntos de interaccin adicionales al
10
espacio de trabajo (3), se pueden construir automticamente pasos
empresariales, siempre y cuando un suceso de un conjunto de interaccin
comparta el mismo punto de contacto que una accin en otro conjunto de
interaccin (4). Esto contina hasta que el proceso est definido por completo
(5).


2.1.3 Seguimiento de flujos de sucesos

Los flujos de sucesos (al igual que los contextos ad-hoc) se pueden seguir en
tiempo de ejecucin mediante WBE Administration. Para los flujos de sucesos,
WBE Administration muestra un grfico que muestra las acciones pendientes
de un contexto y enumera cada contexto (la instancia de un flujo de suceso).
Puede detallar ms en cada contexto para ver detalles sobre sucesos y
acciones individuales que estn en el contexto. Tambin se pueden mirar
detalles de filtros y de instancias de objetos intermedios que se utilizan en el
contexto.





Este ejemplo muestra los sucesos y las acciones que se han producido hasta la
fecha en un contexto en concreto.
11
2.1.4 Interaccin con los procesos en WBE User Console

La mayora de procesos de negocio son una mezcla de actividad de sistema e
interaccin humana. Revisar una solicitud de crdito, investigar un fraude
potencial o aprobar un informe de gastos son todos ellos ejemplos en los que
es probable que se requiera un paso humano.

WBE User Console admite la interaccin de personas y sistemas en el entorno
de proceso de sucesos de negocio que gestiona WebSphere Business
Events.WBE User Console slo trata la parte de interaccin humana como otro
conjunto de suceso/accin que interacciona con otros procesos en un flujo de
suceso. Cuando se dirija a ello, WebSphere Business Events Runtime enviar
una accin a WBE User Console, que mostrar los campos de objetos de
accin como datos. Tambin se proporcionan campos de entrada de datos que
se definen como resultado de la accin. Cuando el usuario escribe informacin
en los campos y pulsa la tecla Intro, los datos se envan como un resultado de
vuelta a WebSphere Business Events Runtime, donde se tratan igual que
cualquier otro suceso que entra en el sistema. La figura 9-1 ilustra esto.


12



En WBE Design Data, una accin se define como que utiliza el conector User
Console y tambin se define un resultado de la accin. En el tiempo de
ejecucin, se enva una accin utilizando el conector a WBE User Console. El
nombre de la accin se utiliza para compilar la cabecera en la pantalla de
detalles:

1. el nombre del objeto de accin se utiliza para compilar la subcabecera
2. Los nombres de campo de objeto de accin.
3. forman la primera columna y los valores de campo del objeto de accin
4. forman la segunda columna. El nombre del objeto de resultado se utiliza
para compilar la cabecera para el rea de entrada de datos.
5. cada campo de resultados se enumera en el rea de entrada de datos,
junto con el rea de entrada adecuada para el tipo de datos del campo.
6. Cuando el usuario termina de introducir datos y pulsa Aceptar, se crea
un suceso de resultado y se enva a WebSphere Business Events Runtime,
donde se trata como un suceso.
13

WBE User Console consta de:

Un conector de tecnologa que dirige acciones desde WebSphere
Business Events Runtime a WBE User Console.
Una interfaz de usuario que muestra acciones y permite la entrada de
datos como un resultado que se enva de nuevo a WebSphere Business Events
Runtime para tratarlo como un suceso


2.2 Requisitos especiales

Los requisitos especiales podran generalizarse con los requisitos no
funcionales como la eficacia. Pues son solo especiales para el caso de uso
pagar factura


2.2.1 Requisitos de rendimiento


2.2.1.1 Requisitos especiales para el caso de uso pagar factura

Cuando un comprador enva una factura para su pago, el sistema debera
responder con una verificacin de la solicitud en menos de 1.0 segundos en el
90 por ciento de los casos. La duracin de esta verificacin nunca deber
exceder los 10.0 segundos a menos que la conexin de red no funcione (en
cuyo caso se debe informar al usuario).


2.2.2 Prototipo de interfaz de usuario

Un prototipo de interfaz de usuario es una representacin parcial de la interfaz
de usuario que tendr el software, que muestra la forma en que el usuario
interaccionar con l. Este prototipo es un elemento muy importante para la
14
comunicacin con el usuario en la definicin de los requerimientos, pues al
revisar la interfaz, el usuario puede refinar sus necesidades y comunicarlas al
desarrollador.

Se llama pantalla o interfaz al mecanismo con el cual interacta el usuario con
el sistema. Cuando se diseen estas pantallas podrn ser cdigo html, o
ventanas o entradas de modo texto.

Para disear el prototipo de la interfaz se consideran los casos de uso
planteados en el diagrama general y se puede construir al mismo tiempo que
se detallan los casos de uso. Si el diagrama general tiene los casos de uso X,
Y y Z, en la pantalla principal del sistema debern estar las opciones del men
X, Y y Z. Si en la descripcin del flujo de un caso de uso dice el sistema
presenta la pantalla de X..., en el prototipo deber existir esa pantalla. Si en el
flujo dice el usuario oprime el botn M..., deber haber un botn M en la
pantalla.

En resumen, se debe cuidar que exista coincidencia entre el detalle de los
casos de uso y el prototipo. Deben coincidir:

Las opciones del men y los casos de uso
Los nombres de las pantallas
Los nombres de los botones



15
3 REFINACIN DE CASOS DE USO. HEURSTICAS.


3.1 Refinacin

Qu significa aqu recopilar la mayor parte de los requisitos? Esta cuestin
naci al empezar a planificar la fase de elaboracin, nuestra aspiracin debera
ser identificar alrededor del 81 por ciento de los casos de uso. Aqu podemos
describir detalladamente entre el 40 y el 80 por ciento de todos los casos de
uso. No es necesario identificar todos los casos de uso, y no es necesario
describir en detalle todos los que identificamos, puesto que sabemos que
algunos sistemas pueden ser diseados (arquitectnicamente) en seguida, no
contener riesgos inesperados y pueden ser tasados de forma exacta.

Puede ser necesario considerar slo una fraccin de los escenarios durante el
diseo, implementacin y pruebas, con objeto de obtener la arquitectura y
mitigar los riesgos. El objetivo es recopilar los requisitos hasta el punto de
lograr los objetivos de esta fase.


3.2 Refinacin de casos de uso

Cada caso de uso es una coleccin de escenarios y cada escenario es una
secuencia de pasos. Como puede ver, tales pasos no aparecen en el diagrama.
No se encuentran en notas adjuntas a los casos de uso. Aunque el UML no lo
prohbe, la claridad es clave en la generacin de cualquier diagrama y el
adjuntar notas a cada caso de uso podra volverlo confuso. Cmo y dnde
hara Ia secuencia de pasos? El uso de los diagramas de casos de uso ser,
por lo general, parte de un documento de diseo que el cliente y el equipo de
diseo tomarn como referencia. Cada diagrama tendr su propia pgina, de
igual manera, cada escenario de caso de uso tendr su propia pgina, donde
se listar en modo de texto a:

El actor que inicia al caso de uso
16
Condiciones previas para el caso de uso
Pasos en el escenario
Condiciones posteriores cuando se finaliza el escenario
El actor que se beneficia del caso de uso

Tambin puede enumerar las conjeturas del escenario (por ejemplo, que un
cliente a la vez utilizar la mquina de gaseosas) y una breve descripcin de
una sola frase del escenario.

Las clases pueden heredarse entre s y esto tambin se aplica a los casos de
uso. En la herencia de los casos de uso, el caso de uso secundario hereda las
acciones y significado del primario, y adems agrega sus propias acciones.
Puede aplicar el caso de uso secundado en cualquier lugar donde aplique el
primario. En el ejemplo, deber imaginar un caso de uso Comprar un vaso de
gaseosa que se hereda de Comprar gaseosa. El caso de uso secundario
tiene acciones como agregar hielo y mezclar marcas de gaseosas. Modelara la
generalizacin de casos de uso de Ia misma forma que lo hace con las clases:
con lneas continuas y una punta de flecha en forma de tringulo sin rellenar
que apunta hacia el caso de uso primario, como se muestra en la figura.



La relacin de generalizacin puede establecerse entre actores, as como entre
casos de uso. Quiz tenga personificados al representante del proveedor, al
recolector y al agente del proveedor. Si cambia el nombre del representante
como Reabastecedor, tanto ste como el Recolector sern secundarios del
Agente Proveedor, como muestra la figura.

17



3.3 Heurstica

Una heurstica es un mtodo basado en la experiencia que puede utilizarse
como ayuda para resolver problemas de diseo, desde calcular los recursos
necesarios hasta en planear las condiciones de operacin de los sistemas.
Mediante el uso de heursticas, es posible resolver ms rpidamente problemas
conocidos o similares a otros conocidos. Existen varios mtodos heursticos
disponibles para los ingenieros como, por ejemplo, el Anlisis modal de fallos y
efectos y los rboles de fallo. En el primero se depende de un grupo de
ingenieros experimentados que evalan los problemas y fallos, los ordenan
segn su importancia y recomiendan soluciones.

Dado que las heursticas pueden equivocarse, es fundamental conocer los
casos en los que son aplicables y los lmites a su uso. En general, deben
considerarse como ayudas o apoyos para hacer estimaciones rpidas y
diseos preliminares, pero no como justificaciones finales de un diseo o
proyecto u otros.




18
4 RELACIN ENTRE CASOS DE USO: INCLUSIN Y EXTENSIN


4.1 Relacin de Inclusin

El modelado de casos de uso persigue capturar la funcionalidad del sistema
visto desde el punto de vista de sus operadores (actores) por lo que es
fundamentalmente una construccin de elementos de modelado comprensibles
por los clientes y no solo por los analistas.

Sin embargo, en ocasiones es conveniente introducir algunos pocos elementos
que no sean directamente los conceptos que manejan los clientes. Por ejemplo,
en aras de evitar la redundancia, es posible pensar en extraer algunos
fragmentos que nos permita indicar en uno o ms casos de uso este fragmento
repetido, por referencia en lugar de repetirlo en cada caso.

A este proceso de extraccin del fragmento repetido lo modelamos por medio
de la relacin de inclusin <<include>>, tal como se ve en el siguiente
diagrama:



Relacin de inclusin entre casos de uso


En la figura, el caso de uso A es un fragmento, que define un trozo de un flujo
de eventos que es referido por el caso de uso B. En este tipo de relacin, el
caso incluido (el A) debe ser un fragmento, nunca un caso concreto, en tanto
que el caso que incluye (el B del ejemplo) si ha de ser un caso de uso
completo.

19
A diferencia de la relacin de extensin, aqu ninguno de los casos de uso
involucrados puede ser entendido por completo como piezas aisladas. Por un
lado, el caso incluido es solo un fragmento, por lo que no es posible
considerarlo un caso de uso pleno; en tanto que el caso que incluye al hacer
referencia a un fragmento externo tiene necesariamente que ser entendido en
presencia del fragmento.

Formalmente, como para el glosario:

Relacin de Inclusin <<include>> Un caso de uso concreto incluye a un
fragmento de caso de uso, cuando como parte de su descripcin breve o su
flujo de eventos, se hace referencia al texto del fragmento; de forma tal que lo
dicho en el fragmento pasa a ser parte de la especificacin del caso de uso.

Para lograr que se entienda el concepto, nada mejor que un ejemplo.
Supongamos que estamos hablando de un sistema de gestin de agenda de
unas empresas con gerentes y asistentes. En este sistema hemos identificado
dos casos de uso:

Cdigo: UC-0100.
Nombre: Acepta cita.
Actor: Gerente.
Descripcin: El Gerente visualiza su calendario de citas y aprueba aquellas
citas que desee aceptar.

Cdigo: UC-0200.
Nombre: Coordina cita.
Actor: Asistente.

Descripcin: El asistente busca un momento apropiado para las citas
pendientes al visualizar el calendario de citas del Gerente. Indica para cada cita
propuesta la descripcin, el da y la hora.

Tabla de casos de uso del sistema
20

Como se nota, en ambos casos se requiere de visualizar la agenda. Es posible
imaginar que esta funcin abarca no solo la visualizacin del calendario, sino
tambin ciertas funciones de bsqueda y filtrado por criterios. Para especificar
esta funcionalidad pero evitar hacerlo en cada uno de los flujos de eventos de
los casos de uso ya definidos, se opta por crear un fragmento que contenta
esos detalles e incluirlo en los casos de uso originales. La situacin da lugar al
siguiente diagrama:


Modelo de casos de uso con un ejemplo de relacin de inclusin


De esta forma, evitamos tener que definir en mltiples lugares una misma
funcionalidad. Sin embargo, el fragmento que se incluye ha de ser visto
siempre como lo que es: un fragmento sin significado completo. En verdad es
una lstima que de momento no tengamos una forma de marcar a los
21
fragmentos de manera que se diferencien a simple vista de los casos de uso.
Sugiero que al menos, en tanto surge un estereotipo estndar para esta tarea,
tengamos una serie de numeracin particular para los fragmentos. O bien,
tomar la iniciativa y definir un estereotipo de UML por nosotros mismos.

Naturalmente que a la hora de hacer la especificacin detallada de los casos
de uso, en particular en los flujos de eventos, debemos marcar muy claramente
en qu lugar se ha de realizar la inclusin de lo dicho en el fragmento.
La relacin de inclusin es claramente diferente a la relacin de extensin y
espero que haya quedado claro. La inclusin es una relacin entre un caso de
uso concreto y un fragmento, en tanto que la extensin involucra casos de uso
concretos.

Por otra parte, a diferencia de la relacin de extensin, la inclusin en cierta
forma modifica al caso que incluye, por cuanto el fragmento define una parte de
la funcionalidad del caso de uso completo. Esto significa que el caso de uso
que incluye no puede ser entendido por completo en ausencia del fragmento
que se incluye; algo muy diferente a la situacin en una relacin de extensin.

Webgrafa:

http://synergix.wordpress.com/2008/06/07/casos-de-uso-avanzados-relacion-de-
inclusion/


4.2 Relacin de extensin

En muchas ocasiones el uso de caractersticas avanzadas de los casos de uso
genera dudas en los equipos de desarrollo. La razn bsica es que estos
modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el
uso de las relaciones de inclusin y extensin, entre otras caractersticas.

Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad
y sencillez, existen situaciones en que hacer uso de una relacin avanzada
22
entre casos de uso mejora en lugar de reducir, la claridad del modelo de
requisitos. De ah por tanto que todo analista de requisitos debe comprender
perfectamente el significado de estas relaciones. En el presente post
abordamos la relacin de extensin <<extend>>.

Tcnicamente como para el glosario, la relacin de extensin <<extend>> se
define como:

Relacin <<extend>> Un caso de uso extiende a otro cuando sin alterar a este,
se incorpora su funcionalidad como parte integral del primero. Se denota con
una relacin que apunta del caso extendido al caso base y la conexin se hace
o bien al principio del flujo de eventos principal del caso base o en alguno de
los puntos de extensin que este haya definido.

La notacin grfica es la siguiente:



Relacin de extensin <<extend>>


La relacin del ejemplo significa que un caso de uso ya existente (el caso A)
se aprovecha en la definicin de un segundo caso (el caso B). Dado que la
reutilizacin que requerimos agrega funcionalidad pero no altera al caso base,
se ha optado por la relacin de extensin. Dicha relacin se ha denotado
grficamente con una flecha de dependencia desde el caso extendido (el caso
B) al caso base (el caso A). La dependencia la hemos estereotipado con
<<extend>> para que quede claro lo que pretendemos decir.

A nivel de los flujos de eventos, se podra decir que el flujo principal del caso
base no se ve alterado, pero que en cambio, el flujo de eventos del caso
23
extendido hace referencia al primero, de manera tal que no puede ser
entendido en ausencia de los pasos del caso base.

A fin de contar con un ejemplo completo, consideremos un sistema de compras
electrnico. Digamos que este sistema va a atender tanto a clientes finales
como a clientes corporativos, permitiendo que adquieran productos en nuestra
tienda en lnea. La diferencia ser que los clientes corporativos hacen compras
masivas, quizs programando la entrega a lo largo de un periodo de tiempo de
lo que compraron. Esta visin la podemos expresar en el siguiente diagrama:


Ejemplo de relacin <<extend>> en un sistema de tienda electrnica en Internet


Ahora si vamos al caso de uso base Compra artculo (UC-0100) podramos
tener la funcionalidad de escoger el artculo a comprar y el de pagar con tarjeta
de crdito, por ejemplo. Esta funcionalidad est disponible a los clientes finales,
tal como se ve en el diagrama.
24
Por su parte, los clientes corporativos pueden escoger el artculo a comprar y el
modo de pago: digamos tarjetas de crdito. Adems el caso de uso captura
tambin la funcionalidad de programar la entrega parcial de lo comprado a lo
largo de un periodo de tiempo. Dado que gran parte del caso de uso Compra
masiva (UC-0200) es idntica a la encontrada en el caso del cliente final,
optamos por reutilizar la especificacin por va de la relacin de extensin.

Los criterios a aplicar para saber si la relacin de extensin es aplicable son los
siguientes:

Hay cuando menos un caso base y un caso extendido.

El caso base no se ve modificado por la existencia del caso extendido.

El caso base es un caso concreto atado a cuando menos un actor.

El caso extendido incorpora al caso base por completo.

La relacin de extensin guarda relacin con todos los restantes tipos de
reutilizacin que estn definidas para los casos de uso; en particular la relacin
es muy ntima con la relacin de inclusin <<include>> sin embargo la
diferencia primordial entre <<extend>> e <<include>> es la modificacin del
caso base. Extensin no implica cambio, en tanto que la inclusin aade
funcionalidad al caso base.

Otra relacin, la herencia, es similar tambin a la extensin. En este caso la
diferencia es que la herencia cambia o puede cambiar, la naturaleza de lo dicho
en el caso base. Por ejemplo, podemos decir que aquello que fue llamado
artculo en el caso base es ahora referido ms detalladamente como libro o
juguete. La herencia de casos de uso reutiliza al caso base s, pero nos
permite alterar la semntica de los detalles; algo que la relacin de extensin
(ni la de inclusin) pueden hacer.

25
Por tanto concluyamos: la relacin de extensin permite reutilizar una
especificacin pero sin modificar al caso base.

Webgrafa:

http://synergix.wordpress.com/2008/06/05/casos-de-uso-avanzados-relacion-
extend/



























26
5 OBJETOS INICIALES DE ANLISIS.


Analizar los requisitos en la forma de un modelo de anlisis es importante por
varios motivos, como ya hemos explicado:

Un modelo de anlisis ofrece una especificacin ms precisa de los requisitos
que la que tenemos como resultado de la captura de requisitos, incluyendo al
modelo de casos de uso.

Un modelo de anlisis se describe utilizando el lenguaje de los
desarrolladores, y puede por tanto introducir un mayor formalismo y ser
utilizado para razonar sobre los funcionamientos internos del sistema.

Un modelo de anlisis estructura los requisitos de un modo que facilita su
comprensin, su preparacin, su modificacin, y en general, su mantenimiento.

Un modelo de anlisis puede considerarse como una primera aproximacin al
modelo de diseo (aunque es un modelo por s mismo), y es por tanto una
entrada fundamental cuando se da forma al sistema en el diseo y en la
implementacin. Esto se debe a que debera ser mantenible el sistema en su
conjunto, y no slo la descripcin de sus requisitos.


Webgrafa:

http://www.cannes.itam.mx/Alfredo/Espaniol/Publicaciones/MINT/Requisitos.pdf







27
6 REQUISITO NO FUNCIONAL

Un requisito no funcional o atributo de calidad es, en la ingeniera de sistemas y
la ingeniera de software, un requisito que especfica criterios que pueden
usarse para juzgar la operacin de un sistema en lugar de sus
comportamientos especficos, ya que stos corresponden a los requisitos
funcionales. Por tanto, se refieren a todos los requisitos que ni describen
informacin a guardar, ni funciones a realizar.

Algunos ejemplos de requisitos no funcionales tpicos son los siguientes:

Rendimiento.
Disponibilidad.
Seguridad.
Accesibilidad.
Usabilidad.
Estabilidad.
Portabilidad.
Costo.
Operatividad.
Interoperabilidad.
Escalabilidad.
Concurrencia.
Mantenibilidad.
Interfaz.

Los requerimientos no funcionales hacen relacin a las caractersticas del
sistema que aplican de manera general como un todo, ms que a rasgos
particulares del mismo. Estos requerimientos son adicionales a los
requerimientos funcionales que debe cumplir el sistema, y corresponden a
aspectos tales como:

Flexibilidad.
28
Desempeo.
Facilidad de uso e ingreso de informacin.}
Facilidad para las pruebas.
Administracin.
Validacin de informacin.
Arquitectura.
Backups.
Integracin.
Interoperabilidad.
Polticas y gestin de la informacin para la administracin.


Webgrafa:

http://es.wikipedia.org/wiki/Requisito_no_funcional
http://www.procuraduria.gov.co/infosim/media/file/VERSIONES_EN_PDF/Etapa
4-ReqNoFunc.pdf
















29
CONCLUSIONES

En la relacin entre casos de usos, encontramos la relacin de inclusin, la
cual nos indica que un caso de uso llama al fragmento de otro caso para
completar una funcin ya que ambos tienen un mismo objetivo; pero este
llamado genera cambios en el caso de uso base.
Tambin existe la relacin de extensin, en ella se ve el llamado que hace un
caso de uso a otro, sin alterar al caso base, en pocas palabras es una funcin
adicional y opcional, que no es necesario que todas las veces se cumpla.

En la relacin entre casos de usos, encontramos la relacin de inclusin, la
cual nos indica que un caso de uso llama al fragmento de otro caso para
completar una funcin ya que ambos tienen un mismo objetivo; pero este
llamado genera cambios en el caso de uso base.

Tambin existe la relacin de extensin, en ella se ve el llamado que hace un
caso de uso a otro, sin alterar al caso base, en pocas palabras es una funcin
adicional y opcional, que no es necesario que todas las veces se cumpla.

Un modelo de anlisis puede considerarse como una primera aproximacin al
modelo de diseo (aunque es un modelo por s mismo), y es por tanto una
entrada fundamental cuando se da forma al sistema en el diseo y en la
implementacin. Esto se debe a que debera ser mantenible el sistema en su
conjunto, y no slo la descripcin de sus requisitos.