100% Generation: No More Excuses!

Transcription

1 100% Generation: No More Excuses! Steven M. Davelaar Custom Development Center of Excellence, Oracle Corporation Introduction Today, 100% generation with the Forms Generator is only achievable for real generation freaks, who are prepared to invest whatever time required to drive the Generator to its limits, applying all possible techniques and tricks to achieve the holy goal. The upcoming Designer/2000 release 2.0 will provide us with a number of long-waited features in the area of forms generation. This release promises to enable the main stream of Designer/2000 users to achieve generation rates of (close to) 100%. This paper addresses the issue of achieving 100% generation from two different angles: Organizational/mental perspective: what nontechnical conditions must be met to achieve high generation rates? Technical perspective: what does Designer/2000 release 2.0 offer? Although equally important, the focus of this paper will be more on the first question, the one that is often underestimated, or worse, completely ignored. However, answers to both questions are of limited value as long as we do not have a clear understanding of what 100% generation is (at least in the eyes of the author), and what the benefits are of this approach to system development. 100% Generation, What Is It? This paper assumes the following working definition of 100% generation: A form is 100% generated if after a change in either: template form, preference setting, table or column definition, module data usage, the form can be generated again from Designer/2000 and runs directly, without any changes required in the layout or generated source code. This does not mean that you do not hand code anymore! Complex business rules and navigational logic will always requires coding of (PL/SQL) program units. The big difference with non-generated forms is that the GUI event points that invoke the manually coded chunks of functionality are generated into the form. Some people react disappointed to this definition, as they were probably dreaming of the end of the programming days. Of course, declarative definitions of functionality are preferred above procedural coding. However, the benefits of 100% generation still apply with the above definition as the following section explains. 100% Generation, Why? This indeed is a very important question to raise, as the answer will largely determine the

2 costs you are willing to make to achieve this goal. Based on many years of field experience, I feel there are four main advantages of 100% generated systems: Higher flexibility and adaptability of the system Higher maintainability of the system: single source of information for all application components (client and server) current application models facilitate accurate and complete impact analysis a detailed blueprint of the application is built as the application is built. Higher quality of the system: enforced standards and layout across all generated forms and reports common item definition across forms. high quality code (through module re-use, optimized SQL, commonality) More robust system More robust means that the product is less likely to break. Similar to this notion is the converse - if the product does break, it is easier to fix. Templates, reusable module components, common procedures, and user preferences all combine to enforce consistency across all generated forms and expedite maintenance. Define it once and leverage it many times. From these benefits, it is very clear that the cost vs. benefit of 100% generation is one that must be looked at over its entire payback period, not just in the first incarnation. In the first-release of a system, using a rigorous model-based approach to engineering systems may require additional design time. However, the payback is in the medium to long-term. The iterative phases of system development, and especially its maintenance and enhancement phases are when payback for generation occurs. The declarative approach to design and generation, coupled with the use of templates and userpreferences expedites the iterative nature of today's' system development. From an enhancement and maintenance perspective, the fact that the application code is based on business models, makes for a significantly simpler and better managed evolution of the system. In other words, time and money is saved over an application s complete life-cycle for iterative development, maintenance and enhancement Planning a '100% Generation' Project Although the benefits discussed in the previous section are impressive, the longer-term nature of these benefits reveals at the same time why we fail so often in applying a (close to) 100% generation approach. The big pitfall here is the word 'Generation'. Most people regard this more or less as the opposite of 'Programming'. Of course, to a certain extent this is true, however, code generation still involves a lot of what I would call "Declarative Programming", and even procedural programming if complex business rule are involved. What does this mean: Generation usually does not create applications faster. Depending on the skills, experience and attitude of the developer (see next section), initial creation of the system can easily take longer than hand coding of the same system. Only very

