International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and

Wireless Communications, 2011(ISSN 2225-658X)

Knowledge based approach to software development process modeling

Jan Kousznik and Svatopluk tolfa
Department of Computer Science VB - Technical University of Ostrava, Faculty of Electrical Engineering and Computer Science 708 33, Ostrava - Poruba, Czech Republic {jan.kozusznik,svatopluk.stolfa}@vsb.cz

Abstract. Modeling a software process is one way a can company decide which software process and/or its adjustment is the best solution for the current project. Modeling is the way the process is presented or simulated. Since there are many different approaches to modeling and all of them have pros and cons, the very first task is the selection of an appropriate and useful modeling approach for the current goal and selected conditions. In this paper, we propose an approach based on ontologies. Keywords: ontology, knowledge representation, modeling, simulation, software development process

Introduction

Modeling the process is always driven by the specific goal. The goal has to be selected before the modeling is performed, because the modeling approach depends on the desired point of view and that point of view depends on the goal. Our intention is to develop a modeling approach that can be used, at least at the beginning of the modeling, without the knowledge of the real goal. We decided to use an ontology based approach that could fulfill some necessary properties: iterativeness the model can be modeled from the abstract viewpoint and then refined; transformation between different types of model approaches; integration of approaches avoiding duplicities when modeling by one approach and then switching to another. The goal of this paper is to describe how to use ontologies for the creation of such software process models. This paper is organized as follows: section 2 provides an introduction to the problem of the software development process, section 3 describes the most current software process modeling, section 4 presents our knowledge-based approach to software process modeling, section 5 discusses the properties of using an ontology and the OWL for process modeling, section 6 demonstrates the presented approach of the case study, section 7 concludes, and section 8 discusses our future work.

617

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

Software development process

Business processes represent the core of company behaviour. They define activities which companies (their employees) perform to satisfy their customers. For a definition of the term business process, we use the definition from (WfMC, 1999): Business process is a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the structure defining functional roles and relationships. A process of IS development is called the software process. The software process is also a kind of business process but it has its specific aspects. Software engineering is a discipline that is involved in software process development and maintenance [1]. The main purpose is risk and cost reduction during software development. A process development could be divided into activities of different kind, as is defined by the process life-cycle engineering [2]. The process life cycle spiral includes these activities: Meta-modeling; Modeling, Analysis; Simulation; Redesign; Visualization; Prototyping, walk-through and performance support; Administration; Integration; Environment generation; Instantiation and enactment; Monitoring, recording and auditing; History capture and replay; Articulation; Evolution ; Process asset management. A description of every activity is provided in [2].

Modeling discipline

Modeling is often used in other disciplines and it is beneficial for the software development process. The term model means a representation of one system modeled system by another system. The modeled system often comes from reality or another artificial complex system and the model is its simplification abstraction. Three functions of abstraction for modeling during database system development are defined [3,4] see Fig. 1. Aggregation entity containing other parts from modeled domain is represented by one entity in the model; Classification class of similar entities and their features is identified; Generalization different set class of entities are unified into one class with similar properties. There exist many modeling techniques for process modeling as is mentioned in [5]. On the other hand, the software development process is quite specific [6] and it has been characterized as the most complex endeavor humankind has ever attempted [7]. Nonetheless, the software process could be modeled formally [8]. A knowledge-based approach to software process engineering has already been dealt with in [9-11]. The benefits of the knowledge-based approach to modeling and simulation(KBS) compared to a Discrete-Event Simulation (DES - [6]) and System Dynamics (SD - [12]) are discussed in [13].

618

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

Modeled system
Wheel Aggregation Engine Chassi
Elise Bob Patric

Model

Car

Cockpit

Classification

Customers

Elise Bob Patric Boby Dr.X

Generalization

Persons

Fig. 1. Functions of abstraction

3.1

Knowledge based approach to process modeling

Summarising the comparison of the KBS approach to DES and SD approaches provided in [13], we now list the activities supported by particular models in Table 1. Explanation of items in Table 1: S this activity is fully supported by given modeling approach; SL - this activity is supported by given modeling approach but different approach appears to be more appropriate; LT this activity is not supported by given approach, but, in our opinion, this restriction is due to the framework used for the model development rather than due to the approach in general; WS this activity seems that the given approach will most likely never be supported. Based on the previous summary, the knowledge-based approach has been chosen also as primary tool for capturing and dealing with software process for SPI purposes. The selected approach was mainly inspected as a tool for process simulation but it is strong enough to be used during the whole process lifecycle. It also deals with problems or goals defined in the introduction: iterativeness mentioned by Redesign and Evolution; transformation support in principle defined by mappings between different domains; an integration of other methodologies mapping or transformation could be defined between different approaches.

619

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

Table 1. Summary of comparison of different approaches

Knowledge-based Meta-modeling Discrete event System dynamics

S(ontology can be
e asily manage d)

SL SL SL (supporte d only by fe w
imple me ntations of DES)

S(supports an
Modeling incre me ntal de ve lopme nt of a mode l)

Analysis

S S S (supports an
automatic transformation)

Simulation

SL (support only the monolithic

simulation)

Redesign Visualization Prototyping, walkthrough and performance support Administration Integration Environment generation Instantiation and enactment Monitoring, recording and auditing History capture and replay Articulation Evolution Process asset management

SL S LT S LT LT LT S S

LT S

S S (supports an
automatic transformation)

WS SL LT

620

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

3.2

State-of-the-art of knowledge based approach

A well-defined meta-model of a software process1 for the knowledge-based approach is described in [11]. Authors defined a unified resource model (URM) for integrating types of objects appearing in models of the software process. Their URM consists of resource classes and relations between different types of resources. The type of resource could be a developed system, a document (or more generally artifact), a development tool, a particular software process2 and others. This meta-model defines the generic model that consists of tree objects: resource, simple-resource, aggregateresource; and relations among these classes: is-a-subclass; has-member-resource, has-neighbors, has-resource-specs. This generic model is specialized into five specific models for developed software-system, document, agent, tool and process. In every model, object types are specified Resource becomes Tool, Simple-resource becomes Program and aggregate-resource becomes Toolkit in the tool model. Additional relations among resources from different model have also been added. However, the previous approach was based on the platform for AI and knowledge representation named Knowledgecraft. This platform had been developed by the Carnegie Group in the 80s and 90s [14]. At the present, this platform is not available any more. It was based on Common Lisp language and knowledge definition by frames.

Suggested approach

The current mainstream for knowledge representation and its use is in the applications of semantic webs[15] and multi-agent systems. There was already an applied concept of ontology based modeling on process modeling and simulations. A model represented by an ontology was transformed into a description for JSIM simulation system [16]. The ontology approach offers basic functions of abstraction for modeling. The generalization is represented by the relation superclass between sets. The conceptualization is represented by sets and individuals. The aggregation is not directly supported but it could be represented by object property. To analyse, design and build the semantic annotation of a software process, we follow the W3C recommendations on OWL/DLW3C, see [17]. OWL is a language classified as a description logic-based language that is a subset of the first-order language. The language offers definitions of: sets (the term class will be used instead of set according to OWL terminology in the rest of the paper) and their individuals - classification, relations between sets inheritance, disjunction, equivalence; various constraints of classes; possible relations between individuals object properties.

1 2

Authors use term model of software development. Authors use term development process.

621

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

Particular constructions used in the model of the software development process will be discussed later.

Specificities of a modeling by a ontology and OWL

