Log in

MDriven designer overview Part 1

From MDrivenWiki

MDriven Designer is a UML modelling tool that allows you to capture enough details to actually cover every aspect of a software system. It makes you model the full specification of what you want to explain. The MDriven designer overview sessions were created to provide the answers to all the questions that you might have during the operation process of our service. This step-by-step guide will assist you in MDriven designer effective application.

To make your experience more comfortable, we set the main tags mentioned in the video to the right bar menu of this mini player. Choose the interesting subtitle on the list and immediately get to the exact theme navigation-itemplace in the video. Now you can pick any topic to be instructed without watching the whole video.

MDriven designer installation Interface Overview : Setting New Diagram Add a category Add a class Processes StateMachine diagram TagExtensions Attributes Association FeaturePickForm Setting the color What to show on the diagram? Delete/Hide from view Filtering the repository tree Reintroduce/Introduce associations Anchor points and square line option Additional options: DimDefaults “modlr” file and "ecomdl" file Association tool PluralSuffix property Generalization/specialization mode Reference window Index model and report errors Default String Representation “Enterprise Architect Information" window : Processes More on processes Information Actors Applications Infrastructure

Installation of MDriven Designer

MDriven Designer overview screen with default model.

To outset the guidance we need:

  1. Go to the CapableObjects site and open MDriven Designer by click MDriven Designer use the ClickOnce.
  2. Note! For Chrome and Firefox you may need a plugin to associate the .application extension with ClickOnce (plugin for Chrome / plugin or Firefox).

Click Once is the distribution technology from Microsoft. It updates every time there's a need, otherwise the application stays in your internet cache, so that's a good way to execute the application.

Once you’ve downloaded all the needed extensions and the browser is able to recognize them, you can safely launch the “MDriven Designer use the ClickOnce” link, as you already signed in. Then it started with the “Default” or starting model.

Following up on the benefits of the MDriven designer, here you can define your model and lots of things, regarding your application. We argue that you could create complete software systems using nothing, but modeling with the help of MDriven designer. In as much as you might not believe, so will have to follow this guidance to get to that conclusion yourself.

Setting new diagram

UI elements

What we see first - is the overview screen and it shows, what diagrams there are. In our case as an example, we use only one diagram - "Diagram one". There is also a repository tree, where you also can create and see diagram structure. So, if we were to set up another diagram, by choosing '’Add Class diagram",' it would pop up on both overview screen and repository tree as "Diagram2".

You can change your diagrams, for example changing "Diagram2" to “DiagramMyNewDiagram”.  The things we point at in the tree are usually have properties that might be set. (Object Inspector field of properties lies under the repository tree). We also can edit the “Diagram1” name on “DiagramMyFirstDiagram” straight from the “Name” properties menu in the Object Inspector. Some of these properties on how the diagram should behave. There is no critical need to use them, but it is recommended for better quality of control.

Add a category

Chose the “Add a category” option in the repository tree area. The “New category” supposed to have only one property name, where we name it as “Important” one, while another category appeared to be  ”Less Important”. Once you have categories you could set them on both diagrams as “Important”, for example.

To enter a whole diagram you would just double-click it or pressing the “Switch Back Arrow” to return to the overview screen. Another way to move between the diagrams using a repository tree as well.

Right clicking the screen inside of the diagram, the options menu drops down, where we can “Add a class”, for instance, “Class1” that will appear in the repository tree and overview screen section of “DiagramMyNewDiagram''.

Classes that are created really lives in a “Package” and you can have multiple packages, but it's not necessary to use multiple packages, just think of that as a way to section a software system, so called namespace.

Following the logic, the diagram is just a representation of the class. Having created the “Class2” in the “DiagramMyNewDiagram'', we can always drag it from the repository tree to the “DiagramMyFirstDiagram” on the overview screen. That doesn't mean it disappears from the initial spot, as it’s just two different representations of the same classes and that are in our complete model. In our repository for the model you can actually add other things too, and the diagrams as well, helping you to get an overview or to get navigation, or to navigate between things. Also, we can include “DiagramMyNewDiagram” into “DiagramMyFirstDiagram”, which will be illustrated on the overview screen as a thumbnail picture one diagram containing another.

