Project plan | Time usage reports | Change log | Meeting minutes | Functional specification | Technical design document | Implementation document | Testing reports | User's Manual | Final report

Software Engineering Project:
Venice

UML Visualization Tool

Technical design document

Version 1.0
Last updated: Thursday 10.05.2001 00:24:02 EEST

[Validate this document]

Contents

1 Introduction
1.1 Main requirements
2 General architecture
2.1 Model/View/Controller
2.2 Subsystems
2.3 File formats
3 Subsystem descriptions
3.1 Main application framework
3.1.1 General description
3.1.2 External and internal classes
3.1.3 Interfaces to other subsystems
3.1.4 Class descriptions
3.2 GXL model
3.3 Visualization
3.3.1 General description
3.3.2 External interface of the subsystem
3.3.3 Implementation of the interface using Jazz library
3.3.4 Visualization data structure
3.3.5 Saving and loading of visualization layout
3.3.6 Class and interface descriptions
3.4 User interface
3.4.1 General description
3.4.2 User interface description
3.4.3 Overall structure of the user interface subsystem
3.4.4 Class and interface descriptions
4 Testing plan
4.1 Main framework
4.2 GXL model
4.3 Visualization subsystem
4.4 GUI subsystem
Appendix A: Updates for milestone 2
Appendix B: JAVADOC documentation

1 Introduction

This is the technical design document for a software engineering project called Venice. This is the technical design for the first milestone. This document is still being worked on.

1.1 Main requirements

There are a few main requirements that will be implemented in the first milestone. Those requirements are GXL reading, default layout making, drawing nodes and arcs (using specified notation), zooming and panning.

2 General architecture

2.1 Model/View/Controller

Venice is built around a model/view/controller (MVC) framework. The GXL data is the model (class ModelStorage), the Jazz based viewing system is the view and the user interface is the controller. The idea is to have these three components so independent that one component could be changed without affecting the other two. Even if that isn't achieved, it is a good idea to keep components as separate as they can be.

General architecture

Command and its subclasses is modeled after the design pattern Command. The subclasses handle UI commands, such as grouping, ungrouping, selecting, moving and filtering. Various UI related items and widgets are given instances of Commands which they can execute when the UI items are activated.

The creator of a Command subclass must initialize the instance to contain the needed references to the subsystems. For example, a GroupCommand instance must have a reference to the system's ModelStorage instance for it to change the model and group items in it.

ModelStorage and GUI/Visualization never interact directly. Various Command subclasses act as Mediators (see the design pattern with the same name for reference) between them. The Commands encapsulate the interaction between ModelStorage and GUI/Visualization.

Visualization and GXL model subsystem subsystem act as a somekind of degenerate abstract factory or a collection of factory methods. They both have public interface classes, and have methods to instantiate the concrete classes that implement these interfaces. Clients (mostly Commands) use these factory methods to create concrete instanses. This way the clients are shielded from changes in the implementation of these two subsystems. They could be even totally replaced. See design patterns Abstract factory and Factory method for further reference.

2.2 Subsystems

The application is split in four major subsystems.

As the architecture diagram shows, the visualization and model storage subsystems don't communicate with each other. All communication between them goes through the main application framework.

2.3 File formats

Venice uses it's own file format to save current state of the visualization to disk and then load it back later. File format is based on ZIP archive and is accessed using JAVA-platforms ZIP handling mechanisms. Venice visualization files can be identified from their .venice-extension.

A venice file contains two files as in the following:

Archive:  examplemodel.venice
VENICE UML Visualization tool data file
 Length   Method    Size  Ratio CRC-32    Name
--------  ------  ------- ----- ------    ----
    8412  Defl:N      927  89%  2d66439b  model.gxl
   50105  Defl:N     9294  82%  f695ef1f  model.visualization
--------          -------  ---            -------
   58517            10221  83%            2 files

State of GXL Model subsystem is saved in GXL format to file model.gxl. State of Visualization is saved to file model.visualization. Class VeniceFileHandler provides access to these 'substreams' of venice files. These streams can then be passed to GXL model subsystem and Visualization subsystem which implement their own reading and writing routines for these files.

File format used by GXL subsystem

GXL subsystem uses XML-based graph exchange language (GXL) -format as its file format. Information on GXL can be found from GXL website

File format used by Visualization subsystem

Visualization subsystem uses a customized file format which is described in chapter describing visualization subsystem.

3 Subsystem descriptions

3.1 Main application framework

3.1.1 General description

Main application framework is the part of Venice, which ties the whole thing together. It is the central part to which everything else is connected and through which all other can communicate with each other. It is the instantiator of other objcts.

Main application framework consists mainly of four classes: venice.Applet, venice.Application, venice.AppModule and venice.Command. Applet and Application classes are really small classes that just instantiate AppModule. Because Venice can be run as an applet and an application, there is a need for a wrapper around the real application main class. Different launching mechanisms are also needed. Applet and Applicatation tell the AppModule whether the system is being run in applet or application mode. This way AppModule can, for example, modify its user interface to include proper functionality.

After Applet or Application has instantiated AppModule, they are of no use in the system. They don't perform any other duties. AppModule must, as a part of its initialization procedure, instantiate a ModelStorage and a GUI. It gives a reference of itself to these components which can use the AppModule to get references of each other.

It might seem pretty redundant and wastefull to have this kind of class structure, but it exists for one reason. That reason is protecting the system from unnecessary rewriting when some part is changed. Also, this way there will be no unnecessary code duplication between Applet and Application, which might be the case without AppModule. If AppModule gains more functionality in the future, which seems quite possible, it is better to keep those things in one place, rather than duplicate that functionality between two classes.

Command and it subclasses are also a part of the main application framework. However, they are not really tied to AppModule, which is the center of the framework. Classes in other subsystems instantiate subclasses of Command as part of their initial setup, and rely on them to perform various duties. Only one instance of each Command is needed. Undo mechanism would probably require one instance of each Command per execution, but that is a thing not considered currently. But to keep the MVC model nice, the commands are said to be a part of the main application framework.

3.1.2 External and internal classes

The diagram below shows the internal classes of the main application framework. External classes can be seen in the diagram showing the architecture of the whole application (Section 2.1).

Diagram of the main framework

Commands

There are the following Command subclasses in Venice. The feature the command will handle should be quite obvious from its name.

Description of design and implementation of different commands is included in the JAVADOC documentation and is not duplicated here.

3.1.3 Interfaces to other subsystems

Application framework will communicate with just about every other component in the system, because it is the one creating them. Of course AppModule will only communicate with top level subsystem classes, such as ZuiView and ModelStorage, but the various Command subclasses require more intimate connections to the innards of the other subsystems.

Top level modules are shielded from the implementation details of other modules, but various Commands will have to know more. However, this isn't an issue, since every command will handle only one thing: the command it is meant to execute. Each Command can do whatever it has to perform its job, but no other class needs to know how the things are done. Changes in other subsystems probably don't affect but a few Commands.

3.1.4 Class descriptions

Refer to the Javadoc documentation for class descriptions.

3.2 GXL model subsystem

3.2.1 Section prequisites

This document does not cover Java API for XML Prcessing, XML or GXL. Reader should be familiar with these to be able understand this section of the document.

3.2.2 General description

GXL Model Subsystem is responsible for Venices main data structures and reading and parsing GXL-files. It consists mainly of three classes: venice.ModelStrorage and venice.GXLReader. ModelStorage class provides the main datastructure for storing the architectural model and operations for querying information. The main datastucture is generated from the GXL-files containing an architectural model that is to be visualized.

The architectural model can be read directly from any URI that is accessible to the applet/application. Crimson SAX-parser, which is a part of Sun Microsystems's Java API for XML Processing (JAXP), is used to parse the GXL-files. The parser reads through the file and extracts the information needed and stores the data in various datastructures. These data structures will be discussed later in greater detail.

3.2.3 Diagram describing the structure of the subsystem

GXL Subsystem

3.2.4 GXL-reader

This class is responsible for reading and parsing of the GXL-file. SAX is used in the parsing of the GXL-file, so the principles of SAX apply. The whole document is read one tag at a time. The data is stored temporarily until the closing tag is read. Then the corresponding Venice object is created and added to the main datastructure.

