0

Imagine the main system with the following use cases : one person may register, and book a room.

At the same time there is a mobile app which is derived from the main system which is enabling the same functions (register, book a room) with some added use case options.

How to distinct these two systems in a same use-case diagram?

  • It's not clear when you write "use case options", if you mean additional use cases, or if you mean optional behavior/features. Could you provide an example ? – Christophe Dec 28 '16 at 16:24
1

In the UML 2.5 specification, Figure 18.2 in section 18.1.5 is an example of what you want to do:

Use Case with a Subsystem

As you can see, you can show packages and subsystems, as necessary, on a UML Use Case Diagram. In your case, you likely wouldn't have the package, but you would have system boundary boxes identified and annotated as subsystems.

There are a few things to keep in mind:

Each Use Case diagram should show a system. If you have what is really two or more systems, you will want a use case diagram for each system. How you define what the "system" is versus what the "subsystem" depends on what you are building. You may want to define the software you are looking at as two systems or one system with at least two subsystems.

You may also be interested in a question about polymorphism in use cases and my answer to it. There are good methods for showing relationships between use cases that are part of the formal UML specification. There aren't ways to show relationships between actors, however, unless you don't care about following the specification.

  • About generalization relation between actors, note that an actor is a behaviored classifier (UML 2.5 §18.2.1, and behaviored classifiers allow generalization). You might have adifferent opinion, but use of generalization is quite common as explained for this SO question, in this article and on this website dedicated to UML-(just in case that you'd have downvoted my answer for this reason). – Christophe Dec 23 '16 at 12:35
  • @Christophe From 18.2.1.4: An Actor can only have Associations to UseCases, Components, and Classes. My understanding was that a Generalizations was a specific type of Association, so I read that statement as removing the ability for one Actor to generalize another Actor, even though an Actor is a BehavioredClassifier. I'd like to be misreading that statement in 18.2.1.4, since the ability to show relationships between actors is incredibly useful. – Thomas Owens Dec 23 '16 at 15:00
  • i fully agree with you : it's not fully clear if the enumeration is meant to be restrictive, or if the classifier's relations are implicitly allowed. Still some room for improvement in the standard ;-) – Christophe Dec 23 '16 at 16:15
1

The use case diagram shows use cases offered to actors by the system under consideration.

In principle it should not represent the technical distribution of functionality across processing nodes: this is for the deployment diagram.

Case 1 The mobile UI belongs to the system under consideration

The assumption here, is that you have only one system with potentially several front ends offering each a different set of use cases. You could then consider using two actors: user and mobile user. You could then:

  • either link each of the two to the relevant use cases (more precised and preferred approach);
  • or, if a mobile user can always do everything a user can do, you could represent an inheritance relation between both actors to avoid cluttering the diagram with too much duplicate links (even if this is not explicitly allowed, an actor is a classifier according to UML2.5 §18.2.1, and as illustrated here)

Example:

enter image description here

Variant of case 1:

If the common use cases shall exhibit some differences in features or in user interface, you could simply document this in the narrative of the use cases.

If however you want to show optional behaviors in the diagram, you could think of extending use cases. Extensions allow to show a variant to the normal flow and to document in a comment note the condition of such an extension to occur.

Keep nevertheless in mind, that UML use case diagrams should not be abused for functional decomposition. Lots of inclusions or UI specific extension could be a symptom of such abuse. So ask yourself if you really need this level of detail in the diagram.

Case 2: The mobile app to be a system on its own

If you have two systems that have to be considered as distinct from each other (for example if the booking system is operated by a third party), then you need distinct use case diagrams (one for each system).

In the diagram of the mobile app, you'd show the remote system as a secondary actor (and materialize its involvement in the use cases with additional links).

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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