| Re: [epf-dev] Architectural mechanisms - a bit confusing as itstands ? |
|
"Architectural service" ----- Original Message ----- Sorry for jumping into this late (I was on vacation last
week), but my two bits...
- I have traditionally used the term "architectural
mechanism" and the three levels of abstraction (analysis, design,
implementation) and it's worked pretty well. However, while at the end of the
explanation, people seem to get the idea pretty well, they really had no idea at
the beginning what I was trying to get to (just by the name). More recently I've
been using the term "architectural service" instead.
- Here's my definition of "architectural service": "A
capability provided by the architecture to enable applications to function
within a technology platform." Another way to put it, "things the architecture
does, that all by themselves aren't useful, but without them the application
couldn't function".
- The definition of analysis mechanism in OpenUP is really
a definition of a pattern (a la Alexander), which is odd as it says it "an
analysis mechanism is a pattern that constitutes a common solution to a common
problem" which really means "an analysis mechanism is a pattern that is a
pattern..."
- I have found using a three- or four-level state model
useful for work products that are incrementally refined. For
example:
- Identified: architectural services identified by
name -- this would be similar to the notion of "analysis
mechanism"
- Described: architectural services mapped to
analysis classes with qualitative and quantitative
attributes
- Outlined: approach to implementing architectural
services described -- this would be similar to the notion of "design
mechansim"
- Detailed: architectural services implemented in
context of the technical platform -- this would be similar to the notion of
"implementation mechanism"
From this, one can come up with simple task names such as
"identify architectural services", "describe architectural services", "outline
architectural services", and "detail architectural
services"...
Chris ~:|
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Sigurd Hopen Sent: Thursday, April 27, 2006 1:32 AM To: Mark.Dickson@xxxxxxxxx; 'Eclipse Process Framework Project Developers List' Cc: peter.eeles@xxxxxxxxxx Subject: RE: [epf-dev] Architectural mechanisms - a bit confusing as itstands ? Mark, I’d agree that
this paper is a good one to plant the concept,but as the title suggests , its
more on Architectural Requirements (i.e. those which leads to the needs of
creating Arch. Mechanisms). It would be good if we had Pete’s paper AND a
concept on Architectural Mechanisms that describes the mechanisms and their
evolution from analyzing those req’s Pete talk about, through the “conceptual –
concrete – actual” stages. So yes, I think we need two CONCEPTs as you say, but
I’d favor these to be CONCEPT: Capturing Architectural Requirements, and
CONCEPT: Architectural Mechanisms including all stages of developing the
mechanisms (the existing Analysis Mechanisms concept talks mainly about
characteristics of sample Mechanisms, and the two-liner Design and
Implementation Mechanisms paper in OpenUP is pretty useless IMHO).
Greetings Pete !
Hope you’re well ? Did anything become of the rework of the architecture
course? Anything we could harvest in epf round arch. mechanisms
? Cheers, From:
Mark.Dickson@xxxxxxxxx [mailto:Mark.Dickson@xxxxxxxxx] Sigurd I've reviewed the sections you
refer to (STEP - Identify Analysis Mechanisms; CONCEPT - Analysis Mechanisms)
and I am pretty sure you're right. I think that the concept should be
"Architecture Mechanisms." Calling them "Analysis Mechanisms" etc is too
confusing. I mentioned a useful paper by
Peter Eeles in my last note. You can read it here http://www-128.ibm.com/developerworks/rational/library/4706.html.
It explains that anaysis, design and implementation mechanisms are
representations of Architecture Mechanisms. I agree that we should
rename the sections; STEP - Identify *Architecture*
Mechansisms CONCEPT - *Architecture*
Mechanisms CONCEPT - *Designing and
Implementing Architecture Mechanisms* (was Design and Implementation
Mechanisms") We will also need to reword the
associated text. The Task for looking at
Architecture Mechanisms at Design and Implementation level is very different
from old RUP, where there was an Activity (= EPF TASK) called "Identify Design
Mechanisms." In OpenUP, it looks like the Task is "Refine the Architecture" and
the step is "Define strategies for achieving quality requirements." There's no
text there yet, so I can't be sure. It's also possible that mechanisms might be
considered as part of the step "Identify common solutions across
requirements." I think these Step names are good enough, unless someone *really*
wants to change them too... We'll give this a little more
airtime and then I propose we raise a bugzilla to cover this. I don't mind it
being assigned to me for now but Sigurd (or anyone else) is welcome to write any
of the text changes. I think it's ok to raise a new bugzilla to cover this group
of changes, as it represents a nicely related bundle of
things. I'd also like to talk
to Peter Eeles about the possibility of including his article as the basis
for a Guideline in OpenUP on this topic. What do you think about that? I've
cc'd Peter on this note. cheers Mark
Mark Dickson -----epf-dev-bounces@xxxxxxxxxxx
wrote: ----- To: "'Peter Haumer'"
<phaumer@xxxxxxxxxx>, "'Eclipse Process Framework Project Developers
List'" < 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]
_______________________________________________
Whilst this email has been checked for all known viruses, recipients should undertake their own virus checking as Xansa will not accept any liability whatsoever. This email and any files transmitted with it are confidential and protected by client privilege. It is solely for the use of the intended recipient. Please delete it and notify the sender if you have received it in error. Unauthorised use is prohibited. Any opinions expressed in this email are those of the individual and not necessarily the organisation. Xansa, Registered Office: 420 Thames Valley Park Drive, Thames Valley Park, Reading, RG6 1PU, UK. Registered in England No.1000954. t +44 (0)8702 416181 w www.xansa.com |