Rambutan Requirements Management Tool for Busy System Analysts
Technical Report
Sasmito Adibowo Faculty of Computer Science University of Indonesia July 2003 Bibliographical Data Sheet
Report No. : UI-CS-2003-xx Report Date : July 2003 Original Language : English Type of Paper : Technical Report
Title Rambutan – Requirements Management Tool for Busy System Analysts
Keywords requirements management, requirements engineering, extensible markup language, requirements markup language, document object model, handheld application, personal digital assistant, design patterns, PalmOS, PocketPC, Windows CE, SuperWaba, Waba, Java, Swing, XML, RQML, DOM, Xerces.
Authors and Their Email Addresses Sasmito Adibowo ([email protected]) Eko K. Budiardjo ([email protected])
Performing Organization Name and Addresses Faculty of Computer Science University of Indonesia Kampus UI, Depok 16424, Indonesia Ph. +6221 7863419 Fax +6221 7863415 http://www.cs.ui.ac.id
Abstract
Rambutan is a Requirements Management Tool for Busy System Analysts. The application consists of two programs, one for a desktop computer and the other for a handheld computer. The desktop software is programmed as a Java Swing GUI application while its handheld counterpart is coded using SuperWaba and runnable on Palm OS, PocketPC, and Windows CE. Both applications are programmed with the Java programming language using established design patterns to support its evolution. The conceptual foundations of Rambutan are based on Requirements Markup Language (RQML), an XML dialect for storing natural-language requirements document. In turn, RQML is based on a set of best practices in requirements engineering. Therefore, Rambutan is independent of any particular requirements engineering methodologies. Supplementing Rambutan’s source code documentation, this report consists of a general description of the product, example screen shots of both applications, architecture overviews, and several pointers on evolving the system.
Total number of pages (including this page and cover page): 35 Table of Contents
General Description ...... 4 Product Functions...... 4 User Characteristics...... 4 Product Path ...... 4
User Interface Design ...... 9 Handheld Application...... 9 Desktop Application...... 14
System Components ...... 24 Architecture Overviews...... 24 RQML Problem Domain ...... 27
Evolution Management ...... 32 Evolving RQML ...... 32 Adding missing features...... 32 Supporting multiple users ...... 33 Upgrade issues to network-based user interface ...... 33 Supporting other mobile device platforms...... 34
Bibliography ...... 35
3 1 General Description
1.1 Product Functions Rambutan – Requirements Management Tool for Busy System Analysts is a set of end- user applications software that assists a system analyst in the gathering and categorization of facts for a requirements specification document. In its current state, the product consists of two programs that perform similar functions. A handheld application is used to gather facts in the client's site while a desktop application is used to edit and further refine the requirement statements in the analyst's office. Both applications allow the user to enter, modify, and display data that make up a requirements specification document. The concepts behind Rambutan lies on RQML 0.9, an XML-based requirements specification document format [Gudg00]. In turn, Requirements Markup Language (RQML) is based on a set of best current practices in requirements engineering. This design decouples Rambutan from any specific methodology for requirements engineering. Both the desktop application and its handheld counterpart are implemented using the Java programming language, allowing them to share some common code. However, it is not possible to code both applications to the same API. The desktop application is programmed for the Java 2 Standard Edition platform, version 1.3. On the other hand, the handheld application is programmed to run under the SuperWaba virtual machine using its own API. Both applications are GUI-based single-user systems. Compared to other requirements management tools, Rambutan offers these competitive advantages: • Convenient client application for use in handheld (PDA-class) computers. • Portability between handheld platforms supported by SuperWaba: PalmOS, Windows CE, and PocketPC. The handheld application may also be run on any Java 1.1-compatible devices. • Portability between desktop platforms supported by Java 2 Standard Edition: Windows, Macintosh, and Unix (including Solaris and Linux). • Extensible pattern-based object-oriented design ([Gamm95]). • Open XML-based document format. • Independent from any specific requirements engineering methodology. • Non-restricting Apache-style open-source license.
1.2 User Characteristics Rambutan is targeted toward mobile system analysts that performs extensive data gathering at the client's site during software development. These users typically use a handheld computer to assist their day-to-day tasks and also a desktop/notebook computer for heavier computing activities.
1.3 Product Path 1.3.1 Handheld and desktop applications
4 Chapter 1 – General Description 5
This initial state of the product consists of a handheld and a desktop application for use by a single user. The handheld application maintains data in its own proprietary format on the device. Its desktop counterpart is able to read, modify, and save documents in the handheld format. Natively, the desktop application uses XML DOM to manipulate the requirements document. The XML format used is a subset of the proposed RQML 0.9 specification. 1.3.2 Desktop conduits The next phase will be the development of conduit components that allow the handheld application to carry only a subset of the data available in the desktop version of the requirements document. This will allow the user to maintain large requirement Figure 1.1 Duet of Handheld and documents yet still minimize memory requirements Desktop Applications on the handheld. These conduits should also provide synchronization facilities between the desktop and the handheld. By synchronizing data, the user will be able to edit the same document both in the desktop and in the handheld computers. At synchronization time, data in both of the modified documents will be merged in a record-by-record basis. This synchronization facility is similar to the one provided by PIM applications such as the Palm Desktop. 1.3.3 Collaborative document editing Having attained a high usability for a single user requirement management tool, the next step of the evolution should be in supporting team members involved in requirements engineering. This support will be in the form of collaborative editing of requirements specification documents. Multiple users will be able to concurrently modify the same document at their own computers. Multi-user functionality should be accomplished by using a central repository that stores the requirements docu- ments. Users work on their desktop computers using data downloaded from this central repository. Occasionally, applications on the desktop connect to the repository to receive updates from other team members as well as to commit its own updates to the repository. Handheld application still synchronizes with its desktop counterpart. Figure 1.2 Collaborative Document Editing Thus, the desktop application acts as a middle-tier be- tween the handheld and the repository. Going multi-user also implies that there will be conflicts among the users of the system. These conflicts may range from simple concurrency problems to contradicting requirements even to modifications made by one user that negates the work of another user. Concurrency problems should be solvable by means common in the operating system and database domains – using techniques such as locking, semaphores, and transactions. While problems beyond concurrency are pertained to the problem domain which is requirements engineering. Conflicts on a level higher than concurrency problems are solvable by providing revision control and history functionalities. Each modification of a requirement Chapter 1 – General Description 6 statement is recorded along with the user who performed the modification. Should conflicts arise, the system will be able to provide historical data that assists in conflict resolution. Furthermore, keeping a history of each requirement allows traceability information between requirements to extend into the dimension of time. Additional "nice-to-have" features in this phase might include: • Discussion/messaging facilities. • Group scheduling tools. • Group polling (decision-making) tools. • Shared contact list data (to keep in touch with stakeholders). 1.3.4 On-line multi-faceted requirements management system Requiring the use of desktop applications for collaborative requirement engineering may prove to be inflexible in the long run. Being a thick client, the application must be installed in the user's computer before use – making it more difficult to upgrade and team members may be running different versions of the same application. When connecting to the central repository, the desktop application may also require a significant amount of network bandwidth – which may only be provided in a LAN-based setup. Finally, desktop GUI applications do not extend well to B2B information systems in which the back-ends of two companies communicate to each other directly. These cases might not be optimally served using the configuration described in the previous section: • Team members working remotely. A reliable network connection might not be available when a user is working out of the office. He or she might be forced into using a dial-up network connection or even mobile wireless data uplink (such as GPRS). Connection difficulties are especially true when the user in question is working offshore – airtime connection fare might be expensive and bandwidth will be low. • Giving access to nontechnical stakeholders. One fine advice in management is to Put the Customer in Control [Kawa95]. Therefore, it might be desirable to provide some access for stakeholder-customers to the requirements management system. Since these users are typically non- technical, they will require a different set of user interfaces and/or devices (for example, they might not want to use a PDA). • Subcontracting the development of subsystems. When developing large systems, it may be necessary to subcontract parts of the system's development to another company. This company may use different tools in their requirements engineering process. Even if they use the same set of tools, it will be necessary (for business-politics reasons) to restrict their access to the repository. Those aforementioned cases might be tackled by providing heterogeneous access methods to the requirements management system. Each of the access method should target a certain class of user and available connectivity option. The following table outlines some of the possible access methods available in present-day technologies. Chapter 1 – General Description 7
Client Type Thick Client Thin Client Enterprise Servers Enterprise JavaBeans Web Services
Desktop/Notebook Swing application HTML-based JSP application Computers Swing WebStart application Small-screen optimized XHTML- Handheld (PDA- SuperWaba application based JSP application class) Computers WML-based JSP application Mobile Telephones J2ME CLDC application
Furthermore, a prototype of HTML-based JSP application for requirements management was already developed by Dharmawan [Dhar02]. This prototype is also based on RQML. 1.3.5 Software Development Information System
Requirements engineering in itself covers only a fraction in the broader context of the activities involved in software development. Any non-trivial systems engineering effort will gain advantage from an integrated set of tools that encompasses the requirement elicitation, analysis and design, construction, testing, deployment, and maintenance activities. This toolset should include the following: • Requirements management tools. • Project management (including human resource management tools). • Analysis and design tools (including code generators). • Rapid application development tools (code templates and user-interface builders). • Source code revision control. • Testing framework (including automated unit and integration testing tools). • Deployment and upgrade tools (including Internet-based setup tools). • Maintenance tools (to handle field-discovered bugs and user feedback). Fortunately, software applications that cover various subsets of the aforementioned toolset have been developed. Some of these applications may even be obtained at no charge and some of which are open-source. On the down side, integration among the existing tools provided by different vendors is minimal, or even nonexistent. Although integrating the various tools in software development is a task not to be taken lightly, advantage gained by doing that is of great value to the industry. An integrated toolset will be able not only to link a requirement to a feature – but further to design decisions, on to software modules, lines of codes, and even to bug reports and the people in charge of fixing the bug. All of this will enable stakeholders to gain a real- time view of the development effort in progress. Furthermore, efforts to gather and analyze productivity measurement statistics (lines of codes, function points, bug count, etc.) that were done manually may mostly be automated. Chapter 1 – General Description 8
The following is a list of open-source tools that assists in the process of software development. These software tools are obtainable at no cost in terms of license fees. Note that this list is provided only for convenience – it is in no way complete. • SourceForge (collaborative web-based software development) http://sourceforge.net/projects/alexandria-dev/ • hoot (Summary Process improvement for open software projects) http://hoot.tigris.org/ • Apache Maven (project management and comprehension tool) http://maven.apache.org/ • Tutos (web-based project management and groupware software) http://www.tutos.org/ • Progect (Palm-based project management software) • Concurrent Version System (source code version management) http://www.cvshome.org • Subversion (source code version management) – http://subversion.tigris.org • JavaNCSS (source code metric analyzer) – http://www.kclee.com/clemens/java/javancss/ • Jakarta Cactus – Test framework for server-side Java code – http://jakarta.apache.org/cactus/ 1.3.6 Horizontal Aspects
The preceding sections primarily focus on evolving the system vertically. Expansion paths are outlined step-by-step in manners of increasing scope and features. However there are other horizontal aspects of the software that must not be left out. These aspects are:
• Supported requirements engineering methodologies. quality • Usability aspects – user friendliness, performance, reliability, etc. The foundation of RQML is a set of best practices in requirements engineering selected by Wiegers [Wieg99]. It scope is still debatable whether this set is indeed "best" in the methodology usability current state of the industry. Also RQML is still far from being an accepted standard for requirements specification Figure 1.3 The three aspects in Rambutan's evolution document. One reason which hinders acceptance is that there are still inconsistencies present in [Gudg00]. Further refinements will need to be done to iron out these wrinkles from the proposed RQML 0.9 specification. Being fully-featured may not be best in all cases. Software packed with too much features will be large and difficult to use. This is especially true in handheld applications, where the feature set must be carefully selected to achieve a delicate balance in terms of features, ease-of-use, memory consumption, and speed [Palm]. Unfortunately, evolution of those horizontal aspects cannot be plotted as easily as the vertical aspects. Extensive research and trial-and-error attempts will be required in order for the system to mature in these areas. Even so, quality of the system will be improved gradually when the expansion of scope is made in-line with the improve- ments in usability and methodology. 2 User Interface Design
2.1 Handheld Application
2.1.1 Flow Description
There are three primary screens in the handheld application. They are Document List, Element List, and Element Edit. Occu- pying all of the handheld display area, only one of these screens is shown at a time. Document List Element List The handheld application starts at the Document List screen showing the list of requirements documents available on the handheld, if any. Tapping on Element Edit the name of a document will open that Figure 2.1 Handheld User Interface States document. There is also a New com- mand button at the bottom of the screen that is used to create a new document. When the user taps on the New button, a dialog box will appear prompting for the name of the new document. After the user provides a name, the new document will be created and then opened as if the document has already existed and he or she taps on its name.
Figure 2.2 (A) The Document List screen. (B) Tapping on New to create a new document.
Opening a document will display the Element List screen, displaying the document's name in the screen's title-area. This screen is actually a set of screens in which each lists a certain type of RQML first-class elements, displaying its ID and Name attributes.
9 Chapter 2 – User Interface Design 10
Switching between the first-class element type displayed is done through a combo box in the upper-right side of the display. Tapping on the title-area will display a pull- down menu where the user may create a new RQML first-class element of the desired type. While tapping on the name of a first-class element will edit that element. Three command buttons are provided at the bottom of the Element List screen: • New – to create a new first-class element of the type currently displayed. • Close – to close the currently displayed docu- ment and return to the Document List screen. • Delete – to delete the currently displayed docu- ment and return to the Document List screen. This user interface arrangement mimics the style of some of the PalmOS built-in applications. The Address Book, To Do List, Memo Pad, and Mail applications all have a "category switch" combo box in the upper right and a row of command buttons at the bottom of the screen. When the user creates a new element or opens an existing one, an Element Edit screen is displayed. This screen is also a set of screens where each is used to modify a particular set an RQML first-class element’s attributes. In these screens, the category switch combo box is used to switch between views of the same first-class element being edited. The title Figure 2.3 An Element List screen. area of these screens displays the type of the first- This one displays the available Use- class element being edited. case elements in the document. Currently, the Element Edit screens do not provide any menu; commands are provided as a row of buttons at the bottom of the screen. All of these commands return to the previously active Element List screen: • OK – Commits changes to the element. • Cancel – Abort any change to the element. • Delete – Deletes the currently displayed element. The Element Edit screens for the first-class elements Requirement, Stakeholder, Assumption, and Issue are identical as they do not add any information to RQMLFirst- Class. While the editors for other first-class element types add their own specific displays for their extra attributes. Chapter 2 – User Interface Design 11
Figure 2.4 Sample Element Edit screens displaying the common attributes for all RQML first-class elements. The attributes are divided into two screens (A) and (B) to fit the display. Exactly the same set of view is used for the Requirement, Assumption, Stakeholder, and Issue first-class elements since they do not add any attribute beyond those common ones displayed in this figure. The user interface of the handheld application is implemented in these packages: • com.arcle.rmt.superwaba.ui – Generic user-interface classes. • com.arcle.rmt.superwaba.vc – User-interface classes. • com.arcle.rmt.superwaba.vc.rqml – RQML first-class element editors. More complete description the classes is available in the source code documentation1. 2.1.2 Additional First-Class Attributes
2.1.2.1 Project Apart for standard attributes, the editor for the Project first-class element adds the following sub-screens: • Problem Statement •Product • Scope & Vision
1Source code documentation is provided in the accompanying CD-ROM. Chapter 2 – User Interface Design 12
Figure 2.5 Additional attributes for the Project first-class element type
2.1.2.2 Use-Case Apart for standard attributes, the editor for the Usecase first-class element adds the following sub-screens: •Actors • Conditions • Comments • Normal Course • Alternative Course • Exception Chapter 2 – User Interface Design 13
Figure 2.6 Additional attributes for the Use-case first-class element type
Figure 2.7 Additional attributes for the Use-case first-class element type Chapter 2 – User Interface Design 14
2.1.2.3 Context and Lexicon Apart for standard attributes, the editor for the Context first-class element adds a Context sub-screen. While the editor for Lexicon adds a Definition sub-screen.
Figure 2.8 Additional attributes for the Context and Lexicon first-class element types.
2.2 Desktop Application
2.2.1 Overview
Layout of the desktop application’s user interface is mostly inspired from Rational RequisitePro. It is basically an MDI window with a tree view placed in the left. The desktop area is used to display first-class element editor windows. Chapter 2 – User Interface Design 15
Active document file name File modified flag
First-Class Element Type Desktop Area First-Class Element
Document Tree Active Element
Active Element Description
Status Bar Figure 2.9 Desktop User Interface Overview
The Document Tree at the left of the window displays the first-class element types as the folders in the tree. Each first-class element type node in the tree contains the elements for that element type. Double-clicking an element type node creates a first- class element of that node's type. While double-clicking an element node will display an editor window for that element. New elements may also be created through the Requirement pull-down menu. The Active Element Description box just below the Document Tree displays the description attribute of the currently highlighted element in the tree. It is serves as a quick view when browsing first-class elements in the document – without the need of editing the element. The Desktop Area is used to contain first-class element editor windows. Taking advantage of the richer user interface capabilities of the desktop, this area is capable of displaying multiple editor windows at once. The Status Bar is an area at the bottom of the window to display status information. This area is reserved for further development; it currently has no function. The user interface of the desktop application is implemented in these packages: • com.arcle.rmt.j2se.swing Main window and "about" dialog. Chapter 2 – User Interface Design 16
• com.arcle.rmt.j2se.swing.ui Generic user interface classes. • com.arcle.rmt.j2se.swing.vc User interface classes. • com.arcle.rmt.j2se.swing.vc.rqml First-class element editors. More complete description the classes is available in the source code documentation2. 2.2.2 Element Editors
The first-class element editor windows are internal frames placed in the Desktop Area. Similar to the handheld application, each editor window contains several sub-views that house their own set of controls for editing the first-class element. In the desktop application, the sub-views are placed in a tabbed pane within the editor frame. There are two command buttons placed at the bottom row of the windows: • Close – closes the editor window and commits the changes done. • Delete – removes the corresponding element being edited from the document and then closes the editor window. 2.2.2.1 Common Attributes The Basic and Extended common sub-views of the first class editors are similar to the ones found in the handheld application. These sub-views exists for all first-class element editors. Identical sub-views are used for the Requirement, Stakeholder, Assumption, and Issue first-class elements since they do not have any additional attribute besides the common ones.
Figure 2.10 First-class element editor window, displaying the Basic tab.
2 Source code documentation is provided in the accompanying CD-ROM. Chapter 2 – User Interface Design 17
Figure 2.11 First-class element editor window, displaying the Extended tab.
2.2.2.2 Project specific attributes The editor for the Project first-class element type contains these additional sub-views: • Problem Statement • Scope & Vision •Product
Figure 2.12 The Project first-class element editor displaying the Problem Statement tab Chapter 2 – User Interface Design 18
Figure 2.13 The Project first-class element editor displaying the Scope & Vision tab
Figure 2.14 The Project first-class element editor displaying the Product tab
2.2.2.3 Use-case specific attributes The editor for the Usecase first-class element type contains these additional sub-views: •Actors • Conditions • Courses • Comments Chapter 2 – User Interface Design 19
Figure 2.15 The Usecase first-class element editor displaying the Actors tab
Figure 2.16 The Usecase first-class element editor displaying the Conditions tab Chapter 2 – User Interface Design 20
Figure 2.17 The Usecase first-class element editor displaying the Comments tab
The Courses tab is further divided into three identical sub-views: • Normal Courses • Alternative Courses • Exceptions
Figure 2.18 The Usecase first-class element editor displaying the Courses tab Chapter 2 – User Interface Design 21
2.2.2.4 Context-specific attributes Like its handheld counterpart, the editor for the Context first-class element contains one additional sub-view.
Figure 2.19 The additional attribute of the Context first-class element editor
2.2.2.5 Lexicon-specific attributes Like its handheld counterpart, the editor for the Lexicon first-class element contains one additional sub-view.
Figure 2.20 The additional attribute of the Lexicon first-class element editor Chapter 2 – User Interface Design 22
2.2.3 Switchable Look-and-Feel
Swing supports the notion of pluggable look-and-feel in its components. Rendering of each Swing component is delegated to a separate Look-and-Feel Module. Therefore, a component may be rendered differently onscreen, depending on the active look-and-feel module. The active look-and-feel module may be changed at runtime, allowing a Swing application to "change its face" during execution. Rambutan exposes this capability through the Tools menu. A command in this menu allows the user to switch between installed look and feel modules. The following figures shows samples of the application screens using the three look-and-feel modules installed by default in JDK 1.3.
Figure 2.21 The default look-and-feel (Metal)
Figure 2.22 The Motif look-and-feel Chapter 2 – User Interface Design 23
Figure 2.23 The Windows look-and-feel
It is visible that the pluggable look-and-feel is capable of emulating the user interface of the underlying operating system. On the other hand, it is also capable to mimic the display of applications from another operating system. 3 System Components
3.1 Architecture Overviews
Rambutan consists of two application software: a desktop application and a handheld application. The desktop application is programmed to the Java 2 Standard Edition API (J2SE) while the handheld application is programmed to the SuperWaba API. Both applications are coded in the Java programming language. Using a common implementation language allows the two applications to share some common code – these cross-platform components contains simple algorithms and interface classes that do not rely on either API to function.
Both applications are roughly divided into two Swing GUI SuperWaba GUI layers: a user interface layer, and a data model layer. Currently, the desktop application uses the Desktop RQML Abstraction Handheld Swing GUI library available with J2SE (note that Model Model Swing is not the only user interface option available J2SE API SuperWaba API in the platform). Since a handheld device is more limited, the handheld application has little option desktop application handheld application besides using SuperWaba's GUI library. Figure 3.1 Architecture overview of the The two applications share the RQML Abstraction desktop and handheld applications component. This component is a set of interface classes that defines the RQML data model. In turn, these interfaces are implemented by both the Desktop Model and Handheld Model components. Access to the RQML implementations in both applications utilizes this abstraction as much as possible. Therefore consistency of the data models between the handheld and desktop is enforced – changes to these interfaces will ripple to both implementations in the handheld and desktop. Likewise, a method signature change in the implementing model of one application will require the change to be mirrored in another application. There are four top-level packages in Rambutan beneath the application's root package com.arcle.rmt: • com.arcle.rmt.j2se The desktop application. • com.arcle.rmt.superwaba The handheld application. • com.arcle.rmt.rqml RQML Abstraction interfaces. • com.arcle.rmt.xplat Cross-platform utility classes. 3.1.1 Handheld Application
The handheld application actually has three major layers: the user interface (GUI) layer, the data model layer, and the RQML implementation layer. Being a shared compo- SuperWaba GUI nent, classes in the RQML Abstraction layer is also Handheld Model RQML Abstraction included in the handheld application. All layers in the handheld application rely on the SuperWaba API classes. RQML Implementation SuperWaba API The GUI layer implements the user interface. Classes in Figure 3.2 Handheld application this layer mostly extend from SuperWaba's Window class. architecture overview
24 Chapter 3 – System Components 25
Access to the handheld's data by the GUI is done solely through the Handheld Model or the RQML Abstraction layers. Classes in the Handheld Model layer provide services to manage RQML elements to the GUI. Most operations done by the model rely only to the method signatures defined by the RQML Abstraction component to access the RQML elements. One major exception to this includes object instantiations of the RQML elements (in which the model acts as an abstract factory to its clients). Since the classes in the RQML Abstraction are all abstract interfaces, they must be implemented to be useful. Straightforwardly called the RQML Implementation layer, these classes implement those interfaces for use in the handheld application. Shielded from the GUI by the Handheld Model and RQML Abstraction layers, internal implemen- tation changes to this layer will not affect the GUI. Organized under the package com.arcle.rmt.superwaba, the handheld application consists of these packages: • com.arcle.rmt.superwaba.vc User interface classes. • com.arcle.rmt.superwaba.model Data model and RQML Implementation classes (located in a subpackage). • com.arcle.rmt.superwaba.ui General-purpose user interface classes. • com.arcle.rmt.superwaba.util General utility classes. • com.arcle.rmt.superwaba.framework Interfaces for the MVC framework. 3.1.2 Desktop Application
Similar to its handheld counterpart, the desktop application also consists of three major layers: the user interface, model, and RQML implementation. The RQML Abstraction layer contains the same set of classes as in the handheld application. All layers in the desktop application rely on the J2SE API. The user interface of the desktop application uses the Swing GUI library available in J2SE. Although its functions are similar to the handheld, the desktop GUI takes advantage of the larger screen and richer user interface capabilities typically available in a desktop computer. Access to the data is also done solely through the model and the RQML Abstraction Swing GUI classes. Desktop Model RQML Abstraction Since a desktop computer offers greater processing and richer user interface capabilities, the desktop model has Element Adapters more features to take advantage of this fact. Therefore, DOM API the desktop data model has different methods signatures Xerces Implementation and implementations from the handheld’s model. Like the handheld, it also relies on the RQML Abstraction inter- J2SE API faces to manipulate the RQML elements in the model and Figure 3.3 Desktop application acts as a factory class to instantiate their implementa- architecture overview tions. Implementation of the RQML Abstraction layer in the desktop application is different from the handheld. Instead of storing RQML data itself, these classes rely on XML Chapter 3 – System Components 26
DOM objects to represent the data in-memory. Therefore, classes in this layer are collectively called Element Adapters. The DOM implementation library used is Apache Xerces, an open-source XML parser. Since these adapters communicate with the parser solely through the DOM interfaces provided, another DOM-compliant XML parser besides Xerces may alternatively be used. The desktop application is contained in these packages: • com.arcle.rmt.j2se.swing.vc User interface classes. • com.arcle.rmt.j2se.model Data model and element adapter classes • com.arcle.rmt.j2se.swing.ui Generic user interface classes. • com.arcle.rmt.j2se.util Utility classes. • com.arcle.rmt.j2se.framework Framework interfaces. 3.1.3 Bridge Classes
The desktop application architecture shown in Figure 3.3 depicts only a part of the architecture. A Bridge component is purposely hidden from the picture to improve its legibility. This component is used by the desktop application to access the handheld's data. It handles the conversion between the desktop and handheld models.
When the user opens a handheld document or saves Bridge Facade a handheld document using the desktop application, Import Facade Export Facade its user interface calls the Bridge Facade to read the First-Class Copy Facade First-Class handheld data and loads the data into the in-memory Importer Element Copiers Exporter desktop model and vice-versa. This facade in turn RQML Abstraction delegates the request to the appropriate Import Handheld & Desktop Models Facade or Export Facade components. The two SuperWaba API facades then handle the import or export, respec- J2SE API tively. SuperWaba to Java Bridge
The Import Facade uses a set of First-Class Importer Figure 3.4 Bridge architecture overview classes to load data from the handheld model into the desktop. Each of these importer classes imports a certain type of first-class RQML element. Analogically, the Export Facade uses a set of First-Class Exporter classes to save data from the desktop into the handheld model. Similar to the importers, there are one-to- one mappings between the element exporters and an RQML First-Class element type3. Both of the import and export facades relies on a Copy Facade to transfer data between RQML elements. In turn, the facade uses a set of Element Copier classes to copy the data. There are one-to-one mappings between a copier class and an RQML element (both first and second class elements). These copiers only depend on the RQML Abstraction interfaces – they have no knowledge of the underlying implementations of
3 Except for the
3.2 RQML Problem Domain
3.2.1 RQML Data Model
The RQML markup is constructed by the aid of an object-oriented data model. This data model is a class hierarchy in which the classes define the kinds of data stored in a requirements document.
RQMLSecondClass
External RQMLFirstClass Term
Taxonomy Requirement Stakeholder Usecase Trace
Project Assumption Context Issue Lexicon Group Figure 3.5 RQML data model hierarchy
This object-oriented model is then mapped to an RQML DTD by flattening the inheritance tree and then defining XML tag types from the leaf nodes in the flattened trees. Simple data types (such as simple texts and enumerations) are mapped into attributes of the element. While complex types are mapped into sub-elements. This
4 For example, platform differences would require a J2ME implementation of Rambutan to define yet another data model component. Chapter 3 – System Components 28 method of mapping is analogous to instantiating all of the classes and then creating element definitions derived from the objects that are instances of the leaf classes. 3.2.1.1 RQMLSecondClass The RQMLSecondClass class defines attributes common for all RQML elements. These attributes are: • ID – unique identifier for the element. • URI – reference to an external entity. 3.2.1.2 Term The term element is used in many other elements to make block in a natural language text targetable by a traceability link. This block then may be traced to lexicon entries, context entries, or for other traceability purposes. Currently, the term element is not yet supported by Rambutan. 3.2.1.3 External The external element is used in an RQML document to refer to entities outside the document. Since the referral method is through a URI, any entity that has one may be linked from an RQML document. Currently, the external element is not yet supported by Rambutan. 3.2.1.4 RQMLFirstClass The RQMLFirstClass class defines common attributes for all entries in an RQML document. Subclasses of this class are used to define markups for elements that are placed immediately beneath the
First-class Additional Attrib- Description Remarks Element utes
3.2.2 Mapping RQML to classes
Object-oriented representations of RQML is put together by mapping the RQML data model into an interface hierarchy. Each RQML element is mapped into an interface that represents it. When common attributes or sub-elements definitions present, the commonalities are re-factored into one or more super-interfaces. These interface Chapter 3 – System Components 30 classes are placed in the package com.arcle.rmt.rqml that are implemented by the data model classes in the handheld and desktop applications. A simplified approach was taken while mapping RQML DTD entries to Java interfaces. For every element that may have more than one sub-element of a particular type (those child element specifications that are suffixed with ‘*’ or ‘+’ in the RQML DTD [Marc99]) is mapped to an interface which only allows one instance of the child element. There are three reasons that motivates this simplification: • The discovery of several inconsistencies in the RQML specification in [Gudg00] signifies that the specification is not yet stable. • RQML is yet to be a ratified standard by an international body (such as ISO, IETF, or W3C) so that this (short-duration) project need not be 100% compliant with RQML to ensure interoperability with other RQML-based tools5. • Technical difficulties in the implementation of an efficient user interface for the handheld application to support such configuration of child elements. Further developments of Rambutan should re-visit this design decision and perhaps lift the limitations imposed by it. The following is a fragment of the RQML DTD for the
This element is mapped into several interfaces, those are: RQMLSecondClass, RQMLFirstClass, and Requirement. public interface RQMLSecondClass { public abstract java.lang.String getURI(); public abstract void setURI(java.lang.String URI); public abstract java.lang.String getID(); public abstract void setID(java.lang.String ID); }
Common to all first-class elements, the attributes priority, difficulty, status, and stability are enumerated types where a value may be chosen from a (very) limited set of values. These attributes are mapped to the int Java data type where the value of the enumerated types are specified through static constants. For example, to set the status attribute to the value approved the constant STATUS_APPROVED is used.
5 In fact, the only known “other RQML-based tool” is the one created by Dharmawan [Dhar02] Chapter 3 – System Components 31 public interface RQMLFirstClass extends RQMLSecondClass { public static final int PRIORITY_LOW = -1; public static final int PRIORITY_NORMAL = 0; public static final int PRIORITY_HIGH = 1; public static final int DIFFICULTY_LOW = -1; public static final int DIFFICULTY_NORMAL = 0; public static final int DIFFICULTY_HIGH = 1; public static final int STATUS_PROPOSED = 0; public static final int STATUS_APPROVED = 1; public static final int STATUS_INCORPORATED = 2; public static final int STATUS_VALIDATED = 3; public static final int STABILITY_LOW = -1; public static final int STABILITY_NORMAL = 0; public static final int STABILITY_HIGH = 1; public abstract Name getName(); public abstract int getPriority(); public abstract int getDifficulty(); public abstract int getStatus(); public abstract int getStability(); public abstract java.lang.String getVersion(); public abstract Description getDescription(); public abstract Rationale getRationale(); public abstract void setName(Name NAME); public abstract void setDescription(Description DESC); public abstract void setRationale(Rationale RATIONALE); public abstract void setPriority(int PRIORITY); public abstract void setDifficulty(int DIFFICULTY); public abstract void setStatus(int STATUS); public abstract void setVersion(java.lang.String VERSION); public abstract void setStability(int stability); }
The
4.1 Evolving RQML
Over time there will be a need to improve the current RQML support, or even to change the RQML DTD itself. These changes will likely manifest in changes to the RQML interfaces in the package com.arcle.rmt.rqml. Modifications to these interfaces will ripple mostly to the components described in this section. 4.1.1 Data Model Implementations
The implementation classes for the RQML interfaces will subject to a direct impact from RQML interface changes. These classes are located in the packages: • com.arcle.rmt.superwaba.model.imp.rqml • com.arcle.rmt.j2se.model.domimpl.rqml 4.1.2 RQML Copier classes
The classes that copies element instances through their RQML interface are the next group of classes that will need to undergo modifications. Changing the RQML data representations also mean changing the way to access these data – which includes copying the data. The RQML Copier classes that will require modifications are located in the package com.arcle.rmt.bridge.copy.rqml. 4.1.3 Import/Export classes
Changes to the RQML first-class elements will also impact the import and export components that transfer data between the desktop and handheld models. These classes are located in the packages: • com.arcle.rmt.j2se.bridge.swexport.rqml • com.arcle.rmt.j2se.bridge.swimport.rqml 4.1.4 RQML First-class editors and their panels
Any change to an RQML element definition will affect their data-entry components. Changes to a first-class element will affect their corresponding editor components. Likewise, changes to a second-class element may affect one or more panels that are used by the first-class editors. These components are located in the packages: • com.arcle.rmt.j2se.swing.vc.rqml • com.arcle.rmt.superwaba.vc.rqml
4.2 Adding missing features
Incorporating effective support for the currently unimplemented RQML features – namely the
32 Chapter 4 – Evolution Management 33
Support for the
4.3 Supporting multiple users
Collective experience shows that any non-trivial project will involve more than one person. Therefore, it makes perfect sense to evolve Rambutan to support multiple users. As a requirements management tool, the primary targets for such evolution will likely to support collaborative document editing and facilitating communications between the requirements engineers. Adding support for concurrent users means moving the data storage from the user’s machines to a centralized system. A client/server setup will be necessary, although a more limited thin-client environment may turn to be suitable for some uses. In any case, a server will be needed to centralize handling of the requirement data and resolve concurrency issues. The choice between setups may be weighted through several factors: • Required user-interface capabilities – Normally a thick-client application is able to provide faster interaction and thus better user experience while thin-clients are characterized by longer turnaround times between user inquiries. • Maintenance of client applications – Obtaining upgrades for a thin-client (browser-based applications) are straightforward since the application is stored on the server – upgrading does not require user interaction. This is unlike thick- clients where upgrades are done by installing programs on the client’s machines. • Network connectivity – A thin-client application is more dependent on the network connection available while a thick-client may be able to operate while the network is unavailable. Before supporting more than one users, traceability support must already be incorporated. Most notably are the traces that handles versioning (revision control), conflicts, and replacement of one set of requirements over another.
4.4 Upgrade issues to network-based user interface
Supporting network-based user interface environments such as web or WAP will require another implementation of the user interface classes. However, the layers beneath it – the data model and import/export classes – should not be affected by the expansion. The bridge component may be useful to support handheld devices that are connected to the server via a wireless network. Naturally, multi-user support is a pre- exquisite for the implementation of a network-based user interface. The classes that will need to be re-implemented to support different user interface environments are located in the package com.arcle.rmt.j2se.swing and its sub- packages. Other user interface implementations should follow similar package naming Chapter 4 – Evolution Management 34 convention. For example, a JSP/Servlet-based implementation preferably be placed in packages rooted from com.arcle.rmt.j2se.servlet.
4.5 Supporting other mobile device platforms
Should the need arise to expand support to handheld devices beyond those operating on Palm OS and PocketPC, these options are available: • Porting the handheld application – A thread in the SuperWaba newsgroup6 states that porting a J2ME application should to SuperWaba is not a difficult task – it can be done in two or three days. Porting to the other direction – SuperWaba application to J2ME – should not be too different, if the application does not use any of the advanced features of SuperWaba not supported by J2ME (for example, floating point or infrared communications). • Porting SuperWaba – Albeit porting the SuperWaba virtual machine to other mobile operating systems (e.g. Symbian) will be more difficult than porting a particular application, doing so may be more rewarding. Since SuperWaba already supports two very different operating systems (Palm OS and PocketPC), adding support to another mobile operating system should not be impossible. • Thin-client platforms – providing support to other mobile devices may also be done by expansion to network-based user interface environments engineered for small devices, such as WAP. A JSP/Servlet version of Rambutan could be programmed that outputs WML pages instead of HTML.
6 news://news.falch.net/pilot.programmer.waba Bibliography
[Dhar02] Dharmawan, Zulfikar S. Alat Bantu Requirements Management Berbasis Web Dengan Memanfaatkan Dokumen Extensible Markup Language. University of Indonesia Research Paper. 2002. [Gamm95] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Company. 1995. [Gudg00] Gudgeirsson, Gardar. Requirements Engineering and XML. University of York Research Paper. 2000. http://www.raqoon.is/rqml/rqml-resources.htm [Kawa95] Kawasaki, Guy. How to Drive Your Competition Crazy. Hyperion, New York. 1995. [Leff00] Leffingwell, Dean & Don Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley. 2000. [Marc99] Marchal, Benoiˆt. XML By Example. Que. 1999. [Palm] et. al. Palm. Zen of Palm. Palm, Inc. [Wieg99] Wiegers, Karl E. Software Requirements. Microsoft Press. 1999.
35