UML Gota A Gota

CAP 2 Un bosquejo del procesos de desarrollo

UML es un lenguaje para modelar, no un metodo.

A pesar de que se podrían haber obviado los procesos de modelamiento, el hecho de describir técnicas para modelar no tiene mucho sentido sin estar inserto dentro de un proceso de modelamiento.

El proceso llamado objectory tiene detalles sobre los tipos de modelos para desarrollar en las diferentes etapas del proceso. Lo que se describe en este capitulo es una descripción de un modelo ligero de bajo perfil pero consistente con objectory.

Sin embargo no deje dejarse de lado el hecho de que UML es independiente con el proceso que se utilice, se debe utilizar algo adecuado para el proyecto que se esta abordando.

El procesos de desarrollo a describir tiene 4 etapas en su nivel mas alto de explicación, estos son:

- Concepción

- Elaboración

- Construcción

- Transición

Este procesos es un proceso de desarrollo iterativo y gradual, es decir el sw no es liberado en forma total de una sola vez, sino que por partes.

La etapa de construcción en particular consta de muchas iteraciones, donde cada iteración es un sw que se prueba eintegra y cubre un subconjunto de requerimientos del proyecto, cada una de estas entregas puede ser internas o externas. Cada una de estas iteraciones tiene cada una de las fases normales de un ciclo de vida: analisis, diseño, implementación y experimentación.

De las dos primeras etapas, concepción y elaboración, se puede decir con rrespecto a la concepción que se ve la razon del proyecto y su alcance (compromiso del sponsor), la elaboración tiene que ver con los requerimientos detallados con analisis y diseños de alto nivel.

En la transición deben estar las pruebas beta, afinación de desempeño y entrenamiento del usuario.

La descripción mejor de cada una de las fases esta a continuación:

Concepción

Se define la situación económica del proyecto, cuanto costará aproximadamente y cuanto retornará, además de conocer el alcance que va a tener el proyecto.

En la concepción se analiza si es necesario o vale la pena dedicar algún tiempo de investigación durante la elaboración.

Elaboración

En esta etapa al comienzo se tien una vaga idea de lo cuales son los requerimientos

En esta etapa se querrán dilucidar ciertas dudas como que requiere contruir, comose va a contruir y la tecnología con la cual se contruira

En esta etapa lo que mas se debe considerar son lo riesgos asociados al proyecto. Según la experiencia del autor los riesgos se pueden clasificar en cuatro categorías. Riesgos de requerimietos (construir un sistema que realmente satisfaga los requerimientos), tecnologicos (existe experiencia en el trajo con objetos?, se conoce suficiente Java o Web?), habilidades (estan disponibles expertos que se necesitan) y politicos.

- Manejo de riesgos de requerimientos

En esta parte las técnicas de UML son especialmete provechosas, en particular los casos de uso descritos mas adelante.

Los casos de uso son la base para la comunicación entre patrocinadores y desarrolladores durante la planificación del proyecto.

Una de las cosas mas importantes de esta etapa de elaboración es descubrir los posibles casos de uso (no todos pero la gran mayoría).

Ademas de los casos de uso se debe elaborar el modelo conceptual del dominio, este modelo es cualquier modelo cuyo sujeto de apoyo se el mundo que da el apoyo al sistema que se va a desarrollar.

Existen dos valiosas técnicas para la construcción de modelos del dominio: Diagramas de clase y Diagramas de Activad.

Los digramas de clase deben ser descritos desde la perspectiva conceptual para ver los conceptos que utilizan los expertos y como se vinculan entre ellos.

Los diagramas de actividad complementan lo anterir diagramando los flujos de trabajo del negocio.

Este modelo de dominio es un modelo de alto nivel

- Manejo de riesgos Tecnológicos

Lo que se debe hacer es contruir prototipos que prueben las partes tecnologicas con las que piensa uno trabajar, es decir, construir las primeras versiones del modelo del dominio y ver que tal funcionan las herramientas escogidas.

Se deben probar diversos tipos de herramientas para ver cual de todas funciona mejor.

El riesgo mayor esta en integrar los componentes tecnologicos como lenguajes de programación y bases de datos.

Se deben tomar las decisiones arquitectonicas que darán la idea acerca de los componentes y como se contruirán estos mismos

Para ver estos riesgos se pueden utilizar los diagramas de clases y de interacción para ver como se comunican las distintas componentes, además los diagramas de emplazamiento pueden dar un panorama sobre la distribución de las piezas

- Manejo de riegos de habilidad

Se debe tener un entrenamiento adecuado con respecto a las técnicas que se va a utilizar para evitar errores que pueden costar muy caros en terminos de dineros y plazos.

Se puede tener un tutor que apoye al grupo de desarrollo en el tema del desarrollo, el cual puede ir una vez por semana a revisar y supervisar el trabajo realizado realizando criticas constructivas para mejorar los modelos.

- Manejo de riesgos políticos

El autor no puede ofrecer consejos importantes porque no se considera un politico, pero recomienda buscar alguien que si lo sea.

La etapa de elaboración tiene un resultado conocido como base arquitectonica que se compone de casos de usos que definen requerimientos, el modelo del dominio que es la clave para las principales clases del dominio y como se acoplan las partes claves de la plataforma tecnológica

La elaboración termina cuando los desarrolladorestiene la confianza para estimar sobre el tiempo que demorarla construcción de cada uno de los casos de uso, además se han identificado los riesgos siginificativos y se sabe como tratarlos.

Se debe tener clara la planificación en base al punto anterior

Construcción

La construcción se confecciona a partir de iteraciones, donde cada iteración es un mini proyecto, es decir, se debe hacer analisis, diseño, codificación pruebas e interacción finalmente se hace una demostración al usuario para ver que se haya cumplido el requerimiento que abarca el caso de uso, esto con el fin de reducir el riesgo que significan las pruebas y la integración

Se recomienda realizar un código de pruebas, es decir, no se puede dar por finalizado un código si no se le han hecho las pruebas suficientes.

Las iteraciones en esta etapa son incrementales e iterativas, lo primero se refiere es que en cada iteración se construye sobre los casos de uso hechos en las iteraciones anteriores. Lo segundo tiene relación con la reescritura de alguna parte del codigo que implementa el caso de uso

Empleo del UML en la construcción

Transición

Durante esta etapa no se deben hacer desarrollos para añadir funciones nuevas, sino que debe haber un desarrollo de depuración, es decir una liberación beta, depurar esta versión y liberar el producto final

CAP 3 Casos de Uso

Los casos de uso son la herramienta esencial para la captura de los requerimientos por parte del usuario.

Los casos de uso son interacciones del usuario con el sistema. Un conjunto de estos Casos de uso representan los objetivos que tenga el usuario con el sistema.

Los casos de uso deben ser usados en la fase de elaboración principalmente, por lo menos los que se puedan detectar. No se debe tratar de descubrir todos los casos de Uso de una sola vez, sino que al ir iterando se irán descubriendo.

Actor

El actor es un usuario que interactúa con el sistema, no se debe pensar en la personas sin no en papeles al momento de definir los actores, ya que una persona puede desempeñar diversos roles y estos deben ser vistos por separado.

Un actor puede realizar varios casos de uso y un caso de uso puede ser realizador por muchos actores.

El autor recomienda, para los sistemas grandes, definir primero cuales son los actores y luego los casos de uso que interactúan con ellos.

Los actores no necesariamente son seres humanos, sino que pueden ser sistemas, a pesar de que existen modeladores que difieren de esta definición. El autor considera que los sistemas son actores dentro del modelo y por lo tanto los integra como tal.

Una buena forma de identificar los casos de Uso es identificar los eventos externos que puedan provocar una reacción en el sistema.

Extend

Se usa un extend cuando se tiene un caso de uso que es similar a otro pero que hace un poco mas.

Se refiere a las variaciones que puedan ocurrir en el flujo normal del caso de uso, es decir preguntar acerca de que puede fallar o como el caso de uso puede funcionar de forma distinta. El autor recomienda que todas las variaciones que puedan pasar dentro de un caso de uso sean dibujadas como extensiones.

En la etapa de construcción se dividen los casos de uso complejos en casos de uso normales con un cierto numero de extensiones y luego se solucionan por

...