3.2.5 ModelStorage

This class provides needed datastructures and operations for obtaining information from the model. Information is stored using venice.MElement and venice.MRelationship classes and their subclasses. Each node-tag in the gxl-file is mapped as a venice.MElement and similarly each edge-tag is mapped as a venice.MRelationship. Venice does not support GXL-files that contain more than one graph. ModelStorage also is resposible for writing the documents into gxl-format.

3.2.6 Class and interface descriptions

Refer to the Javadoc documentation for class descriptions and usage of methods and classes.

3.3 Visualization subsystem

3.3.1 General description

Visualization subsystem generates a visualization of the architectural model. It keeps the visualization information in it's own data structures which are separate from the model data structure. The visualization data structures include information such as locations and states of graphical elements which are displayed on the screen. Visualization data structures do not include all data from the model. A particular state of the visualization can be saved to a layout file and it can respectively be loaded back in later.

Visualization subsystem offers an interface to other subsystems which is not directly dependent on any particular visualization implementation. Current incarnation of visualization subsystem is based on the use of Jazz library. Jazz is a general purpose Java-based engine for supporting 2D visualizations using zoomable user interface. Jazz influences the way we must store the visualization information (as will be seen later). The ideas and interfaces of the Jazz library are not described in this document. To better understand the objectives behind different Jazz-derived classes, reader should first have a look at the Jazz documentation.

3.3.2 External interface of the subsystem

The following diagram describes the interface offered by visualization subsystem to other subsystems. An instance of a class implementing the Visualization interface can be obtained through the Visualization factory. Instances of model-corresponding components can be obtained through factory methods in the Visualization interface.

An instance of Visualization corresponds to a single visualization of a model. This means that in VENICE, there will be only one active instance of the Visualization interface at a time.

VSS interface

(PDF)

3.3.3 Implementation of the interface using Jazz library

The following diagram describes the implementation of the external interface using classes based on the Jazz library. ZGroup and ZVisualLeaf are part of Jazz library and both represent visual elements which can be attached to the Jazz visualization data structure (the scenegraph). Visualization elements used in VENICE are based on them.

vss-jazz

(PDF)

3.3.4 Visualization data structure

JAZZ uses a hierarchical data structure (a tree) called scenegraph to store the visual elements of the zoomable user interface. Hierarchy enables grouping of visualization elements which suits well to visualiazing software architecture because software architecture is also hierarchical.

A Package (class ZPackage) is the basic hierarchical container object which contains a number of components and interfaces and also other packages as it's child. Relationships are childs of the 'lowest possible package' for storing them. A Package has (nearly) rectangular bounds and all childs of the package are drawn inside the rectangular bounds.

To support moving of visual element from a location to another, a special group called ZTransformGroup is inserted above a node in the tree. A transformation transforms all nodes which are under the transformation group in the scenegraph tree. Similarly, a ZFadeGroup is used to manage package content visibility when zooming in and out. When package content is set invisible, a ZInvisibleGroup is inserted to the tree.

The following diagram presents an example Jazz scenegraph tree and then the corresponding visualization of the tree. The transform groups are not presented in the diagram to make it easier to understand.

vss-scenegraph

(PDF)

3.3.5 Saving and loading of visualization layout

Saving and loading of visualization layout to a file is performed using JAVA serialization. Class SerializedZVisualization represents a serialized layout and scenegraph information. It contains everything to restore visualization state so for example it is not needed to recreate the visualization tree using model storage.

Saving layout

An instance of SerializedZVisualization is created and in that object is put a reference to the root package and reference to the index lookup hashtable. Then root package is temporaliry removed from visualization to avoid unnecessary references to scenegraph nodes which do not need to be saved. SerializedZVisualization instance is then serialized using JAVA serialization which causes all contents of root package to be serialized recursively.

Loading layout

An instance of SerializedZVisualization is loaded in from an object input stream. Current root package is dropped from visualization and then replaces with the one from deserialized SerializedZVisualization. Index lookup table is replaced similarly. New root package is then added to the visualization.

3.3.6 Class and interface descriptions

