Lotus Notes and Domino ease application development for many organizations. Unfortunately, some organizations lack the management and techniques needed to keep their application development from raging out of control. Evidence of this is readily apparent. For example, some large installations have thousands of Notes databases, but their development teams lack the standards enforced in other application development environments. In addition, the data and efforts of developers are too often duplicated.

The result of this lack of discipline, regardless of the cause, is that the very promise of Notes is negated. Instead of making it easier to organize and share information, it gets harder. Organizations begin to drown in data, information becomes fragmented and harder to find, user frustration rises, applications are abandoned, and development takes more time and money.

Gaining Control

The TeamStudio Design System, from Lotus Premium Business Partner Ives Development, is a suite of interrelated modules that perform functions that enhance the inherent capabilities of the Notes development environment. TeamStudio is based entirely in the Notes client and works with all Notes versions. The TeamStudio modules are TeamStudio Analyzer, TeamStudio CIAO!, TeamStudio Configurator, TeamStudio Delta, and TeamStudio Librarian. Here is a look at some development issues that apply particularly to the Notes environment and how TeamStudio components can help you deal with it.

Team Development

By its very definition, Notes empowers teams to work together. The Notes replication model means that users get the same access and can add data to a database regardless of time or location.

Notes developers, of course, enjoy the same benefits because the database design resides with the Notes data and conforms to the same replication model. The problem is that software development rarely follows this additive transaction model, especially when

an application is in maintenance mode. It often happens that different developers make changes to the same elements at the same time.

Therefore, Notes development teams don’t always know who’s working on a design element at a particular time. In addition, Notes has no inherent mechanism to lock design elements. If two developers working on the same application on the same server make changes to a form, a save conflict results, and the problem is even worse on an application that resides on different servers. If the developers are unaware that they’re working on the same element, it could result in a replication conflict, which can cause problems in the application and can be difficult to resolve. One element may even appear twice in the design with no indication of a conflict. Furthermore, you can’t resolve the conflict by merging changes through the “difference of two documents” feature in Notes.

Non-Notes development environments commonly use source code control (SCC) systems to manage this problem. Some organizations actually try to control their Notes environments with these standard SCC systems, but the results aren’t very satisfactory. TeamStudio CIAO! is an SCC system that allows Notes development teams to work on the same database design at the same time. Because TeamStudio CIAO! is Notes-based, it fully understands the internal structure of a Notes database. TeamStudio CIAO! allows you to lock all database design elements, including forms, views, folders, subforms, navigators, shared fields, and agents. TeamStudio CIAO! also controls access to design elements (meaning that only authorized developers can check elements out), keeps an audit trail of changes made to the elements, and allows you to roll back to previous versions. If someone checks out an element but makes changes that have a bug, you can easily roll back to the version that didn’t have the bug.

Version Control

Keeping abreast of application versions and changes can be challenging for any development team. In well-managed development environments, it’s common to see three distinct environments: the development environment, where you work on the next release of the application; the test environment, where the application design is tested before release; and the production environment, which has the usable version of the application. To make this work well, you must know two key things: which version of the application design is in which environment and that the version of the application in production is the same one developed and tested.

These issues are difficult to answer in Notes development for several reasons. First, there’s no way to reliably “stamp” a database application with a version number. Second, there’s no way to be sure that changes haven’t been made to an application before it went into production. Third, it’s possible to link individual design elements to different templates, with the elements identified only by their names. Fourth, it’s easy to switch off template inheritance for individual design elements by checking the design attribute “Do not allow design refresh/ replace to modify.” All this means that the version of a Notes application in production may vary considerably from the one originally developed and tested.

Also, in a controlled development environment, the goal is to split and manage specific development tasks, such as maintenance, bug repair, and development of new features. Before the next version of an application is released, all development threads must be merged. Consider the development cycle, as illustrated in Figure 1. Version 1.0 of an application is tested and released to users in the production release. However, as soon as the version is released, the development team begins to work on new features. In addition, bugs begin to appear in the application. To fix the bugs without disrupting the first development team, a separate team works on a release called Version 1.1. This makes sure that the production schedule doesn’t fall behind and that bugs get fixed quicker. However, the two versions must be merged before the new production version, called Version 2.0, can be released.

There are two challenges: to make sure that all versions match up and to merge changes between versions. Two TeamStudio products can help in the Notes environment. TeamStudio CIAO!, for example, can be used for version control, keeping copies of all released templates. Better yet, though, you can use TeamStudio Delta to find all the differences between two versions of a database design. TeamStudio Delta allows you to compare two versions of a database design or two versions of the same design element quickly and easily. Once you find the differences between Version 1.0 and Version 1.1, you can quickly merge the versions to make Version 2.0.

Debugging

Testing and debugging present particular challenges for the Notes developer. Although it’s quite easy to build an application with Notes forms and other design elements, it’s not quite so easy to modularize the code and test and debug each module separately. For example, code that runs when you open a Notes form may be associated with many fields or events on the form, making it difficult to isolate and test code fragments. To debug problems with the element, you need to find all references to the element in the application.

TeamStudio Analyzer allows you to do this quickly and efficiently. Analyzer scans a database design and generates a Notes database that displays all elements in the database design. Figure 2 shows the information about a form that the Analyzer module displays. Say you have a field on the form that gets updated with a wrong value every time the form displays. There could be many places in the form definition where the field gets updated, and you need to pinpoint the one supplying the wrong value. TeamStudio Analyzer allows you to identify all references to the field and thereby solve the problem in a matter of minutes.

Code Reuse

As Notes applications become more complex, it makes sense to reuse certain blocks of code. Notes developers have always had the ability to reuse some code, first with the shared form and subsequently with the subform, but both of these were somewhat limited. They had to be used in a single database or had to be copied and pasted from a template to a database.

TeamStudio Librarian truly enables code reuse in Notes applications by allowing you to build and share libraries of design elements. You can browse, categorize, sort, and search the library, and you can preview design elements before copying them into any database design. The library also keeps track of all dependencies for each element (for example, a form with a keyword list field). When you add the element from the library to a database design, TeamStudio Librarian makes sure that all dependencies are present. Without TeamStudio Librarian, you would have to inspect each design element for its dependencies manually.

Code Maintenance

Many Notes applications need continual maintenance. Forms change, functions are added or subtracted, and so on. However, code maintenance can be a time-consuming and laborious task. Take the simple example of changing a field name, a common Notes task. Changing the field name itself is easy, but finding and changing all the references is not. One way to find and change references is to open every single design element and inspect each line of code, looking for all references to the field name.

A quicker method for finding and changing field name references is to search for and replace all field name references automatically. TeamStudio Configurator finds and replaces every reference automatically or lets you step through each match and decide whether to make the change. This feature can save you programming time and ensures that every reference is covered. TeamStudio Configurator brings the simplicity of a standard word processing search-and-replace function to the Notes environment.

No Substitute

No set of tools can substitute for sound application programming techniques, but, without the tools, it becomes that much harder to put these techniques into practice. The Notes development environment has come a long way and allows you to build complex, mission- critical applications. The TeamStudio Design System complements the Notes environment and makes it possible to improve Notes application development.

For more information about TeamStudio, visit the Ives Development Web site at www.teamstudio.com.

Version 1.0 release to production Version 1.0 with new features and old bugs

Version 2.0 release to production

Copy of Version 1.0

Fix bugs

Add new features Make new copy Merge new features and bug fixes to create Version 2.0

Version 1.1 release to production

Figure 1: This is an example of a Notes development cycle.

Figure 2: TeamStudio Analyzer displays all the information about a Notes form.