Nodal Inventory

farrightΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 3 μήνες)

249 εμφανίσεις

The GUI Platform Project

Progress Report

Vito Baggiolini & the GP team

Outline


Recall of NetBeans and GP project


Work items executed during First Phase


“Release 0”


requirements and results


Conclusions First Phase


Outlook on Next Phase





[ Technical Motivation ]


Outline


Recall of NetBeans and GP project



Work items executed during First Phase


“Release 0”


requirements and results


Conclusions First Phase


Outlook on Next Phase





[ Technical Motivation ]


Our View (“Project Vision”)


We need to
unify

our GUI development process


New GUI applications should be based on the
same platform


We should
share general
-
purpose components


We should also share Accelerator
-
specific
GUI sub
-
systems
(“modules”)


(e.g. Alarm Screen, Global Cycle Selection, “Page1” display,
Hardware configuration panels, RAD/Scripting console, etc.)



Modules should be
“pluggable”
into different GUI applications



This requires


More functionality than provided by Java/Swing


A good
architecture

and clear development
guidelines



How can it be achieved?


We don’t have the man power to develop a platform ourselves


A good
open
-
source platform
exists: “
NetBeans Platform”

What is Netbeans?


A
GUI development
Platform


Generic

functionality for developing
any GUI Application


A
mature open source project

lead by Sun


Started as a private company in 1997, Open source since 2000


Free version of Sun’s Forte IDE

Platform

Netbeans

Modules

of the IDE

Platform

+

Modules
=

Netbeans IDE

Editor

Debug.

Javadoc

CVS



ANT

EJB dev.

XML


A Java Development Environment (
“Netbeans IDE”
)


The Netbeans IDE is just one application built on top of the
GUI development platform

A Platform for Accelerator GUIs

Beamline

Tuning

Settings

Management

Zone

Acces

RAD/Scripting

JDataViewer

Page1

info

Biscoto

GUIs

Alarm

screen

Cycle

Selection

Explorer

Menus and Toolbars

Windowing System

Part of NetBeans

Project
-
specific

General purpose

Legend:

Why Netbeans?


It adds value to plain Swing and StOpMI


It provides an
architecture
and development

guidelines


It has
generic functionality

needed by all GUI developers


It can easily be combined with
existing Swing code



It is made for
collaborative, multi
-
team development


Proven track record: it is an open source project with several
teams + external contributors



It’s
well done and well organized


Technically sound, standard based


Well
documented


Quality Assurance done by Sun,
tested

by large community

Purpose
(Reason)


Provide a
Common Platform
for Operational GUIs


A
frame
that accepts
“pluggable” GUI modules


General purpose components
(Explorer, Settings panel, etc)


Training + Support for developers


Coordinate

aspects of GUI development


Coordinate requirements


Recommend architecture, “best practice”


Facilitate sharing of existing components “donated” by projects


Reduce man
-
power

needed


Unified developments, less redundance, easier maintenance


Less maintenance (3rd party platform instead of in
-
house)



Continue work of StOpMI with additional requirements

(and anticipating future requirements)

[ Slide presented at Kickoff ]

25
-
July
-
2002

Scope
(Our responsibility)


Produce the Common GUI platform


Gather User Requirements


Select and recommend suitable functionality of NetBeans


Reengineer and integrate existing GUI components (StOpMI,
AscBeans, etc…)


Develop further general
-
purpose GUI components


Provide
Training and Support


Train and support developers
in using the Common Platform


Elaborate written recommendations and guidelines


Migrate existing StOpMI applications

to the new platform


Assure long
-
term
maintenance

of Common GUI Platform



Not inside the scope


Migration of existing
non
-
StOpMI

applications (support: yes)


Enforcing

the adoption of the Common GUI Platform

[ Slide presented at Kickoff ]

25
-
July
-
2002

Objectives (Deliverables)


The Common GUI Platform


The
NetBeans platform

(as provided by Sun)


Reengineered
StOpMI Beans, AscBeans
, etc.


General
-
purpose
components


Documentation



StOpMI applications
migrated to Common Platform



Training and support


Training

courses


Case
-
by
-
case

help for specific questions


Web site with documentation, a mailing list

[ Slide presented at Kickoff ]

