Some UML diagrams about OPUS system.

From: Rafael Hiriart (
Date: Wed Nov 06 2002 - 07:34:35 MST


I draw some UML diagrams describing some concepts about OPUS
architecture. The diagrams are drawn from a conceptual perspective.

In OO design there are three perspectives: conceptual, specification and
implementation. Let me quote an explanation from UML Distilled: A Brief
Guide to the Standard Object Modeling Language, Second Edition, by
Martin Fowler, Kendall Scott.

> *
> *Conceptual.* If you take the conceptual perspective, you draw a
> diagram that represents the concepts in the domain under study.
> These concepts will naturally relate to the classes that
> implement them, but there is often no direct mapping. Indeed, a
> conceptual model should be drawn with little or no regard for
> the software that might implement it, so it can be considered
> language-independent. (Cook and Daniels call this the essential
> perspective.)
> *
> *Specification.* Now we are looking at software, but we are
> looking at the interfaces of the software, not the
> implementation. Object-oriented development puts a great
> emphasis on the difference between interface and implementation,
> but this is often overlooked in practice because the notion of
> class in an OO language combines both interface and
> implementation. This is a shame, because the key to effective OO
> programming is to program to a class's interface rather than to
> its implementation. There is a good discussion of this in the
> first chapter of Gamma, Helm, Johnson, and Vlissides (1995). You
> often hear the word "type" used to talk about an interface of a
> class; a type can have many classes that implement it, and a
> class can implement many types.
> *
> *Implementation.* In this view, we really do have classes and we
> are laying the implementation bare. This is probably the
> perspective used most often, but in many ways the specification
> perspective is often a better one to take.
My purpose is to introduce UML so we can begin modelling with it, if you
find this tool useful.

I will explain the diagrams. You would want to open or print them to
refer to them while reading the following description.

The diagram OPUS_servers.pdf shows a component diagram. The rectangles
with two boxes in the left side are "components". A component represents
a physical module of code. Usually they are shown contained in "nodes",
or hardware components. I am not showing the nodes in this diagram. The
rectangles with a folded corner are just annotations or commentaries.

The three servers of the OPUS system are shown as components:
opus_env_server, opus_event_service and opus_bb_server. Contained in the
component opus_bb_server I included some classes: ObsBlackboard,
ProcBlackboard, CacheManager, Executor and Logger. Additionally I
represented an "interface", the OPUS_API_Interface (or OAPI in OPUS
documentation). The Process Java Manager and the Observation Java
Manager depends of the OAPI (if the interface change, the Managers will
have to change). They depend too of the Java Virtual Machine.

Some of the classes shown in this diagram appear in the class diagrams
OPUS_blackboards.pdf and OPUS_pipeline.pdf. In OPUS_blackboards.pdf it
is possible to see two kinds of blackboards: CacheBlackboard and
OnDiskBlackboard. If OPUS is running in CORBA mode, periodically, the
CacheManager copies the contents of the CacheBlackboard to the

Hanging from the CacheBlackboard class there are two inherited classes:
ObsBlackboard and ProcBlackboard, the Observation Blackboard and Process
Blackboard. (Inheritance is represented by the line with an empty
arrow.) The Observation Blackboard is composed (composition is
represented by the line with a filled rombo) by ObsStatusEntry. In this
class it is possible to see the attributes of an Observation Status
Entry. The same can be seen for the ProcBlackboard: it is composed by
ProcStatusEntry objects.

The On-disk classes are mirror of the cache classes, but the entries are
just files, and the attributes are included as part of the file name
(but this is an implemmentation issue.)

The OPUS_pipeline.pdf diagram shows other objects of the OPUS
architecture. A Pipeline is composed by Process objects and is
associated (a simple line) with a Path (a set of directories) and an
Executor. The Executor is associated with the Process objects that it
controls. Processes (or modules) are configured by Process Resource
Files and Paths are configured by Path Files. It is possible to inherit
two different kinds of processes: External Polling Tasks and Internal
Polling Task. External Polling Tasks are external task, like IRAF
scripts, shell scripts or independent executables. Internal Polling
Tasks depends of OAPI to work, i. e., they use the OPUS API Interface
(not shown here). Depending of the triggers, the Extenal Polling Tasks
can be subclassed in File Triggered Tasks, OSF Triggered Tasks and Timer
Triggered Tasks.

The last diagram, OPUS_osf_trigger, shows a sequence diagram where I
tried to explain the way a OSFTrigTask gets called. It is sort of an
implemmentation issue, so to have a really accurate representation I
will have to see the code, but still is useful to see the idea and
introduce more notation. Horizontally in the top of the diagram you can
see some objects: Executor, OPUS_API_Interface, ObsBlackboard,
ObsStatusEntry and ProcBlackboard. Hanging from these objects there are
"timelines". OSF triggers run tasks based on some condition in the
STATUS attribute of ObsStatusEntry. So, the Executor calls the
OPUS_API_Interface, who calls the ObsBlackboard, who iterates through
the ObservationStatusEntry objects and if the condition is accomplish,
the ProcBlackboard is updated, a Unix Process is created (using SSH),
who return an status. Then the blackboards are updated.


Rafael Hiriart

[PDF attachments removed. See Pipeline web site.]

This archive was generated by hypermail 2.1.4 : Thu Nov 14 2002 - 12:24:24 MST