Domain model of retail business line

Here is my next business line model. The business is retail. The amount of variation between individual retail businesses is quite huge. This is why the current model is perhaps somewhat more abstract than some others.

In retail the key to the business is the material flow. When we consider contemporary retail like Amazon.com the modern trend is close to JOT ( Just On Time ) production. The point is to avoid any unnecessary storing of component. The implication of this is of course highly organized supply flow. Emphasis on the delivery mechanism is a must. In production it is actually more critical than in retail in average.

This demand is reflected in the domain model as well. The deepest essential event flow gos like this:

  1. Provide the customers a comprehensive catalog of product descriptions.
  2. Then the customer can order based on this catalog. When the order is received it is immediately replicated to the provider of the product.
  3. In the worst case this will trigger a request to production. Then the customer is kept updated of the process.
  4. In many cases and at least in more classical scenario the retail company is keeping and managing a stock of goods and maintaining order limits and quantities.

My model here includes all above aspects. The event-object purchase can thus be either and event between producer and the retail company or between the retailer and end customer.

I have of course also included the work-events and the worker role in the model as well.

Here is the object collaboration of a classical even chain, where the product is first ordered, received and placed on a shelf in the stock (or in the shop) and finally purchased by a customer.

Advertisements

Confusions in the concepts of model execution and code generation.

There is quite a lot of  fuzziness and confusion in the general discussion around the concepts of model execution and code generation.

I try to straighten up these concepts and their relationships.

1)      Isomorphic mappings
First every programming language (with a working compiler) is a isomorphic mapping between syntactically correct piece of code and the corresponding compilation ( executable code). This means that for every compiler a reverse complier can be written and that compiler will produce a corresponding source code from an executable piece of code.

2)      Current (deterministic) computers cannot execute any kind fuzzy code.  This implies that the executing code has to be always at the lowest granularity and the whole execution flow is completely deterministic.

3)      Models by definition are abstractions. They drop detail to gain clarity in more important aspects of things. This way the initial models to serve their purpose must exclude details that the applications using the model finally must have. This implies that there cannot be any meaningful execution of a model as such.

I think that it is important to separate domain (business) model from the whole application. Of course it is technically possible to model the whole application in one model, but the increase of complexity is enormous. I don’t think that one needs any “application model” because applications are always very simple thing and they should be designed not modeled.

All this implies that model execution cannot be anything very productive. An totally other question is “graphical programming language”. This has been tried several times in the past and with very poor results. Here the amount of detail is in the key role again. It seems evident that we are able to handle very small amount of information in graphical form. The breakeven point is actually very low and after that the situation very quickly gets really bad. One very clear and also good attempt in this direction was IBM’s Visual Works for Java. It focused in graphical GUI programming. In demos it looked fabulous but everyone that really tried to do something real with it was quickly convinced that it will never work. Even a modest window with some functionality became a total mess.

This means that graphical presentations (at least for me) are vitally important thing. Class diagram in UML is quite sufficient. Collaboration diagrams theoretically are also good, but the current tools with these are very poor indeed. There should be powerful tools to produce collaboration diagrams and they should include a default option to present them as animations. Some time Rose had that but sadly that time passed long time ago.

Then the true key question is how to make the transition from graphics to textual programming sooth or almost invisible.

To concretizes all this let’s go through an example. Let’s start with a small model. Here is an abstract core model for a web- book store.

Here we have four classes: Person, Book, Walk and Purchase.  Objects in Person-class are the only entity type objects. Walk and Purchase classes are event type and Book classes is description type. Walk event is actually the person’s visit in the shop and the name of the class could also be visit. The association between walk and book represents the book that the walking person has picked up and as purchase candidates. When the walk ends it will create purchase event and transfers those books that the person finally is buying.  Here is the corresponding collaboration diagram:

The simple generation from class diagram includes following:

@Entity
public class Person {
private String name;
private Date birthday;
private String creaditCard;
private List walks = new ArrayList();
private Long id;

@Column
public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

and

@OneToMany
public List getWalks() {
return walks;
}

public boolean addWalk(Walk walk) {
if (!this.walks.contains(walk)) {
this.walks.add(walk);
if (walk.getPerson() != this) {
walk.setPerson(this);
}
return true;
}
return false;
}
public boolean removeWalk(Walk walk) {
if (this.walks.remove(walk)) {
walk.setPerson(null);
return true;
}
return false;
}
public Walk createWalk() {
Walk walk = new Walk();
addWalk(walk);
return walk;
}

In a similar way the code for the Walk class can be generated. There for instance can be generated the pickUp() method as follows:

public boolean pickUp(Book book) { }

This signature can be generated but there is now way to conclude the method behavior even if for a human through the semantics of the method name this think could be quite evident:

public boolean pickUp(Book book) {

this.myHand.add(book);

book.pickedUp();

return true;

}

Finally there is now way to generate anything for the application. The application has to have at least one GUI window that enables management of persons and books and pane for a walk and purchases. To get a decent result the GUI and its functionality must be design and implemented by humans.

Paradigms and Object Paradigm in particularly with quote from Grady Booch

The concept of paradigm is a tricky one. To characterize this in some way we can describe paradigm as a outmost explanatory framework or mechanism of modeling a complex thing. (see: http://en.wikipedia.org/wiki/Paradigm).

A paradigm offers building blocks to create a model of complex part of reality. These building block are in a sense fundamental to all models ( you could call them explanations as well) that are base on that paradigm.

The paradigms for same aspect are mutually exclusive. Let’s take a concrete example. If you want to create a 3-dimensional model of houses, you can us as you building material for example: Lego bricks, matchboxes or carbon. With each of these materials you can achieve good results but the working techniques differ and of course there are differences in the end results too. Now these three materials – the building blocks – represents here the paradigms. The first (and I consider this most important) result of this consideration is that is impossible to mix paradigms. Either you work with Legos or matchboxes but there no way of mixing these materials. This is universally true with different paradigms explaining the same aspect of the same part of reality.

The article in Wiki also mentions both paradigm shift and paradigm paralysis. It seems that the used paradigms are changed from time to time to more accurate or explaining ones. For instance people hade from the days of antique Greece a very commonly adopted paradigm of solar system. People believed that it is geocentric.  When time passed and people learned more about the universe they realized that their understanding of Solar system was wrong and they had to do a paradigm shift to heliocentric. This shift proved to be a difficult one at least for part of people (at least around Catholic Church). This ended in a paradigm paralysis. The reasons behind this were various and so were the explanations and excuses.

Now let’s consider the object paradigm. The paradigm shift happened from procedural paradigm. The key difference between the paradigms here is in how they describe model’s behavior. The older paradigm has a simple way of slicing the behavior in time and end up with time flow of events as the object paradigm describes the behavior as collaboration of named objects and their separated responsibilities. These ways of describing behavior are mutually exclusive. If you explain the behavior as flow of events there is no point in doing that all over again with collaborative object and their distribution of work. If this would be done one of the models would be completely redundant and unnecessary or even confusing!

I think that most of business application development today are done with OO-languages and most of the design is done in procedural way. My question is how far we are in the paradigm shift and how bad is the paradigm paralysis with procedural approach? The fact is that application development with object paradigm is from 2 to 10 time as effective as with the previous one! In the next post I will elaborate on this and start it with a quote – part of epilogue from Grady  Booch’s Object Solutions book.

  • Software development is difficult
  • Object-oriented technology helps

Is object-oriented technology mature enough upon which to build indus­trial-strength systems? Absolutely. Does this technology scale? Indeed. Is it the sole technology worth considering? No way. Is there some better technology we should be using in the future? Possibly, but I am clueless as to what that might be.

It is dangerous to make predictions, especially in a discipline that changes so rapidly, but one thing I can say with confidence is that I have seen the future, and it is object-oriented.

This was written around 1995. At that time the OO boom was at it’s heights and we all though that transition from procedural would be graduate, smooth and strait forward. It proved to be more difficult and there were a lot of forces against it. There were (some still are) the mighty stakeholder of procedural legacy.  The new concept proved to bee more difficult for many people than we thought.  Anyhow everything here hold today! of course we have learned something in 15 years and we can do things more efficiently today but the bases is here, solid and holds! The software that I am working with can and should all be implemented with OO.

Airline business (Business area models:)

Business area models:  Airline business

Here is now my second business area abstract domain model. My second target is Route Airline business. I have been working in Finnair about ten years, so I know the business and the model by myself very well.

The target scope have been narrowed a bit from general airline. This model concentrates on a typical flag carrier base operation: route flights. All these transportation core models contains a pattern; a pair of route design and implementation aspects:  Route, RouteFlight classes for design and Flight for real event.

The largest business cycle – or pulse- is a period or a season like spring, summer, autumn.   These periods are planned and coordinated as one unit. So my example is Finnair and its route can be for example Helsinki – London. When this is decided then the airline has to decide the weekly operating days and the plain type out of the fleet. When this is done then the airline have to negotiate the gate time slots. When this is done the plan for a periods route operation is ready.

The models class RouteFlight is on description object of a single repeating flight. The real flight event can then be generated for a given period from these objects.

The basic collaboration are very straight forward. Here is one of those: buying a ticket and reserving a seat:

These diagrams can be found in StartUML form at:  http://personal.inet.fi/cool/jukkatamminen/OOstaf/Airline/ RouteFlightCompany.uml

Just upload and open with StarUML.

Dynamics of object creation

A fundamental starting point is that all the classes in a domain model are connected. This means that there is always an association path from one class to another.  In most cases the creating objects are directly associated with the new object. On the other hand domain layer objects don’t have any reference outside the domain. All domain objects must be created by a domain object even if the stimulus to do so comes almost always from outside (from application layer).

When an application usage starts, some entity object exists. So creation of these objects is out of the scope of the application. Of course technically every object of an application must be created, but this is not the issue. So a set of objects exists and are in a way given to the application. In most cases for example the home organization, its roles and persons exists.

Now when we start to analyze object creation, the first fundamental base finding, that by the way is easily passed by beginners, is that an object cannot ever create itself. The next issue is can an object from the same class create an object from the same class. This is true from some classes and not true for others. For instance object in Persons class can create a new person. Now actually this needs two objects from person class and 9 months – but serves as an example anyway. An example of entity class that cannot create an object from same class is the class House.

When we take into account the Coad’s color categories then we can be more precise. My first examples were bots entity-type classes. So we can say in general that some entity class object can create object from the same class.

Role-type classes are actually objectified associations. There is even no theoretical aspect why a role object should create similar objects. The same applies to Description-type as well as to Event –type.

Typical creation patterns

Let look at different dependencies and situations at object creation. Let’s go through Coad’s categories what are the creation patterns and their justification. The bottom line here is to set the behavior into an object that “knows” most or best what to do. This seldom corresponds strictly reality instead some level of abstraction (read imagination) is needed.

Creating Entity-class objects

As I already mention some entities can create similar entities. Here are some typical patterns to create entity objects. One example of these abstract ways is the first very common entity creation pattern.

Creating entities from descriptions

Here the idea is that we have a description object, that describes an entity. The responsibility of creation is put in this description. Let’s take a couple of examples: The drawings (the design) of a house will create (read build) the house. A recipe will create (read cook) a meal and so on. In reality this description in most cases is unable to do this, but the abstract way of thinking this is that the description is the actual performer but it uses something of someone in reality as an instrument to do so. In the case of a meal the instrument is the cook.

Creating entities  from events

Similar to description are event. The production of entities from can also be modeled with and event object. In these cases the responsibility of entity creation is typically but into the event. For instance a cook event can also be considered to be responsible of creating a meal. This is an alternative solution instead of the previous one.  The need to have the event in the model instead of just a method is the need to know something about this event itself. Simple example of cook event could be the duration.

Creating Description-class objects

This is very similar to entity case. The domain stories often starts from a description, so they are not actually created within the domain but rather outside. Of course the application layer have to have a functionality to crate object that are starting points of the domain behavior. This is however another story.

Creating Role-class objects

In most cases a entity object will create a role for another entity. This creation of a role enables this entity to participate in some activity. For example a role of developer have to be created for a person by the organization entity before it can be associated for instance I a project task.

Creating Event-class objects

This is perhaps most flexible category. Entities, role are typical creators of events, but event can be created by other events and descriptions as well.

Genuine object model: Health care

Here is now my first business area abstract domain model. The target business area is generally health care. I have chosen the scope so that it will cover everything from doctor’s practice and from diagnosing through all kind of treatment, medication and other. It also includes all kind of laboratory tests and x-ray research (and similar). So to model covers the quite widely all kinds of deceases and injure treatment. This model is quite abstract (OOA) model and it will lack most of the attributes required for implementation and application around this core. On the other hand the semantics in defining and naming concepts (classes) is enough rich and if proceeded to application design and implementation the additional classes needed for the domain layer are few. The class model contains around 20 classes and almost 40 associations and one inheritance.  Here is he class diagram:


I am not completely satisfied with the current model but I would require a set of health case professional to finalize it. The things that are somewhat vague is the triangle of three events: Status, Disease and Treatment.  Another thing to keep in mind is that English is a foreign language for me and as I am not a health care professional so I don’t know how good my “translations” of concepts are.

The only collaboration that I include here is a story of two phase treatment of a sore throat.

This collaboration is lined up by three visits: 1. to doctor’s reception, 2. to laboratory 3. a phone call from the doctor to patient. The details of the story should be readable from above diagram (at latest from the animation).

Here is the StarUML-file

http://personal.inet.fi/cool/jukkatamminen/OOstaf/GeneralPractice.uml

the same in MS-Word

http://personal.inet.fi/cool/jukkatamminen/OOstaf/Domain model for medical general practice.doc

and PowerPoint animation of collaboration diagram

http://personal.inet.fi/cool/jukkatamminen/OOstaf/aginaAnimation.ppt

All suggestion, questions and comment are appreciated.

An implementation of the domain layer is very straight forward from here.

OO domain models for several industries

I am about to start to publish OO domain models of some industries. The first model that publish is within healthcare and could be named as Heal Centre. The model will cover a group of doctors have reception. The model dynamic starts from a patient need for a doctor’s reception and it end at diagnosis, a treatment plan and possible recopies for medical treatment.

When I publish this kind of model, then it will contain the following parts:

  1. class diagram of the domain
  2. one to some collaboration diagrams describing the most essential business logic.
  3. PowerPoint animation presentation for each collaboration diagram to easy the reading of those.
  4. The abstraction level of this model is high and for instance the attributes in the classes is only a small portion of the required when implementing of any application that uses this domain.
  5. During a possible implementation the abstract analysis model should incrementally expanded to include all the necessary attributes. In most cases very few new classes are needed in this phase.

In this post I am not yet publishing the Heat Care (or any other real) model. Here I only give the form of the publication and the reasoning behind it.

I will publish here a very small toy (or tutorial) model called a BookShop to give you an example of everything that I described above.

The business that we look at here is a small bookshop in a centre of a city. The following is deliberately highly abstract model to emphasize the difference between the reality and the model. In the shop the books on the selves actually represent a publication than a copy. So our models don’t have these copies as objects in the model at all.

This way one can think that the copies represent a catalog. This way it is rather easy to sift from a real shop to internet shop. The model has first event called walk. This is the even where a person enters the shop and stars to walk around. During the walk the person pick up interesting book. This set of books are the candidates for purchase.

I use Peter Coad’s color coding. This will make it a lot easier to read. The colors are: Entity-classes green; Role-classes yellow; Description-classes blue and Event-classes pink.

Here is a collaboration diagram on what I described above.

If you have a need for a model on a specific domain then send me a proposal and let’s see can I do it for you.

http://personal.inet.fi/cool/jukkatamminen/OOstaf/webKauppAnim.ppt

http://personal.inet.fi/cool/jukkatamminen/OOstaf/BookShopUML.uml