Technical Debt

Data Modeler Meets Objects

On the Agile Modeling forum, there was a great post by a Data Modeler requesting help on how to interpret an Object Model in terms of Data Modeling concepts.

My reply:

Some DM people "get it" and others remain stymied by the OM world ;-)

Biggest issue is that the relationships in OO can often be "backwards" to many in the DM camp. Conversely, in SQL, you can usually get at any data that you want, regardless of the "direction"... A Client can have Address(es). Or, you can look at an address and probably tell me which clients are at that address.

You should endeavor to think in Objects. And, object models are often in the eye of the beholder. The perspective for a given model needs to be understood. That is, what did the modeler intend to convey?

Cutting to the chase (you get what you pay for here):

• Classes
• Class == Table
• (non-transient) Attribute == Column
• Normally i come up with standards for column width for various strings in the model
• Names are varchar 125
• URLs are varchar 416 (making this up )
• Descriptions are Text
• etc.
• Associations
• typically are whole-part or containment concepts. A Client-------0..* Address.
• if you see a filled-in diamond, think "Cascade Delete"
• other associations are simply relationships
• Association Class
• This is simply an unfinished portion of the model -- or a short cut.
• It means that there is more "information" to be stored than simply the pure association
• For example: Insurance Agent -------- Agency can have an association class like "Registered" that shows the dates when the agent was active (employed) at the Agency.
• You have to eventually implement the Association class as a class/table in between, and connect the classes with the proper cardinality.
• Generalization
• do not bother doing LDM for this (kind of like unary operators should be avoided)
• parent has some attributes, children probably add more
• you have a choice of the following:
• one superset table with parent and child columns. for different child classes, you may have unfilled columns. a porous table so to speak.
• use joins of child tables to parent tables. suffer the cost of a join
• you can determine which is better based on projected usage and run some plans both ways with loaded sample data and representative queries and measure performance to make up your mind which way is best for your specific application
• Implements
• This is for an interface, which is purely behavior (methods)
• You may be able to ignore completely
• Or, if it is being used in an association (like a one class holds a collection of things implementing the interface), then you have to pay attention to it:
• It can serve as a "reference" to many other classes that implement that Interface
• You may have to persist that association and figure out how all the underlying implementing classes/tables can be held in a collection (typically a join table sort of a thing suffices)

Hope this helps!

Daily Meetings

When I was working at a professional engineering services organization (86-95), we would frequently work on writing proposals to bid on government contracts (Tactical Naval Air stuff).

we had a specific room we outfitted with walls covered in cork board, called the War Room. This room served as a way to put up the overall proposal architecture and the individual sections and allow them to grow over time.

each day, we conducted Daily Stand-up Meetings. the intent was to:

1. to *not* allow people to sit comfortably in their seats,
2. to be able to quickly go through the team's status,
3. to see if there was anything holding people up, and
4. to keep the vision at the fore of everybody's mind.

personally, i grew averse to daily meetings of the mundane type at my first job (81-86) at the Naval Air Propulsion Center -- where I did R&D on Cruise Missile jet engines. There was a daily meeting at the test facility wing. I remember being excited to have finally "earned my stripes" to be invited to attend this meeting. After all, important topics were presented regarding the test cell usage, scheduling, resource conflicts, etc. Important people would be there adjudicating amongst the competing projects.

However, after a while, I noticed it was often a hollow routine. Many people would sit in the same seats. Walk in the exact same footsteps (+/-5% error), say the exact same things. More ritual than substance. I stopped going except when I had very specific things to discuss for my team's engine test plans.

So I always vowed to not fall in the trap of having habitual meetings that contained a high percentage of drivel.

To call daily meetings "scrum" is kind of funny now that I know more about rugby :-0 (Thanks to Heinz Kabutz asking his son to comment on the term "scrum" -- dangerous, you can break your neck, you don't want to be in the front row, you need to wear gum guards, because the opposition team will punch you in the face. Ouch!)

Where do your Daily Meetings fall on the scale of mundane to concise (to dangerous)?