|Representation Options||UML Representation: Collaboration, stereotyped as <<business use-case realization>>
In many cases, the focus of this work product is the activity diagram, in which you define what responsibilities belong
to which business system or business worker, by using swimlanes. This is where you make key decisions about what to
automate. Often, the Business Use-Case Realization Specification with the textual properties of the work product can
then be excluded, and any derived requirements can go in the Supplementary Business Specification instead. Activity diagrams can
also indicate the sending and receiving of business events between business workers.
If the Business Use Cases themselves will not be modified, but instead the realization of the Business Use Cases will
change, the Business Use-Case Realizations can be used to compare current (as-is) process descriptions with target
(to-be) process descriptions. For example, imagine that an existing software system is going to be replaced by a
standard software product that will be administered by an external partner. In such a case, Business Use-Case
Realizations can be used to assess the impact of this change on the organization.
Because Business Use-Case Realizations are generally more detailed and specific than Business Use Cases, they can also
be used to illustrate differences between different contexts of a more abstract Business Use Case. For example,
consider the case in which customers must be serviced using different communication channels (Internet, call center,
mail, or electronic messaging, for example). The steps performed during a business use-case Request Quotation or Accept
Proposal will remain unchanged, but the ways in which this business use case is performed will differ for
each channel. Business Use-Case Realizations can be used to illustrate channel-specific realization of the
business use case.
Recall that Business Use Cases are triggered either by Business Actors or by internal Business Events, through the
invocation of one or more services provided by the business - invocation that occurs externally in the case of the
Business Actor, and internally in the case of the Business Event. A service comprises one or more business operations
(see Artifact: Business Operation), so that a Business Use-Case Realization is the
overlay of all required business operation realizations (see Artifact: Business Operation Realization). This can be modeled as a large collaboration (the Business Use-Case Realization)
which is built from smaller ones (the business operation realizations). Note though that the Business Use-Case
Realization does not 'own' the business operation realizations - they may, and very likely will, show up in other
Business Use-Case Realizations.
Note that there is no reason why you should not model some services provided by the business as private - they
represent actions the business may ask of itself (when servicing a Business Event, for example) - but which are not
available to a Business Actor.