Øystein Haugen & Birger Møller-Pedersen
Ericsson Research NorARC - Applied Research Center, Ericsson Norway
JavaFrame is a Modelling Development Kit that aims to improve the dependability of large complex real-time systems implemented in Java. It is argued that using JavaFrame will also make the resulting system more maintainable through the independence of system parts, and that producing a Java system with JavaFrame will be more efficient than traditional approaches.
Areas: Large complex systems, Real-time, Java, UML
Contact:
Dr. Oystein Haugen
Ericsson Research NorARC
P.O. Box 34,
N-1375 Billingstad,
Norway
Tel: +47 66 84 23 46
Fax: +47 66 84 19 15
Mob: +47 913 90 914
E-mail: oystein.haugen@ericsson.no
Web: http://eto.ericsson.se/org/i_r
Support for the modelling of large , complex (and especially real-time ) systems has recently attracted much attention. It is generally agreed that UML does not have adequate mechanisms. Projects using UML
[7] therefore do not rely on UML for modelling the overall system structure. They use UML for object modelling (with classes and associations) and for use case/interaction modelling, while system structure is modelled by non-standard box and arrow diagrams.
Some languages and tools have adequate mechanism. If C++ is the preferred (or only) implementation language, the ROOM language supported by RoseRT 1 (as a UML profile 2 sometimes referred to as UML-
RT) is an option. If the modelling should be independent of implementation language, then SDL [5] may be the answer. SDL has a formalised concept of objects consisting of (connected) objects, also covering the special case of system structuring, simply by regarding systems and subsystems as just (large) objects. While
SDL originally had flat state machines, ROOM combined the idea of system object structuring mechanism of
SDL with Statecharts.
1
See information on RoseRT on http://www.rational.com/
2
A UML profile in an adaptation of UML for a specific purpose. "UML-RT" is a proprietary profile for Rational's RoseRT tool.
1

2
In our project situation, the use of Java [4] as an implementation language is given. The use of UML is also given, but hampered by lack of structuring mechanisms and lack of Java code generation. SDL was also considered, but real Java code generation is some time ahead. TogetherJ 3 (a UML-graphical Java) was not right either - the solution is not just graphical Java. Even though Java is superior to C++ in many respects, it is still possible to do things wrong in Java, especially when it comes to handling of threads. The modelling support should enforce disciplined use of Java, not allow all styles of Java programming. The situation in software that we examined was that bad structuring of the system made inclusion of new functionality increasingly difficult until it became virtually impossible. Parts of the system were too interdependent and there was no overall, updated model of the implemented system. The frequent, but unpredictable execution of the Java Garbage Collector was also a source of uncertainty of the performance.
In order to get the system structure right, it must be possible to model the system structure , preferably in a language independent way and in a way that makes it possible to analyse it, but at least in a way that makes it possible to discuss architectural issues independently of low level implementation issues.
On the other hand, implementation must be done in Java. Designers tend to believe in only the source. In order to have an updated model of the structure of the system, the model must be reflected in the source.
No modelling language or tool supports this. SDL and ROOM (RoseRT) support some of the modelling needs, but they have no Java code generation, and when they eventually do, there may still be problems with round-trip engineering.
Our answer to this is a framework for modelling in Java – JavaFrame. With this framework it is possible to apply modelling techniques and still work in Java. The Java source and the model have a one-to-one relationship. The framework provides classes of well-proven modelling concepts, and by using these, instead of just programming in plain Java, the abstraction level is raised.
JavaFrame can be viewed in two different ways: as an advanced API 4 or as a specialised language with support for modelling concepts.
The API view is indicated in Figure 1 . JavaFrame is a framework of classes on top of Java. The classes provide both the modelling concepts and the implementation of basic mechanisms (run-time system, RTS) in terms of classes. JavaFrame applications are made by using the JavaFrame classes in combination with userdefined classes in standard Java. Typically, applications define subclasses of the concept classes and create objects from these.
JavaFrame
Application
JavaFrame
Application
JavaFrame
Application
JavaFrame concept classes and run time system
Java
Figure 1.
JavaFrame – Classes and Run-time System
The specialised language view is indicated in Figure 2 . JavaFrame provides modelling concepts in between the low-level (compared to JavaFrame) mechanisms of Java and the modelling concepts as they would have been in a JavaFrame specialised UML. Using standard UML or a JavaFrame profile (or simply the UML-RT profile), the models have to be transformed to Java according to JavaFrame. With a modelling
3
See also http://www.togethersoft.com/
4
API = Application Programmer Interface

3 language specific for JavaFrame (but based upon the elements of UML) it would be possible to have a oneto-one mapping between graphical models and the JavaFrame source.
UML
UML
JavaFrame transformation
JavaFrame
Java transformation
JavaFrame
Java
JavaFrame
UML mapping
JavaFrame
Java modeling by programming
JavaFrame
Java
Figure 2.
JavaFrame – alternative modelling notations
The project includes the definition of a JavaFrame UML Profile and an experiment to use UML-RT as supported by RoseRT for the graphical modelling. The ultimate graphical modelling support for JavaFrame would not only allow for a one-to-one mapping, but also allow for a distinction between which Java classes should be presented graphically and not. A graphical view generated uncritically from all Java classes of a
JavaFrame application would not help the user. Obviously the classes made according to the modelling concepts of JavaFrame like e.g. Composites should have a graphical representation, but not classes introduced only for implementation purposes. In addition to the concept classes, JavaFrame applications will also contain “classes of data objects”, that are important for the modelling and therefore should have a graphical representation.
JavaFrame is based upon a fairly small number of well-proven modelling concepts. These form the backbone of JavaFrame models. The JavaFrame concepts must be used exactly as specified in the
JavaFrame modelling guidelines. Detailed programming of (say) algorithms is done in general Java without many restrictions. We are, however, very cautious with introducing auxiliary program threads as explained later in this paper.
JavaFrame is built upon the experience that large, complex real time systems are best modelled in terms of Active Objects that interact asynchronously through messages. The behaviour of an Active Object is therefore described by either a state machine or by a structure of interacting state machines. Asynchronous message passing has advantages over synchronized remote method calls as the involved parties may handle the messages in their own speed, and that the interacting objects may all continue concurrently as long as the protocol allows it.
In order for the notion of Active Objects to scale, an Active Object may also be a Composite, i.e. an
Active Object that has a substructure of Active Objects. The system as a whole is just the outermost
Composite. The conceptual model is given in Figure 3

4
Composite
ActiveObject
StateMachine
Mediator
Figure 3.
Class diagram for the JavaFrame concepts
ActiveObject is an abstract class representing the notion of something that acts on its own, sending and receiving messages through its associated mediators.
From a communication perspective an Active Object appears the same regardless of whether it is a
Composite or a single StateMachine when seen from the outside. A message is passed to a mediator associated with the Active Object and then it is up to the internal structure and behavior of the Active Object that it performs the appropriate operations.
Common for the modelling concepts of JavaFrame is that they are defined as Java classes. Applications can thereby be specified to have several Composite objects of the same class. More interesting is that specialisation applies to classes of Active objects, Composites and even Statemachines. The structure of a
Composite superclass is thereby inherited, and the states and transitions of a Statemachine super class are inherited. While modelling languages like UML, ROOM and SDL may support this differently (if at all),
JavaFrame gets this directly from Java. The experience on object oriented modelling with classes and subclasses in general in Java can be directly used also for the modelling on top of JavaFrame.
The State Machines of JavaFrame are re-entrant meaning that many state machines refer to the same state machine structure. The States are separate objects with the transitions implemented in a method with the triggering message as parameter. The last statement of this method will bring the state machine into a new state. The State concept in JavaFrame contains a set of primitives used to describe the insides of the transitions such as outputting a message or saving a message. The advantage of this separate state structure is that the state machine behavior may be updated and modified on the fly and that all state machines of the same kind will be updated at the same time. Space is also saved when the state structure is reentrant.
JavaFrame state machines also have Composite States. Composite States are states that have internal states. When entering a Composite State, the model may specify an explicit or implicit entry point that will define what inner state will be reached. A Composite State may be exited through exit points to reach states on enclosing levels.
Each state machine has an explicit queue of messages. These queues are managed by the Scheduler which is associated in a one-one manner with a Java Thread. The scheduling regime is that for every time a given
State Machine has consumed a maximum number (given for each state machine) of messages before the
Scheduler continues to the next State Machine in a Round-Robin fashion. Thus within one Scheduler the input queues are fair.
Large and complex software made in large and complex software projects can only be made simpler if the different parts of the software appear independent of each other. Thus different subgroups of engineers may develop different software parts without intimate knowledge of each other or each other's software.
Subsequently the maintenance of these independent parts may also proceed independently.
In a JavaFrame environment, independence between Active Objects is achieved through the introduction of Mediators. Mediators are objects that represent the interaction interfaces between Active Objects. Each
State Machine will address only the innermost mediators. These mediators are in turn associated with other

