Using Unified Modeling Language (UML) for modeling business systems enhances communication between software developers, domain experts and other professionals with different backgrounds. UML defines a standard notation for object-oriented systems. However, UML does not specify how to structure the information describing the business system, nor does it specify which diagrams to include in the business models or what the relationships between various models are. This paper introduces a pattern of four models that can be used for description of business systems with UML. The pattern is based on models that describe classifier relationships, interactions, responsibilities and state machines. The application of the pattern can easily be extended to cover information about the business system in different views and on different levels of abstraction.

To define the behavior of the business system, some methods suggest describing scenarios or workflows, and other methods suggest creating sequence diagrams or data flow diagrams. Which is the correct approach? To answer this question, we must realize that there is a difference between a business model and its representation. The model determines the information about the business system, and the representation determines how the information is presented. For example, the behavior mentioned above is determined by the interaction model or by the state model. In UML, the interaction model can be represented by a set of sequence diagrams or a set of collaboration diagrams. The state model can be represented by a statechart diagram, an activity diagram or a state transition table.

A useful description of a business system is based on precisely defined models, rather than on diagrams. This paper introduces a simple structure of the business system models, which can easily be traced to the more detailed software architecture and the design of the product.

Software products can be described at various levels of abstraction and from various views. Some examples of levels of abstraction are the domain level, system level and the architectural level. Some examples of views are the use case view, the logical view and the implementation view. At each level of abstraction and in each view, the business system can be described by four artifacts: static relationships between classifiers, dynamic interactions between classifiers, classifier responsibilities and classifier state machines. Each of these artifacts can be represented either by UML diagrams or by text. The pattern is illustrated in Fig. 1.

The classifier model, classifier interaction model, classifier and classifier state model in Fig. 1 represent types. They define the structure and the relationships of model instances, which contain the actual information about the business system. A model can consist of a large number of instances. For example, a business object model can consist of several static structure diagrams, each of them representing small parts of a problem domain; an interaction model can consist of many interaction diagrams describing various business scenarios.

The classifier interaction model specifies interactions between classifiers. The classifier interaction model can be represented by sequence diagrams or collaboration diagrams. The UML Notation Guide describes only interaction diagrams in which classifiers are objects; it does not describe interaction diagrams in which classifiers are use cases or other classifiers. Use case interaction model is discussed in section 5 of this paper.

The model called classifier specifies classifier responsibilities, roles, and static properties of classifier interfaces (for example, a list of classifier operations with preconditions and postconditions). Classifiers can be represented by structured text, for example, in the form of a CRC card.

The classifier state model specifies classifier state machine and dynamic properties of classifier interfaces (for example, the allowable order operations and events). The classifier state model can be represented by a statechart diagram, an activity diagram, a state transition table and Backus-Naur form.

An instance of the classifier model can be linked to several instances of the classifier interaction model. All of these instances are linked to instances of the classifier. An instance of the classifier is linked to an instance of the classifier state model.

Fig. 2 shows the pattern applied in use case view and logical view, and at domain level and system level of abstraction, because they are the most relevant for business processes and UML is intended preferably to be used in these areas.

The domain level describes the business system in terms of domain objects and their interactions. The description of the business system at the domain level is independent from the future implementation of the system. The domain level specifies responsibilities of the domain objects, their static relationships, and dynamic interactions. Business processes, generalized scenarios and collaborations between domain objects are specified by domain level use cases, domain use case interaction models and domain use case activity models. Domain use cases have "organization" scope (see reference [1]), in contrast to the system use cases, which have the scope of the software product being designed.

The domain object model specifies static relationships between domain objects. The domain object interaction model specifies interactions between domain objects, which are instances of domain use cases. The domain object specifies responsibilities, and roles of domain objects, as well as static properties of their interfaces (for example, a list of object services). The domain object state model specifies behavior of domain objects and dynamic properties of their interfaces, for example, the allowable order of object services or the allowable order of events that the object responds to.

The domain use case activity model specifies behavior of the domain object within the scope of the domain use case. The domain use case activity model can divide potentially complex state model of the domain object into several activity models of its use cases, which can be simpler. Activities in the domain use case activity model can be refined into use cases on the system level. In this way the domain use case activity model can specify the allowable order of system use cases.

