JAERI-Conf 95-021

PB16

Graphical Representation of Objects' States for the PF Linac
Control System
Mejuevl., Abe I. and Nakahara K.
National Laboratory for High Energy Physics
Oho 1-1, Tsukuba, Ibaraki 305, Japan

Abstract
This paper describes our approach forcreating of a graphical representation of thestates of accelerator objects. For every
object which needs to display its state
dynamics we create a chart element. Anychanges in the object state are immediatelyrepresented on the chart of this object. We
use the objects dependencies facility supplied
by Smalltalk to keep track of the objects'
states changes. This allows us to remove anygraphics related features from the Object
Model of the accelerator. Thus, the Object
Model can be developed separately andreused in a number of applications.

1. Introduction
Accelerator control requires a convenientgraphical representation of the present stateof the objects that the accelerator contains.
For instance, there could be the possibility
either to display accelerator sections,indicating the section state, or, a moredetailed representation also includingForaccelerator
section'sobjects.
subsystems, such as the vacuum system andrf system, it would also be convenient torepresent the subsystem hierarchy, including
the subsystem objects in order to gather
information about their states. Usually, inthe present control systems graphicalroutines are mixed with both code and data
for the control, this makes it difficult tochange the graphical part of the system
without reviewing of the control data andcode. In this paper we represent an approachthat divides a visual representation frommodel. The Smalltalk language that we used(VisualWorks)
providesconvenient
possibilities for such division. These areobject
dependencies
concepts
andapplication of this concept for the userinterface creation: MVC (model viewcontroller) concept [1, 2]. Two separate
system part, model and interface, arerepresented below.

2. ModelThe key point concerning the accelerator
domain model is ControlObject class (modelobject class). This generic system class isused for all system objects representation.
The accelerator, subsystem and subsystemobjects are all Contro/Object class instances.
The Contro/Object class defines a number ofproperties described in [4]. However, for thepresent consideration only the "state"property is important. This property
contains symbolic values representing thecurrent object state. The state examples are:"normal", "alarm" and so on. The object
state corresponds to the "state" variable of aContro!Object instance. Since this variable isupdated every time some object value ischanged, it always contains the object statevalid at the moment. Further, an instance ofContro/Object can have a set of dependent
objects. The standard dependencies facility
supplied by Smalltalk guarantees that if the"changed: #aspect" method is invoked forthe object, every dependent receives an"update: #aspect" message. The aspectparameter is used to separate independent
object modifications and to suppress-292-JAERI-Conf 95-021

redundant updates [2]. The Dynamic modelfor the change-upda te method together with
the Object Model for the ObjectChart(explained below) and Contro/Object classes
are represented in Fig. 1. We use Rumbaugh
method notation [3].

3. Interface
The objects' states are represented in thechart (Fig. 3). A chart element contains
fields for the name (top) and state (bottom).
The state field dynamically represents themodel object state. In the simplest case, it
could be only a text string, like "normal",and "running"; however it is possible to map
some states to pictures.

4. Update method
For a graphical representatio n of theaccelerator object' states we create theOhjeetChart class. An ObjectChart instancecorresponds to an accelerator chart element;
it is responsible for the dynamic
representation of some object's state. The
model object reference is contained in the"object" variable of the ObjectChart. To
assign and get this variable we use methods"object:" and "object" correspondingly.
When we set a new object to display bysending the "object:" message, the receiver isregistered as a dependent of this object.
If the model object "state" variable ischanged through the "state:" message, thisobject sends the message "changed: #state"
to itself. That causes the message "update:#state" be sent to object dependent:
ObjectChart. Having received an "update:#state" message the ObjectChart instanceretrieves the state variable value from themodel object which is stored in its "object"variable. After that, ObjectChart draws on
the user terminal picture or text
corresponding to the present model object
state.
This method allows us to remove any
messages responsible for graphics from thedomain model. The domain model can be

developed independently, and multiple
graphical modules representing different
aspects of its state can be easily connected toit. It is also possible to reuse graphicalinterfaces with different models. It is
supposed that this approach is capable ofreducing the system development andmaintenance costs.

5. Conclusions
The method represented above could be
used to display a large variety of control
system aspects. First, it can represent
accelerator subsystems with the "normal" or"alarm" states for every subsystem object.
Also, it is possible to collect information
about states of the accelerator sections. In
this case the state resumes a summary of all
the section objects states.
Although in this paper we allow only one
object connection to an ObjectChart classinstance, in the future we will discuss thepossibility for a multiple objects connection.
With multiple connections the problem ofstates priority appears. Another way toresolve the multiple objects problem is tocreate composite object in the domain model
representing the objects ·aggregation.

6. References[l] An Introduction to Object-Oriented
Programming and Smalltalk; Lewis J.
Pinson, Richard S. Wiener; University ofColorado at Colorado Springs, AddisonWesley, c 1988.
[2] VisualWorks User's Guide; ParcPlace
Systems, c 1994.
[3] Object-oriented modeling and design;
James Rumbaugh [et al.] Englewood Cliffs,
N.J.: Prentice Hall, c 1991.
[4] Application of an Object-Oriented
Analysis for the PF Linac Control SystemDevelopment; Mejuev 1., Abe I. andNakahara K.; Proceedings of the 20thLinear Accelerator Meeting in Japan,
Osaka, 1995, p. 212.

-293-

JAERI-Conf 95-021

7. Figureschange state/state(n ewState)
ObjectChart
displa~ statew
Control Object
state

entry/get ewState~:try/chatged(#state)Itupdate(#sta te).......

update #state)'"

ObjectChart
stateobjectobjectobject:update:Fig. 1

Fig. 2-294---ControiObje ct
state
state
state:
changed: