Entradas etiquetadas como fundamentos de rup

Diagramas de Clase

De entre todos los tipos de diagramas UML, el más común y conocido es el diagrama de clases. Dicho diagrama ilustra una vista de los componentes estáticos del sistema, ya sean estos clases o módulos, indicando las relaciones entre estas y los atributos (datos) de las clases, así como sus métodos (código).

El diagrama de clases puede ser utilizado para presentar la vista estática del modelo de dominio, del modelo de diseño, o bien, del detalle de la implementación de un sistema en un lenguaje de programación orientado a objeto, como Eiffel, Java o C++. Para todos estos usos, lo que se desea es expresar las unidades en que el código se organiza -las clases- así como algunas características de estas, notablemente como dije antes, sus relaciones, atributos y métodos.

Es valido combinar los diagramas de clase con paquetes, dando lugar a un diagrama que muestra simultáneamente clases y paquetes. Dicha práctica ayuda a documentar elementos que estén en distintos paquetes pero que guarden alguna relación, aún cuando la especificación de UML habla de diagramas de tipos diferentes para los paquetes y las clases.

En este blog se encuentran muchos ejemplos de diagramas de clase, ya que se han incluido en los post que lo requieren como parte del asunto tratado. Algunos de estos son:

Por lo anterior, si se queiren ver ejemplos de un diagrama de clases, basta con dar un paseo por el blog, seguro encontrará muchos ejemplos apropiados.

Anuncios

, , , , ,

2 comentarios

Las 4+1 Vistas

Un enfoque en la presentación de un sistema en UML es conocida como 4+1 vistas. Esta forma de documentar nuestros modelos divide lo que sabemos de él en cinco áreas:

  • Vista de Casos de Uso: que contiene requisitos desarrollados en las restantes vistas.
  • Vista Lógica: Muestra la estructura estática del sistema.
  • Vista Física: Muestra el despliegue de la aplicación en la red de computadoras.
  • Vista de Procesos: Muestra los hilos y procesos de ejecución así como la comunicación entre estos.
  • Vista de Desarrollo: Muestra la estructura en modelos del código del sistema.

Estas vistas se presenta tradicionalmente en una figura de cuatro cajas con un ovalo central que representa al modelo de casos de uso. Dicho gráfico no es UML pero al ser tan conocido no puedo menos que incluirlo en el post. La siguiente figura corresponde a esta imagen de la que hablo:

Fig. 1 – Diagrama simple del enfoque 4+1 vistas.

El enfoque 4+1 vistas fue desarrollado originalmente por Philippe Kruchten en 1995, el artículo original puede ser encontrado en la Internet en: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf.

De acuerdo al Sr. Kruchten, las distintas vistas del enfoque responden a las necesidades de las distintas partes interesadas: clientes, programadores, administradores, etc. Para cada uno de estos, se presenta una visión resumida del sistema con la información que requieren para satisfacer sus necesidades.

Es así que la vista de desarrollo le dice al programador como iniciar y organizar su código; la vista física ayuda a los administradores de sistemas a decidir la infraestructura que se ha de dedicar al sistema; la vista de procesos es útil para realizar análisis de integridad y tomar decisiones de integración con otros sistemas; finalmente, siempre de acuerdo con el Sr. Kruchten, la vista lógica le sirve a los usuarios y clientes a visualizar la funcionalidad que el sistema les provee.

Este enfoque es uno de los más extendidos en la literatura, sin embargo su aplicación es de alcance limitado en los tiempos modernos, donde las aplicaciones tradicionales han dejado su lugar a sistemas basados en Web. Es entonces un enfoque digno de estudio aunque es probable que en nuestros proyectos sigamos otras aproximaciones para la organización y presentación de nuestros modelos.

, , , , , , , , , ,

5 comentarios

Presentación de Modelos en UML

UML documenta los sistemas de software que modela desde dos puntos de vista básicos: dinámico y estático. Por modelado dinámico nos referimos al comportamiento del sistema en tiempo de ejecución, en tanto que por modelado estático nos referimos a la descripción de los componentes del sistema así como de sus relaciones.

El siguiente diagrama de paquetes ilustra la situación:

Fig. 1 – Modelo de sistema con parte dinamica y estatica.

