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.
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.
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.
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.
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.
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:
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.
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.