OOPSLA 2001 Workshop
Representing Software Architectures -- Call for Papers
WELCOME
Content Updated on July 16, 2001
About this Workshop:
This
workshop invites experienced software architects to exchange ideas about
representing architectures. The goal is
to share useful techniques and insights that people have used to convey architectural content.
Background:
The
workshop organizers view Software Architecture as dealing with the production and
consumption of summary information. The
question is – what techniques have worked best for conveying the type of summary information
that Software Architects use? The UML
is frequently exploited for this purpose but it was initially
conceived to model analysis and design. Our experience using analysis and design diagrams
for Software Architecture often leaves us wanting for something more general. Perhaps others have had the same experience?
The
inspiration behind this workshop was a Birds-Of-a-Feather (BOF) session at last
year’s OOPSLA'00. The goal of the BOF was
to get a couple of dozen seasoned architects in a room to swap stories about how they
represent software architecture. Some
BOF attendees were driven to follow standard notations and tools;
while others were strictly pragmatic about communicating clearly and
keeping their ship date in sight. At the
end of the evening there was very little consensus, but almost everyone had a great time.
Unfortunately,
like most conversations about Software Architecture, the BOF had trouble getting
past
the old “what is Architecture”
discussion and on to more practical subjects like how to represent architectural
content.
Goal for this Workshop:
The primary goal for this workshop is to end with at least five unusual architectural representations that are "essential" to certain situations. We want to document what those representations are, what they communicate, to whom they are intended, and the situation(s) they address.
The
plan is to begin discussions at a point beyond
the mere “what is Architecture” (we don’t need to
rehash that again) and to focus on how best to represent
architectural content. If the workshop
produces at least five essential representations and the discussion topics cover lessons learned, methods,
tricks, and wisdoms about representing architecture then the day will be a
success.
Contents of Position Paper:
We are asking prospective attendees to write a short two-page position paper – the contents of which will determine admission to the workshop.
Position papers will be used for
these purposes:
1) To ensure this workshop
doesn’t get stuck in a discussion about “what
is Architecture”
2) To initialize points of
discussion that will help us move things quickly
3) To have "good"
prepared material for
our poster presentation (as opposed to drawing everything with a magic marker
on the day of the workshop)
We are screening for two categories of insight. First, we are screening for examples of non-obvious types of architectural content for which it would be useful to have representations (regardless of whether such representation exists). Second, we are looking for ways of representing architectural content, where the content is clearly valuable but where there are no usual or customary ways of representing it; or the methods available produce an unacceptable representation.
What you should submit:
Position papers should be approximately two pages (ordinary font size, 1-inch margins, you know the drill). The subject is “Representing Software Architecture”. The two pages is mostly for explanation, if you have graphical representations please supplement your paper with example diagrams and such.
You are welcome to write more if
you have time – but two pages plus diagrams is sufficient for our purposes. Remember that at the conclusion of the workshop we
will “borrow” from everyone’s position papers to create a poster for the OOPSLA
poster session, so the more material the better.
Checklist
of stuff that must be included in a submission:
1) Your name (first and last)
2) Your one-page position paper
on “Representing Software Architecture”
3) Any copyrights or trademarks
that we should be aware of
4) Permission to distribute
your paper to other attendees (not to the conference at large)
5) Your biographical
information (summary of work experience, credentials, etc)
6) Your country of residence (if not the
7) Your E-Mail address and
other contact information (please include a phone number if possible)
After
submitting your paper, the organizers might contact you and ask for revisions
to clarify certain points in your paper.
If this happens we ask that you please help us, it will advance your chances
of acceptance and will make the workshop higher quality.
Submission Deadline:
The deadline for submission is August 17, 2001. If you must submit after that date, please contact the organizers to make special arrangements.
Submission Media:
Please
send your position paper as one of the following:
- Microsoft Word Document
(preferred)
- HTML File
- Adobe Acrobat (PDF)
file
- Postscript file
- Raw ASCII Text file
- Paper (if sent
snail-mail)
**** PLEASE DO NOT SEND
"STAR OFFICE" OR
"INTERLEAF"
FILES ****
Where to Submit:
Please
send your position paper to following e-mail address:
OR
you can send a paper version to:
Sphere
of Influence, OOPSLA Position Paper
Conference Registration:
All participants in a workshop are expected to register for at least the day of the conference on which the workshop is to be held.
Examples
and other (hopefully) Inspirational Material
These are merely provided as
examples. We welcome you to expand on,
add to, or trample over the items listed here.
This is not meant to be inclusive (not by a mile) – we included them
just for fun.
Some hard to convey architectural concepts:
2)
Middleware or protocol used to connect logical
subsystems
3)
Dependencies from Physical entities to Logical Entities
(components to logical packages)
4) Dependencies that are “allowed” but which do not necessarily exist in the as-built system
5)
Dependencies that are explicitly disallowed
6) Intermediate stages of implementation – showing things that will change or move more mature releases
7)
The idea of aggregation for anything beyond UML Classes
(such as between components, processes, logical packages). For
example, this is needed to show that a subsystem is “reused” as an
implementation detail inside multiple components or inside multiple parent
subsystems
8)
Mapping from semantic interfaces to logical interfaces
and then to realizations
9)
Dependencies to (or from) semantic interfaces
10) Middleware
/ protocols supported by a component
11) Rough
Order of Magnitude (ROM) of a component, package, framework, subsystem, etc.
12) Components
and packages in an architectural spike
13) Sizing
needs for middleware connections (early)
14) Sizing
needs for database (early)
15) Executable
threading within a component
16) Technologies
used to implement logical (and physical) software abstractions
17) Uses
of Commercial-Off-The-Shelf (COTS) products/technologies
18) Events
or messages flowing through or controlling logical abstractions
19) Dynamic
binding (double-dispatch, etc.)
Goals
of an architectural representation:
These are provided to
stimulate thought. Even where standard
representations are available, sometimes the intended audience (or the purpose
of) a representation makes us wish we had a different way of conveying a
concept.
1) Summary Charts/Briefing Charts
2) Preservation of key decisions or agreements
3) Getting a handle on what needs to come next
4) Size/Cost estimations
5) Defining Scope/Boundaries
6) Drawing partitions for separation of concerns (realizing change-cases)
7) Constraining code production efforts
8) Explaining the static structure of a system – logical and physical
9) Explaining the dynamic behavior of a system
10) Establishing dependency rules (what can or cannot be dependent on what)
11) Establishment of a Product Development Plan (PDP)…Using dependencies to define the order of development and types of resources (human and machine) required
12) Assessing cohesion between logical (static), physical (static), and dynamic aspects of a system
13) Assessment of any other aspect: technologies, interfaces, programming languages, risks
Types of stakeholders:
Usually a representation is specific to the audience / consumer. Who are the consumers of architectural content? We have started a list. Please add to or remove from this list.
-
Yourself (the architect + any deputies)
-
Program Managers
-
Line Managers
-
Ordinary Designers + Programmers
-
Rock Star Designers + Programmers
-
Database Developers
-
Software Engineers
-
Analysts / Systems Engineers
-
Network Engineers
-
Testers
-
Daily build coordinator
-
Configuration management tool-smith
-
Modeling tool-smith
-
IT administrator (person who installs HW, SW, and keeps printers going)
-
Non-Technical Customers
-
Customers’ technical advisor
-
Cookie Monster paying customer
-
End users
-
End user’s manager
-
Administrative User
-
Administrative user’s manager
-
Business partners
-
External financial stakeholders
-
Executive Management
-
Peers (the OOPSLA crowd)
-
Marketing / Sales
-
Politicians (local, state, federal)
-
Your spouse
-
Your shrink
One of the workshop organizers put it this way, “…before I spend time drawing a diagram or preparing a document I ask myself why? Who is going to read it? Me or someone else? What concept am I trying to preserve or communicate with this? Many times I stop there.”