The way of how these semantic information are represented in the system vary according to the approach chosen (see below), common to these approaches are the following features:
- The semantics represent static facts, that is: facts that describe the domain in question at a given moment, and which do not change during runtime (as opposed to Semantic Web for instance)
- The system has native access to these semantic structures during compile time and runtime, and can interpret them in order to fulfill the requested features
- Clear separation from logic and implementation (where possible)
- In many cases, SOP supports the notion of Single Source of Truth (SSoT), such that every semantic concept is stored exactly once, Any possible linkages to this concept are by reference only
- A programmer can freely and quickly add new semantic meanings without breaking compatibility with the system environment
The goals of SOP are:
- Improving the maintainability of a software
- Improving the transparency of a software
- Flexibility by allowing exchangeability of logic and/or implementation
- Optimal support for agile development processes (refactoring)
Soplets is a method of describing semantic concepts as blocks of code, using existing features of the (Java) language, namely annotations and enumerations. Each block of code (called Soplet) represents all properties and features of a given concept (as far as reasonable and feasible), including features outside of the traditional modelling scope, such as translations, documentation, requirement tracking and so on.
Soplets can be referenced and used from anywhere inside the code. Given the strong-typed nature of the references they can be safely refactored as seen fit.
A Soplet may be exhanced by one or more (stateless) functions, which are directly attached to the code block. That way also related features related to a given concept (such as calculations, validation, transformations etc.) beyond pure key-value pairs may be associated with a given Soplet.
The structure of a Soplet is formally defined by the stereotype it implements. This stereotype may be individually composed of several aspects (such as Translatable, Beanable, Bindable, Testable etc.), which in turn may be freely defined by the developer (or which are part of a framework which he uses).
An open-source plugin (based on the Project Lombok plugin) allows the creation of byte-code during compile-time, based on the information contained in the Soplets. For instance, a data bean may have all of its attributes, getters and setters generated.
SymADE (Symbolic Adaptable Development Environment) is an open-source IDE and implementation of SOP (Semantic-oriented programming) paradigm.
In SymADE a program is edited and stored as a tree of semantic nodes (meanings). The tree is edited by structural editor, and programmers can edit either the semantic tree directly or a projection of the semantic tree onto syntax tree. There may be multiple projections of the same tree, and they can be rendered on the screen as reach text, as UML diagrams and so on.
Semantic meanings are completely user-defined. This allows to use SymADE for creating and editing new domain-specific languages, modify existing languages, use in the same piece of code a mix of multiple languages.
SymADE is common in spirit with IP and MPS. The main difference is that they define and edit syntax trees, but in SymADE you create and edit semantic trees. This gives an unbound possibility for automating code writing, i.e. the actual code can be written by computer based on dialog interaction with programmers. And of cause, the SymADE project is open-source, unlike proprietary IP and MPS development environments.
The higher automation of code writing will allow to create more complex programs without increasing the amount of abstraction layers - because the computer, not programmers, will take care of the code complexity. This will allow to write more complex programs without increasing resource requirements (CPU speed and memory size).
- Model-driven engineering
- Domain-specific languages
- Service-oriented programming
- Language-oriented programming
- Aspect-oriented programming
- Generative programming
- Intentional programming
- Automatic programming
- Resource-oriented architecture
- Transaction-level modeling