Diseño de Software: Proceso, Principios y Modelos

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

El proceso de diseño es la transformación de 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.
• Proceso que conduce a una representación final del diseño.

El proceso de diseño producirá:

• 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.

Procesos de diseño antiguos (principios antiguos)

• Modulares
• Estructurada (procedimentales)
• Estructuras de datos
• Orientación a objetos
• Hoy día, Arquitectura del software

Qué contiene el modelo de la aplicación:

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

Paradigma de inferencia seleccion plataforma implementación:

Razonamiento hacia delante, hacia atrás, hipotético, mantenimiento de la verdad, con incertidumbre y basado en casos.

En qué está basado el diseño de una inferencia:

En la información contenida en el modelo de conocimiento.

Principios

1. No deberá utilizarse orejeras (Enfoques alternativos).
2. El diseño debe poder rastrear hasta el modelo de análisis.
3. Es necesario tener un medio para poder rastrear el cumplimiento de los requisitos en el modelo de diseño.
4. No reinventar. Reutilización como máxima.
5. Reducir la distancia entre software y problema.
6. Presentar uniformidad e integración. Debe parecer que el diseño lo ha hecho una persona y con reglas de estilo y formato.
7. El diseño debe estructurarse para que pueda admitir cambios (Abstracción, refinamiento, modularidad).
8. Diseño robusto.
9. Diseño no código, código no diseño.
10. El diseño debe evaluarse en función de la calidad mientras se va creando, no al final.
11. El diseño debe revisarse para minimizar los errores conceptuales.

Objetivos MD COMMONKADS

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

Modelo de Diseño COMMONKADS

El modelo de diseño COMMONKADS se compone de cuatro pasos:

Primer Paso

El objetivo del diseño de la arquitectura es la identificación de subsistemas y el establecimiento del marco de trabajo que nos permite especificar el control y la comunicación entre los subsistemas. 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, está basada en MVC, se desarrolló como paradigma para el diseño de programas para el lenguaje orientado 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.

Segundo Paso

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. Dentro del 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.

1rpaso          2opaso           3erpaso          4opaso

diseño de  --  especif de la--Especf detall-- diseño detall

la arquitec.     plataf hw/sw   de la arquit     de la app

MVC

Modelo: En este subsistema se especifican las funciones y los datos que conforman las funcionalidades de la aplicación. En un 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.