NinJo - Frameworks, Applications and Release Distributions - Development and Software Process

DWD EGOWS 2004, Haucke, NinJo frameworks and software development process

NinJo - Frameworks, Applications and Release Distributions -

Development and Software Process

Sibylle Haucke, DWDEGOWS 2004 - Potsdam


OverviewOverview

Part 1 :NinJo frameworks and applications NinJo architecture NinJo frameworks overview (reminder) NinJo frameworks - new features and extensions Building client applications with NinJo

Part 2: NinJo software process and release distribution How to organise the work in teams distributed in Europe and

Canada ? Software development process and quality management NinJo going productive : preparation of release distributions


NinJo architectureNinJo architecture

ExportServices

Products

Client Tier

Data Server

Infrastructure Services

ConfigurationServer

Data Storage

Monitoring

Data Storage

Server Tier

ServerInfrastructure

Corba NamingService Event Service Authentication

AuthorizationServer

Management

BatchControl

NinJoBatch

Local ClientStorage

(Geography Data)

Client

External Storage(eg. Archive)

Databases

Prot

ocol

like

eg.

JD

BC

RadarServer

Data Storage

GridServer

Data Storage

Sat Server(Product)

Data Storage

PointServer

Data Storage

ImportServices

Point

Grid

Sat

Radar

ScienceModules

ForecastGuidance

Cell Detection

External Systems

Dis

trib

utio

n

Decoding

Point Layer /Application

Grid Layer /Application

Sat Layer / Application

Radar Layer /Application

Cor

ba (I

IOP)

Cor

ba (I

IOP)

or F

iletr

ansf

er


NinJo architectureNinJo architecture

3 main tiers : client, server, middleware client tier:

NinJo client (GUI) NinJo batch client

server side: data servers and services event service authentication service import (data+products) export (products) monitoring and alerting

