MDriven The Book

Doing effective Business – by taking control of Information

Hans Karlsen, Stockholm, Sweden 2016-01-23

Part 1. Intro

What is MDriven

MDriven is software modeling, prototyping and execution made easy. You do not need to know Java or c# to fully
test your ideas for advanced information handling. You just need to learn how to model and you will get instant
gratification. If you already know c# or Java you will be amazed on how quickly you can verify your ideas with
MDriven compared to alternative prototyping schemes.

Furthermore MDriven can take you all the way to a finished system – in the cloud or on your server – with web
based user interface or/and with a rich client application.

MDriven is totally transparent in architecture and you will never lose control of your data.

With MDriven you can continuously progress systems easily making you truly agile.

MDriven is like having a software developer made of software – that does what you say really fast.

If you used to use excel to handle information, MDriven will strike as much more type safe, precise and efficient
way to get things done fast and to have things stay done.

If you used to write requirements for software with text, images and mockups, MDriven can change the way you
interact with stakeholders and developers – removing a lot of confusion and speeding up the process.

Modeling will make you think further and faster about information.

MDriven is free to use for up to 50 information classes – enough for even non trivial systems.

Introduction

As I have been working as a software developer and software architect in Sweden for the last 20 years I have
seen a lot. I am not going to bore you with my historic reflections at all.

That was my first attempt on an introduction for this book. Then I came to realize that most things we have done
with MDriven is very much anchored in the historic reflections of things we have experienced in the past. So
I guess what I need to say is more like this: Having worked many years as a software architect I have seen
a lot of things that change – but also very much that sort of stays the same over time – a stable core.

What is the stable core? The need to store and retrieve the information we are dealing with. The need to somehow
display it for users and handle users need to update it according to the rules we want to enforce. This is
the technology of any application or system and is what every system developer needs to deliver – using technology
modern at the time of implementation. I will refer to this as system modernity.

Furthermore we have the need to understand the business information in the system and how the rules that governs
the information’s evolution and consistency protection works. This part I will refer to as the system gist.

On the other hand we all know that in order to make our software sell – to an external market or to in-house
users - it must be perceived as modern and cool, but in the software business modern and cool change every
year or so, at least on the surface.

So mixing the system gist down into a format that is modern now but that will be obsolete in a couple of years
seems like something one should avoid.

It would be better if the system gist somehow could be separated from the currently modern implementation strategy
– which we know for sure will be less modern as time goes by.

This book is on how I suggest that we deal with system gist and system modernity.

Praise to UML

UML from Wikipedia: “The Unified Modeling Language (UML) is a general-purpose modeling language in the field
of software engineering, which is designed to provide a standard way to visualize the design of a system.

It was created and developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software during 1994–95,
with further development led by them through 1996.”

To fully convey my appreciation for UML I must explain how I look on the world.

Below I define three areas that will help to explain my reasoning.

Fashion: fashion is what goes together with what and if it is hot and sexy in the manner that people somehow
crave it without further need to understand it.

Modernity: I attribute modernity to ways to solve known problems. Tools and strategies have a modernity aspect.
A more modern tool is not necessarily better – but it often is since the new tool has had the advantage of
creation in a world that has more knowledge than the world that created the old tool

System gist: a system in this context is anything that combines a series of ideas and actions in order to produce
value. The gist of the system is the system description stripped from everything that is either fashion or
modernity as described above.

Let me exemplify these definitions. A car manufacturer is very much reliant on fashion. How the lines of the
car body appeals to the target audience is very important but almost totally based on feelings and soft aspects
that are hard to measure. The modernity aspect of car manufacturing is important for the manufacturing process.
What tools to use. How to apply industrial robots. What third party systems to include like anti-lock braking
and airbags. The system gist is captured in the design phase of the car construction process. It involves all
the inherited knowledge about what is important for cars in general and also some new things that are important
for this car model in particular.

Second example: A surgeon. Modernity provides important tools to diagnose a patient, like MRI. It also provides
ever better tools in fixing what is wrong, like with minimally invasive surgery. System gist is for the surgeon
the knowledge on what and where to cut and how and why organs act as they do. It is important for a surgeon
to be able to draw the intuitive line between gist and modernity. Having the latest tools will not be enough
if you are not educated in what to look for and how to act

upon what you find. As a patient you will want a surgeon that masters both gist and modernity, and does not neglect
one for the benefit of the other. When it comes to fashion it is important for the plastic surgeons – but they
too must have the main focus on gist and modernity or you will end up with a defect system. I know little about
the field of surgery but I am sure that if I knew more I would also see aspects of fashion in appendix removal
procedures. It might be how hi to cut and how to stitch the wound that has no immediate support in current
science but feels right or looks good.

Where is the software industry in this spectrum? The software industry differs from the two examples given by
not having ONE fixed or slow evolving system gist. Software industry is actually about producing new systems
and as such new areas that have gist, modernity and fashion of their own. The software industry is one Meta
level up compared to surgery or car manufacturing. It is in this way not just a human activity like surgery
but an activity of activities. This is what makes software development a field that will leave no other area
of human activity untouched.

Hundreds of new unique software systems are finalized every day and they will resemble each other when it comes
to modernity and fashion. What makes them each unique is mostly their system gist.

Look at what all the apps on mobile devices share: their execution environment, their use of the network, the
interaction patterns and widgets. Modernity and fashion is a time marker that makes it easy to guess the time
of construction for a particular software system.

The modernity aspect of software development is very important to be able to produce a well behaving system.
The fashion aspect of system development is very important to attract users and make the system intuitive to
use. These two areas, reused over and over, also evolve at a rather high pace. Refined strategies – or as I
call them – modernity aspects - on how to build software systems is a topic discussed endlessly in the developer
community.

It is easy for software developers to completely get lost in the modernity aspects. As they do they will leave
less room in their minds for system gist. When we get software developers that move cross field and mostly
work with modernity and fashion, is anyone taking care of the gist?

What sets one software system apart from another is mainly its gist not its modernity.

UML is all about system gist. This is why we need UML or something that solves the same problems. We use UML
to describe system gist in an easy, clear and partly visual format without any possibility for alternate interpretations.
UML is the most prominent way to handle system gist.

For a software engineer it is important to be able to quickly place arguments on design decisions in the correct
category. If it is about system gist then there will be facts to research in the domain of the system in order
to make the best decisions. Is it about modernity – then it is important to analyze best practices from the
development communities and consider the pace and gain of change to see which path to take. Is it about fashion
– stand back and let the end users or market decide. Take a vote if they do not reach a consensus.

Just as software frameworks – like Entity Framework, Hibernate or the like, aims to help developers with modernity
issues there are manufacturers of generic software systems that aim to solve everything. These are Meta systems
where you somehow can describe your system gist and then you would be done.

Since a meta system like this is a holy grail – the search for it engage many software companies. Of course many
claims are made that the grail is found. But is it really? And is there really such a thing as the holy grail
in the first place?

SharePoint is a tool that I have seen used like this on a number of occasions. As SharePoint may have an appealing
modernity and may be fashionable in certain populations it is an easy sell if it also lends itself to handle
ANY system gist.

As SharePoint is a software system it has a system gist of its own. One that may be described with UML.

As you see the gist of SharePoint is tiny. In fact the gist of a Meta systems often are tiny.

Alan Turing thought us in 1936 that one can build universal machines – a machine that can simulate all other
machines. Universality of machines is reached very fast as Stephen Wolfram showed us in his book “A new kind
of science (NKS)”-2002 where he suggest that a cellular automate of only two state and three colors is universal.
Alex Smith later proved this in 2007.

In light of this it is not surprising that the system gist of SharePoint is Universal – so it can be used to
implement any and all systems conceivable. This may seem fantastic – but just because something is possible
does not necessarily make it a good idea. It may for example be possible to build anything by gluing grains
of sands together under a microscope – but not practical or economical defensible.

Folding down the system gist into ListDefinitions in SharePoint is not the best way to treat the gist. In that
format it is not easily evolved and maintained. It is however possible, I do not question that.

My opinion is that the best way currently available to describe system gist is UML using the language of the
domain. Refrain from building Meta systems.

Accept that each area of human activity has its own gist that deserves its own UML description. When each area
has its own gist clearly described in UML it is easy to maintain and evolve. Free from modernity and fashion
issues.

I wish all developers would be aware of the three different areas of gist, modernity and fashion. It is my belief
that we limit our ability to develop everything due to lack of focus and lack of discussion on system gist.
Having a language for the gist opens up for discussions and thinking that helps development in all areas of
human activity.

What if UML was forbidden?

If UML or other structured ways to define system gist was forbidden – what would happen then. Maybe UML need
not be forbidden – the effect would be the same if UML simply was not used.

Well the system gist still exists – even if it is not explicitly documented. It must be extractable from the
source code of any running system since the system is a transformation of the system gist any how that gist
was captured in the first place.

Maybe the system gist is held in documents that outline requirements or prose text that describe scenarios that
the system should solve or support with. Maybe the developers were obligated to write other prose documents
that act as the documentation of the produced software.

To document software is boring compared to coding for any developer. Code can be compiled and type checked so
that bugs in it can be removed. Code can also be executed and further tested to ensure that the idea we wanted
to cover really is covered. Documentation does not work that way.

Most likely any existing documentation is filled with bugs beyond belief since the process of verifying lacks
compilation and testing. Since developers suspect this, developers seldom trust and seldom consult documentation
for existing software systems. Instead they have a tendency to go to code. If the only option is prose documents
they are probably correct. Even if the developer finds information in the code – it is important to remember
that the code is just the original developer’s interpretation of the requirement – and this need not be equal
to the requirement. Software tools and libraries may follow other rules – but when an experienced developer
is confronted with a software system he or she very seldom expect that the documentation is complete or correct.

Prose documentation of system-gist is by the reasons stated above almost never used for anything except making
the stakeholders feel a bit safe – like life jackets on an airliner – that fly over land – it was never intended
to help anyone – but the stakeholders want it so we provide it.

Another way I have come across to protect and keep the knowhow that is the system gist is what I would describe
as “invest in the team”.

Let the skilled and motivated software developers solve things with their talent and memory. Let the collective
team memory be your knowhow and documentation of the system gist.

This is the common way for most businesses that produce software that I have come across. I argue that this is
not a strategy. It is an abdication of ownership and control. Developers might not see this as a problem at
first since they take pride in the trust management place in them.

Still I have seen many cases where this strategy over the years create a chasm between the ones that know (developers)
and the ones that make decisions (management) – it usually ends with a collapse that benefits no one. Since
developers now are left on their own to decide where the resources should go – into system gist or into modernity
or maybe into fashion. They will soon lose the managements trust since management lacks control and does not
understand why the developers chose to prioritize the way they do.

Nevertheless this is commonly how small and midsized businesses handle their software investments today. Let
the code speak for itself – there is no other representation of the ideas within the software than the code
itself. The very same code that is strongly flavored by the team members take on what is modern and what is
fashionable this year – or was – last year.

Luckily UML is NOT forbidden

For prose document writers and for nothing but code cowboys there is a missing link – a way to describe system
gist separated from the flavor of the year implementation method in a format that is not as flimsy and open
to interpretation as prose documents.

What I propose here and what many has proposed before me is that we can document with models. The models are
more descriptive than prose text and leave less room for alternate interpretations. At the same time models
are less complex and easier to read than code written in the flavor and style of the year.

The model is then home of the system gist. Here it can be understood, discussed, criticized and evolved long
before it has taken the expensive form of implementation code.

What is somewhat new in what I say is that Models can be compiled and executed just like code. We can then focus
on using the currently modern technique to execute the model. This way the modeled solution can have a much
longer lifespan than the user interface or delivery method that are heavily subjected to modernity and fashion.

Models can cover the uniqueness and true solution of your software.

A model executer brings your model to life in a specific environment. When one model executer goes out of style
and something new is requested by the market – we do not rewrite the system gist – we create a new model executer
– and feed it the very same model.

MDriven is the latest model executer we have done – but we have been involved in doing many. A model that was
executed with Delphi 1999 (BoldSoft) can be executed with c# MVC5 or with WPF (CapableObjects) today. It was
executed with Windows Forms in 2003 (Borland, Embarcadero), with Silverlight in 2007, with ASP.NET in 2005.
No doubt will there be new model executers when modernity so requires – and sure enough MDriven Turnkey that
brings any system gist to AngularJS is currently available.

One key to a good investment in software is to avoid entangling things that change for different reasons and
with different intervals and speed. Your system gist change and evolve along with the business it supports.
The modernity of the solution changes by market forces no one can control but everyone must adapt to.

I propose that we should keep these two areas apart so that they do not get confused as being the one and same
problem.

Model driven development is by me defined as: develop system gist in its own machine readable format. Build a
software machine that turns the system gist into a complete software system and fulfills the required modernity
aspects. Giving such a machine a descriptive name: ModernGistExecuter – we at CapableObjects call our implementation
MDriven Framework.

What is not to like?

Having worked with model driven development for the last 20 years I have many times been surprised on how much
resistance we have met. It is not like other developers are indifferent or do not care. Many do care – but
the reactions are surprisingly often skeptical and negative.

