GuÃ-a 2 - kamila UML.docx

Distrito Capital

CENTRO DE GESTION DE MERCADOS, LOGISTICA Y TECNOLOGIAS DE LA INFORMACION

GUÍA DE APRENDIZAJE PARA EL PROGRAMA DE FORMACIÓN ANÁLISIS Y DESARROLLO DE SISTEMAS DE

INFORMACIÓN

GUIA 2. MODELAMIENTO: CASOS DE USO

Versión: 119 de abril de

2023Página 1 de 14

1. IDENTIFICACIÓN CURRICULARNOMBRE: JENNIFER CAMILA GUZMAN CASTRO FICHA: 896800

PROGRAMA DE FORMACIÓN:

Análisis y desarrollo de Sistemas de Información.

COMPETENCIA:

Analizar los requerimientos del cliente para construir un sistema de información y modelarlos empleando el lenguaje unificado de modelado - UML.

3. DESARROLLO

Introducción a UML - introducción a los Casos de Uso

El modelado de un sistema desde el punto de vista de un usuario es el trabajo de los casos de uso, es decir, un caso de uso es una interacción entre un usuario y un sistema. Todos cuando realizamos una compra que no sea impulsiva seguimos un análisis de caso de uso: nos preguntamos cómo utilizaremos el producto o sistema que queremos comprar, de modo que podamos obtener algo que cumpla con nuestras necesidades. Lo importante es saber cuáles son esos requerimientos.

Este tipo de análisis es particularmente crucial para la fase de análisis del desarrollo de un sistema. La forma en que los usuarios utilicen un sistema le da la pauta para lo que diseñará y creará.

El caso de uso es una estructura que ayuda a los analistas a trabajar con los usuarios para determinar la forma en que se usará un sistema. Con una colección de casos de uso se puede hacer un bosquejo de un sistema en términos de lo que los usuarios intenten hacer con él.

En su forma más simple, el caso de uso se obtiene hablando con los usuarios habituales y analizando con ellos las distintas cosas que deseen hacer con sus sistemas. Se debe abordar cada

2. RESULTADOS DE APRENDIZAJE

Representa el modelo de la solución al problema presentado por el cliente, mediante la elaboración de diagramas de casos de uso, apoyado en el análisis del informe de requerimientos, al confrontar la situación problemática con el usuario según normas y protocolos de la organización.

Distrito Capital



INFORMACIÓN



2023Página 2 de 14

cosa discreta que quieran, darle un nombre y escribir un texto descriptivo breve (no más de unos párrafos).

Durante la elaboración, esto es todo lo que necesitará para empezar. No trate de tener todos los detalles justo desde el principio; los podrá obtener cuando los necesite. Sin embargo, si considera que un caso de uso tiene ramificaciones arquitectónicas de importancia, necesitará más detalles a la mano. La mayoría de casos de uso se pueden detallar durante la iteración dada, a medida que se construye.La idea de involucrar a los usuarios en las etapas iniciales del análisis y diseño del sistema. Es aumentar la probabilidad que el sistema sea de mayor provecho para los usuarios a los que ayudará, en lugar de ser una cantidad de expresiones de computador incomprensibles e inmanejables por los usuarios finales.

Diagramas de caso de uso

Jacobson (1994), además de introducir los casos de uso como elementos primarios de desarrollo de software, también diseñó un diagrama para su representación gráfica.

Actores

Empleamos el término actor, para llamar al usuario, cuando desempeña ese papel con respecto al sistema. Los actores llevan a cabo casos de uso. Un mismo actor puede realizar muchos casos de uso; a la inversa, un caso de uso puede ser realizado por varios actores. Un actor no es necesario que sea un ser humano, a pesar de que este representado por figuras humanas en el diagrama de caso de uso. El actor puede ser también un sistema que necesite cierta información del sistema actual.

Uses y extends

Distrito Capital



INFORMACIÓN



2023Página 3 de 14

Además de los vínculos entre los actores y los casos de uso, hay otros tipos de vínculos. Estos representan las relaciones de uses (usa) y extends (extiende) entre los casos de uso.

Se usa la relación extends cuando se tiene un caso de uso que es similar a otro, pero que hace un poco más. Las relaciones uses ocurre cuando se tiene una porción de comportamiento que es similar en más de un caso de uso y no se quiere copiar la descripción de tal conducta.

Es posible volver a utilizar casos de uso. Una forma (inclusión) es utilizar los pasos de un caso de uso como parte de una secuencia de pasos de otro caso de uso. Otra forma (extensión) es crear un nuevo caso de uso mediante la adición de pasos a un caso de uso existente.

