and actions are both implemented by services with differ- ent visibilities. Roles are divided into Managed Roles (MR) and Au- tonomic Roles (AR) (similar to the ...
TOWARDS A MODEL-DRIVEN SOFTWARE ENGINEERING METHODOLOGY FOR ORGANIC COMPUTING SYSTEMS Holger Kasinger, Bernhard Bauer Department of Computer Science University of Augsburg 86135 Augsburg, Germany {kasinger | bauer}@informatik.uni-augsburg.de ABSTRACT The complexity of computing systems steadily increases and their future administration will soon exceed any human capabilities. A resort to this scenario are self-managing systems that administrate themselves according to highlevel policies established by an administrator. Thus systems configure, optimize, protect and heal themselves autonomously making administrative interferences unnecessary. Organic Computing (OC) keeps this track by drawing analogies from biological systems such as ant colonies or dissipative structures, both resulting in emergent behavior. Due to its characteristics agent technology is particularly suitable for an implementation of Organic Computing Systems (OCS). However for a widespread industrial application acceptable software standards are required for both system architecture and software engineering. Therefore we propose a multi-agent system architecture and an appropriate development process as a first step towards a software engineering methodology for OCS. The process is based on the Model Driven Architecture (MDA) by the OMG and the UML 2 standard as well. KEY WORDS Multi-Agent-Systems (MAS), Software Engineering and Organic Computing.
1 Introduction The integration of computing systems into everyday life is an ongoing process. Faster processors, more memory capacities and higher data transfer rates lead to multifunctional systems becoming at the same time smaller, less power consuming and are often virtually or physically invisible to the user. As a result future computing systems will be much more embedded into everyday commodities, such as air plains, vehicles, telecommunication systems and factories, than they are today. But in the same way as the increasing functionality and interoperability of computing systems offer great benefits to users, the accruing complexity exhibits enormous challenges to administrators. Mastering the complexity is already one of the major tasks and - as Moore’s law is still present - will still be in the future. However, referring to [1] there will be not enough skilled I/T people to keep the world’s comput-
ing systems running. Even if this amount could be accomplished, the complexity would grow beyond human ability to manage it. Thus one resort is to leave the administration of future computing systems to the systems themselves. Organic Computing [2] addresses this objective by drawing analogies from complex biological systems, with the human-centered goal of self-organization. OCS are defined as self-managing systems possessing so-called self-x properties, namely being self-configuring, self-optimizing, self-healing, self-protecting, context-aware and anticipatory. By virtue of its characteristics agent technology is particularly suitable for an implementation of OCS, as agents are autonomous, reactive, proactive and already possess social capabilities (see [3]). Nevertheless an important key prerequisite to a widespread industrial application in various domains resides in software engineering. Without an appropriate engineering approach it is almost impossible to cope with the complexity of OCS, especially with the self-x properties. In spite of the different software methodologies for MAS existing today (for an overview see [4]) none is applicable to OCS as they do not support the development of self-x properties. Thus a new, continuous and consistent software engineering methodology is required which incorporates the ability to develop self-x properties for OCS. A software methodology is typically characterized by a modeling language - used for the description of models - and a development process - defining the development activities, the interrelationships among the activities, and how the different activities are performed. In this paper we propose a model-driven development process as a first step towards a methodology for OCS. The process is based on the framework of the MDA [5] by the OMG and uses the UML 2 standard for the notation of the models as far as possible. Necessary notation elements not yet defined in the UML standard will be specified. The rest of the paper is organized as follows: Section 2 explains the nature of OCS in detail and provides an appropriate system architecture whereas section 3 presents the development process and its models. In section 4 we illustrate the development of a specific self-x property by a simple case study of the manufacturing control domain. Section 5 presents some concluding remarks and gives an outline of future work.
Figure 1. Meta model of the system architecture of OCS
2 The System Architecture As introduced in the previous section, an OCS possesses certain self-x properties. Self-configuration allows a system to be capable of configuring itself automatically in accordance with high-level policies representing businesslevel objectives – that specify goals – and supporting automated, seamless incorporation of new components and new types of components. Self-optimization means continually seeking ways to improve its operation, monitoring itself to identify and seize opportunities to make itself more efficient in terms of performance or cost, while self-healing deals with detecting, diagnosing, and repairing localized problems resulting from bugs or failures in software and hardware system. Self-protection is used in two ways: Defend the system as a whole against large-scale, correlated problems arising from malicious attacks or cascading failures that remain uncorrected by self-healing measures and anticipate problems based on early reports from sensors and take steps to avoid them. Context-awareness is characterized by adaptivity, i.e. learning from the past and adapting the behavior to react in an optimized way and contextsensitive, i.e. gathering information from the environment and taking this environment into account. To facilitate all these properties we propose a meta model for a MAS depicted in figure 1. Within the meta model we have combined different proved concepts of both existing agent architectures or rather agent methodologies and non-agent architectures. Similar to many existing agent methodologies a role is the central architectural concept. The complete set of roles builds up the environment. The life cycle of a role is traditionally: A role or rather the enacting agent recognizes a situation, makes a decision based upon it and executes appropriate activities.
The recognition of situations (context-awareness) is based on events. Regular events are already known to a role, e.g. by design or by adaptation, whereas irregular events (similar to the concept of NCS by ADELFE [7]) are new to a role, e.g. by failure appearance (self-healing) or by intrusion detection (self-protection). Events activate and deactivate respectively norms (similar to the NoA Agent Architecture [8]) which regulate the behavior of a role. A norm is a generalization of an obligation, a permission and a prohibition and consist of a goal as well as activation and deactivation events. The decision making is based on plans that fire certain events at the end (as a notification of being in a certain state) which may correspond to a norm’s goal or event respectively. A plan consists of actions (internal activities of a role) and interactions (external activities between different roles) and is chosen according to a goal of an activated norm. Interactions are implemented by specific interaction protocols. The relation between interactions and interaction protocols is the same as between interfaces and their implementations. Thus according to diverse requirements an interaction may be implemented by different kinds of protocols for direct (e.g. by auctions), or indirect (e.g. by stigmergy) communication. Interactions and actions are both implemented by services with different visibilities. Roles are divided into Managed Roles (MR) and Autonomic Roles (AR) (similar to the concept of Managed Resources and Autonomic Managers by the Autonomic Computing reference architecture [9]). MRs are responsible for the business logic of a system and reside on versatile resources (applications, databases, directory services, printers, CPUs, . . . ). They are controlled and supervised by one or more ARs that are responsible for the self-management of a system. ARs do not necessarily have to be located at
Figure 2. Development process models for OCS
the same resource as their MRs. In contrast to MRs the ARs are able to generate new plans (self-optimization) based on the received data of their MRs. The latter do not have to generate new plans as they communicate the occurrence of irregular events to their supervising ARs and mostly are not in possession of further required information. Both roles are dynamically taken over by Managed Agents and Autonomic Agents respectively. Autonomic Elements contain one ore more Autonomic Agents and Managed Agents at the same time.
3 The Development Process The proposed development process is, as already mentioned, based on the MDA. In the context of the MDA the system’s functionality is separated from the technology specific implementation. This is addressed by constructive models over all phases of the development process. These models are not only used for an abstract description of the later system but for the (semi-)automatic generation of later models and finally components of the system. This is achieved by the definition of transformations between models of different levels. The MDA distinguishes three different levels: A computational independent viewpoint, a software independent viewpoint and a software specific viewpoint. The first viewpoint is encapsulated into the Computational Independent Model (CIM) and describes a system in its current or future environment. The second viewpoint is encapsulated into the Platform Independent Model (PIM) and describes a system without divulging any details of a specific platform. The third viewpoint is encapsulated into the Platform Specific Model (PSM) and describes a system for a detailed implementation on one or more specific platforms. The proposed development process consists of 19 activities and encompasses an analysis phase and a design phase. Each activity results in a specific model (see figure 2) either in the CIM (for the analysis phase) or the PIM (for
the design phase). An implementation phase is not considered yet but can be added in future smoothly. Notice, the process does not prescribe a process model.
3.1 The Analysis Phase The analysis phase consists of five activities: (1) Definition of the business context, (2) Definition of business processes being supported, (3) Characterization of the environment, (4) Assembly of potential use cases and (5) Assembly of common vocabulary. As result of (1) the business context of the future system is modeled in the Business Context Model by an UML activity diagram. This model only considers higher level correlations and abstracts from concrete business processes. As result of (2) the business processes which shall be supported by the system are modeled in the Business Process Model by an UML activity diagram again. The activities of a process have to be assigned to actors (workers, machines, databases, . . . ) of the company (represented as partitions in the model). As result of (3) important environment objects of all types are modeled in the Environment Model by an UML class diagram. Thus the system environment is specified in detail by e.g. attributes. As result of (4) the system application is declared abstractly in the Use Case Model by an UML use case diagram. The model is supported by an UML sequence diagram to explain the message flow of the system clearly. As result of (5) the common vocabulary is categorized in the Ontology Model by an UML class model.
3.2 The Design Phase The design phase consists of 14 activities: (6) Identification of MRs, (7) Specification of norms for MRs, (8) Development of plans for MRs, (9) Derivation of interactions between MRs, (10) Specification of services of MRs, (11)
Identification of ARs, (12) Specification of norms for ARs, (13) Development of an analysis for ARs, (14) Development of plans for ARs, (15) Derivation of interactions between ARs, (16) Specification of services of ARs, (17) Development of interaction protocols, (18) Identification of Autonomic Elements and (19) Deployment of Autonomic Elements. As result of (6) the Managed Roles are identified in the Managed Role Model. As UML defines no notation element for roles we have defined a new element similar to a class in an UML composition structure diagram. As result of (7) the norms of MRs are specified in the MR Norm Model. Again there is no defined UML notation which gets us to the definition of a notation similar to a class in an UML class model. However there are no attributes or methods but goals, activation and deactivation events. As result of (8) the plans of MRs are modeled in the MR Plan Model by an UML activity diagram. The plans contain input and output parameters, actions and interactions, and events as well. In addition they are separated into partitions corresponding to the MRs. As result of (9) the interactions between MRs are derived and modeled in the MR Interaction Model as UML sequence diagram. In this model only the exchanged objects (information carriers) are embodied, not a concrete protocol. As result of (10) the signatures of provided services of a MR are specified in the MR Service Model. For it a new notation element had to be defined similar to a class in a UML class diagram again. Here the visibility and input and output parameters are contained instead of attributes and methods. As result of (11) the ARs are identified in the Autonomic Role Model. The notation of these roles is the same as in the Managed Role Model. The activity has to take place in parallel to activity (12). As result of (12) the norms for ARs are specified according to desired self-x properties in the AR Norm Model. Notice, a norm of an AR symbolizes a part of a certain self-x property of a system. As result of (13) the monitoring and analysis of events and data by an AR is modeled in the AR Analysis Model by an UML activity diagram. This is an important premise for the right choosing of a plan to satisfy an AR norm. As result of (14), (15) and (16) the plans, interactions and services of an AR are modeled in the AR Plan Model, AR Interaction Model and AR Service Model which are similar to the respective MR models. As result of (17) the interaction protocols for the interactions between MRs/MRs, MRs/ARs and ARs/ARs are specified in the Interaction Protocol Model by an UML sequence diagram. Depending on the requirements of the application the kind of interaction can be direct or indirect. As result of (18) MRs and ARs are summarized into Autonomic Elements in the Autonomic Element Model. The notation of an Autonomic Element is similar to a class in an UML composition structure diagram again. As result of (19) the deployment of the Autonomic Elements on resources is defined in the Autonomic Element Instance Model which is similar to an UML deployment diagram.
3.3 Model Transformations As transformations are the central paradigm of MDA the definition of transformation rules is inescapable. Up to now we have formally defined a few tens of transformation rules between CIM/CIM, CIM/PIM and PIM/PIM models (see arrows in figure 2), for example (informal): (a) Every partition in the Business Context Model executing a business process being supported by the system in future is transformed into a partition in the Business Process Model. (b) Every instance within the sequence diagram of the Use Case Model is transformed into a MR of the Managed Role Model. (c) Every message exchange in the addressed sequence diagram is transformed into a norm of the emitting role or instance respectively. (d) Every activation and deactivation event within a norm in the MR Norm Model is transformed into an event in the MR Plan Model. (e) Every MR having assigned a norm is mapped into the MR Plan Model. (f) Every message exchange between two partitions in the MR Plan Model is transformed into an interaction between the corresponding roles in the MR Interaction Model. This transformation already automates activity (9) completely. (g) Every action of a partition in the MR Plan Model is transformed into a private service of the corresponding role in the MR Service Model. (h) Every message in an interaction between two roles in the MR Interaction Model is transformed into a public service of the receiving role in the MR Service Model. (i) Every activation event of a norm in the MR Norm Model is transformed into an event in the AR Analysis Model. The analysis itself can not be automated at design time yet. Notice, transformation rules for the MR models also are partly valid for the AR models.
4 Case Study In order to evaluate the process we have redesigned an existing MAS and added different self-x properties to obtain an OCS. As the set of artifacts would exceed the limitation of this paper we only illustrate activity (12), (13) and (14) by a short example of developing a self-x property.
4.1 Manufacturing Control Today’s manufacturing industry is facing a major shift from a supplier’s to a customer’s market. Thus the requirements on the manufacturing process itself increase permanently: Instant demand satisfaction, higher product variety and cost reducing are just some of them. Thus Valckenaers et al. [10] developed a multi-agent coordination and control system based on stigmergy (coordination mechanism based on indirect communication, e.g. used by food foraging ants). The system consists of three different types of agents: Resource agents, each assigned to a machine or switch in the manufacturing plant, order agents, each routing a product instance through the plant while reserving processing
time on appropriate machines, and product agents, each containing the construction plan for a specific product. In addition resource and order agents can make use of intelligent ant agents propagating and collecting information throughout the plant. The coordination mechanism works as follows: Resource agents assigned to machines permanently send ant agents opposite to the production line through the plant. These ants deposit the processing capabilities of their sending resource agent/machine as so called pheromones on every switch they cross. Order agents also create ant agents in a certain interval and send them down the production line. Based on the deposited pheromones on a switch the ants decide to which machine they will travel next. When they arrive at this machine, they request an offer for a specific process step (duration, earliest start, . . . ) and as soon as they receive the offer they continue traveling. If the end of the plant is reached the ants return to their order agents and report their chosen route. An order agent decides which of its ants has found the best way and routes its product instance accordingly.
Figure 3. A norm for self-optimization
4.2 Adding Self-Optimization The existing system already copes with machine breaks and short-termed changes. Nevertheless the system can be improved by adding self-x properties like self-optimization. Consider a resource agent simultaneously responding to a multitude of offer requests of present ant agents, the response time can exceed in a way that the performance of the complete production system may slow down. In order to prevent this situation we added an AR - resource to the MR - resource which measures the response time and if needed informs the order agents to reduce their ant agent generation interval to minimize the amount of concurrent offer requests. For the measurement the norm offer request response time optimization (see figure 3) has been specified for the AR - resource as result of (12). This forces the AR to achieve the goal offer request response time in bounds, is activated by the event offer request response time out of bounds and deactivated by the event homonymous to the goal. To provide the AR - resource with the ability to analyze if this norm is activated or not, the monitoring and analysis of certain events is modeled (see figure 4) as result of (13). The AR - resource listens to offer request events and offer sent events fired by the MR - resource. Within the analysis action the response time is determined according to given rules (not modeled in this figure) and depending on the result a corresponding event is fired. By catching this event the AR - resource can decide whether or not the above norm is activated or deactivated. If the analysis marks the norm as activated, the AR resource has to choose a plan for informing the order agents to reduce their generation interval. Such a plan is modeled within an action (see figure 5) as result of (14). The AR resource generates an offer request adjustment desire and
Figure 4. Monitoring and analysis of events
sends it to every order agent or rather to every AR - order, possibly propagated by ant agents again. Such an AR in turn generates an offer request adjustment instruction for its controlled MR - order which on its part slows down the generation interval (not modeled in this figure).
5 Conclusion The proposed development process along with the presented system architecture is a first step towards a software engineering methodology for OCS. The process incorporates the ability to develop both a multi-agent system and additional self-x properties. This separation yields to two advantages: On the one hand the development process is applicable for the engineering of ordinary MAS without any self-x properties, on the other hand self-x properties can be added to a system subsequently according to specific requirements (see section 4). Moreover the case study points out the supervising character of ARs and the clear separation between business logic and self-x properties. The use of standards, such as MDA as framework and UML 2 as modeling language, additionally offers great benefits. Due to the broad industrial acceptance of these standards the future period of vocational adjustment for developers will be low. Moreover by the definition of further transformation rules between the models, process activities can be completely automated and thereby reduce the de-
[2] Gesellschaft f¨ur Informatik: VDE/ITG/GIPositionspapier zum Organic Computing, 2003, http://www.gi-ev.de/download/VDE-ITGGIPositionspapier% 20Organic%20Computing.pdf. [3] M. Wooldridge and P. Ciancarini, Agent-Oriented Software Engineering: The State of the Art, AgentOriented Software Engineering, P. Ciancarini and M. Wooldridge (eds), LNAI 1957, 2000, 1–28. [4] B. Bauer and J.P. M¨uller, Methodologies and Modelling Languages, Agent-Based Software Development, M. Luck, R. Ashri and M. d’Inverno (eds), Artech House, 2004, 77–131.
Figure 5. Plans for Autonomic Roles
velopment time. Thus the complexity of future computing systems is not only transferred from administration to development but reduces efforts spent on both sides. Moreover OCS might be developed in future by non I/T experts as the specification of requirements could be the only necessary step in development performed by humans. In contrast to other role-based agent methodologies, e.g. Gaia [6], ROADMAP [11], TROPOS [12] or SODA [13], results of previous activities are directly utilized in later ones. By the definition of transformation rules existing gaps between different phases and models are eliminated. Furthermore clear definitions for the identification of MRs or enacting agent types exist. Moreover the process is designed for the support of business processes and embeds the system into a specified environment. As the modeled concepts within the PIM are platform independent, the process is open for different agent platforms and not limited to a technology. In addition the process focuses on the internal activities of an agent/role as well as on the external interactions between different agents/roles. Up to now an analysis and design phase are supported by the process. Nevertheless a lot of future work has to be done. To prove the concepts we have to add an implementation phase by defining transformation rules between PIM/PSM and based on that realize an OCS. The application of such a system will lead us to detailed experiences and possibly to an improvement of the process. Further more transformations rules have to be defined in order to automate more activities. At last a tool support has to be developed as this is the only way quality OCS can be developed efficiently in time.
References [1] IBM Research, Autonomic Computing Manifesto, http://www.research.ibm.com/autonomic/manifesto/ autonomic computing.pdf
[5] Object Management Group, Model Driven Architecture: A Technical Perspective, ormsc/01-07-01, 2001. [6] M. Wooldridge, N. Jennings and D. Kinny, The Gaia Methodology for Agent-Oriented Analysis and Design, Journal of Autonomous Agents and MultiAgent Systems, 3(3), 2000, 285–312. [7] C. Bernon, M.-P. Gleizes, G. Picard and P. Glize, The ADELFE methodology for an intranet system design, presented at AOIS2002, Toronto, 2002. [8] M.J. Kollingbaum and T.J. Norman, Supervised Interaction - Creating a Web of Trust for Contracting Agents in Electronic Environments, Proceedings of the AAMAS 2002, ACM Press, New York, 2002, 272–279. [9] IBM Research, An architectural blueprint for autonomic computing, 2004, http://www306.ibm.com/autonomic/pdfs/ACBP2 2004-1004.pdf. [10] P. Valckenaers, H. Van Brussel, M. Kollingbaum and O. Bochmann, Multiagent coordination and control using stigmergy applied to manufacturing control, Multi-Agent Systems and Applications, LNAI 2086, 2001, 317–334. [11] T. Juan, A. Pierce, and L. Sterling, Roadmap: Extending the Gaia methodology for complex open systems, Proceedings of the 1st ACM Joint Conference on Autonomous Agents and Multi-Agent Systems, Bologna, Italy, 2002, 3–10. [12] J. Castro, M. Kolp, and J. Mylopoulos, Towards requirements-driven information systems engineering: the TROPOS project, Information Systems, 27, 2002, 365-389. [13] A. Omicini, Soda: Societies and infrastructures in the analysis and design of agent-based systems, Agent Oriented Software Engineering, 2000, 185– 193.
