Plantilla: Glosario del Sistema

Ya había comentado sobre la importancia de mantener un documento llamado Glosario, que sirva para capturar el vocabulario en uso en un proyecto. No solo para la muy vital misión de tener un vocabulario común con el cliente, sino también para otras tareas, como el análisis gramatical y la construcción de un Modelo de Dominio.

Similar en su estructura a un diccionario, el glosario contiene entradas con sus acepciones así como las relaciones de interés entre palabras; notablemente: los sinónimos y los homónimos.

Siendo como es, un documento muy sencillo, la plantilla que presentamos aquí tiene solo seis páginas. Donde cinco de ellas son heredadas de la estructura definida por la plantilla Documento del Proceso y solo una es propiamente el esquema para construir nuestro glosario.

Ahora bien, recordemos que todos los documentos del proceso tienen un anexo llamado Glosario, es preciso explicar que las definiciones con sus detalles solo las hacemos en este documento expresamente destinado a recoger el vocabulario del proyecto, en tanto que en aquellas secciones de los demás documentos podemos hacer un extracto de las definiciones aquí contenidas. Este extracto puede incluso, prescindir de las acepciones y en tal caso, nos llevaríamos solo las palabras que es preciso interpretar en forma especial; es decir, las palabras que hay que buscar en el Glosario.

Por otra parte, es posible hablar de un Glosario de Requisitos por oposición a un Glosario de Diseño o un glosario de cualquier otro aspecto del proyecto. Esto surge cuando hemos desarrollado documentos separados para cada aspecto, algo que tiene sentido en algunos proyectos grandes.

Glosario del Sistema(Plantilla)

Plantillas: Documento de Visión del Sistema

Uno de los primeros objetivos de todo proceso de desarrollo, no importa cuan formal o informal puede ser, es el de desarrollar una visión clara sobre el producto deseado, el proceso en si, y las necesidades que se van a cubrir con el proyecto. Esto es, una de las primeras tareas es la de Desarrollar una Visión del Sistema.

El producto básico de esta tarea es un documento bastante concreto y bien conocido por todos: El Documento de Visión del Sistema; cuya plantilla adjuntamos aquí.

La versión que presento es apropiada para proyectos de tamaño pequeño. Si bien tiene la típica estructura de un documento de visión (identificación de stakeholders, necesidades, macro características, características) no se queda ahí, sino que presenta suficientes secciones de requisitos adicionales como para poner en duda la utilidad de un documento separado de Requisitos Suplementarios.

Por lo mismo también, es apropiada para proyectos grandes: entre todas sus secciones se cubren todas las bases; permitiendo que no quede angulo del proyecto sin ser considerado. Por otra parte claro, para aquellas secciones donde el soporte no sea suficiente, siempre nos es posible desarrollar un documento más detallado más adelante en el proceso; por ejemplo, un Plan de Control de Calidad más detallado.

Recuerde desarrollar también un Glosario y naturalmente, alguna forma de capturar sus requisitos más en detalle. Si tiene dudas, siempre puede revisar mi selección de artefactos para la disciplina de requisitos.

Visión del Sistema (en PDF)

Visión del Sistema (en iScribd)

Definimos Pruebas de Ciclo de Negocio como…

La mayor parte de los sistemas de información modernos son concebidos como un apoyo para un proceso de negocio bien definido de la organización. Por lo mismo, en ocasiones es necesario reproducir un ciclo de negocio completo para poner a prueba la funcionalidad de un sistema. El reto surge cuando el ciclo de negocio a probar es extenso en el tiempo, digamos que debido a que ciertas fases de él solo se ejecutan en ciertas épocas del año. Un ejemplo de esto sería un sistema de administración o contabilidad, el cual solo emitirá planillas de pago de impuesto una vez al año.

En tales circunstancias, es necesario crear un procedimiento de prueba que abarque el ciclo de negocio completo, pues de otro modo no será posible cubrir el sistema entero.

Los procedimientos de pruebas de ciclo de negocio deben necesariamente venir acompañados de conjuntos de datos completos, preparados por expertos en el área relacionada, de manera de poder alimentar al sistema apropiadamente a lo largo del periodo simulado.

Veamos entonces la definición ya un poco más formal, de prueba de ciclo de negocio:

Prueba de Ciclo de Negocio Procedimiento de prueba que evalúa el sistema a lo largo de todo un ciclo completo de negocio, generalmente un año fiscal u otra unidad de tiempo similar. Se acompaña con todos los procedimientos necesarios para evaluar en poco tiempo lo que de normal ocurre a lo largo de un periodo de tiempo extenso.

Por otra parte, dado que como parte del procedimiento de pruebas se puede llegar al punto de alterar la fecha de los sistema de computo, es necesario que en la especificación del ambiente de prueba se hayan señalado recursos para la restauración de estos, ya que en su mayoría, las computadoras no aceptar bien el tener una fecha en el futuro hoy y mañana tenerla en el pasado. Los licenciamientos y el seguimiento de fechas de diversos sistemas no directamente relacionados con el sistema que probamos pueden presentar problemas y hacer más difícil de interpretar los resultados de las pruebas.

Selección de Artefactos de Requisitos

Dado que son muchos los posibles artefactos a incluir en un proyecto, es imperativo el desarrollar una visión de conjunto que nos permita escoger solo aquellos que son realmente capaces de otorgar valor al desarrollo. Esto es, necesitamos tener una visión o mapa estructural de todos los artefactos, para luego saber cual incluir en el desarrollo y cual dejar por fuera.

En este artículo analizaremos los artefactos de la disciplina de requisitos.

Primero tenemos los documentos básicos: El Documento de Visión del Sistema y El Glosario de Requisitos. Estos documentos son tan importantes que simplemente los tendremos siempre en nuestros desarrollos. En ellos tendremos el vocabulario del cliente así como la captura de las necesidades y las características de alto nivel de la solución propuesta. Ambos forman una suerte de paraguas que cobija a los restantes artefactos del proceso, tanto si son de requisitos como si son de otras disciplinas.

Para el resto de los artefactos de requisitos tenemos tres enfoques: el tradicional, los casos de uso y el dual o mixto.

El enfoque tradicional esta representado por el documento de Especificación de Requisitos del Sistema, que contiene los requisitos en un formato estilo “el sistema debe…”. En este enfoque, no dividimos los requisitos en funcionales y no funcionales, por lo que nos basta con un solo documento.

Por otra parte, en el enfoque de casos de uso, es necesario contar con algún tipo de documento para capturar los requisitos no funcionales, ya que los casos de uso como es sabido por todos, solo nos ayudan con los requisitos funcionales. El rol del documento de Requisitos Suplementarios es justamente este: complementar los casos de uso y documentar cualquier requisito no funcional al lado de cualquier requisito funcional que sea general a todo el sistema.

El ultimo enfoque es el dual. Es simplemente mantener tanto un documento tradicional de requisitos como un modelo de casos de uso. En este enfoque surge un nuevo artefacto: El Cruce de Requisitos; con cuya ayuda mantendremos el control de la duplicidad de cada requisito: una vez en el documento de especificación y otra en el modelo de casos de uso.

El siguiente diagrama muestra las relaciones entre estos artefactos, organizados en lo que llamamos un Artifacflow o Flujo de Artefactos. En este diagrama vemos la forma en que la información viaja desde la visión hacía los restantes documentos. Los rombos representan las decisiones que tomamos durante la creación del Caso de Desarrollo y el criterio de decisión.

Fig. 1 – Flujo de Artefactos de la Disciplina de Requisitos

Las decisiones son simples de plantear, aunque no necesariamente fáciles de contestar. ¿Debemos utilizar casos de uso o un enfoque tradicional? ¿Quizás debamos optar por el enfoque mixto? Finalmente, de utilizar casos de uso ¿vale la pena mantener un documento de requisitos suplementarios? ¿No es todo esto simplemente mucho trabajo?

La verdad es que si es un proyecto pequeño, tomar todos los artefactos es demasiado. De hecho, en un proyecto pequeño lo mejor es aprovecharse de un detalle interesante: en ciertas condiciones los artefactos se pueden combinar.

Un ejemplo de esto es el Documento de Visión. Dado que este incluye secciones suficientes para documentar requisitos no funcionales y considerando también que podemos hacer un anexo que cubra el glosario, es simple obtener un conjunto de artefactos combinados que resulten apropiados para un proyecto pequeño.

La situación es planteada en el siguiente diagrama:

Fig. 2 – Flujo de Artefactos de la Disciplina de Requisitos
para un Proyecto Pequeño

En el caso planteado, es de esperar que los costos de construir y mantener estos artefactos sean mucho menores que en el caso de tener documentos separados. Así que han de resultar mucho más adecuados para un proyecto de pequeñas dimensiones.

El Ciclo de Vida: Objetivos de Fase

Cada Fase del Ciclo de Vida debe terminar cuando se alcanzan un conjunto bien identificado de objetivos, definidos en términos de productos concretos o eventos acordados con los stakeholders. Según lo que se haya indicado en la planificación del proyecto durante la Fase de Concepción.

Esto es, llamamos Objetivos del Ciclo de Vida a las metas concretas que marcan el éxito de una fase, según lo que se haya planificado inicialmente.

Según la fase del proyecto en la que nos encontremos, los objetivos van a ser diferentes. Algunos ejemplos son:

• Objetivos del Ciclo de Vida de la Fase de Concepción: Documento Visión, Modelo de Casos de Uso, Documento de Requisitos Suplementarios.
• Objetivos del Ciclo de Vida de la Fase de Elaboración: Documento de Arquitectura del Sistema, Prototipo de Interfaz de Usuario, Prototipo Técnico de la Arquitectura del Software.
• Objetivos del Ciclo de Vida de la Fase de Construcción: Versión Beta del Software en ejecución en ambiente de pruebas, Documentación de Usuario, Soporte de Entrenamiento de Usuarios, etc.

Un objetivo del ciclo debe ser concreto, verificable, planificado de antemano, bien conocido y aceptado por todos los stakeholders del proyecto. Veremos cada criterio uno a uno:

Concreto: Cada objetivo del ciclo de vida debe estar bien enunciado. No se aceptar definiciones vagas o que no se comprendan plenamente por todos los stakeholders involucrados. Se tienen por concreto a los artefactos del proceso cuando estos son aprobados por el cliente y este entiende el significado y rol técnico del producto que esta aprobando.

Verificable: Tanto el cliente como el equipo de Control de Calidad del Software van a estar interesados en comprobar que el objetivo se ha alcanzado. Esto es, la ocurrencia del evento debe poder ser observada por terceros de forma así de garantizar que el éxito en alcanzar el objetivo del ciclo de vida no es resultado de una evaluación subjetiva más sujeta al capricho o la premura que a la realidad.

Planificado: El objetivo de ciclo de vida es una meta; por lo que no puede ser alcanzado solo por casualidad. El objetivo ha de haber sido señalado como meta desde un principio y no puede en ningún caso, ser presentado como aquello que se ha salvado de un proceso malogrado de desarrollo. La planificación también es importante para permitir con el suficiente tiempo, la elaboración de estrategias de evaluación que permitan la verificación del objetivo.

Bien Conocido: El objetivo del ciclo de vida debe ser un artefacto o evento reconocido en el sector de desarrollo, de forma tal que exista un acuerdo profesional sobre lo que este significa y de los eventuales criterios de aceptación y demás características del objetivo. Por ejemplo, el Documento de Visión es bien conocido ya que esta difundido en la profesión el contenido esperado de este documento así como en el propósito que persigue.

Aceptado: Todos, tanto los clientes como los desarrolladores, deben haber aceptado el objetivo del ciclo de vida y sentir compromiso por conseguirlo. El objetivo de ciclo de vida debe ser aceptado como un elemento que señala un avance significativo del proyecto que aporte valor real al desarrollo y que debe ser apoyado y buscado con energías. Esto debe ser algo sincero, ya que un objetivo del ciclo de vida no puede ser percibido como un alcabala o requisito burocrático: muy por el contrario, debe ser un artefacto o evento de valor para todos los involucrados.

Definimos Caso de Uso como…

