This is a Legacy Document!

All information contained in this document is for historical purposes and does NOT contain current information! Visit http://wiki.cytoscape.org/Cytoscape_3 for up-to-date information.

What's New

Quick Start

Plugin Development

This is a first version of documentation for Cytoscape 3.0 geared towards plugin developers Pages under this header will be put in a proper directory structure. In the near future all documentation regarding Cytoscape 3.0 will come in a clean separate wiki.

Release 3.0 Overall Goals

There are several motivations for release 3.0 of Cytoscape, but the overriding theme of the release is to refactor/redesign the code so that things become easier. Things in this case has several specific meanings:

Desired Features

Refactoring Strategy

Rather than rewriting Cytoscape from scratch we intend to refactor the existing code base. Since we already have a working version of Cytoscape that suits many people's needs quite well, a central tenet of the refactoring process will be to maintain a working version of Cytoscape. That means that each time a change is made (i.e. code checked into the trunk), all unit tests should pass and Cytoscape's main functionality should still work. This will be an iterative process with many small changes, rather than a few large ones. The hope is that with this process we will not lose functionality as we make changes.

Rough module refactoring plan

The general plan is to begin by cleaning up the existing code base and modularize what we can while changing as little as possible. The goal is to establish the modules that comprise Cytoscape and the dependencies between them. Once we have a coherent structure of existing code, we can begin redesigning modules to suit our new requirements.

Prepare the existing code base for refactoring.

Once the existing code base has been cleaned up, we can begin our redesign efforts for 3.0. The general strategy will be to work from the bottom up. That is to say, begin with the modules at the base of the dependency graph that all other modules depend on. This means work on Networks and Attributes first, followed by the View and on up through the dependency graph.

A time schedule has been put together to allow for time to discuss and plan each module and provide some end dates for when each discussion should be finished and implementation can begin. As much as possible we will work to adhere to this to allow 3.0 to be released in a reasonable time frame. Start dates will be added after 2.6 is officially released.

Layer design discussion schedule

Layer

Discussion organizer

Description

Status

Discussion page

Start Date

Model

Mike Smoot

The core graph model for Cytoscape

Will resume mid-late April

Model layer design discussions

May 8, 2008

View Model

TBD

The view model representation (not the presentation layer).

TBD

View Module discussions/use cases

TBD

IO

TBD

IO layer (files, web services, databases, etc)

TBD

IO Module discussions/use cases

TBD

Presentation (view)

TBD

Presentation layer that renders the underlying view models

TBD

Presentation Discussions

TBD

Command

TBD

Formerly called Actions. UI-independent collection of high-level functions, such as creating network, execute layout, etc.

TBD

Command discussions/use cases, Tunable discussions/use cases, Monitor discussion/use cases

TBD

Application

TBD

TBD

TBD

API naming

The following table summarizes the classes that represent a given object in each layer.

Object

Model

ViewModel

Presentation

network

CyNetwork (and CyRootNetwork, CySubNetwork)

NetworkView

NetworkRenderer

node

CyNode (and CyMetaNode)

NodeView

NodeRenderer

edge

CyEdge

EdgeView

EdgeRenderer

attribute table

CyDataTable

*

*

row in attribute table

CyRow

*

*

column in attribute table (an attribute)

CyColumn

*

*

* After discussing things at the second mini-retreat, we realized that visualizing CyDataTable/CyRow/CyColumns should have the same view-model and presentation layers that networks/nodes/edges have. We haven't discussed these, nor has anyone proposed names for them, which is why those fields are filled in.

Project Plan

See attachment for a nicely formatted version of the table below that includes time estimates, potential dates and notes regarding each. Please keep in mind this is meant to be very high level and will gain details through our discussions of each module. Cyto3ProjectPlan.xls

Note also that the dependencies and time estimates can change. Some of these things are potentially doable in parallel so we will update this as we determine which pieces are being done. As people volunteer for parts we will also add them to the table to keep everyone aware of what is being done.

ProjectPlan.gif

ID

Name

Description

Status

Lead

4

Modular System

Milestone 1 - Layer current code base

5

Separate code into layers

Per the RFC's modules for Graph model, View model, IO, View (presentation), Application, Command

6

Introduce temporary interfaces

Starting with the graph model, write interfaces to allow other layers toaccess the graph model and remove all dependencies to classes outside the graph model. Once it has no dependencies, work on other layers to ensure dependencies are correct and unidirectional.

7

Unit test/documentation

Per each layer, multiple people can work on this

8

Build Process - Maven

Mavenize separate layers to build modularly again start from the graph model

9

Merge 2.6 bug changes

Merge 2.6 changes into 3.0 branch

10

Recode Core Interfaces

Milestone 2 - Replace temporary interfaces with stable, planned interfaces. First relayered system finished

11

Graph Model

Use what's been learned from Step 1 to write use cases specific to the graph model as used within core code. Ideally 3-10 use cases should be identified

12

Use Cases/Discussions

Based on use cases develop a graph model interface for core usage. Add indexing pattern forfast graph iteration.

13

Interface Development

14

Plugin Interface Development

Determine if a separate Plugin interface is required to limit access to specific parts of the graph model.

15

Interface Implementation

16

Unit test/documentation

Each layer's interface needs to include unit tests and documentation in order to be considered finished

17

View Model

Similar to Step 8, the difference being that this layer deals only in the persistable visual data that needs to be stored (but not the actual presentation layer)

18

Use Cases/Discussions

3-10 use cases

19

Interface Development

Provide for view models that are persistable but not dependent on the actual presentation.

20

Interface Implementation

21

Unit test/documentation

22

IO

23

Use Cases/Discussions

24

Interface Development

25

Plugin Interface Development

26

Interface Implementation

27

Unit test/documentation

28

View (Presentation)

29

Use Cases/Discussions

30

Interface Development

??? Not sure about this one. The presentation layer may require more time and will be adjusted later

31

Plugin Interface Development

32

Interface Implementation

33

Unit test/documentation

34

Command

35

Use Cases/Discussions

36

Interface Development

37

Plugin Interface Development

38

Interface Implementation

39

Unit test/documentation

40

Application

41

Use Cases/Discussions

42

Interface Development

43

Plugin Interface Development

44

Interface Implementation

45

Unit test/documentation

46

Examine further componentization (OSGi)

Visual Development Timeline

This diagram displays provides lots of information:

cytoscape3_development_timeline.png

Design Discussions

Mini-Retreat Discussions

Timeline

Release Date: TBD

Implementation

TODO List

Testing Cytoscape 3.0

Outdated_Cytoscape_3.0 (last edited 2011-12-01 18:04:03 by MikeSmoot)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux