Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Use cases are primarily meant for interaction between user and a system. It could be used for interaction between system and another system. The actors are primarily roles.

It is easy to document the use cases for a front end application like a portal where in all the activities and role performing the activity could be defined. However if the system is an order management or provisioning system which a downstream system how could the use cases be documented?

For eg: An order management application may responsible for processing orders for type new install , change of service , cancel , reschedule , suspend , restart etc.These transactions could be triggered by from different sources by different means (service call , entry placed in db which OM application polls , order placed in jms queue - however I assume these have no relation to use case). Once an order is received Order Management application might have to interact with different applications (credit check , shipping , provisioning , activation , billing etc) depending on the order type.

EDIT: ADDED MORE INFO

I have an application that receives data from an upstream application. My application consumes webservices exposed by multiple other applications in order to fulfill a task. The data flows through multiple applications before reaching the upstream system which sends messages to my application. The activities that my application does are install, disconnect , suspend, restore etc using multiple services that it consumes.

When I read posts on having system as actors, the primary aim seems to be demarcating and defining the interfaces properly. In the scenario above assuming the upstream system is A, my application is B and the applications that my application consumes are C, D, and E.

1) My aplication performs install , disconnect , restrat and suspend. Are these the activities? 2) Will the primary actor be the system sending messages to my application? I can't think of this as a role and also there no interaction between the upstream application and my application after the point when my application recieves a message. 3) How can I define the external applications that my application consumes? as actor or activity? or i need not care about these in use case diagram?

When you take an interaction between user and a system for shopping a product - you will list the series of interations between you and the software. However what software does internally is not specified.

Here in my case , since it is a downstream system , the upstream system sends only one message and there is no series of interaction. Hence I am in a quandry as to how I should define the scenarios.

share|improve this question
1  
The user of a downstream system is the upstream system. Write your use cases identifying the upstream system as the user. Sounds silly, but it works. –  Robert Harvey Feb 13 '13 at 17:40
    
One of the challanges of working in downstream system is that the specific system in question could be multiple levels lower in the rung. For instance , the data might be flowing through 5 different applications before reaching the provisioning application. So the developer / designer in provisioning system might not know the roles of actual users who placed the order. The designer in provisioning system might just know the immediate upstream systems which send the data across. I am not sure if it is a valid challenge , but this is something that I have faced in very large organizations. –  Punter Vicky Feb 13 '13 at 19:35
    
@Punter - I suspect that you are trying to mix different "levels" of use-cases and that is causing you confusion. If you want to capture the use-cases that include ALL the various applications then you need to create use-cases(generally a totally separate document) that are "enterprise" level use-cases. Those use-cases only talk about enterprise level interactions. Not low level stuff. If you are trying to define use-cases for the application you are building then you only care about the interactions that directly affect your application. So you would write your "application" level use-cases. –  Dunk Feb 19 '13 at 15:46
    
Although rare, I do from time to time run into situations where it is appropriate to write "module" level use-cases. Each level of use-case is distinct and separate from the other level of use-cases, although the higher level use-cases may help identify the use-cases for the lower level use-cases. But when writing use-cases you only care about the direct interactions for the level you are concerned with. –  Dunk Feb 19 '13 at 15:49

1 Answer 1

For a use case the Actor can easily be a:

  • User
  • System (self-reference)
  • System (external reference)
  • ... (I'm sure there's others I'm not thinking of right now)

The problem that you're running into is that you are assuming that an Actor can only be a User. In reality, the Actor is just the agent that triggers some sequence of events. System to System use cases are quite common, and are the solution to your challenge.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.