[erlang-questions] CBSE anybody

[Ulf Wiger (TN/EAB)]

Joe Armstrong skrev:
> Pardon my ignorance but ...
[...]
> The highest level should be a drag and draw gui thingy to describe the
> interconnection
> between components. UML has a notation for this (it has a notation for
> *everything*) which could be cannibalized.
> 
> 
> Does anybody have experience with this kind of way of building
> software - there seems to be a vast
> literature - I search turned up book titles like
>  -
> UML Components: A Simple Process for Specifying Component-Based
> Software  (Cheesman and Daniels)
> ...

I found this paper from 1999 on using UML for describing
system architecture:

Describing Software Architecture with UML  - Hofmeister, Nord et al.
http://citeseer.ist.psu.edu/cache/papers/cs/15435/http:zSzzSzwww.scr.siemens.comzSzpdfzSzUsingUML-unix.pdf/hofmeister99describing.pdf

A quote from the summary of Hofmeister's paper:

"An important concern we have about using UML to describe
software architecture is that the same notation can have
a wide range of semantics. We use the same basic diagram,
the UML Class/Object diagram to show most of the aspects
of the architecture. We use stereotypes and special symbols
to minimize the confusion between different views.

"The more traditional use of UML is for the design of
implementation classes for a system. We are also concerned
that by using the same notation to describe the software
architecture, we run the risk of further blurring the distinction 
between the architecture and the implementation. This is another
reason to consistently use particular conventions, stereotypes,
and special symbols for these architecture diagrams.

"In summary, we found UML deficient in describing:
• correspondences: A graphical notation is too cumbersome
   for straightforward mappings such as the correspondence
   between elements in different views. This information is
   more efficiently described in a table (e.g.Table 3).
• protocols: The ability to show peer-to-peer communication is
   missing from UML. We used ROOM to describe protocols (e.g.
   Figure 2).
• ports on components: We used nesting to show the relationship
   between ports and components, but this is visually somewhat
   misleading. We would prefer a notation more similar to the
   lollipop notation for the interfaces of a module.
• dynamic aspects of the structure
• a general sequence of activities

"UML worked well for describing:
• the static structure of the architecture
• variability: e.g. the conceptual configuration in Figure 1
   describes the structure of a set of pipelines.
• a particular sequence of activities: e.g. the start-up
   behavior of an Image Pipeline (Figure 6)."


This corresponds well with my own impression of UML, but
a lot has happened in UML 2.0. Does anyone have a good
reference to experiences on how these deficiencies are
addressed by UML 2.0?


Here's a short paper on FMC by Frank Keller:

FMC: An Approach towards Architecture-Centric System Development (2003)
Frank Keller, Siegfried Wendt
http://citeseer.ist.psu.edu/keller03fmc.html

Keller's paper included the following note on model consistency:

"The problem of keeping architecture and design models
in a synchronous state with the “real world” artefacts is
often mentioned. Our experiences show that the low level
design models of the software and the hardware categories
should reflect the current state of the development. Those
models serve the purpose of detailed communication among
the developers or engineers. If they are not aligned with the
sources or the hardware implementation, they do not fulfill
their purpose. This is in contrast to conceptual models on
higher levels of abstraction. Once those models are in place,
they usually do not change drastically over time. Experience
shows that the integrity and consistency of architecture
models can be sufficiently ensured by an appropriate development
process [37]. Nevertheless, a well suited tool support
would help to keep the architectural models up to date."
(pg 9)

This got me thinking: model consistency is often touted
as a very big thing, but most Erlang projects tend to
maintain their models by hand, for lack of a better tool.
If we think that the type of modeling most needed for
Erlang projects is something like FMC, and FMC gurus
claim that this particular type of models are unlikely
to change over time, one might conclude that the current
practice of manually maintaining models for Erlang is not
such a disaster after all... (:

Assuming this is true, the first priority should be to
establish an agreement on how best to describe the
architecture of Erlang programs. We shouldn't be too
worried about round-trip engineering support - at
least not for now.

BR,
Ulf W