Monday, October 26, 2009

Segmenting definition and logic

ECO makes it easy to define models. To reuse a model you can simply import a ecopkg.

image

This will make the package part of your model and you can edit the contents of the package. Code generation will also create new code and empty stubs for code implemented operations.

Normally you want to reuse the whole model assembly that may contain code implemented operations, maybe code derived attributes and relations and so on.

To do this you choose the “Edit referenced packages” option instead:

image 

Then choose “Add” and find a ecopkg you want to use as part of your complete model:

image

In this post I choose the EcoAspProvider.ecopkg that comes with the ECO install. This package implements the membership functions for ASP.NET as eco objects.

When referencing a package like this, the classes in the package are made read only. You can still draw associations to and from the classes in referenced packages as long as the association end is not embedded in any read only end. In other words: you can point out read only classes, but you cannot make a read only class point out anything new. Give this some thought and you will probably find it very intuitive; the external, referenced, definition cannot be changed in this context.

A referenced package is NOT code generated with the rest of the model. The referenced package probably comes with a compiled assembly or project of its own that use the definition in runtime. Add a reference to this as you would do with any other externally defined logic in .net:

image

If you try to change a property of a referred package ECO will stop you: image

To make your solution use the referred package you must click the choose package icon in the ecospace designer:

image

Then make sure that all packages you want to use are selected:

image

Then make sure you generate code and build your solution before you generate the schema (the schema is derived from the runtime model that is derived by looking on the code alone)

Sunday, October 18, 2009

UML Inheritance

With the ambition to make it easy for people to benefit from object oriented approaches using eco and gaffr.net I will in this post give a quick introduction to UML inheritance.

UML inheritance is different from “I get you 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# & VB.NET does not, and since eco focus on the latter languages eco does not support it either), so I will not mention multiple inheritance again in this post. This means that a class can only have one parent class (or no parent class of course, but never many parents).

An example

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

image

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 eco and gaffr.net that when you add a generalization associations, the class’s superclass is updated in the object inspector.

image

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

Why is inheritance so useful?

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

image

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.

With the model we have now we can see the benefit that strong types give. Our code will now look like this:

   1: Country malaysia=new Country(this.ServiceProvider());
   2:  
   3: Apple apple = new Apple(this.ServiceProvider());
   4: Orange orange = new Orange(this.ServiceProvider());
   5:  
   6: apple.GrowsInTheseCountries.Add(malaysia);
   7: orange.GrowsInTheseCountries.Add(malaysia);
   8:  
   9: foreach (Fruit fruit in malaysia.ExportsTheseFruits)
  10: {
  11:     if (fruit is Apple)
  12:     { 
  13:       // Do apple specific operations
  14:     }
  15:     else if (fruit is Orange)
  16:     {
  17:         // Do orange specific operations
  18:     }
  19: }

 

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:

image

I add a method on fruit that I make virtual:

image

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

image

 

   1: public partial class Fruit {
   2:     public virtual bool HasSeedsYouNoticeWhenYouEat()
   3:     {
   4:         return true;
   5:     }
   6: }
   1: public partial class Banana {
   2:     public override bool HasSeedsYouNoticeWhenYouEat()
   3:     {
   4:         return false;
   5:     }
   6: }

So having this I can write code that go over a list of Fruit and ask if the fruit HasSeedsThatYouNoticeWhenYouEat like this:

   1: List<Fruit> crapfruit = new List<Fruit>();
   2: List<Fruit> okfruit = new List<Fruit>();
   3: foreach (Fruit fruit in malaysia.ExportsTheseFruits)
   4: {
   5:     if (fruit.HasSeedsYouNoticeWhenYouEat())
   6:         crapfruit.Add(fruit);
   7:     else
   8:         okfruit.Add(fruit);
   9: }

Did you follow me so far?

If you are still with me 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 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”.

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 superclasses) 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.