The presented approach which uses OWL has some disadvantages it lacks the possibility of defining that an individual represents a class again (this possibility is called the multilevel classification in the rest of the paper). This could be perceived as a pointless issue but this possibility is advocated in [4]. Multilevel classification is also important during the use of meta-model based OMG specifications [18,19]. A meta-model represents classification abstraction of a modeled element it defines basic concepts and their relations used during modeling (its conceptualization). It defines modeling language or modeling methodology. The term meta expresses that it is a conceptualization of elements used for modeling. Usability of multilevel classification for (meta)modeling is presented in Fig. 2. Role represents a class of individuals that stand for individual roles in the presented metamodel (Project manager, Analyst). This relation is represented by a dashed line marked as is item of. On the other hand, these particular individuals represent a set of other individuals (people): in the role Project manager John; in the role Designer Alice, Lilian (same individual as in class Project manager). Relations could be treated similarly. The link between Role and WorkUnit (named carries out) defines the relation with the domain of specific classes. The link between Project manager and Requirement analysis is an item of the relation, but it defines another set of links between individuals from the specific classes it defines a relation between the classes. We are aware of this limitation and our initial approach will prevent the necessity of multilevel classification. This could be done by a different modeling approach. A relation named contains can be defined as expressing that a specific role contains a specific person. There is also a different approach in the manner of the meta-model definition. The class Role can be defined as a set of individuals that play some role. The subset Designer defines a set of persons in the role Designer. The choice between defining by individuals and by class depends on the level of abstraction. Particular people will be defined during software development process modeling. Roles are quite abstract and unreal objects so they are expressed by class.

622

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

Metamodel
Role
Carries out

WorkUnit

Is item of Is item of Is item of Is item of collaborates

Is item of

Model
Requirement analysis
Is item of

Project manager Analyst

Is item of

Is responsible

Is item of Is item of Is item of Is item of Is item of

Instances
Requirement analysis execution on 4th July
Is item of

John Alice

Lilian

Requirement analysis execution on 20th July

Fig. 2. Multilevel classification

There is another specificity of OWL use for modeling. A link cannot be defined between a set and another set or individual. Only links between individuals (it is called an object property in OWL) can be defined. There is no difference between the type of modeling constructs used in the level of a meta-model and a model that was presented in the previous text. A meta-model contains a coarser structure of sets while a model contains a more detailed structure of sets and individuals. A meta-model is also part of a model with a higher level of abstraction in this approach. More precisely, a meta-model of models defines the elements of OWL. However, we will use the term meta-model for the basic and general structure of the software development process according to the convention of OMG specifications. The definition of OWL elements will be called meta-metamodel. The presented modeling process is based on a top-bottom approach to modeling. A meta-model that is based on previous studies ([19]) is used. It becomes more specific during modeling. However, the opposite sequence is also possible. Individuals and their specialized sets are defined during modeling. Their structure could lead to a more general system of sets which defines a common meta-model.

Software process model creation

Our presented example process is an easy development process that is followed in a middle-sized software company. The input to this process is Customer Needs and the output is a Developed System. The role Project manager is responsible for the execution of this process (

Fig. 3). The Software Development Process (SDP) consists of four sub -processes (Fig. 4): Requirements Elicitation and Analysis (REA), Software Design (SD), Software Construction (SC) and System Testing (ST). In this level of abstraction,

623

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

new roles are present. The names of roles and their responsibilities are: Analyst that is responsible for REA, Designer is responsible for SD, Programmer is responsible for SC, and Tester is responsible for ST. Each sub-process consumes and produces some artifacts: Customer Needs is input to the REA. Analysis Document part Requirements Specification is created there and is passed to the SD. SD sub-process produces Design part of an analysis document. Design goes to the Software Construction and the Developed system is created there. In ST, several tests are performed and the output is a Developed System and Test Report. If necessary, each sub-process can be refined to more detail as is shown in Fig. 5 and so on. Its activities are defined as responsible roles connected with solid lines, and cooperating roles connected with dashed lines.
Project Manager
Analyst Designer

Requirements Elicitation and Analysis Software Design

Programmer Tester

Customer Needs

