• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

actor in system interactions

 
Ranch Hand
Posts: 765
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

In my case; my system (A) is publishing a web service which another system (B) invokes to make payment. There is a series of interactions between A and B where A fullfill demands/needs of B by providing required services.

My question here: Whether system B can be shown as ACTOR in Use Case ?

Bye
Viki
 
Vikrama Sanjeeva
Ranch Hand
Posts: 765
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Somebody can help here ?
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd say: sure, no problem. Actors can be anything external to your system that initiates an interaction. If you're trying to model system A, that sounds like what you're describing.
 
Bartender
Posts: 1201
22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Matthew Brown wrote:I'd say: sure, no problem. Actors can be anything external to your system that initiates an interaction. If you're trying to model system A, that sounds like what you're describing.



I agree and I've done exactly that in the past. However, I'd also point out that you might want document some use cases of the complete system (yours plus the other system). That way you can verify that the combined system really will be satisfying some end-user requirements. This practice is more useful when you're developing the "other" system or at least have the ability to influence the design of it. The practice of developing use cases for the combined system is relatively less useful when the other system is already set in stone.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Ryan McGuire wrote:However, I'd also point out that you might want document some use cases of the complete system (yours plus the other system).


Very true - I almost mentioned that, then decided to keep things simple. Be clear about the scope of the system you're analyising (System A, System B, System A + B), and your actors should be external to that.
 
Vikrama Sanjeeva
Ranch Hand
Posts: 765
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

In my case; System B is completely a separate System. Actually, we own System A which provides payment services by publishing required Web Services. Whereas other systems (B1,B2,Bn) integrates with System A in order to make payments.

After above replies, I am concluding that System B can be shown as (Primary) Actor as it will be the one who will be initiating interaction (s) with System A.

Bye
Viki
 
Surfs up space ponies, I'm making gravy without this lumpy, tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic