Descomposición arquitectónica de software

La descomposición arquitectónica de software es el proceso de dividir un sistema de software en módulos más pequeños y manejables. Estos módulos se denominan componentes y se diseñan para realizar funciones específicas. La descomposición arquitectónica es una parte fundamental del diseño de software y ayuda a lograr varios objetivos importantes, como:

Modularidad: La descomposición en módulos hace que el software sea más modular, lo que significa que los módulos están bien definidos y tienen una baja dependencia entre sí. Esto facilita la comprensión, el mantenimiento y la modificación del software.

Reutilización: Los módulos bien diseñados se pueden reutilizar en otros proyectos de software. Esto puede ahorrar tiempo y esfuerzo de desarrollo.

Escalabilidad: Un software bien descompuesto se puede escalar fácilmente agregando o eliminando módulos. Esto es importante para aplicaciones que necesitan adaptarse a cambios en la demanda o en los requisitos.

Mantenimiento: La descomposición modular facilita el mantenimiento del software. Los módulos individuales se pueden probar y depurar de forma independiente, lo que facilita la identificación y corrección de errores.

Estrategias.

Existen diferentes enfoques para la descomposición arquitectónica de software. Algunos de los enfoques más comunes incluyen:

Descomposición funcional.

Este enfoque divide el sistema en módulos según las funciones que realizan. Por ejemplo, un sistema de comercio electrónico podría tener módulos para administrar productos, pedidos y clientes.

Ejemplo de Descomposición funcional: Un cajero automático

Función principal: Retirar efectivo de una cuenta bancaria.

Descomposición en subfunciones:

1. Identificación del usuario:

   • Leer la tarjeta del usuario.
   • Validar la tarjeta del usuario.
   • Solicitar el PIN del usuario.
   • Verificar el PIN del usuario.

2. Selección de la transacción:

   • Mostrar un menú de opciones de transacción.
   • Permitir al usuario seleccionar la opción "Retiro de efectivo".

3. Especificación del monto:

   • Solicitar al usuario que ingrese el monto a retirar.
   • Validar el monto ingresado.

4. Dispensación de efectivo:

   • Verificar que haya suficiente efectivo disponible en el cajero automático.
   • Dispensar el efectivo solicitado.

5. Impresión del recibo:

   • Imprimir un recibo de la transacción.

Diagrama de descomposición funcional:

Retirar efectivo
├── Identificación del usuario
│   ├── Leer tarjeta del usuario
│   ├── Validar tarjeta del usuario
│   ├── Solicitar PIN del usuario
│   └── Verificar PIN del usuario
├── Selección de la transacción
│   ├── Mostrar menú de opciones
│   └── Permitir selección de "Retiro de efectivo"
├── Especificación del monto
│   ├── Solicitar monto a retirar
│   └── Validar monto ingresado
├── Dispensación de efectivo
│   ├── Verificar disponibilidad de efectivo
│   └── Dispensar efectivo
└── Impresión del recibo
    └── Imprimir recibo de la transacción

En este ejemplo, la función principal de retirar efectivo se descompone en cinco subfunciones más pequeñas y manejables. Cada subfunción realiza una tarea específica y tiene una interfaz bien definida. Esto facilita la comprensión, el mantenimiento y la modificación del software.

Descomposición por capas.

Este enfoque divide el sistema en capas horizontales, cada una con una responsabilidad específica. Por ejemplo, un sistema de software empresarial podría tener una capa de presentación, una capa de lógica de negocios y una capa de acceso a datos.

Ejemplo de Descomposición por capas: Un sistema de gestión de cursos en línea

Capas:

1. Capa de presentación: Esta capa es responsable de la interacción con el usuario. Se encarga de mostrar la interfaz de usuario y manejar las entradas del usuario.

2. Capa de lógica de negocios: Esta capa es responsable de la lógica del sistema. Implementa las reglas de negocio y la validación de datos.

3. Capa de acceso a datos: Esta capa es responsable de la interacción con la base de datos. Proporciona métodos para almacenar, recuperar y modificar datos.

Diagrama de descomposición por capas:

Usuario
├── Interfaz de usuario (Capa de presentación)
│   ├── Formularios web
│   ├── Controles de entrada
│   └── Mensajes de salida
├── Lógica de negocios (Capa de lógica de negocios)
│   ├── Registro de usuarios
│   ├── Gestión de cursos
│   └── Calificación de tareas
└── Acceso a datos (Capa de acceso a datos)
    ├── Conexión a la base de datos
    ├── Consultas SQL
    ├── Almacenamiento y recuperación de datos

En este ejemplo, el sistema de gestión de cursos en línea se descompone en tres capas:

• La capa de presentación proporciona una interfaz de usuario sencilla para que los usuarios interactúen con el sistema.
• La capa de lógica de negocios implementa las reglas de negocio del sistema, como la forma en que se registran los usuarios, se crean los cursos y se califican las tareas.
• La capa de acceso a datos maneja la interacción con la base de datos, almacenando, recuperando y modificando los datos necesarios para que funcione el sistema.

La descomposición por capas tiene varias ventajas, que incluyen:

• Mayor modularidad: Las capas están bien definidas y tienen una baja dependencia entre sí. Esto facilita la comprensión, el mantenimiento y la modificación del software.
• Mayor reutilización: Las capas se pueden reutilizar en otros proyectos de software.
• Mayor facilidad de mantenimiento: Las capas se pueden probar y depurar de forma independiente, lo que facilita la identificación y corrección de errores.

Descomposición orientada a objetos

Este enfoque divide el sistema en objetos, que son instancias de clases. Las clases definen el comportamiento y los datos de los objetos.

Ejemplo de Descomposición Orientada a Objetos: Sistema de gestión de biblioteca

Clases:

• Libro: Representa un libro en la biblioteca.

  • Atributos:
    • ISBN: El número de identificación internacional estándar del libro.
    • Título: El título del libro.
    • Autor: El autor del libro.
    • Género: El género del libro.
    • Estado: El estado del libro (disponible, prestado, etc.).
  • Métodos:
    • Consultar disponibilidad()
    • Prestar()
    • Devolver()

• Usuario: Representa un usuario de la biblioteca.

  • Atributos:
    • ID de usuario: El identificador único del usuario.
    • Nombre: El nombre del usuario.
    • Apellido: El apellido del usuario.
    • Dirección: La dirección del usuario.
    • Teléfono: El número de teléfono del usuario.
    • Correo electrónico: La dirección de correo electrónico del usuario.
  • Métodos:
    • Registrarse()
    • Iniciar sesión()
    • Consultar libros prestados()
    • Renovar préstamo()

• Bibliotecario: Representa un bibliotecario de la biblioteca.

  • Atributos:
    • ID de bibliotecario: El identificador único del bibliotecario.
    • Nombre: El nombre del bibliotecario.
    • Apellido: El apellido del bibliotecario.
    • Cargo: El cargo del bibliotecario (jefe de bibliotecario, bibliotecario asistente, etc.).
  • Métodos:
    • Agregar libro()
    • Eliminar libro()
    • Consultar usuarios morosos()
    • Gestionar multas()

Relaciones:

• Un libro puede ser prestado por un usuario.
• Un usuario puede prestar varios libros.
• Un bibliotecario puede agregar o eliminar libros.
• Un bibliotecario puede consultar usuarios morosos y gestionar multas.

Diagrama de descomposición orientada a objetos:

Usuario
├── Registrarse()
├── Iniciar sesión()
├── Consultar libros prestados()
├── Renovar préstamo()
Bibliotecario
├── Agregar libro()
├── Eliminar libro()
├── Consultar usuarios morosos()
├── Gestionar multas()
Libro
├── Consultar disponibilidad()
├── Prestar()
└── Devolver()

En este ejemplo, el sistema de gestión de biblioteca se descompone en tres clases principales:

• La clase Libro representa un libro en la biblioteca y tiene atributos como ISBN, título, autor, género y estado. También tiene métodos para consultar la disponibilidad del libro, prestarlo y devolverlo.

• La clase Usuario representa un usuario de la biblioteca y tiene atributos como ID de usuario, nombre, apellido, dirección, teléfono y correo electrónico. También tiene métodos para registrarse, iniciar sesión, consultar libros prestados y renovar préstamos.

• La clase Bibliotecario representa un bibliotecario de la biblioteca y tiene atributos como ID de bibliotecario, nombre, apellido y cargo. También tiene métodos para agregar y eliminar libros, consultar usuarios morosos y gestionar multas.

La descomposición orientada a objetos tiene varias ventajas, que incluyen:

• Mayor modularidad: Las clases están bien definidas y tienen una baja dependencia entre sí. Esto facilita la comprensión, el mantenimiento y la modificación del software.
• Mayor reutilización: Las clases se pueden reutilizar en otros proyectos de software.
• Mayor facilidad de mantenimiento: Las clases se pueden probar y depurar de forma independiente, lo que facilita la identificación y corrección de errores.

Descomposición por Patrones:

Este enfoque se basa en identificar patrones de diseño de software comunes y utilizarlos para descomponer el sistema en módulos.

Ejemplo de Descomposición por Patrones: Sistema de gestión de pedidos en línea

Patrones de diseño utilizados:

• Observer: Este patrón se utiliza para implementar un sistema de notificaciones. Cuando un pedido se crea, modifica o elimina, se notifica a los módulos interesados, como el departamento de envío y el departamento de atención al cliente.

• Memento: Este patrón se utiliza para guardar y restaurar el estado de un pedido. Esto permite a los usuarios deshacer o rehacer cambios en sus pedidos.

• Command: Este patrón se utiliza para encapsular las solicitudes de los usuarios en objetos autocontenidos. Esto facilita el procesamiento y la gestión de las solicitudes.

Descomposición en módulos:

• Módulo de gestión de pedidos: Este módulo es responsable de crear, modificar y eliminar pedidos. También implementa el patrón Observer para notificar a los módulos interesados sobre los cambios en los pedidos.

• Módulo de envío: Este módulo es responsable de procesar los pedidos y enviar los productos a los clientes. Implementa el patrón Memento para guardar y restaurar el estado de los pedidos.

• Módulo de atención al cliente: Este módulo es responsable de proporcionar soporte al cliente relacionado con los pedidos. Implementa el patrón Command para encapsular las solicitudes de los clientes.

Diagrama de descomposición por patrones:

Usuario
├── Realizar pedido
│   ├── Notificar módulo de gestión de pedidos (Observer)
├── Modificar pedido
│   ├── Notificar módulo de gestión de pedidos (Observer)
├── Cancelar pedido
│   ├── Notificar módulo de gestión de pedidos (Observer)
Módulo de gestión de pedidos
├── Crear pedido
│   ├── Notificar módulo de envío (Observer)
│   ├── Notificar módulo de atención al cliente (Observer)
├── Modificar pedido
│   ├── Guardar estado actual (Memento)
│   ├── Actualizar pedido
│   ├── Restaurar estado anterior (Memento) si es necesario
│   ├── Notificar módulo de envío (Observer)
│   ├── Notificar módulo de atención al cliente (Observer)
├── Eliminar pedido
│   ├── Notificar módulo de envío (Observer)
│   ├── Notificar módulo de atención al cliente (Observer)
Módulo de envío
├── Procesar pedido
│   ├── Consultar estado del pedido (Memento)
│   ├── Enviar productos al cliente
Módulo de atención al cliente
├── Responder preguntas sobre pedidos
│   ├── Consultar estado del pedido (Memento)

En este ejemplo, el sistema de gestión de pedidos en línea se descompone en tres módulos principales, cada uno de los cuales implementa un patrón de diseño específico:

• El módulo de gestión de pedidos es responsable de la lógica central del sistema, como la creación, modificación y eliminación de pedidos. Implementa el patrón Observer para notificar a los módulos interesados sobre los cambios en los pedidos.

• El módulo de envío es responsable de procesar los pedidos y enviar los productos a los clientes. Implementa el patrón Memento para guardar y restaurar el estado de los pedidos, lo que permite a los usuarios deshacer o rehacer cambios.

• El módulo de atención al cliente es responsable de proporcionar soporte al cliente relacionado con los pedidos. Implementa el patrón Command para encapsular las solicitudes de los clientes, lo que facilita su procesamiento y gestión.

La descomposición por patrones tiene varias ventajas, que incluyen:

• Mayor modularidad: Los módulos están bien definidos y tienen una baja dependencia entre sí. Esto facilita la comprensión, el mantenimiento y la modificación del software.
• Mayor reutilización: Los patrones de diseño se pueden reutilizar en otros proyectos de software.
• Mayor facilidad de mantenimiento: Los módulos se pueden probar y depurar de forma independiente, lo que facilita la identificación y corrección de errores.

Descomposición por Eventos

Este enfoque se basa en identificar los eventos que ocurren en el sistema y utilizarlos para descomponer el sistema en módulos.

Ejemplo de Descomposición por Eventos: Sistema de chat en línea

Eventos:

• Mensaje enviado: Este evento se genera cuando un usuario envía un mensaje.
• Usuario conectado: Este evento se genera cuando un usuario se conecta al chat.
• Usuario desconectado: Este evento se genera cuando un usuario se desconecta del chat.

Descomposición en módulos:

• Módulo de gestión de chat: Este módulo es responsable de administrar la sala de chat y los usuarios conectados. Implementa los eventos "Mensaje enviado", "Usuario conectado" y "Usuario desconectado" para actualizar la sala de chat y notificar a los usuarios sobre los cambios.

• Módulo de mensajería: Este módulo es responsable de enviar y recibir mensajes. Implementa el evento "Mensaje enviado" para enviar mensajes a otros usuarios y el evento "Mensaje recibido" para mostrar mensajes en la sala de chat.

• Módulo de notificaciones: Este módulo es responsable de notificar a los usuarios sobre nuevos mensajes y usuarios conectados/desconectados. Implementa los eventos "Mensaje enviado", "Usuario conectado" y "Usuario desconectado" para enviar notificaciones a los usuarios.

Diagrama de descomposición por eventos:

Usuario
├── Enviar mensaje (Evento "Mensaje enviado")
├── Conectar al chat (Evento "Usuario conectado")
├── Desconectar del chat (Evento "Usuario desconectado")
Módulo de gestión de chat
├── Manejar evento "Mensaje enviado"
│   ├── Actualizar sala de chat con nuevo mensaje
│   ├── Notificar módulo de mensajería (Evento "Mensaje enviado")
├── Manejar evento "Usuario conectado"
│   ├── Agregar usuario a la lista de usuarios conectados
│   ├── Notificar módulo de notificaciones (Evento "Usuario conectado")
├── Manejar evento "Usuario desconectado"
│   ├── Eliminar usuario de la lista de usuarios conectados
│   ├── Notificar módulo de notificaciones (Evento "Usuario desconectado")
Módulo de mensajería
├── Manejar evento "Mensaje enviado"
│   ├── Enviar mensaje a otros usuarios
├── Manejar evento "Mensaje recibido"
│   ├── Mostrar mensaje en la sala de chat
Módulo de notificaciones
├── Manejar evento "Mensaje enviado"
│   ├── Enviar notificación a otros usuarios sobre nuevo mensaje
├── Manejar evento "Usuario conectado"
│   ├── Enviar notificación a otros usuarios sobre nuevo usuario conectado
├── Manejar evento "Usuario desconectado"
│   ├── Enviar notificación a otros usuarios sobre usuario desconectado

En este ejemplo, el sistema de chat en línea se descompone en tres módulos principales, cada uno de los cuales maneja un conjunto específico de eventos:

• El módulo de gestión de chat es responsable de la lógica central del sistema, como la gestión de la sala de chat, la lista de usuarios conectados y la notificación de eventos.

• El módulo de mensajería es responsable de enviar y recibir mensajes entre usuarios.

• El módulo de notificaciones es responsable de enviar notificaciones a los usuarios sobre nuevos mensajes y usuarios conectados/desconectados.

La descomposición por eventos tiene varias ventajas, que incluyen:

• Mayor modularidad: Los módulos están bien definidos y tienen una baja dependencia entre sí. Esto facilita la comprensión, el mantenimiento y la modificación del software.
• Mayor flexibilidad: El sistema es más flexible para adaptarse a nuevos eventos y requisitos.
• Mayor facilidad de mantenimiento: Los módulos se pueden probar y depurar de forma independiente, lo que facilita la identificación y corrección de errores.

