2

I am currently in the process of creating a use case digram for a new system that we are building and have stumbled upon an interesting scenario.

The system has a number of primary actors which include Corporate and Non-Corporate users. Each of these users can “do something” within the system from a variety of different device types which may or may not be under the direct control of my company:

  • A corporate user could “do something” from a corporate Managed device or their personal device.

  • A non-corporate user could “do something” from their device which is “unmanaged” by my company.

How do I show this relationship on the use case digram? The combination of actor and device type is a fundamental consideration for the design of the system.

Currently I have settled on “managed device user” and “unmanaged device user” with the view of articulating all the possible combinations on a separate artefact perhaps within the actor descriptions tab. Others say I should have the device as an actor on the use case.

current

I could have “corporate user” “non corporate user” and “device” as 3 actors on the system. I’m not precious, I just want to make sure it’s correct.

alternative

So which is the most suitable approach ?

Christophe
  • 74,672
  • 10
  • 115
  • 187
CyberGav
  • 23
  • 2
  • Just put the 2ndary actor to the right of the boundary. That's a common convention. –  Apr 27 '20 at 13:45
  • It rather depends on where is the boundary of the system you are developing. Are the devices inside the system or outside it? If they are outside, then they are actors. But if the devices are the actors, then do the users interact with your system at all? – Simon B Apr 27 '20 at 13:50
  • Thank you both. I will update the original post as per your note below Simon when I return to my laptop. Different user types (employees and lets say external contract staff) will connect to the system using a variety of device types. Both are external to the application. The goal for me is to express that different users, on different device types need to be catered for and there will be fundamental differences based on the combinations when they do something on the system. Talking it through, it feels like the device is an actor alongside the users. – CyberGav Apr 27 '20 at 14:49
  • How does the difference between a managed and unmanaged device affect your system? Is it in the authorization (unmanaged device is not trusted to be securely locked, so you need an additional login when accessing the system), or in the functionality you offer? Can anyone get a managed device, or is there an implicit assumption that managed device == own employee? – Bart van Ingen Schenau Apr 27 '20 at 15:21
  • Let me use your Auth example Bart as its a good one. Let’s say the system needs to make a decision regarding whether to provide a user with access to a resource or not. The system could check the identity of the user (are they internal or external) and the device type (BYOD or corporate managed) using this information the system could then make a decision as to the risk posture associated with the access request. In this instance both the user and device context are fundamental to the way the system will operate – CyberGav Apr 27 '20 at 15:43
  • In addition, where the device is not managed by my company and is a personal asset or one of a 3rd party contractor. The initial access / entrance to the system will be different I.e different functionality based on device type. – CyberGav Apr 27 '20 at 15:47
  • Just if you care to learn more: The book from Bittner/Spence about use cases is probably the best source you can get. –  Apr 27 '20 at 20:28

1 Answers1

3

Is it that simple?

From your narrative, I understand that:

  • you have one actor, User, with one use-case do something
  • the actor can be corporate or external (this sounds like a descriptive comment about the actor)
  • the actor may use a managed device or an unmanaged device (in your narrative, this sounds like a constraint for the association between the user and the use case)

Keep the diagram as simple as possible. Comments and constraints can be added to the use-case model without a combinatorial explosion.

More complex situation

Your diagram is certainly simplified. In a more complex model, it is probable that different actors would interact with different use cases.

A natural choice could be to have a corporate user and an external user, especially if these users would have different roles (e.g. external users are customers, or external stakeholders with a specific role).

Of course, it is possible that an internal user may not interact, or may interact slightly differently with a use-case if an unmanaged device is used. But this would stay a constraint as explained above.

Could devices influence the actors?

To the very dry and formal definition of UML 2.5 specs, I prefer the more understandable definition of Ivar Jacobson, the inventor of UC:

A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.

Consequence: the choice of use-cases should be driven by user goals. The device may influence what an actor can do in the interaction (e.g. dangerous operations forbidden on a smartphone because of the risk of error, or from an unmanaged device because of the security risk), but not what he/she may want to do.

In other words, devices are only means to interact with the system, that can constrain its use. But they do not define the goals of the user.

Final word

Ultimately, the goal-driven principle is only an advice. I insisted on it, because your narrative suggested that the real difference was between corporate and external users, and corporate users using unmanaged device are just constrained for technical reasons.

But UML doesn't require the use-cases to be goal driven. So if it makes sense to you, you may very well decide to go on with your first diagram. This is legit ans is also used when different user-interfaces offer different functionalities.

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • Thank you for taking the time to respond. The diagram above is indeed an incredibly simple abstraction of the one I am working on. Let’s explore the more complex model you have above. Both corporate and external users will indeed share some common functionality within the system and have some functionality that is unique to them. Would your position on the devices stay the same or change if depending on the device type, the functionality of the system may be different? I.e. corporate user on their own device may see a registration page, a Corporate user on a company device would not – CyberGav Apr 27 '20 at 15:54
  • @CyberGav I have edited to clarify my position and add some thoughts. Personally I'd stick to the device independent approach. But ultimately, UML is a tool that is meant to serve your modelling needs. – Christophe Apr 27 '20 at 18:05
  • Thank you for taking the time to answer and update my post. Your time is greatly appreciated. – CyberGav Apr 27 '20 at 18:20