Re: [epf-dev] Mechanisms and other terms

[Mark.Dickson@xxxxxxxxx]

Thanks Christoph. I think that it would be hard for anyone to argue with that.

I think the proposal from Sigurd is that we simplify the existing terminology around architecture mechanisms, rather than add any new complexity. I agree with that and it sounds like you do too. Correct?
Cheers
Mark

Mark Dickson
SE&E Practice
Xansa
0780 1917480


----- Original Message -----
From: epf-dev-bounces
Sent: 27/04/2006 06:58
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Mechanisms and other terms

I've followed the discussion about architectural mechanisms. Let me 
throw in my 5 cents.

The goal is software that fills a need of the user.
On the way to the goal, we (as the developers) need to cope with the 
complexity.
If the complexity is overwhelming / doesn't easily fit into one mind, we 
(may) try to deal with complexity by modeling.
*) The waterfall model has distinct phases for analysis and design.
*) MDA has distinct platform independent and platform specific models.
*) Architecture is more abstract and long-living than design.
*) Design is more concrete and project specific.
*) Architecture can be project/solution specific or govern all 
projects/solutions within an enterprise.
*) Architecture has several views: software internal structure, 
operational structure, information structure,...
*) Scott Ambler has a lot of useful advice on agile modeling (model with 
a purpose, model to understand and to communicate,...)

With the end in our minds (one of Covey's advices from the 7 Habits of 
Highly-Effective People), we need the software, we may need some models.
But do we need to have analysis models? Do we need to have design 
models? Do we need to have an architecture that is more abstract and 
long-living than the design?
The answers may well be "yes", but that depends on the context / situation.

I think we shouldn't prescribe the way how to get from the requirements 
to the code via analysis => design => code.
We may show some typical roads to get there, but I wouldn't want that 
openUP readers/consumers/followers imply that they now need to do 
something in one specific way.

And even less would I want to add another term to the already confusing 
terminology in the analysis & design / modeling / architecture domain.

 Christoph



_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev

Whilst this email has been checked for all known viruses, recipients should undertake their own virus checking as Xansa will not accept any liability whatsoever.

This email and any files transmitted with it are confidential and protected by client privilege.  It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.

Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
    Xansa, Registered Office: 420 Thames Valley Park Drive,
    Thames Valley Park, Reading, RG6 1PU, UK.
    Registered in England No.1000954.
    t  +44 (0)8702 416181
    w  www.xansa.com