Architecture School

Use the Architecture School perspective to build a system under test by using the logical, physical, and synchronization views. You can also use this perspective to manage the schemas available in your project.

Overview

Test Integrations and APIs takes a service-oriented approach to testing.

Using this approach, business logic is modeled as one or more services, each one containing a number of operations with which the system can interact.

Architecture School is Test Integrations and APIs initial view (or perspective). In this perspective, users (that is, Architects) build the system to be tested in a simple, graphical fashion. The Architect defines the logical and physical system components and their relationships to one another.

Note: Logical components are bound to physical components by using one or more environments.
When a new project is opened in Test Integrations and APIs, an empty palette is presented in Architecture School. How the system is built varies, but it follows the same basic steps:
  1. Create a service component.
  2. Add operations to the service component.
  3. Add infrastructure components.
  4. Create physical components.
  5. Create environments and bindings.

Test Integrations and APIs considers the following items when you are building a system under test:

  • Service Components are named components that expose one or more operations to be tested. A service component can be simple (that is, has no child components) or composite (that is, has one or more child components).
  • Infrastructure Components are named components (for example, a database, a JMS domain, an HTTP connection) that can be bound to physical resources by using an environment. Infrastructure components do not expose any testable operations.
  • Operations are interfaces that define a service components functionality. An operation is defined by a Message Exchange Pattern (MEP) that describes the message pattern (Publish or Request/Reply) required by the operations transport to establish communications.
  • Physical Resources are testable resources within the enterprise (for example, a database or a web server) that represent a single configuration of an infrastructure component. The binding between the infrastructure component and the physical resource is configured in one or more environments.
  • Dependencies represent a reference from one operation to another, or from an operation to an infrastructure component. For example, if an operations output is stored in a database, the operation would have a reference to the database (that is, it would depend upon it). Outgoing dependencies are displayed in lavender, and incoming dependencies are displayed in green. Dependencies are only displayed for items in the diagram that are selected.

By itself, the logical system does not contain enough information to be testable. To enable the creation and execution of tests, the configuration details of the infrastructure components that make up the logical system must be provided. These details are stored in physical resources, which can be bound to infrastructure components (by using an environment).

Note: An infrastructure component can have any number of physical resource implementations, but only one binding can exist when you are running a test.

You can do the following tasks in the Architecture School perspective:

  • Create and edit service and infrastructure components.
  • Define a service components operations and dependencies to other operations and infrastructure components.
  • Create and edit physical resources.
  • Define the bindings of Infrastructure components to their physical resources for different testing environments.