=Paper=
{{Paper
|id=Vol-52/paper-12
|storemode=property
|title=Using Meta-Model Technologies to Organize Functionalities for Active System Schemes
|pdfUrl=https://ceur-ws.org/Vol-52/oas01-breton.pdf
|volume=Vol-52
}}
==Using Meta-Model Technologies to Organize Functionalities for Active System Schemes==
https://ceur-ws.org/Vol-52/oas01-breton.pdf
Using Meta-Model Technologies to Organize
Functionalities for Active System Schemes
Erwan Breton Jean Bézivin
Société Soft-Maint LRSG, Université de Nantes
4, rue du Château de l'Eraudière,BP 588 2, rue de la Houssinière,BP 92208
44074 Nantes cedex 3, France 44322 Nantes cedex 3, France
ebreton@sodifrance.fr Jean.Bezivin@sciences.univ-nantes.fr
ABSTRACT
Keywords
A new information system landscape is emerging that will be more
Process Models and Meta-models; MOF; MDA; UML;
model-centered than object-oriented, characterized by many
models of low granularity and high abstraction, which describe
static or dynamic aspects of enterprise information systems. This 1. INTRODUCTION
This paper focuses on the particular challenge of interoperability of
paper focuses more particularly on the organization of dynamic
process models. In section 2 we discuss the new MDA scheme
models that we call here active system frameworks (process
(Model-Driven Architecture) [10] put forward by the OMG (Object
models by opposition to product models). They cover, among Management Group) and the central role of models and meta-models.
other concerns, the organization of work, its assignment to We show in section 3 how heterogeneous meta-models are
potential performers and interactions between them. Agent interleaved. This may oblige a particular domain meta-model to
technology is thus concerned in two ways. First, as active respect constraints in order to be integrated into more global
elements, they may intervene in a workflow in the same way as environments. As we observe similarities between them, we attempt
to organize them in a rational way. We particularly study two
real persons. Second, some of their aspects (organization,
problems of immediate interest to software engineering. First how to
processing and interaction) are also shared by other domains. All
couple the meta-models of process with the meta-models of
these schemes could and should be organized in a lattice of meta- products. Second how to organize the various process meta-models
models. The point of view taken here is essentially the one of the involv ed in the design and maintenance of information systems.
software engineering community. As we witness a rapid These problems may be considered as two application areas of agent
proliferation of product and process meta-models, the question of technology.
their overall organization arises. Inspiration may be provided in
this field by some results of ontology engineering. We specifically 2. MODEL DRIVEN ARCHITECTURE
point out at two practical areas of concern. First how to couple The arrival to maturity of object technologies has allowed the idea of
the meta-models of process and the meta-models of products. model-based software development to find its way to practicality.
The OMG is no more centering its activities on a unique
Second how to organize the various process meta-models involved
interoperability bus, but on two different ones: the classical CORBA
in the design and maintenance of information systems. software bus (for code interoperability) and the emerging MOF
(Meta-Object Facility) [7] knowledge bus (for model
Categories and Subject Descriptors interoperability). The consensus on UML (Unified Modeling
D.3.3 [Software Engineering]: Design Tools and Techniques – Language) [8] has been instrumental in this transition from code -
oriented to model-oriented software production techniques. A key
Object-Oriented Design Methods.
role is now played by the concept of meta-model in new software
organizations like the OMG meta-model stack architecture. The
General Terms notion of a meta-model is strongly related to the notion of
Design ontology, used in knowledge representation communities. The
concept of a MOF (Meta-Object Facility) has progressively emerged
in the last ten years from the work of different communities like
CDIF, IRDS, etc., as a framework to define and use meta-models.
The MOF is some kind of an upper -level ontology, defin ed and used
by OMG, for the specific task of building information system.
Delimiting with precision the boundaries of this task is not easy since
it may encompass the definition of business processes for any kind of
organization.
We face today a multiplicity of models. The information engineer or
the software engineer are usually working with several different ones
at the same time, i.e. with models of different semantics. The
executable source code is no more the main and central reference. may be performed both by persons of the organization and software
Product models are arranged in complex organization networks. components. Finally a process may generate some costs depending
They are produced and used within precise methodological on applications and people. Processes may be of different types. For
frameworks sometimes themselves defined by other models (process example a bank is concerned with business processes as cash retrieval
models). One view of Computer Science is that we are now achieving or account opening. The software development team of a bank
the first historical paradigm shift, namely from procedural performs software processes and produces software components,
refinement to object composition and that we are, at the same time, which are the result products of software processes. The agents who
starting the second paradigm shift, from object composition to perform the business processes will use these software components as
model transformation. Obviously to make this last scheme workable, applications.
we need to start with some basic models, mainly the domain model, One of the first problems is to define the precise relations between
the resource model and the requirement model. Each model is itself the various kinds of elements of a produc t model with the various
structured in a number of sub-models, allowing for example to define, kinds of elements of a process model. The difficulty here is often to
within the domain model, different entities like business objects, organize the product model in separate chunks that are logically
business processes and business rules. related. For example the UML meta-model defines nine different
There are two broad families of models: product and processes. A kinds of diagrams and a given engineer, with particular skills and
product model may describe for example the software artifacts one responsibilities, may for example accept use cases on input and
may find in an object -oriented design; these artifacts may be produce class diagrams on output. Modular decomposition of product
described with one of the nine basic diagrams of the UML formalism. models is thus of paramount importance. The various modules
Another example of a product model would be the QoS attributes defined by the product meta-model may play the role of structured
associated with the functional attributes of a similar system. One type definition in a classical organization whereas the process meta-
corresponding process model could be the software process intended models provides the basis for defining the control structures.
to produce the de sign model or the QoS model. If this kind of decomposition is necessary, it is far from being
The decision not to go for a unified object -oriented software sufficient. The product model defines what is being acted upon. The
production method was initially a wise decision. This conducted to process model is supposed to state who is doing what, when, how and
giving the priority to the definition of a meta-model for software why. As a consequence the process meta-model also cannot be
artifacts, namely the UML which is basically a product meta-model. viewed as a monolithic definition. Instead it should be composed of
The missing link to put this into practice was then the definition of a interrelated chunks of information (Figure 1), related to the actors,
corresponding generic process and this is what is being achieved with the performed tasks, the scheduling of tasks, the conditions for
the Unified Process Model (UPM), considered either as a first -class executing these tasks, the cost factors, etc.
meta-model or as a profile of the UML meta-model. UPM is
supposed to provide the building blocks to define a software
Objectives
production process in various environments. At the same time it was
also recognized that UML was not sufficient to cover all software
artifacts and this is one reason why the CWM (Common Warehouse
Meta-model) was defined, opening the path for the definition of
broader process like migration processes from legacy systems to Products
advanced component based systems.
All these considerations have brought the OMG to make an Organization
important move from OMA (Object Management Architecture) to Processes
MDA (Model Driven Architecture) [2], [10]. One particularity of
this scheme is the importance given to middleware parameterized
model management in the new vision. This means that, as new
middleware platforms are emerging and co-existing (CORBA,
Java/EJB, C#/DotNet, Web/HTTP, etc.), means should be provided Software components (agents, Costs
actors, objects, legacy systems)
to generate from the abstract models themselves, executable systems
for t he various target platforms.
3. ORGANIZATION OF META-MODELS Figure 1 A lattice of product and process meta-models
A meta-model defines a language for describing a specific domain of
interest. For example UML describes the artifacts of an object - Agents may be considered (from a process point of view) either as
oriented software system. Some other meta-models address domains single products or as performers of automated tasks. As a
like process, organization, quality of service, etc. Their number may consequence it should be possible to consider them according to both
be very important as identified domains are highly specialized. dimensions. They may have to perform a task lik e a person within
Though they are first defined as separated components, it is clear the organization. As agents may also perform activities, agent and
that many relationships exist between them. We found two areas as person specialize a common generic performer.
being of urgent concern: firstly how to organize the coupling of
meta-models of products with meta-models of processes. Second how
3.2 Organizing Process Meta-models
to organize the various models of process that we have to manage. There are many separate process domains. This implies many
separate meta-models. However there exist some core similarities. A
3.1 Coupling of Processes and Products process skeleton is a set of ordered activities (or tasks), grouped in
An enterprise has some objectives, which may be achieved by order to achieve common global objectives. It may thus be
products or processes. Products are the results of processes. Processes interesting to propose a process meta-model architecture, allowing a
specific process meta-model to be defined using a more general 4. CONCLUSION
process meta-model. Expected benefits are reuse and facilities for
It comes with no surprise that the software engineering community is
process models translation from one meta-model to another. Figure
today discovering the huge potentialities and also some of the
2 proposes such architecture based on domain identification and
unsolved problems of ontology engineering. Once we have laid out
hierarchy. A generic process meta-model may introduce common
the approximation that a meta-model is similar to an ontology, an
concepts like activities, objectives, and transitions. More specific important work of confrontation remains to be done, with certainly
meta-models specialize this root meta-model (or a specific one) by
a lot of fruitful outcome. Many insights could be found for example
adding new relations and entities. Manufacturing meta-model may
in TOVE [4] or similar research projects. Within a world of
thus define mechanisms to handle resources consumption, whereas
increasing complexity due to technological and social evolution, the
software process introduces iteration.
only sensible way to keep in contro l is to deal with this complexity
at a higher level of abstraction. Many meta-models of products have
Generic
Process already been defined to help in this task (UML, CWM, end-user
domains meta-models, etc.). It appears that this is only a first step
and that the definitio n of several process meta-models represents
also an urgent task (workflow, business process, software production
Software Workflow Manufacturing Business process, software maintenance process, system migration process,
Process Process
etc.). As a consequence we should be in a position to handle, both at
the description and at the execution level, the relations between
these various process models. Also, the coupling between process
models (e.g. workflow models) and product models (e.g. EJB
Software Buiding Software Maintenance Software Migration
Process Process Process component models) should be handled in a regular way.
5. REFERENCES
Figure 2 Some meta -models for various processes [1] BPMI.org Business Process Modeling Language
Agent technology may also find its place in such an architecture. (BPML) Working draft 0.4 March 2001.
Business process definition proposals like BPML[1] (Business [2] Dsouza, D. Model-Driven Architecture and
Process Modeling Language) or ebXML[3] (electronic business XML)
define complex interactions between partners, which may
Integration: Opportunities and Challenges Version 1.1.
encapsulate transactions and activities. The OMG workflow RFP [9] www.kinetiuym.com
has the purpose to define graph of activities (which may be either [3] ebXML Business Process Project Team The ebXML
manual, automatic or which even may lead to sub-processes). All Business Process Metamodel Second Draft June 2000.
these meta-models may share a core of common concerns with
AUML [3], namely interactions, activity flow and role assignment. [4] Fox, M.S., Gruninger, M., (1997), On Ontologies and
It would thus be interesting for some common patterns, or best Enterprise Modelling , International Conference on
practices, to be reused across separate domains. In this way meta- Enterprise Integration Modelling Technology 97,
models could cover either a particular domain of interest (like agents, Springer-Verlag, 1997.
business processes or bank documents, etc) or propose standard
frameworks (like group organization, interaction between multiple [5] Lee J., Grunninger M., Jin Y., Malone T., Tate A., Yost
partners, etc.). Framework meta-models would then be reused and G. & other members of the PIF Working Group The PIF
specialized by domain meta-models. Domain met a-models would Process Interchange Format and Framework Version
have integration relations between them as they form a strongly 1.2 The Knowledge Engineering Review, Vol. 13, No. 1,
interconnected lattice. For example a business process may assign pp. 91-120, Cambridge University Press, March 1998.
some activities to software agents and others to human beings.
What we may witness today is a lot of separate efforts to define
[6] Odell, J., Van Dyke Parunak, H., Bauer,B. Extending
various variants of domain dependent processes like the UPM UML for Agents AOIS Workshop, 17th National
(Unified Process Model) for production of object -oriented software conference on AI, Austin, TX, pp. 3-17
systems, in conjunction with the UML software product model. [7] OMG Meta Object Facility (MOF) Specification. OMG
Teams working in the related areas of workflow de finition, business
Document AD/97-08-14, september 1997.
process specification, maintenance and migration frameworks and
many other areas are all encountering similar problems. It would be a [8] OMG OMG Unified Modeling Language Specification
wise initiative to put all these contributions together and to study version 1.3 OMG Document AD/99-06-08, June 1999.
what may be common and what should stay specific. Learning from
previous similar projects like PIF [3] should be very helpful in this
[9] OMG Workflow Process Definition Request for
work. We have today the possibility to perform this meta-model Proposal OMG Document BOM/99-10-03, November
organization in a more operational way, by building on well-accepted 1999.
industrial frameworks like the OMG MOF. What we need is a global [10] Soley, R. & the OMG staff. Model Driven Architecture
context/organization to host this kind of cooperative work.
OMG Document, November 2000.