You have to sacrifice some abstraction of the analysis classes, so that they
are structured more closely to your implementation intention.
Remember that I mentioned one caveat: this approach assumes a certain type
of architecture where all the business logic (which you modelled with your
domain classes) happens in business object and policy object layer. So, your
abstract domain analysis classes are very close to your solution business
and policy objects. So close that you won't mind losing a little bit of
abstraction for the occasional tweak.
I recommend domain modelling done in a pretty rigorous manner -- much more
so than the usual ERD-like diagrams you must have seen many so-called
business analysts draw. These are ok as throwaway sketches, but not as the
models of the domain. The domain model should capture all the classes and
the business rules that govern them.
When you then draw sequence diagrams for your use cases, you prove that the
domain model will work. So, why throw away a model that works? Instead, you
embellish it with your design artefacts in user interface, object
communication and persistence levels. You now have a full implementation
model but your analysis classes are intact.
EXAMPLE:
Your analysis discovers some classes which you organise like this:
Domain package
--------------
Student, Course, Teacher, CourseScheduler
You then do your design work and you end up with these packages:
UI package (representing the window controllers)
----------
CourseScheduling, StudentMaintenance, CourseMaintenance, TeacherMaintenance
UI Corba package
---------------
StudentStub, CourseStub, TeacherStub, CourseSchedulerStub
Backend Corba package
---------------------
StudentSkeleton, CourseSkeleton, TeacherSkeleton, CourseSchedulerSkeleton
Persistence package
-------------------
StudentEntity, CourseEntity, TeacherEntity
All these packages depend on the Domain package.
Now, the Corba classes can be generated if necessary. So can the persistence
stuff. There is probably some handcrafting of the UI classes. They provide
the communication with the windows themselves.
Remember that this is a very simple example. I hope we don't get into a
discussion over the appropriateness of the class names or of the
over-simplified architecture. You would, for instance, need better
decoupling between some of the packages through client and server interfaces
and so on. It's likely that the business objects would have some methods to
do with implementation, too; but these can be hidden for domain analysis
documents.
The point here is to analyse your domain as you intend to develop it. Then
keep the visible parts of the domain classes at a high level of abstraction
and add the design details at the lower level of abstraction in a way that
will not affect the domain classes.
The domain classes are your biggest assets. You don't want to
over-pollute their abstractions during implementation and you don't want to
spend too much time tracing backwards and forwards between analysis and
design details. The best way of achieving this is to force your design into
a form that preserves the domain classes. It so happens that this is a
pretty good architecture for enterprise architectures, so you don't
sacrifice anything.
Regards,
H�seyin Angay
www.karabash.co.uk
Karabash Ltd.
> -----Original Message-----
> From: Peter Smith [mailto:[EMAIL PROTECTED]]
> Sent: 10 January 2002 17:37
> To: Angay, Huseyin
> Subject: RE: (ROSE) Synching the Analysis and Design models
>
>
> Huseyin, since Analysis classes are at a different
> level of abstraction than design classes (that may at
> design become several different classes) how can you
> reconcile this? How would you make a design class
> dependent on an analysis class when they come from two
> different perspectives? I may not be understanding your
> approach completely, can you give some examples? It
> sounded like you were directly using both sets of
> classes in the implementation. I don't see how this
> could work?
>
> Thanks,
> Pete Smith
>
> Quoting "Angay, Huseyin" <[EMAIL PROTECTED]>:
>
> >
> > Hi Erica.
> >
> > I imagine you are referring to analysis and design
> class diagrams when you
> > are talking about analysis and design models.
> >
> > Keeping separate models looks good but it's not
> feasible without tool
> > support.
> >
> > I would suggest a different approach of partitioning
> your design model into
> > packages of classes that come as part of your
> analysis (i.e. your business
> > and policy objects) and packages of classes that
> result from your technical
> > architecture, (i.e. user interface and infrastructure
> objects).
> >
> > Now make the design packages depend on the analysis
> classes and you have a
> > model of both your analysis and design/implementation
> in one place. You can
> > isolate the analysis classes for higher level
> documentation purposes or use
> > the full set of classes for your implementation.
> >
> >
> > The advantage of this approach is that it gives you
> separate analysis and
> > design models without the synchronisation problems:
> changes to your
> > analysis
> > classes will propagate to your design. You can also
> do some pretty neat
> > tricks like generating large chunks of your design
> classes (or even code)
> > by
> > applying design pattern templates to your analysis
> classes.
> >
> > The disadvantage is that you need to use a certain
> type of architecture
> > with
> > business objects in the middle. Given that this is
> actually a good
> > architecture anyway, it's not much of a disadvantage,
> though.
> >
> >
> > Best regards,
> > Huseyin Angay
> > Karabash Ltd.
> > www.karabash.co.uk <http://www.karabash.co.uk>
> >
> >
> >
> > -----Original Message-----
> > From: Winston, Erica [mailto:[EMAIL PROTECTED]]
> > Sent: 10 January 2002 16:15
> > To: '[EMAIL PROTECTED]'
> > Subject: (ROSE) Synching the Analysis and Design
> models
> >
> >
> > Hi, all,
> >
> > I am inquiring as to the best practices for synching
> the analysis and
> > design
> > models. The project in question is large and will be
> released in several
> > evolutionary lifecycles of RUP over 3 years, with
> releases being worked in
> > concurrently. So keeping a current analysis and
> design model would have a
> > lot of benefit if there is a way to manage them.
> >
> > In my past experience, the analysis model evolved
> into the design model and
> > was not maintained separately after the cutoff.
> >
> > If there are any technotes/white papers, I'd be
> grateful for the URL. I
> > checked through the web site and found nothing.
> >
> > TIA,
> >
> > Erica Winston
> > Software Consultant
> >
> >
> >
> > This private and confidential e-mail has been sent to
> you by Egg.
> > The Egg group of companies comprises Prudential
> Banking plc
> > (registered no. 2999842), Egg Financial Products Ltd
> (registered
> > no. 3319027) and Egg Investments Ltd (registered no.
> 3403963) which
> > carries out investment business on behalf of Egg and
> is regulated
> > by the Financial Services Authority. All members of
> the Egg group
> > are registered in England and Wales. Registered
> offices: 142
> > Holborn Bars, London EC1N 2NH
> >
> > If you are not the intended recipient of this e-mail
> and have
> > received it in error, please notify the sender by
> replying with
> > 'received in error' as the subject and then delete it
> from your
> > mailbox.
> >
> >
> ********************************************************
> ****************
> > * Rose Forum is a public venue for ideas and
> discussions.
> > * For technical support, visit
> http://www.rational.com/support
> > *
> > * Post or Reply to: [EMAIL PROTECTED]
> > * Subscription Requests: [EMAIL PROTECTED]
> > * Archive of messages:
> > *
> http://www.rational.com/support/usergroups/rose/rose_for
> um.jsp
> > * Other Requests: [EMAIL PROTECTED]
> > *
> > * To unsubscribe from the list, please send email
> > * To: [EMAIL PROTECTED]
> > * Subject: <BLANK>
> > * Body: unsubscribe rose_forum
> >
> ********************************************************
> *****************
> >
>
This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies comprises Prudential Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority. All members of the Egg group
are registered in England and Wales. Registered offices: 142
Holborn Bars, London EC1N 2NH
If you are not the intended recipient of this e-mail and have
received it in error, please notify the sender by replying with
'received in error' as the subject and then delete it from your
mailbox.
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Post or Reply to: [EMAIL PROTECTED]
* Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
* http://www.rational.com/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
* To: [EMAIL PROTECTED]
* Subject: <BLANK>
* Body: unsubscribe rose_forum
*************************************************************************
