Skip to content

Concept Classification

Marcel Heinz edited this page Apr 4, 2017 · 11 revisions

In our technology models we want to relate to existing concepts denoted by common terminology.

func pic

Concept types

The following kinds of software concepts were identified up until now.

  • A Programming Domain is a 'problem space' corresponding to a field of study that defines common requirements, problems, terminology and ways for technologies or languages to support it (e.g., ModelDrivenEngineering or Metaprogramming).
  • A Technology Space is a 'solution space' corresponding to a field of study that is strongly related to a single instance of the following types: Technology, Language, Role, Construct, AbstractProcess and Paradigm. It contains software languages, programming tools such as IDEs, technologies, knowledge corpora, conferences and communities.
  • A Design Pattern is a reusable technology independent solution that formalizes a structural best practice solution for a certain motivated problem such as the expression problem. While a design pattern formalizes best practice solutions at the code level, an Architectural Pattern provides a reusable conceptual solution at a larger scale (typically the component level).
  • In our megamodels, we also want to relate to a field's or domain's terminology. In some informal documentation artifacts may be given a specific name that resembles its role in the system. We try to capture such terms as instances of Role. Examples are MDE-Models, MDE-Metamodels and Grammars.
  • We also intend to relate to programming-/language constructs. Such constructs are for example critical sections (see synchronized in Java), annotations or garbage collectors.
  • An Abstract Process is a commonly known technology- and language-independent process that can be informally described. For example, parsing relates to the process of analyzing concrete syntax and creating some abstract syntax as an intermediate representation.
  • All programming languages are typically classified by a Paradigm. A paradigm is a certain way of thinking that has implications on language semantics, available language constructs and usage benefits. For example, Object-oriented programming implies the existence of objects as roles and object graphs as constructs that have to be involved in the language semantics. It is supposed to be an intuitive way of thinking such that every thing can be formalized as an object.

Relations between Concepts

  • Design Pattern and Architectural Pattern provide structural relationships between structural conceptual parts or so called 'participants'. Such parts are essentially given a certain terminology that are essentially Roles. Thus, we can say that a role may be participantOf a design or architectural pattern, e.g., a model as defined in the context of MVC is participant of the MVC design pattern -- MVCModel participantOf Model-View-Controller.
  • Some concepts may only appear in the context of other more complex broad concepts. We speak of this kind of relation as a concept being an aspect of another.
    • A Role can be aspect of a programming domain, e.g., Database aspectOf DatabaseProgramming.
    • A Construct can be aspect of a programming domain, e.g., Cluster aspectOf ClusterComputing.
    • An AbstractProcess can be aspect of a programming domain, e.g., Parsing aspectOf MetaProgramming.
    • A Construct can be aspect of a paradigm, e.g., Semaphore aspectOf ConcurrentProgramming.
  • Several kinds of concepts can be further refined, such that a concept may be a more specific form of the other.
    • An abstract process can be refined, e.g., EndogeneousTransformation refines Transformation.
    • A construct can be refined, e.g., DistributedFileSystem refines FileSystem.
    • A paradigm can be refined, e.g., AspectOrientedProgramming refines ObjectOrientedProgramming.
    • A role can be refined, e.g., AttributeGrammar refines Grammar.
  • Two further kinds of refinement exist. Though, the refinement rather reduces a space for ProgrammingDomain and TechnologySpace.
    • We speak of a programming domain refining another as a programming domain being a subdomain of another.
    • We speak of a technology space refining another as one being a subspace of another.

Clone this wiki locally