Differences between revisions 6 and 20 (spanning 14 versions)
← Revision 6 as of 2007-11-12 19:36:09 →
Size: 472
Editor: c-76-104-237-29
Comment:
← Revision 20 as of 2008-04-09 18:14:29 →
Size: 8571
Editor: nebbiolo
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
= Release 3.0 Use Cases / Overall Themes =
(Under construction) 		= 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:
 * '''Easier''' interface for plugin writers to understand and use.
 * Better modularity or layering making it '''easier''' for components of Cytoscape can be used in different contexts.
 * Clean up/refactor the structure of the existing Cytoscape core so that it can be more '''easily''' maintained, modified, and extended in the future.
 * Make backwards compatibility '''easier''' to maintain.
 * Clean up the user interface so that it's '''easier''' for users.
Line 6: Line 11:
= Rearchitecture Discussions =
[:Oct2007SeattleMeeting: Seattle Meeting 2007] 		= Desired Features =
 * '''2.6'''. The primary feature for Cytoscape 3.0 is to do everything that 2.6 does. See [http://cytoscape.org Cytoscape].
 * '''Layer Cytoscape'''. Separate Cytoscape functionality into clearly defined layers or modules. The motivation is to allow alternative users of Cytoscape. For more information read: [:CytoscapeLayerRefactor: RFC 46], [:HeadlessModeRFC:RFC 6], [:WebFrontEnd: RFC 55].
 * '''Separate the view from the model'''. The motivation for this is to use Cytoscape in various headless (or alternatively headed) modes. See: [:HeadlessModeRFC:RFC 6], [:WebFrontEnd: RFC 55].
 * '''Command layer'''. In current versions of cytoscape one of the primary impediments to headless mode operation is the problem that the GUI it tightly coupled with almost all actions available to users (load file, save file, etc.). To solve this, Cytoscape needs a command layer that is cleanly separated from the application (not necessarily the view). This command layer should also be extensible so that plugin writers can add their own commands. See: (write an RFC).
 * '''Improved Event handling'''. Cytoscape currently uses a mish-mash of different events to signal system state changes. This is confusing, error prone, and causes performance problems. We need to develop a simple, clean Cytoscape event handling interface that can be used listen for and fire common events. See: [:EventHandling: RFC 52].
 * '''Custom graphics'''. We would like the ability for plugin writers to be able to define their own shapes and edges to be displayed and integrated into Cytoscape. See: [:RichLineTypes:RFC 32], and (write shape RFC).
 * '''Improve build process and package structure'''. We would like to simplify the build process for cytoscape so that all necessary libraries and plugins can easily be found and built with the core. See: [:DependencyManagement:RFC 44].
 * '''Local Attributes'''. Allow for attributes to be specific to networks in addition to maintaining the current global attributes. See: [:LocalAttributes:RFC 31], [:AttributeNamespaces:RFC 37].
Line 9: Line 21:
[:HackathonNotes: Amsterdam Hackathon 2007] = 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.

  * Fix all deprecation warnings and remove unused code.
  * Begin building software using maven instead of ant.
  * Separate '''''existing''''' code into modules.
    * Networks
    * Attributes
    * View
    * Layouts
    * VizMapper
    * IO
    * Plugins
  * Write unit tests.

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.

See attachment for a nicely formatted version of the table below that includes time estimates and potential dates.
attachment:Cyto3ProjectPlan.xls

||'''ID'''||'''Name'''||'''Description'''||'''Status'''||
||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 usedwithin core code. Ideally 3-10 use cases should be identified|| ||
||12||Use Cases||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||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|| || ||
||24||Interface Development|| || ||
||25||Plugin Interface Development|| || ||
||26||Interface Implementation|| || ||
||27||Unit test/documentation|| || ||
||28||View (Presentation)|| || ||
||29||Use Cases|| || ||
||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|| || ||
||36||Interface Development|| || ||
||37||Plugin Interface Development|| || ||
||38||Interface Implementation|| || ||
||39||Unit test/documentation|| || ||
||40||Application|| || ||
||41||Use Cases|| || ||
||42||Interface Development|| || ||
||43||Plugin Interface Development|| || ||
||44||Interface Implementation|| || ||
||45||Unit test/documentation|| || ||
||46||Examine further componentization (OSGi)|| || ||

= Discussions =
 * [:Oct2007SeattleMeeting: Seattle Meeting 2007]
 * [:CytoscapeRetreat2007/HackathonNotes: Amsterdam Hackathon 2007]
 * [:Cytoscape_3.0/Model: New Model]
 * [:Cytoscape_3.0/View: View Layer Proposal]
 * [:Cytoscape_3.0/HyperEdges: Hyperedges]
 * [:MavenInfo: Some info for using Maven]
Line 13: Line 105:

= Release 3.0 Feature Ideas (VERY tentative) =
== New Features ==
 * Better modulality - OSGI model?
 * Multi-thleading - better support for multi-core/CPU machines.
    * Layout Algorithms
    * Analysis tools

TableOfContents

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:

  • Easier interface for plugin writers to understand and use.

  • Better modularity or layering making it easier for components of Cytoscape can be used in different contexts.

  • Clean up/refactor the structure of the existing Cytoscape core so that it can be more easily maintained, modified, and extended in the future.

  • Make backwards compatibility easier to maintain.

  • Clean up the user interface so that it's easier for users.

Desired Features

  • 2.6. The primary feature for Cytoscape 3.0 is to do everything that 2.6 does. See [http://cytoscape.org Cytoscape].

  • Layer Cytoscape. Separate Cytoscape functionality into clearly defined layers or modules. The motivation is to allow alternative users of Cytoscape. For more information read: [:CytoscapeLayerRefactor: RFC 46], [:HeadlessModeRFC:RFC 6], [:WebFrontEnd: RFC 55].

  • Separate the view from the model. The motivation for this is to use Cytoscape in various headless (or alternatively headed) modes. See: [:HeadlessModeRFC:RFC 6], [:WebFrontEnd: RFC 55].

  • Command layer. In current versions of cytoscape one of the primary impediments to headless mode operation is the problem that the GUI it tightly coupled with almost all actions available to users (load file, save file, etc.). To solve this, Cytoscape needs a command layer that is cleanly separated from the application (not necessarily the view). This command layer should also be extensible so that plugin writers can add their own commands. See: (write an RFC).

  • Improved Event handling. Cytoscape currently uses a mish-mash of different events to signal system state changes. This is confusing, error prone, and causes performance problems. We need to develop a simple, clean Cytoscape event handling interface that can be used listen for and fire common events. See: [:EventHandling: RFC 52].

  • Custom graphics. We would like the ability for plugin writers to be able to define their own shapes and edges to be displayed and integrated into Cytoscape. See: [:RichLineTypes:RFC 32], and (write shape RFC).

  • Improve build process and package structure. We would like to simplify the build process for cytoscape so that all necessary libraries and plugins can easily be found and built with the core. See: [:DependencyManagement:RFC 44].

  • Local Attributes. Allow for attributes to be specific to networks in addition to maintaining the current global attributes. See: [:LocalAttributes:RFC 31], [:AttributeNamespaces:RFC 37].

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.

  • Fix all deprecation warnings and remove unused code.
  • Begin building software using maven instead of ant.

  • Separate existing code into modules.

    • Networks
    • Attributes
    • View
    • Layouts

    • VizMapper

    • IO
    • Plugins
  • Write unit tests.

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.

See attachment for a nicely formatted version of the table below that includes time estimates and potential dates. attachment:Cyto3ProjectPlan.xls

ID

Name

Description

Status

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 usedwithin core code. Ideally 3-10 use cases should be identified

12

Use Cases

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

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

24

Interface Development

25

Plugin Interface Development

26

Interface Implementation

27

Unit test/documentation

28

View (Presentation)

29

Use Cases

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

36

Interface Development

37

Plugin Interface Development

38

Interface Implementation

39

Unit test/documentation

40

Application

41

Use Cases

42

Interface Development

43

Plugin Interface Development

44

Interface Implementation

45

Unit test/documentation

46

Examine further componentization (OSGi)

Discussions

Timeline

Release Date: TBD

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

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