IS – 286 MODELADO Y ANALISIS DE SOFTWARE

Buenas prácticas en el Modelado y Análisis de

Software

1. Introducción
El modelado y análisis de software es una actividad crucial en el desarrollo de sistemas
complejos. Permite a los ingenieros de software capturar, representar y comunicar los
requisitos del sistema, su arquitectura y su comportamiento. Las buenas prácticas en esta
área son esenciales para asegurar la calidad, la claridad y la eficiencia en el desarrollo del
software.

Las buenas prácticas en el modelado y análisis de software son estrategias y enfoques

recomendados para asegurar que los modelos sean útiles, precisos y efectivos en la
representación y comprensión de los sistemas de software.

a. Claridad y Simplicidad
Evitar Complejidad Innecesaria La simplicidad en los modelos es vital para asegurar
que todos los stakeholders puedan entender y trabajar con ellos de manera efectiva.
Los modelos excesivamente complejos pueden ser difíciles de comprender y
mantener. Una práctica común es centrarse en los elementos esenciales y evitar
detalles irrelevantes que no aportan valor inmediato al análisis o diseño del sistema.

 Ejemplo Práctico: En un diagrama de clases UML, incluir solo las clases principales y sus
relaciones más importantes en lugar de detallar todos los atributos y métodos
secundarios.

Referencia Bibliográfica: Sommerville, I. (2016). Ingeniería de software (10ª ed.).

Pearson Educación. (pp. 160-162)

Uso de Nombres Claros y Descriptivos Los nombres asignados a los elementos del
modelo deben ser autoexplicativos y reflejar claramente su propósito y funcionalidad
dentro del sistema. Esto no solo facilita la comprensión del modelo, sino que también
ayuda a evitar ambigüedades.

 Ejemplo Práctico: Nombrar una clase “ Usuario “ en lugar de “Cls1” para reflejar
claramente su papel en el sistema.

b. Consistencia
Consistencia Interna Los modelos deben ser internamente consistentes, lo que
significa que no deben contener contradicciones. Cada elemento dentro de un modelo
debe relacionarse de manera coherente con los demás elementos.

 Ejemplo Práctico: Si un atributo de una clase está definido como un entero, todas las
referencias a este atributo deben tratarlo como un entero en lugar de otro tipo de dato.

Referencia Bibliográfica: Booch, G., Rumbaugh, J., & Jacobson, I. (2005). The Unified
Modeling Language User Guide (2ª ed.). Addison-Wesley. (pp. 80-82)

1
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

Consistencia Entre Modelos Es esencial que los diferentes modelos que representan
el mismo sistema sean coherentes entre sí. Esto asegura que la información y los
comportamientos representados en un modelo se reflejen de manera precisa en
otros modelos relacionados.

 Ejemplo Práctico: Si un diagrama de casos de uso muestra una interacción específica

entre un usuario y el sistema, esta interacción debe reflejarse en los diagramas de
secuencia y de clases correspondientes.

Referencia Bibliográfica: Rumbaugh, J., Jacobson, I., & Booch, G. (2004). The Unified
Modeling Language Reference Manual (2ª ed.). Addison-Wesley. (pp. 120-122)

c. Modularidad
División en Módulos Dividir el sistema en módulos o componentes más pequeños
facilita la gestión y el mantenimiento. Cada módulo debe representar una
funcionalidad específica y ser lo suficientemente independiente como para ser
desarrollado y probado de manera aislada.

 Ejemplo Práctico: Separar el sistema en módulos como "Gestión de Usuarios",

"Procesamiento de Pedidos" y "Control de Inventario".

Referencia Bibliográfica: Pressman, R. S. (2015). Ingeniería de software: Un enfoque

práctico (7ª ed.). McGraw-Hill. (pp. 210-212)

Encapsulamiento El encapsulamiento es una práctica que implica ocultar los detalles

internos de un módulo y exponer solo las interfaces necesarias. Esto promueve la
reutilización y la mantenibilidad del código.

 Ejemplo Práctico: Un módulo de autenticación podría exponer métodos como login y

logout, mientras que oculta los detalles de cómo se manejan las credenciales
internamente.

Referencia Bibliográfica: Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design
Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. (pp. 35-36)

d. Iteración y Revisión Continua

Iteración El proceso de modelado debe ser iterativo. Esto significa que los modelos
deben revisarse y refinarse continuamente a medida que se obtiene una mejor
comprensión del sistema y sus requisitos.

 Ejemplo Práctico: Comenzar con un diagrama de clases básico y añadir detalles en ciclos,
