In any development project, management tasks can be split roughly into two categories:
n Project management, which includes allocating the necessary equipment, budget, and person-hours of work necessary to complete the development of the application.
n Software configuration management, which includes assigning modules to developers, determining dependencies among modules, maintaining the code under development, and version control.
Project Builder, a component of both Forms Developer and Reports Developer, enables you to simplify your software configuration management tasks so you and your team can focus on your primary objectives: designing, coding, and testing applications.
About Project Builder
To help simplify your software management tasks, Project Builder provides the means for you to:
n Associate modules with an application or component of an application.
n Automate actions based on file types.
n Create dependencies between modules and indicate how changes cascade; in other words, show which modules need to be recompiled based on changes to other modules.
n Assign default connection strings to modules.
n Designate which modules are to be included in the final install set.
n Share projects and subprojects among team members and port them to different environments.
n Invoke other tools from the Project Builder user interface.
These features are described in detail in Section 1.1.3, "Exploring Project Builder benefits". If you’re unfamiliar with Project Builder terminology, however, it’s a good idea to read through Section 1.1.2.1, "Understanding Project Builder terminology" before proceeding. This section defines some basic terms which provide the context for a discussion of Project Builder’s features.
Understanding Project Builder terminology
Project Builder is based upon the concepts of projects and subprojects:
n Projects are collections of pointers to the modules and files that are part of your application.
n Subprojects are projects contained within other projects, providing a finer level of organizational granularity. Often the organization of files into subprojects mirrors the organization of files into subdirectories, but this is not a requirement.
In addition to projects and subprojects, these terms are also central to a solid understanding of Project Builder:
n Types. A type is the basis of every item, and controls the actions that are available in Project Builder. Project Builder types recognize their associated file types primarily by default extension; for example, .TXT for text files. Project Builder predefines types for many commonly used files, such as forms documents (FMB), text files, and C source files. You can also use the Type Wizard to define types for other applications.
n Project items. The components that make up a project are known as items. An item is simply a description of a file that is part of a project. Each item is fully described in the associated Property Palette, which lists the item’s type, location in the file system, size, and when it was last modified. The actions and macros (see below) for the item are also defined.
It is important to remember that an item is not the file itself; rather, it is a description of the file. So, when you delete an item from a project, you are simply telling Project Builder that the file is no longer part of the project. The file itself is not deleted.
n Types. A type is the basis of every item, and controls the actions that are available in Project Builder. Project Builder types recognize their associated file types primarily by default extension; for example, .TXT for text files. Project Builder predefines types for many commonly used files, such as forms documents (FMB), text files, and C source files. You can also use the Type Wizard to define types for other applications.
n Project items. The components that make up a project are known as items. An item is simply a description of a file that is part of a project. Each item is fully described in the associated Property Palette, which lists the item’s type, location in the file system, size, and when it was last modified. The actions and macros (see below) for the item are also defined.
It is important to remember that an item is not the file itself; rather, it is a description of the file. So, when you delete an item from a project, you are simply telling Project Builder that the file is no longer part of the project. The file itself is not deleted.
n Actions. Actions are command strings that apply to files of a given type; for example, the Edit action for a text item may be the command string that invokes Notepad or WordPad.
n Macros. Macros are variables you can use to modify actions. A macro may be either a constant or a simple expression (which, in turn, may contain other constants and/or expressions). For example, Project Builder inserts all the information you’ve specified for connecting to a database into the ORACONNECT macro, which is included in all commands that might require you to connect. The information in the macro is then inserted into the action so you can log on automatically.
Just as you might use environment variable in scripts or batch files to conveniently modify a script’s actions without editing the script itself, so you can use macros to customize actions without having to edit the action themselves. For example, you might define a macro to determine whether to compile your application in Debug mode or Optimized mode. In preparation for building the deployment version of the application,
Just as you might use environment variable in scripts or batch files to conveniently modify a script’s actions without editing the script itself, so you can use macros to customize actions without having to edit the action themselves. For example, you might define a macro to determine whether to compile your application in Debug mode or Optimized mode. In preparation for building the deployment version of the application,
n Global registry. The Global Registry contains the pre-defined Project Builder types.
n User registry. Each user has a user registry in which to define new types, redefine existing types, and modify or create actions or macros.
n Project registry file. The project registry file contains information necessary to track a project, including pointers to modules contained within the project, default connection strings, and a pointer to the "home" directory for the project.
The Project Builder interface provides three tools for manipulating the items that make up a project:
n The Project Navigator furnishes a familiar "navigator" or "explorer" style interface with which you can view the modules in your application. In addition, you can use Project Builder’s filtering capabilities to display only the modules you want to see. You can
also launch editing tools directly from the Project Navigator.
n The Property Palette enables you to examine and modify the properties of selected items.
n The Launcher, a secondary toolbar, provides another means of accessing development tools. You can even add buttons to the Launcher and associate them with your favorite third-party tools.
How Project Builder affects existing development roles
Certain roles must be filled to keep the application development effort going smoothly. Some, such as project manager, development manager, and team leader, are common roles
within development groups and require no definition. However, with Project Builder one
new role exists—that of project administrator.
A project administrator is charged with creating projects and making them available to developers. The project administrator maintains the Global Registry and modifies it as necessary, exporting the changes to the developers on the team. He or she may also export the project information to different environments, such as test environments, or other platforms for cross-platform development.
The work the project administrator does when managing projects may affect the roles of the following team members:
new role exists—that of project administrator.
A project administrator is charged with creating projects and making them available to developers. The project administrator maintains the Global Registry and modifies it as necessary, exporting the changes to the developers on the team. He or she may also export the project information to different environments, such as test environments, or other platforms for cross-platform development.
The work the project administrator does when managing projects may affect the roles of the following team members:
n Developers
n Source control administrator
n Testers (QA)
n Releaser
Of course, the precise duties of each team member vary from development group to development group. A team member may also take on more than one role; for example, a team leader may also be a project administrator, or a developer may be in charge of source control.
Exploring Project Builder benefits
Now that you are familiar with basic Project Builder terminology ( "Understanding Project Builder terminology"), let’s examine the benefits Project Builder provides.
Associating modules with an application
You can associate all of the modules in an application with the application itself simply by adding the modules to the same project. This allows you to track a large application as a single entity, determine the dependencies between modules, and so on.
Automating actions based on file types
Project Builder ships with an extensive list of types, to which are assigned default actions (such as Open, Edit, or Print). When you select a module, then click the right mouse button, a pop-up menu displays the actions associated with that type. By default, the actions included in a type definition apply to all modules of that type in a project. You can also modify and add to these actions.
Actions are simply command strings. One benefit to defining actions with the actual command strings (besides simplicity, of course) is that an action can be associated conceptually with several different types. For example, editing a Word document requires a different tool than editing a text document, yet conceptually the two edits are very similar. Project Builder can associate an Edit command with many different types, using a different command string for each. In this way, a single command executes an appropriate action no matter what type of module you’re working with.
Actions are simply command strings. One benefit to defining actions with the actual command strings (besides simplicity, of course) is that an action can be associated conceptually with several different types. For example, editing a Word document requires a different tool than editing a text document, yet conceptually the two edits are very similar. Project Builder can associate an Edit command with many different types, using a different command string for each. In this way, a single command executes an appropriate action no matter what type of module you’re working with.
Creating dependencies between modules
Knowing which modules depend on which other modules is necessary to determine when modules need to be recompiled as a result of a change. It’s also the key to managing the impact of changes; for example, if a library changes, which forms are now out-of-date?
Project Builder includes the dependencies for module types in their type definitions. Thus, it can recognize dependencies between existing modules in a project. Since it can also track modifications to modules, it automatically recompiles changed modules and the modules dependent on them.
In fact, Project Builder can recognize dependencies that do not yet exist within the project and create markers for them. These markers are called implied items. For example, suppose your project contains an .FMB file, defined by the Project Builder type "Form Builder document." The "Form Builder executable," or .FMX file, may not exist—you may not have generated it yet. But Project Builder knows the existence of this .FMX file is implied by the existence of the .FMB file, and creates an implied item to mark it.
To determine the existence of an implied item, Project Builder correlates the value of the property Deliverable Type for each defined type with the input items, or source, required for the Build From <type> action for each defined type. In our example above, the Deliverable Type property for the "Form Builder document" type is defined as "Form Builder executable," or .FMX.The Build From <type> action defined for a Form Builder executable is "Build From FMB". This means .FMBfiles are the input items for creating
Project Builder includes the dependencies for module types in their type definitions. Thus, it can recognize dependencies between existing modules in a project. Since it can also track modifications to modules, it automatically recompiles changed modules and the modules dependent on them.
In fact, Project Builder can recognize dependencies that do not yet exist within the project and create markers for them. These markers are called implied items. For example, suppose your project contains an .FMB file, defined by the Project Builder type "Form Builder document." The "Form Builder executable," or .FMX file, may not exist—you may not have generated it yet. But Project Builder knows the existence of this .FMX file is implied by the existence of the .FMB file, and creates an implied item to mark it.
To determine the existence of an implied item, Project Builder correlates the value of the property Deliverable Type for each defined type with the input items, or source, required for the Build From <type> action for each defined type. In our example above, the Deliverable Type property for the "Form Builder document" type is defined as "Form Builder executable," or .FMX.The Build From <type> action defined for a Form Builder executable is "Build From FMB". This means .FMBfiles are the input items for creating
.FMX files, and, conversely, .FMX files are targets for .FMB source.
The chain of implied items can consist of multiple files. For example, suppose you add a C source file to a library file. In this case, Project Builder adds modules of whatever other types are necessary to get a complete path of Build From <type>actions from one file type to the other (like an object file).
While Project Builder detects dependencies only between compilable modules and their resultant executables, you can set dependencies manually by adding modules to a project below the item dependent on them. For example, if an .FMB is dependent on a PL/SQL library, you can add the .PLL to the project below the .FMB, and Project Builder will recognize the dependency.
While Project Builder detects dependencies only between compilable modules and their resultant executables, you can set dependencies manually by adding modules to a project below the item dependent on them. For example, if an .FMB is dependent on a PL/SQL library, you can add the .PLL to the project below the .FMB, and Project Builder will recognize the dependency.
Assigning default connection strings to modules
With Project Builder, you can define all of your most-used connection strings and store their definitions under the Connections node. You can then assign a connection to a module by dragging the connection from the Connections node and dropping it on the module. When you need to edit that module—for instance, a form—you can select the form in the Project Navigator and choose Edit from the pop-up menu. Project Builder automatically opens Form Builder and connects to your database for you.
Designating which modules are to be included in the final install set
Project Builder makes it easy to determine and track the modules that will be included in your final install package (for example, .EXE files, .DLL files, and .HLP files).To earmark a file for delivery, set the Deliver File property to Yes. When you’re ready to create an install package, you can use the Delivery Wizard to package all modules for which the Deliver File property is set to Yes into a single unit.
Note: You can set the Deliver File property for a type or for individual project items.
Sharing and porting project and subproject registry files
Project Builder enables you to export the information about a project to other team members and to other platforms. Information about types, actions, macros, and project registry files—including all the customizations you’ve made—can be written to a text-based export
file which you can then import to other environments and other platforms. This enables cross-platform development and testing.
file which you can then import to other environments and other platforms. This enables cross-platform development and testing.
Accessing other product components and third party tools
You can access other tools from the Project Builder user interface through several means:
n Actions, which you access by selecting a module in the Project Navigator and clicking the right mouse button. A pop-up menu displays all the actions associated with the selected item; the actions listed invoke whatever tools are specified in the command strings. You can also double-click an item in the Project Navigator to invoke its default action.
n The Build, Deliver, and source control actions, which launch whatever tools are associated with them.
n The Launcher toolbar, which launches many components such as Form Builder, Report Builder, and Graphics Builder. You can also add your own buttons to the Launcher toolbar and associate them with your favorite third-party tools.
Using source control packages
Both Forms Developer and Reports Developer provide interfaces to these source control packages:
n PVCS from Intersolv
n Clearcase from PureAtria
n Versions, the source control component of StarTeam, from StarBase
You can also use other source control tools by modifying the source control actions provided with Project Builder to point to them.
Since a variety of source control packages are available and can be used with Forms Developer and Reports Developer, specific instructions for source-controlling your projects are beyond the scope of this chapter.However, general guidelines will be provided where applicable.
Since a variety of source control packages are available and can be used with Forms Developer and Reports Developer, specific instructions for source-controlling your projects are beyond the scope of this chapter.However, general guidelines will be provided where applicable.
No comments:
Post a Comment