Entre lo Estático y lo Dinámico: El papel del analista y del programador

Al escuchar la expresión “Programador Analista” es probable que se nos venga a la mente la idea de que es una persona que se encarga de automatizar soluciones a ciertas necesidades de información de una empresa.

Esto es cierto cuando el proyecto es muy simple y es para una tarea muy específica, por ejemplo, para hacer algún cálculo o para exportar cierta información, sin embargo, en proyectos de tamaño normal o grande, por lo general son varias personas las que participan, entre ellas, un programador (o varios) y un analista, es decir las actividades se reparten. En este artículo veremos cual es la función de ambos, principalmente desde un punto de vista inicial y crucial para un proyecto: El diseño.

El papel del analista desde el punto de vista del diseño

El analista se ocupa del sistema desde un punto de vista “estático”, es decir, se encarga de recabar los requerimientos y darle forma a los cimientos y estructura del sistema. Así mismo se preocupa de que las reglas de negocio se cumplan y sean soportadas por la estructura.

El papel del programador desde el punto de vista del diseño

El programador se ocupa del sistema desde un punto de vista “dinámico”, es decir, se preocupa por como los objetos de negocio van a interactuar entre si para la lograr la funcionalidad requerida del sistema dentro de la estructura y reglas de negocio que el analista estableció desde un principio. Podríamos decir que el programador interactúa con los objetos cuando estos ya tienen vida, por lo que normalmente veremos una instancia de objeto, en los diagramas del Programador: Objeto: Clase.

Herramientas de modelado

Para lograr sus objetivos, tanto el analista como el programador deben de hacer uso de técnicas de modelado, una de las técnicas mas comunes es UML. El Lenguaje Unificado de Modelado es un lenguaje estándar para escribir planos de software y permite visualizar, especificar, construir y documentar los artefactos de un sistema.

UML se compone de diversos tipos de diagramas y es aquí donde es fácil confundirse y perderse entre todos los tipos de diagramas y modelos que UML ofrece y preguntarse ¿Cuál es mi papel dentro del sistema? ¿Qué tipo de diagramas debo de hacer? ¿Debo de usar todos los diagramas UML? ¿Como programador, debo diagramar o puedo simplemente empezar a programar basado en los casos de uso? La respuesta a todas estas preguntas es que el analista debe hacer ciertos diagramas y el programador debe de hacer otros tipos de diagramas.

Los diagramas y modelos del analista

Debido a que el analista ve al sistema desde un punto de vista estático, debe de hacer uso de aquellos diagramas que le permitan establecer los cimientos y la estructura del sistema, por lo que los diagramas UML que le servirán para lograr este objetivo son:

• Diagrama de Casos de Uso. Es un diagrama de comportamiento que muestra como se relacionan los casos de uso con los actores del sistema.
• Detalle de Casos de Uso. Es la descripción de las actividades que debe realizar un caso de uso. Este es quizás el elemento más importante del que hace uso el analista ya que es aquí donde describe en detalle como debe de funcionar el sistema y es el documento en el que se basara el programador.
• Diagrama Entidad Relación (Diseño Lógico). Es el diagrama de bases de datos que contiene las entidades y las relaciones entre estas.
• Diagrama de Actividades. Es un diagrama de comportamiento que muestra el flujo existente en un conjunto de actividades. También el programador puede usar un diagrama de actividades para aclarar un control de flujo en su codificación.
• Diagrama de Despliegue. Es un diagrama estructural que muestra las relaciones entre conjuntos de nodos, artefactos, componentes, etc. Un ejemplo de diagrama de Despliegue es la Arquitectura Cliente-Servidor. El analista es el que debe decidir qué tecnología se va a usar, si el sistema será Web o local, si utilizará la red para transferencia de datos o utilizara archivos planos, etc.

Figura 1. Ejemplo de diagrama de casos de uso

Los diagramas y modelos del programador

En cuanto al programador, debido a que ve al sistema desde un punto de vista dinámico, debe de hacer uso de aquellos diagramas que le permitan observar cómo los objetos se relacionan entre si. Los diagramas UML que el programador podría usar son:

