Monday, December 21, 2009

Knowing nothing, where to begin

When you are dropped by parachute deep behind enemy lines with nothing but your analytical skills – where do you start? Ok, I probably should not compare the client and their business with hostile territory filled with enemies. Sorry! But still! Where do you start if you know nothing?

You say “Hi!” to everyone, exercise your complete toolbox of people skills, follow everyone to lunch, buy the informal leaders beer etc… But that is not enough is it?

Being a developer using ECO and the strategies proposed by DDD I will know what to do once I know what “the whole thing is about”. But the client is not really equipped to tell me what I need to know spontaneously, so I need some strategy to get that information extracted from them.

This post is about that strategy. Ok, I know there must be like a million ideas on how this is done. This is the way we do it:

  1. Gather a representative group of people from the domain
  2. Set up a workshop and let them brainstorm on who is showing any interest at all in what they do. More specifically ask them: who calls you on the phone, who emails you,  who comes to visit, who delivers stuff, who sends you stuff, who buys your stuff, etc. All these questions are reversible: Who do you call, Who do you email etc. Collect this information and keep it as the Triggers.
  3. For each unique persona from step 2 find out what the goal of this persona is; why does X email you, what is their goal? Why do you email that person, what is your goal? Collect this information and keep it as the Goals.
  4. Split your group into smaller groups and let them break down each non-nonsense combination of trigger and goal into some steps that are central in getting to the goal. Make them aim for 5 steps. If they have a hard time getting started, encourage them to bring up just 1 step. Example: “Trigger is Customer, Goal is Getting a loaf of bread”. One obvious step is “handing the bread to the customer”. Great! Now force your group to explain what they do before- , and what they do after that step. “Need to fetch the bread from the shelf” is before, and “Receive payment” is after. This is going great! Continue like this, and throw away the silly steps and keep the important steps. What they create here are overviews of what their business is about. Keep this information as Processes.

After you are thru these steps you will have a pretty good idea on what you are up against. You will have a set of high level processes. Document these in or ECO:



Some processes that you have already found might be detailing processes for a another process. And some steps in a found process might need detailing in further steps; you should callback your domain group to help you out with that.

By arranging the processes as “detailing” a step, you build up a structure in the Modlr tree:


Do you really need to involve real domain people? Will it not suffice with reading some existing documentation and talking to some IT-guys in the company? No. It will not suffice for 2 major reasons:

  1. You do not know what the real issue is – it might be that the current documentation and or the current IT-crew is wrong.
  2. You really need to get real people involved so that they feel and know that you are on their side. After all you will be a central player when it comes to change of these peoples working environment. You need to earn trust, you need to communicate, you need to make them involved. If you do not you will have a hell of a time trying to get the real people to understand the greatness of your work once you are done. And then it is all for nothing.

When you have reach this far you need to start on the information model. Create 1 class diagram per process and associate the two:


As you focus on a specific process when creating this class diagram you get a small and readable result:


The Process diagrams indicate that they are associated to class diagrams, and you can click the Icon to jump straight to the class diagram:


Further more the Process tree gives you a good structure of diagrams:


Now you have the big picture on “What it is that happens” from the processes, you get the “What information” view from the class diagrams. All you need now is the detailed business rules that controls this process. Being totally into declarative development, I only consider for short while to actually start to write c# code to catch these. But the state diagrams are better because the documentation gets clearer and maintenance will be cheaper in that form (our point of view). You can associate these to processes as well:



Once you have reached this far you may want to take it yet another step: Declare a viewmodel per process… But I will save ViewModels for another post.

Summing it up

The process tree will give you a navigation of diagrams and artifacts. The processes will make it easier for an outsider to understand the domain. And if you are a group of people where some do client communication with process modeling and some take it further with development you can now share one tool to keep your development efforts collected.

Weather you choose to do everything in your development declarative as we do, or only part of your your work declaratively and the rest by traditional coding is entirely up to you.

Total cost of using

If you control your own method and you think that fits, you can even license; we will stripe it so your clients see your logos and they need not to know anything about us. You will then both have a tool and method. You will be free to price the tool as you see fit and the payment models are up to discussion but very modern and flexible. Email us today: sales at .

