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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.