• Diagrama Entidad Relación (Diseño Físico). Es el diagrama de bases de datos que contiene las tablas, las relaciones entre estas, tipos de datos, llaves primarias, etc.
• Tarjetas CRC. Son una extensión informal de UML y permiten definir responsabilidades dentro de un flujo de eventos. Son muy útiles para diseñar interfaces de usuario.
• Diagrama de clases. Es un diagrama estructural que muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones. Las clases son entidades que contienen objetos conocidos como propiedades y métodos. Las clases son fundamentales para la programación orientada a objetos y se basan en las entidades existentes del negocio.
• Diagrama de paquetes. Es un diagrama estructural de agrupación que muestra la organización del modelo en paquetes (Lo que en .Net se conoce como Namespaces para organizar las clases). Sin embargo los paquetes también pueden encapsular otras entidades, como por ejemplo Casos de Uso.
• Diagrama de objetos (o de instancias). Representa a un conjunto de objetos y sus relaciones en un momento concreto. Como decíamos anteriormente, el programador convive directamente con los objetos cuando estos ya tienen vida, por lo que este tipo de diagrama le será muy útil.
• Modelado de artefactos. Los artefactos en UML son librerías (dll), archivos ejecutables (exe), archivos de código fuente, archivos de datos. El modelado de artefactos permite plasmar la relación que hay entre estos objetos dentro de un proyecto.
• Diagramas de secuencia. Muestra los objetos que intervienen en el escenario con líneas discontinuas verticales y los mensajes pasados entre los objetos como vectores horizontales. Muy útil cuando los objetos de varias clases tienen que interactuar entre sí.
• Modelado de colaboraciones. Es una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento.
• Modelado de interfaces y componentes.Un componente es una parte lógica y reemplazable de un sistema que conforma y proporciona la implementación de un conjunto de interfaces. Una interfaz es una colección de operaciones que sirven para especificar un servicio de una clase o un componente. Esto permite establecer una frontera entre aquellas partes del sistema que pueden cambiar y las que no. Cuando participan varios programadores en un proyecto, las interfaces permiten establecer un punto de partida y obligarlos a utilizar los nombres de los objetos para evitar confusiones.
• Máquinas de Estados. Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos.
• Patrones y Frameworks. Un framework es una microarquitectura que incluye un conjunto de mecanismos que colaboran para resolver un problema en común. Por ejemplo, cuando se desarrolla un framework para conexión a bases de datos y que contiene todo lo necesario para solicitar datos en conjunto, para ejecutar como comandos como Delete, Update, Insert, etc. Este framework, al ser genérico, podrá ser utilizado en cualquier otra aplicación. Al ser utilizado en varios proyectos, es entonces cuando el framework se convierte en un patrón, es decir, se convierte en una solución común a un problema común: la conexión a bases de datos.

Figura 2. Ejemplo de diagrama de objetos.
 

Figura 3. Ejemplo de diagrama de secuencia

Desmitificando el papel del analista con respecto a los diagramas

Es curioso darse cuenta al revisar toda esta información de que, el que tiene un abanico más amplio de diagramas y modelos por realizar es el programador y no el analista como podría pensarse. Esto es debido a que el programador trabaja con los objetos cuando estos ya tienen vida, y modelar le permitirá visualizar cómo deben comportarse los objetos antes de codificarlos.

Precauciones al utilizar UML

UML es un lenguaje de modelado muy poderoso que si no se usa correctamente puede inclusive ser contraproducente. Se debe de tener bien claro qué diagramas deben de hacerse y cuales pueden omitirse, y quién los debe hacer. Tomemos en cuenta que hacer diagramas es una tarea que lleva mucho tiempo, por lo que se recomienda usarlos con discreción (con excepción de los diagramas del analista que son fundamentales, no así los del programador).

Mientras que los diagramas del analista tienen por objetivo establecer los cimientos del sistema, los diagramas del programador tienen por objetivo ayudarle a el a comprender cómo deben de interrelacionarse los objetos de negocio para lograr la funcionalidad deseada, por lo que si el programador tiene claro ciertas partes del proyecto, no será necesario que diagrame todos y cada uno de los aspectos de este. UML debe de servir al programador y no el programador a UML.

La relación entre el analista y el programador

Se recomienda ampliamente a las empresas que en sus proyectos de tamaño mediano o grande, no escatimen en recursos y tengan a un analista y un programador (o varios), ya que en el transcurso del desarrollo del proyecto surge una relación muy interesante entre ambos, dando como consecuencia una retroalimentación completa. En cambio si una sola persona esta a cargo de todo, podría perder la objetividad y creer que esta haciendo las cosas bien cuando en realidad puede ser que no sea así.

Por ejemplo cuando el analista le pide al programador desarrollar algo, este al intentar implementarlo podría darse cuenta de que el requerimiento no es factible o que esta incompleto. De hecho, lo mas común es que el programador (que es el que realmente lucha con la aplicación cara a cara) le haga observaciones al analista, este corrige, y le vuelve a pedir el requerimiento, hasta que el programador se da cuenta de que lo que se esta pidiendo esta correcto y es factible implementarlo. Este patrón se repite durante todo el proyecto.

También es común que el analista al revisar lo que el hizo el programador, se de cuenta de que a pesar de estar bien programado, no esta del todo correcto lo que le solicito, y tendrá que regresar a su escritorio a replantear algunas cosas, y darle nuevamente los ajustes al programador.

Conclusión

El modelado es muy importante en el diseño de un sistema para no terminar construyendo una mesa de ping pong cuando en realidad se quería construir una mesa de billar. Sin embargo, los modelos deben de hacerse en base a los objetivos que persigue cada participante en el desarrollo.

Referencias:
[1] G. Booch, J. Rumbaugh & I. Jacobson. El Lenguaje Unificado de Modelado, 2 ed. Addison Wesley, 2006.
[2] J. Gorman. “UML For .Net Developers”. http://parlezuml.com