"Architectural service" I like that term and it seems to fit the concept well. Any other thoughts? Regards Mark Mark Dickson SE&E Practice Xansa 0780 1917480
----- Original Message ----- From: "Chris Armstrong" [chris.armstrong@xxxxxxxxxxxxxxxxx] Sent: 04/05/2006 18:42 To: <shopen@xxxxxxxxxxxxxx>; 'Eclipse Process Framework Project Developers List'" <epf-dev@xxxxxxxxxxx>; Mark Dickson Cc: <peter.eeles@xxxxxxxxxx> Subject: RE: [epf-dev] Architectural mechanisms - a bit confusing as itstands ?
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 ~:|
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] Sent: 27 April 2006 01:55 To: shopen@xxxxxxxxxxxxxx; Eclipse Process Framework
Project Developers List Cc:
peter.eeles@xxxxxxxxxx Subject:
RE: [epf-dev] Architectural mechanisms - a bit confusing as it stands
?
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 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.
Mark Dickson SAE Practice m
0780 1917480 w www.xansa.com e mark.dickson@xxxxxxxxx
-----epf-dev-bounces@xxxxxxxxxxx
wrote: -----
To: "'Peter Haumer'"
<phaumer@xxxxxxxxxx>, "'Eclipse Process Framework Project Developers
List'" <epf-dev@xxxxxxxxxxx> From: "Sigurd Hopen"
<shopen@xxxxxxxxxxxxxx> Sent
by: epf-dev-bounces@xxxxxxxxxxx Date: 04/26/2006 11:58PM cc: 'Eclipse
Process Framework Project Developers List' <epf-dev@xxxxxxxxxxx>,
epf-dev-bounces@xxxxxxxxxxx Subject: RE: [epf-dev] Architectural mechanisms -
a bit confusing as it stands
?
Ø
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
_______________________________________________ epf-dev
mailing list epf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/epf-dev
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
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
|