SEMANA SIETE

Pista de aprendizaje:

Tener en cuenta: las metodologías de desarrollo son distintas, con distinto alcance, todas son válidas, aunque existan algunas con más recursos que otras.

Tenga presente: la orientación a objetos es una de las mas  completas y recursivas.

Traer a la memoria: si hay un buen manejo de los conceptos existe la posibilidad de una buena aplicación en la práctica.

Introducción al UML

UML, es un lenguaje de Modelos Unificados por sus siglas en inglés, es el lenguaje de modelos de sistemas de software más popular en la actualidad, es un lenguaje para construir, especificar,visualizar y documentar sistemas de aplicativos.

Comprensión de los Modelos

Un modelo es una colección de imágenes y texto que representa algo, para nuestro software.

Los modelos son valiosos por muchas razones específicas, en gran parte, constan de imágenes e incluso, las imágenes simples pueden transmitir más información que una gran cantidad de texto.

Los modelos son valiosos porque es más fácil dibujar algunas imágenes sencillas que escribir código o incluso texto que describa lo mismo, además es más económico, rápido y fácil de cambiar modelos que cambiar código o texto.

El UML es una definición de un lenguaje de símbolos y relaciones comunes que tiene un significado común, si todos los participantes hablan UML, entonces las imágenes tienen el mismo significado para todo aquello que las observe, por lo tanto, aprender UML es esencial para ser capaz de usar imágenes para experimentar económico, flexible y dar rápidas soluciones.

Uso de los Modelos

Los modelos consisten en diagramas o imágenes, lo que intenta con los modelos es que sea más fácil de producir y experimentar que con solo código.

Creación de diagramas

La primera regla de la creación de diagramas de modelos es que el código y el texto consumen tiempo, y no queremos pasar una gran cantidad de tiempo creando documentos de texto que nadie leerá. Lo que si queremos hacer es captar con exactitud las partes importantes del problema y una solución. Lamentablemente, esta no es una prescripción para el número o la diversidad de diagramas que necesitamos crear y no indica cuanto detalle necesitamos agregar a esos diagramas.

Tipos de Diagramas

Existen varios tipos de diagramas que el individuo puede crear, miremos los tipos que se pueden usar y los tipos de información que se pretende transmitir con cada uno de los diagramas.

Diagrama de cajas de uso (casos de uso)

Los símbolos principales de las cajas de uso son el actor, y el ovalo de la caja de uso, los diagramas son responsables principalmente de documentar los macro requisitos del sistema, pensando en la lista de capacidades que debe tener o proporcionar el sistema.

Un diagrama de actividades es la versión UML de un diagrama de flujo. Los diagramas de 

actividades se usan para analizar los proyectos y, si es necesario, volver a realizar la ingeniería de los procesos.

Un diagrama de actividades es una herramienta excelente para analizar problemas que al final, el sistema debe resolver. Como una herramienta de análisis, no queremos empezar resolviendo el problema a un nivel técnico mediante la asignación de clases, pero podemos usar diagramas de actividades para entender el problema e incluso refinar los procesos que comprenden el problema.

Diagrama de Clases

Los diagramas de clases se usan para mostrar las clases de un sistema y la relación entre ellas. Una sola clase puede mostrarse en más de un diagrama de clases y no es necesario mostrar todas las clases en un solo diagrama monolítico de clases. El mayor valor de mostrar las clases y sus relaciones desde varias perspectivas, de una manera que ayudara a transmitir la comprensión más útil.

Los diagramas de clases muestran una vista estática del sistema, no describe los comportamientos o cómo interactúan los ejemplos de la clase. Para describir los comportamientos y las interacciones entre los objetos de un sistema, podemos revisar los diagramas de interacción.

Diagramas de interacción

Existen 2 tipos de diagramas de interacción, la secuencia y la colaboración. Ambos transmiten la misma información, empleando una perspectiva un poco diferente. Los diagramas de secuencia muestran las clases a lo largo de la parte superior y los mensajes enviados entre esas clases, modelando un solo flujo a través de los objetos del sistema. Los diagramas de colaboración usan las mismas clases y mensajes, pero organizados en una disposición espacial.

Un diagrama de secuencia implica un ordenamiento en el tiempo al seguir la secuencia de 

mensajes desde arriba a la izquierda hasta abajo a la derecha. Debido a que en el diagrama colaborativo no se indica en forma visual un ordenamiento en el tiempo, enumeramos los mensajes para indicar el orden en el cual se presenta. 

Algunas herramientas convertirán de manera automática los diagramas de interacción 

entre secuencia y colaboración. Pero no es necesario crear los dos tipos de diagrama. 

En general, se percibe que un diagrama de secuencia es mas fácil y más común.

Ejemplo (Diagrama de colaboración)