Refer to the Javadoc documentation for class descriptions.

3.4 User interface subsystem

3.4.1 General description

GUI subsystem generates user interface of the system. It "listens" users commands and executes them through command interface. GUI subsystem defines user menus, toolbar and popup menus and actions taken in case of using those GUI elements. Gui subsystem gets JComponent from Visualisation subsystem where uml visualization is done. GUI subsystem is initialised by control (AppModule) subsystem.

GUI subsystem is based on the use of javax.swing library and Venice visualization subsystem.

3.4.2 User interface description

This section describes the user interface of Venice.

GUI extends is a JFrame in application and applet version of the system. All commands are located in menubar which is divided into separate menus (File, Edit, View,Zoom, Selection, Filtering, and help in picture below). Frequently used commands can be accessed through a popup menu.

3.4.2.1 Menubar

User interface includes four basic elements: menubar, toolbar, popupmenus and canvas. Contents of menus in menubar can be seen in snapshots below. In menubar is shown some information about current selection so it is updated everytime menubar is used. For example when user changes selection so that new selected package state is open and earlier selection was close. Or when component is selected package status is not enabled. NOTE. these example views from menubar are from applet version of Venice.

3.4.2.2 Toolbar

In Venice toolbar is three togglebuttons for selection, pan and zoom modes. By default canvas is in selection mode, which means that when clicked above element that element is selected and dragging left mouse down moves current selection. Selection and pan modes can be changed to zoom mode with control-key down, when control-key is released mode returns to original mode.

In zoom mode zooming can be done with mouse right an left. Left button zooms in and right zooms out. Zooming speed can be changed with mouse right button above zoom button in toolbar (0% does not zoom at all and 100% is REALLY fast).

Selection and filtering by name and by type can be done with textfield where these functions get their input. Filter / select textfield is this input stream. Filtering or selecting command can be selected from menus or from popupmenu witch pops up when right mouse button is clicked in textfield.

3.4.2.3 Canvas

Canvas is element where all UML visualisation is shown. Commands to change view or state of its element can be selected from menubar or popupmenu, which both are updated to correspond current selection. Canvas popupmenu is not present in snapshots above. Every element (package, component, dependency and interface) has its unique popupmenu with useful subset of commands. Available commands for current selection go by strict conditions. This means that only common commands are availeble when selection contains different types of visual elements.

3.4.3 Overall structure of the user interface subsystem

The following diagram describes the overall structure of the GUI subsystem. The main interface to the subsystem is the GUI class. An instance of GUI class corresponds to a single user interface frame. It initializes all gui elements and sets actionListeners.

GUI manages the user interface of Venice system and uses commands from command-interface which executes changes to view of the model being visualised.

GUI interacts with Visualization subsystem, control subsystem (AppModule) and command interface. GUI gets information from Visualization subsystem when it needs information about current selection when popup and menubar menus are updated. So user interface query's Visualization to know (only when needed) what services can be offered to user.

Control subsystem (AppModule) instanties GUI with information about lauched mode (application or applet) so GUI can initialise correct service points to menubar.

Command interface is interface witch implements commands selected by user. GUI's and MenuToolBar's actionListeners use command interface to transfer requested service to Visualization subsystem which executes changes to canvas.

GUI offers getVisualization()-method to AppModule. Method can be used to get instance of Visualization being viewed.

3.4.4 Class and interface descriptions

Refer to the Javadoc documentation for class descriptions.

4 Testing plan

The system build for milestone 1 will be tested during its development by the implementor of each particular class. Also, as many classes reference classes in other subsystems, implemented by different people, some cross testing will be done.

However, at the beta stage (when all features have been implemented, and just bugs remain), a rigid testing plan is needed. The plan is to test each feature, one by one, variating the procedure so that all possible combinations can be tested.

4.1 Main framework

4.1.1 Test suites

Application, Applet and AppModule are very small classes. They can be formally tested, but that might not be really useful. Anyways, if these classes have bugs, it will really soon be noticed when the application is lauched.

4.1.2 Interactive testing

Various Command subclasses are quite difficult to test. Most of them involve actions which can mainly verified visually. This means each of them has to be tested interactively.

