actividad 3. captura de requisitos como casos de uso
TRANSCRIPT
CAPTURA DE REQUISITOS COMO CASOS DE USO
SANDRA MILENA SÁNCHEZ LÓPEZ
ALEJANDRO VARGAS GARCÍA
HANNER PADILLA ANDRADE
LEIDY MILENA SOLANO
WENDY GUALGUAN
INSTRUCTOR
ING. JULIO CÉSAR SIERRA GONZÁLEZ
CENTRO DE DISEÑO Y METROLOGÍA SENA
TECNÓLOGO ANÁLISIS Y DESARROLLO DE SISTEMAS DE
INFORMACIÓN
COLOMBIA, BOGOTÁ D.C
2014
1
TABLA DE CONTENIDO
Pág.
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 Creación de un flujo de sucesos............................................................8
2.1.3 Seguimiento de flujos de sucesos........................................................10
2.1.4 Interacción 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 REFINACIÓN DE CASOS DE USO. HEURÍSTICAS...........................16
3.1 Refinación............................................................................................16
3.2 Refinación de casos de uso.................................................................16
3.3 Heurística.............................................................................................18
4 RELACIÓN ENTRE CASOS DE USO: INCLUSIÓN Y EXTENSIÓN...19
4.1 Relación de Inclusión...........................................................................19
4.2 Relación de extensión..........................................................................22
5 OBJETOS INICIALES DE ANÁLISIS...................................................27
2
6 REQUISITO NO FUNCIONAL.............................................................28
CONCLUSIONES...............................................................................30
3
1 ACTORES Y ESCENARIOS
1.1 Actores
Los actores representan un tipo de usuario del sistema. Se entiendo como
usuario cualquier cosa externa que interactúa con el sistema. No tiene por qué
ser un ser humano, puede ser otro sistema informático o unidades
organizativas o empresas.
Siempre hay que intentar independizar los actores de la forma en que se
interactúa con el sistema. Por ejemplo un teclado no es un actor en la mayor
parte de los casos, sólo un medio para introducir información 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 interactúa con el sistema. Un
usuario físico puede actuar como uno o varios actores, desempeñando los
papeles de esos actores en su interacción con el sistema. Varios usuarios
concretos pueden actuar como diferentes ocurrencias del mismo actor. Por
ejemplo, puede haber miles de personas que actúan como el actor Cliente de
Banco.
Los actores se comunican con el sistema mediante el envío y recepción de
mensajes (Apéndice A) hacia y desde el sistema según éste lleva a cubo los
4
casos de Uso. A medida 111W definimos lo que hacen los actores y lo que
hacen los casos de uso trazaremos tina clara separación entre las
responsabilidades de los actores y las del sistema. Esta separación nos ayuda
a delimitar el alcance del sistema.
Podemos encontrar especificar todos los actores examinando los usuarios que
utilizarán el sistema y a otros sistemas que deben interactuar con él. Cada
categoría de usuarios o sistemas que interactúan se representan por tanto
como actores.
1.2 Escenario
Un caso de uso debe especificar un comportamiento deseado, pero no imponer
cómo se llevará a cabo ese comportamiento, es decir, debe decir QUÉ pero no
CÓMO. Esto se realiza utilizando escenarios.
Un escenario es una interacción entre el sistema y los actores, que puede ser
descrito mediante una secuencia de mensajes. Un caso de uso es una
generalización de un escenario.
Webgrafía
http://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?
media=principal:csof5101-requerimientos.pdf
http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf
5
2 CASO DE USO
2.1 Flujo de sucesos
Un flujo de sucesos es una representación gráfica de un conjunto de sucesos
relacionados, bloques de interacción contenidos en conjuntos de interacción
que se evaluarán cuando los sucesos se disparen, y acciones que pueden
desencadenarse como resultado de esos bloques de interacción 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 interacción de proceso de sucesos complejos y para producir
estadísticas con el fin de documentar el estado de los contextos que se están
ejecutando en un flujo de sucesos. En un entorno empresarial, los flujos de
sucesos pueden ser los pasos necesarios para realizar una comprobación de
crédito para una solicitud de préstamo o los pasos que se llevan a cabo para
cambiar una reserva de avión cuando se cancela un vuelo.
Los flujos de sucesos normalmente están 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
compañía aérea que se encuentre en el centro de atención al cliente de dicha
cancelación, y éste recibirá una lista de pasajeros. A continuación, el empleado
se pondrá en contacto con cada pasajero por vía telefónica para notificarles la
cancelación 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.
6
2.1.1 Contenidos del flujo de sucesos
Cada flujo de sucesos contiene uno o varios conjuntos de interacción. Los
conjuntos de interacción que hacen que se inicie el flujo de sucesos se
denominan conjuntos de interacción iniciales. (En un flujo de sucesos puede
haber más de un conjunto de interacción inicial).
En el siguiente diagrama, el recuadro "Solicitud de cambio de contraseña de
cuenta" muestra el suceso al que hace referencia el filtro complejo; el recuadro
Solicitud de cambio de contraseña de proceso muestra el conjunto de
interacción; el recuadro Alerta por posible fraude muestra los dos bloques de
interacción.
Las líneas de puntos rojas indican una relación compleja entre sucesos. Los
filtros de bloques de interacción en el conjunto de interacción Alerta por posible
fraude hacen referencia al suceso Solicitud de cambio de contraseña de
cuenta.
Un flujo de sucesos también puede contener pasos empresariales. Un paso de
empresarial indica un suceso que se espera que siga a una acción en un
proceso de negocio. Los pasos empresariales se crean automáticamente en un
flujo de sucesos cuando una acción de un conjunto de interacción del flujo de
sucesos está en el mismo punto de contacto que un suceso en otro conjunto de
interacción. Los pasos empresariales también se pueden crear de forma
manual arrastrando un suceso sobre una acción.
7
Se creó un paso empresarial arrastrando la acción Retirar dinero sobre el
suceso Cambiar contraseña de cuenta. El paso empresarial describe lo que se
espera en este proceso: que se pueda producir una retirada de dinero tras
cambiar la contraseña. Si el suceso y la acción estuvieran en el mismo punto
de contacto, el paso empresarial se habría creado automáticamente. El paso
empresarial predeterminado se puede renombrar.
2.1.2 Creación de un flujo de sucesos
¿Por qué y cuándo se efectúa esta tarea?, para crear un flujo de sucesos en
WBE Design, resalte la carpeta donde quiere guardar el flujo de sucesos y
pulse el botón Flujo de sucesos. Una vez creado el flujo de sucesos, puede
realizar las siguientes acciones:
• Agregar conjuntos de interacción arrastrándolos desde el Árbol de
activos al espacio de trabajo. Si una acción de un conjunto de interacción se
encuentra en el punto de contacto como un suceso en otro punto de contacto,
se crea automáticamente un paso empresarial.
8
• Cree manualmente un paso de negocio arrastrando un suceso de un
conjunto de interacción en un punto de contacto a una acción de un conjunto
de interacción en otro punto de contacto distinto (o viceversa)
• Para modificar la ubicación de los objetos, pulse en ellos y arrástrelos
hasta la posición deseada.
Ejemplo de construcción de un flujo de sucesos en WBE Design:
Después de pulsar el botón Flujo de sucesos para crear un espacio de trabajo,
se construye el flujo de sucesos arrastrando un conjunto de interacción (1) al
espacio de trabajo (2). Al arrastrar conjuntos de interacción adicionales al
9
espacio de trabajo (3), se pueden construir automáticamente pasos
empresariales, siempre y cuando un suceso de un conjunto de interacción
comparta el mismo punto de contacto que una acción en otro conjunto de
interacción (4). Esto continúa 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 ejecución mediante WBE Administration. Para los flujos de sucesos,
WBE Administration muestra un gráfico que muestra las acciones pendientes
de un contexto y enumera cada contexto (la instancia de un flujo de suceso).
Puede detallar más en cada contexto para ver detalles sobre sucesos y
acciones individuales que están en el contexto. También 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.
10
2.1.4 Interacción con los procesos en WBE User Console
La mayoría de procesos de negocio son una mezcla de actividad de sistema e
interacción humana. Revisar una solicitud de crédito, 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 interacción de personas y sistemas en el entorno
de proceso de sucesos de negocio que gestiona WebSphere Business
Events.WBE User Console sólo trata la parte de interacción humana como otro
conjunto de suceso/acción que interacciona con otros procesos en un flujo de
suceso. Cuando se dirija a ello, WebSphere Business Events Runtime enviará
una acción a WBE User Console, que mostrará los campos de objetos de
acción como datos. También se proporcionan campos de entrada de datos que
se definen como resultado de la acción. Cuando el usuario escribe información
en los campos y pulsa la tecla Intro, los datos se envían 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.
11
En WBE Design Data, una acción se define como que utiliza el conector User
Console y también se define un resultado de la acción. En el tiempo de
ejecución, se envía una acción utilizando el conector a WBE User Console. El
nombre de la acción se utiliza para compilar la cabecera en la pantalla de
detalles:
1. el nombre del objeto de acción se utiliza para compilar la subcabecera
2. Los nombres de campo de objeto de acción.
3. forman la primera columna y los valores de campo del objeto de acción
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 envía a WebSphere Business Events Runtime,
donde se trata como un suceso.
12
WBE User Console consta de:
• Un conector de tecnología 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 envía de nuevo a WebSphere Business Events
Runtime para tratarlo como un suceso
2.2 Requisitos especiales
Los requisitos especiales podrían 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 envía una factura para su pago, el sistema debería
responder con una verificación de la solicitud en menos de 1.0 segundos en el
90 por ciento de los casos. La duración de esta verificación nunca deberá
exceder los 10.0 segundos a menos que la conexión 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 representación 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
13
comunicación con el usuario en la definición 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 interactúa el usuario con
el sistema. Cuando se diseñen estas pantallas podrán ser código html, o
ventanas o entradas de modo texto.
Para diseñar 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 deberán estar las opciones del menú
X, Y y Z. Si en la descripción 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 botón M...”, deberá haber un botón 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
14
3 REFINACIÓN DE CASOS DE USO. HEURÍSTICAS.
3.1 Refinación
¿Qué significa aquí recopilar la mayor parte de los requisitos”? Esta cuestión
nació al empezar a planificar la fase de elaboración, nuestra aspiración debería
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 diseñados (arquitectónicamente) en seguida, no
contener riesgos inesperados y pueden ser tasados de forma exacta.
Puede ser necesario considerar sólo una fracción de los escenarios durante el
diseño, implementación 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 Refinación de casos de uso
Cada caso de uso es una colección 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
prohíbe, la claridad es clave en la generación de cualquier diagrama y el
adjuntar notas a cada caso de uso podría volverlo confuso. ¿Cómo y dónde
haría Ia secuencia de pasos? El uso de los diagramas de casos de uso será,
por lo general, parte de un documento de diseño que el cliente y el equipo de
diseño tomarán como referencia. Cada diagrama tendrá su propia página, de
igual manera, cada escenario de caso de uso tendrá su propia página, donde
se listará en modo de texto a:
El actor que inicia al caso de uso
15
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
También puede enumerar las conjeturas del escenario (por ejemplo, que un
cliente a la vez utilizará la máquina de gaseosas) y una breve descripción de
una sola frase del escenario.
Las clases pueden heredarse entre sí y esto también 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 además 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
generalización de casos de uso de Ia misma forma que lo hace con las clases:
con líneas continuas y una punta de flecha en forma de triángulo sin rellenar
que apunta hacia el caso de uso primario, como se muestra en la figura.
La relación de generalización 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 serán secundarios del
Agente Proveedor, como muestra la figura.
16
3.3 Heurística
Una heurística es un método basado en la experiencia que puede utilizarse
como ayuda para resolver problemas de diseño, desde calcular los recursos
necesarios hasta en planear las condiciones de operación de los sistemas.
Mediante el uso de heurísticas, es posible resolver más rápidamente problemas
conocidos o similares a otros conocidos. Existen varios métodos heurísticos
disponibles para los ingenieros como, por ejemplo, el Análisis modal de fallos y
efectos y los árboles de fallo. En el primero se depende de un grupo de
ingenieros experimentados que evalúan los problemas y fallos, los ordenan
según su importancia y recomiendan soluciones.
Dado que las heurísticas pueden equivocarse, es fundamental conocer los
casos en los que son aplicables y los límites a su uso. En general, deben
considerarse como ayudas o apoyos para hacer estimaciones rápidas y
diseños preliminares, pero no como justificaciones finales de un diseño o
proyecto u otros.
17
4 RELACIÓN ENTRE CASOS DE USO: INCLUSIÓN Y EXTENSIÓN
4.1 Relación de Inclusión
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 construcción 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 más casos de uso este fragmento
repetido, por referencia en lugar de repetirlo en cada caso.
A este proceso de extracción del fragmento repetido lo modelamos por medio
de la relación de inclusión <<include>>, tal como se ve en el siguiente
diagrama:
Relación de inclusión 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 relación, 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.
18
A diferencia de la relación de extensión, 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:
Relación de Inclusión <<include>> Un caso de uso concreto incluye a un
fragmento de caso de uso, cuando como parte de su descripción 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 especificación del caso de uso.
Para lograr que se entienda el concepto, nada mejor que un ejemplo.
Supongamos que estamos hablando de un sistema de gestión de agenda de
unas empresas con gerentes y asistentes. En este sistema hemos identificado
dos casos de uso:
Código: UC-0100.
Nombre: Acepta cita.
Actor: Gerente.
Descripción: El Gerente visualiza su calendario de citas y aprueba aquellas
citas que desee aceptar.
Código: UC-0200.
Nombre: Coordina cita.
Actor: Asistente.
Descripción: El asistente busca un momento apropiado para las citas
pendientes al visualizar el calendario de citas del Gerente. Indica para cada cita
propuesta la descripción, el día y la hora.
Tabla de casos de uso del sistema
19
Como se nota, en ambos casos se requiere de visualizar la agenda. Es posible
imaginar que esta función abarca no solo la visualización del calendario, sino
también ciertas funciones de búsqueda 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 situación da lugar al
siguiente diagrama:
Modelo de casos de uso con un ejemplo de relación de inclusión
De esta forma, evitamos tener que definir en múltiples 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 lástima que de momento no tengamos una forma de marcar a los
20
fragmentos de manera que se diferencien a simple vista de los casos de uso.
Sugiero que al menos, en tanto surge un estereotipo estándar para esta tarea,
tengamos una serie de numeración 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 especificación 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 inclusión de lo dicho en el fragmento.
La relación de inclusión es claramente diferente a la relación de extensión y
espero que haya quedado claro. La inclusión es una relación entre un caso de
uso concreto y un fragmento, en tanto que la extensión involucra casos de uso
concretos.
Por otra parte, a diferencia de la relación de extensión, la inclusión 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 situación en una relación de extensión.
Webgrafía:
http://synergix.wordpress.com/2008/06/07/casos-de-uso-avanzados-relacion-de-
inclusion/
4.2 Relación de extensión
En muchas ocasiones el uso de características avanzadas de los casos de uso
genera dudas en los equipos de desarrollo. La razón básica es que estos
modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el
uso de las relaciones de inclusión y extensión, entre otras características.
Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad
y sencillez, existen situaciones en que hacer uso de una relación avanzada
21
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 relación de extensión <<extend>>.
Técnicamente como para el glosario, la relación de extensión <<extend>> se
define como:
Relación <<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 relación que apunta del caso extendido al caso base y la conexión se hace
o bien al principio del flujo de eventos principal del caso base o en alguno de
los puntos de extensión que este haya definido.
La notación gráfica es la siguiente:
Relación de extensión <<extend>>
La relación del ejemplo significa que un caso de uso ya existente (el caso “A”)
se aprovecha en la definición de un segundo caso (el caso “B”). Dado que la
reutilización que requerimos agrega funcionalidad pero no altera al caso base,
se ha optado por la relación de extensión. Dicha relación se ha denotado
gráficamente 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 podría decir que el flujo principal del caso
base no se ve alterado, pero que en cambio, el flujo de eventos del caso
22
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
electrónico. Digamos que este sistema va a atender tanto a clientes finales
como a clientes corporativos, permitiendo que adquieran productos en nuestra
tienda en línea. La diferencia será que los clientes corporativos hacen compras
masivas, quizás programando la entrega a lo largo de un periodo de tiempo de
lo que compraron. Esta visión la podemos expresar en el siguiente diagrama:
Ejemplo de relación <<extend>> en un sistema de tienda electrónica en Internet
Ahora si vamos al caso de uso base “Compra artículo (UC-0100)” podríamos
tener la funcionalidad de escoger el artículo a comprar y el de pagar con tarjeta
de crédito, por ejemplo. Esta funcionalidad está disponible a los clientes finales,
tal como se ve en el diagrama.
23
Por su parte, los clientes corporativos pueden escoger el artículo a comprar y el
modo de pago: digamos tarjetas de crédito. Además el caso de uso captura
también 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 idéntica a la encontrada en el caso del cliente final,
optamos por reutilizar la especificación por vía de la relación de extensión.
Los criterios a aplicar para saber si la relación de extensión 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 relación de extensión guarda relación con todos los restantes tipos de
reutilización que están definidas para los casos de uso; en particular la relación
es muy íntima con la relación de inclusión <<include>> sin embargo la
diferencia primordial entre <<extend>> e <<include>> es la modificación del
caso base. Extensión no implica cambio, en tanto que la inclusión añade
funcionalidad al caso base.
Otra relación, la herencia, es similar también a la extensión. 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
“artículo” en el caso base es ahora referido más detalladamente como “libro” o
“juguete”. La herencia de casos de uso reutiliza al caso base sí, pero nos
permite alterar la semántica de los detalles; algo que la relación de extensión
(ni la de inclusión) pueden hacer.
24
Por tanto concluyamos: la relación de extensión permite reutilizar una
especificación pero sin modificar al caso base.
Webgrafía:
http://synergix.wordpress.com/2008/06/05/casos-de-uso-avanzados-relacion-
extend/
25
5 OBJETOS INICIALES DE ANÁLISIS.
Analizar los requisitos en la forma de un modelo de análisis es importante por
varios motivos, como ya hemos explicado:
• Un modelo de análisis ofrece una especificación más 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 análisis 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 análisis estructura los requisitos de un modo que facilita su
comprensión, su preparación, su modificación, y en general, su mantenimiento.
Un modelo de análisis puede considerarse como una primera aproximación al
modelo de diseño (aunque es un modelo por sí mismo), y es por tanto una
entrada fundamental cuando se da forma al sistema en el diseño y en la
implementación. Esto se debe a que debería ser mantenible el sistema en su
conjunto, y no sólo la descripción de sus requisitos.
Webgrafía:
http://www.cannes.itam.mx/Alfredo/Espaniol/Publicaciones/MINT/Requisitos.pdf
26
6 REQUISITO NO FUNCIONAL
Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y
la ingeniería de software, un requisito que específica criterios que pueden
usarse para juzgar la operación de un sistema en lugar de sus
comportamientos específicos, ya que éstos corresponden a los requisitos
funcionales. Por tanto, se refieren a todos los requisitos que ni describen
información a guardar, ni funciones a realizar.
Algunos ejemplos de requisitos no funcionales típicos son los siguientes:
Rendimiento.
Disponibilidad.
Seguridad.
Accesibilidad.
Usabilidad.
Estabilidad.
Portabilidad.
Costo.
Operatividad.
Interoperabilidad.
Escalabilidad.
Concurrencia.
Mantenibilidad.
Interfaz.
Los requerimientos no funcionales hacen relación a las características del
sistema que aplican de manera general como un todo, más 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.
Desempeño.
27
Facilidad de uso e ingreso de información.}
Facilidad para las pruebas.
Administración.
Validación de información.
Arquitectura.
Backups.
Integración.
Interoperabilidad.
Políticas y gestión de la información para la administración.
Webgrafía:
http://es.wikipedia.org/wiki/Requisito_no_funcional
http://www.procuraduria.gov.co/infosim/media/file/VERSIONES_EN_PDF/
Etapa4-ReqNoFunc.pdf
CONCLUSIONES
28
En la relación entre casos de usos, encontramos la relación de inclusión, la
cual nos indica que un caso de uso llama al fragmento de otro caso para
completar una función ya que ambos tienen un mismo objetivo; pero este
llamado genera cambios en el caso de uso base.
También existe la relación de extensión, en ella se ve el llamado que hace un
caso de uso a otro, sin alterar al caso base, en pocas palabras es una función
adicional y opcional, que no es necesario que todas las veces se cumpla.
En la relación entre casos de usos, encontramos la relación de inclusión, la
cual nos indica que un caso de uso llama al fragmento de otro caso para
completar una función ya que ambos tienen un mismo objetivo; pero este
llamado genera cambios en el caso de uso base.
También existe la relación de extensión, en ella se ve el llamado que hace un
caso de uso a otro, sin alterar al caso base, en pocas palabras es una función
adicional y opcional, que no es necesario que todas las veces se cumpla.
Un modelo de análisis puede considerarse como una primera aproximación al
modelo de diseño (aunque es un modelo por sí mismo), y es por tanto una
entrada fundamental cuando se da forma al sistema en el diseño y en la
implementación. Esto se debe a que debería ser mantenible el sistema en su
conjunto, y no sólo la descripción de sus requisitos.
29