1. Dealing with the challenges © H. Mouratidis 1 Better processes  Faster development  Light methods Better models  Abstractions  Architectures  Components Agile Development Agent Oriented Software Engineering

2. Software Engineering Challenge The challenge  Better models  Abstractions  Architectures  Components The solution  Agent Oriented Software Engineering?? 2 © H. Mouratidis

3. Agent Oriented Software Engineering Agent Oriented Software Engineering (AOSE) introduces an alternative approach in analysing and designing complex distributed computerised systems, according to which a complex computerised system is viewed as a multiagent system in which a collection of autonomous software agents interact with each other in order to satisfy their design objectives 3 © H. Mouratidis

4. What is an agent? No standard definition!!! At least two reasons why it is difficult to define precisely what a software agent is [Nwana, 1996]  A term used widely outside the research community  A software agent can play many roles (navigate, search, personal assistants) 4 © H. Mouratidis

5. Wooldridge & Jennings (Wooldridge, 1995) Definition A hardware or (more usually) software based computer system that enjoys the following properties:  Autonomy  Agents operate without the direct intervention of humans or others, and have some kind of control over their actions and internal state  Social Ability  Agents interact with other agents (and possibly humans) via some kind of agent communication language  Reactivity  Agents perceive their environment, (which may be the physical world, such as a user via a graphical user interface, a collection of other agents etc), and respond in a timely fashion to changes that occur in it  Pro-activeness  Agents do not simply act in response to their environment, they are able to exhibit goal directed behaviour by taking the initiative 5 © H. Mouratidis

6. IBM definition (Franklin, 1996) Intelligent agents are software entities that carry out some set of operations on behalf of a user or another program with some degree of independence or autonomy, and in doing so, employ some knowledge or representation of the user’s goals or desires 6 © H. Mouratidis

7. Multiagent Systems The true power of the agent paradigm is realised from the use of multiagent systems. Contain more than one agent A task is divided into a set of subtasks and distributed amongst the different agents of the system 7 © H. Mouratidis

8. Few Types of agents Many different ways to classify agents  According to tasks they perform  Information gathering  Information filtering  Personal assistants  According to their properties  Intelligent Demonstrates some kind of intelligence  Learning Changes its behaviour according to previous experience  Mobile Able to transport itself from one machine to another 8 © H. Mouratidis

9. Agents versus Objects Objects are inactive most of the time and become active only when another object requires their services. In contrast, a software agent is continually active, sensing its environment and selecting the actions to perform The object paradigm does not address issues like cooperation, competition, negotiation and so on, which form the foundation for multi-agent systems development Agents are able to judge their results and modify their behaviour (their internal structure) according to these results and their goals, while objects are not able of doing so In objects, messages are method invocations while agents define different types of messages and use complex protocols to negotiate For objects to communicate, “public” methods are used. Any other object has the right to invoke a public method from any object that contains one. In contrast an agent can decide if it will perform an action (method) that belongs to it or not. 9 © H. Mouratidis

10. Applications of agent technology Many different applications From military  Military is testing software robots that can identify targets and present them to commanders much more quickly than a human could. The robots use software intelligent agents to sift through troves of images and intelligence data to find viable targets To health care sector  The eSAP project at the university of Sheffield, looked at how agents can be used to act on behalf of doctors, nurses, patients To NASA  NASA are seriously investigating the possibility of making probes more autonomous — giving them richer decision making capabilities and responsibilities. DS1 probe tracks its progress, and decides how to deal with unexpected eventualities. 10 © H. Mouratidis

11. Returning to AOSE “…a complex computerised system is viewed as a multiagent system, in which a collection of autonomous software agents interact with each other in order to satisfy their objectives” When designing a multiagent system “View the system as a society, similar to a human society, consisting of entities that possess characteristics similar to humans such as mobility, intelligence and the capability of communicating” (Mouratidis, 2003) 11 © H. Mouratidis

