RFC Name : Layering of Cytoscape Code

Editor(s): Sarah Killcoyne, John Boyle, Mike Smoot

Date: August 16, 2007

Status: Open for comment

<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>

Proposal

Many Cytoscape clones are available that: utilize both web and server based technologies; use advanced information visualizations of graphs; and support a plugin architecture. While Cytoscape is still preferentially, we can improve the functionality in a number of ways, including: clear scripting/macro capability; web based delivery; allowing for high throughput asynchronous message based analysis; server/distributed functionality; uniform access to data sources; and a componentized code base (e.g. to change the rendering code). While it may be possible to do many of these things with the current code base, all of these would be simpler and cleaner to implement if the code is relayered to separate the functionality. This would also enable cleaner builds and ensure that the code is maintainable in the future. This proposal builds upon the following RFCs: (38) Code Layering, (40) Scripting in Cytoscape and (6) Cytoscape Headless Mode Operation.

In order to accomplish the goal of relayering we will introduce use cases/features, including those that that require scripting, web front ends and easier maintenance. We will also discuss the package structure and build dependencies. The plan is to iteratively move towards a fully layered architecture through meeting several milestones that will also allow Cytoscape to continue some forward development during this work. The current package structure will first be refactored into the an intermediate structure that mimics that model/view relayered code we desire, then a set of temporary interfaces will be created to handle the dependencies that will exist to allow us to meet the first milestone. We can then take that structure and set up each part as an OSGi service with the registry to meet the second milestone. Finally we can go back and remove the various artificial interfaces and dependencies we introduced initially in order to have a fully layered system. At this point it will be much simpler to set up interfaces for plugins, scripting and command-line control of Cytoscape.

Use Cases


Build Dependencies

Layers.jpg

The proposal is to initially introduce three layers into the code: Model layer which contains the business logic; view layer containing all the graphical/presentation code; and the IO layer which controls readers/writers. These will be built as subsystems, with the no dependencies existing on the model layer. View and IO systems will be dependent on Model and Application will depend on all three. Temporarily we will introduce a “Common” subsystem which all other systems will depend upon to allow us to factor out dependencies more simply. As the relayering progresses, interfaces from the Common system will be refactored to remove this dependency.

Package Structure Overview

The packages will be broken into four main groups as described above: model, view, application and io. Each of these packages will contain classes specific to that part of the system.

Model Layer

The model layer contains the basic data structures necessary for the underlying graph, including networks, nodes, edges and attributes.

Model Definition

NetworkModelDiagram.jpg

The network package structure will be a set of interfaces for the basic network object types. All will inherit off of a single interface that will contain basic information each network object should need (see below).

Model Events

ModelEvents.jpg

