Definition

So how do you go about it? Your drawing board is blank, at least before you had code, methods, classes and a sea of internet documentation and forums for support.

Don’t worry, we’ll get to that. For now just fill it with this:

When you are able to answer each one of these questions, congratulations, you have a Pattern. If you put all the answers of all the Patterns together under the same technology, then you get a Model Driven Development platform.

• Model - This is what constitutes your model. Its name, what options does it have and how it relates to other patterns.

• Semantics - It's the meaning of those names, options and relations. Its a description of the expected result of your pattern and how the variables influence that result.

• Repository - It's the permanent format in which you will record your instances of that model. It's also the meta-model, the schema your model needs to follow.

• Interface - It's the API that you will allow for developers to view and edit your model, the constraints, validations and helpers.

• Artifacts - Are the group of resources for your result that never change. It's the boilerplate your developers were copying over and over again.

• Automation - Are the engines and processes you use to transform your model into actual working code with the help of the Artifacts.

As you can see, now, a Pattern is not a single thing. It’s a complete and autonomous body of knowledge. It’s the symbol, the meaning, the communication channel, the memory, the action and the consequences. It’s all those things together bundled into a coherent whole.

Patterns can associate together, as they can be composed by sub-patterns. An Entity has Fields, those Fields have Types, the Fields can be mandatory or unique, a List can use a Field and color it depending on the value of another Field. It's up to you to define your semantics of what happens when a Pattern associates with another Pattern.

Relation to coding languages

The main difference between a Pattern and a coding language is that its syntax is not closed, it evolves in terms of new keywords instead of new methods.

For example, in C#, the keywords if, for, class, public, static, are a closed set of things that language allows you to express, they correspond to bifurcations in code execution, cycles, object storage in memory, etc. When you start a new project or create a new API, the set of keywords you use are all the same, the language is all the same. You extend it by creating new methods and by defining new objects.

A Pattern is like going to one of those functions and object definitions and saying: “Well, now I will call you Entity Pattern” and that becomes a new keyword in your MDD system. So that, when you use it, the “model compiler” knows everything it needs to do. In other words, when you want your code to do more things you program more methods, when you want you model to do more things you give it more options: “My Entity can now support security access restrictions”.

Relation to diagram languages

On the other end of the traditional development stack, we have requirement diagrams like those produced with UML. The main difference between a Pattern and UML is that the Pattern's semantics are closed, once we draw that symbol, the implementation is concrete and complete, directly inferable from the meaning.

While UML started with the good intention of abstracting away the implementation details, its goal of being a general-purpose language quickly forced more and more extensions to the language, to an ever expanding symbol library, but the need for it to cater to the ambiguities of human description of requirements also had the effect of destroying a closed semantic meaning for UML. Each UML drawing is now open for interpretation and is not traceable to each of its implementations. The diagrams forgo being complete, for the sake of being understandable by "non tech people", and so it follows that there is no way to validate if a UML diagram "works" or not, nor is there a demand for it to do so.

A Pattern departs completely from a documentation goal and sets its eyes on the solution. It's not an abstraction of a concept, instead it's an abstraction of a real and implementable solution. The solution comes first, the Pattern comes later. Sure, as any abstraction, it can be reinterpreted later on, as you re-target it, but that just means that your Pattern describes 2 valid solutions, not zero.

Uniqueness

Patterns deserve a place among the developer vocabulary. They are not algorithms or code because they are descriptive, they are not documentation because they are not ambiguous, and they are not Design Patterns because they contain the actual implementation.

Many coding IDE's have generators that are akin to this notion of Pattern, using models like WSDL and Relational Diagrams to describe concrete implementations. But what they lack is a way for all the Patterns to come together and interact and become a fully fledged MDD platform.

Next

In the final Part 3 we will see how this definition can come alive into a MDD environment where your developers can spend their valuable time automating their Patterns instead of repeating the same development tasks.