Cytoscape Wiki|
Size: 15272
Comment:
|
Size: 14100
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| [[TableOfContents]] |
<<TableOfContents>> = What's New = * Developer's documents update in progress - Kei (3/10/2009) * Current progress on Cytoscape 3.0 development is monitored at [[/DevelopmentModules]] = Quick Start = * [[Cytoscape_3.0/Developer/QuickStart|Quick start guide for Cytoscape 3 developers]] * [[Cytoscape_3.0/Eclipse/CoreDevelopment|Start guide for Cytoscape 3 developers using Eclipse]] * [[Cytoscape_3.0/Eclipse/CoreDevelopment|Cytoscape 3 Plugin development pages]] * [[http://cytoscape.wodaklab.org/javadoc/|3.0 API]] -- Please note that this still an active work-in-progress and subject to change at any time! |
| Line 11: | Line 23: |
| Line 12: | Line 25: |
|
* '''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: [:Cytoscape 3.0/CommandDiscussions:Command Layer Discussions]. * '''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]. * '''Dynamic language support'''. Implement a built-in support to access Cytoscape API from dynamic (scripting) languages. See: [:Scripting:Scripting RFC] |
* '''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: [[Cytoscape_3.0/CommandDiscussions|Command Layer Discussions]]. * '''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]]. * '''Dynamic language support'''. Implement a built-in support to access Cytoscape API from dynamic (scripting) languages. See: [[Scripting|Scripting RFC]] |
| Line 40: | Line 54: |
| Line 45: | Line 60: |
|
||'''Layer''' ||'''Discussion organizer''' ||'''Description''' ||'''Status''' ||'''Discussion page''' || '''Start Date''' || ||[#graphModule Model] || Mike Smoot || The core graph model for Cytoscape ||Will resume mid-late April || [:Cytoscape 3.0/ModelDiscussions:Model layer design discussions] || May 8, 2008 || ||[#viewModule View Model] || TBD || The view model representation (not the presentation layer). ||TBD || [:Cytoscape 3.0/ViewModelDiscussions:View Module discussions/use cases] || TBD || ||[#ioModule IO] || TBD || IO layer (files, web services, databases, etc) ||TBD ||[:IODiscussions:IO Module discussions/use cases]|| TBD || ||[#viewPresentation Presentation (view)] || TBD || Presentation layer that renders the underlying view models ||TBD || [:Cytoscape 3.0/PresentationDiscussions:Presentation Discussions]|| TBD || ||[#commandModule Command] || TBD || Formerly called ''Actions''. UI-independent collection of high-level functions, such as creating network, execute layout, etc. || TBD || [:Cytoscape 3.0/CommandDiscussions:Command discussions/use cases], [:Cytoscape 3.0/TunableDiscussion:Tunable discussions/use cases], [:Cytoscape 3.0/MonitorDiscussion: Monitor discussion/use cases]|| TBD || ||[#appModule Application] || TBD || ||TBD || || TBD || |
||'''Layer''' ||'''Discussion organizer''' ||'''Description''' ||'''Status''' ||'''Discussion page''' ||'''Start Date''' || ||[[#graphModule|Model]] ||Mike Smoot ||The core graph model for Cytoscape ||Will resume mid-late April ||[[Cytoscape_3.0/ModelDiscussions|Model layer design discussions]] ||May 8, 2008 || ||[[#viewModule|View Model]] ||TBD ||The view model representation (not the presentation layer). ||TBD ||[[Cytoscape_3.0/ViewModelDiscussions|View Module discussions/use cases]] ||TBD || ||[[#ioModule|IO]] ||TBD ||IO layer (files, web services, databases, etc) ||TBD ||[[Cytoscape_3.0/IODiscussions|IO Module discussions/use cases]] ||TBD || ||[[#viewPresentation|Presentation (view)]] ||TBD ||Presentation layer that renders the underlying view models ||TBD ||[[Cytoscape_3.0/PresentationDiscussions|Presentation Discussions]] ||TBD || ||[[#commandModule|Command]] ||TBD ||Formerly called ''Actions''. UI-independent collection of high-level functions, such as creating network, execute layout, etc. ||TBD ||[[Cytoscape_3.0/CommandDiscussions|Command discussions/use cases]], [[Cytoscape_3.0/TunableDiscussion|Tunable discussions/use cases]], [[Cytoscape_3.0/MonitorDiscussion|Monitor discussion/use cases]] ||TBD || ||[[#appModule|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. |
| Line 53: | Line 85: |
| 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.'' attachment:Cyto3ProjectPlan.xls | 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.'' [[attachment:Cyto3ProjectPlan.xls]] |
| Line 57: | Line 89: |
| attachment:ProjectPlan.gif | {{attachment:ProjectPlan.gif}} |
| Line 59: | Line 91: |
| ||<rowbgcolor="#3b9c9c" rowstyle="font-weight: bold;">4 ||Modular System ||Milestone 1 - Layer current code base || || || | ||<rowbgcolor="#3b9c9c" rowstyle="font-weight:bold; ">4 ||Modular System ||Milestone 1 - Layer current code base || || || |
| Line 65: | Line 97: |
|
||<rowbgcolor="#3b9c9c" rowstyle="font-weight: bold;">10 ||Recode Core Interfaces ||Milestone 2 - Replace temporary interfaces with stable, planned interfaces. First relayered system finished || || || ||<rowbgcolor="#ffffe0" rowstyle="font-weight: bold;">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 ||[:Cytoscape 3.0/GraphModelDiscussions:Use Cases/Discussions] ||Based on use cases develop a graph model interface for core usage. Add indexing pattern forfast graph iteration. || || || |
||<rowbgcolor="#3b9c9c" rowstyle="font-weight:bold; ">10 ||Recode Core Interfaces ||Milestone 2 - Replace temporary interfaces with stable, planned interfaces. First relayered system finished || || || ||<rowbgcolor="#ffffe0" rowstyle="font-weight:bold; ">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 ||[[Cytoscape 3.0/GraphModelDiscussions|Use Cases/Discussions]] ||Based on use cases develop a graph model interface for core usage. Add indexing pattern forfast graph iteration. || || || |
| Line 72: | Line 104: |
| ||<rowbgcolor="#ffffe0" rowstyle="font-weight: bold;">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) || || || | ||<rowbgcolor="#ffffe0" rowstyle="font-weight:bold; ">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) || || || |
| Line 77: | Line 109: |
| ||<rowbgcolor="#ffffe0" rowstyle="font-weight: bold;">22 ||IO || || || || | ||<rowbgcolor="#ffffe0" rowstyle="font-weight:bold; ">22 ||IO || || || || |
| Line 83: | Line 115: |
| ||<rowbgcolor="#ffffe0" rowstyle="font-weight: bold;">28 ||View (Presentation) || || || || | ||<rowbgcolor="#ffffe0" rowstyle="font-weight:bold; ">28 ||View (Presentation) || || || || |
| Line 89: | Line 121: |
| ||<rowbgcolor="#ffffe0" rowstyle="font-weight: bold;">34 ||Command || || || || | ||<rowbgcolor="#ffffe0" rowstyle="font-weight:bold; ">34 ||Command || || || || |
| Line 95: | Line 127: |
| ||<rowbgcolor="#ffffe0" rowstyle="font-weight: bold;">40 ||Application || || || || | ||<rowbgcolor="#ffffe0" rowstyle="font-weight:bold; ">40 ||Application || || || || |
| Line 101: | Line 133: |
| ||<rowbgcolor="#ffffe0" rowstyle="font-weight: bold;">46 ||Examine further componentization (OSGi) || || || || | ||<rowbgcolor="#ffffe0" rowstyle="font-weight:bold; ">46 ||Examine further componentization (OSGi) || || || || |
| Line 105: | Line 137: |
| This diagram displays provides lots of information: | |
| Line 106: | Line 139: |
| This diagram displays provides lots of information: | |
| Line 113: | Line 145: |
| attachment:cytoscape3_development_timeline.png | {{attachment:cytoscape3_development_timeline.png}} |
| Line 115: | Line 147: |
|
= Discussions & Useful Information = * [: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:Using Maven with Cytoscape] This includes links to plugins for Eclipse, IDEA and NetBeans as well as descriptions for use with Eclipse. |
= Design 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|Using Maven with Cytoscape]] This includes links to plugins for Eclipse, IDEA and NetBeans as well as descriptions for use with Eclipse. |
| Line 123: | Line 155: |
|
= Related Frameworks and Technologies = From 3.0, new technologies/frameworks will be used for implementation. The following is the list of links to documents related to those frameworks/technologies. |
|
| Line 126: | Line 156: |
|
* OSGi - Cytoscape will be modularized by following this standard. * [http://www.osgi.org/Main/HomePage OSGi Alliance] * [http://felix.apache.org/site/index.html Apache Felix]: Although OSGi is implementation-independent, this implementation will be used as standard development/testing tool. * [http://wiki.ops4j.org OPS4J] Products: This project has a lot of usuful scripts to develop OSGi bundles * [http://www.springsource.com/repository/app/ SpringSource Bundle Repository]: To use existing plain JAR libraries in an OSGi environment, we need to add metadata to it. This repository is a collection of OSGi-ed popular libraries, i.e., repository of OSGi bundles managed by Spring Source. * Dependency Injection Frameworks - One of the scopes of 3.0 is modulalization and make Cytoscape usable as a part of other programs, including server-side application or command -line tools. The following DI frameworks are POJO-base and popular among server-side application developers. * [http://code.google.com/p/google-guice/ Google Guice]: Currently focused on DI only. * [http://springframework.org/about Spring Framework]: De facto standard framework for DI and AOP. * [http://springframework.org/osgi Spring-DM]: Integration of Spring Framework and OSGi * [http://maven.apache.org/ Apache Maven]: 3.0 project will be moved from Ant to Maven. * [http://m2eclipse.codehaus.org/ Maven integration for Eclipse] * [http://mvnrepository.com/ Maven Repository Search] - Note: Cytoscape cannot use most of these libraries directly. To use these, they should be re-packed as an OSGi bundle. * Server-Side / SCA - Once Cytoscape is modulalized based on OSGi, we can use Cytoscape bundles and these frameworks to build server-side applications or web services. * [http://incubator.apache.org/tuscany/ Apache Tuscany]: An open-source implementation of Service Component Architecture. * [http://www.springsource.com/products/suite/applicationplatform SpringSource Application Platform]: OSGi-Spring powered application server. * Scripting Language Support - There are several implementations of scripting languages running on JVM. These will be used to implement scripting feature in Cytoscape. * [http://jruby.codehaus.org/ JRuby]: Ruby scripting language running on JVM. Actively developed by Sun. * [http://www.mozilla.org/rhino/ Rhino]: JavaScript. Bundled with Java SE 6. * [http://www.jython.org/Project/ Jython]: Python implementation. * [http://openjdk.java.net/projects/mlvm/ Da Vinci Machine Project] == Tutorials and References == * [:Cytoscape 3.0/PAX:How to build bundles with Pax-Construct] * [:Cytoscape 3.0/Eclipse:Setup Eclipse for OSGi Projects] * [:Cytoscape 3.0/Spring:How to use Spring Framework in Cytoscape 3] |
= Mini-Retreat Discussions = * [[Cytoscape_3.0/MiniRetreatOne]] * [[Cytoscape_3.0/MiniRetreatTwo]] * [[Cytoscape_3.0/MiniRetreatThree]] |
| Line 159: | Line 163: |
|
= Implementation = * [[Cytoscape_3.0/Developer|Cytoscape 3 Developer's Guide]] = TODO List = * [[Cytoscape_3.0/todo|ToDo]] = Testing Cytoscape 3.0 = * [[Cytoscape_3.0/Enhanced Test Plan|Enhanced Test Plan]] |
Contents
What's New
- Developer's documents update in progress - Kei (3/10/2009)
Current progress on Cytoscape 3.0 development is monitored at /DevelopmentModules
Quick Start
3.0 API -- Please note that this still an active work-in-progress and subject to change at any time!
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 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: RFC 46, RFC 6, RFC 55.
Separate the view from the model. The motivation for this is to use Cytoscape in various headless (or alternatively headed) modes. See: RFC 6, 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: Command Layer Discussions.
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: 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: 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: RFC 44.
Local Attributes. Allow for attributes to be specific to networks in addition to maintaining the current global attributes. See: RFC 31, RFC 37.
Dynamic language support. Implement a built-in support to access Cytoscape API from dynamic (scripting) languages. See: Scripting RFC
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
- 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.
Layer design discussion schedule
Layer |
Discussion organizer |
Description |
Status |
Discussion page |
Start Date |
Mike Smoot |
The core graph model for Cytoscape |
Will resume mid-late April |
May 8, 2008 |
||
TBD |
The view model representation (not the presentation layer). |
TBD |
TBD |
||
TBD |
IO layer (files, web services, databases, etc) |
TBD |
TBD |
||
TBD |
Presentation layer that renders the underlying view models |
TBD |
TBD |
||
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 |
|
TBD |
|
TBD |
|
TBD |
API naming
The following table summarizes the classes that represent a given object in each layer.
Object |
Model |
Presentation |
|
network |
CyNetwork (and CyRootNetwork, CySubNetwork) |
||
node |
CyNode (and CyMetaNode) |
||
edge |
|||
attribute table |
* |
* |
|
row in attribute table |
* |
* |
|
column in attribute table (an attribute) |
* |
* |
* 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.
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 |
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:
- It provides a best (initial) guess of which modules will exist in Cytoscape 3.0.
- It shows some of the dependency relationships between modules.
- It groups modules into layers (based on color).
- Some modules (pink) haven't been put into layers because there is some question about which layer they should go in, but they have been put near the modules where they might belong.
- We will begin discussions at the bottom and work our way up (as indicated by the time arrow). There are tentative numbers assigned to the modules which we will discuss first.
Design Discussions
Using Maven with Cytoscape This includes links to plugins for Eclipse, IDEA and NetBeans as well as descriptions for use with Eclipse.
Mini-Retreat Discussions
Timeline
Release Date: TBD
Implementation
TODO List