Patterns of agents Massimo Cossentino Massimo Cossentino, Luca Sabatucci ICAR/CNR High performance computing and networks institute Italian National Research.

Slides:



Advertisements
Similar presentations
GenArch: Automatic Product Derivation in Multi-agent Systems Product Line Elder Cirilo.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Design Patterns Examples of smart use of inheritance and polymorphism: Composite Pattern State Pattern FEN 2014UCN Teknologi/act2learn1.
Introduction To System Analysis and Design
Developing MAS The GAIA Methodology A Brief Summary by António Castro and Prof. Eugénio Oliveira.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
NaLIX: A Generic Natural Language Search Environment for XML Data Presented by: Erik Mathisen 02/12/2008.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
© Copyright Eliyahu Brutman Programming Techniques Course.
Design Patterns Ref : Chapter 15 Bennett et al. useful groups of collaborating classes that provide a solution to commonly occuring problems. provide.
PRESENTED BY SANGEETA MEHTA EECS810 UNIVERSITY OF KANSAS OCTOBER 2008 Design Patterns.
Şabloane de Proiectare Daniel POP, Ph.D. 2 The Plan Introducing fundamental patterns (today) 18 design patterns will be covered based on the case study.
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
Design Patterns Discussion of pages: xi-11 Sections: Preface, Forward, Chapter
ICT Management page 1MBA BORM - BORM © - Business Object Relation Modeling Know-How Fund of British Council, ČVUT v Praze, ČZU Praha,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
1 Copyright © 2014 Atego. Patterns INCOSE MBSE WG – Simon A. Perry - Atego.
TC Methodology Massimo Cossentino (Italian National Research Council) Radovan Cervenka (Whitestein Technologies)
An Introduction to Software Architecture
05 - Patterns Intro.CSC4071 Design Patterns Designing good and reusable OO software is hard. –Mix of specific + general –Impossible to get it right the.
Spoken dialog for e-learning supported by domain ontologies Dario Bianchi, Monica Mordonini and Agostino Poggi Dipartimento di Ingegneria dell’Informazione.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Experiences from a standardization attempt in AO methodologies Massimo Cossentino (Italian National Research Council)
Introduction To System Analysis and Design
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 27. Review UML dynamic view – State Diagrams.
Odyssey A Reuse Environment based on Domain Models Prepared By: Mahmud Gabareen Eliad Cohen.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Object-Oriented Design Principles and Patterns. © 2005, James R. Vallino2 How Do You Design? What principles guide you when you create a design? What.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
Design Principle & Patterns by A.Surasit Samaisut Copyrights : All Rights Reserved.
ECE450S – Software Engineering II
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Copyright © Active Frameworks Inc. - All Rights Reserved - V2.0Design Pattern Catalog - Page L3-1 PS95&96-MEF-L10-1 Dr. M.E. Fayad Creationa.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
Design Patterns: Elements of Reusable Object- Orientated Software Gamma, Helm, Johnson, Vlissides Presented By: David Williams.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Object-Oriented Parsing and Transformation Kenneth Baclawski Northeastern University Scott A. DeLoach Air Force Institute of Technology Mieczyslaw Kokar.
Class Diagrams. Terms and Concepts A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Class Relationships Lecture Oo08 Polymorphism. References n Booch, et al, The Unified Modeling Language User Guide, Chapt 10 p.125 n Fowler & Scott, UML.
1 Good Object-Oriented Design Dr. Radu Marinescu Lecture 4 Introduction to Design Patterns.
Basic Characteristics of Object-Oriented Systems
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
Design Patterns CSCE 315 – Programming Studio Spring 2013.
GRASP – Designing Objects with Responsibilities
Design Patterns: MORE Examples
Design Patterns: Brief Examples
Software Design Patterns
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Design Patterns Introduction
Unified Modeling Language
OO Methodology OO Architecture.
Abstract descriptions of systems whose requirements are being analysed
An Introduction to Software Architecture
DESIGN PATTERNS : Introduction
Copyright 2007 Oxford Consulting, Ltd
CS 8532: Advanced Software Engineering
PASSI (Process for Agent Societies Specification and Implementation)
From Use Cases to Implementation
Presentation transcript:

Patterns of agents Massimo Cossentino Massimo Cossentino, Luca Sabatucci ICAR/CNR High performance computing and networks institute Italian National Research Council

The Goal of This Work We aim to drastically affect the cost of developing a multi-agent application. But… it is not easy to achieve this goal without simplifying the problem. We decided of using FIPA-compliant platforms and this reduces effectively the dimension of the problem (almost all of these platforms are JAVA-based and have a similar structure). By now we refer to two different platforms: FIPA-OS and JADE

Difference in implementing a simple agent behavior in FIPA-OS and JADE FIPA-OS JADE FIPA-OS JADE Different use of the done method in the two platforms Same structure of behaviors but different name of methods Constructor and setup method in both the platforms Shutdown method in FIPA-OS only

What is a pattern Christopher Alexander* definition: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” *C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl- King, and S. Angel. A pattern language. Oxford Univ. Press, New York, 1977

OO Patterns classification E. Gamma and R. Helm and R. Johnson and J. Vlissides - "Design Patterns Elements of Reusable Object Oriented Software“ - "Addison-Wesley", 1994 According to Gamma *, patterns can be classified using two criteria: Purpose: what the pattern does. They can belong to the following categories: creational (dealing with the process of object creation), structural (dealing with the composition of classes and objects) or behavioural (describing the interactions of classes/objects) patterns. Scope: classification is directed to separate patterns that apply to classes or object. Class patterns deal with the relationships among classes (usually structural, for example inheritance), Object patterns include relationships among object (usually dynamic and established at runtime).

AO patterns classification Lind 1 classifies agent-oriented patterns in accordance to the views defined by the author in the MASSIVE methodology.  Categories reported in this work are: Interaction, Role, Architecture, Society, System, Task, and Environment. Aridor 2 clusters patterns in these categories:  traveling (dealing with agent mobility issues),  task (regarding the breakdown of agents tasks and the delegation of them from one agent to another)  interaction (dealing with agents communications) categories. (1) Jurgen Lind, "Patterns in Agent-Oriented Software Engineering", in Proc. Of AOSE Workshop at AAMAS July 2002, Bologna(Italy) (2) Y. Aridor and D. B. Lange, "Agent Design Patterns: Elements of Agent Application Design", in Proc. Of the Autonomous Agents '98 Conf., 1998.

Our concept of patterns We consider a pattern of agent as composed of its design level description and the corresponding JAVA code. More in detail each pattern is composed of:  A structure Usually a base agent class and a set of task/behavior classes. Described using UML class diagrams  A behavior Expressed by the agent using its structural elements Detailed in UML dynamic diagrams (activity/state chart diagrams)  A portion of code Some lines of code implementing the structure and behavior described in the previous diagram

The proposed AO classification We think that:  the basic duality (structure/dynamics) that exists in software is captured by the Gamma's approach  we also consider the importance of enriching it in order to fit the specific context (agents not objects). We classify the patterns using two main criteria (like in Gamma et al.) and include agent specific subcategories in them. Classification Criteria:  Application context: it regards the structural aspects of the pattern, whether it is to be applied to one agent, more agents or to their composing elements (tasks/behaviors).  Functionality: it regards the functional/behavioral aspects of the pattern.

Application Context patterns category Sub-categories: Action patterns. They address a functionality of the system; for instance they can be implemented as a method of either an agent class or a task class. Behavior patterns. They address a specific behavior of an agent; we can look at each of them as a collection of actions. Component patterns. They are entire agent patterns; these patterns propose a solution composed of the entire structure of an agent together with its tasks. Service pattern. Concerned about the collaborations between two or more agents; they can be thought as an aggregation of component patterns.

Functionality patterns category Sub-categories: Access to local resources. They deal with information retrieval and manipulation of data source. Communication. They represent the solution to the problem of making two agents communicate by an interaction protocol. Elaboration. They are used to deal with the agent's functionality devoted to perform some kind of elaboration on its knowledge. Mobility. These patterns describe the possibility for an agent to move from a platform to another

Patterns in our repository

Patterns documentation Name  The name of the pattern Classification  The classification of the pattern according to the categories reported in the previous slides Intent  A description of what the pattern does and its rationale and intent Motivation  A scenario that illustrates a design problem and how the agents and their tasks in the pattern solve the problem. Pre-conditions  The initial situation in which the pattern can be applied. Post-conditions  The consequences of the application of the pattern: what changes the pattern introduces into the system Structure  A graphical representation of the structure of the agent and its tasks (usually done with a class diagram)

Patterns documentation Participants  A description of the agents involved in the pattern and their roles Collaborations  A (graphical) representation of the collaborations of the agents involved in the pattern (if any) Implementation availability  Availability of the implementation code for the FIPA-OS/JADE platforms. Availability of the UML diagrams of the solution (XMI) for importing them in the existing system design Implementation description  Comments on the most significant code fragments to illustrate the pattern implementation in the specific agent platforms Implementation Code  FIPA-OS/JADE code of the solution Related Patterns  Patterns that should be used in conjunction with this one

The phases of the pattern production/reuse process Meta-pattern XSLT platform specialization XSL rules pattern constraints resolver Constraints + Java skeleton Action pattern Java agent complete code Class Diagram(s) Activity Diagram XSLT Multi-Platform RepresentationPlatform-Specific Representation Design Representation UMLXMLJAVA

The design level representation of the pattern Meta-pattern XSLT platform specialization XSL rules pattern constraints resolver Constraints + Java skeleton Action pattern Java agent complete code Class Diagram(s) Activity Diagram Design Representation UML XSLT Design level representation of the pattern using UML class and activity diagrams … QueryReceiveTask

The XML meta-pattern representation Meta-pattern XSLT platform specialization XSL rules pattern constraints resolver Constraints + Java skeleton Action pattern Java agent complete code Class Diagram(s) Activity Diagram Design Representation UML XSLT Meta-patterns are platform independent Meta-patterns contain all the common elements of patterns for different MA platforms … Multi-Platform Representation XML public public public

From meta-patterns to patterns – XSL rules Meta-pattern XSLT platform specialization XSL rules pattern constraints resolver Constraints + Java skeleton Action pattern Java agent complete code Class Diagram(s) Activity Diagram Design Representation UML XSLT Each pattern is specific for one of the selected platforms. In order to obtain a FIPA-OS pattern we apply to the meta- pattern the XSLT transformation shown on the right … FIPAOSAgent public private … Multi-Platform Representation XML

From meta-patterns to patterns Meta-pattern XSLT platform specialization XSL rules pattern constraints resolver Constraints + Java skeleton Action pattern Java agent complete code Class Diagram(s) Activity Diagram Design Representation UML XSLT The resulting pattern is localized to a specific platform The pattern is still general and can be customized for the specific application … Multi-Platform Representation XML Meta-pattern Pattern XSL Transformation public FIPAOSAgent public public …

Patterns introduction in the project generates constraints When a pattern is applied to a project, it modifies the context in which it is placed (introducing new functionality into the system) The relationship between the pattern and existing elements could be expressed with a constraint. A constraint is a rule composed of three elements:  A target that specifies what agent/task will be influenced by the rule.  A platform that specifies which is the application context (FIPA-OS or JADE)  A content that expresses the changes to be applied when the pattern is inserted into the project (it could be an aggregation of attributes, constructors or methods). An example in FIPA-OS:  When we insert a communication task pattern into an existing agent, the listener task (IdleTask) should have a handleX method to catch performative acts of a particular type (i.e. QueryIf, Request, Inform, …)

Constraints Meta-pattern XSLT platform specialization XSL rules pattern constraints resolver Constraints + Java skeleton Action pattern Java agent complete code Class Diagram(s) Activity Diagram XSLT … Multi-Platform RepresentationPlatform-Specific Representation Design Representation UMLXMLJAVA From the previous example: here we have the constraint used to introduce the handleQueryIf method in the IdleTask class of a FIPA-OS agent public a_function …

From skeleton of classes to complete code With the previous steps we obtained a skeleton of the agent with its tasks/behaviors that is complete down to the method interfaces of each class In order to (partially) fill the skeleton with the remaining code, action patterns are applied. An action pattern is a portion of JAVA code realizing some kind of behavior. It is specific for each platform.  For example the registration to the DF service (Directory Facilitator, the yellow pages of the platform) it is part of the action pattern and it is introduced in the setup method of the agent Action patterns are stored in a database of pieces of code and the correct one for each method is selected referring to the value of the Code tag for the specific module (see the XML pattern representation)

Constraints Meta-pattern XSLT platform specialization XSL rules pattern constraints resolver Constraints + Java skeleton Action pattern Java agent complete code Class Diagram(s) Activity Diagram XSLT try { registerWithDF( AGENT_TYPE ); DIAGNOSTICS.println("Registered with DF", this,DIAGNOSTICS.LEVEL_MAX ); } catch (DFRegistrationException dfre) { DIAGNOSTICS.println(dfre, this, DIAGNOSTICS.LEVEL_MAX ); String reason = dfre.getExceptionReason(); if ( reason == null || !reason.equals(FIPAMANCONSTANTS. AGENT_ALREADY_REGISTERED) ) { shutdown(); return; } } … The action pattern for the setup method of a generic FIPA-OS agent Multi-Platform RepresentationPlatform-Specific Representation Design Representation UMLXMLJAVA

The AgentFactory web application

Screenshots Create a new multi agent system Select the agent platform (FIPA-OS or Agent)

Screenshots Add a component pattern to the MAS Select the Generic Agent pattern

Screenshots Static, dynamic structure of the pattern and tree representation of the system

Screenshots Add a behaviour pattern to ‘myTask’ Select the FIPA Query Initiator pattern

Screenshots Static structure of the FIPA Query Initiator pattern Select the previously created agent from the list

Screenshots The result of the pattern application: the agent structure, the automatically generated code…

Screenshots … the static structure and the dynamic behavior

Conclusions and future works

Experimental results are encouraging but the amount of code automatically produced depends on the dimension of the pattern repository It is difficult to synchronize the DB of patterns for many different platforms An high level representation of patterns is needed in order to facilitate reuse in early stages of design processes