Archivo para la categoría Análisis

Qué es un modelo?

Llamamos modelo a toda representación simplificada de la realidad, donde se han conservado aquellos elementos considerados importantes y se han descartado todo lo demás.

Los modelos son importantes dentro de la industria del software, y son utilizados para toda suerte de fines. Es posible apoyarse en el uso de modelos para entender y comunicar una enorme variedad de aspectos de nuestros productos de software e incluso, de los proyectos en si mismos.

En general, ya sea dentro de la industria del software o no, los modelos vienen a ayudar la comprensión de la realidad, al presentarnos solo aquellos aspectos o características de la situación que sean relevantes en un momento dado.

Pongamos un ejemplo. El New Beetle es un producto muy conocido de la compañía alemana Volkswagen y es el automóvil que podemos ver en la primera imagen. En este caso, es un automóvil de color negro.

Automóvil Volkswagen New BeetleFig 1. Volkswagen New Beetle.

Es posible decir mucho de este automóvil. Podemos indicar cualidades obvias, como que tiene cuatro ruedas, dos puertas, un volante, que su techo es curvo o cualquier otra que se nos pueda ocurrir. Aunque también es posible indicar cualidades más sutiles, como el hecho que el automóvil de la foto no tiene placa. Hemos de recordar que después de todo, el producto no es solo muy conocido, sino que lo que tenemos ante nosotros es una foto y por lo tanto, tenemos muchos detalles a la vista.

Es posible sin embargo, que en un momento dado lo que nos interese decir sobre el automóvil sean sus medidas. Si este el caso hemos de construir un modelo en el cual se eliminen todas estas cualidades observadas y se queden solo aquellas que permitan ver con claridad las medidas del automóvil.

Naturalmente siempre podremos comunicar nuestra versión simplificada del automóvil por medio de una imagen, quizás una imagen como la siguiente.

Esquema del Volkswagen New BeetleFig 2. Esquema del Volkswagen New Beetle.

Nuestra segunda imagen resalta el aspecto de interés: las medidas del automóvil. Al hacerlo nos presenta una vista inusual del producto real, quizás una que no tendremos ocasión de ver jamás en el mundo físico, pero que comunica en forma muy directa lo que necesitamos.

Un modelo es pues, definido como para el glosario:

Modelo: toda construcción hecha con información de una situación, idea o fenómeno real, en la cual hayamos resaltado ciertos aspectos de interés al tiempo que hemos ocultado todo lo demás.

Para construir modelos no hace falta necesariamente recurrir a diagramas e imágenes, pero es definitivamente una forma popular de hacerlo. Además de los planos o diagramas como los que se ilustran en el ejemplo del Volkswagen, contamos con herramientas más propias de nuestra profesión, como el lenguaje de construcción de modelos UML.

De esta forma, cuando se trate de aplicaciones de software, lo más común será encontrar modelos construidos y presentados por medio del uso del UML, actividad para la cual contamos con una gran variedad de herramientas útiles disponibles hoy en día, tanto comerciales como libres.

2 comentarios

Definimos Terminos de Referencia como…

De tanto en tanto nos vamos a encontrar con que la organización que requiere el desarrollo elabora para nosotros un documento de requisitos, en formato libre, al que llaman no sin cierto orgullo “Términos de Referencia”. La práctica viene de otras áreas de la ingeniería donde una petición simple de parte del cliente puede ser analizada y convertida en un trabajo completo, con un razonable nivel de calidad.

Sin embargo, en Ingeniería del Software los términos de referencia no pueden ser utilizados con buenos resultados. Típicamente son documentos incompletos, que mezclan requisitos con análisis e incluso con diseño, cuya existencia es señal de acceso limitado a los stakeholders por parte de la organización de desarrollo. En otras palabras: si nos dan Términos de Referencia tendremos problemas más adelante.

