Mark and other architecture freaks ;-)
The concept of Architectural mechanisms isn’t quite as clear as it
could, IMO.
This concept is described in the RUP and hence also in the OpenUP’s
Architecture Discipline (although the Concept: Design and
Implementation Mechanisms is merely a placeholder in OpenUP), in an
unnecessarily complex way with analysis, design and implementation
mechanisms. I have experienced some confusion when teaching these
concepts to new RUPers, simply too many different “mechanisms”
architectural mechanisms, analysis mechanisms, design mechanisms,
implementation mechanisms, design patterns… A fairly straight forward
concept is described as three (or even four if you count the
“umbrella”) “artifacts” (or subartifacts of Architecture) as opposed
to three states of the same “thing”. _/Architectural/_ mechanism is
the important entity here.
Analysis mechanisms are simply the identification & specification of
architectural mechanisms (the req. of arch. mech. if you like)
Design mechanisms is the design / model of the architectural mechanism
Implementation mechanisms describe how to realize the arch. mechanism
within the constraints of the implementation platform.
So, instead of task “Identify Analysis Mechanisms” I’d like to see it
as “Identify and describe architectural mechanisms” – or even “Analyze
Architectural Mechanisms”
At a high level, you analyze, design and implement _/architectural
mechanisms/_
One extract of the “Concept: Analysis Mechanisms” which highlights my
points:
However, as more analysis patterns are established in various domains,
the partial or complete instantiation of these in analysis mechanisms
will lead to these mechanisms appearing in the upper layers of the
architecture.
* Examples of Analysis Mechanisms *
· * Persistency *
For all classes whose instances may become persistent, we need to
identify:
·
· * Granularity * : Range of size of the objects to keep persistent
· * Volume * : Number of objects to keep persistent
· * Duration * : How long does the object typically need to be kept?
· * Retrieval mechanism * : How is a given object uniquely identified
and retrieved?
· * Update frequency * : Are the objects more or less constant; are
they permanently updated?
· * Reliability * : Shall the objects survive a crash of the process;
the processor; or the whole system?
.
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 ?
/Sigurd
/Sigurd Hopen
2-Pro Mentor , Norway
+47 90689131
shopen@xxxxxxxxxxxxxx <mailto:shopen@xxxxxxxxxxxxxx>
www.2promentor.com <http://www.2promentor.com>
------------------------------------------------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
