Analysis, Design model, round-trip engineering

Question

ok, here's the point.
We work with the problem domain and develop the analysis model. The analyst at this stage doesn't concern himself with the implementation details, some low-level code patterns and the programming language (well, let's forget for now about C's multiple inheritance and Java's workaround for it). So, when most of the analysis work is done, we end up with major classes (populated only with some basic attribs & behaviour; then, we have a high-level representation of business processes and corresponding activity diagrams. Of course, this model will be refined at a later stage, but for now it will do.
Say, we have the model in a project. Now we move to the design level. More and more details are added to the model, sequence/collaboration diagrams are added, we concern ourselves much more with the detailed class behaviour.
And here's the first question. Should we leave the original high-level diagrams intact and produce separate detailed ones? Generally, they represent the same process, but at a more detailed level. What about duplication of diagrams? Or should we elaborate the existing ones (but then we lose the clear and simple bird-eye view of the problem domain).
After that, we make a decision to implement the system as a set of EJB's. So, we've switch to component modeling at system design. UML model for these components differs quite a lot from a traditional one, so it can be quite painful to refactor the existing interaction diagrams. But do we need to do it? I agree that having <<EJBImplementation>>, <<EJBRealization>> , etc stereotypes displayed in the analysis model is not a nice solution.
Another question - is it a good idea to start a separate project for system design and just import/copy the required pieces from a higher-level design model? Or can we get away with combining all stages in one project file?
Please, read all of the above in the light of round-trip engineering. So, finishing after analysis stage, is not an option, but to lead the whole project to as low level as implementation details.
I'd like to hear from you, some hands-on experience with similar projects, your approaches. Feel free to comment on the flow of events.
Best regards,
Andrew

Answer 1

ok, here's the point.
We work with the problem domain and develop the
analysis model. The analyst at this stage doesn't
concern himself with the implementation details, some
low-level code patterns and the programming language
(well, let's forget for now about C's multiple
inheritance and Java's workaround for it). So, when
most of the analysis work is done, we end up with
major classes (populated only with some basic
attribs & behaviour; then, we have a high-level
representation of business processes and corresponding
activity diagrams. Of course, this model will be
refined at a later stage, but for now it will do.
Say, we have the model in a project. Now we move to
the design level. More and more details are added to
the model, sequence/collaboration diagrams are added,
we concern ourselves much more with the detailed class
behaviour.
And here's the first question. Should we leave the
original high-level diagrams intact and produce
separate detailed ones? Generally, they represent the
same process, but at a more detailed level. What about
duplication of diagrams? Or should we elaborate the
existing ones (but then we lose the clear and simple
bird-eye view of the problem domain).Depends on whether you are concerned about the abstract methodology or more concerned about the implementation methodology.
For full process control, on a large project, you will have a architecture design which will always reflect the target system but has little to do with the implementation design. If the architecture needs to change it means something was "wrong" with it (which could come about due to a change order or a refinement of the specification of the system.) There might be other associated high level documents which occupy the same level - such as the project plan. This would typically be the project initiation phase which occurs before software design starts.
Of course you would keep all of the documents. Just as naturally each version would be checked into the version control system.
>
After that, we make a decision to implement the system
as a set of EJB's. So, we've switch to component
modeling at system design. UML model for these
components differs quite a lot from a traditional one,
so it can be quite painful to refactor the existing
interaction diagrams. But do we need to do it? I agree
that having <<EJBImplementation>>, <<EJBRealization>>
, etc stereotypes displayed in the analysis model is
not a nice solution.I doubt that any reasonable system is going to make the decision to use J2EE in the system design process. That is always going to be a architecture or requirements decision (even if it is implicit.) If not then it suggests that there are probably at least three levels to the design process and the J2EE decision is in the top most layer (maybe there is a "high" and "low" level architecture process.) And architecture design must describe why J2EE was choosen and what if any alternatives were considered.
Again this document will be retained (and checked into version control.)
>
Another question - is it a good idea to start a
separate project for system design and just
import/copy the required pieces from a higher-level
design model? Or can we get away with combining all
stages in one project file?
In the abstract yes.
Why? Because in an ideal design environment, a "high" (system) level design is created by a small very experienced set of developers. Then it is handed off to many junior developers for "low" (detailed) design. That doesn't work if you are using the "same" design. This is only somewhat mitigated by design tools that somewhat support this process (or least last time I checked they didn't support it very well.)
Keep in mind that this is the ideal, and it is unlikely (probability wise) that you are working at or with a company where doing this is feasible much less encouraged.
Please, read all of the above in the light of
round-trip engineering. So, finishing after analysis
stage, is not an option, but to lead the whole project
to as low level as implementation details.
Round trip. You start with the documents that have been checked in. You branch the version control tree or just up the version numbers of the docs (depending on how "deliverables" are being handled) and start over.