Changes between Version 59 and Version 60 of DEVELOPMENT_OVERVIEW


Ignore:
Timestamp:
10/15/09 23:00:42 (10 years ago)
Author:
lpandeff
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DEVELOPMENT_OVERVIEW

    v59 v60  
    1515'''SVN setup'''. Subversion (SVN) is the version control system that we use. On Windows you can use TortoiseSVN (download it from [http://tortoisesvn.net/download]). The official site of SVN is [http://subversion.tigris.org/]. There you can find SVN binaries for other OSs. You must install the Subversion client in order to continue to the next step.[[BR]] 
    1616 
    17 '''Repository setup'''. Once you have installed SVN, you can download the repository on your own machine. Basically, this means you will have your copy of the project. In Windows, just choose a folder on your drive, right click and select SVN Checkout. Further explanation for the repository links / structure / rules for committing can be found at [wiki:PLATFORM_STANDARDS_REPOSITORY]. Just before you continue to the next step, you should know how to submit a file to the repository (for example, your daily report).[[BR]] 
     17'''Repository setup'''. Once you have installed SVN, you can download the repository on your own machine. Basically, this means that you will have your own copy of the project. In Windows, just select a folder on your drive, right click and select SVN Checkout. Further explanation for the repository links / structure / rules for committing can be found at [wiki:PLATFORM_STANDARDS_REPOSITORY]. Before you continue on to the next step, you should know how to submit a file to the repository (for example, your daily report).[[BR]] 
    18181) Create the new file in the desired folder (for reports, it is /manage/reports/{current iteration}/. The format of reports is explained below, in the "Process" chapter). [[BR]]  
    19192) Use "svn add" to schedule the file for committing to the repository. [[BR]] 
    20203) Use "svn commit" to commit it. Attention: committing without comment is NOT allowed! [[BR]] 
    21 A sample book about subversion can be found at [http://svnbook.red-bean.com/].[[BR]] 
     21A sample book concerning subversion can be found at [http://svnbook.red-bean.com/].[[BR]] 
    2222 
    23 '''JDK'''. Since Sophie 2.0 is written in Java, it requires Java Development Kit (JDK) to develop for it, and Java Runtime Environment to run it. JDK can be downloaded and installed from [http://java.sun.com]. [[BR]] 
     23'''JDK'''. Since Sophie 2.0 is written in Java, it requires the Java Development Kit (JDK) to develop for it, and Java Runtime Environment to run it. JDK can be downloaded and installed from [http://java.sun.com]. [[BR]] 
    2424 
    2525'''Maven setup'''. Maven is a software tool for Java project management and build automation. Downloads and installation  
    26 instructions are located at [http://maven.apache.org/download.html]. A tutorial for building with Maven is written here:  
     26instructions are located at [http://maven.apache.org/download.html]. A tutorial for building with Maven has been written and is available here:  
    2727[wiki:PLATFORM_DEPLOYMENT_BUILD_MAVEN]. If you build the project with maven, you would probably need to open  
    28 [source:/trunk/sophie2-platform/old/lib/readme.txt sophie2-platform/old/lib/readme.txt] and read the bottom lines. [[BR]] 
     28[source:/trunk/sophie2-platform/old/lib/readme.txt sophie2-platform/old/lib/readme.txt] and read the lines at the end. [[BR]] 
    2929 
    30 '''Eclipse setup'''.  The software platform we use for developing Sophie 2.0 is Eclipse. First of all, the installation.  
    31 Download the latest eclipse version from [http://www.eclipse.org/downloads/] and install it to your computer. Then, modify your compiler settings according to the [wiki:COMPILER_SETTINGS] document. The next two steps, Subclipse installation and Maven integration, are described in [wiki:PLATFORM_INFRASTRUCTURE_OVERVIEW#EclipsePlug-ins]. The most important for these is that they are eclipse plugins, which integrate the subversion and maven functionalities in Eclipse. The M2 plugin is required for loading our maven project in eclipse. Once you have installed the plugins, you can follow the steps from [wiki:PLATFORM_DEPLOYMENT_BUILD_ECLIPSE], which describes how to import Sophie 2.0 in Eclipse and run the FakeAuthor configuration. [[BR]] 
    32 You already have everything needed to develop for Sophie 2.0. :) 
     30'''Eclipse setup'''.  The software platform we use for developing Sophie 2.0 is Eclipse. First of all, the installation: 
     31Download the latest Eclipse version from [http://www.eclipse.org/downloads/] and install it to your computer. Then, modify your compiler settings according to the [wiki:COMPILER_SETTINGS] document. The next two steps, Subclipse installation and Maven integration, are described in [wiki:PLATFORM_INFRASTRUCTURE_OVERVIEW#EclipsePlug-ins]. The most important for these is that they are Eclipse plugins, which integrate the subversion and maven functionalities in Eclipse. The M2 plugin is required for loading our maven project in Eclipse. Once you have installed the plugins, you can follow the steps from [wiki:PLATFORM_DEPLOYMENT_BUILD_ECLIPSE], which describes how to import Sophie 2.0 in Eclipse and run the FakeAuthor configuration. [[BR]] 
     32You now have everything you'll need to develop for Sophie 2.0! :) 
    3333 
    3434 
     
    3737'''The Goal'''. The most important aspect of a project is its goal. Our project's goal is to take the all of Sophie 1.0's best aspects and to optimize them, while at the same time adding new features and removing others. [[BR]] 
    3838 
    39 '''Schedule'''. The Sophie 2.0 project is organized into approximately 600 tasks, each with one or more revisions (in total approximately 2000). These tasks have several states, and you will learn about them in the next chapter. The tasks are divided into 12 sprints (iterations). Each sprint is approximately one month long. The methodology used for the schedule of the project is not exactly SCRUM, but is similar to it. For more information what SCRUM is, read [http://en.wikipedia.org/wiki/Scrum_(development)]. [[BR]] 
     39'''Schedule'''. The Sophie 2.0 project is organized into approximately 600 tasks, each with one or more revisions (in total approximately 2000). These tasks have several states, and you will learn about them in the next chapter. The tasks are divided into 12 sprints (iterations). Each sprint is approximately one month long. The methodology used for the project's scheduling is not exactly SCRUM, but is similar to SCRUM. For more information as to what SCRUM means, you can read [http://en.wikipedia.org/wiki/Scrum_(development)]. [[BR]] 
    4040 
    41 '''Layers'''. Task names are also grouped in several development layers: 
     41'''Layers'''. Task names are also grouped into several development layers: 
    4242 * PLATFORM: specifies coding standards, platform structure, plugin structure, as well as tools for building the project. 
    4343 * CORE: the smallest layer; it provides fundamental functionalities for every part of the platform. It includes the properties library (ProLib), logging, and modularity. 
    4444 * BASE: provides basic GUI (menus, halos, palettes, layout). 
    45  * MAIN and EXTRA: they contain the main functionality, which makes Sophie 2.0 a complete platform. These two are split according to the dependencies, so that MAIN does not depend on EXTRA. 
    46  * SCS: Sophie community server. It includes the Trac system we use, the Subversion, provides information for the external contributors. 
     45 * MAIN and EXTRA: these contain the main functionality, which makes Sophie 2.0 a complete platform. They are split according to dependencies, so that MAIN does not depend on EXTRA. 
     46 * SCS: Sophie community server. It includes the Trac system we use, the Subversion, and provides information for the external contributors. 
    4747 * S2S: Sophie 2.0 server. This is the server product. 
    48  * SUPPORTING_ARTIFACTS: the project schedule, the backlog and the process are categorized as supporting artifacts. 
    49  * END_PRODUCT: here are a few tasks related to application tuning and creating user help. [[BR]] 
     48 * SUPPORTING_ARTIFACTS: the project schedule, the backlog, and the process are categorized as supporting artifacts. 
     49 * END_PRODUCT: here are a few tasks related to application tuning and the creation of user help. [[BR]] 
    5050 
    51 '''Additional'''. The non-development side of the project is described in the [wiki:PROJECT_OVERVIEW] document. This includes information about Astea Solutions, Sophie, the license we use, and other useful things. 
     51'''Additional'''. The non-development side of the project is described in the [wiki:PROJECT_OVERVIEW] document. This includes information about Astea Solutions, Sophie, the license we use, and other things you may find interesting and useful. 
    5252 
    5353 
    5454 
    5555= 2. The Process = 
    56 This chapter includes the states of each task until it is completed, the rules you have to follow when performing a task, some good/bad examples.[[BR]] 
    57 Generally speaking, every task must first be analyzed, then a design must be made, and finally the design is implemented. If the task is a coding one, its implementation is tested. After each phase, a review is made. The tasks, sorted by iterations, can be looked at [http://sophie2.org/trac/roadmap]. The exact task states and much more are described and regularly updated at [wiki:PROCESS]. This document is fundamental, so read it carefully. Also, tasks are of several different types. For an explanation what the types are, read [wiki:PLATFORM_STANDARDS_GENERAL]. [[BR]] 
    58 Every state of a task is important. However, here are the existing recommendations for performing various actions: 
    59  * Analyzing: [wiki:PLATFORM_STANDARDS_ANALYSIS how to write good analysis]. Please note that when you create an analysis, the wiki page you write it in most probably won't exist. If you are logged in the Trac, you will be asked whether to use a page template. You should use TaskPageTemplate. 
     56This chapter includes the states of each task until it is completed, the rules you have to follow when performing a task, including some good/bad examples.[[BR]] 
     57Generally speaking, every task must first be analyzed, then a design must be prepared, and finally the design can be implemented. If the task is a coding one, its implementation is tested. After each phase, a review is made. The tasks, sorted by iterations, can be looked at [http://sophie2.org/trac/roadmap]. The exact task states and much more are described and regularly updated at [wiki:PROCESS]. This document is fundamental, so read it carefully. Also, tasks are of several different types. For an explanation what the types are, read [wiki:PLATFORM_STANDARDS_GENERAL]. [[BR]] 
     58Every state of a task is important. However, here are our current recommendations for performing various actions: 
     59 * Analyzing: [wiki:PLATFORM_STANDARDS_ANALYSIS how to write good analysis]. Please note that when you create an analysis, the wiki page you write it in most probably won't exist. If you are logged into the Trac, you will be asked whether you want to use a page template. You should use TaskPageTemplate. 
    6060 * Designing: [wiki:PLATFORM_STANDARDS_DESIGN how to write design] - design recommendations. 
    6161 * Coding: [wiki:PLATFORM_STANDARDS_CODE coding standards], [wiki:CODE_SMELLS code smells] (bad code examples), [wiki:LOGGING logging]. [wiki:JAVADOC_CONVENTIONS Javadoc] should also be here. 
    6262 * Testing: [wiki:PLATFORM_STANDARDS_AUTO_TESTS auto tests] (unit / system), [wiki:PLATFORM_STANDARDS_MANUAL_TESTS_R0 manual tests]. [[BR]] 
    63 The process is executed with the help of Trac - the issue tracking system we use. If you have problems with using it, go to [wiki:TracGuide]. 
     63The process is executed with the help of Trac, which is the issue tracking system we use. If you have problems using it, please go to [wiki:TracGuide]. 
    6464 
    6565 
    6666 
    6767= 3. The Product = 
    68 '''Design'''. Here will be some of the main design features, which are present in Sophie 2.0.  
    69  * Plugins: software units. In the context of our project, "plugin" is the same as module or bundle. In Eclipse, they are actually represented as different projects. Have a look at [wiki:PLATFORM_STRUCTURE platform structure]. There you can see where modules are located and what their structure is. 
    70  Decomposition to plugins of Sophie 2.0 is one of the most important things to do for the project. If you need to create a new module, one of the ways to do this is described in [wiki:PLATFORM_DEPLOYMENT_BUILD_ECLIPSE#Creatinganewmodule how to create a new module]. 
    71  * Extensions / Extension points: these are used to reverse the dependencies so that we cannot have cyclic dependencies in the project. The other advantage of extensions is that they provide extensible functionality.  
    72  * Editions: different standalone subsets of the Sophie 2.0 platform. Sophie 2.0 has three editions: Author, Reader and Server. The page dedicated to editions provides information about the [wiki:PLUGIN_EDITIONS_STRUCTURE plugin editions structure]. 
    73  * Distributions: the distribution is the end product a user will see on his/her hard drive after installing the edition. In order to be fully functional, a distribution has to provide executables and/or some other needed resources. The problem here is the way we provide these things, and the solution is the /distrib directory (look again at [wiki:PLATFORM_STRUCTURE platform structure]). [[BR]] 
    74  * High-level design. This refers to the Model-View-Controller (MVC) design pattern. Its purpose is to define how the model and the view interact with each other. There is an MVC tutorial at [wiki:CORE_MVC_BASE]. There is a problem with the standard MVC pattern: it is too complicated for this particular project. This is why Properties are introduced here. So, each model in Sophie 2.0 is defined by a property. This way the controller is replaced by Logics, and this simplifies the whole pattern. The properties are represented by the ProLib library, and you can read the important Properties tutorial here: [wiki:PRO_LIB_CORE_TUTORIAL]. [wiki:PRO_LIB_CORE_CODE_TEMPLATES This page] defines useful code templates for properties. [[BR]] 
     68'''Design'''. Here can be found some of Sophie 2.0's main design features.  
     69 * Plugins: software units. In the context of our project, "plugin" is the same as a module or bundle. In Eclipse, these are actually represented as different projects. Have a look at [wiki:PLATFORM_STRUCTURE platform structure]. There you can see where modules are located and what their structure is. 
     70 Decomposition to plugins of Sophie 2.0 is one of the most important things that can be dome for the project. If you need to create a new module, one way to do this is described in [wiki:PLATFORM_DEPLOYMENT_BUILD_ECLIPSE#Creatinganewmodule how to create a new module]. 
     71 * Extensions / Extension points: these are used to reverse the dependencies so that we do not have cyclic dependencies in the project. The other advantage of extensions is that they provide extensible functionality.  
     72 * Editions: different standalone subsets of the Sophie 2.0 platform. Sophie 2.0 has three editions: Author, Reader, and Server. The page dedicated to editions provides information about the [wiki:PLUGIN_EDITIONS_STRUCTURE plugin editions structure]. 
     73 * Distributions: the distribution is the end product a user will see on his/her hard drive after installing the edition. In order to be fully functional, a distribution has to provide executables and/or some other needed resources. The problem here is the way in which we provide these items, and the solution is the /distrib directory (look again at [wiki:PLATFORM_STRUCTURE platform structure]). [[BR]] 
     74 * High-level design: this refers to the Model-View-Controller (MVC) design pattern. Its purpose is to define how the model and view interact with each other. There is an MVC tutorial at [wiki:CORE_MVC_BASE]. There is a problem with the standard MVC pattern: it is too complicated for this particular project. This is why Properties are introduced here. Therefore, each model in Sophie 2.0 is defined by a property. This way the controller is replaced by Logics and this simplifies the whole pattern. The properties are represented by the ProLib library, and you can read the important Properties tutorial here: [wiki:PRO_LIB_CORE_TUTORIAL]. [wiki:PRO_LIB_CORE_CODE_TEMPLATES This page] defines useful code templates for properties. [[BR]] 
    7575 
    7676 
    7777 
    7878= 4. Extras =  
    79 You will certainly encounter a problem you cannot resolve on your own. You can find help:  
    80  * In the [wiki:FAQ developers' FAQ] section 
    81  * In our mail groups (see the beginning of this document)  
    82  * In our Skype group chat (again, see the beginning of this document)  
    83  * In the Sophie 2.0 forum: [http://sophie2.org/trac/discussion/] [[BR]] 
     79You will likely encounter a problem you will not be able to resolve on your own. You can always find help in:  
     80 * The [wiki:FAQ developers' FAQ] section 
     81 * Our mail groups (see the beginning of this document)  
     82 * Our Skype group chat (again, see the beginning of this document)  
     83 * The Sophie 2.0 forum: [http://sophie2.org/trac/discussion/] [[BR]] 
    8484Useful Links: 
    8585 * [wiki:ImportantDocs Important Documents] [[BR]]