Representación de Conocimiento y Razonamiento en el...

1

1

Representación de Conocimiento y

Razonamiento en el Proceso de Diseño de

Arquitecturas de Software

Seminarios PAE – CELTIC

María Luciana RoldánBecaria Postdoctoral CONICET

Director: Dr. Horacio Leone

Co-Director: Dr. Silvio Gonnet

2Seminarios PAE – CELTIC - 2009

Proceso de Diseño de Arquitecturas de Software

� El Diseño de Arquitecturas de Software: Proceso complejo que abarca actividades de:

� Exploración

� Evaluación

� Composición

� Durante el Proceso de Diseño de Arquitecturas de Software (PDAS) se generan, transforman y refinandiversos productos.

� La complejidad inherente al PDAS requiere ser administrada.

de alternativas de diseño

2


Necesidad

� Herramientas existentes� Enfocadas en los productos del diseño

� No satisfacen la necesidad de capturar el conocimiento aplicado y generado durante el diseño de la arquitectura de software.

� No se conserva una representación explícita acerca de cómo los productos fueron obtenidos, quéactividades los generaron y qué razonamientos respaldan a las decisiones tomadas.

� El conocimiento se conserva sólo en la mente de los actores que participan en el proceso� Se pierde con el transcurrir del tiempo


Objetivo

� Proponer un modelo para:

� representación de conocimiento y razonamiento del proceso de diseño de arquitecturas de software

� posibilitar la captura y el seguimiento del proceso desde la definición de los requerimientos.

� Desarrollo de herramientas computacionales de soporte al PDAS.

� Que permitan estructurar la información y el conocimiento que se adquiere a lo largo del proceso de solución, así como el razonamiento que sustenta a las decisiones adoptadas.

3


Modelo para la Representación de Conocimiento y Razonamiento en el

Proceso de Diseño de Arquitecturas de Software

Modelo Propuesto

Esquema de Versionamiento

Modelo del Dominio Modelo de Operaciones

Conceptos de Estructura y Comportamiento

Conceptos de Razonamiento

Propiedades y Relaciones Operaciones

Propiedades y Relaciones Operaciones

Versiones

Repositorio


Enfoque adoptado

� Perspectiva Operacional.

� PDAS: serie de actividades que operan sobre los productos del proceso de diseño (la arquitectura de software bajo diseño, los requerimientos a ser alcanzados, los escenarios que deben verificarse, los componentes de software, etc.)

� Los productos se van transformando a medida que el PDAS tiene lugar, originando diversas versiones.

� Las decisiones de diseño son materializadas en operaciones arquitectónicas que son capturadas junto a los productos que ellas generan.

4


Esquema para la Administración de Versiones

m2Sistema

Cliente Servidor

m0

m1

φ1

φ2

aplicar(φ2, m1) = m2

λφ =

o • φ, o: operación

Evolución del Modelo (Cálculo de Situaciones)

aplicar(φ, mp) = mn

Operaciones Primitivas� agregar(v)� eliminar(v)� modificar(vp, vs)


Modelos

Inferidos

Modelo Inferido k

<<sistema>>

Struts

<<componente>>

AplicaciónWeb

Modelo Inferido q

<<sistema>>

Struts

<<componente>>Vista

<<componente>>Modelo

<<componente>>Controlador

Objetos de Diseño

Versión de

Modelo m0

Versión de

Modelo mj

Versión de Modelo mk

Versión de

Modelo mp

Versión de

Modelo mi

Versión de

Modelo mq

Relación de Precedenciaque implica que se ha ejecutado una Secuencia de Operaciones

φi

φkφq

φj

φp


Los productos del diseño son denominados Objetos de

Diseño

Doble representación:

-Nivel Versiones:

Versiones de Objeto

-Nivel Repositorio:

-Objetos Versionables

5



Versiones

Repositorio

origen *

destino

*

objeto

Versión

*

Asociación

pertenece

1..* *

versión1..*

VersiónDeObjeto

ObjetoVersionable

*

Versión

predecesora

HistoriaVersión

*

*

ValorPropiedad

Historia

HistoriaModeloVersiónDeModelo

sucesora

1

*

0..1

resultado*

argumento*

{ordered}*

{ordered}

Captura de Productos

Captura de Operaciones


Modelo de Dominio Integración con Esquema de Versionamiento

Versiones

Dominios

RelaciónDeDominioparte

Propiedad

contenedor

*

*

TipoPropiedadRepositorio

origen*

destino

*

objeto

Versión

TipoDeObjeto

TipoDe

Asociación

*

*

instancia

Asociación

pertenece

1..* *

versión1..*

VersiónDeObjeto

TipoDeObjetoDeDiseño

ObjetoVersionable

*

*

Versión

resultado*

argumento

predecesora

HistoriaVersión

**

*

ValorPropiedad

Operación

Historia

HistoriaModelo Versión DeModelosucesora

TipoDeObjetoDeDiseñoConcreto1

*

0..1

{ordered}

{ordered}*

*

{ordered}

*

6


Un Dominio para PDAS

Evaluación

Sistema

RequerimientoDeCalidad

Requerimiento

RequerimientoFuncional

ResponsabilidadEscenarioDeCalidad

Componente

Rol

Puerto

Conector

Característica

Restricciónnombre

descripción

nombre

descripción

protocolo

nombre

descripción

nombredescripción

nombre

descripción

nombre

descripción

número

nombre

descripción

tipo

sistema operativo

nombre

descripción

valor

técnica

nombredescripción

estímulo

origenDelEstímulo

artefacto

entorno

respuesta

medidaDeRespuesta

nombre

descripción

prioridad

nombre

descripción

*

1 *1

0..1

0..1

2..*

*

*

*

*

*

*

1

*

*

*

*

1

*

1

*0..1

*

RConexión

0..1

*

*

1

RReqFRespRReqCEsc

REvalEsc

REvalComp

REvalCon

RSistCon

RSistComp

RSistRest

RReqSist

RConRol

RConRest

RTienePuerto

RCompCar

RConCar

RTieneResp

RCompRest

Tipos de Objetos de Diseño

derivados de ADD y ACME


Operaciones del Dominio

Operaciones Primitivas:

agregar, eliminar y modificar

No son suficientes para representar las actividades de diseño de un arquitecto en el dominio de PDAS

(aplicar patrones arquitectónicos, refinar componentes, definir escenarios de calidad)

Necesidad de contar con operaciones válidas para los tipos de objetos de diseño del dominio

Mayor contenido semántico

Alto poder de abstracción

7


Modelo de Operaciones


TipoDeDato

TipoDeDatoPrimitivo Colección

tipoDeElemento

RelaciónDeDominio

argumento

*

1..*

{ordered}cuerpo

MacroComando Primitiva

EliminarAgregar Modificar

Argumento

Operación

Comando

nombre

Variable

valor

Bucle Siguiente

Iteración

rvalue

Asignación

tipo

VersiónDeObjeto

resultado

FunciónAuxiliar

SeleccionarObtener AgregarAsociación

ConstructorColección

1..* <<interface>>

Valor

lvalue*{ordered}

i-ElementoConcatenar

AplicableA

Declara una interfaz para la ejecución de

operaciones

Se define como un macro-comando

Provistas por el Esquema de Administración de

Versiones

Modelo de Operaciones Básico

Definición de operaciones arquitectónicas de manera

flexible




TipoDeDato


tipoDeElemento

RelaciónDeDominio

argumento

*

1..*

{ordered}cuerpo



Argumento

Operación

Comando

nombre

Variable

valor

Bucle Siguiente

Iteración

rvalue

Asignación

tipo

VersiónDeObjeto

resultado

FunciónAuxiliar



1..* <<interface>>

Valor

lvalue*{ordered}


AplicableA

Tipos de datos manejados en el modelo

para la argumentos

8




TipoDeDato


tipoDeElemento

RelaciónDeDominio

argumento

*

1..*

{ordered}cuerpo



Argumento

Operación

Comando

nombre

Variable

valor

Bucle Siguiente

Iteración

rvalue

Asignación

tipo

VersiónDeObjeto

resultado

FunciónAuxiliar



1..* <<interface>>

Valor

lvalue*{ordered}


AplicableA

Predefinidas en el Modelo.

Posibilitan la construcción de

operaciones complejas


Especificación de Operaciones No PrimitivasagregarComponente(s: Sistema, nc: Cadena,

lResps: Colección[Cadena],

lPuertos: Colección[Cadena],

lprops: Colección[TipoDeDatoPrimitivo])

c:= agregar(nc, Componente, lprops)

para cada nr en lResps

agregarResponsabilidad(c, nr, [])

fin para

para cada np en lPuertos

agregarPuerto(c, np, [])

fin para

agregarAsociación(s, c, RSistComp)

fin

agregarResponsabilidad(

c: Componente, nr: Cadena, lprops: Colección[TipoDeDatoPrimitivo])

r := agregar(nr, Responsabilidad, lprops)

rtr := agregar(null, RTieneResp, [])

agregarAsociación(c, rtr, RCompRTR)

agregarAsociación(rtr, r, RRTRResp)

fin

agregarPuerto(c: Componente, np: Cadena, lprops: Colección[TipoDeDatoPrimitivo])

p := agregar(np, Puerto, lprops)

agregarAsociación(c, p, RTienePuerto)

fin

9


Especificación de Operaciones de Aplicación de Patrones Arquitectónicos

aplicarClienteServidor(c: Componente)

s : = obtener(Sistema, c)

cliente := agregarComponente(s, ‘Cliente’,

[‘IniciarConexión’, ‘EnviarSolicitud’], [‘Cliente-P1’],[])

servidor := agregarComponente(s, ‘Servidor’

[‘AceptarConexión’, ‘ResolverSolitud’, ‘EnviarDatos’,

‘CerrarConexión’], [‘Servidor-P1’] ,[])

agregarConector(s, ‘ConClienteServidor’, [‘CCS-R1’, ‘CCSR2’],

obtener(Puerto, cliente(0)) • obtener(Puerto,�servidor(0)) ,[])

delegarResponsabilidad(c, cliente(0))

delegarResponsabilidad(c, servidor(0))

eliminarComponente(c)

fin

φ = {aplicarClienteServidor(Componente_1)} <<componente>>

Componente_1

ConHTTP

<<componente>>

Cliente_1<<componente>>

Servidor_1

<<responsabilidad>>

IniciarConexión

<<responsabilidad>>

EnviarSolicitud

<<responsabilidad>>

AceptarConexión

<<responsabilidad>>

ResolverSolicitud

<<responsabilidad>>

EnviarRespuesta

<<responsabilidad>>

CerrarConexiónRol

Puerto

Conexión Puerto-Rol

Conector

m

aplicar (φ, m)


Representación de Razonamiento Arquitectónico

� Nuevo conjunto de tipos de objetos de diseño y sus operaciones que posibiliten la captura del razonamiento del proceso

� Definición de Operaciones Orientadas a Objetivos.

� Derivación en forma semi-automática de documentación de razonamiento, en base a la información del PDAS capturada

Modelo propuesto hasta aquí: posibilita la Representación de Conocimiento

� definición de tipos de objetos de diseño

� la definición de operaciones que encapsulan conocimiento arquitectónico

� la captura del proceso de diseño llevado a cabo (productos y operaciones ejecutadas para obtenerlos).

Resta proveer al modelo de los elementos que contribuyen a la explicación y razonamiento del PDAS desde el punto de vista del diseñador.

10


Incorporación de tipos de objetos de diseño relativos a Razonamiento Arquitectónico al dominio

RequerimientoDeCalidad

Restricción

RLimita

Argumento

RRechazaArg

Evaluación

RequerimientoFuncional

RReqSist

valortécnicaUtilizada

RSoportaArg

nombredescripciónnivelDeImportancia

nombredescripciónestímuloorigenDelEstímuloartefactoentornorespuestamedidaDeRespuestaestadoprioridad Requerimiento

nombredescripciónprioridadnombre

descripción

EscenarioDeCalidad

Sistema

ElementoArquitectónico

RReqCEsc

RNegocia

descripciónporcentajeReq1porcentajeReq2

estado

1

*

*

*

*

1

1

1

1

1

1

*

*

1

1

*

1

1

*

*

*

**

RRCER

RRCEE

RLR

RLEARAFEA

RAFA

RACA

RACEA

RRSS

RRSR

REEC

REEA

Algunos Tipos de Objetos de Diseño para la representación de Razonamiento Arquitectónico


Ejemplos de Operaciones para Análisis y Evaluación

agregarEscenarioDeCalidad(ne: Cadena,

rc: RequerimientoDeCalidad,

lProps: Colección[TipoDeDatoPrimitivo])

e := agregar(ne, EscenarioDeCalidad, lProps)

re := agregar(null, RReqCEsc, [])

agregarAsociación(re, e, RRCEE)

agregarAsociación(re, rc, RRCER)

fin

agregarEscenarioDeCalidad

• Permite agregar en una versión de modelo un escenario relativo a un requerimiento de calidad dado, a fin de traducir a éste en algo más concreto capaz de ser evaluado en una arquitectura de software.