Mientras que los diagramas de interacción muestran los objetos y los mensajes que se pasan entre ellos, un diagrama de estado muestra el estado cambiante de un solo objeto, conforme este pasa por un sistema.

Diagramas de componentes

El UML define varios tipos de modelos, incluyendo modelos de análisis, para el diseño y para implementación, sin embargo, nada hay que le fuerce a crear o mantener tres modelos para una aplicación. Un ejemplo de un diagrama que podría encontrar en un modelo de implementación es de componentes. En un diagrama de componentes, estos se muestran en el producto final.

Otros Diagramas

Existen otros tipos o variaciones de diagramas que podemos crear. Por ejemplo, un diagrama de topología del despliegue le mostrara como se verá desplegado su sistema. Lo común es que un diagrama de este tipo contenga símbolos que representan cosas, como servidores web, servidores de bases de datos y varios dispositivos diversos, así como software que construye la solución que usted requiere. Este tipo de diagrama es más común cuando usted está estructurando sistemas distribuidos en n hileras.

VIERNES 27 DE NOVIEMBRE

Pista de aprendizaje:

Tener en cuenta: es una herramienta de análisis que nos permite optimizar recursos, tiempos y mejoras en la creación de un sistema de cómputo.

Tenga presente: no es una herramienta exclusiva para el desarrollo de software.

Traer a la memoria: que es un proceso que depende de la lógica del que analiza el problema, no hay una limitante de los procesos o una estructura única de creación.

Definiciones: 

» Proceso de negocio: Flujo de trabajo de la organización. Existe por sí mismo.

» Requisito: Característica que el sistema software debe tener. 

» Caso de uso: Técnica para la definición de requisitos funcionales.

 » Caso de uso: 

1. Conjunto de acciones realizadas por el sistema. 

2. Producen un resultado observable. 

3. Participan actores

Diagramas de casos de uso

¿Qué casos de uso identificamos?

 » Iniciar una nueva partida. 

» Descubrir una casilla. 

» Marcar una casilla. 

¿Quién realiza estos casos de uso?

 » El jugador.

Ejercicio: Descripción del problema

•  Sokoban es un juego de varios niveles.
•  Cada nivel está compuesto por un jugador, cajas, repisas y muros.
•  El objetivo del jugador es empujar todas las cajas sobre las repisas.
•  Cuando esto sucede el jugador pasa al siguiente nivel
•  Para mover una caja, el jugador debe colocarse al lado y empujarla. Si la casilla hacia la que está empujando la caja está libre la caja se moverá.
• Si el jugador se queda bloqueado, es decir, no puede terminar el nivel, puede reiniciar el nivel perdiendo una vida. 
• Cuando el jugador pierde todas sus vidas la partida termina.

Relaciones actor-actor y casos de uso-casos de uso

• Ya hemos visto la única relación posible entre un actor y un caso de uso: asociación. 
•  También podemos establecer una única relación entre actores: generalización. 
•  En UML podemos establecer tres relaciones entre casos de uso: generalización, inclusión y extensión.

Ejercicio: 

sistema de normativas 

» Actor funcionario

 • Suscribirse a avisos de normativas. 

• Buscar normativas 

• Ver detalles de una normativa. 

» Actor registrador

 • Acceder al sistema con su nombre y clave. 

• Registrar normativa. • Borrar normativa. 

• Reemplazar normativa,


Casos a incluír y casos a extender 

Antes que todo, ¿qué es el “include” y el “extend”?  Gráficamente lo que mostramos es una relación de dependencia entre el par de casos de uso, con el nombre correspondiente al tipo de relación de la que se trate: ya sea <<include>> o <<extend>>. Estas, son relaciones que usamos para ligar gráficamente dos casos de uso, cuyos flujos de eventos están unidos, normalmente en una sola sesión del usuario. En otras palabras, un caso de uso que está ligado, por medio de una de estas dos relaciones, a otro caso de uso; también podría leerse o ejecutarse como un sólo caso de uso en lugar de dos. Obviamente, hay una razón por la cual decidimos separarlos en dos, lo cual explicaremos más adelante. Imagina el conjunto de pasos que ocurren al realizar una compra en una tienda departamental. Seguramente no tendrás problema en visualizar el conjunto de pasos para solicitar la autorización de la tarjeta de crédito con la que vas a pagar, ligado a los pasos donde el vendedor registra los productos a comprar. Es decir, los flujos de eventos de ambos procesos forman una sola cosa; juntos podrían formar un solo caso de uso, en lugar de dos casos de uso unidos por alguna de estas relaciones que aquí estamos tratando. Figura 1. Relacionando casos de uso 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 incluído). 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 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 objetivo original del caso de uso base. En cambio en el “include” es necesario que ocurra el caso incluído, 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 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 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ño 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. Reuso: 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 de identificar reuso. Figura 5. Identificación de reuso 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. Por Leticia Ortiz