Open/Close/Transparent Commands

These three Commands will be tested with the following test cases. All the test cases presume there are one or two packages (with the other contained in the other in the first test case) in the view. These packages should have some children with relationships going between all the children.

Close subpackage
Close main package
Transparent main package
Open subpackage
Open main package

Close A
Close B
Open A
Open B

Close A
Close B
Open B
Open A

Close
Open

Close
Transparent
Open

Transparent
Open

Application opening

These test verify that the application can be launched and will behave correctly in all those cases. The test consist of starting the application from command line, and most of the time giving one or more command line parameters to Venice. File means a local file system file and URL means an URL. Use is specified in the users manual.

No parameters
Valid XML file
Invalid XML file
Valid .venice file
Invalid .venice file (for example, any non .venice file)
Invalid file name
Invalid .venice file name
Multiple valid files
Multiple invalid files
Valid XML URL
Invalid XML URL
Valid .venice URL
Invalid .venice URL (for example, any non .venice file)
Invalid URL
Invalid .venice URL
Malformed URL
Multiple valid URLs
Multiple invalid URLs

Applet launching

These tests verify that Venice can be started as an applet and it will behave corretly. Most of these tests specify what the "initialmodelurl" parameter will contain, except for the first test where the whole parameter is removed from the HTML file launching Venice.

Parameter missing
Valid XML file URL
Invalid XML file URL
Valid .venice file URL
Invalid .venice file URL
Malformed URL
Empty URL

Interface commands

ShowOfferedInterfacesCommand - Features 9 and 10

Description

GXL input files includes only offered interfaces which can be used by other packages and components. So if GXL input includes interfaces those are presented as offered by default. ShowOfferedInterfacesCommand should be tested with multiple selections of packages and components which offer or require different amount of interfaces.

Cases

HideOfferedInterfacesCommand - Features 9 and 10

Description

GXL input files includes only offered interfaces which can be used by other packages and components. So if GXL input includes interfaces those are presented as offered by default. HideOfferedInterfaces command should be tested with multiple selections of packages and components which offer or require different amount of interfaces.

Cases

ShowRequiredInterfacesCommand - Feature 8

Description

GXL input files includes only offered interfaces so required interfaces are only visualization thing. So loaded model doesn't include required interfaces.

Cases

HideRequiredInterfacesCommand - Feature 8

Description

This command should hide required interfaces generated by Venice tool.

Cases

Zooming commands

ZoomToSelectionCommand - Features 30 and 32

Description

Zoom to selection is a feature which makes current selection as big as possible

Cases

FitToScreenCommand - Features 30 and 32

Description

Fit whole model to screen.

Cases

4.2 GXL subsystem

4.2.1 Test suites

Testing is divided into parts, where each of the main classes is tested separately. Testing will be done with extensive test input and a separate testprogram will be used to test GXL-subsystem.

4.2.1.1 GXL-Reader

GXL-reading

Description: GXL-reading is a feature in which a gxl-model is loaded from a local location or from an external location (URL). A java.io.InputSource is constructed from a GXL-file and this is passed to GXL-subsystem which will parse the file and construct a model from the information.

Test method to be used: interactively with venice.

Case1: GXL-file ok.
Expected result: File is loaded and the model is loaded into memory.

Case2: Invalid input.
Expected result: File loading will stopped and an execption will be thrown. Exception will be catched and a message will be shown.

Case3: No input;
Expected result: Model datastructures are initialized, but they are empty.

Case4: GXL-files dtd is invalid
Expected results: GXL-file dtd location is overrided and a dtd stored in venice.jar is used.

GXL-writing

Description: A model stored in memory datastructures is written in to a file. File is selected and written into a file.

Testing method be used: interactively with venice.

Case1: New filename is selected.
Expected result: File is written to disk.

Case2: Existing file is selected.
Expected result: File is written to disk, the selected file will be overwritten.

Case3: Existing writeprotected file is selected.
Expected result: File writing fails exception will be thrown and they will be caught and a message will be displayed.

Case4: Model with no data.
Expected result: File is written to disk. The gxl-file contains no nodes or edges.

Validity tests