If you are newbie in UML or not experienced enough, you should follow our UML School — Class diagram



A process is just a workflow of the order you should do things. Double click it on the repository tree and you will get the view of “Processes“ in “Enterprise Window”.

We will name it “'Fetching Mail'” and create some steps involved in this process.

In such a manner, this is more like a documentation of what you have learned in the domain, that you're designing for. Once you have that, you could add a small “process diagram” to the screen and dress this up with more information as you model further.

However, we have reviewed two types of diagrams, there is actually one type, that needs to create an attribute on the “Class1” to see and that is the important “StateMachine” diagram. Once we’ve added the StateMachine, we immediately jumped into the new “StateMachine”, but, if we switch back, we should have ended up on the “DiagramMyFirstDiagram” field, having gotten the new attribute to the “Class1” called "State". That is actually a state attribute.

State diagrams

The state diagram is really what kind of name states, that your information can be, another way to describe states of your domain, for instance it’s about  “FetchingTheMail”.

If the state attribute isn't shown on the “Class” icon, then we need to add some small widgets to see that. As long as this hasn’t been done automatically, do it manually on the functions by adding the “TagExtensions”. The TagExtensions show up as a dialogue and we will ensure the default TagExtension:

  • "statediagramsymbol"
  • "triggermethod"
  • "constraintclass"

Since the tag extensions has a WPF xaml definition, we can add a new symbol easily, patching some xaml that is prefered to view.

Once we have done that, we can use the extensions for different things. In our case, if we take a look on the diagram there is a little widget appeared, stating the "S" for the state diagram.

That is a sort of the coverage of the different types of diagrams,  that are available in MDriven designer. Everything works the same way, as if you point something, it is selected and you could change some properties in the proper field or the name of the class to "House". Either standing on the actual “Class” name and pressing f2/double clicking to edit, as well. Moving around with the arrow signs and arrow characters helps to navigate the model easily or just do it with the mouse. In addition, you can select many to move them in together.

For instance, the "House" has several attributes. You would go about adding an attribute (Ctrl+A) and edit those in place, just by double clicking make it changeable to "Address". An attribute needs to have a type. As we point the "Address”, the possible types are available in the Object Inspector picker. These are the types that are available for you, if you are going to execute your modelling, turnkey.

All the classes, that you add also turn into types, but model type isn't used as an attribute type. It's instead called an Association. They can be created just by picking the Association mode tool and dragging between two classes. Noteworthy that the class is in the package, it's not really on the diagram, as the last one is just a way to show that class. So if we were to switch the diagram back to the other one, can see that since this show the same class it also shows the same attributes as we added many. Adding even more attributes, it will be also visible on the other diagram.

What you can do if you don’t want that? Right clicking on a class, say "Features", where the “Show features” is checked. We can also choose optionally what features to be shown on just current diagram. Clicking “Pick show features…” brings up dialog "Featurepickform". Here we can state what mode it should be (show all, show only picked, hide only picked or hide all). Go on choosing "show only the picked” one and pick the "Address" and the “State”, it will appear on the Picked Attributes side as well as on the overview screen. That doesn't mean that the rest of the attributes aren't available. As you see in the repository they are still there, but we have chosen not to show them on this screen. At the same time on the other diagram, you are still there.

So this is a way to design your diagrams to focus on a single issue that you want to describe. You could also give the placed classes a colour on the screen that differ from default. Choosing this option in Object Inspector, let's pick a blue one for the “House” in the current diagram. However, sometimes we want any "House" class to have a certain colour and then we can instead set the default colour on the class. In the first case the blue “House” stayed the same colour, because it's what we told explicitly to be. However, we can also see that it has been set the default colour as gold. So if we were to clear the blue one out, it will turn gold. That is one way to give your model colour.

Deciding what to show on the diagram, you could right click on the class and say "Features", "Pick show features". A shorthand for this is just standing on the attribute and pressing "Delete". As you might think, that this would actually remove or delete the attribute from the repository, but that is not the case. What happened was really the "Features"," Pick show features" and then in the "Featurepickform" it has been updated to remove the ones that I am not interested in.

What if we actually want to delete “Attribute1”? Then we have to press "Ctrl+Delete", so "Delete" is most often stands for hiding from view. For instance, we want to "Delete" this class, just having it selected and pressed "Delete". It will disappear, but still be in the repository, so we can get it back that way to actually remove it, again it's "Ctrl+Delete". Now press the "Edit”,”Undo"  to get it back.

If we drag on another class to the diagram one, that actually has a relation to the "House" that will be shown. I can also drag on the "House" one more time and repeat the process on the overview screen. The common use case for this is actually when your diagram is large and maybe "House" is just a peripheral class to something that needs to be shown in various locations. So then it would be good to be able to duplicate it and show it in many places.

But maybe you don't want the associations to show. Let's say, that we have another class and we call that "Street. We create an association between "Street" and "House". How come there's no association between the other “House”s in the diagram? That was because the "House" class came into this diagram before the "Street" even existed. If we were to remove this with "Delete" and add it again, then it would be there and the rest are optional.

In case you want to "View or not" assosiations just press "Delete" to remove them from view and “Ctrl+Delete" to actually delete. In addition, having selected "Undo", we will get them back. If it needs to remove from the view in this location, just press "Delete".

Let's have that deleted, and at this point both classes lacks the association to "Street" in this diagram By filtering the repository with the "House" we can see:

  • "House" the class
  • "House" attribute 10

" Attribute ":

  • everything that matches "attribute" and isn't a class

". House":

  • all the association ends that are named "House"


  • "Street" the class
  • "House" -  the "Street" association name
  • "Street" – the "House" association name

Of course, these options are selectable; we are able to set the properties and they all in the Object Inspector field. Press "Esc" to clear the filter search and get back to the repository tree, all the things are available on the screen, as well.

If we want to reintroduce associations, right-click and say "Introduce and remove", where "Introduce pick from available"  says "House".  However “House" is already on diagram, it won’t be able to do it. For instance, we removed the association between the “Street” and he “House” classes and using the "Re-introduce removed associations" option we can get it back.

Associations have the anchor points on their classes, so it should be possible to design your diagrams. Grabbing an associations introduce via points. Recommended to use the square line option that intended to do things in 90 degrees for more clean and manageable design. This so common, so clicking the backside to get the diagrams properties in the Object Inspector, set it to “square new associations”, so all associations will be defaulted to squared.

There are smaller options on the diagram. Right-clicking backside show "association names", which we need to set to "DimDefaults". What we mean by this action is that this dimmed "Street" and the "House", because these haven't actually been given hard names, which has arrived from what they are pointing at. Another two options for “show association names” besides “DimDefault”:

  • “AlwaysEvenDefaults leads to hard black all the aspects of the associations.
  • Ability to show and tell the diagram to not draw the defaults at all –“NoDefaults”.

Having a little model, there is an important matter to save it. Creating and saving  the e.g. c:\temp\demo55  , there are two ways for system to treat it:

  • Saving as a “modlr” file → will be treated as one zip file, where we can see all the parts in it;
  • Saving is a "ecomdl" file → format and this is saved  as the individual parts, so then we get all the parts and each of it is well-formed XML

Taking a look at the "association" tool that helps you combine things together with associations and where you can set the cordiality on the ends. It is also manageable on the property inspector, Or do a manual editing by writing something on the ends like: "*" or "1" or "0..1" House”. Immediately we see the "e" (stands for embed) to pop up. Usually, there is “many-to one” side of an association in this case, this side will actually store the key to this single object and then the key is where the association is embedded in this class. What of we need to get keys for  a one-to-one associations, so  that's why we actually write it out explicitly, but this is consider more or less an error because it's redundant to embed the key both in "House" pointing out the "Street" and as well in the "Street" pointing out the "House". So we need to choose one, that actually embeds and remove embed from the other one, manually.

