Ø 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