Ø
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.
Ø
This is indeed part of the confusion,
because RUP – and now OpenUP – fails to describe this accurately.
The extract is from a Concept page in RUP/OpenUP and it says “Here is
some sample Analysis Mechanisms, and then it lists 4-5 examples (of which
Persistence is one), and for each list the attributes. The classic example used
in ratl training courses to describe this RUP concept is
Persistence
is an Analysis Mechanism – described by adding value ranges to the
typical attribs such as volume, granularity of stored objects, expected
frequency of read/update/delete etc.
Persistence
using relational db is a Design Mechanism, here’s where you describe
some techniques mapping the object model to relational tables, and define the
services (interface) the mechanism offers (enables as Peter says to encapsulate
complex behavior and results in higher abstractions in the UCRs)
RDB
Persistence using JDBC is an Implementation Mechanism describing how to access
the Java sql library to implement the db support
I’m not questioning the usefulness
of architectural mechanisms (although I agree that the name itself is a bit
abstract) – nor that we can benefit from talking about them at different levels
of abstraction, but I’m questioning the overly complex presentation of
the concept where we try to define these as three-four different things. To me,
this is clearly one concept (Analysis PATTERN is orthogonal to this, and can be
used anytime we want to describe PI collaborations of any sort); how are we
going to be sure that our system meets the arch. significant requirements of db
storage. We evolve the mechanism through Analysis | Design | Implementation
states as we learn more about the problem and about the platform specific
constraints.
I think a fix would at least require the
rename of the STEP (sorry Ricardo) and probably the description to go with it, to
something along the lines of “Identify and describe architectural
mechanisms” and a rename to the Concept page named Analysis Mechanisms to
become something along the lines of “Significant Architectural Requirements”,
and describe how the identification of these are important inputs to the
definition of Architectural Mechanisms.
From: Peter Haumer
[mailto:phaumer@xxxxxxxxxx]
Sent: 26 April 2006 23:39
To: Eclipse Process Framework
Project Developers List
Cc: Eclipse Process Framework
Project Developers List; epf-dev-bounces@xxxxxxxxxxx; shopen@xxxxxxxxxxxxxx
Subject: Re: [epf-dev]
Architectural mechanisms - a bit confusing as it stands ?
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
