Al igual que con los escenarios, esperaramos tener slo un conjunto representativo de diagramas de interaccin,no es un juego completo. Con el fin de tener interacciones completas y definidas con precisin,

progresamos de diagramas de interaccin con los protocolos que definen exactamente qu interaccinsecuencias son vlidas dentro del sistema. Debido a que los protocolos deben mostrar todas las variaciones, que son a menudo ms grande que el diagrama de interaccin correspondiente y pueden necesitar ser dividido en trozos ms pequeos.Con el fin de dar un ejemplo de desarrollo de un protocolo de interaccin completa, necesita una notacin para describir los protocolos de interaccin. Desde protocolos de interaccin incluyen secuenciacin, opciones, iteracin y otras estructuras de control, la notacin tiene que ser bastante expresivo. Existe una serie de anotaciones para los protocolos que describen incluyendo la actividad UML diagramas, AUML (Agente UML) (Odell et al., 2000), y las redes de Petri (por ejemplo (Coste et al. 1999; Nowostawski et al. 2001; Poutakidis et al. 2002)). Vamos a utilizar la versin revisada versin del Agente de UML, (Huget et al., 2003) actualmente en desarrollo.Protocolos en desarrollo se realiza considerando alternativas. Para cada mensaje (o percepcin) que un agente recibe, nos preguntamos 'cules son los posibles mensajes que el agente pudiera 76 DISEO ARQUITECTNICO: Especificacin del INTERACCIONES enviaremos como respuesta? ', entonces Repetimos el proceso para estos mensajes. De manera ms general, que preguntan 'cules son las posibles continuaciones (es decir, secuencias de mensajes)?' En algunos casos, las alternativas se describen mejor en trminos de paralelismo o bucle. Por ejemplo, si un diagrama de interaccin muestra mensaje m1 seguido por m2 y una alternativa es que m2 se enva primero seguido por m1, entonces podramos describir esto como una alternativa, pero es ms fcil de decir que los dos mensajes se envan en paralelo.Por ejemplo, considere un protocolo de tarjeta de crdito, cheques implica un comerciante y un banco. El protocolo comienza con el comerciante de enviar al banco una solicitud de tarjeta de crdito mensaje. El banco va a responder a esto con una solicitud de datos de la tarjeta; no hay alternativa respuestas. El comerciante, al recibir la solicitud de datos de la tarjeta, responder con la Datos de la tarjeta; de nuevo no hay respuestas alternativas. Cuando el banco recibe la tarjeta detalles, puede responder con una serie de posibles mensajes. Una posibilidad es responder con un Aprobar. Otra posibilidad es responder con una Rechazar. Por ltimo, en algunos casos, el banco responder tanto con un mensaje de rechazo (al comerciante) y tambin un fraude mensaje. Figura 6.5 muestra este protocolo. Tenga en cuenta que el envo de rechazo y fraude puede ocurrir en cualquier orden o simultneamente.Al considerar las posibles alternativas, una fuente de posibilidades es el campo de variacin de los escenarios de casos de uso. Otra fuente de posibilidades es diferentes escenarios de casos de uso.A menudo, habr varios escenarios que se relacionan con los mismos conceptos. Para ejemplo, un escenario que podra mostrar lo que ocurre cuando un cliente pide un libro que est en stock y otro escenario podra mostrar lo que ocurre cuando un cliente pide un fuera de stock libro. Desde protocolos de interaccin estn destinadas a cubrir todas las posibilidades, considerara ambos escenarios de casos de uso como alternativas en una sola interaccin protocol.teractions,