Hello,

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 OnDiskBlackboard.

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.pdf, 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.

Regards,

Rafael Hiriart