revisando y mejorando el modelo con cada iteración.

Referencia Bibliográfica: Beck, K. (2000). Extreme Programming Explained: Embrace

Change. Addison-Wesley. (pp. 45-46)

2
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

Revisión y Validación Los modelos deben revisarse y validarse regularmente con los
stakeholders para asegurar que cumplen con los requisitos y expectativas. Las
revisiones periódicas ayudan a detectar errores tempranos y a ajustar los modelos
según sea necesario.

 Ejemplo Práctico: Realizar revisiones de modelos con clientes y desarrolladores al final de

cada iteración para validar su precisión y relevancia.

Referencia Bibliográfica: Larman, C. (2004). Applying UML and Patterns: An Introduction

to Object-Oriented Analysis and Design and Iterative Development (3ª ed.). Prentice Hall.
(pp. 60-62)

e. Documentación y Anotación

Documentación Completa Los modelos deben ir acompañados de una documentación

detallada que explique los elementos del modelo, sus relaciones y cualquier
suposición subyacente. Esto es crucial para la comprensión y el mantenimiento a largo
plazo.

 Ejemplo Práctico: Proporcionar una descripción detallada de cada caso de uso,

incluyendo su propósito, flujo de eventos y excepciones.

Referencia Bibliográfica: Cockburn, A. (2001). Writing Effective Use Cases. Addison-

Wesley. (pp. 75-77)

Anotaciones Utilizar comentarios y anotaciones en los modelos para proporcionar

contexto adicional y aclaraciones. Las anotaciones pueden explicar decisiones de
diseño, condiciones específicas o cualquier otro detalle relevante.

 Ejemplo Práctico: Añadir notas en un diagrama de secuencia para explicar las condiciones
bajo las cuales se ejecuta una interacción particular.

Referencia Bibliográfica: Booch, G., Maksimchuk, R. A., Engel, M. W., Young, B. J.,
Conallen, J., & Houston, K. A. (2007). Object-Oriented Analysis and Design with
Applications (3ª ed.). Addison-Wesley. (pp. 132-134)

f. Uso de Estándares y Herramientas Adecuadas

Estándares Utilizar lenguajes de modelado estandarizados como UML para asegurar la

consistencia y facilitar la comunicación entre los equipos de desarrollo. Los estándares
proporcionan un conjunto común de notaciones y convenciones que todos los
miembros del equipo pueden entender y seguir.

 Ejemplo Práctico: Utilizar UML para crear diagramas de clases, secuencia y casos de uso,
en lugar de inventar notaciones propias.

Referencia Bibliográfica: Rumbaugh, J., Jacobson, I., & Booch, G. (2004). The Unified
Modeling Language Reference Manual (2ª ed.). Addison-Wesley. (pp. 30-32)

3
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

Herramientas de Modelado Utilizar herramientas de software especializadas que

soporten los estándares de modelado y proporcionen funcionalidades avanzadas,
como validación automática y generación de código. Estas herramientas pueden
mejorar la productividad y la precisión del modelado.

 Ejemplo Práctico: Herramientas como Enterprise Architect, Visual Paradigm, o las

funcionalidades de modelado UML en IDEs como IntelliJ IDEA y Eclipse.

Referencia Bibliográfica: Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard
Object Modeling Language (3ª ed.). Addison-Wesley. (pp. 10-12)

g. Participación de las Partes Interesadas

Colaboración Activa Involucrar a todas las partes interesadas en el proceso de

modelado es crucial para asegurar que los modelos reflejen correctamente los
requisitos y expectativas del negocio. La colaboración activa permite recoger feedback
valioso y ajustar los modelos según sea necesario.

 Ejemplo Práctico: Realizar talleres de modelado con clientes, usuarios finales,

desarrolladores y analistas para recoger feedback y asegurar que los modelos son
precisos y útiles.

Referencia Bibliográfica: Pressman, R. S. (2015). Ingeniería de software: Un enfoque

práctico (7ª ed.). McGraw-Hill. (pp. 280-282)

Feedback Regular Recoger y actuar sobre el feedback de los stakeholders de manera

continua ayuda a mejorar la precisión y relevancia de los modelos. El feedback regular
asegura que los modelos se mantengan alineados con los requisitos del negocio.

 Ejemplo Práctico: Después de cada iteración de modelado, revisar los modelos con las
partes interesadas y ajustar según sea necesario.

Referencia Bibliográfica: Beck, K. (2000). Extreme Programming Explained: Embrace

Change. Addison-Wesley. (pp. 50-52)

h. Precisión y Detalle Apropiado

Nivel de Abstracción Adecuado Es importante elegir el nivel de detalle y abstracción

adecuado para el propósito del modelado. Los modelos de alto nivel deben capturar
conceptos generales, mientras que los modelos detallados deben especificar los
aspectos precisos de la implementación.

 Ejemplo Práctico: En las primeras etapas del proyecto, utilizar diagramas de casos de uso
para captar requisitos generales. A medida que avanza el proyecto, crear diagramas de
clases detallados para especificar la implementación.

4
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

Referencia Bibliográfica: Larman, C. (2004). Applying UML and Patterns: An Introduction

to Object-Oriented Analysis and Design and Iterative Development (3ª ed.). Prentice Hall.
(pp. 70-72)

Evitar Redundancias Evitar duplicar información en diferentes modelos o dentro del

mismo modelo a menos que sea absolutamente necesario. La redundancia puede
llevar a inconsistencias y dificultar el mantenimiento del modelo.

 Ejemplo Práctico: Si una relación ya está representada en un diagrama de clases, no es

necesario volver a representarla en otro diagrama a menos que sea necesario para
clarificar un aspecto diferente.

Referencia Bibliográfica: Booch, G., Maksimchuk, R. A., Engel, M. W., Young, B. J.,
Conallen, J., & Houston, K. A. (2007). Object-Oriented Analysis and Design with
Applications (3ª ed.). Addison-Wesley. (pp. 142-144)

i. Trazabilidad

Rastreabilidad de Requisitos Mantener una trazabilidad clara entre los requisitos y los
elementos del modelo facilita la verificación de que todos los requisitos se han
cumplido. La trazabilidad asegura que cada requisito está representado y que
cualquier cambio en los requisitos se refleja en los modelos correspondientes.

 Ejemplo Práctico: Utilizar herramientas de gestión de requisitos que enlacen

directamente los requisitos a los casos de uso y otros artefactos de modelado.

Referencia Bibliográfica: Pressman, R. S. (2015). Ingeniería de software: Un enfoque

práctico (7ª ed.). McGraw-Hill. (pp. 290-292)

Control de Versiones Utilizar sistemas de control de versiones para gestionar los

cambios en los modelos es esencial para mantener un historial de modificaciones y
poder revertir a versiones anteriores si es necesario. El control de versiones también
facilita la colaboración entre diferentes miembros del equipo.

 Ejemplo Práctico: Almacenar los modelos en un repositorio de control de versiones como

Git, para poder rastrear cambios y revertir a versiones anteriores si es necesario.

Referencia Bibliográfica: Beck, K. (2000). Extreme Programming Explained: Embrace

Change. Addison-Wesley. (pp. 60-62)

j. Adaptabilidad y Mantenimiento

Facilidad de Cambio Diseñar modelos que sean fáciles de adaptar y modificar es crucial
para manejar cambios en los requisitos o el entorno del sistema. Los modelos deben
ser flexibles y permitir ajustes sin grandes esfuerzos de reestructuración.

 Ejemplo Práctico: Utilizar patrones de diseño que faciliten la extensibilidad, como el

patrón de diseño de fábrica o el patrón de adaptador.

5
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

Referencia Bibliográfica: Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design
Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. (pp. 150-152)

Mantenimiento Continuo Mantener los modelos actualizados y reflejar los cambios

realizados durante el ciclo de vida del desarrollo del software es fundamental para
asegurar que los modelos sigan siendo relevantes y útiles.

 Ejemplo Práctico: Después de cada sprint en un entorno ágil, actualizar los modelos para
reflejar cualquier cambio en los requisitos o en la implementación del sistema.

Referencia Bibliográfica: Beck, K. (2000). Extreme Programming Explained: Embrace

Change. Addison-Wesley. (pp. 65-67)

2. Integridad, Consistencia y Robustez en el Modelado y Análisis de

Software
En el contexto del modelado y análisis de software, la integridad, consistencia y robustez juegan
roles cruciales para asegurar que los sistemas desarrollados sean confiables, precisos y capaces
de manejar situaciones diversas y complejas.

a. Integridad del Modelo

La integridad del modelo se refiere a la exactitud y coherencia de la información

representada en los modelos de software. Un modelo se considera íntegro cuando todos
los elementos, relaciones y restricciones definidas en él reflejan correctamente los
requisitos y características del sistema real. Esto implica que no haya inconsistencias
internas ni información contradictoria que pueda llevar a interpretaciones erróneas o
decisiones incorrectas durante el desarrollo del software.

