Gazafatonario IT

2008-05-20T23:54:00.000-05:00

Lectura Fundamental 12

Lectura Fundamental Anterior: “Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)”

Lectura # 12

Casos de Uso: de Extensiones y de Inclusiones

“El hombre vive fascinado por la inmensidad de la eternidad y nos preguntamos: ¿Nuestras acciones perdurarán a través de los siglos? ¿Gente que no conocemos oirá nuestros nombres mucho después de nuestra muerte? ¿Y se preguntarán quiénes éramos, cuán valientemente peleábamos, cuán ferozmente amábamos?”

Wolfgang Petersen (Troya, 2004)

Introducción

De vuelta en el tiempo, hace unas siete Lecturas Fundamentales, prometí hablar de las relaciones entre los casos de uso. Pues bien, he querido extender el tema hacía el no menos complejo asunto de modelar sistemas de información mediante casos de uso. Trataré de mantener una posición minimalista: abordaré sólo la cuestión relacionada con el diagrama de casos de uso.

Básicamente, un diagrama de casos de casos de uso está compuesto de Actores y Casos de Uso, y las relaciones entre los unos, entre los otros y entre los unos y los otros.

Para recordar qué es un Actor podemos leer la Definición 5 en [3]. Para recapitular sobre Casos de Uso, podemos leer esencialmente [4] y luego repasar [5], [6], [7] y [3]. Ya sabemos además que podemos usar UML [8] para especificar, visualizar, construir y documentar los artefactos de sistemas de software.

Generalización de Actores

Dos o más Actores se relacionan entre ellos mediante la Generalización (de actores). Esta relación significa que uno o más actores pueden heredar las características, pero mejor aún, las responsabilidades de otro actor del sistema. Un Vendedor de Licencias de Software y un Vendedor de Servicios de Ingeniería tienen al menos una responsabilidad en común, una actividad: Registrar Cliente. Si los roles se interceptan en dos o más actividades en el sistema, es posible entonces, por razones de organización del modelo, de abstracción y de simplicidad, crear un nuevo actor: Vendedor de Productos y Servicios. Este parentesco se diagrama como muestro en la figura 1.

Además, muchas veces enfrentamos el dilema en el que un caso de uso (del sistema) es ejecutado por dos o más actores. Como en un sistema de Administración de Proyectos, donde el Gerente de Proyectos puede Matricular un Proyecto, pero también lo puede hacer el Gerente de la Oficina de Proyectos. Una mala idea es expresar esta situación como lo hago aparecer en la figura 2.

Figura 1: Diagrama parcial de Actores de un Sistema CRM

En cambio, usamos la generalización, creando un actor que desde el punto de vista del negocio y del usuario es Abstracto: el Administrador de Proyectos. Entonces, el diagrama se convierte en algo como lo que sugiero en la figura 3.

Figura 2: Diagrama Incorrecto de Casos de Uso de un Sistema de Administración de Proyectos

Figura 3: Diagrama Correcto de Casos de Uso de un Sistema de Administración de Proyectos

Quizás lo que sucede en estos casos es que confundimos Actores del Negocio [3] con Actores del Sistema o, simplemente, cargos o roles de la organización para la cual se construye la aplicación con roles o responsabilidades en el sistema de las personas que ejercen esas funciones. Ese no es el camino.

Por último, tengamos en cuenta el sentido de la generalización de actores: los casos de uso ejecutados por el actor padre son en la práctica ejecutados por los hijos.

Relaciones Entre Actores y Casos de Uso

Un Actor se comunica con casos de uso, componentes y clases [9]. Esta comunicación se representa mediante la relación de Asociación (binaria). En Particular, nos interesa la relación entre el actor y el caso de uso. Esta relación muestra el actor que inicia o ejecuta el caso de uso, normalmente una persona o un grupo de personas, pero también cualquier entidad externa al sistema, como otra aplicación o maquinaria especial.

Las figuras 3, 4, 5 y 6 son muestras de relaciones de asociación típicas entre actores y casos de uso.

En estos diagramas, la constante es que la relación es en ambos sentidos, es decir, es una relación de toma y dame, el actor hace-el sistema hace. Pero también se presentan casos donde la asociación es en un solo sentido, o hacia el caso de uso o hacia el actor. Estas situaciones son comunes cuando el actor no es una persona, sino un software externo o una máquina. Como en la figura 4, donde al ejecutarse la funcionalidad de registrar un cliente que es persona natural, el sistema CRM le comunica al sistema contable que matricule un tercero.

En este diagrama, la funcionalidad que va al sistema externo se representa como un caso de uso “incluido”, una relación de la que hablaré en breve. Pero en la práctica, la comunicación puede ir directamente del caso de uso principal al sistema externo.

Figura 4: Diagrama Parcial de Casos de Uso donde interviene un sistema externo

Casos en los que un actor se relaciona con una clase o un componente se presentan cuando el actor es un sistema externo que envía o recibe datos del sistema principal o, cuando siendo persona, el actor se comunica con el sistema vía una página Web, por ejemplo, que se representa como una clase en la aplicación. Este último caso se presenta en los diagramas de Interacción, como los de Secuencia [10] o de Comunicación.

Relaciones Entre Casos de Uso

Este es la materia que genera más polémica y la que es menos entendida en la comunidad de la IT, así es que trataré de ir más despacio.

Dos o más casos de uso se pueden relacionar entre ellos para distintos propósitos: distribuir mejor el modelo, establecer condiciones de reusabilidad (de funcionalidad), de incrementos del software, y para planear las iteraciones, entre otros. Las relaciones son de tres tipos: Inclusión, Extensión y Generalización. Enfatizaré en las dos primeras.

Relación de Inclusión

Una relación de inclusión define que un caso de uso contiene el comportamiento definido en otro caso de uso [11].

Una relación de inclusión es una relación de un caso de uso base a un caso de uso incluido en la que se especifica como el comportamiento definido en el caso de uso incluido es explícitamente insertado en el comportamiento del caso de uso base [1]. Decimos entonces que el caso de uso incluido es abstracto, es decir, no es ejecutado directamente por un actor.

Esta relación se usa cuando queremos:

Factorizar o descomponer (en sentido matemático) el comportamiento del caso de uso base que no es necesario para entender el objetivo principal del mismo y donde solamente el resultado del caso de uso incluido es importante.
Distribuir en uno o más casos de uso, funcionalidad del caso de uso base que es común para dos o más casos de uso (reusabilidad).

La primera opción se usa especialmente en casos de uso largos o complejos donde algunas partes del mismo no son relevantes para el sentido primordial del caso de uso y no son necesarias, en primera instancia, para entenderlo y aprobarlo. Por ejemplo, un caso de uso para Ingresar un Cliente de Naturaleza Jurídica puede solicitar docenas o cientos de datos que se pueden agrupar de acuerdo a algunos criterios como Datos Generales, Datos del Tipo de Entidad y Naturaleza Jurídica, Datos del Gerente o Representante Legal, Datos de los Contactos, Referencias Comerciales, entre otros. Algunos de estos grupos de datos pueden incluirse en casos de uso complementarios que son ejecutados desde el caso de uso principal que podría lucir así:

Caso de Uso: Registrar Cliente Jurídico

Actor: Vendedor de Productos y Servicios

Descripción: este caso de uso permite registrar los datos de una persona de naturaleza jurídica…

Secuencia Básica:

1. El caso de uso inicia cuando el Actor decide registrar los datos de una persona jurídica

2. El sistema pide seleccionar la ciudad y oficina de vinculación

3. El actor selecciona la ciudad y oficina de vinculación

4. …

…

12. Se ejecuta el caso de uso Registrar Datos del Tipo de Entidad y Naturaleza Jurídica

13. Se ejecuta el caso de uso Registrar Datos del Gerente o Representante Legal

14. Se ejecuta el caso de uso Registrar Datos de las Referencias Comerciales

15….

…

25. El caso de uso termina

Poscondiciones: N/A

Requisitos Especiales: N/A

En este ejemplo, en los pasos 12 a 14 se ejecutan distintos casos de uso de los que, en principio, interesa el resultado. La palabra clave es “en principio”. En este diagrama también muestro la segunda posibilidad de inclusión, el reuso, con el caso de uso Verificar Centrales de Riesgo, que se ejecuta desde varios casos de uso del modelo.

Algunos aspectos de los casos de uso incluidos que debemos tener en cuenta:

Un caso de uso incluido no contiene una funcionalidad significante para la arquitectura del sistema, especialmente para la vista funcional o de casos de uso.
Un caso de uso incluido se puede “prototipar” en las primeras de cambio, es decir, durante el análisis y el diseño del mismo, el diseñador se puede concentrar en el caso de uso base y omitir los detalles particulares del caso de uso incluido.

Figura 5: Diagrama parcial del caso de uso Registrar Cliente Jurídico

Un caso de uso incluido no debe usarse como excusa para hacer descomposición funcional [4], es decir, tener uno o más casos de uso incluidos que especifiquen aspectos CLAB (creación, lectura, actualización o borrado –CRUD en inglés) o que estén vinculados a usuarios concretos específicos, o completamente ligados a un componente del sistema o a un componente arquitectónico específico, o vinculados a una pantalla o función de usuario determinada, o en algún paso de su secuencia ejecutan otros casos de uso incluidos (asunto este que debería evitarse tanto como se pueda). Para saber más de casos de uso funcionalmente descompuestos ver Definición 3 en [4].
Un caso de uso incluido está incompleto por naturaleza, es decir, por sí solo no arroja un resultado observable para el actor, o es un resultado parcial, o sus escenarios dependen de lo que ha pasado antes en el caso de uso principal.
Un caso de uso incluido no es ejecutado por un actor distinto al actor del caso de uso base. Sin embargo, un caso de uso incluido puede tener asociado un actor pasivo o secundario, normalmente cuando este actor recibe o entrega información al caso de uso incluido, como anotaba en la figura 4.
Un caso de uso incluido no se usa para especificar procesos automáticos o semi-automáticos que el sistema realiza en su totalidad sin interacción con el usuario.
Un caso de uso incluido siempre se implementa con el caso de uso base o antes, si se trata de un caso de uso que expone funcionalidad común. En otras palabras, el caso de uso incluido se implementa durante la misma iteración en que se implementa el primero caso de uso principal que lo incluya.
Un caso de uso incluido no es condicional, es decir, si el ejecutar el caso de uso base se alcanza el paso donde se ejecuta el caso de uso incluido, éste se ejecuta. Por supuesto, la ejecución de la funcionalidad incluida puede depender de si se cumple una condición o no en el caso de uso base, pero esta condición debe especificarse explícitamente en el caso de uso principal, como apunto en el paso 12 del ejemplo siguiente:

Caso de Uso: Registrar Cliente Natural

Actor: Vendedor de Productos y Servicios

Descripción: este caso de uso permite registrar los datos de una persona natural.

Secuencia Básica:

5. El caso de uso inicia cuando el Actor decide registrar los datos de una persona natural

6. El sistema pide seleccionar la ciudad y oficina de vinculación

7. El actor selecciona la ciudad y oficina de vinculación

8. El sistema solicita el nombre de la persona

9. El actor ingresa el nombre de la persona

10. El sistema pide seleccionar la profesión de la persona

11. El actor selecciona la profesión de la persona

12. Si la profesión es “Congresista” se ejecuta el caso de uso Verificar Lista Clinton.

13. …

14. Se ejecuta el caso de uso Registrar Datos de las Referencias Comerciales

15….

…

25. El caso de uso termina

Poscondiciones: N/A

Requisitos Especiales: N/A

Un caso de uso incluido debería incluir, en su documentación, una sección que describa explícitamente los casos de uso base desde los cuales es incluido. Este simple ejercicio hace al documento tan auto-suficiente o auto-contenido como sea posible, es decir, los interesados en el artefacto no tendrán que navegar por ningún otro lado para conocer todo el detalle del caso de uso.
En un caso de uso incluido, las precondiciones siempre se han cumplido en el caso de uso base que lo incluye. Entre tanto, las poscondiciones del caso de uso incluido afectan el comportamiento del resto del caso de uso base.
Finalmente, un caso de uso incluido no debería tener relaciones de extensión con otros casos de uso. Simplemente no tiene sentido.

Pasemos precisamente a la trama de las extensiones.

Relación de Extensión

La Extensión es una relación de un caso de uso de extensión a un caso de uso extendido que especifica como y cuando el comportamiento definido en el caso de uso de extensión puede ser insertado en el comportamiento definido en el caso de uso extendido [12].

Esta relación se usa:

Para establecer que un fragmento de la funcionalidad del caso de uso es opcional, o potencialmente opcional. A diferencia de lo que ocurre con la inclusión que es una relación que implica obligatoriedad en la ejecución, por decirlo de cierta manera.
Para señalar una parte del comportamiento que es ejecutado sólo bajo ciertas circunstancias, a veces excepcionales, tales como el envío de un mensaje a un usuario cuando se produce un hecho determinado. Por ejemplo, cuando un cliente VIP solicita el aumento de un cupo de crédito y la cantidad solicitada sobrepasa la política de crédito que puede soportar al Analista de Crédito, entonces el proceso pasa a una instancia mayor, como un Gerente de Oficina o algo así. Decimos entonces que ha ocurrido una interrupción en el caso de uso. A este dilema nos enfrentamos continuamente y la primera intención de un Ingeniero de Requisitos inexperto es crear un único caso de uso con dos actores. Ahora ya sabemos que realmente son dos parejas actor-caso de uso.
Para mostrar que puede haber un conjunto de segmentos de comportamiento de los cuales uno o varios de estos pueden ser insertados en un punto de extensión en un caso de uso base o extendido. Estas secciones insertadas (y el orden en el cual son insertadas) dependerán de la interacción con los actores durante la ejecución del caso de uso base.

La extensión es condicional, lo que significa que su ejecución depende de lo que ha pasado mientras se ejecuta el caso de uso base. Éste no controla las condiciones para la ejecución de la extensión –las condiciones son descritas dentro la relación de extensión. El caso de uso de extensión puede acceder y modificar los atributos del caso de uso base. Éste, sin embargo, no puede ver las extensiones y no puede acceder a sus atributos.

Una diferencia fundamental con la inclusión es que, en la extensión, el caso de uso base está completo por sí mismo, es decir, que debería entenderse y tener significado completo sin ninguna referencia a sus extensiones. Sin embargo, el caso de uso base no es independiente de las extensiones, puesto que no puede ser ejecutado sin la posibilidad de seguir las extensiones [2]. También pasa que el caso de uso de extensión puede acceder y modificar los atributos del caso de uso base, pero éste no puede ver las extensiones y no puede acceder a sus atributos. Y más, el caso de uso base se modifica implícitamente por las extensiones. En otras palabras, el caso de uso extendido (base) es ciego a sus extensiones específicas, pero no al contrario.

Un poco truculento, pero así es. La figura 6 es una muestra típica de extensión de casos de uso.

Otra gran diferencia entre la inclusión y la extensión es que el caso de uso de extensión puede ser ejecutado por un actor distinto al caso de uso base, como observamos en el diagrama. Observamos también la condición que activa la extensión en cada caso: en una de ellas se trata de un crédito de mayor cuantía, donde la mayor cuantía es un atributo que puede y debería ser configurable; mientras que en el segundo caso se trata de un cliente del sector gubernamental o bien podría ser algún otro tipo de cliente con tratamiento especial.

Figura 6: Diagrama parcial del caso de uso Aprobar Solicitud de Crédito

Y más de la cuestión semántica, las extensiones de un caso de uso son suplementarias, lo que quiere decir, que el caso de uso extendido está completo, es un todo. En el ejemplo de la figura 6, Aprobar Solicitud de Crédito es un caso de uso terminado por sí mismo y bien podría ser implementado en una iteración distinta (previa) y hasta en un proyecto diferente a la iteración o proyecto donde se implementan los otros casos de uso. Esta es otra de las razones por las que se usa la extensión.

Y estos son algunos aspectos de los casos de uso extendidos y de extensión que debemos tener en cuenta a la hora de modelar sistemas de información:

Un caso de uso extendido y sus casos de uso de extensión sí entregan un resultado de valor observable para el actor que los ejecuta, ya sea a través de ellos mismos o transfiriéndolo de la extensión al extendido y de allí al actor.
Un caso de uso de extensión no es una especialización del caso de uso extendido, es decir, la extensión no es una relación de herencia o de generalización, dependiendo desde el ángulo del cual miremos. Hago énfasis en este aspecto porque tengo la ligera impresión de que, no sólo los analistas noveles, sino también los diseñadores y los programadores estamos entrenamos para ver la extensión como una especialización, cuando en realidad no es así.
Quizás es por eso que la OMG tomó la decisión de cambiar la definición formal de la extensión para que sea una relación de dependencia. Aunque quiero aprovechar este punto para decir también que esta situación se desprende de la estructura formal de UML, la así llamada Especificación de Infraestructura de UML [13], algo que nos ha complicado la vida de muchas formas, sin embargo, esta definición formal muchas veces es irrelevante en la vida real, quiero decir, no es práctica en la mayoría de los modelos que construimos.
Un caso de uso se puede usar para documentar nuevas versiones del caso de uso original. Este es un gran beneficio de la extensión, porque deja intacto el caso de uso original que posiblemente ya está implementado y hasta en producción y permite que el analista de requisitos se concentre con los usuarios en las nuevas características del caso de uso extendido.

Aquí nos enfrentamos a la disyuntiva de extender o no extender un caso de uso. Me refiero a que si el cambio es pequeño, posiblemente sea más útil y práctico especificar una secuencia alterna en el caso de uso base; si la modificación es substancial, a juicio del analista, éste tomará la sabia decisión de crear un nuevo caso de uso.

Ahora bien, un caso de uso extendido luce más o menos así:

Caso de Uso: Aprobar Solicitud de Crédito

Actor: Analista de Crédito

Descripción: este caso de uso permite aprobar una solicitud de crédito realizada por un cliente…

Secuencia Básica:

1. El caso de uso inicia cuando el Actor decide aprobar una solicitud de crédito

2. El sistema solicita el radicado y la fecha de de la solicitud

3. El actor ingresa el radicado y la fecha de de la solicitud

4. El sistema valida que el radicado exista para la fecha establecida y muestra los datos de la solicitud: nombre o razón social del cliente, número de identificación y tipo de la misma, dirección, ciudad, …, sector del cliente, cantidad solicitada, …

5. El sistema pide seleccionar el tipo de desembolso (Cheque, Consignación, Efectivo)

6. El actor selecciona el tipo de desembolso

7. El sistema solicita el número de aprobación de la solicitud

8. …

…

25. El caso de uso termina

Poscondiciones: N/A

Puntos de Extensión

5A. La cantidad solicitada es de Mayor Cuantía

7A. El cliente es del sector Gobierno

Requisitos Especiales: N/A

Lo único distinto son los puntos de extensión. Observen que la secuencia básica del caso de uso, ni ninguna otra secuencia, hace alusión a uno o más casos de uso de extensión. Es lo que había dicho: el caso de uso base no conoce los atributos ni las características del caso de uso de extensión.

Por su parte un caso de uso de extensión, se diferencia de un caso de uso normal en que debe tener especificado el evento que lo activa (llamado comúnmente trigger). Por ejemplo, en la figura 7, Asignar Revisión de Arquitectura es considerada una actividad especial por el sistema de Administración de Proyectos:

Figura 7: Diagrama parcial de casos de usos de un Sistema de Administración de Proyectos

Este caso de uso, que extiende a Asignar Actividad, podría lucir más o menos así:

Caso de Uso: Asignar Revisión de Arquitectura

Actor: Gerente de Oficina de Proyectos

Descripción: este caso de uso permite al PMO asignar la revisión de una arquitectura de software…

Evento de Activación: la actividad es una actividad especial: Revisión de Arquitectura

Secuencia Básica:

1. El caso de uso inicia cuando el Actor decide asignar una revisión de arquitectura

2. El sistema pide seleccionar el revisor técnico

3. El actor selecciona el revisor técnico

4. El sistema verifica que el revisor técnico tenga el perfil requerido para la actividad

5. El actor …

6. …

…

12. El caso de uso termina

Poscondiciones: N/A

Requisitos Especiales: N/A

La figura 7 también dilucida sobre otro aspecto de las relaciones entre casos de uso: un caso de uso base puede estar asociado con uno o más casos de uso incluidos y con uno o más casos de uso extendidos.

Otro aspecto importante de las relaciones de extensión es que el diagrama es bastante explicativo. En la figura 8, por ejemplo, está claro que un vuelo cualquiera puede ser reservado por un pasajero cualquiera, pero que si el pasajero está registrado como frecuente, la reserva tiene algunas características especiales (estas particularidades no se pueden observar en un diagrama de casos de uso como este).

El diagrama 8 también muestra otro aspecto de las relaciones de extensión y es que un caso de uso de extensión puede ser a su vez extendido por uno o más casos de uso de extensión. Y este hecho profundiza más en el proceso del negocio que resuelve este modelo: si el vuelo es internacional, y el pasajero frecuente además está registrado como pasajero VIP, tiene la opción de establecer o seleccionar el menú que consumirá durante el vuelo.

Figura 8: Diagrama parcial de casos de usos de un Sistema de Reservación de Vuelos

Del diagrama no se pude extraer información sobre las distintas clases de vuelo que proporciona la aerolínea. Sin embargo, este es precisamente el objeto del siguiente apartado: la clasificación de casos de uso, en el sentido de generalización, llamada también herencia de casos de uso.

Generalización Entre Casos de Uso

Una generalización es una relación taxonómica entre un clasificador más general y un clasificador más específico. Cada instancia del clasificador específico también es una instancia indirecta del clasificador general. Así, el clasificador específico hereda las características del clasificador más general [14].

Esta relación es ampliamente usada en el modelado orientado a objetos, sin embargo, no solo se da entre clases y objetos, sino entre cualquier elemento de UML que actúe como clasificador, como los casos de uso.

La generalización de casos de uso se usa cuando dos o más casos de uso comparten comportamiento, estructura y propósito. Es decir, si dos casos de uso ejecutan un conjunto amplio de actividades similares y sólo algunas diferentes, es posible tomar todas las tareas comunes y especificarlas en un nuevo caso de uso que generaliza a los dos anteriores y en estos dos sólo se especifican las tareas disímiles. Esa es la primera premisa para usar la relación de generalización entre casos de uso, como en la figura 9, donde es posible que Reservar Vuelo Doméstico y Reservar Vuelo Internacional sólo difieran en que para este último caso el actor pueda seleccionar la ruta y especificar algunas condiciones especiales de vuelo.

Figura 9: Diagrama parcial de casos de usos de un Sistema de Reservación de Vuelos

El caso de uso Reservar Vuelo Doméstico puede especificarse de la siguiente manera:

Caso de Uso: Reservar Vuelo Doméstico

Actor: Pasajero

Descripción: este caso de uso permite a un pasajero reservar un vuelo entre dos ciudades nacionales…

Secuencia Básica:

1. El caso de uso inicia cuando el Actor decide reservar un vuelo doméstico

2. El sistema pide seleccionar las ciudades origen y destino del vuelo

3. El actor selecciona las ciudades origen y destino del vuelo

4. El sistema solicita las fechas de ida y de regreso del vuelo

5. El sistema valida la existencia de vuelos con las condiciones establecidas y pide seleccionar la tarifa

6. El actor selecciona la tarifa

7. El sistema genera y muestra un código de reserva y el caso de uso termina

Poscondiciones: N/A

Entre tanto, el caso de uso Reservar Vuelo Internacional puede ir así:

Caso de Uso: Reservar Vuelo Internacional

Actor: Pasajero

Descripción: este caso de uso permite a un pasajero reservar un vuelo cuya ciudad destino es de otro país…

Secuencia Básica:

1. El caso de uso inicia cuando el Actor decide reservar un vuelo internacional

2. El sistema pide seleccionar las ciudades origen y destino del vuelo

3. El actor selecciona las ciudades origen y destino del vuelo

4. El sistema solicita las fechas de ida y de regreso del vuelo

5. El sistema valida la existencia de vuelos con las condiciones establecidas, muestra las rutas disponibles (escalas intermedias) y pide seleccionar la ruta y tarifa de preferencia

6. El actor selecciona la ruta y la tarifa de su preferencia

7. El sistema pide seleccionar las condiciones especiales del vuelo

8. El sistema genera y muestra un código de reserva y el caso de uso termina

Poscondiciones: N/A

Requisitos Especiales: N/A

La diferencia entre uno y otro se nota en los pasos 5, 6 y 7. En este caso, el caso de uso padre, Reservar Vuelo puede contener exactamente la misma funcionalidad que Reservar Vuelo Doméstico y dejar sólo los pasos distintos en Reservar Vuelo Internacional. De esta manera se simplifica la especificación y el modelado del sistema.

También puede ocurrir que sea necesario agrupar dos o más casos de uso cuya funcionalidad, estructura y objetivo sean compartidos en un caso de uso puramente abstracto, también para efectos de simplificación del modelo. Como en la figura 10.

Figura 10: Diagrama parcial de casos de usos de un Sistema de Administración de Proyectos

Aquí, el caso de uso abstracto no contiene ninguna especificación funcional y se usa como “comodín”, quizás para relacionar los casos de uso hijos con uno o más casos de uso incluidos o de extensión. También para hacer el análisis y diseño de todos ellos al mismo tiempo (hacer una única realización de casos de uso, por ejemplo).

Aunque no está especificado, los casos de uso hijos pueden ser ejecutados por actores diferentes. También, si el caso de uso padre es abstracto, podría no tener actor relacionado. En esta última instancia, los hijos deberían tener asociado el actor que los ejecuta, necesariamente.

Mi recomendación final es que usemos la generalización de casos de uso como detallo en esta última alternativa. Para la primera forma, siempre podemos usar inclusión y hasta extensión.

Conclusiones

Un modelo es una abstracción de la realidad, una representación simplificada de algunos fenómenos del mundo real. En materia de sistemas de software, esos fenómenos se refieren a requisitos del software y la representación de los mismos se hace mediante actores, casos de uso y las relaciones entre aquellos y estos y entre cada uno de ellos.

La asociación, la generalización, la inclusión y la extensión son los cuatro tipos de relaciones entre estos elementos de los sistemas de información. Algunas de ellas se quedan en un plano estrictamente teórico o conceptual, en el sentido de que no tienen aplicación práctica, al menos, no una de valor para el modelador. Me refiero a la generalización que en lo que a casos de uso se refiere no tiene el sentido de provecho que tiene, por ejemplo, en un diagrama de clases o uno de objetos.

La asociación, por su parte, es la relación natural entre actores y casos de uso, su significado es directo y simple: este actor ejecuta o inicia este caso de uso. También, este actor entrega o recibe información de (interactúa con) este caso de uso. Más allá, la inclusión y la extensión constituyen un par de relaciones que despiertan emociones encontradas en la comunidad de analistas, ya sea porque tendemos a confundir su uso o porque nuestros paradigmas mentales (específicamente los de la orientación a objetos) no nos permiten verlas y usarlas con claridad expedita.

Estos son los temas que he tratado de dilucidar en este artículo. Son aspectos en los que todos debemos mejorar en aras de incrementar la calidad de los productos que desarrollamos.

¿Quiere Saber Más?

Para conocer más sobre especificación de casos de uso, podemos consultar [15] que sigue siendo, sino el mejor, uno de los muy buenos libros sobre el espinoso asunto de escribir casos de uso.

Para conocer más de modelado de casos de uso, relaciones de inclusión, extensión y generalización, podemos consultar [16], [17] y [18] cuyos autores concentran sus esfuerzos en explicar los distintos patrones que podemos encontrar al momento de modelar requisitos de software con casos de uso.

Como siempre, está el que considero el mejor libro sobre UML, patrones, análisis y diseño orientado a objetos y el proceso de desarrollo de software, todo en uno. Se trata del libro de Larman [19].

También está el libro origen de todo, el de los three amigos [20].

Fin.

Referencias

[1] IBM. The Rational Unified Process V7.1.

[2] IBM. The Rational Unified Process version V7.1.

[3] Luis Antonio Salazar Caraballo, “Casos de Uso: Origen, Especificación y Evolución”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales-2.html, 17 nov. 2006.

[4] Luis Antonio Salazar Caraballo, “Casos de Uso: De Vuelta a lo Fundamental”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales.html, 09 nov. 2006.

[5] Luis Antonio Salazar Caraballo, “Casos de Uso: Del Todo y de Sus Partes”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales-3.html, 23 nov. 2006.

[6] Luis Antonio Salazar Caraballo, “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación?”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2006/12/lecturas-fundamentales-4-1-de-2.html, 07 dic. 2006.

[7] Luis Antonio Salazar Caraballo, “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2006/12/lecturas-fundamentales-5-2-de-2.html, 22 dic. 2006.

[8] Luis Antonio Salazar Caraballo, “Prolegómenos Sobre el Lenguaje de Modelado Unificado”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2005/06/prolegmenos-sobre-el-lenguaje-de.html, 01 jun. 2006.

[9] Object Management Group, “OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2”, http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML, 2 nov. 2007. Pp. 587.

[10] Luis Antonio Salazar Caraballo, “Realización de Casos de Uso: de los Objetos y sus Interacciones”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html, 23 oct. 2006.

[11] Object Management Group, “OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2”, http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML, 2 nov. 2007. Pp. 592.

[12] Object Management Group, “OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2”, http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML, 2 nov. 2007. Pp. 589.

[13] Object Management Group, “OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2”, http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML, 4 nov. 2007.

[14] Object Management Group, “OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2”, http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML, 2 nov. 2007. Pp. 71.

[15] Alistair Cockburn, “Writing Effective Use Cases”, Addison-Wesley, 21 feb. 2000.

[16] Mike O’Docherty, Object-Oriented Analysis & design, Understanding System Development With UML.” John Wiley & Sons. 2005.

[17] Steve Adolph, Paul Bramble, Alistair Cockburn, Andy Pols. Patterns for Effective Use Cases. Addison Wesley. August 23, 2002.

[18] Kim Hamilton, Russell Miles. Learning UML 2.0. O'Reilly. April 2006.

[19] Graig Larman. applying-uml-and-patterns-an-introduction-to-object-oriented-analysis-and-design-and-the-unified-process-2nd-edition. 13 jul. 2001.

[20] Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. 2nd-edition. May 29, 2005.

Lectura Fundamental Siguiente: Casos de Abuso

Lectura Fundamental 11

2007-11-23T00:02:00.003-05:00

Lectura Fundamental Anterior: “Realización de Casos de Uso: De los Objetos y sus Interacciones”

Lectura # 11

Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)

“Cuando la Generación-Net alcance la mayoría de edad, el mundo será más pequeño e infinitamente más complejo. No tenemos idea de cuáles problemas afrontarán estos jóvenes, cuáles serán sus sueños, ni qué nuevas y audaces soluciones idearán. Pero una cosa es segura: la democracia tal como la conocemos se acabará. Quizás debamos adoptar una actitud seria desde ahora y replantear nuestra noción sobre el gobierno y el significado de la libertad.”

Don Tapscott (Creciendo en un Entorno Digital)

Introducción

En Ingeniería del Software, la clase es la unidad esencial que forma a todo sistema de software. Es además la estructura sistémica y funcional fundamental del software en actividad, capaz de ejecutarse independientemente como entidad mono-funcional (como un servicio), o bien, hacer parte de una formación mayor, como instrumento multi-funcional. La clase presenta dos modelos básicos: abstracto y concreto. Su organización general comprende: identificador de la clase o nombre, atributos o propiedades y operaciones o métodos.

La teoría de la orientación a objetos o simplemente orientada-a-objetos es la base sobre la que se sustenta gran parte de la Ingeniería del Software. Todos los elementos utilitarios que forman los productos de software moderno están formados por clases.

El concepto de clase como unidad orgánica (en el sentido de estructural) y funcional de los sistemas de software surgió hará apenas unos cuarenta años, cuando el término “orientado-a-objetos” fue usado por primera vez.

“En Utah, en algún momento después de Noviembre del 66 cuando, influenciado por Sketchpad, Simula, el diseño para la ARPAnet², el Burroughs B5000 y mi conocimiento en Biología y Matemáticas, empecé a pensar en una arquitectura para la programación. Y fue probablemente en 1967 cuando alguien me preguntó qué estaba haciendo y le respondí: “Es programación orientada-a-objetos”.”³

Posteriormente, en los años setenta, el Grupo de Investigación en Aprendizaje (Learning Research Group) de XPARC (Xerox Palo Alto Research Center) con el Dr. Alan Kay a la cabeza, desarrolló SmallTalk, el primer lenguaje de programación orientado-a-objetos nativo que fue liberado a principios de los ochenta a toda la comunidad de desarrolladores. Algunas leyes⁴ o primitivas subyacen el desarrollo del lenguaje:

1. Cualquier cosa es un objeto

2. Los objetos se comunican enviando y recibiendo mensajes (en términos de objetos)

3. Los objetos tienen su propia memoria (en términos de objetos)

4. Cada objeto es una instancia de una clase (la cual puede ser un objeto)

5. La clase contiene el comportamiento compartido para sus instancias (en la forma de objetos en un programa)

6. Para evaluar un programa, el control se pasa al primer objeto y el resto es tratado como su mensaje.

Hoy, todos los lenguajes de programación implementan esas leyes y como programadores deberíamos tenerlas siempre presente a la hora de escribir un programa.

Más tarde se crearon lenguajes como C++, Eiffel y Oberon. En los noventas, Java y hace apenas unos años, ya en este milenio, C# (C Sharp), alrededor de los cuales se han establecido los postulados de la teoría orientada-a-objetos, que afirma, entre otras cosas, que la clase (el objeto) es una unidad morfológica (desde el punto de vista sistémico) de todo sistema de software.

Biología Informática

La célula es la unidad fundamental de los organismos vivos, generalmente de tamaño microscópico, capaz de reproducción independiente y formada por un citoplasma y un núcleo rodeados por una membrana.¹

Una célula está compuesta por un Núcleo, el organillo más ilustre en la mayoría de células animales y vegetales. En el núcleo, las moléculas de ADN y proteínas están estructuradas en cromosomas normalmente dispuestos en pares iguales. El ADN del interior de cada cromosoma es una molécula indivisible larga y arrollada que contiene cadenas lineales de genes. Éstos encierran a su vez instrucciones codificadas para la construcción de las moléculas de proteínas y ARN necesarias para producir una copia funcional de la célula, ¡el mismísimo milagro de la vida!

Los otros componentes de la célula son el Citoplasma y el Citosol. El primero comprende todo el volumen de la célula, salvo el núcleo. Engloba numerosas estructuras especializadas y orgánulos. El otro es la solución acuosa concentrada en la que están suspendidos los orgánulos.

Les estoy contando todo esto precisamente porque una analogía muy útil para una célula (biológica) es un objeto (informático). Los objetos tienen instrucciones codificadas dentro de ellos llamadas métodos (o procedimientos o funciones). Los programas en los objetos son análogos a la programación genética en el DNA dentro de las células. El DNA se subdivide en unidades funcionales llamadas genes; estas unidades corresponden a los atributos (o variables) en el objeto. Un objeto también tiene un metabolismo: consume memoria de acceso aleatorio (léase RAM) o hasta de sólo lectura (ROM).

Tanto los programas en las células como los métodos en los objetos pueden ser 1) copiados y 2) ejecutados. Algunas de las proteínas creadas cuando un programa genético se ejecuta corresponden a los resultados o salidas de los procedimientos y funciones del objeto. Pero otras proteínas son más análogas a los componentes de la clase o a las interfaces de la misma con el entorno. Por supuesto, los objetos no crean sus propios métodos o sus interfaces, lo hacen los programadores; la analogía no es perfecta.

De hecho, nada en los objetos es análogo a la reproducción de una célula. Una célula puede crear una copia completa de sí misma; esta célula contiene las instrucciones completas (programas) y la maquinaria celular (hardware) necesarias para reproducirse por sí misma. Un objeto no puede crear una copia de sí mismo… ¡hasta ahora! Le hacen falta los mecanismos necesarios (pero puede ser capaz de reproducir su conjunto de instrucciones respondiendo a un mensaje de su entorno, por ejemplo.) Un objeto que pueda reproducirse por sí mismo sería mejor descrito como un robot-software auto-reproductor. Tal cosa es concebible, pero no existe hoy.

Una criatura multiceldada es como un diagrama de clases. Se requiere de una arquitectura orientada a objetos, paralela, a gran escala para operar criaturas multiceldadas tales como mamíferos con billones o trillones de celdas, todas trabajando en armonía, cada una haciendo su tarea. El sistema nervioso y el sistema hormonal son dos importantes sistemas en red usados por los mamíferos.

Cambiar la forma en que un objeto trabaja requiere de novedosos y más avanzados algoritmos. Algunas veces un programador puede simplemente codificar un conjunto nuevo de órdenes de Inteligencia Artificial: el objeto reconoce el nuevo método o procedimiento, acepta su nuevo código y lo usa. Otras veces, reprogramar un objeto es más traumático. Las nuevas funciones pueden tener “errores”; puede no ser compatible desde el punto de vista de la lógica con el comportamiento existente en el objeto; se pueden llegar a necesitar parches adicionales; se puede introducir un virus de computador; o puede causar que el todo el objeto, y con ello el sistema del que hace parte, colapse sin explicación.

La evolución biológica sucede cuando las células son reprogramadas. De una forma u otra, los nuevos programas genéticos son instalados y activados. ¿Cómo se consigue instalar y activar nuevo software genético? ¿Y de dónde viene? Estas son algunas de las preguntas que la Cósmica Ancestral²² intenta responder.

Mientras encontramos estas y otras respuestas fundamentales, volvamos a nuestro hemisferio.

Conceptos Fundamentales

Una suite de conceptos, unos básicos o fundamentales, otros más avanzados, desde el punto de vista de la semántica, son necesarios para entender la teoría de la orientación a objetos.

Definición 22: Clase. Una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y semántica. Una clase puede usar un conjunto de interfaces para especificar colecciones de operaciones que ella proporciona a su entorno.⁵

Una clase puede ser vista como una plantilla o molde, un prototipo funcional, a partir del cual se pueden crear o instanciar un conjunto de elementos con las mismas características y comportamientos llamados Objetos. La clase es la unidad básica, el equivalente de la célula en el ser humano, que forma todo sistema de software. Una clase representa un grupo de datos y la manipulación de estos datos. Como piezas de datos, las clases pueden ser manipuladas. Sin embargo, como procedimientos, las clases también describen la manipulación. La información se manipula enviando un mensaje a la clase que representa la información.

Tiene sentido: puesto que un sistema de software es una herramienta para manipular información, las clases son esos diminutos corpúsculos, invisibles, que forman un sistema de software. Para los propósitos de este artículo, estoy usando una definición muy amplia de información.

Definición 23: Información. Una representación o descripción de algo.⁶Hay muchos tipos de información que describen diferentes cosas en formas diversas. Uno de los grandes sucesos en la computación fue el hecho de que la información podía, entre otras cosas, describir la manipulación de la información. Este tipo de información es llamada software.

En el mundo real, los seres humanos no concebimos una estructura (una cosa) sin pensar al mismo tiempo en el comportamiento que presenta o puede presentar esa estructura (esa cosa). Esta fue la premisa que alimentó la investigación del LRG en XPARC. Y debería ser el punto de partida en el desarrollo de cualquier producto de software. Es el orden natural de las cosas: las clases, al menos las primeras que aparecen de la mano de los usuarios, provienen precisamente del mundo real que, en términos del ciclo de vida o del proceso de desarrollo, constituyen lo que se llama el modelo de dominio. Alrededor de estas clases aparecen otras, durante el análisis y el diseño del software, que apoyan la operación “automatizada” de las primeras.

Ejemplos de clases típicas son: Proveedor, Cliente, Factura, Producto, Contrato, Pago (vemos una clase puede representar Personas, Cosas o Artefactos y Operaciones transaccionales). Cada una de estas clases tiene un conjunto de atributos o valores o características y un conjunto de métodos o procedimientos. En el caso de Contrato, por ejemplo, los atributos clave serían Número del Contrato, Fecha de Contrato, Valor del Contrato, Objeto del Contrato, Contratante, Contratista, Modalidad del Contrato, entre otros; algunas operaciones que se pueden hacer con el contrato son: Abrir Contrato, Cancelar Contrato, Suspender Contrato, Cerrar Contrato, Extender Contrato, Pagar Contrato. Son operaciones inherentes al negocio, del dominio dentro del cual una empresa rige su negocio.

Definición 24: Modelo de Dominio. Un modelo de dominio es un modelo del dominio dentro del cual una Empresa conduce su negocio. El Modelo de Dominio para una Empresa debería ser el mismo que para cualquier otra Empresa que conduzca el negocio en el mismo dominio. Cuando bajamos a niveles más detallados, personas distintas tienen diferentes ideas acerca de lo que constituye un Modelo de Dominio.

Un modelo de dominio puede verse como un modelo conceptual de un sistema el cual describe las distintas entidades involucradas en ese sistema y sus relaciones. El modelo de dominio es creado para documentar los conceptos clave y el vocabulario del sistema. El modelo muestra las relaciones entre las entidades principales dentro del sistema y usualmente identifica sus métodos y atributos importantes. Esto significa que el modelo proporciona una vista estructural del sistema el cual es complementado por las vistas dinámicas en el modelo de casos de uso. Un beneficio importante de un modelo de dominio es describir y restringir el alcance del sistema.

El modelo de dominio puede ser usado a bajo nivel en el ciclo de vida del desarrollo del software desde que la semántica del mismo puede ser usada en el código fuente. Las entidades se convierten en clases, mientras que los métodos y atributos pueden llevarse directamente al código fuente; los mismos nombres típicamente aparecen en el código fuente.

El modelo de dominio es uno de los artefactos centrales en las más importantes metodologías o procesos de desarrollo de software existentes. En UML, un diagrama de clases se usa para representar el modelo de dominio.

Todas las clases mencionadas en el apartado anterior son clases típicas que conforman un modelo de dominio. Para entender mejor, citemos algunas clases que no harían parte de ningún modelo de dominio: la Clase de Acceso a Datos, El Manejador de Errores (llamado también Controlador de Errores), la clase Usuario (en un contexto de seguridad), El Controlador de Transacciones, la clase de Auditoria, entre muchas otras que hacen parte del diseño de la solución y están fuera del dominio del problema.

Definición 25: Objeto. Una entidad con un límite bien definido e identidad que encapsula un estado y un comportamiento. El estado se representa por los atributos y las relaciones, mientras que el comportamiento es representado por las operaciones, métodos y las máquinas de estado. Un objeto es una instancia de una clase.⁷

Un objeto es una entidad individual que satisface la descripción de una clase o tipo.

Definición 26: Instancia. Es una manifestación concreta de una abstracción a la cual un conjunto de operaciones puede aplicarse y que tiene un estado que almacena los efectos de las operaciones.⁸ Instancia y Objeto son básicamente sinónimos.

Una clase puede derivar muchas instancias. Dicho de otra manera, en un momento determinado se pueden crear una o más instancias u objetos de una clase. El número de instancias creadas a partir de una clase está limitado únicamente por la cantidad de memoria disponible en el computador donde se esté ejecutando la aplicación que usa la clase.

Cada objeto se diferencia del otro por los valores de sus atributos. Este conjunto de valores forman el Estado del Objeto, único para cada instancia. Y observen que estoy usando los términos Instancia y Objeto indistintamente para referirme a lo mismo.

Definición 27: Operación. Un servicio que puede ser requerido desde un objeto para afectar su comportamiento. Una operación tiene una firma, que puede restringir los parámetros reales que son posibles. En otras palabras, una operación es una abstracción de algo que se puede hacer a un objeto que es compartido por todas las instancias de la clase.⁹

Una clase puede tener cualquier número de operaciones o ninguna operación. Por ejemplo, en una librería de ventanas como la que se encuentra en el paquete awt de Java, todos los objetos de la clase Rectangle pueden moverse, cambiar de tamaño o ser consultados sobre el valor de sus propiedades.

Muchas veces (pero no siempre), invocar una operación sobre un objeto cambia los datos o estado del objeto. En la Orientación a Objetos, una operación recibe comúnmente el nombre de método y en los lenguajes de programación se pueden clasificar en procedimientos y funciones.

En general las clases incluyen algunas operaciones comunes para Crear (create o new) o Destruir (Destroy o Release o Dispose) una instancia.

Además, las operaciones pueden ser públicas, es decir, visibles desde el exterior de la clase, o privadas, las que están disponibles solamente para los objetos de la clase.

Un término bastante relacionado con Operación es Mensaje.

Definición 28: Mensaje. Una especificación de una comunicación entre objetos que transmite información con la expectativa de iniciar una actividad; el recibo (la recepción) de una instancia de un mensaje es considerada normalmente una instancia de un evento.¹⁰

Los mensajes se establecen vía el conjunto de operaciones públicas de una clase.

Definición 29: Protocolo. El conjunto de mensajes a los que un objeto puede responder.¹¹

Como programadores, lo primero que debemos preguntarnos es cuál será el protocolo de la clase a programar y cuál es el protocolo de la(s) clase(s) relacionadas. Son estos protocolos los que permiten poner en movimiento un proceso (automático), los que permiten el flujo de información y mantener en ejecución por tiempo indefinido un sistema de software.

Definición 30: Interfaz. Una colección de operaciones que son usadas para especificar un servicio de una clase o de un componente.¹²

La Interfaz es el mecanismo que usan los lenguajes de programación para implementar un Protocolo.

Definición 31: Atributo. Un atributo definido por una clase representa una propiedad nombrada de la clase o sus objetos. Un atributo tiene un tipo que define el tipo de sus instancias.¹³

El conjunto de atributos de una clase constituye su Estructura y los valores de esos atributos en un instante dado representan el Estado del objeto.

Normalmente los atributos o propiedades de una clase están ocultos al mundo exterior, es decir, al resto de clases o de entidades que forman un sistema. Solamente se puede acceder a los valores de tales propiedades a través de métodos de la clase dispuestos para tal fin. Algunos de estos métodos son especializados y únicamente son capaces de asignar o “recordar” (leer) el valor de una propiedad, otros lo hacen mediante operaciones o transacciones más o menos complejas. Hay atributos que sólo pueden ser vistos por las operaciones de la clase, otros pueden ser vistos además por las clases “hijas” en una jerarquía de clases (ver Herencia).

Sin embargo, la mayoría de los lenguajes de programación implementan mecanismos para que desde el exterior de un objeto, o sea, desde otros objetos se pueda acceder directamente a los valores de las propiedades de una clase. Esto se hace para mejorar el desempeño de las aplicaciones en varios sentidos, sin embargo, deberíamos evitar el uso de estos mecanismos tanto como sea posible.

Definición 32: Relación. Es una conexión semántica entre elementos de un modelo. Ejemplos de relaciones incluyen asociaciones y generalizaciones.¹⁴

Las relaciones son los elementos encargados de darle vida a un modelo. Por sí solos, los demás componentes de un modelo como las clases no son capaces de hacer mucho (tal como muchos organismos unicelulares que actúan simplemente como parásitos) y es a través de relaciones como la Asociación, la Composición, la Agregación y la Generalización que se pone un modelo en ejecución.

Como regla general, todas las clases del dominio deberían estar relacionadas entre sí, sin embargo, el número de relaciones entre una clase y otras del modelo debería mantenerse al mínimo, lo que permitirá a su vez una baja dependencia entre el subsistema a los que pertenece una clase y los subsistemas a los que pertenecen las clases relacionadas. Esto se llama el Principio o Patrón de Bajo Acoplamiento.

Definición 33: Asociación. Una asociación es una relación estructural que especifica que objetos de una cosa están conectados con objetos de otra. Dada una asociación que conecta dos clases, podemos relacionar objetos de una clase con objetos de la otra clase. Es legal tener ambos extremos de una asociación sobre la misma clase, de manera circular. Esto significa que, dado un objeto de la clase, podemos enlazar a otros objetos de la misma clase. Una asociación que conecta exactamente dos clases se llama una asociación binaria. Aunque no es común, podemos tener asociaciones que conectan más de dos clases; éstas son llamadas asociaciones n-arias. Usamos asociaciones cuando queremos mostrar relaciones estructurales.¹⁵

En principio, durante las etapas de Análisis, todas las clases del dominio deberían estar “asociadas” entre sí. Más adelante, hacia el final del análisis y en el diseño, algunas asociaciones se pueden convertir en otro tipo de relaciones y las que permanecen como asociaciones se deben cualificar.

La cualificación de una relación como la asociación se logra mediante la cardinalización de ambos extremos de la relación, lo mismo que con el nombramiento, en ambos sentidos, de la misma. Por ejemplo, en un sistema típico tanto la entidad Cliente (de una Compañía) como la entidad Proveedor (de la misma Compañía) tienen alguna forma de relación (de asociación) con la entidad Producto. Pero a todas luces se evidencia la diferencia existente en la relación entre Proveedor y Producto que entre Cliente y Producto.

El Proveedor “vende” o “provee” de productos a la compañía, mientras que el Cliente “compra” o es “surtido” de productos por la compañía. En este contexto, “proveer”, “vender”, “comprar” y “surtir” son nombres representativos de asociaciones.

A su vez, es probable que un Proveedor suministre uno o más productos a la compañía (y hasta puede suceder, por políticas de la compañía –regla del negocio-, que quizás haya un máximo número de productos que un proveedor pueda suministrar, por ejemplo, 5). También puede ocurrir que para ser considerado como tal, un Cliente de la compañía deba comprar o adquirir mínimo 2 productos y máximo 12. Estos rangos (uno o más productos, 1 a 5, 2 a 12) hacen parte de la cardinalidad de las asociaciones.

Definición 34: Generalización. Es una relación entre un tipo general de una cosa (llamada la superclase o padre) y un tipo más específico de cosa (llamada la subclase o hija). Algunas veces, la generalización es llamada una relación “es-un-tipo-de”: una cosa (como la clase Baywindow) es-un-tipo-de una cosa más general (por ejemplo, la clase Ventana). Un objeto de la clase hija puede ser usado para una variable o parámetro tipado por el padre, pero no a la inversa. En otras palabras, la generalización significa que la hija es sustituible para una declaración del padre. Una hija hereda las propiedades de sus padres, especialmente sus atributos y operaciones. Muchas veces pero no siempre la hija tiene atributos y operaciones en adición a los encontrados en sus padres. Una implementación de una operación en una hija anula una implementación de la misma operación del padre; esto se conoce como polimorfismo. Para ser la misma, dos operaciones deben tener la misma firma (mismo nombre y parámetros). Use generalizaciones cuando quiera mostrar las relaciones padre/hija.¹⁶

La generalización es una relación taxonómica entre un elemento más general y un elemento más específico. El elemento más específico es completamente con el elemento más general y contiene información adicional. Una instancia del elemento más específico puede usarse donde el elemento más general es permitido.

Definición 35: Herencia. Es el mecanismo que hace posible la generalización; un mecanismo para crear descripciones completas de clases a partir de segmentos de clases individuales.¹⁷

En Orientación-a-Objetos, dada una clase, con unas características y un comportamiento bien definidos, se puede crear una jerarquía de clases, en donde cada clase de la jerarquía “hereda” los atributos y las operaciones de todos sus ancestros. El elemento hereditario además puede tener características y comportamiento propios o adicionales a los de los demás miembros de la estructura taxonómica a la que pertenece.

La herencia aparece cuando tipificamos o clasificamos elementos de un modelo, cuando decimos que este elemento “es-una-clase-de” o “es-un-tipo-de”. Por ejemplo un (Animal) Mamífero es una clase de Animal, un Automóvil es un tipo de Transporte Terrestre, un Vendedor es una clase de Persona.

Definición 36: Agregación. Una asociación plana entre dos clases representa una relación estructural entre pares, lo que significa que ambas clases están conceptualmente al mismo nivel, ninguna es más importante que la otra. Algunas veces queremos modelar una relación “todo/parte” en la que una clase representa una cosa más grande (el “todo”), que consiste de cosas más pequeñas (las “partes”). Este tipo de relación se llama agregación, que representa una relación “tiene-un” que significa que un objeto del todo tiene objetos de la parte. La agregación es realmente una clase especial de asociación.¹⁸Una de las grandes diferencias de la Agregación con la Asociación es que las instancias no pueden tener relaciones de agregación cíclicas, es decir, una parte no puede contener al todo.

La agregación se convierte en un concepto simple con alguna semántica moderadamente profunda. La agregación simple es enteramente conceptual y no hace nada más que distinguir un “todo” de una “parte”. La agregación simple no cambia el significado de la navegación a través de la asociación entre el todo y sus partes, ni enlace los ciclos de vida del todo y sus partes.

La multiplicidad de la parte agregada no puede ser mayor a 1, esto quiere decir que no es compartida.

Definición 37: Composición. Hay una variación de la agregación simple, la composición, que adiciona cierta semántica importante. La composición es una forma de agregación con propiedad fuerte y ciclos de vida coincidentes como parte del todo. Partes con multiplicidad no fija pueden ser creadas después del compuesto mismo, pero una vez creadas viven o mueren con ella. Tales partes también pueden ser explícitamente removidas antes de la muerte del compuesto.¹⁹A la Composición también se le conoce como Agregación Compuesta.

Esto significa que, en una agregación compuesta, un objeto puede ser una parte de sólo un compuesto a la vez. Por ejemplo, en un sistema de Ventanas, un Marco pertenece a exactamente una Ventana. Esto contrasta con una agregación simple en la que una parte puede ser compartida por varias partes. Por ejemplo, en el modelo de una casa, una Pared puede ser una parte de uno o más objetos Cuarto.

Además, en una agregación compuesta el todo es responsable por la disposición de sus partes, lo que significa que el compuesto debe manejar la creación y destrucción de sus partes. Por ejemplo, cuando creamos un Marco en un sistema de ventanas, debemos adicionarlo a una Ventana. Similarmente, cuando destruimos una Ventana, el objeto Ventana debe a su vez destruir sus partes Marco.

El control que mantiene el “todo” con la “parte” puede ser directo o transitivo, o sea, el “todo” puede tener la responsabilidad directa de crear o destruir la “parte” o puede aceptar una parte previamente creada y más tarde pasarla a algún otro “todo” que asuma la responsabilidad por esa “parte”.

Un objeto puede ser parte de solamente un compuesto a la vez. Si el compuesto es destruido, este debe destruir todas sus partes o pasar la responsabilidad de ellos a algún otro objeto. Un objeto compuesto puede ser diseñado con el conocimiento de que ningún otro objeto podrá destruir sus partes.

Un ejemplo típico de una composición es el del Automóvil: las puertas, la carrocería, las llantas y el motor, por sí solos pueden no tener ninguna utilidad (funcionalidad), pero compuestos, bien podríamos tener un (objeto) buen automóvil que nos presta una mayor utilidad (funcionalidad), seguramente mayor que la suma de sus partes.

Definición 38: Polimorfismo. Generalmente, la habilidad aparece en muchas formas. En programación orientada-a-objetos, el polimorfismo se refiere a la habilidad de un lenguaje de programación de procesar objetos de manera diferente dependiendo de su tipo de dato o clase. Más específicamente, es la habilidad de redefinir métodos para clases derivadas.²⁰Por ejemplo, dada una clase base Figura_Geometrica, el polimorfismo habilita al programador para definir métodos CalcularArea diferentes para cualquier número de clases derivadas, tales como círculos, rectángulos y triángulos. Sin importar de qué forma es un objeto, aplicarle el método CalcularArea retornará los resultados correctos. El polimorfismo es considerado un requisito de cualquier lenguaje de programación orientado-a-objetos (OOPL).

En otras palabras, dada una jerarquía de objetos, cada objeto implementa su(s) comportamiento(s) de acuerdo a sus características. La operación para calcular el área de un triángulo (Base X Altura / 2) es diferente de la operación para calcular el área de un círculo (π X Radio²) porque evidentemente tienen atributos distintos como bien sabemos.

Definición 39: Abstracción. Es un mecanismo y práctica para reducir y factorizar los detalles de tal manera que podamos enfocarnos en unos pocos conceptos al tiempo.²¹

El concepto se da por analogía con la abstracción matemática. La técnica matemática de abstracción comienza con definiciones matemáticas; esto tiene el efecto afortunado de afinar algunos de los aspectos filosóficos molestos de abstracción. Por ejemplo, tanto en computación como en matemáticas, los números son conceptos en los lenguajes de programación, tal como se encuentran en las matemáticas. Los detalles de implementación dependen del hardware y del software, pero esto no es una restricción porque el concepto computacional de número todavía está basado en el concepto matemático.

La abstracción puede aplicarse tanto al control del proceso como a los datos manipulados por el proceso. La abstracción de control es la abstracción de acciones mientras que la abstracción de datos aplica a las estructuras. Por ejemplo, la abstracción de control en programación orientada a objetos tiene que ver con el uso de métodos, interfaces y clases genéricas. La abstracción de datos permite el manejo de datos de maneras significativas. Por ejemplo, es la motivación básica detrás de los tipos de datos. Finalmente, la Programación orientada-a-objetos puede verse como un intento de abstraer tanto el dato como el código.

De Dónde Surgen los Objetos

Parece justo, al menos para mí, terminar esta disertación sobre orientación a objetos con un aspecto del que tengo algún conocimiento: la Gramática, en particular, y el lenguaje, en general. Por supuesto no hablo de C#, Java o C++, algunos de los lenguajes de programación más ampliamente usados hoy, estoy hablando del idioma Español.

Luego de tener un manifiesto con los requisitos del sistema (y por sistema también quiero decir un módulo, un subsistema, un proceso, un modelo), expuestos en distintos artefactos como un documento de visión, un glosario, una descripción detallada de esos requisitos, un conjunto finito de casos de uso (hoy se llaman casos de uso, Jacobson 1994, ayer se llamaban escenarios, Rumbaugh 1991), entonces procedemos a realizar un análisis sintáctico, pero no de esos que hacen los compiladores, no. Estoy hablando de una exploración minuciosa de todas y cada una de las frases del manifiesto y hacer una tabla con los sustantivos, los verbos, los adjetivos, los adverbios. Si de pronto hemos olvidado lo que es un Predicado o lo que es un Adverbio de Lugar, entonces hay que volver a sacar el libro Español y Literatura de nuestra queridísima maestra Lucila González de Chávez y repasar algunos detalles sobre el tema.

Los sustantivos son clases o atributos potenciales (en este período mesozoico del proceso todavía no somos capaces de acertar en el primer intento sobre que elemento de nuestras fuentes documentarias es que elemento de nuestro modelo objetual). Entre tanto, los verbos son métodos potenciales (incluso, podrán llegar a ser procedimientos almacenados o triggers).

¿Y los adjetivos y los adverbios dónde se quedan? Bueno, dice mi Gazafatonario y doña Lucila González que un adjetivo califica al sustantivo (hay muchas clases de adjetivos), le da un valor, esa es la clave: si finalmente nuestro sustantivo es una propiedad, el adjetivo posiblemente sea su valor predeterminado, mientras que si es una clase, el calificativo será una instancia. Por su parte, el adverbio califica al verbo (¿recuerdan? Adverbios de modo, de lugar, de tiempo, demostrativos, relativos, interrogativos, de cantidad e intensidad), una teoría lingüística interesante y profunda que si la conocemos bien nos ayudará a encontrar cuál es el desempeño que se quiere para el método (adverbio de modo), dónde se ejecuta el método (adverbio de lugar) –quizás nos diga de qué clase es, en qué capa de la arquitectura va, si puede ser un trigger o no y cuándo se ejecuta (adverbio de tiempo), algunos criterios funcionales (adverbios demostrativos, relativos, interrogativos), cuál es la frecuencia de ejecución (adverbios de cantidad e intensidad), y hasta pueden llegar a ser argumentos del método en cuestión.

El tema tiene tanto de ancho como de profundidad y no quiero extender más esta lectura, así que los invito a que revisen la extensa literatura que existe sobre ello.

El Siguiente Paso en la Evolución

Fue por allá a mediados de los años 80 cuando escuché y leí por primera vez sobre la orientación a objetos. El término realmente me pareció interesante pero extraño. En contraste, algunos otros compañeros que todavía no habían tenido su primera vez con computadores encontraron la idea de los sistemas orientados a objeto como algo natural. No es que los programadores novatos puedan crear sistemas complejos en un ambiente orientado a objetos más fácilmente de lo que pueden los programadores experimentados. Ciertamente, crear sistemas complejos envuelve muchas técnicas más familiares al programador experto que al principiante, sin tener en cuenta si se usa o no un entorno orientado a objetos. Pero la idea básica acerca de cómo crear un sistema de software en un estilo orientado a objetos llega de una forma más natural a quienes no tienen una preconceptualización acerca de la naturaleza de sistemas de software. Entender los conceptos que he expuesto fue la clave que condujo mi carrera profesional durante mucho tiempo y que me permitió escribir algunos cientos de miles de líneas de código en diversos lenguajes de programación.

Muchos años después, con el advenimiento de la Internet, me di a la tarea de buscar y conocer en qué andaba el célebre equipo de XPARC que creó la técnica tan acertadamente. Los encontré en www.parc.com y el mundo de la programación no volvió a ser igual para mí.

Los amigos de PARC habían encontrado muchos problemas de programación para los que ni las técnicas de programación procedimental ni orientadas a objeto parecían suficientes para capturar claramente algunas de las decisiones importantes que un programa debía implementar. Ellos observaron que esos problemas forzaban la implementación de muchas decisiones de diseño en el código de una manera dispersa y heterogénea, dando como resultado un código fuente “enmarañado” que es difícil de desarrollar y mantener. Así es que presentaron a la comunidad un análisis del porqué ciertas decisiones de diseño eran difíciles de capturar apropiadamente en el código actual y llamaron a las propiedades a las que esas decisiones apuntaban aspectos. También mostraron que la razón de su captura compleja era que estas decisiones eran transversales a la funcionalidad básica de todo sistema. Con esto en mente, presentaron las bases para una nueva técnica de programación que llamaron programación orientada a aspectos o simplemente aspectos. Esta técnica hace posible escribir programas con precisión que involucren tales aspectos, incluyendo aislamiento apropiado (más allá de la encapsulación de objetos), composición y reusabilidad de código “aspectual”.