Description: These test are intended to be used in testing the model with different test material.

Test method used: interactively with venice.

Case1: Model is read and then written back to disk.
Expected result: Information content in both files should be identical.

Query tests

Description: GXL subsystem provides several queries. Each of these queries will be tested with a test program and the results will be manually compared with the gxl-file.

Test method to be used: Test program ModelTest.java is used
Testmodel to be used: example.xml

Case1: Dependencies query
Expected result: List of dependencies stored in the model will be displayed.

Case2: Realizations query
Expected result: List of realizations stored in the model will be displayed.

Case3: Generalzations query
Expected result: List of generalizations stored in the model will be displayed.

Case4: Containments query
Expected result: List of containments stored in the model will be displayed.

Case5: ModelElements query
Expected result: All the ModelElements stored are displayed.

4.3 Visualization subsystem

4.3.1 Interactive testing

For visualization subsystem a visual testing will be carried out. This is done using a test model embedded in ZVisualization. ZVisualization includes method setupTestModel1() which uses the Visualization interface provided by ZVisualization to construct a test model correctness of which can be examined interactively by a test user.

Test cases for interactive testing:

4.3.2 Performance profiling

Visualization subsystem should also be profiled using a JAVA profiler using which we can find out potential performance bottlenecks.

Specifically, the following operations should be profiled because they were found to be slow in milestone 1:

4.4 GUI subsystem

4.3.1 Interactive testing

For gui subsystem a visual testing will be carried out. This is done using a test model embedded in ZVisualization and using bigger models as soon as they are available. ZVisualization includes method setupTestModel1() which uses the Visualization interface provided by ZVisualization to construct a test model correctness of which can be examined interactively by a test user.

setupTestModel1() should include all different visualization elements (package, component, interface, dependency, generalization, realization). Packages should be nested to at least 2 levels. Test model should containt at least two instances of package, component and interface.

Gui subsystem testing is not usability test where quality of user interface is tested. It is functional testing where functionality of every widget is tested. This is done by log writings.

Correctness of offered services in menubar and popupmenus should also be tested with different kinds of selections. Gui offeres as much features as possible with current selection, so a lot of combinations are needed.

For example show required interfaces should not be available if current selected package doesn't use any interfaces and show offered should not be available if current selection doesn't offer any.

Menubar and popupmenu testcases. Testing correctness menu updates.

  1. 1 element selected (each type separately)
  2. multiple similar types selected (each type separately)
  3. multiple different types selected (all possible)
  4. packages and components with different kind of combinations of interfaces
  5. multiple interfaces selected offered and required

Guidelines to menubar and popup testing and expected results

Appendix A: Updates for Milestone 2

This appendix contains some pseudo-code on which the features of milestone 2 were based. For other parts than these commands, design for milestone 2 is integrated to the main document. Information in this appendix should be integrated to JAVADOC documentation.

Features 4, 5 and 6: move dependencies

Feature 6 is just a special case of feature 5, where every dependency is moved to upper level. Close means make transparent and hide contents. Open means show contents and move dependencies to lower level. Together these features need new things from the Visualization: the ability to have relationships which can be Composite (maybe implement corresponding Design pattern here?).

Each node (VInterface, VComponent and VPackage) need to have a list of relationships ending or starting from itself. VPackages need to be able to query their children these relationships. This information must be queried dynamically, because the relationships will change at run-time, when the user closes packages, makes them transparent or otherwise moves dependencies to upper level.

Every VPackage has a list of VCompositeRelationships, which contain references to ordinary VRelationships.

When a node (as defined earlier) needs to move its dependencies to an upper level, it needs to have its parent do this. The parent will collect all relationships from the child, and pack them to its own list of VCompositeRelationships. The original relationships are then hidden.

When a node needs to move its dependencies to a lower level, it must again consult its parent. The parent will the remove the dependencies concerning that particular node from its VComponentRelationships and at time of removal that particular relationship will be shown.

Also, addVRelationship method in ZVisualization nees to be modified. It has to add a reference of the relationship to both its source and destination node.

In summary, needed changes for moving dependencies are:

VPackage.close()

