diseño e implementación del sistema principios del diseño y criterios de calidad arquitectura del...

Diseño e Implementación del Sistema

Principios del diseño y criterios de calidad

Arquitectura del Sistema CommonKADS

Pasos para la creación de un modelo de diseño

Curso CommonKADS Diseño e implementación del Sistema 2

Desde el análisis al diseño


Diseño del Sistema

Entrada: Modelo del conocimiento = requisitos de resolución de problemas Modelo de comunicación = requisitos de interacción Otros modelos = requisitos ‘no funcionales’

Salida: Especificación de una arquitectura software Diseño de la aplicación con dicha arquitectura


Arquitectura del sistema

Descripción del software en términos de: Descomposición en sub-sistemas Elección del(los) regímene(s) de control Descomposición de los sub-sistemas en módulos software

Elemento central en el proceso de diseño Arquitectura base para sistemas basados en CommonKADS


Diseño basado en el mantenimiento de la estructura del análisis

“Preservar durante el diseño tanto el contenidos como la estructura del modelo de análisis”

Principio esencial en el diseño moderno Se considera que el diseño sólo debe ‘añadir detalles

específicos de la implementación a los resultados del análisis’ La clave está en preservar la información Relacionado directamente con los criterios de calidad


Criterios generales de calidad en el diseño

Minimización del acoplamiento Maximización de la cohesión Transparencia Mantenibilidad


Criterios de calidad para el diseño de SBC

Reusabilidad de elementos del diseño /del código resultante Mantenibilidad y adaptabilidad

Desarrollos en un solo paso es poco realista, especialmente para sistemas intensivos en conocimiento

Posibilidad de generar explicaciones Facilidad en la extracción y refinamiento del conocimiento

El conocimiento evoluciona en el tiempo


Pasos en el diseño de sistemas


Paso 1: especificar la arquitectura global

Principio: separar las cuestiones de funcionalidad de la interfase

Arquitectura MVC: Desarrollado para el Smaltalk-80 Se distingue entre los objetos de la aplicación y su

visualización Unidad de control central con un régimen dirigido por eventos


Arquitectura del Sistemas: Componentes principales


Subsistema: modelo de la aplicación

Contiene los datos y las funciones de la aplicación= objetos del modelo de conocimiento

Datos Bases de conocimiento Datos dinámicos manipulados durante el razonamiento (roles dinámicos)

Funciones Tareas, inferencias, funciones de transferencia


Subsistema: vistas

Visualizaciones de los datos de la aplicación y de sus funciones Posibilidad de que existan múltiples visualizaciones Visualización por agregación de múltiples objetos de la

aplicación Requiere de mecanismos de actualización /integridad de la

arquitectura Tabla de mapeo Protocolo de mensajes para cambios en los estados de los objetos


Subsistema: controlador

Unidad central de ‘mando y control’ Proporciona manipuladores para los eventos internos y externos Posibilita la activación de funciones de la aplicación Puede definir sus propias vistas de control Puede tener un reloj y una agenda interna

Comportamiento por ‘demonios’


Puntualizaciones sobre la arquitectura MVC

Desarrollo en un contexto orientado a objetos Es de hecho una descomposición funcional de objetos Su utilización no está necesariamente limitada a

aproximaciones O-O Aunque el paradigma de paso de mensajes se ajusta bien con las

características de esas arquitecturas


Descomposición del subsistema del modelo de la aplicación

Criterio Debe permitir un diseño que preserve la estructura del análisis Debe posibilitar la integración con otras aproximaciones

Opciones Descomposición funcional o por objetos

Elección: descomposición basada en objetos Se ajusta bien con el carácter declarativo de las especificaciones de

los objetos en el modelo de conocimiento (tarea => objeto) Simplifica la traducción (mapeo) en la implementaciones O-O


Arquitectura del sistema:Subsistema del modelo de la aplicación


Paso 2: Identificar la plataforma de implementación

Los requisitos específicos del cliente suelen restringir esta elección= es necesario considerar esto desde el principio

Hoy día es más importante la elección del software que la del hardware Excepto en aplicaciones de control en tiempo real

Si la elección no está limitada, considerar retrasar la elección hasta la finalización del paso 3


Criterios de selección de la plataforma

Librería de visualización de clases de objetos Su desarrollo puede ser muy costoso

Formalismo de representación del conocimiento declarativo Interfaces estándar a otro software

Ej. ODBC, CORBA Suele ser un requisito

Facilidades de tipado en el lenguaje El tipado débil implica usualmente más trabajo en mapeo del modelo de

análisis (ver paso 4a)

Control de las facilidades/protocolos


Entorno ejemplo: Prolog

Librería de visualización: dependiente del vendedor Representación del conocimiento declarativa Interfaces con BD: depende del vendedor Tipado débil del lenguaje No existen protocolos estándar para el control de

eventos o paso de mensajes


Entornos ejemplo: Java

Librería de vistas No tiene una representación del conocimiento declarativa Posee interfases con BD Facilidades de tipado similares a C++ Facilidades de control:

Ej. Multi-threading


Paso 3: especificar los componentes de la arquitectura

