Apostila Vsual Age English

VisualAge Generator Version 4 System Development Guide
Pat McCarthy, Guillaume Hetu-Dandurand, Stefano Sergi
International Technical Support Organization www.redbooks.ibm.com
SG24-5467-00
SG24-5467-00
International Technical Support Organization
VisualAge Generator Version 4 System Development Guide October 1999
Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix E, Special Notices on page 307.
First Edition (October 1999) This edition applies to VisualAge Generator V4: VisualAge Generator Developer for OS/2 and Windows NT Version 4.0, 5697-G98 VisualAge Generator Server for OS/2, AIX, Windows NT, HP-UX and Sun Solaris Version 4.0, 5639-G97 VisualAge Generator Templates for OS/2 and Windows NT, 5639-H09 Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California 95120-6099
Copyright International Business Machines Corporation 1999. All rights reserved

Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii The Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Part 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. VisualAge Generator V4 Overview . . . . . . . . . . . . . . 1.1 VisualAge for Java Interoperability . . . . . . . . . . . . . . . . . . . . . . 1.2 Functional Enhancements to VisualAge Generator . . . . . . . . . 1.2.1 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Object Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 VisualAge Generator Templates Enhancements . . . . . . . 1.2.4 SUN Solaris Runtime Support . . . . . . . . . . . . . . . . . . . . . 1.3 Web-Based and e-business Enhancements . . . . . . . . . . . . . . . 1.3.1 Development Support for WebSphere Application Server . 1.3.2 Enterprise Java Bean Support . . . . . . . . . . . . . . . . . . . . . 1.4 VisualAge Generator Automated IC Packaging . . . . . . . . . . . . 1.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 GUI Packaging Options . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 Automated IC Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 . .4 . .5 . .5 . .6 . .7 . .7 . .7 . .8 . .9 . .9 . .9 . 10 . 10 . 13 . 13 . 14 . 15 . 16 . 17 . 19 . 19 . 20 . 20 . 21 . 22 . 24 . 24 . 24 . 25
Chapter 2. Java-Based Version of VisualAge Generator . . . . . . . . . . . . 2.1 Workbench Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Workbench Extensions for VisualAge Generator . . . . . . . . . . . . . 2.1.2 Organization of VisualAge Generator Parts in VisualAge for Java 2.1.3 VisualAge Generator Parts in the Workspace . . . . . . . . . . . . . . . . 2.1.4 Class and Method Mapping for VisualAge Generator Parts . . . . . 2.1.5 Part Name Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.6 Source Management and Organization in VisualAge for Java. . . . 2.2 Java (GUI) Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Free-form Surface Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Table and Record Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Function Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Program Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Communication Session Information . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Making Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copyright IBM Corp. 1999
iii
2.3 VisualAge Generator Program 2.3.1 Testing . . . . . . . . . . . . . . 2.4 Generation . . . . . . . . . . . . . . . 2.4.1 4GL Part Generation . . . 2.4.2 Java Client Generation . .
Definition . ......... ......... ......... .........
. . . . .
. . . . .
. . . . .
.. .. .. .. ..
. . . . .
. . . . .
. . . . .
. . . . .
.. .. .. .. ..
. . . . .
. . . . .
. . . . .
.. .. .. .. ..
. . . . .
. . . . .
. . . . .
. . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 28 . 28 . 29 . 29 . 30 . 35 . 35 . 35 . 39 . 40 . 41 . 42 . 42 . 43 . 44 . 45 . 47 . 48 . 49 . 51 . 51 . 52 . 53 . 55 . 60 . 60 . 62 . 67 . 75 . 80 . 85
Chapter 3. Introduction to VisualAge Generator V4 Enhancements . 3.1 Function Logic Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Loose Typing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Syntax and Part Type Changes . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Object Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Data Exchange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Script Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Object Scripting Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6 Reusable Object Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7 Event Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 VisualAge Generator Templates Enhancements . . . . . . . . . . . . . . . 3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Generation support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Generation Parameter Management during Development . . . . 3.4 WebSphere Rapid Application Development . . . . . . . . . . . . . . . . . . 3.4.1 Native (Java-Based) Development . . . . . . . . . . . . . . . . . . . . . . 3.4.2 The VisualAge Generator WebSphere RAD Solution . . . . . . . . 3.4.3 Web Transaction Program Development . . . . . . . . . . . . . . . . . 3.4.4 Web Transaction Program System Structure Options . . . . . . . . 3.4.5 Generation and Implementation of a Web Transaction . . . . . . . 3.4.6 Runtime Configuration Samples . . . . . . . . . . . . . . . . . . . . . . . .
Part 2. Primer for Developer on Java Team Development . . . . . . . . . . . . . . . 89 Chapter 4. VisualAge for Java Team Development Environment . 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. . . . . . . . . . . . . . 91 . 91 . 91 . 93
Chapter 5. Understanding the Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.1 Program and System Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.1.1 Program Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
iv
VisualAge Generator Version 4
5.1.2 System Elements . . . . . . . . . . 5.2 Version Management . . . . . . . . . . . 5.2.1 Open Edition . . . . . . . . . . . . . 5.2.2 Version. . . . . . . . . . . . . . . . . . 5.2.3 Scratch Edition . . . . . . . . . . . . 5.2.4 History of Program Elements . 5.3 Configuration Management . . . . . . 5.3.1 Releasing Program Elements . 5.3.2 Releasing Methods . . . . . . . . 5.3.3 Releasing Classes . . . . . . . . . 5.3.4 Releasing Packages. . . . . . . . 5.4 Change Management . . . . . . . . . . . 5.4.1 Ownership . . . . . . . . . . . . . . . 5.4.2 Team Roles . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 98 . 100 . 101 . 101 . 103 . 103 . 104 . 104 . 105 . 105 . 106 . 106 . 106 . 108 . 113 . 113 . 115 . 117 . 119 . 121 . 123 . 125 . 125 . 127 . 127 . 128 . 128 . 129 . 130 . 130 . 131 . 132 . 135 . 135 . 136 . 137 . 138 . 139 . 140 . 140 . 141
Chapter 6. A Developer on Java Team Environment Quick Start . . 6.1 Functional Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Class Management (Application Becomes Package) . . . . . . . . . . . 6.3 Container Management (Configuration Map Becomes Project) . . . 6.4 System Structure Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Organizational Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Using Project List Parts to Implement a Layered Project Structure .
Chapter 7. Defining a Developer on Java Development Process . . . 7.1 Choosing a VisualAge Generator Solution . . . . . . . . . . . . . . . . . . . . 7.2 Available Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Traditional Development Environment . . . . . . . . . . . . . . . . . . . 7.2.2 One Package per Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 One Package per Programmer . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4 The Package-to-Function Relationship Answer . . . . . . . . . . . . 7.3 Defining Project and Package Structures to Organize Code . . . . . . . 7.3.1 Project to Package Ratios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2 Package Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 Package-to-Function Container Breakdown Example . . . . . . . . 7.4 Representing Stages of Development . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Project Sets for Each Development Phase . . . . . . . . . . . . . . . . 7.4.2 Moving Code between Development Phase Projects . . . . . . . . 7.4.3 Managing Development Phases Using Project List Parts . . . . . 7.4.4 Moving Code between Development Phase Project List Parts . 7.4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Package Management for Java Client Generation . . . . . . . . . . . . . . 7.5.1 Source Package as Java Client Generation Target Package . . 7.5.2 Common Package as Java Client Generation Target Package .
Part 3. Development Scenario Using Developer on Java . . . . . . . . . . . . . . 143 Chapter 8. Scenario: Designing the Development Process . 8.1 Introduction and Objectives . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Team Environment Development Process Definition . . . . . 8.2.1 Identify System Functions to Migrate . . . . . . . . . . . . . 8.2.2 Team Environment Container Structure Definition . . . 8.3 Partial TUI System Migration . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Moving Source Code to the Team Environment . . . . . 8.3.2 Validation and Versioning the Migrated Code . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 . 145 . 146 . 146 . 148 . 150 . 150 . 152 . 153 . 153 . 153 . 153 . 163 . 167 . 167 . 168 . 170 . 174 . 174 . 175 . 175 . 176 . 176 . 177 . 178 . 179 . 180 . 181 . 181 . 183 . 184 . 187 . 187 . 188 . 189
Chapter 9. Migrating an Existing System to Developer on Java . 9.1 Team Environment Development Process Definition . . . . . . . . . 9.2 Partial TUI System Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 Moving Source Code to the Team Environment . . . . . . . . . 9.2.2 Validation and Versioning the Migrated Code . . . . . . . . . . .
Chapter 10. GUI Development with Developer on Java . . . . . . . . . . 10.1 Development of New VisualAge for Java GUI System . . . . . . . . . 10.1.1 Component Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 System Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.3 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Global Reusable Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 IsaActionEventHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 IsaErrorRoutine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 IsaLogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.4 IsaComboBox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.5 IsaGroupBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.6 IsaTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.7 IsaTextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 System Reusable Components . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 CustomerListPanelResource . . . . . . . . . . . . . . . . . . . . . . . . 10.3.2 CustomerListPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.3 CustomerDetailPanelResource. . . . . . . . . . . . . . . . . . . . . . . 10.3.4 CustomerDetailPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Java GUI Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1 VisualAge for Java AppletCustomerListApplet . . . . . . . . . 10.4.2 VisualAge for Java ApplicationCustomerListApplication . . 10.4.3 VisualAge for Java ApplicationCustomerDetailApplication
vi
Part 4. Primer for Developer on Smalltalk Team Environment . . . . . . . . . . 191 Chapter 11. Developer on Smalltalk Development Environment . 11.1 Team Environment Images and Libraries . . . . . . . . . . . . . . . . . 11.2 Software and Management Components . . . . . . . . . . . . . . . . . 11.3 Versioning and Component Container Release Processing . . . 11.4 Component Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 . 194 . 195 . 196 . 197 . 199 . 200 . 202 . 203 . 209 . 210 . 212 . 213 . 214 . 217 . 217 . 218 . 220 . 221 . 225 . 226 . 227 . 228 . 231 . 232 . 232 . 232 . 233 . 233 . 234 . 234 . 239 . 243 . 247 . 247 . 249
Chapter 12. Smalltalk Architecture and Team Environment Support 12.1 The Team Environment Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 The Image in Smalltalk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Library-Image Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 13. Software and Management Components 13.1 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Methods in VisualAge Generator . . . . . . . . . . . . . . 13.3 Applications and Subapplications . . . . . . . . . . . . . . 13.4 Configuration Map . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 14. Version, Edition, and 14.1 Management of Editions. . . . . 14.2 Version Management . . . . . . . 14.3 Scratch Edition. . . . . . . . . . . . 14.4 Release Process . . . . . . . . . . . . . . . .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. ..
Release Management . ................... ................... ................... ................... . . . . .. .. .. ..
Chapter 15. Component Roles and Responsibilities . 15.1 Configuration Map Manager . . . . . . . . . . . . . . . . . . 15.2 Application Manager . . . . . . . . . . . . . . . . . . . . . . . 15.3 Class Owner and Class Developer . . . . . . . . . . . . .
Chapter 16. Developer on Smalltalk Development Process Definition . 16.1 Understanding Developer on Smalltalk Team Environment . . . . . . . . 16.1.1 VisualAge Generator Team Environment Integration . . . . . . . . . 16.1.2 VisualAge Generator Implementation Issues . . . . . . . . . . . . . . . 16.1.3 Development Process Objectives . . . . . . . . . . . . . . . . . . . . . . . . 16.1.4 Initial Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2 Managing the VisualAge Generator Development Process. . . . . . . . . 16.2.1 Serial Versus Concurrent Development . . . . . . . . . . . . . . . . . . . 16.2.2 Identifying a Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.3 Testing the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3 Implementing Serial Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.1 Working with Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.2 Working with Configuration Maps . . . . . . . . . . . . . . . . . . . . . . . .
vii
16.3.3 Naming Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4 Organizational Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.1 Data Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.2 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.3 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.4 Common Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.5 Application and Subapplication Organizational Example
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
.. .. .. .. .. .. ..
. . . . . . .
. . . . . . .
. 252 . 252 . 252 . 253 . 254 . 255 . 255
Part 5. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Appendix A. Workspace Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 A.1 Managing Program Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 A.2 Project Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 A.3 Package Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 A.4 Management query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 A.5 Project Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 A.6 Managing Resource Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 A.6.1 Using Shared Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 A.6.2 Managing Resources by Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Appendix B. The Team Development Process . . . . . . . . . . . . . . . . . . . . . . . . . 269 B.1 Activity Patterns for Daily Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 B.1.1 The Basic Development Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 B.1.2 Single Package, Single Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 B.1.3 Single Package, Multiple Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 B.1.4 Multiple Packages, Multiple Developers . . . . . . . . . . . . . . . . . . . . . . . . . . 276 B.1.5 Multiple Parallel Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 B.2 Project Wrapup and Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Appendix C. Program Element State Transitions . . . . . . . . . . . . . . . . . . . . . . 283 C.1 Project State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 C.1.1 Not Existing -> Open Edition (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 C.1.2 Not Existing -> Repository Only (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 C.1.3 Repository Only -> Version/Open Edition (3) . . . . . . . . . . . . . . . . . . . . . . 285 C.1.4 Version -> Open Edition (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 C.1.5 Open Edition -> Version (5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 C.1.6 Version -> Scratch Edition (6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 C.1.7 Scratch Edition -> Open Edition (7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 C.1.8 Scratch Edition -> Not Existing (8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 C.1.9 Version/Open Edition -> Repository Only (9) . . . . . . . . . . . . . . . . . . . . . . 289 C.1.10 Repository Only -> Not Existing (10). . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 C.2 Package State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 C.2.1 Not Existing -> Released Open Edition (1) . . . . . . . . . . . . . . . . . . . . . . . . 291
viii
C.2.2 Not Existing -> Repository Only (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 C.2.3 Released Open Edition -> Released Version (3) . . . . . . . . . . . . . . . . . . . 293 C.2.4 Released Version -> Open Edition (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 C.2.5 Open Edition -> Released Open Edition (5) . . . . . . . . . . . . . . . . . . . . . . . 293 C.2.6 Open Edition -> Version (6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 C.2.7 Version -> Released Version (7). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 C.2.8 Version -> Open Edition (8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 C.2.9 Version/Released Version -> Scratch Edition (9) . . . . . . . . . . . . . . . . . . . 295 C.2.10 Scratch Edition -> Open Edition (10) . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 C.2.11 Scratch Edition -> Not Existing (11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 C.2.12 (Released) Open Edition/(Released) Version -> Repository Only (12). . 296 C.2.13 Repository Only -> Open Edition/Version (13) . . . . . . . . . . . . . . . . . . . . 297 C.2.14 Repository Only -> Not Existing (14). . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 C.3 Class State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 C.3.1 Not Existing -> Open Edition (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 C.3.2 Open Edition -> Version (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 C.3.3 Version -> Released Version (3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 C.3.4 Version/Released Version -> Open Edition (4) . . . . . . . . . . . . . . . . . . . . . 300 C.3.5 Version/Open Edition/Released Version -> Repository Only (5) . . . . . . . 300 C.3.6 Repository Only -> Version/Open Edition (6) . . . . . . . . . . . . . . . . . . . . . . 300 C.3.7 Repository Only -> Not Existing (7). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Appendix D. Sample Code and Other Materials . . . . . . . . . . . . . . . . . . . . . . . 303 D.1 VisualAge for Java and VisualAge Generator V4 Code . . . . . . . . . . . . . . . . . . 303 D.2 VisualAge Generator V3 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 D.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Appendix E. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Appendix F. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 F.1 International Technical Support Organization Publications . . . . . . . . . . . . . . . . 311 F.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 F.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 IBM Redbook Fax Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
ix
Figures
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. VisualAge Generator V4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Developer on Java Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Integration of VisualAge Generator in VisualAge for Java . . . . . . . . . . . . . . . . . . . . . 14 Integration of VisualAge Generator in VisualAge for Java . . . . . . . . . . . . . . . . . . . . . 16 Part Filter and Part Browser Support Access to Parts in the Workspace . . . . . . . . . . 17 VisualAge Generator Parts stored as Methods in VisualAge for Java . . . . . . . . . . . . 18 Using 4GL Parts in Java Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 VisualAge Generator Parts on Free Form Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 VisualAge Generator Integration to Java Component . . . . . . . . . . . . . . . . . . . . . . . . 22 Java Applet with Connections to/from 4GL Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Making Connections to VisualAge Generator Logic and Program Parts . . . . . . . . . . 26 Making Connections to VisualAge Generator Data Parts . . . . . . . . . . . . . . . . . . . . . . 27 Testing in Developer on Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 VisualAge Generator Parts Stored as Methods in VisualAge for Java . . . . . . . . . . . . 29 Development and Implementation of a Java Client with 4GL Parts . . . . . . . . . . . . . . 31 How Functions Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Arguments and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Other Uses of Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Function Logic Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Map Edit Routine as a Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 How Object Scripts Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Data Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 VAGen Script Wizard SmartGuide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Object Scripting Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Reusable Object Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Events Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 VisualAge Generator Templates Development Support. . . . . . . . . . . . . . . . . . . . . . . 51 VisualAge Generator Templates Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 What is a Generator/Visitor?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Generated System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Generation Scope and Store Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Entity Parameter Definition Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 VisualAge Generator Templates Entity Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Anatomy of a Web System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Web-Based Transaction Programming Skill Requirements . . . . . . . . . . . . . . . . . . . . 61 Comparing 3270 and Web Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Mapping 3270 Programming Constructs to Web Transaction Solution . . . . . . . . . . . 63 Web Transaction Implementation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Web Transaction Implementation: Mapping Definition to Runtime . . . . . . . . . . . . . . . 65 Benefits of VisualAge Generator WebSphere RAD Approach . . . . . . . . . . . . . . . . . . 66
xi
41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83.
UI Record Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 UI Record Display Options for a Web Transaction Program . . . . . . . . . . . . . . . . . . . 70 Web Transaction: Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 UI Record Mapping to HTML Based on UI Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 HTML Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 UI Record Display and Transfer of Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Transferring Control between Web Transactions using UI Records. . . . . . . . . . . . . . 76 Web Transaction System Structure Options: Using CONVERSE . . . . . . . . . . . . . . . 77 Web Transaction System Structure Options: Using XFER pgm WS, UIRec . . . . . . . 78 Web Transaction System Structure Options: Using XFER , UIRec . . . . . . . . . . . . . 79 Web Transaction System Structure Options: Using Combinations . . . . . . . . . . . . . . 80 Web Transaction: Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Web Transaction: Runtime Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Runtime: Sample Configuration (Windows NT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Runtime: Sample Configuration (Windows NT / CICS TS) . . . . . . . . . . . . . . . . . . . . . 86 Runtime: Sample Configuration (OS/390) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 VisualAge for Java Enterprise Team Development Environment . . . . . . . . . . . . . . . . 92 Program and System Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contained in Relationships between Program Elements . . . . . . . . . . . . . . . . . . . . . . 97 Part of Relationship between Packages and Projects in the Repository . . . . . . . . . . 98 Terms for Editions of Program Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Versioning Program Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Releasing Program Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 VisualAge for Java Workbench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Developer on Java VAGen Part Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 VisualAge for Smalltalk and VisualAge for Java Team Environment Containers . . . 115 Comparing Application and Package Structure Options. . . . . . . . . . . . . . . . . . . . . . 116 Content Rules for Applications and Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Using Configuration Maps to Manage Applications . . . . . . . . . . . . . . . . . . . . . . . . . 118 Using Projects to Manage Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Developer on Smalltalk Container Structure Example . . . . . . . . . . . . . . . . . . . . . . . 120 Developer on Java Container Structure Example. . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Sample Developer on Java Container Structure derived from Subapplications . . . . 122 Sample Developer on Java Container Structure Derived from Applications . . . . . . 123 Using Project List Part Processing to Emulate a Layered Set of Projects . . . . . . . . 124 Traditional Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Developer on Java Development with One Package for the Project . . . . . . . . . . . . 128 Developer on Java Development with One Package per Programmer . . . . . . . . . . 129 Developer on Java Development with One Package per System Function . . . . . . . 130 System Defined Using Multiple Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Sample Team Environment Container Breakdown. . . . . . . . . . . . . . . . . . . . . . . . . . 133 Implementation of Project Sets to Represent Phases of Development . . . . . . . . . . 135 Promoting a Package from Test to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
xii
84. Promoting a Package from Test to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 85. Using PLPs to Define Sets of Projects Used by Development Phase . . . . . . . . . . . 138 86. Promoting a Project from Test to Production Using PLPs . . . . . . . . . . . . . . . . . . . . 139 87. Java Client Generation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 88. Java Client Generation Using the Same Package as the Java Component Source 141 89. Java Client Generation Using a Shared Package in the System Project . . . . . . . . . 142 90. Initial Container Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 91. Second Container Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 92. Final Container Breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 93. Project Creation SmartGuide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 94. Package Creation SmartGuide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 95. Team Environment Container Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 96. VisualAge Generator Import Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 97. Database Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 98. Target Package Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 99. Sample Program Call Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 100. Cleaning Up Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 101. Versioning the Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 102. Class List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 103. Package List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 104. Component Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 105. CustomerListPanel Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 106. CustomerDetailPanel Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 107. CustomerListApplet Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 108. CustomerListApplication Prototype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 109. CustomerDetailApplication Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 110. Reusable Component Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 111. CustomerListPanelResource Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 112. CustomerListPanel Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 113. CustomerDetailPanelResource Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 114. CustomerDetailPanel implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 115. CustomerListApplet Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 116. CustomerListApplication Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 117. CustomerDetailApplication Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 118. Team Development Library Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 119. VisualAge Generator Developer on Smalltalk Team Development Environment. . . 199 120. Team Environment File Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 121. Library and Image Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 122. Image as a Temporary and Saved Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 123. Smalltalk Software and the Team Environment Management Components . . . . . . 209 124. VisualAge Generator Part Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 125. VisualAge Generator Extended Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 126. Applications and Subapplications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
xiii
127. Configuration Maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 128. Edition Definition Illustrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 129. Loading Another Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 130. Version Definition Illustrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 131. Scratch Edition Definition Illustrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 132. Team Environment Change Management Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 133. Summary of Team Environment Component Management Steps . . . . . . . . . . . . . . 223 134. Levels of Component Responsibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 135. Configuration Map Roles and Configuration Map Manager Responsibilities . . . . . . 227 136. Application Roles and Application Manager Responsibilities . . . . . . . . . . . . . . . . . . 228 137. Class Owner and Class Developer Roles and Responsibility . . . . . . . . . . . . . . . . . 229 138. Serial Versus Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 139. VAGen Application/Extended Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 140. Reconciliation of Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 141. Extended Class Ownership + Concurrent Development = Confusion . . . . . . . . . . . 239 142. Traditional Source Library for Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . 240 143. VisualAge Generator Development with One Application for the Project . . . . . . . . . 241 144. VisualAge Generator Development with One Application per Programmer . . . . . . . 242 145. Configuration Map Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 146. Application Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 147. Code Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 148. Serial Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 149. Workbench Managing Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 150. Management Query Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 151. Using Predefined Query Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 152. Specifying a Shared Resource Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 153. The Basic Development Pattern for Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 154. Single Developer Working with a Single Package . . . . . . . . . . . . . . . . . . . . . . . . . . 271 155. Working Pattern for Class Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 156. Establishing a Package Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 157. Merging Divergent Class Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 158. Establishing a Project Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 159. A Rolling Project Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 160. Split Stream Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 161. Valid State Transitions for Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 162. Valid State Transitions for Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 163. Valid State Transitions for Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
xiv
Tables
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Java Class Types used to Store VisualAge Generator Parts. . . . . . . . . . . . . . . . . . . . 18 Data Item to Java Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Java Client Generation Naming Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Sample Team Environment Container Breakdown Package Content . . . . . . . . . . . . 134 Programs to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Team Environment Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 IsaActionEventHandler Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 IsaErrorRoutine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 IsaLogic Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 IsaComboBox Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 IsaComboBox Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 IsaTable Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 IsaTextField Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 CustomerListPanel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 CustomerDetailPanel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 VisualAge Generator Configuration Maps and Applications . . . . . . . . . . . . . . . . . . . 304
xv
xvi
Preface
This redbook introduces the new function and development platforms provided in VisualAge Generator V4. Also included are primers on the team development support provided in each platform: Developer on Java and Developer on Smalltalk. With VisualAge Generator V4, two development platforms are provided: Developer on Java (Java interoperability, new with V4); and Developer on Smalltalk (Smalltalk interoperability, first introduced with V3). The new capabilities included in V4 include: function support, object scripting, enhanced VisualAge Generator Templates development support, and support for WebSphere Rapid Application Development (RAD). Functions provide for reusable code; object scripting allows for direct object access during 4GL logic; VisualAge Generator Templates enhancements include support for new target system types and better information model management; and WebSphere RAD simplifies the development and implementation of Web-based transaction systems. Also, to further understand the Developer on Java platform, a migration and development process, focused on the implementation of a Java GUI system, was performed. This resulted in a sample GUI system, which includes a set of reusable Java classes that assist in the process of application development when using Developer on Java.
xvii
The Team That Wrote This Redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization San Jose Center. Pat McCarthy is a Consulting Application Development Specialist at the International Technical Support Organization, San Jose Center. He writes extensively and teaches IBM classes worldwide on all areas of application development, with a specific emphasis on VisualAge Generator and related technologies. Before joining the ITSO in 1990, Pat worked in an IBM internal information systems organization in Poughkeepsie, New York, as a programmer, database administrator, and development center leader. Pat received a B.S. in Business Administration from Indiana University of Pennsylvania (Indiana, PA) and an M.S. in Computer Science from Marist College (Poughkeepsie, NY). Guillaume Hetu-Dandurand is a consultant with Bahnso in Canada. He has 3 years of experience in the application development field and has IBM professional certifications in VisualAge Generator and MQSeries. His areas of expertise include client/server programming with VisualAge Generator and VisualAge for Smalltalk. Stefano Sergi joined IBM US as a software developer in 1984. He has held numerous positions in the area of Application Generator technology, as programmer, development manager, and product market manager. Currently a Senior member of the Worldwide Software Sales Support Team, Stefano is responsible for sales support of VisualAge Generator in E/ME/A. He holds a Ph.D in Civil Engineering from the University of Rome, Italy. Special thanks are due to the following people from the VisualAge Generator development team for their invaluable contributions to this project:
Alex Akilov Frieda Dollar Amy Hawkins Henry Koch Beth Lindsey Debbie Prevost Tim Wilson Jay Cagle David Hardy Kristine Heaton Susan LaFera Alex Liu Jon Shavor Dan Zhong Nicolas Dangeville Paul Harmon Gary Johnston Lisa Lasher Jeri Petersen Guy Slade
Thanks are also due to: Ueli Wahli, for the use of the Java team environment material The San Jose Publishing Team (Joan Bow, Yvonne Lyon, Deanna Polm and Emma Jacobs), for their assistance in finishing this redbook
xviii
Comments Welcome
Your comments are important to us! We want our redbooks to be as helpful as possible. Please send us your comments about this or other redbooks in one of the following ways: Fax the evaluation form found in ITSO Redbook Evaluation on page 325 to the fax number shown on the form. Use the electronic evaluation form found on the Redbooks Web sites: For Internet users http://www.redbooks.ibm.com/ For IBM Intranet users http://w3.itso.ibm.com Send us a note at the following address:
redbook@us.ibm.com
xix
xx
Part 1. Introduction
Part 1 includes the following chapters: Chapter 1, VisualAge Generator V4 Overview Chapter 2, Java-Based Version of VisualAge Generator Chapter 3, Introduction to VisualAge Generator V4 Enhancements
These chapters provide a general introduction to VisualAge Generator V4, with a specific focus on the new integration with the VisualAge for Java platform and new functions provided by both the Developer on Java and Developer on Smalltalk development environments.
Chapter 1. VisualAge Generator V4 Overview

VisualAge Generator, the very productive end-to-end solution for developing e-business systems, is now available on both Smalltalk-based and Java-based development platforms (see Figure 1).
Workstation VisualAge Smalltalk VisualAge Generator Developer on Smalltalk Image
New Java Development Platform

Java Interoperability Java Client Generation
Workstation VisualAge for Java VisualAge Generator Developer on Java Workspace
Functional Enhancements:
Function Logic Part Object Scripting Web-Program / UI Record New VAGen Templates Generators SUN Solaris Runtime Enterprise Java Bean Support (Java Platform Only)
ENVY:
Image Manager Configuration Maps Applications
Pf m C am B pm Sj g
ENVY:
Workspace Repository Projects Packages
Library (manager.dat)
Repository (ivj.dat)
Red Cam
Red Q rs
Qrs
Sjg
Qrs
Bpm
Figure 1. VisualAge Generator V4 Overview
VisualAge Generator V4 introduces both functional enhancements and new development and runtime platforms. With VisualAge Generator V4 you get: VisualAge for Java InteroperabilityA new development platform FunctionsTrue reusable coding capability Object ScriptingTight integration between 4GL and object logic VisualAge Generator Templates EnhancementsA better RAD engine SUN Solaris Runtime SupportA new runtime platform WebSphere RAD SupportWeb systems made easy Enterprise Java Bean SupportIntegrated support for advanced Java-based distributed object systems
1.1 VisualAge for Java Interoperability

VisualAge Generator is fully integrated into the VisualAge for Java Enterprise development environment (see Figure 2). In the Developer on Java platform provided by VisualAge Generator V4: VisualAge Generator 4GL parts can be created and stored in a VisualAge for Java development environment. VisualAge Generator 4GL parts and logic, as well as Java methods, can be used in a VisualAge for Java component. VisualAge Generator 4GL parts used in a VisualAge for Java component are generated as native Java for use at runtime.
VisualAge Generator Developer Workstation
Workstation VisualAge for Java VisualAge Generator Developer on Java Workspace
New Java Development Platform

Java Interoperability Java Client Generation
Functional Enhancements:
ENVY:
Workspace Repository Projects Packages
Red Cam
Qrs
Sjg
Qrs
Bpm
Function Logic Part Object Scripting Web-Program / UI Record New VAGen Templates Generators SUN Solaris Runtime Enterprise Java Bean Support (Java Platform Only)
Figure 2. Developer on Java Overview
With the Developer on Java you can build pure 4GL-based systems and: Java ApplicationsRobust traditional GUI systems Java AppletsGUI-like function delivered in a Web browser Java ServletsThin client systems using a Web browser and backend server-side logic
The option of a VisualAge Generator development platform (the Developer on Java) enables you to: Integrate e-business and traditional application system development Obtain access to the world of reusable Java components being developed by other vendors and business partners.
Notes:
This type of integration, for the Developer on Smalltalk development platform, was introduced in VisualAge Generator V3.0. The team environment repository (library) implementation used by VisualAge for Java cannot be shared with the Developer on Smalltalk development platform. The Developer on Java development environment is discussed further in Chapter 2, Java-Based Version of VisualAge Generator on page 13.
1.2 Functional Enhancements to VisualAge Generator

The functional enhancements made to VisualAge Generator are reviewed in this section. These functional enhancements are available in both the Developer on Java and Developer on Smalltalk development platforms, Further details are provided in Chapter 3, Introduction to VisualAge Generator V4 Enhancements on page 35.
1.2.1 Functions
Functions are the logic part in VisualAge Generator V4. They support logic definition, the use of 4GL processing options (CONVERSE, INQUIRY, SQLEXEC) and the option of passed parameters. Functions replace statement groups and processes. These replaced parts are converted to functions during migration. The capabilities of a function part equal and exceed those provided by process and statement group logic parts. This enhances reusability of VisualAge Generator code by adding: Support for parameters Support for the development of true reusable 4GL code Local storage option to avoid naming conflicts during function reuse
See 3.1, Function Logic Parts on page 35 for additional information.
1.2.2 Object Scripting

This release of VisualAge Generator introduces the ability to access non-VisualAge Generator objects from within 4GL through the synchronous execution of Smalltalk or Java method (Object Script). A new built-in function, called EZESCRPT, allows the programmer to invoke an Object Script as part of 4GL statement processing. In other words, EZESCRPT allows the programmer to make a call to a Smalltalk or Java script from the 4GL logic. This technique allows you to script together references to control non-VisualAge Generator objects among the rest of your business logic. Object scripting increases the level of integration with the native object language (Smalltalk or Java) available on the development platform (Smalltalk or Developer on Java interoperability). This extends programming flexibility and capability for those who build GUI systems. A new set of Wizards and help menus guide you through the task of building basic method logic (Object Scripts) in the target language (Java or Smalltalk). The ability to invoke an Object Script from within the 4GL logic opens up VisualAge Generator and improves the programmer's capability to control external objects. For example, the programmer can now invoke Object Scripts to control the visual parts on a view as part of their normal business logic. Instead of using visual connections or performRequest actions, messages can now be sent directly to visual parts as part of 4GL code processing. This programming technique also supports access to business objects defined in the object programming environment. Within the Object Scripts, you can communicate with Smalltalk or Java client parts and access both class and instance objects. This includes: Smalltalk client parts Smalltalk globals Smalltalk classes Java client parts Java classes EJB objects
Existing instances of Smalltalk or Java classes can be accessed, or new instances can be created, as needed. EZESCRPT is only valid in GUI client programs, not in server programs. For example, in a GUI component that has visual connections to execute individual VisualAge Generator functions and invoke a VisualAge Generator server program, the use of the EZESCRPT function word would be valid in the individual 4GL functions, but not within the server program. See 3.2, Object Scripting on page 42 for additional information.
1.2.3 VisualAge Generator Templates Enhancements

Message: Extreme productivity with support for new types of systems.
VisualAge Generator Templates has been enhanced with VisualAge Generator V4 to provide: Generation of Java-based systems Improved integration with VisualAge Generator Implementation of a VisualAge Generator Templates on Java version of the information model and generators Redesigned user interface to improve both entity definition and information model source management See 3.3, VisualAge Generator Templates Enhancements on page 51 for additional information.
1.2.4 SUN Solaris Runtime Support

Message: VisualAge Generator expands its extensive runtime platform support to include SUN Solaris.
VisualAge Generator stand-alone (TUI) and server programs can be generated as C++ programs that support: Both the native operating system and CICS-based execution DB2, Oracle, and ODBC database access
1.3 Web-Based and e-business Enhancements

The enhancements made to VisualAge Generator to support e-business and Web browser based transaction systems are reviewed in this section.
Further details are provided in Chapter 3, Introduction to VisualAge Generator V4 Enhancements on page 35.
1.3.1 Development Support for WebSphere Application Server

Message: Here, we have a simplified programming approach, compatible with traditional 4GL programming techniques, for Web-based e-business application systems.
A new model of programming is provided with VisualAge Generator V4. This new programming model includes: New main program typeMain TransactionUI Records and Segmented New record typeUser Interface (UI Record) The support for this new programming model implemented in VisualAge Generator V4 permits: The development of main programs, using 4GL programming techniques, that can interact with end users in a Web browser. These 4GL-based programs implement user interface, business logic, and database processing. This processing can be implemented in either a series of main programs or a set of main and called batch (server) programs. This flexibility will allow both for the migration (through rework) of existing text based transaction systems and client/server systems previously implemented in a VisualAge Generator 4GL programming environment. Testing of these new programs using the existing VisualAge Generator test facility and a Web browser. A default view for the UI Record is used in the browser. This communicates directly with the main program being tested. The use of generation technology to handle the complexities of runtime communication and processing. UI Record generation creates Java Beans and default Java Server Pages (JSPs) These materials can be used by Web-based user interface developers (who use HTML, XML, and so on) to access the data and render an appropriate screen. The Java Beans have methods that allow attribute access and a single action that puts all the inputs through the edits defined by the programmer.
The program is generated using the current VisualAge Generator pseudo-conversational model for runtime execution. CICS pseudo-conversational problems of state, transaction control, program flow, and so on, are similar to Web problems. The generated program is independent of the user interface; any tool that can access a Java bean can create a user interface view using the data available in the Java Bean. The power of the new 4GL-based programming model and generation technology will reduce the skill requirements, and therefore the price of entry, into the world of Web-based e-business transactional application systems. See 3.4, WebSphere Rapid Application Development on page 60 for additional information.
1.3.2 Enterprise Java Bean Support

Message: EJBs represent an architected way to access server side capability. They are recognized as a candidate for being the standard architecture for accessing server side services.
VisualAge Generator support for Enterprise Java Beans (EJBs) will allow Java clients to call VisualAge Generator server programs through an intermediary session bean. Support for calling server programs through an EJB session bean is directly applicable to Java development, and will only be provided within the Developer on Java development platform.
1.4 VisualAge Generator Automated IC Packaging

The new automated image component (IC) packaging support that will be provided with VisualAge Generator V4 is introduced in this section. The introductory text was copied from a draft of the product documentation that will be made available with VisualAge Generator V4.
1.4.1 Introduction
The VisualAge Generator Automated IC Packaging mechanism is based on the image component (IC) technology available within VisualAge Smalltalk, on which the VisualAge Generator GUI development environment is based.
For more detailed information about image components (ICs), please consult Chapter 37, "Packaging with Image Components (ICs)" of the IBM Smalltalk User's Guide, SC34-4536-02.
1.4.2 GUI Packaging Options

The way you typically package a GUI runtime system in the Smalltalk environment is through the Make Executable menu option. This step produces a reduced runtime image (ICX file) that contains all the code needed to run all the GUIs in the system. This image can vary in size from 1.5MB to over 60MB, depending on the number and size of the GUIs in the system. Large images like this can cause performance and maintenance problems related to image load time and memory footprint at runtime (since all the code is loaded at the start, even though you may never access certain parts of the system in that particular run) as well as high distribution costs of incremental code changes. The new Enhanced IC packaging feature allows you to package your GUI system in a modular way. Each Smalltalk team environment application containing GUIs can be packaged into a separate file (typically 100K-1MB in size) called an IC (Image Component) file which can be repackaged and distributed separately. Also, the runtime system loads these ICs dynamically as needed. This means that startup time is reduced, and the memory footprint will not grow to the maximum size of the whole system unless every GUI in the system has been visited.
1.4.3 Automated IC Packaging

This new delivery mechanism combines technology available in VisualAge Generator V3 with a packaging and delivery mechanism that is more reminiscent of .app files that were used to build GUI applications prior to VisualAge Generator V3. ICs represent image components, hence the name. Rather than a single, large loadable .ICX file that contains the VisualAge Generator GUI code, ICs provide a partitioning mechanism that allows your application to be split over multiple files (with suffix .ic). For VisualAge Generator GUI applications, this means that every GUI screen can potentially be packaged into a separate file. Why is this partitioning important? Because, ICs provide the following benefits for VisualAge Generator GUI programmers: ICs reduce runtime application memory requirements by only loading into memory those GUI portions of the application that are used. ICs aid in incremental deployment of large applications containing many views. Also, bug fixes in individual views would not require a complete redeployment of the application code.
10
ICs allow adding new GUI functionality to the application in an incremental manner. There are three types of ICs that are output as the result of the VG automated packaging:
Prerequisite Components
A prerequisite component is an IC that contains code that is shared (reused) by more than one view in more than one Smalltalk team environment application. If another IC directly references a class in a prerequisite component, then the prerequisite component is loaded before the component where the reference is made. Typically, a prerequisite component will contain shared GUI forms that are used within many different views within your application.
Loadable Components
A loadable component is one that is dynamically loaded when a symbolic reference to a class name contained within the loadable component is resolved. Within a loadable component, code should only contain direct class references to classes that: Are defined in the same application where they are referenced Are defined in a prerequisite component. Typically, a loadable component will only contain one or more view classes that will imbed shared forms and reference other views using ViewWrapper, Object Factories or Variable parts.
Launch Component
Output of the automated packaging process will include a special IC called the launch IC. The launch IC contains information about the contents of the other ICs produced in packaging, so that it can control the dynamic IC loading process. The launch IC also contains the name of the first view to be opened when your application is started. None of your application code is packaged into the launch component. To successfully make use of VisualAge Generator loadable components, it is important to analyze your existing VisualAge Generator GUI classes and applications and ensure that they conform to the above constraints for prerequisite and loadable components.
11
12
Chapter 2. Java-Based Version of VisualAge Generator

Once the Developer on Java version of VisualAge Generator has been installed (on the required VisualAge for Java base), an installable feature named IBM VisualAge Generator V4 will be available. The Java code to support Java Interoperability will reside in the Java Project IBM VisualAge Generator, once the feature has been added (loaded) to the VisualAge for Java base. By adding the feature IBM VisualAge Generator V4 to the Java development platform: VisualAge Generator parts will be available on the VisualAge for Java composition editor palette. A VisualAge Generator part browser window can be opened from the Workbench. VisualAge Generator 4GL parts can be created, edited, tested, and generated. The Developer on Java VisualAge Generator feature will be integrated with existing VisualAge for Java features. This will allow VisualAge Generator parts to work with the beans of other features. This includes: Web Object Extender Database The basic functional areas of the Developer on Java Version of VisualAge Generator are described in this chapter.
2.1 Workbench Integration

Java Interoperability will provide the ability to use VisualAge Generator 4GL parts within the VisualAge for Java development environment. Figure 3 depicts the development environment when the feature named IBM VisualAge Generator V4 is added to VisualAge for Java.
13
Workstation VisualAge for Java VisualAge Generator
VisualAge Generator (Java-based) Developer Workstations
Workstation VisualAge for Java VisualAge Generator
Workspace
Workspace
ENVY Class Management:

Projects Packages
Local Area Network
Library Connection:
EMSRV Only
Cam
Red
Qrs
Sjg
Qrs
Bpm
VisualAge for Java Repository (EMSERV)
Figure 3. Integration of VisualAge Generator in VisualAge for Java
2.1.1 Workbench Extensions for VisualAge Generator

The IBM VisualAge Generator V4 feature extends the VisualAge for Java workbench with these menu options: VAGen Parts Browseradded to the Workspace menu option Generate VAGen runtime codeadded to: Context menu or as part of Selected menu option for Java Classes Context menu or as part of Selected menu option for Java Packages and Projects VisualAge Generator parts will be available on the VisualAge for Java composition editor palette. When using the Developer on Java platform, all VisualAge Generator tasks (part modification, options setting, program validation) must be performed using the VAGen Parts Browser and not directly through the VisualAge for Java workbench. Unlike the VisualAge Generator integration approach used with the Developer on Smalltalk platform, there is no VAGen Parts pane that allows direct access to the VisualAge Generator tasks.
14
Note: Much of the code used in the Developer on Java version of VisualAge Generator is shared with the Developer on Smalltalk version. This means that there will be visual differences in the user interfaces used in native VisualAge for Java and VisualAge Generator windows and dialogs. For example, the VisualAge for Java Workbench uses circular buttons, while rectangular buttons are used by VisualAge Generator part browsers, editors, and dialogs.
2.1.2 Organization of VisualAge Generator Parts in VisualAge for Java

The organization of parts (classes) in the Developer on Java team environment is different from that used in the Developer on Smalltalk version of VisualAge Generator. In the Developer on Java team environment, the following terms should be understood:
Repository
This is the file used to store all code available for use in the development environment. One or more development platforms can connect to the same Repository. This is roughly identical to the Library used in the Developer on Smalltalk version of VisualAge Generator.
Workspace
This is the file used to store all code currently being used in a development platform. This is roughly identical to the Image used in the Developer on Smalltalk version of VisualAge Generator.
Package
This is a named collection of classes. The package naming pattern is name.name.name. This construct is similar to an Application in Smalltalk. However, there is no concept of prerequisites or SubPackages. In Java, package relationships must be directly managed by the programmer.
Project
This is a named collection of packages. The project naming pattern is Name. This construct is similar to a Configuration Map in Smalltalk. However, there is no concept of required projects. In Java, project relationships must be directly managed by the programmer.
The class management rules in VisualAge for Java differ from those used in VisualAge Smalltalk (see Figure 4).
15
Projects
System Layer Logical Structure
Proj Sub-Sys A
Packages
...
Pkg Pgm 3
Managed Components
Proj Common Parts
Pkg Pgm 1
Pkg Pgm 2
Pkg Records
Pkg Shared Code

VAGen Functions
VAGen Programs VAGen Records VAGen DataItems VAGen Functions
VAGen Records VAGen DataItems
Classes
VAGen Part Containers
Figure 4. Integration of VisualAge Generator in VisualAge for Java
2.1.3 VisualAge Generator Parts in the Workspace

Since VisualAge Generator parts will now be saved as Java methods, the parts will automatically display in the workbench. The methods representing VisualAge Generator parts will be displayed as Private instance methods in the appropriate class. The name of the method will be partname() . When a method representing a VisualAge Generator part is selected, the ESF for the member will be displayed as the source. The ESF can be viewed, but not directly modified. When the part is modified using the part editor, the displayed ESF will change to reflect any modification. To directly modify the ESF you must export the part to a file, edit, and import the modified ESF. Because of this, it is expected that the programmer will use the Parts Browser (see Figure 5) to perform most of the tasks concerning our 4GL parts (copy, move, print, test, validate, generate, etc.).
16
Workspace
Proj Sub-Sys A
Pkg Pgm 1
Pkg Pgm 2
VAGen Programs
Pkg Pgm 3
VAGen Functions
Part Browser is only way to list and edit VAGen parts loaded in Workspace
Figure 5. Part Filter and Part Browser Support Access to Parts in the Workspace
The VisualAge Generator preferences notebook will only be available from the Parts Browser as well. Copy and move will work for VisualAge Generator part methods on the workbench, however, the programmer would be limited to naming the new method according to the Java rules for method naming. With the Parts Browser you can use the less restrictive VisualAge Generator naming rules, and for instance, include a dash (-) in a part name. The Parts Browser logic creates and manages an alias for the part when it is stored as a method (see 2.1.5, Part Name Aliasing on page 19).
2.1.4 Class and Method Mapping for VisualAge Generator Parts

The VisualAge Generator 4GL parts will be stored as Java Methods within Java classes that represent the part type (see Figure 6).
17
Project 1 Package A Classes

Methods
Project 2 Package C Classes

Methods
VGenXXX Class
(VA Generator Parts)
Classes
Methods
Package B Classes
Methods
Package D Classes
Methods
VGenXXX Class
VGenXXX Class
Figure 6. VisualAge Generator Parts stored as Methods in VisualAge for Java
The mapping of VisualAge Generator part types to Java class names is shown in Table 1.
Table 1. Java Class Types used to Store VisualAge Generator Parts
VisualAge Generator Part Type

Program Function Map Group Map Record Table PSB Data Item Generation Options Linkage Table Resource Associations Bind Control Link Edit
Java Class
VAGenPrograms VAGenFunctions VAGenMapGroups VAGenMaps VAGenRecords VAGenTables VAGenPSBs VAGenDataItems VAGenOptions VAGenLinkages VAGenResources VAGenBindControls VAGenLinkEdits
18
2.1.5 Part Name Aliasing

Because VisualAge Generator supports characters within part names that are not valid within Java method names, we must introduce the concept of name aliasing for our parts. To correct this problem, VisualAge Generator will replace any character that is not valid in a Java method name with an escape sequence.
Note: Valid characters for Java method names consist of all alphanumeric characters, the dollar sign ($) and underscore (_).
This escape sequence will consist of a lower case 'x', followed by the 4-byte hexadecimal value of the character. For example, the part name MY-RECORD contains a hyphen (-) that would be invalid in a Java method name. Therefore, the method created for this part will be named MYx002DRECORD. The user will see the actual method names (with escape sequences) in the Java Workbench, but the actual part names will be displayed in the parts browser.
2.1.6 Source Management and Organization in VisualAge for Java

The major class management differences are: The same class names can be loaded into the workspace, in different packages, at the same time. The packages used during test processing are determined by Workspace settings, and properties defined for the class that will be tested. These differences will impact how development is managed in the Developer on Java version of VisualAge Generator. Because the parts are now being stored as Java methods, it will be possible to get multiple parts with the same name and type in the workspace at the same time (each in a different package). For example, you might define a record CUSTINFO and choose to save it in the Java Package My.VAGen.Parts . You could then load another Java Package named Your.VAGen.Parts that contains a record named CUSTINFO . The solution for this is to have VisualAge Generator issue a warning message when duplicate parts (part names) have been loaded. In the above example, a warning message will be issued when the package Your.VAGen.Parts is loaded.
19
If the workspace contains any duplicate part names and either a generation or start testing request is made, an error message will be issued and the generation or testing request will stop. The part browser includes an option to display a list of the duplicate part names in the workspace. This provides an easy means to find and resolve the existence of duplicate part names in the workspace.
2.2 Java (GUI) Interoperability

The techniques used to integrate VisualAge Generator 4GL parts into the VisualAge for Java programming environment are discussed in this section.
2.2.1 Introduction
VisualAge Generator is fully integrated with the VisualAge for Java programming environment (see Figure 7).
Any Java component (Class, Applet, Application, Servlet) can be defined to include the use of VAGen 4GL parts Adding 4GL parts is as simple selecting the part type from the palette and dropping it on the FFS Additional support code (VAGen context, VAGen communication session) is dynamically added to the component VAGen data parts (records and table) have been defined with attributes that allow connections to other Java parts to be made When the Java component is tested, the VAGen Test Facility takes charge when 4GL parts are referenced.
Figure 7. Using 4GL Parts in Java Components
Java Components
Class Applet Application Servlet
VAGen Parts
Records Functions Tables Programs
Test Facility
VAGen Specific Methods

getVAGenCommSession() getVAGenContext() hptHandleException() hptInitContext() ...
The Developer on Java platforms supports both pure 4GL programming (TUI or Web Transaction) and Java-based programmingextended (some would say improved) by the capabilities of VisualAge Generator.
20
2.2.2 Free-form Surface Integration

VisualAge Generator parts can be used in any Java component, typically through the process of dropping them on the FFS of the component part. When you build a Java component (Application, Applet, Servlet, or other class), you can add VAGen Parts to the free-form surface (see Figure 8).
Composition Editor Integration

VAGen Parts category on palette Standard part types
Record Table Function Program
Special parts
VAGen variable VAGenCommSessionPart
Adding VAGen part to FFS triggers generation of initial VAGen integration logic (support methods)
Figure 8. VisualAge Generator Parts on Free Form Surface
The standard and special VisualAge Generator parts included are comparable with those provided in VisualAge Generator V3.x. The VAGenCommSessionPart is a visual representation of the client/server session, and can be used to promote sharing of the session between multiple client components. When 4GL parts are added to the FFS, VisualAge Generator integration support code is automatically added to the Java component. The act of dropping the first 4GL part on the FFS triggers VisualAge Generator integration processing logic. This adds methods to the Java component that support identification, processing support, and exception management for 4GL parts in the Java component (see Figure 9).
21
3 1
Part on FFS Save Bean
Figure 9. VisualAge Generator Integration to Java Component
The life cycle steps for a Java component with respect to adding 4GL parts (a record) to the FFS, as shown in Figure 9, are: 1. Base methods that exist in a Java component (class) without any 4GL parts involved 2. Java component, after adding a 4GL part to the FFS 3. Java component, after using the Bean -> Save Bean menu Visual Composition menu option These parts are available in the composition editor category VAGen Parts: VAGen VAGen VAGen VAGen Table Part Record Part Function Part Program Part
2.2.3 Table and Record Parts

When a Table or Record part is dropped on the free-form surface, the programmer will be prompted for the name of the Table/Record to be used.
22
A list of Table/Record parts contained within the Java workspace will be provided. The programmer can choose one of the names provided, or enter another Table/Record name. Once the part is dropped, the list of properties available for connection will be the same as the attributes available on the Smalltalk editor. For example, if the internal structure of a Record CUSTINFO is: 05 CUSTOMER-INFO 10 NAME 15 LASTNAME 15 FIRSTNAME 10 SOCIALSECURITYNUMBER 77 MISC-INFO The following will be listed for the properties of the Record: data NAME NAME data MISC-INFO MISC-INFO data this
The substructured data items and their data will be accessible through tear-offs. These properties will be READ/WRITE and BOUND (except this , which is read-only). This means that values can be read from or written to these data items. Since the items are BOUND, notification will be sent whenever the value of any item is changed. As an example, imagine a simple Java applet TestApplet in the composition editor. The applet contains a TextField with a connection from the property text to the property LASTNAME of the CUSTINFO record. When the applet is saved on the composition editor, JAVA code will be generated so that when the applet is run, the applet TestApplet will be registered as a "listener" of the item LASTNAME. Whenever the value of this item is modified, TestApplet will be notified of the change. Consequently, all Object properties that are connected to a data item will automatically be updated whenever a data item's value is changed. One exception to this is when the value of a data item is modified within a VAGen Function. Notification will not be sent until the function completes, or an EZESEND is reached. This means that if an item is modified multiple
23
times within a Function, change notification will only occur once for that item, when the Function completes or the EZESEND is executed. The Record/Table parts will know how to create table models from their substructured data items so that the substructures can be represented in Swing tables. Table 2 lists the Java Type that is associated with each VisualAge Generator data item type.
Table 2. Data Item to Java Data Type Mapping
VisualAge Generator Data Item Type

BIN, Pack, Num with no decimals BIN, Pack, Num with decimals Hex Cha, Mix, DBCS
Java Type
long com.ibm.vgj.wgs.VGJBigNumber byte[] java.lang.String
2.2.4 Function Parts

When a Function part is dropped on the free-form surface, the programmer will be prompted for the name of the Function to be used. A list of Function parts contained within the Java workspace will be provided. The programmer can choose one of the names provided, or enter another Function name. When a connection is made to the execute() or the executeDeferred() method for the function, the parameters for the function will automatically be set up as the parameters of the connection. To visually pass a parameter to the function, the programmer would make a connection to the appropriate parameter in the connection. This is consistent with how the programmer would invoke a Java method and pass parameters.
2.2.5 Program Parts

The connection to the parameters will work consistently with connections to the Function parts. That is, the programmer will now add parameters to the connection instead of to the part itself. The main difference is that the parameters will not be built automatically, as they are in the Developer on Smalltalk version of VisualAge Generator.
2.2.6 Communication Session Information

When a VisualAge Generator part is dropped onto the free form surface, we will dynamically update the properties list for the view class to add the
24
VisualAge Generator communication session information (VAGen commSession, VAGen commSessionOwner, VAGen inheritsCommSession). These communication session properties will be removed from the view class if all of the VisualAge Generator parts are deleted from the free form surface.
2.2.7 Making Connections

When you build a Java component (Application, Applet, Servlet, or other class), you can add VAGen Parts to the free-form surface and make connections between the 4GL parts and other 4GL and non-4GL parts that exist on the FFS (see Figure 10).
Figure 10. Java Applet with Connections to/from 4GL Parts
The VisualAge for Java visual programming environment can be used to interact with VisualAge Generator 4GL logic parts. This process is conceptually similar to the support for 4GL parts provided in VisualAge Generator V3 (Developer on Smalltalk).
25
Figure 11 shows the properties that can be referenced when making connections to logic or program parts.
VAGen Function execute executeDeferred hasExecuted returnValue
VAGen Program execute executeDeferred hasExecuted failure success linkageinfo
Figure 11. Making Connections to VisualAge Generator Logic and Program Parts
For logic parts, the connections are straightforward. Invoking execution, or reacting to a hasExecuted event, is possible. Methods and properties that provide access to the return value or status of the execute request are also available. For VisualAge Generator program parts, linkage table information is also accessible (see Figure 11), and can be defined dynamically in client logic. The VisualAge for Java visual programming environment can be used to interact with VisualAge Generator 4GL data parts (see Figure 12). For data parts, the connections use the array item definition, and not the array item data alternative. Single data item connections target the item data definition. The connections are implemented in Java methods. These methods connect the VisualAge Generator data structure to the target Java part. The real work
26
is in the classes that represent the 4GL parts; they translate the VisualAge Generator data structure into a form that is compatible with Java parts (the model attribute is an example).
List (AWT) ----VAGen Record -----
JTextField (Swing)
JList (Swing)
JTable
ScrollPaneTable
(Swing)
1. Not possible without a method - add(String) 2. (IBKCRRO_WPAGE.CONTROL-COUNT-INSTANCES data <--> TextField1.text)

getTextField1().setText(getIBKCRRO_WPAGE().getStringData("CONTROL-COUNT-INSTANCES"));
3. (IBKCRRO_WPAGE.INSTANCE-FIELDS <--> JList1.model)

getJList1().setModel(getIBKCRRO_WPAGE().getArrayField("INSTANCE-FIELDS"));
4. (IBKCRRO_WPAGE.INSTANCE-FIELDS <--> ScrollPaneTable.model)

getScrollPaneTable().setModel(getIBKCRRO_WPAGE().getArrayField("INSTANCE-FIELDS")); getScrollPaneTable().createDefaultColumnsFromModel();
Figure 12. Making Connections to VisualAge Generator Data Parts
Figure 12 shows connections, and the associated Java methods, that implement communication between a VisualAge Generator record and selected Java parts. 1. A direct connection to a list part (AWT) is not possible. A series of add(string) method invocations is required to add instances to the list. 2. A direct connection from a data item to a JTextField part is made using the item data definition. 3. A direct connection from an array data item to a JList part is made using the array item definition. The target attribute is the list model. 4. A direct connection from an array data item to a JTable part is made using the array item definition. The target attribute is the table model. An additional method is used to define the table columns using the record item array structure passed as the model (form and data). For more information see Chapter 10, GUI Development with Developer on Java on page 167.
27
2.3 VisualAge Generator Program Definition

The editors and parts used to build non-GUI systems are similar in function to those provided in VisualAge Generator V3. They will not be described further. The new program and record types used to build Web Transaction are discussed in 3.4, WebSphere Rapid Application Development on page 60.
2.3.1 Testing
The VisualAge Generator Test Facility works with the Java testing environment to manage the emulation of 4GL data and logic parts. Once Java Client generation has been performed, the runtime logic (Java source code) for the 4GL parts can be used in the Java test environment.
Figure 13. Testing in Developer on Java
28
2.4 Generation
The Developer on Java development platform supports generation of Java for VisualAge Generator parts used in Java components as well as the standard generation processing (C++ or COBOL) for programs, maps, and tables (see Figure 14).
Proj Sub-Sys A
Workspace
Generate
Java
Components
Pkg Pgm 1
Pkg Pgm 2
VAGen Programs
Pkg Pgm 3
Generated Java for VAGen Parts used in Java Components
Export Classes or JAR
Packaged Java Classes
VAGen Functions
Workspace
Proj Sub-Sys A
Programs, Maps, and VG Tables
Generate
Pkg Pgm 1 Pkg Pgm 2
Prepare
Pkg Pgm 3
Generated 3GL Source Code
Compiled Executables
Figure 14. VisualAge Generator Parts Stored as Methods in VisualAge for Java
2.4.1 4GL Part Generation

A new generation option will be introduced to support generating C++ and/or COBOL from VisualAge Generator parts stored in the Java library. This option will be /PROJECT and will only be meaningful on the Generate command. The format of this option will be: /PROJECT="projectName", "projectVersion". The double quotes are required. Since VisualAge for Java does not provide a way to group projects together (like Smalltalk does with configuration maps), the /PROJECT option will be
29
cumulative. That is, multiple /PROJECT options can be specified on the generate command. For example the generate command: hptcmd generate MYPROG /PROJECT="My Project", "Version 1.0" /PROJECT="Your Project", "Version 29.5" ... will cause both projects specified to be loaded.
2.4.2 Java Client Generation

Java client generation is a key part of the implementation of Java Interoperability support in VisualAge Generator V4.
2.4.2.1 Overview Programmers can use the Developer on Java to create Java components (Applications, Applets, Servlets, Classes) that use 4GL Parts (Records, Tables, Functions, Programs) to implement the required processing.
When these Java components are tested in the Developer on Java development platform, the VisualAge Generator test facility is used to support the 4GL parts. Java client generation allows 4GL parts used in Java components to be implemented in a Java enabled runtime environment (see Figure 15).
30
Define - Test
Java
Components
Pkg Pgm 1
Proj Sub-Sys A
Workspace
2
Generate
Pkg Pgm 2
Pkg Pgm 3
3 Export 5
Combined to Implement Executable Client
Classes or JAR
VisualAge Generator Java Client Runtime Support

Figure 15. Development and Implementation of a Java Client with 4GL Parts
The Java client development, testing, generation, and implementation scenario shown Figure 15 is described below: 1. Define and test a Java Application that uses 4GL parts. 2. Generate Java source to implement the logic required for the 4GL parts used in the Java Application. 3. Export and deploy the Java Application and Java byte codes generated for the 4GL parts to a target client runtime platform. 4. Install and configure Java client runtime support (part of the implementation of Java client generation) on the target client runtime platform. 5. Execute the Java Application in a Java enabled runtime environment.
2.4.2.2 Generation Processing A new generation option will be added to support the generation of the 4GL parts used within a Java Client. The generation option /PACKAGENAME is used to specify the name of the package that will hold the generated runtime code. Since the generated Java runtime code will be placed into the
31
repository, the specified package must exist in the Java workspace, or the generation will fail. A generation dialog will be provided (accessible from the Workbench) to allow the programmer to generate the runtime code for the 4GL parts used within a Java Client. This dialog will allow the user to specify which Generation Options file to use during generation. The generated Java code will be placed in the repository (and the Java workspace). The generated classes will have to be versioned and released when generation is complete. In addition, a method named HptRuntimePackage will be placed into the Java Client during generation. This method will return a java.lang.String that represents the name of the Java package containing the generated runtime code. This will be the equivalent to whatever is specified in the /PACKAGENAME generation option. Because this information is stored into the Java Client, the class will have to be versioned and released when generation is complete.
2.4.2.3 Implementation Java classes and methods are generated for the 4GL parts included in a Java component. The Java code generated is directly stored in the workspace and team environment repository being used by the Developer on Java development platform.
The naming convention for the generated Java classes for a 4GL part named NNNN are illustrated in Table 3.
Table 3. Java Client Generation Naming Pattern
4GL Part Type
Naming Pattern
Working Storage Record Table File SQL DL1 Functions (As methods in one generated class)
VGWkgNNNN VGTblNNNN VGFileNNNN VGSqlNNNN VGDl1NNNN
VGGuiNNNN
32
All 4GL functions used in a Java component are implemented as methods in a single generated class. The generated class is named VGGuiCCCC where CCCC is the name for the Java component. Here is an example: A function named FOO used in a Java Application named MyJavaAppl is generated as a method named funcFOO in the generated Java class named VGGuiMyJavaAppl . The generated Java class VGGuiMyJavaAppl : Contains references to all the 4GL parts used in the Java component that were generated using the Java client generation support. Provides an interface between the Java component that uses generated 4GL parts and the implementation of the 4GL parts in Java (as performed by Java client generation). The Java code generated for related 4GL parts is grouped in one Java package. The generation option /PACKAGENAME is used to specify the name of the package that will hold the generated runtime code. This package can be deployed to platforms supported by the VisualAge Generator Java Client Runtime Support. The generated Java classes and methods can be exported as Java source files (.java), Java byte codes (.class files), or a Java archive file (.JAR).
2.4.2.4 Java Client Runtime Support The common services required by a Java component that uses generated 4GL parts are provided by Java Client Runtime Support. This support includes:
Generic record, data item, table, and program processing functions PowerServer API support for client/server communications A JAR file is used to package the Java code that implements the Java Client Runtime Support. This code must be installed on a target runtime platform.
33
34
Chapter 3. Introduction to VisualAge Generator V4 Enhancements

This chapter provides a quick review of some of the major enhancements made to VisualAge Generator as part of version 4.
3.1 Function Logic Parts

In this section we will cover the new VisualAge Generator Function logic parts. The new support for functions in VisualAge Generator V4 provides: True reusability and encapsulation: Prior to VisualAge Generator V4, true reusability and encapsulation, which require the use of storage variables local to a specific code segment, were only available through the definition of program parts. This clearly was unwieldy, both in terms of sheer number of individual generated source and executable objects, and because defining programs was too involved an activity for small reusable functional units (for example, small simple business rules or simple algorithms). Better I/O error and map item edit routines: Without the availability of functions, defining I/O error routines reusable across different programs and I/O operations was virtually impossible using statement groups (or required usage of global definitions to be carried along in all systems that intended to share those routines). Similar constraint existed for map item edit routines reusable across different map items Brings 4GL closer to object implementation: Finally, as the VisualAge Generator programmers become more involved in the use and exploitation of object technologies, such as Smalltalk and Java, the lack of information hiding and encapsulation facilities in the 4GL domain became more apparent and perceived as a severe limitation.
3.1.1 Usage
Functions can be invoked as a transfer statement type, just as was done with statement groups, or they can be coded inline within another type of statement (such as an assignment, math, conditional, and so on), as shown in Figure 16.
35
PGM1
FUNC1
....
index = 1; arg1 = 8; arg1 = 8 0 index = 1
FUNC2
index = 39 .... parm1 = parm1 = 0; index = 39; ....
....
FUNC2(arg1,..,argN); IF arg1 = 0;
.... ....
Local Storage: index Paramaters: parm1..parmN

RESULT = ITEM1 + FUNC3(arg1, .., argN);
FUNC3
.... .... EZERTN retval;
....
Return Value: bin 4, dec 1 Paramaters: parm1..parmN

Figure 16. How Functions Work
Since they replace both former statement groups and processes, when you define a Program, all the program logic is contained in functions. In this example, FUNC1 is a main function of PGM1. Functions have access to all storage areas of the Program that contains them or invokes them: in our example, FUNC2 could reference directly arg1. However, for a function to be reusable in different programs that may not have common storage areas (Records, Items, and so on), it is possible to use Parameters. When a function is invoked with a set of Arguments, like FUNC2 in this example, the arguments arg1..argN are known to the function as parm1..parmN (parm1...parmN must be defined when FUNC2 is defined): when FUNC2 uses parm1..parmN it is really directly using the original storage area of arg1...argN. For a function, you can specify local storage data elements (Records, Items): this allows for the use of the same data definitions in different parts of a program, but with different values that are scoped locally to the function. In our example, index is a data item visible in FUNC1 within PGM1; if I need a variable area identical to index inside FUNC2, I can simply specify, when I define FUNC2, that I want to use index as local storage. This ensures that a local copy of index, containing its own value, will exist during execution of
36
FUNC2. This eliminates the requirement for the creation of two identical data items (or records). Finally, functions can return a value to the invoking statement. This is accomplished by coding an EZERTN statement with a return value associated to it: this value is an item representation of the function (with data item characteristics defined for the return value in function definition) within the invoking statement. Data items, records, and literals are used as function arguments (see Figure 17).
Arguments
Data items
can be subscripted can be map or SQL items not implicit
Parameters
Data items
can be map or SQL items can test/modify state
Records
can be WS or other
Records
only WS cannot test/modify state
Literals
Data items
modifications discarded on return
Figure 17. Arguments and Parameters
You can specify as arguments normal data items, map items and SQL data items. If you pass a map item or an SQL item you can specify the corresponding parameter also as a map or SQL item: this allows to test and modify item state (for example, SET map_item MODIFIED) within the function. You can specify as arguments any type of record (working storage, SQL, UI Record, and so on), however the receiving parameter can only be a working storage record. This means that record state cannot be tested or modified (the statement TEST recname NRF is not allowed if recname is the receiving parameter): you can set/test the argument name directly (instead of the parameter), but this defeats the purpose of function for generalization and reuse.
37
If literals are passed as arguments, they must be received as data items. If the item is modified within the invoked function, the test facility will stop with an error! However, if you generate anyway, this condition is not detected by the validation step of pre-processing, and during runtime the modification will just be discarded upon return to the invoking function (literal is essentially protected by creating a local copy of it within the function). Figure 18 reviews some additional capabilities of functions.
Table lookup logic

FIND state_code states-table.code truefunc, falsefunc; No arguments TEST EZEAID PF1 truefunc, falsefunc; No parentheses
I/O Error Routine, Map item edit routine

No arguments Two-tier approach required to implement generic reusable routines Convenient to split edit logic for map arrays
Function use restricted in Flow statements

Only allowed use of Functions as part of a program flow segment is to transfer to main Functions in the program
Figure 18. Other Uses of Functions
Functions can be specified as the true and false routines of a FIND or a TEST statement. In this case no arguments can be specified on navigating (and the statement editor will not even let you enter the parentheses), so the basic use is for control transfer. Functions can be specified as the error routine of an I/O option, and as an edit routine of a map data item. In this case, no arguments can be specified on invocation, so to create reusable error processing functions or generic edit functions, you need to implement a two-tier nesting approach: the I/O error function is specific to the I/O (aware of specific record state and data) and in turn can invoke a generalized error processing logic passing required arguments. For a map item edit function, a tier-1 function will invoke the generic edit function passing the map item to be checked: this is a recommended way to handle map array edits: tier-1 function (specified for the array) invokes tier-2 function that accepts the current array item in a parameter, so that the edit logic can be written once for all elements of the array.
38
3.1.2 Examples
An example of reusable logic, implemented using a function, is shown in Figure 19.
Figure 19. Function Logic Example
The example in Figure 19 shows how you can create a Universal validation routine, for example you have a common algorithm for all Identifiers. This reusable function (IDVALIDATOR) is invoked from CUSTOMER_INSERT to validate, in this case, the customer ID. The generic reusable function sets the return code for the invoking function, and it does not know or care about the fact that is validating Customer ID or Supplier ID or whatever. Notice the definition of the functions local storage and parameters. The LOCALREC data structure could be also used in other parts of the program, but when used here, the storage area is obtained locally to the IDVALIDATOR function only. An example reusable map edit routine is shown in Figure 20.
39
Figure 20. Map Edit Routine as a Function
The example in Figure 20 shows a map array, SALARY[1...4], with an edit routine MEDF1. MEDF1 is a function with a local storage variable, NUMBER. MEDF1 is invoked automatically when any of the elements of the array is modified, it loops through all elements and for each invokes a reusable function, MED2, passing the current element of the array, SALARY[NUMBER]. MED2 actually implements the edit algorithm and receives the current element as parameter SAL, as defined in Figure 20.
3.1.3 Loose Typing

Loose typing support allows for the definition of generalized functions that may work with slightly different arguments (for example, if you want to pass numeric items with different number of decimal places to the same function) Parameters can be defined with a loose typing option: ANYCHAR ANYNUMERIC ANYMIX
40
ANYDBCS ANYHEX The choice of loose typing helps widen the scope and flexibility of a reusable function. There is no need to specify bytes or decimals. The test facility and generated program logic determine what conversion is required based on the data passed to the function. Note: The use of loose typing may have an adverse effect on the size of the generated code (extra testing and conversion logic generated in the 3GL program). If you define the parameter type as one of the available loose values, you do not need to specify the decimal places or bytes values, thus no strong matching is enforced between arguments and parameter characteristics. If conversions need to occur, they are performed by VisualAge Generator (during test or generation).
3.1.4 Syntax and Part Type Changes

Logic syntax must change when using functions, the statement syntax required is different from that used by the previous logic parts (processes and statement groups). During migration (see Chapter 9, Migrating an Existing System to Developer on Java on page 153) the appropriate function syntax is produced as processes and statement groups are converted to function parts: Invocation statements are updated and CALL EZExxx statements are automatically transformed into function invocation syntax. The use of standalone invocation or inline invocation depends on the function being referenced. REPLY option processing is implemented, as required. Examples:
Before After
CALL EZESTLEN source length; CALL EZEMAX item1 item2 result;
length = EZESTLEN(source); result = EZEMAX(item1, item2);
When migrating from previous versions of VisualAge Generator or from CSP, processes and statement groups are automatically transformed into functions by the VisualAge Generator V4 import facility.
41
During import, statements are also parsed, and PERFORM statements and statement groups invocation statements are transformed into function invocation statements. During import, if statements are found that use VisualAge Generator supplied functions (such as string manipulation or math functions), the former type of invocation, using a CALL statement, is transformed into the appropriate function invocation. Depending on the function, this may become an inline invocation or a standalone invocation, as shown in the two examples. Use of the REPLY option on the CALL statement, is transformed into the appropriate equivalent use of the new function word, EZEREPLY, by adding a statement prior to the function invocation.
Note: Migration processing also converts process and statement group logic to the new function syntax.
3.2 Object Scripting

The new Object Scripting facility allows 4GL functions to directly invoke other functions written in Java (or Smalltalk, when using the Developer on Smalltalk).
3.2.1 Introduction
The Object Scripting facility is an innovative way to enhance the power of the VisualAge Generator environment by allowing direct and synchronous access to Java or Smalltalk methods from within a 4GL function running in the Java or Smalltalk environments. The fact that Object Scripts are executed immediately (synchronously) in the middle of the 4GL statements execution makes it possible, for example, to interact with UI parts based on the content of a 4GL data area or based on 4GL events. An example can help clarify this. Suppose you want to implement a status indicator based on the content of a 4GL data item: using Object Scripting you can fire a method that updates the status indicator on the GUI, and the Java or Smalltalk script can interrogate the VisualAge Generator data item to refresh the status value synchronously.
42
Prior to the availability of Object Scripting, a VisualAge Generator programmer would have had to resort to a complex and unnatural application design to accomplish this simple requirement. Another advantage of Object Scripting is the possibility to make data that can be modified outside of VisualAge Generator logic (such as in an EJB, Java, or Smalltalk environment) immediately available to VisualAge Generator statements. Because of the ability to directly invoke components such as Enterprise Java Beans (EJBs), Object Scripting is also an important step for e-business enablement.
3.2.2 Implementation
The new VisualAge Generator EZESCRPT special function word statement allows for the invocation of a Smalltalk or Java method (depending on the current development platform). EZESCRPT accepts a single parameter which can be either a literal with the name of the method to be invoked, or a data item whose value is the name of the method to execute (see Figure 21).
Note: The script invocable with EZESCRPT does not accept parameters.
Class
VG Function
WHILE DONE NE 1; ..... EZESCRPT ("showValue") IF DONE NE 1; .... END
showValue
Definition
New 4GL statement Code script natively or use Wizard Visibility:
Script can access 4GL parts in Class Script must be defined in Class
Test
Debugger integration Stack monitor nests through scripts
Figure 21. How Object Scripts Work
If you are not familiar with the Java or Smalltalk language, a wizard facilitates building required methods.
43
The method must be defined as part of the current class (the one that contains the VG function issuing the Object Script). In the method you can access any object/part visible within the class, including VisualAge Generator parts. For example, all the VG parts that have been dropped in the FFS are addressable from within the Java or Smalltalk script (method). The method can retrieve or store data in any visible VisualAge Generator data area. The method can invoke the synchronous execution of a visible VisualAge Generator function, thus allowing for nested VG-Java/ST-VG execution and true synchronized interoperability between VisualAge Generator logic and Java or Smalltalk logic. When the script terminates, control will return to the statement following the EZESCRPT statement in the invoking function. At this point, all data modified by the method is available to VisualAge Generator. During testing, when the EZESCRPT statement is found, the Java or Smalltalk debugger takes over to let you follow the execution of the Java or ST logic within the script. However, the VisualAge Generator Test monitor remains available, and in fact, if the Java method should invoke another VisualAge Generator function, this function will be placed on top of the current VisualAge Generator stack and will be visible in the stack monitor.
3.2.3 Data Exchange

Exchanging data between VisualAge Generator and Java requires you to do some data type mapping. You do not have to perform these mappings manually, they are provided by VisualAge Generator as part of the behavior of the VisualAge Generator parts in a Java environment. For example, let us assume that a data item named SALARY defined as PACK in a record called STAFFWK must be retrieved into a Java variable of type int named salaryValue. VisualAge Generator parts can be obtained through the getPARTNAME() message which becomes available to the class being defined in the moment the part is dropped in the FFS. Each VisualAge Generator part then makes available methods that return a Java equivalent of their content: in our case the record part STAFFWK (which is obtained through the getSTAFFWK() message) can be asked to return the value of one of its data items, and since the item was a PACK it can only be received as a long using method getLongData("data item name") . Shown in Figure 22 is the Java statement we need to write in our Object Script. In this example we cast the long into an int).
44
Get the value contained in SALARY data item and put it in Java integer variable salaryValue
Java method ... ... salaryValue = (int) getSTAFFWK().getLongData("SALARY"); ...
Store the literal "Stefano" into data item NAME

Java method ... ... getSTAFFWK().setStringData("NAME","Stefano"); ...
Figure 22. Data Exchange
Figure 22 also shows an example of how to set the value of a VisualAge Generator CHA data item using another protocol of the record part STAFFWK. The method setStringData is used because we set a CHA data item using a Java string). This approach will allow programmers to interact with all VisualAge Generator part types. Code that uses these methods is automatically generated when connections are made to VisualAge Generator parts in the Visual Composition facility (see 2.2.7, Making Connections on page 25). The script wizard is also a good way to facilitate writing these type of statements, so that the programmer does not need to learn the special protocols.
3.2.4 Script Wizards

The Object Scripts Wizard facility is designed to facilitate composition of Java or Smalltalk methods that are syntactically correct (Java syntax can be particularly difficult and error-prone, with the need to code for exception handling, and so on). The Object Scripts Wizard aids 4GL programmers in building methods, making it easy to access names and properties of all available subparts (for example, the UI controls that have been defined in a GUI, or the parts that have been dropped in the Free From Surface, including the VisualAge Generator parts).
45
To define a method (or Object Script) using the assistance of a Wizard, you need to go to the Class Definition facility of VisualAge for Java or VisualAge Smalltalk; you cannot invoke a wizard from the VisualAge Generator function definition editor. This is because the composition of a method requires the context of the containing class (and you could define a function part without having a defined class context. Figure 23 shows one of the dialogs shown during the use of the VAGen Script Wizard.
Figure 23. VAGen Script Wizard SmartGuide
It is important to understand that the intent of the VAGen Script Wizard is to facilitate writing methods that allow easy access to parts and their properties.
46
In general, the wizard is optimized for the simplification of the basic tasks that VisualAge Generator programmers will need; the wizard was not designed to assist in the development of general purpose methods. The coding patterns supported by the VAGen Script Wizard include: Get an objectto get an object in the class and assign it to a variable Set a valueto set a property of an object in the class Invoke an actionto send a message to an object in the class Free form statementallows you to enter any statement
You could use a set pattern, for example, if a data item must be set conditionally based on different contents of other Java parts properties (for example, if the value of a slider is below a threshold, you may want to set the data item value to 0; otherwise set the data item to the actual value).
3.2.5 Object Scripting Examples

Two Object Script examples are shown in Figure 23.
FUNC1
IF SALARY NOT NUMERIC; EZESCRPT("ErrorInMsgField"); END; STAFF ID SALARY ... MsgField errorInMsgField
GUI1
void errorInMsgField() { java.awt.TextField localField; /* set error text and set field red */ localField = getMsgField(); localField.setText("Salary is not numeric!"); localField.setBackground(java.awt.Color.red);
FUNC2
EZESCRPT("validateID"); IF MESSAGE = " "; CALL CUSTSRV CUSTWS; END;
validateId
GUI2
TextField1
CUSTWS CUSTID ... MESSAGE. ..
void validateID() { String myid; myid = getTextField1().toString(); if (myid.length() != 4) { getCUSTWS().setStringData("MESSAGE", "Invalid Identifier");} else { getCUSTWS().setStringData("CUSTID", myid.toUpperCase();} }
Figure 24. Object Scripting Examples
47
In the first example, we see how a 4GL function (FUNC1), which is being used inside a Java Application (GUI1) to validate the SALARY data item, can invoke an Object Script (errorInMsgField ) to set a message Text field (MsgField) control defined in the Java GUI1 application to the color red. Notice how the 4GL record STAFF is also part of GUI1 (so that FUNC1 can reference the record contents). Also notice how the method errorInMsgField (our script) is one of the methods defined for GUI1: this method obtains the MsgField object into a local variable, which is a java.awt.TextField, using the getMsgField() method. (This method becomes available as part of the protocol of GUI1 after you drop the TextField part on the GUI, name it MsgField , and you save the bean.) At this point the whole protocol of the java.awt.TextField class is available for the local variable: we used the setText(String) message to set the message text in the message field, and the setBackground(java.awt.Color.red) to set the color. This script can be built using the Object Script wizard. The second example shows how an object script (validateID ) can be invoked from a function (FUNC2) to perform a validation of the content of a VisualAge Generator data item (CUSTID) before calling a server program to go add a customer to the database. We take advantage of the Java String class protocol to make sure that the length of the Customer Identifier is 4 digits, and to fold the entered string to uppercase if the length is correct: notice how the script validateID communicates with VisualAge Generator data items MESSAGE and CUSTID to set them to values according to the results of the validation algorithm, prior to returning to the invoking function FUNC2. In fact, the FUNC2 statement following the EZESCRPT invocation directly tests the content of MESSAGE (which was set by the Java method) to determine how to proceed.
3.2.6 Reusable Object Scripts

Here we take a look at how it is possible to write reusable Object Scripts. A classic example for the need of reuse is when the exact same sequence of actions must be done for a group of different parts in the Application (or Applet or class in general). In Figure 25 we look at how we could (using Developer on Smalltalk and Smalltalk logic in this example) write a single script (errorInFiled) that applies error processing logic across different Text field parts on GUI1.
48
.
FU NC1
IF SALARY NOT NUM ERIC; M OVE "SalaryText" to FIELD_N AM E; EZES CRPT("ErrorInField"); END; IF FIELDLE N(ID) NE 4; M OVE "IdText" to FIE LD_NAME; EZES CRPT("ErrorInField"); END;
GUI1
errorInField
VGREC | localField | ... FIELD_NAME ... " get subpart name from VG find subpart and set to red" localField: =(( self subpartNamed: 'VGREC') abtAtAttribute:#'FIELD_NAME' data). (self subpartNamed: localField) backgroundC olor: 'red'.
Figure 25. Reusable Object Scripts
In Figure 25: The 4GL logic: Does the validation of the values (contained in VisualAge Generator data items SALARY and ID) Sets the data item FIELD_NAME to the name of the data item being validated in the GUI part Invokes the script ErrorInField The script (Smalltalk in this example): Finds the subpart corresponding to the name passed to the script in FIELD_NAME by the 4GL logic Uses a method (backgroundColor: aColor ) to set the named GUI entry field to red
3.2.7 Event Synchronization

When you use Object Scripting, your application design must take into account the fact that there is a difference in the way events are fired. Event behavior differs when Object Scripts are mixed with 4GL logic.
49
When you code an Object Script statement that will trigger a 4GL event, the event is fired synchronously instead of being deferred until the end of the execution of the function (see Figure 26).
Using EZESCRPT changes event synchronization Events triggered by EZESCRPT are fired immediately
FUNC1 ..... EZESCRPT ("myScript") .... myScript
GUI1
set ITEM1 ITEM1 event

FUNC3
FUNC2
..... ITEM1 = 1; ....
execute
Events triggered by 4GL (data triggers) are deferred until the end of the logic unit or until an EZESCRPT statement
Figure 26. Events Synchronization
The example in Figure 26 shows an event trigger for ITEM1 that will cause the execution of FUNC3. This event is triggered by both FUNC1 and FUNC2: FUNC1the event is fired immediately after ITEM1 is modified by the Object Script myScript invoked from FUNC1 The end result of the execution of FUNC3 logic (such as the availability of new or modified data) is immediately available to the logic following the EZESCRPT statement found in FUNC1. FUNC2the event is fired after FUNC2 has finished execution if ITEM1 was modified by a 4GL statement inside FUNC2. The end result of the execution of FUNC3 logic is not available until after FUNC2 has completed.
Note: Existing VisualAge Generator applications will continue to behave consistently after migration to V4. The pure 4GL event trigger processing is consistent with previous versions.
Another word of caution on events synchronization: now that we have mentioned how some events are triggered immediately within a script, we
50
need to mention that there are some exceptions: One exception is the clicked event of a button: this is a deferred event, which means that if the script sends a message to click the button, the clicked event will let other pending events to be processed first. Another situation is peculiar to Java: Java handles events in separate threads, which do not process until the current thread completes execution; therefore if within your script you change the value of a TextField, and your visual composition uses the textValueChanged event to execute a 4GL function, the function will not be executed within your script, but at the end of it. We have not identified all possible exceptions, so additional experimentation and study will be required.
3.3 VisualAge Generator Templates Enhancements

The new features and functions provided by VisualAge Generator Templates in the VisualAge Generator V4 development environment are reviewed in this section.
3.3.1 Introduction
Support for VisualAge Generator Templates development is provided in both VisualAge Generator V4 development platforms (see Figure 27).
VisualAge Generator Templates is implemented in both development environments:

Developer on Java Developer on Smalltalk
VAGT VA Generator
Based on shared:
Information model User interface Generator design
VAGT VA Generator
VA Smalltalk
IBM Smalltalk
VA Java
Java
Figure 27. VisualAge Generator Templates Development Support
51
The new VisualAge Generator Templates support for V4 includes: New generator types Improved development user interface Isolation of generation and functional entity definitions for improved definition source management
3.3.2 Architecture
The VisualAge Generator Templates architecture is shared on both development platforms (see Figure 28).
Basic Architecture is the same for Java and Smalltalk
Other tools
Database
Import
VisualAge Generator Environment

VAGen Parts VA Smalltalk Parts VA Java Parts
Information Model
VAGen Templates Browser
VAGen Templates Generators
Customization
Other targets
Figure 28. VisualAge Generator Templates Architecture
The shared architectural framework includes the following features: The same information model and user interface is used to support definition and generation. The Information Model and generation technology can be customized. Relational database import support bulk-loads the Information Model with data definitions. The VisualAge Generator Templates browser supports Information Model entity definition and generation. The entity definitions represent the basic system constructs, which can be implemented by generators in any chosen target runtime environment.
52
The design of the generators is shared, with some producing identical code on each platform (TUI, Web Transaction). Other generators are designed for the target runtime platform (Smalltalk-based or Java-based GUI systems.
3.3.3 Generation support

The VisualAge Generator Templates generator (see Figure 29) in the Developer on Java environment is a series of Java classes that are used to implement the Java framework. Visitor is the term used on the Developer on Java platform (the term comes from a design pattern domain).
A Generator/Visitor is a Java class that uses : the generation framework, the API of the Information Model the Target Entity classes Visitors to build target entity instances.
(user and standard)
Fetch specs
Relatio nal Tabl e D ataE l ement nterfac I e Un it Busi ness O bjec t
Build
ValueS tyl e
Information Model Entities (Visitables)

Figure 29. What is a Generator/Visitor?
Generation Framework
Target Entities
As shown in Figure 30, the high level architectural view for a system generated by VisualAge Generator Templates is the same for all target runtime environments (generator types).
53
TUI / Main Programs Smalltalk GUIs and Objects Web Transaction Programs UI Records Java GUIs and Objects Server program parts Reusable system functions
Presentation Navigation, Error Management, and Control flow Business
Data
Figure 30. Generated System Architecture
During generation, entity definitions are obtained using the Information Model API, and a target system (entities) is created. A generator: Produces client and server components for graphical and textual user interfaces Automates the production of functions for: Data access Concurrent access management Presentation Navigation Other reusable functions
Allows development standards to be integrated into generation process As shown in Figure 31, generation control for a specific generation request is a mix of: The scope of the generation request. The number of generators that are run against a entity instance is determined by the generation scope defined for a generation request. The store processing option chosen. The target package names are defined in the generation parameters.
54
Generation Scope
Generation Scope
Instance only With associates With associates and predefined beans
Interface Unit Business Object Target Interface Unit
Relational Table Data Element
Workspace
Store Options
Normal Overwrite Reset Customize
Pkg1
Proj
Pkg2
Pkg3
VAGen Records
VAGen Programs VAGen DataItems
VAGen Functions
Figure 31. Generation Scope and Store Control
The generated component types created during generation are also defined as part of a generation request: Client Server Layout This provides flexibility in team responsibility and generation independence.
3.3.4 Generation Parameter Management during Development

The basic development process steps are: Import relational database specifications Define entities in the Information Model Define generation parameters for target system Generate the target system using VisualAge Generator Templates generators Add required business logic and functional extensions using VisualAge Generator
55
The development cycle is circular, with refinement of technique and generator functions (customization) occurring during a single development cycle and over multiple development projects. Key points in this process are: Generation parameters control the creation of distinct systems, sharing of generated parts is controlled by the values used to define generation processing logic. Reuse of VisualAge Generator Templates Information Model definitions is possible with effective management of the generation parameters. That said, reuse and proper management of generation parameters was a difficult task with VisualAge Generator Templates as implemented in VisualAge Generator V3.x. The following general principles and goals drove the enhancement of VisualAge Generator Templates for VisualAge Generator V4: Keep technical specifications independent from the functional business specifications Reuse model instances for GUI, TUI, and Web UI Use default values for generation parameters Allow for customization at multiple levels With V4, VisualAge Generator Templates supports the following customization levels for entity specifications (see Figure 32): Workspace parameters Entity parameters Redefining parameters at the instance level
56
Cust IU Interface Unit Cust IU Cust IU Cust IU

VAGen Records
Proj Sub Sys A
...
Pkg Pgm 3
W O R K S P A C E
Business Object
Pkg Pgm 1
Pkg Pgm 2
VAGen Programs
VAGen Functions VAGen DataItems
Relational Table
Cust IU Cust IU Cust IU Cust IU Cust IU Cust IU
Data Element
Proj Common Parts

Pkg Records Pkg Shared Code VAGen Functions
Value Style
Generation parameters define target package structure

Figure 32. Entity Parameter Definition Levels
Generation parameter definitions can be stored in: A workspace instance At the entity level, as defaults for each entity type instance At the entity type instance level, to adjust parameters for specific system specifications To support this segmented storage of information model entities and improve overall usability, the functionality of VisualAge Generator Templates definition user interface was dramatically improved. Figure 33 shows the VisualAge Generator Templates browser provided with VisualAge Generator V4.
57
Figure 33. VisualAge Generator Templates Entity Browser
At the workspace level, the first set of decisions are made. Separate project/package sets can be used to store workspace and other entity definitions. At the workspace level: These generation parameters are shared by all Information Model entities: Common graphical user interface parts Common textual user interface parts Client / Server responsibilities concerning checks, commit, and so on Error message management functions Part naming conventions Target package structure
They are stored in the workspace. They can be managed independently of entity definitions.
58
VisualAge Generator Templates allows for the definition of default parameters, at the entity level, that will be used by all entity type instances. At the entity level: These generation parameters are shared by all the instances of a given entity: Interface Unit Business Object Data Element Relational Table
Some examples of Business Object generation parameters shared by all Business Object instances are: Layout characteristics (number of columns and rows) Database access display (bar menu, popup menu, push buttons) Display of extraction criteria Generation control definitions can be overridden at the instance level. Some instance level customization examples are: Graphical presentation of Data Element instances: Combo box Multi-line edit box Radio button Graphical presentation of Business Object instances: Notebook Group box Form with or without border This granular customization approach provides great flexibility.
59
3.4 WebSphere Rapid Application Development

In this section, which describes WebSphere RAD support: We review how a Web-based transaction system would be implemented on the IBM WebSphere Application Server runtime platform. We introduce the concepts of Web Transaction development using VisualAge Generator UI Records. We review the VisualAge Generator development, testing, and generation support for rapid development and implementation of Web-based application systems on the WebSphere Application Server runtime platform.
3.4.1 Native (Java-Based) Development

Typically, a Web application programmer must string a series of servlets and JSPs together to render the complete Web-based business application (see Figure 34).
Web browser
Web server
Websphere Application Server
Comm Gateway
Data/Tx server
1.
Java servlet Java servlet Java servlet

4.
2. 3.
TX Program
5.
Session
Java Server Java Server Page Java Server Page Page
Database
Java Virtual Machine

Figure 34. Anatomy of a Web System
The servlet will receive and process the HTTP request and, using JSPs, send back an HTTP response. The Web programmer is also likely to save the conversation state for the user on the Web server during an ongoing transaction with that user over potentially many servlets.
60
The following processing steps are performed in the Web-based transaction system shown in Figure 34: 1. The browser invokes a servlet from an HTML FORM. 2. The servlet reads the data from the FORM INPUT fields using its HttpServletRequest object. It may create, or instantiate, new Java objects which hold this user data. It may also initiate some enterprise access, for example, look up information on a database. The results of the enterprise access may cause the instantiation of other objects. 3. The servlet now needs to create a new session object for the user, or else reference an existing one. There is a single method, getSession() of the HttpServletRequest to do this. Once we have reference to a session object, we can store references to objects for that user in it. Typically the objects we referred to in 2. 4. The servlet invokes a JSP, passing the HttpServletRequest object. 5. JSP syntax will allow you to effectively run a getSession() against the request and also to then query the session object to locate user objects, so they may be displayed to the user in the final HTML stream sent to the browser. As outlined in Figure 35, basic (native) development for a Web-based transaction system requires a mix of skills, all of which are hard to master and typically require the coordinated effort of multiple individuals.
Web-based Transaction development has high cost of entry: Java programming skills Servlet programming
Request/response architecture State management JSP Communications with tier-3 servers Web UI design and linkage to remote programs
Simplification of programming model and the associated reduced skill requirements will lower cost of entry for Web-based transaction system development.
Figure 35. Web-Based Transaction Programming Skill Requirements
One of the underlying goals of VisualAge Generator has always been making complex tasks easy. The task of building Web-based transaction systems is made easier with the WebSphere RAD support provided in VisualAge Generator V4.
61
3.4.2 The VisualAge Generator WebSphere RAD Solution

The VisualAge Generator solution begins with the recognition that the high-level view of a Web-based transaction system has a simple processing flow (see Figure 36).
Terminal
CICS/IMS
COBOL pgm Restore state if required Business Logic Validation Access Data Data formatting Call other programs Navigation Save transient state Commit/rollback CGI/Servlet Restore state if required Business Logic Validation Access Data Data formatting Call other programs Navigation Save transient state Commit/rollback
request
execute send
3270 d.s.
Browser
Web Server
request
execute send page
HTML d.s.
Figure 36. Comparing 3270 and Web Systems
When considered from a distance, the processing flow for a 3270 transaction and Web-based transaction system using servlets is very similar: The user view sends a request to the runtime domain. The runtime domain recovers any stored information that may be required to continue the conversation. Edit and business logic is used to react to the request and formulate a response. Information required to continue the conversation is stored. The response is returned to the user view.
62
Based on this comparison, we recognize two things: There is an affinity between Web systems architecture and 3270 pseudo-conversational systems. VisualAge Generator knows how to generate and implement such systems. This has resulted in the introduction of a new model of programming as part of VisualAge Generator V4. This new programming model includes: A new main program typeWeb Transaction A new record typeUser Interface (UI Record) The Web Transaction programming model is related to the model used for TUI programming in VisualAge Generator (see Figure 37). Similar component roles exist, and the method of interacting with the end user is based on the use of the 4GL CONVERSE processing option.
Provide a similar 4GL single threaded programming model to the one used for 3270 pseudo-conversations
Main Transaction Map Map Items
Formatting Validation
Web Transaction UI Record UIrec Items

Formatting Validation
CONVERSE mapname Single Segment XFER maintran mapname maintran with First Map
CONVERSE UIrecname Single Segment XFER webtran UIrecname webtran with First UIrec
Figure 37. Mapping 3270 Programming Constructs to Web Transaction Solution
This implementation of the Web Transaction programming model for Web-based transaction systems is a derivative of the existing VisualAge Generator approach for support of CICS pseudo-conversational programming. Support for Web Transaction development is fully integrated into the VisualAge Generator environment (see Figure 38).
63
Development
Web-Transaction
Testing
Browser
UI Record Default HTML
Test Facility
Web-Transaction CONVERSEd or XFERed UI Record
CONVERSed or XFERed UI Record
Generation and Runtime

Gateway Servlet Browser Java Beans Default JSPs Catcher Program
Generated Web-Transaction
Figure 38. Web Transaction Implementation Overview
The support for this new Web Transaction programming model implemented in VisualAge Generator V4 permits: The development of Web Transaction main programs, using 4GL programming techniques, which interact with end users in a Web browser. These 4GL-based programs implement user interface, business logic, and database processing, which can be implemented in either a series of main programs or a set of main and called batch (server) programs. Testing of these new programs, using the existing VisualAge Generator test facility and a Web browser. A default view for the UI Record is used in the browser. This communicates directly with the main program being tested. The use of generation technology to handle the complexities of runtime communication and processing. When generated, the VisualAge Generator Web Transaction program can be implemented in a Web server runtime domain (see Figure 39). The actual runtime processing is similar to that used for a native Java implementation (see Figure 34 on page 60), but this complexity is hidden from the development programmer. The development programmer works with the logical specification.
64
Simplify definition and testing of solution Generate Java and provide runtime support on tier-2 Generate 3GL code for tier-3 Automatically connect to tier-3 as needed
UI Record Web Tx Program
Logical Specification Actual Implementation
Comms Gateway
VG Gateway servlet (runtime supp)
TX Program
Session
Java Server Page
Database
Java Virtual Machine WebSphere Application Server

Figure 39. Web Transaction Implementation: Mapping Definition to Runtime
Runtime involves several tiers: 1. A Web browser 2. A Web server with servlet support, perhaps using the IBM WebSphere Application Server 3. A VisualAge Generator Server runtime environment (such as CICS or TX Series) The Web server and VisualAge Generator Server could potentially be on the same machine.
65
When you code a Web Transaction, VisualAge Generator generation produces: A COBOL or C++ load module to run in the VisualAge Generator server environment A Java bean, which represents the data in the UI Record A Java bean to run any edits (other than VAGen server side edit routines) for the UI record, to fill out any titles and labels, handle help, and do any other UI Record processing A Java Resource Bundle, which represents the data in the message table A Java Server Page, which will handle formatting and sending the display of the UI to the Web browser Edit table(s), consisting of a binary file and a Java wrapper VisualAge Generator provides the following: Gateway Servlet A session ID manager A catcher program (for certain environments, some environments make use of existing facilities) By implementing support for an effective, easy-to-use way of building a Web-based transaction system, VisualAge Generator reduces the cost of entry for most programming shops (see Figure 40).
Reduced cost of entry to Web System development

No Java, JSP, Web programming skills No need to learn Java communication API Simpler programming model Built-in edits, help, reduce coding requirements
Rapid iterative development/prototyping

Full support in VisualAge Generator Test Faclity No need for runtime infrastructure setup!!
Separation of concerns between Transaction Programmer and Web User Interface Developer
Transaction programmer defines UI Record with content and actions Generated components are referenced by Web developer
Figure 40. Benefits of VisualAge Generator WebSphere RAD Approach
66
The VisualAge Generator Web system development approach: Makes everyone a Web system developer (COBOL skills translate well to 4GL). The learning curve, based on the native approach (Java, servlet, JSP, private communications protocols) does not exist here. 4GL source code can be rapidly defined, tested, and implemented using the VisualAge Generator development approach. The Test Facility is integrated directly with the Web browser. The architecture used to implement a VisualAge Generator Web Transaction system allows for extension of the user interface view by experts in the Web development front end tool set.
3.4.3 Web Transaction Program Development

The development process for a Web Transaction-based system includes the following activities: Define UI Record and UI Type properties for data items: Data item edits (such as validation) Data items UI type properties (input/output, submit, form, and so on) Define Program as Web Transaction: Write program logic with references to UI Records Can CONVERSE or use XFER (single segment) approach Data I/O and CONVERSE in same Web Transaction Animate through ITF, which supports: Simulation of business logic execution Starting browser and dynamically building HTML for UI Records Handling browser submit request and linking back to 4GL Test Facility The UI Record links the Web browser user interface and business processing domain (Web Transaction program). A UI Record, which is an organized set of data items and properties: Determines what data is sent to, and received from, the browser Contains user action indicators (what push button was clicked) Can contain transfer control information (where to go next) Contains UI functions (for example, Help, Labels, Edits) Enables default HTML rendering
Figure 41 shows the VisualAge Generator record editor for a UI Record.
67
Figure 41. UI Record Definition
A UI Record definition looks just about like any other record when viewed in the record editor. The UI Record includes a set of data items (shared or nonshared), with support for levels (03, 05, and so on), general characteristics (type, length), and other properties specific to the record type. The UI Record specific properties for both the record, and the data items in the record, make the UI Record special. the UI Type and UI Properties columns in the record definition show options that support the use of a UI Record as a browser interface definition. These properties determine the role of each UI Record data item, how it will be managed in a browser view, and what interaction is possible in both the browser and the Web Transaction program. The test facility triggers default HTML generation when a UI Record is CONVERSEd.
Note: This default HTML generation used during testing emulates the functionality that will be provided when the UI Record is generated into Java Beans and JSPs for use at runtime.
The UI Record UI Type and associated properties determine the function of each data item.
68
Record attributes that are new for a UI Record are: Help Text Default help text for the entire UI Record TitleDefault title for the UI Record Submit Value Item Name of data item in UI Record that will contain the value of the actual submit button on the form presented to the end user Data item attributes that are new for data items defined as part of a UI Record include: User Interface TypeThe user interface type defines how the data item is used in the user interface. The User Interface Type value, along with other data item attributes (such as occurs, substructuring, and so on), determine the content of: The default HTML that will be generated for the UI Record during testing (displayed in the Web browser). The JSPs that will be created for the UI Record during generation. The following User Interface Type values are supported:
Input Output Input/Output None
Specifies that input can be entered by end user and that edits will be run on the input data. Specifies that output edits will be performed on data received from the server. Specifies that INPUT and OUTPUT attributes are defined. Specifies that this field is not to show on the user interface and that no edits are to be defined for it. Items with this setting are typically used as control data for user-defined edits, or as items such as the one defined as the Submit Value Item . Defines an item to contain a value (or set of values if for an occurring data item) that can be received into the Submit Value Item when a user submits a form back to the server.
Submit
SubmitBypass Same as Submit; however, when these buttons are pressed, all input edits are bypassed. ProgramLink
Defines a data item that implements a push button in the visual display. This button, when pressed by the user, will implement a link to a defined program.
69
Hidden
Specifies that the data item will not be displayed in the browser, but can contain data to be returned to the program. Specifies that the data item will be implemented as an HTML form. All data items in this data item structure will be part of the same HTML form.
Form
OCCURSITEMNumber of occurrences item. For an array item, another item in the record can be referenced as the Number of occurrences Item. This item must be a numeric item with no decimals. The values set into this item determine the number of occurrences in the array item that actually get displayed in a list. INDEXITEMSelected Index Item. For an array item, another item in the record can be referenced as the Selected Index Item. This item can be occurred. If occurred, the array will be a multiple select list. If not occurred (occurs=1), the list will be single select. The values set into this item are the indices of the elements that were selected by the user. HELPTEXTItem Help Text Help text defined for the item. This attribute is saved with global data items to facilitate sharing of help text between all records that use the item. LABEL Item Label Default Label for the item. If the item is occurred and is of type Submit , SubmitBypass , or Link; labels can be defined for each occurrence. Once the UI Records have been defined, Web Transaction programs can be built that use the UI Records to interact with a Web browser. As shown in Figure 42, there are two Web Transaction program design options available in VisualAge Generator: CONVERSE program design First UI Record program design
Conversed UI Record Display Options
Figure 42. UI Record Display Options for a Web Transaction Program
First UI Record Pgm
70
Testing of these new programs is performed using the existing VisualAge Generator test facility and a Web browser (see Figure 43).
ITF dynamically buids default HTML when CONVERSE or XFER statement found Browser launched if necessary ITF waits for user input UI Record data from FORM sent back to ITF ITF runs all edits, re-send page with error if necessary If edits pass, ITF resumes Web Transaction execution At end of Web Transaction being tested, ITF displays defualt entry point page with list of available Web Transactions
Test Facility Web-Transaction Browser

UI Record Default HTML
CONVERSed UI Record
Web-Transaction XFER ,UI Record
Web-Transaction with first UI Record
Figure 43. Web Transaction: Testing
A default view for the UI Record is used in the browser. This communicates directly with the main program being tested. Rules are used to determine the appropriate HTML element to use for each data item in the UI Record (see Figure 44).
UI Type = Input or Input/Output UI Type = Output
<INPUT TYPE=TEXT NAME="SALARY" VALUE="
">
<b></b>&nbsp Enter staff ID and push Find
UI Type = Submit
<INPUT TYPE=SUBMIT NAME="BUTTONS" VALUE="Find"> HTML tables, HTML Lists
Items w ith occurrences
Figure 44. UI Record Mapping to HTML Based on UI Type
71
The following rules determine if the data item should be included at all: Data items with a User Interface Type of NONE do not show on the generated page. Data items with a User Interface Type of SubmitBypass or Submit work the same.
Note: In the text below, the data item attribute User Interface Type (in a UI Record) will be referred to as UIType. Single occurrence data itemno substructure:
UIType = Input or Input/Output Data item length <= 80 Data item length > 80 UIType = Output UIType = Submit Data item LABEL followed by Text input field. Data item LABEL followed by Text Area (multi-line text) input field.
Data item LABEL followed by plain text of data item. A single submit button with the label of the item as the button text is used. All Submit buttons display at the end of the form. A single hypertext link with the label of the item as the link text is used. If there is no label, then the value of the item is used. The value of the HREF attribute of the <A> HTML element will contain the program name and parameter name/value pairs as defined by Program Link properties. Provides true/false support. Valid numeric item values are 1 (true) and 0 (false). Valid character item values are Y (true) and N (false). The data item LABEL and then a checkbox.
UIType =ProgramLink
Boolean
Data Item Edit
Multiple occurrence item with no substructure:
UIType = Submit
Values will be displayed as a set of Submit Buttons. If a list of Labels is defined for this data item, the label values will be the text shown on the button. Values will be displayed as a set of HTML hypertext links. If a list of Labels is defined for this item, the label values will be the text shown in the link. If there is no label, then the value of the item is used. The value of the HREF attribute of the <A> HTML element will contain the program name and
UIType = ProgramLink
72
parameter name/value pairs as defined by the Program Link properties. Since this is an occurred item, the index used to retrieve values from the value items will be the same as the given link item if those items are occurred or are defined in a substructure that is occurred. UIType = Output Values will be displayed as a select list. If the Selected Index Item associated with the array is a single occurrence item, then the list is single select. If the Selected Index Item is a multiple occurrence item, the list is a multiple select list. If there is NO Selected Index Item defined, the data will be displayed as a block of text; each line being the data at each index of the array. UIType = Input or Input/Output Values will be displayed as list of text entry fields. If there is a Selected Index Item defined, then there will be a Select column of either Radio or Checkbox fields. If the Selected Index Item associated with the array is a single occurrence item, then the Select column will contain Radio buttons only one can be selected;. if the Selected Index Item is a multiple occurrence item, the column will contain Checkbox fields in which multiple items can be selected.
Multiple occurrence item with substructures:
Always displayed as an HTML Table where each leaf data item in the substructure is a column. Data items in the substructure defined as UIType = None will not show as a column. Data items in the substructure defined as UIType = Input or Input/Output will show as a column of text entry fields. If there is a Selected Index Item and the item is UIType INPUT or INPUTOUTPUT then there will be a Select column of either Radio Buttons
73
(single select) or Checkboxes (multiple select), depending on whether the Selected Index Item has occurs > 1 or not. This allows selection of a row from an HTML Table which has no inherent selection function. Some level of field layout can be controlled in the default HTML, as follows: Items of UIType = Input or Input/Output are rendered in the order they appear in the record. Top level items (items that are not substructured) cause paragraph breaks when they are rendered in HTML. To cause fields to be flowed from left to right, a superstructure filler item (named '*') can be added to the set of items that you want to flow horizontally. This implies that if you have a single item at the top level that substructures all the record data, the fields will all flow horizontally. The HTML created for the UI Record implements the processing required based on the UI Record rules for HTML associations (see Figure 45): Forms are used, which direct all responses back to the hptGateway process, the common gateway servlet provided by VisualAge Generator. Input fields are defined with size information to limit length of input string. Literals are defined. Submit UI Types are implemented using push buttons.
</HEAD> <BODY> <H1>Staff Info</H1> <table border=4 width=100% cellspacing=0 cellpadding=20> <tr><td><table border=0 align=left valign=middle> <FORM METHOD="POST" ACTION="/hptGateway"> <P> <b>Id</b>&nbsp<INPUT TYPE=TEXT NAME="ID" SIZE=4 VALUE=" "> <b>Name</b>&nbsp<INPUT TYPE=TEXT NAME="NAME" SIZE=9 VALUE=""> <b>Department</b>&nbsp<INPUT TYPE=TEXT NAME="DEPT" SIZE=4 VALUE=" "> <b>Job</b>&nbsp<INPUT TYPE=TEXT NAME="JOB" SIZE=5 VALUE=""> <b>Years</b>&nbsp<INPUT TYPE=TEXT NAME="YEARS" SIZE=4 VALUE=" "> <b>Salary</b>&nbsp<INPUT TYPE=TEXT NAME="SALARY" SIZE=8 VALUE=" "> <b>Commission</b>&nbsp<INPUT TYPE=TEXT NAME="COMM" SIZE=8 VALUE=" "> <INPUT TYPE=SUBMIT NAME="BUTTONS" VALUE="Find"> <INPUT TYPE=SUBMIT NAME="BUTTONS" VALUE="Exit"> <INPUT TYPE=HIDDEN NAME="hptPageId" VALUE="322964"> <INPUT TYPE=HIDDEN NAME="hptAppId" VALUE="WEBTRAN"> <INPUT TYPE=HIDDEN NAME="hptHandlerId" VALUE="24461"> </FORM> </td></table></tr></table> </BODY></HTML>
Figure 45. HTML Forms
74
3.4.4 Web Transaction Program System Structure Options

There are many options available for how a complete system can be constructed using Web Transaction programs. As shown in Figure 46, there are three ways to transfer control when using Web Transaction programs.
Conversed UI Record Display Options Transfer of Control Options: DXFR pgm W Srec
Direct
First UI Record Pgm
W Srec
pgm
W Srec, First UIrec
XFER pgm W Srec, UIrec

Delayed
pgm
First UIrec2
Program Link or Form Submit

Form/Link
UIrec1
pgm
Specify pgm, and any data item s from UIrec1 to UIrec2 (not needed if same UI Record is used in both or if like names and target is output )
Figure 46. UI Record Display and Transfer of Control Options
The three transfer of control options shown in Figure 46 are: Direct transferNext program starts immediately, no user (browser) interaction Delayed transferNext program starts after return from browser Form/Link transferNext program starts only after user (browser) interaction with displayed UI Record. Form transferinstigated by the program when the XFER , UIRec transfer option is used Link transferdefined when a UI Record data item is defined with the Program Link UI Type. Each of these program design options have different design implications that should be understood before embarking upon creating a Web Transaction application system (see Figure 47).
75
CONVERSE UIrec
HTML sent out on CONVERSE All storage saved and restored automatically Logic can be coded before and after CONVERSE VAGen manages control transfer
W eb Browser
First UI
Generator Web Transaction

CONVERSE
UI Record
W orking Storage Local Records
Session
W eb Browser
W ebsphere App Server
W ork DB VisualAge Generator Server VAGen Server
XFER PROG W S, UI
UI Record
W orking Storage
XFER pgmname WSrec, UIrec

HTML for sent out on XFER Current program ends, Next program takes over Next program receives WSrec and UIrec as First UI Rec VAGen manages control transfer
Session W ebsphere App Server
W ork DB VisualAge Generator VAGenServer Server
XFER ' ' , UIrec
XFER <blank> , UI
Current program ends, HTML for sent out on XFER Program Link or Form on UIrec determine what pgm follows Program that follows receives UIrec only as First UI Record User managed dialog sequence using Program Link or Form
Pgm Link Form First UI
Figure 47. Transferring Control between Web Transactions using UI Records
When designing Web Transaction programs, it is important to understand the issues surrounding the saving of program state. Program state is saved in a variety of ways, depending on the design of your VisualAge Generator program. Through the use of the CONVERSE and First UI Record design options, there are three levels of state saving available. The three state saving options are outlined below:
State Saving Options All (Controlled) State Controlled State Stateless Command Syntax XFER PROG WS XFER PROG WS, UI XFER <blank> , UI Program Design CONVERSE First UI Record First UI Record
The saving of state on the Web server and VisualAge Generator server will have scalability and performance impacts for the entire Web Transaction application system.
76
A Web Transaction program-based system can be constructed using the CONVERSE statements (see Figure 48). This approach results in the implementation of an all (controlled) state model of programming.
Using CONVERSE
WebTrans1
DXFR WebTrans1 WebTrans2
DXFR WebTrans3
WebTrans1
WebTrans2
Pgm Link Form submit
Easier to program, but ALL data saved and restored Possible performance and resource usage implications
Figure 48. Web Transaction System Structure Options: Using CONVERSE
The program design using CONVERSE is similar to traditional Main transaction programs in VisualAge Generator using maps. This design saves all of the program state at each CONVERSE. The UI Record data is saved in the session bean on the Web server. All of the data for the working storage and local records are stored on the VisualAge Generator server. Once the end user clicks a submit button on the Web page, all of the state data is restored and the program continues. The conversed UI Record programming approach has several options: One Web Transaction program can contain multiple CONVERSE statements. This might be useful for a data collection and feedback transaction where the data analysis between browser interactions is significant. Multiple Web Transaction programs can be directly linked using DXFR processing. This segments the long running transaction/interaction into smaller parts. This might allow for reuse of the separate parts.
77
One area of concern is when a program link from a conversed UI Record is used to start a new Web Transaction program. The data saved to support the converse is not automatically released. If processing does not return to the expected Web Transaction program flow, a system time-out would have to occur before the saved state is released. The program design using First UI Record with program name allows the developer some control of the state saved for the program (see Figure 49).
Using XFER pgm WS, UIrec

XFER WebTrans1 WebTrans2 XFER WebTrans3
XFER Pgm Link Form submit
WebTrans4
Developer decides what state to preserve (Controlled state) WS and UI saved and restored Less exposure on Program Link or Form Submit Best compromise between simplicity of implementation and resources/scalability implications
Figure 49. Web Transaction System Structure Options: Using XFER pgm WS, UIRec
Upon sending HTML to the Web browser, only the UI Record and working storage data are saved, and the transaction ends. Once the end user submits a request back to the Web server, a new transaction is initiated and the passed UI Record and working storage data is restored. Because the UI Record has been sent as part of the termination of WebTrans1, the use of a program link to start a new Web Transaction does not leave significant amounts of data saved and awaiting a time-out for cleanup processing. The program design using First UI Record with blank (Stateless) saves no state for the program. Upon sending HTML to the Web browser, the transaction ends. Once the end user submits a request back to the Web server, a new transaction is initiated (see Figure 50).
78
Using XFER ' ' , UIrec

XFER WebTrans1
Pgm Link Form submit
WebTrans4
Nothing is preserved (Stateless) Programmer has to manually save pertinent information using hidden fields in UI Record or database on runtime platform FORM support (user input processing) via Form UI Type Harder to implement but provides best performance/scalability
Figure 50. Web Transaction System Structure Options: Using XFER , UIRec
A stateless Web Transaction program is created by transferring control to a UI record with a blank program name. In reality, this is not transferring control to another program. It is performing a send page to the Web browser. The form in the Web browser page will cause the target transaction to start when the program link is selected. There are two ways to save state programmatically using this program design: 1. Save state data in hidden fields on the UI Record in the client browser. 2. Save state data in a database on the VisualAge Generator server. Developing programs that are stateless places more of a burden on the application programmer to develop programs that satisfy the business requirements. While this may be a more difficult task, it will result in an application design that both performs well and is scalable. The varied approaches to Web Transaction program design and UI Record display (CONVERSE or First UI Record) can be combined (see Figure 51).
79
Using combinations
XFER pgm2 pgm1 XFER pgm1 pgm2 Pgm Link Form submit CONVERSE pgm3 XFER pgm1 XFER ' ' , UI
Depending on expected think time and ease of state preservation on different dialogs of same system, a hybrid system may be adopted A combined structure approach could limit complexity with the selection of reduced overhead options only when required
Figure 51. Web Transaction System Structure Options: Using Combinations
The ability to combine the different approaches simply means that the complete business transaction can be analyzed, and the most effective choice in Web Transaction program structures chosen, as part of the implementation of a Web Transaction program-based system.
3.4.5 Generation and Implementation of a Web Transaction

VisualAge Generator allows for the generation of either the UI Record or the Web Transaction program with its associated UI Records (see Figure 52).
80
Web-Transaction
3GL Program
CONVERSed or XFERed UI Record
Java Bean (UI Record Data)
Java Bean (UI Record Interface) Java Resurce Bundle Message Table Edit Table Java Wrapper Edit Table File
Default JSP
Figure 52. Web Transaction: Generation
UI Record generation creates Java Beans and default Java Server Pages (JSPs). These materials can be used by Web-based user interface developers (who use HTML, XML, and so on) to access the data and render an appropriate screen. The Java Beans have methods that allow attribute access and a single action that puts all the inputs through the edits defined by the programmer. The Web Transaction program is generated using the current VisualAge Generator pseudo-conversational model for runtime execution. CICS pseudo-conversational problems of state, transaction control, program flow, and so on, are similar to Web problems. The generated program is independent of the user interface; any tool that can access a Java bean can create a user interface view using the data available in the Java Beans generated for the UI Record. The generated components are used in an appropriately configured WebSphere Application Server environment to implement a Web Transaction program runtime system (see Figure 53).
81
Web browser
Web server
VAGen session ID manager
VAGen server
Websphere Application Server

1
linkage table properties
VAGen gateway servlet

3 2 8
4 7
catcher program (DFHMIRS in CICS)

6 5
10
interface bean data bean
Session
Java Server Page
edit table
message table (resource bundle)
VAGen web transaction (will apply any VAGen server-side edit routines)
workdb
Figure 53. Web Transaction: Runtime Processing
The processing steps depicted in the runtime environment shown in Figure 53 are described below: 1. At runtime, a user triggers the Gateway Servlet through his browser. If it is the first time through: The user has the option of typing in a URL for the Gateway Servlet. This causes it to serve an HTML page/JSP, called the entry point page, which lists all the available Web Transactions. The session ID manager is invoked to assign a unique ID for the user and a session object is created for the user. This ID for the user is unique over multiple Web servers and VisualAge Generator server platforms. The ID is stored in the session object and may be obtained through EZEUSR. If the Gateway Servlet is configured to request users to logon, then just before the entry point is served, the user will be asked to authenticate themselves. The security information is then stored in IBM WebSphere Application Server in a session object for later use.
82
If this is not the first time through: The Gateway Servlet would be invoked from one of the following: A SUBMIT button or ANCHOR tag on the entry point page A SUBMIT button on an HTML FORM which was output from a previous CONVERSE or XFER with UI Record of a Web Transaction. If the entry point page is being used, so a new program is being invoked, the session ID manager is contacted to assign a unique ID for that conversation with the browser user. This ID is stored in the session object and can be obtained through EZELTERM. 2. If this is the first time through, we go straight to step 9, and the entry point page, and perhaps additionally the logon page, is served. Otherwise, if the Gateway Servlet was triggered from a SUBMIT button, on a JSP sent as the result of a previous CONVERSE or XFER with UI Record, it stores this user data in a data bean. The bean is associated with a session object for that user, so it can be referenced on later interactions with the user. 3. If the Gateway Servlet was triggered from a SUBMIT button, on a JSP sent as the result of a previous CONVERSE or XFER with UI Record, the interface bean is now used to apply to INPUT or INPUT/OUTPUT fields any: Standard supplied edits, such as numeric, input required and so on. Edit tables Web side edit routines. The message table is used to look up any message keys associated with a particular supplied edit for a given data item. If an error is found, we go straight to step 9. 4. We are now ready to invoke the VisualAge Generator Web Transaction. The Gateway Servlet synchronously invokes the catcher program on the target runtime environment. In a similar way to VisualAge Generator client/server systems, a linkage table is used to determine: What underlying protocol should be used to connect to the catcher program, for example, CICS ECI Data conversion Remote system identifier Transaction id, if using CICS or IMS and there is no current CONVERSE or XFER with UI record outstanding
83
CICS is a commonly used VisualAge Generator server platform. To connect to a CICS server in order to run a Web Transaction, you would use the CICS client. The Gateway Servlet connects to CICS client using the CICS Transaction Gateway. CICS client will connect to a CICS server and invoke the catcher program, otherwise known as the mirror program, DFHMIRS, by the external call interface (ECI) or the EXCI for MVS. 5. The catcher program invokes the requested Web Transaction. If the page on the browser had originally been sent as a result of the CONVERSE of a Web Transaction, or XFER with UI Record and some other VisualAge Generator record, this data is retrieved from the WORKDB. If the Web Transaction was invoked from an HTML FORM, and there were any VisualAge Generator server side edit routines associated with INTPUT or INPUT/OUTPUT fields in the UI Record, they are run at this time. If the VisualAge Generator runtime environment is CICS, the Web Transaction is invoked through a CICS LINK from DFHMIRS. 6. If server side edits failed, or the VisualAge Generator Web Transaction issues a CONVERSE or XFERs with a UI Record: The Web Transaction saves program storage, for CONVERSE, or saves the VisualAge Generator record (if any) specified on the XFER with UI Record statement, in the WORKDB. Control returns to the catcher program, passing back the UI Record data. In a CICS environment WORKDB will be a Temporary Storage Queue, in IMS, some form of database. The queue name is uniquely keyed on EZELTERM. 7. The logical unit of work ends, all task resources are released, and control returns to the Gateway Servlet. 8. The bean name to access and the data of the UI Record to be sent to the browser is returned to the Gateway Servlet. The Gateway Servlet stores the UI Record data in the users data bean using methods in the interface bean. The data bean and interface bean are put into the session object for later use. 9. The Gateway Servlet then uses the interface bean to determine the Java Server Page name and serves it. The process of serving this JSP will access attributes in the data bean using the interface bean. Reference to the interface bean is passed through in the HttpServletRequest object.
84
10.The JSP sends an HTML page to the browser that is filled out with data that was in the UI Record passed from the VisualAge Generator server when it executed its CONVERSE or XFER with UI Record. UI Record data items of UI type NONE will not be present in the HTML. This runtime process continues until the Web Transaction ends. At this point the Gateway Servlet knows it has ended and it serves a default entry point page.
3.4.6 Runtime Configuration Samples

Some of the available runtime configurations for a system based on Web Transaction programs are reviewed in this section. A three-tier approach using only Windows NT is shown in Figure 54.
Web Server
Apache IBM Websphere Application Server DB2 UDB CICS Transaction Gateway JDK IBM CICS Server
TCP/IP
Transaction Server
DB Server
DB2 UDB
CICS Universal Client
VisualAge Generator server for NT C++ Runtime Libraries

TCP/IP
VisualAge Generator Common services
C++ Runtime Libraries
DB2 Client Application Enabler
Figure 54. Runtime: Sample Configuration (Windows NT)
The configuration shown in Figure 54 uses three platforms: Web serverServes Web pages, runs JSPs and servlets, and provides the entry point to the rest of the system. Starts with a Web server (Apache) and the IBM WebSphere Application Server servlet/JSP runtime platform. VisualAge Generator Common Services is added to implement the Gateway Servlet, and provides support for making calls to target server platforms (where the Web
85
Transaction program will be running). CICS connectivity software is added to this platform to provide access to the target Transaction Server. Transaction serverCICS-based technology for running transactions on the Windows NT platform. After installation, the TX Series software is configured to support communications from CICS clients and runtime execution of generated VisualAge Generator programs. This includes support for DB2 access. Database serverDB2 engine for relational database support. A two-tier approach using Windows NT to front-end an OS/390 transaction server is shown in Figure 55.
Web Server
IBM HTTP Server IBM Websphere Application Server DB2 UDB CICS Transaction Gateway JDK
Transaction and DB Server

CICS TS for OS/390 or CICS/ESA VisualAge Generator server for MVS LE Runtime Libraries
LU 6.2
CICS Universal Client C++ Runtime Libraries
VisualAge Generator Common services
DB2 UDB for OS/390
Figure 55. Runtime: Sample Configuration (Windows NT / CICS TS)
The configuration shown in Figure 55 uses two platforms: Web serverServes Web pages, runs JSPs and servlets, provides the entry point to the rest of the system. Starts with a Web server (Apache) and the IBM WebSphere Application Server servlet/JSP runtime platform. VisualAge Generator Common Services is added to implement the Gateway Servlet, and provides support for making calls to target server platforms (where the Web Transaction program will be running). CICS connectivity software is added to this platform to provide access to the target Transaction Server.
86
Transaction and Database serverCICS-based technology for running transactions on the OS/390 platform and DB2 engine for relational database support. The workstation Web server is configured to access the host transaction and database server platforms. The host environment is configured to support communications from CICS clients and runtime execution of generated VisualAge Generator programs. A single tier approach using the OS/390 as a Web and Transaction Server is shown in Figure 56.
IBM HTTP Server
Web Server TX Server DB Server

JDK CICS TS for OS/390
IBM Websphere Application Server CICS Transaction Gateway
VisualAge Generator Server for MVS LE Runtime Libraries
OS/390
Figure 56. Runtime: Sample Configuration (OS/390)
DB2 UDB for OS/390
The configuration shown in Figure 56 uses one platform, the OS/390. On this platform: Web serverServes Web pages, runs JSPs and servlets, provides the entry point to the rest of the system. Transaction and Database serverCICS-based technology for running transactions on the OS/390 platform and DB2 engine for relational database support. This configuration is based on a Web server (IBM HTTP Server) and the IBM WebSphere Application Server servlet/JSP runtime platform. VisualAge Generator Server for MVS provides support for the Gateway Servlet and runtime execution of generated VisualAge Generator programs. The CICS Transaction Gateway connects the WebSphere Application Server and the CICS Transaction server for OS/390.
87
88
Part 2. Primer for Developer on Java Team Development
The following chapters, provided in Part 2, Primer for Developer on Java Team Development, were first published in VisualAge for Java Enterprise Version 2 Team Support, SG24-5245: Chapter 4, VisualAge for Java Team Development Environment Chapter 5, Understanding the Basics These chapters are included here to help you fully understand the VisualAge for Java team development environment. The following chapters were written to help you understand the implications of using Developer on Java in a VisualAge for Java team development environment: Chapter 6, A Developer on Java Team Environment Quick Start Chapter 7, Defining a Developer on Java Development Process
Note: Several additional chapters from VisualAge for Java Enterprise Version 2 Team Support, SG24-5245, are also included in this redbook as these appendices:
Appendix A, Workspace Management on page 259 Appendix B, The Team Development Process on page 269 Appendix C, Program Element State Transitions on page 283
89
90
Chapter 4.
VisualAge for Java Team Development Environment

This chapter provides an overview of the team development environment provided as part of VisualAge for Java. VisualAge Generator programmers use the basic functions of the VisualAge for Java development environment when using the Developer on Java development platform.
4.1 Introduction
The software development process is becoming more and more complex. End users are demanding that more function be delivered in less time. Many companies are extending their core business applications to enable new users to work in new ways through their intranet and the Internet, and new applications are required to run on many different platforms. All this often results in the need for large development teams to design, build, and maintain applications. Additionally, the teams are often forced to maintain or expand existing code in a very short time. Java programmers need development tools that enable them to work together in a highly dynamic environment. They require facilities that easily allow them to manage multiple versions of their work and switch quickly between the different versions. VisualAge for Java Enterprise provides an extremely flexible, productive, and secure built-in team environment for managing the software life cycle process.
4.2 Development Environment

At its simplest level, the architecture of the VisualAge for Java Enterprise team environment is a two-tier client/server model: multiple developer workstations connected to a single file server. Residing on the file server is a shared file, which stores all code for all developers of the development team. This file is called the repository. Each developer workstation has a set of executable files that are common to every client as well a unique file that contains a single developers working code set. This file is called the workspace.
91
The client connection to the server is established over a local area network (LAN), and communication between client workspaces and the repository server is through TCP/IP. Figure 57 shows the VisualAge for Java Enterprise team development environment.
Developer Workstations
A N
Local Workspace File
Shared Repository
Figure 57. VisualAge for Java Enterprise Team Development Environment
The repository is a large binary file that stores the source and bytecodes of all developer workspaces connected to it. It can be thought of as an object-oriented database that houses all development objects. The workspace file is unique to each client that is connected to the repository. It contains the bytecodes for the development environment and all program elements that the developer has loaded and is working with. A developer makes changes to code inside the workspace. These changes are always saved immediately into the repository. Starting VisualAge for Java causes the local workspace file to be loaded into memory and connected to the repository. A VisualAge for Java team client cannot run without a live connection to a repository.
92
Developers can add program elements, for example, classes or packages, from the repository into their workspace. Only loaded program elements are subject to change by a developer. Generally, many more program elements are stored in the repository than are loaded in a developers workspace. Developers can also delete program elements from their workspace. Deleted program elements still exist in the repository and can be added back into the workspace. The workspace file also defines the context of execution when applets and applications are tested during development. All classes and packages that are required to successfully run a program must be loaded into the workspace. Adding program elements from the repository is a way of easily sharing code among developers working with the same repository. In contrast to other file-based source code management systems, code changes are immediately available to other developers in the group. This does not mean that each developer is directly informed about any changes made by other users. A changed piece of code must be loaded into the workspace in order for it to be accessible. Therefore, each developer has full control over which program elements reside in the workspace.
4.3 Ownership
A powerful system of ownership supports the dynamic, concurrent VisualAge for Java team environment. Each program element must have an owner. Thus developers have the freedom and flexibility to make changes and try new things, and at the same time the integrity of each program element is ensured. The ownership model assigns distinct responsibilities to different team members, imposes discipline on the team during the development cycle, and facilitates tracking of changes at maintenance time.
Chapter 4. VisualAge for Java Team Development Environment
93
94
Chapter 5. Understanding the Basics

In this chapter we describe the concepts and terminology used in the team environment of VisualAge for Java Enterprise. We explain the four basic management services that VisualAge for Java Enterprise offers: managing system and program elements, version management, change management, and configuration management. Because VisualAge for Java Enterprise is based on an ownership model, team members assume specific roles at different times. We give details of these roles here and explain how they provide the basis for change control in the VisualAge for Java Enterprise team environment.
5.1 Program and System Elements

VisualAge for Java Enterprise distinguishes between program elements , which are managed by the developers, and system elements , which are managed by the administrator of the repository (Figure 58).
Program Elements
projects packages classes interfaces methods fields
Figure 58. Program and System Elements
System Elements
types
repositories users package groups
5.1.1 Program Elements

Program elements are the building blocks of an application and are managed by the developers. VisualAge for Java Enterprise handles projects, packages, classes (and interfaces), and methods.
5.1.1.1 Projects The project is the unit of organization within VisualAge for Java. Projects are used to group related packages in a way that is meaningful to the users of VisualAge for Java. A project has no analogy in the Java language.
95
5.1.1.2 Packages A VisualAge for Java package has exactly the same meaning in VisualAge as it has in the standard Java language. 5.1.1.3 Classes Classes and interfaces are the building blocks in VisualAge for Java just as they are in the Java language. The VisualAge for Java development environment sometimes refers to classes and interfaces with the generic term type. Although we might occasionally adopt the same convention in this book, we generally prefer to use the term class . Whenever we refer to a class, we implicitly refer to an interface as well. For example, if we talk about versioning a class, it is understood that the same operation can be applied to an interface. If this rule does not apply, we explicitly say so in the text. 5.1.1.4 Methods A method in VisualAge for Java is exactly the same as a method in the standard Java language.
For a complete description of program elements, see Programming with VisualAge for Java, SG24-5264.
5.1.1.5 Relationships between Program Elements When dealing with program elements in VisualAge, it is often helpful to consider the relationship between the various elements:
Inside the workspace there is a contained in relationship between program elements. Any given element is always contained in another program element at a higher level. A method is contained in a class, a class is contained in a package, and a package is contained in a project (see Figure 59).
96
Method
contained in
Class
contained in
Package
contained in
Project
Figure 59. Contained in Relationships between Program Elements
When packages and projects reside in the repository, a part of relationship can exist between them. The part of relationship is less restrictive than a contained in relationship. For example, a package can be part of several projects. However, it is not possible to have more than one project with the same package being loaded in the workspace at a time (see Figure 60).
97
A package can reside in a repository without being part of a project. For example, this is the case if you import a package that is not assigned to a project. When you load a package into the workspace, it must be assigned to a project.
Project X
Project Y
A B
C E
Package C is part of - Project X - Project Y - Project Z Package E is part of - Project Y - Project Z Package D is part of - Project Z Package F is not part of any project
Packages A and B are part of Project X
Project Z
Figure 60. Part of Relationship between Packages and Projects in the Repository
5.1.2 System Elements

System elements are used to support the team environment itself. They are maintained by the administrator of the repository.
5.1.2.1 Repositories A repository is a binary file where all parts of a software system are stored. It can be accessed by multiple users concurrently through a LAN. These users can reside on multiple platforms supported by VisualAge for Java Enterprise.
Each repository is managed by a special user object called the Administrator. This user preexists in every VisualAge for Java repository and cannot be deleted.
5.1.2.2 Users VisualAge for Java Enterprise maintains a list of authorized users for each repository. Only the administrator is allowed to create, change, and delete users from the repository.
98
A user is described by three attributes: Unique name The unique name is the users identifier. It must have a unique value. We suggest using the e-mail address to make sure it is a unique value in your team or company. Companywide unique names avoid problems when moving packages between different organizations, because user objects are also imported when you import a package from another repository. The unique name is case sensitive. Full name The full name is used by the system to refer to a particular user. Any list of users as well as the Properties window of a program element show the full name of a user. To avoid confusion, we recommend using unique values for the full names. Network login name The network login name is the user ID of the user and is used to identify the user to the repository. If you choose to enable password verification at logon, the network login name is the user ID against which the password is verified. For more information about passwords, refer to the product documentation. A network login name must be provided when you create a user. However, if you choose not to use password verification at logon, the network login name is not used.
5.1.2.3 Package Groups Each edition of a package has a package group associated with it. A package group contains a list of users who are allowed to create classes in this package. The user who created the package is by default the package group owner. The owner is the only one who is allowed to add or delete other users to or from the package group (see Change Management on page 106). The owner can also pass the ownership to another user.
A package that is undergoing split stream development can have different package groups assigned to each development stream. Each development stream is represented by a different edition of the package.
Note: The package owner is indicated in the middle lower pane of the Managing page of the workbench with a leading >. Be aware that this is the same symbol used for indicating unreleased editions!
99
5.2 Version Management

Program elements can exist in different states. Once a program element has reached a certain state that you want to save as a baseline, you can mark the state as immutable. To apply any changes to this piece of code, you first have to create a copy of it. This mechanism is commonly known as version control. VisualAge for Java Enterprise provides three constructs to manage changes to program elements (see Figure 61): Open edition Version Scratch edition All three constructs can be treated as editions. In other words, you can think of a version as an immutable edition. We refer to a program element that is currently loaded in the workspace as the current edition . A current edition can be either an open edition or a version. It can never be a scratch edition, because a scratch edition does not exist in the repository and therefore cannot be loaded from the repository. Open editions, versions, and scratch editions represent the status of a program element.
Edition
Open Edition
Version
Scratch Edition
released Open Edition
unreleased Open Edition
released Version
unreleased Version
Current Edition when loaded in workspace
Figure 61. Terms for Editions of Program Elements
100
5.2.1 Open Edition

An open edition is a program element that you can change. It is indicated by a time stamp containing the date and time of its creation. You cannot change this unique identifier. All open editions of program elements have a time stamp.
Tip Time stamps Time stamps of methods are not shown in the various standard browsers, but they can be seen in method properties. Time stamps of open editions are referred to as the Version Name in the Properties window.
You can have more than one open edition of a program element in the repository, but only one can be loaded in the workspace at any given time. Thus developers have the flexibility to work down several paths on the same program element. You can create an open edition either manually or automatically. Remember that a version is an immutable program element. You can explicitly create an open edition from a version. An open edition is automatically created by VisualAge for Java Enterprise if you make changes to an existing open edition of a method. When you save the changes, a new open edition of the method is automatically created. Creating an open edition from an existing version actually makes an editable copy of the program element. The version, which is not editable, remains in the repository.
5.2.2 Version
A version is an edition that you cannot change. It is indicated by a version name. VisualAge for Java provides automatic naming of versions, starting with 1.0 as the first version name of a new element and then adding one to the last number (1.1, 1.2). You do not have to accept this default name. Instead you can use your own, more specific name, that also can include letters. We suggest using specific prefixes in the version name so it is easy to determine which version was created by which developer and at what time.
101
Tip
Version name Version names should be used carefully. We recommend using <initial>-<date>-<version number> for a version name; for example, JS-6Mar-2.1.
A version is always created from an open edition. To version a project or package, all program elements at a lower level have to be versions. In the case of versioning packages, versioning of the contained classes may result in interaction with the different class owners, because only the class owner is allowed to release a class or interface. As a project owner you are allowed to version the containing packages individually or by versioning the project itself. Note that older versions still exist in the repository (see Figure 62).
Project
Open Edition
Version
Scratch Edition
Package
Open Edition
Version
Scratch Edition
Class/Interface
Open Edition
Version
Method
Open Edition
Figure 62. Versioning Program Elements
You can have more than one version of a program element in the repository, but only one is loaded in the workspace at a time. When you deploy an application, we strongly recommend that all program elements be versions.
102
5.2.3 Scratch Edition

A scratch edition is a private edition and not visible to other users. It resides in the users workspace, not in the repository. There are two situations where the construct of a scratch edition is helpful: You want to do some testing with a versioned package that you own. You have to make changes to a contained class that are not intended to be visible to other users. When you save the changes made in the class, a new open edition of the class is created as well as a scratch edition of the package. Because a scratch edition is a private edition, it is not seen in the repository. Therefore it will not fill the repository with unnecessary editions of the package that do not refer to any kind of baseline code. After testing you can reload the original version of the package. You have to make changes to a class within a package, but that package is owned by another user. Usually, the owner has to create a new open edition of the package before you can start making changes (which also means creating a new open edition of the class). If the owner of the package is not available to create a new open edition, you would not be able to continue your work. However, the concept of scratch editions enables you to work with your own private edition of the package (which is created automatically by VisualAge for Java Enterprise). You can have only one scratch edition of a package or a project in your workspace at a time. There are no scratch editions of a class. If you make changes to a version of a class, you always get an open edition. A scratch edition is indicated by displaying <> around the name of the original version.
5.2.4 History of Program Elements

VisualAge for Java Enterprise keeps track of all states of all program elements in the repository. They can be viewed by the Repository Explorer. A complete history of all program elements is available. VisualAge for Java Enterprise also provides a management query facility to search for different program elements in different states that are currently loaded in the workspace. You can add owner and/or class developer information as additional arguments for the query. For more information about the query facility, see Management query on page 262.
103
5.3 Configuration Management

Many different program elements are created during development, and most of them will exist in many different editions and versions in the repository. There are relationships among the program elements. For example, a certain version of a package contains several classes. Each class itself may exist in multiple editions or versions. A configuration management tool has to keep track of which version or open edition of each program element is contained in a particular version or open edition of the containing program element. The summary of these references is called a configuration. For example, you can think of a version of a package as a named, versioned configuration of class versions. VisualAge for Java Enterprise allows multiple configurations of the same element. Different configurations are maintained: Each version or open edition of a class represents a configuration of method editions. Each version or open edition of a package represents a configuration of class versions or open editions. Each version or open edition of a project represents a configuration of package versions or open editions.
5.3.1 Releasing Program Elements

A configuration represents the relationship between an open edition or version of a program element and the open editions or versions of the program elements that it contains when it is loaded in the workbench. To add a specific version or open edition of a program element to a configuration is referred to as releasing (see Figure 63). In other words, releasing determines which edition of a program element is loaded when a specific configuration is added to the workspace by a developer. Different rules exist for releasing different program elements. The terms of ownership used in the discussion that follows are described in detail in Ownership on page 106.
104
Project
Open Edition
Version
Scratch Edition
Package
Open Edition
Version
Scratch Edition
Class/Interface
Open Edition
Version
Method
Open Edition
Status of program elements that can be released
Figure 63. Releasing Program Elements
5.3.2 Releasing Methods

Each time a method is created or changed, a new edition is created and automatically released to the edition of the class. There is no explicit release mechanism for methods.
5.3.3 Releasing Classes

Only versions of a class or interface can be released. Classes are blocks of executable code in Java. When you work on a class or interface, it is an open edition, and it may not be in a state where it should be used by other developers. Once a class or interface is released to a package, it is used by all developers when they load the current configuration of the package into their workbench. To ensure that only classes with well-defined and tested behavior are loaded, only versions of a class can be released.
Important Info
Who can release a class? Only the class owner can release a class version into the containing package, whereas only the class developer can version the class.
105
5.3.4 Releasing Packages

A package can be released as an open edition or a version: Releasing an open edition of a package When you release an open edition of a package, it is not necessary to have all contained classes versioned and released. However, this does not mean that open editions of contained classes are going to be released. Instead, the most recent released version of the classes will be part of the resulting configuration of the package. For example, say you have an interface, MyInterfaceA, as an open edition currently loaded in the workbench and a released Version 5.0 in the repository. When the open edition of the package is released into the project, the configuration of the project contains not the current (open) edition of the interface but the released version in the repository. Releasing a version of a package Before you can version a package, all contained classes and interfaces have to be versioned and released. Then you can version the package and release it into a project. When you create a new package in a project, the initial open edition of the new package is automatically released to the project.
Important Info
Who can release a package? The package owner and the owner of the containing project are allowed to release an open edition or a version of a package into a project.
5.4 Change Management

Change management is implemented by VisualAge for Java Enterprise through the concept of ownership of program elements.
5.4.1 Ownership
Traditional change management tools are often based on a concept of reserving elements. A user reserves (or checks out) a program element to prevent other users from modifying it concurrently. In most of these systems any user is allowed to reserve elements. Element ownership as implemented in VisualAge for Java Enterprise is the basis for an alternative strategy that enables developers in a team to work
106
dynamically and concurrently but always have the appropriate control over the development process. For example, multiple developers may change a class more or less simultaneously and even create versions of it. However, there is only one individual, the class owner, who is responsible for the main stream of the development for that class. The class owner is the only one who can release the class version into the containing package. Therefore, although more than one developer is allowed to change a class, only the class owner determines which of the existing versions is visible to the other team members when they load the containing package. Owners are typically members who coordinate the work of many developers. Depending on the size and the complexity of the product, your team might have one project owner, and a package owner for each package. Each program element managed by VisualAge for Java Enterprise has an owner. The owner is responsible for integrity and maintenance during the whole life cycle of the program element. Certain operations are performed only by an owner.
5.4.1.1 Assigning Ownership Ownership can be assigned to a user explicitly or implicitly. A user gets implicit ownership of a program element when it is created. A user can get explicit ownership of projects, packages, and classes by having the ownership transferred from the current owner. The current owner relinquishes ownership on that program element. Therefore, although ownership is not immutable during the development process, only one person at a time is responsible for the class functionality.
Methods are implicitly owned by the owner of the containing class.

5.4.1.2 Scope of Ownership If you are the owner of a class, you are the owner of all existing editions of that class within the package edition (see also Class Owner on page 108). If you are the owner of a package or a project, you are the owner of only the current edition of the package or project. Thus different editions of packages and projects with different owners exist in the repository.
This different behavior is due to the fact that VisualAge for Java Enterprise treats classes as elements that have executable behavior. Therefore editions are single steps to achieve the desired functionality of a class, and only one user, the class owner, is responsible. In contrast, packages and projects are constructs used for organizational and administrative purposes. Different users can be responsible for different editions.
107
5.4.2 Team Roles

Change control is based on the different roles for the developers in a team: Class developer Class owner Package owner Project owner
Still another role is implemented in VisualAge for Java Enterprisethe role of administrator. We do not discuss this special role any further because the administrators tasks are not tightly related to the developers tasks within a typical development cycle. The administrator manages the repository as a whole, independently from certain development projects.
5.4.2.1 Class Developer A class developer is a user who has created an edition of a class or interface. Any user registered by the administrator to work with the repository can make changes to any class or interface. A class developer does not have to be the class owner. A class developer does not have to be in the package group to which the class belongs. Creating an open edition of a class automatically records the current user as the class developer. This behavior provides the flexibility that is necessary in a highly concurrent development environment.
How do I become a class developer? By creating an open edition of an existing class By creating a new class in a package in which you are a package group member. In this case you also become the owner of the class. What can I do as a class developer? Add the open edition to your workbench Version the open edition Change the class definition Change, save, delete, or reload a method
5.4.2.2 Class Owner A class owner is the team member responsible for the integrity of a class or interface in a package edition. Class ownership promotes the creation and maintenance of quality code for the following reasons:
Classes are not equivalent to modules in the traditional structured programming sense. Classes are building blocks for present and future
108
systems. To improve code quality and reuse, class ownership helps to ensure the reliability and generality of a class throughout the life cycle. The semantic dependencies of an object-oriented model (such as inheritance) increase the risk that a poorly considered change could have a unfortunate ripple effect. Only a class owner can change a class or interface and be reasonably expected to understand the ramifications of that change. The semantics of check-in/check-out are unclear when inheritance is used. If an abstract superclass is checked out, for example, should all of its concrete subclasses be reserved as well? Long-term class ownership introduces cultural changes in the software team. When developers know they will be maintaining a class for a significant period of time, they will be less likely to program short-term fixes. Class ownership provides the controls necessary for serious software development while offering the flexibility to let developers experiment quickly. The key is that only the class owner can release a class into its containing package. Other developers can create an open edition of a class, change the open edition, and even version the open edition. The class owner, however, determines the main stream of development of the class, through releasing the class. How do I become a class owner? By creating a new class or interface in a package edition in which you are a package group member (you also become the developer of the class). By explicit change of ownership: any member of the package group (including you) can set you as the owner of a class in the package.
Important Info
Who can change class ownership? The fact that any member of a package group can reassign ownership of a class is the sole exception to the concept that only the owner of an existing program element can change the ownership.
What can I do as a class owner? Release a version of the class Delete a class
109
The scope of class ownership is restricted to a single package edition. Therefore, if a package has multiple streams of development, the class might have a different owner in each stream.
5.4.2.3 Package Owner A package owner is responsible for the overall status of a package. The package owner also manages the package group and therefore coordinates the class developers working on that package.
How do I become a package owner? By creating a new package in a project you own By getting the ownership of an existing package transferred by the current owner of the package. You must be a member of the package group. What can I do as a package owner? Add new users to the package group of the package Delete users from the package group, as long as they do not own any class Transfer ownership to another member of the package group Create an open edition of the package Create a version of the package Release an open edition or a version of the package
5.4.2.4 Project Owner The project owner is responsible for the organization of the project. The project owner is the only one who can create packages in a project and maintain the integrity of the whole project.
How do I become a project owner? By creating a new project By getting the ownership of an existing project transferred by the current owner of the project What can I do as a project owner? Create an open edition of the project Create a version of the project Create packages in the project
110
Delete packages from the project, which means change the configuration of the project Transfer ownership of the project to any other user defined in the repository These team roles are dynamic in VisualAge for Java Enterprise. Your role may change many times during development without you being aware of it. For example, if you are a package owner and you create a class in that package, you act as a package owner. When editing and versioning the class, you act as a class developer. When releasing the versioned class to the package, you are doing that as the class owner. You do not notice all of these role changes except when you are about to perform a task that requires privileges from another team role that is not assigned to you. From the descriptions of the roles, we can deduce that there are two roles that any developer can automatically assume without regard for any controls on the repository. They are class developer and project owner. Therefore, you are always allowed to start your own development project and you are always allowed to work with all released program elements in the repository. However, you are not allowed to make any changes to a package and its containing classes if you are not a member of the package group.
Attention!
Can any user delete any project? We know that deleting from a workspace is the equivalent of an unload operation and does not delete from the repository. At this point you may be thinking that deleting projects and deleting packages are similar operations. They are not. Deleting a project from your workspace does not change any configuration. However, unloading a package from your workspace changes the configuration of the project of which that package is a part. Therefore any developer can delete any project from his or her workspace, but only the owner of a package or the owner of the containing project can delete a package.
111
112
Chapter 6. A Developer on Java Team Environment Quick Start

This chapter reviews some key points about how VisualAge Generator development works in the VisualAge for Java team environment. It identifies some of the team environment behaviors that must be understood from a VisualAge Generator part development and management perspective.
Note: This information is intended for those who have been using the 3.x version of VisualAge Generator and are comfortable with the structure and processing implemented on the Developer on Smalltalk platform.
Once these differences are understood, an organizational approach and project/package architecture that can support the VisualAge Generator development process can be defined (see Chapter 7, Defining a Developer on Java Development Process on page 125).
6.1 Functional Organization

If you have been using the Developer on Smalltalk platform, the first change you will notice when you start working with the Developer on Java platform is the look and feel of the VisualAge for Java Workbench (see Figure 64).
Figure 64. VisualAge for Java Workbench
113
The function provided by the VisualAge for Java Workbench is similar to that provided by the VisualAge for Smalltalk Organizer, except that invocation of VisualAge Generator part editors and processing options are not supported against the methods used to store the VisualAge Generator parts. All VisualAge Generator tasks must be performed from the VAGen Parts Browser (see Figure 65).
Figure 65. Developer on Java VAGen Part Browser
The main difference between the VisualAge for Java and VisualAge for Smalltalk is how the classes are managed in the development environment: VisualAge for Java has fewer container types than VisualAge for Smalltalk. Unlike the configuration map to image relationship used by VisualAge for Smalltalk, all containers are physically loaded in the VisualAge for Java workspace. (A configuration map is a list of pointers, but the list itself is not loaded). Duplicates are not permitted in the list of packages that exist for a set of loaded projects. Duplicates are permitted in the list of classes that exist for a set of loaded packages.
114
The container types for both the Developer on Smalltalk and Developer on Java platforms are shown in Figure 66.
Smalltalk Team Environment Containers:

Configuration Maps Applications Subapplications
Java Team Environment Containers:

Projects Packages
Configuration Map 1 Configuration Map 2 Application A VGenXXX Class

VAGen Parts
Project 1 Package A Classes

Methods
VGenXXX Class
VAGen Parts
Subapplication A VGenXXX Class

VAGen Parts
Subapplication B Classes
Methods
Package B VGenXXX VGenXXXClass Class

(VA Generator Parts) VAGen Parts
Application B VGenXXX Class

VAGen Parts
Project 2 Package C VGenXXX Class

VAGen Parts
Figure 66. VisualAge for Smalltalk and VisualAge for Java Team Environment Containers
6.2 Class Management (Application Becomes Package)

Java packages are similar to applications in the Developer on Smalltalk version. The main differences are: You cannot add prerequisites to a package. Packages cannot be substructured; there are no subpackages. In the previous version of VisualAge for Smalltalk, Subapplications were used to substructure source code into logical units. In VisualAge for Java, packages cannot be substructured (see Figure 67).
115
App SubSysA
Subapplication GUIS Subapplication Records
App Shared Code
Pkg SubSysA
Pkg Shared Code
Pkg Records
Pkg GUIs
Applications can use Subapplications to create layers.
Packages do not support layering.
Figure 67. Comparing Application and Package Structure Options
While the number of containers required is the same, it will seem like more packages are required to provide the same organizational granularity found in a Developer on Smalltalk based system. The use of Subapplications allows for a folder in a folder. There are also differences in the way classes are managed and the uniqueness rules followed for method names in the Developer on Smalltalk and Developer on Java platforms (see Figure 68).
Applications store VAGen parts in extended Classes

Application Records Application Shared Code
VAGen Functions
FUNCB()
Packages store VAGen parts in Classes

Pkg Records Pkg Shared Code
VAGen Records VAGen Functions

FUNCA()
VAGen Records VAGen Functions

FUNCA()
VAGen Functions
FUNCA()
Smalltalk Image processesing ensures that method names are unique across extended Classes.
Duplicate Classes across different Packages are suported in Java. Method names do not need to be unique, but duplicate parts in Workspace are not supported by Developer on Java.
Figure 68. Content Rules for Applications and Packages
116
While the Developer on Java platform cannot prevent the existence of duplicate names for VisualAge Generator parts in a workspace, when this situation is identified (such as at the start of testing or generation), warning messages are issued. The class owner and class developer roles exist for in both VisualAge for Smalltalk and VisualAge for Java. Groups are defined for packages as they were for applications. The major difference is that customization of the authority level required to create new editions of classes stored in a package is not supported. In VisualAge for Smalltalk, the right to create a new edition of a class in an application could be restricted to: World (default) Group member Class owner In VisualAge for Java, this level of authority customization is not supported. Any user in the VisualAge for Java environment has the right to create a new edition (and version that edition) of a class in a package.
Note: The following rules are consistent:
Only the class owner can release a version into the package. Only the package owner can version or make a new edition of a package. This static authority rule can limit the VisualAge for Javas ability to enforce a single threaded development process for the contents of a package. In a VisualAge for Smalltalk environment you could modify the privileges on an application so that only the class owner could make a new edition. This change would force a single threaded development process. Similar results in a Developer on Java environment will require better control of the process of releasing class versions into the package.
6.3 Container Management (Configuration Map Becomes Project)

Projects are similar to configuration maps, in that they identify a specific version of one or more packages. The main differences between the two are: The version (or open edition) of a project is loaded into the workspace. Prerequisites (required maps) cannot be defined for a project. Configuration maps contain pointers to an application. The target applications are loaded; the configuration map does not act as a container (see Figure 69).
117
2 Load
1 Load
3 Load
Config Map A
Config Map B
Config Map C
Application Q
Application R
Application S
Application T
Application U
Image
All Config Maps can be loaded. Only the Applications they reference are added to the image. The image contains the union of the referenced Applications.
Figure 69. Using Configuration Maps to Manage Applications
Like configuration maps, different projects can point to the same package, but projects that point at the same package (even if different editions) cannot be added (loaded) in your workspace at the same time (see Figure 70).
2 Load Fails
1 Load
3 Load Fails
Project A
Project B
Project C
Package Q Package R Package S Package T
Package U
Workspace
Only Projects with a unique set of Packages can be loaded at the same time. Either Projects A and C, or only Project B, can be loaded at one time. The workspace can contain only one instance of a Package.
Figure 70. Using Projects to Manage Packages
118
With configuration maps, you could have redundant pointers to an application or another configuration map that contained common code. This might have been done to make the process of loading a working set of code into the image easier to perform. This technique is not possible with projects. You will have to discreetly load each project to establish the working set of code required. Developer on Java enhancements will allow for alternate techniques which can be used to establish relationships between different projects (see 6.5, Organizational Alternatives on page 121). The project owner and package owner roles exist in VisualAge for Java. These equate to the configuration map Manager and application Manager roles in VisualAge for Smalltalk. The major difference is that customization of the authority level required to release or deleteeditions or versionsof packages in a project is not supported: In VisualAge for Smalltalk, the right to release or delete editions or versions of applications in a configuration map could be granted to the application Manager. In VisualAge for Java this is the default, either the project owner or package owner can release packages into or delete packages from a project.
Note: Only the project owner can version or make a new edition of a project, or add a package to a project, which is consistent with the VisualAge for Smalltalk behavior for configuration maps.
This inability to delegate project content responsibility to package owners, and the rule that only versions can be released, may require a change in the development process used when working with Developer on Java (see 7.3, Defining Project and Package Structures to Organize Code on page 130).
6.4 System Structure Definition

Based on the differences that exist between projects and configuration maps, we can now see that there are differences in the structural layers that can be defined using VisualAge for Java and VisualAge for Smalltalk. An example of a configuration map and application structure that is possible when using the Developer on Smalltalk platform is shown in Figure 71.
119
Config Map Config Map
Application
Config Map Config Map Config Map Application Application

Subapplication Subapplication
Application
Application
Application
Figure 71. Developer on Smalltalk Container Structure Example
Figure 71 shows that a layered network structure is possible in the VisualAge for Smalltalk environment: Configuration maps can reference other configuration maps. Different configuration maps can reference the same application. Applications can have subapplications. An example of a project and package structure that is possible when using the Developer on Java platform is shown in Figure 72.
120
Proj Sub Sys A
...
Pkg Pgm 3 Pkg Pgm A
Proj Sub Sys B
...
Pkg Pgm C
Pkg Pgm 1
Pkg Pgm 2
Pkg Pgm B
Proj Common Parts
Pkg Records
Pkg Control Files
Pkg Shared Code
Figure 72. Developer on Java Container Structure Example
Figure 72 shows that a only a flat structure is possible in the VisualAge for Java environment: Projects contain packages. The set of packages contained in a set of projects loaded in the workspace must be unique. Packages must be in a project to be loaded. Different projects can reference the same package, but they cannot be in the workspace together.
6.5 Organizational Alternatives

The lack of support for multiple layers and a network relationship requires that the organizational structure used with the Developer on Smalltalk platform change before code can be organized using the Developer on Java environment. A solution to this problem is to create packages with a naming scheme that identifies organizational decisions and relationships.
121
Figure 73 shows a sample team environment container structure for a system implemented using either the Developer on Smalltalk or Developer on Java development platform. The approach shown in Figure 73 uses configuration maps, applications, and subapplications in the Developer on Smalltalk platform.
Sample Smalltalk Structure

SYSMySystemCMap
SYSCommonApp SYSCommonClientSubApp SYSCommonClientErrorRoutineSubApp SYSCommonClientDateSubApp SYSCommonServerSubApp SYSCommonServerErrorRoutineSubApp SYSCustomerApp SYSCustomerClientSubApp SYSCustomerDetailClientSubApp SYSCustomerListClientSubApp SYSCustomerServerSubApp SYSCustomerDetailServerSubApp SYSCustomerListServerSubApp ...
Sample Java Structure

Company System Common (project)
co.sys.common.client co.sys.common.client.errorroutine co.sys.common.client.date co.sys.common.server co.sys.common.server.errorroutine
Company System Customer (project)

co.sys.customer.client co.sys.customer.client.detail co.sys.customer.client.list co.sys.customer.server co.sys.customer.server.detail co.sys.customer.server.list ...
Figure 73. Sample Developer on Java Container Structure derived from Subapplications
In the example shown in Figure 73, top-level applications were replaced by projects, and Subapplications by packages. The VisualAge for Java container structure shown would allow for an easy migration of VisualAge Generator 3.x parts to the Developer on Java repository.
Note: VisualAge for Smalltalk classes (such as GUIs) cannot be migrated to VisualAge for Java.
Figure 74 shows a sample team environment container structure for a system where only configuration maps and applications are used in the Developer on Smalltalk platform.
122
Sample Smalltalk Structure

SYSMySystemCMap SYSMySystemCommonCMap
SYSCommonClientApp SYSCommonClientErrorRoutineApp SYSCommonClientDateApp ... SYSCommonServerApp SYSCommonServerErrorRoutineApp
Sample Java Structure

Company System Common (project)
co.sys.common.client co.sys.common.client.errorroutine co.sys.common.client.date ... co.sys.common.server co.sys.common.server.errorroutine
SYSMySystemCustomerCMap
SYSCustomerClientApp SYSCustomerDetailClientApp SYSCustomerListClientApp
Company System Customer (project)

co.sys.customer.client co.sys.customer.client.detail co.sys.customer.client.list co.sys.customer.server co.sys.customer.server.detail co.sys.customer.server.list ...
SYSMySystemCMap
SYSCustomerServerApp SYSCustomerDetailServerApp SYSCustomerListServerApp ...
Figure 74. Sample Developer on Java Container Structure Derived from Applications
In the example shown in Figure 74, the first level of configuration maps were replaced by projects, and applications by packages. The VisualAge for Java container structure shown would also allow for an easy migration of VisualAge Generator 3.x parts to the Developer on Java repository. If both layers of configuration maps and Subapplications are used, you will need to consider either the use of additional projects or a naming pattern for packages that provides for a form of logical organization.
6.6 Using Project List Parts to Implement a Layered Project Structure

The use of layered of configuration maps is the one major organizational technique used in a Developer on Smalltalk environment that cannot be represented by VisualAge for Java. This limitation impacts the management of complex systems and makes loading all required code into the workspace a tedious task. Automating the loading of multiple related projects, to support LAN-based generation, was defined as a Developer on Java requirement.
123
A solution to this problem is provided by extensions to Developer on Java generation option processing. To support project relationship definition (layering), the following approach will be used: The VisualAge for Java concept of a default package for a project. A specifically named options part, a project list part (PLP), recognized by Developer on Java, that can be found in the default package. To enable LAN-based generation, and assist in loading related projects in a workspace, Developer on Java processing will search for a PLP in the first project identified on the project load request. If found, the target projects will be loaded (with recursive PLP search and load logic applied at each level). Key points regarding these new generation options: A specifically named PLP must exist in the default package. If different versions of a project are identified, the last one processed will be loaded. PLP processing logic does not force the most recent version. This flexiblity allows for the creation of layered structures of related projects (see Figure 75).
System Project
VAGEN_SYSTEM_PROJECT.PLP
/Project=Sub Sys A, V1.0 /Project=Sub Sys B, V1.4 /Project=Common Parts, V2.6
Default Pkg
Java GUI Gen Pkg
DevProj Sub Sys A
DevProj Sub Sys B
Proj Common Parts
Pkg Pgm 1
Pkg Pgm 2
Pkg Pgm 3
Pkg Pgm A
Pkg Pgm B
Pkg Pgm C
Pkg Records
Pkg Cntl Files
Pkg Shared
Figure 75. Using Project List Part Processing to Emulate a Layered Set of Projects
The function provided by these generation processing extensions can also be used to help define and control a Developer on Java-based development process (see 7.4.3, Managing Development Phases Using Project List Parts on page 137).
124
Chapter 7. Defining a Developer on Java Development Process

The previous chapters provided you with a working knowledge of how the team environment functions in a VisualAge for Java environment: Image and repository concepts Team environment components: projects, packages, classes, and methods Version, edition, and release processing as applied to the components Development roles: class developer, class owner, and package owner Once you understand these key ideas, you are ready to begin the real task: defining a development process that optimizes the use of the Developer on Java development platform. (This process will be different than one defined for pure Java development.) This chapter reviews some key points about how VisualAge Generator development works in the Developer on Java environment. It suggests an organizational approach and team environment project and package architecture that can efficiently support the VisualAge Generator development process. Later, in Chapter 8, Scenario: Designing the Development Process on page 145, an active development scenario is described to demonstrate and reinforce these concepts.
7.1 Choosing a VisualAge Generator Solution

Before we start, here are some of the key features to remember about how VisualAge Generator has been implemented in the VisualAge for Java development environment: VisualAge Generator is a feature that you can add to the base VisualAge for Java development environment. The feature contains all of the code to support development, testing and generation of VisualAge Generator systems. VisualAge Generator parts are stored as methods in classes. A class is created for each VisualAge Generator part type in each of the packages where VisualAge Generator 4GL parts are stored. The process of creating new 4GL parts creates a new edition of the VisualAge Generator part class in the package selected to store the part.
125
Given the way VisualAge Generator has been implemented in the VisualAge for Java environment, we offer the following thoughts: There is no locking of parts in the team environment; that is, there is no formal support for serial development. By design, the team environment supports concurrent development. Without serial development, enforced by user password validation, different developers can make updates to parts of the same type that are stored in the same package. This would create multiple open editions or versions of the VisualAge Generator part class in the package. Merging is the only way to resolve these multiple class versions. Knowing this, many aspects of VisualAge Generator development tend to suggest that a serial development approach is often the preferred approach.
Initial Recommendations:
Our study of how to use the team environment for VisualAge Generator development in VisualAge for Java is not complete, but here are some recommendations that should help you to avoid the need for merging, and promote an effective development environment: Accept that the approach you will use for VisualAge Generator will differ from the one that might be used in a standard VisualAge for Java development environment. The granularity of your package container structure must be such that specific development tasks on a set of related VisualAge Generator parts fall within the scope of a single programmer (or will do so, say, 95% of the time). Support for efficient version and release management should be incorporated into the organizational approach used to support VisualAge Generator development. That is, programmers should be able to issue simple requests, such as creating new project/package editions and versioning changes when they are done with a task. Confirm that the organizational approach selected will support your development process and techniques before you migrate a system or start a new project in the Developer on Java environment. Do not begin to define the project and package container structure until the team roles have been agreed on.
126
7.2 Available Solutions

Following these recommendations, you may notice that one of the main issues that you wish to avoid when designing your development process is merging. When different programmers modify the same VisualAge Generator part type in the same package, the two changes collide, and the VisualAge Generator Part class cannot be released until these changes are reconciled/merged to produce a new edition of the class. If such a situation is allowed to happen, it can be extremely difficult to resolve. How likely is this in practice? To illustrate this, let us consider a system where we have 100 VisualAge Generator Programs: Each program has an average of: 40 functions 3 records For a total of: 4000 functions 300 records The project team has 5 programmers.
7.2.1 Traditional Development Environment

In a traditional source library environment, the likelihood of a collision is calculated using the ratio of programmers to source library members (see Figure 76).
Lu cy
Joe
Bob
Ja ne
Bil l
Figure 76. Traditional Development
127
In our example, the probability for collisions would be one chance in: 20 programs 800 processes 60 records These represent acceptable to negligible chances.
7.2.2 One Package per Project

In a Developer on Java environment, the likelihood of a collision is calculated using the ratio of programmers to VisualAge Generator part classes. If there is only one package for a system, then there would be only a single VisualAge Generator part class for all programs, records, function, and so on (see Figure 77).
Lu cy
J oe Bob
Jan e
B ill
Figure 77. Developer on Java Development with One Package for the Project
In this case, there would be a collision for every VisualAge Generator part, because all the parts of the same type are stored in the same class.
7.2.3 One Package per Programmer

It becomes clear that the way to reduce collisions is to increase the number of VisualAge Generator Part class instances. This can be done by increasing the number of packages. How many packages is enough? The answer does not lie in some rule-of-thumb ratio but is derived by considering the scope of development work. What scope would reduce the chances of a collision to acceptable/negligible amounts?
128
If only one programmer at a time was actively modifying the classes in a package, then there would be no collisions: he or she cannot collide with himself or herself (see Figure 78).
Joe
Bob
Jane
Bill
Lucy
Joe Bob
Ja ne
B il
R ic k l
cy Lu
Figure 78. Developer on Java Development with One Package per Programmer
In this scenario, each programmer has his own package which contains all of the parts he or she is responsible for. This works fine if the team setup or responsibilities do not change. However, if they do (Rick replaces Lucy), extensive changes to the team environment container structure would be required.
7.2.4 The Package-to-Function Relationship Answer

The previous solutions were explained to show what you should consider when designing your Developer on Java based source code management solution: Minimize the number of potential collisions by separating your components in multiple containers Do not design your container structure based on changing factors such as code ownership (this can, and probably will, change) Given this, a sensible approach would be to store each system component, like VisualAge Generator programs and applets, and their tightly coupled associates (non-reusable code), in a separate package (see Figure 79). This way, if the responsibility for a component is reassigned, the only change required is the assignment of a new package owner.
129
Lu cy
Joe Bob
Jan e
Bill
Figure 79. Developer on Java Development with One Package per System Function
This will allow the team environment structure to remain stable while programmer responsibilities change over time.
7.3 Defining Project and Package Structures to Organize Code

Once you have chosen the approach you wish to use, you are ready to define how projects and packages will be used to organize the source for the system. Remember that the team environment was designed to support an object-oriented development process. This is why it is easier to design your container structure based on objects (one per system function).
7.3.1 Project to Package Ratios

As reviewed in 6.3, Container Management (Configuration Map Becomes Project) on page 117: Projects must contain discrete sets of packages to allow for loading of the complete system. Due to the system requirement that only allows the project owner to modify the list of packages contained in the project, the number of packages per project will be reduced. Figure 80 shows an example of a system defined in the Developer on Java environment.
130
Proj Sub Sys A
...
Pkg Pgm 3 Pkg Pgm A
Proj Sub Sys B
...
Pkg Pgm C
Pkg Pgm 1
Pkg Pgm 2
Pkg Pgm B
Proj Common Parts
Pkg Records
Pkg Control Files
Pkg Shared Code
Figure 80. System Defined Using Multiple Projects
A similar system implemented in the Developer on Smalltalk environment might have had the same application in multiple configuration maps and more applications per configuration map (as compared with packages per project).
7.3.2 Package Contents

When you analyze the code that composes a system, you may notice that this code falls into two categories: non-shared code and shared code. Shared code can be further divided into two categories: Intra-system shared code code shared in a single system function/object such as a customer detail record. Inter-system shared codecode shared across systems, such as an error routine.
7.3.2.1 Non-Shared Source Code Most of the code in your system is not reused by other components. In your team environment container structure, these parts should be grouped by system function.
If there are too many parts in the function, or if the maintenance of the parts could become the responsibility of more than one person, you may wish to
131
further refine the part organization by creating additional packages using a defined naming scheme.
7.3.2.2 Shared Code (Intra-System) Some parts are only shared only by components belonging to the same system function/object. For example, you may have a TUI program and a VisualAge for Java application both using the same customer detail record. If the TUI and the application are stored in different packages, where should you put the shared record?
A good solution to this problem would be to put the record in a package that contains the shared parts for the customer system function/object. Other parts, like generation options, linkage tables, and resource associations are also used throughout the system. They should also be stored in their distinct package.
7.3.2.3 Shared Code (Inter-System) Parts that are shared across multiple systems are generally the responsibility of a specific group of people; system-specific developers are not allowed to change these parts. Because of this, these components should be stored in distinct packages owned by the leader of the group responsible for their maintenance.
Data definition parts are an example of parts that are shared across a system. In most projects, a member of the team is responsible for maintaining the database and its corresponding VisualAge Generator definitions: the database administrator (DBA). As with any other shared parts, they should be stored in a separate package.
7.3.3 Package-to-Function Container Breakdown Example

Packages could also be grouped by system functionality. Each system function would be identified using a significative package naming scheme. An example of a valid naming scheme could be: co.sys.function.program , where: co is the company name, sys is the system name, function is the system function to which the program belongs to, and program is the name of the system component (GUI, TUI). Figure 81 shows an example of a Developer on Java project and package breakdown for a system that contains VisualAge for Java applications and TUI programs.
132
Banking System Common Definitions

co.banking.common.databasedefinitions co.banking.common.options co.banking.common.programs
Banking System Customer

co.banking.customer.guis.common co.banking.customer.guis.detail co.banking.customer.guis.list co.banking.customer.servers.common co.banking.customer.servers.detail co.banking.customer.servers.list co.banking.customer.tuis co.banking.customer.tuis.detail
...
Figure 81. Sample Team Environment Container Breakdown
Notice how common components are stored in distinct packages. Common components used throughout the system are stored in packages grouped under the Banking System Common Definitions project. Each of the systems major functions (business objects or layers) has its own project which contains its source code. Again, common components are
133
stored in separate packages. Table 4 lists the contents of each of these packages.
Table 4. Sample Team Environment Container Breakdown Package Content
Package Name
co.banking.common.databasedefinitions co.banking.common.options co.banking.common.programs co.banking.customer.guis.common co.banking.customer.guis.detail co.banking.customer.guis.list co.banking.customer.servers.common co.banking.customer.servers.detail co.banking.customer.servers.list co.banking.customer.tuis co.banking.customer.tuis.detail
Content
Contains the SQL row table definitions and their corresponding data items Contains the generation options, linkage tables and resource associations Contains the code shared between all the systems programs (TUIs and servers) Contains the shared code of the customer Java applications Contains the code for the customer detail Java application Contains the code for the customer list Java application Contains the shared code of the customer data servers Contains the code for the customer detail data server Contains the code for the customer list server Contains the shared code of the customer TUI programs Contains the code for the customer detail TUI program
This is a valid solution if assignment of ownership is based on system functions (one group responsible for all the components of a single function). On the other hand, if responsibility is based on component type instead of functions (one group responsible for all data servers), then the following package naming scheme could be used: co.sys.program.function, where: co is the company name, sys is the system name, program is the name of the system component (GUI, TUI).
134
7.4 Representing Stages of Development

The next issue to be addressed is how to manage the packages in projects.
7.4.1 Project Sets for Each Development Phase

You could use one set of projects to both organize and contain the packages used in a non-trivial system, and manage the development process, but life would become difficult. Identifying which version of each project represented the current development, test, or production base line, and managing the package-to-project relationships along these same lines, can quickly become a very complex and error-prone task. A simpler approach is to use multiple sets of projects, one set for each phase in the development life cycle (see Figure 82).
PrdProj Sub Sys A
TstProj Sub Sys A
Pkg Pgm 1 V2.1
Pkg Pgm 2 V1.0
Pkg Pgm 3 V1.1
DevProj Sub Sys A
Pkg Pgm 1 V2.1
Pkg Pgm 2 V2.0
Pkg Pgm 3 V2.2
Pkg Pgm 1 V2.1
Pkg Pgm 2 V2.0
Pkg Pgm 3 V3.3
Figure 82. Implementation of Project Sets to Represent Phases of Development
This approach would also allow a programmer to define a project that loaded just the code they were interested in working with, to make loading the full set of code that they require an easier task to perform.
135
7.4.2 Moving Code between Development Phase Projects

The appropriate package versions are released into each project set as appropriate for the phase of development represented by the project set. The act of promoting packages between projects represents a basic development process management task. The act of releasing (promoting) a package from test to production is shown in Figure 83.
Promote to Prod Open Edition
PrdProj Sub Sys A
TstProj Sub Sys A
Pkg Pgm 1 V2.1
Pkg Pgm 2 V1.0
Pkg Pgm 3 V2.2
DevProj Sub Sys A
Pkg Pgm 1 V2.1
Pkg Pgm 2 V2.0
Pkg Pgm 3 V2.2
Release Pkg Pgm 3 V2.2 into PrdProj Sub Sys A
Pkg Pgm 1 V2.1
Pkg Pgm 2 V2.0
Pkg Pgm 3 V3.3
Figure 83. Promoting a Package from Test to Production
The target project, for the package that needs to be promoted, must be an open edition. The release action must be performed by the target project owner. The overall process is a pull of code to the next level. Figure 84 shows the act of promoting a package from development to test.
136
PrdProj Sub Sys A
Promote to Test Open Edition
TstProj Sub Sys A
Pkg Pgm 1 V2.1
Pkg Pgm 2 V1.0
Pkg Pgm 3 V2.2
DevProj Sub Sys A
Pkg Pgm 1 V2.1
Pkg Pgm 2 V2.0
Pkg Pgm 3 V3.3
Pkg Pgm 1 V2.1
Pkg Pgm 2 V2.0
Pkg Pgm 3 V3.3
Release Pkg Pgm 3 V3.3 into TstProj Sub Sys A
Figure 84. Promoting a Package from Test to Production
7.4.3 Managing Development Phases Using Project List Parts

While VisualAge for Java does not support relationships between projects, the use of the VisualAge Generator PLP (see 6.6, Using Project List Parts to Implement a Layered Project Structure on page 123) will allow for management of cross-project relationships as part of the development process. This means an approach to the use of PLPs to define project layers, and the implication to the development process (when PLPs will be updated) is required. Figure 85 shows how PLPs can be used to control the projects referenced in a specific development phase, without the use of complete redundant project sets (one for each phase).
137
Prod System Project

Proj Sub Sys A
...
Proj Common Parts
Default package
Proj Sub Sys B
...
Test System Project

Proj Sub Sys A
...
Proj Common Parts
Default package
Proj Sub Sys B
...
Devl System Project

Proj Sub Sys A
...
Proj Common Parts
Proj Sub Sys B
...
Default package
Figure 85. Using PLPs to Define Sets of Projects Used by Development Phase
In Figure 85, the only redundant projects are the phase projects, the first level in the project hierarchy supported by a PLP. A project hierarchy with additional levels can also be defined using PLPs in more than one project layer. This technique, while a bit more complex, may be required to provide the organization and control support required for your system.
7.4.4 Moving Code between Development Phase Project List Parts

The process of moving code between development phases (promoting projects) is very straightforward when using PLPs to define the projects that are to be included in a phase project. When the code changes contained in the V2.57 version of project SubSys A are ready to be included in the phase project Test System, then the PLP for the target phase project is updated to specifically identify that version (see Figure 86).
138
Test System Project

Proj Sub Sys A
...
Proj Common Parts
Default package
Proj Sub Sys B
...
Devl System Project

Proj Sub Sys A
...
Proj Common Parts
Proj Sub Sys B
...
Default package
Figure 86. Promoting a Project from Test to Production Using PLPs
The package used to store the PLP for the target phase project, and the project itself should be open editions to prepare for commitment of this change (promotion of code between development phases). 7.5, Package Management for Java Client Generation on page 140 reviews other development process considerations when using a PLP-based phase project management approach.
7.4.5 Summary
There are several choices for development phase management: Redundant project sets for each phase of development (see Figure 82). Redundant PLPs (with an owning project) for each phase of development (see Figure 85). Combinations of the above techniques. The technique you choose should reflect how you want to manage and control the development process. Note that you will need to use PLPs to support the use of LANGEN-based generation and preparation processing, so you may find it easier to manage the development phases using either a mix of the available techniques or only through the use of multiple PLP-based structures (phase projects).
139
7.5 Package Management for Java Client Generation

When 4GL parts are used in a Java component, Java client generation must be performed prior to exporting Java class files that will be used for a runtime system (see Figure 87). Java client generation creates Java source to implement the processing required for the 4GL parts related to the Java component.
Define - Test
Java
Components
Pkg Pgm 1
Proj Sub-Sys A
Workspace
Generate
Pkg Pgm 2
VAGen Programs
Pkg Pgm 3
VAGen Functions
Export Classes or JAR
Combined to Implement Executable Client
VisualAge Generator Java Client Runtime Support JVM & pre-reqs
Figure 87. Java Client Generation Overview
7.5.1 Source Package as Java Client Generation Target Package

When Java client generation is invoked, the /PackageName generation option identifies the Java package that will be used to store the VGxxx classes that are created for the 4GL parts. Figure 85 shows a scenario where the /PackageName generation option identifies the same package used to store the Java client source.
140
/PackageName="Pkg B"
Project Sub Sys B Project Common
Pkg A
Pkg B
Pkg C
Pkg Records
Pkg Shared
Java GUI VAGen Records VAGen Functions VAGen Programs VGGUIClass VGWkgClass
VAGen Functions VAGen Records
Figure 88. Java Client Generation Using the Same Package as the Java Component Source
7.5.2 Common Package as Java Client Generation Target Package

To support better management of source and runtime code, the proper selection for a target package for Java client generation might be the one that can more readily support source-to-runtime code relationship management. That is, we might choose a package that can be directly related to the source that was used to create the code during Java client generation. Figure 89 shows a scenario where the /PackageName generation option identifies a common package in the project that controls the PLP for the full system.
141
System Project
/PackageName= "Java GUI Gen Pkg"
Default Pkg
Java GUI Gen Pkg
VGGUIClass VGWkgClass
DevProj Sub Sys A
DevProj Sub Sys B
Proj Common Parts Pkg Pgm C Pkg Records Pkg Cntl Files
Pkg Pgm 1
Pkg Pgm 2
Pkg Pgm 3
Pkg Pgm A
Pkg Pgm B
Pkg Shared
Java GUI
Figure 89. Java Client Generation Using a Shared Package in the System Project
By keeping the target package for Java client generation in the system project, the following process is suggested to ensure that source-to-runtime system relationships exist: 1. Version all projects referenced by the system PLP part. 2. Update the system PLP to reflect new target project version identifiers. 3. Perform Java client generation on all Java components in the system using a /PackageName generation option that targets the common Java GUI generation package in the system project. 4. Version the system project. This process should only be followed as part of the process used to build test and production level systems. This would allow the task to be performed by one person as part of a standard phased development process.
142
Part 3. Development Scenario Using Developer on Java
Part 3 includes the following chapters: Chapter 8, Scenario: Designing the Development Process Chapter 9, Migrating an Existing System to Developer on Java Chapter 10, GUI Development with Developer on Java
These chapters discuss how the Developer on Java development platform can be used to implement Java-based GUI business application systems. Focus areas include the use of a team environment development process, development of reusable parts, and GUI programming examples.
143
144
Chapter 8. Scenario: Designing the Development Process

This chapter will attempt to demonstrate how the team environment supports your VisualAge Generator development process. This will be done by using an example of a fictitious company that wishes to migrate its systems to the Developer on Java Version of VisualAge Generator.
8.1 Introduction and Objectives

ITSO Software Associates (ISA) is an institution that builds financial systems. The company has just finished a six-month project to make all of their systems Y2K compliant, and now wishes to take advantage of new technologies that support Rapid Application Development (RAD) and e-business. When doing the analysis for the conversion project, the company was surprised at how many systems they had. ISA wants to take advantage of new technologies, such as GUIs and Web-based systems, but cannot afford to rewrite all of their legacy systems. The first phase of the project is to migrate part of their banking system to the Developer on Java Version of VisualAge Generator and define a new development process. If the results are satisfactory, they will migrate the rest of the banking system and all their other systems to VisualAge Generator V4. The project was divided into the following steps: Team environment development process definition Partial TUI system migration Development of new VisualAge for Java application Complete TUI system migration Testing of enhanced TUI system and VisualAge for Java application System build This chapter will give you an overview of the approach that was used to complete all of these steps. Chapter 9, Migrating an Existing System to Developer on Java on page 153, will explain in detail how they were executed. The end result of the GUI system development task is reviewed in Chapter 10, GUI Development with Developer on Java on page 167.
145
8.2 Team Environment Development Process Definition

The first task that was identified in ISAs project was to define how the tool is going to support the development life cycle. The company already has a working development process and wishes to make minimal changes to it. Defining a development process for a corporation is not an easy task, and there is no one-size-fits-all solution. Therefore, this section will focus mainly on how our sample company designed their team environment container structure to support their current and future development activities. See Chapter 7, Defining a Developer on Java Development Process on page 125 for additional details. The task of designing ISAs new development process was assigned to Jack by the companys Information Technologies (IT) director, Allan. Jack started to work at the company as a developer, but has slowly climbed the ladder to become a senior analyst. He was involved in multiple development projects and is very familiar with the companys current development life cycle. It will be his responsibility to establish and document the new development process and the team environment container structure that will support it.
8.2.1 Identify System Functions to Migrate

Before doing the actual migration, Jack must clearly identify the system functions that will be migrated. ISAs banking system was originally developed in CSP, but was recently migrated to VisualAge Generator 3.1. Jack chose to migrate the bank and customer functions, since they are reasonably complex, and also because he is familiar with them. Each of these functions has list and detail TUIs, data servers and GUIs. Since the GUIs were written in the Smalltalk-based version of VisualAge Generator, they cannot be migrated to the Developer on Java Version. They will be replaced by new GUIs implemented using VisualAge for Java.
146
Table 5 identifies the programs that exist in the two banking system functions that will be migrated.
Table 5. Programs to Migrate
Name
IBKBEWM IBKUWM IBCEWM IBKTUWM IBKBKO1 IBKBKOF IBKBKOL IBKBKON IBKCRO1 IBKCROF IBKCROL IBKCRON
Function, Type
Bank, TUI Bank, TUI Customer, TUI Customer, TUI Bank, called Batch Bank, called Batch Bank, called Batch Bank, called Batch Customer, called Batch Customer, called Batch Customer, called Batch Customer, called Batch
Description
Bank list Bank detail Customer list Customer detail Bank detail select/update server Bank detail validation server Bank list update server Bank list select server Customer detail select/update server Customer detail validation server Customer list update server Customer list select server
All of these programs, and their associates, have to be brought into the Developer on Java environment. To accomplish this, Jack plans to export them into a set of External Source Format (ESF) files and then use the Developer on Java platform to import these files.
Notes:
1. This process could also be performed using either of these Developer on Java migration support tools: V3 to V4 Migration (accepts VisualAge Generator V3 .dat files as input) MSL Migration (accepts ESF, which is placed in MSLs, as input) 2. We did not use the migration tools, as this process was initially performed using the Beta 2 drop of VisualAge Generator V4, and the migration tools were not yet fully functional. 3. When you migrate, you should consider the use of the available migration tools. For additional information, see the VisualAge Generator Migration Guide Version 4.0, SH23-0267.
147
8.2.2 Team Environment Container Structure Definition

Once the components to migrate have been clearly identified, Jack has to design the team environment container structure in which they will be stored.
8.2.2.1 Initial Container Breakdown The initial breakdown that Jack came up with regroups components by system function/object and separates the two types of shared components (system-shared and function-shared). A single project will contain all of the systems packages. Figure 90 displays this initial breakdown.
ISA ITSO Banking System

isa.ibs.common isa.ibs.bank isa.ibs.bank.common isa.ibs.customer isa.ibs.customer.common
Figure 90. Initial Container Structure
8.2.2.2 Second Container Breakdown The first component breakdown is not satisfactory, because the team that will be responsible for developing the new VisualAge for Java applications will not be the same as the one that maintains the existing TUI system. Also, the person responsible for maintaining the SQL definitions will be the ISAs DBA, Otto.
To avoid this problem, Jack decided to: Separate the system functions and common components by type: VisualAge for Java applications (GUIs), TUIs, and data servers. Create a new package for the database definitions. Put common components and functions in separate projects. Applying these changes results in the breakdown shown in Figure 91.
148
ISA ITSO Banking System Common Components

isa.ibs.common.databasedefinitions isa.ibs.common.programs
ISA ITSO Banking System Bank

isa.ibs.bank.guis isa.ibs.bank.guis.common isa.ibs.bank.servers isa.ibs.bank.servers.common isa.ibs.bank.tuis isa.ibs.bank.tuis.common
ISA ITSO Banking System Customer

isa.ibs.customer.guis isa.ibs.customer.guis.common isa.ibs.customer.servers isa.ibs.customer.servers.common isa.ibs.customer.tuis isa.ibs.customer.tuis.common
Figure 91. Second Container Structure
8.2.2.3 Final Container Breakdown If Jack were to import the systems source code in this structure, he would probably get a few hundred VisualAge Generator parts per package. This would complicate the systems maintenance and would augment the chances of two developers modifying components in the same package. Jack decided to solve this problem by creating packages for each system sub-function: detail and list.
Figure 92 illustrates the final breakdown:
149
ISA ITSO Banking System Common Components

isa.ibs.common.databasedefinitions isa.ibs.common.programs
ISA ITSO Banking System Bank

isa.ibs.bank.guis.common isa.ibs.bank.guis.detail isa.ibs.bank.guis.list isa.ibs.bank.servers.common isa.ibs.bank.servers.detail isa.ibs.bank.servers.list isa.ibs.bank.tuis.common isa.ibs.bank.tuis.detail isa.ibs.bank.tuis.list
ISA ITSO Banking System Customer

isa.ibs.customer.gui.common
...
Figure 92. Final Container Breakdown
8.3 Partial TUI System Migration

This phase of the project will validate the migration process that will be used to migrate all of ISAs systems to VisualAge Generator. The general idea is to import the code into the team environment container structure, validate the programs to make sure that none of the components are missing, and version this migrated version of the system.
8.3.1 Moving Source Code to the Team Environment

There are a multitude of ways of migrating code in VisualAge Generator, and the product provides some tools to do this. We recommend that you take advantage of these tools. Once the new development process and the team environment container structure have been defined, Jack is ready to import the code in VisualAge
150
Generator. For this phase of the project, Jack decided that he would do the migration manually to familiarize himself with organizing parts in the team environment. Here are the steps that he identified: Create the team environment users and container structure Import ESF content move Database Definitions Move programs
Each of these steps is explained in the following sections.

8.3.1.1 Create Team Environment Users and Container Structure Before starting to migrate the system, Jack has to define all the users that will be part of the systems development in the team environment. Native operating system password checking will be enabled in the repository to make sure that people use the product (and make changes) under their own name. The list of users shown in Table 6 was identified and implemented in Developer on Java.
Table 6. Team Environment Users
User Name
Administrator Jack Migrator
OS user id
jack jack jack
Description
User responsible for maintaining the repository. Initially mapped to Jack, this responsibility may be assigned to someone else later on. ITSO Software Associates senior analyst. User responsible for all migrations. Initially mapped to Jack, this user will help identify which VisualAge Generator classes were created during migration. Mapping may change once initial migration is completed. ITSO Software Associates database administrator. Default project/package owner. Will be assigned to projects, packages and classes to which no owner has been assigned yet. Since the user is mapped to __emserv__, no password check will be done when developers change their id to this user.
Otto TeamOwner
otto __emserv__
Besides creating the planned container structure, Jack will also create a temporary migration package that will hold all of the systems components before they are moved to the appropriate packages.
8.3.1.2 Import ESF Content This step is rather straightforward: just import the content of each ESF file into the temporary migration package.
151
The following ESF files were imported: Cust31.ESF Bank31.ESF CmnCode31.ESF CmnData31.ESF
For information on the ESF files, see Appendix D, Sample Code and Other Materials on page 303.
8.3.1.3 Move Database Definitions In this step, Jack will move all of the SQL row records and their associates in the common definitions package. 8.3.1.4 Move Programs After moving the database definitions, Jack will move each program in the system along with the associated parts, to the appropriate package. For each program, he will create a list of the associated parts and apply the following logic:
If the component is currently in the programs package, leave it there. If the component is currently in the temporary migration package, move it to the programs package. If the component is in another programs package and the other program is part of the same system function, move it to the system functions common package. If the component is in another programs package and the other program is not part of the same system function, move it to the common programs. Using this logic, Jack should be able to easily identify and move system and function shared components.
8.3.2 Validation and Versioning the Migrated Code

After importing the code, Jack plans to validate all the programs to make sure that he did not forget to import some parts. If the validation is successful, he will version the code and change the project, package, and class owners to the TeamOwner user. After that, the code will be handed over to the team members responsible for enhancing the TUI system.
152
Chapter 9. Migrating an Existing System to Developer on Java

This part of the redbook describes the actions taken to migrate an existing system into VisualAge Generator V4 using the Developer on Java development platform. Chapter 8, Scenario: Designing the Development Process on page 145, described the migration plan and each of its steps. This chapter will detail each of the steps.
9.1 Team Environment Development Process Definition

The first task that was identified in ISAs project was to define how the tool would support the development life cycle. An initial draft of the new development process was detailed in the last chapter.
9.2 Partial TUI System Migration

This phase of the project will validate the migration process that will be used to migrate all of ISAs systems to VisualAge Generator. The general idea is to import the code into the team environment container structure, validate the programs to make sure that none of the components are missing, and version this migrated version of the system.
9.2.1 Moving Source Code to the Team Environment

9.2.1.1 Create Team Environment Users and Container Structure Jack creates all the users that will be part of the banking systems development, and then switches the workspace owner to Migrator.
Jack is now ready to start creating the team environment container structure. He adds the following three system projects: ISA ITSO Banking System Bank ISA ITSO Banking System Common Components ISA ITSO Banking System Customer
153
Figure 93 displays the project creation SmartGuide.
Figure 93. Project Creation SmartGuide
He then selects the "ISA ITSO Banking System Bank" project and creates each of its packages. For each package, he adds the user Owner as a group member. Group members are entered in the second screen of the Package Creation SmartGuide (see Figure 94). The following packages are created: isa.ibs.bank.guis.common isa.ibs.bank.guis.detail isa.ibs.bank.guis.list isa.ibs.bank.servers.common isa.ibs.bank.servers.detail isa.ibs.bank.servers.list isa.ibs.bank.tuis.common isa.ibs.bank.tuis.detail isa.ibs.bank.tuis.list
154
Figure 94. Package Creation SmartGuide
Jack then selects the "ISA ITSO Banking System Common Components" project and creates each of its packages. This time, he adds Owner and Otto as group members of the database definitions package and adds Owner as a group member of the common programs package. Here is the list of packages to add: isa.ibs.common.databasedefinitions isa.ibs.common.programs Jack then selects the "ISA ITSO Banking Customer" project and creates each of its packages. Like the first project, he adds Owner as a group member of all of the packages. Here is the list of packages to add: isa.ibs.customer.guis.common isa.ibs.customer.guis.detail isa.ibs.customer.guis.list isa.ibs.customer.servers.common isa.ibs.customer.servers.detail isa.ibs.customer.servers.list isa.ibs.customer.tuis.common isa.ibs.customer.tuis.detail isa.ibs.customer.tuis.list
155
All the packages for the system functions and common components have been created. We now have to add the temporary migration package. Just select the "ISA ITSO Banking System Common Components" project and add a package named "isa.ibs.migration" with no group members (the user Migrator will be added by default). Figure 95 shows the resulting team environment container structure.
Figure 95. Team Environment Container Structure
156
9.2.1.2 Import ESF Content Once we have defined our team environment container structure, we are ready to import our code into it. The first thing to do is to make sure that the "VAGen Web Transaction Samples" project is not loaded in your workspace. If it is, delete it to avoid duplicates during the import process. Once the project is deleted, open the VAGen Parts Browser by clicking on the "Open VAGen Parts Browser" option under the Workspace menu.
This window should list all the VisualAge Generator parts that are stored in your workspace. To import code, select the "Import..." option of the "Parts" menu. This should display a file selection window that prompts you for an ESF file. Select the "bank.esf" file and click on "Open". VisualAge Generator will read all the members in the file and display them in the VAGen Import dialog (see Figure 96).
Figure 96. VisualAge Generator Import Dialog
157
There should be no parts with errors. Select "isa.ibs.migration" as the target package and click on the "Force target package" to force VisualAge Generator to import the members in the migration package. Click on the ">>" button to add all the available parts to the selected parts pane and click on "Import". After importing all the parts, you may see a window popup. This window displays all the warnings and errors that were encountered during the import process. If you see this window, make sure that all the displayed messages are warnings, and close it down. If you do not see this window, then there were no problems during the import. Click on the "Close" button to close the VAGen import window. In your Parts Browser, press F5 to refresh the parts list. You should now have more than 350 parts in the "itso.ibs.migration" package. We are now ready to move all the VisualAge Generator parts to their appropriate packages.
9.2.1.3 Move Database Definitions The first components that we are going to move are the database definitions. To accomplish this, change the selection criteria of your parts browser by clicking on the "Set Filter..." option of the "View" menu. Deselect all the packages by clicking on the left "None" button and deselect all the VisualAge Generator part types by clicking on the right "None" button. After doing this, select the "isa.ibs.migration" package, expand the "Records" VisualAge Generator part type, select the "SQL Row" type and click on "OK".
158
Your VAGen Parts Browser should now display four SQL row records (see Figure 97).
Figure 97. Database Definitions
Select the first record and click on the "Associates" option of the "Parts" menu. This will open up another VAGen Parts Browser that will show the record and all the global data items that it uses. Select all the parts (hold down the "Ctrl" key and press "/") and click on the "Move" option of the "Parts" menu. A window will pop up and display all the packages in your workspace that are editioned (see Figure 98).
Figure 98. Target Package Selection
159
Double-click on the "isa.ibs.common.databasedefinitions" package to select the target package. The parts should now have been moved to the package, and your VAGen Parts Browser should have been refreshed accordingly. Close this Parts Browser down and move the three other records using the same steps: List associates Select all Move record and associates Before moving the data items, make sure that they are not already in the database definitions package. If some of the items that you selected are already in this package, they will not show up in the target package list when you try to move them.
9.2.1.4 Move Programs After moving the database definitions, we are now ready to move each of the systems programs and its associates in the appropriate package. For each program, we will list all of its associates and apply the following logic for the move operation:
If the component is currently in the programs package, leave it there. If the component is currently in the temporary migration package, move it to the programs package. If the component is in another programs package and the other program is part of the same system function, move it to the system functions common package. If the component is in another programs package and the other program is not part of the same system function, move it to the common programs. To accomplish this, open a VAGen Parts Browser and change the display filters to select the "isa.ibs.migration" package and "Program" VisualAge Generator part type. This should list all the programs, TUIs, and called batches, that are in the package (there should be 13 of them).
160
When moving programs, it is better to move the ones that are leaves of the call tree first. For example, let us say that we have the following call tree, as shown in Figure 99.
Program A Program B Program C Program D

Figure 99. Sample Program Call Tree
The first programs that should be moved are D and B, because they do not call any other programs. After that, C should be moved, and then A. The reason for this is that program parameters, which are shared by the program and all the programs that call it, should be stored with the program itself. Knowing this, we are going to move the called batch programs first, since they do not call other programs (in this scenario, at least). The first program that we are going to move is the SSYSERT, which is a common TUI program that displays error messages to users. List the associates of the program ("Associates" option of the "Parts" menu). Move the parts that are currently in the migration package (all of them) into the "isa.ibs.common.programs" package. Close down the Parts Browser and press "F5" to refresh the programs list. SSYSERT should now be gone from the list, since it is not in the migration package anymore. The next program that we are going to move is IBKBKOF, which is the bank detail validation server. Select it from the VAGen Parts Browser and list its associates. Change the sort order of the list to display the VisualAge Generator parts by package name (click on the "Package" column of the list). Select all the parts that are in the migration package and move them to the "isa.ibs.bank.servers.detail" package. All the parts should now be in this package or in one of the common packages. Close down the Parts Browser. The next program that we are going to move is IBKBKOL, which is the bank list server. Select it from the VAGen Parts Browser and list its associates.
161
Change the sort order of the list to display the VisualAge Generator parts by package name (click on the "Package" column of the list). You may notice that there are several parts in the list that are in the "isa.ibs.bank.servers.detail" package. This means that these parts are shared by at least two programs (IBKBKOF and IBKBKOL). Since these programs are part of the same function, select the shared parts and move them into the "isa.ibs.bank.servers.common" package. After doing this, select all the parts that are in the migration package and move them to the "isa.ibs.bank.servers.list" package. Close down the Parts Browser. The next program that we are going to move is IBKCROF, which is the customer detail validation server. Select it from the VAGen Parts Browser and list its associates. Change the sort order of the list to display the VisualAge Generator parts by package name (click on the "Package" column of the list). You may notice that there are several parts in the list that are in the "isa.ibs.bank.servers.common" package. This means that these parts are shared between programs of the bank and customer functions (like IBKCROF). Since they are shared across multiple functions, move these parts to the "isa.ibs.common.programs" package. After doing this, select all the parts that are in the migration package and move them to the "isa.ibs.customer.servers.detail" package. Close down the Parts Browser. Continue moving all the other servers using the same logic and then move the TUI programs. When moving the parts, you may notice that a particular package contains too many members, or that a particular package is missing. This will often happen, as you cannot predict everything when you design your container structure. In this case, you may create additional packages while you are importing.
9.2.1.5 Package Cleanup After moving all the programs, you should verify that there are no more parts in the migration package. To do this, open a VAGen Parts Browser and change the filters to display all the VisualAge Generator part types in the "isa.ibs.migration"package. If there are still parts left, you have to move them to the appropriate package (list the associates of the part to know where it is used). If there are no more parts left, delete the temporary migration package by selecting it and clicking on the "Delete" option of the "Selected" menu.
Once this is completed, you should clean up the packages. By cleaning up, we mean that you should delete the VisualAge Generator part classes that do not contain any members. In Figure 100, the "isa.ibs.bank.servers.common" package contains three VisualAge Generator part classes: VAGenFunctions, VAGenRecords and VAGenTables.
162
Figure 100. Cleaning Up Packages
The package contains one function and six records, and each of these parts is represented by a method in its corresponding VisualAge Generator part class. You may notice that VAGenTables does not contain any methods. This means that the package does not contain any tables. This situation happens when you move all the parts of a specific type from one package to another. When you move parts, VisualAge Generator creates the appropriate part class in the target package (if it is not already there) and then moves the methods (parts) from the source package to the target package. Even if there are no more parts of a specific type in the package, VisualAge Generator will not remove the part class. This has to be done manually by selecting the class and clicking on the "Delete" option of the "Selected" menu. To clean up your packages, expand them one at a time and check if there is a "plus" sign next to the VisualAge Generator part classes. If there is no "plus" sign, this means that the class has no methods (parts) and you can delete it.
9.2.2 Validation and Versioning the Migrated Code

Once youhave finished importing the code, you should make sure that you did not forget to import anything, by validating all your programs.
163
9.2.2.1 Validating the Code Open a VAGen Parts Browser and change the filters, so that the browser displays the programs in all the packages of your workspace. Select them all by pressing "Ctrl" and "/" and click on the "Validate..." option of the "Parts" menu. Select the target system (MVSCICS) in the drop-down list and click on the "Validate" button.
After a couple of seconds, you should get the "Validation complete" message at the bottom of the window. If you do not get this message, a window will pop up that will display the validation errors and warnings. If you get messages saying that a particular part has not been defined, this means that you forgot to import the part, or that you accidently deleted it. If this happens, you can always reimport the part from the ESF using the import command.
9.2.2.2 Versioning and Releasing the Code Once validation is completed, you now have to version the projects, packages and classes. The quickest way to do this is to collapse the three system packages in the workbench and click on the "Version..." option of the "Manage" submenu of the "Selected" menu. The following window in Figure 101 should appear:
Figure 101. Versioning the Components
Select the "One Name" radio-button option, type the "- Migration 1.0" version name, and click on "OK". This should version and release all the systems projects, packages and VisualAge Generator part classes.
9.2.2.3 Changing the Class Owners Before handing over the migrated code to the development team, you have to change all the class, package, and project owners to the default Owner user.
164
To accomplish this, go to the Classes tab of the Workbench and select the "Goto Class..." option of the "Classes" menu. Type in "VAG" for the class name as shown in Figure 102; this should list all the classes whose name starts with VAG:
Figure 102. Class List
Double-click on the first class in the list (VAGenDataItems). This will locate the first definition of the class in your workspace. Select it and scroll down to the last VisualAge Generator class definition in the list. Hold down the "Shift" and click on the class; this should select all the VisualAge Generator classes in your workspace. To change their owners, click on the "Change Owner..." option of the "Manage" submenu of the "Classes" menu. This will list all the group members that are common to the packages in which the selected classes are defined. Double-click on the Owner user to change the class owners to the default owner.
9.2.2.4 Changing the Package Owners The next step is to change the package owners. Go to the "Packages" tab of the workbench and click on the "Go To Package..." option of the "Packages" menu. The following window in Figure 103 should pop up:
165
Figure 103. Package List
Enter "isa" in the package name and double-click on the first package in the list. This will highlight the first package of the banking system in the list. Select it, scroll down to the last package of the system, hold down the "Shift" key and click on it (this should select all the systems packages). To change the owner, click on the "Change Owner..." option of the "Manage" submenu of the "Packages" menu. This will list all the group members that are common to the selected packages. Double-click on the Owner user to change the package owners to the default owner.
9.2.2.5 Changing the Project Owners The final step of the migration is to change the project owners. To do this, go to the "Projects" tab of the workbench and collapse the three system projects. Select the first one, hold down the "Shift" key, and click on the last one (the three projects should be selected). Click on the "Change Owner..." option of the "Manage" submenu of the "Selected" menu. This will list all the users that are defined in the repository. Double-click on the Owner user to change the project owners to the default owner.
The partial migration phase is now complete. The code can now be handed over to the development team so that they can enhance it.
166
Chapter 10. GUI Development with Developer on Java

This chapter describes the VisualAge for Java system developed to demonstrate the use of Java interoperability with VisualAge Generator parts. The components that were developed for the new system are described, along with their general behavior and their interface (methods, properties and events).
10.1 Development of New VisualAge for Java GUI System

The next step after migrating and enhancing the bank and customer functions is to develop the new VisualAge for Java GUI application. The new system has to be accessible from a multitude of locations. The easiest way to achieve this is by creating VisualAge for Java applets that can be executed from a Web browser. The company also wants to have a version of the system that will be used internally. The second version will use visual components, like frames (windows), that are normally not part of a browser-enabled system. Two sets of classes will have to be created, one for the applets and one for the standard VisualAge for Java applications. For this phase of the project, only the customer part of the system will be developed. Three main GUIs will be created for the Java system, two for the customer lists and one for the detail: CustomerListApplet CustomerListApplication CustomerDetailApplication The customer applet does not have a detail GUI because it will contain both the list and the detail. These three GUIs will be broken down into several classes. Before the development can begin, the following tasks have to be completed: Define the component architecture Design the system specifications Define roles and responsibilities Develop the system
Each of these steps is detailed in the following sections. Once all of this is completed, development can begin. The end result of the development
167
process is detailed in Chapter 10, GUI Development with Developer on Java on page 167.
10.1.1 Component Architecture

Most of the developers at ITSO Software Associates are experienced mainframe COBOL programmers. For them, maintaining the existing TUI system under VisualAge Generator just meant that they had to get used to the tool; the code basically remains the same. The company also has a few programmers that have limited knowledge of object-oriented languages after having attended an introductory course in VisualAge for Java. Because of their limited Java skills, ISA decided that they would try to reduce the amount of manual Java programming in the system by creating reusable beans. Using these beans, the developers would not have to code a single line of Java, since they would only be using visual programming and 4GL. Two systems will be built, a Java applet system and a Java application system. Navigation processing between the screens of these systems will be different, but the information that will be displayed, and the logic to retrieve it, will be the same. Reusable VisualAge for Java classes will be created to implement the common processing. These classes will contain a basic view of the data (one list or several entry fields) and the logic to retrieve and update the data. The reusable classes will be used by both the Java applet and Java application systems. Figure 110 displays the component architecture used in this project.
168
JavaApplicationA (GUI)
(Shared components) Components
JFrame JPushButtons JPopupMenu JavaApplicationB ...
AppletA
Components
Applet Content Pane JPushButtons
PanelA Components
JPanel JTable ...
PanelResourceA Components
VGPROGA ErrorRoutine ... ...
Figure 104. Component Architecture
As shown in Figure 110, both the JavaApplicationA and AppletA classes use PanelA. JavaApplicationA contains a more complex user interface (using secondary windows and popup menus) than AppletA. However, both GUIs display the information in the same format and retrieve it from a called batch program. This shared logic is encapsulated in the PanelA class. To summarize, the following component types will be defined in the system: Reusable components. These components can be used in one or more systems; for example, error routines and list handling parts. Reusable system components. These components can be reused in the system in which they are defined; for example, customer list panel and customer detail panel. VisualAge for Java applets. These will contain one or more panels that display the information for the Web-enabled system. VisualAge for Java applications. These will generally contain one panel, and will use several windows to display information.
169
10.1.2 System Specifications

Now that the component architecture has been defined, the system specifications can be written. The new system will use the same detail and list servers as the existing TUI system. The following sections describe the different components that will be developed for the system. In Chapter 10, GUI Development with Developer on Java on page 167, these components will be described in detail.
10.1.2.1 Global Reusable Components In any development project, there are components that are reused throughout the system. These generic components simplify and standardize the development of new functions. Examples of global reusable components are error routines and list handling parts.
In the scope of this project, ISA wants to limit the amount of manual Java programming to be done, since their developers have a limited knowledge of the language. Reusable components will help them achieve this goal. The following components will be created: IsaActionEventHandler this component allows the developer to visually implement methods and events in a bean. IsaErrorRoutinethis component checks the common error working storage record and triggers the appropriate event (errorOccured or noErrorFound ). IsaLogic this useful bean performs various logic operations. It can check if a value is true or false and perform a "not" operation on a boolean, for example. IsaComboBox this is an extension to the JComboBox part. Features will be added to facilitate the population of the combo boxs items using an array (such as the content of a record). IsaGroupBox this is an extension to the JPanel part. It will behave like a normal panel except that it will have a title and a border. IsaTable this is an extension to the JTable part. Like the combo box part, features will be added to populate the list. Also, other features will be added to update the list and facilitate the use of a popup menu. IsaTextFieldthis is an extension to the JTextField part. This version of the text field can change the case of its content and limit the number of characters that it contains. It also lets you control when the text event is fired.
170
10.1.2.2 System Reusable Components As was explained earlier, ISA will develop two systems, a Java applet and a Java application system. The two systems will display the same information and use the same retrieval and update logic. For this reason, layers of GUI components will be created that encapsulate this logic. These GUI components will be shared by both systems.
The first component that is reused by both systems is CustomerListPanel. This panel displays the customer list retrieved from the database by a VisualAge Generator program. This panel does not function by itself and must be embedded in another GUI. Figure 112 shows the CustomerListPanel prototype.
Figure 105. CustomerListPanel Prototype
The second component that is reused by both GUI systems is CustomerDetailPanel . This reusable panel displays and updates a customer record. Again, all the retrieval and update logic are encapsulated in the panel. Figure 114 shows the CustomerDetailPanel prototype.
Figure 106. CustomerDetailPanel Prototype
171
10.1.2.3 VisualAge for Java Applets There is only one applet in the system: CustomerListApplet. The applet will contain both the customer list and detail; and will let the user add, modify, or delete customers. Again, this applet does not perform any database IOs; these are done by the two reusable components.
Figure 115 displays the prototype for the CustomerListApplet applet.
Figure 107. CustomerListApplet Prototype
10.1.2.4 VisualAge for Java Applications Unlike the applet system, the application system uses two GUIs. The first one, CustomerListApplication, displays the customer list in a frame. It has a set of buttons and a popup menu to add, modify, or delete customers. When one of these buttons is pressed, a secondary window opens and displays the customer detail information.
172
Figure 116 displays the prototype for the CustomerListApplication GUI.
Figure 108. CustomerListApplication Prototype
The second GUI in the Java application system is CustomerDetailApplication . This GUI enables the update of customer data. The GUI is displayed when the user clicks on one of the Add, Modify, or Delete buttons in the CustomerListApplication . Figure 117 displays the prototype for the CustomerDetailApplication application.
Figure 109. CustomerDetailApplication Prototype
173
10.1.3 Roles and Responsibilities

Once the major system components have been identified, the work to be done can be divided between the different members of the project team. For this project, the development effort was separated in the following tasks: Coding of reusable components Coding of system reusable components Coding of applet and application Each of these tasks is a prerequisite to the following task. The coding of the system reusable components (CustomerDetailPanel and CustomerListPanel) cannot start until the base reusable components development is completed. The applet and application programming cannot begin until the two system reusable components are finished. Because of these constraints, a serial development approach will be used. Each development task will be assigned to a different person. The people with the most VisualAge for Java experience will code the reusable components, since they contain native Java code. The people who are the most familiar with the existing VisualAge Generator servers will code the system reusable components, and the rest of the team will code the applets and applications that use them. Ownership of the packages and projects in which these classes are going to be stored will change throughout the project. After migration, the project, package, and class owners were reset to the Owner user. After the assignment of the development tasks is completed, ownership will be changed accordingly. After writing the program specifications and assigning the responsibilities, the development phase can begin.
10.2 Global Reusable Components

The generic globally reusable panel components developed using VisualAge for Java are discussed in this section. These could be used in multiple systems.
174
10.2.1 IsaActionEventHandler
This bean allows the developer to implement methods and events in a bean visually (see Table 7).
Table 7. IsaActionEventHandler Interface
Name
executeAction() event
Type Method Event
Description Triggers the event event Triggered when the executeAction() method is invoked
For example, two instances of the IsaActionEventHandler bean could used in a resource bean to fetch a customer detail instance. The first bean would be named GetDetail and the second one GetSuccessful. After both beans have been put on the free-form surface, connections can be made between them. The first connections source would be the event event of the GetDetail bean, and its target would be the bean that retrieves the information (a VisualAge Generator function, for example). The second connection would connect the hasExecuted event of the function to the executeAction() method of the GetSuccessful bean. Once the connections are done, promote the executeAction() method of the GetDetail bean as getDetail and the event event of the second bean as getSuccessful. By using this bean, you can implement the logic of any part using visual programming.
10.2.2 IsaErrorRoutine
This is a simple bean that checks the common error record to see if any errors are logged in the error code array field. It then triggers the errorOccurred or noErrorFound event accordingly (see Table 8).
Table 8. IsaErrorRoutine Interface
Name
processMessageRecordData
Type Property
Description Record data property. This property is used as a method. When it is changed, the bean will run the error checking logic. Triggered if one or more of the error code fields contain non-blank or non-zero values.
errorOccurred
Event
175
Name
noErrorFound
Type Event
Description Triggered if all the error code fields are blank or zeros.
10.2.3 IsaLogic
This bean performs several logic operations using visual programming. It can check if a string contains a true value ('TRUE', 'YES', and so on) and it can perform a not logical operation on a boolean. Other useful methods could be added to the bean (see Table 9). For example, methods could be added to check for equality between two objects or to check if an object is nil.
Table 9. IsaLogic Interface
Name
checkIfTrue(String)
Type Method
Description Checks if the supplied string contains a true value. If it is equal to 'T', 'TRUE', 'Y' or 'YES', then the isTrue event is triggered. If not, the isFalse event is triggered. Boolean property. When changed, a not operation is performed on aBooleanNot. Boolean property. When changed, a not operation is performed on aBoolean . Triggered by the checkIfTrue(String) method Triggered by the checkIfTrue(String) method
aBoolean
Property
aBooleanNot isTrue isFalse
Property Event Event
10.2.4 IsaComboBox
This bean extends the JComboBox. A method was added to populate the contents using an array (see Table 10). For example, you could use the contents of a VisualAge Generator table to populate the combo box.
Table 10. IsaComboBox Interface
Name
addAllFromArray(Object[])
Type Method
Description Adds the contents of the object array to the combo box.
176
10.2.5 IsaGroupBox
This bean extends the JPanel and has a title and a border surrounding it (see Table 11). These attributes can be customized using the bean properties.
Table 11. IsaComboBox Interface
Name
groupBoxLineColor groupBoxLineWidth groupBoxTitle groupBoxTitleColor groupBoxTitleFont groupBoxTitleJustification (<Choice>)
Type Property Property Property Property Property Property
Description
Color Property. Specifies the color used to draw the group box border. Int Property. Width of the border in pixels. String Property. Title to display. Color Property. Color used to write the title.
Font Property. Font that will be used to write the title. Drop-down list with the following values: DEFAULT_JUSTIFICATION LEFT CENTER RIGHT This sets the position of the title. Drop-down list with the following values: DEFAULT_POSITION ABOVE_TOP TOP BELOW_TOP ABOVE_BOTTOM BOTTOM BELOW_BOTTOM This property specifies where the group boxs title will be written.
groupBoxTitlePosition (<Choice>)
Property
177
10.2.6 IsaTable
This bean extends the JTable part and facilitates list retrieval, updates, item selection, and popup menu handling (see Table 12).
Table 12. IsaTable Interface
Name
addAllFromArrayDataItem (HptArrayField, int)
Type Method
Description Adds the elements stored in the array field to the list. The second parameter is the number of elements in the array. Each field to be displayed in the list (set with the identifier column property) must be a substructured field of the array field. If the field is not found, the items will not be added. Adds the contents of the field to the table at index int. Each field to be displayed must be a substructured field of the supplied field. Adds the contents of the field to the table. Each field to be displayed must be a substructured field of the supplied field. Takes the selected item and puts it in the field. Again, each field that will be displayed must be a substructured field of the supplied field. Removes the item at index int. Replaces the item in the list at index int with the contents of the field. Each field to be displayed must be a substructured field of the supplied field. Boolean property. True if at least one item selected in the list.
JPopupMenu property. A reference to the popup menu that will be displayed when the user right-clicks in the list.
addFromDataItem (int, HptField) addFromDataItem(HptField) putSelectedValueInDataItem (HptField) removeAt(int) setFromDataItem (int, HptField) isItemSelected popupMenu selectionMode(<Choice>)
Method
Method Method
Method Method
Property Property Property
Drop-down list containing the following values:

SINGLE_SELECTION SINGLE_INTERVAL_SELECTION MULTIPLE_INTERVAL_SELECTION
This will set the tables selection type.

mouseDoubleClicked selectedRowChanged
Event Event
Signaled when the user double-clicks on an item in the list. Signals that the selected row in the list has changed.
To use the table, add a JScrollPane to your GUI, put an IsaTable in the pane, and add TableColumn parts to the table. After that, put the data item name that has to be displayed, between double-quotes, in the identifier property of each column. An example of the use of this IsaTable class can be found in 10.3.2, CustomerListPanel on page 181.
178
There is an alternative to the technique that was implemented in the Customer Java GUI system. We could have used the following direct connection from the VisualAge Generator record array to the JTable model attribute: IBKCRRO_WPAGE.INSTANCE-FIELDS <--> ScrollPaneTable.model The main reason that we chose to use a private method, instead of an attribute-to-attribute connection, is that you cannot have a list with an unlimited number of items if you directly connect it to the record. Using the method, we left open the option of looping on the server retrieve logic and invoking the private method multiple times to fill up the list after each block is retrieved. We did not implement support for retrieving multiple packets.
10.2.7 IsaTextField
This bean extends the JTextField. Several features were added to format the contents of the field (set to uppercase, limit length) and control when the text property event fires (see Table 13).
Table 13. IsaTextField Interface
Name
caseConversion (<Choice>)
Type Property
Description Drop-down list containing the following values: NONE (default) TO UPPERCASE TO UPPERCASE - LOCALE TO LOWERCASE TO LOWERCASE - LOCALE Selecting one of these will format the text field to upper or lower case. Drop-down list containing the following values: LOSING FOCUS (default) AFTER EACH KEYSTROKE This attribute specifies if the text property event is triggered every time a key is typed or when the field loses focus (user tabs out).
fireTextChangedOnEvent (<Choice>)
Property
179
Name
formatStringOnEvent (<Choice>)
Type Property
Description Drop-down list containing the following values: LOSING FOCUS (default) AFTER EACH KEYSTROKE This attribute specifies when the fields content will be formatted (truncated and/or case change). Specifies the maximum number of characters that can be typed in the field. Setting it to any value greater than zero (which is the default) will truncate the fields content if it is too large. Truncation will occur when the field is formatted.
maximumStringLength
int
10.3 System Reusable Components

The system specific reusable panel components developed using VisualAge for Java are discussed in this section. The architecture of the reusable components that were implemented for the customer Java GUI system is shown in Figure 110.
(Shared components) ListPanel Components

JPanel JTable ...
ListPanelResource
DetailPanel Components
JPanel JField ...
DetailPanelResource
Components
IBKCRON ErrorRoutine ...
Components
IBKCRO1 ErrorRoutine ...
Figure 110. Reusable Component Architecture
180
10.3.1 CustomerListPanelResource
The first system reusable GUI component is the resource bean that supports list processing. The CustomerListPanelResource component supports access to the VisualAge Generator server program that can obtain a list of customer data, and supports various processing operations on the contents of the list. Figure 111 shows the Developer on Java implementation for this resource bean component.
Figure 111. CustomerListPanelResource Implementation
The CustomerListPanelResource class encapsulates all the retrieval logic and error handling and calls the VisualAge Generator called batch program.
10.3.2 CustomerListPanel
The first visual system reusable GUI component is the customer list panel or view part. This panel provides a list view of the contents of the customer database table and enables various update operations (add, modify and delete) on the contents of the list. Figure 112 shows the Developer on Java implementation for this panel component.
181
Figure 112. CustomerListPanel Implementation
This primary part in the GUI is a panel that contains a list and a label. This component also contains the CustomerListPanelResource class which is responsible for retrieving the list. This class encapsulates all the retrieval logic and error handling and calls the appropriate VisualAge Generator called batch program. Table 14 describes the different methods, properties, and events for the CustomerListPanel class.
Table 14. CustomerListPanel Interface
Name
getList()
Type Method
Description Invokes the getList() method of the panels resource part which fetches the list from the database. Adds a customer record to the list using the customerDetail record. This does not update the database.
addCustomer()
Method
182
Name
modifyCustomer()
Type Method
Description Modifies the selected customer in the list using the customerDetail record. This does not update the database. Removes the selected customer from the list. This does not update the database. Gets the id of the selected customer and stores it in the selectedCustomerId property. Reference to the record used in the customer detail panel. This record is used to update the contents of the list. Reference to the list used to display the customers. String that contains the selected customers id. This is populated by the getSelectedCustomerIdValue() method. Triggered after adding, modifying or deleting a user from the list.
deleteCustomer()
Method
getSelectedCustomerIdValue()
Method
customerDetail(Record)
Property
customerList(IsaTable) selectedCustomerId(String)
Property Property
listUpdateSuccessful
Event
10.3.3 CustomerDetailPanelResource
The next reusable GUI component is the resource bean that supports detail processing. The CustomerDetailPanelResource component supports access to the VisualAge Generator server program that can work with instances of customer data and supports various update operations (add, modify and delete) on the customer instances. Figure 113 shows the Developer on Java implementation for this resource bean component.
183
Figure 113. CustomerDetailPanelResource Implementation
The CustomerListPanelResource class encapsulates all the retrieval logic and error handling and calls the VisualAge Generator called batch program.
10.3.4 CustomerDetailPanel
The second visual system reusable GUI component is the customer detail panel. This panel retrieves, displays and updates a customer record.
184
Figure 114 shows the Developer on Java implementation for this reusable detail view component.
Figure 114. CustomerDetailPanel implementation
This primary part in the GUI is a panel that contains three entry fields and a combo box. The combo box lists all the valid title values and is populated using a VisualAge Generator table. The CustomerDetailPanelResource class is embedded in this panel and is used to retrieve and update the customer database table.
185
Table 14 describes the different methods, properties, and events in the CustomerDetailPanel class.
Table 15. CustomerDetailPanel Interface
Name
disableCustomerDetail()
Type Method
Description This method disables all the fields in the customer detail so that they cannot be updated. Empties all the fields of the customer detail and enables all the fields. Initializes the panel before an add operation. Initializes the panel before a modify operation. The customer id is disabled so that it cannot be modified and the customer detail is retrieved. Initializes the panel before a delete operation. All the customer detail is disabled so that it cannot be modified and the customer detail is retrieved. Adds, modifies or deletes the customer table database using the information entered in the panel. Reference to the record that contains the customer detail. This event is triggered after the customer was successfully added to the database. This event is triggered after the customer was successfully deleted from the database. This event is triggered when an error is encountered while retrieving the customer detail (modify or delete). This event is triggered after successfully retrieving the customer detail (modify or delete). This event is triggered after the customer was successfully updated in the database. This event is triggered when an error is encountered while adding, modifying or deleting a customer.
resetCustomerDetail() initializeAdd() initializeModify()
Method Method Method
initializeDelete()
Method
updateCustomer()
Method
customerDetail(Record) addSuccessful deleteSuccessful getError
Property Event Event Event
getSuccessful
Event
modifySuccessful updateError
Event Event
186
10.4 Java GUI Components

The VisualAge for Java applets and applications developed using the reusable panel components are discussed in this section.
10.4.1 VisualAge for Java AppletCustomerListApplet

CustomerListApplet is the first and only applet in the system, and uses both the CustomerListPanel and CustomerDetailPanel panels.
The only logic in this applet is navigation and control logic, such as enabling and disabling the push buttons. All other processing is implemented in the two panels (CustomerListPanel and CustomerDetailPanel ). Figure 115 shows the Developer on Java implementation for the CustomerListApplet applet component.
Figure 115. CustomerListApplet Implementation
To add a new customer, the user clicks on the add button, enters the information and clicks on the update buttonthe customer is added to the list and database.
187
To modify an existing customer, the user highlights it in the list, double-clicks on it or clicks on the modify button, modifies the information and clicks on the update buttonthe customer detail is updated in the list and in the database. To delete a customer, the user highlights it in the list, clicks on the delete button (the customer detail shows up) and clicks on the update buttonthe customer is deleted from the database and the list.
10.4.2 VisualAge for Java ApplicationCustomerListApplication

A single VisualAge for Java application will be used to display list data. The CustomerListApplication , as with the CustomerListApplet GUI, only includes navigation control logic. Figure 116 shows the Developer on Java implementation for the CustomerListApplication GUI component.
Figure 116. CustomerListApplication Implementation
188
The CustomerListPanel encapsulated in the CustomerListApplication implements the required database access processing.
10.4.3 VisualAge for Java ApplicationCustomerDetailApplication

When the user clicks on the Add, Modify, or Delete buttons in the CustomerListApplication GUI, the CustomerDetailApplication secondary frame opens to support detail instance modification. The CustomerDetailApplication GUI uses the CustomerDetailPanel, which handles all the database processing. Figure 117 shows the Developer on Java implementation for the CustomerDetailApplication GUI component.
Figure 117. CustomerDetailApplication Implementation
189
190
Part 4.
Primer for Developer on Smalltalk Team Environment
Note: The following chapters, provided in Part 4, Primer for Developer on Smalltalk Team Environment, were first published in VisualAge Generator V3.1 System Development Guide, SG24-4230:
Chapter 11, Developer on Smalltalk Development Environment Chapter 12, Smalltalk Architecture and Team Environment Support Chapter 13, Software and Management Components Chapter 14, Version, Edition, and Release Management Chapter 15, Component Roles and Responsibilities Chapter 16, Developer on Smalltalk Development Process Definition They are included here to help you fully understand the VisualAge for Smalltalk team development environment.
191
192
Chapter 11. Developer on Smalltalk Development Environment

If you are going to implement a VisualAge Generator-based development environment, you will find it helpful to be familiar with the new concepts that are part of the VisualAge for Smalltalk team programming environment. In this chapter, we explain the basic elements of the Developer on Smalltalk development environment. This environment is based on the team environment, which is part of the VisualAge for Smalltalk programming platform. Figure 118 shows a view of a Developer on Smalltalk development environment with multiple programmers, their private images, and the shared team environment library.
John's Workstation
John's Image
Application
Zhu's Workstation
Zhu's Image
Application
Marcio's Workstation
Marcio's Image
Application
Configuration Map
Application Application
Configuration Map
EMSRV for Library Connection:

TCP/IP based Security is a configuration option
Image contents loaded from library Changes saved in library Changes controlled by library process
Configuration Map
Application Application Application Application
Pfm
Cam Red
Application
Bpm Sjg
Configuration Map
Application Application Application
Qrs
Team Environment Library Management

Figure 118. Team Development Library Support
This chapter addresses the support provided by the team environment for a group of programmers who are working on the same project.
193
11.1 Team Environment Images and Libraries

The VisualAge for Smalltalk team environment uses images and libraries to support the team development environment. An image provides a private local cache for a single programmer, while a library provides shared storage for the team. You can load components from the library into the local image. The key points to remember about the relationship between the contents of an image and the contents of a library are these: You can have in your image only what you have loaded from the library. Everything you create in your image is saved in the library. When you load a container (such as a configuration map or an application), you also load the contents of the container. These concepts are described in the VisualAge for Smalltalk manuals as:
Image A Smalltalk file that provides a development environment on an individual workstation. An image contains object instances, classes, and methods. It must be loaded into the Smalltalk virtual machine in order to run. Library A shared repository represented by a single file. It stores source code, object (compiled) code, and persistent objects, including editions, versions, and releases of software components. Load A system operation that links the compiled code for a software component from a library into an active image. Loading also performs other operations that enable the component to run, such as linking prerequisites.
This topic is discussed in detail in Chapter 12, Smalltalk Architecture and Team Environment Support on page 199.
194
11.2 Software and Management Components

Methods, classes (and class extensions), applications (and subapplications), and configuration maps are used to define a system and manage the process of system development. These components are described in the VisualAge for Smalltalk manuals as:
Method Executable code that implements the logic of a particular message for a class. In VisualAge for Smalltalk, methods are also called scripts . Class The specification of an object, including its attributes and behavior. Once defined, a class can be used as a template for the creation of object instances. Class, therefore, can also refer to the collection of objects that share those specifications. A class exists within a hierarchy of classes in which it inherits attributes and behavior from its superclasses, which exist closer to the root of the hierarchy. Class extension An extension of the functionality of a class defined by another application. The extension consists of one or more methods that define the added functionality or behavior. These methods cannot modify the existing behavior of the defined class; they can only add behavior specific to the application that contains the extended class. Application A collection of defined and extended classes that provides a reusable piece of functionality. An application contains and organizes functionally related classes. It can also contain subapplications and specify prerequisites. Subapplication An application contained by another application. Using subapplications, you can organize the classes into a tree of subapplications, or isolate the parts of an application that are platform-specific. Configuration map A named group of application editions. A configuration map usually represents a system or one of its major parts.
This topic is discussed in detail in Chapter 13, Software and Management Components on page 209.
195
11.3 Versioning and Component Container Release Processing

The team environment provides versioning support for the storage of components in the library. That is, each time you change a component and save the new copy, the team environment creates a new edition. The old edition is still available. Team environment components act as containers. The team environment release process controls how different versions of a component are added to other containing components. These concepts are described in the VisualAge for Smalltalk manuals as:
Version An edition of a software component that cannot be changed. Each version has a version name or designator, such as R.30. Edition A software component that is subject to further change. A software component can have one or more editions, identified by a time stamp stating the date and time of the editions creation. Many changes can be made to a single edition of a class. In contrast, every change to a method creates a new edition of that method. Release A system operation on a component that changes its containing components configuration. Releasing a component adds its released edition or version to the configuration for its containing component. When a containing component is loaded into an image, the released editions of version of the components it contains are also loaded.
This topic is discussed in detail in Chapter 14, Version, Edition, and Release Management on page 217.
196
11.4 Component Roles and Responsibilities

Management and ownership relationships are assigned between team environment users and the software components. These relationships define certain control and authorization mechanisms that govern the development process. These concepts are described in the VisualAge for Smalltalk manuals as:
Class developer A team member who develops and changes classes. The team member who created an edition of a class is that editions class developer. Class owner A team member responsible for the integration of that class in an application edition. The class owner is responsible for releasing class versions. Application manager A team member who is responsible for the overall state of an application. An application manager coordinates the activities of the applications developers and assigns ownership of classes to team members. Configuration map manager A team member who maintains the integrity of a configuration map.
This topic is discussed in detail in Chapter 15, Component Roles and Responsibilities on page 225.
197
198
Chapter 12. Smalltalk Architecture and Team Environment Support

In this chapter we discuss the basic architecture of a development environment based on VisualAge for Smalltalk and the team environment, and how VisualAge Generator is implemented in this new world. This chapter combines information available from other sources with information specific to VisualAge Generator; it is aimed at both those familiar with prior releases of VisualAge Generator and those already comfortable with the team environment. Specialized product manuals are available that discuss the workings of the team environment; these should be consulted as well. We start by describing a physical layout of a typical team-development environment as implemented by VisualAge for Smalltalk, which is the base for the Developer on Smalltalk platform (see Figure 119).
Workstation
VisualAge Smalltalk VisualAge Generator VisualAge Generator Developer Workstations
Workstation
VisualAge Smalltalk VisualAge Generator
Image
Image
Local Area Network
EMSRV for Library Connection:

Pfm
TCP/IP based Security is a configuration option
Cam Red Qrs Sjg Bpm
Team Environment Library Management
VisualAge Smalltalk Enterprise Manager Library
Figure 119. VisualAge Generator Developer on Smalltalk Team Development Environment
199
As you can see from Figure 119, there are two basic VisualAge Smalltalk Enterprise-based platforms in the development environment:
VisualAge Generator Developer workstation Implemented as a VisualAge for Smalltalk - Client with the VisualAge Generator Developer feature loaded into the the team environment library and the local client image. See the VisualAge Generator product documentation for guidance on VisualAge Generator Developer workstation installation. VisualAge for Smalltalk - Manager Library Shared library on a server workstation. Shared access to the library is implemented using the EMSRV library access program provided with VisualAge for Smalltalk.
To understand how the Developer on Smalltalk development environment works, you must understand the key elements of a development environment based on VisualAge for Smalltalk and VisualAge Generator: the image used to support programming activity on the development workstation and the team environment library, as shared on the library server.
12.1 The Team Environment Library

The team environment library is a common repository with all the necessary code to run a team-development environment. This code implements the team environment logic and processing rules. The library is basically a large file, usually named something like manager.dat .
Note: The default name is based on the product version being installed. For VisualAge for Smalltalk V5, the default library name is mgr50.dat.
The library can be directly accessed, using native file I/O, by one programmer (active development image). To support concurrent access by multiple programmers (active development images), a library server must be established that implements the EMSRV program. The EMSRV program supports shared access by multiple developers. See production documentation for additional details on the library server and EMSRV. Starting with VisualAge for Smalltalk 4.5, the maximum size of a library is no longer restricted to 1 GB. The new maximum library size is the smaller of: 16 GB, or The largest file supported on the native file system used on the workstation platform where the library is stored.
200
Because the library grows as you version each software component, you need to manage both the growth and the size of the library. With VisualAge for Smalltalk Enterprise, the library can only be accessed using the specialized server program (EMSRV) provided with VisualAge for Smalltalk - Manager Library. The use of the EMSRV library server program supports enhanced library control and authorization processing. There are several key planning and configuration steps that must be performed to set up an EMSRV-based shared library. See the VisualAge for Smalltalk product documentation for the team environment library and EMSRV implementation details and guidance. One library can support multiple development platforms. For example, a library on AIX, implemented using EMSRV, can support connections from images being used on OS/2 and Windows NT. Other configurations for multiplatform support are also supported. Typically, libraries are created and maintained by the Library Supervisor, an team environment library user with administrator authority. This is true for the first library created as part of VisualAge for Smalltalk installation and configuration. You can have more than one library, which might be a requirement if you need to keep projects separated for control or security reasons, but consider this option carefully; if you have more than one library you need to define additional procedures in order to reuse parts across the multiple libraries. Programmers can also create libraries by exporting software components from an existing library. During export processing, the team environment asks for a file name for the destination of the export. If the library exists, the exported components are added; if it does not exist, a new library with the identified file name is created. The ability to export (and import) software components from one team environment library to another is the easiest way to share code between locations and teams.
Note: When using an EMSRV-based library configuration, the export/import file name is based on the drives available on the library server workstation. This server-based drive access is also true when you importing a VisualAge for Smalltalk feature using and EMSRV-based library configuration.
Libraries created during export processing are not full-function libraries; that is, they cannot support active development, the loading of other VisualAge for Smalltalk or VisualAge Generator features, or other common development tasks. These type of libraries might be better termed .dat or interchange files.
201
The term .dat comes from the file extension commonly used for these types of files.
Note: The library is a replacement for the MSL (Member Specification Library) used in prior versions of VisualAge Generator.
12.2 The Image in Smalltalk

The image is a Smalltalk executable file that provides a development environment on your workstation. The basic image file, abt.icx, which is created when you install VisualAge for Smalltalk - Client, holds the following: Classes that define the basic VisualAge for Smalltalk product Compiled code for all the executable methods Data for all variables defined in the product You can customize the functionality and capability of the development workstation by controlling which features are loaded into the image. VisualAge Generator support is added to a VisualAge for Smalltalk workstation by: Installing VisualAge Generator Developer on each development workstation. Both VisualAge Generator Developer and VisualAge Generator Common Services must be installed. The installation process adds files to the directory structure where VisualAge for Smalltalk has been installed. Loading the VisualAge Generator Developer feature into the image on each workstation. The first time the VisualAge Generator Developer feature is loaded, the code required to support the feature is imported into the team environment library. The process continues by loading the feature into the development image and modifying or adding files, as required, to the client workstation. When the feature is loaded on other workstations connected to the same library, the import process is not required. Only the loading of the feature into the image and any required file manipulation on the client workstation is performed. The feature code is imported into the library only once. The feature itself could be loaded once, the image saved, and then the same image copied to other development workstations. This way, you need only load the feature once. When the VisualAge Generator Developer feature is loaded, the image contains all the VisualAge Generator Developer components, such as the
202
part editors, test facility, and generation tools that are used to support VisualAge Generator development. Other features, such as the Trailblazer browsers and Web parts, can be added to your workstation by loading the appropriate features. When implementing a full development environment for VisualAge Generator, you may want to identify which features, from VisualAge Generator, VisualAge Smalltalk Enterprise, and other vendors, should be available on all development workstations. Once this base image has been created and saved, it can be shared by copying the image to other development workstations and connecting it with the common library. It is not unusual for a team leader or library administrator to build common base images for a development team that have all the required product function and the current version of the application system that is being developed. By creating this image once and sharing it with the team, you can save load time for each programmer and provide a common base for future development activity. This task may be assisted by using configuration maps to define the structure and content of the application system as stored in the team environment (see 13.4, Configuration Map on page 214). The definition and creation of common images for a development team is best done by a team leader or library administrator.
Notes:
While sharing images is common with VisualAge for Smalltalk, there are some restrictions and possible limitations: Sharing images between operating systems is not possible. The shared image does not always function properly for all workstations, possibly due to operating system setting and configuration differences. Before sharing images, the process should be fully tested. You must test this process in your environment and proceed with caution.
12.3 Library-Image Interactions

The image resides on the VisualAge Generator Developer workstation. The library is physically stored on a shared server platform. The library can only be accessed by using TCP/IP to communicate with the EMSRV program, which is running on the shared server. In some ways, the image resembles a cache of a subset of the library. The cached contents of the image are linked to the masters stored in the library (see Figure 120).
203
Library manager.dat Configuration Map
Application
Class
Image
abt.icx
Method
Object Pointers: From Image To Library
Figure 120. Team Environment File Relationships
Figure 120 shows the basic interactions between the image and the library. Also shown are the Smalltalk software and the team environment management components or objects (configuration map, application, class, and method). These components are discussed in Chapter 13, Software and Management Components on page 209. For now, the image and library relationship can be summarized as follows: Everything that is defined and saved in the team development environment is stored in the shared development library. These stored changes are available to all team members that are using an image connected to the same shared development library. When the changes become availablethat is, immediately or after being versioned, released, or bothdepends on the component type (see Chapter 14, Version, Edition, and Release Management on page 217). You can copy software components from the library and place them in your image using load operations (see Figure 121). Since the library stores the compiled representations as well as source code, loading does not require recompilation. The team environment loading process, like all library interactions, is transactional. This means that either the complete load succeeds or the entire load cancels. You can remove portions of what is stored in your image using the unload operation. An unload discards the selected component objects, as they are already in the library and do not need to be returned or saved.
204
Development Workstation
Image
Unload
Load
Record Changes
(Save)
Figure 121. Library and Image Interactions
The process of loading provides developers with the ability to share and reuse the code easily. It is a simple task to load software components developed by other team members, or even an older version of a component you developed yourself. The library keeps all versions and current editions of all software components for all team members. Any of these components can be found in the library and loaded into your image. You can load individual methods, classes, or applications, which gives you a fine-grain control over what you want to have in your image. You can also, using the unload operation, remove components you no longer need.
Note: The team environment components (methods, classes, and so on) are discussed in Chapter 13, Software and Management Components on page 209. The versioning process is discussed in Chapter 14, Version, Edition, and Release Management on page 217.
Another important concept is the difference between a saved image and a temporary image. You use two images on the VisualAge Generator Developer workstation. The saved image is stored on the hard disk (file abt.icx) and the temporary image resides in memory (see Figure 122).
205
Temporary image
(in memory)
Software components
5 8 13 14 4
8 1 9 2 3 10 12 4 7 14 13 6
Record Changes
(Save)
LOAD
SAVE
abt.icx
5 11
manager.dat
Image File
Figure 122. Image as a Temporary and Saved Cache
Library File
This saved image holds the VisualAge Generator Developer product and any components that you have loaded and saved. The temporary image represents your work in progress. When you make changes to components, they are automatically stored in the temporary image and the library, but not in the saved image. If we want to save the temporary image, we must select the Save Image option from the File menu of the System Transcript (this saves the image to abt.icx). You can save the image to another file by using the Save Image As... option from the File menu of the System Transcript and VisualAge Organizer windows. This means that you can have multiple development images stored on your hard disk, and you can control which one is used when you start the VisualAge Generator Developer. The one used is the one named abt.icx, but you can rename and move files around if you need to use multiple images. Until you save your temporary image, new work that you have done exists only in memory (and, of course, in the Library). The system does not automatically update the abt.icx file on disk. It is up to you to save the image at the appropriate time, or use the alternative (but time-consuming) method of loading the most recent library editions of all the components you need to have in your image to define and test your code.
206
When the system saves an image, the new image is written to the disk and the old image is then erased. Thus, you must have sufficient free space on your hard disk to be able to make successful saves. When you are exiting the VisualAge Generator Developer, the system displays a window asking you whether you want to save the image into abt.icx. Unless you think your image is broken, this is a good opportunity to save your days work so that it will be brought right back to you without having to manually load components from the library.
Note: If your saved image is broken, you need to use the Options->Make Image Consistent function provided in the VisualAge Organizer menu to repair your image.
207
208
Chapter 13. Software and Management Components

Figure 123 shows the structure of the container relationships between the Smalltalk software and the team environment management components that are directly related to VisualAge Generator development: Classes (and class extensions) Methods Applications and subapplications Configuration maps
Configuration Map1 Configuration Map2 Application Classes
Methods
VG Class extensions
Subapplication1 Classes
Methods
VG Class extensions
Subapplication2 Classes
Methods
Subapplication3
Classes
Methods
Figure 123. Smalltalk Software and the Team Environment Management Components
In Figure 123, the application, class, and method components and their container relationships are shown. That is, in the team environment: Methods belong to a particular class definition or class extension. Classes are defined or extended in an application or subapplication. Subapplications are created in an application or another subapplication. Applications can be added to a configuration map. Configuration maps can identify other configuration maps as required.
We explain each of these components, especially the class and the class extension and application relationships, since these component relationships
209
are fundamental to understanding how VisualAge Generator is integrated into the VisualAge for Smalltalk development environment. The team environment also defines roles with associated authorities and responsibilities for each software component. These topics are discussed in Chapter 15, Component Roles and Responsibilities on page 225.
13.1 Class
A class is a set of objects that share common attributes, behaviors, and implementation. A class definition can also be viewed as a template from which you can create new classes (subclassing a class to create a new class definition) or a base that you can enhance within another application (class extension). The first two class categories represent concepts that will help us understand how VisualAge Generator is implemented in VisualAge for Smalltalk. A defined class is a new class that a containing application adds to the system. An extended class is used to add function to the defined class in another application. An extended class consists of one or more methods that define the added functions. These methods are contained in an application other than the application that contains the defined class. When we work with VisualAge Generator parts in the team environment, we work with extended classes and methods. These extended classes are based on defined classes provided as part of VisualAge Generator. The combination of defined and extended classes provides support for VisualAge Generator parts such as records, processes, and so on. VisualAge Generator adds a set of classes to VisualAge for Smalltalk that represent 4GL part types. These classes are identified by VAGen as the first five letters of their class names, for example
VAGenRecords for a Record part type. Figure 124 shows a complete list of the VisualAge Generator part classes defined in the team environment.
GUI member types are represented as defined classes and are subclassed from the AbtAppBldrView class. They are often referred to as views or GUI clients. GUI clients are not involved in the extended class implementation used for VisualAge Generator parts.
210
4GL Member Types GUI Application Process Statement Group Record Map Map Group Data Item PSB Others
VAGen Part Classes Smalltalk class View VAGenPrograms VAGenProcesses VAGenStatementGroups VAGenRecords VAGenMaps VAGenMapGroups VAGenDataItems VAGenPSBs VAGenOptions VAGenLinkages (Stored as files in previous VAGenResources VAGenBindControls versions.) VAGenLinkEdits
Figure 124. VisualAge Generator Part Classes
The five additional VAGen part classes shown in Figure 124 that do not map to VisualAge Generator 4GL member types are used for control information that was stored outside the MSL as files in previous releases of VisualAge Generator. These additional classes support the definition of linkage tables, resource associations, generation options, and the bind and link-edit information. These are used as required during VisualAge Generator testing and generation. The set of VAGen part classes might best be viewed as templates for creating VisualAge Generator parts in the VisualAge for Smalltalk team environment. To use the VAGen part classes to create VisualAge Generator parts, you need to create a VAGen part class extension (for each specific class such as VAGenPrograms) in the application where you create and store VisualAge Generator parts. As you create VisualAge Generator parts, methods are added to the extended class in the current application (see Figure 125).
211
Object... HptVAGenParts... VAGenProcesses VAGenPrograms
Defined class
Applications
SjgVAGenApp1
VAGenProcesses
INIT
Class extensions
SjgVAGenApp2
VAGenProcesses
GET-LIST CLOSE-SQL
GET-NEXT READ-N-SAVE
Methods
Figure 125. VisualAge Generator Extended Classes
Note: In many instances, when you, as the application manager, create the first VisualAge Generator part in an application, the VisualAge Generator code automatically creates the application prerequisite (for the HptVAGenPartsApp application that contains the defined VAGen part classes) and, for each different VAGen part type, the class extension (for the specific part type). This does not occur if you are not the application manager, because only the application manager can modify the application prerequisites. The role of the application manager is discussed in Chapter 15, Component Roles and Responsibilities on page 225.
13.2 Methods in VisualAge Generator

A method is a piece of code that implements the behavior for a specific message for a class. In VisualAge for Smalltalk, when you edit a class, you can edit the methods associated with the class. This is true for pure Smalltalk methods. For VisualAge Generator parts, as defined using extended classes, each part created is implemented as a method on the appropriate extended class (for example, the VAGenProcesses extended class for process parts). If you edit a VisualAge Generator extended class, you can see methods, and if you select a method that represents a VisualAge Generator part, you see the external source format (ESF) code for that part. You can modify the ESF,
212
but this is not the recommended method of editing VisualAge Generator parts. When editing the VisualAge Generator part methods, you use a specialized VisualAge Generator part editor (record editor, process editor, linkage table editor, and so on). The VisualAge Generator part classes appear in the second pane, called Parts , of the VisualAge Organizer window. VisualAge Generator parts, represented as methods on the VAGen extended classes, appear in the third pane, called VisualAge Generator Parts , of the VisualAge Organizer window. This third pane was added to the VisualAge Organizer as part of the installation and loading of the VisualAge Generator feature.
13.3 Applications and Subapplications

An application groups or contains the classes, and their methods, that are functionally related.
Note: The VisualAge Generator Version 2.2 term application, as a member type, was replaced by the term program. In VisualAge Generator Version 4, the term application means VisualAge for Smalltalk team environment application.
A subapplication is an application that belongs to or is contained by, a higher level application (or subapplication). An application is a group of classes and methods that are closely related in function (see Figure 126).
An Application groups classes that are functionally related, so that they can be reused as a unit A Subapplication is an application that is part of another application
Application
Sub application Sub application
Classes
Extended Classes
Figure 126. Applications and Subapplications
213
The role of applications and subapplications for programmers involved in development is explained in Chapter 15, Component Roles and Responsibilities on page 225.
13.4 Configuration Map

We have discussed the application, class, and method components that exist in the team environment and their relationship to VisualAge Generator. There is one more team environment component to understand: the configuration map. The function of a configuration map and how it is used to manage system development and implementation are discussed in this section. Figure 127 shows an alternative view of a configuration map structure that includes other configuration maps and applications.
Named group of applications Can reference other configuration maps Represents a product or one of its major parts During development used for making code baselines
Config Map
Config Map
Application
Config Map
Application
Application
Application
Figure 127. Configuration Maps
Configuration maps are a way to gather, organize, version, and control sets of applications, or other configuration maps. These capabilities can be used to manage code baselines, group-related applications, or create full product versions. Configuration maps can also be used to assist in the loading of a common base of code into an image for further development. Instead of loading
214
numerous independent applications manually, you can load a configuration map that will include the correct set of application versions that represent a common base for a team of programmers. The role of configuration maps is discussed further in Chapter 15, Component Roles and Responsibilities on page 225.
215
216
Chapter 14. Version, Edition, and Release Management

Version control provides the team members with three constructs with which they can manage changes to software components: Editions Versions Scratch editions These constructs give the team members two major benefits:
Flexibility Software components can be developed along alternative paths. These paths can be specific to one image or shared among images. Stability Versions represent fixed baselines of tested code.
Editions and versions allow programmers to check their work as they develop, and if required, back up and try again with a new future path for development decisions. This represents a major advantage over the way programmers used MSLs in previous releases of VisualAge Generator.
14.1 Management of Editions

An edition denotes a state where changes can occur to the component. Editions are identified by time stamps (see Figure 128).
Open Edition
SjgVAGenApp1 (07/19/97 15:30:13PM)
Software component that you can change All changes are recorded in a library Represented by the date and time of its creation
Project Sjg App Edition Plan

Create a 0.5 version by Friday
Work Tasks Fix Class Add Help Revise Views
Figure 128. Edition Definition Illustrated
217
You can create one or more editions of the same software component, with each edition implemented differently. Each edition has a time stamp from which you can identify it. You can create an edition in two ways: Automatically, by saving the work you have done on a component On demand, by requesting that the system create an edition This applies to classes in an open application edition and methods in a class. Programmers working with VisualAge Generator parts will notice that whenever they make a change to the part they are developing, a new edition is automatically created. The programmers can take advantage of the possibility to go back to any of the previous editions. This was not so easy using MSLs. Loading a previous VisualAge Generator part (method) edition is very simple: Use mouse button 2 to click on the selected component. Select the Load - Another edition menu option. Choose the edition you want to load from the window of available editions (see Figure 129). The edition that is currently loaded in the image is represented by an asterisk.
Figure 129. Loading Another Edition
14.2 Version Management

A version represents a complete and frozen set of work. Versions are identified by a customizable version string. By default, the string has a value at the end that is updated sequentially for each subsequent version.
218
A version is made from an edition (Figure 130). After all changes to a component have been made and tested, or at some logical point as defined by the programmer or the programming team, the component can be versioned. When all classes in an application have been versioned, then the application can also be versioned. The version and edition functions provide the fundamental support for change management in the team environment. Using these capabilities frees programmers to work on alternative solutions to a problem. When an answer is selected, it can be versioned and locked at that state.
Version
SjgVAGenAppl1 R1.0
Software component that you cannot change Must create a new edition if you want to make changes Represented by its version identifier
Figure 130. Version Definition Illustrated
You create a version from an edition. To create a version of a component, you often must first create (and load) versions of the components contained in the component to be versioned. For example, to create a version of an application, you must first create versions of all classes and subapplications contained in the application. You cannot create versions of methods (VisualAge Generator parts are implemented as extended class methods). Methods are always editions. A class version contains the specific editions of the contained methods (VisualAge Generator parts) that are loaded when the class version is created. To modify a version, you must first create an edition, make the required changes to it, and then create a version of this updated edition. The old version will be still available in the library; the new version would be used for future work.
219
14.3 Scratch Edition

To make a change to a component in a container, you must create a new edition. There is a special case for applications: you can make changes to classes in a versioned application without creating a new edition. To allow this, the team environment creates what is called a scratch edition (see Figure 131).
<<Scratch Edition>>
<<SjgVAGenApp1 (07/19/97 15:30:13PM)>>
Created if we want to make changes to a versioned component Exists only in a developer's image Represented by << >> signs around its edition identifier
I want to make some experiments with the code that is already in production...
Figure 131. Scratch Edition Definition Illustrated
You create a scratch edition when you want to modify classes contained in an application version, but you do not want to wait for the manager of the application to create a new edition.
Note: Only the manager of the application version can create a new edition of the application. This is discussed in Chapter 15, Component Roles and Responsibilities on page 225.
When you try to modify a class in an application version, the system asks you if you want to create a scratch edition of the application. After you create the scratch edition of the application, you can modify the contained classes and methods. For example, you might create a scratch edition to start some work early, or to support some experimental programming or learning exercise.
Note: To be able to create a scratch edition, you must have the appropriate privileges on the application. While only the application manager can create
220
a new edition of the application, privileges for creating a new edition within the application can be set to either world (any user), group (members of the application group), or owner (owner of the class). You can never (directly) release to others the classes that were modified in the scratch edition of the application. A scratch edition is solely a private edition. You can restore the application to a previous edition or version using the Load Another Edition option on the Applications menu of the VisualAge Organizer window. Once an open edition of the application is available, you can load the editions of the classes and methods you created using a scratch edition, and then version and release them to the application. This will salvage the work you performed using the scratch edition.
14.4 Release Process

Team environment components are containers of other components: Methods are contained in the class where they are defined. Classes are contained in the application where they are defined or extended. Applications are contained in the configuration maps where they have been added. Configuration maps can contain other configuration maps. The changes visible in one component are not visible in the components container unless the component is released. There are multiple techniques for releasing a component into a container: (The description is component dependent.) Method into class Load the required method edition and then version the class. Class into application or subapplication Release the required class version into an edition of the containing application or subapplication. Subapplication into application Release the required subapplication edition or version, into an edition of the containing application. Application into configuration map Add the required application edition or version to an edition of the containing configuration map without creating a new edition of the application. (If you create a new edition for the application, this edition is not released into the configuration map, it must be added later).
221
Figure 132 provides an overview of the component change management process.

1. Create an edition of a component
6. Create an edition of the component so that other members of the team can modify the component 2. Release the edition of the component (if required)
5. Release the component version (if required)
3. Change the component edition
4. Create a version of the component edition

Figure 132. Team Environment Change Management Cycle
The release process is different for each component. For methods, it is not so much a release action as having the required edition of the method loaded. Only a version of a class can be released into an application or subapplication. An open edition or a version of a subapplication can be released into an application. When you release an open edition and then later version that edition, that set of code is still released. It is the same subapplication container, only the state has changed (from edition to version). An open edition or a version of an application can be released into a configuration map. The term as used in the configuration map dialogs is Add . When you release an open edition and then later version that edition, that set of code is still released. It is the same application container, only the state has changed (from edition to version).
222
Figure 133 shows how one component, such as a configuration map or an application, might evolve through the stages of change management.
Editions
Contents can be changed identified by time stamp
Versions
Contents cannot be changed Identified by version string
Release
Component
Only one version can be released into a container

class into application application into configuration map
Edition Edition
Version Red1.0 Version Red1.1 Release
Edition
Version Red1.2
Edition
Version Red2.0
Figure 133. Summary of Team Environment Component Management Steps
223
224
Chapter 15. Component Roles and Responsibilities

The team environment library system manages changes made by a development team in two ways: It restricts modification of components to those users authorized to modify them. It controls concurrent development of components. As shown in Figure 134, change control is based on these distinct ownership roles: Configuration map manager Application manager Class owner Class developer
Configuration Map Manager

Configuration Map
Application
Application Manager
Class Owner
Class
Method
Class Developers
Figure 134. Levels of Component Responsibility
The team environment library manages the issue of who can make changes by using component ownership techniques to identify who is and is not authorized. By component ownership, we mean that each software component is assigned to an individual who is responsible for its quality and
225
integrity. There are certain operations on the software component that can only be performed by the owner. Component ownership contributes to an overall environment that is very good for concurrent application development while maintaining adequate control over the development process. Configuration maps and applications always have a team environment library user assigned as the manager. These managers are responsible for the integrity of the components released into the configuration map or application container. This is still true even if they are not the ones who release the components. Each class in an application or subapplication, including the extended VisualAge Generator part classes, has an owner. These owners are also responsible for the integrity and quality of the code that is contained in the methods associated with that class.
15.1 Configuration Map Manager

The configuration map manager is responsible for the integrity and quality of the code released into their configuration maps. The configuration map manager also maintains the integrity of the configuration map. As shown in Figure 135, the configuration map manager can: Create a version of the configuration map. Create an edition of the configuration map version. Change the applications specified in the configuration map. Release an application version or edition to the configuration map. Change the configuration map manager. Modify the privileges for the configuration map.
226
Configuration Maps
Can reference other (required) configuration maps or applications Creator is configuration map manager Configuration map manager can:
Add applications Release applications to the map Add required maps Create versions and new editions Change the configuration map manger
Config Map
Application
Config Map
Config Map
Application
Application
Application
Figure 135. Configuration Map Roles and Configuration Map Manager Responsibilities
You can use the team environment library configuration map privileges function to modify the rules for releasing application editions or versions to the configuration map. For example, this would allow you to allow application managers to release new editions of the application to the configuration map. See the VisualAge for Smalltalk documentation for details on setting configuration map privileges.
15.2 Application Manager

The application manager reports to the configuration map manager and is responsible for the integrity and quality of the code placed in the applications he or she manages. In an object-oriented environment, this role is even more important, because reusability must sometimes be enforced. The application manager is responsible for the overall status of the contents of the application container. Managers coordinate the activities of the class owners and developers who are working on classes contained in their applications.
227
As shown in Figure 136, the application manager can: Add or delete users from the application group. Assign class ownership. Change the application manager. Change the prerequisites of the application. Create an edition of the application. Create a version of the application. Modify the privileges for the application.
Application
Can have subapplications Creator is application manager Application manager can
Define group (users) Change application manager to another group member Create versions and new editions Release subapplications to managed application
Classes
Application
Sub application
Classes and extended classes are contained in applications
Sub application
Figure 136. Application Roles and Application Manager Responsibilities
An application group represents a group of team environment users assigned to work on an application edition. The application manager is automatically a member of the application group. Other users can become members of the group if the application manager adds them. To own a class in an application you must be a member of the application group. You can use the team environment library application privileges function to restrict access to the contents of the application. For example, this would allow you to decide that only group members have access to the code for the classes contained in the application edition. See the VisualAge for Smalltalk documentation for details on setting application privileges.
15.3 Class Owner and Class Developer

These are the lowest levels of ownership, but not the least important. The class manager is responsible for the methods associated with their class.
228
The class owner is a team member who is responsible for the quality and integrity of a class in an application edition. Only the class owner can do the following: Release the class version. Delete the class from an application. The class developer is a team member who develops and changes classes. The class developer need not be the class owner. Unless restricted by the privileges defined for the application, every user defined to the team environment can become a class developer; however, the class owner is responsible for the integrity of the class definition. Class developers can do the following: Load the edition into his or her image. Change methods or VisualAge Generator parts of the class (load, release, save, delete). Create a version of the class edition. Figure 137 shows the role and responsibilities of class owners and developers.
Classes/Extended Classes
Creator is the owner by default
Class owner can release class into application or delete class
Classes
Class developer can version/create new editions of a class

Class developer role is based on the right to modify the class (privileges) and is directly related to the edition of the class that has been created
Extended Classes
Figure 137. Class Owner and Class Developer Roles and Responsibility
The application manager can change the privileges for the application and change the authority to create new editions within the application from the default (world), to either group or owner. This would limit who can become a class developer. See Chapter 16, Developer on Smalltalk Development Process Definition on page 231, for more details on using privileges to manage the development process.
229
230
Chapter 16. Developer on Smalltalk Development Process Definition

The chapters in Part 4, Primer for Developer on Smalltalk Team Environment on page 191, attempt to provide you with a working knowledge of the team environment: Image and library concepts Team environment components: configuration maps, applications and subapplications, classes, and methods How VisualAge Generator was implemented in VisualAge for Smalltalk: class extensions for each VisualAge Generator part type Version, edition, and release processing as applied to the team environment components Development roles: class developer, class owner, application manager, configuration map manager. Once you understand these key ideas, you are ready to begin the real task: defining how you can use the team environment to support a VisualAge Generator development process. A person familiar with Smalltalk and the team environment might say that this would not be a difficult task. The team environment was designed to support object oriented development (classes and methods), and the application and configuration map containers are well suited to managing the development and system configuration process. Even if you are familiar with both Smalltalk and the team environment, however, you need to appreciate the differences in how VisualAge Generator development is managed and how VisualAge Generator was integrated into the VisualAge for Smalltalk and the team environment library environment before you define your development process. Different approaches are required for VisualAge Generator development in a VisualAge for Smalltalk environment. This chapter reviews some key points about how VisualAge Generator development works in the team environment, identifies some of the behaviors that must be understood from a VisualAge Generator part development and management perspective, and suggests an organizational approach and team environment application architecture that can support the VisualAge Generator development process.
231
16.1 Understanding Developer on Smalltalk Team Environment

Previous chapters in this part of the document have described the team environment library system and the development process in detail. In this section, we review the key points.
16.1.1 VisualAge Generator Team Environment Integration

There are some critical aspects of how VisualAge Generator has been implemented in the team environment that need to be explained: VAGen Part classes have been defined as part of the VisualAge Generator product. These implement the basic behaviors required for VisualAge Generator parts in the VisualAge Smalltalk Enterprise environment. A VAGen Part class is extended in applications that are created to support VisualAge Generator development. We use VAGen Part class extensions, such as VAGenRecords, to create methods that represent our VisualAge Generator parts. The methods we create for a VAGen class are contained in the application where the class was extended. The process of creating methods creates new versions of a class. If two programmers work separately in one application and create methods (VisualAge Generator parts) for the same class (VisualAge Generator part type), they have created two different editions of the VAGen Part class. Each edition can be versioned. Only one version of a VAGen Part class can be released to the containing application. If the changes made by both programmers need to be brought forward (released) into the current edition of the containing application, the two different class versions must be merged.
16.1.2 VisualAge Generator Implementation Issues

Given the way VisualAge Generator has been implemented in the team environment, we offer the following thoughts: Many aspects of VisualAge Generator development tend to suggest that a serial development approach is often the preferred approach. There is no locking of parts in the team environment; that is, there is no formal support for serial development. The team environment supports concurrent development.
232
Without serial development, multiple updates to the same part, and therefore multiple version histories, can result when multiple programmers are working in the same application. Merging is the only way to resolve the changes that have been made to the same part across multiple versions. The high number of parts related to any one VisualAge Generator GUI client or program increases the difficulty of merging versions.
16.1.3 Development Process Objectives

Given the issues just identified, we consider merging to be a task we wish to avoid. We view it as difficult, time consuming, problematic, and avoidablegiven the right approach to using the team environment. To help avoid the need for merging, and promote an effective development environment, we suggest the following to guide the process of implementing an Developer on Smalltalk-based development environment: Accept that approaches to the team environment will differ between development activities based on VisualAge Generator and those based on VisualAge for Smalltalk. Team environment organizational approaches need to be defined that will eliminate (as far as is possible) the need to have more than one programmer working on a VAGen Part class in an application at any one time. Support for efficient version and release management should be incorporated into the team environment organizational approach used to support VisualAge Generator development. That is, programmers should be able to issue simple requests, such as Version/Release Owned, in the VisualAge Organizer when they are done with a task. The granularity of applications must be such that specific development tasks on a set of related VAGen parts fall within the scope of a single programmer (or will do so, say, 95% of the time).
16.1.4 Initial Recommendations

Our study of how to use the team environment for VisualAge Generator development is not complete, but some recommendations can be made now: Be prepared to use subapplications as part of the team environment organizational approach. Ensure that you plan your approach and test your assumptions before starting a new VisualAge Generator development project.
233
Confirm that your organizational approach will support your development process and techniques before you migrate a system to VisualAge Generator Do not begin to create the team environment application structure until the team roles and scope have been agreed on.
Note: After reading the rest of this chapter, you may wish to review the Developer on Java topic 7.4, Representing Stages of Development on page 135. Even though the discussion involves Java, the technique of using project sets could be applied to configuration maps.
16.2 Managing the VisualAge Generator Development Process

To use VisualAge Generator effectively, a development process based on the team environment that satisfies the needs of a VisualAge Generator development team must be defined.
16.2.1 Serial Versus Concurrent Development

VisualAge Generator is a confluence of two different streams of development practice: serial and concurrent (see Figure 138). We need to recognize this and decide how best to use the team environment to manage this situation, recognizing that the team environment was developed for concurrent development.
Serial Development
Controlled access Single-threaded updates 1 Organized Clear delegated scope of authority
2 3
Concurrent Development
Multithreaded updates Flexible Organic Team Envi r onm ent Merging D ef aul t
Figure 138. Serial Versus Concurrent Development
234
16.2.1.1 Serial Development Traditional 3GL or 4GL projects more closely fit the serial model. A programmer is usually assigned complete programs to write and test. These will make use of shared code for common functions. It is unusual for the programmer to look at the internals of this shared code, let alone change it. Any required changes to code that has been made available to the project are made under strictly controlled conditions. 16.2.1.2 Concurrent Development In a pure object-oriented (OO) development project, work tends to be more concurrent than for a traditional third-or fourth-generation language (3GL or 4GL) programming team. This reflects two of the characteristics of an OO development:
Evolution Discovery These characteristics are a consequence of: Class hierarchy Inheritance At the start of a project, the classes and hierarchy defined for the system to be built represent the best guess of the lead designer. During the project, these change as understanding grows and the level of detail becomes finer. Change requires that the team be comfortable with using (inheriting) code already written, in order to extend its function. Sometimes, this can result in the same code (method) being changed by more than one programmer. As a result, changes need careful management, and class owners may have to reconcile different editions. The team environment repository was designed to support this kind of project style. Existing users of VisualAge Generator may have had some of the above experiences in GUI development. They will have seen how reusable parts have been discovered (or modified, perhaps radically) during the project. In performing these tasks, they may have found that the MSL structure was limiting because of the lack of support for versioning. In summary, concurrent development is about: Multithreaded updates Classes are logical containers that can be tested independently Flexibility
235
Intimate knowledge of environment Organic Flat development team structure Class ownership Based on logical owner of a piece of code One Class Owner with multiple Class Developers Multiple editions of the same class Class Developers write methods; Class Owners release classes. Merging Language parsers provide good support for merge process
16.2.1.3 Working with VisualAge Generator Members The 4GL member types have been implemented in VisualAge for Smalltalk as extensions to base classes that define the common behavior for each member type. These are known as VAGen Part classes. In a given VisualAge for Smalltalk Application, all required VisualAge Generator members are defined as extensions of their base class, such as: VAGenRecords, VAGenProcesses, VAGenPrograms, and so on.
This relationship is shown in Figure 139.
Application HptVAGenParts... VAGenProcesses VAGenPrograms
SjgVAGenApp1
VAGenProcesses
INIT GET-NEXT READ-N-SAVE
SjgVAGenApp2
VAGenProcesses
GET-LIST CLOSE-SQL
Figure 139. VAGen Application/Extended Class Hierarchy
236
This gives us classes (VAGen extended classes) that cannot be tested independently. It is the set of VAGen parts associated with a GUI client or program, implemented as methods on multiple VAGen extended classes, that require testing as a unit. In summary, the way VisualAge Generator was implemented in the VisualAge for Smalltalk team environment provides the following challenges: VAGen extended classes: Are used as part-type templates. Cannot be tested in isolation. VAGen programming teams: Are less familiar with new the team environment. Use a hierarchical team structure. Merging with ESF is done at a part level only: Development activity is based on a set of parts. Ownership of a extended class is meaningless. Prerequisites change as member types are added: Only the application manager can change prerequisites. Figure 140 depicts a scenario where multiple programmers are working on different editions of VAGen extended classes in the same application.
237
Different editions of the same class in the same application ...
Programmer1 Image
Programmer2 Image
SjgVAgenApp1 (05/07/97 15:22;17PM)

VAGenProcesses (05/07/97 18:15:32AM)
GET-LIST (05/07/97 18:15:32AM) READ-N-SAVE (05/07/97 18:17:52AM)
SjgVAgenApp1 (05/07/97 15:22;17PM)

VAGenProcesses (06/07/97 09:07:55AM)
GET-LIST (06/07/97 09:07:55AM) READ-N-SAVE (06/07/97 09:17:44AM)
Figure 140. Reconciliation of Parts
As shown in Figure 118, where more than one programmer works on VAGen parts in the same application, then it is possible to have: Different editions of the same VAGen part (for different changes) Or, more likely, different editions of a VAGen extended class part, as a result of changes to unrelated VAGen parts that are extensions of the same VAGen class part. Both of these situations require manual intervention to reconcile. So we appear to have a potentially confusing situation (see Figure 141).
238
Processes?
Records?
Maps?
Programs?
Figure 141. Extended Class Ownership + Concurrent Development = Confusion
16.2.2 Identifying a Solution

It is very easy to be in a situation where VAGen parts that belong to the same VAGen Part class are being tested by two programmers and need changing independently. The two sets of changes then collide, and the VAGen Part class cannot be released until both sets of changes are reconciled and merged to produce a new edition. If such a situation is allowed to happen, it can be extremely difficult to resolve. How likely is this in practice? Let us make some simple assumptions: 100 VAGen Programs Each program has an average of: 40 processes and statement groups 3 records For a total of: 4000 processes and statement groups 300 records 5 programmers.
239
16.2.2.1 Traditional Source Management Scenario In a traditional source library environment, the likelihood of a collision on these parts is related to the ratio of programmers to source library members (see Figure 142), so the probability would be one chance in:
20 programs 800 processes 60 records These represent acceptable to negligible chances.
Lu cy
Joe
Bob
Jan e
Bi l l
Figure 142. Traditional Source Library for Development Team
16.2.2.2 One Application for Each Project In the team environment, the likelihood of a collision is related to the ratio of programmers to VAGen part classes.
If there were only one application for a project, then there would be only a single VAGen part class extension for all programs, records, and so on. In this case, there would be a collision for every VAGen part, because each type of part is dependent on one VAGen part class (see Figure 143).
240
Lu cy
Jo e Bob
Jan e
Bil l
Figure 143. VisualAge Generator Development with One Application for the Project
16.2.2.3 One Application for Each Programmer It becomes clear that the way to reduce collisions is to increase the number of VAGen Part classes. This can be done only by increasing the number of applications (including subapplications). So, how many is enough?
The answer does not lie in some rule-of-thumb ratio, but in a consideration of the scope of development work. What scope would reduce chances of a collision to acceptable to negligible? If each Application were developed by a single programmer (see Figure 144), then he or she could not collide with himself or herself.
241
Lu
cy
Joe Bob
Jan
Bil
Figure 144. VisualAge Generator Development with One Application per Programmer
If projects could be planned perfectly, then the above solution would be fine. However, plans are made to be changed. As soon as an item of work had to be reassigned, extensive changes would have to be made in the team environment.
16.2.2.4 The Application-to-Programmer-Relationship Answer Given the issues and behaviors for the scenarios just reviewed, the answer seems to be in minimizing the chance of a collision. Therefore, a sensible approach would appear to be to make each program belong to a single application; where a program is defined as an independently testable unit of work. This way, when a program is reassigned, the only change in the team environment is to the users defined in the group for the application.
The main points of managed access with the team environment can be summarized as follows: The programmer is to own his or her logical piece of work: Relationship is one programmer to one application. Avoids merging process for most activities.
242
Public (world) gets read access to everything. Restrict write access (creation of new editions) to application group members or Class Owner. Programmer uses set operations at application level. Uses Version/Release owned menu option. Easy to do, keeps logical relationship in version. Application owner could be programmer. Prerequisites are built automatically. Needs ownership change at project end.
16.2.3 Testing the Solution

Let us see how well this simple ideaof one application for each programmers unit of workwill work in practice. We also work toward refining this definition of a VisualAge for Smalltalk-based development process for the Developer on Smalltalk development platform.
16.2.3.1 Configuration Map Management Applications are contained within configuration maps. Configuration map management is reviewed in Figure 145.
Configuration Map Manager manages containers but not content. Manager is the only person who can version Privileges determine who can release into the Configuration Map
Configuration Map
Application
Class
Class
Application
Class
Class
C lass
Class
Application
Class
Class
1.Edition
Class
2.Version
Figure 145. Configuration Map Management
243
Consider the process of creating and working with the applications in the configuration map: Configuration map manager manages containers but not content. Manager is the only person who can version. Privileges determine who can release into the configuration map. These activities apply to the configuration map manager, who may or may not be one of the individual team leaders.
16.2.3.2 Application Management Applications can be versioned, must have assigned managers, and can have groups defined. Application management is reviewed in Figure 146.
Creation of class and method editions controlled by the application privileges Ownership is determined by who created the object What about maintenance? What if the code is to be maintained by a different developer?
Figure 146. Application Management
1. Create an edition 6. Create an edition 2. Release the edition (if required)
5. Release version (if required) 4. Create a version
3. Change the edition
In the team environment development and maintenance life-cycle, The ability to create class and method editions are controlled by the application privileges. Ownership is determined by who created the object. Applications would normally be created by a team leader, not the programmer, but when a programmer is assigned to build this code, the programmers user ID can be added to the group responsible for this application. This implies that there will be only two users in a group; the team leader (owner) and the assigned programmer.
244
If the code is to be maintained by a different programmer, then a second programmer is added to the group. Ownership is assigned to the new programmer, and the original programmer is dropped from the group.
16.2.3.3 Code Management Now consider how this approach affects the programmer of the actual code. Code management (management of the classes where the code is stored) is reviewed in Figure 118.
Creator is the owner by default

Class owner can release class into application or delete class
Classes
Class developer can version and create new editions of a class

Developer has the privileges to modify the class Relationship is with a specific edition of the class
Extended Classes
Member of Group can become Class Owner

Figure 147. Code Management
For 4GL code, the programmer is modifying the VAGen part classes within an application. These allow the programmer to create, modify, and test the 4GL parts. For GUI development, the class is the visible or nonvisible VisualAge Smalltalk Enterprise part. Any 4GL parts dropped on the free-form surface will create VAGen part classes in the application to which the GUI belongs (unless another application is selected during part creation). The key question is: Should the GUI parts be in the same application as the server code? The answer depends on whether a single programmer will create both the GUI and the server code, and test them as a single entity. If yes, then the two parts form a complete unit of work, so we could put them in a single application. If GUI and server coding is split between different programmers, then the GUI and server coding tasks represent different units of work and should be placed in different applications.
245
Note: If client and server code is split between applications, then care must be taken with the ownership of the VAGen records passed as parameters. The project team (or leader) must decide if these are to be owned by the GUI application, the server application, or a dedicated parameters application (perhaps modifiable by the team leader only, to ensure control over changes).
An alternative organizational technique might use subapplications within an application for the client, server, and parameter parts.
16.2.3.4 Programmers Requirements What do programmers want from a library management process? They want the process to work for them, protect them from other programmers, and make life generally easy. The following list covers some typical requirements:
To have full write access to their own code To have read access to common code, but no write access, so the base is not modified or altered unless intended To have system component visibility, but the programmer need only learn what is required to for the task. Ease of backtracking, because previous editions and versions are available Skeletons and templates that provide the ability to copy and rename anybodys work Open access to source, which provides a supportive test and debug environment Ease of loading, because there are no parameters and no complex application relationships Minimal housekeeping (and someone else should do it)
16.2.3.5 Project Leaders Requirements What do project leaders want from a library management process? In essence, they want to be able to check on progress and quality, and get assistance with assessing the impact of proposed changes. A typical list of requirements would be:
Ease of management enabled by processing code in logical sets Assignment of tasks and scope of work (who does what with what?) Methods to easily check completion and determine project status Integration, ensuring that the system works with other systems Ability to manage the build process, plan the code packaging, and plan distribution
246
16.3 Implementing Serial Development

As discussed, VisualAge Generator development works well when managed as a serial process. However, implementing a serial development process in the team environment requires specific approaches for application and configuration map management (see Figure 148).
Application Management
3.Release 3.Release 2.Load editions
Class
Class
Configuration Map
Application
Class
Class
Application
Clas s
Cl ass
Cla ss
Class
Application
Class
Cl ass
Application
Class
Class
Class
1.Edition
1.Edition 1.Edition
Methods (VA Gen Parts)
2.Version
1.Create New editions
2.Version
2.Version
Configuration Map Management
Figure 148. Serial Development
16.3.1 Working with Applications

Application management considerations include: Management of application editions Defining the group for the application Management of privileges Managing changes in ownership
16.3.1.1 Management of Application Editions The project leader who owns the applications (application manager) creates a new edition of each application (logical set of source) to be assigned to a programmer. If the project leader has the privilege (as defined for the configuration map) to release the new edition of the application into the
247
configuration map, then this is done. Otherwise, the owner of the configuration map must release the new edition of the application. The applications to be worked with are now available to the team. Team members should use the configuration map to load the set of applications required to support development activity.
16.3.1.2 Defining the Group for the Application The group for any one application or subapplication should consist of just two people:
Project Leader Programmer This will support the use of application privileges that restrict the creation of new editions to members of the group.
16.3.1.3 Management of Privileges The application manager should ensure that the privileges for the application are set such that only members of the group have the right to create new editions. The right to create editions is related to the classes in the application. If subapplications are used, the same privileges should be defined. 16.3.1.4 Managing Changes in Ownership Before an application is assigned to a programmer for development, the project leader is the application manager. When the new edition is created, ownership of the classes contained in the application should be given to the programmer.
The application manager (project leader) can either reassign class ownership to the programmer added to the group or change the application privileges so that members of the application group can change class ownership. This would allow the programmer to take ownership of the classes to be modified. By default, the programmer is the owner of any new classes created. The project leader is still the application manager. Class ownership allows the programmer to control both versioning and release processing for the classes. The cycle is based on these activities: Create new classes or modify existing classes. Use the version/release owned processing option to version the classes and release them into the application.
248
When unit testing has been completed, the programmer versions the application, and then returns ownership to the project leader. For GUI clients, Smalltalk runtime code for VisualAge Generator parts used in the GUI clients should be generated before versioning the classes. Generation of non-GUI parts (such as VisualAge Generator programs) can be done using versioned classes, applications, or configuration maps.
16.3.2 Working with Configuration Maps

Configuration map management considerations include: Management of privileges Creation and loading strategies Support for batch generation
16.3.2.1 Management of Privileges At some appropriate point after a new application edition has been created, the new edition will need to be released into the current edition of the associated configuration map. By default, this task is restricted to the configuration map manager, but by changing the privileges for the configuration map, the application manager for applications already added to the configuration map can release new editions of their application in that configuration map.
This would essentially delegate the process of keeping an edition of a configuration map up to date to the respective application managers.
16.3.2.2 Creation and Loading Strategies There are two ways to work with configuration maps:
Programmers reload the configuration map periodically. The system loads all released applications, subapplications, and classes into the image. This means that programmers must reload their own open editions (editions not yet released). Each programmer can also selectively load versioned applications or classes created by other team members. A new configuration map is built based on a fixed cycle (for example, once each week). With this policy, every programmer must version and release his/her classes, applications, and subapplications each week. The application manager then makes a version and a new edition of each application. The configuration map manager (or the application manager, depending on the
249
privileges) can then release the new editions of the applications into the configuration map. The new configuration map can either be loaded directly or be used to create a saved image, which is then copied by the team to begin the development process for the next cycle. The time required for the load process depends on the amount of code to be loaded. You could synchronize the load with a weekly team meeting if required.
Note: The VisualAge Organizer preferences are stored in the image, so individual programmer preferences are lost. Alternatively, the team can unload the current configuration map and then load the new one, although this may become too time-consuming in a large project.
The second option offers a much more controlled environment, which is significant when batch generation is in use.
16.3.2.3 Using Alternative (Private) Configuration Maps During the development cycle you will often create a new application or application edition. You might not be ready to share the code contained in the application edition with the rest of the development team, so you decide not add or release this application edition to the appropriate system or subsystem configuration map. You can still use the existing configuration map structure to support both the process of loading code into your image and batch generation by using a private alternative configuration map.
Consider this situation: A configuration map named SubsysACfmap exists. This configuration map contains all the applications that are needed for Subsystem A. Modifications have been made to an application named App1App that is included in configuration map SubsysACfmap, but the active application edition of App1App has not been added or released to SubsysACfmap. To support batch or LAN-based generation the contents of the current edition/version of SubsysACfmap must be loaded along with the active application edition of App1App. Alternative generation options may also be required.
250
How can a private alternative configuration map be used to help? Define a private configuration map, for example, a configuration map named JeriCfmap. Include in this configuration map an application that contains some private generation options (such as ftp user id, password, /PROJECTID, and so on) Define the configuration map SubsysACfmap as a required map to JeriCfmap. With this technique, you can include the current application edition of App1App as in the configuration map JeriCfmap instead of creating an edition of SubsysACfmap that includes the current application edition of App1App. This supports the use of batch or LAN-based generation without requiring that the SubsysACfmap configuration map be modified. The generation request can specify the JeriCfmap configuration map because the required map SubsysACfmap will be loaded first, and the current application edition of App1App will overlay what ever version/edition of App1App was included in the SubsysACfmap configuration map. This means that the generation request will use the baseline code contained in the SubsysACfmap configuration map, plus the code contained in the current, but private, application edition of App1App. With this technique, you can avoid opening editions of SubsysACfmap and releasing App1App until you are ready to share your work with other members of the development team that might be loading the SubsysACfmap configuration map. You can independently manage the configuration map JeriCfmap to add or delete applications as required. You may also have to adjust which edition or version of the required map SubsysACfmap is referenced so that you pick up new baselines as they became available. This technique also allows the build administrator to be in charge of SubsysACfmap (the master configuration map) and only include new code at predetermined times (such as for a build cycle).
Note: The Developer on Java technique of using project sets, as discussed in 7.4, Representing Stages of Development on page 135, could be applied to configuration map management.
251
16.3.2.4 Batch Generation Considerations Batch generation requests specify a configuration map name. To ensure that the configuration map contains the code that should be generated, the classes containing the source code should be versioned and released into an application edition that has been released into the configuration map.
16.3.3 Naming Versions

A version name should mean something to the principal user of the versioned object. It could include: Time line information Owner ID Process stage Comments Date
The version name can be incremented automatically with default naming: 1.1 becomes 1.2, or if 1.2 exists, 1.1.0 A.b becomes A.c
16.4 Organizational Options

This section examines how an application structure can support the management of different types of VisualAge Generator parts, including those shared across multiple programs and systems.
16.4.1 Data Items

Database and master file data definitions can be considered as belonging to the database administrator (DBA). This leads to a conclusion that, if SQL columns are defined as global data items, then they should be defined in an application that is managed by a single user, the DBA. Also: You may need to consider the use of an application and subapplication structure to create manageable units of data definitions. One subapplication per DB2 table (or DL/I segment, master file) might be an option, but be cautious about the level of granularity that you use to segment these definitions. New versions of each subapplication could represent database changes needed by a new project or a major enhancement to an existing system. Programmers should have access only to versioned editions. They should be restricted from changing these editions.
252
Note: Although a subapplication can belong to more than one application in the library, it can belong to only one application in an image. Therefore, if data items are defined outside of any single development project, only those belonging to tables used by the project need to be defined as subapplications of a projects data definition application. This will avoid inflating the size of the image with unwanted contents. 16.4.1.1 Populating Data Items One technique for populating the library with new data items is this:
Set the current user to the DBA user ID. Load or create the SQL Data application. Select this application, and if used, the appropriate subapplication. Create an SQL record for each table, and use the retrieve facility to get all columns from the DB2 catalog. Version and release each SQL data application.
16.4.2 Records
Different approaches for record definition management may be required.
16.4.2.1 SQL Records (Serial, Indexed, DL/I) A very disciplined organization could manage the use (and reuse) of globally defined VisualAge Generator SQL records for relational table definitions to be used by all development projects. This holds true for the other record types and data storage techniques. If this is the case or intention, then these can be managed like data items. The team environment makes such management easier to achieve.
The situation where SQL and other file type records are common to one development project only is more likely. When code generators are used, project SQL and file records are generated. To handle this, one approach is: Create an application for SQL records. The manager of the application should be a team member with a project DBA role. Create one subapplication for each table or view. This subapplication would have only one VAGen Part class called VAGenRecords. Records generated by a code generator may have to be imported separately by the person having the appropriate authority.
253
Any subsequent imports of generated code should filter out all SQL records. Any SQL record changes required from the generated code, should be manually controlled. In summary, all database related information should be: Made available to programmers in read-only form. Grouped to be of manageable size.
16.4.2.2 Working Storage Records Working storage records are used for:
Holding database data for program manipulation. Holding control, status, and temporary data. Working storage records cannot be fully defined at the beginning of a project. They change during the project as the understanding of the requirements increases. Place each working storage record in the application in which it is used.
16.4.2.3 Records Used as Parameters on CALL Statements By definition, these records will be used in at least two programs: the calling and the called one. These programs may be developed (and hence owned) by different programmers. So who should own the definition of these records?
One solution would be to always have one or more SharedRecordApps in the library, with only one owner defined in the group.
16.4.3 Programs
Programs must be organized to support effective development, with access to shared definitions and support for reuse.
Note: Programs include the components such as processes, maps, and VisualAge Generator tables unique to that program. These are the associates of the program.
The initial project plan could allocate one program to one programmer, and hence one application. The project leader may want to put programs that are closely related into the same application. This will work in our approach, as long as all programs are being developed by the same programmer. Do not overload the scope of the application, because it should correspond to a single task in the project plan.
254
Programs can be related in several ways: An umbrella server program and atomic server program for the primary table. List and detail server programs for a table. Umbrella and atomic server programs for all referenced tables.
Note: The terms umbrella and atomic refer to layers in a multitier client/server design. Umbrella servers call other servers. Atomic servers typically include database access and are reusable.
16.4.4 Common Definitions

All common (shared) components should be in applications or subapplications that consist solely of common components. For common functions or services, there should be common applications, or applications with subapplications. For example, a project may have common applications that include: Control and status management Message handling Error logging and reporting Parameter records
16.4.5 Application and Subapplication Organizational Example

We have not yet offered much guidance on using subapplications. The non-GUI parts do not exhibit characteristics that cry out for substructuring an application. When we consider architected GUI views, however, then we have definite layers. It is these layers that are candidates for subapplications. One advantage of using subapplications is that they can be grouped into applications in two ways: By GUI main view, such as a Customer list By layer, such as a Business Object The choice depends on whether the development team is split by the systems data structure, or by programmer skill type, such as: View layout or behavior Business Object visual programming Server 4GL coding
255
We illustrate this with an imaginary GUI client/server system that uses the following layered architecture: View Subview Business Object Resource Object
These are supplemented by functions for: Navigation Services Error handling Message handling Authorization This could provide the following initial breakdown in the team environment: SQLDataApp (all versioned) Table1Data Table2Data ... CommonConfigCm ControlAndStatusApp MessageHandlingApp ErrorLoggingAndReportingApp AuthorizationApp GUICommonPartsApp
View1App Subview1 View1Records View1RscObj View1BusObj
View2App Subview2 View2Records View2RscObj View2BusObj
CalledParameterApp No subapplications VAGenRecords (for all records used in program CALLs)
256
Part 5. Appendices
Note: Several additional chapters from VisualAge for Java Enterprise Version 2 Team Support, SG24-5245, are included in this redbook as these appendices:
Appendix A, Workspace Management on page 259 Appendix B, The Team Development Process on page 269 Appendix C, Program Element State Transitions on page 283 The following additional appendix was written to describe the code and other materials developed during the residency project that produced this redbook: Appendix D, Sample Code and Other Materials on page 303
257
258
Appendix A. Workspace Management

In this appendix we examine various issues concerning the management of an individual user workspace. We describe the Managing page of the Workbench that allows various management operations to be carried out on the standard program elements. We consider how you might organize your projects and packages for maximum flexibility. We then look at the Management Query facility, which enables you to issue many kinds of search operations over your workspace. Finally, we discuss the issue of external resources and suggest how you might manage them to best effect.
A.1 Managing Program Elements

VisualAge for Java Enterprise provides one central place where all user management options can be performed: the Managing page in the Workbench. The Managing page is a view of all loaded project, package, and type editions and the corresponding ownership information. From the Managing page, an owner of a program element can perform all tasks necessary for version, configuration, ownership, and element management. All actions can be performed from the menu items or through the pop-up menus in the lower three owner panes or in the upper program element panes. The actions you are allowed to perform on the different program elements depend on the current role you are playing for a certain element. For example, if you are the owner of a package, you can add team members to the package group or transfer ownership to another team member. If you are not the package owner, these options are grayed out. Figure 149 shows a view of a repository through the Managing page.
259
Figure 149. Workbench Managing Page
Remember that this pageas with the other pages of the Workbenchallows developers to work with items that are currently loaded in their workspace. The Repository Explorer is used to view other editions of program elements that are not currently loaded in the workspace. Together with the management query facility described in Management query on page 262, the Managing page serves as a source of all team-related information.
260
A.2 Project Organization

In VisualAge for Java you can use projects in a number of different ways: As a convenient way of grouping packages with something in common: VisualAge for Java Enterprise itself delivers several projects with this kind of organization. Consider the IBM Java Examples project. It contains a grouping of unrelated packages, each of which contains sample Java code demonstrating various aspects of the product. As a way of grouping together all the elements of a real-world project: Because loading a project is a single atomic operation, this organization provides a simple mechanism to enable all project members to have a common view of the current state of a project. You are most likely to use this organization for your projects. As a way of organizing packages before making a delivery to a customer: If a project contains a complete copy of everything that is delivered to a particular customer (or set of customers), it will be easy to replicate a customer environment later on for maintenance purposes. In practice, you can use all three ways to organize your projects, because in VisualAge for Java Enterprise you can specify the same package as part of multiple projects. The only limitation is that only one such project can be loaded into your workspace at any given time. See 6.4, System Structure Definition on page 119 for additional project organization considerations.
A.3 Package Organization

You use packages in VisualAge for Java just as you would in any other Java development environment. Packages provide a method of grouping together a set of classes and interfaces that are related in some way. In the standard Java Developers Kit (JDK), the package naming convention reflects the directory structure in which the classes and interfaces of the package are stored. The standard Java compiler depends on this structure to locate the classes for which it is looking. Because VisualAge for Java is repository-based, rather than file-system-based, the same restrictions do not apply. However, because the code you develop is likely to be eventually exported, VisualAge for Java insists that you name your packages in a conventional way with a dot-separated list of names, each of which represents a valid directory name.
261
A.4 Management query

VisualAge for Java Enterprise provides a management query facility (Figure 150) for interrogating the status of the program elements in your workspace. This facility enables you to manage your workspace and to regulate its contents. It is an indispensable aid at various stages of the development process when you need to be aware of the status of all of the program elements for which you are responsible.
Figure 150. Management Query Facility
The management query is invoked through the Workspace menu option of any browser. It is organized as a dialog with two areas: Query definition Result
262
The management query facility allows queries to be defined with respect to these attributes: Status Program element Scope Owners Developers
Queries can be built based on types, packages, and projects, and for each of these program elements, you can search for elements that are in a particular state; for example, all packages that are open editions. Each of these queries can be further refined by specifying ownership criteria, and in the case of types, by specifying class or interface developer criteria. Along with the customized query option, there are also 14 predefined queries which define the settings required to answer common questions (see Figure 151).
Figure 151. Using Predefined Query Definitions
263
A.5 Project Resources

When developing in Java, you sometimes need to use external resources that are not part of the language. For example, it is quite common to use images and audio clips in Java applets. VisualAge for Java does not store these external resources in the repository along with your Java source and bytecodes. Instead you must create these resource files explicitly outside the development environment and store them on the standard file system. VisualAge for Java makes certain assumptions about where resource files are located. For a project called ProjectX , it assumes that the resource files will be found in a directory called IBMVJava\Ide\project_resources\ProjectX on the client machine. In fact, whenever VisualAge for Java creates a new project, it automatically creates a directory with the same name. VisualAge for Java uses this resource directory in a number of ways: When running an applet from within VisualAge for Java, the code base for the applet is specified as the name of the resource directory. The URL of this directory will be returned by the getCodeBase method of the java.applet.Applet class. When running an applet or an application from within VisualAge for Java, the default CLASSPATH contains the resource directory. When exporting a project to a JAR file, all files in the resource directory for that project can be included in the JAR file, and the JAR file can be compressed. Skeleton HTML files for all applets are optionally generated. An alternative to the default resource directory is to explicitly tell VisualAge for Java in the workspace options (Window > Options ) that you want to use shared resources and indicate the path to the location where those shared resources can be found (Figure 152).
264
Figure 152. Specifying a Shared Resource Directory
This path should identify a shared file location. You must manually create a directory under this path for each project whose resources are to be shared. Even if this option is set, VisualAge for Java still automatically creates the default resource directory. This shared resource location is used by VisualAge for Java when exporting a project in JAR format. In fact, it includes all resource files from both the shared and the default resource directories. The shared resource directory is not used to establish the code base when running an applet from within VisualAge for Java. Resource files must be managed carefully to avoid problems when VisualAge for Java needs to locate them.
265
Issues that must be considered include: If many developers are working on a single project and each developer manages resources independently, problems will occur when you attempt to consolidate the work of separate developers. For example, system testers will be unable to locate resources when testing a a package that has many class owners. More fundamentally, a class owner may be unable to test a class if it uses another class that has associated resource files and is owned by another developer. When carrying out certain kinds of export operations, all resource files for a project must be accessible to VisualAge for Java or they will not be included in the export. By default, resource files are located by the project in which a package exists. If you move the package to another project, VisualAge for Java will not be able to locate the resource files. In addition to the requirement that VisualAge for Java be able to locate resource files, it is also important that your applets and applications can find their resource files in a consistent way.
A.6 Managing Resource Files

Here we offer some suggestions for managing your resource files. Many options are available to you, and you should consider the unique circumstances of your own environment before deciding which solution will work best for you. The first scenario makes use of VisualAge for Javas shared resources facility. The second scenario manages resources by package.
A.6.1 Using Shared Resources
In this scenario, you want to manage your resources using a shared resources directory. Create a directory on a shared file system to act as the shared resource path. Set the VisualAge for Java option to use shared resources as detailed above. In the shared resource directory, create a subdirectory for each project that contains resource files to be managed. It is the project owners responsibility to maintain the project resource directories. This is normally done in conjunction with the owner of the
266
class that uses the resources. It is also the class owners responsibility to copy the required resources into the local project resource directory as created by VisualAge for Java. Some operating systems (UNIX, for example) allow you to create a soft link between the master copy and your local copy. This is the preferred mechanism, but a hard copy is acceptable. All developers and testers are responsible for copying the required resource files into their personal project resource directory. When it is time to deliver a project through an export operation, the required resource files are already in place.
A.6.2 Managing Resources by Package
In this scenario, you want to manage your resources by package as it likely that your packages will be moved among projects for organizational reasons. Establish a directory on a shared file system to store the master copy of all resource files. In the directory create a subdirectory for each package that contains resource files to be managed. Use the full name of the package as your directory name to keep the hierarchy shallow and facilitate retrieval. If you have a large number of packages, you can group them in arbitrary subdirectories. By organizing your resource files by package instead of by project, you avoid problems associated with moving packages among projects. It is the package owners responsibility to maintain the package resource directories. This is normally done in conjunction with the owner of the class that uses the resources. It is also the class owners responsibility to copy the required resources into the project resource directory as created by VisualAge for Java. All developers and testers are responsible for copying the required resource files into their personal project resource directory. It is the responsibility of the project owner to copy all resource files of all packages in the project into the project resource directory before exporting the project as a JAR file. In both scenarios class developers should access resource files in their code relative to a common root directory. For applets, this should be the applet code base. This organization fits in with the code base established by VisualAge for Java for testing applets. For applications, there is much greater freedom, and you will probably pass a parameter to your program indicating where resource files are kept.
267
268
Appendix B. The Team Development Process

This appendix describes the standard VisualAge for Java team development process in more detail. To get the most out of the team programming features of VisualAge for Java Enterprise, it is important that you adhere to some well-established modes of operation, which we call development patterns . We examine several such patterns, ranging from the simple to the complex. We also discuss what happens when development has finished and your work has to be delivered to the end user. Note: This information is provided to improve your overall understanding of how VisualAge for Java team support can be used by a set of programmers. The development process required to support VisualAge Generator-based development is described in Chapter 7, Defining a Developer on Java Development Process on page 125.
B.1 Activity Patterns for Daily Development

In this section we discuss how you can use VisualAge for Java Enterprise for daily development activities. We first introduce the basic development pattern, which describes how programmers work with class editions and versions. We then explore four different development scenarios ranging from a simple, single developer environment to large projects involving multiple developers working on multiple packages.
B.1.1 The Basic Development Pattern
Figure 153 shows the most fundamental development pattern in VisualAge for Java. As a class developer, you move through a cycle of creating a new edition, making changes to it, and versioning it.
Create New Edition Version the Class Make Changes
Figure 153. The Basic Development Pattern for Classes
269
You can enter this cycle at different points depending on the overall context in which you are working. You leave this cycle having created a new version of the class. This basic pattern forms the core of all the work you do in VisualAge for Java and is repeated in all of the scenarios we explore. The frequency with which you version your class depends on personal style and the overall team environment. A rule of thumb is to version the class or interface whenever you reach a known state to which you may want to return. Versioning classes at least on a daily basis would be typical practice. This pattern naturally supports an incremental development style that is usual in object-oriented programming. When you reach a point in the cycle where you want to preserve your code, version it and then move on to the next phase with the confidence that if anything goes wrong you can always return to a known state. If you are working as part of a team, there may be a requirement to version your classes at defined intervals, so that your classes can be seen by other developers or be released by the class owner for the creation of a package baseline.
B.1.2 Single Package, Single Developer
This scenario, a small application consisting of a single package where only one person is responsible for all the work, is the simplest way of working with VisualAge for Java Enterprise. The application may use classes from other packages but does not have to change them. Figure 154 shows the overall process. Although this is a simple scenario, it is probably representative of the many small applications that will be developed in VisualAge for Java.
270
Create Class-1
Create New Edition Version the Class
Create Package
Make Changes
Release All
Create Class-n
Version Package
Release Package
Figure 154. Single Developer Working with a Single Package
In this scenario you are a single user playing the role of package owner, class owner, and class developer. The project owner creates a package in the appropriate project and assigns ownership of the package to you. You create all the classes and interfaces required for the application. For each class you cycle through the standard development pattern by creating successive versions as you develop and debug the application. Work continues in parallel on each class until you are completely satisfied that your application works correctly. Now you release all classes and interfaces into the package edition and create a version of the package. Finally, either you or the project owner releases the package.
B.1.3 Single Package, Multiple Developers
In this scenario multiple developers work on an application that is being developed as a single package. The scenario introduces the issues that arise when developers must cooperate with each other to do their work. Typically, in this situation, the lead developer acts as the package owner. The project owner creates the package and assigns ownership to the lead developer. After the initial analysis of the problem domain has been completed and a first pass design has been carried out, the set of classes and interfaces that make up the application are known. The lead developer allocates
271
responsibility to each developer for a number of classes. The lead developer adds the users to the package group so that they will have the authority to create classes and interfaces within the package. Figure 155 shows the normal working pattern in this scenario.
Developer 1
Create Class-x
Release Class-x
Developer 2
Create New Edition
Create Class-y
Make Changes
Version the Class
Release Class-y
Figure 155. Working Pattern for Class Owners
When a developer creates a class or interface, he or she becomes the owner of that type. This is one of the key principles of the team environment. The ownership model reinforces the notion of responsibility. Other developers can make changes to a class they do not own, but, as we see later in this scenario, the owner must eventually accept or reject those changes and make them available to the rest of the team. Each developer, who is also a class owner, works independently on the classes for which they have responsibility. The project manager has established a project plan that lays out various milestones in the application development process. These milestones generally represent the achievement of a certain level of functionality within the application and present an opportunity for all developers to synchronize with each other and have a common view of the current state of the overall application. This is normally called establishing a baseline. A baseline allows inconsistencies and discrepancies (which could be related to analysis, design, or development) to be caught early in the development process before they
272
have become too entrenched. Baselines also allow regular deadlines to be set, which is good for programmer productivity! When approaching a deadline, the lead developer expects programmers to have all their classes in a working state and instructs them to release the classes. The lead developer establishes a new package baseline by creating a new version of the package. Each developer then reloads the new package version to access the latest version of all classes in the package. This process is shown in Figure 156. The class owners resume the normal development pattern until the next project milestone and the production of a new baseline. Unfortunately, things do not always proceed smoothly. Invariably a developer working on a class finds that some new function is needed in another class or discovers a bug in another class that adversely affects his or her own progress. In these situations the developer does not have to immediately bother the owner of the other class in order to move forward. The developer simply creates a new edition of the class in question and makes any required changes in that edition. By creating a new edition of the class, the developer becomes the class developer of that private edition. When the developer is satisfied with the changes, he or she creates a new version of that class and gives it a meaningful name indicating the source of the changes. The developer consults with the owner to discuss the changes and the reasons for them. It is now up to the class owner to decide whether those changes are valid and fit in with the overall purpose of the class. In a fast-moving development project, it is quite likely that the class in question has been further developed by the owner in the meantime. In this situation the owner must reconcile the changes and merge them into a new version (see Figure 157 on page 275). Once the changes have been reconciled, the owner resumes a normal development pattern.
273
Class Owners
Release Class-x Release Class-y Release Class-z
Package Owner
Version Package
(New Baseline)
Create New Edition
Class Owners
Reload Package Reload Package Reload Package
Figure 156. Establishing a Package Baseline
274
Class Owner
Create Class
Class Developer
Create New Edition
Make Changes
Version the Class
Create New Edition
Reconcile Changes
Figure 157. Merging Divergent Class Changes
Change reconciliation is made easy through the use of the comparison browser in VisualAge for Java. The owner views class and method definitions side-by-side with the differences highlighted. The owner selectively loads one or the other of the versions into a new edition. Where changes to a single method clash, the owner must manually edit the method to reconcile the changes. Merging changes like this should take place on a regular basis. It is much less error prone to have frequent small reconciliations than it is to wait for a long time and try to reconcile a larger set of changes in one operation.
Tip
Do you have to wait for a baseline to see changes? Developers need not wait until a new baseline is established to see changes made to other classes. Informal interaction among team members is a normal daily occurrence. A class owner can announce to the colleagues that a new version of a class, which is fit for general use, is available. Other developers may explicitly load that version into their workspace. Creating a package baseline simply formalizes this process.
275
B.1.4 Multiple Packages, Multiple Developers
We now move on to a more complex scenario, which is typical of a large-scale project. In this scenario we have simultaneous development of multiple packages. The scope of the project is such that we have many distinct subsystems, which are naturally partitioned into separate packages. The project team is divided into smaller teams, each of which has responsibility for a particular package. The project owner is likely to be the chief architect and creates the packages and assigns ownership of each package to the corresponding team leader. Each team leader adds the team members to the package group. All the patterns of development we have seen so far are also present in this scenario: the basic development pattern for classes; the establishment of package baselines; and the reconciliation of changes. Change reconciliation may also be necessary across package boundaries. There are always interpackage dependencies, and a developer of one package may have to change a class of another package. This is not a problem. Membership of a package group is not required in order to create a new edition of a class in that package and become the edition developer. The process of managing the reconciliation is exactly the same. In this large-scale project scenario we now must consider managing project baselines. We define and discuss two useful and typical kinds of project baselines: standard and rolling.
B.1.4.1 Standard Project Baseline A standard project baseline is directly analogous to a package baseline. With a standard project baseline you first create baselines of all the packages in the project. You then release all the package versions to the project. This step can be carried out by either the individual package owners or, more probably, by the project owner. Once all the packages have been released, the project owner creates a new baseline by versioning the project. This version represents an immutable state of the project, its packages, and all their classes. It is likely that this step will be carried out only at major project milestones and, of course, at the end of the project. Figure 158 shows the complete process.
If work is to continue after the creation of the baseline, a new project edition is created, and development continues.
276
Package Owners
Version Package1 Version Package2 Version Package3
Project or Package Release Owners Package1
Release Package2
Release Package3
Project Owner
Version Project
(New Baseline)
Create Project Edition
Package Owners
Create Pkg1 Edition Create Pkg2 Edition Create Pkg3 Edition
Class Owners
Reload Project Reload Project Reload Project
Figure 158. Establishing a Project Baseline
277
B.1.4.2 Rolling Project Baseline The standard project baseline can be quite a burdensome process. The more packages you have in the project, the more difficult it is to ensure that you can produce a baseline for all packages at the same time.
Fortunately, VisualAge for Java provides a much more convenient way for programmers to have access to an edition of the project that provides a snapshot of the current state of the application. Figure 159 shows the rolling project baseline process.
Package Owners
Version Package1 Version Package1 Version Package3
Project or Package Release Owners Package1
Release Package2
Release Package3
(Rolling Baseline)
Class Owners
Reload Project Reload Project Reload Project
Figure 159. A Rolling Project Baseline
278
The key to the rolling project baseline process is that packages do not have to be versioned before they are released to the project edition. (In Figure 159 the broken boxes indicate optional steps.) The ramifications of this are quite profound. By releasing an open package edition to the project, you are ensuring that when a class is released into that package it automatically becomes available to any developer who reloads the current edition of the project into the workspace. Hence the use of the term rollingthe project baseline is constantly changing as new classes and interfaces are released.
Tip
Use caution with rolling project baselines! As with any powerful feature, caution should be exercised when using rolling project baselines. The release of a buggy class could cause inconvenience for any programmer who loads it. Releasing a class into a released package has the effect of bypassing any integration testing that would typically occur at the package level. The ability to freely combine the release of versioned packages and open edition packages into your project enables you to exercise a degree of fine tuning over the process. For example, open edition releases could be restricted to packages where the class owners are senior programmers and can be trusted to fully test their classes before release.
B.1.5 Multiple Parallel Streams
This scenario shows the power of VisualAge for Java Enterprise in handling complex development situations. Suppose you are part of a software house developing an application for a customer. The application is being developed as a single package. At a certain stage in the development process, your salesperson manages to sell the system to another customer. Naturally the system has to be tailored to the new customers needs. You continue system development until all of the code that is common to both customers has been written and tested. You are now ready to enter split stream development mode. Using the tested and stable version of the package as a base, you create two new editions of the package: one for each customer. Each edition of the package can have a separate owner and package group associated with it (see Figure 160).
279
Single Stream
Release Class-x Release Class-y Release Class-z
Version Package
(New Baseline)
Stream A
Create New PKG Edition
Stream B
Create New PKG Edition
Work on Class-x
Work on Class-y
Work on Class-y
Work on Class-z
Figure 160. Split Stream Development
Development proceeds as if there were two distinct packages. The same class or interface can be modified independently in each package edition. The ownership of common classes can be modified to reflect the changed responsibilities. In essence, the owner of the class or interface edition is associated with the package edition that holds that edition.
280
With split stream development, there is no intention to rejoin the streams. The advantage is having a common code base from which both streams developed. If this code base has to change (as it invariably will), a new edition of the package version at the root of the split stream should be created. Each of the split streams can then be brought up-to-date by simply reloading the changed program element in question and performing any reconciliations that might be required.
B.2 Project Wrapup and Delivery

When a project has been completed, you must go through the process of delivering it to your customer. This process is usually the same whether you are a software house delivering to an external customer or an IT department delivering an internal system to your end users. The first step is to produce a standard project baseline as described earlier. You may want to leave this version of the project as the reference release version. Alternatively you may want to set up a special project just to hold the released version, reinforcing the separation of development and released versions of the project. Reinforcement would simply be a matter of policy on your part. VisualAge for Java Enterprise guarantees the separation of different versions of the same project. In either event, you should add extensive comments to the project edition, before versioning. We recommend that you establish a standard format for comments that must be added to a project edition before it is versioned for release. When you have a completed project version, you should choose a delivery mechanism. VisualAge for Java Enterprise offers a number of options for exporting your work so that it can be delivered to the customer: Export .class and/or .java files Produce a JAR file Export to another repository Exporting can include all of the required resources (see Project Resources on page 264) and generate HTML files for applets. These export options are described in the documentation accompanying the VisualAge for Java Enterprise product.
281
282
Appendix C. Program Element State Transitions

In this appendix we document the allowable state transitions for projects, packages, and classes. In Chapter 5, Understanding the Basics on page 95, we state that software elements can exist in three statesas scratch editions, open editions, and versioned editions or, more simply, versions. We also describe the notion of releasing, where a program element is made available to its containing program element. While releasing does not actually change the state of a program element, it can sometimes be useful to think about it in that way. For example, releasing is an action on a class that changes the subsequent actions that can be applied to that class. We therefore introduce the notion of a released class and, for packages, a released version and a released open edition. So far our discussion has assumed that we are talking about program elements that are present in the workspace. After all, it is only in the workspace that elements can be changed. However, program elements must be created at some time and can exist only in the repository after they have been removed from the workspace. Program elements can also be removed completely (admittedly with some difficulty) from the repository. Therefore we introduce the states of not existing for program elements before their creation or after their removal, and repository only for elements that do not exist in the workspace. We define a transition as the change of a program element from one state to another. This definition is somewhat loose because the nature of such a transition can vary. For example, when we talk about moving from an open edition to a version, the program element remains the same but its name changes. When we talk about moving from a version to an open edition, however, we are actually creating a new instance of the program element. Nevertheless, in all cases, the semantics of the transition should be clear. For each transition we document the situation in which the transition might occur, the prerequisites that must be satisfied before it can occur, and the mechanism by which it occurs.
C.1 Project State Transitions

Figure 161 shows the 5 states in which projects can exist and the 10 valid transitions among them.
283
7
Scratch Edition
Open Edition
1 9 3 2
Repository Only
Not
Existing
6 8
Version
10 9 3
Figure 161. Valid State Transitions for Projects
These transitions are listed below and described in the subsequent sections: 1. Not Existing -> Open Edition 2. Not Existing -> Repository Only 3. Repository Only -> Version/Open Edition 4. Version -> Open Edition 5. Open Edition -> Version 6. Version -> Scratch Edition 7. Scratch Edition -> Open Edition 8. Scratch Edition -> Not Existing 9. Version/Open Edition -> Repository Only 10.Repository Only -> Not Existing
C.1.1 Not Existing -> Open Edition (1) Situation This is how brand new projects are created. Prerequisites Any registered team user can create a new project. The user becomes the owner of the project.
284
Mechanism From the Project view of the Workbench, bring up a SmartGuide by selecting Selected > Add > Project... The same SmartGuide can be invoked by selecting Projects > Add > Project... from the Managing view of the Workbench.
Select the Create a new project named: radio button and type the name of your new project. If a project of the same name already exists in your workspace, you are prompted with a message at the bottom of the SmartGuide and you will not be able to click the Finish button. Otherwise, click on the Finish button, and the new project is created in your workspace and in the repository. If the project already exists in the repository, you will be asked if you want to create a new edition of that project. You cannot have more than one project with the same name in the repository.
C.1.2 Not Existing -> Repository Only (2) Situation A project is created in the repository as a result of an import operation. Prerequisites Any registered user can import a project into the repository. The administrator becomes the owner of such projects.
The project to be imported must be a version in the other repository.

Mechanism Select File > Import from the Workbench to invoke the SmartGuide.
Complete projects can be imported from another repository by selecting the Repository radio button. The SmartGuide asks you to provide the IP address and file name of the other repository. When you have selected a valid repository, you are presented with a list of projects (and packages) in the other repository, and you can select the projects and versions you want to import.
C.1.3 Repository Only -> Version/Open Edition (3) Situation You must bring a project into the workspace before you can work on any of its packages. Project versions and open editions are handled in the same way.
285
Prerequisites Any registered user can load a project into the workspace. The load will not be successful if the project to be loaded contains a package that already exists in the workspace as part of another project. It is a rule in VisualAge for Java Enterprise that the same package can exist in multiple projects in the repository, but not in the workspace. The entire load is an atomic operation, and the operation will either succeed completely or not load any portion of the project. Mechanism Invoke the Add Project SmartGuide by selecting Projects > Add > Project... from the Managing view of the Workbench or Selected > Add > Project... from the Project view.
Check Add projects from the repository and select the projects and the editions you want to load. Click on the Finish button, and the selected project editions are loaded into your workspace. Alternatively: Go to the Repository Explorer and highlight the project and edition you want to load. Select Editions > Add to Workspace (or use the pop-up menu in the Editions pane), and the selected project edition is loaded into your workspace. A project that already exists in the workspace can be replaced by another version/open edition from the repository. Select Projects > Replace With > Another Edition..., and you are asked to select from the list of editions in the repository. You can quickly revert to the previous edition by selecting Projects > Replace With > Previous Edition or, if you are currently working with an open edition and it has changed in the repository, you can bring your workspace up-to-date by selecting Projects > Replace With > Current Edition .
C.1.4 Version -> Open Edition (4) Situation You should create a new edition of a project when you want to make a change to the project. Remember that a project version is immutableif you want to change it in any way such as creating new package editions or even changing the comment associated with the project, you must first create a new edition.
Changing the owner of a project, however, does not force you to create a new edition.
286
Prerequisites Only the project owner is allowed to create a new edition of the project. Mechanism Select Projects > Manage > Create Open Edition (or Selected > Manage > Create Open Edition) to create a new project edition. The edition is named by appending the current data and time in parentheses to the project name.
If you attempt to add a new package to a project version, the VisualAge for Java SmartGuide asks you if you want it to create a new edition of the project. (There is actually a way for anyone to create a new edition of a project. First delete the project from your workspace. Then go into the Add Project SmartGuide and create a new project of the same name. The SmartGuide tells you that a version already exists in the repository and asks you if you want to create a new edition. If you answer yes, a new edition of the project is created with you as the owner.)
C.1.5 Open Edition -> Version (5) Situation You create a new project version from an open edition when you want to establish a baseline for your entire project. Once versioned, the project is immutable. Prerequisites Only the owner of a project can create a new version of the project.
All packages in the project must be versioned and must be released (released versions in our terminology).
Mechanism Select Projects > Manage > Version from the Managing view of the Workbench. C.1.6 Version -> Scratch Edition (6) Situation A scratch edition of the project is automatically created whenever an open edition of an existing package is created in a project version. Prerequisites None. A scratch edition is created for any user. Note that only package owners are allowed to create an open edition of a package.
287
Mechanism None. Creating a scratch edition of the project happens automatically. C.1.7 Scratch Edition -> Open Edition (7) Situation Because VisualAge for Java can automatically create scratch editions of a project, it may be necessary to convert your scratch edition to an open edition. You do this conversion if you want to eventually release package elements into the project and thus make them available to other users. Prerequisites Only the project owner can convert a scratch edition to an open edition. Mechanism Select Projects > Manage > Create Open Edition from the Managing view of the Workbench. C.1.8 Scratch Edition -> Not Existing (8) Situation If you do not want to retain the changes you made to the project that caused the scratch edition to be made, you can completely remove the scratch edition.
You can remove the scratch edition in two ways. As project owner you can delete the project and thus remove the project from the workspace. Alternatively you can replace the scratch edition with another edition from the repository and thus remove the scratch edition from the workspace. Because the scratch edition existed only in the workplace, it is completely deleted. Note that nothing ever really disappears from VisualAge for Java! If you created new package editions in your project scratch edition, they will still be in the repository after the project scratch edition is deleted. However, you have to search for the new package editions in the packages list because they do not belong to any project.
Prerequisites Only the project owner can explicitly delete a project scratch edition.
Anyone can replace a scratch edition with another edition from the repository.
Mechanism To delete a project, select Projects > Delete... from the Managing view of the Workbench, and the project is completely removed from the
288
workspace. However, all previous project versions and open editions still exist in the repository and can be reloaded at any time. Because the scratch edition existed only in the workspace, it disappears completely. To replace the scratch edition with another edition, select Projects > Replace With from the Managing view of the Workbench. You have a choice of three submenus: Current Edition: Load the edition that has the same name as the edition in your workspace. If the current edition is not a version, its contents may have changed since you last loaded it. Previous Edition: Load the version of the project that was created chronologically before the edition currently in your workspace. Another Edition...: This option presents you with a list of all project editions in the repository. You are invited to select the edition to load.
C.1.9 Version/Open Edition -> Repository Only (9) Situation VisualAge for Java provides menu options for deleting program elementshowever, you only delete in the context of your personal workspace. The elements themselves remain in the repository. You use this option simply to clear up your workspace. Having a smaller workspace reduces your startup and shutdown times. So if you are no longer working on a particular project, you should remove it from your workspace.
You may also have to remove a project from your workspace if it contains a package that is also contained in another project that you want to load. Only one copy of a package can be in your workspace at a time.
Prerequisites None. Any user can delete a project version or open edition from the workspace. Mechanism Select Projects > Delete from the Managing view of the Workbench. C.1.10 Repository Only -> Not Existing (10) Situation Eventually you want to remove old projects from your repository. Otherwise the repository continues to grow. Prerequisites Only the project owner or the administrator can purge projects or project editions. A project edition cannot be purged if it is loaded in your
289
workspace. (Check that there are no asterisks beside any of the project editions in the Repository Explorer.) Only the administrator can compact the repository.
Mechanism Completely removing projects is a two-stage process:
First you must purge the project and/or project editions. To purge the entire project, in the Repository Explorer highlight the project and select Names > Purge. To purge one or more editions, highlight the required editions and select Editions > Purge. If all editions of a project are purged, the project is also purged. The second stage involves compacting the repository.
C.2 Package State Transitions

Figure 162 shows the 7 states for packages and the 14 transitions.
5 4 10 6
Scratch Edition Open Edition
12 13 12
Released Open Edition
14 8
Repository Only
Not Existing
11 9
12 13
Version
2 12 7
Released Version
Not Existing
Figure 162. Valid State Transitions for Packages
These transitions are listed below and described in the subsequent sections: 1. Not Existing -> Released Open Edition 2. Not Existing -> Repository Only 3. Released Open Edition -> Released Version 4. Released Version -> Open Edition
290
5. Open Edition -> Released Open Edition 6. Open Edition -> Version 7. Version -> Released Version 8. Version -> Open Edition 9. Version/Released Version -> Scratch Edition 10.Scratch Edition -> Open Edition 11.Scratch Edition -> Not Existing 12.(Released) Open Edition/(Released) Version -> Repository Only 13.Repository Only -> Open Edition/Version 14.Repository Only -> Not Existing
C.2.1 Not Existing -> Released Open Edition (1) Situation There are two situations where this transition can occur: creating a brand new package and importing elements (.class files, .java files, jar files) from outside VisualAge for Java into a package that does not exist.
A package must always be created within the context of a project. You typically create a new package when a major new work application is being initiated. You import an existing package when you want to copy external code into VisualAge for Java. A major difference between importing directly from another repository and importing files is that in the former case you import directly into the repository, and in the latter case you import into a package in your workspace.
Prerequisites The user must be the project owner.
The project must be an open edition. For package creation, a package of the same name must not exist in any project in the users workspace. For package import, if a package of the same name already exists in a project currently loaded in the workspace, the new classes will be added to it. This applies even if the package is in a project other than the one specified on import. In this situation, all prerequisites for creating classes in a package apply.
Mechanism Creating a new package:
291
Select Packages > Add > Package... from the Managing view of the Workbench. This brings up the Add Package SmartGuide. Select the Create a new package named: radio button and type your new package name. You may also add new package group members at this stage if you want. Package group members can create new classes and release them into your package. Importing from files: Select File > Import... from the Workbench. This brings up the Import SmartGuide. Select the project to import to and the type of import (class files, java files, JAR file, or entire directory) The next screen in the SmartGuide allows you to select the files or directory to import.
C.2.2 Not Existing -> Repository Only (2) Situation This transition occurs when you import a package from another repository into your VisualAge for Java repository. Prerequisites Any registered user can import a package into the repository. The administrator becomes the owner of such packages.
The package you want to import must be a version in the other repository.
Mechanism A package can be imported as part of a project as detailed in the corresponding transition for projects.
A package can also be imported independently: Select File > Import... from the Workbench. This brings up the Import SmartGuide. Select the type of import (Repository). The next page in the SmartGuide asks you to provide the IP address or host name of the server and the name of the repository file from which to import. When you have selected a valid repository, you are presented with a list of packages (and projects) in the repository. Select the package and package edition you want to import.
292
C.2.3 Released Open Edition -> Released Version (3) Situation You should convert a released open edition to a released version when you want to make a new package baseline. Once versioned, the package cannot be changed. Prerequisites You must be the package owner.
All classes in the package must be released (which also implies that they must be versioned).
Mechanism Select Packages > Manage > Release from the Managing view of the Workbench. C.2.4 Released Version -> Open Edition (4) Situation You can create an open edition of a package from a released version when you want to make changes to the package. Prerequisites You must be the package owner.
The owning project must be an open edition. If not, a scratch edition of the project will be created. You do not need to be the project owner to create a new package edition.
Mechanism Select Packages > Manage > Create Open Edition from the Managing view of the Workbench. C.2.5 Open Edition -> Released Open Edition (5) Situation This transition allows you to release a package to its project before you have versioned the package. This is a very useful facility when you want to create a rolling baseline from which all developers can synchronize their workspaces. When a developer loads the project, only classes that have been released to the package are visible. As other classes are released, the developer can reload the project to update the workspace. This facility avoids cluttering the repository with package versions that are created with the sole purpose of establishing a baseline.
293
Prerequisites You must be the project owner or package owner. Mechanism Select Packages > Manage > Release from the Managing view of the Workbench. C.2.6 Open Edition -> Version (6) Situation You should create a package version from an open edition when you want to freeze the contents of the package before releasing it into its project. Prerequisites You must be the package owner.
All classes in the package must be released (which also implies that they must be versioned).
Mechanism Select Packages > Manage > Version from the Managing view of the Workbench. C.2.7 Version -> Released Version (7) Situation You can release a version of your package when you want to make it available to the enclosing project. Prerequisites You must be the project owner or package owner. Mechanism Select Packages > Manage > Release from the Managing view of the Workspace. C.2.8 Version -> Open Edition (8) Situation You can create an open edition of a package from a version when you want to make changes to the package. Prerequisites You must be the package owner.
By definition, the owning project will already be an open (or scratch) edition.
294
Mechanism Select Packages > Manage > Create Open Edition from the Managing view of the Workspace. C.2.9 Version/Released Version -> Scratch Edition (9) Situation This transition occurs automatically whenever a new edition of an existing class or interface is created in a versioned package. Prerequisites None. A scratch edition will be created for any user, even if that user is a member of the package group. Mechanism None. The transition happens automatically. C.2.10 Scratch Edition -> Open Edition (10) Situation The scratch package edition exists because you created new classes or interfaces in a versioned package. You have to convert the scratch edition to an open edition to make the new classes or interfaces available to other users. Prerequisites You must be the package owner.
The project must be an open edition. If not, VisualAge for Java creates a scratch project edition.
Mechanism Select Packages > Manage > Create Open Edition from the Managing view of the Workspace. C.2.11 Scratch Edition -> Not Existing (11) Situation You can remove the package scratch edition if you do not want to retain the changes you made to the package that caused the scratch edition to be created.
You can remove the scratch edition in two ways. As package owner, you can delete the package and thus remove the package from the workspace and disassociate it from its project. However, this is unlikely to be the behavior you want. The simplest approach is to replace the scratch edition
295
with another edition from the repository. As the scratch edition is not stored in the repository, the replace deletes the scratch edition. As with scratch project editions, removing a scratch package edition does not completely remove any of its class editions. These are still stored in the repository. To see them you must use a class browser and examine editions of the class.
Prerequisites To explicitly delete a scratch edition, you must be the package owner.
Anyone can replace a scratch edition with another edition from the repository.
Mechanism To delete a package select Packages > Delete... from the Managing view of the Workbench.
To replace with another edition select Packages > Replace With from the Managing view of the Workbench. You have a choice of four submenus: Released Edition: Load the edition that has been released to the project. Current Edition: Load the edition that has the same name as the edition in your workspace. If that edition is not a version, its contents may have changed since you last loaded it. Previous Edition: Load the version of the package that was created chronologically before the edition currently in your workspace. Another Edition...: This option presents you with a list of all package editions in the repository. You are invited to select the edition to load.
C.2.12 (Released) Open Edition/(Released) Version -> Repository Only (12) Situation You can delete a package if you have the correct privileges. Deleting a package has two effects:
The package is no longer loaded into your workspace. However, it still exists in the repository and can be accessed through the Repository Explorer. The association between the project and the package is removed, even in the repository. In the repository, a package can be part of zero, one, or many projects. In a workspace it must belong to a single project.
296
Prerequisites You must be the package owner, project owner, or administrator.
The project must be an open edition.

Mechanism Select Packages > Delete... from the Managing view of the Workbench. C.2.13 Repository Only -> Open Edition/Version (13) Situation A package can be loaded from the repository into a specific project in the workspace. Typically this will be an infrequent operation carried out when a project is being set up and defined. When package editions are loaded in this way, they retain their original package owner and package group members. Prerequisites You must be the owner of the project or the administrator.
The project must be an open edition. A package of the same name must not exist in the same or any other project in the workspace.
Mechanism From the Managing view of the Workbench select Packages > Add > Package. This brings up the Add Package SmartGuide.
Select the Add packages from the repository radio button and a list of available packages and editions will be displayed. Select any number of package editions and click on the Finish button.
C.2.14 Repository Only -> Not Existing (14) Situation Packages can be purged from the repository if they are no longer required. You can also purge individual package editions. Even when purged, packages can be restored, provided that the repository has not been compacted. Prerequisites Only the package owner or the administrator can purge packages or package editions.
The package must not be currently loaded into the workspace. Only the administrator can compact the repository.
297
Mechanism Completely removing a package from the repository is a two-stage process:
First you must purge the package and/or package editions. In the Packages view of the Repository Explorer, select Names > Purge... to purge a complete package or select Editions > Purge... to purge a single edition. The second stage involves compacting the repository.
C.3 Class State Transitions

Figure 163 shows the 5 states in which classes and interfaces can exist and the 7 valid transitions among them.
Open Edition
1 6 5 7
Not Existing
6 4 5
Version
Repository Only
5
Released Version
Figure 163. Valid State Transitions for Classes
These transitions are listed below and described in the subsequent sections: 1. Not Existing -> Open Edition 2. Open Edition -> Version 3. Version -> Released Version 4. Version/Released Version -> Open Edition 5. Version/Open Edition/Released Version -> Repository Only
298
6. Repository Only -> Version/Open Edition 7. Repository Only -> Not Existing
C.3.1 Not Existing -> Open Edition (1) Situation This is how brand new classes and interfaces are created. Prerequisites The package in which the class is being created must be an open edition. If it is not, the SmartGuide will change the package to an open edition for you automatically. You must be the package owner.
If the package is already an open edition, you must be a package group member to create a new class.
Mechanism Classes are created using the Create Type SmartGuide. One way to create a new class is through the Types > Add > Class/Interface menu option in the Managing view of the Workbench. The creator of the class becomes the class owner and the class developer of the new edition. C.3.2 Open Edition -> Version (2) Situation You create a new version of a class from an open edition when you want to freeze the definition of the class. Versioned classes cannot be changed. Prerequisites Only the class developer can version a class. Mechanism Select Types > Manage > Version... from the Managing view of the Workbench. You can version multiple classes at a time and apply the same or individual version numbers to each class. C.3.3 Version -> Released Version (3) Situation You release a class to its enclosing package when you want to make it available to other users who load that edition of the package. Prerequisites Only the class owner can release a class.
The enclosing package must be an open edition.
299
Mechanism Select Types > Manage > Release from the Managing view of the Workbench C.3.4 Version/Released Version -> Open Edition (4) Situation If you want to make changes to a versioned class, you must first create an open edition of the class. Prerequisites Anyone can create an open edition of an existing class. If the package to which the class belongs is not an open edition, a scratch edition is created automatically. Mechanism Select Types > Manage > Create Open Edition from the Managing view of the Workbench. C.3.5 Version/Open Edition/Released Version -> Repository Only (5) Situation You can delete a class when it is no longer required. Deleting a class removes it from the enclosing package and from the workspace. The class remains in the repository and is still implicitly associated with the same package. You can load the class from the repository back into any edition of the same package at a later stage. Prerequisites Only the class owner can delete a class.
The enclosing package must be an open edition.

Mechanism Select Types > Delete... from the Managing view of the Workbench. C.3.6 Repository Only -> Version/Open Edition (6) Situation This is how you retrieve a previously deleted class from the repository. Prerequisites The enclosing package must be an open edition. VisualAge for Java does not automatically create a scratch edition for you.
You must be a group member of the enclosing package. You automatically become the new owner of the class you load in this way. The class
300
developer remains the same, so when you load an open edition that has another user as its developer, you cannot change the class.
Mechanism Select Types > Add > Class/Interface... > Type from Repository... from the Managing view of the Workbench. You will be presented with a list of classes and interfaces that belong to the currently selected package in the repository.
Select a class and an edition of the class to load.

C.3.7 Repository Only -> Not Existing (7) Situation This transition is shown as a broken line because it is not possible to explicitly remove classes from the repository. Classes are purged when the package they belong to is purged.
301
302
Appendix D. Sample Code and Other Materials

In this appendix we describe the code and other materials developed during the residency project that produced this redbook. These materials, which are available for your use, include: VisualAge for Java and VisualAge Generator V4 code (one project) VisualAge Generator V3.1 code DB2 database materials The SG245467.EXE file packaged on the diskette is a self-extracting ZIP file with directories for the different materials included with this document. The materials included on the diskette may be updated. Please check for updates in the SG245467 directory at the ITSO redbook materials ftp site at:
ftp://www.redbooks.ibm.com/redbooks/
The materials are provided as-is and with limited informal support. If you have questions regarding the materials, please place a question on the VisualAge Generator newsgroup or send a note to the book owner, Pat McCarthy, at patmc@us.ibm.com.
D.1 VisualAge for Java and VisualAge Generator V4 Code

The Java code implementation of GUIs, a subset of the ITSO Bank system used in other redbooks, is described in Chapter 10, GUI Development with Developer on Java on page 167. We exported the VisualAge for Java and VisualAge Generator code, using the interchange file format, and stored it in .dat files, which is included in the DevJ directory:
DevOnJ.dat
Projects containing the Developer on Java source code (Java GUIs and 4GL).
The following projects are Included in the VisualAge for Java export file: ISA ISA ISA ISA ITSO ITSO ITSO ITSO Banking Banking Banking Banking System System System System includes PLP part for remaining projects Bank Common Components Customer
Note: The Java GUIs for the subset of the ITSO Bank system were implemented using a Beta version of Developer on Java. They were tested using the Beta 3 drop, and should function fine on your code base.
303
D.2 VisualAge Generator V3 Code

The VisualAge Generator codes includes a set of GUI, TUI, and server programs implemented for the ITSO Bank system using VisualAge Generator Templates. This code was used during the migration tasks described in Chapter 9, Migrating an Existing System to Developer on Java on page 153 We exported the VisualAge Generator V3.1 ENVY applications and stored them in a .dat file which is included in a file in the VAGen directory:
Bank31CM.dat Configuration maps and applications containing the VisualAge Generator source code.
The configuration maps and applications shown in Table 16 are included in the VisualAge generator .dat file in the VAGen directory.
Table 16. VisualAge Generator Configuration Maps and Applications
Configuration Map
VGV3ITSOBankCM VGV3BankingSystemCM
Application
(points at other configuration maps) IBKBankApp IBKCustomerApp
VGV3CommonCM
CmnGlobalItemApp CmnVAGTPartsApp
Also included in the VAGen directory are ESF exports of the VisualAge Generator V3.1 applications:
Cust31.ESF Bank31.ESF
Code from the IBKCustomerApp application. Code from the IBKBankApp application.
CmnCode31.ESF Code from the CmnVAGTPartsApp application. CmnData31.ESF Code from the CmnGlobalItemApp application.
For further information on VisualAge Generator Templates please visit the http://www.redbooks.ibm.com web page and look for the publication VisualAge Generator Templates - Creating a Well-Tailored Solution, SG24-5263.
304
D.3 Database
The VisualAge Generator server programs referenced in this book accessed one or more DB2 tables in the ITSOBank database. The following files are included in the Database directory:
BankDB.bat
Command file to create database and load data into the tables. Edit file to adjust database create statements and creator ID value for create table statements. Data definition statements to create database and tables. SQL statements to insert data into tables. Catalog report of database tables. SQL query for data in tables.
ITSOBank.ddl loaddata.sql itsocat.txt itsodb.txt
Appendix D. Sample Code and Other Materials
305
306
Appendix E. Special Notices

This publication is intended to help programmers and project leaders who will work with VisualAge Generator V4 to develop new business application systems. The information in this publication is not intended as the specification of any programming interfaces that are provided by VisualAge Generator, VisualAge for Java, or VisualAge for Smalltalk. See the PUBLICATIONS section of the IBM Programming Announcement for VisualAge Generator, VisualAge for Java, and VisualAge for Smalltalk for more information about what publications are considered to be product documentation. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, North Castle Drive, Armok, NY 10504-1785. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The information about non-IBM ("vendor") products in this manual has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate
307
them into the customer's operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment. This document contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples contain the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. Reference to PTF numbers that have not been released through the normal distribution process does not imply general availability. The purpose of including these reference numbers is to alert IBM customers to specific information relative to the implementation of the PTF when it becomes available to each customer according to the normal IBM PTF distribution process. The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:
IBM AS/400 DB2 MQ Netfinity OS/390 S/390 System/390 WebSphere AIX CICS IMS MQSeries OS/2 RS/6000 SP VisualAge
The following terms are trademarks of other companies: C-bus is a trademark of Corollary, Inc. in the United States and/or other countries.
308
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries. PC Direct is a trademark of Ziff Communications Company in the United States and/or other countries and is used by IBM Corporation under license. ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and/or other countries licensed exclusively through X/Open Company Limited. SET and the SET logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.
Appendix E. Special Notices
309
310
Appendix F. Related Publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
F.1 International Technical Support Organization Publications

For information on ordering these ITSO publications see How to Get ITSO Redbooks on page 313. Programming with VisualAge for Java, SG24-5264 VisualAge Generator Templates - Creating a Well-Tailored Solution , SG24-5263 VisualAge for Java Enterprise Version 2 Team Support, SG24-5245 VisualAge Generator Version 3.1 System Development Guide, SG24-4230
F.2 Redbooks on CD-ROMs

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs offered, updates and formats.
CD-ROM Title
System/390 Redbooks Collection Networking and Systems Management Redbooks Collection Transaction Processing and Data Management Redbooks Collection Lotus Redbooks Collection Tivoli Redbooks Collection AS/400 Redbooks Collection Netfinity Hardware and Software Redbooks Collection RS/6000 Redbooks Collection (BkMgr) RS/6000 Redbooks Collection (PDF Format) Application Development Redbooks Collection IBM Enterprise Storage and Systems Management Solutions
Collection Kit Number SK2T-2177 SK2T-6022 SK2T-8038 SK2T-8039 SK2T-8044 SK2T-2849 SK2T-8046 SK2T-8040 SK2T-8043 SK2T-8037 SK3T-3694
311
F.3 Other Publications

These publications are also relevant as further information sources: VisualAge Generator Installation Guide Version 4.0, GH23-0257 VisualAge Generator Getting Started Version 4.0, GH23-0258 Introducing VisualAge Generator Templates Version 4.0 , GH23-0272 VisualAge Generator Templates Users Guide - Standard Functions Version 4.0, SH23-0269 VisualAge Generator Templates on Java - Reference Guide Version 4.0 , SH23-0271 VisualAge Generator Templates on Smalltalk - Reference Guide Version 4.0, SH23-0276 VisualAge Generator Server Guide for OS/2, Windows NT, AIX, HP-UX, and Sun Solaris Version 4.0 , SH23-0266 VisualAge Generator Server Guide for MVS, VSE, and VM Version 4.0 , SH23-0256 Running VisualGen Applications on OS/400, SH23-6549-01 VisualAge Generator Design Guide Version 4.0, SH23-0264 VisualAge Generator Client/Server Communications Guide Version 4.0, SH23-0261 VisualAge Generator Users Guide Version 4.0, SH23-0268 VisualAge Generator Programmers Reference Version 4.0, SH23-0262 VisualAge Generator Generation Guide Version 4.0, SH23-0263 VisualAge Generator Migration Guide Version 4.0, SH23-0267 VisualAge Generator External Source Format Reference Version 4.0 , SH23-0265 VisualAge Generator Messages and Codes Reference Version 4.0 , GH23-0260
312
How to Get ITSO Redbooks

This section explains how both customers and IBM employees can find out about ITSO redbooks, redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided. Redbooks Web Site http://www.redbooks.ibm.com/ Search for, view, download, or order hardcopy/CD-ROM redbooks from the redbooks Web site. Also read redpieces and download additional materials (code samples or diskette/CD-ROM images) from this redbooks site. Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few chapters will be published this way. The intent is to get the information out much quicker than the formal publishing process allows. E-mail Orders Send orders by e-mail including information from the redbooks fax order form to: In United States Outside North America Telephone Orders United States (toll free) Canada (toll free) Outside North America 1-800-879-2755 1-800-IBM-4YOU Country coordinator phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl/
e-mail address usib6fpl@ibmmail.com Contact information is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl/
Fax Orders United States (toll free) Canada Outside North America 1-800-445-9269 1-403-267-4455 Fax phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl/
This information was current at the time of publication, but is continually subject to change. The latest information may be found at the redbooks Web site.
IBM Intranet for Employees

IBM employees may register for information on workshops, residencies, and redbooks by accessing the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical professionals; click the Additional Materials button. Employees may access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.
313
IBM Redbook Fax Order Form

Please send me the following: Title Order Number Quantity
First name Company Address City Telephone number Invoice to customer number Credit card number
Last name
Postal code Telefax number
Country VAT number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment.
314
List of Abbreviations
IBM ITSO MSL CICS ESF ECI FFS EJB PLP JSP UI Record UI Type
International Business Machines Corporation International Technical Support Organization Member Specification Library Customer Information Control System External Source Format External Call Interface Free Form Surface Enterprise Java Bean Project List Part Java Server Page User Interface Record User Interface Type
315
316
Index Symbols
/PACKAGENAME 31 /PROJECT 29 scratch edition 220 subapplication 195, 209, 213 version 196, 217, 218 concurrent 234 configuration management 104 configuration map 195, 209, 214 manager 197 manager 226 connections to VisualAge Generator parts 25 VisualAge Generator part attributes 27 containers 196 CONVERSE model 77 CustomerDetailApplication 189 CustomerDetailPanelResource 183 CustomerListApplet 187 CustomerListApplication 188 CustomerListPanel 181, 184 CustomerListPanelResource 181
Numerics
4GL syntax changes 41
A
administrator 108 definition 98 aliasing 19 application 195, 209, 213 manager 197 manager 227 automatic naming 101
C
change control 225 change management 106 class 96, 195, 209, 210 developer 108, 197, 228 owner 108, 117, 197, 228 ownership 107 release 105 class management rules 15, 19 VisualAge for Java 114 VisualAge for Smalltalk 114 CLASSPATH 264 communication session 24 components 195 application 195, 209, 213 class 195, 209, 210 configuration map 195, 209, 214 edition 196, 217 method 195, 209, 212 ownership 197, 225 application manager 197, 227 class developer 197, 228 class owner 197, 228 configuration map manager 197, 226 release 196, 221
D
Developer for Smalltalk development process 231 implementation issues 232 Developer on Java project list part defining system structure 123 team environment functional organization 113 quick start 113 VAGen Parts Browser 114 Developer on Smalltalk 4GL parts 211 feature 202 development split stream 99 development process concurrent 234 Developer for Smalltalk 231 implementation issues 232 serial 234, 247 VisualAge for Smalltalk 231
edition 100, 196, 217
317
open edition 101 scratch edition 103 EMSRV 200 export 201 TCP/IP 203 Enterprise Java Bean overview 9 ESF in workspace 16 export 201, 281 EZE statement syntax changes 41 EZESCRPT 43
F
feature VAGen Parts Browser 14 VisualAge for Java 13 form 70 free form surface VisualAge Generator parts 21 communication session 24 connections 25, 27 functions 24 programs 24 records 22 tables 22 functions arguments 37 description 35 examples 39 loose typing 40 overview 5 reuse 35 syntax changes 41 usage 35
classes CustomerDetailApplication 189 CustomerDetailPanelResource 183 CustomerListApplet 187 CustomerListApplication 188 CustomerListPanel 181, 184 CustomerListPanelResource 181 IsaActionEventHandler 175 IsaComboBox 176 IsaErrorRoutine 175 IsaGroupBox 177 IsaLogic 176 IsaTable 178 IsaTextField 179 JComboBox 176 JPanel 177 JScrollPane 178 JTable 178 JTextField 179 component architecture 168 implementation 167 implementation global reusable components 174 Java applet 187 Java application 188, 189 system reusable components 180 introduction 167 system specifications 170 global reusable components 170 Java applet 172 Java application 172 system reusable components 171
H
hidden 70 HTML UI record mapping 71 UI record representation 72
G
generation 4GL parts 29 Java client 30 of Java 30 options /PACKAGENAME 31 /PROJECT 29 overview 29 VisualAge Generator Templates 53 Web Transaction 80 GUI development
I
image 194, 202 unload 204 image component automated packaging 10 overview 9 import 292 input 69
318
input/output 69 interoperability feature 13 free form surface 21 communication session 24 connections 25, 27 function parts 24 parts palette 21 program parts 24 record parts 22 table parts 22 menu options 14 palette 14 part aliasing 19 parts as methods 17 VAGen Parts Browser 14 VisualAge for Java and VisualAge Generator 4, 20 IsaActionEventHandler 175 IsaComboBox 176 IsaErrorRoutine 175 IsaGroupBox 177 IsaLogic 176 IsaTable 178 IsaTextField 179
J
JAR 264 Java classes CustomerDetailApplication 189 CustomerDetailPanelResource 183 CustomerListApplet 187 CustomerListApplication 188 CustomerListPanel 181, 184 CustomerListPanelResource 181 IsaActionEventHandler 175 IsaComboBox 176 IsaErrorRoutine 175 IsaGroupBox 177 IsaLogic 176 IsaTable 178 IsaTextField 179 JComboBox 176 JPanel 177 JScrollPane 178 JTable 178 JTextField 179
GUI component architecture 168 implementation 167 development 167 implementation global reusable components Java applet 187 Java application 188, 189 system reusable components system specifications 170 global reusable components Java applet 172 Java application 172 system reusable components interoperability 4, 20 Java applet implementation 187 specification 172 Java application implementation 188, 189 specification 172 Java client 30 JComboBox 176 JDK 261 JPanel 177 JScrollPane 178 JTable 178 JTextField 179
174
180 170
171
L
Library Supervisor 201 load 194 loose typing 40
M
method 96, 195, 209, 212 release 105
N
none 69
O
object scripting data exchange 44 description 42 event synchronization 49
319
examples 47 EZESCRPT 43 implementation 43 introduction 42 overview 6 reuse 48 wizards 45 open edition 100 options /PACKAGENAME 31 /PROJECT 29 organization projects 261 output 69 owner package group 99 ownership 93, 197, 225 application manager 197, 227 class developer 197, 228 class owner 197, 228 configuration map manager 197, 226
project list part defining system structure 123
R
release 196, 221 program elements 104 repository 91, 98 description 15 resource files managing 266 reusable components global implementation 174 specification 170 system implementation 180 specification 171 reuse functions 35 object scripts 48 runtime Web Transaction 82, 85
P
package 96, 115 baseline 274 description 15 organization 261 owner 108, 110 release 106 package group 99 parts palette VisualAge Generator parts 21 program elements 95 history 103 ownership 107 relationships 96 release 104 version 100 programlink 69 project 95, 117 defining system structure 119 delete 111 delivery 281 description 15 loading rules 118 organization 261 owner 108, 110 version 287
S
scratch edition 100, 103, 220 serial 234, 247 Smalltalk image component 9 subapplication 195, 209, 213 submit 69 submitbypass 69 SUN Solaris 7 system elements 95, 98
T
TCP/IP 92, 203 team roles 108 testing HTML generation 68 programs 28 Web Transaction 71 type 96
U
UI record attributes 69 data item attributes 69
320
definition 68 HTML generation 68 HTML representation 71, 72 UI types 69 unload 204 user 98 attributes 99 package group owner 99 user definition 99 user interface type description 69 form 70 hidden 70 input 69 input/output 69 none 69 output 69 programlink 69 submit 69 submitbypass 69
V
VAGen Parts Browser 114 version 196, 217, 218 automatic naming 101 control 100 management 100 proposed naming 102 VisualAge for Java class management 114 class management rules 15, 19 CLASSPATH 264 import 285 package 15 project 15 repository 15 team environment administrator 98, 108 purge 289 applet code base 264 authority 117 automatic naming 101 baseline 272, 281 rolling 276, 278 standard 276 change reconciliation 276
change management 106 class 96 add from repository 301 create 299 developer 108 owner 108, 117 work pattern 272 ownership 107 reconciliation 275 release 105, 299 scratch edition 300 state transitions 298 version 299 class management 114, 115 class management rules 15, 19 CLASSPATH 264 comparison with Smalltalk 113 configuration management 104 containers 115 management 117, 118 defining system structure 119 Developer on Java functional organization 113 quick start 113 development patterns 269 split stream 99, 279 development pattern basic 269 edition 100 open edition 101 scratch edition 103 export 281 import 285 introduction 91 lead developer 271 management query 260, 262 workspace 259 management considerations 114 managing page 259 merge 275 method 96 release 105 open edition 100 overview 91 owner package group 99 ownership 93
321
package 15 , 96, 115 add from repository 297 create 292 delete 296 import 292 management 267 open edition 291 owner 108, 110 release 106, 293 scratch edition 295 state transitions 290 version 294 package group 99 process team development 269 program elements 95 history 103 managing 259 ownership 107 relationships 96 release 104 state transition 283 version 100 project 15, 117, 118 add from repository 286 baseline 281 delete 111 delivery 281 import 285 open edition 284 organization 261 owner 108, 110 purge 289 resources 264 scratch edition 287 state transition 283 project list part 123 reconciliation 275 release program elements 104 repository 15, 91, 98 explorer 260 resources 259 files 264, 266 project 264 shared directory 264 scratch edition 100, 103, 287, 295 split stream development 279 state transitions 283
storing ESF 16 system elements 95, 98 team development process 269 team roles 108 type 96 user 98 attributes 99 package group owner 99 user definition 99 version control 100 management 100 proposed naming 102 VisualAge Generator part organization 15 workspace 15, 91 delete 111 management 259 managing page 259 VisualAge Generator communication session 24 connections 25, 27 feature 13 free form surface 21 function parts 24 interoperability 4, 20 part aliasing 19 parts as methods 17 parts palette 21 program parts 24 record parts 22 table parts 22 VAGen Parts Browser 14 workspace 15 VisualAge for Smalltalk class management 114 components organization 252 development process concurrent 234 organization 252 serial 234, 247 team environment 4GL parts 211 application 209, 213 architecture 199 change control 225 class 209, 210 class management 114
322
comparison with Java 113 components 195, 209 application 195 class 195 configuration map 195 edition 196, 217 method 195 ownership 197, 225 application manager 197, 227 class developer 197, 228 class owner 197, 228 configuration map manager 197, 226 release 196, 221 scratch edition 220 subapplication 195 version 196, 217, 218 concepts 193 configuration map 209, 214 containers 115, 196 development process 231 EMSRV 200 export 201 image 194, 202 library interactions 203 implementation issues 232 introduction 193 library 194, 200 image interactions 203 Library Supervisor 201 load 194 manager library 200 manager.dat 200 method 209, 212 subapplication 209, 213 unload 204 workstation 200 VisualAge Generator communication session 24 connections 25, 27 enhancements functions 35 object scripting 42 overview 35 VisualAge Generator Templates 51 WebSphere RAD 60 feature 13 free form surface 21 function parts 24
generation 4GL parts 29 Java client 30 of Java 30 overview 29 interoperability 4, 20 part aliasing 19 parts as methods 17 introduction to V4 Enterprise Java Bean 9 functions 5 image component 9 object scripting 6 SUN Solaris 7 VisualAge for Java interoperability 4, 20 VisualAge Generator Templates 7 WebSphere RAD 8 overview of V4 3 part aliasing 19 parts as methods 17 parts on free form surface 21 communication session 24 connections 25, 27 functions 24 programs 24 records 22 tables 22 parts palette 21 program definition 28 generation 29 testing 28 program parts 24 record parts 22 syntax changes 41 table parts 22 team environment part organization 15 storing ESF 16 VAGen Parts Browser 14 VisualAge for Java 4GL part generation 29 feature 13 Java client generation 30 VAGen Parts Browser 14 VisualAge Generator Templates architecture 52 description 51 generation 53
323
generation parameters 55, 57 introduction 51 V4 enhancements 7
W
Web Transaction development 67 generation 80 implementation 80 program state 76 runtime configuration 85 runtime processing 82 saving state 76 system structure CONVERSE model 77 options 75 XFER , UIRec 79 XFER Pgm WS, UIRec 78 testing 71 transfer options delayed transfer 75 direct transfer 75 form/link transfer 75 UI record 68 WebSphere RAD comparison with native Java 60 description 60 overview 8 Web Transaction approach 62 generation 80 implementation 80 program development 67 program state 76 runtime configuration 85 runtime processing 82 saving state 76 system structure 75 wizards object scripting 45 workspace 91 delete 111 description 15 storing ESF 16
X
XFER , UIRec 79 XFER Pgm WS, UIRec 78
324
ITSO Redbook Evaluation

VisualAge Generator Version 4 System Development Guide SG24-5467-00 Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this questionnaire and return it using one of the following methods: Use the online evaluation form found at http://www.redbooks.ibm.com Fax this form to: USA International Access Code + 1 914 432 8264 Send your comments in an Internet note to redbook@us.ibm.com Which of the following best describes you? _ Customer _ Business Partner _ Solution Developer _ None of the above
_ IBM employee
Please rate your overall satisfaction with this book using the scale: (1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction __________
Please answer the following questions:

Was this redbook published in time for your needs? If no, please explain: Yes___ No___
What other redbooks would you like to see published?
Comments/Suggestions:
(THANK YOU FOR YOUR FEEDBACK!)
325
VisualAge Generator Version 4 System Development Guide
SG24-5467-00
SG24-5467-00 Printed in the U.S.A.

Apostila Vsual Age English

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila Vsual Age English

Transféré par

Droits d'auteur :

Formats disponibles

VisualAge Generator Version 4 System Development Guide

Pat McCarthy, Guillaume Hetu-Dandurand, Stefano Sergi

International Technical Support Organization www.redbooks.ibm.com

International Technical Support Organization

VisualAge Generator Version 4 System Development Guide October 1999

Copyright International Business Machines Corporation 1999. All rights reserved

Copyright IBM Corp. 1999

Definition . ......... ......... ......... .........

VisualAge Generator Version 4

VisualAge Generator Version 4

Release Management . ................... ................... ................... ................... . . . . .. .. .. ..

. 252 . 252 . 252 . 253 . 254 . 255 . 255

VisualAge Generator Version 4

VisualAge Generator Version 4

Copyright IBM Corp. 1999

VisualAge Generator Version 4

VisualAge Generator Version 4

Copyright IBM Corp. 1999

VisualAge Generator Version 4

Copyright IBM Corp. 1999

The Team That Wrote This Redbook

VisualAge Generator Version 4

VisualAge Generator Version 4

Copyright IBM Corp. 1999

VisualAge Generator Version 4

Chapter 1. VisualAge Generator V4 Overview

Workstation VisualAge Smalltalk VisualAge Generator Developer on Smalltalk Image

New Java Development Platform

Workstation VisualAge for Java VisualAge Generator Developer on Java Workspace

Figure 1. VisualAge Generator V4 Overview

Copyright IBM Corp. 1999

1.1 VisualAge for Java Interoperability

Workstation VisualAge for Java VisualAge Generator Developer on Java Workspace

New Java Development Platform

Figure 2. Developer on Java Overview

VisualAge Generator Version 4

1.2 Functional Enhancements to VisualAge Generator

Chapter 1. VisualAge Generator V4 Overview

See 3.1, Function Logic Parts on page 35 for additional information.

1.2.2 Object Scripting

VisualAge Generator Version 4

1.2.3 VisualAge Generator Templates Enhancements

1.2.4 SUN Solaris Runtime Support

1.3 Web-Based and e-business Enhancements

Chapter 1. VisualAge Generator V4 Overview

1.3.1 Development Support for WebSphere Application Server

VisualAge Generator Version 4

1.3.2 Enterprise Java Bean Support

1.4 VisualAge Generator Automated IC Packaging

Chapter 1. VisualAge Generator V4 Overview

1.4.2 GUI Packaging Options

1.4.3 Automated IC Packaging

VisualAge Generator Version 4

Chapter 1. VisualAge Generator V4 Overview

VisualAge Generator Version 4

Chapter 2. Java-Based Version of VisualAge Generator

2.1 Workbench Integration

Copyright IBM Corp. 1999

Workstation VisualAge for Java VisualAge Generator

VisualAge Generator (Java-based) Developer Workstations

Workstation VisualAge for Java VisualAge Generator

ENVY Class Management:

Local Area Network