5 mediators of Composites to form the system architecture. The simplest mediators contain only a reference to another mediator (or finally to a State Machine). More advanced mediators include routing or even message translation.
Mediators minimize the need for the designer of one part of the system to have knowledge of completely different parts of the system. This will make the individual Active Objects more robust, and it will ease local changes.
Mediators come in different specializations as shown in Figure 4.
Mediator
RouterMediat or MulticastMediator ProtocolMediator EdgeMediator
Figure 4 Different flavors of Mediators
RouterMediators will use extra information, from the message and from associated data bases, to route the message to the appropriate next mediator.
MulticastMediators will replicate the message and send the replicas to a number of other mediators.
ProtocolMediators hide lower levels of protocols. The point of this is that while the system can be simulated on a very application-oriented level, the actual implementation may be dependent upon the actual communication environment. The use of ProtocolMediators will make it possible to make the application totally independent of the communication environment. Changes in the underlying platform will only affect the few ProtocolMediators while the application system will not need any reprogramming.
EdgeMediators are used to separate the JavaFrame system from other systems and threads.
EdgeMediators are used to exchange information between the JavaFrame system and its exterior.
In Figure 5 we see an example of a JavaFrame architecture that we shall go through in some detail to explain the features of the different parts.
5
5
The model is shown in a UML-like (or rather RoseRT-like) collaboration diagram manner even though Powerpoint has been used here.

6
ServiceFrame acdsystem
BEp:H323UserEp
AEp:H323UserEp
*
AllUsers
1
U
UserB
UserA
1 1 m 1 1
Aagt :UserAgent
*
* 1 1
D
*
* 1 1
R
*
*
*
*
E
1 1 m 1
1 1 m 1
1
*
P
PlayerH323
1 1 m 1 *
1
*
*
*
Figure 5 Example JavaFrame architecture
Firstly we notice that every ActiveObject is connected to other ActiveObjects through the Mediators on its edges. The inwards Mediators are shown in grey, while the outwards Mediators are white.
From the left we see the StateMachines AEp and BEp - both instances of the State Machine extension
H323UserEp . The leftmost inward Mediator must select which H323UserEp to send the incoming message and therefore this Mediator is a RouterMediator basing its decision on the database D . From the
H323UserEp the messages are forwarded to the Composite AllUsers . The inward Mediators for AllUsers will have to decide which User it should forward the message to and this is again done by a RouterMediator using the data from database U . Within the User composites there are both simple Mediators and
RouterMediators in the communication between the inner StateMachines Aagt and PlayerH323s . Routing is here based on database P . Finally the results from the handling within AllUsers are forwarded towards the
H323UserEps by routing dependent upon database E .
Assume now that we found out that the behavior of the User could be defined by one single StateMachine and not a structure of a UserAgent and a set of Players . Then solely the User would be redefined. Instead of a Composite, it would now be a StateMachine. Since the mediators of the User objects are not affected, all the rest of our system would remain unchanged. Not a single line of code there would be affected.
The change could even in principle have occurred during run-time.
In addition to the modelling concepts described above and their support by a run-time system, JavaFrame contains the following components:
§ Modelling Guidelines . Strategies for how to model the systems. It is assumed that users of JavaFrame primarily are designing and programming in Java. The packaging of JavaFrame is like the packaging of any Java API. JavaFrame is used by generating objects of and defining subclasses of its predefined classes. Although not essential for the use of JavaFrame, it is also assumed that UML will be used for graphical analysis modelling. We have above used Class- and Collaboration Diagrams of UML and

o n i t c a i f s i c p e
7 are considering UML-RT as supported by RoseRT. Sequence Diagrams or MSCs [6] will be used to define behavioral properties of the system.
§
. JavaFrame models are ultimately really programmed in Java.
Modelling may be in UML/UML-RT, but it may also be in Java, simply leaving out the details of e.g.
transitions. JavaFrame defines patterns for how to make models of Active Objects, Composites,
Mediators, and Statemachines. These patterns have to be followed in order for the JavaFrame models to work.
§ . The Java design uses concepts that will make automatic reasoning theoretically possible. Currently the JavaFrame concepts are supported by a Trace system. The trace system makes it possible to trace the execution of the various state machines of a JavaFrame model. The trace subsystem comes for free without extra programming.
Object Model subscA subscB
Property Model subscA hook off call reply subscB i s d e g n class SubscA extends StateMachine
{ SubscB subscB;
int stateIdle, stateBusy, ...;
}; class Idle extends State
{ int exec(Message msg)
{ ..... };
};
Trace
Process State Message Next subscA Idle hookoff Wait subscB...Idle...call....Conv
subscA...Wait...reply...Conv
...
Figure 6.
Use of JavaFrame
To reap the maximum benefits of JavaFrame, it is necessary to follow a set of simple guidelines for how systems are designed with JavaFrame. If these principles are violated, analysis of the system is made more difficult and dependability of the system cannot be guaranteed.
Even though we may use Java-modelling directly, it is often simpler to keep the JavaFrame invariants if architectural modelling with UML or RoseRT is used. Then the structure of Active Objects and Mediators can visually be verified.
The structural invariants are:
Every Active Object will communicate only through its own Mediators
Every State Machine will only address its own innermost Mediators.
A Composite will contain other Active Objects and the containment is defined through the communication structure of the Mediator connections.
Whenever an Active Object is going to be created it is assumed that its Mediators already exist. They are parameters to the constructor.

8
The behavior of the JavaFrame system is only dependent upon the individual behaviors of its constituent
State Machines. For the State Machines the following invariants must hold:
All State Machines of a specific extended class are reentrant in that they refer to the same State structure.
All dynamic variables are local to the State Machines.
Every transition should end in an operation that defines the next state.
At any point in time, a State Machine is associated with either one or zero Schedulers. If a State machine is not associated with a Scheduler, it will not execute until it again is associated with a
Scheduler. State machines may migrate from one Scheduler to another.
We touched above upon the issue of Java Threads. It is clear that threads represent one of the most serious programming challenges of Java and it is our experience that careful control of the threads is the single most important issue to make the system dependable. We urge the programmer not to introduce extra threads in the behavior of the JavaFrame system. In systems that communicate with the JavaFrame system, threads may be applied at will, but these threads must not modify any variables within the JavaFrame system other than those of the Edge Mediators.
More thorough discussion of general modelling principles of asynchronously interacting state machines can be found in the TIMe method [2, 3].
In order to keep the invariants of the JavaFrame modelling guidelines, we provide the Java programmer with a set of patterns or templates where he should substitute some parts with his own system specific properties. The patterns themselves make up an example running JavaFrame system. As can be expected, the patterns are documented with Javadoc.
In addition to contributing to keeping the invariants, the patterns give recipes for how to program in a thread-safe manner. This is by no means trivial, and experience among even expert Java programmers has shown that thread errors are too often made. The Java mechanisms of concurrency has been criticised [1] and it necessary to be very cautious to avoid the concurrency pitfalls.
In particular we have given patterns for thread-safe, but effective programming of free-lists of messages.
This improves the performance with respect to storage as well as speed. The performance also becomes more predictable as garbage collection occurs more seldom.
When architectural modelling is performed in UML or RoseRT, the Java patterns are used merely as code schemas, and the translation from the model to Java code is close to trivial.
JavaFrame is now in its first version. The motivation for making JavaFrame was basically to ensure quicker production of more dependable Java systems. It was also a motivation that our JavaFrame systems should be more maintainable and more suited for dynamical change. Our Ericsson product line partners appreciates these goals, but feared that performance would suffer.
Therefore we decided that our first testbench would be a model intended to give indications of performance relative to the existing IP telephony product in which we have suggested that JavaFrame would be beneficial. The performance model was reasonably simple, but contained most of the JavaFrame concepts.
The IP telephony development team produced a corresponding performance model using their preferred software technology.
The results are up to now very encouraging. Typically for a certain throughput of messages, our
JavaFrame model showed an average throughput duration of 6.92 ms, while the traditional technology showed 10.13 ms. The JavaFrame model had much smaller variance of the throughput durations, while the traditional model showed better best throughput time. The last result is to be expected as the JavaFrame model performs storage optimization all the time while the traditional model applies the Java garbage collector.

