Situated Process Engineering for Integrating Processes from Methodologies to Infrastructures Ambra Molesini
Elena Nardini
Alma Mater Studiorum –
Alma Mater Studiorum –
Universita` di Bologna Bologna, Italy
Universita` di Bologna Cesena, Italy
[email protected] Enrico Denti
[email protected] Andrea Omicini
Alma Mater Studiorum –
Alma Mater Studiorum –
Universita` di Bologna Bologna, Italy
Universita` di Bologna Cesena, Italy
[email protected]
[email protected]
ABSTRACT
Keywords
In the field of Multi-Agent Systems (MASs), methodologies and infrastructures have developed in the last years along two opposite paths: while Agent-Oriented methodologies have essentially undergone a top-down evolution, MAS infrastructures have mostly followed a bottom-up path, producing a conceptual gap between methodologies and the available agent infrastructures. This paper aims at defining a method for filling such a gap, based on Situational Method Engineering (SME) and SPEM (Software Process Engineering Meta-model). After highlighting the lack of sufficient research and understanding about the role of the infrastructures in the software engineering process, we show that infrastructures, like methodologies, have processes behind them, and propose a method based on the integration of the processes underpinning both methodologies and infrastructures. Then, we validate such an approach by showing how the process of the SODA methodology can be integrated with the process of the TuCSoN infrastructure using SME and SPEM.
Multi-agent systems, AOSE, software process, methodology, MAS infrastructures, SODA, TuCSoN, SPEM, situational method engineering
1.
INTRODUCTION
Multi-Agent Systems (MASs) are a powerful paradigm for the implementation of complex computational systems: this is probably one of the main reasons why the agent metaphor and the agent-oriented paradigm are gaining momentum in areas such as electronic commerce, enterprise resource planning, and mobile computing. In particular, methodologies (and respective notations) have become central in AgentOriented Software Engineering (AOSE) research as key tools for MAS analysis, design and development process. However, a rapid paradigm shift – from traditional Software Engineering (SE) to Agent-Oriented Software Engineering (AOSE) – dropped technology behind: while in the past new abstractions used to come from programming languages, and were later included in the software engineering practice, nowadays the available technologies for MAS development and deployment often do not support the novel abstractions adopted in the AOSE analysis and design [19]. Such a gap mainly depends on AO methodologies and MAS infrastructures having evolved along two parallel, yet somehow inverse, paths: a top-down evolution for AO methodologies, a bottom-up path for multi-agent infrastructures [18]. Several research efforts are being made to fill this gap: [2] and [19] explore a mapping between methodologies’ metamodels and infrastructures’ meta-models, and a new methodology is being defined in the MEnSA project [18] by assembling different AO methodologies and MAS infrastructures. Although such investigations have paved the way towards a more precise mapping between the concepts supported by methodologies and infrastructures, leading to the definition of infrastructures’ meta-models, this is still not enough for a software development process aimed at covering all the stages of the software lifecycle. In fact, this approach provides only guidelines on abstractions’ mapping, but says nothing about the process resulting from such an integration and how to use it.
Categories and Subject Descriptors D.2.10 [Software Engineering]: Design—Methodologies, Processes; D.2.18 [Software Engineering]: Software Engineering Process—Process definition, Software process models
General Terms Software Development Processes, Methodologies, Infrastructure
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’09 March 8-12, 2009, Honolulu, Hawaii, U.S.A. Copyright 2009 ACM 978-1-60558-166-8/09/03 ...$5.00.
699
To address this issue, it is worth considering that the traditional software engineering practice includes four fundamental process activities that are common to all software processes [32]: Specification, Design and Implementation, Validation and Evolution. AO methodologies support processes that differ from the traditional ones precisely in the management of these activities: while Specification and Design are always present in any AO process, Implementation is seldom considered, and Validation and Evolution are usually not taken into account at all. So, extending the work in [19], in this paper we mean to re-use the Situational Method Engineering (SME) technique [5, 6] along with the Software Process Engineering Meta-model (SPEM) [22] for integrating methodologies and infrastructures. In particular, starting from the idea that infrastructures, like methodologies, have an underpinning process, we consider methodology and infrastructure as two fragments to be integrated in order to obtain a new software process. This approach is applicable even if both the methodology and the infrastructure are not “atomic processes”, but are composed of further fragments coming from different methodologies and infrastructures—in which case, the integration occurs between one or more methodology fragments and one or more infrastructure fragments. For sake of concreteness, we take the integration between two atomic processes, the SODA agent-oriented methodology [23, 30] and the TuCSoN infrastructure for MAS coordination [27, 31], as our running example. Accordingly, Section 2 presents a definition of software development processes and sketches both SME and SPEM, which are adopted for modelling software process. Section 3 and Section 4 discuss SODA and TuCSoN, respectively, while the integration between the corresponding processes is presented in Section 5. Section 6 reports on related work, and Section 7 concludes and outlines some future work.
2.
the infrastructure on the software engineering process: this is quite peculiar, since the presence of a specific infrastructure clearly affects the engineering process—for instance, there would be no need to design a function if it is already provided by the services/functionalities of the selected infrastructure. Analogously, the processes underpinning the methodologies could be influenced by the adoption of an infrastructure instead of another. Summing up, infrastructures represent a key piece of the software development process, especially in AOSE. Our viewpoint is that infrastructures, like methodologies, do have a process behind them: simply, it is usually ‘silent’ and unspecified. To define a complete software development process, we believe that such an infrastructure process needs to come ‘out of the water’, so as to be first explicitly detailed, and then clearly integrated with the methodologies’ process.
2.2
PROCESSES & SITUATIONAL METHOD ENGINEERING
This section introduces the definition of software process (Subsection 2.1), highlighting the relations between processes, methodologies and infrastructures, then presents the two techniques adopted in this paper—Situational Method Engineering for integrating method fragments (Subsection 2.2), and SPEM (Software Process Engineering Meta-model ) for process modelling (Subsection 2.3).
2.1
Software Processes
According to a Development Process is an ordered set of steps that involve all the activities, constraints and resources required to produce a specific output which satisfies a set of input requirements [3]. A process is typically composed of several stages/phases:each stage/phase identifies a portion of the work to be done, the resources to be exploited for that purpose, and the constraints to be obeyed. The relation between methodologies and processes is well studied in the literature: as pointed out in [3], methodologies focus more explicitly on how an activity or task should be performed in specific stages of the process, while processes may also cover more general management aspects about who, when, how much, etc. On the other side, to the best of our knowledge, the current SE/AOSE literature pays no attention to the impact of
Situational Method Engineering
Situational Method Engineering (SME) [5] provides means for constructing ad-hoc Software Engineering Processes following an approach based on the reuse of portions of existing design processes. SME is mainly based on the idea that each methodology can be decomposed into reusable parts (method fragments) that a designer can re-use and re-assemble so as to create his/her own methodology, “ad hoc” for a given purpose [6]. The first step is therefore to extract method fragments from existing design methodologies, and store them in a repository (the method base), from which they can be retrieved by the method engineer when constructing a new method; obviously, the definition of a suitable assembly technique is of paramount importance for the successful application of this approach. The composition of a new process is called method fragments integration and usually consists of two complementary phases: the selection of the useful fragments from the method base, and their assembly [6]. In our case, we exploit such an approach in a peculiar way, adopting two very coarse-grained fragments, which represent a methodology on the one side, and an infrastructure on the other. The reason is that such (somehow unusual) macro-fragments are particularly suited to the purpose of this paper, which is to illustrate the presence of the process behind an infrastructure, and how it can be integrated with the methodology’s process. Of course, SME could be applied in principle also to methodologies and infrastructures composed of different fragments: however, this is outside the scope of this paper. After identifying the infrastructure’s and the methodology’s processes, we discuss their integration (Section 5) based on the meta-models mapping approach [19].
2.3
SPEM
SPEM is an OMG standard for defining software and system development processes, and their components [22]. Its meta-model is structured in seven packages: (i) the Core package provides the base classes and abstractions for all other meta-model packages; (ii) the Process Structure package defines a process model as a breakdown or decomposition of nested Activities with the related performing Roles and input/output Work Products; (iii) the Process Behavior package allows the static breakdown structure of a process to be extended with existing externally-defined behavior models; (iv) the Manage Content package introduces
700
the concepts required to document and manage the development processes through natural language; (v) the Method Content package describes how to achieve fine-graned development goals, specifying the involved roles, resources and corresponding results, independently of the placement of these steps within a specific development lifecycle; (vi) the Process With Method package provides for integrating processes defined through the Process Structure package with instances of Method Content package concepts; finally, (vii) the Method Plugin package introduces the concepts needed to design and manage maintainable and reusable libraries of method content and processes. Since the goal of SPEM is to support the representation of development processes with mechanisms that promote process reusability [22], its meta-model introduces a clear separation between reusable method contents and their application in processes. Method contents provide step-by-step explanations, describing how a given development goal can be achieved, independently of the placement of these steps in a development lifecycle; then, processes take these method content elements and relate them into partially-ordered sequences that are customised to specific project types.
3.
Requirements Analysis
Analysis
Is the problem well specified?
no Layering yes
Architectural Design Is the system well specified?
no
yes
Layering
yes
Detailed Design Are there problems in the system?
SODA
no
SODA (Societies in Open and Distributed Agent spaces) [23, 30] is an agent-oriented methodology for the analysis and design of agent-based systems, which adopts [20] the Agents & Artifacts meta-model (A&A) [26], and introduces the layering principle – composed by two mechanisms: zoom and projection – as an effective tool for scaling with the system complexity, applied throughout the analysis and design process [20]. The abstractions supported by SODA (the SODA metamodel is presented in [30]) are logically divided into three categories: i) the abstractions for modelling/designing the system active part (task, role, agent, etc.); ii) the abstractions for the reactive part (function, resource, artifact, etc.); and iii) the abstractions for interaction and organisational rules (relation, dependency, interaction, rule, etc.). In its turn, the SODA process is organised in two phases – Figure 1 –, each structured in two steps: the Analysis phase, which includes the Requirements Analysis and the Analysis steps, and the Design phase, which includes the Architectural Design and the Detailed Design steps. Each step models the system by exploiting a subset of the SODA abstractions: in particular, each subset always includes at least one abstraction for each of the above categories—that is, at least one abstraction for the system active part, one for the reactive part, and another for interaction and organisational rules. Since SODA is a technology-neutral methodology [19], the Implementation stage is intentionally not covered. The SODA process is iterative and incremental: each step can be repeated several times, by suitably exploiting the layering principle. Figure 1 depicts an example of the iterative nature of this process: each step can be repeated several times, by suitably exploiting the layering principle: so, for instance, if, during the Analysis step, the System Analyst – one of the roles involved in the SODA process – recognises some omissions or lacks in the requirements’ definition, he/she can restart the Requirements Analysis step by adding a new layer in the system or selecting a specific layer and then refining it. Similar considerations can be made for both the Architectural Design step – where the Analysis step
Figure 1: Activity Diagram of the SODA process. can be restarted from the layering – and the Detailed Design step—which leads to restart the Architectural Design step. It is worth noting that, although the Detailed Design step is iterative (Figure 2), its iterative nature does not involve the layering principle, which, by definition, is not applicable in this step. In fact, the goal of this step is to choose the most adequate representation level for each architectural entity, thus leading to depict one (detailed) design from the several potential alternatives architectures outlined in the previous step. So, as one can see in Figure 2, the first activity of this sub-process is the Carving, which represents a sort of boundary between the Architectural Design and the Detailed Design, where the chosen system architecture is “carved out” from all the possible architectures. Finally, in order to support the integration between fragments, the fragment’s Inputs and WorkProducts have to be specified. In particular, since we see the whole SODA process as a unique fragment, the fragment input is represented by the input of the Requirements Analysis step, i.e., the Requirements Statement that represents a requirement’s textual description. In turn, the WorkProducts of this macrofragment are the WorkProducts of the Detailed Design, expressed as relational tables that provide the description of the system design in terms of agents, agent societies, artifacts, aggregates and workspace as far as the abstract entities involved are concerned; in terms of concepts such as use, manifest, speak to and linked to as far as the representation of the types of interactions are concerned.
4.
TUCSON
TuCSoN (Tuple Centres Spread Over the Network) [27, 31] is an infrastructure providing services for the communication and coordination of distributed / concurrent in-
701
plementation phase, and (iii) the Organisation Test phase. In the Organisation Definition phase (Figure 4) the agent organisation is described in terms of the abstractions of the TuCSoN meta-model [19]. In particular, the agent system is described as an organisation dynamically structured in societies, defined as instances of society classes (acting as templates). A society class groups a set of roles: each role is characterised by a policy, which in turn rules the agent’s entrance in the organisation and defines the actions and interaction protocols allowed for agents playing that role. This phase describes also the structural and functional tests needed to check the behaviour of the whole agent organisation. Then, in the Organisation Implementation phase the agent organisation is implemented upon the TuCSoN infrastructure. The abstractions defined in the previous phase representing society classes, societies, roles, and policies ruling the agents’ entrance are reified here as tuples in a special tuple centre – usually denoted as $ORG – which models the agent organisation. Moreover, the policies defining the actions and interaction protocols allowed for agents playing society class roles are described using a Prolog theory. This phase takes care also of implementing the tests (defined in the previous phase) in terms of ReSpecT specifications. Finally, in the Organisation Test phase the organisation behaviour is tested so as to discover possible structural and functional errors, by exploiting the tests implemented in the previous phase. As shown in Figure 3, we consider the iterative and incremental process model as the most adequate for TuCSoN. In fact, such a model not only is the typical choice when designing large and complex software projects [32]: it also supports the delivery of incremental releases of the agent organisation until a satisfying organisation is reached.
Carving
Mapping
Agent design
Environment design
Workspace design
Interactions design
is the system well specified? yes
no
Figure 2: Activity Diagram of the Detailed Design step.
dependent agents. TuCSoN supports agent communication and coordination via tuple centres—shared & reactive information spaces, distributed over the infrastructure nodes, which work as coordination media [9]. More precisely, a tuple centre is a tuple space enhanced with the notion of behaviour specification: as such, it is perceived by the interacting entities (agents) as a standard tuple space [10], but its behaviour in response to events can be user-specified in terms of coordination laws. The behaviour specification of TuCSoN tuple centres is by default expressed in the ReSpecT specification language [25]. Another TuCSoN peculiarity is represented by the Agent Coordination Context (ACC ), introduced in [24] as the conceptual boundary between an agent and its organisational environment: its purpose is to encapsulate the interface that enables the agent’s actions and perceptions within the environment. Following the approach outlined in [3], a process – intended as an ordered sequence of steps to be followed to exploit the infrastructure as the working environment for an agent organisation – can be identified behind TuCSoN, too.
Society Class Definition
Society Instance Definition
Topology Definition
Agent Behaviour Definition
TC Behaviour Definition
Yes Organisation Test Definition New Iteration ?
Organisation Definition
Yes
No
New Interation ? Organisation Implementation
Organisation Test
No
Figure 4: Activity Diagram of the Organisation Definition phase.
Figure 3: Activity Diagrams of the TuCSoN process.
In this work, we aim at integrating methodologies and infrastructures by adopting the SME technique [5]—in particular, considering infrastructures and methodologies as sin-
More precisely, three phases clearly emerge (Figure 3): (i) the Organisation Definition phase, (ii) the Organisation Im-
702
gle atomic processes, seen as macro-fragments (see Subsection 2.2). Accordingly, among the TuCSoN process phases, the Organisation Definition – described in the activity diagram shown in Figure 4 – is the most relevant for the integration of the TuCSoN fragment with the selected AO methodology. In fact, this phase takes the description of the agent organisation to be realised and adopts the abstractions of the TuCSoN meta-model [19] to obtain a concrete design of the system at hand. This is why the abstractions introduced in such a phase are the only ones to be considered when integrating the TuCSoN fragment (Section 5). In the last step, the Inputs of the TuCSoN process are specified: perhaps expectedly, there is just one mandatory input—the Organisation Design coming from the design stage of the selected methodology. Such Input abstractions are then used in the Organisation Definition phase as sources to instantiate the TuCSoN meta-model abstractions.
5.
of a prioritisation algorithm [5] consisting of three steps: (i) prioritisation of MMMEs; (ii) identification and assembly of the method fragments that define the MMMEs; (iii) extension of the meta-model until the complete process is defined [5]. In our case, however, this algorithm is unnecessary, since all of the SODA MMMEs have a counterpart in one or more TuCSoN MMMEs: so, the assembly is far less difficult then the generic fragments assembly (Figure 5).
%==8)=+0)"5;-)0H
%=),0
I583/:+;) &5() ":)+3405
!"#$%&"'"()* +),)"'"()
!
"#
%$%;0-5, &'()
*+,-.)/0 "5;-+( %80-.+;0
FRAGMENT INTEGRATION
2-,3405 1/)
# :)8+0-5, K,