Especificar las interfases de los componentes Diseñar las utilidades/facilidades generales de la

arquitectura Mecanismo de actualización de las vistas


Facilidades del controlador

Activación/terminación de las funciones de la aplicación Interrupciones de usuario para trazar o editar información

de background Aborto de funciones Gestión de las funciones de transferencia


Facilidades del modelo de la Aplicación (1)

Tarea: Métodos de inicialización y ejecución

Método de la tarea: Elementos de control del lenguaje ‘Declaratividad’ del lenguaje de control

Inferencia: Ejecutar, ¿más soluciones?, ¿tiene solución? Enlace con los métodos de inferencia



Método de Inferencia ¿existe un catálogo de métodos? Posibilitar relaciones muchos a muchos entre las inferencias y los métodos

Funciones de transferencia Implementarlas mediante envío de mensajes

Roles dinámicos Tipos de datos permitidos: elemento, conjunto, lista ¿?¡ Operaciones de actualización y acceso: seleccionar, eliminar, añadir, ...



Roles estáticos Funciones de acceso y de query

Modelos del Dominio Formato representacional Funciones de acceso y query Funciones de modificación y análisis

Construcciones del Dominio (Sólo revisarlas)


Facilidades de las vistas

Visualizaciones gráficas standard Generación de formatos externos

e.j. SQL query

Facilidades de actualización de vistas Tabla de mapeo Protocolos basados en mensajes


Interfases de usuario

Interfase de usuario final Considerar utilidades específicas como la generación de

lenguaje natural. Utilizar visualizaciones características del Dominio

Interfase Experta Interfase de traza Interfase para editar o refinar las bases de conocimiento


Ejemplo de trazador


Paso 4: especificar la aplicación en la arquitectura

Paso 4a: “mapear el análisis en la arquitectura” Es un proceso engorroso

Paso 4b: “añadir detalles de diseño” Listar los detalles de diseño que necesiten añadirse para

completar la operacionalización del modelo de análisis


Paso 4a: mapear la información del análisis en la arquitectura

Existen herramientas de mapeo en desarrollo ejemplo: VOID API Ver el web de CommonKADS

El alcance del mapeo va a depender de algunas decisiones de diseño


Diseño de la aplicación para el controlador

Entrada: modelo de comunicación Mínimo: procedimiento de arranque Otras funciones:

Requerimientos de gestión de justificaciones Control del usuario sobre el proceso de razonamiento Interrupciones del razonamiento / estrategia de control Posibilitar escenarios “what-if”


Diseño del modelo de la aplicación

Conjunto mínimo de actividades para el diseño de la aplicación: Para cada método de tarea:

Construir la estructura de control operacional

Para cada role dinámico: Elegir un tipo de datos

Para cada inferencia Identificar un mapeo Escribir un método de invocación para la inferencia


Diseño de la aplicación para las vistas

Si fuera necesario, seleccionar una vista para cada objeto de la aplicación

Consejo: utilizar vistas lo más parecidas a los formatos utilizados en el dominio para la interfase de usuario Demasiado a menudo los diseñadores imponen a los usuarios sus

preferencias Cada dominio tiene sus propias tradiciones a la hora de representar

la información (y normalmente por buenos motivos)


Prototipado: subsistema de razonamiento

¿Cuándo se necesita? Para elementos de conocimiento novedosos o sin precedentes Cuando se detecten ‘vacíos’ en el conocimiento del dominio En general: para verificar y validar el modelo de conocimiento

– verificación: “is the system right”

– validación: “is it the right system”

La plataforma de implementación debe ser capaz de facilitar este proceso La construcción del prototipo debe ser cuestión de días


Elementos Clave

Se considera al diseño como un proceso de refinamiento en el que se mantiene la estructura del análisis

Cuatro pasos para el proceso de diseño Se puede recibir apoyo de:

Arquitectura CommonKADS Herramientas de transformación de los modelos de conocimiento y comunicación Plataformas específicas con paquetes CommonKADS

“diseño racional: cómo y porqué imitarlo” (Parnas & Clements)


Prototype: mock-up agent interface

Test mock-up interface without full application functionality When needed:

complex external interaction (e.g.; HOMEBOTS) complex view formats complex view aggregations


Sistemas de conocimiento distribuidos

Servicios de Razonamiento El modelo de la aplicación actúa como un servicio Sin interfase de usuario

Servidor de bases de conocimiento /ontologías Servicio de métodos

Sistemas distribuidos implementados mediante un conjunto de métodos

Combinaciones


Sample implementations

Housing application Source code at web-site “Academic” implementation

public-domain Prolog

“Business” implementation Aion8

Experiences show that prototypes of “running knowledge models” can be built within days


Architecture Prolog system


Trace Prolog system (1)


Aion8 system for “housing”

Realized as O-O “framework” roles, interfaces => multiple inheritance Hollywood principle

Includes task-template library facility Default implementation of inferences


Aion8 system architecture


Aion8 CommonKADS classes


Aion8 assessment library


Trace Aion8 system (1)


Trace Aion8 system (2)

diseño e implementación del sistema principios del diseño y criterios de calidad arquitectura del...

Documents