11


Ejemplos de Operaciones para Análisis y Evaluación

evaluarEscenario(e: Escenario, nev:Cadena,

[valor: Cadena, técnicaUtilizada:Cadena],

lversiones:Colección[ElementoArquitectónico])

ev := agregar(nev, Evaluación, [valor, técnicaUtilizada])

agregarAsociación(ev, e, REEC)

para cada v en lversiones

agregarAsociación(ev, v, REEA)

fin para

fin

evaluarEscenario

• Trabaja con los resultados que pueden obtenerse mediante el empleo de técnicas de análisis o a partir de la experiencia de los diseñadores que estiman dichos resultados.

• Crea un objeto de tipo Evaluación, el cual se asocia al escenario que estábajo evaluación y a las versiones de objeto de los elementos arquitectónicos, en base a las que se hizo la evaluación.

• Conserva el valor de aproximación obtenido y la técnicaUtilizada.


Otros de tipos de objetos de diseño relativos a Razonamiento Arquitectónico

Restricción

Suposición

RConsideraRestricción

Evaluación

valortécnicaUtilizada

RRespetaSuposición

nombredescripciónnivelDeImportancia

nombredescripcióntipo

EscenarioDeCalidad

RPosibleSoluciónEscenario

*

1..*

*

ComponenteConector

Rol Puerto

Propiedad

Responsabilidad

Sistema

ElementoArquitectónico *

*

*

1

*

1

1*

nombredescripciónestímuloorigenDelEstímuloartefactoentornorespuestamedidaDeRespuestaestadoprioridad

RCRR

RCREA

REEC

REEA

RPSEEC

RPSEEA

RSS2

RSS1

12


Otras Operaciones

asignarPosibleSoluciónEscenario(e: EscenarioCalidad, nrel: Cadena,lversiones: Colección[ElementoArquitectónico],

lprops: Colección[TipoDeDatoPrimitivo])

aps := agregar(nrel, RPosibleSoluciónEscenario, lprops)

agregarAsociación(aps, e, RPSEEC)

para cada v en lversiones

agregarAsociación(aps, v, RPSEEA)

fin para

fin

Operaciones como éstas permiten expresar intenciones y/o objetivos del diseñador

Útiles para la definición de operaciones arquitectónicas Orientadas a Objetivos


Operaciones Orientadas a Objetivos

� Explicitar cuál es el objetivo perseguido por el arquitecto durante la ejecución de una operación

� Premisa: toda vez (o la mayoría de las veces) que un arquitecto considera la ejecución de una operación, tiene en mente cuál es el objetivo que está intentando alcanzar

� Para toda operación puede definirse una operación

alternativa orientada a objetivos: argumento extra que

indica el objetivo al cual apunta. aplicarIntermediario-oo(lComps1: Colección[Componente],

lConns: Colección[Conectores],

argObjetivo: RequerimientoDeCalidad)

lr := aplicarIntermediario(lComps1, lConns)

e := seleccionar(obtener(Escenario, argObjetivo))

asignarPosibleSoluciónEscenario(e, null, lr, [])

fin

13


Operaciones Orientadas a Objetivos

� Explicitar cuál es el objetivo perseguido por el arquitecto durante la ejecución de una operación

� Premisa: toda vez (o la mayoría de las veces) que un arquitecto considera la ejecución de una operación, tiene en mente cuál es el objetivo que está intentando alcanzar

� Para toda operación puede definirse una operación

alternativa orientada a objetivos: argumento extra que

indica el objetivo al cual apunta. aplicarIntermediario-oo(lComps1: Colección[Componente],

lConns: Colección[Conectores],

argObjetivo: RequerimientoDeCalidad)

lr := aplicarIntermediario(lComps1, lConns)

e := seleccionar(obtener(Escenario, argObjetivo))

asignarPosibleSoluciónEscenario(e, null, lr, [])

fin


Generación de un Objeto de Razonamiento Arquitectónico sobre Actividades de Diseño

� Secuencia de operaciones (actividad arquitectónica desarrollada por el arquitecto) � Materialización o concreción de una decisión de diseño compleja.

� HistoriaModelo: Captura una secuencia de operaciones ejecutada � Representa la decisión arquitectónica tomada por el arquitecto en un punto del proceso de diseño

DecisiónArquitectónica ≡ HistoriaModelo

14



1..*

Pertenece

predecesora*

*

VersiónDeObjetosucesora

argumento

successor

*VersiónDeModelo

