This is the main innovation introduced by Kephas Framework. In the common modeling world, one would define a model for a specific solution. And that is pretty much all. But what if that solution must be customized for different needs? There are not many options available. Now let’s complicate the things and say: hey, it would be nice to support aspects, such as security or logging. They are orthogonal to the default model and bring features that “melt” into the business model. And then all serious applications are modular, and layered (for example client, application server, data store).
How could that ever be manageable? We say: yes, it is possible. Think of modeling as taking place in a space, a model space. Then have a dimension for customization, one for modules, one for layers, and one for aspects. Modeling a solution is just modeling points in this space, assemble them later for a specific deployment, and voila, here you have it.
Sometimes the solution is complex enough to need more models: a model for the primary data, one for the data warehouse, and one for authentication. And then add another model for common concepts reused in the previously named models.
The developers may define packages with custom model elements which integrate seamlessly with the built-in ones. This is a powerful feature of the framework carefully designed to embrace the special needs of the developer. He may either extend the built-in model elements, or define completely new ones. For example one could define an OlapCube model element which would generate OLAP Cubes.
This is a common feature of the OOP, which is fully supported by Kephas Framework. By default all classifier members are virtual and may be overridden, except when the member is marked as sealed.
The inheritance is simple, each classifier being derived from at most one other classifier. However, a kind of multiple inheritance is provided by the mixins, as described below.
An interesting feature is that also simple types support inheritance. This is useful for example when defining a simple type Email : Text, which may add for example a RegEx constraint and a maximum length. Another useful feature is that every model element’s child element may be overridden, even attributes and nested classifiers.
The model elements are composable in the first place by defining parts in mergeable dimensions, as described earlier. However, the framework supports also mixins, as being model elements of the same kind as those including them which merge their content into the latter ones. The main difference from the inheritance is that the merged members may not be extended in the classifier including them.
Kephas Framework supports generics for classifiers and classifier operations.
The model may be persisted in a variety of ways. By default, Kephas Framework provides support for:
- CodeDOM definition: this is the preferred way for developers, because it has full support of the Visual Studio, including class diagrams, and this is the only supported way of providing executable code for example in case of operation definitions.
- XML definition: this is the preferred way for extending definitions without support for executable code. A good example is extending enumerations with custom values.
However, they are not exclusive, meaning that both definitions may be used at the same time, and their content is simply merged.