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: Artifact: Business Use Case Model, Artifact: 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
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.
Create initial Context Diagram
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.
Refine associations and interfaces
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.
Detail business Operations and other characteristics
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.