3 experienced Designer/2000 users will show an increase in productivity during initial system development. This means that one of the most important prerequisites for achieving 100% generation is in the very beginning of the project: a reasonable project planning! If you have relatively inexperienced developers on your project, do not underestimate the learning time of Designer/2000 and the Forms generator in particular. Fortunately, it looks like Designer/2000 release 2.0 has done a great job in improving the usability of the tool. However, time will tell whether the assumed reduced complexity, and subsequent higher productivity, is really perceived for novice users. If you have no experience in estimating generation projects, a good rule of thumb is to use the same figures as you did for hand coded projects, assuming a good mix of inexperienced and experienced developers. When you work with novice users of Designer/2000, it is strongly recommended to start of with a small pilot project, preferably with one experienced Designer/2000 consultant who can coach your people. Double your hand coding figures for estimating such a pilot project! Although these figures may disappoint you, do not forget that, once the application has been created, ongoing maintenance and enhancement is dramatically improved via model-based design and build. Make sure you clearly communicate these longer-term advantages to the (internal) customer of the system. If you do not succeed in this, you probably will be forced to lower the estimates, as the customer probably will say something like "I thought you said you would simply 100% generate the whole application, why are the figures so high?" Required Skills and Attitude of Developer and Team Leader Provided that the project leader has put together a reasonable project planning, it is up to the developer to really achieve the goal of 100% generation. An obvious prerequisite for this task is that the developer should have working knowledge of the Designer/2000 Generators as well as Developer/2000. A less obvious requirement refers to a 'soft' skill of the developer: he/she should believe in a 100% generation approach, and understand the implications. Let me explain this with an analogy. It is widely accepted that shifting from procedural 3GL programming to event-driven 4GL programming, requires a significant mind shift of the developer. It is my strong believe that shifting from a 4GL hand coding approach, to model-based 4GL generation, requires a mind shift of the same magnitude. The more you are experienced in building Developer/2000 applications manually, the more 'mental barriers' you have to take to be successful in model-based generation with Designer/2000. The possible frustration this implies is best illustrated by the following quote: "I'm getting mad of all these generator preferences, it only takes me 10 minutes in Forms Designer" This, of course, is the great temptation. Therefore, it is often easier for people who are novice to both Designer/2000 and

4 Developer/2000 to learn and understand the Forms Generator, than for experienced Developer/2000 programmers. The latter group will have a tendency to work against the Designer/2000 tool instead of with the tool, at least in the beginning. If this is the situation, your role as team leader / project leader is critical: You should convince the developers of the importance of 100% generation. You should organize sufficient coaching capacity to help the developers in taking the mental and technical barriers. You should not put pressure on making task estimates as this will lead to further frustration. Remember, it is your fault, not the developers fault, that the task estimates are too optimistic (assuming you have read this paper ). Admitted, this attitude may have a bad effect on project progress in the short term, but the payback will be double in the longer-term. Not only will you deliver a system that has the benefits described earlier in this paper, you also end up with a staff of highly motivated, 100% generation believers. This may sound a little bit like a fairy tale, but I can tell you from field experience it is not! Compromising on Functionality? It is often heard that to be able to achieve 100% generation, you must be willing to compromise (considerably) on the functionality requested by the users. This brings me to another skill of the designer/developer, which is particularly important when a user-interactive project approach has been chosen that heavily relies on prototyping sessions (e.g. RAD): The Attitude towards the users who provide the requirements You are working according to the user s requirements and these should, of course, be reflected in the system. However, it is not always in the user s best interest that you implement requirements exactly the way they were expressed during the workshop session or interview without further analysis. In fact, requirements should not be of such detail that they completely prescribe the way you should implement them. This room for creativity on your side makes it challenging to come up with a solution that makes the user happy. But this room also exists on the users side and their creativity is often underestimated. You may have the feeling that you understand the different aspects of the user s requirements but they do not understand your concerns. It is crucial for good team-work between you and the user that you make sure you really DO understand the various reasons why the user wants a particular piece of functionality a certain way. In doing so, you will automatically find out all the pieces of functionality where the how is not so important to them and where you therefore have more room for inventive, easily generatable, design. On the other hand, you will find that there are pieces of functionality that really must work the way they want in order for the system to be a success. This valuable information should not go to waste and can only be the product of an open and constructive atmosphere during prototyping sessions. Modeling requirements together with future end-users is really giving and taking. Giving and taking is really one of the most important aspects of being a system analyst/designer, and should not be underestimated.

5 For the user participants, there is often only one thing that counts: the usability of the final system. Of course, that is a goal you have in common, but at this point you will understand there are other factors that you, as system analyst/designer, should take into account as well. Finally, the end users will benefit most from this attitude; although, in the short-term, not all their wishes may be fulfilled. In summary, generation considerations should always be taken into account but they can never outweigh the usability of the application. 100% Generation: Technical Issues Many courses, books and white papers are available which all discuss technical issues related to 100% generation of Developer/2000 applications. These conference proceedings already contain two other papers discussing this subject. At this point, I will stay with discussing relevant features of Designer/2000 release 2.0. References for more information on achieving 100% generation are included in the last section of this paper. What Does Designer/ Offer? Designer/2000 release 2.0 certainly has a lot to offer. A lot of effort is put in improving the usability and productivity of the tool. This paper does not intend to provide a full overview of release 2.0, it stays with the new features that impact the ability to achieve 100% generation of Developer/2000 applications: Application Logic Unbound Items Layout Generation Summaries and Derivations Navigation Application Logic The most important new feature of Designer/2000 Release 2.0 is the ability to record application logic or 'custom code' within the repository, and have the generators embed that code within the generated applications. This reduces the need for post-generation alterations to generated code and greatly improves the manageability and maintainability of systems developed using Designer/2000. The reverse engineering and design capture capabilities of Designer/2000 have also been extended to provide 100% reverse engineering of application logic as well as 100% generation. The repository will allow the storage and definition of application logic by holding the event model for each target language. For the Oracle Forms Generator this will mean that logic can be defined at form, block and item level for event points such as WHEN- VALIDATE-ITEM and PRE-INSERT. Each event point may have several pieces of code associated with it, some user defined - application logic, and some generated from declarative definitions - generated logic. You will be able to see the code that is to be generated from repository definitions and sequence their own application logic within the generated code chunks as required. If required, it will also be possible to replace generated application logic with the users own. Unbound Items Primary and Secondary Column Usages have been remodelled to allow items to be defined as bound to a column or unbound. A Module

