Whereas the Use-Case Model shows the behavioral context for the system, in this task you create a logical model of the system in its environment, using the following: Work Product: Business Use Case Model, Work Product: Supplementary Business Specification. The model is used to delineate a Context Diagram.

• The interfaces to be realized by the system (in terms of the operations the systems provides, and the associated protocols supported, the state variables and stores that the system realizes, and attributes).
• The I/O entities that flow between the system and its actors.
• The interfaces required by the system (to be realized by the actors which interact with the system) for correct performance. Often, if the actor represents an existing system with which the system must communicate, these required interfaces simply reflect constraints imposed by that other system.

A context diagram shows the top-level collaboration between the system and its actors. It is the structural analog to the Use-Case Model for the system. This collaboration is created in the Analysis Model.

I/O entities (represented for modeling as "I/O" stereotyped classes with attributes but no operations) describe things that flow into or out of the system, and can, in the general system case, include data, mass, energy, or physical parts. I/O entities are associated (during modeling) with actor-system pairs, indicating that these particular I/O entities flow between actor and system. They can optionally be shown on the diagrams, associated with the actor, and the direction of flow is indicated by a stereotype "send"or "receive" on the association, indicating the direction relative to the actor.

A System Operation is a service that can be requested from an object to effect behavior. An operation specifies the name, type, parameters, and constraints for invoking an associated behavior. The Operations are grouped around interfaces along the main responsibilities of the (sub)system under consideration. A system operation invocation represents a finer grained interaction with the system than a use-case instance, and a use-case instance is a composition of operation invocations and responses.

State variables and stores are attributes defined on the interfaces realized by the system. These are abstract and require that the system maintain information corresponding to the type and multiplicity of the attribute and permit storage, retrieval and modification of that information. There is no implication that there an attribute in the system directly corresponds to the attribute defined at the interface. The difference between state variables and stores is not intrinsic, it just reflects the way the attributes are used to control the operation of the system's (abstract) state machine. A "state" persists over a period of time, unlike an event (such as the arrival of a signal) that occurs at a point in time. The state machines mentioned here are finite state machines, and the delineation of "state" is usually decided by relatively few variables; for example, the current state could be specified by the value of a single attribute of an enumeration type. The reaction of the system however, to an event, might depend not only on the nature of the event (and the information it carries, for example, in the operation parameters), and the current state, but also on the value of (perhaps many) other attributes.

As you evolve and add more detail to the Use-Case Model (discovering the business actors; or if actors and perhaps operations have already been identified, elaborating their interaction), you can create the initial collaboration and illustrate this with a Context Diagram. The Context Diagram can be created as shown, initially with the system interfaces abstracted away. The system is depicted as a top-level subsystem (stereotyped "system"), which eventually realizes several interfaces. Business actors and their associations are also shown, again, with no detail initially.

Next, you refine the associations between the business actors and system, and the system interface. You can start to reason about the system operations and the system attributes as they emerge from Task: Find Business Actors and Use Cases. Later you can use Task: Detail a Business Use Case). Note that now the system as it appears to the actors, by showing the interface. The realization of this can be shown if you wish, but can be omitted without much loss of information.

At this stage, only tentatively identify the I/O business entities, based on domain knowledge and any work done previously in realizing business use cases at the enterprise level. Note that it is not required that the I/O business entities be shown on the diagram, but this can be helpful in reasoning about actor-system interactions.

Thus, you can start to characterize the connection(s) between actor and system (for example, record the protocol required) and record the entities that flow between them.

In this step, you start to construct business use-case scenarios (instances of use cases) from which you can describe business system operations (provided and required). The scenarios can be illustrated by interaction or activity diagrams. Each black-box step in a use case represents a finer-grained interaction with the system and maps to a operation invocation (but not necessarily a unique operation; other black-box steps might use the same operation). As well as defining the system operations in the Context Diagram (and hence in the Business Analysis Model), the use cases are also annotated, for traceability, to the operations invoked. The operations also inherit any performance requirements or other non-functional requirements that have been allocated to the black-box steps. As you examine each black-box step performed in the scenario, you discover the use of names that might suggest state variables and stores that the system must maintain to execute the use-case scenario. You can also refine the I/O business entities that are required and associate these with operation invocations to form the signals sent between actor and system. 

It might aid understanding to divide the system interface into more specific interfaces; indeed, there can be interface requirements in the Business Supplementary Specification which drive this. The illustration below shows the evolution of the system interface into a "provided system interface" for each actor type, although this is not a fixed prescription. Actors might share an interface, or there could be more than one interface for an actor.

This analysis might also identify interfaces required by the system, that is, interfaces that must be supported by the business actors (to process messages from the system). These can be added to the diagram in a symmetrical way. A business actor might support (realize) more than one interface.

The operations, stores and so forth., need to be added to an expanded form of the interfaces (in the attribute and operation compartments) as shown. Again, the realization of the provided system interfaces can be omitted without much loss of information.

This top-level collaboration, captured in the Context Diagram, allows the interfaces, connections, what flows into and out of the system, and associated performance characteristics, to be rigorously specified.