The real world development cycle is:
(lying, trial-and-error, brute force, and violence)
Seriously, code is obviously a model of the system. Each set of UML
diagrams of a given type is also a model of the system. As Yourdon
types might say, the models exist in different spaces.
The Holy Grail for us as analysts and designers is a model, or elegant
set of models, that translates domain knowledge into machine language.
We don't know how difficult this translation is, but I do get a sense of
convergence in progress. This is far off enough, though, so that the
discussion is out-of-place in a practical list like this one.
As a matter of best practices, code is unlikely to be the best model for
the repository of A&D, because it was not designed for that. Code is
designed to impose a language representation of data and operations that
translates into machine language. The goals of the design are not
understandable in terms of code, and relatively simple code is a deep
mystery unless you are given a description of the design that shaped
it. The code structures are practically impossible to translate back
into a design, much less a set of requirements. Meaningful names for
classes, attributes, and operations may give the code some appearance of
comprehending the design, but even that is deceptive, because the
meanings themselves are not useful to the machine -- for instance, they
can't be used by the machine (or by any of the models that we currently
make) to create novel operations in the problem domain.
Finally, the practical result of letting the code drive the design is
that the architecture tends to degenerate into a heap of patches. This
is entropy for systems.
-Eric
Don Bate wrote:
>
> I've tried in the past with some of Rational's earlier products and
> while the keeping the Design and Code in synch is an attractive goal;
> it doesn't work out in practice on other than small projects. Almost
> by definition, on a moderately sized project, there are going to be
> problems in synching and it occurs as soon as the
> architects/designers and the programmers are different people with
> different priorities and schedules.
>
> You also hit upon a pet peeve of mine by stating:
>
> (requirements, analysis, design, and coding)
>
> I believe that it should be
>
> (problem analysis, architecture, requirements, design, and
> coding) with lots of cycles in between.
>
> Regards,
> Don Bate
>
> At 11:34 AM -0500 4/6/01, Glover, Roger H. wrote:
> >The problem here is that there is *great value* in separating Design from
> >Code. A team project runs several unnecessary risks in a
> >"Code-is-Design-is-Code" scheme:
> > o Accountability: How can you assess whether the Code is true to the
> > Design when you are in a situation where changes in the code *change*
> > the design? If you add a new method or instance variable to a class,
> >how
> > is one to know that that change deviates from the design if the code
> >was
> > the only place that stored that design knowledge?
> > o Messy Code: Useful design elements that do not need to be expressed
> > directly in code in the context in which they appear in diagrams
> >(such as
> > traits of non-navigable association ends) could lead to confusion.
> > Either the developer has to put up with confusing documentation
> >within
> > his code, or he deletes it and that information is lost to the design
> > model.
> > o Inflexibility: Often the design model needs to be updated during the
> > construction process, due to changing or late-arriving requirements.
> >In
> > this case, the designer and the developer both need to work on the
> >"code-
> > design-is-code" at the same time. Someone is going to have to give
> >up
> > access to the code during this time and I doubt it will be the
> >developer.
> > Thus the designer will have to find some other way to work. You say,
> > "design and code are never out of step." I say, "there are lots of
> >cases
> > in which it is necessary and proper for the design and code to be out
> >of
> > step."
> >
> >Even if you keep your code under sophisticated source management (ClearCase,
> >Source Integrity, etc.(Don't even think of mentioning VSS)):
> > o so that you can trace the code back to the Design after Coding begins
> >in
> > earnest
> > o so that you can reclaim any lost comments that the developer deleted
> > o so that you can start a divergent source path so that Code and Design
> >can
> > progress in parallel.
> >Now all that you have done is *recreated* code/design separation the hard
> >way. You have to keep track of which version denotes the cutover from code
> >to design, and any other versions that represent a design change not yet
> >reflected in code. You have a high likelihood of code divergence *before*
> >release (Normally it does not happen until bugfix versions after release).
> >"In short," says George, "you have a gastly mess."
> >
> >If you are doing it all yourself (requirements, analysis, design, and
> >coding) and you have good source management, and you have a *great* memory
> >for details, then I suppose that you could juggle "code-is-design-is-code"
> >well enough. On the other hand, as a mere mortal who works most often as an
> >architect in a team environment, I must say that I much prefer to have
> >separate design and development tools that freely communicate with each
> >other.
> >
> >-- Roger Glover
> >
> >
> >-----Original Message-----
> >From: Shields James [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, April 06, 2001 3:06 AM
> >To: 'Lars Hauschultz'; [EMAIL PROTECTED]
> >Subject: RE: (ROSE) RE: Code is not design!
> >
> >
> >
> >Lars
> >
> >I can see that you may think that it is Ready - Fire - Aim.
> >But it actually more like: Ready - Aim - Fire - Ready - Aim - Fire - Ready -
> >Aim - Fire - Ready - Aim - Fire ...
> >The users on see the last, i.e. the deployed, Fire.
> >
> >I'm not saying DON'T do Design.
> >Design is important because it is more abstract than Code.
> >And you still have to do Architecture (higher level Design).
> >
> >What I AM saying is that the main repository for the Design should be the
> >Code.
> >(The other elements of the repository include Diagrams, (JavaDoc) Comments
> >in the Code.)
> >
> >Design is just a higher level View of this repository.
> >By having the Code as the repository means the Design and Code are never out
> >of step.
> >
> >Honestly, speak to the guys at TogetherSoft.
> >Get a demo on your own Code; get a demo on creating a 'Design', then
> >fleshing it out with implementation, i.e. 'Code' (it's actually one and the
> >same thing).
> >
> >Hope I have expressed myself clearly.
> >
> >James
> >
> >-----Original Message-----
> >From: Lars Hauschultz [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, April 06, 2001 9:46 AM
> >To: [EMAIL PROTECTED]
> >Subject: RE: (ROSE) RE: Code is not design!
> >
> >
> >
> >Hi James,
> >
> >somewhere I read that RUP is following the strategy "Ready - Aim - Fire" and
> >that XP is "Ready - Fire - Aim". Your approach seems to resemble the latter.
> >At least you risc ending up with code, which the programmers like, but does
> >not do the job it was intended for.
> >
> >Lars
> >
> >-----Original Message-----
> >From: Shields James [mailto:[EMAIL PROTECTED]]
> >Sent: 6. april 2001 09:29
> >To: 'Aker, Eric'; 'Patrick Adewunmi'; 'Michael Hill'; Moin Ahmad
> >Cc: [EMAIL PROTECTED]
> >Subject: (ROSE) RE: Code is not design!
> >
> >
> >
> >Eric
> >
> >One of the *good* things about Together is that the Code IS the Design.
> >As you move from Design to Code, all you are doing is fleshing out Design
> >with implementation details.
> >The Diagrams are updated automatically as the Code changes; as the Diagrams
> >change content (not presentation) the Code changes.
> >
> >You do not need worry so much about reviews that make sure the Code has
> >followed the Design, because they are the same thing.
> >Sure, if the Code changes in maintenance it may change what you INTENDED
> >when you had your Design Hat on.
> >But you use the tool to View these changes the Code made to the Design.
> >You are then in a position to judge whether or not the Code is correct or
> >not.
> >If it is not correct, you point out the differences and ask the Programmers
> >to make the necessary changes.
> >You would probably TELL them to make the changes because you, as a Designer,
> >are superior. ;)
> >
> >Another point is that a lot of your Design documentation is captured in the
> >Code (in JavaDoc).
> >This is probably the best way of ensuring that the Design documentation is
> >kept up to date.
> >
> >But, hey, don't take my word for it. Speak to the guys at TogetherSoft.
> >
> >James
> >
> >PS Have you told your bosses that you hours moving little boxes and lines
> >around to make them look pretty? I'm sure that will please them. ;)
> >
> >PPS Please don't take offence at any of my sarcasm.
> >
> >-----Original Message-----
> >From: Aker, Eric [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, April 05, 2001 7:13 PM
> >To: Shields James; 'Patrick Adewunmi'; 'Michael Hill'; Moin Ahmad
> >Cc: [EMAIL PROTECTED]
> >Subject: Code is not design!
> >
> >
> >Let me see if I understand correctly.
> >
> >I spend a few weeks creating a design and documenting my intentions
> >as a designer. I get some code from that design. Then someone makes
> >some changes to that code. My design, my BEUTIFUL design, where I have
> >documented what I intend the system to do, is changed? I would be very
> >upset.
> >
> >So, some new guy on the project makes a change to the code and all of my
> >class diagrams that I have spent time laying out, making pretty for
> >a design review, are changed? This does not sound like a good idea to me.
> >
> >No, not good! As the DESIGNER, I am superior. I do not want coders making
> >changes to my lovely design. Sounds like a stupid idea to make the code
> >equal to the design.
> >
> >After the coders have done their work it would be most interesting to
> >verify if they followed my design. Reverse engineer it, then run it through
> >the model integrator to get a report on the differences. That would be good,
> >then I could have a model as designed and as built. My father is a carpenter
> >and he builds houses. When he makes changes to the blueprints he notes that
> >and when the house is finished a fresh set of drawings is made "as built".
> >The architect then signs off on the "as built" indicating that nothing
> >illegal was done.
> >
> >Eric
> >
> >
> >-----Original Message-----
> >From: Shields James [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, April 05, 2001 12:27 AM
> >To: 'Patrick Adewunmi'; 'Michael Hill'; Moin Ahmad
> >Cc: [EMAIL PROTECTED]
> >Subject:
> >
> >
> >
> >I'm not trying to be subversive here, but are you all aware that Together
> >keeps code in step with all UML diagrams?
> >
> >www.togethersoft.com
> >
> >James
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >> Sent: Wednesday, April 04, 2001 7:30 PM
> >> To: 'Michael Hill'; Moin Ahmad
> >> Cc: [EMAIL PROTECTED]
> >> Subject: RE: (ROSE) interaction diagrams
> >>
> >> I do not believe that as well that Rose is capable of generating codes
> >> from interaction diagrams - that will be a very useful functionality.
> >>
> >> Cheers.
> >>
> >> Patrick
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