Para asegurar la integridad del modelo, es crucial seguir prácticas como la validación
continua, donde se verifica que todos los componentes del modelo cumplan con las
reglas y restricciones definidas. Además, la trazabilidad de requisitos juega un papel
importante al vincular directamente los elementos del modelo con los requisitos
específicos del sistema, garantizando así que cada aspecto del modelo esté alineado con
las necesidades del cliente y las expectativas del usuario final (Referencia: Pressman, R.
S. (2015). Ingeniería del Software: Un enfoque práctico (7ª ed.). McGraw-Hill).

Alcanzar la integridad del modelo exige:

 Definición clara del alcance del modelo: Es indispensable establecer desde el inicio
los límites del modelo, especificando qué aspectos del sistema se incluirán y
cuáles no.
 Identificación exhaustiva de elementos: Un modelo íntegro debe contemplar
todos los componentes del sistema, incluyendo entidades, atributos, relaciones,
comportamientos y restricciones.
 Recopilación meticulosa de información: Se requiere recopilar toda la información
pertinente sobre el sistema, tanto de fuentes documentadas como de expertos
en el dominio.

6
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

b. Consistencia entre Modelos

La consistencia entre modelos se refiere a la armonización y coordinación de diferentes

representaciones de un sistema dentro de un entorno de desarrollo de software. Esto
implica que los modelos de diferentes aspectos del sistema, como los diagramas de clase,
los diagramas de secuencia y los diagramas de casos de uso, deben estar alineados y no
deben contradecirse entre sí.

Para lograr la consistencia entre modelos, se recomienda el uso de estándares de

modelado como UML (Unified Modeling Language), que define una notación común y
reglas claras para la creación de diversos tipos de modelos. Además, el uso de
herramientas de modelado que soporten la validación automática y la generación de
informes puede ayudar a identificar y resolver inconsistencias antes de la
implementación del software, asegurando así una representación coherente y precisa del
sistema (Referencia: Fowler, M., & Scott, K. (1999). UML Distilled: A Brief Guide to the
Standard Object Modeling Language. Addison-Wesley).

Para lograr la consistencia del modelo, se recomienda:

 Emplear una notación clara y concisa: La notación utilizada para representar los
elementos del modelo debe ser comprensible y no generar confusiones.
 Definir términos y conceptos de manera precisa: Es fundamental establecer
definiciones precisas y consistentes para todos los términos y conceptos
utilizados en el modelo.
 Realizar una verificación rigurosa: Se debe realizar una revisión exhaustiva del
modelo para detectar y corregir errores, ambigüedades o inconsistencias.

c. Robustez del Sistema

La robustez del sistema se refiere a su capacidad para funcionar correctamente bajo

diversas condiciones y situaciones adversas. En el contexto del modelado y análisis de
software, esto implica diseñar sistemas que no solo sean funcionales bajo condiciones
normales de operación, sino que también sean capaces de manejar excepciones, errores
y cargas inesperadas de manera efectiva y sin comprometer la integridad de los datos o
la seguridad del sistema.

Para mejorar la robustez del sistema, los modelos deben incluir escenarios de excepción
y casos límite que puedan surgir durante la ejecución del software. Esto se puede lograr
mediante la especificación detallada de casos de uso alternativos y extensiones en los
diagramas de casos de uso, así como mediante la modelización de estados y transiciones
robustas en los diagramas de estados y actividades. Además, la aplicación de principios
de diseño robusto, como la modularidad y el encapsulamiento, puede fortalecer la
capacidad del sistema para adaptarse y responder eficazmente a cambios y desafíos
inesperados (Referencia: Sommerville, I. (2011). Ingeniería de Software (9ª ed.). Pearson
Educación).

7
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

La integridad, consistencia y robustez son pilares fundamentales en el modelado y análisis

de software, asegurando que los sistemas desarrollados sean confiables, precisos y
capaces de operar eficazmente en diversas condiciones. Al adherirse a prácticas sólidas
de modelado, utilizando herramientas adecuadas y siguiendo estándares reconocidos,
los profesionales de ingeniería de software pueden garantizar que los modelos no solo
reflejen con precisión los requisitos del sistema, sino que también proporcionen una base
sólida para la implementación y el mantenimiento del software.

Para alcanzar la robustez del modelo, es importante:

 Diseñar un modelo modular: La estructura del modelo debe estar organizada en

módulos independientes y bien definidos, facilitando su modificación y extensión.
 Documentar el modelo de manera clara: Una documentación completa y detallada
del modelo es crucial para comprender su funcionamiento y realizar cambios
futuros.
 Validar el modelo con datos reales: Se debe validar el modelo utilizando datos
