The GUI Platform Project Progress Report Vito Baggiolini & the GP team

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 ]



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

Modulesof the IDE

Platform +Modules =Netbeans IDEEditor 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

BeamlineTuning

SettingsManagement

ZoneAcces

RAD/Scripting JDataViewer

Page1 info

BiscotoGUIs

Alarmscreen

CycleSelection

Exp

lore

r

Menus and Toolbars

Windowing SystemPart 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


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


25-July-2002

Milestones (First Phase)• Goal: Get started quickly and create confidence

1-Aug Project launched and fully staffed15-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




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



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

Gre

en

= d

one

; ora

ng

e =

par

tly d

one

; gra

y =

no

t do

ne

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

Gre

en

= d

one

; ora

ng

e =

par

tly d

one

; gra

y =

no

t do

ne

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



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 1st 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

BeamlineTuning

SettingsManagement

ZoneAcces

RAD/Scripting JDataViewer

Page1 info

BiscotoGUIs

Alarmscreen

CycleSelectionE

xplo

rer

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



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 3rd 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 PlatformExplorer

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-filewith XMLdescription

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

Documents

The GUI Platform Project Progress Report Vito Baggiolini & the GP team