We have tried to take this as an indication that we are on to something relevant and beautiful. Big and disruptive
shifts never come without agony and pain. The suggestion is that it is a defense mechanism that kicks in. People
are afraid that model driven development will change their current set up – and resistance to change is natural
and triggers unconsciously.

I do not believe in the anti-change theory. I think it is a simple case of not correctly separating the different
issues at hand: modernity versus gist.

Developers know that everything changes. Experienced developers have been left stranded with abandoned techniques
and products thru out their careers. It is not a good feeling and it is not good for business or the credibility
of the developers. No one likes to be forced into change by external influence, but a product that has lost
new development and support must be replaced. This has led most developers into a minimalistic approach when
it comes to using products. Minimalistic or gigantic – trust only the really big companies in software like
Microsoft or Oracle – and things that are transparent like open source and simple tools.

The problem with traditional development that blends and mixes modernity with system gist is that change hits
so hard. Everything must be rewritten once a technology change is required. If the gist changes a lot – rewrite,
if the modernity changes a lot – rewrite, if the fashion changes heavily – rewrite. There are more reasons
to abandon made investments than what any investor dare to think about. All this because of the mix up of the
three different areas.

If we separate the gist from modernity we will find that most changes in technology leave the gist untouched.
In fact all different types of gist will be handled by many different approaches and technologies over its
lifetime. For this we can plan from the start.

Since few have had the opportunity to try this in real life, few know the benefits it brings.

Separating the gist from modernity protects that part of the system from the IT-wind-of-change that is always
blowing at hurricane strength. At the same time free up the modernity area to change without having to change
all the gist stuff at the same time. Both areas will win by keeping this separation.

As an information architect or developer of domain work organization, the gist is the most interesting area.
It is the theory and motive. This is also were the structural capital of the enterprise resides. Having this
documented in a useful and actively maintained format is very attractive to any business.

For classic software architecture Modernity is extremely important as it ties into the projected lifespan of
the system, maintainability, how hard it is to build, usability concerns, security, efficiency and overall
investment sanity like “our maintenance burden must not be to disparate”. However for a business wanting to
build in house systems in order to become more automated the modernity aspect is still important but they should
put system gist in the front seat. It will be good for the whole business to structure their knowledge of whom
they are and how they do things.

I agree that if you use no tools to manage your gist it is easier to just mix gist and modernity together and
let it stew. Then sit back and wait for the inevitable rewrite need that forces you do it all again. I propose
that this is the wrong approach and an approach that is not very smart or efficient.

Looking back on many discussions over the years I now believe that a lot of developers and software architects
do not separate the system gist area from modernity with enough clarity. Many software developers also focus
mainly on modernity issues – after all as a professional developer this is what you can reuse for different
clients that all have different gist. I believe that this limits their ability to produce robust long term
systems. I suspect that this is part of the explanation why software development has to low success rate. It
can also explain why legacy ERP systems that are so far from modernity that it hurts still have an appeal on
the industry.

It is my belief that we must be vigilant to correctly identify modernity and fashion arguments when solving system
gist problems. If not, people will wrongfully let modernity or fashion arguments color their gist and by doing
so confuse both other developers and stakeholders.

This book is primarily on how to use MDriven to handle and manage gist and secondary on how to use MDriven to
help you manage modernity. I will show how the modernity issues are managed with standard techniques in Visual
Studio with no limitations or assumptions – so that you are ready for all new modernity requirements that will
be sailing up. Lastly this book will cover how the gist and modernity offered by MDriven Framework easily is
dressed up with the current fashion.

What is next

I propose and will show examples of how you can maintain the gist and idea of your software in a model – and
a how you can apply existing or create your own model execution engines to act as modern and current delivery
mechanisms for your solutions.

The steady pace of shifts in the markets perceptions on what is new and cool often paralyze companies from building
support systems and with them control their information. The main problem is that most techniques today mix
the two different problems of system gist and modernity. Entangling these two problems makes solving them as
one hard and risky and something that many businesses will avoid.

To summarize: Model centric – describe the system gist in a model that use a model executer of correct modernity
level to bring it to life. The model is then the documentation, the knowhow and the gist of the system– invest
heavily in this. Put modernity and fashion in the model executer and into user interface and delivery –invest
in this too but keep in mind it may change soon. Make sure you involve management in the system gist governance
so that they are in control and can take informed decisions.

The series of tools and strategies presented here reduce the effort needed for business to take control of and
own their information. It does so by introducing a clear separation between system gist and modernity.

It is my belief that companies that own and control their information are better equipped to compete than companies
that are clueless to it. A no brainer of course – but still – most companies lack a good and deep understanding
of their information. The few that have control often spend too much resource trying to evolve system gist
and modernity in one complex and risky process.

It is the aim of the tools and strategies presented in this book to show new ways to produce and maintain domain
specific software support systems – and to vastly reduce the costs and increase the quality and speed on how
to produce and maintain them. It is not magic – it is just a matter of raising the abstraction level a bit
and refrain from entangling problems that are much better solved separately.

Part 2. Design

Information design

I claim that for understanding a business you should understand its information – what they deal with – the information
they create while they produce their product. Others may argue that the processes are the most important part
– but I differ – if you first know the information you know – or can figure out - what processes must be present
that creates this information. If you just know the processes you still do not really know the information.

As a software architect you can use the phrase “follow the information” in the same sense as detectives of crime
use “follow the money”. You will find the truth this way.

When you follow information it is easy for all to see if it is valuable information or not, but when following
processes you track work that is performed currently. Suppose you found an unneeded process step – how will
you know that it is unneeded? You cannot get a correct answer from the ones performing it now – since they
are biased that it is important - and no one else will have enough information to really know.

If you first learn the important information you can easily see what the process step at hand does to that information.
It should evolve the information in some way. If it does not create or change information in a valuable way
the process step is unnecessary – for this business at least.

The information

There are many ways to describe Information. My recommendation is UML – the Unified Modeling Language. UML contains
a few set of rules – and it lets you describe everything you need without further need for interpretation.
UML is the core defining the models available in MDriven. This book will use UML extensively.

Short introduction to UML– class diagram

UML class diagram is the preferred way to describe the statics of information.

A UML class diagram shows classes and their relations.

A Class differs from an Object. The Object is of a Class. The Class may have many instance objects each being
of the Class. “Instance” and “object” are treated as interchangeable in this document – they both mean an object
instance of a class.

Class can be regarded as the “Concept” of something. Like if I have class named “Car” – it is likely to symbolize
the fact that there are Cars and Car is a concept that exists and that there are probably instance objects
of this class as “my car”, “your car” and the car with license plate ABC.

A class typically has attributes. One attribute of Car might be License plate number. Attributes must have types.
Typical types are string, integer, double, Boolean and datetime.

This means that once we have objects of class Car – these objects will have a place to store the License plate
number of that particular car.

Classes typically has relations to other classes (relation, association, link are sort of synonyms and can be
used interchangeably)

A relation has two endpoints. An endpoint has a name. When you read a class diagram and your eye follow a relation
you should use the name on the far side of the relation. So in this example I would say: “There is the concept
of Car. Cars have LicensePlate strings. Cars also point out the BrandOfTheCar with a Name”.

If I was talking about brand – looking on the model from another direction: “There is the concept of Brand. Brand
has a name. Brands also have Cars of the brand that in turn has LicensePlates”.

Relation endpoints also have Cardinality. Cardinality is a rule that describes how many instances there can be
in the relation endpoint. The cardinality marking of star (*) means “unlimited”. Valid cardinality markings
are: 0..1 (zero or one instance allowed), 1 (must always have 1 instance), y..x or x where y and x is any number
or x is star (*).

This was the basics of UML – there are more of course – but this is what you need to get started.

How do I know if it is correct?

The classes we have defined above – along with their attributes and associations – constitute a model.

A model is always a model of something. A model is simplified version of the reality concepts that you model.
The model should have a purpose. The validity of the model comes from if it fulfills its purpose or not.

There is no universal right or wrong – it all depends on what your needs are.

I could just as well have said that the Brand was an attribute of Car.

I chose not to since I do not want to have the brand “Plymouth” repeated 10 million times, once on each and every
“Plymouth” (if there are 10 million Plymouth car objects).

Instead I rather just see “Plymouth” typed in once – in the brand class name property (property and attribute
are essentially synonyms). This pattern – to classify attributes as being concepts of their own I refer to
as the value store pattern. The Brand class is the ValueStore of brands and at most 1 brand tags each Car instance.

For me – in this situation – this is better – but it is not more correct:

The process of modeling is a process of describing the important things. As you model you will have classes that
represent physical objects, like Car, but also abstract things like Brand. This is perfectly normal.

This way of describing information does not dictate that you follow the language of the domain you are modeling
or not. In principle you could have named the class Car for “A” and the class Brand for “B”. You could then
document someplace else that A is actually Car and B is actually Brand.

You may think that this was a very silly example. Still thousands of system implementations use that strategy.
Sometimes it is due to some limitation of the implementation tools and sometimes it is an ambition to make
the resulting system more generic.

Think of SAP for example – they may call a class “Part” – and document someplace else that for a particular system
instance Part means either a gear or a frame or a saddle.

So if the will to make systems more generic makes your model less readable and more abstract than your reality
is –is there an alternative?

The alternative is called Domain Driven Design (or DDD for short) – Eric Evans defined this in
the book Domain-Driven Design
. In short it stipulates that you should use the language of the domain you are modeling. This way you
– the modeler – and the people working in the domain – get a ubiquitous language and as a result you understand
each other better. In turn this makes it much easier to build software systems.

My experience is that being as close as possible to the language used by the domain is beneficial to everyone.
It makes everything much clearer and easier. Most information architects has done this long before it was given
the name DDD.

Association classes

Associations define relationship between Classes. Whenever you need some additional information on that relationship
an association class will come in handy.

Model 1:

Even if the Association class is mostly used for many to many relationships, you can just as well use them on
association of any cardinality.

Model 2:

OR-mapping (the process of taking an object oriented model (a standard UML class diagram) and transform it to
a relational database schema (tables, fields, primary and foreign keys) ) will turn this model into three tables;
one to store Person, one to store Flight and one to store Booking.

If you had not used the association class, OR-mapping would still create three tables due to the many to many
association. The third table would store two foreign keys, one to identify the Person and one to identify the
Flight. The third table will implicitly be named, if you did not explicitly give it a name, to PersonFlight
or FlightPerson. This table the DB-guys often refer to as a link table.

The funny thing is that modeling another way will give the exact same OR-Mapping result:

Model 3:

This will also end up in the database as three tables where Booking points out Person and Flight with one foreign
key for each. So for a DB-centric-guy this is the same… To an OO-Guy this is NOT the same.

What is the difference

The rules that association classes adhere to in any well behaving MDD framework are these:

1. Lifetime control; the booking cannot be explicitly created. It is created as a consequence of associating
a Person with a Flight: aPerson.Flights.Add(aFlight). And it is destroyed automatically whenever the association
is removed: aPerson.Flights.Remove(aFlight)

2. Uniqueness; In UML one instance must be unique in the relation, you cannot add one person to a flight
twice. This way the use of the association class has effectively given the UML reader the information that
a person can only be one passenger at a time and not two.

So whenever you see the need for lifetime control and uniqueness you should use the association class. It will
help the reader and it will help the developer.

Inheritance

UML inheritance is different from “I get your stuff when you die”. It is also different from “Oh look that kid
really looks like her Mother”.

UML inheritance is this: “A child class has all attributes and associations that a parent class has, and the
child also has attributes and/or associations of its own that the parent does not have”. In other words UML
inheritance is “specialization” and “generalization”; a child class is a “specialized” version of the parent,
and a parent is a more “generalized” definition of the child class.

UML inheritance is the same as OO-inheritance (Object oriented inheritance).

UML inheritance will allow you to inherit the properties of multiple parents – but very few OO-languages allow
for, so called, multiple inheritance (c++ does, c# and Java does not, and since we focus on the latter languages
we do not support it either), so I will not mention multiple inheritance again. This means that a class can
only have one parent class (or no parent class of course, but never many parents).

An example

Fruit is pretty generic class. If we think of specializations of fruit we will find apple, orange, pear, banana,
pineapple etc.

The lines ending with the big arrow is called a Generalization-association, meaning that if you follow it you
get something more generalized of the class that you leave. If you follow it in the other direction you get
the opposite of generalization, namely specialization. You will notice in MDriven Designer that when you add
a generalization association, the class’s superclass is updated in the object inspector.

Superclass is a more correct UML term than “Parent class”. Instead of “Child class” the correct UML terminology
is Subclass. Therefore, I will use Super- and Subclass from now and on.

Why is inheritance useful?

The obvious benefit of inheritance is the ability to introduce common properties that all fruit have in one place.
If there are properties that all fruit have they will go into the Fruit class rather than defining them over
and over in the subclasses.

The true power of inheritance is that it resembles how people reason and think. As humans we always generalize.
Our language and communication depends on it. This fact is the reason for some bad things in society – prejudice
where we jump to conclusions based on earlier experience or hearsay, and some good things – that we instantly
know how to use a door knob even if we have never seen that particular type of door knob before.

Polymorphism

