| RE: [epf-dev] Architectural mechanisms - a bit confusing as it stands ? |
|
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]
_______________________________________________
|