representación de conocimiento y razonamiento en el...
Post on 07-Oct-2020
7 Views
Preview:
TRANSCRIPT
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
3Seminarios PAE – CELTIC - 2009
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
4Seminarios PAE – CELTIC - 2009
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
5Seminarios PAE – CELTIC - 2009
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
6Seminarios PAE – CELTIC - 2009
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
7Seminarios PAE – CELTIC - 2009
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)
8Seminarios PAE – CELTIC - 2009
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
Esquema para la Administración de Versiones
Los productos del diseño son denominados Objetos de
Diseño
Doble representación:
-Nivel Versiones:
Versiones de Objeto
-Nivel Repositorio:
-Objetos Versionables
5
9Seminarios PAE – CELTIC - 2009
Esquema para la Administración de Versiones
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
10Seminarios PAE – CELTIC - 2009
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
11Seminarios PAE – CELTIC - 2009
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
12Seminarios PAE – CELTIC - 2009
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
13Seminarios PAE – CELTIC - 2009
Modelo de Operaciones
TipoDeObjetoDeDiseño
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
14Seminarios PAE – CELTIC - 2009
Modelo de Operaciones
TipoDeObjetoDeDiseño
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
Tipos de datos manejados en el modelo
para la argumentos
8
15Seminarios PAE – CELTIC - 2009
Modelo de Operaciones
TipoDeObjetoDeDiseño
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
Predefinidas en el Modelo.
Posibilitan la construcción de
operaciones complejas
16Seminarios PAE – CELTIC - 2009
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
17Seminarios PAE – CELTIC - 2009
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)
18Seminarios PAE – CELTIC - 2009
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
19Seminarios PAE – CELTIC - 2009
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
20Seminarios PAE – CELTIC - 2009
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
21Seminarios PAE – CELTIC - 2009
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.
22Seminarios PAE – CELTIC - 2009
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
23Seminarios PAE – CELTIC - 2009
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
24Seminarios PAE – CELTIC - 2009
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
25Seminarios PAE – CELTIC - 2009
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
26Seminarios PAE – CELTIC - 2009
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
27Seminarios PAE – CELTIC - 2009
Generación de un Objeto de Razonamiento Arquitectónico sobre Actividades de Diseño
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
28Seminarios PAE – CELTIC - 2009
Generación de un Objeto de Razonamiento Arquitectónico sobre Actividades de Diseño
1..*
Pertenece
predecesora
VersiónDeObjeto
sucesora
successor
0..1
*
VersiónDeModelo
*
HistoriaVersión
HistoriaModelo
Explica
RazonamientoArquitectónico
actor
fecha
Operación
1..*
0..1
1
ItemDeRazonamiento
respuesta
RazonamientoArquitectónicoPlantilla ItemDeRazonamientoPlantilla
TipoDeObjetoDeDiseño
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
29Seminarios PAE – CELTIC - 2009
Generación de un Objeto de Razonamiento Arquitectónico sobre Actividades de Diseño
1..*
Pertenece
predecesora
VersiónDeObjeto
sucesora
successor
0..1*
VersiónDeModelo
*
HistoriaVersión
HistoriaModelo
Explica
RazonamientoArquitectónico
actor
fecha
Operación
1..*
0..1
1
ItemDeRazonamiento
respuesta
RazonamientoArquitectónicoPlantilla ItemDeRazonamientoPlantilla
TipoDeObjetoDeDiseño
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
30Seminarios PAE – CELTIC - 2009
Herramienta TracED: Editor de Dominios
16
31Seminarios PAE – CELTIC - 2009
TracED – Definición de Tipos de Objetos de diseño
32Seminarios PAE – CELTIC - 2009
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
33Seminarios PAE – CELTIC - 2009
TracED: Administrador de Versiones
34Seminarios PAE – CELTIC - 2009
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
35Seminarios PAE – CELTIC - 2009
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?
36Seminarios PAE – CELTIC - 2009
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
37Seminarios PAE – CELTIC - 2009
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.
38Seminarios PAE – CELTIC - 2009
Muchas Gracias!
top related