"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 ~:|
------------------------------------------------------------------------
*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,
/Sigurd Hopen
2-Pro Mentor, Norway
+47 90689131
shopen@xxxxxxxxxxxxxx <mailto:shopen@xxxxxxxxxxxxxx>
www.2promentor.com <http://www.2promentor.com>
------------------------------------------------------------------------
*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 ?
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
SAE Practice
m 0780 1917480
w www.xansa.com <http://www.xansa.com>
e mark.dickson@xxxxxxxxx <mailto: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.
/Sigurd Hopen
2-ProMentor , Norway
+47 90689131
shopen@xxxxxxxxxxxxxx <mailto:shopen@xxxxxxxxxxxxxx>
www.2promentor.com <http://www.2promentor.com/>
------------------------------------------------------------------------
*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
------------------------------------------------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev