>> It sounds that agile model driven development puts more control in the >> developer and takes less control from the modeler. Is this accurate?
It is accurate. Developers' understandings on UML are different. Need a senior guy, eg Modeler, to control on the modeling aspect. Experiences told us that developers tend not to understand other's design, which result in chaos.
Originally posted by Andy HK Ng: Developers' understandings on UML are different.
IMO, developers need to have the same understanding as modelers(if there are)... If not, there can be misunderstanding and the resulting output will be different from the original target, which is really undiserable...
Need a senior guy, eg Modeler, to control on the modeling aspect. Experiences told us that developers tend not to understand other's design, which result in chaos.
Right, there should be some kinda senior developers who are taking care of junior developers in understanding the given UMLs...
Or r u guys referring to senior developers as modelers?
I don't know that I'd really say that one person has more responsibility than another. If the modeler or the developer fails in their task, the application fails, it's just that simple. Even a wonderfully designed system won't work if the implementation is poor and a poorly designed system won't work well even if the implementation is wonderful.
UML is all about communication. The whole purpose of it is to create a way that different people can communicate ideas about software systems. In the case that your modeler and your developer are different people, the ability to understand UML really comes through to the fore-front. The modeler certainly needs to understand UML well but, if the developer doesn't understand it well, there will be misconceptions and errors.
The communication described above is the key. If a modeler completes a model and hands it over to a developer with no other communication, the model has to say everything. It has to be much more complete and detailed with more of the tricky little UML decorations. If the modeler and developer doodle the diagrams together on a whiteboard they can communicate verbally about much of that stuff and leave it out of the model. If a developer models for himself on the back of an envelope he can leave out even more and just capture enough of the idea to start coding.
How does that fit with your concept of control?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I think agile development blurs the line between a modeler and a developer, and at the same note, modelling phase and development phase. It recommends that they be done kind of in parallel - do the model for a piece and implement it right away; do the model for the next piece, implement, and refactor; and so on.
Going by this, the control would still be the same, but the modeller and the developer might be pair programmers. That way, the modeller can do modelling, the developer can do developing, but they do it together, thereby removing communication issues.
Originally posted by Sathya Srinivasan: Going by this, the control would still be the same, but the modeller and the developer might be pair programmers. That way, the modeller can do modelling, the developer can do developing, but they do it together, thereby removing communication issues.
Except that in Pair Programming, the pair is a pair of equals and both do the same activities (one at a time, taking turns, but still). Of course this does not mean that a modeler and developer couldn't collaborate as you describe. It just isn't Pair Programming per se but simply "pairing" or "collaborating".
Joined: Aug 26, 2003
So how important is it for the modeler to really understand the language? For example, if a person had been a developer/modeler in VB and then went to model (exclusively) in a Java environment. Would he normally have problems? How about similar languages say C++ to Java?
Joined: Jan 23, 2002
Originally posted by Stefan Bell: So how important is it for the modeler to really understand the language? For example, if a person had been a developer/modeler in VB and then went to model (exclusively) in a Java environment. Would he normally have problems? How about similar languages say C++ to Java?
I guess it depends on the skills of the modeler. If the modeler did good OO designs, it shouldn't be a problem to implement those designs in Java instead of C++. Then again, I guess VB "designs" are far from object-oriented so there might be a big gap between modeling VB applications and modeling C++/Java/.NET applications...
In Agile Modeling (AM) I do in fact try to blur the lines between modeler and programmer, and better yet between business stakeholder and developer for that matter.
One of the practices of AM ( http://www.agilemodeling.com/practices.htm )is to model with others, the AM equivalent of pair programming. You work together as a team, not as seniors and juniors. Yes, person A might be better at sequence diagrams than person B, but B might be better at data modeling than A and person C might be better at use cases than either A or B. So who is senior? Who is junior? I don't know and more importantly I don't care. What I do know is that if all three people were to work together on a project, if they were to follow the practices of AM, then all three would improve their development skills because they'd learn from each other.
Finally, Agile Modelling is about Team Building, working together with better understanding of each other's strengths and weaknesses . Agile modelling is about continous learning with total attachment to the team . Agile modelling is not about creating silos os specialists .