Aplique la siguiente regla:

Utilice extends cuando describa una variación de conducta normal Emplee uses para repetir cuando se trate de uno a varios casos de uso y desee evitar

repeticiones.

Distrito Capital



INFORMACIÓN



2023Página 4 de 14

4. OBJETIVOS

Comprender el contexto y el por qué de los beneficios del uso de un lenguaje de modelado como UML en el desarrollo del software.

Apropiarse de los conceptos y propósito del lenguaje UML.

5. ESTRATEGIAS DE ENSEÑANZA

ACTIVIDAD DE APRENDIZAJE

Desarrollar Guía de Aprendizaje mediante la investigación en internet y diferentes fuentes del conocimiento como: TIC, trabajo colaborativo, orientador, Entorno.

Socializar en la próxima clase la investigación realizada.

ACTIVIDAD PROPUESTA:

Investigue los siguientes interrogantes en internet o en libros relacionados

1. ¿Qué es levantamiento de información?, ¿Qué técnicas se usan?

RTA/ Es un conjunto de elementos organizados que se encuentran en interacción, que busca alguna meta en común, operando para ello sobre datos o información para producir como salida de información.

TECNICAS: 1.Tecnica del Grupo Nominal (TGN):

Ayudar a identificar problemas y separarlos de los síntomas. Ayudar a resolver o aclarar problemas estructurales u organizacionales que incidan en la

comprensión del sistema total. Evaluar las propuestas del grupo de sistemas, antes de proceder a su estudio detallado.

VENTAJAS: Se obtiene un consenso sin la posibilidad de que alguien domine la reunión ni imponga sus

ideas. Se logra la participación de todos los presentes. Se disminuye otras influencias a través de la jerarquización lo cual equivale a una votación sin

los inconvenientes de la levantada de mano, etc.

Distrito Capital



INFORMACIÓN



2023Página 5 de 14

2. ¿Qué es un requerimiento de sistema?

RTA/ Los requerimientos/requisitos de un sistema describen los servicios que ha de ofrecer el sistema y las restricciones asociadas a su funcionamiento.

3. ¿Qué es un requerimiento funcional y un requerimiento no funcional?

RTA/ REQUERIMIENTOS FUNCIONALES: Expresan la naturaleza del funcionamiento del sistema (cómo interacciona el sistema con su entorno y cuáles van a ser su estado y funcionamiento).

Los requisitos funcionales definen qué debe hacer un sistema. A veces, también es conveniente indicar lo que no hará el sistema. Los requisitos funcionales definen qué debe hacer un sistema.

REQUERIMIENTOS NO FUNCIONALES: Rendimiento del sistema: Fiabilidad, tiempo de respuesta, disponibilidad. Interfaces: Dispositivos de E/S, usabilidad, interoperabilidad. Proceso de desarrollo: Estándares, herramientas, plazo de entrega. Los requisitos no funcionales definen cómo debe ser el sistema.

4. ¿Cómo se documenta un caso de uso? Adjuntar un formato de documentación diligenciado y explicar cada campo a qué se refiere.

RTA/

Distrito Capital



INFORMACIÓN



2023Página 6 de 14

Distrito Capital



INFORMACIÓN



2023Página 7 de 14

Distrito Capital



INFORMACIÓN



2023Página 8 de 14

(*): Nombre del caso de uso: Formato convenio empresariales.(1,2,3,4,5,6,7,8,9,10): Resumen: permite al usuario hacer un pago al convenio.(6): actor primario.(1): actor primario.(Banco Davivienda): actor secundario.(Formato convenio empresarial de banco Davivienda): sistema bajo estudio.(4): objetivo del actor: pagar valor total al convenio.(6, 7, 8,9): entradas.(Precondición): el formato de pago al convenio está operando y el usuario dispone de su efectivo.(Postcondicion): el usuario ha cancelado el valor total al convenio y el banco del usuario ha notificado al convenio de su pago.(Secuencia normal): secuencia de interacciones entre los actores y el sistema que lleva a la finalización con éxito del caso de uso.(Excepciones): -el número de identificación del usuario es incorrecto ‘vuelva a llenar de nuevo el formato’-el código de convenio no coincide.-seleccione la forma de pago.(Resultados): el usuario ha cancelado su valor total de pago al convenio y fue registrado en el sistema.

5. ¿Cómo se llama a la entidad que inicia un caso de uso? Enuncie sus principales características