for each child as myChild
	for each relationship of myChild and its children as myRel
		// handle relationship leaving this package
		if not (myRel.src isDescentOf this and myRel.dst isDescentOf this)
			myRel.hide
			this.addToCompositeRelationship(myRel)
	myChild.hide // or global hide all children with ZInvisibleGroup

VPackage.addToCompositeRelationship(inRel)

if(mCompositeRelationshipList == null)
	mCompositeRelationshipList = new LinkedList
iterate mCompositeRelationshipList as myElement
	if (match src, dst and reltype with inRel)
		myElement.addRelationshiop(inRel)
		return
myComp = new CompositeRelationship(inRel.src, inRel.dst, inRel.type) // where either src or dst is this
mCompositeRelationshipList.add(myComp)
Visualization.addVRelationship(myComp)

ZPackage.Open

for each child as myChild
	myChild.show // or global remove ZInivisibleGroup
iterate mCompositeRelationshipList as myElement
	iterate myElement as myRel
		myRel.show
delete mCompositeRelationshipList

VNode.moveDependenciesToUpperLevel

for each child as myChild
	for each relationship of myChild and its children as myRel
		if not (myRel.src isDescentOf getParent() and myRel.dst isDescentOf getParent())
			myRel.hide
			getParent().addToCompositeRelationship(myRel with dst or src moved to parent)

Feature 7: Show/Hide interface content

This feature will be implemented as follows:

  1. Command implementing the feature finds out currently selected interface and for that VInterface instance it calls vinterface.setViewMode(VIEWMODE_CIRCLE) or vinterface.setViewMode(VIEWMODE_EXPANDED) depending on users request.
  2. VInterface object receives the call, sets mViewMode and calls dataChanged() which reshapes the component
  3. ZRealization instances connected to the VInterface object receive boundsChanged-events which causes a dataChanged() there.
  4. ZRealization's dataChanged() finds out destination VInterface object's viewMode and adjusts its line shape accordingly

Feature 8: Show/Hide required interfaces

This feature will be implemented as follows:

Show

  1. Find out SelectedNode
  2. Find out Dependencies whose source is SelectedNode and target is instance of interface
  3. for each found dependency
        setVisible(false)
        create new interface(required)
        create new realization(source = selectedNode, target = created interface)
        create new dependency (source = created interface, target = found dependency.target)		  
    end for
    

Hide

  1. Find out SelectedNode
  2. Find out realizations whose source is SelectedNode and target instance of (required) interface
  3. for each found realization
        find out dependency whose source is found realization.target
        draw original dependency(source = realization.source,
                                 target = found dependency.target)
        dependency.remove
        realization.target.remove
        realization.remove
    

Feature 9: Show/Hide offered interfaces

See implementation of feature 10. This is similar but aplied to all interfaces realized from selected package or component.

Feature 10: Hide realized interfaces (show direct dependencies instead)

  1. Command finds out selected node id (from now on, called selectedNodeId)
  2. Using ModelStorage, Command finds out realizations whose source is selectedNodeId.
  3. For each myRealization in realizations
        myInterface = myRealization.destination;
        myInterface.setVisible(false);
        // now old relationships going to myRealization stop drawing,
        // because their target is invisible
        myDeps = modelstorage.findDepsByDestination(myInterface)
        for each dep in myDeps
            newDep = visualization.newVDependency()
    	newDep.setSource(dep.source)
    	newDep.setDestination(selectedNode)
    	visualization.addVRelationship(newDep);
    	myInterface.addSubstituteDep(newDep);
        end for
    end for
    

Feature 10: Show realized interfaces (hide direct dependencies)

  1. Command finds out selected node (called selectedNode)
  2. Using ModelStorage, Command finds out realizations whose source is selectedNodeId
  3. For each myRealization in realizations
        myInterface = myRealization.destination;
        myInterface.setVisible(true);
        // now old deps get automatically drawn again
        SubstituteDeps = myInterface.getSubstituteDeps();
        for each dep in SubstituteDeps
            visualization.removeVRelationship(dep);
        end for
        myInterface.clearSubstituteDeps();
    end for
    

Appendix B: JAVADOC documentation

Link to JAVADOC documentation