Polymorphism is a fancy word for an important concept: poly==many, morph==shape => many shapes. In our example
we use polymorphism in the association from country to fruit; namely a resulting list that can contain different
subclasses of fruit – apples and oranges etc.

Polymorphism allows us to operate on stuff we do not really know that much about. Check this out:

I add a method on fruit that I make virtual:

I can implement this to return a default value on Fruit and override it on the subclasses that should return
a different value:

I also want to mention the concept of “Abstract”. When we have a model like the one above you should really think
of the Fruit class as being abstract – meaning that having an instance of a fruit (a real fruit) that is just
of type Fruit should not be legal. A fruit-instance must be one of the subclasses; it can be an Apple, Pear,
Orange, Banana or PineApple (in our model) but never just “Fruit”. Because Fruit is an abstraction.

In Object orientation terms Abstract means that the compiler will treat any attempt to create an instance as
an error. It is an error because the developer that defined the class never intended it for direct use; it
was designed as an abstraction or generalization of a set of subclasses.

My recommendation is to always treat classes that has subclasses (aka is a superclass) as being abstract. In
the Fruit sample above this might be obvious, but remember this when you classify your domain where it might
not be so obvious.

Composite and Aggregate and what they imply

Associations between classes are easy enough to understand; Car has 4 wheels

But in the information system we build it may be obvious that a Car owns all its Wheels; the car and all its
wheels can be looked at as a complete entity of its own - a composite. If the Car is scrapped, the wheels are
also implicitly thrown away. A Composite in UML is created by decorating the association with a filled diamond:

For any well behaving MDD tool this decoration should imply a cascading delete of all associated wheels when
the Car is deleted.

A composite also signals to the UML reader that the Car and Wheels are created at the same time, and that they
may not be meaningful on their own. So some will argue that the model should be changed from “0..1 Car” to
“1 Car” (i.e wheel must always belong to exactly one car):

On the other hand this might not be the best idea for just the domain we are modeling now. If the system we build
is one that describes a garbage sorting facility we may want to say: “Yes a car often has wheels, and the car
and its wheels can be looked as an entity of its own (a composite), but we sometimes want to take this composite
apart and treat the parts separated”. If this is the case the
aggregate decoration can be used:

The aggregation symbol signals to the UML reader that the connection between Car and Wheel is “strong and common”
and that “Car owns wheels” is more appropriate to the domain than “Wheel owns Car” (this also applies to the
composite symbol) .

A well behaving MDD tool should probably prohibit the deletion of a Car until the Wheels are gone.

So that the scrap yard guys does not delete a car while the valuable wheels are still on it.

To sum it up: Composite is stronger than Aggregate; both symbols imply that the domain sometimes look on
the classes as a bigger unit. The symbols help the UML reader to understand the larger compositions in the
domain. The symbols imply specific destruction behavior to good behaving model driven development frameworks
(MDD-Frameworks).

To sum it up:

Each Association end in MDriven has the “Delete Action” property:

The DeleteAction can be set to one of these values:

DeleteAction on the Wheels association

Calling Car.AsIObject().Delete()

Allow

will work even if you have wheels left on the car, but the wheels will be left dangling

Prohibit

will not work as long as you have wheels on the car

Cascade

will delete any remaining wheels

<Default>

If the association end is Composite treat as Cascade, if the association end is Aggregate treat as Prohibit,
if the association end has no aggregation treat as Allow

The recommendation is to leave the DeleteAction on <Default> and use the Aggregation setting to control
the delete action AND help UML readers to understand the domain.

Derived attributes & associations

Derived attributes is an important concept of MDriven. To a SQL-guy derived attributes resemble calculated fields.
Derived attributes are just like calculated fields that subscribe to all the values that it is calculated from.
So whenever data, seen by the expression, is changed the derived attribute is marked as out of date. The next
time you or your UI tries to read it, the attribute is re-evaluated.

The key thing with derived attributes is that it is NOT calculated each time you access the attribute. If it
were performance would suffer. It is calculated (or derived) as few times as theoretical possibly; only when
read the first time after a change of anything that the derivation expression looks at.

