MDriven designer overview Part 1
No edit summary
No edit summary
Line 95: Line 95:


Although we have reviewed two types of diagrams, there is 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 jump into the new “StateMachine”, but, if we switch back, we should end up on the “DiagramMyFirstDiagram” field, having gotten the new attribute to the “Class1” called "State" that is actually a state attribute.
Although we have reviewed two types of diagrams, there is 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 jump into the new “StateMachine”, but, if we switch back, we should end 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 what its name states: that your information can be another way to describe the states of your domain. For instance, it is about  “FetchingTheMail”.
If the state attribute isn't shown on the “Class” icon, then we need to add some small widgets to see that. If this hasn’t been done automatically, do it manually on the functions by adding the “TagExtensions”. The TagExtensions show up as a dialogue - we will ensure the default '''TagExtension''':
* "statediagramsymbol"
* "triggermethod"
* "constraintclass"
Since the tag extensions have a WPF xaml definition, we can add a new symbol easily, patching some xaml that is preferred to view.
Once we have done that, we can use the extensions for different things. In our case, if we take a look at the diagram, there is a little widget that appeared, stating the "S" for the state diagram.
This is a sort of coverage of the different types of diagrams that are available in MDriven designer. Everything works the same way. If you point at 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 rather, use a 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 to make it changeable to "Address". An attribute needs to have a type. As we point to 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 modeling, turnkey.
All the classes, that you add also turn into types, but the model type isn't used as an attribute type. It's instead called an [http://wiki.mdriven.net/index.php/Part_8_Link_Objects_association_classes Association]. These can be created just by picking the Association mode tool and dragging between two classes. Noteworthy is that though 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. If we were to switch the diagram back to the other one, you can see that since this shows the same class, it also shows the same attributes as we added many. After adding even more attributes, it will also be visible on the other diagram.
What can you do if you don’t want that? Right-click on a class, say "Features", where the “Show features” is checked. We can also choose what features we want to be shown on the current diagram. Clicking “Pick show features…” brings up the 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. This 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.
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 differs from the 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 explicitly told it to be. However, we can also see that it has been set with the default colour as gold. If we were to clear the blue one out, it will turn gold. This 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", or "Pick show features". A shorthand for this is just standing on the attribute and pressing "Delete". Though you might think that this would actually remove or delete the attribute from the repository, that is not the case. What happened was that the "Features", " Pick show features" and then the "Featurepickform" has been updated to remove the ones that I am uninterested in.
'''What if we actually want to delete''' “Attribute1”? Then we have to press "Ctrl+Delete" - "Delete" most often stands for hiding from view. For instance, if we want to "Delete" this class, select it and press "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”, and ”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. It would be good to be able to duplicate it and show it in many places.
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 is optional.
In case you want to "View or not" associations, just press "Delete" to remove them from view and “Ctrl+Delete" to actually delete them. 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 lack 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":''
* "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 are 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 the diagram, so it won’t be able to do it. For instance, we removed the association between the “Street” and the “House” classes. By 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 association introduces via points. It is recommended to use the square line option that is intended to do things in 90 degrees for a more clean and manageable design. This is so common. By clicking the backside to get the properties of the diagrams in the Object Inspector, set it to “square new associations” - 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, because of 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”.
When you have a little model, it is important to save it. Creating and saving the file to e.g. c:\temp\demo55, there are two ways for the 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 as an "ecomdl" file →  format and this is saved  as the individual parts, so then we get all the parts and each of them is well-formed XML
Take 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 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 a “many-to-one” side of an association - in this case, this side will actually store the key to this single object. The key is where the association is embedded in this class. What if we need to get keys for a one-to-one association? This is why we write it out explicitly, but this is considered more or less an error because it's redundant to embed the key both in "House" pointing out the "Street" as well as in the "Street" pointing out the "House". We need to choose one that actually embeds and removes the 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 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 correct.
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 the suffix “s” to everything that all associations end with. If it seems insufficient, you can always overwrite it with a specific name.
Heading back to the overview screen now, we want to focus on 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 or locate things.
Here is 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 is necessary to do so. This is pretty much a work in progress as we figure out how best to use it.
'''What about the generalization/specialization mode?'''
Let’s create a base class or superclass 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, 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 on any side because there can be many classes for each of them. 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 which means the 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", and "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 from one diagram with another and you want to see them side-by-side. it might be good 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 we may have in our model.
There was the question about what the '''"Default String Representation"''' of the “House” is. If we would do this by writing a small OCL object constraint language expression, we would be in the context of "House" and we would use the Address "self.Address". Then the expression would be there. If we check, it's fine, but should the expression 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 it up to the editor, we will also see that "AddressX" is not a member of "House".  For now, it is enough to fix this error by removing the "X". However, there are also other ways to do it through the OCL (object constraint language expression).
With the help of the “Enterprise Architect Information" window, we can add processes and how they connect to each other. We can have and add "entries", and "catalogue entries" that aren't really classes, but are more concepts, that we use our classes to fulfill. 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", and you can add a "motivation" or “user story” for the actors as well. This can also 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 we actually have in our enterprise are the tools for people in the enterprise to use, and for the actors to manage. That’s the whole point of the apps. The applications need 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 and implemented by classes
We will see that all of these things tie together in the end, such that you will have a complete understanding and documentation of all the things that you choose to model.
[[Category:MDriven Designer]]
[[Category:MDriven Designer]]
[[Category:MDriven Designer Sessions]]
[[Category:MDriven Designer Sessions]]

Revision as of 05:39, 14 June 2023


MDriven Designer is a UML modeling tool that allows you to capture sufficient details to cover every aspect of a software system. It enables you to model the full specification of what you want to explain.

To make your experience smooth, we set the main tags mentioned in the video to the right bar menu of this mini-player. Choose an interesting subtitle on the list and immediately get to the exact theme navigation item place in the video. Now you can pick any topic to be instructed on 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 the default model.

To outset the guidance we need:

  1. Go to the https://mdriven.net/designer site and open MDriven Designer by clicking "Run with 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 safe 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 since you already signed in. It started with the “Default” or starting model.

Following up on the benefits of the MDriven designer, here you can define your model and do more, regarding your application. We argue that you can create complete software systems using nothing but modeling with the help of the MDriven Designer. This may be doubtful to you, so we encourage you to follow this guide to get to that conclusion yourself.

Setting a New Diagram

UI elements

The overview screen, which is the first thing we see, 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 can create and see the diagram structure. If we were to set up another diagram, by choosing '’Add Class diagram",' it would pop up on both the 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 usually have properties that might be set. (Object Inspector field of properties lies under the repository tree). We can also edit the “Diagram1” name on “DiagramMyFirstDiagram” straight from the “Name” properties menu in the Object Inspector. Some of these properties affect how the diagram should behave. There is no critical need to use them, but this is recommended for a better quality of control.

Add a Category

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

To enter a whole diagram, double-click on it or press the “Switch Back Arrow” to return to the overview screen. Another way to move between the diagrams is by using the repository tree.

When you right-click the screen inside of the diagram, the options menu drops down, and we can “Add a class” - for instance, “Class1”, which will appear in the repository tree and overview screen section of “DiagramMyNewDiagram''.

Classes that are created live in a “Package”. You can have multiple packages, but it is not necessary to use multiple packages. Think of it as a way to section a software system or 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 that are in our complete model. In our repository for the model, you can add other things, including diagrams, to help you to get an overview or navigation, or to navigate between things. We can also include “DiagramMyNewDiagram” into “DiagramMyFirstDiagram”, which will be illustrated on the overview screen as a thumbnail picture of one diagram containing another.

If you are a newbie in UML or lack sufficient experience, you should follow our UML School: Class diagram.

Processes

Processes

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

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

In such a manner, this is more like 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.

Although we have reviewed two types of diagrams, there is 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 jump into the new “StateMachine”, but, if we switch back, we should end up on the “DiagramMyFirstDiagram” field, having gotten the new attribute to the “Class1” called "State" that is actually a state attribute.

This page was edited 79 days ago on 02/10/2024. What links here