El acto de especificar un sistema de software a demostrado repetidamente ser difícil. Es necesario indicar un gran número de aspectos distintos, mantener la diferencia entre requisito y solución, actuar primero a lo ancho, capturar valor de negocio, entre otros puntos que son propios de nuestra profesión y que resultan incompatibles con las premisas detrás de un documento de términos de referencia.

Veamos algunos de estos puntos en detalle. Comencemos por la definición:

Términos de Referencia: Documento elaborado por el cliente con indicaciones de las especificaciones requeridas al sistema de software por desarrollar.

En otras palabras: en un documento de Términos de Referencia el cliente ha querido ahorrarnos a nosotros el trabajo de especificación. Muy amable de su parte, pero si la organización de desarrollo no interviene en la especificación entonces nos enfrentamos a varios problemas:

  • Se ha asumido un modelo de ciclo de vida en cascada. Los modelos actuales son iterativos, repitiendo múltiples veces el paso de especificación. Un esquema más rígido, como el cascada, suele incrementar el riesgo de fracaso del proyecto.
  • Si el cliente siente que ya ha desarrollado los requisitos a satisfacción puede verse renuente a dedicar esfuerzos nuevos en este asunto. Tendríamos entonces problemas al presupuestar horas para actividades de elicitación de requisitos.
  • El documento en si mismo es un problema. Su estructura es necesariamente ad-hoc, independiente de la metodología que se vaya a seguir en el desarrollo. Puede ser difícil de analizar y haber dejado puntos importantes por fuera.

Si solo fuera para tener una idea del proyecto, básicamente cualquier documento o carta es bueno. Sin embargo los términos de referencia vienen con intenciones más amplias: sustituir la especificación profesional por un único documento, valido para el desarrollo así como para el cálculo de la oferta económica. No importa como lo vea, los términos de referencia son un problema.

Sin embargo, los Términos de Referencia son también un hecho. En algunas situaciones incluso son lógicos: en las licitaciones se distribuyen especificaciones para acto seguido requerir ofertas de costo cerrado. Si esto funciona bien en tantos sectores distintos, el cliente puede pensar que ha de valer también para sus proyectos de software.

Por lo anterior será inevitable que nos topemos con estos documentos. Tendremos que desarrollar entonces alguna técnica para sacar el mayor provecho de los mismos, sin importar cuan diferentes sean de caso en caso y de cliente en cliente. A fin de cuentas ellos son el cliente, y uno no puede ser tan descortez de desachar los resultados de su trabajo.

Finalmente me gustaría recordar que todos sin excepción hemos luchado con los términos de referencia de nuestros profesores y preparadores. ¿Cuantas veces en nuestros estudios tuvimos que llevar a cabo un proyecto a partir de un breve enunciado carente de toda norma de calidad? Así como entonces fue difícil producir un programa autenticamente útil a partir de dichas especifiones, aquí nos va a costar mucho trabajo en conseguir satisfacer el cliente si nos atenemos unicamente a lo dicho en los malvados, digo, en los variables Términos de Referencia.

, , , , , , , ,

3 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

Ejemplo de análisis de caso de uso

Si el análisis pone en descubierto las partes de aquello que se ha visto como un todo, entonces el análisis de casos de uso ha de poner en descubierto las instancias que intervienen en el sistema a la hora de realizar la funcionalidad descrita en dicho caso de uso.

Para efectos de la tarea análisis de caso de uso, en su versión con modelo de domino, dichas instancias van a pertenecer a alguna de las clases descritas en el modelo de dominio. El objetivo del análisis va a establecer los detalles de la relación que es necesaria que tengan estas clases para lograr la funcionalidad descrita en el caso de uso.

Tomemos el siguiente modelo de dominio para el sistema de subterráneo (Metro) de una ciudad cualquiera:

Fig. 1 – Diagrama de clases del modelo de dominio del sistema metro

Y complementemos con el siguiente modelo de casos de uso; asumiendo de momento que los casos de uso han sido descrito en detalle en algún documento apropiado.

Fig. 2 – Diagrama de casos de uso del sistema metro

