4. The Functional View

The Functional View provides the functional specification of the methods that are to operate within designate containers in the Interface View. The Functional View describes the system using UML notions and notations such as Class Diagrams and State Machine Diagrams. (Cf. figure 4.2) The Functional View allows the designer to model the object-oriented structure of the system and its sequential behaviour only. The concurrent behaviour is specified in the Interface View and realized in the Concurrency View. In order to represent the Functional View, the HRT-UML/RCM tool provides editing capabilities for both Class Diagrams and State Machine Diagrams.

At present, the Functional View can be imported, in XMI format, from a UML model to which the ETH FWProfile [CEPV06] was applied to ensure that the underlying metamodel is compatible with that of HRT-UML/RCM which in turn warrants that the imported model abides by the RCM constraints. In principle any other UML2 Profile which provably ensures the required level of compliance with the RCM metamodel could be used to produce a legal Functional Model.

An RCM-compliant functional model can only express and imply (1) time-free and (2) sequential execution semantics and (3) must make no reliance on actions that may incur blocking semantics at run time.

• The prescription that the functional model semantics shall be time free prohibits the use of
  time-related suspensions (sleep, delay, wait, time-out)
• The prescription that the functional model semantics shall be strictly sequential prohibits the use of constructs which may require the spawning of threads of control, whether directly or indirectly
  
• The prescription that the functional model shall not include constructs that may incur blocking semantics at run time prohibits the use of invocations which require interventions from outside the application space (dynamic memory allocation is an action that can only be performed outside the application space and, as such, it is forbidden in the RCM functional model).
  

The Functional View supports the modeling of classes which define operations and attributes with the proper visibility and also interfaces and realization relations between classes and provided interfaces (PI).
An attribute for a given class can also be typed with an interface or with another class: in HRT-UML/RCM this is currently the way to model required services (i.e. the required interfaces, RI) for a given functional class. The PI specifies what the component may do for the environment. The RI specifies what the component may need from the environment to carry out its own tasks.

Figure 4.2 is a schema of a class used in the Functional View. As part of functional modeling, the designer also needs to specify how many times a provided method uses a required method (a worst-case bound is given when multiple execution paths are possible). This information is crucial for system analysis.

The Distributed Toy Example: Functional View

Figure 4.3 is the representation of the original toy example in the Functional View, the next figure shows the Dispatcher component we use instead of the original one.

POS

POS is a data resource shared by two processes: GNC and TMTC. POS exhibits three service methods, Read, Write and Read_X_Write, each of which must warrant that its caller shall hold mutually exclusive access on the functional state of the component. Read_X_Write invokes  Compute on the RI typed Computer just once per execution. As we shall see, this solution successfully captures the scenario depicted in the original problem specification, but it fails to be a sound object-oriented design in the way it introduces unneeded mutual dependency between POS and GNC. A simpler design would not have POS depend on Computer, in that POS is a mere data wrapper. The role of GNC, as specified in the original problem, is to read the value, compute some adjustments and eventually write the computed value on POS: there is no obvious need for POS to actively take part into this process. This unusual design is part of the solution currently provided in HRT-UML/RCM to obtain transactional access control. We shall return to this issue in the Interface View section, while a more detailed discussion is provided in appendix 1.

GNC

GNC performs a feedback-control loop on POS, by first reading the current value, computing any necessary adjustments and then updating the initial value accordingly. In order to overcome the potential interaction between the two distinct update operations on POS, GNC accesses to POS with transactional access rights. As a result, GNC exhibits two operations: one default operation, which is periodically executed, and a public Compute operation, which is used to perform the local adjustment computation on the value read from POS. The problem specification requires that the default operation should be granted transactional access to the POS. Consequently, GNC exhibits one RI typed Reader_X_Writer. When default operation GNC_op() is executed, it invokes RI Read_X_Write operation exactly once.

TMTC

TMTC either writes to POS the data values uploaded from ground by a dedicated TC or sends to PRO the "BOOST_ORDER" command sent from ground by a TC. TMTC is then functionally decomposed into:

• a Dispatcher element, with a single Dispatch operation, which receives a TC, checks its contents and dispatches it to the appropriate destination for servicing via one of the Send operations included in its RI. If the TC is an update on POS, the dispatcher invokes a Send operation typed Write_Sender, else it chooses one of the three Boost_Order operations on the RI typed PRO_Boost, depending on the physical location of the destination PRO component specified in the incoming TC.

• a Write_Sender element which performs the write on POS via a Write operation on the RI typed POS_Writer

PRO

PRO is a process that periodically executes its default operation (PRO_op in figure). PRO also provides the Boost_Order service.

Remarks to Figures 4.3 and 4.4

1. There are no arrows for required interfaces since the methodology currently provides no support for them.

2. For the sake of simplicity, we directly show some primitive types.

Open Issues

Visibility attributes over elementary interfaces (or groups thereof), which range: public (to any user); private (to the container which exposes that interface); and restricted (to a specific set of users), are currently only specified in the Interface View. The setting of visibility attributes in the Functional View is only limited to the classical UML semantics (for example, the editor forbids that an operation of an object X which is marked as "private" may appear as "required" in the specification of another object distinct from X). We are currently investigating how the expected finer-grained level of support could be provided.