The network event package structure is based on the standard java event pattern (<item>producers firing <item>events to a list of <item>consumers). The definition and reason of the event objects being past between objects depends on the type of event, and is detailed in the description below. Each model contains a list of its consumers, however to enable the ability to have multiple selections propagation mechanisms attached to one model a series of selection delegates can be attached to the model (each containing separate lists of listeners.

Attribute Definition

AttributeModel.jpg

The attribute package structure would contain the basic interface for an attribute and set of attributes.

The attribute events package would contain events for create, destroy, modify and selection events (patterned similarly to network events).

View Layer

View layer is dependent on the model. It provides visual representations of the model, and will include additional state information. Controller classes will not be used in the first instance, but will be introduced when/if a web based system is introduced. The planned views include:

IO Layer

IOModel.jpg

IO/Comms layer handles network creation from both remote and local locations. The system is designed to be extensible to a number of different scenarios (including web service, J2EE, database and file system based loading). A basic single login security model and location “property” are suggested.

Producers are used to access single Models (either CyNetwork or CyNetworkArray) and so require a unique id, whilst finders provide “searching” functionality. The searching specification can either be through a generic method or through specific method signatures. The security model takes login and location information (e.g. JNDI resource, file name). Initially only a file system based implementation is planned.

Additional Packages (Layers)

Application package will contain anything specific to the gui application (e.g swing for a desktop application).

Common package will contain all the glue interfaces required as we separate out the layers. This would be a temporary package that will eventually be removed when the final layered system is complete.


Project Management

Project Plan

ProjectPlan.gif

Excel version of the plan: RefactorProjectPlan.xls

Tasks and Milestones: All time estimates based on 1 FTE.

  1. Milestone/Deliverable 1: Completed modular systems.

    1. Refactor the packages (estimated at 1 month): move the code into the new package structure. Starting with the model each package should compile in the order demonstrated above. The model should have no dependencies outside itself. View, IO and Plugin depend on the model and the application will depend on Model, View and IO.
    2. Introduce interfaces (estimated at 3 months): use ‘artificial’ interfaces to break dependencies between classes in different packages. Starting with the model, write interfaces to allow other layers to access the model and remove all dependencies to classes outside the model. Once the model has no dependencies, work on other refactoring to ensure dependencies are correct and unidirectional.
    3. Unit test redevelopment and documentation (estimated at 2 months).
  2. Milestone/Deliverable 2: Components based runtime

    1. Produce componentized build (estimated at 1 month): build the system as a series of artifacts (using Maven or similar).
    2. Produce and register the relevant OSGi services (estimated at 1 month): Register each of the new components as services.
  3. Milestone/Deliverable 3: First relayered system.

    1. Remove dependencies (estimated at 6 months): Recode Cytoscape to reduce and repackage the artificial interfaces.
    2. Redo build and services/components (estimated at 2 months). First release of new componentized Cytoscape.
    3. Unit test redevelopment and documentation (estimated at 1 month).

Project Dependencies

The following project depend on the successful completion of the milestones in this project.

Issues

There are a few issues that need to be resolved:

Alternative #1

Here is an alternative package structure. It looks complicated, but the dependencies are acyclic. Some existing class names are added for clarity.

ClassDiagram3.png


Comments

How to Comment

Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

AllanK: I have a couple of questions:

1. Can the architecture be utilized to provide some orchestration of user-level event handling, for example multiple, independently-written plugins that might compete over processing of a DropTarget? If so, then how would we do that?

2. What does the network model assume about whether nodes, edges, groups, attributes are shared vs. copied when they appear in multiple networks? Our current set of conventions is quite complex. Can we achieve some simplification during the process of re-layering?

3. moving forward, we need to support arbitrary graphics, i.e. graphical shapes that are not attached to a particular node or edge in a network. Do we need an additional Interface for this? If so, then should we add a fourth interface to the model package?


ScooterMorris: This is a very nice start! Thanks so much for getting this moving. A couple of comments:

1. The model probably needs to include CyGroups as a separate model element, or we have to bind a group to a network, which I'm not sure is what we want (although there is room for discussion about that).

ScooterMorris:

2. I've been increasingly wondering if Attributes really should be as separate from the model as we currently make them. I believe that that is a result of the implementation, not a desired architecture. Personally, I would like to be able to find all the attributes of this CyNetwork (or CyNode or CyEdge) without having to search a separate data structure. If we're going to go through a full relayering, I would certainly like to have the discussion about why CyAttributes aren't "attributes" of the objects they annotate.

ScooterMorris:

3. It's not entirely clear that layout should be dependent on the view or just the model. If a CyNode had an X,Y[,Z,t?] attribute then there are many very useful things we could do without having to create an entire view. Once of those things would be to layout the Network, then we could apply a view to map the layout to a specific representation or media. Notice here that I'm separating out the concept of a node's location from other graphic ideas such as color and opacity, which are more clearly (at least in my mind) part of the view.


CytoscapeLayerRefactor (last edited 2009-02-12 01:03:14 by localhost)

MoinMoin Appliance - Powered by TurnKey Linux