12. The arguments for the use of AOSE Too early to say that AOSE will become widely successful AOSE will be of benefit for engineering certain complex software systems (Jennings)  The effectiveness of agent oriented decompositions in partitioning the problem space of a complex system  The suitability of the key abstractions, such as agents, interactions, and organisations, in modelling complex systems  The appropriateness of the agent oriented philosophy for dealing with dependencies and the interactions that exist in a complex system 12 © H. Mouratidis

13. What makes AOSE distinct from other paradigms? The higher level of abstraction employed in the development of software systems “The idea of modelling a system in terms of autonomous entities with characteristics similar to humans introduces a close-to-real-life modelling of the system, and therefore makes the development of the software system natural” (Mouratidis, 2004) 13 © H. Mouratidis

14. AOSE methodologies Can current methodologies (which are customised to different paradigms -such as OO) be used as agent oriented software engineering methodologies?  Current methodologies are based on software engineering rules and ideas…so they can be used  The different characteristics of each paradigm must be taken into consideration…so they cannot be used!  Not a simple answer!!! 14 © H. Mouratidis

15. Reasons for justify OO methodologies According to Iglesias (Iglesias, 1999)  Similarities between the main two concepts  Common usage of object oriented languages (e.g. JAVA)  Familiarity of many software engineers with object oriented methodologies  Both emphasize the importance of interactions between the entities of the system 15 © H. Mouratidis

16. Shortcomings of extending OO methodologies The level of abstraction and the models provided by OO are not adequate to model agent characteristics  Autonomous, have intentions Not adequate set of concepts and mechanisms for complex systems “… for complex system we find that objects, classes and modules provide an essential yet insufficient means of abstraction” (Booch, 1994) 16 © H. Mouratidis

17. Shortcomings of OO methodologies The object model fails to capture the dynamic nature of the interactions between the agents Fail to capture the social behaviour of agents Fail to model the mental states (goals, tasks, capabilities) of the agents of the system So? Can we use them? Agent Oriented methodologies are necessary but the work on them can adopt, where suitable, existing methods and take advantage of the work done so far 17 © H. Mouratidis

18. AOSE now Agent systems development is currently dominated by informal guidelines rather than formal principles and well-defined engineering techniques Very few formalized techniques exist to support different stages of AOSE AOSE is still in its infancy 18 © H. Mouratidis

19. Some AOSE methodologies GAIA  Jennings (Southampton), Wooldridge (Liverpool), Zambonelli (Modena) MaSE  Scott A. Deloach (Kansas) Tropos  Mylopoulos (Toronto), Giorgini (Trento), Mouratidis (UEL) 19 © H. Mouratidis

20. GAIA One of the first methodologies specifically tailored to the analysis and design of agent-based systems. It views the requirements phase as separate of the analysis and design phase. Requirements Statement Roles Model Interactions Model Agent ModelServices Model Acquaintance Model Analysi s Desig n 20 © H. Mouratidis

21. MaSE It provides support for generating code using the MaSE code generation tool. the general components of the system are designed before the system itself is actually defined. UML diagrams have been modified in order to model notions of agents as well as their cooperative behaviour. Domain Level Design Agent Level Design Component Design System Design Star t End 21 © H. Mouratidis

22. Tropos The most important feature of Tropos is that it aspires to span the overall software development process, from the early requirements to implementation Uses concepts such as actors, goals, tasks, resources and social dependencies that define obligations from one actor to another 22 © H. Mouratidis

23. Tropos stages Early requirements: identify domain stakeholders and model them as social actors who depend on each other. Possible to state the why! Late requirements: Model the dependencies of the system with other actors (functional and non-functional requirements) Architectural Design: define the system’s architecture and identify the agents of the system Detailed Design: Specify agent capabilities and interactions Early Requirements Late Requirements Architectural Design Detailed Design Star t End 23 © H. Mouratidis

24. Pitfalls of agent development (Wooldridge, 2004) You oversell agent solutions, or fail to understand where agents might be usefully applied  Do not understand its limitations You get religious or dogmatic about agents  Many applications still for which conventional software engineering techniques are more appropriate You do not know why you want agents  Read optimistic reports about the technology and adopt it You believe that agents are the silver bullet  Hasn’t proved itself yet! You forget you are developing software  So software engineering good practice should be followed! 24 © H. Mouratidis

25. Pitfalls of agent development (Wooldridge, 2004) Your design does not exploit concurrency  Do you really need agents? You see agents everywhere  Develop a successful system using agents…then you only think agents! You have too few agents  Do not recognise the advantages of multi agent systems You spend all your time implementing infrastructure  No widely used software platforms for developing multiagent systems…spend effort and time for developing them 25 © H. Mouratidis

26. Agent Computing “My guess is that agent-based computing will be what object oriented computing was in the 1980s. Everybody will be in favour of it. Every manufacturing will be promoting his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.” (Jenning, 1999) 26 © H. Mouratidis

27. References / Reading “An introduction to Multiagent Systems”, Michael Wooldridge, Willey & Son, 2003 “Software agents”, J. Bradshaw (006.3) “Readings in agents”, M. Hunhs et al. (006.5) Lots of research papers on WebCT!!!! 27 © H. Mouratidis

28. Software Patterns 28 © H. Mouratidis

29. What is a software pattern? repeatable solution to a commonly occurring problem in software design Enable an efficient transfer of experience by documenting common solutions to recurring problems in a specific context. A three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves (Hillside.net) 29 © H. Mouratidis

30. A historical view Christopher Alexander first used it as an architectural concept (1979) “[A] 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 using it the same way twice.” – (Christopher Alexander) Nothing to do with software 30 © H. Mouratidis

31. History of Patterns in Software Gamma, Helm, Johnson, Vlissides (or the Gang of Four – GoF) Use the work of Alexander for software Seminal Publication (1994) Design Patterns: Elements of Reusable Object- Oriented Software 31 © H. Mouratidis

32. Documenting Patterns Contain information about the problem, the context, the forces, the solution Pattern Name: Every pattern should have a descriptive and unique name that helps in identifying and referring to it. (Classification): The pattern should be classified according to a classification. This classification helps in identifying the use of the pattern. (Intent): This section should describe the goal behind the pattern and the reason for using it. It resembles the problem part of the pattern. (Also Known As): A pattern could have more than one name. These names should be documented in this section. Forces: A description of the relevant forces and constraints, and how they interact/conflict with each other and with the intended goals and objectives of the pattern. 32 © H. Mouratidis

33. Documenting Patterns II Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams can be used for this purpose (if OO patterns). Participants: A listing of the classes and objects used in this pattern and their roles in the design. [ If OO patterns] (Collaboration): Describes how classes and objects used in the pattern interact with each other. Consequences: This section describes the results, side effects, and trade offs caused by using this pattern. Implementation: This section describes the implementation of the pattern, and represents the solution part of the pattern. (Sample Code): An illustration of how this pattern can be used in a programming language Known Uses: This section includes examples of real usages of this pattern. Related Patterns: This section includes any related patterns and it discusses their differences with the presented pattern. 33 © H. Mouratidis

34. Common Pattern Classification Concurrency patterns  These patterns involve coordinating concurrent operations and address two primary problems  Shared resources  Sequence of operations Architectural patterns  Indicate fundamental structural organization schemas (predefined sub-systems and relations) for information systems. Creational patterns (OO patterns)  Creation of objects Structural patterns  Indicate how relationships between components can be realised Behavioral patterns  Are used to organize, manage, and combine behavior 34 © H. Mouratidis

35. Pattern Languages Patterns are only point solutions Patterns are often organised in the form of pattern languages A pattern language is set of closely related patterns that guides the developer through the process of designing a system. Design starts as a “fuzzy cloud” As patterns are applied parts of the system come into focus / refine the design 35 © H. Mouratidis

36. Criticisms for Patterns Duplication of effort Standardize accepted best practices. Why use the design abstraction and not the code? Lacks formal foundations Study is ad hoc without using any specific formalisation. Large Pattern catalogues Similar Patterns appear with different names 36 © H. Mouratidis