"Writing models and then writing the code never works," says Dr Booch. Instead, the code and the model are two ways of looking at the same thing. Models can be used as scaffolding to help programmers "climb" existing code, or to guide the construction of new code. Rather than advocating top-down construction, from model to code, Dr Booch advocates an incremental, iterative process: start with a model, make a working program, and then add features to the program progressively, in small steps, keeping the model updated along the way.
http://www.economist.com/science/tq/PrinterFriendly.cfm?Story_ID=1841081
Product Companies Advocate Tools - Film at 11
'nuff said?
"Writing models and then writing the code never works"
Hi all,
My experience with writing UML models is scarse. Having said this, IMO it all comes down what is the fundamental objective when writing a model (Static Model).
1) Is it to describe how business objects are associated with each other?
2) Is it to describe the detailed object associations necessary to a running program?
On the first approach enough has been said. Is all about shape. Some other posts in this site excellently described this. Does it work? Well yes, but one has to understand what is at stake. I have to confess that I have been strugling a lot lately with DNC (can we post DNC centric modelling questions or observation on this site? If not where?).
On the second, my experience is that it does not. That is, my practice sustains Dr. Booch statement at the level of technical details. There are some things that CPs think of during development that speed considerably the implementation process that falls out of the scope of the Domain Modeller.
"Simple" shape/business driven models can quickly span out all other software driven objects to support it, adding considerable complexity to the inital model. Think of factories, managers, brokers, facades, DAO/DTOs, other frameworks classes (like persistance frameworks), etc.
In conclusion of my thoughts (I may be wrong), IMO the first is a blue print of the business domain being mapped to a software system, the second is a blue print of the software, two different thinks that in the end need to be intertwined with each other - the second around the first. In the end I'll have two different views of the same sofware, a business oriented view, and a software oriented view. I'm not advocating two different models, but two different views of the same model, were the second view is built to support the first (around it).
This makes it easier to spot bugs against business requirements, or change the software due to some changes on the business requirements. But it does not make it easier to spot bugs steamed from unfitted usage of technology (such as memory leaks, dead locks etc).
What is quality software? The answer can be many things, but primarly for me is: A software that in the end does at least what the users expect/want it to do (without business bugs?) + A software without technical bugs - without bugs period. IMO, other definitions for software quality can only be developed around this one.
Best regards
Nuno Lopes
Yes - modeling questions are fine
Sure Nuno,
of course you can ask modeling questions here.
Jeff
Model the Domain, Luke
Hi Nuno,
without meaning to sound like I'm over trivialising the issue, there really is one answer to all of this. And that is to simply model the domain.
Your first question regarding what the model represents: the business domain. Your model should represent the business concepts in the domain you are working, or at least some subset of them that are needed for your particular application. In process 1 of FDD we're primarily concerned with shape here, as you've noted.
I don't believe there is any other view of the system. There is no static model vs. some other runtime or detailed model of the system. There is no other view of the system. In subsequent phases of development we refine the model, adding in more attributes and behaviour as necessary. There are slight tweaks here and there, perhaps some derived associations or implementation details sneak in. But we still have the same model as we started with, just with more detail.
We keep our models alive, always! Long after the system has been built and in production. Throughout development, all design is done around "the" model. For each piece of behaviour we want, we build sequence diagrams. This produces additional methods, and sometimes attributes, to the model. Only then do we get down into the code. But even now we're simply coding up refinements to the model.
So where we end up is with a single model. It is both the picture of the business domain, and describes the running software.
Regarding your argument about bugs etc, I've found the opposite to be true. Memory leaks aren't a problem - use Java ;) Something like deadlocks should be much easier to visualise given a domain model, simply because all the sequence diagrams should be illustrating pieces of behaviour from a business sense. I can't imagine anything more natural than visualising a sequence diagram against a domain model. Particularly using colour archetypes, the access paths and the implicit dynamics of the archetypal domain shape should make this much easier.
I'm guessing this is a different approach to what you've done to date, so I'd be very interested to know what you think.
Regards, Paul.
Model the Domain, Luke
Should we say the, that FDD complies with Dr. Booch vision not otherwise. That is, FDD does not suggest that we need to define/describe all the model in a Static Diagram (Class Diagram) first and only code it after it is done. As far as I understand the DBF/BBF cycle is in compliance with Booch statement (deals with details, both system and business specific). That is, without further explanation on is part about what he ment in its statements.
>So where we end up is with a single model. It is both the picture >of the business domain, and describes the running software.
Yes, I think you explained much better what was going on in my mind. There is only one model, but different picture can be taken from it.
What I was trying to emphasise when I used the term "views" is that quite often I don't show to my customer (domain experts) the system's DAO Classes or Managers (persistance centric classes), or whatever that it is sofware specific (Data Adapters and so on). Why, because most of my clients don't have the time, the inclination neither the tecnical expertise to understand their relevance to the business domain. What do I show to them? The business view of the model according to my precept, the picture of the business domain according to yours.
I think we are refering to the same thing using a different dictionary of words. I must say that I like yours much more, its far more succint then mine.
As for the usefullness of the Domain Model for bug detection (like dead locks) you are are correct for sure! I'm quite a noob when it comes to modeling and FDD.
Nuno Lopes
Persistence objects aren't client-valued
Nuno,
You are spot on with your observations here. We don't show the client the persistence classes or infrastructure either. Yes, plumbing does exist in FDD systems but the original domain model isn't throwaway understanding. Rather it is the core of what gets developed.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Great PR control by Rational
When I read this piece in the Technology Quarterly, I sent it straight to Pete (Coad). In the wider article, you'd think that Grady and Rational invented the simultaneous round-trip engineering and from this quote Steve has picked out, you'd think he invented FDD too.
Borland's CTO was quoted in the same article. Bottom line is Borland's PR people clearly aren't fully up-to-speed on the history of Togethersoft. Some tighter PR control could have put the credit for these ideas where they were due.
However, it's great to hear that Rational (and by implication IBM) have got "religion"
<tung-in-cheek> I wonder if this means Grady will ditch RUP?</tung-in-cheek>
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/