Phase 1: Analysis and design

During this phase, the project team does a complete analysis of the business processes, including all actions to be taken by the application, both normally and in exceptional cases (such as off-line mode). The project team obtains or creates documentation of the existing information system and defines a design of the runtime application (both the model engine and the presentation engine). From the overall analysis and design, the project team identifies the required extensions to the toolkit. To do this, the project team performs the following tasks:
  1. Gather requirements and create use cases to fully understand the functionality specifications for the application. See Gathering requirements in Phase 1 of the Java Client Sample Application documentation for a brief example. In some cases, the project team will be given the functional specifications and need not perform this step.
  2. Analyze and identify business processes based on the functional specifications for the required solution and the behavior of the existing system. This includes identifying any process flow mode (for example, online or offline) that the solution must support and the logical and physical architecture for the solution. This step allows you to define the data model, execution flow, logic distribution, and required services. See Identifying the business processes in Phase 1 of the Java Client Sample Application documentation for an example. The result of this step is that you know which processes your application must have and when they run.
  3. Identify the host transaction messages, including which data the messages must include and how the messages are sent (see Formatters and CHA Formatter Service), and which data must be retained in host storage such as the Electronic Journal. See Identifying backend system transactions and journal entries in Phase 1 of the Java Client Sample Application documentation, which identifies the messages that are sent between the sample application and the host, the data contained in the messages, and the data to be recorded in the Electronic Journal.
  4. Agree on the naming of all data elements identified in the previous two tasks and then build a data-naming dictionary to ensure that both the corporate system and the front-end application are using the same concepts during the implementation. Define any required data mapping. There is an example of a data dictionary in Creating a data dictionary in the Java Client Sample Application documentation.
  5. Identify the set of services required by the application to perform each business process. For example, identify whether the business process needs a printer, communication with the host system, journaling, access control, or other services. The Services document contains links to the various toolkit services. See Identifying services in Phase 1 of the Java Client Sample Application development for an example of this step.
  6. Define the required process flows. This entails identifying a set of process groups that cover all the possible business processes. Defining reusable process steps helps in building a modular solution. Refer to the Business Process Component and Single Action EJB document for more information. See Flows and Struts extensions for handling complex process flows.
  7. Based on the definition of the transaction messages, identify all the required data elements and formatters and compare them with the ones provided by the toolkit. See the documentation on Data elements, Typed data elements (including NLS), and Formatters for information about defining and extending these elements. The documentation for the Java Client Sample Application (Identifying data elements and Identifying formatters in Phase 1) has a table containing the required data fields and describing what formatters were created to support the new data elements.
  8. Create specifications for the user interface (data design and views) of the business processes. See Visual beans and JSPs for more information. Note that local business processes might influence the definition of data elements and formatters. As a result, the user interface's data design and required views may require new data elements and formatters for the application. For example, if the application needs local journaling, you might have to define new data elements and formatters for the journal. See Defining the user interface in the Java Client Sample Application documentation for an example.

    The toolkit provides a wide variety of functions to create panels linked to the model and linked to the actual execution of processes. Make a clear identification of which of these features the application will use to ensure that the toolkit addresses all requirements regarding data management, process execution, panels presentation, and so on. This activity also locates possible areas of customization to cover those requirements not available in the toolkit.

    This task includes defining the policy for error management. For example, specify what to do if errors happen while an process is executing, whether or not the user will be able to take any action, and whether occurrences of events should be logged. For information on exception handling by the toolkit, see Exceptions.

  9. For any visual parts that are not already available in the toolkit, create specifications for reusable visual parts that fulfill the application's business needs. Defining new parts that are reusable by many process views greatly improves the speed of the application development process and also the quality of the results because of the consistency that comes from reuse. See the Visual beans and JSPs documentation for information on defining visual parts.
  10. Decide how to implement the business logic for validating business fields. That is, when defining the user interface for the processes, you may need to balance the business logic between the visual components and the script execution. This influences how the process is created. For example, performing cross-validations when launching the process might be performed by a visual component based on some fixed rules or it might be performed as an additional step inside the process flow, which may reside on a middle-tier server.
  11. Define the context hierarchies for both the client and the server, and group the toolkit entity definitions (such as data elements, contexts, processes, steps, formatters) to match the business logic and structure. For information on contexts and context hierarchies, see the Contexts and the CHA contexts document, and for an example of defining a client context hierarchy and a server context hierarchy, see Defining context hierarchies in Phase 1 of developing the Java Client Sample Application.
  12. Define the application desktop, and identify which toolkit components must be extended or which new components must be added to the application solution. Define also the policy for controlling user access and personalizing the desktop. Based on these definitions, identify any extensions that must be made to the toolkit Desktop. See Desktop for more information.