6 Component can consist wholly of unbound items, thus allowing the generation of control blocks. An unbound item can have a domain associated and can be of any display datatype. Action Items The design level model has been extended to allow the definition of buttons - Action Items for a given window. Typically the buttons are used to: Navigate to another window Navigate to another module To initiate a process These action items can be graphically manipulated on the Module Data Diagram thus providing a mechanism for defining the navigation for a transaction independently of the data model for the modules. Layout Generation Although it is today possible to 100% generate an acceptable and aesthetically pleasing layout, it requires in depth knowledge of layout preferences, and foremost a lot of patience. Designer/2000 release 2.0 offers minor improvements in this problem area: Hierarchical Item Groups allow the user to nest item groups which can have different orientations. For example, this facilitates generation of vertically oriented groups, that include descriptor items that must be displayed to the right of the foreign key column. The Module Data Diagram will offer an additional view: The Layout View. This view gives an indication of what the module will look like when it is generated, hopefully decreasing the number of generations required to produce an acceptable layout. Tab Canvasses: Designer/2000 version 1.3 has an implementation of tabbed canvasses which is built using stacked canvasses as the tab pages and a poplist to control which page is visible. Release 2.0 will support the native implementation of true MS Windows 95 tabbed pages of Developer/2000 release 2.0. Prompt as an Item Property: In Developer/2000 release 2.0 the prompt will be a property of the item. Designer/ will support this feature in the Forms Generator. Assuming 100% generation, the main benefit will be the ability to generate multi-lingual applications without using Oracle Translation Manager. Summaries and Derivations The following enhancements are made to Forms generation of summary items and derivation items: They do not need to be displayed They can appear in lookup table usage's It can be the first item in a block Derivation expressions will be allowed to contain global variables, parameters, items on the form, and PL/SQL procedures/ functions The following Summary Types are supported: SUM, COUNT, AVG, MAX, MIN, VARIANCE and STDDEV Summary functions are allowed on derived items The value of a summary item reflects only those records that are actually in the block, even if a restricted query is imposed on the detail block. There will be an option to generate a 'database summary', the value reflecting all database records in a table (or a subset if governed by a WHERE clause)

7 The Generator does not restrict where summary items are displayed. It will display summary items in the block that they are defined in. Navigation The navigation model of the Forms Generator has been improved significantly and is now more in line with the expected behavior of most windows users. Areas the navigation has improved are: Navigation Scope: a preference controls if the generated form should have it's navigation bounded within each window. This causes the application to behave much more like a normal windows application where the cursor only navigates within the window and not between windows. Navigation Style: preferences are provided to set the Navigation Style of an item to either Same record, Change Record or Change Block. The item navigation style can be set differently for single-record and multi-record blocks. Window Management: preferences control if code to close child windows and child opened forms is generated. Mnemonic Access Keys: it will be possible to generate mnemonic access keys (ALT+letter) for buttons. Context Information: To pass context information when navigating to another form, you will be able to use parameters and map these parameters to items in each module. References With Headstart Designer/2000 and CDM Advantage, Oracle Consulting Services offers a complete and integrated toolkit that enables 100% generation of custom development systems using Designer/2000: The following components are included: CDM Method books to choose the optimal development approach using Designer/2000 (Classic, RAD or Lite), providing detailed descriptions of the roles, tasks and deliverables as well as automated support in the form of deliverable templates and template work breakdown structures. CDM Designer/2000 Standards and Guidelines for systems analysis, design and generation provide detailed guidance in how to use Designer/2000 in an optimal way. Headstart Template Package enables 100% generation of CDM GUI standards and guidelines, saving weeks of development time. Headstart Utilities provide automated quality assurance by checking and enforcing the CDM Designer/2000 standards, and automating time-consuming and error-prone tasks. Contact your local Oracle representative for more information or send an to cdminfo@us.oracle.com. or qms@nl.oracle.com Biographical Information Steven M. Davelaar Senior Principal Consultant Quality Management Services Rijnzathe PV de Meern Oracle Netherlands Phone: Fax: sdavelaa@nl.oracle.com