*

HistoriaVersiónHistoriaModelo

Explica

RazonamientoArquitectónico

requerimientosElicitados

escenariosPerseguido

suposicionesrestriccionesConsideradas

restriccionesImpuestas

implicaciones

argumentosAFavor

argumentosEnContra

informaciónAdicional

actor

fecha

resultado

Operación

*

0..1

1

0..1

Representa una Decisión

Arquitectónica

Documenta el Razonamiento Arquitectónico de una

evolución de la arquitectura



1..*

Pertenece

predecesora

VersiónDeObjeto

sucesora

successor

0..1

*

VersiónDeModelo

*

HistoriaVersión

HistoriaModelo

Explica


actor

fecha

Operación

1..*

0..1

1

ItemDeRazonamiento

respuesta

RazonamientoArquitectónicoPlantilla ItemDeRazonamientoPlantilla


relaciónReificada

*

DominioProyecto1*

1

1

*

*

descripción

nombre

*argumento

resultado

*

*

*

*

1

*

1*

descripción

derivarRazonamientoArquitec-

tónico()

Plantilla de Razonamiento que

posibilita la generación del

Objeto de Razonamiento en

forma Semiautomática

15



1..*

Pertenece

predecesora

VersiónDeObjeto

sucesora

successor

0..1*

VersiónDeModelo

*

HistoriaVersión

HistoriaModelo

Explica


actor

fecha

Operación

1..*

0..1

1

ItemDeRazonamiento

respuesta

RazonamientoArquitectónicoPlantilla ItemDeRazonamientoPlantilla


relaciónReificada

*

DominioProyecto1*

1

1

*

*

descripción

nombre

*argumento

resultado

*

*

*

*

1

*

1*

descripción

derivarRazonamientoArquitec-

tónico()

Mecanismo para generación de objetos

Razonamiento Arquitectónico


Herramienta TracED: Editor de Dominios

16


TracED – Definición de Tipos de Objetos de diseño


TracED – Administrador de Versiones

Las operaciones definidas en el dominio seleccionado

para el proyecto, son ofrecidas en un menú y

agrupadas según el tipo de objeto de diseño al que se

aplican

Caso de Estudio:Diseño de la Arquitectura de Struts

(Framework para desarrollo de Aplicaciones Web)

17


TracED: Administrador de Versiones


TracED: Administrador de Versiones<<sistema>>

Struts

<<componenteCliente>>Navegador

<<componenteServidor>>

ServidorWeb

Modelo Inferido 4

Modelo Inferido 5

<<sistema>>Struts

<<componenteVista>>Vista

<<componenteModelo>>Modelo

<<componenteControlador>>

Controlador

<<componenteCliente>>

Navegador

φ6= {aplicarMVC(V1ServidorWeb)} ConModVis

ConModCtrlrConVisCtrlr

18


TracED: Historia de una Versión de Modelo

De qué manera se alcanzóla Versión de Modelo 4?

Quiénes fueron los actores involucrados?

Cuáles son los resultados o productos de una operación

ejecutada?

Enumera todas las secuencias de operaciones ejecutadas partiendo de la Versión de

Modelo Inicial

Cuáles son las operaciones de una cierta secuencia de

operaciones aplicada?


Conclusiones

Modelo capaz de capturar los productos del diseño y las operaciones que los generaron, con el objetivo de expresar el razonamiento aplicado.

A diferencia de las propuestas existentes para documentación de Razonamiento de Diseño que construyen el razonamiento en una etapa posterior al diseño, el modelo propuesto permite hacerlo durante el proceso de diseño mismo.

Modelo de Dominio: representación de los tipos de objetos de diseño. Permite definición de dominios con diferentes grados de granularidad y la especialización de los tipos de objeto de diseño incluidos.

Modelo de Operaciones: especificación y ejecución de operaciones arquitectónicas con diferentes niveles de abstracción.

19


Conclusiones

Identificación de conceptos de razonamiento arquitectónico y la definición de las operaciones aplicables a los mismos.

Definición de operaciones orientadas a objetivos: permiten reflejar en el modelo arquitectónico las consideraciones e intenciones del diseñador al ejecutar la operación;

Definición de un mecanismo para derivación de razonamiento arquitectónico

Desarrollo del prototipo TracED que implementa el modelo propuesto.


Muchas Gracias!

Representación de Conocimiento y Razonamiento en el...

Documents

Transcript of Representación de Conocimiento y Razonamiento en el...