25
-
July
-
2002

Milestones (First Phase)


Goal:
Get started quickly

and create confidence


1
-
Aug

Project launched and fully staffed

15
-
Aug

Release Plan of Version 0 agreed with external




developers (based on preliminary requirements)

15
-
Oct

Release 0 is ready (basic functionality)

15
-
Oct

Training and Support for Release 0 is ready



Release 0

consists of
(to be confirmed)
:


NetBeans
Platform

(as provided by Sun)


A few general purpose
components


Executable
example programs

for basic GUI tasks/features


Documentation



~ 1 man year of work for the whole project

[ Slide presented at Kickoff ]

Outline


Recall of NetBeans and GP project


Work items executed during First Phase


“Release 0”


requirements and results


Conclusions First Phase


Outlook on Next Phase





[ Technical Motivation ]


Gathered Requirements


We have
preliminary requirements
from developers in


Operations (PCR and MCR GUIs + environment)


PS/CO Java project (PS Frame + Console Mgr)


Laser Project (Alarm display console)


BiSCoTo (Biscoto GUI Applications)


SPS
-
2001 (Device Explorer, Cycle Selection)


CMW (Device Explorer)


Cesar (Beamline Explorer, Settings Management)


CO/IN (new version of Xcluck)



Release Plan 0

was based on these interviews

Elaborated and Refined Requirements


Through close collaboration with
active users


Clear

requirements motivated by
real needs


Small, incremental development cycles


Frequent mini
-
releases, frequent feedback



These users where working on
real GUIs


Alarms display screen


SPS
-
2001 cycle selection GUI


Cesar Navigator and GUIs for settings handling



Release 0

was developed based on


preliminary requirements


feedback from these early collaborations

“Interpreted” NetBeans in Acc. Context


Scrutinized of NetBeans Functionality & APIs


selected NetBeans
APIs to be used directly


identified
APIs to be tailored

and simplified


identified APIs to
avoid


Tailored NetBeans GUI components for easier use


We provide a set of
ready
-
to
-
use

Explorers, Tables, etc.


Elaborated and implemented
“GP Layer”


Functionality + API to easily populate explorers/tables from
domain classes (explained later)


Defined additional APIs where appropriate


Make stand
-
alone applications independent from NetBeans


Logging API

that can be used both in GUI and domain code


Other work items


Set up
Web server


http://cern.ch/gp


Written Documentation



Set up
innovative
development environment


All code and
documentation under version control


Automatic
“release
-
like” publishing of all web content

from
repository



Outline


Recall of NetBeans and GP project


Work items executed during First Phase


“Release 0”


requirements and results


Conclusions First Phase


Outlook on Next Phase





[ Technical Motivation ]


Functional Requirements
(preliminary)


Common, shareable GUI components + functionality


Generic
: Tree explorer, Settings panel, Table


Accelerator
-
specific
: standard cycle selection, domain
selection, GFA Editor, Knobs, Working Sets, JDataViewer


GUI
Framework Functionality


Workspaces, Tabbed panes, output window, error notification


Menus, toolbars, keyboard shortcuts, pop
-
up menus


Configuration of Menus from
Database


Easy + flexible
reconfiguration

of Menus, toolbars, etc


“Save
-
on
-
exit”, Printing


Customizable Look & Feel


Development + Deployment Environment


Development with JBuilder


Support for
stand
-
alone

development and execution


Deployment via Java Web Start

Non
-
Functional Requirements
(preliminary)


Backward compatibility


Integration of
existing Swing Panels


Use of
existing GUI Bean

components


Maintenance should be done by CO


Maintenance of framework (and common components)


“Fast” response to new requirements


Support for Developers


Ease of use


Training and help for developers


Help in porting of existing applications

Addressed Functional Requirements


Common, shareable GUI components + functionality


Generic: Tree explorer, Settings panel, Table


Accelerator
-
specific: standard cycle selection, domain
selection, GFA Editor,

Knobs
,
Working Sets,

JDataViewer


GUI Framework Functionality


Workspaces, Tabbed panes, output window, error windows


Menus, toolbars, keyboard shortcuts, pop
-
up menus


Configuration of Menus from Database


