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

[Peter Haumer <phaumer@xxxxxxxxxx>]

The requirements discipline in BUP only
deals with eliciting and writing requirements, not analyzing them.  It
is therefore not Requirements Engineering in that classical sense.  In
RUP analysis is done by the designer and not by the system analyst, which
created a lot of confusion as you can image, but this is how it was.  However,
as there is no analysis in BUP, there is also no need for analysis mechanisms
in BUP (which are different beasts than architectural mechanism, although
they can help improve developing the right and better architectural mechanisms).

I agree with everything Sigurd said
about changing the BUP content.  I also agree with Christoph that
creating architectural mechanisms is just one way of getting to the goal.
 However, as I understand doing essential and proper architecture
work is a key differentiator of BUP against other code-centric approaches.
 So the process design decision we need to make is if using mechanisms
is just one technique out of many that we capture as guidance or if architecture
mechanisms are really driving the process of architecture work and we model
them as tasks and artifacts.  Based on my RUP-biased experience I
think the latter would be the way to go if we want to make the case to
the agile world that this would lead to better results than evolving architecture
in the code.

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
______________________________________________________________

Donald Firesmith <dgf@xxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx

04/27/2006 05:19

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

To	Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
cc
Subject	Re: [epf-dev] Architectural mechanisms - a bit confusing as it stands        ?

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
>  
>


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