View
221
Download
3
Category
Tags:
Preview:
Citation preview
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
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
[ 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 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
[ 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
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)
“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 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
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 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
Recommended