RTA/ La entidad que inicia el caso de uso se llama Actor(es), el actor es un rol que un usuario juega con respecto al sistema.

Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma telefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, son considerados un único actor: Empleado de Ventas. Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos. Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores. Otro sistema que interactúa con el que estamos construyendo también es un actor. Por ejemplo, si nuestro sistema deberá generar asientos contables para ser procesados por el sistema de contabilidad, este último sistema será un actor, que

Distrito Capital



INFORMACIÓN



2023Página 9 de 14

usa los servicios de nuestro sistema. También puede ocurrir que el actor sea una máquina, en el caso en que el software controle sus movimientos, o sea operado por una máquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un robot, el hardware del robot será un actor, asumiendo que dentro de nuestro sistema están las rutinas de bajo nivel que controlan al hardware. Los actores se representan con dibujos simplificados de personas, llamados en inglés “stick man” (hombres de palo)

Incluir un caso de uso: Es una forma de inclusión es utilizar los pasos de un caso de uso como parte de las secuencias de pasos de otro caso de uso, incluir un caso de uso es cuando relacionamos dos casos de uso y decimos que el primero incluye al segundo es decir que el segundo es parte esencial del primero.

6. ¿Qué se entiende con "incluir un caso de uso"?. Dar un ejemplo

RTA/Include. En términos muy simples, cuando relacionamos dos casos de uso con un “include”, estamos diciendo que el primero (el caso de uso base) incluye al segundo (el caso de uso incluido). Es decir, el segundo es parte esencial del primero. Sin el segundo, el primero no podría funcionar bien; pues no podría cumplir su objetivo. Para una venta en caja, la venta no puede considerarse completa si no se realiza el proceso para cobrarla en ese momento. El caso de uso “Cobrar Renta” está incluido en el caso de uso “Rentar Video”, o lo que es lo mismo “Rentar Video” incluye (<<include>>) “Cobrar Renta”.

Figura 2. Ejemplo de Include

7. ¿Qué se entiende con "extender un caso de uso"?. Dar un ejemploRTA/

Extend. La polémica al querer seleccionar una de las dos relaciones es que en el “extend” también podemos ver, desde la perspectiva del usuario, a los dos flujos como si fueran uno sólo. Y en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no se ejecutara la extensión. Pero, una de las diferencias básicas es que en el caso del “extend” hay situaciones en que el caso de uso de extensión no es indispensable que ocurra, y cuando lo hace ofrece un valor extra (extiende) al

Distrito Capital



INFORMACIÓN



2023Página 10 de 14

objetivo original del caso de uso base. En cambio en el “include” es necesario que ocurra el caso incluido, tan sólo para satisfacer el objetivo del caso de uso base. Ejemplo: Puedes “Realizar Venta” sin “Acumular Puntos de Cliente VIP”, cuando no eres un cliente VIP. Pero, si eres un cliente VIP sí acumularás puntos. Por lo tanto, “Acumular Puntos” es una extensión de “Realizar Venta” y sólo se ejecuta para cierto tipo de ventas, no para todas.

Figura 3. Ejemplo de Extend

8. Describa como sería el caso de uso "comprar café" en una dispensadora - máquina de café.

RTA/Describa como sería el caso de uso "comprar café" en una dispensadora - máquina de café.Los casos de uso pueden ayudarle a analizar un negocio y un sistema. Imagine una gran tienda de equipos de cómputo que vende hardware, periféricos y software. ¿Quiénes serían los actores? ¿Cuáles serían algunos de los principales casos de uso?

9. Los casos de uso pueden ayudarle a analizar un negocio y un sistema. Imagine una gran tienda de equipos de cómputo que vende hardware, periféricos y software. ¿Quiénes serían los actores? ¿Cuáles serían algunos de los principales casos de uso?

RTA/ Los actores serian el vendedor y el comprador ya que son los que gestionan el sistema.

EMPLEADO ADMINISTRA

Distrito Capital



INFORMACIÓN




CLIENTE COMPRA

Figura 1. Relacionando casos de uso

Casos de Abuso

Uno de los riesgos que existe cuando la gente sabe que tiene estas relaciones como un elemento a utilizar en sus modelos de casos de uso, consiste en su abuso. Mucha gente, y sobre todo la que arrastra prácticas de métodos estructurados, la suele utilizar en exceso. No es raro ver modelos de casos de uso que llegan a tener decenas de inclusiones y extensiones, incluso las inclusiones y extensiones se vuelven a extender a varios niveles, generando una maraña de casos de uso que no ofrecen valor al ser mostrados explícitamente.

Figura 4. Abuso de relaciones

Es importante comprender que el objetivo de estos tipos de relaciones NO consiste (remarco la negación) en motivar la división de los casos de uso en la mayor cantidad de pedazos. Debe de