Easy + flexible reconfiguration of Menus, toolbars, etc


“Save
-
on
-
exit”, Printing


Customizable Look & Feel


Development + Deployment Environment


Development with JBuilder


Support for stand
-
alone development and execution


Deployment via Java Web Start


Green = done;
orange = partly done;

gray = not done

Addressed Non
-
Functional Requiremts


Backward compatibility


Integration of existing Swing Panels


Use of existing GUI Bean components


Maintenance should be done by CO


Maintenance of framework (and common components)


“Fast” response to new requirements


Support for Developers


Ease of use


Training and help for developers


Help in porting of existing applications

Green = done;
orange = partly done;

gray = not done

Release 0 Deliverables


NetBeans platform

(as provided by Sun)


with installation instructions


GUI Platform
Release 0 distribution


GP Library (Jar file)


Source code (WinZip Archive)


Executable “getting started” examples



Documentation


Our functionality is documented by us


References to NetBeans documentation where possible


Practical
how
-
to documents for specific tasks


F.A.Q. (to be built up)

List + ListTable

Tree + TreeTable

MultiList Explorer

“GP Layer”


Purpose:


simplify use of NetBeans GUI components


Facilitate separation of generic GUI code from domain specific
code


The idea: Leverage the
JavaBeans standard


domain classes follow JavaBeans conventions


(i.e., with
setXxx() / getXxx()

methods)


GP GUI components know how to display such domain classes


GP Layer = implementation of this functionality + API


GP Layer API substitutes a part of NetBeans API

[ Others NetBeans APIs are used directly ]



Why JavaBeans?


because NetBeans uses it extensively


because it is a standard

GP Layer Example: Settings Panel

Domain class

(compliant with JavaBeans specs
)


class MagnetSettingsJB {


String
getName
() {..}


double
getCurrent
() {..}


setCurrent
(double val) {..}


double
getOrigCurrent
() {..}


Action[]
getActions
() {..}

}


GP Table component
“understands” domain logic class


Displays
one line per instance

of the domain class

One column per property, editable properties in blue


Shows selection
-
sensitive
actions in Pop
-
up menu


Separation of GUI from domain
-
specific code


GP Table Component is not specific to Magnet Settings

Support for existing code and habits


GP provides users with
smooth upgrade path


Existing
components

(e.g. ASC/StOPMi) shall be used


Existing
Swing Panels
can be easily integrated


Code
templates

and
base classes

can be reused


Users can choose the
level of integration

they want


Strong integration: use NetBeans GUI functionality


Weak integration: just integrate your Swing panels into menus


Only
one person per team
really has to know GP


Any IDE can be used to develop panels & modules


We recommend NetBeans IDE for integration and testing


Stand
-
alone execution


Panels with
weak integration

can be
executed stand
-
alone


If you use NetBeans shared components, you need the Platform
to run them

Outline


Recall of NetBeans and GP project


Work items executed during First Phase


“Release 0”


requirements and results


Conclusions First Phase


Outlook on Next Phase





[ Technical Motivation ]


State of Work after First Phase


Code of Release 0 is ready



More functionality than planned in original Release Plan


Continuously used and validated by 3 projects


All features required by those 3 projects


Documentation is
slightly behind


Documentation is ready at 80%, not all on Web yet


Preliminary training material available, rest in preparation



Estimation:
2 man weeks

needed to complete




We will be
ready for evaluation phase

with external
developers in 1
st

week of November

NetBeans is only one (necessary) Part


NetBeans is a
generic
platform


the supportive structure of non
-
trivial GUIs


provides general purpose GUI components + functionality


allows for development of “pluggable” modules


But we also need
accelerator specific
things:


GUI beans ASC, StOpMI and more


Accelerator
-
specific components


Existing Applications integrated as Modules


The Gui Platform is a combination of both

Beamline

Tuning

Settings

Management

Zone

Acces

RAD/Scripting

JDataViewer

Page1

info

Biscoto

GUIs

Alarm

screen

Cycle

Selection

Explorer

Menus and Toolbars

Windowing System

Pros and Cons of GP/NetBeans


It can cover current and anticipated requirements


It is well done


It is standard
-
based


It is well documented


It has a good and mature architecture


Modular, made for reuse and sharing of components


Clean separation of GUI from domain code


It is maintained and tested by Sun and the community



GP is married with the NetBeans platform


Sun might stop supporting it


It needs initial investment in learning


For some tasks you need to use NetBeans IDE

Outline


Recall of NetBeans and GP project


Work items executed during First Phase


“Release 0”


requirements and results


Conclusions First Phase


Outlook on Next Phase





[ Technical Motivation ]


Next Steps


Formalize User Requirements



Train external developers


Carry out
Evaluation phase

with external developers



Develop Final Release


add missing functionality (according to URD and feedback
from evaluation phase)


Improve documentation (How
-
to’s, F.A.Q. as needed)



Migrate/integrate
existing applications

Proposed Milestones (Phase 2)


Goal: Produce
final deliverables

30
-
Nov

Final
URD published

and agreed on

30
-
Nov

Release Plan for final version published


1
-
Feb

Long
-
term maintenance agreed on

15
-
Mar

Final Release of Common GUI Platform ready

30
-
Mar

StOpMI applications have been ported



We
confirm

a total need of
1 man year of work



Possible additional tasks


Seamlessly integrated PS Framework?


Expertise & support for Console Manager Project?


Unified Equipment Access?

Strategic Decisions


Do it yourself


Start with low functionality…



…develop new things when
required


Spend time continuously on
evolutive maintenance



RAD and “throw
-
away” GUIs




Limit tasks of non
-
expert
people




Use 3
rd

party products


Start with complete
functionality…


…open up existing features
when required


Spend time initially on
tailoring



Continuously evolving
permanent GUIs



Invest in training non
-
expert
people

The Case for Architecture


Software Architecture is hard to understand


Computer Hardware Architecture

is easy to understand:


Modular Structure


Mother board: CPU, main memory, memory bus, extension bus,
timing distribution, power supply, hard disk


Extension Modules: Network Card, TV Card, Scope Card


Clear Interfaces: Bus specs, PCMCIA specs


Components


Standard: CPU, RAM, Video chip set, hard disks, …


Domain specific: ASIC or VLSI Chips, Hardware Modules


Clear Guidelines for developers


Inter
-
module communication goes through bus, no “flying” wires


Nobody questions importance of Hardware Architecture!


Why question importance Software Architecture?!

NetBeans Software Architecture


Modular Structure


NetBeans Core services: Windowing, Actions + Node
infrastructure, support for deploying modules, save
-
on
-
exit


Extension modules: Alarm Screen, Page
-
1, Cesar Navigator


Clear Interfaces: APIs of Modules


Components


GUI components: Menus, Toolbars, Explorers, Tables, Output
Windows


Domain components (e.g. ASC & StOpMI Beans, GFA editor)


Clear Guidelines for developers


how to build an Explorer based on JavaBean domain class


How to create a menu item that invokes an action of the
domain class


Architecture is not only important for Hardware…

Architecture = APIs + Guidelines


Module


[XML]

API provided
by Platform







Explorer

Menus

Toolbars

Output Windows

API provided by Module

Explorer

Menus

Toolbars

Output Windows

Modular Architecture of NetBeans

Module


write(“output message”)

getNodes()

getActions()

MyMenu

Jar
-
file

with XML

description

Why care about Architecture?


A good architecture facilitates building
well structured

and
effective

program


Common functionality is implemented through common
concepts and with common mechanisms


Architecture makes sure
parts

provided by different
developers
fit together


Thanks to modularity, clear interfaces and guidelines


Development can be done independently


A system with a coherent Architecture is
easier to
understand


Easier to adapt and maintain


Elaborating the architecture is very
challenging



difficult to get right at the first try


Lets use a proven architecture

like the one of NB

Why separate domain from GUI code ?


Example of separation of code: GP table + JavaBeans


GP table can explore any compliant domain class

(could be alarm state, equipment, beam process)


Domain class does not have to know in what component it is
visualized (could be Explorer, Settings Panel)


Advantages: GUI component and domain class are
independent


Can be developed and maintained independently


Can be combined with other elements



“Separation of concerns” is fundamental to OO


“A class shall do one thing and do it well”


Several classes can be combined to build more elaborate
functionality