It’s more convenient to use when the "House" has 0..1 "Street", but the "Street" can have multiple "House"s in fact it might be and a good practice to have the default name of this. This is now named "House", but maybe it would be better to put a plural "s" on all their multilinks, that would make the default associations a bit more correctly.

We can actually set the property on the package, remembering that all our classes belong to one package, "Package1" in  this case and there's a property called "PluralSuffix", so is there anything  Our goal is to append suffix “s” to everything that all association ends with. If it seems to not enough you can always over wright it with the specific name.

Heading back to the overview screen now we want to focus on a little thing looking for something special among all the diagrams. You can always turn on the magnifier, there's a looking glass, that is held over the diagrams to find the details, locate things.

Here the overview of all the diagrams, but in this way we also can manage all the classes and their relations that are currently in the model, information, actions and even the 3D view if it necessary to do so. This is pretty much work in progress still so we figure out, how to use it best.

What about generalization/specialization mode?

Let’s create a base class or super class for "Street" called "Location" , and "Street" is a type of “Location”. So "Street" is then a specialization of "Location". Taking a generalization arrow, drag it from "Street" to “Location”, because in this direction things get more specialized. The next step is a property for “Location” called “Position”, logically that the "Street" actually inherits the attributed "Position".

How does the association class connection mode work?

This is commonly used, if you have many-to-many relations where the key is not embedded at any side because there can be many classes for each of them. So what we'll need to be done logically is to introduce a link class in this association. Clicking the association, we have an option of picking its specific class to say that this is the Association class. it is also manageable with the association connection tool. Dragging the arrow tool we get a dotted line it means setting of the association classes. You can control the ”Association Class” tool factors from the Property Inspector where:

  • If we null it -  the dotted line will disappear
  • If we add it again - the dotted line will not be introduced, because that would be the same as we had removed it by hand, so go to the "Introduce and remove", "Reintroduce removed associations".

Introducing some of the other toolbar items

The reference window is just to get a read-only copy of one of your diagrams, if you need to compare something one diagram with another and you want to see them side-by-side. it might be good to be able to have multiple diagrams on the screen at the same time.

"Index model and report errors..." actually runs through the model to check that everything seems fine it checks all the expressions, that we may have in our model.

There was the question about what "Default String Representation" of the “House” is. So if we would do this by writing a small OCL object constraint language expression, so here we are in context of "House" and we would use the Address "self.Address", like that  and then the expression is there, if we check -  it's fine, but if the expression would be something different - that is not an available property. We would get an error indicator saying that the "Default String Representation" on "House" is not a member of "House" . Since this is in error, when we bring up to editor, we will also see that the "AddressX" is not a member of "House".  For now it is enough to fix this error by removing the "X", however the ria also other ways to do it through the OCL object constraint language expression.

With the help of “Enterprise Architect Information" window we can add processes and how they connect to each other. We can have and add "entries", "catalogue entries",  that aren't really classes, but are more concepts, that we use our classes to fulfil. For instance one concept might be "Place to live" and the "House" implements “place to live". Tying things together will bring further information on the classes.

The "Actors" are "Mailman", "Home Owner", you can  add a "motivation" or “user story” for actors as well. This also can be implemented by one of the steps in our processes.

As we go deeper down on the Enterprise Architect Information window, we have the “Applications”. What do we actually have in our enterprise are that tools for people in the enterprise to use, for the actors to manage and that’s the whole point of the apps. The applications needs some kind of infrastructure.

These are the core concepts of the "Enterprise Architecture Information"

  • how infrastructure relates to applications
  • how applications are used in processes by actors
  • how they all work on information
  • how the information is tied to implemented by classes

We will see that all of these things tight together in the end so that you will have a complete understanding and documentation of all the things that you choose to model.