APPLICATION MODEL

home Home   

 Architecture nextNext
  The Application Model captures the design components that govern an application’s behavior and its interaction with the user. During the prototyping phase, OmniBuilder generates an application layer using default design templates. Once the Business Model has been defined (even minimally), application designers are free to modify the Application Model to suit specific requirements; OmniBuilder will respect their design decisions in subsequent generation. The Application Model also includes the actual physical implementation of the objects into RDBMS objects such as tables, indices, foreign keys references, and referential constraints; this is the Physical Model. The Physical Model is automatically built by OmniBuilder from the Business Model, however it can be separately modified by the developer if desired.
line Object Brokers

Design Patterns

Windows

Window Functionality

Security

Back Object Brokers Object brokers are sophisticated data access classes that mediate between the Business Model and the running application. Each Object Broker is mapped to a portion of the Business Model and can be used for prototyping without the effort of screen painting.

Object brokers can be mapped to entities, relationships and queries. Foreign key references and domain values are resolved, and services are automatically attached to allow data input and navigation to related entities. Other services available include: Zoom to parent records; Browse children relationships; and, Query by Form.
  Dataview
  Object Brokers support Live Object Modeling, a powerful feature that allows the Business Model to be developed and validated without coding. If the analyst adds a new property to a business object or articulates a new relationship, the rebuilt Object Brokers will immediately reflect the changes.

Triggers and services can be attached to a wide range of Object Broker events (example: post-commit or pre-insert) and the resultant behavior is automatically reflected in the User Interface.

Back Design Patterns OmniBuilder provides a variety of Design Patterns which implement sophisticated object behavior. Application designers are free to define their own Design Patterns to meet specific requirements. A few of the supplied Design Patterns are:
  • Add, update, delete functionality
  • Full transaction control
  • Object copy/duplicate
  • User queryable (Query by Form) with optional startup condition
  • Object navigation and related object lookup based on relationships
  • Zoom, browse
  • Hierarchy data with CreateChild/ CreateSibling services and move nodes
  • Version control: view history/new version
  • User-definable computed fields
  • Refresh on commit
  • Sort-by specification
Back Windows

Defaulting Windows

 Once an Object Broker is built, OmniBuilder generates default windows for its display. This simplifies the work of the interface designer, as they do not need to have any detailed knowledge of the underlying business objects.

Standard window controls are available which can be chosen by the application designer or defaulted by OmniBuilder.

Once OmniBuilder has generated a default window, the developer can enhance the window with a Window Painter.

  Resource
  The painted windows may be run interactively from within OmniBuilder just as they will be run by the application executable.
Back Window Functionality Window functionality is easily added. Assume, for example, that you want to add a button. Once the button is painted, you add a button to a specific window panel within OmniBuilder and either attach a ‘canned’ Feature to the button (ex. "Create a new record"), or write your own script for the button.
  Features
Back Security OmniBuilder provides a full and intuitive security implementation:
  • Role-based for all users. (Example: Manager, Clerk, Supervisor)
  • Privilege rules are specified for entities. (Example: Clerks can see but not change Medical information)
  • Entity rules may be conditional. (Example: Managers can update the Task lists for their departments only)
  • Properties can be conditionally restricted. (Example: The Date of Birth field can be changed only by the Employee himself)
  • The user interface is completely "security aware".
  • Menu security is based on the existence of a ‘test’ business object and operation which must be allowed before menu access is given. (Example: the ‘New Employee’ menu option is available only to those who are allowed to insert into the Employee object).
  • Authentication and login logic can be generated.
Prototyping Security Security can be prototyped within the development environment with the Prototype Wizard. After a Role is chosen, menus will be displayed accordingly and data access can be tested. This speeds up testing and interface design immensely because specific login accounts do not need to be created and the tester does not need to log-out/log-in to another account continuously.
Porting Security OmniBuilder generates the required security implementation at all tiers.
Window Security OmniBuilder notifies users of their access permissions within windows and menus of the application. Data, which is not allowed to be edited, will be automatically grayed out in the window. Buttons which perform disallowed functions are grayed out, and services which are not allowed are automatically removed from the service list attached to the mouse click. Menus to which the user is denied access are not visible to the user.

The sample window below shows display access to the full Employee record with update restricted on Employee name. Also, deletion is not permitted so the ‘Delete’ button is inactivated and the Delete service removed from the mouse menu.

  Menus

nextNext