reales del sistema para garantizar que representa adecuadamente su
comportamiento.

Ejemplo
Contexto

Consideremos un sistema de gestión de proyectos de software. Este sistema permite a

los usuarios gestionar tareas, asignar recursos y monitorear el progreso de los proyectos.
Nos centraremos en asegurar la integridad del modelo de datos, específicamente a través
del diagrama de clases.

Descripción del Modelo

Las principales entidades en nuestro sistema de gestión de proyectos de software son:

 Proyecto: Representa cada proyecto en el sistema.

 Tarea: Representa las tareas asociadas a cada proyecto.
 Usuario: Representa a los usuarios que gestionan y realizan tareas.
 Asignación: Representa la asignación de tareas a usuarios.

8
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

Asegurando la Integridad del Modelo

Revisión y Validación Regular

1. Revisión de Atributos y Relaciones:

o Proyecto: Verificamos que todos los atributos (id, nombre, fechaInicio,
fechaFin) están presentes y son correctos.
o Tarea: Verificamos que los atributos (id, nombre, descripción, estado,
proyectoId) están correctamente definidos.
o Usuario: Verificamos que los atributos (id, nombre, email) están correctamente
definidos.
o Asignación: Nos aseguramos de que la asignación tiene todos los atributos
necesarios (id, tareaId, usuarioId, fechaAsignación) y que las relaciones con
Tarea y Usuario son correctas.
2. Validación de Relaciones:
o Un proyecto puede tener múltiples tareas, lo que se refleja en la relación uno a
muchos entre Proyecto y Tarea.
o Un usuario puede realizar múltiples tareas, lo que se refleja en la relación uno a
muchos entre Usuario y Asignación.
o Una tarea puede ser asignada a múltiples usuarios, lo que se refleja en la
relación uno a muchos entre Tarea y Asignación.

Trazabilidad de Requisitos

3. Requisitos de Negocio:
o Gestión de Proyectos: Cada proyecto debe tener un identificador único (id),
nombre, fecha de inicio y fecha de finalización. Validamos que estos requisitos
se reflejan correctamente en el modelo.
o Gestión de Tareas: Cada tarea debe tener un identificador único (id), nombre,
descripción, estado y estar asociada a un proyecto. Validamos que estos
requisitos están correctamente modelados.
o Gestión de Usuarios: Cada usuario debe tener un nombre y un correo
electrónico único, y un identificador interno (id). Validamos que estos requisitos
están correctamente modelados.
o Gestión de Asignaciones: Cada asignación debe tener un identificador único (id),
fecha de asignación, y estar asociada a una tarea y un usuario. Aseguramos que
todos estos requisitos están reflejados en el modelo.

Ejemplo de Revisión de Consistencia

4. Consistencia Interna:
o Tipos de Datos: Verificamos que los tipos de datos son consistentes. Por
ejemplo, id es de tipo int en todas las clases.
o Nombres de Atributos: Nos aseguramos de que los nombres de los atributos
son claros y consistentes. Por ejemplo, fechaInicio y fechaFin se usan en lugar de
variaciones como inicioFecha o finFecha.

Ejemplo de Análisis de Robustez

5. Modularidad y Encapsulamiento:

9
 IS – 286 MODELADO Y ANALISIS DE SOFTWARE

o Encapsulamiento: Cada clase encapsula sus atributos y métodos, y expone solo

las interfaces necesarias. Los detalles internos, como los métodos de gestión de
asignaciones en la clase Usuario, están ocultos.
o Interfaz Clara: Las relaciones entre las clases están claramente definidas,
facilitando las modificaciones futuras sin afectar a todo el sistema.

Ejemplo de Documentación

6. Documentación y Anotación:
o Proyecto:
 id: Identificador único del proyecto.
 nombre: Nombre del proyecto.
 fechaInicio: Fecha de inicio del proyecto.
 fechaFin: Fecha de finalización del proyecto.
o Tarea:
 id: Identificador único de la tarea.
 nombre: Nombre de la tarea.
 descripción: Descripción detallada de la tarea.
 estado: Estado actual de la tarea (e.g., pendiente, en progreso,
completada).
 proyectoId: Identificador del proyecto al que pertenece la tarea.
o Usuario:
 id: Identificador único del usuario.
 nombre: Nombre del usuario.
 email: Correo electrónico único del usuario.
o Asignación:
 id: Identificador único de la asignación.
 tareaId: Identificador de la tarea asignada.
 usuarioId: Identificador del usuario al que se le asigna la tarea.
 fechaAsignación: Fecha en la que se realizó la asignación.

10