ActorFrame Visualisation

Background ActorFrame provides means to define

services by instances of collaborating actors.

Actors can have an internal structure of other actors, parts.

Connections between parts are definded by using ports

Consepts Actorframe uses

consepts known from UML2.0

Actor is a spesialisation of UML2.0s consept of class.

Part is an instance of a class enclosed by another class.(or in ActorFrame, actors)

Port defines interfaces used to connect parts to other parts.

Figure from ActorFrame Developers Guide

Background The internal structure of Actors in terms of

parts, ports and connections can be defined by using actor-descriptors written in XML.

Writing actor-descriptors for services with many actors, can be an error prone task.

The actor descriptors is also specific to the current implementation of the ActorFrame protocol for role requests and role releases.

The project The main goal of this project was to

provide a graphical representation of the actor-descriptors in a service.

The project also aimed at the ability to modify actor-descriptors by using the same tool.

My goals The utility should try do abstract away

implementation spesific details of the actor-descriptors.

Visualisation should be as close to UML2.0 as possible

Modification/creation of actor-descriptors by means of drag and drop.

Notify users in case of errors.

Challenges Information about the initial UML2.0

model are lost in the xml descriptors Ports and connections Inheritance

Challenge 1: Ports and Connections Rolerequest is not

according to UML2.0 Requested part is

typically found by looking up in a nameserver

Direct connection between requesting and requested part

From ActorFrame developers guid

Challenge 1: Ports and connections In UML2.0 one have

to explictly define ports and connectors from requesting part to requested part.

Challenge 2:Inheritance The current notation used in the actor

descriptors does not support inheritance Inherited structure in terms of parts and

ports needs to be explicitly described in the descriptors.

Solutions Inhertiance

No solution. Not critical as visualisation of actual structure is

still provided. Ports and connectors

Extra ports introdused where needed. Are then able to visualise port connections

according to UML2.0Design

Design of application Based on Model View

Controller (MVC) design pattern.

Well known design methology, for example used by Swing components in Java.

Separates between the model that provides the data and the view of this model.

Benefits with MVC Easy to provide different views of the

same data. Separation of consern when coding.

Implementation Import

The current application can import actor-descriptors and visualise them as UML2.0 diagrams.

Can be done better, but a good start. Export

Currently provides a solid base to create actor descripors. The UML2.0 diagram can be modified or created from

scratch by means of drag and drop. Method for parsing the model and creating actor descriptors

started but not finished at the moment.

Demonstration?

Future features 1 Export/import to/from popular UML editors

such as Enterprise Architect and Rational Rose.

Export to popular imageformats such as jpeg, bmp, png, gif etc.

General usability features. Layout algorithms Visual hints Printing Etc.

Future features 2 Encapsulation of information.

Other interesting topics related to visualisation Debugging/monitoring

Provide a visualisation of a running system, as actors are dynamically being created and destroyed (realtime?)

Traces of distributed statemachines in ServiceFrame (suggested by Geir Melby, Ericsson)