Finalmente, tomemos el caso de uso Compra de Ticket para completar nuestro ejemplo:

Nombre: Compra de Ticket.
ID: N/A.
Actor: Usuario del Metro.
Descripción breve: El usuario del metro compra un boleto del sistema luego del pago de la cantidad apropiada.

Tabla 1 – Detalles del caso de uso: Compra de Ticket

Ya armados con todos estos detalles, nos podemos hacer la siguiente pregunta:

¿Qué clases del modelo de dominio intervienen en el caso de uso?

No existe una respuesta necesariamente correcta, queda a juicio del analista el tomar una u otra clase según su visión y particular enfoque del problema; en mi caso, he tomado las clases Usuario del Metro, Venta de Ticket, y Ticket.

Luego de identificar que conceptos de nuestro modelo de dominio intervienen en el caso de uso, necesario ahora indicar cuales son los mensajes que estas instancias deben intercambiar para completar la funcionalidad. Este intercambio lo presentamos en un diagrama de UML, típicamente un diagrama de secuencia.

Fig. 3 – Diagrama de secuencia con el escenario de análisis
del caso de uso: Compra de Ticket

El resultado de nuestro análisis ha sido una primera versión de los mensajes que han de intercambiar las instancias de las clases Usuario del Metro, Venta de Ticket y Ticket, para lograr la funcionalidad requerida en el caso de uso Compra de Ticket.

Hay que fijarse que el modelo de domino original tenía pocos o ningún atributo o método para sus clases. El resultado del análisis es que ahora estas clases han sido detalladas un poco más, indicando para algunas de ellas (las que intervienen en el los escenarios de análisis) cuales métodos son necesarios e incluso, el proposito de cada uno de estos.

Cuando se parte de un modelo de dominio, el análisis de caso de uso no hace más que enriquecer este modelo, detallando como he dicho ya, cuales métodos son necesarios que estén presentes. Al final, el análisis habrá completado un esbozo de un modelo del sistema; modelo este que ya habrá asumido todos los requisitos de nuestros clientes y presentará una relación de clases capaz de instanciar lo visto en el análisis.

Queda por supuesto más pasos antes de contar con un sistema listo para su uso; es necesario que realicemos la integración con las clases de análisis (si las hemos usado) así como llevar a cabo el diseño del sistema; es decir, aún no estamos listos para programar, pero si estamos listos para diseñar.

, , , , , , , ,

12 comentarios

Modelo de Dominio

Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física.

Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el análista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir.

El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterraneo de una ciudad cualquiera.

Fig. 1 – Ejemplo de Modelo de Dominio de un sistema de subterráneo

En este diagrama se ve que un Usuario del Metro tiene cero o más boletos, comprados estos en una maquina de Venta de Boletos; dicha maquina “crea” los boletos los cuales son consumidos en un viaje, el cual tiene una estación de origen y otra de destino. Finalmente se ve que una estación tiene una o más maquinas de venta así como empleados de limpieza, seguridad y operaciones.

Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cuanto detalle va a ser necesario y hasta donde llegar a modelar. El objetivo es capturar lo necesario para comprender donde va a funcionar el sistema que estamos diseñando y esto demanda una cantidad distinta de detalles cada vez.

El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.

En la aproximación llamada Desarrollo Guiado por Modelos al modelo de dominio se le conoce como Modelo Independiente del Computador o CIM, por sus siglas en inglés. El CIM es el que da inicio al proceso de desarrollo y ocupa el rol, tanto de modelo de requisitos como de modelo análisis.

Por otra parte, cuando se sigue una aproximación Centrada en Casos de Uso como RUP/UP, el modelo de dominio es utilizado como entrada en la tarea análisis de los casos de uso en la construcción de los llamados escenarios de análisis.

Es decir, y con esto quiero concluir, que el modelo de dominio ocupa un rol protagonico en el desarrollo moderno de software y constituye un artefacto que vale la pena tener en nuestros proyectos.

