Data, Process and Cluster Classes

Similar to a suggestion in [130], SHE distinguishes two types of resources for hard- ware/software systems. Active resources are components of a system that may take the initiative to perform certain functionality without involving any other resource. Active resources can often be arranged according to a hierarchical structure. For example, a system may incorporate several concurrently operating interconnected components that are composed of smaller concurrent units, etcetera. Passive re-

sources, on the other hand, present information or data that is generated, exchanged,

interpreted, modified or consumed by other resources. Figure 4.2 depicts5_examples

of the classes that the SHE method distinguishes to specify different resource types.

Na m e Na m e Na m e At tri bu te s M et ho ds M es sa ge s At tri bu te s At tri bu te s M et ho ds M es sa ge s < < d a t a > > P a c k e t < < i n s t a n c e v a r i a b l e s > > D e s t i n a t i o n : I n t e g e r S i z e : I n t e g e r < < m e t h o d s > > g e t D e s t i n a t i o n ( ) : I n t e g e r s e t S i z e ( S : I n t e g e r ) : P a c k e t < < p r o c e s s > > S w i t c h _ C o r e < < i n s t a n t i a t i o n p a r a m e t e r s > > S w i t c h D e l a y : R e a l < < i n s t a n c e v a r i a b l e s > > P : P a c k e t < < m e t h o d s > > I n i t ( ) ( ) T r a n s f e r P a c k e t ( I D : I n t e g e r ) ( ) < < i n i t i a l m e t h o d c a l l > > I n i t ( ) ( ) < < m e s s a g e s > > I n ? P a c k e t ( P a c k e t ) O u t ! P a c k e t ( P a c k e t ) < < c l u s t e r > > I n t e r n e t _ R o u t e r < < i n s t a n t i a t i o n p a r a m e t e r s > > S w i t c h D e l a y : R e a l M es sa ge s < < m e s s a g e s > >

Figure 4.2: Illustration of the class symbols for SHE.

Data Classes SHE offers data objects, which are instances of data classes, for mod- elling passive resources. Figure 4.2 shows that the class symbol for data classes consists of three compartments. The stereotype<<data>>in the name compart-

ment denotes that a class is a data class. The attributes of a data class are specified as instance variables, which is indicated by stereotyping the corresponding compart- ment with<<instance variables>>. The behavior of data objects is described

with (data)6_{methods. Execution of such a method is initiated by sending an equally}

named message to the data object. Upon completion of executing the method, the result of some calculation or the data object itself is returned. The class symbol in- cludes the headers of all methods (with the declaration of input parameters and the result type) in the methods/messages7_{compartment, which is stereotyped with}

<<methods>>. The header of the primitive methods for the predefined data classes

Object,Boolean,Integer,Real,String,Nil,Array,FileIn,FileOutand

RandomGenerator(see appendix B) are preceded by stereotype<<primitive>>.

5_{The labelled arrows are not a part of the actual class symbols but indicate the compartment names.} 6_{Prefixing methods by the word data or process is omitted when this is clear from the context.} 7_{Notice that UML uses the term operations compartment. A different terminology is introduced for SHE}

Data classes must inherit from a single other data class (except for data classObject

from which all other data classes eventually inherit). In class diagrams8_{, such a rela-}

tion is drawn as a generalisation/specialisation relation using a triangle at the border of the superclass. Based on the stereotypes defined for the class symbol and the in- heritance relation, POOSL skeleton code can be derived easily for any data class (this may be automated by a future tool). The remainder of formalising a data class with POOSL then concerns defining the actual behaviour of all (non-primitive) methods.

Process Classes To model the basic (non-composite) active resources of hardware/ software systems, SHE provides process objects or processes. The precise difference between basic and composite active resources depends on the modelling approach. Sketches of possible system architectures drawn during brainstorm sessions and dis- cussions on concepts for realising the system reflect the (hierarchical) way in which a system is composed of components. A suitable modelling approach is often to define process classes for those active resource that are drawn as non-subdivided blocks in such sketches. Notice that these components may still expose concurrent behaviour. As shown in figure 4.2, the name compartment of the class symbol for process classes is stereotyped with<<process>>. The attributes of process classes include instance variables and instantiation parameters. The difference is that instantiation parame-

ters allow parameterising the behavior of a process at instantiation. The attributes compartment in the class symbol separates the instance variables from the instan- tiation parameters with a dashed line and stereotypes the sub-compartments with

<<instantiation parameters>>and<<instance variables>>.

The behaviour of processes is described with (process) methods, which may include the specification of sending or receiving messages (see also appendix B). The start behavior of a process is defined by the initial method call. The methods compart- ment of the class symbol includes the specification of both the methods and the initial method call. They are separated from each other by a dashed line and the sub-compartments are stereotyped with<<methods>>and <<initial method

call>>respectively. The<<methods>>sub-compartment includes the headers of

all methods (with the declaration of input and output parameters). The<<initial

method call>>sub-compartment specifies the actual call of one of those methods.

To describe the services available from classes, UML defines two kinds of interfaces.

Provided interfaces describe services offered by a class, while required interfaces denote

services that must be provided by other classes in order to operate properly [26]. A set of provided and required interfaces can be grouped into a port. In the UML profile for SHE, the UML concept of ports is matched to the concept of the ports through which processes (or clusters) may communicate messages9_{. Correspondingly, re-}

quired interfaces are related to messages that processes (or clusters) can send, while provided interfaces are related to messages that can be received. An important dif- ference between interfaces and messages is that messages are not directly coupled to process methods (services or operations), see also appendix B. A separate com- partment in the class symbol, which is stereotyped with<<messages>>, specifies

8_{Class diagrams are sometimes also called static structure diagrams.}

9_{Consequently, services provided or required by data classes are not expressible with ports and inter-}

all messages that can be sent or received. Such a specification includes the actually10

involved port, the symbol ! or ? for message send (required interface) and message receive (provided interface) respectively, the message name and parameters. Process classes may have an inheritance relation with a single other process class. In class diagrams, this is drawn as a generalisation/specialisation relation. Based on the stereotypes defined for the class symbol and the inheritance relation, POOSL skeleton code can be derived easily for any process class (this may be automated by a future tool). Notice that the information in the messages compartment of the class symbol suffices for deriving both the port interface and message interface in POOSL (see also appendix B). Hence, the remainder of formalising a process class concerns defin- ing the actual behaviour of the methods in the<<methods>>sub-compartment.

Cluster Classes To model composite active resources, SHE provides clusters. Clus-

ters are instances of cluster classes and group a set of processes and clusters (of other

cluster classes). Similar ways of grouping are also allowed in UML, but an impor- tant restriction is that a cluster does not extend the behaviour of its constituents11_{. In}

addition, cluster classes cannot inherit from any other class. The need for defining a cluster class emerges for example from aggregation or composition relations in class diagrams between classes that represent active resources. Figure 4.2 shows the use of stereotype<<cluster>>to denote that a class is a cluster class. The attributes

of cluster classes include only instantiation parameters, which are indicated in the corresponding compartment with stereotype<<instantiation parameters>>.

Messages of encapsulated processes (or clusters) that may pass the boundary of an instance of the cluster class through its ports are specified in the messages compart- ment, which is stereotyped with<<messages>>. The information in the message

compartment suffices for deriving both the port interface and message interface in POOSL. The remainder of defining a cluster class involves specifying the composi- tion of processes and clusters using instance structure diagrams, see section 4.2.2.