Dicha división no significa que nosotros tengamos que dividir nuestros modelos en dos paquetes para acto seguido crear elementos y diagramas en cada uno de estos; muy por el contrario, la presentación de la parte dinamica y estatica se hace para cada modelo del sistema es decir, ya sea que estemos creando un modelo de requisitos, uno de análisis o presentando el modelo físico, en todos los casos tendremos diagramas que visualicen tanto el comportamiento dinamico como la estructura estatica del sistema.

Es mucho más habitual el presentar los sistemas con una colección de puntos de vista, y para cada uno de estos, mezclar diagramas dinamicos y estaticos.

, , , , ,

3 comentarios

El Ciclo de Vida: Fase de Elaboración

La fase de elaboración es la encargada de determinar la solución técnica del proyecto. Así como durante la fase de inicio se determino el qué, ahora es necesario el como. Es esta fase durante la cual elaboramos los requisitos al nivel del diseño y por tanto, nos pone en posición de saber si el proyecto es técnicamente viable así como conocer la tecnología que vamos a utilizar durante la construcción.

El foco de la fase de elaboración se encuentra en las disciplinas de Diseño y Análisis; ya que estas son las encargadas de dar con la solución técnica. Aunque también hay un importante papel para la Gerencia del Proyecto, dado que en la fase de Elaboración es el punto donde debemos haber disminuidos y controlados los riesgos principales que pudieran dar al traste con el proyecto.

Es también la Fase de Elaboración el punto de no retorno para el proyecto. Una vez que dejemos atrás a esta fase y entremos en la construcción, los gastos serán tan elevados que se tendrá que tener muy en claro el alcance de la apuesta económica; es mejor detener un proyecto aquí, cuando se ha ejecutado menos del 25% del presupuesto que más adelante, donde los gastos son mucho mayores.

Típicos objetivos para esta fase son:

  • Documento de Arquitectura del Sistema revisado y aceptado.
  • Prueba de Concepto exitosa de todas las tecnologías novedosas a utilizar.
  • Prototipo de la Arquitectura del sistema.
  • Plan de Riesgos con los riesgos principales identificados y controlados.

El objetivo central es solo uno: responder si el proyecto es técnicamente viable con la solución o diseño propuesto.

Entonces, ahora como para el glosario:

Fase de Elaboración: Establece el como del proyecto; es decir: determina la solución técnica del sistema y la demuestra a nivel de pruebas de concepto. La Fase de Elaboración también es el punto donde se deben de haber controlado los riesgos principales del proyecto.

Finalmente, en cuanto a su duración, considero como sano una fase de elaboración de dos o tres iteraciones. Esto debido a la necesidad de realizar y probar el diseño, lo que genera una carga de documentación y de programación sensiblemente mayores a las que teníamos durante la fase de concepción. Por otra parte, en un proyecto típico, el gasto realizado es de aproximadamente el 20% del total del costo del proyecto; por lo que la ejecución del presupuesto si contamos también a la fase de concepción rondará el 25%.

, , , , , ,

4 comentarios

Centrado en la Arquitectura

Un Proceso Definido es una construcción mental; que organiza un conjunto complejo de conceptos. No es de sorprender entonces que sea útil el construir este Proceso en torno a una serie de conceptos o principios, que hagan más fácil la comprensión del todo.

Uno de los principios claves del método definido al que llamamos UP, es la declaración que dice: Centrado en la Arquitectura. Es este uno de los tres principios rectores del método, por lo que no debemos menospreciar su importancia.

Entendemos por Arquitectura los elementos centrales del diseño de un sistema. Pueden ser las abstracciones comunes, los fundamentos en código o la tecnología central utilizada. Sea cual sea el caso, la arquitectura es esa parte del sistema que describe lo fundamental de este, y que por tanto, mantenemos esencialmente inalterada pese a las adiciones y modificaciones que tenga el software.

Dicho formalmente, como para el glosario:

Arquitectura del Software: conjunto de elementos esenciales del diseño, que sientan la estructura común a todo el sistema y determinan sus posibilidades técnicas con miras a satisfacer los requisitos con un mínimo de riesgo técnico y con un uso apropiado de los recursos disponibles.

Es durante la Fase de Elaboración que se desarrolla la arquitectura, no solo por medio del diseño en un UML, sino que también se prueba, se implanta y se documenta. De todo esto se encarga la llamada Disciplina de Diseño.

El método lucha en todo momento por establecer y mantener una arquitectura viable, por lo que la conservamos durante la fase de construcción. La idea de arquitectura es de hecho tan importante, que es posible incluso argumentar que el riesgo tecnológico queda disminuido gracias a que una buena arquitectura nos da bases para evitar muchos problemas e incluso, para hacer factible técnica y económicamente a un proyecto.

Notemos que la arquitectura es uno de los principales puntos a ser sometidos al proceso de Revisión por Pares, dado su rol central en la obtención de un software de calidad; no solo para el esquema tradicional de características de calidad, sino también para el enfoque de concordancia que manejo en el blog.

Finalmente recordemos que los otros dos principios básicos son Iterativo Incremental y Guiado por Riesgos y Requisitos.

, , , ,

Deja un comentario

La Iteración Inicial

En muchas ocasiones ocurre que las ideas de proyectos fluyen entre las organizaciones -o dentro de ellas- de una manera más informal que formal. Esto es natural, ya que todos acostumbramos a hablar mucho de nuestras cosas con los amigos y compañeros, así como de recurrir a los aliados a la hora de intentar comprender algo. Y sin duda, los proyectos que “están en el tintero” son objeto de conversación en estas reuniones.

Así la cosa, es probable que las primeras acciones de un proyecto sean tomadas mucho antes de contar con un acuerdo formal sobre el modelo de negocio, el método de desarrollo o las condiciones de contratación. Todos estos, aspectos muy importantes a la hora de definir el Caso de Desarrollo y el Caso de Negocio que sustentan en ultimada instancia el proceso de desarrollo.

Entonces surge la pregunta: ¿como dar cabida a este proceso de discusión de proyectos en un Proceso Definido? Pues bien, la solución que planteo es la de definir una Iteración Inicial.

Llamo así, a todo el tiempo que transcurre desde la primera mención de la idea de un proyecto, hasta el inicio de su primera iteración “oficial” o planificada tal y como se entiende dentro del método de desarrollo. Esta iteración inicial puede abarcar desde días hasta meses, y esta orientada a permitir registrar el avance de la idea en la medida en que esta va demandando trabajo.

Entonces, en el Plan de Desarrollo vamos a tener una Fase de Inicio formada por cuando menos, dos iteraciones. Una -la inicial- que tiene fecha de inicio indeterminada y la otra -la primera formal- que dura lo que todas nuestras iteraciones y que esta definida en un Plan de Iteración en términos precisos.

Nos estamos viendo.

, , , , ,

Deja un comentario

Como dar inicio a un Proyecto

Acostumbro a pensar -así, a título personal- que un proyecto se arranca con los siguientes tres simples pasos:

  1. Escuchar a los Grupos de Decisión –Stakeholders– del Proyecto.
  2. Capturar lo que se sabe en Artefactos iniciales del Proyecto.
  3. Ejecutar el método de desarrollo.

En un primer momento, el Proyecto solo existe en la mente del cliente y de los restantes grupos de decisión, por lo que espero que sea natural para todos que el escuchar sea una primera actividad bien aceptada. Sin embargo, el escuchar tiene su truco. No es lo mismo compartir una mesa de reunión, que el escuchar atentamente y entender lo que se dice.

Con todo, si se han asumido buenas practicas, como el desarrollo de un glosario, seguro que este primer paso puede ser dado sin mayores tropiezos.

Luego de esto, es necesario realizar un Caso de Desarrollo con el objetivo de establecer los soportes -documentos y artefactos- donde vamos a hacer registro de lo que hemos captado al escuchar a los Grupos de Decisión. Este paso es el punto de inicio del Proceso Definido, y debe ser visto como el ultimo momento en que el proyecto puede existir sin una estructura definida.

Finalmente, dado que los artefactos tienen un momento en el Ciclo de Vida, y su desarrollo esta regido por actividades bien conocidas, es posible entonces dejar que el proceso cobre su propia vida y se ejecute en sus propios términos. Ya sabe, en los términos del Proceso Definido que hemos adoptado.

, , , , , , ,

Deja un comentario