Are you relatively new to UML or Object Orientation? Download eco for visual studio or the standalone Gaffr.net UML executer to get free access to the tools that will truly help you to evolve your OO-thinking in a direct and fun way.

Thursday, October 15, 2009

Model Driven

There are a lot of acronyms out there. This post will set things straight on how we, capableObjects, define these and how we use them.

MDA – Model driven architecture – The idea that the model for an information system can be described in a platform independent format (PIM), and that the PIM can be transformed into artifacts that build up vital parts of the resulting IT-solutions. We at capableObjects are currently geared towards the .net arena and we have no ambition to be platform independent with our MDA-Framework ECO; still we see the benefit for all organization to develop PIM’s in order to secure their definitions in a longer perspective. Using the PIM approach the investment for information design is safeguarded against shifts in technology. Our solution to PIM-production is the Modlr uml design tool. Modlr is part of both the ECO-designtime-Visual-Studio-plugin and the standalone model-and-execute tool Gaffr.net.

ECO allows for applying the PIM in the UI layer by transforming it into ViewModels that in turn can be transformed into user controls for different UI architectures; WPF, ASP.NET, Windows forms and Silverlight.
ECO can apply the PIM result in Handles designed for different UI architectures; WPF, ASP.NET, Windows forms and Silverlight
ECO can transform the PIM into c#, VB.NET or Delphi.NET code (code generation)
ECO can transform the PIM into relational database schemas for SQLServer, Oracle, MySql and many more
ECO can put the PIM to use on a server to act as a OR-mapper for other PIM compliant services

MDD – Model driven development – The idea to focus development efforts on a model and using the model as core definition and template for the rest of the artifacts needed for the finished product. Changes always go into the model first and then trickle down to the derived artifacts. The artifacts may be largely derived by an automated process (code generation, db schema generation) but could just as well be hand made. The gain in production speed and quality is largely omitted if you use the hand made approach.

ECO is model centric. Changes go into the model first, you then update the code, keeping your handwritten additions to the largely generated domain layer by utilizing partial classes. ECO also use the re-engineering capabilities of Visual Studio to apply changes done in the model thru out your code. The database schema is updated by a built in evolve function that use as non intrusive methods as possible on your existing database to change it from the original form to the form that  is described by the model.

DDD – Domain driven design – The idea that the model should adhere to the terms and definitions from the domain the system is built for. To many of us that have been modeling business for many years this is kind of a no brainer; how would you do it any other way? But think about it like this: We can understand the domain very well but still choose to model it with abstract and non domain specific names. Maybe in an effort to create a reusable model for other domains with the same need, or maybe in an attempt to create an optimized version of the domain. That model can be still be used with MDA and MDD but it would not be DDD. DDD aims to create an ubiquitous  language between developers, modelers, domain experts and stakeholders, and thus taking the technical mumbo jumbo out of creating IT-systems.

ECO is great for DDD. We have not done anything extra for making it a good DDD tool apart from making it a super MDD and MDA tool. DDD is describing the mindset you have while modeling and not really saying anything on how to use the model once you are done.

Suggest a topic for this blog?
Guest post on this blog?
Email me Hans at capableObjects.com

Sunday, October 11, 2009

Association classes

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

Model1:

image

 

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.

Model2:

image

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 would 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 this another way will give the exact same OR-Mapping result:

Model3:

image

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 a 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 – the db-guy will not know the difference but then again they seldom do.

(Side note: Entity Framework does not currently support association classes. They argue that there is no need since the Model2 can be replaced with Model3 (No surprise since they are db guys :-) )  )

Saturday, October 10, 2009

Think about this for a minute

Deep down in every system there is a model.
Weather you see it or not, it is there

The model is the description on what data your system thrives on.
The model describes how your data relates, what properties it has and what that data is called. Whenever people talk about what your system does, they talk in a language that is defined by the model.

Some people keep the model in their heads alone, or in a separate file on their hard drive.

This leads to all kind of challenges when communicating within the developer team and when communicating with the customer; not unlike the whispering game where information degenerates as it passes from mouth to mouth.

This degeneration leads to subtle differences between the database schema and the application code and differences amongst the members of the team as well

These differences are not usually seen by the different parties; everyone involved thinks that they have the correct understanding of the information; just as the classic effect of the whispering game

The differences sooner or later show up as internal incompatibilities and as an increased friction when the parties involved try to be productive and focus on development.

Developers have grown accustomed to this increasing friction that makes it harder to maintain and develop a system the older it is. So when the energy to understand a system overgrows the energy to write a new system they simply start over while chanting "Re-write" so everyone can here. Getting the clients acceptance by blaming earlier developers and poor design choices is easier than it should be; there is not much choice once the system has reached this state of decay.

The developers then often start over with the whispering game and they are bound to fail again, blaming the earlier incarnation of themselves. Around it goes, draining money from the client that has been tricked into believing that this is just how it must be.

Today a lot of us understand that very much pain and decay was caused by not communicating the model to all involved parties and by not sticking to one common model along the system’s lifetime.

We also know that by setting the model in focus we can automate much of the work that was earlier done by hand. So not only do model driven development solve the basic issue with diverging ideas what the system is about, it also allows you to reach the goal faster and with higher quality.

The bulk of any information system is after all about predictable operations on domain objects, their relations and attributes as defined in the model. It is easy to understand that these operations can be handled by a framework, and thus can be implemented once and for all.

Now; 9 years into the 21 century there are still cavemen walking around, producing rotting systems by trusting the whispering game for core definitions. Be advised; evolution will eventually erase them. The stuff they build today will eventually be gone; it will rot and be replaced. If you pay for work like this you are in for a never ending story of rewrites that will cost you money and stop you from earning money.

The quantum leap developers do, when focusing on the model and applying a model centric framework is a wonderful thing to see. You can expect that one developer can do the work of at least 5 ordinary non model centric developers, but the biggest gain is the precision and stability that this approach gives.

Imagine to see a developer that looks straight into the client’s eyes and says "Oh, you want it like that, now I see, no problem”, and never again here “that was not what you said before, we cannot change now”.

Many developers have finally shifted focus from defending their rotting systems, to implement every tiny detail needed for today’s businesses.

Having all developers seeing the same model and having a framework that can act on the very same model is a refreshing, yet so obvious solution to how we as a species can master information and create the systems to handle it.

Composite and Aggregate and what they imply

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

image

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:

image

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):

image

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:

image

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).

What does ECO and Gaffr do

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

image

The DeleteAction can be set to one of these values:

image 

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 aggregation==none 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.

Thursday, October 8, 2009

The framework argument

Some time ago I wrote a presentation called “the framework argument”. I picked it up today and read thru the power point slides. At the time I wrote it I also made a video in which I talk a bit about each slide: http://www.capableobjects.com/cam/theframeworkargument/camtasia/camtasia.html 

You can download the power point slides here http://www.capableobjects.com/downloads/hkprespptx.pptx

I still stand for everything in there and I am convinced that most people work at the wrong level of abstraction when it comes to software development. Tradition has lead most people into a false belief that every problem is so unique that it requires hi skilled developers to do the same thing over and over again. This is both tedious and error prone. (I intentionally leave out expensive since I think that saving money is the least important effect Model-driven-development (MDD) with ECO, although very real).

Being able to lower the threshold to get going with development and getting results will start a process where you no longer are “afraid to try”. This will change the way you look at development. You will move even further away from “waterfall – big specification” to true agility with no need for prior documents at all.

The quality of the information that you produce when you develop (class models, state machines, view models) will be a live specification. One that runs/executes and produce value for you and everyone that wants to understand what you did.

This is why we registered the domain livespec.net and pointed it to us.

Mixing in the common sense Domain Driven Development (DDD) strategies to actually keep an ubiquitous language between your clients domain  and your developers will not hurt one bit; and you will be considered a domain expert and not only the “IT-guy” faster than you think.

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