Software Development Process

Developed System

Customer Needs Analysis Document (Requirements Specificaton)

Software Construction System Testing

Analysis Document (Design)

Developed System

Developed System (Tested)

Test Report

Fig. 3. Software development process

Fig. 4. Sub-processes of a Software Development Process

Project Manager

Customer

Consultant

Analyst

CAB

Designer

Programmer

Salesman

Preparation for the Meeting with Customer

Analysis Meeting

Requirements Description

Requirements Review

Requirements Specification

Requirements Specification Review

Effort Estimation

Schedule Creation

Customer Needs

Meeting Minutes

Meeting Minutes

Analysis Document (System Requirements)

Analysis Document (System Requirements) [Reviewed]

Analysis Document (Requirements Specification)

Analysis Document (Requirements Specification) [Reviewed]

Estimated Effort

Schedule

Project Manager

Analyst

Fig. 5. Sub-process REA

6.1

Meta-model creation

A creation of the software process meta-model is defined in [19]. This paper provides a clear overview of the problem. Different approaches and methodologies are considered - including the OMG business process definition meta-model (for more

624

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

details see [20]). The authors suggested a simple mechanism for the integration of multiple meta-models into simple cores with possible flexible extension for the purpose of further modeling. 5 metamodels from different viewpoints are identified: activity (Fig. 6), product, decision, context and strategy; and from one integrating part - process domain meta-model (Fig. 7).These mentioned meta-models are defined by MOF Meta-Object Facility that is the language used for meta-model creation MOF is defined in a meta-metamodel level). Activity and process domain metamodel are presented in (figures originate from [19]).

Fig. 6. Activity-oriented metamodel - [19]

Fig. 7. Process domain metamodel - [19]

Before modeling, these metamodels are combined into one that contains selected subclasses of every part. The selection is based on the demands placed on the process. We have created a separate ontology for every part of the meta-model. These ontologies are defined in OWL by the tool Protg. Classes from particular parts of the meta-model are represented by ontology classes, while associations are represented by object properties and inheritance is represented by sub-classing. There are two types of associations, which differ:

625

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

associations with a name where names of roles are omitted e.g. association raises between classes Work Unit and Issue in a process domain metamodel, and associations where only names of roles are defined association between Activity and ProcessRole with roles activity and assistant in the activity-oriented meta-model. Associations with names are represented by one object property with the same name and one inverse object property where the name has the suffix !. Domains and Ranges are selected according to a defined direction of the meaning of the association. Object property raises has defined domain as class Work Unit and range as class Issue. There also exists the inverse object property raises! where the domain and the range are swapped. Associations with two defined roles are represented by two object properties that ( ) - is are inverse. The name of every object property constructed by this pattern: ( Value ) ( ) ( ) (1) ( ) represents name of class that defines Domains. Value ( ) represents name of role of class that defines Ranges of the relation. Association between Activity and ProcessRole with roles activity and assistant is represented by these object properties: ProcessRole.activity with domain ProcessRole and with range Activity Activity.assistant with domain Activity and with range ProcessRole Every specialized meta-model ontology imports a core ontology that represents process domain meta-model see Fig. 8. The import of ontologies is directly supported by OWL and it means that the importing ontology includes all elements from the imported ontology (also other imports). In a case when both ontologies contain two elements with the same name, the elements are distinguished by the namespace of its origin ontology. This situation is even eliminated in our presented approach because the same name for elements means the same things. On the other hand, there are classes that have different names in different ontologies but present the same class [19]. It is solved in the specific ontology that imports the core ontology there is defined that a specific class is equivalent to the same class (but with a different name). Class WorkDefinition from an activity-oriented meta-model is defined as equivalent to WorkUnit from the process domain meta-model. It is defined in the ontology representing the activity-oriented metamodel.

626

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

Metamodel ontologies
process domain metamodel

strategy domain metamodel Activity oriented metamode Product oriented metamode