Descomposición por Actores.

Este enfoque se basa en identificar los actores del sistema (usuarios, sistemas externos, etc.) y utilizarlos para descomponer el sistema en módulos.

Ejemplo de Descomposición por Actores: Sistema de gestión de citas médicas

Actores:

• Paciente: El paciente es el actor principal del sistema. Es responsable de solicitar citas, consultar su historial médico y pagar las citas.

• Médico: El médico es responsable de atender a los pacientes, diagnosticar enfermedades y prescribir tratamientos.

• Secretaria: La secretaria es responsable de gestionar la agenda del médico, programar citas y atender las llamadas de los pacientes.

• Administrador: El administrador es responsable de gestionar el sistema, crear cuentas de usuario, configurar el sistema y generar informes.

Descomposición en módulos:

• Módulo de gestión de pacientes: Este módulo es responsable de la información de los pacientes, como sus datos personales, historial médico y citas.

• Módulo de gestión de citas: Este módulo es responsable de la programación y gestión de citas, incluyendo la asignación de pacientes a médicos, la confirmación de citas y el envío de recordatorios.

• Módulo de gestión de médicos: Este módulo es responsable de la información de los médicos, como su especialidad, horario y disponibilidad.

• Módulo de administración: Este módulo es responsable de la gestión del sistema, como la creación de cuentas de usuario, la configuración del sistema y la generación de informes.

Diagrama de descomposición por actores:

Paciente
├── Solicitar cita
│   ├── Módulo de gestión de citas
├── Consultar historial médico
│   ├── Módulo de gestión de pacientes
├── Pagar cita
│   ├── Módulo de gestión de citas
Médico
├── Atender paciente
│   ├── Módulo de gestión de pacientes
│   ├── Módulo de gestión de citas
├── Diagnosticar enfermedad
│   ├── Módulo de gestión de pacientes
├── Prescribir tratamiento
│   ├── Módulo de gestión de pacientes
Secretaria
├── Gestionar agenda del médico
│   ├── Módulo de gestión de citas
├── Programar citas
│   ├── Módulo de gestión de citas
├── Atender llamadas de pacientes
│   ├── Módulo de gestión de pacientes
│   ├── Módulo de gestión de citas
Administrador
├── Crear cuentas de usuario
│   ├── Módulo de administración
├── Configurar sistema
│   ├── Módulo de administración
├── Generar informes
│   ├── Módulo de administración

En este ejemplo, el sistema de gestión de citas médicas se descompone en cuatro módulos principales, cada uno de los cuales sirve a las necesidades de un actor específico:

• El módulo de gestión de pacientes almacena la información de los pacientes y proporciona acceso a su historial médico.

• El módulo de gestión de citas se encarga de programar y gestionar las citas, asegurando que los pacientes sean atendidos por el médico adecuado en el momento oportuno.

• El módulo de gestión de médicos administra la información de los médicos y su disponibilidad para las citas.

• El módulo de administración proporciona las herramientas necesarias para gestionar el sistema, como la creación de cuentas de usuario, la configuración del sistema y la generación de informes.

La descomposición por actores tiene varias ventajas, que incluyen:

• Mayor claridad: El enfoque en los actores y sus necesidades facilita la comprensión de los requisitos del sistema.

• Mayor facilidad de mantenimiento: Los módulos están bien definidos y tienen una baja dependencia entre sí, lo que facilita el mantenimiento y la modificación del software.

• Mayor participación del usuario: Involucrar a los actores en el proceso de diseño puede ayudar a garantizar que el sistema satisfaga sus necesidades.

En resumen.

El enfoque específico que se utiliza para descomponer un sistema de software dependerá de una variedad de factores, como el tamaño y la complejidad del sistema, los requisitos del usuario y las preferencias del equipo de desarrollo.

La estrategia de descomposición más adecuada para un sistema de software en particular dependerá de una variedad de factores, como el tamaño y la complejidad del sistema, los requisitos del usuario y las preferencias del equipo de desarrollo.

Es importante tener en cuenta que la descomposición del software es un proceso iterativo. A medida que se avanza en el diseño del sistema, puede ser necesario reestructurar los módulos y ajustar las estrategias de descomposición.