Skip to content

The CodeModeler Meta Model

Jump to bottom
Simon Mourier edited this page Feb 19, 2020 · 1 revision

This topic presents SoftFluent CodeModeler modeling concepts

Software Factory

SoftFluent CodeModeler is a software factory. A software factory is an industrialization software which applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing.

Nowadays, most of software developments can be compared to a hand-crafted work which implies that the ratio development effort / produced software is dramatically lower than an industrialized production. In a hand-crafted development, the craftsman will develop his feature from scratch each time needed which outcomes in a time waste.

This is a commonly known issue, and a widely spread way to address this issue is developing frameworks. Instead of developing the feature again and again throughout projects, the feature is made generic and included in a framework so that this feature becomes reusable. Even though this approach is more productive on the long term than hand-crafted development, it creates, on a long term, possibly huge, hard to maintain and hard to evolve frameworks. Moreover, in scenarios where a software development needs one precise feature of the framework, it will have to drag the whole framework to benefit from the single given feature.

Finally, another solution to tackle the software productiveness issue, is the software factory development mode. A software factory is a software or a software product line which allows developers to industrialize software developments based on a software schema. In our case, CodeModeler is a model driven software factory which based on a model describing an application, will produce 100% functional components. To get back to our example, the feature is provided by the software factory which, if defined in the model, will be produced in the output software. This way, software developments are industrialized assuring shorter development cycles, a higher quality, and avoids dragging complex and/or large frameworks since only the desired features are used.

Comparison between software development modes are summed-up in the following diagram:

Software Factory

Global Concepts

  • Model Driven Development (MDD): CodeModeler is a model driven software factory, meaning that based on a model defining your business concepts and the desired technical architecture, CodeModeler will produce fully functional components. Moreover, CodeModeler is built so you can easily modify and rebuild your application. Hence, the model remains a core part of the developments. Among other benefits, driving developments by the CodeModeler model will ensure the model stays in synchronization with developments, this way providing an accurate, and up-to-date, overview of your software.

  • Platform Independent Model (PIM): CodeModeler models are platform independent. The architect focuses on defining the business concepts and desired features.

  • Platform Specific Model (PSM): nevertheless, CodeModeler models are also platform specific thanks to CodeModeler’s producer logic. Each producer produces platform specific and optimized code. In addition to the generated and optimized code, CodeModeler allows software architects to add custom, platform specific, code to CodeModeler models. This custom code will be inserted in the targeted specific output, thanks to its related producer.

  • Object-Relational Mapping (ORM): CodeModeler allows you to create a representation of real-world concepts that define or influence your software. It includes primary objects (entities) in the system, and relationships between those objects, the overall providing a logical representation between objects. Those objects will be produced into persistent objects in the database layer and into .NET objects in the business layer; and business layer objects are mapped on to the persistence layer objects. The business layer acts as a virtual object database where changes operated on them will reflect in the persistence layer as well.

  • Declarative Programming: CodeModeler is a Declarative Programming tool in which a software architect can define in a readable model of his software. This model is a complete and accurate representation of the business concepts, rules, and architecture of the software.

  • Aspect-Oriented Programming (AOP): CodeModeler allows software developers to define aspects of concepts and their properties regardless of their implementation. For instance, one can declare the aspect of an e-mail in his model and be assured the generated software, regardless of the technologies used and throughout all layers, will handle e-mails as defined.

OOP concepts

  • Entity: a business entity like 'Customer', 'Order', 'Cat', 'Dog', ...

  • Lightweight Entity: an entity representing a light object such as non-persistent objects, structures, etc. It can also be mapped to standard .NET types such as the Point structure or views.

  • Relation: describes the type of relation and cardinality between two entities. The relation can be 1:1, 1:M, M:1 or M:M.

  • Inheritance: an inheritance relationship describes the relationship between a super-type entity and its sub-type entities. An entity can have any number of ascendant or descendant entities.

  • Method: CodeModeler allows the definition of any method (standard C.R.U.D., custom load methods, snippet methods, external business rules, ...) associated with a given entity. Depending on configured producers, these methods may (or may not) be exposed as Services. For example, the Web Service producer creates by default a SOAP operation for every method in the model.

  • Property: an entity has a defined set of properties. Some properties are inherited from ascendant entities. Properties are also used as 'connectors' for relations between entities: if the property's type is an entity or the collection of an entity defined in the CodeModeler model, the property also defines a relation. The cardinality on this side of the relation is M (Many) if the property's type is a collection, 1 (One) if the property's type is an entity.

  • Parameter: every method can have zero to any number of parameters.

  • View: a view is a read only virtual or logical entity associated with a model entity, composed of view properties. Each view property is defined by an expression computed on the associated entity. Changing the data in an entity alters the data shown in the view. Every entity has at least one view, automatically created by CodeModeler, the Default view. This view's properties match the entity's properties.  At the persistence level, a view can be generated as a real SQL view.

  • View Property: a view has a defined set of view properties, just like an entity has a defined set of properties. View properties have almost the same characteristics as entities properties.

Persistence concepts

These concepts represent a logical database and are used (or not) by producers configured for persistence such as the SQL Server producer:

  • Store: every entity in the model is associated with a store. A store is only defined by its name. The store concept can be used by persistence-oriented producers to create multiple databases for one CodeModeler model. At production time, a store may be associated with a relational database or any other persistence mechanism.

  • Database: there is only one database per CodeModeler model. The database contains all tables and procedures. This concept is not related to relational databases.

  • Table: a table is a set of data elements (values) that is organized using a model of horizontal rows and vertical columns.

  • Column: a column of a table is a set of data values of a simple type, one for each row of the table. A column's type is always a Simple Type.

  • Constraint: a constraint defines conditions about a table that must remain true while modifying data in the database. CodeModeler has three types of constraints: Primary Key, Foreign Key, Default and Unique.

  • Procedure: a procedure represents a relational database stored procedure. CodeModeler represents procedures internally using an exclusive technology named SQLDom. One of the most interesting things about SQLDom is that it's completely SQL language-agnostic (just like CodeDom is for .NET languages). The SQLDom provides types that represent many common types of SQL code statements (SELECT. UPDATE, DELETE, ...). This object graph can be rendered as SQL source code for a specific target platform using persistence producers (such as the SQL Server producer). The CodeModeler View tool is also capable of displaying a pseudo representation of each procedure in the model.

  • View: a model view (defined in OOP concepts) can be optionally associated with a persistence view.

Object Model

The root object of the SoftFluent CodeModeler is the Project (represented by a .NET Project class): everything starts from it. From the Project class, you'll be able to manipulate the entire inferred meta-model:

  • the inferred business object model,

  • the inferred database.

Please note that at this stage, we're still manipulating platform independent concepts. The following diagram illustrates the main concepts available in the API to manipulate the inferred business object model:

Object Model

The following diagram illustrates the main concepts available in the API to manipulate the inferred database:

Persistence Object Model

Note: diagrams are not an exhaustive list of all available concepts.

Clone this wiki locally