context oriented metamode decision oriented metamode

Model of the real process

Fig. 8. Ontology import structure

6.2

Model creation

Model creation of the example process starts from the meta-model that is defined in a previous section. The model is created as an ontology in the Protg tool that imports necessary meta-model ontologies. Since we model the prescription of the process, the classes are modeled. When there is a need to model the particular execution of the process, modeling by the entities is used. This type of modeling is not described in this text. At a high level of abstraction, our example process consists of three basic elements that are modeled as a specialization of three meta-model classes. The SDP process is a specialization of Work Unit, Project Manager is a specialization of Role, and Customer Needs and Developed System are specializations of Work Product. Project Manager is responsible for the execution of the SPD. This is modeled as a restriction on the Project Manager: Project manager can only carry out the SDP. For the simplification of the modeling of the example, let us say that the responsibility and cooperation of the Work Unit is the same. Otherwise the solution would be the creation of the sub-property of the carries_out property from the metamodel and appropriate restrictions would be created. The same principle of property restrictions is applied to the connections of the Customer Needs that is input to the SDP (WorkProduct.in property with domain Work Product and range Work Unit) and Developed System that is output from the SDP (WorkProduct.out property with domain Work product and range Work Unit). When we want to model a more detailed description of the model (Fig. 5), we can use an aggregation function for the description of the connection between the SDP process and its sub-processes REA, SD, SC, and ST that are defined as a specialization of the Work_Unit. The aggregation is realized in the SDP Work_Unit by the property subWork: SDP subWork only (REA, SD, SC, ST) SDP subWork some REA SDP subWork some SD

627

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

SDP subWork some SC SDP subWork some ST The same principle is used for the aggregation of Requirements Specification and Design into Analysis Document. The responsibilities of the roles are modeled by the carry_out property and in/out Work Product for the new Work Units are defined by the WorkProduct.in and Work.Product.out properties. One new situation has to be solved, Customer Needs is the input into the SDP and REA that is in fact part of the SDP. The solution is the restriction on the Customer Needs property WorkProduct.in only SDP or REA. Then, when there is a need for another lower level abstraction, the same principles for modeling are used again: specialization and splitting-up into components as inverse procedures to the generalization and aggregation functions of abstraction. This type of modeling can be used for the modeling of well-known domains, where the meta-models are already defined. Otherwise, the meta-models and models must be recognized and defined first; three functions of abstraction are used.

Conclusion

An approach of process modeling with ontologies (or formal knowledge) has many benefits, as was discussed in the beginning of this paper. Another valuable benefit is the possibility of combining more meta-model ontologies during modeling. A mechanism of ontology import is used for this purpose. One metamodel ontology could also extend (import) another ontology metamodel. Equivalence between semantically same classes with different names could be used. The structure of the ontology is simultaneously proved with an inference machine during model creation. However, the great disadvantage is that fact that modeling itself is very troublesome. A huge model becomes unclear. On the other hand, it is only a limitation of the tool which is used process modeling in OWL is similar to a PDF creation in a text editor. It is necessary to create a superstructure over it. The superstructure could provide a visual overview with a possibility of ontology creation. It will be discussed in the next chapter.

Future works

The superstructure of the direct ontology definition will be created in the future. Our vision is to provide a graphical editor. The editor will provide a view of a selected part of the model. There is also a planned feature for the simple creation of typical model constructs. Methodology creation is another important issue. A full overview of modeling construction or patterns will be arranged for the purpose of process modeling. For every construction, a corresponding implementation in OWL will be defined. The methodology will solve the problem of when to use individuals for modeling and when to use subclasses.

628

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

