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

Avoiding costly rework

There have been some discussions around data modeling and the more costly impacts of database changes.

Doing the right amount of up front work precludes doing the costliest of

refactoring.

Doing enough quality modeling of the domain up front usually makes it

easier to accept change — and to find where the change “goes.”

Making a clear distinction between roles of the different software

artifacts (ui classes, business layer services, domain classes,

persistence management layer, DAOs, etc.) and how they play

architecturally in the implementation, also helps to make it easy to

figure out the impact of a change and where to make the changes.

however, if you have crap for architecture and widely-varying approaches

in different parts of the app, and all sorts of logic spread into the

database (like stored procedures doing business functions that could be

done in objects), then you have crap.

data folks being a “bit defensive” to me says i have to pay more

attention to what i do upfront. if it is costly to do certain parts of

development, then i will adjust my techniques to account for that. i

will have the team work a bit harder, possibly, to ensure that we don’t

thrash the expensive parts of our construction costs.

DAMA

Scott Ambler shared this link

agile schmagile…

The first slug of slides (which i have not gotten past yet) pointing out realities of some development efforts being lousy has nothing to do with agile and everything to do with people doing a lousy job at software development. News flash: anyone can screw up doing a project or misinterpret principles of development. Is that somehow the fault of the Agile Manifesto? I propose to consider it be the responsibility of the people involved…

If I get the stamina to respond I will, but here is just one stupid example:

“Who

Miami JUG May 9th

If you happen to be in the area, we’ll have a nice opportunity for a roundtable discussion!

Topics and Speakers:

  • Agile Project Management Techniques by Jon Kern. We will discuss how to consider a simplified agile technique for managing a project, and how to blend it with classic “MS Project” style of management by Gantt chart.

Speakers Bio:

Jon is passionate about helping clients succeed in delivering business value through software development efforts. His varied career has spanned jet engine R&D through centrifuge-based flight simulators, to being an object-oriented evangelist through the 90s and his work with the Agile Manifesto for Software Development in 2001. Many credit him with much of the success that TogetherSoft enjoyed during his tenure with the UML modeling/ development product and the professional mentor group he founded.

Jon works with teams to solve challenging development projects for the stakeholders. From analyzing the approach, to helping provide solutions, to mentoring teams — and all points in between — Jon routinely has significant impact on the projects he works on. Often with a team of experts from his friends at immuexa.com, the small teams of 3-6+ people supply a quick-hit ability to solve problems and deliver results. Projects routinely see high quality solutions in half the time, and typically leave the local team in place, mentored on OO and agile, and excited.

second first iteration

we had our second iteration kickoff today.

the first iteration was a bit premature — but i knew that. there were still issues with the team’s preparation:

  • getting their systems setup
  • understanding the best project structure
  • reconfiguring SVN
  • figuring out some of the flex UI issues
  • determining how to do CFUnit properly
  • etc.

The team was also new to

  • working collaboratively across multiple time zones,
  • doing an agile project,
  • doing a feature-driven approach,
  • having to estimate features,
  • doing domain modeling
  • considering a technical architecture
  • using tools like the confluence wiki, jira issue tracking, and IRC

Nonetheless, nothing like a deadline and an exercise to help bring things to the foreground!

We allotted only 25% of their available time to be allocated as ideal engineering hours for the task estimates. About half of the iteration or more was taken up by issues with infrastructure, set up, etc. Surprise, surprise, we got 17 of 31 issues completed. about 50% — which stands to reason.

there are a couple of lingering technical issues as we start this iteration. we rolled over the unfinished issues for iteration 1, added a new round of follow-on issues, and went through an estimating and assigning session.

progress is being made on many fronts. now to see some features roll off the assembly line in a bit more predictable fashion for this milestone!

A layered approach with ColdFusion

currently working on a new project that is anchored in ColdFusion (CF). nonetheless, IMHO, the approach still should revolve around:

  • User Interface
  • Problem Domain
  • Data Management
  • Ext. System Integration

we have worked up some initial domain models as we built up the feature list. in the land of CF, we are able to build Value Objects to represent our domain. For persistence, we can use simple DAOs for CRUD, and Data Gateways for more complex SQL machinations.

from the services end of things, we’ll surface the business functionality as delegates/business facades to be invoked over the wire by the Flex clients.

just getting into it… but i’ll keep you posted on how well things get on with this approach.

sum of the parts

working with a new development team on a business app to be surfaced through a portal. taking them through an agile project approach. spent the past few weeks doing:

  • domain modeling
  • feature list elicitation
  • looking at the technical architecture (the “how”)
  • UI sketches

We then did a first pass at estimating the features… An estimate of how long it would take to build the feature — including everything from persistence to surfacing it on the UI and all parts in between.

“But do we need to estimate building the UIs too?”

That’s a good question. I explained that there were lots of features that contribute to a given UI screen… Therefore, there were lots of “pieces” of estimates from each of those features to be built. These piece-wise estimates of the UI will ultimately contribute to enough hours for the overall UI screen. I think of it as a bottom-up approach to getting a reasonable estimate going.

You can also look at a UI design and estimate it top-down. Check the two against each other if you like…

Not to say that we won’t also have some specific UI work. Just that we do not need to count the full cost of building the feature *and* the full cost of building the UI.

How do you estimate?

lines of code

i was consulting at a client a couple months back. the president of the company was concerned that his staff was not as productive as it used to be.

about a year or two prior, the owner and the president decided they wanted more software to be produced. they decided to add offices overseas and double (at least) the staff.

shockingly… two years later, they are 3 years behind on delivering a new version of their flagship product. on top of that, there is little known about just what they have in the way of valuable assets in the project source code.

now the president is looking to measure lines of code and to see what the difference is between team “A” versus team “B” to try and maximize developer productivity.

i tried to make a few forays into explaining there is more to development productivity than LOC. but i didn’t have much luck. maybe i’ll check back in a year and see how they are faring.

any silliness like that where you work? or, better, any successful ways folks are measuring developer output (#feature points increasing over time, etc.)?