2016 5th International Workshop on Theory-Oriented Software Engineering
Systematic Approach for Mapping Software Development Methods to the Essence Framework Görkem Giray
Eray Tüzün
Bedir Tekinerdogan
Izmir University, Part-time Instructor Izmir, Turkey
Havelsan Ankara, Turkey
Wageningen University Wageningen, Netherlands
[email protected]
[email protected]
[email protected]
Yagup Macit Havelsan Ankara, Turkey
[email protected] framework can be used for modeling a broad set of software development methods. The mapping of a software development method to the Essence framework is called “essentialization” [2]. The overall mapping process is shown in Figure 1. The mapping process takes the software development method and the Essence framework as inputs and produces “essentialized” model as an output in the Essence language.
ABSTRACT The Essence framework has been recently defined as a basis for modeling various kinds of software development methods. The framework includes the necessary concepts to instantiate the software development methods. In this way a new method can be better understood, learned and compared with other methods. In practice, it is not straightforward to model a given software development method using the Essence framework. In this paper we provide a systematic approach for mapping methods to the elements of the Essence framework. To illustrate our approach, we use the mapping of the Nexus, a scaled agile approach, to the Essence framework. We report on the lessons learned and provide our conclusions. • Software methods
and
its
engineering~Software
Essence Framework Method Specification
Systematic Approach for Mapping
Essentialized Method
Figure 1. Systematic approach for mapping
development
The Essence framework is rather expressive in modeling a software development method, i.e. the essentialization process. However, this essentialization process is not straightforward to perform. Therefore, defining a systematic approach for mapping the software development method to Essence framework is essential.
Keywords Essence framework; Software development method; Nexus framework.
1. INTRODUCTION
To support this goal, we provide a systematic approach for mapping methods to the elements of the Essence framework. To illustrate our approach, we use the mapping of the Nexus, a scaled agile approach, to the Essence framework. We report on the lessons learned and provide our conclusions.
A software development method contains procedures, practices, and techniques to provide a systematic way of developing software [1]. In the last decade, several software development methods have been proposed ranging from plan-driven to more agile approaches. The Essence framework aims to provide a common language and a core domain model of software development. The Essence framework provides a formal basis for modeling software development methods and as such includes the necessary concepts to instantiate the software development methods. In this way a new method can be better understood, learned and compared with other methods. The Essence
The remainder of the paper is organized as follows. In section 2, we briefly describe the Essence framework. In section 3, we present our systematic approach for mapping and in section 4, we model the Nexus framework using Essence. In section 5, we present the related work. Finally, the section 6 concludes the paper by providing future work as well.
2. ESSENCE FRAMEWORK
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. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. TOSE'16, May 16 2016, Austin, TX, USA © 2016 ACM. ISBN 978-1-4503-4174-5/16/05…$15.00
The Essence framework defines a Language and Kernel for modeling software development methods [3]. The Language is a domain-specific language to define Kernels, Practices, and Methods [3]. The Kernel is a conceptual model of software development domain [4]. This model initially contains seven important concepts (called as Alphas and listed as Opportunity, Stakeholders, Requirements, Software System, Work, Team, and Way of Working) and their relationships. It provides a framework for assessing the progress and health of software development projects and a foundation for method and practice definitions [4].
DOI: http://dx.doi.org/10.1145/2897134.2897139 26
A practice provides a systematic and repeatable way of work focused on the achievement of an objective, which addresses a specific aspect of software development or teamwork [3]. A method is the composition of a Kernel and a set of Practices to fulfill a specific purpose [3].
on shallow instantiation and for its implications on Essence framework refer to [6] and Annex D of [3] respectively. •
The Essence Specification has been constructed using a formal language, natural language, and a metamodel [3]. Object Constraint Language (OCL), as a formal language, was used to define some well-formedness rules of the language. Dynamic semantics was defined using English as a natural language. The metamodel provides an abstract syntax and some constraints on the relationships between elements. The metamodel resides on level 2 of the meta-level hierarchy used by Essence specification. This meta-level hierarchy consists of four layers and widely known with its usage in Unified Modeling Language (UML) specification [5]. A part of the meta-level hierarchy is illustrated in Figure 2 with some example classes and objects at level 1 and 0.
In summary, Essence framework provides a language (at level 2) and a domain model for software development (at level 1), called the Kernel. A method engineer uses Essence Language and the Kernel to essentialize a method. Having modeled a method for a project at level 1, a software development team can create an instance of the essentialized method and track their software development project.
3. SYSTEMATIC APPROACH FOR MAPPING The Essence framework is expressive for modeling software development methods. However, mapping software development method concepts to the Essence framework is not straightforward. In this section we will present our systematic approach for supporting this mapping process. In section 3.1 we distinguish ontological concepts and linguistic elements of Essence framework. The ontological concepts of the Essence framework are used for what to consider as important when essentializing a method. The linguistic elements are used for having a properly represented method in Essence Language. Subsequently, in section 3.2, the steps of the approach are described.
Level 2
LanguageElement
Level 1
instanceOf
Requirements
my_Alpha instanceName currentState
isConcrete RepresentationOf
BasicElement
Alpha
WorkProduct
3.1 Ontological Concepts of Essence Framework
instanceOf
my_WorkProduct
SprintBacklog
In general, a model can be defined as an approximate representation of a phenomenon. In parallel with this definition, a model is an approximate representation of a software development method (i.e. essentialized method) within the scope of this paper. This means that a model considers some details of a method and ignores others. Since modeling is a knowledge representation activity and one of the fundamental roles of knowledge representation is defining a set of ontological commitments [7], we need to extract the set of ontological commitments made by Essence Language and Kernel. Ontological commitments, within the scope of this paper, are made up of ontological concepts (concepts that exist in software development domain) and their relationships. These ontological commitments guide a method engineer what to consider and ignore while modeling a method.
instanceName currentLevelOfDetail
Level 0
instanceOf
SprintBacklog1 : SprintBacklog instanceName = "SprintBacklog1" currentLevelOfDetail = "User Level"
Figure 2. Partial meta-level hierarchy of Essence framework •
Level 3: The meta-metamodel defines a language for specifying a metamodel [5]. Meta Object Facility (MOF) is used for the definition of level 3 of Essence specification [3]. Level 3, which contains MOF in this case, was excluded from Figure 2 for the sake of simplicity.
•
Level 2: The metamodel layer defines a language for specifying models [5]. The Essence Language is defined at this level. In Figure 2, LanguageElement, BasicElement, Alpha, WorkProduct are constructs in Essence Language.
•
Level 1: The model layer is for specifying models which are instances of the metamodel [5]. The Kernel concepts and an essentialized method reside at this level. In Figure 2, Requirements construct is contained in the Kernel and one of the seven Alphas defined by default. my_Alpha and my_WorkProduct are constructs to provide instance properties to be used at level 0. These constructs are required since MOF architecture (which constitutes the metametamodel of Essence Language) only support shallow instantiation. Shallow instantiation means that a class can only define the semantics of its direct instances, and can have no effect on entities created by further instantiation steps [6]. In our example, the properties of WorkProduct are not propagated to the instance SprintBacklog1. For a discussion
Level 0: The occurrence level contains objects or run-time instances of the elements of the model layer [5]. In Figure 2, SprintBacklog1 is an object at level 0 to be used to track a software development project.
The ontological commitments can be extracted from Essence specification. The metamodel both provides language constructs and ontological concepts for modeling methods. Separation of linguistic and ontological concepts has been pointed out in the literature. Gitzel et al. state that although linguistic and ontological relationships cannot be separated completely, it is possible to distinguish their purposes [8]. They limit the definition of linguistic metamodeling to a description of a language syntax without a concrete real-world mapping. On the other hand, ontological metamodeling is used for describing domain-specific hierarchies. Assmann et al. differentiate language concepts from description concepts (or ontological concepts) in a metamodeling architecture [9]. They use ontological concepts for describing real-world objects and language concepts for instantiating software objects. Similarly, Atkinson and Kühne map some of the types in a model to the types in a domain and some types do not have a correspondence in that domain [10]. For instance, “class” is a linguistic concept and does not have a correspondence in
27
software development domain, whereas an “activity” has a correspondence in the domain, which makes it an ontological concept. Based on these separations in the literature, we define the ontological concepts as the set of concepts which can be mapped to real-world concepts in software development domain. On the other hand, linguistic elements complement ontological concepts to form a representation language and model a method according to some rules. With this definition in mind, we analyzed Essence specification and extracted ontological concepts and relationships among them.
3.2 The Steps of the Systematic Approach for Mapping Our systematic approach for mapping is illustrated in the activity diagram in Figure 3. The approach is similar to domain modeling in object-oriented analysis. Therefore, we got inspired from the guidelines presented in [11], [12] for domain modeling.
The elements in Essence specification are grouped into six packages [3]. The packages and number of elements in each package is listed in Table 1. We have analyzed the elements of Table 1 and distinguished ontological concepts from linguistic elements. The third column shows the number of ontological concepts for each package. The detailed results of our analysis are shown in Appendix 1 (“P.” stands for “Package” and shows the packages of the elements in Essence framework; “O.C.” stands for “Ontological Concept” and shows the result of our evaluation by marking ontological concepts with “Yes” and linguistic elements with “No”). The elements in the UserDefinedTypes package are used for adding more detail to language elements and do not have real-world correspondence. The elements in the View package are related to presentation of model elements and do not correspond to ontological concepts. As a result, 23 of the language elements are corresponding to ontological concepts or ontological relationships among these concepts. These 23 elements reside at level 2 in the meta-level hierarchy. Table 1. Essence packages, number of elements and ontological concepts Package
Number of Elements
Foundation AlphaAndWorkProduct ActivitySpaceAndActivity Competency UserDefinedTypes View TOTAL
17 7 10 2 4 2 42
Number of Ontological Concepts 6 7 8 2 0 0 23
1
Extract concepts from method specification
2
Classify extracted concepts according to Essence concepts
3
Specify concepts using Essence Language
4
Specify properties of concepts
5
Associate related concepts
6
Review essentialized method
Figure 3. Top-level view of the approach As illustrated in the activity diagram, the following steps are proposed for the mapping process. These steps are typically performed iteratively and incrementally. 1.
Essence specification not only provides a metamodel at level 2, but also a model (called Kernel) at level 1. The Kernel is proposed to be included and extended by method definitions. The Kernel consists of 7 Alphas, 15 Activity Spaces, and 6 Competencies. All of these concepts are instances of their corresponding metaclasses in the Essence Language. Essence specification claims that these concepts form the core of any software development endeavor and can be included (and extended if needed) in any method definition. Besides the 23 ontological concept extracted from the Essence language, these concepts residing at the first level should be considered while defining a method based on Essence. Based on ontological and linguistic concept separation, Alpha, WorkProduct, Requirements, and SprintBacklog in Figure 2 are ontological concepts; whereas LanguageElement and BasicElement are linguistic elements. my_Alpha and my_WorkProduct are also treated as linguistic elements since they are used for overcoming shallow instantiation and their correspondences in real world are represented by Alpha and WorkProduct in the model.
28
Extract concepts from method specification: This step encompasses reading through a method specification, especially looking for nouns and noun phrases representing important concepts. In this paper, we refer to a concept as an abstraction or generalization to classify and discriminate things that exist in software development domain. All plurals are changed to singulars and a preliminary list of concepts is obtained. This list contains some obvious and some questionable concepts. A concept category list (such as in Table 2) contains some common categories (extracted from [3]) that are usually worth considering when modeling a method. The result of this step will be a tentative list of concepts. Some concepts will be missing and some will be eliminated later. Moreover, some verbs or verb phrases followed by concepts might indicate an activity, action, such as “refine product backlog”. Some of the nouns, noun phrases, verbs, and verb phrases will not be used as concepts, since they will not refer to an important aspect of the method to be modeled.
Table 2. A sample concept category list Concept Category Activity, Event Acceptance criteria, Checklist, Criterion, Criteria, Constraint, Artifact, Work product Customer, Client, Sponsor Dependency Development team, Team Increment Iteration Milestone Operation (Create, Read, Update, Delete) on an Artifact, Work product Phase Risk list, Issue list Role, Producer, Team member Task Task list User story, Use case, Requirements item Vision, Business need, Business requirement 2.
3.
4.
Table 4. A sample association pattern list •
Essence Concept Activity CheckListItem
• • • • • • • • •
WorkProduct Sub-Alpha of Stakeholders Pattern (Dependency), ActivityAssociation Sub-Alpha of Team Sub-Alpha of Software System Sub-Alpha of Work Pattern (Milestone) Action
6.
Pattern (Phase) WorkProduct Pattern (Role) Sub-Alpha of Work WorkProduct Sub-Alpha of Requirements • • •
Classify extracted concepts according to Essence concepts: Each candidate concept in the list is analyzed and classified based on the Essence framework. The concepts, which cannot be mapped to a category in a concept category list such as in Table 2, will form questionable concepts that will be probably eliminated. Specify concepts using Essence Language: The concepts are defined using graphical and/or text language elements of Essence. Existing concept specifications can be reused if available (SEMAT, the organization that created and developing Essence framework, aims to have a library of practices as declared at semat.org/practice-area). A tool such as the “Practice Workbench” (www.ivarjacobson.com/esswork-practice-workbench) can be used at this step. Specify properties of concepts: The properties (as illustrated in Table 3) of the concepts are defined according to the Essence Language.
• • •
5.
Associate related concepts: The associations among the concepts are established. An association is a semantic relationship between two or more concepts and predefined by Essence Language and Kernel. An association creates a meaningful sequence as “Concept1-VerbPhrase-Concept2”. Table 4 contains some common categories (extracted from [3] and enriched using synonyms) that are worth considering when modeling a method.
Does each sub-alpha have proper states defined? Does each state of sub-alphas have associated checklists consisting of checkpoints? Does each WorkProduct have a list of LevelOfDetails defined? Is each Activity associated with an Alpha and/or WorkProduct? Does each Activity have at least one EntryCriterion and CompletionCriterion? Are all the concepts of the method described using Essence?
4. MODELING NEXUS USING ESSENCE FRAMEWORK AND MAPPING APPROACH Nexus is a framework for developing and sustaining scaled product and software development initiatives [13]. It is modeled using Essence Language, Essence Kernel and the mapping process proposed in this paper. The steps of the process are not illustrated iteratively for the sake of simplicity. On the other hand, the process should be executed iteratively and incrementally until a satisfactory result is achieved.
Table 3. A sample property list an Alpha has States a WorkProduct has LevelOfDetails a Competency has CompetencyLevels
Review essentialized method: The essentialized method is reviewed and its quality is assessed. If the quality is not satisfactory, the essentialized method can be revised by iterating through the previous steps. The assessment of the essentialized method can be verified based on a checklist. The checklist can include verification of some properties and relationships which are important in Essence framework. A sample checklist is illustrated in Table 5.
Table 5. A sample checklist for essentialized method quality
Sub-Alpha of Opportunity
• • •
a Role is responsible for/accountable for/in charge of a WorkProduct a Role participates/takes part in an Activity a Role requires/needs/necessitates/involves a Competency an Action creates, reads, updates or deletes a WorkProduct an Action touches/affects/influences an Alpha an Activity is related to/have connection with an Activity an Activity is a part of/included in an ActivitySpace a State has a Checkpoint a LevelOfDetail has a Checkpoint an Activity has an Action
Nexus Guide [13] was read; the concepts were extracted and classified according to Essence concepts iteratively and incrementally. The output of the first two steps is illustrated in Table 6.
29
Table 7. Partial specification of Nexus practice
Table 6. Tentative list of Nexus concepts Extracted Concept Backlog Dependency Daily Scrum Definition of Done Development Work Integrated Increment Integration Issue Nexus Nexus Daily Scrum Nexus Integration Team Nexus Integration Team Member Nexus Sprint Backlog Nexus Sprint Goal Nexus Sprint Planning Nexus Sprint Retrospective Nexus Sprint Review Product Backlog Product Backlog Item Product Backlog Ordering Product Owner Refine Product Backlog Resolve Shared Challenges Scrum Master Shared Challenge Sprint Sprint Retrospective
Concept Category Dependency
Issue list Practice Event Team
Essence Concept Pattern (Dependency) Activity WorkProduct Sub-Alpha of Work Sub-Alpha of Software System WorkProduct Practice Activity Sub-Alpha of Team
Team member
Pattern (Role)
Task list
WorkProduct
Artifact Event
WorkProduct Activity
Event
Activity
Event
Activity
Requirements
Sub-Alpha of Requirements Sub-Alpha of Requirements Action
Event Artifact Work Increment
Requirements item Operation on an Artifact Team member Activity
practice Nexus: with objective “developing and sustaining scaled product and software development initiatives” extends practice Scrum owns { ESSENCE_kernel.Team contains 1 NexusIntegrationTeam alpha NexusIntegrationTeam: alpha IntegratedIncrement: workProduct NexusSprintBacklog: workProduct IntegrationIssue: pattern NexusIntegrationTeamMember: } activity NexusDailyScrum activity NexusSprintPlanning activity NexusSprintRetrospective activity NexusSprintReview
The states of alphas, the level of details of work products and competency levels are specified in the fourth step. For instance, a state of IntegratedIncrement alpha was identified and specified as illustrated in Table 8. Table 8. Partial specification of a state of IntegratedIncrement alpha alpha IntegratedIncrement: “represents sum of all integrated work completed by a Nexus” with states { state usable and potentially releasable { checks { item c1 {“Definition of Done is met.”} } } }
The associations are established between concepts at the fifth step. The WorkProductManifest concept is used for associating an alpha and a work product. In Table 9, NexusIntegrationTeam alpha is associated with IntegrationIssue work product using WorkProductManifest concept. The activities defined in Nexus guide are associated with standard activity spaces in Essence framework and illustrated in Table 9. Pattern concept in Essence framework can be used for specifying complex concepts such as a role, which is responsible for some work products and participates in some activities.
Pattern (Role) Activity
Activity
Activity
Team member Issue list Iteration Event
Pattern (Role) WorkProduct Sub-Alpha of Work Activity
Table 9. Partial specification of associations in Nexus workProductManifest { alpha NexusIntegrationTeam workProduct IntegrationIssue }
In the third step, these concepts are specified using Essence Language. A partial specification of Nexus practice in Essence Language is illustrated in Table 7. Nexus is built on Scrum [13] (specified using extends practice Scrum), thus only the concepts defined by Nexus Guide are included in specifications. Nexus is defined as a practice since methods in Essence framework are made up of the Kernel and practices guiding software development endeavor.
NexusDailyScrum part-of: ESSENCE_kernel.TrackProgress NexusSprintPlanning part-of: ESSENCE_kernel.CoordinateActivity NexusSprintRetrospective part-of: ESSENCE_kernel.SupporttheTeam NexusSprintReview part-of: ESSENCE_kernel.TrackProgress NexusSprintReview part-of: ESSENCE_kernel.EnsureStakeholderSatisfaction
A quality check was conducted at the last step. This step provided some insight on refining our model. After having a model with sufficient quality we concluded the mapping process. A quantitative measure for sufficient quality does not exist in our approach.
30
5. RELATED WORK
7. REFERENCES
Park modeled the activities and work products of Scrum based on Essence Framework Kernel [14]. The OMG specification titled “Kernel and Language for Software Engineering Methods (Essence)” includes an informative and partial example of a description of Scrum based on Essence framework [3]. This work extends these two by proposing a mapping process in order to define existing practices using Essence Language and Kernel.
[1] Wood, B., Pethia, R., Gold, L. R., and Firth, R. 1988. A Guide to the Assessment of Software Development Methods. Technical Report, CMU/SEI-88-TR-008. [2] Ivar Jacobson International 2015. Essentialization will aid learning, allow simpler & consistent development of extensions and more. https://www.ivarjacobson.com/publications/news/ijiworking-dsdm-essentialize-dsdm-framework (Access date: 17 January 2016)
Method engineering aims to design, construct, and adapt methods for the development of software systems [15]. A critical component of method engineering is a library of methods that contains standardized method building blocks [15]. The Essence framework forms a base for standardization and the mapping approach proposed in this paper addresses a systematic way of forming a library of methods.
[3] OMG 2015. Essence – Kernel and Language for Software Engineering Methods, Version 1.1. [4] Jacobson, I., Ng, P., McMahon, P. E., Spence, I., and Lidman, S. 2013. The Essence of Software Engineering. Addison-Wesley.
There are other metamodels proposed in the literature (five of them are summarized in [16]). The difference of Essence framework is that it provides some concepts at level 1 (see Figure 2) as well as a metamodel, thus it provides a common basic vocabulary for software development. This common basic vocabulary enables the standardization of method building blocks.
[5] OMG 2011. OMG Unified Modeling LanguageTM (OMG UML), Infrastructure, Version 2.4.1. [6] Atkinson, C. and Kühne, T. 2001. The Essence of Multilevel Metamodeling. In Proceedings of the 4th International Conference on The Unified Modeling Language, Modeling Languages, Concepts, and Tools (UML ’01), Martin Gogolla and Cris Kobryn (Eds.). Springer-Verlag, London, UK, UK, 19-33. DOI=http://dx.doi.org/10.1007/3-540-45441-1_3.
6. CONCLUSION There are many software development methods proposed in the last decades. It is important to understand, compare and combine these methods for tailoring a proper method for a unique software development project at hand. The Essence framework provides a base for unifying many different software development methods so that they can be better understood, compared, and combined. Although the Essence framework provides a specification for modeling methods, it is not trivial to map existing methods to Essence framework. Therefore, we proposed a systematic approach to essentialize methods. We applied our approach for mapping Nexus to Essence framework and experienced that our approach facilitates this mapping process. Especially having the knowledge on the ontological concepts of Essence makes the mapping process less complex and our draft lists for concept categories, properties, associations, quality checks provides guidance.
[7] Davis, R., Shrobe, H., and Szolovits, P. 1993. What is a Knowledge Representation?. AI Magazine 14, 1, 17 - 33. DOI=http://dx.doi.org/10.1609/aimag.v14i1.1029. [8] Gitzel, R., Ott, I., and Schader, M. 2007. Ontological Extension to the MOF Metamodel as a Basis for Code Generation. Computer Journal 50 (1), 93-115. [9] Assmann, U., Zschaler, S., and Wagner, G. 2006. Ontologies, Meta-models, and the Model-Driven Paradigm. In Ontologies for Software Engineering and Software Technology (Springer Berlin Heidelberg). 249-273. DOI=http://dx.doi.org/10.1007/3-540-34518-3_9. [10] Atkinson, C. and Kühne, T. 2008. Reducing accidental complexity in domain models. Software & Systems Modeling 7 (3), 345-359.
As a future work, we plan to essentialize more methods and improve our approach including concept, property, and association lists as well as a quality checklist. Moreover, we might identify some possible situations in which one concept of a practice can be mapped to many Essence concepts and propose some conflict resolution guideline for such situations.
[11] Wirfs-Brock, R., Wilkerson, and Wiener, L. 1990. Designing Object-oriented Software. Prentice-Hall, Inc. [12] Larman, C. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall, Inc.
Ability to build a new tailored method using existing methods is crucial for benefiting from existing knowledge and experience accumulation of software engineering. Having a library of methods mapped to Essence framework can serve as a standard library for reusing existing methods. Our effort to systematize mapping effort will also contribute to form such a method library.
[13] Schwaber, K. 2015. Nexus Guide, Version 1.1. [14] Park, J. S. 2015. Essence-Powered Scrum: A Generic Approach to Describing Practices Using Essence Kernel and Language”. 1st Conference on Essence in Practice, Berlin. [15] Brinkkemper, S. 1996. Method engineering: engineering of information systems development methods and tools. Information and Software Technology 38 (4), 275-280. DOI= http://dx.doi.org/10.1016/0950-5849(95)01059-9. [16] Henderson-Sellers, B. and Gonzalez-Perez, C. 2005. A comparison of four process metamodels and the creation of a new generic standard. Information and Software Technology, 47 (1), 49-65. DOI=http://dx.doi.org/10.1016/j.infsof.2004.06.001.
31
APPENDIX 1. ESSENCE LANGUAGE ELEMENTS AND THEIR EVALUATION ON REALWORLD CORRESPONDENCE
Compe tency
ActivitySpaceAndActivity
AlphaAndWorkProduct
Foundation
P.
Language Element
Evaluation
O.C.
BasicElement
It is an abstract superclass and has no real-world correspondence.
No
Checkpoint
It is a condition to be checked in a project and has a real-world correspondence.
Yes
ElementGroup
It is used for grouping concepts; it is an abstract superclass and has no real-world correspondence.
No
EndeavorAssociation
It is used for linking instances at level 0 and not related to a real-world concept at level 1 or 2.
No
EndeavorProperty
It is used for tracking individual properties of instances at level 0 and not related to a real-world concept at level 1 or 2.
No
ExtensionElement
It is used for language element extension and has no real-world correspondence.
No
Kernel
It defines important concepts that are general to everyone when working in that domain, like software engineering development. It is a logical grouping of real-world concepts.
Yes
LanguageElement
It is an abstract superclass and has no real-world correspondence.
No
Library
It is a container for element groups and has no real-world correspondence.
No
MergeResolution
It applies a resolution function to the conflicting attributes and has no real-world correspondence.
No
Method
It is the composition of a Kernel and a set of Practices to fulfill a specific purpose; it has a real-world correspondence.
Yes
Pattern
It is used for defining a structure of language elements. It can combine required competencies, responsibility of work products, and participation in activities into a structure called “Role”. Since it can combine elements with a real-world correspondence, it might represent an ontological concept, such as a role.
Yes
PatternAssociation
Since it might associate real-world concepts, it has a real-world correspondence.
Yes
Practice
It addresses a specific aspect of development or teamwork and has a real-world correspondence.
Yes
PracticeAsset
It is a container for language elements that are no element groups and has no real-world correspondence.
No
Resource
It is used for enriching method model with external materials and has no real-world correspondence.
No
Tag
It is a non-empty label that can be attached to a language element and has no real-world correspondence.
No
Alpha
They are subjects whose evolution we want to understand, monitor, direct, and control. They have a real-world correspondence.
Yes
AlphaAssociation
Alphas can be related to each other. These relationships have a real-world correspondence and illustrated with “associatedWith” relationship in the conceptual model.
Yes
AlphaContainment
It is used to represent a sub-alpha relationship. This relationship has a real-world correspondence and illustrated with “subclassOf” relationship in the conceptual model.
Yes
LevelOfDetail
It represents the amount of detail or range of content in a work product and has a real-world correspondence.
Yes
State
It represents the state of progress of an alpha and has a real-world correspondence.
Yes
WorkProduct
Work products are produced during a project and hence they have a real-world correspondence.
Yes
WorkProductManifest
It binds a work product to an alpha. This relationship has a real-world correspondence and illustrated with “isConcreteRepresentationOf” relationship in the conceptual model.
Yes
AbstractActivity
It is an abstract superclass and has no real-world correspondence.
No
Action
It is an operation performed by an activity on a particular work product and has a real-world correspondence.
Yes
ActionKind
It represents the kind of an action and has enumerated values. It is represented as an attribute of an action in the conceptual model.
Yes
Activity
It describes some work to be performed and has a real-world correspondence.
Yes
ActivityAssociation
It is used to represent a relationship or dependency between activities. This relationship has a real-world correspondence and illustrated with “relatedTo” relationship in the conceptual model.
Yes
ActivitySpace
It is a high-level abstraction representing “something to be done” and has a real-world correspondence.
Yes
Approach
It describes how a particular Activity is accomplished and has a real-world correspondence.
Yes
CompletionCriterion
The work of an activity or activity space is considered complete when its completion criteria are fulfilled. It has a realworld correspondence.
Yes
Criterion
It is an abstract class and represented with CompletionCriterion and EntryCriterion concrete classes in the conceptual model.
No
EntryCriterion
It must be satisfied before work of an activity can be started. It has a real-world correspondence.
Yes
Competency
It is used for defining a capability of being able to work in a specific area. It has a real-world correspondence.
Yes
CompetencyLevel
They are used to create a range of abilities from poor to excellent or small scale to large scale. It has a real-world correspondence.
Yes
32
