> -----Original Message-----
> From: Bennett Simon [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 03, 2002 5:01 PM
> To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: RE: (ROSE) The 4+1 View Model of Architecture
>
>
> To me, part of the problem is that these are not 'views' of the
> architecture
> in Rose.
>
> If I create a class diagram that I associate with a use case in the use
> case
> view and stereotype the classes in it as boundary, control and entity
> (because I want to capture the classes that participate in the
> collaboration
> that realises the use case and want a simple view of them), then I have a
> problem in the logical view. If I use the same classes, they appear as
> stereotypes, but if I switch the stereotypes off, then I lose the
> stereotypes in the use case view too. They also appear with '(from use
> case
> view)' or something like that on them (non-UML). If I create new classes
> in
> the logical view, because now I have a package architecture, and know that
> I
> want a particular class called 'de::geheuk::utils::console::Console' then
> I
> lose the fact that this class in my logical view represents the Console
> class that I had in my use case view class diagram.
>
> I have been trying to find a way to implement traceability. So, given a
> requirements change that affects a use case, it would be nice to be able
> to
> use SoDA to trace from the use case in ReqPro to the use case in Rose (OK,
> can do) to the classes that collaborate to realise that use case (OK, can
> do) to the classes in the analysis and design model with the same names
> (can't do) to the generated code (can't do).
>
> Simon
>
I've been addressing the last two problems (the can't dos) in more
or less the same way since Rose 98, hoping all along that a workaround would
become unnecessary. So far, no such luck.
It's only lately that I have started to question the assumptions
behind these expectations. Yes, I would expect that we have some
traceability between the code and the rest of the model (and this can be
addressed with tools that do full code generation), but what about this
analysis and design model separation? What does it give us?
The established wisdom tells us that there is an abstract analysis
model and a corresponding design model. We somehow or other relate the two,
so that we can trace changes in one to the impact in the other. You change
the requirements, this has an impact on the analysis model and a
corresponding impact on the design model. Or, we discover that we cannot
meet performance requirements if we have two separate classes for something
or other, so we change the design, which has an impact on the analysis model
and so on.
I have now started to question the need to have this analysis and
design separation (too early on the first working day of the week to use the
word dichotomy, so I won't) -- especially since the workaround works so
well. Something in the back of my mind just keeps nagging me, telling me
that maybe the workaround is an appropriate solution.
I repeated this in some form or other in OTUG and RUP and ROSE
forums for a few years, so I'll summarise the workaround here and I'll put
it up in a better prepared whitepaper in a week or two -- I promise!
(By the way, if you notice any similaruty to the translationist
approach, it's no coincidence.)
I work off two premises, neither of which I will justify here.
Justification due in a week or two.
(1) The maintenance of two models, one for analysis and one for
design, is by its very (intuitive, not automated) nature manual.
(2) Even with automated assistance, the effort for the manual part
of this maintenance dominates the costs.
(Hint: the reason is all to do with architectural drift. Some
esoteric machine intelligence may resolve that drift and connect the two
ends together, but I doubt it, as we often have trouble understanding other
people's reasons for mapping from analysis to design in some way rather than
another.)
To get rid of the architectural drift, we make a few sacrifices in
terms of customising our solution. In return, we gain predictability.
The sacrifice is this: When we apply a certain mapping from one
analysis class to a design class, we do the same with all the others.
The gain is this: There is only a single pattern in any
situation, so it is relatively straightforward to trace between analysis and
design classes.
At this point, something rather important happens: the distinction
between the analysis and design models blurs to the point of obsolescence.
So, we get rid of them and end up with a single model that serves both
purposes. In order to separate analysis and design artefacts (they still
exist, but blended in the same model) we use some packaging tricks to leave
the domain classes together in one group of packages (so that they can be
used for domain modelling without reference to implementation artefacts) and
the design.implementation classes in other packages that depend on domain
packages.
Voila: traceability is achieved, as there is nothing to trace to and
from.
(I exaggerate, naturally, as the dependencies between the analysis
and design packages are still important).
There are also other implications to this:
- If there is no code generation being done (i.e. all coding is
manual), we nedd only the domain model and the model of the architectural
mechanisms -- i.e. the mappings from analysis to design classes. You can now
trace between code and analysis models, albeit manually.
- If code generation is required, it is relatively straightforward
to write a model generator (yes, indeed!) to produce the design artefacts
based on the domain classes, because the mapping is regular.
Sorry, no examples this time, but I have done this gig several times
on these forums, now, so I'll use the energy to write a proper paper on this
instead. It is, after all, a regular FAQ.
Best regards,
H�seyin Angay
Karabash Ltd.
www.karabash.co.uk
> -----Original Message-----
> From: English, Art [mailto:[EMAIL PROTECTED]]
> Sent: 03 May 2002 15:52
> To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; Rossomando,
> Philip
> Subject: (ROSE) The 4+1 View Model of Architecture
>
>
>
> I have been having difficulty understanding the 4+1 View Model, so I
> decided
> to dig into it more today and I feel that I have reached an understanding,
> but I also feel that Rational should alleviate the confusion around the
> 4+1
> View Model by making this concept more clear within Rational Rose
>
>
>
>
> Let's start by creating a new model in Rose using the RUP template. Rose
> creates four views: Use Case, Logical, Component, and Deployment
>
>
>
> The 4+1 Architecture starts with the "Use Case View" that drives the four
> other views. The Use Case View describes hat the system should do. OK.
> This
> is the first view defined in the Rose model that uses the RUP Template.
>
>
>
> The next view in the 4+1 View Model is the "Logical View." This view
> contains the Analysis Model and the Design Model. This is OK too. The Rose
> model still matches up to the 4+1 Architecture.
>
>
>
> Now we have the Process View in the 4+1 View Model. This view is missing
> from the Rose model based upon the RUP template. Since I cannot create a
> new
> top-level package in Rose (I don't know why this limitation exists. Is
> there
> a way around it?), the RUP Tool Mentor for Documenting the Process View in
> Rational Rose suggest that I create a package in the Logical View of the
> Rose model and call it the Process View. After creating the process view,
> I
> can create class diagrams where classes are stereotyped <<process>> and
> <<thread>> to add some meat to the process view. I can show how
> <<process>>
> and <<thread>> classes are associated with each other in class diagrams-as
> well as show how they interact in sequence diagrams.
>
>
>
> Why doesn't the RUP template contain a top-level package for Process View?
> Why can't I create a top-level package myself in this model for Process
> View?
>
>
>
> The next view in the 4+1 View Model is the "Implementation View." In the
> Rose model based upon the RUP template it is named the "Component View."
> In
> the RUP Tool Mentor, Structuring the Implementation Model Using Rational
> Rose it tells us to put the Implementation Model in the Component View.
> The
> Tool Mentor does not mention the Implementation View. Personally I think
> we
> should change the Rose model based upon the RUP template and make
> "Component
> View" the "Implementation View" or vice versa. I would just like the names
> to match.
>
>
>
> The last view in the 4+1 View Model is the "Deployment View." This View
> matches up in both the 4+1 View Model and the Rose model based upon the
> RUP
> template. My only complaint here is why not make this View a package so I
> can create more than one deployment diagram. This is really a very serious
> limitation. Also, I know XDE supports putting components in nodes, but
> Rose
> does not. This is another limitation that should be fixed.
>
>
>
> If I am inaccurate in any way, please correct me. My goal is to achieve a
> full understanding of the 4+1 View Model and additionally how it maps to
> Rational Rose.
>
>
>
> Thanks,
>
>
>
> Art.
>
>
>
> Arthur English
>
> Research Director, Technology and Architecture
>
> Global Industries
>
>
>
> Unisys Corporation
>
> One Unisys Way
>
> Blue Bell, PA 19424
>
> *
>
> * (215) 986-5712
>
> Mobile: (610) 805-0183
>
> Net: 423-5712
>
> eMail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
>
>
> ************************************************************************
> DISCLAIMER
>
> The information contained in this e-mail is confidential and is intended
> for the recipient only.
>
> If you have received it in error, please notify us immediately by reply > e-mail and
>then delete it from your system. Please do not copy it or
> use it for any other purposes, or disclose the content of the e-mail
> to any other person or store or copy the information in any medium.
>
> The views contained in this e-mail are those of the author and not
> necessarily those of GEHE Group companies.
> ************************************************************************
>
> ************************************************************************
> * 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
> *************************************************************************
This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg 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.
Registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.
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
*************************************************************************
