[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epf-dev] Architectural mechanisms - a bit confusing as itstands ?
|
Hi all,
Since this is my first post to this
team, I'll take the liberty of asking some fundamental questions :)
This whole "architectural mechanisms"
thread seems to be missing a couple of things: a) A definition of "architecture",
b) A definition of "mechanism", c) A definition of "service".
Having been around the block a few times, I know how important it is to
define semantics, and I think it's all-too-easy to make assumptions when
someone uses one of these terms. Let alone use them together :) Just a
suggestion that maybe this initiative should develop a Glossary of terms
if it doesn't already exist. And since I'm a newbie - if a glossary exists
- please point me to it - and apologies :)
For example, what's the difference between
a "service" and an "architectural service"? What makes
it "architectural"? In order to define that, you need to define
what is meant by "architecture" and presumably those characteristics
that make something "architectural". The phrase "architecturally-significant"
has been used in the past.
I've also observed (and I only joined
the mail list last week) that there is also a discussion of "analysis"
and what this means. I copied my thoughts (privately) to some of this team,
but wanted to share them more widely, with a view to moving things forward.
Attached are some thoughts where I've highlighted those things that might
be worth reading (the content is part of a book I'm in the process of putting
together so forgive some of the missing references).
In summary, I think that a) an "architectural
mechanism/service" is just one type of reusable asset that an architect
will concern themselves with and b) the term "analysis" is overloaded
in the industry and needs to be used with caution!
Regards,
Pete
================================
Peter Eeles, MBCS CITP
Executive IT Architect, Technical Staff Member
Rational Brand Architect for UK, Ireland, South Africa
Email: peter.eeles@xxxxxxxxxx
Mobile: +44 (0)7796 331061
Mobex: 264305
=================================
The IBM Rational Edge Live! By Developers for Developers.
For more information on this and other events such as the Rational User
Group visit:
www.ibm.com/uk/news/events/softwaretechnicalbriefings/
Mark.Dickson@xxxxxxxxx
04/05/2006 22:31
|
To
| <chris.armstrong@xxxxxxxxxxxxxxxxx>,
<shopen@xxxxxxxxxxxxxx>, "'Eclipse Process Framework Project
Developers List'" <epf-dev@xxxxxxxxxxx>
|
cc
| Peter Eeles/UK/IBM@IBMGB
|
Subject
| Re: [epf-dev] Architectural mechanisms
- a bit confusing as itstands ? |
|
"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
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
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.
/Sigurd Hopen
2-ProMentor , Norway
+47 90689131
shopen@xxxxxxxxxxxxxx
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
Attachment:
Thoughts.doc
Description: Binary data