-
Notifications
You must be signed in to change notification settings - Fork 5
Knowledge Levels
Let us start with a very basic thought. If we want to model a technology, what kind of knowledge can be reused? And what kind of knowledge is reusable when we switch to modeling a system (e.g., a project that uses the technology)?
Our core ontology consists of facts that are general for software engineering. Thus, instances appear in relationships for many different technologies. At this stage there are only hard facts that can be retrieved from information sources such as scientific contributions or encyclopedias like Wikipedia. For now, there are three parts that focus on core knowledge.
- Core Vocabulary: The module Prelude.megal declares the essential entity types and relationships to describe technologies.
- Language Classification: There are two separate modules on language classification. First, there is the module Language.megal that gives a schema on what kind of classifiers exist for a language. Second, the module LanguageKB.megal exorcises the relationships systematically for the languages detected so far, that are used by multiple technologies. Languages that are dependent on single technologies only appear in the technology's modules.
- Concept Classification: There are two separate modules on software concepts. First, the module Concept.megal defines the kind of conceptual entities relating to software concepts and their interrelationships. Second, the module ConceptKB.megal exorcises the relationships systematically for the software concepts that we encountered so far.
Now any model for a single technology can reuse the existing core knowledge, but from here on the facts may get more complicated. We also want to express things like: Whenever you use EMF as a technology in a concrete usage scenario, there exists some Ecore file that provides a metamodel.
?EMFApp : Application;
uses EMF.
?schema : Artifact;
elementOf EcoreXMI;
hasRole MdeMetamodel;
partOf ?EMFApp.
Such existential (or abstract) entities can only be introduced as instances of System, Technology, Artifact, Language (languages that only exist for single technologies or systems) and Node.
To describe a concrete scenario we want to make use of the existing core knowledge and the technology knowledge. On one hand, we want to show what kind of relationships exist. On the other hand, we also want to see how this fits to existential statements from the technology knowledge and possibly see whether we are using the technology in the 'right way'. To adress the existential statements we want to copy abstract entities and replace the abstract placeholders by our concrete entities that need to be linked. We do not intend to write the following block ourself as it would be kind of redundant, because the existential statements already exist.
MegaLXtext : Application; //In this case it's the system that we describe.
uses EMF.
megalEcore : Artifact;
elementOf EcoreXMI;
hasRole MdeMetamodel;
partOf MegaLXtext.
Instead we want to state in a new model that MegalXtext substitutes ?EMFApp and megalEcore substitutes ?schema. Here, several features come into play: An abstract entity may have to be substituted by multiple concrete entities. Other times, we want to replace some placeholder by an already existing entity from the core vocabulary.
As a guideline, we suggest that there are no new placeholder at this level in the knowledge hierarchy, since we only want to show where the linguistic pattern can be found in the real world. Introducing abstract elements hints at a description for another technology, but the levels should not be confused here.
- How to Megamodel
- Language Description
- Concrete Syntax
- Constraints
- Semantics
- Project How To's
- Install, Build, Test, Run
- Checker Tool
- Visualizer Tool