server side: science modules OOG (guidance's) : under construction cell/storm detection (planned)


NinJo frameworks overviewNinJo frameworks overview

NinJo is a building kit and a collection of applications as well

it consists of: Frameworks on the one hand Applications : independent windows or integrated components

(Layers) on the other hand, with or without GUI (batch) Applications use the frameworks and must follow unique design

rules Applications are special in respect to their special (main) data type,

window layout, event handling and controlling (event based, time controlled,..)

Applications provide Gui components and concrete graphical representations of data

Frameworks itself use NinJo frameworks



The connection between frameworks, base implementations and runnable applications is the configuration Configuration (XML) is the construction draft for the building kit barely imaginable, how many variants of NinJo applications are

possible NinJo is configuration driven: NinJo can start with one window, containing several maps or with

just a window containing a Meteogram, as well as with lots of windows on several displays - only a question of the used configuration



What do we call a framework in NinJo context? A separate software module (or sub tier) inside NinJo client Similar to a software library or API Consists of interfaces and base classes Based on other NinJo frameworks and existing JAVA classes Is used by several applications inside NinJo Implementation of the frameworks is most generic They are configurable themselves (even the configuration manager)

How to ensure the usability of the frameworks? follow the OO design patterns and standards configurability with XML template pattern for compatible applications MVC pattern for PAC agents backward compatible extensions and changes



3 kinds of frameworks common : used by client and server applications

configuration error handling and logging Id (unique identifications for data types, elements ..) i18n client access layer (data access) math (algorithms, projections) communication units concurrency (threads)



server : only used on server side basic server implementation import system

client : only used on client side PAC (Presentation Abstraction Control: the building kit for client

applications) PAC basic framework derived : Layer framework derived : diagram framework derived : application (Toplevel) framework

GOF (graphical objects factory) : 2d, 3d graphics, several devices vislib and visualizers : technical visualisation GUI standard components


NinJo client frameworks - new featuresNinJo client frameworks - new features

PAC (Presentation-Abstraction-Control) 3 level agent hierarchy

– BottomLevel (Layers)– Intermediate level (diagrams, charts, layercontainer)– Toplevel : applications like: Mainwindow, CrossSection,

SingleScene– different implementations of each level possible– GUI of the client is composed by the Views of the agent hierarchy

recursively layout management for batch products and printouts properties and base configuration - see PAC diagram framework multithreading support (NjJob) support for creation of Toplevel Agents (= Applications)

Ctrl

ModelView



client access layer (client/server-communication) jar file service data cache

cache API sharing data between components faster data access less memory configurable

GOF unified GOF : usage of 2D/3D now transparent

same methods and classes for 2d and 3d animated canvas for animations exportable canvas for export of graphic to file formats (PostScript) overlay functionality added (for the dragging of objects)

„Severity“

20021216

20021217

20030309

3.50.13.00.1 1.0

2010 1 11

x y az b c d

3

e

Root

Level Key„Ozon“

„Date“

„Altitude“

Level 1

Level 2

Level 3

Level 4



GUI form layout usage (JGoodies) standard components:

JFontChooser Input fields spinner button ColorChooser

Editing of data modification deletion write back to the server or file system


NinJo server frameworks - new featuresNinJo server frameworks - new features

new: export system generic trigger, reader, writer

Zip/Jar as virtual filesystem - useful for MetObjects server Configuration server

under construction NinJo Naming Service introduction of authentication, authorisation event service


framework changes- avoid migration effortframework changes- avoid migration effort

architectural principle: separation of concerns change the fwk’s backward compatible use interfaces for decoupling of objects “extensions” for PAC

we invented the “extensions” for PAC editing extension cross section extension 3d extension

add new functionality to frameworks without migration effort for the applications

only those applications, which want to contribute to the extension, have to implement something


NinJo client applicationsNinJo client applications

What is a “client application” in NinJo? a collection of classes and configurations can be aggregated to an existing application (if Bottomlevel or

Intermediatelevel) or act as a standalone application (if Toplevel) can aggregate other components has an own configuration can be installed separately

NinJo can start with only one or with more Toplevel application(s)

How to create a “client application” in NinJo? use the frameworks derive from basic applications implement the special part (visualisation, data container classes) follow the architectural patterns and templates create a configuration

<?xml version="1.0" encoding="UTF-8" ?>

<NinJoCfg><sceneControllerRef name="app" hasGUI="true"

className="org.ninjoworkstation.client.appl.mainwindow.ControllerImpl"

configName="training_workspace_mar_11_2004"/>

<!–- optional more toplevel agents --><sceneControllerRef name="app" hasGUI="true"

className="org.ninjoworkstation.client.appl.singlescene.ControllerImpl"

configName="empty"/>

</NinJoCfg>


client (NinjoMain) configuration example



layers Geovector Georaster layer Surface layer upper air layer Satellite layer Radar layer SCIT Grid layer Flow layer ....



toplevel applications (secondary windows) SimpleMeteogram



toplevel applications AutoMon : Monitoring and EventService (draft)



toplevel applications SingleScene



MainWindow (Toplevel) and 2D-LayerContainer


OverviewOverview

Part 1 :NinJo frameworks and applications NinJo architecture NinJo frameworks overview (reminder) NinJo frameworks - new features and extensions Building client applications with NinJo

Part 2: NinJo software process and release distribution How to organise the work in teams distributed in Europe and

Canada ? Software development process and quality management NinJo going productive : preparation of release distributions


NinJo - management of work in distributed teamsNinJo - management of work in distributed teams

Tools source code management : Perforce document storage : Perforce IDE’s : Eclipse, Netbeans, IntelliJ - question of taste build and class generation support : Ant bug tracking system (Bugzilla) design tools: Together static code analysis: Together dynamical analysis: JProbe test tools: JUnit, JTest



Tools - Perforce for source and document depot



Tools - IDE, e.g. :Eclipse, IntelliJ or Netbeans



Tools - Apache Ant generating of JAVA classes for i18n, configuration and CORBA supporting the build process

compiling the JAVA classes creation of JAR - files

generating of installation scripts from templates generating of run scripts for servers and client from templates see http://ant.apache.org/



Tools - Bugzilla : Bug tracking system



rules well defined and documented software development process

starting with requirements specification for each component Design document for each component review process (and meetings) for documents and code QM measurements

well defined software architecture , package structure and distribution of work

naming conventions : JAVA packages and Perforce labels code freeze dates : for frameworks first, for applications later branching the code lines after a release to ensure bugfixing

possibility



framework and API development developed by the best educated team members, supported by

consulting several locations develop frameworks, server or infrastructure

components locations, developing a framework, simultaneously develop at least

one application ( to test the framework and to understand the application developers)

framework developers need tight contact to each other

communication regularly CD meetings : meeting of all local chief designers report of locations, planning the next steps and discussing / deciding

architectural solutions telephone conferences emails



application development each location team develops “his” components:

as few interfaces between the locations as possible to let the teams work independently as long as possible

full responsibility on all aspects of a component (e.g. layer), from data import on server side up to the visualisation

JAVA package structure : if possible, only one team should develop inside one JAVA package avoid “crossing” development

education 1 week developers training, prepared by architecture team (CD) and

framework developers (once a year) train the usage of frameworks train the usage of the tools remind the software development process and quality standards


NinJo Software development process and QMNinJo Software development process and QM

4 phases of software development process

specification design realisation qm



Quality management starts with the documents: scheduling of QA tasks, 8 steps/measures

1. requirements document

2. test case description

3. design document

4. code review

5. static analysis

6. performance analysis

7. test case results

8. JAVA Help



Continuos QM during realisation phase

design realisation QMspecification

Implementation JavaDocUpdate Design-

DocumentationPartial code reviews

TCC-QA

Performance analysis

Improve code quality

CodeReview.xls

CodeAudit.xlsCodeDynamicalAnalysis.xls

Realisation with continuos QM


CodeDynamicalAnalysis.xls


design Real. QMspecification

Code review

QA:audit

Integrationtest

FunktionalTests : testcases

Final testsPerformance testsreview the final

design document

TestCasesResults.doc

Release-label

CodeReview.xls

CodeAudit.xls

QM - the final tests


Preparing a release- working stepsPreparing a release- working steps

code freeze : each location:

check in the last changes create the RfA- labels for frameworks and all applications: responsible

are the distributed teams

integration phase integration team:

synchronize the RfA labels in the predefined order test the correctness of the labels try the build process

– build all client and server applications create the Release label

Release label available



Perforce - synchronizing the Release label Eclipse/IntelliJ/Netbeans..: run Ant script

select the “DVD” target wait 5 minutes

find on the disc: DVD1 and DVD2 directories, containing: whole NinJo software for server and client whole configuration installation scripts templates for run scripts

copy the Geo data and (if needed) demo data copy a JRE (JAVA runtime environment), inclusive extensions

(third party Jar-files) create the DVD images burn the DVDs



automated release building with Ant


Installing a NinJo releaseInstalling a NinJo release

directly from the DVD Client

GUI driven : just input the target directory input the server name for live server

fully automated installation starts

demo servers GUI driven :

just input the target directory fully automated installation starts

for live server installation additionally some manually configuration needed configure the data import and delivery


Installing a NinJo releaseInstalling a NinJo release

release 0.8 : beanshell, Ant beanshell for customisable installation procedure and run scripts see http://www.beanshell.org/ just correct the root folders and click “install”

release 0.9 : IzPack, Ant IzPack for customisable installation procedure see http://www.izforge.com/izpack/

NinJo - Frameworks, Applications and Release Distributions - Development and Software Process

Documents

Transcript of NinJo - Frameworks, Applications and Release Distributions - Development and Software Process