, , , , , , , , ,

29 comentarios

Tareas: Análisis de Caso de Uso

Entiendo por análisis la habilidad de ver partes en aquello que se ha visto como un todo, en concreto, el análisis de casos de uso ha de visualizar instancias de objetos por ahora de clase indeterminada, que por medio de su colaboración dan lugar a la funcionalidad especificada en el caso de uso.

A esto se le llama también Realización de Caso de Uso al nivel de Modelo de Análisis, un nombre largo que en verdad no sé a que se debe. El siguiente diagrama de UML muestra la relación de realización entre un caso de uso y su escenario de análisis.

Fig. 1 - Realización de Caso de Uso

Fig. 1 – Realización de Caso de Uso

Si contamos con un modelo de dominio bien hecho, el análisis de casos de uso puede ser realizado por medio de la identificación de cuales de las clases de aquel modelo que participan en el caso de uso, y presentar estas en un diagrama de interacción: ya sea de colaboración o más normalmente, de secuencia.

El siguiente diagrama SPEM muestra la estructura de esta tarea:

Fig. 2 – Diagrama SPEM de la Tarea Analizar Caso de Uso
(Versión con Modelo de Dominio)

Por otra parte, RUP nos sugiere una aproximación alternativa: utilizar las llamadas clases de análisis; que son clasificadores de UML estereotipados en tres tipos básicos: control, entidad e interfaz. Esta técnica no presupone la existencia de un modelo de dominio y aunque en su momento daré un ejemplo, no es la aproximación que considero mejor integrada con el resto del método.

El siguiente diagrama ilustra la estructura de la Tarea Encontrar Clases de Análisis, que es la variedad del Análisis de Caso de Uso que utiliza clases de análisis de RUP en lugar de un modelo de dominio.

Fig. 3 – Diagrama SPEM de la Tarea Encontrar Clases de Análisis
(Versión de Análisis de Caso de Uso sin Modelo de Dominio)

Dejando de lado la diferencia en el producto, quiero que se note que en el primer caso la entrada es un Caso de Uso y un Actor, por oposición al Modelo de Casos de Uso completo, que si es la entrada de la segunda aproximación.

Justamente lo anterior es lo que rescata la técnica de las clases de análisis a mis ojos; uno puede tomar no uno, sino varios casos de uso relacionados por algún concepto, y analizarlos en su conjunto; lo que nos lleva a conclusiones diferentes y útiles.

, , , , , , ,

2 comentarios

Tareas: Construir Modelo de Dominio

Llamamos Modelo de Dominio a la representación de los conceptos de importancia en el área de la aplicación, así como de las relaciones entre estos; en la forma de clases UML simplificadas.

Convencionalmente la construcción del Modelo de Dominio es responsabilidad del Analista de Sistema, quien ejecuta esta tarea con ayuda de la Visión del Sistema y del Glosario de Requisitos.

El siguiente diagrama ilustra la tarea:

Construcción del Modelo de Dominio
Fig. 1 – Diagrama SPEM de la Tarea Construcción del Modelo de Dominio

El Modelo de Dominio, cuando es correctamente construido, es una poderosa forma de análisis, llegando a ser tan expresivo y lleno de significado que incluso en algunos métodos de desarrollo llega a sustituir al propio Modelo de Requisitos.

Ejemplo de lo anterior es el novedoso Desarrollo Guiado por Modelos, donde se parte de un Modelo de Dominio para la construcción del sistema. Claro que en la jerga propia del método este modelo recibe un nombre distinto; un detalle que podemos pasar por alto por hoy.

Otro punto digno de mención es la ausencia del Modelo de Casos de Uso entre las entradas de la tarea de Construcción del Modelo de Domino. Lo cierto es que los requisitos funcionales claramente son algo a analizar, pero como todos los conceptos importantes mencionados en los casos de uso ya están contenidos en el Glosario del Sistema no hay mayor uso de estos aquí.

, , , , , , , ,

7 comentarios