Page History

{scrollbar:icons=false}
{section}
{column:width=75%}
h1. {page-info:title}
{column}
{column}
{include:SI Conop Sidebar to Include}
{column}
{section}
The [VKC:Contract Design Infrastructure depicted in the architectural infrastructure diagram|^ArchitecturalInfrastructure.JPG] (showing Deployment and Run Time imports Contract and Design imports Semantic) is part of the RM-ODP Enterprise viewpoint and comprises the means of capturing the logical components of a contract.

Currently these logical components are captured implicitly in code and in the design of applications. Certainly some fully specified contracts deserve to be captured, preserved, and reused where possible. However, capturing other contract components (and optionally realizing them) should be in scope for an enterprise such as CBIIT given its mission.

The RM-ODP Enterprise viewpoint metamodel indicates that that a Community specifies Contract(s) to fulfill specific Objective(s). The Contract is specified by particular Behaviors that are required in order to fulfill the Objective(s) and includes the Policies that pertain to fulfillment of the Contract. An example of capturing contract components and realizing them is the implementation of a durable service that is specified sufficiently to allow clients to consume components at run time without an early explicit binding. Other examples are discussed below.

*Diagram Depicting Contracts Bringing Together Information, Computational and Enterprise Elements and Expressing Quality of Service and Environmental Requirements*
!ContractDesign.JPG|alt="contract design diagram as described"!

The following are shown:
* Information
* Computation
** Enabled Behavior
** Establishing Behavior
** Terminating Behavior
** Interface Specification
* Enterprise and Business
** Rules
** Roles
* QOS (Quality of Service)
* Environment Contract

A contract is an agreement governing all or part of the collective behavior of a set of systems. In addition to the behavior and enterprise objectives fulfilled by the contract for a given community, a contract specifies the policies: permissions, obligations, and prohibitions for the systems involved.

Policies, potentially depicted as rules, describe the permissions, obligations, and prohibitions of the roles involved in the contract.

Roles are identifiers for behaviors, capabilities, capacities, or competencies that are enlisted to fulfill the terms of a contract.

Information components are represented by the invariant, static and dynamic models and characteristics of those models that facilitate the behaviors as constrained by the permissions, obligations, and prohibitions (policies) established by the rules associated with the roles.

For example of the kinds of rules that need to be defined are those in the RM-ODP computational viewpoint defining a set of rules that constrain a computational specification. These comprise:
* _interaction_ rules, _binding_ rules and _type_ rules that provide distribution transparent interworking;
* _template_ rules that apply to all _computational objects_ and _computational interfaces_;
* _failure_ rules that apply to all _computational objects_ and identify the potential points of _failure_ in computational activities.

In NCI's ECCF, Behaviors are broken down into subclasses such that contracts have an establishing behavior, a terminating behavior (commonly called preconditions and postconditions), and an overall objective that is enabled by the contract being established. As well, they defined the interfaces that are bound to each role to support the permissions and obligations associated with that role.

An Environmental Contract is a contract between a system and its environment. It can describe both constraints on a systems behavior in the correct environment as well as requirements placed on a system's environment for the system's correct behavior, such as QoS.

{scrollbar:icons=false}