| Re: [epf-dev] Architectural mechanisms - a bit confusing as it stands ? |
My fellow freaks ;-)
Sigurd - this is a good point. I agree with you.
I *have* used the term "architecture mechanisms" for many years and been very comfortable with it. Peter Eeles (Rational) wrote a really good paper on this very subject a few years ago which makes it pretty clear.
Equally, I acknowledge that others don't use this terminology but deal with similar (if not the same) concepts.
I agree with your viewpoint Sigurd - I see analysis "mechanisms" and design "mechanisms" as aspects of architecture mechanisms - and I agree that the overuse of the "m" word can phase newcomers into thinking that they are different things. So there seems to be a good case for considering a change.
I am inclined to think (IMHO) that the term architecture mechanism is an established and understood concept, well supported by existing documentary materials and practitioners. I agree that the terms "analysis mechanism," "design mechanism," and "implementation mechanism" are potentially confusing. I agree with Sigurd that a clearer view is that we can represent a mechanism at different levels of fidelity at different times, depending on how much work we have done. These levels are analysis, design and implementation.
But the essential point that Sigurd makes and I share is that we are talking about the refinement of a single thing: the architecture mechanism.
Finally - I don't think that this is rocking the boat at all. I think it is consistent with the intent of authors of this concept in RUP. I think that we're just tidying up the vocabulary a bit.
cheers
Mark
To: shopen@xxxxxxxxxxxxxx, Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
From: Donald Firesmith <dgf@xxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
Date: 04/26/2006 01:18PM
Subject: Re: [epf-dev] Architectural mechanisms - a bit confusing as it stands ?
Everyone,
I use architecture style, architecture pattern, and architecture
decision. I also use more specialized words in special engineering areas
such as safeguard in safety and countermeasure in security.
Don
Sigurd Hopen wrote:
> 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
>
>
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev