Browse Prior Art Database

Handling Application Execution Automatically from Requirements Specification Disclosure Number: IPCOM000179128D
Original Publication Date: 2009-Feb-06
Included in the Prior Art Database: 2009-Feb-06
Document File: 3 page(s) / 64K

Publishing Venue



This article considers how a User Interface Generator can be extended to allow a modeller to create a model that generates multiple buttons on a user interface. This allows the user of the system to chose the flow through the system.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 3

Handling Application Execution Automatically from Requirements Specification

When creating specifications for user interfaces, a business analyst may create flow charts that describe the sequence of events that should occur when a user interacts with the implemented system. They can define how the user moves from one screen to another within the application including what labels appear on the buttons or links that move between screens and in what order screens will appear. Traditionally a developer would then take this visual specification and manually convert it, by writing code, into a user interface that behaves in the same way the flow chart described. This is a time consuming and error prone process which can often result in interfaces that do not meet the original specification.

    This paper describes a method for allowing the user interface to be generated directly from the specification flow saving on implementation time and ensuring that the end result exactly matches the intentions of the person specifying the function of the interface.

    The User Interface Generator for IBM's(*) Master Data Management (MDM) Server allows UML Activity flows to be used to define runtime execution of a task in a user interface. Currently the User Interface Generator for MDM Server can automatically generate straight through Activity flows from high level task descriptions. However it is limited in that in the generation does not allow a modeller to express how the user interacts with the flow of a task by choosing which path to take at any point.

    This article describes a solution that allows the modeller the same level of flexibility of task flow when designing a task that will be automatically generated as they would when specifying an interface that will be manually implemented.

The modeller can define:

How and when a piece of executing business logic can alter the flow of the task How and when a user's decision can alter the flow of the task by presenting multiple options to them as the next step in the task
The labels that appear on each of the options that the user can choose from The labels can be translated into any supported language of the resulting application

    Among other concepts, UML Activities can contain "Action" nodes where something happens and Decision nodes where a decision is made about which step in the flow to follow next. In order to distinguish between business logic actions and user actions we say that Action nodes can either be <

>s at which point some business logic is executing or <<ui

_change>>s at which point the user is

interacting with the screen.

    We can place a Decision node following an Action to define that more than one next Action may be chosen at that point.

    For example, consider this Activity for an "Update Person" task shown in Figure 1. The arrows (or edges) between the nodes are known a...