4

Imagine that we are building a Library system. Our use cases might be

  • Borrow book
  • Look up book
  • Manage membership

Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.

  1. Should we draw different use case realizations for different flows? If not, it is very different to borrow a book from a machine and a person. How can we handle it?
  2. Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
  3. What would you use to realize use cases and why?

It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.

bomberman
  • 142
  • 10
  • 1
    Do you want to know what the UML and/or SysML standards prescribe in this respect? Note that they are not methods, but notations. Although UML has something called "realization", it does not explicitly apply this to use cases. The term "use case realization" comes from the Rational Unified Process, or nowadays Open Unified Process. Do you want to have an answer in terms of these methodologies? Do you use a specific methodology? – www.admiraalit.nl Jan 26 '22 at 07:57
  • It is valuable to mention Rational Unified Process here. And, in fact, you are right about UML/SysML being notations. Thank you for that. I was probably applying something very similar to RUP without knowing the name. And it would be good to know if RUP has a specific explanation for the issue. By the way, are there any other notable methodologies to mention? – bomberman Jan 27 '22 at 06:08
  • I don't know any other methodology that gives guidance on how to apply UML. – www.admiraalit.nl Jan 27 '22 at 07:31

3 Answers3

2

There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.

The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.

A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.

It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.

A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.

Now, let me answer you questions one by one.

Question 1.

If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.

However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.

Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.

You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.

Question 2.

Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.

Question 3.

For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.

For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.

For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.

www.admiraalit.nl
  • 5,768
  • 1
  • 17
  • 32
  • Thank you for this elaborated answer. When I think of a white box, I feel like I have to refine details of the interactions. So I want to clarify where do we put this extra implementation detail. By saying that *there are two possible input devices inside that single realization* I assume you add a note in the realization; and this should be a requirement for the software and we need to be able to trace back to this note. So, I would need to draw 2 dynamic diagrams somehow connected to that note showing I have 2 different ways of implementing this keyboard functionality, right? – bomberman Jan 27 '22 at 06:56
  • 1
    Yes, you may use notes, but you could also use classes. For example, the use case realization could consist of a class diagram with classes Keyboard and TouchScreen inheriting from class InputDevice, plus a sequence diagram where the InputDevice is used as a lifeline. – www.admiraalit.nl Jan 27 '22 at 07:37
1

UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:

  • Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
  • Have different models for different stage and keep them all up to date
  • Have successive models, without updating the previous stages.
  • keep only a high level design model to get the big picture, but without implementation details that could be found in the code.

Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.

By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thank you for the recommendations and the book. It seems illogical to not have different models for the same project. And for the second option I am not sure how can I define different alternatives in packages. I feel like when someone opens the project on some tool it should be able to grasp at least the main objective of the project. So I am assuming I need one use case diagram here. After that if I have different realizations , do you suggest I make two separate diagrams for in different packages? – bomberman Jan 26 '22 at 06:57
  • @ozercik Indeed, fewer models are easier to manager, and if the models stay high level, they remain accurate for a longer time. But when you build a powerplant that will operate for 40 years, or design life-critical systems, you may have to invest more in modelling. Also, people using UML for visual programming with code generation or roundtrip engineering are constraint on their implementation model. THis is why ther is such a diversity. Moreover, if you use a drawing tool, you may just have three sets of diagrams. But when using modeling tools, you need some extra-care because the ... – Christophe Jan 26 '22 at 07:39
  • ... the tools really manipulate UML concepts, and when you create one class in one diagram, it keeps using the same class across the different diagrams. You therefore cannot use the same for 3 different designs if the classes in those designs have the same name. This is why I mentioned the packages, which are for UML tools like different folders, that may allow to consider several alternatives. So: what modeling tool do you use? Do you need to keep the alternative models once the decision is made? What will you use the "winning" alternative diagram for? – Christophe Jan 26 '22 at 07:49
  • It's important to have a clear idea on that because potentially, realizing a use case may require all kind of UML diagrams to capture its "internals". Typically you'd start with some sequence diagram for modelling the scenarios fulfilled by a use case (or an activity diagram if it involves some more complex workflow). But these essentials may then require class diagrams for the involved classes, and even state diagrams. – Christophe Jan 26 '22 at 08:16
  • I am using Enterprise Architect generally and have done some small projects. EA lets me connect nearly everything I wish and do not guide in the correct direction at all. When I draw use cases I realized them with a few sequence diagrams. But recently one of my projects got an update and I am all confused how to update the model. I am actually a software guy. I can represent this update in the software architecture (class diagrams and so on) much easier than system architecture (use cases and system flows). I feel like there should be a unique approach to design this part. – bomberman Jan 26 '22 at 08:59
  • @ozercik, if you want a standard approach, please have a look at the Open Unified Process: https://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/guidelines/uc_realizations_448DDA77.html – www.admiraalit.nl Jan 26 '22 at 10:03
  • 1
    @ozercik So, it's perfectly fine to realize a use-case with a couple of SD. Especially if those represent different scenario from the same use case. There is no problem in principle, since you'd use same classes with different messages and interactions. Or some classes may differ. But as long as it's the same system there is no major issue. If you try to show alternative realizations (question 1, i.e. one use case but 2 very different ways to handle them with different implementations-e.g should my class have this responsibility or this other as well?) you might have conflicts. – Christophe Jan 26 '22 at 18:26
  • 1
    (i.e. some names in common but with different meaning). There the package should help. If you enrich an existing use-case with a new scenario, no need for a packge: it's just an additional way to involve components/classes of the same system. If you update an existing scenario (e.g. old vs. new) then we come back to the general modeling approach: does your model only show the latest version? Or should you keep the old and the new (in which case you might again have incompatibility? – Christophe Jan 26 '22 at 18:31
  • Or would a staged model be more suitable: a production model and a development one, and when you release, you copy the relevant model elements? – Christophe Jan 26 '22 at 18:32
  • 1
    In the later case, would this question help you? https://stackoverflow.com/q/56879858/3723423 – Christophe Jan 26 '22 at 18:50
0

UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).

P.213 of UML 2.5 in paragraph 11.7 Collaborations:

The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.

A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • So, for example, sould I draw 2 different collaborations for, let's say "borrow book" use case like 1. borrow book by asking librarian and 2. borrow book using machine – bomberman Jan 26 '22 at 06:17
  • Then assume that our books had barcode previously and some new books which have RF tag. Then should we create 2 more collaborations ? (1 collaboration for each already existing collaboration) Or assume now our library have CDs as well. What would we do? – bomberman Jan 26 '22 at 07:03
  • It depends. Sounds more like different flows in a single UC where you branch to handlng the one or other. Different collabs is more like you implement it differently (e.g. for a PC and a handheld computer). A collaboration use will be used to show those partials like RF and bar code independently. – qwerty_so Jan 26 '22 at 09:28