The concept of derivation relies on the concept of subscription – everything in your domain layer has the ability
to signal whenever it is changed (the publisher pattern), and subscribers subscribe to publishers to detect
these changes. Although this is a different story I must mention that publishing events to catch changes is
a key difference between the MDriven approach to implementing a domain layer and the POCO way (plain old c#-objects)
like NHibernate and some other frameworks use.

Having a model as the one above I can create a derived attribute on the Order that calculates the total shipping
cost by checking the products ordered and the customer’s country in OCL:

do this by creating a new Attribute, set the AttributeMode to Derived and fill in the DerivationOCL.

Derived attributes can be used in other derivation expressions so I can make a derived TotalCost without repeating
the definition of the Shipping cost:

self.OrderItems.Product.Price->Sum() + self.ShippingCost

Derived attributes are efficient and always return the correct up to date result. Associations can also be derived
the same way as attributes.

In the example model above the Shipping cost is out of date if you add a new orderline, if you change the customer,
if the customer changes country, if an already picked ProductThatNeedsShipping gets an updated weight etc –
it covers every and any change that effects the calculation as long as that change is part of your domain layer.

I hope that you see the positive effect this will have on your UI implementations – Showing the ShippingCost
and see it update as you change anything it depends on by one central definition in the system gist far away
from the UI where we rely on modernity and fashion.

Using derived attributes and derived associations clean up your code and consolidates central definitions to
single points and thus greatly reduce maintenance costs and efforts. Having the definition in OCL also makes
the derivation a part of the documentation – the model – rather than just the implementation.

UML – State machines

If the classes of your model define the statics we are now left with dealing with the dynamics of the domain.
With the dynamics I mean all the “state” and “rules” that any instance object defined by a class in your model
might have.

This is where UML introduce the State Machine. A state machine helps us to describe the different allowed states
an object can be in and how it is transitioned between these states.

For the Car class in the model I choose to model the state machine above.

Each box is a State. A state has a name. A state can have transitions moving into it or out from it. To initiate
a transition out of a state and land in another state we must use a trigger. A trigger is a method of the class
that performs all actions associated with moving from one state to another. In order to be allowed to execute
a trigger we must first be in an action where this trigger can be used.

State machines can make the dynamics of the information in your model much more accessible. Having the rules
that the state machine implies also remove the need for a lot of other means to make sure that the information
does not end up in illegal states.

The current state is stored in the attribute named state in this case. But a class can have multiple state attributes
(named differently) – just as objects in real world follow different state machines depending on perspective.
The perspective I have chosen above might be called LifeTimeState. And maybe there is another state attribute
called CleanlinessState.

You can implement many business rules in state machines like these. Consider that your domain has a rule “Do
not start production until deposit is paid”. I would go about it like this:

and a Guard on the state machine:

The language used to declare the guard is called
OCL – Object Constraint Language . It is a languages that allows you to navigate your model. So you can
easily make more complex rules. Consider that the Brand must be set before we start production:

“self.DepositPaid and self.TheBrandOfTheCar->notEmpty”

OCL makes heavy use your model and the rule is just as clear as your model is – using the language of the domain.

You can also define Entry and Exit actions that execute when you enter one state and leave another.

Like this:

Constraints

There are other ways to introduce business rules in the model than using state machines and guards. You can also
use constraints. The model already has a lot of implicit constraints from the cardinalities of the association
ends. Like if you have cardinality of 1..4 and you have zero objects in that relation – then you have a broken
constraint.

But you may also define your own constraints:

You can choose if a broken constraint (a constraint that evaluates to false) should be treated as Information,
Warning or an Error to the user.

You can also define the constraint as being a delete constraint only:

This way we have explained at the model level that the domain does not consider it to be ok to delete a Car-object
as long as we have the deposit – unless it is in state Scrapped.

The delete constraints will be checked when the object is Deleted by MDriven – as a result of the Delete operator
is executed on the object.

Other things that are checked when the Delete operator is run are the BusinessDeleteRules that exists on all
association endpoints:

We as modelers should decide what the best rule is for each association end. In this case – is it ok to delete
a Brand if there are Cars left in the AllCarsOfThisBrand association? No I think not. I am setting it to “MustBeEmpty”.

The association in the other direct on the other hand

I set that to “NeedNotBeEmptyNoWarning” – because deleting a car-object is ok even if it has a brand.

Part 3. ViewModels the declarative way

The ViewModel

It is a common problem that User Interface (UI) code gets filled with business logic that does not belong there.
The logic is often left there as a quick fix and the developer has every intention to someday return and clean
it all up by refactoring the code so that business rules are handle by the model and the UI only handles the
user interaction. This actually never happens. I have never seen a team that has enough room in their schedule
to go back and redo work that to the client is already done, delivered and paid for.

Every developer knows that the degrees of freedom rapidly decrease once you fill your UI with business logic:

You cannot easily reuse the logic placed in a UI so you copy it and increase the maintenance (BAD!)

You forget about rules placed in UI so your system gets a life of its own (BAD!)

Once you have logic in the UI you cannot be expected to know it all so you get afraid to make changes to your
system because something will or may break (BAD!)

You dare not give the UI to that brilliant designer because the designer will break logic for sure (BAD!)

Still I see business logic in the UI everywhere I go. When I ask about it I always get answers like: “Well this
is not finished yet”, or “Well this is really special stuff, only used in one place”, or “Yea I know it sucks,
I will fix that later”. But “Later” never comes, does it? It will always be just “Later”.

I am no superman for sure. I see business logic in UI code I have written myself too.

If everyone or at least most of us is getting into these situations could it be that we are doing things the
wrong way? Could it be that doing things the right way is just a tad bit too complicated?

These are some strategies to make developers do the correct thing and actually follow the coding guidelines:

Automated review tools like FXCop

Adhere very strictly to ModelView patterns as MVVC or MVC – but still you need to verify that you follow the
pattern

Peer review (that usually will be done “later”)

Some other strategy that will force violators (you and me) to mend our ways – even if the correct way is really
complicated (maniac team leader with rabies foam in the face)

Make it easier and faster to follow the “coding guidelines” then to be quick and dirty.

To no surprise I am in favor of making things easier. To be able to make things easier we need to understand
what cause things to go wrong in the first place: Why is the UI filling up with business logic? I think there
are a couple of reasons, depending on how far you are from being model driven some of these reasons will apply:

The UI will need to transform data (could be business logic) in order to display it according to specification.

Actions performed in UI act on selections from UI-components, that has data in the transformed presentation
format, and need to be transformed back (could be business logic) to model-scope in order to let the model
work on the data (business logic). You also need to check that the parameters sent to the model method are
valid (could be business logic).

The existing business logic may not match 100% what your action should do, you may want to call two, three
of more methods to get the job done (new business logic) and you want to do some small checks based on the
results of each method (could be business logic).

Validation – your UI will do a lot of small checks to see that the data fulfills the overall rules for your
application (business logic)

How do we make these reasons go away?

We do it by offering a good and easy way to transform model-elements (or data if you will) into data elements
suitable for render to match the specification.

We do it by making it real easy to add business logic where it belongs (in the model), and make it easy to
call it.

We offer a clean and easy way to add validation logic.

By setting the model in focus, and making it dirt simple to add methods, derived attributes and derived associations
you can do everything you need for a specific UI in the model. This is an improvement even if not the solution.

The problem is that if you have a 100 UI’s your model is filled with 100 times x derived attributes and derived
links. That does not sound like a good thing to me. It will eventually get hard to see the trees for the forest
in a model like that.

Further more when a UI is dropped and deleted for some reason, will we remember to drop the derived associations
and derived attributes we added to the model to accommodate it? Probably not.

A transformation layer between the UI and the Model can fix this. The transformation layer is allowed to have
business logic, as long as it is unique for the context it works on. If the logic is not unique, it should
go in the model ready to be re-used. We call this transformation Layer for a ViewModel. The name View-Model
is from this being a particular view or perspective in how to look at the model. The perspective often correlates
to UI-views.

A ViewModel transforms a piece of the model for a specific purpose. The purpose is often, but not always, to
prepare the model information for interaction with a user for a specific use case – a UI. I said often but
not always; it can also be for creating data transfer objects that are suitable for exposure for another application
or system, or for some reporting engine or the like.

Why is it having the rules in a ViewModel is much better than having them in the UI? There are a lot of reasons:

Testing; it is a good thing to be able to test the logic separated from the UI, because it is awkward and error
prone to test and read the results back from the UI.

ViewModel re-use ; you may have different UI’s for the exact same use case (beginner/advanced, Web-api/Rich
client etc).

Design time type checking; most UI-binding strategies rely on using strings that can only be checked at runtime
(true for winforms and ASP.NET – MVC with Razor is type checked and also WPF), whereas a good ViewModel is
type checked at design or compile time.

When important logic is in the ViewModel the designers can work on the UI without risking any damage to the
logic.

If we have dedicated designers we will not want to wait for them to release a UI file in order to fix business
logic within.

The UI may be on the other side of a network (another physical tier) so the UI cannot have access to the domain
layer tier.

UI and logic have very different motivators and hence will often change for different reasons (looking good
versus working correctly), mixing them up adds confusion regarding the distinction between these important
aspects.

Security, designer that get access to the ViewModel cannot go beyond the ViewModel and unintentionally expose
information that should not get exposed in the use case at hand.

The thing is that you do not have to use a ViewModel pattern to create a great application, it is just that is
a good idea to use the ViewModel pattern when building applications that are going to be worked on for a long
time, released in several versions over several iterations, and will most likely see different developers and
UI-designer, and may very well be radically changed with regards to presentation framework during its lifespan.
In short – it is always a good idea for successful applications to use a ViewModel pattern.

The declarative ViewModel

Presented with a model that I got from colleague, that incidentally helps out as a Hockey Referee when he is
not coding, I wanted to create a ViewModel for the use-case “Set up new Hockey game”.

The Game class has a state machine:

I took a piece of paper and draw the UI I wanted to achieve:

Now I know what the requirements are on the ViewModel since I can see from the drawing what data the ViewModel
needs to hold.

And then created this ViewModel That I named GameSetup:

Notice that it is just a series of named ocl expressions. Some expressions are nested to other list definitions
like Home_PickList that states that if the Game has a picked GameType, then we know what teams that can be
picked – namely those teams that are associated to that GameType

I created some test data so that UI can show something. My first attempt was to manually code a WPF UI and bind
the values to the ViewModel

The UI looks like this:

This has minimal amount of fashion acceptable styling. The good thing is that you can hand it to any WPF savvy
designer in the world – the data and the rules are safe in the ViewModel.

It already shows some of the good effects of separating UI from logic.

The PickLists for Home and Visitor are filtered based on Type of Game

The Picklist for Home team filters away the Visitor team if set (and vice versa)

Start game is enabled only after both home and visitor are set

The End game button is disabled until the Game is started

These are some examples of business logic that would have easily ended up in the UI if we did not have a good
place to define it.

Taking it further still

If the cost of creating and maintaining a ViewModel is high fewer ViewModels will be created. So our mission
is to reduce the cost of creating and maintaining them.

WPF is a declarative way to describe the UI. This mean that the same basic lookless components like TextBlock,
TextBox, CheckBox, Combobox and Image etc will be used again and again and they will be given a look by an
external style or template.

What if we use this fact and provide some basic rendering/placing hints for the ViewModel columns? We could then
use those clues to spill out the correct lookless control in the intended relative position so we would not
need to mess about with xaml every 5 minutes. This is what the ViewModel-Editor looks like without rendering
hints:

And this is the way it looks when I have checked the “Use Placing Hints” checkbox:

Given the extra fields for “Presentation”, “Column”,”Row”,”Span” etc I can work the ViewModel – preview to look
like this:

Now I really need to stress this so that I do not get misunderstood: We are not designing the presentation here
at all. We are describing what data is available, which values are valid, possible selection lists of data,
and, if the UI designer wishes to take notice of it, *hints* as to how to arrange the controls in relation
to each other which happens to give the option of generating the user-interface automatically by whatever front
end is currently in fashion. This is all natural information we have in mind while designing the ViewModel.

Having a ViewModel with placing hints, you can add a ViewModelWPFUserControl to your form with just one row:

And remember that these auto layout controls also adheres to external set styles.

Having the ability to get simple UI automatically derived from the ViewModel placing hints lowers the effort
to produce and maintain. Experience has shown that a lot of the administrative parts of your application is
left as automated so that more time can be spent on the signature screens that are most important for your
users.

Part 4. Actions

What an Action can do

Actions can do a couple of things.

ExecuteExpression

The execute expression is an Action-Language expression that is rooted in some context.

For
GlobalActions this context is null, so what you can do is limited to expressions that stem from a class
of your model, like X.allinstances or X.Create. The ActionLanguage-editor (Action language is OCL but can also
change data) is displayed by the button next to the expression:

If the Action is a
ContextAction, you get access to the variables that the context define, these are named as vCurrent_TheViewModelClassName.
So you can either act on classes as with GlobalActions or act on the current value of variables from the context.
The variables follow the selections that the users do in ViewModel grids, so you can act on things the user
has selected.

When you have an object context like this you can call methods that the objects class define:

And you can of course use all the attributes and navigate all the associations in as many steps as you need to
get the desired effect.

If the action is a
ClassAction the action is rooted in an object of that class, and you use the OCL identifier “self” to operate
on this.

EnableExpression

The EnableExpression is very similar to the ExecuteExpression, except it is not an EAL expression, it is an OCL
Expression. As such it cannot have side effects (it cannot change anything in your domain of objects). And
the EnableExpression must also evaluate to a boolean value of true or false.

Except from these differences the expression operate on the same context and can reach the same variables etc
as described for the ExecuteExpression.

The EnableExpression is used to control when an action should be executable or not.

Consider that you have a state machine on the class X and you only want the Delete action to be enabled when
X is in state Deletable : self.oclIsInState(#Deletable)

BringUpViewModel & ViewModelRootObjectExpression

An action can bring up a ViewModel defined UI, and when it does it will assign the Root object of the viewmodel
the result of the ViewModelRootObjectExpression. If the ViewModel RootObject Expression is empty the Root object
of the brought up ViewModel defined UI will be unassigned – and this might be perfectly fine for certain types
of UI’s, like UI’s designed to seek persistent storage for example.

ViewModelIsModal & ExpressionAfterModalOk

If the action is set to bring up a ViewModel powered UI, you may also choose to bring that UI up as a Modal window
(a dialog you need to Ok or Cancel to get away from). The model executer runtime will add an OK and Cancel
button to the bottom of your window if this is set.

If the user clicks Cancel in such a window nothing else happens besides the fact that window is closed. But if
the user clicks Ok the WECPOF runtime will execute the ExpressionAfterModalOk if you have defined it.

The ExpressionAfterModalOk is an EAL expression that works on the context exactly like the ExecuteExpression
does, but the ExpressionAfterModalOk also bring the variables from the ViewModel UI that was modal and is now
closing. This fact enables you to read values of the window about to close and to apply these values to your
current context.

The variables taken from the window that is closing are prefixed with “vModalResult_” in order to avoid name
collisions with the calling context.

This will enable you to create a Seek/Pick/Assign pattern in a WECPOF application.

Consider that you have a Car-rental-model, you a have a ViewModel that shows the rental contract and you now
need to assign a Car to the Contract. The choice to use a ComboBox to scroll and find a car is no good because
the number of possible Cars are 500+. So instead you add a ContextAction to the Rental contract ViewModel that
brings up the Free-Car-Seeker-ViewModel, and you tick the ViewModelIsModal checkbox.

You also define the ExpressionAfterModalOk to
bevCurrent_RentalContract.AssignedCar:=vModalResult_Current_PickedCar.
Framework Action

If you pick a framework action none of the other expressions will apply.

The Framework action is added to allow access to functions that operate on a different level than your model.

Save – saves the changed (created, deleted, updated) objects using the persistence mapper that you have
used.

Undo/Redo – calls undo or redo on your ecospace. The runtime uses a timer to create new undoblocks every
other second if there are new changes.

Exit – quits the application

Defining Main menu actions

Main menu actions are called GlobalActions. We start by bringing up the Actions definition window:

We add some GlobalActions and give them names based on what we want them to do in the end:

If I run this as is with MDriven prototyping I get this main menu:

But we want to organize the menu, so we create some Menu-Groups:

Now I can decide in what group my actions should be:

and then I get this result when prototyping:

To get the internal order and dividers into the menu I need to set Divider group for the items, if this differs
between two actions they will be separated by a divider. If it is the same between two actions the actions
will be sorted on the “Sort order in Group” value within the group.

This is what I get in prototyping now:

If I want to organize the actions in sub menus I do this by declaring a new Menu group:

And I use that group on the actions I want in the submenu:

The strategy for creating context menus is exactly the same.

Action names

When declaring Actions in MDriven you have the option of giving a name (required) and a Presentation (defaults
to <Name>).

The reason for the two different properties are that the ActionName must be globally unique for all actions –
it is used for presentation of the action and as reference name of the action. The presentation is however
the text we use when presenting the action in a contextmenu or in the MDriven Prototype leftside action column.

Since the Presentation often resembles the Name we have introduced the following shorthand/activecontent:

ActionName

Presentation value

Presentation result

Somename

<Name>

Somename

SomeName

<Name>

SomeName

SomeName

Extra1 <Name> Extra2

Extra1 Some Name Extra 2

SomeName

<AsString>

“DefaultStringRep of context object”

SomeName

<Name> <AsString>

Some Name “DefaultStringRep of context object”

SomeName

<AsString:Attribute1>

“Value of attribute1 of context object”

SomeName

Extra1 <Name> Extra2 <AsString:Attribute1> Extra3

Extra1 Some Name Extra 2 “Value of attribute1 of context object” Extra 3

The context object is of course the object that the actions is acting on. So it is intended to be used with “Class
actions”.

Constraints descriptions

As we introduced the above mentioned shorthand we also made the <AsString:attributeX> part available in
the constraints Description texts. This way your constraints descriptions can get context info. If you have
the need for a complex expression, like navigation for pulling attributes from neighbor classes you are advised
to create the expression as a derived attribute that you then can reference from your constraint description
text.

Part 5. Reports

Microsoft office and OpenDocument as a Report generator

We think that it would be great if we could generate word and excel documents straight from model driven.

This section explains how.

Create a Word template:

You can have grids in grids to create structure:

Save this as an open document file (odt) , save it to a place where you can access it from an url (maybe you
use sharepoint, or just stick it on some website)

Now you need data. Declare a ViewModel in MDriven:

(By now you know that a ViewModel transform your model for a specific need – in this case the open document report)

Create two extra ViewModelColumns in your ViewModel; TemplateUrl and ReportFileName:

Make the TemplateUrl column return the Url to where your template from above can be found – maybe in some sharepoint
instance as in this example. Make the ReportFileName column return what the file should be called when produced.

And you are done.

Execute the report by using new EAL operator:

vSomePumpRev.
opendocumentreportshow(‘PumpRevDeepReport’) – this will call the OnOpenDocument event on the new IOpenDocumentService
– this is because each UI platform has its own way to actually show things to a user.

In MDriven Prototyper for WPF we do this:

In ASP.NET you would do something else – like generating the file on the server and send back and url for the
user to download it.

If you do not want to open the file – just generate the data within – then use new EAL operator vSomePumpRev.
opendocumentreportasblob(‘PumpRevDeepReport’)

A bit hasty and vauge

So you might think I just skimmed over stuff – like how to
get hold of the place holder tags that are replaced with data?

This you do by entering the tag %meta% in your template. We will always look for this tag – and when found we
will add all valid tags in its place.

How do you
create hierarchical structure in the report? Like this in the data:

And like this in the template:

The tag %%+Name% acts as row builder, the following tag %OtherName% is the data in the child. In the Example:
%%+ComponentSpecificationRevs% – I stick this as the first thing in a table row and the row will be duplicated
for each child. Then the %RevisionNumber% is filled in in the cell.

The reporting mechanism also works for excel. Example excel result report:

Qualifications

When working with reports we sometimes do not know in design time what the needs for the report is at runtime.
To handle these situation the template tagging has been extended to allow for qualifications. Let me explain.
Smallest possible report sample:

We want to allow for picking the correct Class2 in runtime time, while working on the template.

If we have this excel template:

we get this data out:

The qualification extension is that we now can have Template tags like this:

%Class2[Name=Hello1]Name%

What this mean is that we are navigating to ViewModel column Class2 – but this is a list – and filter the result
on the viewmodel column Name of ViewModelClass Class2 – taking the one with value “Hello1” – for that Class2
we use the Name column… Example:

will give you:

(Notice that we have different external ids in the two last columns – the first from a Class2 with Name==Hello1,
the other from one with Name==Hello2)

This is useful when you have data in name value pair patterns.

Images in Word reports

This is how to add images to word reports. Add some placeholder image in the template:

Now – the image will be replaced with your data. And new from today is also the fact that the Aspect ratio of
your data is kept in the final word (odt) report:

Part 6. Prototyping – executing your models

Prototyping

Prototyping is used in all lines of engineering. Prototyping is the process were you whip something together
quickly as a mock up in order to show it or test it in order to learn something that otherwise would be hard
to know.

Prototyping for software has a unique position. The prototype is made up by the same stuff as the finished product
; logical rules. This is not true for any other practice of engineering. We have a unique position that we
can harvest. To make the real deal – the finished product – just as easy as if we were building
a prototype.

Many experienced developers will frown on this. They know how very prudent you must be to actually build something
that is robust and solid. And they know how very quick and dirty they are when whipping together a prototype.
Why this big gap? My answer: Normal coding leaves too many degrees of freedom for the task at hand. Normal
coding actually use only one tool – code – for handling data, presenting it, navigating it. Of
course you will mix things up when you are in a hurry.

If we can separate things like the information we handle, from the transformation of that information into views
and from the navigation between these views – then we have something that will almost fly on its own
– and the building of the thing will be like prototyping the thing. Think of it as an autopilot –
it will protect you against doing stupid mistakes – it will make you fly straight – it will give
you time to talk on the radio and stuff – you only need to tell it where you want to fly. So with MDriven
we use the Model to tell the autopilot what information to handle – what the perspectives of the information
should be – how we navigate between the views of information. Having instructed the autopilot we can
take off – and see if we have the right model or not. If not churn away and fix it.

Many developers will also frown on the idea of an autopilot – since it will emasculate them and stop them
from flexing their muscles – so I need to point out that what is great with MDrivenFramework is that
you can turn off the autopilot for any portion of the flight so to speak. You can still do the coolest looping
in front of a gaping audience whenever you feel like it. Then turn on the autopilot to do the mundane flight
back home. This will give you freedom and speed and a lot less accidents.

This is how you do Prototyping with MDriven

1. Model what you know so far – in this example I am prototyping for a Car Rental Service

2. Think about what user stories or requirements you have:

As a Customer I want to see what cars you can rent As a Customer I want to know what they cost per day and what
my total cost will be As a Rental worker I want to be able to hand customers rental contracts to sign As a
Rental worker I want to be able to find free cars

3. Then do some ViewModels that can cover these user stories – when prototyping I will make use of the
scaffolding user interface hints that place out UI controls on a screen surface that match the types of the
viewmodels properties. I ended up with 4 viewmodels:

Search for a Car

Search for customer

View or edit a customer

View or edit a Rental contract

4. What actions do we need to expose to the user for navigation between these views. For this I will start by
clicking Create/Init standard actions in the ActionsDefinition dialog.

This gives me the ordinary actions like save,quit, undo and redo. It also picks up on the ViewModels I have and
add some actions for them.

I will remove the actions created for ViewAndEditCustomer and ViewAndEditRentalContract since these are rooted
views that require a root object (a customer or a Rental contract) to have anything to show. Instead I add
a ViewModelActions in SearchForCustomer ViewModel that creates a new Customer and one that creates new rental
contracts:

I also add class actions that can show and existing customer and rental contract

6. I could think a bit harder – but the whole point with prototyping is that it should be easy to test if we
are done or not. So I hit the start prototype symbol:

I am presented with a choice on how to store data for this prototype – we will choose xml for starters:

I start the prototype and find the main menu items

I pick “Search for customers” – I search – the system finds none – I click the action new customer – I get the
ViewAndEditCustomer view – I enter a name and save and hit back – now the search result sees a customer:

Note to self – must have a Search for rental contracts

I create a new rental contract – I notice that the button “Assign customer” does not do anything

Note to self – must bring up “search for customer on assign customer – then let user pick 1
customer and return back with it and set it on the rental contract”

Note to self – same for assign car – must bring up search for cars

Note to self – I do not have any data for cars or brands and no UI to enter it – Note to self –
do this in the debugger window for now

This is how a typical prototyping session goes and how it reveals obvious things we need to do. Lets do them
now. Starting with using the debugger for adding cars and brands:

I add brand as well – the save the data to the prototyping XML file by switching to dirty objects:

I click open the Autoform of a Car-object – then I drag a Brand object to the Brand field:

So that takes care of test data for Cars and Brands. I still have these to items:

Note to self – must bring up “search for customer on assign customer – then let user pick 1
customer and return back with it and set it on the rental contract”

Note to self – same for assign car – must bring up search for cars

I do this by adding a ViewModelAction for the ViewOrEditRentalContract:

The Action should bring up the search for Customer, it should be a modal action, it should be fine to press ok
once a Customer is selected. And when Ok is executed we assign the picked customer to our rental contract.

The same more or less for picking a car:

I then choose to hook these actions up to the buttons I put in the ViewModel:

I also has this one left: Note to self – must have a Search for rental contracts

Yet another viewmodel.Once I have it done I use the shortcut action to create global action to show it:

Then I press Play again:

This time I can assign a Customer and assign a Car. The search for Car comes up in with an Ok/Cancel button because
it was brought up by a modal action:

I search and pick a car and press ok:

I still have a few user stories left and I will need to change the model some, amend the viewmodels a bit, maybe
create some actions. But all in all this is a very straight forward way to work. And you get instant gratification
to see your model and logic come life. This is also something that triggers your ideas for further things your
users will need and want. Churn on like this for an hour or two and you have done more than what you can do
in a day with traditional specification work or coding.

The look

The prototyper window uses Windows Presentation Foundation (WPF) and you are free to change the used style sheet
just as you see fit:

or maybe you need to stress the that we are “just prototyping” by using something really bubbly:

Available Actions

The actions that are shown to the left are calculated by the framework. You can have class-actions – actions
associated with a class in your model. These will show up whenever an object of that class is shown in you
view.

You can also have viewmodel actions and these only show up in the view they are defined for. We have the ability
to instruct the logic to do exceptions to the calculated display of actions. We can opt out the presentation
of actions per view.

Actions may be used for navigation – but they may also perform something – like calling a method
on an object.

In or example we already have some actions – both viewmodel actions, class actions and global actions (the
ones that build up the main menu).

Look closer at the ShowRentalContract action. This is a class action – available everywhere a RentalContract
is shown. But there are situations where we do not want it to show – like when we already are in the view that
is brought up by the action:

In order to remove it we want to opt it out.

There are two tools in MDrivenDesigner that are good to use for this. The first one is the ViewModelEditor:

Pressing the “>” button will move it to the opt out column:

You can press the “
to opt it in again.

The other place where you can opt out actions from is the Action Cross reference window:

In this window we see the actions that will bring this view up – currently there are 2 actions, the
NewRentalContract and the ShowRentalContract.

We also see the actions that will show and an line to which section or nesting of the ViewModel it refers.
You may click the lines and shift them from green (opt in default) to opt out. Since we already opted out
our ShowRentalContract from this view – that line is already red.

There are also tools for looking at this from a specific actions perspective. In the ActionsEditor we see
this for the ShowRentalContract Action:

It says “Action shows in 2 places. 1 Opted out” followed by a dialog button. Click that and you will see
this:

And here we see that it is opt out in the ViewAndEditRentalContract view – but it shows 2 times in the SearchForRentalContracts
view. I switch back to prototyping to verify this:

And find that this is true. The reason for this is the fact that this viewmodel defines two areas that has
the type RentalContract. One for the root and one for the Grid-nesting that shows the results from the
variable vSeekerResult.

The root instance will always be null since this ViewModel does not require a root object to function. ViewModels
designed for seeking seldom do. If it always will be null then there is little point to have an action
that will be enabled only if it is assigned an object. So we should opt that root action out – click the
line to toggle opt out state:

And then the ActionEditor was updated as well:

It now says shows in 1 place – 2 opted out.

I actually have had my prototyping session running all along – but it still use the model we had prior
to our changes. I can now restart the prototyping by clicking play again – bringing up a new prototype
window. Or I can just reread the model to the one I have:

and then I see that the ShowRentalContract action is shown only once.

If you are left alone for a day and if you have lots of ideas I promise that you can model them in MDriven
designer and verify them in MDriven prototyper. When you are able to try and verify ideas rapidly you will
find many “think bugs” early. Bugs that are like “oh – no – that is not a
good way of doing it”. Since the MDriven environment works as your auto pilot and it has 10: th’s
of thousands flight ours under its belt – you will be more free for the creative part of your work.

Part 7.MDrivenServer

Introducing MDriven Server

Prototyping in the cloud with MDriven Server

Now that we have had a brief look on how to prototype and store the data locally let us move on to storing the
data in the cloud and enable a multi user prototyping scenario.

The easiest way to store your MDriven data in the cloud is to use a MDriver server. MDriven server can be installed
easily on the Microsoft cloud service Azure.

You can sign up for a free try out account at Azure.

Go ahead and register a user, login and you get this:

Now you have an MDriven Server that is used as your backend for a model driven application or prototyping session.

Our MDriven Server’s address:
and to actually connect to it from an application we choose one of the 3 available slots A0,A1 or A2.
If I choose A0
the connection address

In order to make this MDriven Server – slot A0 – understand my model I use MDriven Designer:

I enter the credentials from the user I registered with MDriven Server, the url to the MDriven Server, The chosen
App slot, and also check – suggest automated deploy.

I then hit “Go”:

The message Database created means that MDriven Server has received our model and turned it into a database.

When I now enter prototyping mode again I choose to take data from this MDriven Server instead from the local
XML file:

And when I start the application I no longer see the data in the local xml file – I see the data in the database
managed by MDriven Server hosted by Azure:

There are several ways I can verify that I am working towards the MDriven Server:

Check the AutoForm function of MDriven Server:

The auto forms function of MDriven Server very much works the same way as the Model Driven Debugger – you can
navigate everything according to your model:

Another way to look on the data is to use the ASP.NET Generic App:

And this very much works as the prototyping app we saw in WPF:

If you want to have your customer or some else test the model as it stands just now it would be great to just
send them an url to click to get started. This can be done by sending the the link from MDriven Server that
points to a ClickOnce install of the MDriven Designer – with some parameters that instructs the MDriven
Designer to download the correct model and go into prototyping mode

This link points to the CapableObjects published MDriven Designer clickOnce installation. The link will offer
an installation of MDriven Designer if the user does not have it already:

If/ when you accept the MDriven Designer is installed:

Next time you follow the link a check is made to see if there is a newer MDriven Designer available. If there
is – the new one will be downloaded and installed, otherwise the existing one will start directly.

Note that there are two arguments passed to the MDriven Designer. The first argument is the url address to your
MDriven Designer encoded with base64 to pass thru all browser types. The second parameter is the appslot –
in this case A0. When MDriven Designer sees these arguments on start it will try to do this:

1. Download the model from the provided url and the provided appslot

2. Start prototyping for this model

So in the preferred scenario the user sees this:

But it may fail for a number of reasons to get this far. The reasons are all based in security concerns for your
MDriven Server and your model. Read more about this in the next section

Security concerns for MDriven Server

When you install your MDriven Server you get access to it by registering a new user. But there are more things
to consider.

In order to secure your model and data and system you can:

1. Make sure you communicate with MDriven Server over https so that no one can see your passwords and other data
that will go over the wire.

2. Limit what an un-authenticated user of MDriven Server can do

In the user admin dialog you can state that the Admin UI require identification – if you do – and
you should at some point – make sure you make yourself SuperAdmin so that you do not lock yourself out.

You can also state if the services exposed by the MDriven Server via various web interfaces also require authentication
or not.

It is likely that you will begin with a relaxed attitude to security and this will ofcourse put less requirements
on the users you engage in prototyping etc.

Mind that no security limitations are enforced as long as you run your server in http mode – this is due
to the fact that it would force us to send passwords over an open wire and that is considered worse since it
may implicate other services you have.

MDrivenServer Summarized

The MDrivenServer receives your model from MDrivenDesigner. As it does it will create or evolve the database
it uses to store your data. This database is default a SQLServer Compact edition that gets installed along
the MDrivenServer. You can however change the database used for your data to a SQLServer in Azure.

You change the database used simple by providing a connection string like this:

The MDriven server allows you to get access to the data in your database through various interfaces. The most
advanced interface is the MDriven Framework PersistenceMapper API. This API is easily used with MDriven Framework
built applications.

The MDriven Frameworks PersistenceMapper API is secure and robust way to query and retrieve your data in a multi
user environment.

It allows for functions like optimistic locking, client synchronization, CRUD-operations in transactions, OCL
queries executed as SQL in the database etc.

The MDrivenServer also offers alternate methods to get access to your data via Json objects so that you can build
non MDriven savvy applications that do CRUD operations on the data in your model.

As the MDrivenServer has interfaces to receive model updates from the MDrivenDesigner the development loop from
idea to deploy can be very quick.

MDrivenServer periodic server-side actions

A re-occurring pattern when building multi user software systems is the need to execute periodic actions. With
MDrivenServer you can use it to execute re-occurring actions, or periodic actions.

A Periodic action is defined by a selection expression that selects what objects to act on. For each object selected
for a periodic action we want to do the “action” and that probably needs a cluster of objects and
it needs to do different stuff to evolve some object state. To enable efficient load for such an object cluster
you must define and associate a viewmodel with each periodic action.

The periodic action logic will load the viewmodel for your object and loop through all actions that it finds
in its root viewmodel class. When all actions are executed the periodic action logic will save any changed
state that was the result of your actions.

Periodic actions can be used to “automatically” step your information from one state to the next
– given that the circumstances are correct.

This ability might take some getting used to – but it can be used for things like assigning a unique number
to an order or an article in your domain model – or for actions that need to be done serverside for some
particular reason.

Define the periodic actions in the ViewModelEditor:

With this technique you can change any and all state of objects in your database in an efficient manner with
very little code.

As a common case is the need to assign a unique number I will show this. The client cannot alone be used to guarantee
that the next number in a sequence is taken, since there may be multiple users trying to do this at the same
time. We need to make sure we serialize all user requests for a new number. This is commonly done with a database
lock. There is however a nice alternative to a harsh db-locking technique and that is to serialize via a server
side action.

Consider having this state machine:

The ViewModel associated with the periodic action on the server can now assign my number

The client will set the AssignNumber state. The Server side action will look for Order.allinstances>select(o|o.State=’AssignNumber’).
When objects are found they will be assigned a new number by the actions in the ServerSide ViewModel and saved.

Combined with a periodic client action that calls selfVM.Refresh we will see on the client as soon as state is
changed to NumberAssigned.

Since we do not want the client to poll selfVM.Refresh all the time we set the EnableExpression in this action
to self.State=’AssignNumber’.

Following this pattern we get the user pushing a button to get a new number, we can show some info about working
– the client starts refreshing – the server does its job – the client gets the new info by its refresh – the
info abut progress can be hidden as a consequence. This way we have serialized an action in our system with
model driven techniques that will scale well and work of any number of users of your system.

Other uses of Server side Actions

Emailing from the server

We have also implemented several additional common actions that you can have the MDrivenServer perform for you.

If you have an action in your viewmodel named “email” then MDrivenServer will try to find the following
properties in your viewmodel:

to : will be used as to email address

topresentation: the name of the owner of the email

from: the sender email

frompresentation: the name to use as sender

body: the message

subject: the subject line

The properties found will be used to send an email – you need to fill in the email settings in the admin
UI for this to work.

Importing data from other SQL sources

MDriven Server has functionality to import data from other sqlbased systems.

The ability to read from an external SQL server and import that data – strictly by using MDriven techniques
and zero need for external programs.

´Suppose I have this model and I really want class1 to be reference data from an external database:

So I declare a viewModel that looks like this:

It defines 4 columns with data and 2 actions.

1=
ViewModel – the name of yet another viewmodel that will act as a importer of the sql result set

2=
Connectionstring- the external database

3=
Query – the sql query – remember that you can build it with data from the rest of your model

4=
Key – if we want the import to be able to update Class1 we need to explain what the key is in the
class

And the actions:

SQLImport – using this name will trigger the import function in MDriven Server Finished – this
is a generic action – that just execute the expression – in this case setting Class2.Attribute1
to ‘Done’

So the SQL data returned looks like this:

And the ViewModel that is going to act as the import template – called “TheImporter” in the example above looks
like this:

I now declare the ServerSide job in MDriven server:

The actual import is executed by the import logic described in a separate chapter of this book

Now the MDriven Server will check every 20:seconds if the expression Class2.allinstances>select(attribute1=’todo’)
returns any rows. If it does – it fetches at most 2 of these and executes all the actions found in TheServerSideJob.

In MDriven Designer I can create a Class2 with the debugger and save it:

And then I check the MDriven Server log:

I then check my Class2:

Attribute1 is now ‘Done’ – so the serverside job relaxes and will not find anything more to
do just now…

Producing export files from MDriven Server

You can also write files by adding an action column called “savefile”; when the periodic action supervisor
in MDrivenServer sees this action column it looks for two additonal columns; path and filename (case insensitive).
If these are found the complete result of the ViewModel is streamed out as xml by using the ViewModelXMLUtils.GetDataAsXml
method. The xml is then saved to path/filename.

Like this:

In a real world application it looked like this:

Notice that both path and filename are evaluated expressions, furthermore the Action UpdateExportTime is executed
last – and it changes some data. Since the whole execution is wrapped in a memory transaction we make
sure that we do not update the export time unless the file was written and everything is ok.

The resulting file looked like this:

Shaping and transforming export files

This SaveFile action has been updated to look for a column named xslt, if it is found the contents of the field
is assumed to be a valid xslt transformation. The xml from the viewmodel is transformed with the xslt and the
result is saved as above.

So if your xslt is…

… then your output would be…

NO101087,Cosmica Tygg 90 ST…

SQLExport serverside action

The SQLExport action is an action used to write data from your model into another external SQLdatabase. It is
an alternative way to export data – way to needs no other external components or maintenance than what
MDriven Server provides.

SQLExport requires 'connectionstring' on root, 'data' as a Nesting that contains the datarow(s) to insert or
update and on data - 'queryforinsert','queryforupdate' and 'queryforselectcount' as attributes (if queryforselectcount
returns 0 the queryforinsert is used, else update).

The very common case of “replicating” some model driven data to another database is implemented and
scheduled in minutes.

Part 8. Object Constraint Language

What is Object Constraint Language?

This is from Wikipedia:

The
Object Constraint Language (OCL) is a
declarative language
for describing rules that apply to
Unified Modeling Language (UML) models developed at
IBM and now part of the UML standard. Initially, OCL was only a formal specification language extension
to UML. OCL may now be used with any
Meta-Object Facility (MOF)
Object Management GroupObject Management Group (OMG)
meta-model, including UML. The Object Constraint Language is a precise text language that provides constraint
and object query expressions on any MOF model or meta-model that cannot otherwise be expressed by diagrammatic
notation. OCL is a key component of the new OMG standard recommendation for transforming models, the Queries/Views/Transformations
(
QVT) specification.

Different ways MDriven relies on on OCL

As constraint definition on a class

As description of derivation rule on derived attributes

As description of derivation of derived associations

As ViewModel columns and Nesting definitions

As definitions for Visible and Enable state for ViewModel columns

As expression of style information on ViewModel columns

As expression for object presentation on classes

Action Enable expression

State machine Guards

OCL expression must be without side effects. It is a query language and as such it is not expected to change
data as the language is applied.

In MDriven we do however want to change data when appropriate – so we use the exact same syntax as OCL
in something we call EAL – ExtendedActionLanguage.

We use EAL in MDriven here:

Action execute expression

Actions in ViewModel columns Execute expression

Class method implementations

StateMachine Effects

Normally the OCL expressions are executed in memory – but it is a common need to query large quantities
of data in the database. Normally SQL is used in databases. To avoid having multiple query languages in MDriven
we provide a subset of the OCL language that we can translate to SQL.

We call this subset for OCLps – where ps stands for Persistent Storage.

We use OCLps in MDriven here:

Action execute expression

Actions in ViewModel columns Execute expression

In MDriven all the 3 types of OCL ( OCL, EAL, OCLps) are dynamically typed checked whenever the model is loaded,
saved or if you initiate a model check manually by clicking the mode check

Running the ModelCheck also cross-reference you model so that you can see where things are used:

MDriven relies heavily on OCL and it is a very powerful tool to describe constraints, actions and transformations
in your model.

OCL, EAL, OCLps Introduction

Your model is central to all expression you will handle. We will use this model to for the examples:

Thing.allinstances

Gives you a list of all Things

Things.allinstances->select(someInt>3)

Only things with someInt bigger than 3

Thing.allinstances->select( (someInt>3) and (someInt
<6))

Only things with someInt bigger than 3 but less than 6. Notice the extra parenthesis to or the Boolean
expressions together

Things.allinstances->select(x|x.someInt>3)

Here we introduce the loop variable x. We separate the definition of x from the usage of x with the pipe
sign “|”. Loop variables are optional but if names are unique – but you will need to use them to give
precision or to if you want to perform operations on the loop context itself.

Things.allinstances.Details

Gives a list of all detail objects that are connected to a Thing. The Detail objects that float around
without a Thing will not be in the list

Things.allinstances.Details.Attribute1

A list of nullable strings from the contents from the details attribute1. Note that OCL is null-tolerant
– you do not need to check if the Details exists of not – the language handles null checks for you

The symmetric difference between the collections; ie all the objects in collection1 or collection2 but
not in both

->union

The set of objects in collection1 and objects in collection2

One important aspect of OCL that is worth noting is that it expands lists of lists to just a list. An example
in plain English; Thing.allinstances.Details – this will come back as a set of details that are all the
details from all the Things. If OCL had not expanded lists automatically one could have expected a set of sets
containing the details per thing. But this is not the case. The automatically expansion of lists of lists is
sometime referred to as flattening of a collection – referring to the reduction of topology in the result.

If you are in the context of a simple type like string, double, int, datetime or Boolean MDriven will expose
the simple operations that are available in the .net Framework. Testing this in the OCL-Editor:

In this case it is a string that is the result – and we can to string operations like compare, indexof,
split etc.

The numeric types float, double, decimal and int are sort of apples of the same tree and MDriven expose ways
to go from all numeric types to decimal. The operator is called toDecimal.

Certain important constructs

Some constructs are more returning than others as an everyday business developer with MDriven. Your favorite
ways to express yourself may be different from mine but these are some of my returning expressions:

let z= Things.allinstances>select(x|x.someInt>3)->size in ( If z>4 then ‘There are more than 4 Things with
SomeInt>3’ else ‘There are ‘+z.asstring+’ Things with SomeInt>3’ endif)

I use the “let” construct to assign a result of an expression to a temporary variable. This so I do not
need to repeat myself in the testing of z>4 and the z.asstring

Thing.allinstances>groupby(x|x.SomeValue)

Groupby , this expression has the type Collection(SomeValue:ValueStore+List:Collection(Thing)) so I get
a list of SomeValue and for each a list of the things that use it

Nested collecting. This expression get the type Collection(Part1:System.Int32+Part2:Collection(Thing:Thing+Det
ails:Collection(Detail))) The ability to nest collections is very powerful. In this case I start with
all Things – grab the SomeValue valueStore– check what other things has this set via the association
MultiValuePick and for these I sum up all SomeValue plus grab the Details. This kind of multi level collect-usage
is very handy when summarizing deep object hierarchy’s on different levels

' '.Chars(0)

1, 2, 3, 4, 5, 6

if true then 'this returns a string' else 0.asstring endif

All return paths must result in the same type. Since OCL is a functional language we must be consistent.
This is one way to get the expression correct ; add.asstring after the zero

Working with OCLps – expressions that will be translated into SQL and executed in a database- it is sometimes
easier to do one expression per complex constraint and at the end intersect all the expressions together.

self

When you are in the context of an object you can use the variable self to access properties of this

You may define methods in classes to and implement these with OCL:

You will in the OCL implementation in the Body-property:

Notice that since this was a method MDriven will treat you OCL as EAL – something that is allowed to have
side effects.

In this case our method do not have any side effects and I may want to be able to use this method in OCL.

But trying to use it in OCL will not succeed. Methods with side effects are not recognized by OCL . There is
a flag on the Method definition called IsQuery and if this is set we “promise” that it does not
have intentional side effects. Now it is seen by OCL:

We can then use our IsQuery method in any expression in OCL. Thing.allinstances>select(x|x.MyMethod(x.SomeInt))

EAL differences

When using EAL one often want to stack expressions after each other. To allow for this EAL has introduced an
expression separator: The semicolon “;”. This means that you can build method bodies that do several
things like this:

self.SomeDateTime := DateTime.Now;

self.SomeInt := 27;

self.SomeString := self.SomeDateTime.ToString('yyyy-MM-dd')

In EAL we use := to assign but = to compare.

In EAL we can also create new objects Thing.Create

Worth noting is that the expression separator “;” can only be used between statements. So writing
this ‘a string’;0 is of type integer. But writing this ‘a string’;0; is of unknown
type and hence wrong – the last statement that the parser expect after the last ; is not found.

OCLps differences

OCLps is a subset of OCL. No side effects, and you cannot use your methods even if they are marked with IsQuery.
The collect, groupby and other operators that return tuples are not supported. The reason is that the main
use of OCLps is to return a list of identities based some criteria’s from select or difference or the
like. Once MDriven has the set of identities we will load the corresponding objects – then you can take
over with normal OCL.

Summary OCL

I often get the question if OCL is capable of doing everything we need to do in a line of business application.
The answer is that as long as the arguments and result is representable in your model – yes it will do
anything. Sometimes you have external or ambient data not accessible from the model – then you cannot
use OCL – until you make that data available.

Not only can you do everything you need – it also comes out in small easily interpreted snippets of text
that very much looks just like the requirements you are set to implement.

I like to compare OCL and modeling with Calculus. In math you can discuss numbers and operators on those number
in plain language – but you seldom do since it will be error prune and require you to use a lot of words
for even simple things. Instead everyone actually doing math uses calculus notation to write up expressions.
The expressions are often reduced to the smallest possible – so that they are easily understood and ready
to be used for a purpose.

Use OCL for the same reason but not on only numbers but on all your designed information. Imagine a world without
a good way to declaratively work with math. In this world we would probably not have been able to do much cool
technology. The ability to convey compact math between people is very good for mankind. I am certain that a
good compact way to convey rules on information is equally important – if not even more usable –
for mankind.

Part 9. MultiVariable-DB-Seeker

Seeking the database with OCLps using ViewModels

To get anything done you need to find things. The normal software system has the same need. So how do we go about
to declare a non-limiting multi variable user friendly seeker into a generic model driven system like the ones
we build with MDriven?

This is what we need:

1. We need unrooted (as in not having anything to start with), persistent storage evaluated OCL expressions in
order to execute a search

2. We need user input on how to limit the search

3. We need to allow for the user to use different limiting criteria’s as he or she see fit ; after all
the One-Field-Matches-Everything tactic that Google use does not really cut the mustard in enterprise applications.
Users will want to limit the search on “Only this department”, “Only things from yesterday”
etc, and even in google you need to use an extended syntax to get this done.

4. We want to allow for multiple sets of search definitions per seeker interface – if the user does not
get a hit using the filters with the first set, it is natural for the user to “try again” and then
we want to use another set of search criteria’s; this has been tested on real users and many find it
intuitive and obvious that it should work this way.

Consider this model:

And this is how we can define a seeker:

#1 We declare variables that holds the user input – one variable is a string, and the other is an Object
reference of type ReferenceClass (from our model).

#2 We add Columns that use these variables so that we get some UI for the user to enter the criteria’s
into. The Reference value we set up as a PickList.

We create a SearchExpression - right click menu on view model column - Add nested – Add search expr. When
adding the first search expression to viewmodel the designer will also add the default implementation details
with a vSeekerResult variable and a SeekString. This is intended as a help and there is nothing magical about
the added widgets. The only important thing in a seeker is that there is a variable named vSeekerResult and
that it is of type collection
- this where the result of your search will go.

#3 Add two criterias – the result of the two criteria’s will be intersected (on the server side).
And here is an important fact: Since the result of the criteria’s will be intersected we need some way
to say if a criteria is Active or not – after all it is up to the user to limit the search on either
or both of the two criteria’s.

This is how the activation of a Criteria is done:

and

The Active Expression is optional, if you leave it blank it defaults to true – always on.

#4 The second batch of search expression is executed the second time the user clicks the search button BUT only
if the search variables has not changed. You can have as many search batches as you need, and they are round-robin-used
whenever the user clicks the search button with untouched variables. Whenever a variable is changed the Round-robin
is reset and the first batch is used again.

Even if these rules may seem complex they are intuitive for the user – especially if you use the search
batches to filter for the same data as the resulting columns show. For example; the user enters someone’s
first name, but your first batch filter on last name – the wrong people comes up for the first search,
the user hits search again – now we use the second batch where you filter on first name – voila.
This was just an example – you can just as well create a filter expression that unions the first name
and the last name results ;
Person.allinstances-
>select(a|a.FirstName.SqlLike(vSeekString+’%’))->union(Person.allinstances
>select(a|a.LastName.SqlLike(vSeekString+’%’)))

Another example might be that the users enters a number – first we try to match it with a product code,
user hits search again, we try to match it with the order number. The user is still not happy so he hit search
again – now we match it with the phone number of the customer – user happy. In this example we
could have chosen to create a detailed search interface with 3 text boxes – one for product code, one
for order number and one for customer phone number – just as valid. Or we could do a union expression
as above – just as valid. Choose the strategy that sits best with your users. But I urge to you to test
the simple interface with a single or only few input boxes - it is user friendly.

Databases use SQL

The search expressions for ocl criterias are different than other than viewmodel column expressions in one important
aspect. They are executed against persistent storage (your database). If your database is an SQL-Server these
expressions will be translated to SQL and sent to the database for evaluation and execution. The database is
much better and faster to handle huge volumes of data than MDriven. This means that we are now able to filter
out specific objects in our model from a nearly unlimited sized database. The multi variable seekers described
in this chapter will be the natural starting point for your users work in your system. They search –
they find – and then they work. The work part is often rooted in a specific found object where your other
viewmodels expand the neighboring information.

Efficient fetch – real case (advanced – skip until you have the need)

ViewModels are good for efficient fetching of data since they declaratively explain what data that will be used.
This enables MDriven to scan thru the expressions and fetch data with a lot fewer queries. If you have a root
of Something that has a list of details and the detail in turn fetch even more details you could easily end
up with x*y*z queries to the database.

But since the ViewModel use expressions that may be stackable we can rather easily fetch all x, all x.y and all
x.y.z with 3 queries.

This is the standard behavior when using the MDriven ViewModels.

When you use seekers the result is collected in a collection variable commonly named vSeekerResult.

Search result is not covered by the standard efficient fetch algorithm because this data is not available at
load time. This may in certain situations be less than ideal so we have added strategies to improve the efficient
fetching in ViewModels using seekers.

All the ideas implemented and explained below came from a real case where I had a fairly complex UI to visualize
and manage demand forecast for articles

There are thousands of objects shown in this one single image – it is a seeker, but it can also get data
from a list tied to current user that is called Favorites.

Even with the normal efficient fetch turned on this UI typically spewed out up to 900 questions to the persistence
server.

To fully understand where the questions came from I used the runtime/prototype-time debugger:

Check the PMapper and you will see all the PMapper calls.

The ones that we look for are the ones that fetch only 1 object – these are candidates for improvement.

When the log sees that only 1 object is fetched it also shows the ClassId.

You can look up classid to name in the debugger:

Once we know what it is that create the queries we can think of ways to fix it.

The new strategy to further improve the efficient fetch is to add a ViewModel Nesting with fetching hints. Any
ViewModel nesting with a name that starts with “FetchHints” will be found and the columns within
will be executed on any list that seeker logic delivers.

Like this:

Working like this I could reduce the load from this UI from 900 queries to 30 something.

Now the problem with search was solved – but when the data came from the other source – the user
favorites rather than the search logic – the fetch hints were not applied.

We had to devise a way to allow for me to tell the ViewModel that this logic should execute on a list of objects.

To handle this I make use of the standard variable in ViewModels: selfVM

The selfVM variable is a reference to the ViewModel we work on – self is the object context as before –
but selfVM is the ViewModel holding the objects.

The system gist is explained earlier in this book and this chapter is dedicated to how you create your MDriven
Turnkey site’s so that you have somewhere to execute the system gist.

There are three ways to get a brand new MDriven Turnkey site:

1. Buy a slot from CapableObjects

2. Set up one in your own Azure account.

3. Set up on one on premise

Buying a Turnkey slot from CapableObjects can be a great way to get started – but CapableObjects will do
the same thing as described below for Azure below – the only difference is that the CapableObjects Azure
account will be used and as such CapableObjects will pay Microsoft for computing power. To buy your slot follow
the instructions on the CapableObjects site.

Creating your own MDriven Turnkey instance in your Azure account

Log into the Azure portal with your credentials – if you do not have an Azure account it is easy to get
one and there is often a free trial offer. Azure is a cloud computing hosting environment that is operated
by Microsoft.

Select “App services” and find the “+ Add” button at the top:

You give your app a name and some further details where it should execute (choose a location close to your main
user base to minimize network latency). Then Create. You need to wait a few seconds for Azure to create you
app. Then you will find it amongst your app services:

A Turnkey app is actually two IIS-applications and we need to set up the second one inside the newly created
MDrivenTurnkeyApp1. Select your app – Settings – Application Settings:

Scroll down to the bottom of the Application settings pane – and find the “Virtual applications and directories”
section:

We can see that the root folder holds an application already – this is the one we have created. Now we need to
add a new one in a sub folder. We need to call it “__MDrivenServer” – the name is important – it is underscore+underscore+MDrivenServer.
Double underscores. We must also state the full path to its directory: “site\wwwroot\__MDrivenServer” (remember
that is a double underscore). Finally we state that it is an Application by checking the Application box –
then save.

Did you save? Save button near the top – marked in red box.

We have now an empty shell where we can install the MDriven Turnkey Software.

In order to access the application shell to add a program we will need to use this applications publishing profile.
Go back to the settings pane and you will find the publish profile to download:

Go ahead and download it – save it where you can find it - we will need it soon:

Now we need to pour in the MDriven Turnkey software into our Azure application shell. Go to the capableObjects
maintained site

If you do not have an account you can Register - or login in with a social account (recommended). The social
account login is a way to avoid keeping an extra password for this site.

I choose facebook:

Once logged into LicenseAndTicket I Register my new site as being an MDriven Turnkey site:

In the Choose File – I find my publishing profile that I save from the Azure download a few steps back. I give
my application name – same as in Azure – and click “Create Turnkey Site”.

I save these updates. And look at Owned Sites:

I can see that my new site is listed with state “Registered”. I now select it and choose “Request Deploy”.

The site is now in the Request Deploy state – I must save this change so that the License and Ticket server may
act on it:

After a moment you will see the state changing to Deploying, and then it becomes Deployed.

You may later want to come back to this site and request a new deploy of the MDriven Turnkey software. This will
not change anything regarding your model – but if you have reason to believe that the MDriven Turnkey
software is updated you may want to have the latest available used in your application.

If you click on your site and choose “Manage one Turnkey site “ you get this view:

In this page you can also set up social login for your application. This is optional and described elsewhere
in this book.

You can now start the MDriven Designer by following the link in the admin page above – note that you need
to have a click-once-plugin in your browser if it does not support click-once-applications natively.

The MDriven Designer starts with a prompt to login – you should login with the same credentials as you
did in LicenseAndTicket to create the site:

I used facebook – and once logged in I hit Refresh and select my site in the combo-box:

I then press “Download model” to download the model from the site into MDriven Designer – I then close the CloudForm
to get into the main view of MDriven Designer:

Now you may design your model – upload it to check results – and return to modelling – this
will be the main loop as you evolve your application.

Try somethings like this:

And a view:

And some actions to show the view and to create a new FirstTryClass object:

And

Now I upload the model – cloud dialog

By clicking Check Status I can follow the progress on the server – it will say something like this when done:

I can now visit the site on https://"the name I gave it".azurewebsites.net (read more on Azure how to use your
own domain). I will also find the link in the admin page for license and ticket:

Notice the Views menu – fold it down and click “Bring up my view”

Click the “Create new First Try Class” action in the view:

And you have your very own MDriven Turnkey app that will execute any model you upload to it.

Set up MDriven Turnkey on premise

There can be several reasons for running the MDriven Turnkey software on premise rather in the cloud. And it
is easy to achieve.

1. Make sure you understand how to make the IIS server use https and how you can either selfsign of acquire your
own certificate. This is key for making the internal WCF communication in MDriven Turnkey to work.

Now import the package for MDriven Server into your first application:

Name the application __MDrivenServer – with two underscores :

You will in the end have this:

Configure for https (not described in this book – IIS specific knowledge)

Notice the __MDrivenServer/logs catalog; things will work better if you application can access this – so
find it in File Explorer and give read/write access to “IIS AppPool\NameOfTheAppPool”.

To configure your system navigate to the __MDrivenServer application: https://localhost/MyMDrivenTurnkeyApp1/__MDrivenServer/

You should see this:

This is the server’s response to not finding the expected database – it creates it and sets things up to the
best of its ability. Click Index to go back to default page:

We are prompted with a login – but we need to register a user that the MDriven Turnkey app will use to access
the MDriven Server. You will also want to access the MDriven Server in order to upload and evolve models –
so create a user “b” and remember the password:

Now log into MDriven Server with this user:

In the admin area choose user admin:

In UserAdmin you can control the existing users on your MDrivenServer – we need an account to be used by
your turnkey site.

To tighten security for our MDrivenServer we are going to:

1. Assign the users we want to have access the role SuperAdmin

2. Check the box for Admin require Identification

3. Check the box for Services require identification

4. Check the box for Turn off registration

This way we will enforce user identification and we have turned off the ability to register as a new user. It
is important that you remember the password for the users you have – otherwise you will be locked out.

When you have accidently locked yourself out you can find the admin database, open it with SqlServerCompact tools.
Find table admin_GlobalSettings and set column TurnOffRegistration to 0 (false) – now you may register
a new user and regain control.

The database is located in __MDrivenServer\App_Data\DatabaseCompact.sdf Now the MDrivenServer is fully configured
and we will look at the MDriven Turnkey application that will use it.

Pointing our browser at the Turnkey application will give us this: https://localhost/MyMDrivenTurnkeyApp1

The reason is that the turnkey application expects to find a file with information about what user and password
to use to access __MDrivenServer. The file should be in the App_Data folder and its name must be TurnkeySettings.xml.

As we see there is a template file “TurnkeySettings – NotInEffect.xml” – copy this and
name it “TurnkeySettings.xml”

This file is normally managed from the LicenseAndTicket web site – but since we are now installing Turnkey
locally the LicenseAndTicket has no access to help us with this. We need to edit it manually.

Open the file and fill in the user name and password you picked for MDriven:

Once this is done we try our app again (you must restart your app-pool so that the file is re-read):

When we use MDriven Designer we will also need to enter the address to our MDriven Server manually – so skip
the first login page and go for the second page:

We must fill in the user and password that has access to MDriven Server, we need to say it is slot A0 and we
need to check “Automated Deploy” – that means an upload of model is automatically deployed.
The server address is the same we use to access MDriven Server:
https://localhost/MyMDrivenTurnkeyApp1/__MDrivenServer

And now we have everything set up to run the development loop or production in house – nothing on in the
cloud.

To update the site with fresh binaries for MDriven Turnkey or MDriven server we can simply reapply fresh packages
from the build server.

Just make sure to choose “Append files” – because if you “delete” you will lose the settings we just did and
the database with any models and

Turnkey architecture

The MDriven Turnkey motor handles the Modernity for us. It is implemented like this:

The Turnkey AngularJS architecture has 4 physical tiers:

1. The turnkey JavaScript-application that the user interacts with – this resides on the client –
in a browser – or in an app

2. The turnkey web-application – built with ASP.NET MVC – able to stream viewmodel transformed changes
to and from the javascript application

3. The MDriven Server that the turnkey web-application communicates with

4. The database that stores your data

Responsibilities

Layer 1 has only access to information according to your designed ViewModels – any actual action
is sent to layer 2 for processing. Layer1 allows for displaying and updating of viewmodel properties. Updates
will be packaged and sent to Layer 2. Layer1 periodically asks Layer2 for updates since last time – Layer1
merges the diff-gram response with the local viewmodel representation. Changes from such merge will trigger
subscriptions in AngualarJS display framework and UI will be refreshed according to AngularJS rules.

Layer 2 is responsible for transforming business objects to viewmodels, subscribe to changes and make available
the changes as diff-grams. Layer 2 executes any logic on your business objects. Layer 2 upholds information
security by controlling a per user access. Layer 2 is the traditional MDriven application level – it
maintains a per user state area with the currently accessed viewmodels and a list of changes per such viewmodel.
It uses lazy loading techniques for pulling data from Layer 3 as needed – and it also use look ahead
data load techniques based on specification of viewmodels to dramatically improve load efficiency and reduce
database round trips. Layer 2 also handle local changed state and owns the transaction context with commit
and rollback of save operations. Layer 2 upholds an undo and redo queue for all unsaved changes.

Layer 3 is responsible for OR-mapping – retrieving and storing business objects in the database.
Here we can also do Server side jobs like sending emails, produce exports or imports that should execute periodically
in your system. Layer 3 also manages client synchronization so that multiple clients efficiently see updates
done by others without the need for total refresh of business object cache.

Layer 4 is responsible for persistence services as storage and efficient search with sql.

Data roundtrip

Layer 2 use the MDriven Datablock definition to send and retrieve data from Layer3 with WCF over Https.

The fashion part of the application will be the make or break of your future users interest and acceptance. This
is where you need to be artistic and creative. No automation in world will help you with this part. MDriven
Turnkey can however make it easier for you to maintain focus on fashion and serve you with just how your fashionable
things connects to your system gist.

Information security

Once you have your system in place and it is protected from all evil – you will want to let users in. The
users are should probably have different access rights and different ability to look at and change data.

One importing fact to achieve this is to make the current user available to your model. The current user is however
handled differently by different implementation scenarios – like on the web or on the desktop.

And even for a particular scenario there are several approaches to identify the user – like using federated
authentication, local active directory authentication, Forms authentication etc. Be that as it may –
however the chosen platform identifies the current user you will want to have access to that user in the model.

In ASP.NET Identity this is the model that covers the user and the users claims:

I also added a Class called SysSingleton. Singleton is really the name of a design pattern that establishes a
Class that will only have one object instance. Thus it is THE singleton. The Singleton pattern is very handy
in situations where you do not have any other context on how to get data. It is so handy that OCL has its own
operator for Singleton. In this case SysSingleton->oclsingleton will give access to the only instance of SysSingleton.
If there is no instance at the time of calling oclSingleton – one will be created (maybe only done on
first system use).

In the model above I added a derived link that says that my SysSingleton points out the CurrentUser.

When I have this I can at any time check if the current user fulfills some requirement like:

SysSingleton.oclSingleton.CurrentUser.IsAdmin=true

This means that Enable and Visible expressions on ViewModel Columns and Actions and even derived attributes can
use this information to enforce information security.

But since it is likely very common to check if an action should be enabled or not for a certain type of user
– or if a ViewModel should be accessible or not for this user another concept is introduced: AccessGroups.

AccessGroups shows up in their own dialog:

You can have as many AccessGroups as you see fit. They will show up in the section marked with green in the dialog
above. For each AccessGroup you define expressions in the blue section. The expressions should evaluate to
true or false and state whether Enable, Visible and View should be true or false for the things in the group.
The things in the group are actions and ViewModels – defined in the purple section.

This way you can define a group like MustBeAdmin and add all appropriate actions to this. You can also add ViewModels.
This is a good way to have all your access rules in one place and reducing the need to repeat their definition
in multiple places.

There is also an AccessExpression on each ViewModel. This allows you to test not only on user credentials –
but also on the root object of the ViewModel. If it returns false the AccessDenied ViewModel will be shown
instead:

Part 11. Information Security

Information Security

IT-security covers security of your Information Technology. A natural subset of IT-security is Information security;
secure your information – in this context – as part of an IT-system.

I often argue that nothing is as easy to sell as fear. Fear of anything. Fear of lacking IT security and Information
Security is no different. It is an easy sell. You just open with the line “are you really sure your data
is secure – because I think it might not be?” Deal! Show me! Help me!

In my opinion these are the obvious IT-security hygienic must haves:

‧ make sure you really authenticate users

‧ have order in your authorization processes

‧ keep your computers clean from unwanted software

But beyond the obvious IT-security must haves - the delivered “Show me”, “Help me” very
seldom comes to any real practical effect – other than “you should not have data worth stealing
– and if you do – you should not let anyone come near it – not even your staff”. Well
Thank you Mr. IT-security expert. Really not helpful.

I have experience from business, government and military – the latter two take IT security painfully serious.
That does not automatically equal that they are safe. But they spend a lot of effort aiming to be safe.

There is a tradeoff between protecting data – and making it easy for the trusted users to work with data.
You must find a level in this tradeoff that reduce risk and does not come in the way of work.

There is no such thing as eliminating risk. Trying to eliminate risk will paralyze you and then you will get
nothing done. Decide what risk level that is acceptable – and note that this level may be different for
different types of data that you have. The risk level may also vary not only on data type and data value but
also on data aggregation; you want to protect the whole of the data more than the individual parts.

The basics of IT security

It is pretty simple really – think of a PC as a piece of luggage on the airport. “Sir did you pack
this bag yourself? Have you watched over it all the time since you closed it? Can you assure there is nothing
in here you received from others?” When it comes to your laptop – or the laptop you got from work
you must say “No!” So your computer is not to be trusted. Period. This does not mean that there
is anything wrong with it – but we cannot be sure. It is easy to sell this kind of fear.

When it comes to the servers for your company that are placed under lock and key – patched and maintained
by educated personnel – we might say “well we sure hope we did not receive anything we did not
want”. So your servers might be safe – and they are easier to trust than user-pc’s.

IT departments will try to toughen your PC up. Again with the luggage metaphor – they might make it solid
– making it impossible to store anything inside. Safer – but you are not helped by a solid piece
of luggage – or a computer you cannot store anything in. And anything in between fully functional and
solid is possible – but they can only do so much – and almost anything they do limits the degrees
of freedom you have with the computer.

The IT department is most afraid that your computer contains Trojan software that infects others at work –
and increase the threat against the servers. Trojans can act as beach-heads inside your company from were hackers
have a line of sight to your servers. Trojans may also be a nuance or even hold your computer for ransom –
but a professional attacking Trojan says nothing - it just steal your data – for weeks – or years.

Once infected it is really hard to trust a complex IT environment again because there are so many places where
the Trojans may “hide” during cleaning. The cleaning will be really expensive – and this
motivates high precautions to avoid infection.

But this text will not deal with that kind of IT-security. I just had to state the facts – to make sure
we are on the same page. This text is how we should build systems in this corrosive and hostile environment
in order to control the risk as we expose our data for authorized users.

Building safer software systems

The thing with building protected software systems is that part of the software will implement the lock that
protects it. I will call “the lock” the AccessControlSystem. If the AccessControlSystem protects
the data from being exposed to the wrong user – then who protects the AccessControlSystem from being
bypassed? This is the heart of the matter.

Did someone tell you that your system is protected by the ActiveDirectory in your company? Wrong – the
ActiveDirectory may be the one handing out the keys to the lock – but the system itself is responsible
for implementing the lock. An AccessControlSystem is almost always part of the system itself (true for all
nontrivial access control), just like the lock on your front door is mounted as a part of the door.

So how do we protect the lock best? Let the lock stay on the server! This is the conclusion that most software
architects has reached. Since the lock is a part of the system – the system must stay on the server as
well. I think that this is the main reason for moving away from rich fat clients on windows to typically a
worse user experience with web-technology like MVC even for in-house systems. Another way to keep the system
on the server is to use terminal server solutions.

The important thing is that it is the AccessControlSystem that filters out the slice of data that we are ok with
showing to an individual authenticated user. Filtering out means that you have a bigger volume to filter from
– a volume to reduce to a subset. It is this larger volume that the AccessControlSystem protects. If
the AccessControlSystem is going to protect this volume and filter ok data from it – then it must have
access to the whole – simple logic.

Having stated these facts we have a clear view of our goal: deliver approved slices of data to authenticated
users – our users are not physically on the servers – they are at their laptops.

Sure MVC-web-approach does just this – but as many have found the reduced user experience is not ideal
for prolonged use in an office. Bulky postbacks and tendency to reduce the amount of data on a single screen
to avoid lag often make web based systems click intensive filled with stressful waiting. To mitigate this many
software architects has started to use ajax and javascript to build a richer user experience to replace the
plain data presentation offered by MVC. When doing so they might start to hold data locally in the browser
and ever so slightly they may start to lose track of our simple goal – maybe implementing filtering in
the browser – maybe keeping data between screen navigations-maybe doing some work that really was part
of the AccessControlSystem. But who really knows – because it is really difficult to see what a software system
actually does without high effort reviewing of actual code.

How MDriven Turnkey does it – every time

To avoid the risk to muddle the definition of the AccessControlSystem but still offer a rich user experience
MDriven Turnkey does 4 things:

1. Let the ViewModel define the slice of data we are ok with showing an authenticated user with authorization
for a specific use case. The user cannot see more by definition in the framework

2. Let the ViewModel reduction of data from the complete model happen on the server – and since each ViewModel
is fully implemented with the declarative Object Contraints Language (OCL) you also have an exact an easily
understood definition of the information subset it contains

3. Define the rules that build up the AccessControlSystems in the model declaratively – with static verification
– and ability to make the rules depend on any data in your model

4. Stream the resulting slice of data – and changes to it – to a client to produce a rich client
experience without slow roundtrips. Expose nothing else

MDriven Turnkey comes with the AccessControlSystem already in place – on the server – you just need
to define your keys depending on your rules based on your model.

Even if you build a WPF, AngularJS or Android client – the AccessControlSystem is on the server adhering
to your rules.

Since the platform has the AccessControlSystem built in the number of mistakes a developer can do are fewer.
The verification of the rules can now be done statically in the model and we do not need to review code to
detect tendencies of muddling the simple goal of ensuring information filtering is happening on the server
only.

MDriven Turnkey user authentication is done with standard OAuth2 allowing for implementations with optional social
login or Single sign on (SSO) with OpenId. Multifactor authentication can easily be made part of your AccessControlSystem.

All communication is done over SSL and if you have stronger crypto needs any tunnel can be used to protect traffic
between user and server.

We claim two important things:

‧ Building software systems with MDriven Turnkey will make them intrinsically safe – meaning that
even the lowest effort expose only what you intend to expose

‧ Using MDriven Turnkey will make your complete AccessControlSystem possible to inspect

even for non-coders – meaning that security officers can understand what risk level individual screens
pose even in an evolving system

Both these properties are highly sought after for organizations striving to minimize risk of unwanted information
leakage – be it from coding mistakes, architectural mistakes, misinterpreted requirements or just plain
laziness of either developers or reviewers.

How the access control system is constructed in MDriven

First we need oblige that the reasons for restricting access can be manifold. It may be as simple as to avoid
confusing a user with too many options at the wrong time in the process – or it may be as crucial as
to protect highly secretive information getting in the wrong hands.

Any practical Access control is probably based on static information as “users belonging to group Fishermen
should not have access to view Treasury”, but also dynamic information as “if a Fisherman has been
granted payment but not collected it yet then he should be able to open the view Treasury”.

Another aspect is that we sometimes want to show that actions are available – but not enabled to you in
this particular moment. And at other times we do not even want to show you that a given action exist in the
system. These are all common requirements when dealing with access control. Since MDriven solves all user interaction
through ViewModels and Actions it is natural that these are our targets for Access Control.

As further explained in “part4 – Actions” we can set any expression in the Enable expression
of an action – so this is one way to make actions disabled. But if we have a rule that is the same for
many actions we may consolidate the rule to an AccessGroup;

The accessgroups are good for the static rules like to check is the logged in user is part of the fisherman group:

And we may also want to give the user a hint to why the action is disabled – this abilityhas reduced the
support requests a lot in all the projects we have done:

For views we refine the access control per placed widget by setting the ReadOnly expression or/and the Visible
expression:

But in views we also have the possibility to work on the whole view:

Setting the Readonly expression on this level effects all the widgets in the view. Setting the access expression
will control if the view is shown at all.

If the view’s Access expression evaluates to false the system will look for a ViewModel named AccessDenied
and if found will show this instead. If no AccessDenied view is found then a blank screen will show.

In order to allow for you to disable an action that would bring up a view that has an access expression that
will evaluate to false given a certain root object – you may check the result of the Access expression
prior to bringing up the view. You do this with the ocl operator canAccess(vmname):bool.

This enables you to disable actions that will end up showing AccessDenied.

This also enables you to stop reports from being created based on a ViewModel and a rootobject that is not allowed
based in the Access expression of the ViewModel.

Working with the described levels of expression you will be able to tailor a perfect fit access control system
that evaluates in the safe realm of your server. All the ocl rules use a few ocl-operators but mostly names
from your model that probably is an ubiquitous language shared with the security officers of your domain.

The transparency and fine grained control of this access control system is precisely what many organizations
need in order to protect their information and still allow for a fast paced development.