Re: [epf-dev] Architectural mechanisms - a bit confusing as it stands ?

[Donald Firesmith <dgf@xxxxxxxxxxx>]

Peter,
I would recommend restricting the term analysis to requirements 
engineering, which already has the terms 'requirements analysis' and 
analyst.  I strongly recommend keeping the word architecture with 
architecture mechanism, architecture style, and architecture pattern to 
ensure that the reader understands that we are talking about 
architecting rather than requirements.
Don Firesmith

Peter Haumer wrote:

> I agree that the term mechanism is not used very much.  However, I 
> have used Analysis Mechanisms quite extensively in consulting 
> engagements.  They really help the modelers to focus on the essence of 
> the use case realization and not to get lost in modeling behavior that 
> the analysis mechanisms abstracts from (e.g. not to care about 'open 
> file' messages for persistence, etc.).  They can either be kept 
> abstract or concrete platform independent patterns can be created for 
> them if necessary.  
>
> The attributes Sigurd lists are not the mechanism, but an aid for the 
> design decision rationale to find the right platform specific 
> architectural mechanisms (or patterns), which are quite different 
> patterns than the analysis patterns.  
>
> IF BUP includes Analysis then I think they are an essential tool, but 
> BUP does not deal with analysis, correct? Then I think we should just 
> focus on architectural style and patterns.
>
>
> Thanks and best regards,
> Peter Haumer.
>
> ______________________________________________________________
>
> Rational Software | IBM Software Group
> PETER HAUMER, Dr. rer. nat.
> RUP Development, Cupertino, CA
> Tel/Fax: +1 408 863-8716
> ______________________________________________________________
>
>
> *"Scott W. Ambler" <swa@xxxxxxxxxxxx>*
> Sent by: epf-dev-bounces@xxxxxxxxxxx
>
> 04/26/2006 07:14
> Please respond to
> Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
>
>
> 	
> To
> 	shopen@xxxxxxxxxxxxxx, "Eclipse Process Framework Project Developers 
> List" <epf-dev@xxxxxxxxxxx>
> cc
> 	epf-dev@xxxxxxxxxxx
> Subject
> 	Re: [epf-dev] Architectural mechanisms - a bit confusing as it       
>   stands ?
>
>
>
> 	
>
>
>
>
>
>
> On Wed, April 26, 2006 7:03 am, Sigurd Hopen said:
> <snip>
> > The above can hardly be characterized as a mechanism - can it ??   
> It is a
> > description of important attributes to consider for the Architectural
> > Mechanism called Persistence.
> >
> >
> >
> > So, what do you all think ?  Possible to reposition this without rocking
> > the
> > boat ?
> >
>
> I'd rather rock the boat a bit.  ;-)
>
> I found the discussion of "architecture mechanisms" a bit abstract.  I
> frankly can't recall anyone using the term "mechanisms" in practice,
> although to describe the things that Sigurd has discussed "architectural
> concerns" or less frequently "architectural issues".
>
> If we want OpenUP to be attractive to developers then we need to use terms
> which people are familiar with, IMHO.
>
> - Scott
> http://www.ambysoft.com/scottAmbler.html
>
> Refactoring Databases (
> http://www.ambysoft.com/books/refactoringDatabases.html ) is now
> available.
>
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
>