http://www.milestone.com.mx/articulos/imagenes/caso_de_abuso.gif

Distrito Capital



INFORMACIÓN




existir una razón importante para que decidamos dividir un caso de uso en dos que serán unidos por medio de alguna de estas relaciones. Si entendemos esto y somos congruentes, obtendremos un beneficio real para el proyecto; fin último del uso de UML.

La razón por la que la gente suele partir sus casos de uso en infinidad de “include” y “extend” es porque quieren conocer, entender y comunicar el máximo detalle de los casos de uso en el diagrama. Hay quien llega a utilizar, erróneamente, estas relaciones para mostrar el orden en que se ejecutan estos casos de uso. Debemos de recordar que al modelar el diagrama de casos de uso no buscamos analizar el detalle, y mucho menos los flujos. Todo ese detalle lo podremos plasmar en otro tipo de diagramas, como los diagramas de interacción, de actividad, de estados, o simplemente un texto en una especificación.

Relaciones de Análisis o Diseño

Otra situación donde abusamos de estas relaciones se da cuando queremos representar la unión de casos de uso por una decisión de diseño del sistema, específicamente por una decisión de navegabilidad entre funciones. Pensemos en cierta funcionalidad en un sistema, la cual corresponde a la ejecución de cierto caso de uso (por ejemplo “Registrar Préstamo de un Video”). Y estando en dicho caso de uso tienes a la vista en la pantalla, y decides utilizar, un botón que te permitiría iniciar otro caso de uso que tiene poco o nada que ver con el objetivo del caso de uso inicial (digamos, “Consultar Promociones”). Esto no debería de mostrarse como una relación entre estos dos casos de uso en el modelo.

No deberíamos modelar al primer caso de uso incluyendo ni siendo extendido con el segundo caso de uso ni viceversa, pues la razón por la que se ligaron (no gráficamente, sino en su ejecución) fue por una facilidad otorgada por la manera en que se diseñó el sistema, la cual permite navegar fácilmente entre las diferentes funciones del sistema. La navegabilidad que otorga el sistema entre uno y otro caso de uso normalmente tiene que ver poco con que exista o no una relación entre dichos casos de uso.

Reúso: Evitando el Retrabajo

Una de las razones por las cuales deberías de considerar el uso de este tipo de relaciones, es porque identificas que hay pasos que son iguales en dos o más casos de uso. No querrás tener que escribir y darle mantenimiento a esos pasos en los documentos asociados a cada uno de ellos. Peor aún, no querrás correr el riesgo de que esos pasos se diseñen, programen y prueben de maneras diferentes y con esfuerzos aislados por ti o tu equipo de desarrollo. Finalmente son la misma cosa, ¿para qué querríamos trabajar doble? Lo que queremos es economizar, ser más eficientes en el desarrollo, y ahí es cuando viene el beneficio de identificar estos tipos de relaciones; porque es una oportunidad

Distrito Capital



INFORMACIÓN




de identificar reúso.

Figura 5. Identificación de reúso

Si te sientes preparado para desarrollar modelos de casos de uso más sofisticados y de mayor valor, entonces considera la posibilidad de utilizar estos tipos de relaciones. Sólo asegúrate de aprovecharlas adecuadamente, buscando el beneficio real que deberían de proporcionar en tu modelo y proyecto con base en las recomendaciones mencionadas. Y recuerda unificar los criterios dentro de tu empresa para que el lenguaje sea realmente unificado o estandarizado dentro de tu empresa.

6. EVIDENCIAS DE APRENDIZAJECONOCIMIENTO: Mediante la conceptualización de los diversos términos relacionados con el lenguaje unificado de modelado, el aprendiz dispondrá de la base teórica para empezar a modelar la arquitectura de diferentes sistemas, empleando los diagramas de caso de uso para visualizar la interacción del usuario con el sistema, previa definición de los requerimientos del mismo.

7. FUENTES BIBLIOGRÁFICAS

Distrito Capital



INFORMACIÓN




El Lenguaje Unificado de Modelado. Grady Booch, James Rumbaug, Ivar Jacobson. Ed. Addison Wesley

UML Gota a Gota. Martin Fowler, con Kendall Scott. Pearson Educación

8. TIEMPO ESTIMADO4 horas

9. INSTRUCTORIng. Uldarico Andrade HernándezOrientador: Ing. Henry Garzón

10. FECHA DE ENTREGA DE LA GUIA 25 de Febrero 2015

Documents

GuÃ-a 2 - kamila UML.docx