The domain use case interaction model specifies typical sequences of use case instances. In contrast to the domain object interaction model, where a scenario is described as a sequence of messages, the use case interaction model describes the scenario as a sequence of use cases. Similarly to the use case activity model, the use case interaction model can describe a scenario consisting of other scenarios. The difference between these two models is that the use case activity model completely describes the domain object behavior within the use case, and it is related to the domain use case. The use case interaction model describes only typical scenarios, consisting of domain use cases, and it is related to the domain use case model.

The dependency with the stereotype «collaborations» in Fig. 2 indicates that the domain use case model specifies collaborations between domain objects. The dependency with the stereotype «instance» indicates that interactions between domain objects are instances of domain use cases. A dependency with the stereotype «refine» indicates that the system, the system model, the system interaction model and the system state model represent software design of the package of domain objects. The dependency with the stereotype «realize» indicates that the system, the system model, the system interaction model and the system state model represents realization of the domain use case.

The system level describes the context of the system (software product) or, the software design of the package of the domain objects. The system level specifies responsibilities, static relationships and dynamic interactions of the software product and the systems that collaborate with it.

The system model specifies static relationships between the software product and collaborating systems. The system use case model describes use cases with system scope and their relationships to collaborating systems. The system use cases are collaborations between the software product and other systems. The system interaction model describes interactions between the software product and collaborating systems. These interactions are instances of system use cases. The system specifies system responsibilities, roles and static properties of system interfaces (for example, a list of system operations and events). Other instances of this model can represent responsibilities of external systems and actors, if they are relevant. The system state model specifies behavior of the system and dynamic properties of system interface, for example, the allowable order of system operations and events.

The system use case describes responsibilities of a use case with system scope. This model specifies static properties of the use case, for example, use case goal, pre- and postconditions, list of subsystem operations that are called within this use case, or a list of objects and attributes that are accessed or modified by the use case. The system use case activity model specifies behavior of the system within the scope of the use case. The system use case activity model specifies system state transitions and the allowable order of system operations and events, which are relevant for this use case. The system use case interaction model specifies typical sequences of system use case instances.

The structure of models described above can be extended towards the design of the software product. The tier level specifies system layers, their relationships and interactions. The architectural level describes subsystems, software modules and physical devices inside the layer and their static relationships and dynamic interactions. The class level describes classes and objects, their relationships and interactions, and the procedural level describes procedures and their algorithms. Reference [3] describes application of the pattern at the architectural, class and procedural levels of abstraction.

The system of models discussed in this section can be simplified in various ways. Typically, instances of models are separate documents. However, there might be pragmatic reasons for creating documents containing several closely related models. For instance, classifier responsibilities and state machines can be joined into one document. It is also possible to join domain and system use case models to one use case diagram, providing that use case levels and relationships between use cases and classifiers are clearly distinguished. It might also be reasonable to create one static structure model within each level and show static relationships between use cases, actors and objects in one diagram, although the UML Notation Guide does not mention such a combined static structure diagram. Simple software products are often described sufficiently using only several of the models discussed in this section. However, it is quite important to specify clearly which models are produced and which aspects of the system are documented.

Use case interaction diagrams can represent scenarios consisting of sequences of use cases. An actor can use a system in a way that initiates use cases in a particular order. Such a scenario – a sequence of use cases – can provide useful information about the business system. It can represent, for example, a business process consisting of other business processes.

Use case interaction diagrams are sequence and collaboration diagrams in which classifier roles are use case roles. Use case interaction diagrams are not explicitly mentioned in the UML Notation Guide (see reference [4]), although they conform the UML Semantics (see reference [5]) and follow the concept of the instance interaction diagrams in UML. Unlike other instances in UML, use case instances can interact only with actors and not with each other. Also, they are always initiated by a signal from the actor. Therefore, the label invoke in Fig. 3 means that an actor can invoke a use case while executing another use case. Invocations on the diagram map to signals from an actor to a use case and to static relationships between use cases: generalizations «uses» and «extends», dependencies «invokes» and «precedes», or constraints {invokes} and {precedes}.

Please note that the complete behavior (not just scenarios) of a specific use case can be described in activity or state diagrams in which states or action states map to subordinate use cases.

This paper introduced a structure of models that can be used to document business systems using UML. The structure is based on a pattern of four mutually related models that represent classifier relationships, interactions, responsibilities and state machines. The paper outlined purpose, relationships and representation of these models. Application of the pattern helped to identify use case interaction diagrams, which describe nested business processes and which are not documented in the UML Notation Guide.