Tropos: - Ingeniería de Sistemas | Pontificia Universidad Javeriana

Metodología de Ingeniería de Software para POA a nivel
de conocimiento
Tropos:
La POA está motivada por la necesidad de tener arquitecturas abiertas que puedan
evolucionar ante nuevos requerimientos, puedan operar en diferentes plataformas sin
recompilación y con suposiciones mínimas acerca de su ambiente operativo.
Para implementar sistemas en los que se encuentren las características que identifican a
un agente, se debe programar a nivel de conocimiento.
Las nociones mentales proveen en parte los elementos necesarios para crear software
flexible que se acomode a las necesidades de sistemas complejos, dado que la
representación y el manejo de planes y objetivos permite adaptarse al comportamiento
requerido por el sistema y a llevar a cabo interacciones con otros agentes.
Tropos está basado en dos ideas principales:

Noción de agente y sus estados mentales relacionados, para ser usados durante
todo el proceso de desarrollo de software.

Cubre la etapa de análisis de requerimientos para tener un conocimiento del
ambiente en el cual se va a desempeñar el sistema, y de las interacciones que
deben ocurrir entre los agentes. Es crucial tener en cuenta realizar el
modelamiento de casos de uso y un buen diseño.
Se tienen cinco fases a seguir en la metodología:

Análisis temprano de requerimientos: Entendimiento del problema. Se obtiene un
modelo organizacional en el cual se incluyen los actores relevantes y sus
dependencias. Cada actor tiene sus objetivos que serán logrados en conjunto en
virtud de conocimientos y dependencias reciprocas, por medio de las cuales se
distribuirán tareas y de hará una utilización correcta de los recursos.
En esta etapa el análisis de los objetivos de los usuarios del futuro sistema
conduce a obtener los requerimientos funcionales y no funcionales. Se obtienen
dos clases de diagramas; los diagramas de actores (agente, rol, posición) que
muestran una red de dependencias sociales de manera general, y los diagramas de
racionalidad, en los cuales se hace un análisis de los objetivos (descomposición
en sub-objetivos) que se establecieron para cada uno de los actores del diagrama
anterior. Por medio de este análisis se pueden añadir más actores y dependencias.

Análisis de requerimientos tardíos: El sistema que se quiere obtener es descrito en
su ambiente operacional con sus funciones y cualidades. Sistema es un conjunto
pequeño de actores con dependencias sociales. En el análisis realizado se puede
hacer una descomposición en sub - actores y sub – objetivos. Se logra mostrar un
análisis de casos de uso, ya que en el diagrama de racionalidad se muestra la
manera en la que el objetivo de un actor puede ser cumplido por medio del
sistema.

Diseño arquitectural: Arquitectura definida en términos de subsistemas (actores),
interconectados a través de datos y flujos de control (dependencias). Se definen
las capacidades de los agentes y los tipos de agentes (donde los agentes son una
clase especial de actores). Se termina con la especificación de los agentes del
sistema. Lo anterior se logra por medio del análisis detallado del diagrama
extendido de actores.

Diseño detallado: Cada agente de la arquitectura es definido en términos de
eventos internos y externos, planes, creencias y protocolos de comunicación. La
especificación de las capacidades es importante para modelar los eventos internos
y externos que motivan los planes y creencias envueltas en el razonamiento de los
agentes. Para este diseño, se pueden adaptar algunos diagramas propuestos para
diseñar agentes y SMA, entre los cuales se tienen algunos de los propuestos por
AUML: Diagramas de Capacidad, Diagramas de planes, Diagramas de
Interacción de Agentes. (En esta etapa podemos sugerir una arquitectura para los
agentes, basándonos en diferentes ideas que hemos visto, como Wooldridge, gnets, Ferber).

Implementación: Implementación del sistema con un lenguaje especializado para
agentes, en donde se tenga coherencia con el diseño detallado.
El modelo para ingeniería de requerimientos que se adoptó en esta metodología esta
basado en el de Eric Yu, el cual se llama i*. La idea es entender la manera en la que el
sistema debe cumplir los objetivos del sistema, antes de hacer la especificación de los
mismos. En i* se mira a los actores, objetivos y dependencias entre los actores como
conceptos primitivos.
La motivación es la de crear un marco para modelar procesos que envuelven múltiples
participantes, de manera que no sólo se explique el como y el que tiene que hacer el
sistema y los usuarios que interactúan con él, sino el porque se desarrolla un software.
Así se puede hacer un análisis más detallado de las dependencias en el sistema y un trato
de los requerimientos tanto funcionales y no funcionales del sistema. Lo anterior conlleva
a elaborar un software lo suficientemente flexible para manejar la complejidad del
sistema.
Se deben especificar las conexiones entre las intenciones de los agentes (software y
humanos).