The created model is not the goal itself. It is necessary to utilize its possibilities. Model simulation is possible. The model needs to be enriched with information about the order of the particular activities. A mechanism of ontology extension will again be used. A transformation to a simulation model follows. Transformations for various simulation approaches will be defined. A process enactment is similar to the process simulation and it is planned to be developed. Apart from simulation or enactment, various analyses could also be used. The modeling possibility of OWL is limited. For example, it does not support the multilevel classification. An examination of another language is our next work. A platform OpenCYC exists that is even available as an open source. The platform is declared as knowledgebase with inference machine. The language for knowledge formulation is used. This language is first order logic (FOL) with some constructions from second order logic. Acknowledgements. This research has been supported by the internal grant agency of VSB-TU of Ostrava - SP2011/56 Knowledge approach to the modeling, simulation and visualization of software processes.

References
1 Humphrey WS (1995) A Discipline for Software Engineering. Addison-Wesley Professional. 2 Scacchi W, Mi P (1997) Process Life Cycle Engineering: A Knowledge-Based Approach and Environment. Intelligent Systems in Accounting, Finance, and Management 6:83--107-183--107. 3 Smith JM, Smith DCP (1977) Database abstractions: aggregation and generalization. ACM Trans Database Syst 2 (2):105-133. doi:10.1145/320544.320546 4 Machado EP, Caetano Traina J, Araujo MRB (2000) Classification Abstraction: An Intrinsic Element in Database Systems. Paper presented at the Proceedings of the First International Conference on Advances in Information Systems, 5 Vergidis K, Tiwari A, Majeed B (2008) Business Process Analysis and Optimization: Beyond Reengineering. Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on 38 (1):69-82. 6 Raffo DM (1996) Modeling software processes quantitatively and assessing the impact of potential process changes on process performance. Ph.D. thesis, Carnegie Mellon University. 7 Brooks FP (1987) No Silver Bullet - Essence and Accidents of Software Engineering (reprinted form information processing 86, 1986). Computer 20 (4):10-19. 8 Curtis B, Kellner MI, Over J (1992) Process modeling. Commun ACM 35 (9):7590. 9 Garg PK, Scacchi W (1989) ISHYS: Designing an Intelligent Software Hypertext System. IEEE Expert: Intelligent Systems and Their Applications 4 (3):52-63.

629

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(3): 617-630 The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

10 Mi P, Scacchi W (1990) A Knowledge-Based Environment for Modeling and Simulating Software Engineering Processes. IEEE Trans on Knowl and Data Eng 2 (3):283-294. doi:10.1109/69.60792 11 Mi P, Scacchi W (1996) A meta-model for formulating knowledge-based models of software development. Decis Support Syst 17 (4):313-330. doi:http://dx.doi.org/10.1016/0167-9236(96)00007-3 12 Madachy RJ (2008) Software Process Dynamics. 2nd edn. Wiley-IEEE Press. 13 Scacchi W (1999) Experience with software process simulation and modeling. Journal of Systems and Software 46 (2-3):183-192. 14 Laurent J-P, Ayel J, Thome F, Ziebelin D (1984) Comparative Evaluation of Three Expert System Development Tools: Kee, Knowledge Craft, Art. The Knowledge Engineering Review 1 (04):18-29. doi:doi:10.1017/S0269888900000631 15 Allemang D, Hendler J (2008) Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL. Morgan Kaufmann. 16 Silver GA, Lacy LW, Miller JA (2006) Ontology based representations of simulation models following the process interaction world view. Paper presented at the Proceedings of the 38th conference on Winter simulation, Monterey, California, 17 W3C (2009) OWL 2 Web Ontology Language. http://www.w3.org/TR/owl2overview/. 18 Object Management Group(OMG) (2010) OMG Unified Modeling Language(OMG UML), Infrastructure, Version 2.3. 19 Hug C, Front A, Rieu D, Henderson-Sellers B (2009) A method to build information systems engineering process metamodels. Journal of Systems and Software 82 (10):1730-1742. doi:10.1016/j.jss.2009.05.020 20 Object Management Group(OMG) (2008) Business Process Definition MetaModel (BPDM),Version 1.0.

630