My question is, which of these things are shown on the business use case diagram as actors:

1. The stakeholder of the use case?
2. The owner of the use case artifacts?
3. The workers in the use case?
4. The inputs to the use case?
5. The outputs from the use case?"

Reading between the lines, we want to be able to generate our own RUP like diagrams, using UML and Rose doing Business Modeling.

1) Analysis:

• Input - textual requirements
• Worker - Systems analyst
• Output - Analysis model
• Users - Testers, architects, customer.

2) High level design:

• Input - Analysis model
• worker - Architect
• Output - High level design model
• Users - Designers, testers.

3) Detailed design:

• Input - High level design model
• Workers- Designer
• Output - Detailed design model
• Users - Programmers.

Where do you show workers? How do you indicate inputs and outputs? Who are the initiators? Are there physical systems that you would include in the model?"

Business Actors are those people, organisations etc that are outside of the Business Boundary under investigation. This boundary can take many forms and here are some examples of some boundaries and possible business actors.

• The boundary is the entire organisation : Customers, other companies such as Vendors, Government Bodies, Review Bodies - people who are not employed in the business.
• The boundary is a department : Customers (only if direct contact), other departments, other companies etc
• The boundary is a team : other teams, departments, etc.
• If a person is inside of the boundary then they are a worker (whether manual or automated)

So from your list, I would say at best the stakeholder may be shown on the Business UC Diagram but given your definition, they are more of a Business Model Reviewer. If the stakeholder is within the boundary then they are a worker. The question to ask is "Who gets the value outside of the boundary?" It is these folks that are the actors."

Simon Bennett added; "It seems to me that there are two things getting mixed up here. Business use cases and business process modelling using use cases.

My understanding is that business use case modelling is something akin to context diagrams or top-level data flow diagrams (without the data flows or data stores). The actors here are people, organisations and systems outside the scope of the business system being modelled; the use cases deliver something of value to them. So actors are things like Customer, Supplier, Bank Automated Clearing System etc. The people who do the work inside the business are hidden away inside the use cases that represent business processes. When you model the internal system and the use cases are provided by an information system, then the actors are the people who work with that system. Of course some actors will be the same in both types of diagrams (particularly public information systems with business actors who interact directly with the system).

In 'The Object Advantage' (Jacobson, Eriksson and Jacobson, 1995) use cases are used as part of a business process reengineering process, and it sounds to me as though that is closer to what you want, Leslie. I read the book a while back and haven't got it with me here at work, so can't check this out. In this approach use cases are used to model the business processes within the organisation rather than viewed from the outside, but they include processes that are not necessarily part of some information system. (In the days of data flow diagrams, we used to draw logical DFDs that included processes that weren't necessarily going to be computerised, and part of the design process was determining the boundary of the computer system.)

Regardless of the above, I'd say (4) Inputs and (5) Outputs are not shown as actors in a use case diagram.

It seems to me that what you want, Leslie, is to be modelling your business processes in more graphical detail than is provided by use cases. Why not use stereotyped activity diagrams, as are used in the RUP, to model the various participants, the activities and the inputs and outputs?

Hüseyin Angay also replied: "If all these workers are playing some role in the use case, they are all workers. It sounds like you need to make them all business workers, but then stereotype them as 'Stakeholder', 'Owner' and 'Developer' to differentiate them.


Now, from your description, I would consider a second strategy of documenting this: Write one or more general use cases that describe how a general activity is performed and the interaction between Stakeholder, Owner and Developer. Use some placeholder keywords where activity-specific actions happen. Document the activities separately in a table, say, describing the specifics for each keyword from the use case.

Simple contrived example:

Use Case:

Review:

• Stakeholder places ~document~ on server.
• Owner assigns a developer to the document.
• Developer reviews document and produces a ~review document~.
• Owner approves and passes the review document to the Stakeholder.

Specifics
~Use case review:~
Document: Describe the use case template here.
Review document: Describe the use case review template here.

• Location: place on R:\Use Cases\
• Assigned to: Peer Analyst
• Describe quality criteria for use case review. Must be done within three days of the assignment.
• Location: place on R:\Use Case Reviews\ Must be done within one day after the review.

~Code review:~
Document: Describe source file here.
Review document: Describe the code review template here.

• Location: place on R:\Source Code\
• Assigned to: Peer Coder
• Describe quality criteria for code review. Must be done within five days of the assignment. 
• Location: place on R:\Source Code Reviews\ Must be done within one day after the review.
   

Richard Howlett added; "Not all stakeholders interact directly with the business. Those that do, such as customers (i.e. those with goals your business helps to realize) and business partners should of course be included. I would consider the owner of the use case artifacts as the Process Owner. No need to show him or her in the model, apart from as a note. I suggest including business workers in Activity Diagrams, equivalent to Alistair Cockburn's White Box Business Use Case concept. The input and outputs can also be shown in the Activity model, as object flows coming in and going out of activities.

Now in the use case description you can have a section that describes how each business use case 'protects the interests' of stakeholders."

"1) Analysis:

• Input - textual requirements
• Worker - Systems analyst
• Output - Analysis model
• Users - Testers, architects, customer."

Tools for diagramming

Tools can be frustrating. Short of creating all the Icons in something like Visio which would be very time consuming for this purpose, we've tried to just pick some of the features in each tool to show a concept.

In most of the diagrams in this essay, we used Rational Rose, but it does not have the ability to draw in boundaries. So the diagram below, we used a tool called Enterprise Architect from Sparxystems to diagram a sample Use Case to highlight the Boundaries one can use. We used this tool because it does boundaries nicely, but it didn't allow us to change the visual icon according to the stereotype of Business Worker. It also did not have the concept of a business Use Case Versus a Systems Use Case.

So apologies for any confusion, but the concept we are trying to show here are the different levels of boundary with which you could choose to model your diagram. We have;

• outside the Company and inside the Company.
• Separately we could also have different Departments such as Marketing Department and IT Department.
• Within the IT department we could choose to model at a team level. IT requirements Team and IT Environment Team.

We are not suggesting you use all these boundaries in your model, pick only one set and make your actor stereotypes relative to that set. Inside the boundary use a Business Worker Icon and out side the Boundary use a Business Actor Icon.

Diagram 0. Here we try and show the alternative sets of boundaries one could choose between for your business model.

Assumptions for this Model

In this example, the assumption is that the Business Actors are external to the whole IT department of the business. So the context is inside the IT department we have Business workers and outside the IT department we have Business Actors such as Customer (they could come from some other department within our company or from some other company outside our company.)

We could have had the context line being drawn around each It Department Team, so that each Actor in the team would be a Business Worker and each Actor outside the team would be an Actor. This may be a better way to model the process, just to define the boundaries a little tighter. We haven't chosen to do so here.