Hi everyone,
The only obvious advantage that I can see with the code being the design is on a very small project where the designer is also the programer and the process followed didn't involved much analysis.
Basically, no design is perfect and the programmer will figure that soon enough, if the programmer happens to be the designer of the system then he can make the call on what to change to rectify the problem. At this point he is looking at the code so why not change the code and let the design fix itself?
But if you are on largescale project, where the architects are on a completely different team then the programmers and they are just handing out an architecture document then there is no way the programmer should ever be allowed to change the design from the code. Not because the architects are better then the programmers (as someone suggested :) ) but because the design came from an analysis of a use case. If you fix the design from the code, but what was really wrong was the actually analysis of the problem, then the architecture is still wrong at the core level.
The proper thing to do would be for the programmers to notify the architects and let them figure out whats wrong with the design. Maybe it can be traced back to an analysis class that would have been used to develop other design classes on the next iteration. If so then you saved the architect team from making the same mistakes repeatedly.
I think it was Don who said he believed the process to follow should be the following:
problem analysis, architecture, requirements, design, and
coding-> with lots of cycles in between.
I think your a bit misguided with the RUP process, which says the following : Business Modeling, Requirements, analysis, design, implementation, test, deployment, CM, PM and environment.
Now all of these are iterated over the inception, elaboration, construction and transition. In the inception phase for example, it is stated that you should start a candidate architecture. And the only problem analysis that I could see here would be part of the business modeling (domain model) or maybe risk analysis?. I certainly don't think that problem analysis replaces Analysis which you don't have much choice do to after requirements (what would you analyse if you don't have requirements?).
Marc
-----Original Message-----
From: Victor Volle [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 08, 2001 7:36 AM
To: [EMAIL PROTECTED]
Subject: Re: (ROSE) RE: Code is not design!
Hi!
There will always be a gap between design and code (as well as
between analysis and design, and between requirements and analysis).
But the problem is, that they are intertwined. If you change one
side of each pair, you have to change the other side, too.
And you can not bridge the design-code gap with the current
code generators. The only thing you can currently
forward engineer from Rose are the skeletons of your code:
class, attribute and method declarations.
So if you want to change
some of these declarations, you either have to do in Rose or
reverse engineer the code (convince your developers to do
everything in Rose :-)). But if you change the _behaviour_ of the
system, that is documented in interaction diagrams, you are
on your own. You have to keep both sides in sync manually.
Even if you could generate some meaningful
code out of interaction diagrams, it is nearly impossible to
capture all necessary behaviour in these diagrams. So what
can you do? We keep the number of interaction diagrams to a minimum
and are developing our own code generators (or try the
Codagen-Generators).
We are still hoping that Rational is developing a template
driven code generator.
Tools like Together are nice when a 1:1 relation between
classes in the design and classes in the code exists. But when you
are programming to a larger Framework the relation often is 1:n, and
you have to throw in some helper classes for each package (Java),
for each "component", etc.
Victor
Shields James wrote:
>
> 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: RE: (ROSE) interaction diagrams
>
> 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
> >
> >
> >
> >
> > -----Original Message-----
> > From: Michael Hill [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 04, 2001 10:33 AM
> > To: Patrick Adewunmi; Moin Ahmad
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: (ROSE) interaction diagrams
> >
> > << File: ATT00000.txt; charset = utf-8 >>
> ************************************************************************
> * 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
> *
> *************************************************************************
> ************************************************************************
> * 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
> *
> *************************************************************************
--
-------------------------------------------------------------------------
Victor Volle BASYS GmbH
Bereichsleiter Am Weichselgarten 4
Technisches Consulting 91058 Erlangen
Tel: ++49 9131 77740 Germany
Fax: ++49 9131 777444
mailto: [EMAIL PROTECTED] www: http://www.basys-gmbh.de
************************************************************************
* 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
*
*************************************************************************