En breve, los Aspectos son propiedades para las cuales la implementación no puede ser encapsulada en un procedimiento generalizado. Los Aspectos y los componentes transversales se cruzan entre sí en la implementación de un sistema. Esta técnica soporta una abstracción completa y la composición tanto de componentes como de aspectos. La diferencia clave entre AOP y la OOP (y por extensión con PPO) es que la AOP proporciona lenguajes de componentes y aspectos con diferentes mecanismos de abstracción y composición.²³

Los Aspectos son a los Objetos lo que estos fueron a los Procedimientos. Hoy ya existen lenguajes orientados a aspectos como AspectJ (la primera implementación de un lenguaje AOP basado en Java), AspectC++, Aspicere2 y otros basados en C/C++; también existen LOOM.NET, AspectDNG, Compose, Aspect.NET, DotAspect y otros basados en C#/VB.NET y muchas otras docenas de estos lenguajes emergentes, incluyendo WEAVR de Motorola para UML 2.0, una herramienta de desarrollo de software Orientado a Aspectos de naturaleza industrial que soporta weaving de los modelos comportacionales de UML 2.0 como los diagramas de interacción y de actividad. Y es tiempo de un último aserto.

Definición 40: Weaving es el proceso de aplicar Aspectos a los Objetos Destinatarios para crear los nuevos Objetos Resultantes en los especificados Puntos de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto Destinatario:

· Aspectos en Tiempo de Compilación, que necesita un compilador especial.

· Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el Objeto Destinatario es cargado en la máquina virtual.

· Aspectos en Tiempo de Ejecución.

Está ocurriendo tal cual ha ocurrido durante millones de años en la naturaleza, las insuficiencias existentes, los entornos recién descubiertos, recién creados, sólo dan paso a los más fuertes y sólo los más arriesgados sobreviven, así es la biología celular. Así mismo pasa en la TI, las nuevas necesidades exigen nuevas soluciones y estas a su vez requieren de nuevas tecnologías y nuevas técnicas.

En el futuro lejano, luego de la fusión de tres revoluciones científicas que todavía no ocurren, la teoría cuántica nos proveerá de transistores cuánticos microscópicos más pequeños que una neurona, la revolución informática nos facilitaría redes neuronales tan poderosas como las que hoy residen en el cerebro humano, y la revolución biomolecular nos permitiría la capacidad de reemplazar las redes neuronales de nuestro cerebro por tejidos sintetizados, garantizándonos así cierta condición de renovación, seríamos inmortales.

Pero no nos apresuremos, un paso a la vez, “así se ha hecho durante millones de años” ²⁴, así que todo esto será motivo de otra de mis lecturas.

Conclusión

He abordado sucintamente los conceptos que subyacen la técnica de la programación orientada a objetos. Es lo que existió antes del lenguaje de programación, antes del Java y el C#, aún antes del BASIC y el C. Entender estos conceptos nos da una visión que permite reducir la complejidad de grandes sistemas sin poner complicaciones adicionales en la construcción de sistemas pequeños. Ciertamente, como lo pensaron los investigadores en XPARC durante 20 años de estudios, la técnica se acerca a la forma cómo pensamos los seres humanos; sin embargo, todavía el hardware disponible hoy, otros 30 años después, es incapaz de aceptar tales principios. Quizás en el futuro próximo, ayudados por lo que he dado en llamar Biología Informática, podamos tener máquinas casi tan hábiles como nosotros, máquinas que entretejan (como los Aspectos), millones de chips neuronales que se crucen ad-infinitum y sean capaces de pensar y adaptarse a nuevos entornos.

Mientras tanto, la programación orientada a objetos, y con ésta, el análisis y diseño orientados a objeto, la programación orientada a aspectos, la herencia y el polimorfismo, las asociaciones binarias y las abstracciones lógicas, serán las técnicas que reinen en el mundo de las tecnologías informáticas.

Cierre y fin de la emisión.

Referencias

1. Diccionario de la Real Academia de la Lengua Española Edición En Línea. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=célula

2. ARPANet fue el nombre original de Internet. ARPA son las siglas en inglés de Advanced Research Projects Agency, que inicialmente conectó cuatro grandes computadores en universidades en el suroeste de los Estados Unidos (UCLA, Stanford Research Institute, UCSB y la Universidad de Utah) por allá en 1.969.

3. Dr. Alan Kay. On The Meaning of “Object-Oriented Programming” (http://www.purl.org/stefan_ram/pub/doc_kay_oop_en)

4. Dr. Alan Kay. The Early History of Smalltalk. http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

5. IBM. The Rational Unified Process Glossary.

6. Luis Antonio Salazar Caraballo. Sistemas de Software Orientado a Objetos. 2000.

7. IBM. The Rational Unified Process Glossary.

8. IBM. The Rational Unified Process. UML.

9. IBM. The Rational Unified Process Glossary.

10. IBM. The Rational Unified Process. UML.

11. Luis Antonio Salazar Caraballo. Sistemas de Software Orientado a Objetos. 2000.

12. IBM. The Rational Unified Process. UML.

13. IBM. The Rational Unified Process. UML.

14. IBM. The Rational Unified Process. UML.

15. IBM. The Rational Unified Process. UML.

16. IBM. The Rational Unified Process. UML.

17. IBM. The Rational Unified Process. UML.

18. IBM. The Rational Unified Process. UML.

19. IBM. The Rational Unified Process. UML.

20. IBM. The Rational Unified Process. UML.

21. Wikipedia contributors, 'Abstraction (computer science)', Wikipedia, The Free Encyclopedia, 7 November 2007, 04:20 UTC, <http://en.wikipedia.org/w/index.php?title=Abstraction_%28computer_science%29&oldid=169781888> [accessed 21 November 2007].

22. Wikipedia contributors, 'Cosmic ancestry', Wikipedia, The Free Encyclopedia, 26 April 2007, 23:28 UTC, <http://en.wikipedia.org/w/index.php?title=Cosmic_ancestry&oldid=126264933> [accessed 21 November 2007]

23. Kiczales, Lamping, Mendhekar, Maeda, Videira Lopes, Loingtier & Irwin. Aspect-Oriented Programming. 1997.

24. Así le dice Ted a Ellie en Contacto, de Carl Sagan.

Ted: Este ha sido un primer paso. Con el tiempo, daréis otro.

Ellie: Pero otros necesitan ver lo que he visto yo.

Ted: Así se ha hecho durante millones de años. Poco a poco, Ellie. Poco a poco.

(Le besa la frente. Ambos miran al cielo. Cientos de rayos, como cometas, se

aproximan a la nebulosa rojiza. Al chocar con ella, hay como una explosión

blanca. Volvemos a la realidad, con la cápsula cayendo bruscamente al agua…)

Lectura Fundamental Siguiente: Casos de Uso: de Extensiones y de Inclusiones

Lecturas Fundamentales 10

2007-10-23T19:11:00.000-05:00

Lectura Fundamental Anterior: “RUP: Fase de Concepción Parte 2”

Lectura # 10: Realización de Casos de Uso: De los Objetos y sus Interacciones

Presentación

¿Es familiar para alguno de ustedes esta imagen?

Figura 1: Meta-Modelo de un proceso de desarrollo de software mal-ejecutado

Este meta-modelo muestra un paradigma muy común en los equipos de desarrollo de software en el que la substancia de los emisores (los Analistas) no se coordina con la idiosincrasia de los receptores (los Programadores y los Probadores). Lo que está sucediendo es que el formato en el que se emite y el formato en el que se recibe (para usar términos reconocibles por nosotros) no son compatibles en el sentido en que unos y otros ven las cosas de distinta forma: mientras los Analistas observamos el universo del problema desde una perspectiva de usuario final, los Programadores lo hacemos con una visión técnica y tecnológica de las cosas. Mientras el Analista habla (escribe) en términos de necesidades, causas raíz, características, requisitos y solicitudes, el Programador espera recibir expresiones orientadas al método (orientado-a-objetos, orientado-a-aspectos o a algún otro similar): clases, tablas, objetos, controles visuales, entre otros.

Esta cacofonía por antonomasia, esta genuina desproporción de los formatos de emisión y recepción que nacen (durante la Concepción del sistema) y evolucionan (a lo largo de la Elaboración y Construcción) de manera asimétrica por la simple causa de que una se apoya en lo biológico (las necesidades y los requisitos vienen de seres humanos) mientras que la otra se soporta en la mecánica y en la electrónica (las tablas, los índices y los objetos necesitan de una máquina para vivir), esta situación en la que la comunicación (entre Analistas y Programadores) se torna en un procedimiento irregular y embrollado, esta disyuntiva es la que me empieza a ocupar a partir de esta lectura fundamental.

Ahora bien, puesto que el análisis y diseño orientado a objetos es ciertamente un proceso dinámico, debo elegir desde que ángulo presentarlo. Como con el mismo proceso de desarrollo de software, mostrar un estado “final” muchas veces da al lector falsas expectativas de estar en lo correcto desde el primer intento, mientras que con un primer acercamiento se puede exhibir un sistema incompleto o peor aún, erróneamente entendido. En este artículo elegí compartir mi trabajo a partir de un enfoque temprano, corriendo el riesgo de darle al lector inexperto algunas falsas concepciones acerca de lo que son el análisis y el diseño orientados a objeto. Es un buen reto, sobre todo porque me da la oportunidad de reducir ese riesgo al mínimo, al punto de hacerlo desaparecer a lo largo de la explicación que tengo planeada en esta exposición; al final de la misma, espero, el Diseñador orientado a objetos habrá entendido las cuestiones básicas y algunas no tan básicas de la realización de casos de uso desde una perspectiva sistémica. Si eso sucede, al menos para un pequeño grupo de lectores, entonces habré cumplido mi misión.

Aquí vamos otra vez.

Sobre el Lenguaje de Modelado Unificado

Definición 19: “El Lenguaje de Modelado Unificado es un lenguaje visual para especificar, construir y documentar los artefactos de los sistemas. UML es un lenguaje de modelado de propósito general que puede ser usado con todos los métodos orientados a objetos y a componentes y puede ser aplicado a todos los dominios de aplicación (por ejemplo, salud, financiero, telecomunicaciones, aeroespacial) y a distintas plataformas de implementación (por ejemplo, J2EE y .NET).”¹

En este contexto, Especificar significa enumerar y construir modelos que son precisos, no ambiguos y completos. UML dirige la especificación de todas las decisiones importantes de análisis, diseño e implementación². Mientras tanto, Construir quiere decir crear o modificar diagramas y modelos, usualmente basado en la existencia y estado de otros símbolos base o de otros diagramas. Los modelos que se construyen con UML están relacionados con los lenguajes de programación orientados a objetos. UML se usa para hacer Ingeniería Hacía Adelante, esto es, un mapeo directo de un modelo UML con código fuente. UML también se usa para hacer Ingeniería en Reversa, o sea, una reconstrucción de un modelo UML desde una implementación específica, normalmente en un lenguaje OO³. UML además se usa para Documentar la arquitectura de los sistemas, los requisitos, las pruebas y actividades como planeación del proyecto y manejo de la entrega del producto⁴.

Como cualquier lenguaje, UML tiene una sintaxis y una semántica. La sintaxis de UML está compuesta por un conjunto de construcciones gráficas útiles para especificar diagramas y modelos de sistemas⁵. Cada uno de estos símbolos tiene un significado de manera independiente, como lo tienen las palabras reservadas Begin, End y While en Pascal o los términos private, void y string en C# (léase C Sharp)⁶.

La semántica de UML es la que nos dice, por ejemplo, que un Actor solo se puede “comunicar” con el sistema a través de los casos de uso mediante una relación de Asociación, o que un paquete puede estar compuesto de Clases, Casos de Uso, Componentes u otros Paquetes y que existen distintos tipos de diagramas, a manera de modelos, que pueden ser construidos a partir de uno o más símbolos de UML⁷. De esta manera, podemos construir “instrucciones válidas” en UML como las que ilustro en la figura 2, que resulta ser un Diagrama de Casos de Uso, un espécimen del que hablaré en alguna oportunidad.

Pueden encontrar más de UML en mis Prolegómenos Sobre el Lenguaje de Modelado Unificado (http://gazafatonarioit.blogspot.com/2005/06/prolegmenos-sobre-el-lenguaje-de.html).

El Caso de Estudio (aka, el Ejemplo)

Consideremos el siguiente caso de uso típico ingreso al sistema de reserva de vuelos:

Caso de Uso: Ingresar al Sistema

Actor: Pasajero

Descripción: Este caso de uso permite al Pasajero ingresar al sistema Web de Reservas usando su número de pasajero frecuente y la clave actual. A solicitud del usuario, el caso de uso además muestra los datos detallados del pasajero registrado.

Objetivo: Suministrar al usuario Web del sistema de Reservas una interfaz amigable que le permita acceder rápidamente a las principales opciones del sistema.

Precondiciones

Ninguna

Secuencia Básica:

1. El caso de uso inicia cuando el pasajero decide ingresar al sistema

2. El sistema solicita el código (número) de pasajero frecuente y su respectiva clave

3. El pasajero ingresa su número y clave

4. El sistema busca los datos del pasajero, valida que el número y la clave del mismo coincidan con los registrados previamente.

5. El sistema solicita confirmación para mostrar los datos completos del pasajero

6. El pasajero confirma que quiere ver sus datos

7. El sistema muestra los datos detallados del pasajero

8. El caso de uso termina

Secuencia Alternativa 1

4A. El número de pasajero o la clave no coinciden.

4A1. el sistema muestra el mensaje: “Los datos proporcionados del pasajero no coinciden con los registrados en el sistema. Verifique.”

4A2. El caso de uso continúa en el paso 2.

Poscondiciones

El pasajero puede realizar diversas transacciones en el sistema como Reservar Vuelos, Cancelar Reservas, Cambiar su Clave, Modificar su Perfil, Pagar una Reserva o Cambiar los datos de una reserva.

Requisitos Especiales

Por razones de seguridad, el sistema sólo muestra los cuatro últimos dígitos de la tarjeta de crédito del pasajero.

Por razones de seguridad, el sistema no indica cual de los datos (número o clave) está erróneo.

Advertencia: aunque éste es un caso de uso terminado, es de una situación simulada. Si lo usa en algún proyecto es bajo su propia responsabilidad. Todos los nombres y lugares han sido cambiados para proteger la identidad de los culpables.

Puesto que se trata de un enfoque holista, no puedo continuar sin poner en perspectiva este caso de uso. Hablo de ubicarlo dentro de un sistema, en este caso, de un sistema de reserva de vuelos en el que además se pueda cancelar una reserva, pagar por el vuelo (con tarjeta de crédito, por ejemplo), cambiar la reserva (algunos de sus datos, como la fecha de regreso, por ejemplo), confirmar una reserva, hacer apertura y cierre de vuelos por parte de las aerolíneas y mantener información de los aeropuertos, entre otras funcionalidades. Las cosas así, el diagrama de casos de uso de la figura 2 nos muestra una vista funcional del sistema.

Figura 2: Algunos casos de uso del Sistema de Reserva de Vuelos

Con este conato de modelo en mente, volvamos a nuestro caso de uso.

Interacciones

Las Interacciones son usadas en diversas situaciones: para tener un mejor control de una situación de interacción por parte de un diseñador individual o por un grupo de personas que necesita lograr una interpretación común de la situación. Las interacciones también son usadas durante la fase de diseño más detallada donde la precisa comunicación entre procesos debe ser establecida de acuerdo a protocolos formales. Cuando se ejecutan las pruebas, las secuencias de ocurrencias de eventos del sistema pueden ser descritas como interacciones y comparadas con las de las fases anteriores.⁸

En UML 2.x hay tres clases de diagramas de Interacción: Diagrama de Secuencia, Diagrama de Comunicación (anteriormente diagrama de Colaboración) y Diagrama de Revisión de Interacciones (nuevo a partir de la versión 2.0 de UML).

Los Diagramas de Comunicación muestran las interacciones a través de una vista arquitectónica de las líneas de vida de los objetos en donde la secuencia de Mensajes es dada vía un esquema de numeración secuencial. Mientras tanto, los Diagramas de Revisión de Interacciones definen Interacciones a través de una variante de los Diagramas de Actividad promoviendo la revisión del flujo de eventos. En estos diagramas de Revisión se omiten las Líneas de Vida y los Mensajes entre ellas.

En lo que sigue, me concentraré en los Diagramas de Secuencia, que se enfocan en el intercambio de mensajes entre las Líneas de Vida de los objetos.

Diagramas de Secuencia, Paso a Paso

Un Diagrama de Secuencia muestra una vista de las entrañas del sistema, cómo se van a suceder las funciones (expuestas normalmente en un caso de uso o en un conjunto de casos de uso) a partir de la activación de un Actor (una persona). En general, un diagrama de secuencia se usa para modelar la lógica del sistema (de uno o más casos de uso del sistema al tiempo, o de parte de un caso de uso). Este tipo de diagrama muestra precisamente el orden temporal en el que ocurren las acciones en un sistema. Estas acciones son especificadas en términos de Mensajes entre los objetos que interactúan en el modelo. Además, son modelados a nivel de objetos en vez de a nivel de clases para permitir escenarios que usan más de una instancia de la misma clase y para trabajar a nivel de hechos (reales), datos de prueba y ejemplos. Y más aún, el diagrama de secuencia muestra una vista dinámica del sistema (o de parte de él), en contraposición a lo que hace por ejemplo el diagrama de clases, que presenta un panorama estático del mismo sistema.

De acuerdo a Ivar Jacobson, la parte más importante del así llamado análisis dinámico es la realización del caso de uso, nombrada así puesto que con ellos hacemos real(idad) el caso uso mediante la demostración de cómo puede ser implementado a través de la colaboración entre objetos. La realización de casos de uso tiene tres pasos esenciales:

1. Ir a través de (caminar por) los casos de uso del sistema simulando los mensajes enviados entre objetos y almacenando los resultados en diagramas de interacción.

2. Agregar operaciones a los objetos que reciben los mensajes.

3. Adicionar clases para representar límites (interfaces del sistema) y controladores (un receptáculo para procesos del negocio complejos o para la creación y recuperación de objetos), cuando sea necesario.

En nuestro ejemplo, el caso de uso inicia cuando el Pasajero decide Ingresar al Sistema. Este es el punto de partida, la activación del proceso. La primera pregunta que tratamos de responder es: ¿mediante qué mecanismo (de interacción) el pasajero le indica al sistema que quiere autenticarse? Esta es una pregunta simple que tiene una respuesta simple: mediante un formulario llamado, coincidentemente, Ingresar al Sistema. Si asumimos que estamos desarrollando una aplicación para Internet, este formulario se encuentra en una página Web (no entraré en el detalle de la plataforma de implementación, del lenguaje de programación o de la base de datos a usar para la producción de este sistema). En este escenario, entonces, el actor le envía un mensaje (interactúa) con un formulario llamado Ingresar al Sistema (que no es más que una instancia –un objeto – de una página Web.

Anotación: estoy usando una definición amplia e indistinta de los términos Instancia, Objeto y Clase. En una futura Lectura Fundamental abordaré el tema específico de la programación orientada a objetos y especificaré los detalles de tales conceptos.

La figura 3 muestra entonces la interacción inicial entre el actor (el pasajero) y el sistema (la página Ingresar al Sistema). El diagrama de la figura muestra dos Líneas de Vida.

Definición 20: Una Línea de Vida representa un participante individual en la Interacción. Cada Línea de Vida se conoce como una entidad interactuante⁹. Simplificando, una Línea de Vida es una instancia de una clase (si nos encontramos a la altura del análisis del sistema, ésta es realmente una instancia potencial) que muestra su propio ciclo de vida, desde la creación (que puede ser implícita o explícita), pasando por diferentes estados, hasta su destrucción (que también puede ser implícita o explícita).

Definición 21: Un Mensaje define una comunicación específica entre las Líneas de Vida de una Interacción. La comunicación puede ser de diversos tipos: el envío de una señal, la invocación de una operación, la creación o destrucción de una instancia¹⁰, entre otras. Con el Mensaje se pueden identificar tanto el Emisor (el objeto que envía el mensaje) como el Receptor (el objeto que recibe el mensaje). Este último es el que finalmente implementará la funcionalidad (las operaciones) que se requiere para que el sistema procese el Mensaje.

En el diagrama, el mensaje es “Ingresar”. El mensaje tiene dos argumentos: Número y Clave del Pasajero.

Por ahora, esta interacción nos resuelve los pasos 1 a 3 del caso, en los que el sistema solicita el número y clave del pasajero y este los ingresa. Lo que sigue es que el sistema busca y valida los datos de ese pasajero en particular.

Puesto que normalmente estaríamos en una fase en la que ya se conoce al menos una arquitectura preliminar o candidata del sistema, como diseñadores seguimos los patrones o las restricciones impuestas por esa arquitectura. En este caso, asumamos que nos enfrentamos a un diseño de varias capas en el que la interfaz de usuario no se comunica por ningún motivo con la base de datos. En este caso, la página Ingresar al Sistema debe transferir la solicitud de acceso a otro elemento del modelo que bien podría ser un objeto, una instancia de un Controlador de Pasajeros, como lo muestra la figura 4.

Figura 3: Diagrama de Secuencia Inicial del Caso de Uso Ingresar al Sistema

Figura 4: Transferencia de la Solicitud de Ingreso al Sistema

Quiero detenerme unos instantes en este asunto de las restricciones impuestas por la arquitectura del software. Resulta que durante parte del proceso de desarrollo, los analistas, diseñadores, programadores y demás miembros del equipo nos encontramos en un proceso creativo, un proceso de descubrimiento constante, desde los objetos del dominio (del negocio) durante el modelado del negocio, pasando por los requisitos (en términos de casos de uso) y las clases y las tablas del sistema, hasta muchas de las líneas de código que escribimos. Eso es lo que hace que nuestra profesión siga siendo un “arte”, poco precisa y hasta llena de dilemas y ambigüedades. Pues bien, resulta que la Arquitectura es uno de esos “artilugios” que tenemos para guiar ese proceso de hallazgo al que nos enfrentamos. La arquitectura define o establece un conjunto de elementos estructurales que se nutren de decisiones de diseño, reglas o patrones que restringen ese diseño y la construcción misma del software.

Ahora bien, si nos ceñimos a las reglas arquitecturales (o arquitectónicas), el número de salidas que encontremos para un caso de uso o para un conjunto de ellos puede ser grande. La solución que estoy exponiendo es la de una transacción “tipo”, un patrón determinístico que se puede usar en la gran mayoría de los escenarios que nos ocupan día a día.

Volvamos al ejemplo. Este recién llegado Controlador de Pasajeros es quien puede comunicarse con algo así como una Relación de Pasajeros, un inventario que conozca los datos de todos los pasajeros registrados en el sistema. Este repertorio, bien podríamos llamarlo Catálogo de Pasajeros y dependiendo del momento por el que atravesemos en el proceso de desarrollo, este elemento bien podría permanecer en la abstracción conceptual de lo que ordinariamente conocemos como catálogo (durante el análisis) o bien podría ser una instancia de una Clase (realmente una Colección) de Pasajeros (más tarde en el diseño), hasta llegar a ser una Tabla de la base de datos (durante la implementación de la solución). Por ahora, sólo será el Catálogo de Pasajeros, simple.

Y es a este catálogo al que el Controlador de Pasajeros le puede indagar por los datos del pasajero que acaba de suscribir la solicitud de acceso, como lo dibujo en la figura 5.

Figura 5: Buscar Pasajero por Número

Sabemos que hay dos alternativas posibles: que el pasajero se encuentre registrado en el catálogo o que no se encuentre registrado. En este diagrama sólo ilustraré la primera. Una vez los datos del pasajero han sido localizados, el Catálogo de Pasajeros puede hacer dos cosas: informar a Control de Pasajeros y crear un nuevo objeto, finalmente, el Pasajero. Este nuevo objeto tiene todos los datos del pasajero y conoce todas las funciones que un pasajero (una persona) puede desempeñar en el sistema. ¡Es un Humanoide Virtual!

En la figura 6 podemos observar el instante preciso en el que se crea la instancia del Pasajero, justo después de que el Control de Pasajeros recibe la notificación de que el pasajero en proceso existe.

Figura 6: Crear la Entidad Pasajero

En esta versión del diagrama de secuencia aparecen dos nuevos tipos de mensaje: el mensaje 4: Existe Pasajero devuelve una confirmación del registro de pasajero al Controlador de Pasajeros; mientras tanto, el mensaje 5: Crear Pasajero crea un nuevo objeto del sistema, Pasajero. Aquí, el título del mensaje, nemotécnico por demás, no es el que advierte de la creación del objeto, es más bien el lugar en el diagrama donde aparece la instancia recién-creada, mucho más abajo de donde inician las demás líneas de vida de esta realización.

Bueno, al parecer ya tenemos las identidades de todos los seres interactuantes que nos permitirán terminar de implementar el caso de uso Ingresar al Sistema o, al menos, uno de sus escenarios. El paso 4 del caso de uso: El sistema busca los datos del pasajero, valida que el número y la clave del mismo coincidan con los registrados previamente, se puede implementar como lo muestra la figura 7.

Figura 7: Diagrama de Secuencia del Caso de Uso Ingresar al Sistema (versión 1 – Beta)

La imagen también muestra los demás pasos de la secuencia básica del caso de uso. Observamos que la Entidad Pasajero se convierte en una fuente de información para el resto de elementos del modelo ya que representa, como establecí antes, un pasajero real.

En esta versión del diagrama también aparece un nuevo tipo de mensaje (8: Validar Clave). Este es un mensaje Reflexivo (o Auto-Mensaje), en el que el origen y el destino del mensaje son el mismo objeto. No confundir con mensaje recursivo, que es un mensaje reflexivo que se ejecuta recursivamente (se llama a sí mismo durante su ejecución).

De otro lado, los mensajes 11 y 12 comunican directamente la interfaz de usuario con la entidad Pasajero. Si volvemos a los patrones arquitectónicos quizás deberíamos evitar este tipo de interacción y pasar siempre a través del Controlador de Pasajeros. Esta es apenas una primerísima versión, bien podrían existir algunas otras antes de lograr una que sea definitoria para el sistema.

De Estereotipos y Otros Menesteres

Un estereotipo es el mecanismo que proporciona UML para que podamos extender las construcciones útiles de diseño. Un estereotipo puede ser visto como un clasificador (o tipificador) de clases o de otros elementos del lenguaje, es decir, adicionan un nuevo nivel al árbol de jerarquías en un modelo. Los estereotipos también sirven para representar objetos (físicos o virtuales) de una manera más cercana a la realidad de los mismos. De esta forma, Página Web (o Página HTML o Página ASP), Formulario Windows, Controlador, Entidad del Dominio, Colección, Tabla y Procedimiento Almacenado son estereotipos válidos que aplican al elemento base Clase de UML, mientras que Reporte, Proceso por Lotes, Ingreso de Datos y Transacción bien podrían ser estereotipos aplicables al elemento base Caso de Uso de UML.

La sintaxis de estos clasificadores es: <<Nombre del Estereotipo>>, como en <<Colección>>.

Figura 8: Diagrama de Secuencia del Caso de Uso Ingresar al Sistema con Estereotipos

Algunos de estos estereotipos (usados en el ejemplo), cuyo uso se ha difundido ampliamente en la comunidad de desarrollo, ya tienen su propia sintaxis, como revelo en la figura 8. Ingresar al Sistema tiene un estereotipo boundary (límite), Control de Pasajeros y Catálogo de Pasajeros tienen un estereotipo control, mientras que Pasajero tiene un estereotipo entity. Cada uno de estos clasificadores tiene también su propia semántica: las clases límite (llamadas así porque tienen el estereotipo boundary) representan interfaces con los usuarios o con otros sistemas; las clases controladoras son las responsables de manejar el flujo o la lógica de un caso de uso y coordina la mayoría de sus acciones; por su parte, las clases entidad simbolizan las unidades de información operadas en el sistema, normalmente son elementos pasivos y persistentes en cuanto muchas veces la información que encapsulan en almacenada en algún tipo de repositorio de datos.

En esta figura, también aparece una Nota de UML, que es el equivalente de un comentario en un lenguaje de programación como C++ o Java. Las notas se pueden asociar a una línea de vida, a un mensaje, a un argumento del mensaje o a cualquier otro elemento sustancial del modelo.

Comentarios Finales

Los diagramas de secuencia pueden ser usados en distintas etapas del ciclo de vida, desde el análisis primitivo de los casos de uso, empleando abstracciones clave del sistema, hasta el diseño detallado, explotando muchos de los recursos del lenguaje de modelado unificado. De esta manera, constituyen un conducto natural entre la especificación de requisitos funcionales (casos de uso) y no funcionales por parte de los Analistas y Arquitectos del software y la implementación y prueba de los mismos por parte de los Programadores y Probadores del sistema.

Que cuántos diagramas son necesarios por caso de uso es una cuestión que dejo a las condiciones particulares de cada proyecto y dentro de este, a cada caso de uso. Primero es importante reconocer que no todos los casos de uso necesitan de un diagrama de secuencia para ser implementados (y en este subconjunto quizás entre el propio caso de uso que usé de ejemplo y que quizás solo sirve para ilustrar los principales conceptos de la realización de casos de uso). El paso a seguir es entonces decidir cuáles son los casos de uso que definen la arquitectura del sistema, es decir, los más complejos o riesgosos desde el punto de vista arquitectónico; de estos, los escenarios que abarquen más elementos del modelo (extensión) y que incluyan muchos mensajes entre ellos o mensajes que impliquen procesos delicados o laboriosos (profundidad), son los mejores candidatos, los más útiles, para diseñar con ellos el sistema a través de diagramas de secuencia. Habitualmente, estos casos de uso son los que se desarrollan durante la fase de Elaboración del proyecto y a menudo requieren de información suplementaria para su diseño: requisitos especiales, arquitectura, restricciones de diseño, longitud y tipos de datos y al final del diseño, restricciones de la plataforma de implementación. Los demás casos de uso, aquellos que son más fáciles o directos de implementar encontrarán, si hicimos bien el trabajo, un camino de ida hacía los elementos (clases, objetos, controles, tablas) que se usaron para realizar los primeros.

Los diagramas de secuencia constituyen así un medio de comunicación efectivo que cura esa fisura, a veces insondable, a veces abierta, que supone el paso de la especificación de requisitos a la programación de los sistemas de cómputo. Ahora bien, lograr comunicar un diagrama, y por extensión un modelo, demanda discernimiento y práctica, pues el diseño (orientado a objetos) de software es por ley un proceso formal y para ejecutarlo debemos adquirir los fundamentos (que rayan en lo estrictamente teórico) para que luego la práctica habitual nos permita perfeccionar la técnica y desarrollar mejores productos en cada nuevo intento.

¡Funciona para mí!

Referencias

¹Object Management Group –OMG. UML Infrastructure Specification, v2.1.1. Page 9.

^2,3,4,5,6,7Salazar Caraballo, Luis A. Prolegómenos Sobre el Lenguaje de Modelado Unificado

⁸Object Management Group –OMG. UML Superstructure Specification, v2.1.1. Page 457.

⁹Object Management Group –OMG. UML Superstructure Specification, v2.1.1. Page 489.

¹⁰Object Management Group –OMG. UML Superstructure Specification, v2.1.1. Page 491.

Lectura Fundamental Siguiente: “Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)”

Lecturas Fundamentales 9

2007-06-25T11:44:00.000-05:00

Lectura Fundamental Anterior: “RUP: Fase de Concepción”

Lectura # 9
RUP: Fase de Concepción, Parte 2

“¿De dónde viene esto? Esta búsqueda, esta necesidad de solventar los misterios de la vida..., cuando las más simples preguntas nunca han sido contestadas.
¿Por qué estamos aquí? ¿Qué es el alma? ¿Por qué soñamos? Puede que sea mucho mejor si dejáramos de buscarlas. Sin investigar, sin anhelar. Esa no es la naturaleza humana. No está en el corazón humano.
¡Ése no es el motivo por el que estamos aquí!”

Héroes (Capítulo 1, “Génesis”)

Según las creencias de algunas tribus primitivas de la India, la Tierra era una enorme bandeja de té que descansaba sobre tres enormes elefantes, los que a su vez estaban sobre la caparazón de una tortuga corpulenta. En otra geografía, los antiguos egipcios mitificaron el cielo como una versión etérea del rio Nilo, a través del cual el dios Ra (el Sol) navegaba de Oriente a Occidente cada día, regresando a su sitio de partida por los abismos subterráneos donde residen los muertos; para ellos, los eclipses eran inducidos por ataques de una serpiente a la embarcación de Ra.

Así comienzan los proyectos de software: con usa serie de afirmaciones que a veces distan mucho de la realidad. Hacer que la Tierra efectivamente sea redonda, que el cielo sea un reflejo fantástico de las cosas en el cerebro humano y que los eclipses realmente se provoquen a medida que la luz procedente de un cuerpo celeste es bloqueada por otro, es una tarea ardua que requiere de tiempo, de foco, de actitud. Es la faena del Analista del Software.

En términos simples, en la Concepción buscamos un acuerdo con los usuarios sobre lo que hará el sistema. Durante esta fase atendemos cuidadosamente cada palabra de los usuarios, indagamos por el problema y el problema detrás del problema, nos movemos precisamente en el espacio del problema y desde ningún punto de vista pensamos en la solución. Bueno, hasta cierto grado. Una vez que hayamos entendido y acordado esa cuestión, resumida con diligencia en el documento de Visión y Alcance y tengamos claridad sobre el impacto, sobre los afectados y sobre lo que podrían ser los beneficios de una posible solución, entonces nos movemos al espacio de ésta, donde consideramos las características mayores del software a producir.
Estas características están en el nivel intermedio entre las necesidades de los usuarios y los requisitos detallados de la solución, de tal manera que constituyen un puente estructural entre las unas y los otros y definen la organización del sistema.

Hacer la transición entre lo que es y lo que será, enfrentarse a la ambiciosa tarea de prever el futuro cercano (¡a veces incierto!) de un proyecto de tecnología informática, con la profundidad y el rigor necesarios para calcar en palabras e imágenes las ideas y los sueños de docenas, quizás de cientos de usuarios, es algo que sólo la perspicacia y la sabiduría del Analista del Sistema es capaz de lograr.

El Analista de Requisitos

Gran parte de la responsabilidad del éxito de la fase de Concepción de un proyecto depende del Ingeniero de Requisitos, Analista del Software o Analista de Requisitos.

Analizar el problema de los usuarios comienza con la búsqueda y concertación de un vocabulario común, un glosario que sirva de referencia para todos los interesados en el proyecto, desde los mismos usuarios, los administradores del proyecto, los diseñadores y arquitectos, los programadores, los probadores y cualquier otra persona que requiera información sobre el proyecto y el producto a construir. En paralelo, el Analista busca actores y casos de uso (el mecanismo último para elicitar, especificar y administrar los requisitos del software), es decir, quién hará qué en el sistema (no puedo pasar por aquí sin permitirme remitirlos a mis cinco primeras Lecturas Fundamentales, donde abordé ampliamente este asunto de los casos de uso). Aquí el orden altera el resultado, por eso resalto que primero debemos conocer a los actores que jugarán un papel en el sistema y que luego ubiquemos sus necesidades como organismos primarios de funcionalidad en el software por desarrollar. Uno de los grandes motivos de fracaso en proyectos de software es que al final se encuentran en ellos funciones o módulos completos que nadie solicitó, que nadie necesitaba; también, funcionalidad equivocada. Eso se debe a que no anticipamos con quien o quienes iba a interactuar nuestro sistema.

El espiral de actividades del Analista se complementa con el desarrollo de la Visión del proyecto, condición sine qua non para terminar la fase de Concepción. Pero durante ese desarrollo, los Analistas nos enfrentamos a demasiadas posibilidades y muchas de nuestras aseveraciones (a manera de especificaciones) pueden vacilar porque reflejan puntos de vista coartados y hasta extravagantes de una sola persona o de muchas personas que no se ponen de acuerdo entre ellas. Es labor nuestra encontrar a los individuos adecuados, a los representantes apropiados de los usuarios, ojalá con distintos puntos de vista, conocimiento y experiencia, y entrevistarlos para así poder delinear un marco conceptual y temporal en el que esa Visión se lleve a cabo antes de terminar con el presupuesto del proyecto.

Los Analistas pasamos (o deberíamos pasar) de transeúntes pasivos en materia del conocimiento del negocio que nos ocupa a ser coreógrafos activos del proceso previamente expuesto por los usuarios. En un sentido limitado esto quiere decir que primero debemos escuchar. Un Analista que hable mucho en las primeras de cambio con los usuarios corre el riesgo de caer en el conductivismo, o sea, llevar al usuario por donde cree que debería ir, cuando en realidad debe ser él (o ella) quien conduzca su propio destino. Si ya tenemos experiencia en el negocio debemos incluso estar más atentos porque entonces caemos en el síndrome de la copa medio llena, cuando en realidad está medio vacía; esto es, el conocimiento previo evita que escuchemos como ávidos observadores las recién descubiertas necesidades de nuestro interlocutor.

Después, cuando haya suficientes exposiciones de los usuarios, finalmente empezaremos a descodificar sus palabras, sus ideas, sus verdades, mediante un proceso de ingeniería que las convierta en expresiones que se puedan ejecutar en un computador, que sean factibles de automatizar. Eso significa entonces que nos hemos convertido en conocedores de ese negocio (o de esa parte específica del negocio), con lo que bien podríamos contribuir al mejoramiento del mismo poniendo de manifiesto las tareas repetitivas, las posibles ambigüedades, las actividades imposibles y las faltantes en el proceso de la organización para la cual desarrollamos el sistema. Eso simboliza ser “coreógrafos activos.”

Al definir la visión, es fundamental comprender el marco temporal que tenemos para hacerla realidad. Nos enfrentaremos a diferentes tecnologías, condiciones y personas. Es importante que quede claro qué hará el producto de software, qué no hará y con qué se hará, lo mismo que los riesgos preexistentes.

En la parte final de la Concepción, aceleramos el proceso y disponemos las estrategias y las herramientas para la próxima fase: Elaboración. Nuestro trabajo tendrá grandes repercusiones sobre el resto del proyecto y de las personas involucradas en el. Entrarán el Arquitecto y el Diseñador, lo mismo que el Programador y el Probador, se crearán las clases y los componentes, se integrarán las partes y finalmente se ensamblará un producto que se pondrá a disposición del usuario que lo concibió.

Pero todo comienza aquí, en la Concepción; en consecuencia, el futuro del proyecto está fijado por la mayor disposición, el mayor y mejor esfuerzo y de la calidad del tiempo y del proceso que usemos en esta fase los Analistas del Software.

De Artefactos y Otros Menesteres Durante la Concepción

El resultado del proceso siempre debe documentarse para que quede una prueba fehaciente y toda la fundamentación de lo que será. RUP proporciona algunas herramientas a manera de plantillas, agrupadas en Dominios de Productos de Trabajo, relacionadas unos con otros sobre la base de recursos, temporalidad o interrelación entre ellos, para que podamos concluir nuestro trabajo. En el caso del subdominio de los Requisitos, encontramos:

La Visión y el Alcance. Este artefacto define la vista de los interesados sobre el producto a ser desarrollado, especificado en términos de las necesidades clave de esos interesados y de las características del software. Contiene un perfil o resumen de los requisitos centrales visionados (el corazón o núcleo del sistema) y de esta forma suministra la base contractual para los requisitos técnicos más detallados. En breve, el documento de Visión captura la esencia de la solución imaginada en forma de requisitos de alto nivel y restricciones de diseño que dan al lector una visión del sistema a ser desarrollado desde una perspectiva de requisitos comportacionales. Además, facilita una entrada al proceso de aprobación del proyecto y está, de esta forma, íntimamente relacionado con el Caso del Negocio (del que hablaré en otra oportunidad). El documento de Visión comunica también el “por qué y qué” fundamental del proyecto y es un indicador contra el cual todas las decisiones futuras deberían ser validadas. Otro nombre usado para este artefacto es el Documento de Requisitos del Producto.

En general, este documento está escrito usando un léxico del dominio de los usuarios líderes y finales del sistema y son ellos quienes en última instancia establecen la completitud y la exactitud del artefacto.

El responsable directo, el hacedor de este documento es el Analista del Software.

La Especificación de Requisitos del Software. Por su parte, este artefacto captura los requisitos del software para todo el sistema o para una porción de el. Se enfoca en la recolección y organización de todos los requisitos alrededor del proyecto, tanto funcionales (lo que hace el sistema) como los no funcionales (aquellos aspectos de usabilidad, confiabilidad, desempeño, escalabilidad y restricciones de diseño, implementación y despliegue del software que afectan el producto). Cuando no se usa la técnica de los casos de uso, es en este documento donde consignamos el semblante funcional del sistema tal cual será implementado posteriormente. Si usamos casos de uso, en cambio, dejamos aquí el detalle de aquellos requisitos transversales y reusables del software, aquellos que se usan en distintos ámbitos del producto. En cualquier caso, los requisitos no funcionales encuentran aquí su repositorio absoluto, aunque en ocasiones estos requisitos son expuestos en un Documento de Especificaciones Suplementarias, que también puede incluir requisitos legales y regulatorios, lo mismo que el uso estándares de distinto tipo.

Como antes, el garante inmediato, el productor de este documento es el Analista del Software.

Sin embargo, muchas personas en el equipo del proyecto usan la Especificación de Requisitos del Software:

Los diseñadores lo usan como referencia al definir responsabilidades, operaciones y atributos en las clases y cuando ajustan las clases al entorno de implementación.
Los programadores referencian el documento buscando insumos para la implementación de clases.
El gerente del proyecto lo usa para planear las iteraciones.
Los probadores lo usan para definir las pruebas que serán requeridas.

La Especificación del Caso de Uso. No me extenderé en este apartado. Las cinco Lecturas Fundamentales iníciales describen ampliamente esto del Caso de Uso. Habrá más, pronto.

Algunos otros artefactos importantes durante la Concepción y el resto del proyecto, que bien podrían hacer parte de uno de los anteriores o simplemente poseer su propio repositorio, son:
El Glosario, que define términos importantes usados en el proyecto; constituye el carácter léxico-gráfico del proyecto y del producto. Los Atributos de los Requisitos, que describe los atributos de y dependencias (trazabilidad) entre los requisitos, importantes a la hora de administrar los cambios desde la perspectiva de los requisitos. El Plan de Manejo de Requisitos, que describe los artefactos de requisitos usados en el proyecto, los tipos de requisitos y sus atributos respectivos, especificando la información a recolectar y los mecanismos de control a ser usados para medir, reportar y controlar los cambios a los requisitos del producto.

Por último, pero no menos importante, está el Modelo de Casos de Uso, que sirve como un medio de comunicación y como un contrato entre el usuario líder, los usuarios finales y los desarrolladores (y estoy usando el término desarrolladores en un sentido amplio con el que denoto realmente a todos los miembros del equipo del proyecto) sobre la funcionalidad del sistema. El modelo de casos de uso permite que los usuarios validen que el sistema será lo que ellos esperan y que los desarrolladores construyan lo que se espera del producto. Este modelo está compuesto de casos de uso y de actores y de las relaciones entre ellos. Por supuesto, va más allá de un simple diagrama.

Y ya desde la Lectura Fundamental 7 he mencionado artefactos como la Lista de Riesgos, el Plan de Desarrollo de Software (que incluye como mínimo el Plan Maestro de Iteraciones y la Agenda del proyecto) y el Plan de Pruebas cuya responsabilidad recae más sobre el Gerente del Proyecto u otros integrantes del equipo de desarrollo.

Quiero aclarar que el hecho de que no haga el mismo énfasis en estos últimos artefactos que en los primeros no quiere decir que estos sean menos relevantes que aquellos. Es una mera cuestión de espacio y de tiempo. Quizás en otra ocasión, en otra Lectura, aborde con más detalle algunos de estos documentos. Lo que sí es importante tener en cuenta es que la elaboración de uno o más de estos documentos (de todos los que he expuesto) depende del tipo de proyecto: si el proyecto es grande, requiere de más rigor documental y de más contratos y puesto que más personas estarán interesadas, la necesidad de usar cada artefacto por separado es mayor. En proyectos pequeños, de menos carácter ceremonial, varios de estos artefactos se pueden combinar en uno solo pero a la postre el resultado será el mismo.

Sobre la Arquitectura Preliminar

Ninguna disertación sobre el Inicio de un proyecto estará completa sin hablar de la Arquitectura Candidata. Por allá en la segunda mitad de la fase, el Arquitecto del Software recibe del Analista los insumos necesarios para abordar la Solución. Esta se expresa en términos de vistas o perspectivas, empezando por la vista funcional, arquitectura funcional o vista de casos de uso; ésta es un compendio de los casos de uso que precisamente “definen” la arquitectura, o son los más complejos arquitectónicamente (y la complejidad es un asunto espinoso sobre el que únicamente el arquitecto tiene potestad). El arquitecto incluso puede desviar la atención del analista hacia un grupo distinto de casos de uso y solicitar el detalle de estos para validar efectivamente dicha complejidad. También puede requerir el diseño e implementación de una o más pruebas de concepto arquitectónicas con el ánimo de comprobar la factibilidad técnico-científica de implementar una parte del software que se prevé problemática o en la que no se tiene experiencia anterior.

En un mundo ideal, es deseable que el arquitecto proponga más de una arquitectura candidata y que sea un comité (de arquitectos o de varios miembros del equipo desarrollador) el que decida más adelante (durante la Elaboración) cuál es la mejor alternativa para las necesidades actuales.

En el Final

Cuando un proyecto de Tecnología Informática comienza no damos cuenta del abismo colosal de realidad inexplorada que se expande ante nuestras mentes. La búsqueda inicia aquí y es nuestro compromiso revelar esas ambiciones y estrechar las contingencias de los usuarios, concebir la solución, pasar de observadores pasivos de una organización a ser coreógrafos activos de su proceso o, al menos, de parte de el. A medida que nuestro conocimiento de ese proceso aumenta, se abre la posibilidad de construir mejores artilugios de cómputo para los usuarios. Y salvo que se produzca una catástrofe natural (que en este contexto quiere decir que se desborden los sueños de los usuarios, o que dejemos que esa visión rebase la capacidad técnica y presupuestal del proyecto), o un colapso ocasionado por factores que van más allá de lo técnico y caen en lo legal o regulatorio, estamos en camino de alcanzar, en un marco de tiempo más o menos previsible (¡estimable!), la implantación de un producto de software de alta calidad que satisfaga o resuelva las necesidades elementales de nuestros usuarios.

Y lo que hará que esto sea posible es la configuración y el seguimiento de un proceso de Ingeniería maduro para las características específicas de ese proyecto en particular. En última instancia, haremos que sea permisible plasmar nuestra meta si disponemos de las herramientas y técnicas más o menos como lo he expuesto en estas Lecturas Fundamentales. El aprovechamiento de ellas (de las herramientas y de las Lecturas) es el primer paso para convertirnos en mejores profesionales de la Ingeniería del Software.

Referencias

Algunas de las características y conceptos expuestos aquí se basan en la documentación de IBM Rational Unified Process.

Lectura Fundamental Siguiente: “Realización de Casos de Uso: De los Objetos y sus Interacciones”

lucho.salazar@gmail.com

Lecturas Fundamentales 8

2007-03-08T07:33:00.000-05:00

Lectura Fundamental Anterior: “RUP o Todo lo que quisiste saber alguna vez de RUP y no te atreviste a preguntar…”

Lectura # 8
RUP: Fase de Concepción

“No hay nada más difícil de emprender, ni más dudoso de hacer triunfar, ni más peligroso de manejar, que el introducir nuevas leyes.”
Nicolás Maquiavelo (El Príncipe, 1513)

“In principio creavit…”
Génesis 1 {1:1}

Inicio o Concepción es la primera fase de RUP. El nombre no es importante, solo la meta es importante. Lo realmente trascendental es el objetivo que buscamos durante este período de gestación del proyecto: complementando lo que dije en la lectura fundamental # 7, la finalidad cardinal de esta fase es establecer la visión y el alcance del proyecto y del sistema, lo que se hará y no se hará dentro del proyecto y más aún, lo que hará y lo que no hará el producto a construir.

Para ello, RUP nos proporciona herramientas, a manera de mecanismos y maniobras, que bien usadas nos llevan de la mano hacia la consecución del objeto primario que nos ocupa: obtener un acuerdo con todos los involucrados sobre los objetivos del ciclo de vida para el proyecto.

Pero antes de abordar detalladamente la fase de Concepción como la explica RUP, quiero referirme al significado de las características del proceso durante la misma.

RUP es Dirigido por Casos de Uso y es Centrado en la Arquitectura

Esto significa que los casos de uso son la base para el resto del proceso de desarrollo. Durante la fase de Inicio, cuantificamos y cualificamos los requisitos funcionales del sistema en términos de casos de uso. Estos se convierten en el insumo para:

Crear y validar el modelo de diseño de la solución
Diseñar la arquitectura del sistema
Definir los casos y procedimientos de prueba en el modelo de pruebas
Planear las iteraciones
Elaborar la documentación de usuario
Hacer el despliegue del sistema
Sincronizar el contenido de los diferentes modelos que forman el sistema

Los casos de uso también son usados para modelar el negocio, actividad que pocas veces es tenida en cuenta a la hora de entender el comportamiento sistemático de una organización.

Cualificar los casos de uso quiere decir en el contexto del proceso que el Arquitecto del software debe hacer una priorización de los mismos desde el punto de vista arquitectónico. Es decir, establecer cuales son los casos de uso que definen la arquitectura o que tienen un impacto mayor en la misma. Para ello, los Arquitectos ponemos de manifiesto nuestra experiencia en proyectos anteriores y similares, si es posible, para reconocer los casos de uso arquitecturales: El ciclo de vida del caso de uso, el número y la calidad de los elementos estructurales (tanto de arquitectura como de diseño como de implementación) que se requieren para implementar el comportamiento del caso de uso en el sistema, requisitos de desempeño, confiabilidad, soportabilidad, concurrencia y restriccio-nes de diseño, la complejidad algorítmica asociada al caso de uso, el número de escenarios del caso de uso, el ranking del caso de uso desde el punto de vista de su criticidad (esto es, si el caso de uso es requerido u obligatorio, o importante, o adicional –normalmente los casos de uso arquitectónicos se cuentan entre los dos primeros), el grado de novedad de la tecnología y las estrategias disponibles para implementar el caso de uso o, en otras palabras, la experiencia del equipo de desarrollo en el uso de tal o cual tecnología o conjunto de técnicas para resolver un problema dado, son todas variables relevantes a la hora de catalogar o evaluar los casos de uso desde una perspectiva de arquitectura.

La fase de inicio es exploratoria, los casos de uso, todavía en estado primitivo, corren por un río de aguas diáfanas que se precipitan desde la mente de los usuarios como huevos prehistóricos. Encontrarlos, darles un lugar en el sistema, clasificarlos, esbozarlos, modelarlos y finalmente presentarlos, es lo que hacemos como analistas durante este período del proyecto. Una vez aprobado el modelo, los casos de uso rigen los designios a veces insondables a veces meta-humanos de todo el proyecto. A los casos de uso no se les puede poner limitantes técnicas y el equipo de desarrollo debe mantenerlos como un libro abierto de referencia para decidir siempre el siguiente paso. Eso significa “dirigido por casos de uso.”

La arquitectura del software, por su parte, asoma tímida durante la concepción, a manera de arquitectura candidata o preliminar y debería contemplar más de una posible solución, un conjunto pequeño de alternativas de cómo se va a implementar el software y la estrategia que usaremos para abordar el tratamiento de los requisitos suplementarios o no funcionales: la vista de casos de uso o funcional, subconjunto propio del modelo de casos de uso, una vista lógica de alto nivel y quizás una perspectiva del despliegue de la aplicación, surgen de la mente creativa del arquitecto, cual visión futurista de lo que será, de cómo lucirán las entrañas del sistema una vez esté construido. Y sea cual fuere la decisión, la elección que tomemos en la siguiente fase del proyecto, la arquitectura es desde todo punto de vista restrictiva, circunscribe el diseño y, consecuentemente, la implementación y el despliegue de la solución software que se conciba. Pero a partir de ella se abordan y mitigan los riesgos técnicos del proyecto, durante las primeras iteraciones del mismo; también se construyen las bases o cimientos del sistema, unas en las que todos los requisitos conocidos y algunos de los no conocidos tengan cabida; por supuesto, la arquitectura es el eje medular alrededor del cual se construye la solución, se planea y se controla el proyecto y también, en torno al cual se asegura la calidad del producto. Eso significa “centrado en la arquitectura.”

Para el Gazafatonario IT

A manera de inventario, y puesto que esto no es más que un Gazafatonario, la palabra Conceptualización[1], aunque aparece en algún diccionario de la lengua española definida simplemente como: “f. Elaboración detallada y organizada de un concepto a partir de datos concretos o reales” no es aceptada por la Real Academia de la Lengua Española. Así que seguiremos usando Inicio o Concepción para referirnos a la primera fase del ciclo de vida de acuerdo a RUP.

Roles y Responsabilidades Durante Concepción

Un Ingeniero de Procesos, un Gerente de Proyectos, al menos un Analista de Requisitos, un Analista del Negocio y un Administrador de la Configuración y el Versionamiento son los responsables de iniciar el proyecto. Con ellos, los usuarios, clasificados en Usuarios Líderes, Usuarios Finales y otros Involucrados (stakeholders es el término que nos llega del inglés) son los encargados de dictar el problema (y el problema detrás del problema, la causa raíz), sus necesidades, y hasta sus ambiciones, sus sueños y sus esperanzas. Más adelante, un Especificador de Requisitos (realmente un escritor técnico de casos de uso que bien podría ser el mismo analista de requisitos –de hecho casi siempre lo es) y un Arquitecto del Software, se unen a los anteriores para establecer las características (de alto nivel) del software, los primeros requisitos funcionales (a manera de casos de uso) detallados, los requisitos no funcionales y la misma solución de software expresada en términos arquitectónicos y de diseño.

Vamos por partes.

El Ingeniero de Procesos

Sí, RUP es un proceso configurable y adaptable a cada proyecto. Es así como lo leen, a cada proyecto. La primera conclusión que viene a mi mente, aunque reiterativa, tiene que ver con la forma de abordar el proceso. Recordemos que el proceso expone prácticas que han funcionado alguna vez, pero que no deberíamos seguir al pie de la letra, cual ensayo de laboratorio.

Un proyecto tiene condiciones muy particulares: el tipo de organización, más exactamente, el contexto del negocio, el tamaño del esfuerzo de desarrollo del software, el grado de novedad, el tipo de aplicación, el proceso actual de desarrollo, los problemas actuales y sus causas primarias, los factores organizacionales, las actitudes y la complejidad técnica y de gestión son algunos discriminantes que el así llamado Ingeniero de Procesos debe tener en cuenta al momento de decidir el mejor de los caminos posibles del proceso para ese proyecto.

Previo a ello, debemos tener claridad sobre las influencias del proceso de desarrollo: factores del dominio, por ejemplo, entre los que se cuentan factores del dominio de la aplicación, del proceso de negocio a soportar, de la comunidad de usuarios y de las ofertas disponibles de los competidores; factores del ciclo de vida como el tiempo de salida al mercado, la vida esperada del software y las versiones futuras planeadas son igualmente importantes; factores técnicos, ni más faltaba, como los lenguajes de programación a usar, las herramientas de desarrollo, las bases de datos, los frameworks de componentes y los sistemas de software existentes, constituyen influjos de peso que actúan sobre el proceso de desarrollo, junto con otros factores organizacionales cuyo nombramiento, al menos, se escapa del alcance de esta lectura fundamental.

Sobre el tamaño del esfuerzo del proceso de desarrollo, tenemos en cuenta aspectos medibles como el número de líneas de código entregadas, el número de casos de uso, el número de personas por mes o por alguna otra unidad de tiempo, el número de clases y de componentes, el número de tablas y de procedimientos almacenados en la base de datos, entre otros, para cuantificar la influencia en el desarrollo: a mayor tamaño de proyecto, mayor tamaño de equipo de desarrollo, el contexto del negocio pierde importancia en favor de más formalidad y más visibilidad en los requisitos, en las interfaces y en los indicadores de progreso del proyecto. Adicionalmente, para equipos geográfi-camente dispersos, incluso transoceánicos, tenemos en cuenta aspectos cruciales de comunicación y el cambio del huso horario.

El grado de novedad es otra condición influyente que tengo en cuenta como ingeniero de procesos. Este grado de novedad es relativo al equipo de desarrollo y a la organización que lo envuelve: factores como la madurez de la organización y del proceso de desarrollo (medido vía CMMi o algún otro modelo similar), los activos del proceso, las habilidades actuales del personal, la composición y el entrenamiento del equipo y la adquisición de herramientas y otros recursos para el proyecto, son definitivos a la hora de configurar el proceso: si se trata de un sistema nuevo, establezco fases de concepción y de elaboración más largas y más iteraciones en esta última; también hago más énfasis en la captura y administración de requisitos, el modelo de casos de uso, la arquitectura y en la mitigación de riesgos. Entre tanto, para un sistema en evolución, enfatizo en la gestión de cambios y en la incorporación o no de código legado.
En breve, durante la concepción, el ingeniero de procesos además elabora el caso de desarrollo, prepara las plantillas y las guías para el proyecto y, con un especialista en herramientas, selecciona las herramientas más adecuadas para el proyecto. Son materias que tienen tanto extensión como profundidad y abordarlas bien podría ser objeto de futuras Lecturas Fundamentales.

Lo que sí tengo que decir antes de cerrar esta puerta es que el ingeniero de procesos es al proceso lo que el arquitecto es al sistema y recuerden: la calidad de un producto está determinada en gran medida por la calidad del proceso que se usa para desarrollarlo y mantenerlo[2].

El Analista de Procesos del Negocio

Hablo de procesos distintos. En el apartado anterior me refería al proceso de desarrollo de software, mientras que en este me refiero al conjunto de procesos mediante los cuales una compañía organiza su actividad para conseguir sus objetivos. Cada proceso del negocio se identifica por un repertorio de datos que son elaborados y operados mediante un conjunto de quehaceres, en los que ciertos agentes (trabajadores, proveedores, departamentos, entre otros) interactúan de acuerdo a un flujo de trabajo determinado. Además, estos procesos dependen de un conjunto de reglas de negocio que fijan las políticas y la arquitectura de la información de la empresa.

El analista de procesos del negocio o simplemente analista del negocio es el responsable de definir la arquitectura del negocio y los actores y casos de uso del negocio, lo mismo que la interacción entre ellos. El modelo producido por este analista delimita la organización desde el punto de vista del sistema a desarrollar.

Entender la organización es un aspecto clave en todo desarrollo de software: enterarse de los procesos de negocio, quienes intervienen en su ejecución, sus entradas y sus resultados, como se manejan las excepciones, como se mantiene la integridad de la información y la consistencia entre procesos; también, conocer hacía donde va la organización, las expectativas de los usuarios, la visión que ellos tienen sobre lo que será y no será el negocio en el futuro, al menos, durante el ciclo de vida esperado del sistema.

Ahora bien, idealmente, la construcción de sistemas de software es uno de esos buenos momentos para cambiar procesos de negocio, no porque el negocio tenga que adaptarse al nuevo sistema, sino porque el esfuerzo de revisión de tales procesos puede llegar a ser tan significativo, tan profundo, que se encuentren oportunidades de mejora. Esto, por supuesto, es completa responsabilidad de la organización para la cual se construye el sistema y el área de TI, como buena conocedora de estos procesos, debe apoyar el diseño y la implantación del nuevo modelo y de paso quedar con el nuevo conocimiento para futuros ejercicios de esta índole.

Por supuesto, este trabajo implica un tiempo y recursos adicionales considerables que casi nunca son estimados a la hora de emprender un proyecto de tecnología informática, de tal forma que la cautela y el tratamiento efectivo de las expectativas de nuestros clientes son recomendables.

El Gerente de Proyectos

Planea, maneja y asigna recursos, determina prioridades, coordina las interaccio-nes con los usuarios y mantiene el foco del equipo del proyecto. También establece un conjunto de prácticas para asegurar la integridad y la calidad de los entregables del proyecto. Es un orquestador, articula y coordina los movimientos que se den en el proyecto.

Es el gerente quien precisamente concibe el proyecto mediante la transformación de una idea inicial a un estado en el que, soportado en razones de peso, pueda tomar una decisión sobre continuarlo o abandonarlo. Para lo que nos ocupa la mayor parte del tiempo, este “abandonarlo” más bien se convierte en un “ajustar” algunas condiciones críticas del proyecto, como el tiempo, el talento humano necesario para llevarlo a cabo y, por consiguiente, el presupuesto y la estrategia para alcanzar el éxito.

Durante la concepción, el gerente del proyecto identifica y evalúa los riesgos, elabora un caso de negocio e inicia el proyecto. Más adelante, en la misma concepción, planea el proyecto, teniendo en cuenta las métricas, los riesgos, los criterios de aceptación del producto, las tácticas para la resolución de problemas, el proceso de aseguramiento de la calidad, la organización del equipo de desarrollo, los modos de monitoreo y control del proyecto y las fases e iteraciones del mismo. Para ello se alimenta de toda la materia prima que los demás responsables de la concepción le transmitan. Es el gerente quien también decide si se han alcanzado los objetivos de la fase de concepción y si es viable empezar la fase de Elaboración.

Tanto en Concepción, como en el resto del proyecto, el gerente tiene una perspectiva de mediana profundidad para poder izar los hilos del proyecto con mayor propiedad y asegurar, casi como un dogma, que se pueda hacer una entrega, que se pueda avanzar o, si por el contrario, que se deba replantear la técnica y reorientar el enfoque (corregir el rumbo). Y el final de la fase de concepción es buen momento para asegurarnos de la idoneidad (en cuanto talento, competitividad, aptitud) del equipo de desarrollo, de indagar si los miembros del equipo tienen las habilidades y destrezas suficientes, comparten todos la misma visión de lo que vendrá, soportarán la presión, están dispuestos a dar ese “delta de t” (y otros deltas) necesarios para triunfar en todo proyecto. Desde este punto de vista, el destino del proyecto, incierto hasta este punto, depende enteramente de su gerente.

Bueno, esto no lo dice ningún proceso, no está escrito en ningún lado, simplemente es y con eso basta.

Continuará…

Hace poco uno de mis revisores de cabecera me dijo que estas lecturas fundamentales estaban quedando muy largas. Yo les reenvío la inquietud, ¿ustedes qué piensan? En cualquier caso, les he dado suficiente tiempo, creo, para que hagan la mejor de las lecturas. Estoy atento, los escucho.

De todas formas, es evidente que esta lectura amerita otra parte, donde concluiremos con los aspectos más importantes de la fase de concepción. Hasta la próxima entonces.

Referencias

Algunas de las características y conceptos expuestos aquí se basan en la documentación de IBM Rational Unified Process.

1. Diccionario de la lengua española © 2005 Espasa-Calpe S.A., Madrid:
Conceptualización
f. Elaboración detallada y organizada de un concepto a partir de datos concretos o reales.

2. Basado en principios de Administración Total de la Calidad enseñados por Shewhart, Juran, Deming y Humphrey.

Lectura Fundamental Siguiente: “RUP: Fase de Concepción. Parte 2.”

lucho.salazar@gmail.com

Lecturas Fundamentales 7

2007-02-21T14:40:00.000-05:00

Lectura Fundamental Anterior: “De Procesos y de Humanos”

Lectura # 7
RUP o Todo lo que quisiste saber alguna vez de RUP y no te atreviste a preguntar…

RUP es un proceso punto.

¿Hace falta decir algo más? Sí, todo. Aquí vamos.

RUP es un proceso y una metodología y un framework. RUP nos habla de actividades, de responsables, de procedimientos de trabajo, de casos de uso, de arquitectura del software, de iteraciones e incrementos, de riesgos, de modelos y de modelado con UML, de análisis y diseño del software, de pruebas y control de calidad; RUP también nos habla de guías y listas de chequeo, de herramientas del proceso (no software no hardware), de herramientas de software para apoyar el proceso; y también de gerencia de proyectos, de control de versiones, de configuración y adaptación del proceso, de prácticas contextuales; RUP nos cuenta los porqué de las cosas o, al menos, hace un recuento de la experiencia de otros; RUP tiene dinámica y tiene estática; RUP proporciona mecanismos para que hagamos mejor nuestro trabajo y nos lleva de la mano hacia el éxito y hacia la calidad total.

Framework, Proceso y Metodología

Esto, por ningún motivo es un uso estándar. En el pasado encontré útil diferenciar proceso de metodología como explico a continuación: literalmente, un proceso es un conjunto de pasos para realizar algo, incluyendo quien hace que, cuando y todas esas cosas que expuse en la Lectura Fundamental #6. Estrictamente hablando, RUP no contiene nada de esto. Los flujos de trabajo y las actividades no están entretejidos en procedimientos específicos organizados en el tiempo. De esta forma, RUP es referenciado como un framework de procesos que contiene piezas de las cuales se puede escribir un proceso para una organización. Forzosamente, este proceso debería ser configurado para la organización y sus roles específicos, su estructura y sus objetivos, entre otros.

RUP también es una metodología. Esta afirmación quiere decir que RUP es una base teórico-conceptual detallada para hacer las cosas de cierta manera. Es como una enciclopedia. De este modo, cuando un proceso dice “escriba un caso de uso” hay mucha información en RUP sobre como y aún porqué escribir casos de uso.

Usando los términos así, se aclara la confusión en las empresas que hablan de “hacer el proceso” o “tener un proceso” cuando simplemente quieren decir que tienen algunos procedimientos de trabajo. Adoptar una metodología es algo más –significa involucrarse con un framework conceptual y un conjunto de métodos. Estos métodos entonces necesitan anidarse en procedimientos que concuerden con la organización.

En aquel tiempo también encontré otros dos términos relacionados a los anteriores que debía entender: método y técnica. El primero se refiere a una descripción detallada de quien hace que, cuando y como; se parece mucho a metodología, ni más faltaba, pero hay una diferencia substancial que haré evidente en breve. Mientras tanto, la técnica es mucho más detallada y, por consiguiente, aborda o trata un área muy especializada.

Esto también significa que un framework puede contener varios procesos, un proceso puede contener varios métodos y un método puede contener varias técnicas. Es difícil de decir en que punto se convierte una técnica en método, lo importante es que todos estos conceptos, concluí, es que son parte del mismo cuadro.

Como siempre, hice uso de Mi Gazafatonario para establecer definiciones más semánticas. Este fue el resultado:

Definición 14: Un framework se refiere a un número de bloques de construcción predefinidos con los cuales es posible configurar un proceso, método, etc.

Definición 15: Un proceso se refiere a una serie de acciones, cambios o funciones que entregan un resultado (un flujo). Cuando hablamos de RUP, es útil recordar que el proceso es lo que tiene lugar en el “mundo real” mientras que la descripción del proceso es lo que está documentado en el producto RUP como tal… ¡algunas veces éstas son dos cosas distintas!

Definición 16: una metodología se refiere al cuerpo completo de prácticas (una práctica es una forma regular y sistemática de realizar alguna cosa), procedimientos y reglas usados por quienes trabajan en una disciplina (por ejemplo en la IT); pero una metodología también se refiere al estudio teórico del análisis de tales métodos de trabajo.

Definición 17: un método, por otro lado, se refiere a solamente una de esas prácticas.

Definición 18: Una técnica se refiere al procedimiento sistemático mediante el cual una tarea compleja o científica se lleva a cabo.

Eso era entonces, era feliz e indocumentado y “el mundo era tan reciente, que muchas cosas carecían de nombre, y para mencionarlas había que señalarlas con el dedo."[1]

Hoy, estos conceptos tienen más vigencia que nunca.

Comentario del Autor

Confieso que a pesar de haber hecho docenas de presentaciones sobre RUP y de haber escrito algunos artículos al respecto, me encontré en una encrucijada al momento de abordar este nuevo volumen de lecturas fundamentales sobre el tema. Los enfoques pueden ser muchos: que si las características, que si las fases, que si las disciplinas, que si las actividades, que si las plantillas, en fin, eran muchas las posibilidades. Por fin inicié como acaban de leer, pero entonces algo, quizás sensato quizás absurdo, pasó por mi mente: acaso la mayoría de ustedes nunca ha tenido una primera vez con RUP. Entonces decidí volver a lo fundamental.

Aquí vamos otra vez.

Raíces

Para lo que nos interesa, RUP es un proceso de Ingeniería de Software que busca asegurar la producción de software de alta calidad, satisfaciendo las necesidades de un cliente (y estoy usando un espectro muy amplio de la palabra “cliente” al abordar desde usuarios finales y a otros involucrados hasta las organizaciones que de una u otra forma se ven impactadas por el software), con un plan y presupuesto previsibles.

Pero también podemos mirar a RUP como un conjunto extenso, en lo horizontal, y profundo, en lo vertical, de experiencias documentadas alrededor de los distintos procesos relacionados con el ciclo de vida de los sistemas. Son prácticas dispuestas es una dimensión estática que establecen estándares probados, en principio, para desarrollar software, a través de una dimensión dinámica: el tiempo. Los procedimientos están enmarcados en procesos, conocidos también como disciplinas o flujos de trabajo: Modelado del Negocio, Administración de Requisitos, Análisis y Diseño, Implementación, Pruebas, Administración de la Configuración y Control de Versiones, Administración del Entorno y, por último pero no menos importante, Gerencia de Proyectos. Entre tanto, el tiempo está dividido en Fases: Inicio, Elaboración, Construcción y Transición. A su vez, cada fase, esta fraccionada en etapas o ciclos pequeños llamados Iteraciones.

A través del tiempo hay que alcanzar hitos o cumplir objetivos, en cada fase y, dentro de ellas, en cada iteración. Para alcanzar esas metas, hay que llevar a cabo las funciones definidas en los distintos procesos que, a su vez, tienen objetivos más específicos. La suma de todos estos propósitos alcanzados resulta precisamente en la finalidad universal de todo proceso y RUP no es la excepción: la construcción de un sistema de software de calidad excelsa.

Metas

Inicio o Concepción es la primera fase de RUP. El propósito principal es que alcancemos un acuerdo entre todos los involucrados sobre los objetivos del ciclo de vida para el proyecto. Los involucrados, mejor conocidos como stakeholders, son todas las personas y entidades que de una u otra forma influyen o se ven afectados por el desarrollo del proyecto y por el producto que resulta del proyecto. Ejemplos de involucrados son: usuarios finales, todo el equipo de desarrollo, patrocinadores del proyecto (los productores ejecutivos), socios de negocios, proveedores, clientes, otras áreas de la compañía distintas a aquella para la cual se elabora el software, entre otros.

Al final de la fase de Inicio, revisamos los objetivos del ciclo de vida y decidimos proceder con el proyecto o cancelarlo. Esto último puede ocurrir porque no alcanzamos el hito de la fase o porque, al hacerlo, encontramos que no es posible, tanto técnica como financieramente (y con frecuencia una combinación de ambos factores), continuar con el proyecto.

En particular, durante esta fase elaboramos el modelo del negocio, de ser necesario, y establecemos la visión y el alcance del proyecto, es decir, lo que haremos y lo que no haremos dentro del proyecto; también definimos un plan de manejo de riesgos, lo mismo que diseñamos, implementamos y evaluamos una o más pruebas de concepto arquitectónicas, a criterio del Arquitecto del Software o de los analistas más experimentados del equipo. Estas pruebas se ejecutan para tener la tranquilidad de que distintas estrategias de índole técnica o tecnológica tendrán cabida durante la construcción del software, es decir, es posible realizarlas con éxito. Con todo lo anterior, elaboramos el Plan de Desarrollo de Software o, al menos, una agenda viable para el proyecto que defina tiempos y número de iteraciones potenciales por fase, lo mismo que el talento humano asignado a cada iteración.

Por su parte, el objetivo principal de la fase de Elaboración es delinear la arquitectura del software y proporcionar una base estable para el grueso del diseño e implementación en la siguiente fase. Pero además de bosquejar la Arquitectura, durante la Elaboración probamos esa arquitectura mediante la implementación de la funcionalidad más significativa (precisamente, la que tiene un mayor impacto en la arquitectura) y una evaluación de los riesgos técnicos del proyecto, es decir, los que tienen que ver con el desempeño esperado, la seguridad, la infraestructura requerida para correr el sistema, la usabilidad y otras restricciones de diseño y del entorno de desarrollo del software. Al final de la Elaboración obtenemos una arquitectura estable vía prototipos arquitectónicos sucesivos, que se construyen durante cada uno de los ciclos o etapas en los que se divida la fase.

Mas adelante, en la fase de Construcción, diseñamos, implementamos e integramos el software en su totalidad, basado en la arquitectura prescrita durante Elaboración. En esencia, la Construcción termina con lo que llamamos la versión βeta del producto, listo para someterlo a procedimientos de certificación de calidad. Durante esta fase realizamos pruebas que bien podríamos llamar Pruebas Alfa, completamos la capacidad operacional inicial del sistema y finalizamos la documentación del manual del usuario, cuando hay lugar a ello.

Al final, durante la fase de Transición, nos aseguramos de tener el software listo para entregar a nuestros usuarios quienes, revisan y aprueban todos los entregables del proyecto.

Por su parte, las iteraciones, durante las fases de Elaboración y Construcción sobre todo, tienen un único objetivo: la entrega de software ejecutable y su documentación asociada. Aunque tengo mucho por decir sobre el desarrollo iterativo, esta simple premisa, software ejecutable más documentación, encierra un gran significado que debería ser evidente para todos.

Conocer la intención de cada una de las fases del ciclo de vida nos da una idea inicial de las acciones a seguir para alcanzar tales metas. Les hablo de tareas por hacer, procedimientos por ejecutar, los que finalmente nos conducirán al resultado esperado: un producto de notable calidad y valor. Con esto quiero decir que pensamos en actividades antes que en “entregables”.
Estos últimos son consecuencia inmediata de aquellas, son el recipiente que debemos llenar.

Ahora bien, el propósito principal del Modelado del Negocio gira en torno a entender el problema actual de la organización objetivo e identificar mejoras potenciales; también, evaluar el impacto del cambio organizacional. Esto último debido a que un sistema de software trae un nuevo orden a las cosas, una nueva forma de desempeñar funciones y procedimientos en la organización. En esta disciplina también nos aseguramos de contar con un entendimiento común del negocio para el cual desarrollamos el sistema; y cuando digo común, me refiero a los usuarios, a los desarrolladores y a todos los demás involucrados en el proyecto.

A su vez, la disciplina de Requisitos establece y mantiene un acuerdo entre nosotros y los usuarios sobre lo que el sistema debe hacer; asimismo, define los límites y proporciona bases para la estimación de costos y tiempos para el desarrollo del sistema. Esta disciplina también aporta lo necesario para planear el contenido técnico de las iteraciones y permite definir una interfase de usuario para el sistema, conduciendo nuestro enfoque hacia las necesidades y metas de los usuarios. Un aspecto importante de este proceso de Requisitos es que expone las prácticas recomendadas para instaurar una buena comunicación con los usuarios y el resto de la organización destino del software.

Me queda bien decir en este punto de la lectura es que a menudo no se conoce donde termina la administración de requisitos y donde comienza el análisis y diseño del sistema. Si bien, el Analista del Sistema interviene en ambos procesos, debemos tener claro los límites de uno y otro, para no exponer a los usuarios a aspectos de corte técnico inherentes al Análisis o al Diseño, o aún a la misma Arquitectura del software. Durante la Ingeniería de Requisitos, el Analista del Sistema tiende a ser un Especificador de Requisitos; mientras tanto, durante el Análisis y Diseño, ese mismo Analista tiende a ser un Diseñador y, quizás, un Arquitecto.

Precisamente, el propósito de Análisis y Diseño es transformar los requisitos en un diseño del sistema a construir, adaptar ese diseño para que concuerde con el entorno de implementación teniendo en cuenta, entre otros, factores de desempeño y de usabilidad; Y es también este proceso el que nos ayuda a determinar una arquitectura robusta que albergue el sistema.
Importante es que la línea divisoria entre el Análisis y el Diseño del sistema es bastante tenue pero a la vez bien definitoria. Durante el análisis definimos una arquitectura candidata, ejecutamos una síntesis arquitectónica y analizamos el comportamiento del sistema; en tanto que en diseño, diseñamos componentes, base de datos y servicios, y hasta encontramos una actividad llamada Diseñar Casos de Uso, donde exhibimos todos los aspectos técnicos propios de un caso de uso.

Después del diseño está la Implementación, cuya finalidad es que podamos definir la organización del código, en términos de subsistemas de implementación organizados en capas. Es en este proceso donde convertimos los elementos de diseño en elementos de implementación (archivos fuentes, binarios, programas ejecutables, entre otros); también aquí probamos como unidades los componentes desarrollados e integramos e un sistema ejecutable los resultados producidos por cada uno de nuestros programadores.

Quiero enfatizar en lo de pruebas unitarias o pruebas de unidad. Éstas son ejecutadas por el Implementador, precisamente para verificar tanto la especificación como la estructura interna de una unidad de código, una clase, por ejemplo. Al validar que el componente está trabajando correctamente antes de someterlo a pruebas más formales, estamos asegurándonos de que la transición del código fuente al sistema ejecutable integrado será llevadera. Así como las pruebas hacen parte intrínseca y básica del desarrollo del software, las pruebas de unidad son congénitas a la implementación.

Ya que hablo de Pruebas, esta disciplina, que actúa como un proveedor de servicios a las demás disciplinas de RUP, nos permite enfocarnos en evaluar y valorar la Calidad del Producto mediante la búsqueda y documentación de defectos, y la validación y prueba de las suposiciones hechas en el diseño y en la especificación de requisitos vía demostraciones concretas. Los Probadores también aconsejan o asesoran sobre la calidad percibida en el software; de hecho, el equipo de pruebas es quizás la máxima autoridad del proyecto, dado el carácter restrictivo que tienen sus funciones. Ya alguna vez había señalado que en el futuro no habría gerentes de proyecto como los conocemos hoy, sino gerentes de calidad.

La documentación de RUP anota una diferencia interesante que existe entre la disciplina de Pruebas y las demás disciplinas en RUP: esencialmente, Pruebas encuentra y expone debilidades en el software. Es interesante porque para conseguir mayores beneficios, necesitamos una filosofía general diferente a la que usamos durante la Administración de Requisitos, Análisis y Diseño e Implementación. Estos tres procesos se enfocan en la completitud del software, mientras que Pruebas se enfoca en la incompletitud. Así que no es gratuito aquello de que es mala práctica que sean los mismos desarrolladores quienes ejecuten las pruebas. Además está demostrado que celularmente es cuasi-imposible que un desarrollador tome el camino requerido para encontrar lo que le hace falta a su creación.

Todavía hay más disciplinas. La de Despliegue, por ejemplo, nos guía sobre las actividades necesarias para asegurar que el producto de software esté disponible para los usuarios. Aquí, disponible no sólo quiere decir “en producción”, sino también utilizable para pruebas y demostraciones.

Todos los procesos anteriores, conforman las Disciplinas Básicas del ciclo de vida. Pero existen otros procesos, que son transversales a cualquier proyecto y sirven de apoyo durante todo el ciclo de vida de desarrollo: la disciplina de Administración de la Configuración y Versiones nos permite controlar y sincronizar la evolución del conjunto de Productos de Trabajo que componen un sistema de software. Por su parte, la disciplina del Entorno organiza los elementos del método que suministran el entorno de desarrollo de software que apoya al equipo de desarrollo, incluyendo tanto procesos como herramientas; al hacer esto, esta disciplina soporta los demás procesos.

En breve, la disciplina del entorno es la que nos provee los mecanismos clave para configurar y adaptar el proceso para cada proyecto, brindándonos herramientas para cuantificar y cualificar distintas variables que afectan el desarrollo de un producto de software incluyendo el tiempo y los recursos disponibles, la complejidad del producto, la tecnología a usar, la experiencia del equipo de desarrollo, el conocimiento que este tenga del negocio, el tipo de cliente final, información de la competencia y el grado de formalidad, entre otros.

Finalmente, la Gerencia de Proyectos exhibe las prácticas recomendadas para los procesos de Inicio, Planeación, Ejecución, Control y Cierre de proyectos (incluyendo el cierre de iteraciones y de fases). Esta disciplina nos propone actividades y estructuras para la planeación de proyectos, la administración adecuada de riesgos, lo mismo que para monitorear el avance del proyecto y gestionar las métricas del mismo.

Tendremos mucho espacio, en futuras lecturas fundamentales, para hablar de todos y cada uno de estos procesos. Lo importante, por ahora, es que para alcanzar cada una de estas metas, las actividades propuestas son dirigidas por los casos de uso, centradas en la arquitectura del software además de iterativas, es decir, se repiten una y otra vez, a lo largo de todo el proyecto, quizás hasta el cansancio. Esta última característica ciertamente es como una revolución, de hecho, entender el modelo de desarrollo por ciclos cortos de tiempo implica experimentar una profunda y quizás traumática transformación a varios niveles de nuestras creencias sobre la forma como desarrollamos software.

Aún hoy, muchos proyectos “rupizados” después, muchos años después, me pregunto si lo que hacemos más bien es una secuencia continuada de “cascadas” en vez de seguir prácticas realmente iterativas e incrementales.

Trataremos de dilucidar este y otros temas alrededor de RUP, por supuesto, en nuestra siguiente lectura fundamental.

Referencias

Algunas de las características y conceptos expuestos aquí se basan en la documentación de IBM Rational Unified Process.

1. Cien Años de Soledad, Gabriel García Márquez. Página 1.

Lectura Fundamental Siguiente: “RUP: Fase de Concepción”

lucho.salazar@gmail.com

Lecturas Fundamentales 6

2007-02-06T17:14:00.000-05:00

Lectura Fundamental Anterior: Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2

Lectura # 6
De Procesos y de Humanos

“Hay ciertos privilegios comunes a un escritor cuyos beneficios, espero, no haya razón para dudar; particularmente, que si no se me entiende, se debería concluir que algo muy útil y profundo se esconde debajo; y también, que si cualquier palabra o frase es impresa en un carácter diferente, debería pensarse que contiene algo extraordinario o ingeniosamente sublime.”
Jonathan Swift, A Tale of a Tub, Prefacio (1704)

Jochen Krebs dice en un artículo reciente: “Seguir un proceso de ingeniería de software implica un compromiso con la consistencia y estandarización.”1 Y más adelante expone: “Desde una perspectiva organizacional, emplear especialistas certificados en RUP crea un ambiente consistente para la comunicación y la colaboración entre los miembros del equipo del proyecto y los demás involucrados, lo cual es la base para la eficiencia y la productividad.”2

Esta misma convicción me acompañó desde el instante en que la irreparable voluntad del destino me condujo a usar RUP por primera vez hace ya unos seis años que, convertidos a “años TI”, bien podrían ser treinta o cuarenta. Pero también desde entonces me inquieta férreamente, como una espina clavada en el cerebro, el motivo por el cual en una cultura como la nuestra no hayamos logrado la madurez suficiente y necesaria para enfrentar todos y cada uno de nuestros proyectos con el éxito debido. Pues bien, este es un nuevo intento por remediar esta situación. Hablemos de Procesos.

Definición 13: Un proceso es un conjunto de pasos o acciones parcialmente ordenadas mediante las cuales se busca un objetivo. Un proceso define quién hace qué, cuándo hacerlo y cómo alcanzar ese objetivo.

Lo primero que se me ocurre agregar a esta definición sistémica es que no tiene nada que ver con artefactos documentarios o el puro acto de documentar. Lo aclaro porque en mis continuas asesorías todavía me encuentro con la excusa de “es que nosotros no seguimos ningún proceso porque no hay tiempo para documentar.” Ahora bien, en este contexto, “parcialmente ordenadas” significa que no siempre tenemos que seguir caminos iguales. Es otra aclaración importante porque tendemos a creer que un proceso es una receta o una fórmula que siempre debe llevar los mismos ingredientes y prepararse de idéntica forma y no es así: un proceso se configura o se adapta, no solo para cada empresa, sino para cada proyecto. Y para el caso de la TI, el objetivo del proceso es desarrollar un producto de software nuevo (y estoy usando un término bastante general al decir “producto de software” porque soy de los que consideran al software como un medio y el verdadero producto es el conocimiento contenido en el software), o hacer el mantenimiento de uno existente. Justamente, otro error común es creer que no podemos dar soporte a un sistema de software usando un proceso si este sistema no fue desarrollado originalmente usando ese proceso.

En la segunda parte de la definición, Quién se refiere a los practicantes, actuarios (no actores) en el sentido de actuar, o a los ejecutantes de las acciones. Normalmente es un equipo de personas y, hoy más que nunca, de máquinas y herramientas a nuestra disposición. Entre tanto el Qué da cuenta precisamente de las acciones o pasos que se ejecutan o llevan a cabo por esas personas o herramientas. Son funciones que se suceden en el tiempo, pero que se repiten continuamente una y otra vez (de forma iterativa) hasta alcanzar el resultado esperado. Se trata de tareas más o menos simples, muchas de ellas mecánicas, que se pueden hacer en días o en horas. Esta sucesión de momentos redundantes señalan el Cuándo del enunciado; son instantes que se multiplican durante un proyecto y en muchos proyectos, de tal forma que con el paso del tiempo podemos llegar a predecir con gran exactitud cuando pasarán y cuanto tardará su ejecución; al menos esa es la presunción al usar un proceso: estimaciones más precisas y la conversión del mal llamado “arte” de la programación de computadores en Ingeniería, en ciencia numérica que pueda ser cuantificada. Y finalmente, el Cómo, constituido por los medios, las herramientas (y no me refiero siempre a maquinaria) y las técnicas proporcionadas por el proceso, que no son más que una suma de prácticas documentadas que han funcionado al menos una vez para al menos una persona en al menos un entorno.

Esto último es muy importante asimilarlo con cuidado, porque también tenemos la tendencia a asumir que todo lo que está por escrito sirve para cualquier ocasión cuando una buena práctica es medir distintas variables relacionadas con el hábitat, con los miembros del equipo, con la economía, con la cultura y hasta con la idiosincrasia de las personas para decidir cual es la mejor trayectoria a seguir.

Un proceso se documenta: esto mejora su difusión en cada una de las dimensiones de la compañía que lo adopta, clarifica conceptos y estandariza el uso del mismo. También permite la medición del mejoramiento del proceso. Con esto en mente, un proceso se sigue: lo que pasa es que el seguimiento no es del tipo “receta de cocina”, es decir, no siempre tenemos que participar de acciones semejantes, construir artefactos semejantes, ni actuar tipo “robot” sistemático. Eso ocurre esencialmente porque los actuantes del proceso medimos además variables del ambiente en el que nos transportamos a través del ciclo de vida del desarrollo del software. Variables como el tiempo disponible, la criticidad y complejidad del software, el equipo del proyecto (aspectos como experiencia técnica, conocimiento del negocio y del proceso usado influyen), herramientas de apoyo, modo de utilización del proceso, entre muchas otras, se usan para adaptar el proceso al proyecto que está iniciando.

En ese orden de ideas, un proceso puede ser pequeño al comienzo: y es una buena práctica que sea pequeño para empezar a usarlo. De hecho, es posible emplear sólo una pequeña parte del proceso: la fase de inicio, por ejemplo, o solamente una disciplina como la Gerencia del Proyecto a lo largo de todo el ciclo de vida. De esta forma, luego de aplicar esa porción del proceso, medimos los resultados, mejoramos esa parte del proceso, de ser posible, y la divulgamos al interior de la empresa. Más adelante usamos otra fracción del proceso, quizás junto con la anterior, y vamos creciendo con el.

Y algo muy importante: un proceso no tiene que ser perfecto. Es más, ninguno lo es. Y hay más: un proceso nos indica que hacer bajo ciertas condiciones, que bien podríamos llamar “ideales”. Por ejemplo, un proceso no dice que hacer si al equipo de desarrollo le faltan dos personas intempestivamente o si hay problemas técnicos que no son solucionables a corto o mediano plazo. Lo que sí hace es dar ideas (prácticas documentadas) de qué hacer en casos como esos. En resumen: un proceso no dice que hacer en tiempos de crisis. Es en esos momentos cuando toda nuestra razón, nuestros conocimientos, nuestra praxis (hablo de los seres humanos actuarios del proceso) y nuestra pragmática se debe poner de manifiesto para superar el trance.

Importante es que un proceso vaya de la mano con un programa de entrenamiento para el manejo de las habilidades de las personas que usan el proceso. El proceso no hace nada por sí solo, ni las herramientas, son las personas las que, con cierto grado de conocimiento del proceso y de experiencia en el rito procesal, lo siguen, lo ejecutan. Lo que no debe ocurrir es que el proceso de pie a interpretaciones diversas. El proceso debe ser claro, no ambiguo, preciso, sin que ello quiera decir inflexible. Al final, el proceso debe contar con unas bases para el mejoramiento continuo de la calidad y he aquí la primera premisa de lo que se ha llamado Mejora de Procesos: “La calidad de un producto es determinada en gran medida por la calidad del proceso que es usado para desarrollarlo y mantenerlo”3.

Y para finalizar esta disertación sobre Procesos y Personas, me resta decirles que un proceso debe usar las mejores prácticas probadas en la industria, no sólo la última moda en materia de guías o actividades. Un proceso debe estar bien establecido en el medio donde se utilizará, ser familiar a los miembros del equipo de desarrollo, a los clientes, a los usuarios (de alguna forma), a los socios de negocios y a todos los involucrados en el proyecto. No podemos forzar el uso de tal o cual práctica que aprendimos en un libro de aparición reciente o que escuchamos en la conferencia de la noche anterior.

Y más aún, un proceso debe ser práctico, esto es, entregar la información que se necesita, cuando se necesita y en un formato y medio usable. Y con el temor de ser incisivo: el proceso debe adaptarse a las necesidades de quien lo usa, es decir, un proceso debe proporcionar los mecanismos para que sea configurable de acuerdo al proyecto.

¿Y todo esto qué tiene que ver con RUP? Pues bien, RUP es un proceso pensado en principio para desarrollar software. RUP posee todas esas características a las que me acabo de referir. La entrada de RUP son los requisitos, nuevos o cambiados; la salida de RUP es el sistema, nuevo o cambiado. Pero lo más importante, es un sistema de alta calidad, como lo exigen los estándares de la industria.

Pero para hablar de RUP tendremos todo un volumen, a partir de la próxima lectura fundamental. Por ahora quiero dejarlos con estas tres leyes del proceso de software, algo como para tener siempre presente:4

La Primera Ley del Proceso de Software

Los procesos solamente nos permiten hacer cosas que ya sabemos hacer.

El Corolario a La Primera Ley del Proceso de Software

No puedes tener un proceso para algo que no hayas hecho nunca ni que sepas como hacer.

La Creación Reflexiva de Sistemas y Procesos

1. La única forma de crear sistemas efectivos es a través de la aplicación de procesos efectivos.

2. La única forma de crear procesos efectivos es a través de la construcción de sistemas efectivos.

El Lema de la Tardanza Eterna

Los únicos procesos que podemos usar en el proyecto actual fueron definidos en proyectos previos, que son diferentes de éste.

La Segunda Ley del Proceso de Software

Solamente podemos definir procesos de software a dos niveles: uno demasiado vago o uno demasiado limitante.

La Regla de la Bifurcación del Proceso

Las reglas de los procesos de software muchas veces se dictan en términos de dos niveles: una sentencia general de la regla y un ejemplo detallado específico (valga el ejemplo: La Segunda Ley del Proceso de Software).

La Hipótesis Dual del Descubrimiento del Conocimiento

· Hipótesis Uno: Solamente podemos “descubrir” el conocimiento en un entorno que contiene el conocimiento.

· Hipótesis Dos: La única forma de declarar la validez de cualquier conocimiento es compararlo con otra fuente de conocimiento.

La Observación de Armour sobre el Proceso de Software

Lo que todo desarrollador de software realmente quiere es un conjunto de reglas riguroso, hermético, concreto, universal, absoluto, total, definitivo y completo que se puedan romper.

La Tercera Ley del Proceso de Software

El último tipo de conocimiento a ser considerado como candidato para la implementación en un sistema de software ejecutable es el conocimiento de cómo implementar el conocimiento en un sistema de software ejecutable.

Las Metas Gemelas de la Terminación Óptima

1. La única meta natural de un grupo de procesos de software debería ser alejada del negocio tan pronto como sea posible.

2. El resultado final del desarrollo y aplicación continuos de un proceso efectivo será que nadie realmente tiene que usarlo.

Quizás el único comentario que me queda por hacer es que los procesos y los modelos no pueden separarse de la forma como pensamos los seres humanos. Más que cualquier otra cosa, el desarrollo de software es una actividad pensante. Como humanos, sólo pensamos en términos de modelos. Las restricciones de estos modelos nos asisten en la actividad pensante, pero también nos restringen y pueden aún conducir el resultado de nuestro pensamiento forzando una respuesta sobre nosotros. Todos estos elementos, los procesos que usamos y los modelos de nuestro entendimiento que nosotros mismos creamos, incluyendo el modelo del código, deben conformar con los requisitos de la mente.

Referencias
1. The value of RUP certification, by Jochen Krebs. The Rational Edge, Enero 2007.
2. The value of RUP certification, by Jochen Krebs. The Rational Edge, Enero 2007.
3. Basado en principios de Administración Total de la Calidad enseñados por Shewhart, Juran, Deming y Humphrey.
4. The Laws of Software Process: A New Model for the Production and Management of Software by Philip G. Armour

Lectura Fundamental Siguiente: “Todo lo que siempre quisiste saber de RUP y no te atreviste a preguntar”

lucho.salazar@gmail.com

Lecturas Fundamentales 5 (2 de 2)

2006-12-22T11:35:00.000-05:00

Lectura Fundamental Anterior: “Casos de Uso: ¿Cuándo Están Terminados? ... ¿Y qué hacer con ellos a continuación?” Parte 1

Lectura # 5
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2
Previamente en Lecturas Fundamentales…

En la parte 1 de este artículo enunciaba mi Ley de la Terminación del Caso de Uso. Decía que un caso de uso está terminado cuando se cumplen al menos diez de trece condiciones. Las primeras seis condiciones a las que me refería son:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
5. ¿Los subflujos en el caso de uso están modelados con precisión?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Y aportaba algunos elementos de criterio para hacer la revisión con cada uno de esos puntos. Bien, estas son las demás:
¿Las interacciones del actor y la información intercambiada están claras?
¿Es comprensible la forma como el actor proporciona datos al sistema mediante el caso de uso y qué datos suministra? Esto es, establecer si el actor debe seleccionar de una lista o debe digitar el dato o debe escoger una de un conjunto de posibles opciones; o si debe especificar la ruta o la dirección de un archivo de datos o si debe autorizar la carga de información mediante un proceso.
También debe hacerse evidente el tipo y mecanismo de validación, si existe, para cada dato intercambiado con el sistema. En este contexto, “hacerse evidente” quiere decir “especificar o documentar”, que sea explícito en el caso de uso. No porque algo nos parezca evidente, como especificadores de requisitos, le parecerá evidente a los demás, hay que hacerlo incuestionable, axiomático.
¿La descripción breve ofrece un cuadro verdadero del caso de uso?
Aunque la descripción breve no hace parte de la funcionalidad establecida en el caso de uso, ésta debe brindar a los lectores del mismo una visión horizontal, concisa, que permita formar imágenes mentales precisas de lo que hace el caso de uso y hasta un bosquejo del mismo.
Durante la fase de exploración del proyecto, la fase de Concepción o Inicio, cuando se descubren los casos de uso, la descripción breve del caso de uso juega un papel muy importante no solo para los analistas y usuarios, sino para el Arquitecto del Software, que cuenta con que le facilitemos de estas descripciones para que comience a elaborar la arquitectura del producto, al menos, la arquitectura preliminar, o para que tome decisiones acerca de llevar a cabo pruebas de concepto o no.
¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (Menos de 20)
El límite puede ser 20, 15, 25, 17, 13, 23. “Pequeño” es un término relativo, eso lo sabemos de sobra. Puede haber casos de uso “grandes”, de 30, 50 ó 70 pasos; sin embargo, éstos deben ser la excepción. Además, el tamaño es un índice de complejidad, pero no es el único. Y siempre puede suceder que un caso de uso de 50 pasos sea sencillo y uno de 10 pasos sea complejo.
En cualquier caso, cuando el número de pasos de un caso de uso empieza a crecer, debemos también comenzar a pensar en que quizás se pueda dividir. De hecho una de los lineamientos a seguir para crear casos de uso incluidos es precisamente la máxima de “divide y vencerás” que, en esta oportunidad, podríamos traducir como “divide y entenderás.”
Definición 12. Un caso de uso incluido es aquel cuyo comportamiento (funcionalidad) puede ser insertado en el comportamiento definido para otro caso de uso, llamado caso de uso base.
La inclusión, junto con la extensión y la generalización, son las relaciones que pueden existir entre casos de uso. En una lectura fundamental posterior les hablaré en detalle de este tema de las relaciones entre casos de uso.
¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
En la lectura fundamental #1 anotaba que, desde el punto de vista del usuario, un caso de uso es una pieza indivisible de software, simple, con un objetivo exacto y único.
Siempre debemos buscar estas características en el caso de uso. Si observamos que el caso de uso hace varias tareas desacopladas, si la complejidad de algunas de sus acciones lo hace incomprensible para los usuarios o aún para los desarrolladores, si tiene un número excesivo de pasos o de secuencias alternativas, si la profundidad de las anidaciones (decisiones lógicas o ciclos) es mayor de dos (por ejemplo, si hay secuencias alternativas que se derivan no de la secuencia básica o principal, sino de otra secuencia alternativa), si parte de las acciones de un caso de uso se puede “ocultar” deliberadamente (en casos de uso incluidos) sin que se afecte el matiz que se obtenga de su lectura, si para entender el caso de uso se hace necesario acompañarlo de adjuntos como prototipos de usuario, manifiestos en prosa sobre la funcionalidad del caso de uso u otros elementos de diseño, entonces seguramente será necesario fraccionar la especificación en dos o más casos de uso.
Sí, otra vez, simplicidad es la clave.
¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
En términos generales, un caso de uso incluido no es autónomo en cuanto a que por sí solo no entrega un resultado de valor observable para el actor. Esto lo convierte en dependiente del caso de uso base.
A pesar de tal interdependencia, el comportamiento de un caso de uso incluido no debe verse sobre-influido por un cambio al caso de uso base, sobre todo, cuando la razón de la inclusión es una factorización en la funcionalidad de varios casos de uso, es decir, distintos casos de uso tenían una funcionalidad común que se eliminó de éstos y se incluyó en un único caso de uso incluido por todos los demás.
De esta forma, si al modificar la funcionalidad de uno de los casos de uso, se acomete contra la funcionalidad “incluida”, todos los casos de uso que la usan deben someterse a una minuciosa inspección con el fin de mantener la consistencia en el modelo funcional o de casos de uso.
¿Cada caso de uso es independiente del resto?
Es realmente necesario abordar este chequeo con un pensamiento sistémico que nos permita no sólo modelar el producto sino también obtener varias perspectivas del modelo.
En particular, al revisar las interrelaciones de los casos de uso en los distintos modelos del sistema, el resultado debe ser uno que exhiba bajo acoplamiento y alta cohesión. Bajo acoplamiento quiere decir que hay poca o ninguna interdependencia entre el caso de uso y su entorno (otros casos de uso u otros actores distintos al que ejecuta este caso de uso). Entre tanto, el principio de alta cohesión señala que el caso de uso ejecuta una tarea simple y precisa y alcanza un objetivo predeterminado. En este contexto, los casos de uso a los que me refiero son casos de uso concretos, ejecutados por actores del sistema; esto excluye, si me permiten la disfunción, a los casos de uso incluidos y a los abstractos o generalizados. Estos últimos son aquellos que no se implementan, pero que existan para estabilizar el modelo y entenderlo mejor.
Este, que es un patrón común de diseño heredado cuidadosamente de las técnicas estructuradas de programación de computadores, requiere tanto un enfoque de bajo nivel para verificar el acoplamiento, como un punto de vista más alto para cotejar la cohesión. De allí la necesidad de hacer cálculos holistas con los elementos funcionales del sistema, o sea, con los casos de uso.
¿Este caso de uso hace algo muy parecido a otro caso de uso?
De ser así, quizás deberían convertirse ambos en un único caso de uso.
Ocurre mucho con los casos de uso descompuestos funcionalmente, que deberíamos evitar. Estos tienden a parecerse, porque, por ejemplo, uno es para adicionar un elemento y el otro es para actualizar los datos de ese elemento, digamos un producto o un cliente.
Pero en casos de uso no descompuestos funcionalmente también suele suceder, sobre todo, cuando obtenemos la visión de un rango heterogéneo de usuarios y cada uno de ellos expresa sus necesidades de acuerdo a sus criterios y ambiente de trabajo. Reservar Vuelo y Comprar Tiquete quizás sean dos casos de uso distintos, pero también pueden llegar a convertirse en uno solo, dependiendo de la meta que se quiera alcanzar con uno u otro.
¿Y qué hacer con los casos de uso una vez están terminados?
Realmente no es necesario terminar un caso de uso para continuar con su ciclo de vida. Desde la descripción breve y el esbozo que se obtiene durante la fase de Inicio del proyecto, ya es posible empezar a hacer el análisis y diseño del caso de uso. En este punto ya también el arquitecto puede considerar distintas variables para seleccionar los casos de uso más críticos o complejos para la arquitectura del software, aquellos que definen las bases del producto a construir.
Más adelante, durante cada una de las iteraciones, al completar la secuencia básica es factible diseñar prototipos, “realizar” los casos de uso y comenzar a implementarlos. Y también es posible diseñar los casos de prueba.
Todos estos eventos subsiguientes a la especificación de un caso de uso, serán temas que ocuparán nuestras lecturas fundamentales durante 2007.
Hasta entonces y feliz navidad.

Lectura Fundamental Siguiente: De Procesos y de Humanos.

lucho.salazar@gmail.com

Lecturas Fundamentales 4 (1 de 2)

2006-12-07T07:47:00.000-05:00

Lectura Fundamental Anterior: “Casos de Uso: Del Todo y de Sus Partes”
Lectura # 4
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 1 de 2
Volvamos a considerar el siguiente caso de uso típico de un sistema de reservaciones:
Caso de Uso: Reservar Vuelo
Actor: Pasajero Frecuente
Descripción: este caso de uso permite a una persona reservar un vuelo de ida y regreso entre dos ciudades distintas en las fechas de su elección. El sistema valida la disponibilidad de un asiento de las características que el Pasajero especifique. La reservación se hace vía Internet. La aerolínea sólo tiene aviones con asientos estándar.
Objetivo: Proporcionar un mecanismo rápido y seguro a un Pasajero Frecuente para hacer reservas en vuelos nacionales o internacionales de ida y regreso. No se incluye la funcionalidad de pagar o cambiar el estado de la reserva.
Precondiciones: El Pasajero debe estar plenamente identificado ante el sistema de reservas (Cuenta de Pasajero Frecuente, Identificación, Nombre y otros datos básicos).
Secuencia Básica:
1. El caso de uso inicia cuando el Pasajero decide Hacer una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema valida que las ciudades Origen y Destino sean distintas, que haya al menos un vuelo entre esas ciudades y solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso, incluyendo la hora de ambos viajes
6. El sistema valida que la fecha de regreso, incluyendo la hora, sea superior a la fecha de ida, incluyendo la hora, y pide seleccionar una opción de la lista de vuelos disponibles para las fechas y ciudades establecidas
7. El Pasajero selecciona una opción de vuelo
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema asigna un asiento al Pasajero, genera y muestra un código de reserva
11. El caso de uso termina
Secuencia Alternativa 1:
4A. No hay vuelos entre las ciudades seleccionadas
4A1. El sistema muestra el mensaje: “No hay vuelos entre las ciudades seleccionadas. Verifique.”
4A2. El caso de uso termina
Secuencia Alternativa 2:
6A. No hay vuelos disponibles en las fechas especificadas
6A1. El sistema muestra el mensaje: “No hay vuelos disponibles en las fechas seleccionadas. Verifique.”
6A2. El caso de uso termina
Secuencia Alternativa 3:
6B. La fecha/hora de regreso es inferior a la fecha/hora de ida
6A1. El sistema muestra el mensaje: “La fecha de regreso es inferior a la fecha de ida. Especifíquelas nuevamente.”
6A2. El caso de uso continúa en el paso 5 de la secuencia básica
Poscondiciones: El Pasajero puede consultar el estado de su reserva. El Pasajero puede modificar o cancelar su reserva.
Requisitos Especiales: El sistema sólo muestra y permite seleccionar pares de vuelos disponibles en las fechas y entre las ciudades establecidas. El sistema de reservas es solo para el tipo de Pasajeros Frecuentes de la aerolínea.
Advertencia: todavía este continua siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso.
Voy a cerrar este primer ciclo de lecturas fundamentales sobre casos de uso basándome precisamente en una corta pero sustanciosa lista de chequeo para revisar casos de uso. Vale la pena decir que esta lista hace parte del proceso de Ingeniería de Requisitos institucionalizado en InterGrupo hace ya algún tiempo y que a su vez está cimentada en RUP.
Ley de la Terminación de un Caso de Uso
Un caso de uso está terminado cuando se cumplen al menos diez de las siguientes trece condiciones:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
5. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
7. ¿Las interacciones del actor y la información intercambiada están claras?
8. ¿La descripción breve ofrece un cuadro verdadero del caso de uso?
9. ¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (menos de 20)
10. ¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
11. ¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
12. ¿Cada caso de uso es independiente del resto?
13. ¿Este caso de uso hace algo muy parecido a otro caso de uso? De ser así, quizás deberían convertirse ambos en un único caso de uso.
¿El caso de uso tiene especificado el Actor que lo inicia?
No habría mucho que decir de este control si la búsqueda y posterior definición de los actores de un sistema no estuviera hoy tan desestimada. En principio tengo que decir que intentar definir un sistema sin conocer sus actores es un error bastante común. Antes que cualquier otra cosa es importante conocer para quien construimos el sistema, luego procedemos a documentar lo que hace cada uno de esos actores.
Debemos indagar por el perfil del actor y sus responsabilidades en el sistema. Recordemos que un actor bien podría ser alguien “abstracto” para el negocio, es decir, no equivale a un rol desempeñado por una persona o un grupo de personas dentro del negocio, razón por la cual, luego de hacer la abstracción, hay que mirarlo desde el punto de vista del sistema.
Con ese perfil, evaluamos si las actividades descritas en el caso de uso pueden ser ejecutadas por ese actor. Este es realmente el punto de chequeo, no simplemente asegurarnos de que haya un nombre cualquiera en la sección Actor del caso de uso.
Ahora bien, un caso de uso normalmente tiene un único actor que lo inicia; sin embargo, el caso de uso puede tener más actores. En este caso, los demás actores son pasivos, es decir, o simplemente reciben información, como en el caso de un sistema o un dispositivo externo, o son espectadores participes del proceso del negocio que envuelve el caso de uso, como en el caso de un cliente en un punto de venta. En cualquier caso, es importante enumerar a todos los actores que intervienen en el caso de uso por el horizonte que se extiende tanto para los analistas como para los desarrolladores y probadores del producto, en cuanto al entendimiento del mismo.
En el ejemplo, un “simple” Pasajero puede significar un cliente casual de la aerolínea, mientras que un Pasajero Frecuente es precisamente una persona que toma vuelos con una frecuencia uniforme o que, al menos, está registrado como tal ante la compañía.
¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
Los usuarios son la última línea de defensa del caso de uso, son quienes confirman que está terminado, son quienes lo aprueban. Es tarea del Especificador de Requisitos obtener de ellos la información suficiente y necesaria para terminar el caso de uso. Siempre tenemos a la mano el “¿Qué más debo saber acerca de esta funcionalidad?” Otras preguntas importantes son: ¿Quién más está interesado en este caso de uso? ¿Quién debería leerlo? ¿Quién debería aprobarlo?
Una vez se tiene esa información, el revisor del caso de uso, si existe, puede indagar sobre el número de personas que leyeron y aprobaron el caso de uso para establecer si eso constituye una muestra representativa para dar por terminado el caso de uso.
En el ejemplo, puesto que el Pasajero es un actor externo a la compañía, alguien dentro de ésta es quien lo representa, es decir, es quien decide cómo quiere que los clientes de la aerolínea perciban el sistema. Por ello es importante documentar desde el principio del proyecto, no solo quienes son los usuarios finales, sino quienes serán sus representantes a lo largo del ciclo de vida.
¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
Es más que evidente. Otra vez, es sólo el usuario y nadie más que el usuario, quien decreta la correcta finalización del caso de uso. Por ello el caso de uso no debe incluir aspectos técnicos o detalles del diseño o implementación del mismo.
Se evidencia la participación dinámica y constante del usuario o de un grupo de usuarios durante la Ingeniería de Requisitos (por supuesto, también durante el resto del ciclo de vida, pero sin duda es esta etapa donde se hace más evidente la necesidad de contar con el mayor número de usuarios del producto).
El usuario regular no está interesado en conocer lo que ocurre “detrás del telón” del sistema. Para él sólo es importante el grupo de acciones donde él participa activamente, donde interactúa con el software y finalmente es quien indica si está satisfecho con lo que está documentado en el caso de uso.
Si, por ejemplo en el paso 6, dijéramos que la lista de vuelos se busca haciendo una intercalación multivía seguida de una selección por reemplazamiento, estaríamos adicionando detalles que confundirían innecesariamente al usuario común y corriente. Es más, ni siquiera tendríamos que mencionar las tablas y mucho menos los componentes involucrados en dicha búsqueda y selección.
¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
Si mantenemos el caso de uso en su estado más simple, aunque con el suficiente detalle para pasar al siguiente estado, los momentos de inicio y finalización de cada secuencia de acciones deberían estar a la vista de todos.
Los errores más comunes se encuentran en las secuencias alternativas, al decidir si la acción retorna a la secuencia básica o si el caso de uso termina. También pasa que si el caso de uso tiene varios escenarios a partir de una misma acción, luego de escribir dos o tres de ellos perdamos el foco de la “horizontalidad” del caso de uso y empezamos a cubrir detalles que nos podrían llevar, desde el punto de vista del usuario, por caminos insubstanciales del caso de uso.
¿Los subflujos en el caso de uso están modelados con precisión?
Luego de mi lectura fundamental # 1 no volví a mencionar la palabra modelo. No es que cuando estamos documentando casos de uso no estamos modelando, es que precisamente a veces perdemos la conciencia de que es eso lo que estamos haciendo, aunque sea puramente texto lo que escribamos. De hecho, el modelo de casos de uso es mayormente texto.
Así que cuando hablo de modelar subflujos del caso de uso con precisión, me refiero a que proporcionemos toda la información necesaria al modelo: lugar donde se inicia el subflujo, motivo del subflujo, acciones del subflujo y método de terminación del subflujo.
Cabe decir que los subflujos no son sólo secuencias alternativas, también pueden ser “porciones” de la secuencia básica, normalmente, porciones pequeñas y extremadamente simples.
Sí, el concepto clave es simplicidad.
¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Una cosa es especificar un actor y otra es si ese actor representa adecuadamente al grupo de usuarios que ejecutará el caso de uso. Es posible que haya diferencias entre lo que piensa el representante de los usuarios asignado para proporcionar la información de, revisar y aprobar el caso de uso, y lo que finalmente quede documentado.
Un trabajo de campo, donde aseguremos que varios usuarios lean y acuerden el caso de uso ayuda mucho en estos casos. Así evitamos esa escena de terror que más de uno hemos vivido cuando mucho tiempo después de la especificación, probablemente durante las pruebas de certificación o ya en producción, nos preguntan “¿Quién dijo eso?”
De otro lado, el propósito puede estar implícito a lo largo y ancho de la declaración del caso de uso, o bien puede estar explícito en una sección inicial del mismo. Esta última opción es mi favorita porque permite verificar la consistencia del caso de uso lo mismo que medir su valor para el sistema y para los usuarios.
El propósito, si se especifica, debe escribirse a priori, quizás durante la etapa de descubrimiento del caso de uso, para que posea la menos subjetividad posible. Por supuesto, siempre podemos afinarla, aún antes de presentar el caso de uso para su última revisión.
El propósito debe incluir lo que el actor consigue del caso de uso y también lo que no consigue. Esto ayuda en las etapas posteriores al resto del equipo de desarrollo del proyecto a construir un sistema de alta usabilidad y gran aceptación.
Lo que Falta
Bien, hasta aquí la exploración a los primeros aspectos fundamentales que nos ayudan a decidir cuando un caso de uso está terminado. En la siguiente entrega volveré con el final de este artículo.
Esta lectura #4 continuará. Hasta entonces.
Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2”

Lecturas Fundamentales 3

2006-11-23T23:37:00.000-05:00

Lectura Fundamental Anterior: “Casos de Uso: Origen, Especificación y Evolución”

Lectura # 3

Casos de Uso: Del Todo y de sus Partes

Consideremos el siguiente caso de uso típico de un sistema de reservaciones:

Caso de Uso: Reservar Vuelo

Actor: Pasajero Aerolínea

Descripción: este caso de uso permite a una persona reservar un vuelo de ida y regreso entre dos ciudades distintas en las fechas de su elección. El sistema valida la disponibilidad de un asiento de las características que el Pasajero especifique. La reservación se hace vía Internet. La aerolínea sólo tiene aviones con asientos estándar.

Precondiciones: El Pasajero debe estar plenamente identificado ante el sistema de reservas (Cuenta de Pasajero Frecuente, Identificación, Nombre y otros datos básicos).

Secuencia Básica:

1. El caso de uso inicia cuando el Pasajero opta por Hacer una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema valida que las ciudades Origen y Destino sean distintas, que haya al menos un vuelo entre esas ciudades y solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso
6. El sistema valida que la fecha de regreso sea superior a la fecha de ida y pide seleccionar una opción de la lista de vuelos disponibles para las fechas y ciudades establecidas
7. El Pasajero selecciona una opción de vuelo
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema asigna un asiento al Pasajero, genera y muestra un código de reserva
11. El caso de uso termina

Secuencia Alternativa 1:

4A. No hay vuelos entre las ciudades seleccionadas
4A1. El sistema muestra el mensaje: “No hay vuelos entre las ciudades seleccionadas. Verifique.” 4A2. El caso de uso termina

Secuencia Alternativa 2:

6A. No hay vuelos disponibles en las fechas especificadas
6A1. El sistema muestra el mensaje: “No hay vuelos disponibles en las fechas seleccionadas. Verifique.”
6A2. El caso de uso termina

Poscondiciones: El Pasajero puede consultar el estado de su reserva. El Pasajero puede modificar o cancelar su reserva.

Requisitos Especiales: El sistema sólo muestra y permite seleccionar pares de vuelos disponibles en las fechas y entre las ciudades establecidas. El sistema de reservas es solo para el tipo de Pasajeros Frecuentes de la aerolínea.

Advertencia: este sigue siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso. Además, no es un caso de uso “Terminado”.

Definición 6: La descripción breve o simplemente descripción del caso de uso es un compendio informativo –tres o cuatro líneas a lo sumo- sobre el caso de uso. Resume las principales características del caso de uso pero en ningún momento hace parte de la especificación funcional del mismo. En esta sección se pueden considerar algunas condiciones bajo y para las cuales se ejecuta el caso de uso, se pueden enumerar algunos requisitos no funcionales y otros detalles relevantes. Las descripciones breves surgen durante la fase de Concepción del proyecto, cuando se identifica el caso de uso y no reemplazan el bosquejo o borrador del caso de uso, que surge a continuación de ésta. Un indicador de que hemos entendido el caso de uso o la funcionalidad requerida es cuando escribimos esta descripción en menos de un minuto y a “lápiz alzado” como dicen los dibujantes. Sin embargo, esta es una práctica que toma tiempo y se puede lograr después de muchos casos de uso documentados.

Definición 7: Las precondiciones constituyen el estado en el que debe estar el sistema para que el caso de uso se ejecute. Esto quiere decir, lo que debe ocurrir en el sistema para que sea posible “habilitar” el caso de uso y que este se pueda ejecutar. Pensemos, por ejemplo, en una funcionalidad ampliamente usada por todos: Copiar y Pegar texto. Un prerrequisito de Copiar es Seleccionar el texto; y un prerrequisito de Pegar es Copiar el texto.

Una precondición se fija en prosa, como en nuestro caso de uso en demostración. O en términos de otros casos de uso, es decir, enumerando el o los casos de uso que deben ejecutarse para correr este. O usando una combinación de las dos. Esto último ocurre porque es posible que no hayamos identificado los casos de uso condicionantes, o porque no está claro de estos casos de uso cual es la precondición establecida y porque también hay un conjunto de especificaciones funcionales que no quedan escritas en términos de casos de uso y alguna de ellas puede ser un prerrequisito. Además, porque es mejor para el usuario que usemos su terminología y le evitemos leer un caso de uso completo para que entienda el estado final del mismo.

Las precondiciones son a la vez una forma de validación, ya que esas “condiciones” deben cumplirse antes de crear la instancia del caso de uso. Esto disminuye el número de validaciones que debe hacer dicho caso de uso una vez ha iniciado su secuencia de acciones.

La precondición del ejemplo se refiere al proceso o módulo donde el Pasajero se identifica ante el sistema: debe proporcionar su identificación y su número de pasajero frecuente para que el sistema conozca de quien se trata.

Las precondiciones además le hablan al desarrollador al oído. Le cuentan del mecanismo que debe usar o tener en cuenta para habilitar o deshabilitar opciones de la aplicación. En el ejemplo: si un pasajero no se ha identificado ante el sistema como Cliente o Pasajero Frecuente, la opción Hacer una Reserva Aérea estará deshabilitada o invisible al usuario.

Ahora bien, los tres errores más comunes que cometemos al definir una precondición son:

· Incluir una precondición “lejana en el contexto del proceso” al caso de uso, es decir, algo que no tiene relación directa con el caso de uso en cuestión. En el ejemplo, una precondición así sería “Las ciudades hacía y desde donde se originan los vuelos deben estar matriculadas en el sistema.” Ciertamente ésta podría ser una precondición del caso de uso, en cuyo caso lo afectaría indirectamente; En particular, ésta es una precondición de todo el sistema: sin las ciudades origen y destino registradas, el sistema no puede arrancar.

Aquí es importante precisar que una precondición no depende de esquemas temporales del proceso o del orden de ejecución en el tiempo. La precondición debería ser agnóstica de ello, desligándose del momento en que ocurre; lo que interesa es que se cumpla el estado, no el momento en que ese estado es establecido.

· Incluir una precondición que, en vez de serlo, es una condición que el sistema debe validar durante la ejecución del caso de uso. En el ejemplo, decir que “Debe haber vuelos disponibles” no es una precondición porque es algo que el caso de uso debe verificar a medida que se establecen las condiciones del vuelo. Tampoco lo es: “El Pasajero debe estar matriculado como Pasajero Frecuente en el sistema.” Esta es más bien una condición que se debe verificar en el caso de uso “Validar Pasajero”, el cual sí es una precondición del caso de uso.

Aquí también es importante aclarar que a veces una precondición puede convertirse en una validación en las primeras de cambio del caso de uso. Es decir, si no es compleja, entre otras características, la precondición bien podría incluirse como parte de las acciones del caso de uso.

· Incluir una precondición “no funcional”. Por ejemplo: “El Pasajero debe tener conexión a Internet” o “El Navegador debe soportar el protocolo SSL.” Aquí realmente estamos hablando de recursos físicos o de ciertas condiciones con las que el usuario no tiene que lidiar en lo absoluto.

Finalmente, las precondiciones son opcionales. Es posible, y ocurre muchas veces, que un caso de uso simplemente no tenga precondiciones.

Definición 8: La secuencia básica, llamada también Secuencia Principal, está formada por el conjunto de acciones que más ocurren en el caso de uso. Normalmente es la única que se describe por completo, es decir, de principio a fin.

Ahora bien, las acciones de un caso de uso, son acciones “planas” y, muchas veces, simples. En la Lectura 2 dije que no incluyen aspectos técnicos ni de diseño de pantallas ni otros detalles que pueden hacer difícil de leer y entender el caso de uso. Por lo general, un caso de uso inicia por una acción directa de un usuario o Actor del sistema. Esa acción casi siempre significa que el usuario decide u opta por hacer algo en el sistema para lo que tiene privilegios.

La elección de nombres, tanto de casos de uso como de otros elementos del proceso: Actores, datos y documentos, no debe hacerse a la ligera y mucho menos debe tomarse como algo sin importancia. Recuerden que eso afectará, al menos, la vida laboral de muchas personas. Como técnicos somos muy dados a seleccionar nombres ostentosos, adornados de tecnicismos innecesarios o incomprensibles para el usuario final; o, entre un grupo posible de nombres “del negocio” escogemos el menos usado en el entorno del usuario o alguno que tenga connotaciones distintas en el contexto de ese usuario: Reservar Vuelo, Hacer Reserva, Hacer una Reserva Aérea, Reservar, Hacer Reservación de Vuelo y Apartar un Viaje son algunos posibles nombres para el caso de uso.

Debemos indagar por las costumbres del actor, su perfil, su experiencia, su conocimiento, el entorno donde se mueve. En el caso de InterGrupo, con oficinas y clientes en varios países (aún en nuestro propio país un término puede llegar a tener connotación diferente en Bogotá que en Barranquilla), no está de más hacer este trabajo, no vaya a ser que usemos una expresión ofensiva para alguien. Quienes hemos viajado por distintas ciudades y países atendiendo clientes de la empresa somos testigo de ello.

Volviendo al nombre: Reservar y Hacer Reserva quizás sean muy cortos, sobre todo si hay distintos tipos de reserva; Reservar Vuelo quizás quiera decir un único trayecto, mientras que Hacer una Reserva Aérea puede significar reservar en ambos sentidos. En fin, las posibilidades pueden ser muchas. Por eso también es importante documentar el Glosario del sistema.

Para terminar, dos anécdotas: hace poco le preguntaba a un aspirante a Analista en InterGrupo que si sabía español. Evidentemente le llamó la atención y me dijo: “inglés, sí, a un 75%”. Yo le aclaré que no, y parafraseándolo le insistí que cuál era su porcentaje de español. Finalmente me dijo que no me entendía, creo que se ofendió, pero yo inmediatamente lo descarté.

Sí, es muy curioso que siempre nos exijan saber inglés sin siquiera indagar por nuestro nivel de español. Recuerdo que alguien, muy sincera, durante uno de los cursos que tomé de inglés hace muchos años me pidió ayuda cuando veíamos las distintas formas de conjugación en pasado. Ella me dijo que su problema era que no las dominaba en español y por eso se le dificultaba aprenderlas en inglés. Imagínense lo que pasó cuando llegamos al pretérito pluscuamperfecto: ese curso lo reprobó y nunca más la volví a ver.

De vuelta al caso de uso: las acciones no deben dar pie a ambigüedades, ni en el proceso del negocio ni en el del sistema. A primera vista, el paso 7 del caso de uso es anfibológico[i]. Seleccionar una opción de vuelo quizás quiera decir escoger un único trayecto y hasta bien podría sacarse de contexto y significar que el Pasajero seleccione un tipo de pasillo (Fumador, No Fumador, Ventana, No Ventana, entre otras); sin embargo, en la sección de Requisitos Especiales se aclara un poco el panorama.

Bueno, en otras lecturas volveremos a la secuencia básica.

Definición 9: Una secuencia alternativa está constituida por un conjunto de acciones que ocurren si se cumple una condición específica en el caso de uso, normalmente en la secuencia básica, aunque también puede ser en otra secuencia alternativa.

Cuando me refería a que la especificación de una acción o evento era más bien plana, hacía alusión a que la acción era una sentencia algorítmica básica, es decir, no era una decisión lógica o un ciclo predefinido, o una selección múltiple, que bien pueden existir en un caso de uso, pero que lo hacen complejo de entender.

El mecanismo que usamos para definir las decisiones en un caso de uso es precisamente el de las secuencias alternativas. Estas hacen más claro y preciso el caso de uso.

Una secuencia alternativa siempre debe iniciar detallando el paso o la acción en que se produce (el número del paso en la secuencia que la acarrea) y porqué se produce poniendo de manifiesto la condición que se cumplió para llegar a ese punto del caso de uso. A continuación se enumeran las acciones de la secuencia y por último se finaliza la secuencia bien sea retornando a la secuencia que la originó o terminando el caso de uso.

En nuestro ejemplo, es probable que falten algunas secuencias para terminar el caso de uso.
En conjunto, las secuencias básica y alternativas componen el cuerpo del caso de uso, la funcionalidad que el usuario requiere para resolver su problema de manejo de información: son lo implementable del caso de uso.

En general, un caso de uso se ejecuta para un elemento, en singular, del proceso. Por ejemplo, para un cliente decimos Registrar Cliente y no Registrar Clientes (a no ser que las condiciones así lo exijan); en nuestro caso, Reservar Vuelo: estamos reservando un vuelo de ida y regreso entre dos ciudades y fechas dadas, no son varios vuelos. El juego de palabras puede ser truculento, pero se debe aclarar lo mejor posible.

Definición 10: las poscondiciones describen el estado en el que queda el sistema una vez se ha ejecutado el caso de uso de manera exitosa, es decir, cuando no han surgido excepciones indeseables del sistema. Aquí, de manera exitosa quiere decir que se completó activamente un escenario del caso de uso sin que el sistema fallara por una caída de la base de datos, una sobrecarga de memoria o una mala implementación del caso de uso, entre otros.

Precisando, una poscondición no es el final de un caso de uso, está fuera del caso de uso. Por ejemplo, una poscondición no es que “la información del vuelo queda almacenada en la base de datos.” Esta es más bien una consecuencia lógica del caso de uso.

En el ejemplo, otra poscondición bien podría ser: “el pasajero puede Pagar su reservación con tarjeta de crédito, tarjeta débito o C.E.F.”

Como con las precondiciones, las poscondiciones pueden expresarse en términos de casos de uso o en prosa, si involucra a muchos casos de uso. Aunque la primera opción es la preferida porque no se deja espacio para malos entendidos, podría ocurrir lo mismo que expliqué sobre las precondiciones sentenciadas como casos de uso; por tal motivo, podría ser mejor usar la prosa: sí ven que es importante conocer mejor nuestro idioma.

Y al igual que las precondiciones, las poscondiciones son opcionales, aunque es difícil pensar en la ejecución de un caso de uso, que no sea la generación de un reporte o consulta, que no tenga un impacto directo sobre otro u otros casos de uso del sistema.

Definición 11: En principio, los requisitos especiales se refieren a requisitos de corte no funcional que deben tenerse en cuenta para la implementación de este caso de uso en particular y que no pueden ser descritas fácilmente en el flujo de eventos del caso de uso o lo convierten en un caso de uso enmarañado o sencillamente ilegible. Pero también pueden referirse a algunos requisitos funcionales si con ellos complementamos o precisamos el flujo del caso de uso, sobre todo, cuando no queremos adicionar detalles a ese flujo que también podrían hacerlo indescifrable.

Ahora bien, aunque los requisitos no funcionales se detallan en el documento de Especificaciones Suplementarias, si un requisito especial se refiere a una especificación previamente dictada, primará la que se encuentre en el caso de uso.

Para recordar, los requisitos no funcionales o el modelo URSP+ (por sus siglas en inglés): Usabilidad, Confiabilidad, Soportabilidad, Desempeño, Restricciones de diseño e implementación, Documentación, entre otros.

Bien, así son las piezas constituyentes de un caso de uso, al menos las más usadas. El grado de “adornamiento” de un caso de uso lo delimita el Analista de acuerdo a factores como complejidad, perfil del usuario, tiempo disponible para la especificación, experiencia de los equipos de diseño y de desarrollo, entre otros.

Escribir un caso de uso no es una tarea cándida, terminarlo puede llegar a ser extenuante. Pero ese será el tema de nuestra próxima lectura fundamental.

Hasta entonces.

Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación?”

[i]
anfibológico, ca.

1. adj. Que tiene o implica anfibología.

Real Academia Española © Todos los derechos reservados

anfibología.

(Del lat. amphibologĭa, y este del gr. ἀμφίβολος, ambiguo, equívoco).

1. f. Doble sentido, vicio de la palabra, cláusula o manera de hablar a que puede darse más de una interpretación.

2. f. Ret. Figura que consiste en emplear adrede voces o cláusulas de doble sentido.

Real Academia Española © Todos los derechos reservados

Lecturas Fundamentales 2

2006-11-17T14:05:00.000-05:00

Lectura Fundamental Anterior: “Casos de Uso: De Vuelta a lo Fundamental”

Lectura # 2
Casos de Uso: Origen, Especificación y Evolución

Los casos de uso detallan la funcionalidad del software en construcción. Aunque no tiene que usarse siempre, la técnica de casos de uso es una muy buena práctica a la hora de capturar, documentar, revisar y aprobar requisitos funcionales. Pero ¿a partir de qué elementos, en qué momento del ciclo de vida, surgen los casos de uso?

Los casos de uso, como la materia, no se crean ni se destruyen, se transforman. Están allí, esperando ingresar al conjunto de entidades que conforman un modelo, en este caso, como la materia prima fundamental de un producto de software.

En un principio están las necesidades, el espacio del problema. Aquí atendemos diligentemente la exposición del usuario, sus dificultades, la manera como las resuelve, si lo hace; escuchamos lo que necesita, las causas (el problema raíz o el problema detrás del problema), el impacto de convivir con esos inconvenientes, el costo asociado, entre otros aspectos.

Conocer al detalle la dimensión del problema es el primer gran paso hacia el diseño e implementación de un sistema útil y lleno de bondades para los usuarios. Durante esta parte del proceso, identificamos, sino a todos, a la mayoría de las personas involucradas o impactadas por el proyecto o el producto objeto del proyecto; por supuesto, también a otros sistemas o herramientas con los que nuestro sistema tendrá algún tipo de comunicación directa o indirecta.

Todos estos son insumos para identificar luego las características, ya en el espacio de la solución, del software a construir. Si hemos sido juiciosos consignando las palabras del usuario y confrontándolas con él, podremos empezar, por ejemplo, haciendo un análisis gramatical, una técnica antiquísima que separa los verbos, o las frases verbales, de los sustantivos: los primeros son casos de uso potenciales, o partes de un caso de uso; los segundos son actores u otras entidades relacionadas con el proceso. Es probable, inclusive, que de este análisis, apenas podamos tener una aproximación a un modelo de casos de uso del negocio.

Definición 4: un caso de uso del negocio representa un macro-proceso, un proceso, un subproceso o una actividad del negocio que no necesariamente es llevada a cabo por herramientas automatizadas, en el que intervienen una o más personas (llamadas entonces Actores del Negocio) y en el que se intercambia información relativa al proceso. Como con un caso de uso “normal”, al que llamaremos entonces caso de uso del sistema, o simplemente, caso de uso, el caso de uso del negocio termina con un resultado de valor observable para los actores del negocio. Ahora bien, de un caso de uso del negocio se pueden derivar uno o más casos de uso del sistema. Sin embargo, en ocasiones, un caso de uso del negocio permanece en su estado natural, es decir, ninguna de sus partes es automatizada. Un ejemplo típico de un caso de uso del negocio es la Recepción de una Solicitud de “algo”: Aquí, un actor del negocio, El Cliente, entrega a otro Actor del negocio, Recepcionista, Archivador o Empleado, uno o más documentos; este último, revisa, pone un sello con fecha y número (opcional) y firma una copia que es devuelta al Cliente; este simplemente se retira con su copia y el proceso, el caso de uso del negocio, termina.

Un Actor del Negocio representa un papel “actuado” en relación al negocio por alguien o algo en el entorno de ese negocio. Los siguientes tipos de usuarios del negocio son ejemplos de actores potenciales del negocio[1]:

Clientes
Proveedores
Socios de negocio
Clientes potenciales (el “mercado objetivo”)
Autoridades locales
Colegas

Un término íntimamente relacionado con el Actor del Negocio es el Trabajador del Negocio y muchas veces se confunde uno con otro, pero dejaré los detalles de este tema para una próxima entrega. Lo que nos interesa aquí es que los casos de uso del negocio son también fuentes de los casos de uso del sistema.

En este punto resolvamos más inquietudes:

¿Cómo nombramos un caso de uso? Con frases verbales simples. Verbos como Registrar, Generar, Consultar, Matricular, acompañados de expresiones sustantivadas de una sola parte son ampliamente usados. Y muchos otros. Algunos verbos que debemos evitar son Procesar, Hacer, Ejecutar, Establecer, Administrar o Gestionar, por lo genérico o ambiguo de los términos, al igual que el sustantivo Evento, que además para nosotros significa muchas otras cosas. Tampoco redundemos, como en Generar Reporte de Solicitudes Recibidas: Generar y Consultar normalmente se refieren a eso, a reportes y consultas, a no ser que se especifique otra cosa. El nombre de un caso de uso debe despedir cierto halito de grandeza, de verdad, de seguridad: en lo sucesivo, se convertirá en parte integral del vocabulario de muchas personas, quizás de toda una corporación, eso es motivo suficiente para que sea así.

El nombre, además de usar los verbos y sustantivos, debe dar a conocer la intención que tiene el actor al usarlo en el sistema.

En conclusión, Los nombres de los casos de uso traen orden y sentido a un proceso y a las personas involucradas en el mismo, allí radica su importancia.

¿Cómo especificamos un caso de uso? Cuáles son sus partes? Un caso de uso siempre es ejecutado por un Actor y eso es lo primero que debemos identificar del caso de uso.

Definición 5: un Actor es una entidad externa al sistema, normalmente una persona, pero también puede ser otro sistema o una máquina con la que nuestro sistema tenga algún tipo de contacto. Cuando se trata de personas, el Actor no identifica a alguien en particular; en cambio, señala un grupo o un perfil de usuarios del sistema. Todos los usuarios caracterizados por ese actor, ven el sistema de la misma forma, ninguno ve más o menos que otro. Eso sí, un individuo puede jugar a ser más de un actor en momentos distintos y en estados distintos de la aplicación. El mito más grande que hay con los Actores Personas es que representan cargos dentro de la compañía para la cual se construye el software, lo cual apenas sería una afortunada coincidencia. Hasta es probable que los actores del negocio, más cercanos a la compañía, no signifiquen cargos de trabajo. Ejemplos de actores son: Analista de Crédito, Vendedor de Licencias, Habilitador de Servicios de Salud, Supervisor de Producción, Administrador de Usuarios, entre muchos otros.

En estos ejemplos hay una constante: el contexto. Un actor lo es dentro de un contexto particular. Analista, Vendedor, Habilitador, Supervisor o Administrador son actores bastante genéricos y podrían representar a toda una compañía, que nunca se modela en un sistema. Siempre debemos limitar el alcance de las actividades de un actor (los casos de uso que ejecuta) vía contextualización. Un actor ampliamente usado en los sistemas punto com es el Cliente. Muchas veces, la sola denominación Cliente es bastante amplia y no permite delimitar el ámbito en el que se mueve. Podríamos bien decir: Pasajero Aerolínea, Tarjeta-Habiente, Comprador Minorista, Asegurado, Solicitante de Crédito, entre muchos otros apelativos.

Por supuesto, el otro componente importante de un caso de uso es el conjunto de secuencias, los flujos de tareas. Las tareas dicen qué hace el caso de uso, no cómo lo hace, es decir, no hay detalles técnicos en un caso de uso, al menos, no en principio, mientras se revisa y se aprueba con el usuario, quien es la última línea de defensa en materia de casos de uso. Tampoco hay referencias al diseño de la interfaz gráfica de usuario.

Además, en un caso de uso no se escribe el código fuente ni el manual de usuario. Para ello existen otros artefactos, tratados en otras disciplinas e instancias, que requieren de un conocimiento más profundo y detallado del adquirido durante el período de la especificación de requisitos.

Ejemplo, Ejemplo, Ejemplo.

Caso de Uso: Reservar Vuelo
Actor: Pasajero Aerolínea
Secuencia:
1. El caso de uso inicia cuando el Pasajero solicita una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso
6. El sistema verifica que haya un asiento disponible para las condiciones establecidas y solicita las preferencias de silla al Pasajero
7. El Pasajero indica sus preferencias
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema genera y muestra un código de reserva
11. El caso de uso termina

Advertencia: este es un caso de uso en estado de especificación, no intente usarlo en ningún proyecto en curso.

Esta primerísima versión está medianamente lejos de la versión definitiva. Sin embargo, sirve para indicar varios aspectos:

1. La interacción Usuario-Sistema. El caso de uso siempre debe señalar lo que es obvio para el usuario, lo que él puede ver del sistema. Para el usuario es importante el estímulo que reciba del sistema, ya sea a través de solicitudes o de respuestas. El detalle del mecanismo algorítmico o técnico que use el sistema para enviar esas solicitudes o encontrar esas respuestas debe omitirse del caso de uso. En el ejemplo, el algoritmo de verificación del asiento disponible, si la búsqueda se hace secuencial o binaria, si se usan procedimientos almacenados o si se invoca a un Web Service para lograrlo, son especificaciones que están lejos del alcance del caso de uso (aún en la versión final del caso de uso, la que aprobará el usuario, no existirán).

2. Las formas lingüísticas, en este caso, los verbos y sustantivos usados deben ser un indicador de los mecanismos de implementación a usar: cuando el caso de uso especifica “el Pasajero selecciona[2]…” está diciendo claramente: elegir, escoger de un grupo de posibles opciones. Es evidente que el sistema debe entonces utilizar los medios necesarios para mostrar la lista de opciones y permitir que el usuario decida entre ellas mediante la “Acción y efecto de elegir a una o varias personas o cosas entre otras, separándolas de ellas y prefiriéndolas.” (Significado de Selección, Diccionario de la RAE, XXII Edición).

Vamos un poco más allá: cuando el caso de uso dice: “5. El pasajero especifica…” igual está lejos de señalar el mecanismo de implementación; no obstante, dejamos una puerta abierta para que el Programador use uno o más elementos de interfase de usuario: un cuadro de texto para digitar, un control especializado que permita seleccionar la fecha, un calendario compuesto por listas de días, de meses y de años donde también el usuario pueda “armar” la fecha requerida o una combinación de algunos de ellos.

Por supuesto, es posible que más adelante, durante las fases de análisis y diseño, cuando se suplemente el caso de uso, los posibles medios de implementación se particularicen de acuerdo a otros aspectos como los estándares de diseño gráfico, aspectos de usabilidad, restricciones de la aplicación, entre otros.

3. El versionamiento y el involucramiento del usuario. Es importante tener una versión del caso de uso tan pronto como sea posible, empezar a discutirla con el usuario, refinar la versión y congelarla tan tarde como sea posible, eso sí, antes de que finalice la etapa de especificación de requisitos, ya sea para una iteración en particular o para una fase determinada del proceso. (De Iteraciones y de Fases será otro tema para una lectura fundamental futura).

Ahora bien, el usuario nunca especifica o documenta casos de uso, pero sí los revisa, propone cambios y los aprueba. Hay un tiempo para todo. Si el cambio propuesto ocurre después de finalizada la etapa de especificación, es tarea del Analista de reportarlo como lo que llamamos comúnmente un control de cambio.

¿Y sobre la evolución del caso de uso? Por evolución me refiero aquí a lo que sucede con un caso de uso una vez está aprobado (versión 1.0) por el usuario. Se trata del análisis, el diseño, la implementación, la integración, las pruebas, la puesta en operación del caso de uso. Son temas extensos, motivo de más lecturas fundamentales por hacer.

Lectura Fundamental Siguiente: “Casos de Uso: Del Todo y de Sus Partes”

[1] IBM Rational Unified Process –RUP
[2] seleccionar. tr. Elegir, escoger por medio de una selección. Real Academia Española © Todos los derechos reservados.

Lecturas Fundamentales

2006-11-09T21:55:00.000-05:00

Lectura # 1
Casos de Uso: De Vuelta a lo Fundamental

Volvamos a lo básico: un caso de uso es un conjunto de secuencias de actividades ejecutadas, normalmente por la interacción entre un ser Humano y una máquina. Las actividades son iniciadas por una entidad externa llamada Actor y las actividades terminan con un resultado de valor observable para ese Actor.

Desde otra perspectiva, la del usuario que usa el sistema, un caso de uso es una pieza de funcionalidad de software, casi siempre, una pieza indivisible, que tiene:

Uno o más datos de entrada, el estímulo
Uno o más datos de salida, la respuesta
Un número finito de pasos o tareas, el proceso
En principio, cada uno de esos pasos bien podría realizarse usando “sólo lápiz y papel”, la simplicidad
Un comienzo, la orientación
Un fin, el éxito.

¿Alguien recuerda a qué se parece esa definición?

Un caso de uso es el primer peldaño en la conversión de las necesidades de los usuarios a un sistema automatizado. Es el primero, el cimiento: para llegar al cielo todavía se requieren muchos otros elementos (léase análisis, arquitectura, diseño, implementación…)

Un caso de uso es el componente primario del modelo dinámico de un sistema, ese que hace e intenta responder la pregunta: ¿qué hace el software? Ese que juzga (analiza) el sistema por sus acciones. Sí, ese del que se dice es una representación abstracta de lo que hace el software, el que define el comportamiento del sistema.

Ahora bien, habitualmente un caso de uso se escribe en el formato “el actor hace…, el sistema hace…” un diálogo, un guión, una escena, en este caso, de un sistema de software.

Con esto en mente, resolvamos varias preguntas que siempre llegan a mi buzón:

¿Cuántas secuencias forman el “conjunto de secuencias” del caso de uso? Una, dos, tres…, un número pequeño, contable de secuencias. Como en casi todos estos temas, no está escrita la última palabra. Depende del contexto, del proceso de negocio que implementa el caso de uso, del resultado esperado, de la cantidad y calidad de los datos de entrada, de la habilidad de los usuarios del caso de uso, de los escenarios de usabilidad, de…, la lista de es larga.

En breve, un caso de uso de una única secuencia puede ser mucho más complejo que un caso de uso de media docena de secuencias. El asunto es: el número de secuencias de pasos no es el único capricho de un caso de uso.

Entonces ¿cuántas actividades tiene una secuencia? La respuesta es la misma: un número pequeño. Las prácticas contextuales nos dicen que siempre habrá una secuencia “regular”, la que más ocurre, la principal, la básica; y también podrán existir cero, una, dos, tres…, secuencias de menor ocurrencia, secundarias, eventuales, cada una de ellas, quizás, con un número menor de pasos que la primera.

¿Una secuencia es lo mismo que un escenario? Ah, este es un error muy común que cometemos. Apenas es una feliz coincidencia que sean lo mismo; pero de una secuencia, principal o no, pueden surgir uno o más escenarios.

Definición 1: Un escenario es un “camino” de ejecución, una instancia, del caso de uso con datos reales, donde el actor tiene un nombre, los datos tienen un valor específico y donde efectivamente hay un resultado que se puede “ver”. Quienes alguna vez han diseñado casos de prueba conocen bien esta diferencia. De hecho, un escenario puede (y habitualmente lo hace) ir a través de varias secuencias, normalmente, la principal y una o más secundarias. En síntesis, los escenarios son hilos cohesivos de comportamiento del caso de uso ocasionados por el estímulo que este recibe desde el exterior.

¿Y esas actividades cómo se escriben? ¿Cuál es el alcance de las mismas? Se escriben en terminología del usuario, sin detalles técnicos; en términos lingüísticos, siempre deberían ser escritas como una expresión verbal simple, sin adornos, sin sinónimos, sin adjetivos, sin comentarios del autor: un caso de uso es “orientado-al-verbo” si quisiéramos parafrasear algunos de los términos más usados por quienes nos movemos por los vericuetos insondables del tratamiento sistémico de la información.

En eso se diferencia un caso de uso de un guión de teatro, por ejemplo. Este último es rico en emociones, en observaciones, en detalles analógicos y puntos de vista subjetivos tanto del autor como de los personajes que intervienen.

¿Y qué hay del nivel de granularidad? Aquí entramos en el dilema del CRUD[1] o no CRUD, esa es la cuestión. Por agilidad deberíamos escribir casos de uso esenciales, no descompuestos funcionalmente, es decir, casos de uso que no entren en el nivel de detalle de la “pantalla” o del “formulario”, de los botones y cuadros de texto. Un caso de uso esencial deja un margen de maniobra al Analista, al Programador, al Arquitecto y aún al Probador. Los detalles de usabilidad, colorido y presentación bien podrían ser consignados en documentos auxiliares, en estándares en los cuales basar su implementación. Escribir casos de uso CRUD y similares aumenta innecesariamente el número de casos de uso, el tiempo de especificación, el tiempo de revisión, el tiempo de aprobación. Sí, quizás disminuya el tiempo de programación, pero este es cada vez más reducido a la luz de las poderosas herramientas con las que contamos hoy para escribir código fuente.

Definición 2: un caso de uso esencial se caracteriza porque: la funcionalidad CRUD es una porción del caso de uso, el actor que lo inicia está bien generalizado, su secuencia básica completa una interacción mayor con el sistema, no está asociado con componentes arquitectónicos o del sistema, es completamente independiente de la implementación de la Interfaz de Usuario, contiene un número mayor de secuencias alternas (hummm, esto podría representar algún tipo de inconveniente a la hora de cualificar la legibilidad del caso de uso), representa muchos ejemplos concretos de interacción, es decir, deriva en muchos escenarios, es bastante útil para pruebas del sistema y de funcionalidad. Finalmente, un caso de uso esencial forma parte de un modelo de casos de uso cuyo número de extensiones e inclusiones es menor al 20% de todo el modelo.

Definición 3: un caso de uso descompuesto funcionalmente es aquel que aborda un solo elemento CRUD a la vez, está vinculado a usuarios concretos específicos, no a actores abstractos, su flujo básico no completa una interacción mayor con el sistema, en cambio, describe funciones primarias del mismo, está completamente ligado a un componente del sistema o a un componente arquitectónico específico, está vinculado a una pantalla o función de usuario determinada y contiene instrucciones concretas de diseño de IU, incluye de cero a dos flujos secundarios frecuentemente relacionados con datos, Los escenarios derivados casi siempre deben invocar varios casos de uso para completar un ejemplo integral y es útil para pruebas unitarias. Para terminar, en un modelo de casos de uso descompuestos funcionalmente más de la mitad de los casos de uso son inclusiones o extensiones.

Una práctica contextual beneficiosa es sacrificar el modelo de los casos de uso descompuestos funcionalmente en aras de un diseño arquitectónico robusto y estable, de un modelo estático consistente y resistente y de una especificación más limpia y clara para quien, en últimas, revisa y aprueba cada caso de uso: el usuario.

Ejemplo # 1: el caso de uso “Hola Mundo”

Este es un caso de uso simple:

El caso de uso inicia cuando el Actor ejecuta la aplicación Hola Mundo
El sistema muestra el mensaje “Hola Mundo.”
El caso de uso termina

Ya tendremos la oportunidad de entrar en detalles acerca de como se escribe un caso de uso.

Lo que viene: bueno, habrá más de estas lecturas fundamentales. ¿De dónde surgen los casos de uso? ¿Y qué hay de los actores? ¿Cuándo un caso de uso está terminado? ¿Hay vida más allá de los casos de uso?

Estas y otras cuestiones nos aguardan en el universo binario de la técnica y la ciencia informática.

Lectura Fundamental Siguiente: “Casos de Uso: Origen, Especificación y Evolución”

Hasta entonces.

[1] CRUD: Create Read Update Delete (Crear, Leer, Actualizar, Eliminar). Operaciones fundamentales de los sistemas de información.

Prolegómenos Sobre el Lenguaje de Modelado Unificado

2005-06-01T17:32:00.000-05:00

Este artículo se puede bajar haciendo click a continuación:

Prolegómenos Sobre el Lenguaje de Modelado Unificado

Me puedes contactar en lucho.salazar@gmail.com

Problemancia y Solucionancia

2005-05-17T15:17:00.000-05:00

De todas las preguntas, observaciones y similares que me llegan a diario y que desafortunadamente por razones de tiempo no puedo atender en su completitud, quiero referirme esta vez a algunos comentarios y cuestiones que un colega me hace, a raíz de mi artículo anterior sobre Iteraciones. Ya le respondí a él, pero luego pensé que era interesante ampliar mis respuestas y darlas a un público más amplio, porque además son una muestra representativa de los temas que siempre discuto en los grupos de trabajo.

Como siempre, los nombres y algunos datos fueron cambiados para proteger la identidad de los culpables.

Sobre RUP

Nuestro amigo empieza diciendo que “RUP no es una metodología, sino un Proceso y como tal tiene metodología y responsables de las actividades y artefactos.”

Ciertamente. RUP es un proceso de ingeniería de software, ya había hecho una presentación al respecto en El Imperio de las Metodologías, así es que estoy de acuerdo con esa apreciación, sin embargo, en el contexto en el que lo uso, Proceso y Metodología son sinónimos. Ahora van a salir los puristas del idioma a decirme que eso no es cierto, que hay una diferencia bien marcada. Pero no se trata de eso, hablo de las situaciones en las que uso las palabras: metodología es un término más arraigado en nuestro medio informático que proceso, que nos suena más a algo químico. Hay que ser flexibles en ese sentido y eso me da pie para hablarles de algo más adelante sobre adaptación.

Formalmente, un proceso es un conjunto de pasos ordenados con los que se busca un objetivo; en ingeniería de software, el propósito es construir un producto de software; en el caso de RUP, esos pasos están organizados en Disciplinas que a su vez definen Flujos de Trabajo y otros elementos del proceso.

Nuestro colega sigue diciendo que “en este momento él y su equipo se encuentran desarrollando un proyecto bastante grande siguiendo los lineamentos de RUP, y por ser la primera experiencia ha sido difícil la aplicación (el proyecto es contratado con una empresa desarrolladora de Software). Están precisamente terminando la 4a iteración de la fase de Elaboración.”

Ya he tenido experiencias con RUP (coincidencialmente, la primera de ellas hace algunos años, fue con un proyecto también muy grande, como el mencionado), y también ha sido complejo aplicarlo. Ha sido un proceso de adaptación y adopción, yo lo he llamado en mis conferencias “de tropicalización”. Este tipo de proyectos son escasos en nuestro medio (quiero decir, proyectos de software de varias docenas de personas y de varios años de duración), pero se dan algunas veces. La experiencia, en todo caso, ha sido enriquecedora (a veces ha sido dura, pero los resultados se han visto). En particular, celebro que estén involucrados en este tipo de procesos, creo que es la única forma de mejorar la calidad de lo que hacemos, productos de software.

Voy a hacer énfasis en esto de la adaptación y adopción. El Proceso Unificado tiene muchos “roles” responsables de esa gran cantidad de actividades y de ese enorme conjunto de artefactos que se pueden generar siguiendo el proceso al pie de la letra. Pero una de las grandes ventajas de RUP es que, aunque rígido, permite cierta flexibilización por parte de quienes lo siguen. Y aquí “seguir” es la palabra clave, como lo anotaba nuestro lector en su comentario anterior. Esto quiere decir que no debemos meternos de cabeza en el proceso, sino acomodar y aceptar muchos de sus delineamientos, teniendo en cuenta siempre las habilidades del equipo del proyecto, el tiempo de entrega y los recursos (no es lo mismo “RUPizar” con las herramientas que proporciona IBM Rational –RequisitePro, Rose, Robot, XDE, entre muchas otras, que hacerlo prácticamente con lápiz y papel, como ocurre en muchos lados a nuestro alrededor.)

Por ejemplo, es posible tener en un mismo documento (o Artefacto), La Visión del Sistema, la Especificación de Requisitos y la Especificación Suplementaria, y no en tres documentos separados como propone el proceso. Esto ahorra tiempo, esfuerzo y proporciona un mayor entendimiento del sistema en construcción: la idea es hacer encajar las partes comunes y no comunes de cada uno de esos elementos en uno solo de ellos. Es una propuesta, funciona bien, en proyectos pequeños y medianos, los que hacemos con la llegada de las lluvias.

Sobre Mecanismos de Análisis, Diseño e Implementación

Luego pasamos al tema de las preguntas, inquietudes razonables, a las que traté de dar respuesta desde mi punto de vista y soportado en mi experiencia. Aquí la primera:

Los Mecanismos de Análisis, Diseño e Implementación deben quedar en un artefacto o documento en la fase de Elaboración, necesariamente? O se pueden entregar en la fase de Construcción? Y cual sería la importancia de tenerlos en la fase de Elaboración?

Trataré de definir en palabras simples qué es esto de los Mecanismos de Análisis, Diseño e Implementación. Un mecanismo de análisis representa un patrón que constituye una solución común a un problema común. Afortunadamente para nosotros, en ingeniería de software ya existen muchos problemas documentados, y con la aparición de cada nueva plataforma o tecnología, se documenta la forma de solucionar esos problemas habituales. Puedo citar algunos ejemplos prácticos: Manejo de Errores o Fallas del Sistema, Sincronización de Procesos y Acceso a Datos. En general, los mecanismos de análisis nos permiten concentrarnos en el análisis de los requisitos funcionales, el problema propiamente dicho, y no sumergirnos en ciertas complejidades que nos pueden conducir a la llamada “parálisis del análisis”, muy temida por todos.

Entre tanto, un Mecanismo de Diseño es un refinamiento de un mecanismo de análisis correspondiente. Un mecanismo de diseño agrega detalles concretos al mecanismo de análisis conceptual, pero llega hasta justo antes de proponer una técnica particular de implementación. Tanto los mecanismos de diseño, como los de análisis pueden instanciar uno o más patrones, en este caso, patrones arquitectónicos o de diseño.

De manera similar, un Mecanismo de Implementación es un refinamiento de un mecanismo de diseño correspondiente, usando ya una plataforma o lenguaje de programación específicos. Por ejemplo, para cada uno de los problemas que mencioné arriba ya existen soluciones en una plataforma como Microsoft.Net (y supongo que en J2EE también existirán). De los siguientes enlaces pueden bajar la solución a esos problemas, cuando se trata de usar tecnología Microsoft:

Manejo de Errores o Fallas del Sistema
Sincronización de Procesos
Acceso a Datos
Y aquí pueden bajar otras soluciones comunes.

Y para responder la duda citada, los mecanismos de Análisis, Diseño e Implementación hacen parte de lo que yo llamo “documentación interna”. Efectivamente, pueden hacer parte, por ejemplo, del documento de arquitectura, en cuyo caso lo extenderían y lo harían más complejo, innecesariamente. Lo que sí debe quedar en este documento son las relaciones o el mapeo de los mecanismos de análisis con los mecanismos de diseño con los mecanismos de implementación. Estos, a su vez, sí pueden quedar en el documento de Guías de Diseño, que también es responsabilidad del Arquitecto y que hace parte del Modelo de Diseño. En cualquier caso, estos mecanismos siguen siendo un asunto “peliagudo” (no sé si entiendan el término –“complicado”), son temas algo abstractos y muchas veces prefiero evitarlos, al menos, presentarlos al cliente (aun al representante del área de tecnología), pues siempre sigo la premisa de que “modelamos para entender el sistema que luego vamos a construir”.

Ahora bien, estos mecanismos, muy tarde, deben estar para el refinamiento de la arquitectura, hacia el final de fase de Elaboración. La idea es que haya suficiente claridad al momento de enfrentar el gran grueso de Construcción y que las soluciones comunes estén quizás ya implementadas. Reusabilidad ante todo. Además de esto, son importantes en Elaboración porque son un indicador de que conocemos muy bien el sistema, su arquitectura, la forma como se va a construir e implantar y porque, precisamente, tenemos desde el inicio de la construcción un conjunto de soluciones preestablecidas.

Sobre el Modelo de Dominio

El Modelo de Dominio es indispensable como insumo del documento de arquitectura? Es decir, lo necesito como insumo para validar la vista Lógica?

De acuerdo al Proceso Unificado, un modelo de dominio es un modelo de objetos del negocio que se enfoca en “el producto, entregables o eventos que son importantes para el dominio del negocio.” Un modelo de dominio es un modelo del negocio “incompleto”, en tanto omite las responsabilidades de los individuos. El modelo de dominio típicamente muestra las entidades mayores del negocio, sus responsabilidades funcionales y las relaciones entre esas entidades.

Sin duda, el modelo de dominio es útil para validar la vista lógica de la arquitectura, pero no solo para eso, de hecho, es la base de dicha vista, creo que sin el modelo de dominio no podremos obtener la vista lógica completa y realmente tampoco estaríamos en capacidad de avanzar mucho, porque no tener el modelo de dominio indica que todavía no conocemos lo suficiente el sistema. Sin embargo, en la práctica, el modelo de dominio evoluciona hasta la fase de Construcción, cuando todavía desarrollamos casos de uso que no se trataron en Elaboración.

Sobre Casos de Uso Significativos

Cuántos casos de uso sería aconsejable desarrollar en la fase de Elaboración para definir la línea base de arquitectura?

Cuántos casos de uso? Muchos. Depende del número total de ellos. La última palabra sobre este tema no está dicha ni aceptada, pero podríamos estar hablando de más del 60% de los casos de uso, al terminar la fase de Elaboración. Los que sí deben estar terminados son los casos de uso significativos para la arquitectura, aquellos que tienen mayor impacto sobre la misma.

Con una docena de casos de uso seleccionados como arquitectónicamente significativos de más de mil casos de uso identificados hasta el momento (final de la fase de Elaboración), puedo decir que mi arquitectura es estable? Estos casos de uso arquitectónicamente significativos se escogieron teniendo en cuenta el riesgo tecnológico que representaban para su implementación desde el punto de vista técnico.

Una docena de casos de uso me parece un número muy pequeño comparado con más de mil de ellos. Desde el exterior, y desde mi perspectiva, no creo que podamos hablar de una arquitectura estable. Si seguimos los delineamientos de elaboración de casos de uso, por lo menos, deberíamos tener un centenar o más de ellos arquitectónicamente significativos. Ahora bien, mil casos de uso es un número muy grande para un sistema, yo diría que exageradamente grande, dado que los casos de uso son el medio a través del cual los usuarios (aunque no siempre es así) se comunican con el sistema. Estamos hablando entonces de que el sistema en construcción tiene más de mil maneras de acceder a el. Lo veo complejo desde aquí. Recordemos además que un caso de uso puede tener más de un escenario o secuencia alternativa, con lo que estaríamos hablando tal vez de miles de escenarios. Mucho, pienso yo.

Se debieron escoger Casos de Uso Arquitectónicamente significativos desde el punto de vista de los usuarios o stakeholders y que representen la funcionalidad de negocio? De no tenerse en cuenta estos casos de uso, qué riesgo presenta la definición de la línea base de arquitectura?

Sí, se debieron (se deben) escoger. Pero con mucho cuidado. Algunas veces los usuarios piensan que un caso de uso (una funcionalidad es compleja o significativa) porque simplemente hacen uso de miles o millones de registros en muy poco tiempo y resulta que quizás para nosotros el asunto se resuelve con un algoritmo implementado en un procedimiento almacenado, para lo que se supone somos expertos.

Si el usuario nos dice, por el contrario, que sin importar el sitio de origen, la transacción debe llegar al servidor central y responder al usuario en menos de cinco segundos, así la transacción sea traer unos datos básicos de un cliente dada su cédula, usando los canales existentes en la compañía, entonces sí que debemos preocuparnos. Y como este hay muchos casos que se deben tener en cuenta a la hora de seleccionar los “significativamente arquitectónicos”.

Sobre La Vista Lógica

La vista Lógica me debe mostrar el Core de mi negocio? O que esperaría ver en ella?

El “core” del negocio debe reflejarse de alguna forma en la vista lógica si el sistema Es para el “core” del negocio, de lo contrario no. En cualquier caso, la vista lógica muestra paquetes de alto nivel, subsistemas, clases y las realizaciones de casos de uso. Observemos que si el sistema es “core”, las clases del dominio reflejan precisamente el negocio.

Conclusiones

Y bueno, como recomendación adicional, les sugiero que traten de “platanizar” RUP, como dicen algunos de mis colegas, adoptarlo, sí, pero adaptarlo a nuestros recursos, a nuestras habilidades, a nuestro entorno, donde no tenemos el tiempo ni el presupuesto de los grandes proyectos de otros lados. Quizás combinarlo con prácticas ágiles y obtener una “metodología” acorde al medio.

Como siempre, los invito a que compartan conmigo y con todos sus comentarios acerca de este artículo. Me pueden escribir a luissalazar@usa.net o en http://gazafatonarioit.blogspot.com/.

Luis Antonio Salazar Caraballo

Medellín, Noviembre 4 de 2003

Desarrollo de Software por Iteraciones

2005-02-14T17:58:00.000-05:00

Introducción
Una de las prácticas que más inquieta a los productores de software, una de las llamadas Mejores Prácticas, es esta de las Iteraciones en un proyecto. Una Iteración, para empezar, puede ser vista como un mini-proyecto, sin que el prefijo “mini” quiera decir que el proyecto está inconcluso o es de mala calidad, No. De hecho, esta práctica ha demostrado que el producto final es de mejor calidad que el elaborado mediante metodologías tradicionales como Cascada.
Formalmente, una Iteración abarca el desarrollo de actividades que conducen a la liberación de un producto –una versión ejecutable y estable de un producto, junto con cualquier otro elemento periférico necesario para usar esta versión, como la documentación respectiva, para citar un caso. Desde este punto de vista, en una Iteración se hace un paso completo por todas las etapas del desarrollo de software, desde el análisis de requisitos, hasta la programación y, quizás, puesta en producción, pasando por análisis y diseño, pruebas y control de cambios. Si se quiere es como un proyecto pequeño realizado “en cascada”.
Pero alrededor del concepto de las Iteraciones hay involucrados muchos aspectos de relevancia: cuántas iteraciones tiene un proyecto? Cuánto tarda una iteración? Todas las iteraciones tardan lo mismo? Qué es la Liberación de un producto? Cómo se seleccionan los requisitos a implementar en una iteración? Y muchas otras.
Beneficios
Antes de tratar algunas de esas cuestiones, insistiré en los motivos por los cuales debemos iterar:
Ø Puesto que una iteración es un proyecto pequeño completo, hay un mejor control de los recursos, el talento humano asignado al proyecto, la calidad del producto implantado y los cambios en requisitos que se puedan producir durante el tiempo total del proyecto.
Ø Disminución en los riesgos de un proyecto. Hablo de riesgos tecnológicos, de riesgos administrativos y hasta del entorno. Por ejemplo, es posible que para implementar un requisito, o un conjunto de ellos, un equipo seleccione las herramientas y/o la técnica y/o la plataforma equivocada. Y de esto no se dan cuenta hasta que el producto (la versión a liberar en esa iteración) no está listo o casi listo. Por ejemplo, los tiempos de respuesta no son adecuados, la seguridad de los datos no se puede garantizar, el manejo de concurrencia no es aceptable, entre muchos otros aspectos. En un proyecto tradicional, estos hechos solo se ven al final del mismo, cuando ya no hay tiempo de hacer correcciones, de buscar alternativas, cuando se perdió la oportunidad (el costo de oportunidad), etc. Sin embargo, en un proyecto iterativo, muy probablemente todavía habrá tiempo (luego de buscar a los culpables y de elogiar a los no participantes!) de hacer algo. Cómo qué? Se define otra iteración, con otra técnica, con otras herramientas, con otra plataforma, lo que sea necesario, para asegurar que esta vez el requisito sí va a ser bien implantado.
Ø Las iteraciones relajan los nervios. Hablo de las expectativas que tienen los usuarios, los patrocinadores (llamados en lenguaje metodológico stakeholders), los desarrolladores; hablo también del producto que se libera o entrega en cada iteración. Cuando aquellos ven este, verifican la funcionalidad (los casos de uso), la calidad (desempeño, seguridad, estándares, entre otros), se forjan nuevas ideas de lo que ha sido, es y será el producto final (por supuesto están los “yaques” –ya que hiciste el cálculo de la retefuente, por qué no generas un informe que se envíe por Mail en formato Excel al gobierno?) En mi caso, validan la capacidad (de respuesta) del proveedor, comprueban que obtuvieron lo que compraron y los usuarios comienzan a hablar de las siguientes fases del proyecto, sin haber terminado esta. Recuerden, se terminó una iteración, no el proyecto. En cualquier instancia, los usuarios, sobre todo, no tienen que esperar meses o años para ver su producto, preguntándose todo el tiempo si estos chicos de Sistemas van a entregar y cuándo y que será lo que están haciendo y si habrán entendido lo que querían decir.
Ø Hay otros beneficios técnicos, como que la reusabilidad se facilita y se mejora. Esto es claro, porque una vez terminado un producto, o parte de el, sus componentes ya están ampliamente probados y documentados y se podrán usar en las iteraciones sucesivas donde seguramente serán sometidos a incrementos graduales. También se puede aprender en el camino: me refiero a que los desarrolladores pueden no solo aprender de sus errores pasados, sino de las nuevas técnicas a utilizar durante la iteración; también, las competencias y especialidades que se necesitan para una iteración específica son mejor utilizadas, es decir, es posible emplear desarrolladores diferentes en cada una de las iteraciones del proyecto.
Cómo Iterar
Ahora sí, trataré de resolver algunos de los temas que planteé antes.
Ya sabemos que el desarrollo de un proyecto debe hacerse teniendo como punto de partida y como conductor los casos de uso. Una vez que hayamos elaborado el documento de Especificación de Requisitos (Funcionales y No Funcionales), se escriben las descripciones de todos los casos de uso del sistema (hablo de Nombre del Caso de Uso, Actor, Descripción General y cualquier otra información que se tenga al momento de elaborar las Especificaciones.)
Con esta lista, procedemos a “calificar” los casos de uso. Esta calificación la hacemos de acuerdo al grado de importancia y de criticidad, en cuanto a riesgo de implementación se refiere, de cada caso de uso.
Respecto a su importancia, un caso de uso, como veremos en un artículo próximo sobre el tema, puede clasificarse en: Requerido, Importante o Adicional. Los primeros son aquellos sin los cuales el sistema no puede funcionar. Los casos de uso Importantes son aquellos sin los cuales el sistema puede funcionar, al menos, durante algún tiempo, pero que debemos implementar tan pronto como sea posible. Mientras tanto, los casos de uso Adicionales son aquellos no obligatorios para el sistema (los “yaques” que mencionaba antes), los Buenos, Bonitos y Baratos, como decimos popularmente. Por supuesto, la implementación de estos últimos debe hacerse siguiendo los mismos delineamientos metodológicos y técnicos que los demás; el que sean Adicionales, no los hace de menos calidad o incompletos o no sujetos al mismo proceso de pruebas que los otros.
En relación a su Criticidad, los casos de uso se califican de 1 a 5, por ejemplo, donde 1 es de menor riesgo, 3 es de riesgo aceptable y 5 es de riesgo muy alto. Este riesgo se refiere a la implementación del caso de uso y se debe medir a la luz de varios criterios:
Ø Conocimiento del tema (del negocio) por parte de los usuarios y de los desarrolladores. Hay usuarios que desconocen parte de lo que quieren resolver a través de un sistema (porque la legislación o las políticas son nuevas, o porque son nuevos en la compañía, etc.) También hay desarrolladores que creyeron entender algo del usuario pero no fue así, sobre todo los noveles que, al momento de una entrevista con el usuario, están pendientes de cómo resolver el problema y no de escuchar y comprender todo lo que les quisieron decir.
Ø Habilidad y/o experiencia de los desarrolladores en el uso de la plataforma, herramientas y técnicas utilizadas para llevar a cabo la implementación. Qué se requieren Web Services, que la plataforma .Net, que XML, que UML, que C# (léase C Sharp), que J2EE, que…, en fin, un gran universo de siglas de las que les hablaré en otra ocasión. En todo caso, estos son apenas los medios, algo en lo que se supone somos especialistas, sin embargo, algunas veces no es así. Visto así, un caso de uso que en la práctica es fácil de programar, podría tener un alto riesgo de implementación debido a la poca experiencia del programador.
Ø Y otras como Tiempo de Desarrollo, Número de Analistas y de Programadores, calidad de los requisitos en cuanto a su precisión, compromiso del personal externo necesario para llevar a cabo una implantación (que la gente de Seguridad, que la gente de Calidad, que la gente de Capacitación).
Ya con los casos de uso listados y clasificados, con el tiempo límite del proyecto en mente, con el número de desarrolladores establecido, podemos hacer un Plan de Iteraciones. Este es un conjunto de actividades y tareas secuenciadas en el tiempo, con talento humano asignado y con el conocimiento de las dependencias entre tareas, para cada iteración; un plan bien detallado. Normalmente, siempre hay dos planes activos: uno para la iteración actual y uno en construcción para la siguiente iteración. El plan incluye actividades de Análisis de Requisitos, Análisis y Diseño, Programación, Pruebas y Afinación, y Puesta en Marcha; también, control de cambios, documentación y capacitación.
Las primeras iteraciones deben planearse para implementar los casos de uso Requeridos y de Criticidad Máxima (5). Les dejo una inquietud: existen sistemas que no tengan casos de uso de criticidad 5?
Cuántos casos de uso por iteración? Depende del número total de casos de uso y del número de casos de uso Requeridos y Más Críticos, y además del número de desarrolladores dispuestos para la implementación. Una iteración podría implementar solo un par de casos de uso, o 10 de ellos, o quizás 20 o más. En el artículo de casos de uso exploraré más este tema.
El tiempo, la duración, de las iteraciones es otro factor importante. No está dicha la última palabra a este respecto. En un proyecto pequeño (de pocos meses –dos o tres, quizás), con pocos desarrolladores (dos o tres tal vez–o hasta uno), iteraciones de dos semanas son aceptables. En un proyecto mediano (seis meses, hasta cinco desarrolladores), iteraciones de tres o cuatro semanas son bienvenidas. En un proyecto grande (más de seis meses, más de seis desarrolladores), iteraciones de hasta seis semanas son bien vistas.
Debo anotar que esta clasificación del tamaño de los proyectos de acuerdo a la duración y al número de desarrolladores es un poco arbitraria, soportada en la trayectoria de quien les escribe y de algunos colegas con quienes he discutido el tema. Hablo de nuestro medio. La literatura que nos llega de otras latitudes se refiere a algo totalmente distinto, donde un proyecto pequeño tarda un año y tiene 10 desarrolladores, por ejemplo.
En mi columna anterior decía que una iteración no debería tardar más de un mes. Este asunto de las iteraciones de mes y medio que menciono arriba también es viable si se tiene un buen control del proyecto. Recuerden que este es uno de los grandes beneficios del desarrollo iterativo, el control del proyecto, obtención rápida de resultados, mitigación de riesgos.
Ahora bien, aunque es bueno que todas las iteraciones tarden lo mismo, en la práctica es posible que esto no se dé. Hay iteraciones que por su simplicidad pueden tardar dos semanas, otras pueden tardar cuatro. Lo importante es que los recursos estén disponibles al momento de iniciar cada iteración y se tenga claridad sobre los requisitos que se van a implementar.
Sobre Versiones y Entregas
La Liberación de un producto puede ser Interna o Externa. Es Interna cuando solo será usada por el grupo de desarrolladores durante la ejecución de otras iteraciones en las que se completará un producto propiamente dicho. Y es Externa cuando se trata de un producto de software completo, funcional, que se puede poner en producción.
Ambos tipos de entrega van acompañados de pruebas y afinación, documentación, capacitación y todos los artefactos necesarios para que el proyecto pueda seguir su marcha. Si es un entregable externo, debe tratarse como el mismísimo producto final.
También, las dos especies de producto están sujetos a versionamiento. Sea un componente, la base de datos o una porción de la misma, un grupo de páginas ASP.NET o el producto de software en su completitud, incluyendo los documentos asociados, siempre debemos conocer su versión. Les recomiendo un versionamiento simple: Versión Mayor y Versión Menor; por ejemplo: 1.1, 2.5, 4.0. Creo que no es necesario utilizar las convenciones de las grandes casas productoras (que 8.04.003.185 Build 4321 o cosas así.)
Lo que sí deberíamos incluir, cuando sea del caso, son las Revisiones. Estas son pequeñas modificaciones o ajustes que quizás exigieron compilar y empaquetar de nuevo el software, pero nada más: la documentación es la misma, la funcionalidad no cambió, el impacto no se notó. Las cosas así, podríamos tener una versión 2.5 revisión 3 o una versión 4.0 revisión 2. Por supuesto, el número de revisiones es pequeño (máximo 5). De hecho, un conjunto de revisiones pequeñas quizás dan pie a una nueva versión menor (de la 2.5 a la 2.6).
Conclusión
Las Iteraciones constituyen una técnica apropiada, una mejor práctica, para la construcción de software. Se requieren nuevas habilidades en el manejo de proyectos, coordinación de equipos, documentación de software, desarrollos en tiempos más pequeños pero más especializados, equipos multidisciplinarios y compromiso de parte de todos los involucrados en el proyecto. Pero funciona, sin duda, en cualquier tipo de proyecto, con cualquier número de desarrolladores, sea cual fuere su complejidad.
Los invito entonces a que pongan en práctica este nuevo “arte” de Iterar, sin importar si usan o no una metodología estricta como RUP o una ágil. Seguramente, muy pronto verán los beneficios.
Y también los invito a que compartan conmigo y con todos en AAII sus comentarios acerca de este artículo. Me pueden escribir a lucho.salazar@gmail.com.
Luis Antonio Salazar Caraballo
Medellín, Octubre 15 de 2003

Las Seis Mejores Prácticas

2005-02-14T17:48:00.000-05:00

En cuatro de las cinco últimas columnas he hablado de una u otra forma sobre modelado de software, en particular, y sobre desarrollo de aplicaciones, en general. En “El Papel del Modelado en la Transformación de los Requisitos en Software”, por ejemplo, decía que debemos elaborar modelos simples, a partir de cada porción significativa de requerimientos del software.
En “Qué Diagramas Usar?”, expresé mi opinión de que todas las técnicas y elementos en un proceso como RUP tienen múltiples propósitos y que realmente, no hay una “forma corta”, de decidir lo que es apropiado en cada situación (de modelado). Y en “El Imperio de las Metodologías” decía que era práctico dividir un proyecto en pequeñas piezas o mini-proyectos, donde cada mini-proyecto es una iteración.
Estas y otras ideas al respecto son la base de esta nueva entrega, sobre lo que debemos y no debemos hacer al emprender un proyecto de desarrollo de software, en especial sobre lo que sí debemos hacer, las prácticas que quienes nos enfrentamos día a día al reto de construir software de alta calidad consideramos como mejores, como soporte para el éxito anunciado en los proyectos.
Combinadas unas con otras y orientadas a la raíz de los problemas cotidianos de la construcción de software, estas prácticas permiten desarrollar y mantener aplicaciones en forma repetible y predecible. Ellas son:
1. Modelar Visualmente
2. Manejar Requisitos
3. Verificar la Calidad Continuamente
4. Usar Arquitecturas Basadas en Componentes
5. Desarrollar por Iteraciones
6. Controlar los Cambios
Modelar Visualmente
Para Modelar Visualmente, es necesario usar un lenguaje de diseño con una semántica extendida que permita mejorar la comunicación en el equipo de trabajo que elabora y revisa el diseño de la aplicación. Además de los textos gramaticales, el lenguaje debe proporcionar una sintaxis gráfica predominante y rigurosa con la cual expresemos las decisiones tomadas que luego servirán como base para la implementación del sistema. De esta forma, podremos entender mejor el sistema en construcción y razonar acerca de el con precisión. Hablo, por supuesto, de aplicaciones multi-desarrollador, aquellas en las cuales se invierte una cantidad considerable de talento humano, de tiempo y, claro, de recursos.
El Lenguaje de Modelado Unificado –UML cumple con estas características. Y sobre el ya hice una presentación que pueden encontrar en: http://b.1asphost.com/LuchoSalazar/GazafatonarioIT/Prolegmenos%20Sobre%20el%20Lenguaje%20de%20Modelado%20Unificado.pdf. También en el boletín No. 5, en esta misma columna, presenté una breve discusión sobre los distintos tipos de diagramas que usamos para hacer modelado visual. La columna está en: http://gazafatonarioit.blogspot.com/2005/02/qu-diagramas-usar.html.
En resumen, el modelado visual es un requisito porque muestra la esencia del sistema desde una perspectiva particular y oculta los detalles no esenciales. Los modelos, en general, pueden ayudar a:
Ø Entender sistemas complejos
Ø Explorar y comparar alternativas de diseño
Ø Formar una base sólida para la implementación
Ø Capturar los requisitos con precisión
Ø Comunicar decisiones inequívocamente
Manejar Requisitos
El Proceso Unificado define el Manejo de Requisitos como un enfoque sistemático para encontrar, documentar, organizar y hacer seguimiento a los cambios de los requisitos de un sistema.
En este punto sería interesante que hicieran el siguiente ejercicio que les propongo: Definir que es un “requisito”, un requisito de software, ciertamente. No se imaginan ustedes las sorpresas que me he llevado cuando le digo a los asistentes a mis cursos y conferencias que hagan esa tarea, al parecer, simple para muchos. Pues bien, desde el punto de vista de RUP, un requisito es una “condición o capacidad que el sistema debe cumplir o tener”.
Mientras escribo esta columna, John Alexander López prepara un artículo introductorio sobre manejo de requisitos de software. Esperemos a ver lo que tiene que decirnos al respecto. Lo que sí quiero dejar claro desde ya es que la recolección de requisitos puede sonar como una tarea simple y, sin embargo, puede causar estragos significativos en un proyecto porque los requisitos:
Ø no siempre son obvios y pueden venir de muchas fuentes
Ø no siempre son fácilmente expresables en palabras
Ø son de muchos tipos y de distintos niveles de detalle
Ø si no son controlados desde el comienzo del proyecto, su número puede crecer hasta límites inmanejables
Ø están sujetos a cambios “sin previo aviso”
Ahora bien, para manejar requisitos exitosamente, se requiere:
Ø Analizar el problema
Ø Entender las necesidades tanto de los patrocinadores del proyecto, como de los usuarios y demás responsables del mismo
Ø Definir el sistema
Ø Manejar el alcance del proyecto
Ø Refinar la definición del sistema
Ø Manejar los cambios
Cada una de estas actividades requiere de talento y, evidentemente, de tiempo y recursos compartidos en el equipo de desarrollo. En las próximas entregas les hablaré más del asunto.
Verificar Calidad Continuamente
Una vez me dijeron acerca de la Calidad: “yo no sé como describirla, pero soy capaz de reconocerla cuando la veo”. Les dejo una vez más la tarea de definir lo que es Calidad, concretamente, Calidad de Software.
Lo que sí quiero ilustrar en esta columna es que se debe evaluar la calidad de todos los artefactos en distintos puntos del ciclo de vida del proyecto, a medida que este crece. Estos artefactos deben ser validados al término de cada actividad o etapa que los produce (más adelante les hablaré de Iteraciones y de los resultados que se esperan en cada una de ellas). Específicamente, a medida que se producen componentes ejecutables del sistema, estos se deben someter a un proceso de pruebas que abarque los distintos escenarios para los cuales fueron construidos (todos los escenarios, hasta aquel que solo va a acontecer una vez en la vida útil del sistema y quizás hasta el que nunca va a suceder pero que es posible que ocurra).
Este proceso de pruebas conduce a la depuración del sistema y a la eliminación de los defectos arquitectónicos de la aplicación.
Usar Arquitecturas Basadas en Componentes
En ocasiones pienso acerca de cada ser humano como un imperio y acerca de la humanidad como una summa de imperios. Y una característica común a todos los imperios es que poseen tecnología y estrategias de guerra superiores a las de los conquistados, entre las que se encuentra la famosa “divide y vencerás”, utilizada por Julio César o Hernán Cortés y adoptada hoy como herramienta guerrera por las compañías multinacionales simplemente porque los imperios buscan el control puro y escueto de los conquistados.
Esta analogía me sirve para mostrarles que siempre hay que tener control (nosotros, el imperio) sobre lo que hacemos (soluciones de software). La estrategia de Julio César o Cortés se ha aplicado desde siempre en el desarrollo de software y se seguirá aplicando sin importar la metodología, el proceso, los avances tecnológicos o la cantidad y calidad de talento humano utilizado para crear un producto.
Y cuando dividimos ese producto en piezas más pequeñas, controlables, ajustables, intercambiables, lo que nos queda son grupos cohesivos de código, fuente o ejecutable, con interfaces y comportamiento bien definidos que proporcionan un fuerte encapsulamiento de su contenido. Estos grupos forman la arquitectura basada en componentes de nuestro sistema. Una arquitectura así tiende a reducir el tamaño y la complejidad de la solución y, por supuesto, es más robusta y resistente.
Hoy, las plataformas .Net o J2EE suministran las referencias arquitectónicas que necesitamos para diseñar y construir soluciones basadas en componentes. Como antes, ya se encuentra en preparación un artículo sobre la plataforma .Net que será publicado en el sitio Web de la Asociación.
Desarrollar por Iteraciones
Pero la arquitectura y el producto no es lo único que dividimos al ejecutar un proyecto. El mismo proyecto está sujeto a un fraccionamiento que ha mostrado ser muy efectivo.
La división de un proyecto en grupos continuos de proyectos más pequeños, sujetos a incesante revisión, dinámicos y evaluables, hace posible que tengamos completo control de todo el proyecto.
En El Proceso Unificado - Episodio IV, de hace un mes, expuse las razones por las cuales deberíamos adoptar esta práctica sin reparos. Antes de que volvamos a leerla, quisiera dejarlos con estas tres leyes que escribí hace pocos meses, luego de una discusión amena sobre manejo de proyectos:
Ø Todo proyecto de menos de dos semanas, tarda dos semanas
Ø Todo proyecto de entre dos semanas y un mes, tarda un mes
Ø No hay tal cosa como un proyecto que tarde más de un mes
Por supuesto, me refería a las iteraciones, que realmente pueden tardar más tiempo, algunos dicen que entre tres y nueve semanas, otros que entre dos y seis semanas. Bueno, esa fue mi conclusión, quince años de experiencia la soportan.
La última de estas tres leyes también se puede leer así:
Ø Todo proyecto que tarde más de un mes nunca termina
Y el que esté libre de culpa que lance la primera piedra.
Controlar los Cambios
Ya les dije antes que los requisitos de un sistema están sujetos a cambios “sin previo aviso”, sobre todo en proyectos a mediano y largo plazo. Pero primero lo primero, aclaración # 1: me refiero aquí a los cambios que sufren los requisitos luego de haber sido aprobados por los usuarios y de que posiblemente hayan sido implementados en alguna iteración, concluida o en ejecución, del proyecto.
Los desarrolladores noveles son muy dados a engancharse en una carrera contra el tiempo, contra los recursos, contra el contrato, contra el producto, cuando de llevar a cabo una modificación se trata. Y permítanme decirles, damas y caballeros, que antes de hacerlo es necesario estudiar en detalle el impacto que un cambio tendrá sobre todo nuestro sistema.
Un cambio en un requisito puede causar una dispersión de proporciones descomunales en un producto de software si no es definido claramente, evaluado y puesto a consideración de todo el equipo del proyecto. Por supuesto, el desarrollo iterativo y los componentes ayudan a mitigar los efectos ocasionados por los cambios en los requisitos y a que la implantación de estos se haga acorde a un plan establecido de manejo de cambios que no perturbe la ejecución del proyecto.
En el Final
Bueno, es realmente el final de una presentación efímera sobre estas prácticas. Como siempre, sostengo que los problemas más serios que he encontrado en los proyectos son de talento humano, en este caso, de comunicación entre quienes intervienen en un proyecto.
La conclusión es que cada una de estas prácticas debe tener una buena comunicación como prerrequisito. Sin una buena comunicación, todas fallarán al tratar de alcanzar su objetivo, todos fracasaremos sin duda, y seguramente recibiremos una dosis adictiva de apremio para caer en los métodos tradicionales de cascada donde la comunicación real es substituida por montones de documentos que no contribuyen mucho a producir valor para nuestros usuarios.
Ustedes qué creen? Compartan sus opiniones conmigo y con todos en AAII sobre este y otros temas. Pueden escribirme a lucho.salazar@gmail.com.
Referencias
http://www.rational.com/corpinfo/practices.jsp
http://www.aaii.org.co/html/modules.php?name=Content&pa=showpage&pid=11
http://www.aaii.org.co/html/modules.php?name=Content&pa=showpage&pid=24
http://www.aaii.org.co/html/modules.php?name=Sections&op=viewarticle&artid=11
http://www.aaii.org.co/html/modules.php?name=Sections&op=viewarticle&artid=18
El Proceso Unificado de Rational –RUP:
http://www.rational.com/products/rup/prodinfo.jsp
http://www.rational.com/tryit/rup/index.jsp
Luis Antonio Salazar Caraballo
Medellín, Septiembre 29 de 2003