umluse-casesysml

How to handle different implementations in SysML/UML?


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

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.


Solution

  • 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.