9
In the sequel we plan to test also our intended hypotheses for faster development of more dependable programs in the area of service creation.
It was mentioned in the introduction that both UML-RT as supported by RoseRT and SDL have adequate structuring mechanisms. While UML has a separate concept of Subsystem for system structuring, it is a common property of UML-RT and SDL that the structuring of systems is done by means of objects. Actors of ROOM and Agents of SDL are objects, it is possible to define classes of these structuring objects - and for
SDL it is even possible to define subclasses of these and thereby inherit structure specification.
JavaFrame takes the same approach as UML-RT and SDL. Active Objects and Composites are objects, and as they are defined by Java classes, it is also possible to define subclasses of these structuring classes.
One reason for this is that our technical assumptions and background made this an obvious approach. The other reason is that Java lends itself to this approach. Java has more or less two different, major concepts:
Packages and Classes of Objects. No Java programmer would ever dream of asking for a special kind of package concept for system structuring (which would be the counterpart to UML Subsystems), and every
Java programmer knows that objects should be used when structuring a system. Design Patterns and
Frameworks for improved structuring of systems are also concerned with objects and classes of objects – not with special language constructs for this purpose.
How then is JavaFrame compared to Design Patterns, Java APIs and Application Frameworks?
While Java Design Patterns are fragmented and not necessarily related patterns of well-proven ways of modelling in Java, the classes of JavaFrame are related in a very specific ways. For example Mediators can only be used as boundaries of Active objects, and Statemachines can only be part of a Composite.
Java APIs are often designed for certain application domains. All classes are not necessarily related, and there is normally no required discipline for the use of the classes. Java Frameworks are often also domain specific, although the most popular are very general, e.g. window frameworks with a built-in event dispatcher. JavaFrame is a framework in the sense that it has a run-time system that implements the basic behaviour of e.g. the active objects and that this run-time system is the machinery making the classes work together. The main difference between JavaFrame and other frameworks is that JavaFrame supports a general style of Java programming at such a level of abstraction that it corresponds to modelling in the sense that you would do with UML, provided that UML has support for JavaFrame concepts.
We have described an MDK: Model Development Kit (the term inspired by SDK 6 ) based upon state-ofthe-art modeling concepts from SDL and UML-RT, applied in a Java setting, supplemented with well-proven methodology guidelines. In principle, JavaFrame can be used with only the support from state-of-the-art Java programming environments, making projects less dependent on modeling tools.
Applying the approach of JavaFrame, it is possible to achieve high independence between software parts and between designers, and thereby facilitating fast improvements, e.g. being first with new functionality.
The strong correspondence between model and implementation ensures that even major restructuring of applications is feasible.
The independence between software parts also ensures robustness. In addition, users of JavaFrame do not have to cope with the difficulties in the handling of non-synchronized communicating state machines: the underlying software of JavaFrame takes care of that.
6
SDK = Software Development Kit

10
1. Brinch Hansen, P., Java's Insecure Parallelism.
ACM SIGPLAN Notices, 1999. 34(4) (April 1999): p. 38-
44.
2. Bræk, R., et al.
, The Integrated Method - TIMe , . 1997, Sintef: Trondheim.
3. Bræk, R. and Ø. Haugen, Engineering Real Time Systems . 1 ed. BCS Practitioner Series, ed. R. Welland.
1993, Hemel Hempstead: Prentice Hall International. 398.
4. Gosling, J., B. Joy and G. Steele, The Java Language Specification . 1996.
5. ITU, Recommendation Z.100
, in ITU Specification and Description Language , R. Reed, Editor. 1999,
ITU-T: Geneva. p. 300.
6. ITU, Z.120
, in Message Sequence Charts (MSC) , O. Haugen, Editor. 1999, ITU-T: Geneva. p. 126.
7. OMG, OMG Unified Modeling Language , . 1999, Object Management Group.