Jeremy D. Miller -- The Shade Tree Developer

The first con is a non-argument for me.  I'm not going to limit my effectiveness to the least capable member on my team. It's my job to bring him up to a more effective level.

Lets be honest though, is it really that hard to learn UML? If you can program, you can read UML, its not that hard. Just a thought. :)

In my experience, some strong developers don’t like modeling rather than UML. They see modeling as a waste to time. They would prefer rather to explain design decisions in plain text or verbally. One argument is that hardly any detailed battle plan survives the contact with enemy. Another valid point is that you don’t get anything out of detailed modeling. Visio code generation or synchronization with code changes are poor or none. I think that Visual Studio Team System’s Class Designer is a step in right direction.


http://vikasnetdev.blogspot.com/2006/07/do-some-strong-developers-hate-uml.html

My first query is, are we just talking class diagrams here?

I am currently working on my IT degree after many years in programming and systems design. In that time I have used ERD's/data models and found them very useful - but UML?? My head just can't deal with it. I barely passed the systems design paper which mostly involved UML. But in OO programming and database design I got A+.  So, yes, I think it doesn't work for all.

I suspect that Class diagrams might be very useful but I spent most of my time trying to 'get' Use Class, Activity, Sequence and Communication diagrams.

My mind couldn't deal with the 'grey' areas. I'm a logic person - black and white work for me. I got stuck with quesions like:
Do I diagram this?
Is this too much detail? not enough?
Why is this diagram needed anyway?
Who will look at it? why?
Who *is* the actor anyway in this Use Case digaram?
How come there is different notation for the same thing? How do I standardise?
Plus I was 'fighting'with Visio all the way.

The rest of the class just did it by 'rote' - whatever it takes to pass. I need to know but questions slow up class for others who aren't interested. At times I felt I was going crazy. And I thought systems design was going to be the most 'fun' of all my subjects! Well, I'm not going there again!

People do not like UML because just as Vikas pointed out: they do not like “domain modeling”; and the reason that they do not like “domain modeling” is that “data modeling” is sufficient already; the extra “domain modeling” is waste of time.

Note that UML is now a superset of ER, so, you may say, if we use UML to do the data modeling, then, people will love UML ;-).

I want to point out that excluding “data modeling” from “domain modeling”, or, thinking “domain modeling” is OO only, instead of both database and OO, is the leftover of an old myth that DABs are in charge of database table design.

Nowadays, because programming is so “easy” (because .net or java is so powerful), and also because SQL Server (or Oracle, DB2) is so “easy” also, developers are in charge of both data design and OO design (i.e. programming design). As a result, “domain modeling” includes “data modeling”. Also, data modeling should be done first. Further, in most projects, most OO modeling should be simply copied from the data model; and therefore a separate OO domain modeling per se is totally unnecessary.

For more details, go to:

http://survic.blogspot.com/2006/07/domain-modeling-or-data-modeling.html

I copied the content here to explain why data modeling is the first and often the last (i.e. sufficient):

(a) Users do not care “objects”. They care UI, and the fact that the data on the UI are saved in databases. So, by definition, UI and the key data are the “business language”; objects are not.

(b) The pragmatic inevitability of Anemic Domain Model http://www.martinfowler.com/bliki/AnemicDomainModel.html-- OK, just in case I am not clear enough, I am saying that although sounds terrible, anemic domain model is a good thing. -- Just as others pointed out, OR mapping encourages this. Again, a lot of people believe it is a bad thing (and therefore, OR mapping is a bad thing!), I believe it is a good compromise.

(c) Part of the reason of (b) is that > 80% of the function of an application is “data CRUD”; so, why bother domain model.

(d) Because of all above, domain model can be “skipped” at least for smaller projects; for larger projects, it is certainly a good exercise. However, even in the latter case, the first-cut of the major database tables should be done first; therefore, the key objects should be “copied” from data model. The key reason is, of course, users (see (a)). This is crucial. You may find ways to “bypass” the data modeling phase, and say that you start with a “domain model”. However, if you think of the reason how you get the major objects done, it is always “we need those key data”! OK, the value of being honest to ourselves? – Time saving: > 90% of the domain model can be done within one or two days, after data model is done. And data model is much easier to do, because you can get help from users directly. You may say, how about the rest 10%? – Those are the low-level objects, they are implementation oriented; and we should not talk about them with users anyway.