Tuesday, January 12, 2010

Recurring patterns in application II : Streamlined object modeling to the rescue

I'm still on my quest to find basic patterns in most (if not all) software systems [read my first attempt here] when I stumbled upon Streamlined Object Modeling (SOM) by Jill Nicola, Mark Mayfield and Mike Abney. This book really blows my mind as it answers my calling with a bang! This book is really a superbly good reference book, on par with Domain Driven Design (DDD) and even the GOF book and yet it is so unknown (it was written back in 2002 - I just graduated in 2002 - and it took me all these years to find it). This must be the most underappreciated IT book ever!

The style of the book does not make it an easy read. It is full of Principles (98 of them) and a bunch of Rules (which I did not count). Also, the fact that they put the diagrams on either the top or the bottom of a page (instead of in the middle of a paragraph where you really need to see it) really seems too "academicy" to me. I guess the style could work for IEEE papers but not so much on a book.

Otherwise, the patterns shown in the book are really Earth-shattering. It echoes back some of the patterns I've suspected in my earlier post. (Which is nice since it does confirm my observation).

Some of the similarities between what I have observed and SOM patterns:

  • What I call User is called Actor in SOM
  • What I call Context is called Role in SOM
  • What I call Event is called Transaction in SOM
  • What I call Item is also called Item in SOM
  • What I call Item can have links to other Item, SOM qualifies this further by stating the realtionship of type 'Container-Content', 'Group-Member', 'Assembly-Part' and 'OuterPlace-Place'
  • One thing I did not capture in my patterns is the Object inheritance part (not to be confused with class inheritance)
Both my patterns and SOM agrees that Events should be fired when properties are changed.

So, why don't I just take the SOM patterns and be done with it?

Well... (oh here it comes)
One of my objective in identifying patterns is to create, at the very least, a GUI generator that will create interface based on the patterns present(instead of just CRUD). That is not so simple with SOM. For example, a SOM pattern always starts with an Actor having a Role and a bunch of Transactions are associated with the Role. This represents the subject-verb relationship in which Actor-Role represents the Subject and Transaction represents the verb. Of course, you must also have the Object part too. This is represented by Item. So, in a SOM setup, you will usually have :



Now imagine that I create (using your off-the-shelf CRUD generator) an interface for this setup, I will have a Role page, in it I have things that have happened (Transactions) and only when clicking on things that have happened that I will have a bunch of objects that I can browse. Which is a bit counter intuitive) There is no concept of direct Item ownership by a Role (or an Actor) in SOM.

Now to mediate this, I can just look at Transaction as a 'wrapper' for Item. From Role I would regard transaction as a see through object and can pierce through it like a glass to see its Items directly. But, would my typical CRUD generator support this piercing? (It does look somewhat like a master-detail setup).

Another problem with CRUD generators is that CRUD generators typically follow DDD, in which you would have DAO (or Services + Repositories in DDD parlance) and GUI codes are created for you in function of your domain model. In DDD, verbs are represented by Services and they are on a separate layer from the domain model. In SOM on the other hand, verbs are modeled as objects integrated with other objects in the domain model. To use CRUD generators with SOM would require a marriage (as if we don't have enough of that already during the last school holidays :) ) between SOM and DDD. Hmmm... how would you do that? For example, in DDD, to create an Item, you would request the repository (which is totally disassociated from your object model) to create it for you. In SOM, a Role, through a Transaction (both of which are intricately part of the domain model) might create it.


Hmm... I will investigate and update this blog again. Stay tune

3 comments:

Unknown said...

good post

Raja Iskandar Shah said...

adding from a business and analytics point of view:
actor = entities
roles = processes / rules
transactions = transactions
items = items / elements

Anak Perelih said...

reminds me on UML/RUP