Fundamentos del Diseño de Software: Principios, Proceso y Modelos Clave

Conceptos Fundamentales del Diseño de Software

Diseño: Representación significativa, desde el punto de vista de la ingeniería, de algo que se va a construir. El objetivo de un diseñador es producir un modelo o representación de una entidad que será construida.
Proceso de Diseño: Proceso de transformar una idea informal en una descripción de un producto software que puede ser directamente implementado para operacionalizar dicha idea. El proceso combina:

Intuición y juicio, en función de la experiencia.
Principios.
Criterios.
Un proceso que conduce a una representación final del diseño.

Resultados del Proceso de Diseño

El proceso de diseño producirá los siguientes tipos de diseño:

Diseño de Datos: Transformará el modelo de conocimiento del dominio de la aplicación en las estructuras de datos que se necesitan.
Diseño Arquitectónico: Define la relación entre los elementos estructurales y las restricciones.
Diseño de la Interfaz: Describe la manera de comunicarse con el software.
Diseño de Componentes: Transforma elementos estructurales de la arquitectura del software en una descripción procedimental de los componentes software.

Evolución de los Procesos de Diseño

Los procesos de diseño antiguos (principios antiguos) se basaban en:

Modularidad.
Estructura (procedimental).
Estructuras de datos.
Orientación a objetos.

Hoy día, la Arquitectura del Software es el enfoque predominante.

Contenido del Modelo de la Aplicación

El modelo de la aplicación contiene:

Los elementos software que implementan las funciones.
Los datos especificados en los modelos de análisis.

Paradigmas de Inferencia para la Selección de Plataforma

Los paradigmas de inferencia para la selección de plataforma de implementación incluyen:

Razonamiento hacia adelante.
Razonamiento hacia atrás.
Razonamiento hipotético.
Mantenimiento de la verdad.
Razonamiento con incertidumbre.
Razonamiento basado en casos.

Base del Diseño de una Inferencia

El diseño de una inferencia está basado en la información contenida en el modelo de conocimiento.

Principios Fundamentales del Diseño de Software

No deberá utilizarse «orejeras» (fomentar enfoques alternativos).
El diseño podrá rastrearse hasta el modelo de análisis.
Es necesario tener un medio para poder rastrear el cumplimiento de los requisitos en el modelo de diseño.
No reinventar: la reutilización como máxima.
Reducir la distancia entre el software y el problema.
Presentar uniformidad e integración. Debe parecer que el diseño lo ha hecho una persona y con reglas de estilo y formato consistentes.
El diseño deberá estructurarse para que pueda admitir cambios (Abstracción, refinamiento, modularidad).
Diseño robusto.
Diseño no es código, código no es diseño.
El diseño deberá evaluarse en función de la calidad mientras se va creando, no al final.
El diseño deberá revisarse para minimizar los errores conceptuales.

Objetivos del Modelo de Diseño CommonKADS

Separación del análisis y la implementación.
Garantiza la calidad (evalúa viabilidad y costes de implementación).
Especificación independiente de la plataforma.
Descomposición de la tarea de diseño (qué arquitectura usar, qué lenguaje de implementación…).
Separación de la arquitectura de los contenidos.
Inclusión de los requisitos del entorno.
Reutilización.
Diseño de la interfaz y la interacción.

Modelo de Diseño CommonKADS: Pasos y Componentes

El modelo de diseño CommonKADS se compone de cuatro pasos principales:

Paso 1: Diseño de la Arquitectura

El objetivo del diseño de la arquitectura es la identificación de subsistemas y el establecimiento del marco de trabajo que permite especificar el control y la comunicación entre ellos. Existen diferentes aproximaciones para abordar el diseño de la arquitectura; sin embargo, las siguientes actividades son comunes a todos los procesos de diseño arquitectónico:

Descomposición del sistema: El sistema se descompone en los principales subsistemas y se identifican los requisitos de control sobre ellos.
Modelado del control: Se establece un régimen de control entre las partes del sistema.
Descomposición modular: Cada uno de los subsistemas se descompone en un módulo y se identifican sus tipos e interconexiones.

Un subsistema es un sistema por sí mismo cuyo funcionamiento no depende de los servicios suministrados por otros sistemas. Un módulo es un componente de un sistema que suministra servicios a otros módulos y utiliza servicios de otros módulos (no es un sistema independiente).

Este proceso se puede simplificar utilizando la arquitectura de referencia recomendada:

Arquitectura Global del Sistema: Primero debemos describir la arquitectura del sistema de forma global, basada en MVC, que se desarrolló como un paradigma para el diseño de programas orientados a objetos.
Modelo de la Aplicación: El modelo de la aplicación contiene los elementos software que implementan las funciones y los datos especificados en el modelo de análisis. En CommonKADS, estos elementos software hacen referencia a las funciones de razonamiento y a las estructuras de información y conocimiento.

Paso 2: Especificación de la Plataforma de Implementación

Aunque el diseño se pueda realizar independientemente de la plataforma y el lenguaje de implementación seleccionado, una buena elección de la herramienta puede simplificar el modelo de diseño. Una adecuada elección de la herramienta de implementación puede simplificar el resto de los pasos, por lo que el producto final ganará en calidad. Desde el punto de vista de CommonKADS, las siguientes características pueden ser relevantes a la hora de la elección de la herramienta:

Disponibilidad de una librería de vistas de objetos.
Representación declarativa del conocimiento.
Interoperabilidad.
Paradigma de programación.
Control de flujo.
Soporte para CommonKADS.

Esquema de los Pasos del Modelo de Diseño CommonKADS

El proceso de diseño CommonKADS se estructura en cuatro pasos interconectados:

Paso 1: Diseño de la Arquitectura → Paso 2: Especificación de la Plataforma HW/SW → Paso 3: Especificación Detallada de la Arquitectura → Paso 4: Diseño Detallado de la Aplicación

Arquitectura Modelo-Vista-Controlador (MVC)

El patrón arquitectónico MVC organiza la aplicación en tres componentes interconectados:

Modelo: En este subsistema se especifican las funciones y los datos que conforman las funcionalidades de la aplicación. En un Sistema Basado en Conocimiento (SBC), este contendrá las funciones de razonamiento, los datos que constituyen las bases del conocimiento y los roles dinámicos manipulados.
Vistas: En este subsistema se definen las vistas externas de las funciones y datos incluidos en el modelo de la aplicación. En estas vistas se representan las visualizaciones de los objetos y funciones de la aplicación en una interfaz de usuario, pero también se puede representar un conjunto de datos obtenidos mediante una consulta SQL. Esta separación entre los objetos de la aplicación y su visualización es una de las características más importantes del MVC.
Controlador: Este subsistema especifica la unidad de control del sistema. Se suele implementar utilizando un modelo de control dirigido por eventos y suele estar formado por un conjunto de gestores de eventos para gestionar tanto eventos internos como externos. También puede contener un reloj (para aplicaciones en tiempo real), puede lanzar determinados procesos como demonios y definir sus propias vistas para proporcionar información sobre el estado del sistema. Se encarga de activar las funciones del modelo y decidir cuándo recoger el resultado.