Sunday, December 6, 2009

Catching more information in your model

Once you have started to travel the path of Model driven development you might find that the declarative approach is useful for even more things than what you thought of at first.

You may find yourself searching for a way to mark up certain classes as UserFriendly or an association as being HeavyToLoad, so that your code can see this and perform differently. Of course you can create code that checks if it used on a particular class or on a particular association, but that will eventually cost you in more maintenance.

We cannot and should not try to understand your future needs, after all you probably do not even know yourself yet. So what to do… Tag extensions…

Tag extensions definition


Brings up this dialog


You can create new extensions. In the example above there are 3 extensions, Kasper.Seeker, EcoExtensions and Kasper.

Each extension has a number of TagTypes – on the example above the Kasper extension has 4 tag types; Kasper.AutoSeekAndPick, Kasper.AllowUserNew, Kasper.UserFriendlyClass, Kasper.BusinessDeleteValue.

Each TagType is applicable to only one type of “TagExtendableItem” in the item. In the example above the Kasper.BusinessDeleteValue is active on Association end points.

A TagType can be made to act as a enumerable valueset, the example above allows for 4 values; PSCheckMustBeEmpty, MustBeEmpty, OkEvenIfNotEmpty and NoOneHasMadeADescisionForThisYet.

Tag extension usage

Once you have defined the tag extensions the property inspector is updated.


The Extensions shows up as any other properties of your modeled elements.

The values of the tag extensions are stored as tagged values and translated into .net code attributes in the generated code:

   1: [UmlElement("AssociationEnd", Id="31cfadd7-2b04-493c-a5e5-399913764949", Index=Eco_LoopbackIndices.Reserverad)]
   2: [UmlMetaAttribute("association", typeof(KasperPackage.LagerrorelsePrioriteringLagerrorelsePrioriteringarAnvandareReserverad), Index=1)]
   3: [UmlMetaAttribute("multiplicity", "0..1")]
   4: [UmlTaggedValue("Kasper.BusinessDeleteValue", "OkEvenIfNotEmpty")]
   5: public Anvandare Reserverad {
   6:   get {
   7:     return ((Anvandare)(this.eco_Content.get_MemberByIndex(Eco_LoopbackIndices.Reserverad)));
   8:   }
   9:   set {
  10:     this.eco_Content.set_MemberByIndex(Eco_LoopbackIndices.Reserverad, ((object)(value)));
  11:   }
  12: }

And you can access it in your code, either by using standard .net approaches to get to code attributes, or by using the extended meta  information that ECO brings.

   1: foreach (IStructuralFeature sf in TheObject.AsIObject().UmlClass.AllStructuralFeatures)
   2: {
   3:   if (sf is IAssociationEnd)
   4:   {
   5:     IAssociationEnd ae = (sf as IAssociationEnd);
   6:     string tv = ae.TaggedValues.ValueForTag("Kasper.BusinessDeleteValue", "NoOneHasMadeADecisionForThis");
   7:     if (tv == "PSCheckMustBeEmpty" || tv == "NoOneHasMadeADecisionForThis" && !(ae.DeleteAction == DeleteAction.Prohibit))

Tag extension visualization

Even if the Tag extensions has been in ECO and for some time, a new way in how they can be displayed has been added recently. A new tab on the TagExtension dialog called Symbols has been added:


In this dialog you can define symbols that are built up by a piece of xaml:

   1: <Rectangle xmlns='' Fill='Blue' Width='16' Height='16'>
   2:   <Rectangle.RenderTransform>
   3:    <RotateTransform Angle='45'/>
   4:    </Rectangle.RenderTransform>
   5: </Rectangle>

Any stand alone xaml is valid to use here so you can define any kind of symbol you want.

You can then associate the TagTypeValues to a symbol:


And then your diagram displays the symbols when the values are set:


When hovering over a symbol, you get a tooltip that explains what tag extension it is and what the value is.

So start decorating your business models. Move stuff from your memory to Modlr for more people to see and for you to relax. Remember that development is still the hardest thing in world to truly master so accept any help you can get.

Contact Us | Terms of Use | Privacy Statement © 2009 CapableObjects