1. ActorFrame Visualisation

2. 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

3. 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

4. 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.

5. 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.

6. 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.

7. Challenges Information about the initial UML2.0 model are lost in the xml descriptors Ports and connections Inheritance

8. 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

9. Challenge 1: Ports and connections In UML2.0 one have to explictly define ports and connectors from requesting part to requested part.

10. 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.

11. 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

12. 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.

13. Benefits with MVC Easy to provide different views of the same data. Separation of consern when coding.

14. 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.

15. Demonstration?

16. 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.

17. Future features 2 Encapsulation of information.

18. 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)