Hoy en día los casos de uso son la principal forma de capturar los requisitos de los proyectos de desarrollo de software; y de ahí por tanto que sean el lugar de inicio más común para los libros que explican métodos de desarrollo. Sin embargo son también quizás, el concepto peor entendido de todos, probablemente por su sencillez y por estar enfocado a su tarea de modelar requisitos pero dejar poco lugar para nada más.

Formalmente, para el glosario:

Caso de Uso Escenario que narra la interacción entre un sistema y una entidad externa a la que se le provee una funcionalidad. Los casos de uso son principalmente cuerpos de texto de definición de requisitos funcionales aunque por medio de extensiones pueden ser utilizados por fuera de este ámbito.

El lenguaje UML incluye en su especificación el soporte para los casos de uso, permitiendo representar por medios visuales diversas características de estos; complementando así lo indicado en las especificaciones en formato texto de cada caso de uso.

Considerando que los sistemas de información modernos son altamente interactivos, tanto por su relación con múltiples operadores humanos como por su necesidad de integrarse e interactuar con otros sistemas, es necesario entonces que los requisitos sean capturados respetando esta naturaleza interactiva. Es decir, si bien antes nos bastaba preguntar qué debe hacer el sistema ahora es necesario agregar para cada uno de sus usuarios.

Por sencillez, llamaremos actor a cada operador externo, tanto si es un sistema aparte del nuestro como si se trata de un operador humano.

Con el enfoque de los casos de uso, el sistema luce diferente para cada uno de sus actores. A unos, la funcionalidad que ofrece serán la que se corresponde con su trabajo, en tanto que a otros, será la que corresponda con la necesidad de estos. Esta organización de la funcionalidad según el punto de vista de cada actor es clave para poder capturar rápida y efectivamente, los requisitos funcionales de un sistema altamente interactivo.

En su conjunto, los casos de uso constituyen el llamado Modelo de Requisitos Funcionales el cual puede ser complementado con documentos que detallen Requisitos No Funcionales en una forma más tradicional. Es responsabilidad del Analista de Requisitos el construir y el mantener estos artefactos.

El Modelado de Casos de Uso es hoy por hoy, la principal técnica de captura de requisitos funcionales, y es una pieza central en los procesos de desarrollo de pruebas, de la interfaz hombre-maquina, de la documentación de usuario y manuales así como de guiar el análisis y diseño de la solución técnica del desarrollo. Es decir, que el proceso de desarrollo se encuentra centrado en casos de uso.

Si bien los casos de uso pueden ser manejados en forma gráfica, con ayuda de los diagramas de caso de uso del lenguaje UML, la información total que estos contienen va mucho más allá. Entre las propiedades de los casos de uso se encuentran los flujos de eventos, las pre condiciones, los puntos de extensión y muchos más elementos, solo posibles de ser representados con ayuda de un documento de texto. En este blog, podrá encontrar un ejemplo completo.

Prácticas: Seguimiento y Control de Proyectos

El propósito del Seguimiento y Control de Proyectos es el de proveer una visión objetiva del estado actual del proyecto y determinar las posibles desviaciones a fin de tomar las correcciones del caso. Es en este sentido en el cual le llamamos Seguimiento a la evaluación rutinaria del estado en tanto que llamamos Control a la toma de los correctivos.

Esta práctica guarda intima relación con la Planificación de Proyectos tal como cabe esperar, ya que solo donde la planificación se encuentra correctamente documenta es posible verificar su cumplimiento.

El producto mínimo de esta práctica es el Cierre de Iteración, un documento o artefacto, donde anotamos los resultados de la evaluación de una iteración; de momento sin decir las correcciones a tomar.

Una vez determinada las desviaciones, es necesario que el equipo determine oportunamente la corrección requerida y la lleve a cabo durante la siguiente iteración o en el momento en que sea oportuno. Finalmente es necesario que la corrección planteada sea a su vez, objeto de seguimiento – lo que implica que la planificación debe ser actualizada para que refleje las acciones que se han determinado necesarias para corregir la desviación.

A la hora de realizar las reuniones de seguimiento del proyecto, es útil contar con unos momentos para discutir y revisar el Plan de Riesgos, a fin de verificar la ocurrencia de alguno de estos eventos negativos; además – si bien es una práctica avanzada – debe considerarse la posibilidad de calcular alguna forma de medida o métrica que aplicada al proyecto de desarrollo sirva de indicador sobre el estado del mismo. Esto con el objeto de obtener una evaluación lo más completa y objetiva posible de la salud del proyecto.

Otros factores que deben ser objeto de seguimiento incluyen el presupuesto en tiempo y dinero del proyecto y el cumplimiento de los hitos señalados como objetivos del ciclo de vida.

Control de Calidad: Trazas

La moderna practica de la ingeniería del software se basa en la construcción de modelos que capturen progresivamente, el avance desde los requisitos al diseño y eventualmente, a la implementación y despliegue de la solución final. Esto representa un reto importante desde el punto de vista de la calidad ya que ha de existir alguna manera de seguir la pista de como se ha elaborado lo requerido a través de los múltiples modelos, hasta esa deseada implementación ejecutable.

La solución a este reto son las llamadas Trazas. A lo largo de los modelos, mantendremos notas y relaciones de realización de los casos de uso; de manera de seguir la pista de como se han dado solución a lo planteado como requisito. Es de observarse que las trazas son quizás, la única forma sistemática de comprobar que el proceso de desarrollo no ha tomado un camino propio y terminado por desarrollar algo diferente a lo solicitado.

Entonces, para el glosario:

Trazas. Indicaciones sobre la realización de los artefactos de un proyecto; indican la forma en que los artefactos se han elaborado respetando la información contenida en otros artefactos, generalmente de requisitos o previos en el proceso de desarrollo.

Las trazas son pues, un artificio de control que sigue la elaboración de modelos y artefactos a partir de lo indicado en algún otro documento. Es responsabilidad de todos en el proyecto de asegurar el fiel y cabal cumplimiento de lo requerido, por lo que también es necesario que todos se involucren en mantener las trazas entre los artefactos.

En lo que a los modelos se refiere, las trazas pueden adoptar la forma de un diagrama de paquetes, que muestre las trazas como dependencias estereotipadas de UML entre los modelos, aquí representados a su vez, como paquetes estereotipados. El siguiente diagrama ilustra el punto:

Fig. 1 – Ejemplo de Trazas entre Modelos UML

Por otra parte, en cuanto a los documentos, la forma más simple es la de mantener un anexo o apartado en cada documento, donde se indique cual documento con su número de versión y fecha, a sido tomado como insumo y a su vez, cuales son los documentos derivados que están en uso en el proyecto. La siguiente tabla muestra un ejemplo de esto:

Título del documento: Documento de Visión – v2.0 al 15 de mayo de 2008.
Responsable del documento: Iván Garcerant.
Documentos de insumo: Términos de Referencia – v1.0 al 20 de enero de 2008.
Documentos derivados: Modelo de Casos de Uso y Especificación de Requisitos Suplementarios.

Tabla 1 – Ejemplo de Trazas de Documento

Lo ultimo que vale la pena comentar, es que las trazas son auditadas por el equipo de Control de Calidad[*] (Software Quality Control – SQC) quienes se guían por estas para comprobar el buen estado del proyecto, en tanto que el sistema de trazas es diseñado por el equipo de Aseguramiento de Calidad[*] (Software Quality Assurence – SQA) como parte del diseño del proceso de desarrollo.

Entonces una vez más como conclusión: Las trazas son dependencias entre los artefactos, que indican la forma en que la información fluye por ellos, desde los requisitos hasta el diseño y la implementación; en UML podemos indicar trazas por medio de dependencias estereotipadas en tanto que en los documentos podemos hacer un aparte o anexo con esta información.

Es todo por hoy.

El Ciclo de Vida: Fase de Elaboración

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

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

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

Típicos objetivos para esta fase son:

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

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

Entonces, ahora como para el glosario:

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

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

Casos de Uso Avanzados: Relación de Inclusión

El modelado de casos de uso persigue capturar la funcionalidad del sistema visto desde el punto de vista de sus operadores -actores- por lo que es fundamentalmente una construcción de elementos de modelado comprensibles por los clientes -stakeholders- y no solo por los analistas.

Sin embargo, en ocasiones es conveniente introducir algunos pocos elementos que no sean directamente los conceptos que manejan los clientes. Por ejemplo, en aras de evitar la redundancia, es posible pensar en extraer algunos fragmentos que nos permita indicar en uno o más casos de uso este fragmento repetido, por referencia en lugar de repetirlo en cada caso.

A este proceso de extracción del fragmento repetido lo modelamos por medio de la relación de inclusión <<include>>, tal como se ve en el siguiente diagrama:

Fig. 1 - Relación de inclusión entre casos de uso

En la figura, el caso de uso “A” es un fragmento, que define un trozo de un flujo de eventos que es referido por el caso de uso “B”. En este tipo de relación, el caso incluido (el “A”) debe ser un fragmento, nunca un caso concreto, en tanto que el caso que incluye (el “B” del ejemplo) si ha de ser un caso de uso completo.

A diferencia de la relación de extensión, aquí ninguno de los casos de uso involucrados puede ser entendidos por completo como piezas aisladas. Por un lado, el caso incluido es solo un fragmento, por lo que no es posible considerarlo un caso de uso pleno; en tanto que el caso que incluye al hacer referencia a un fragmento externo tiene necesariamente que ser entendido en presencia del fragmento.

Formalmente, como para el glosario:

Relación de Inclusión <<include>> Un caso de uso concreto incluye a un fragmento de caso de uso, cuando como parte de su descripción breve o su flujo de eventos, se hace referencia al texto del fragmento; de forma tal que lo dicho en el fragmento pasa a ser parte de la especificación del caso de uso.

Para lograr que se entienda el concepto, nada mejor que un ejemplo. Supongamos que estamos hablando de un sistema de gestión de agenda de un empresas con gerentes y asistentes. En este sistema hemos identificado dos casos de uso:

Código: UC-0100.
Nombre: Acepta cita.
Actor: Gerente.
Descripción: El Gerente visualiza su calendario de citas y aprueba aquellas citas que desee aceptar.

Código: UC-0200.
Nombre: Coordina cita.
Actor: Asistente.
Descripción: El asistente busca un momento apropiado para las citas pendientes al visualizar el calendario de citas del Gerente. Indica para cada cita propuesta la descripción, el día y la hora.

Tabla 1 - Casos de uso del sistema

Como se nota, en ambos casos se requiere de visualizar la agenda. Es posible imaginar que esta función abarca no solo la visualización del calendario, sino también ciertas funciones de búsqueda y filtrado por criterios. Para especificar esta funcionalidad pero evitar hacerlo en cada uno de los flujos de eventos de los casos de uso ya definidos, se opta por crear un fragmento que contenta esos detalles e incluirlo en los casos de uso originales. La situación da lugar al siguiente diagrama:

Fig. 2 - Modelo de casos de uso con un
ejemplo de relación de inclusión

De esta forma, evitamos tener que definir en múltiples lugares una misma funcionalidad. Sin embargo, el fragmento que se incluye ha de ser visto siempre como lo que es: un fragmento sin significado completo. En verdad es una lastima que de momento no tengamos una forma de marcar a los fragmentos de manera que se diferencien a simple vista de los casos de uso. Sugiero que al menos, en tanto surge un estereotipo estándar para esta tarea, tengamos una serie de numeración particular para los fragmentos. O bien, tomar la iniciativa y definir un estereotipo de UML por nosotros mismos.

Naturalmente que a la hora de hacer la especificación detallada de los casos de uso, en particular en los flujos de eventos, debemos marcar muy claramente en que lugar se ha de realizar la inclusión de lo dicho en el fragmento.

La relación de inclusión es claramente diferente a la relación de extensión y espero que haya quedado claro. La inclusión es una relación entre un caso de uso concreto y un fragmento, en tanto que la extensión involucra casos de uso concretos.

Por otra parte, a diferencia de la relación de extensión, la inclusión en cierta forma modifica al caso que incluye, por cuanto el fragmento define una parte de la funcionalidad del caso de uso completo. Esto significa que el caso de uso que incluye no puede ser entendido por completo en ausencia del fragmento que se incluye; algo muy diferente a la situación en una relación de extensión.