The Death of the Use Case
After killing the Actor in The Death of the Actor my next victim is the use case. Don’t use Use cases in SysML (or UML) models anymore!
My statement seems to be revolutionary or stupid (or both). Just to be not misunderstood, I’m not against the concept of use cases and actors. I believe that the SysML model elements Actor and UseCase are not necessary and useful. I’ve already explained it for the Actor in my previous post The Death of the Actor.
The definition of the use case in the OMG specification document is free of any method and only explains the language element UseCase. It depends on your modeling method how to use the use case. I use the modeling process SYSMOD which is not very specific, but more a collection of common best practices. In SYSMOD a use case has some additional information like trigger and result or pre- and postcondition. The functional details of an use case are described with activities. A typical use case diagram looks like this (again I use the forest fire detection system):
And the model structure with the activity behind the use case looks like this:
The use case contains the activity and both have the same name “Detect and report fire”. So why do we need the use case element? You could add additional information like the trigger and result to the activity element. And you could still create “use case diagrams” with real actors or blocks as actors (see The Death of the Actor):
If you are a big fan of the ellipse symbol, create a new stereotype “use case activity” and define the ellipse symbol for it. Then you can’t see any change in the diagram, but you have no actors and use case elements in the model.
Without use case elements
- automation scripts on the model are easier to implement (e.g. model checker, document generation, simulation).
- you have fewer elements for the configuration management.
- you have fewer elements for reviews.
- it is easier to navigate through the model tree.
Tim, slowly but surely you’re transforming the UML in an interesting case for CSI (Crime Scene Investigation). 😉
Seriously: every time I’ve modeled a use case and detailed it with an activity diagram, I noticed the redundancy and that the use case itself was reduced to a kind of “hollow construct”. An use case is of course an intermediate result in several analysis methodologies, like SYSMOD. And it is not necessarily said, that an use case MUST BE refined with an activity and an activity diagram! It can be refined with a sequence diagram, too. In some projects, it will be described with the help of structured text only (OK, that’s not really MBSE).
So, maybe we should think about the use case as a kind of stakeholder-compatible interim result required by the method?
In my modeling methodology I prefer to detail a use case with activities. I’ve rarely seen cases in practice where it was useful to use sequence diagrams or state machines. However you can do it. A sequence diagram, e.g. the interaction model element, or the statemachine could be used the same as the activity. You don’t need the use case modeling element. Although I repeat myself: you still need the use case concept!
What a revolution! :-). I’d like the idea of “killing” Use Cases in favor of Activities very much. I’m struggling anyhow to formally depict the relationship between a Use Case and an Activity with the same name (see the discussion on XING). But I can foresee some objection as well. In many organizations and groups, Use Cases have been “installed” and have been accepted as a core artifact used in requirement engineering. They are, perceivably, easily understood even by non-UML/SysML loaded stakeholders, as stick figures and ellipses allow for a rather simple depiction of a subject. Trying to take away those well established elements from those groups will probably present a challenge. But we like challenges, don’t we.
Innovation is always outside the comfort zone 😉
In theory the organisations and groups could still do use case analysis. They just use the activity model element instead of the use case element to model a use case. Like saying something in English instead of Swedish.
You can even fool them and give the activity the stereotype “use case” and an ellipse symbol.
In practice they will notice the difference and many people have problems to separate the different layers – like model semantic, model element semantic and model element notation. I think it is a core capability of a good modeler (and systems engineer) to be able to juggle with abstraction and aspect layers.
It’s for sure an interesting (and good) idea, but I have some concerns about it. First, I think the need to have an activity with the same name as the use case is a tool-dependent issue. For instance, in Enterprise Architect we don’t need this redundancy. I can fairly create an activity diagram under an use case, which I think it doesn’t violate UML specification. The use case is a behavioral element and could be detailed with any behavioral diagram (including an activity diagram). Second, what about parameters for that activity? Without parameters (and pins in call-behaviors) we miss the very point of using an activity in the first place, don’t we? It seems we’re simply throwing away the use case due to a constraint imposed by the tool being used. In my opinion, adding use case elements to your model doesn’t add that much complexity in scritps parsing it nor does it make it harder to navigate in the model tree. As a best practice, we should be able to navigate in our models via the diagrams (hyperlinks) and not using the model tree.
it is not allowed to create an activitiy diagram directly below an use case. Although it is possible in some modeling tools.
You always need an activity element to model actions, control flows, decision nodes, and so on. The activity must not be below
the use case in the tree, i.e. in the namespace of the use case. It is best practice, but you can also put the activity somewhere else
in the model. The activity is the behavior of the use case. That’s a different relationship.
You must clearly separate the diagrams and the model. The diagrams are not part of the repository. They are just views on the model.
I agree that you should be able to navigate through the model via the diagrams. I often use the diagram hyperlink feature provided by many
modeling tools to create paths through the model.
The diagrams are for the human model users and builders. Simulation, transformation or analysis scripts use the model repository only.
They also need a navigable model.
I’m really interested in this topic, because I’m a big fan of activity diagrams to detail use cases. But I have one concern yet. In your SYSMOD, you’ve used use cases and item flows in the associations with the actors to define the exchanges between the system and the environment (what I find great!). We could think on the same principle here, right? I mean, item flows in the associations between the actors and the <> activities. But then, wouldn’t you need to duplicate information by adding parameters to that activity that match exactly the item flows you’ve created in the BDD, so you can detail that <> activity in an activity diagram?
You made a very important point that diagrams are not part of the model. In another forum I suggested that OMG should categorize diagrams in a way other than structural vs. behavioral. I was thinking that some diagrams are good for examples (sequence dia.) and others are good for specification (class dia. and state chart). Another way to categorize along the same lines would be diagrams for model users and diagrams for model builders. Yet another characterization would be diagrams for validation and diagrams for specification.
It also occurred to me that it seems odd for two different Actors to have the same goal when interacting with the system. The Actors might be collaborating to accomplish a larger, common goal but that makes the Actors actually part of a larger system (they become Blocks in that larger context).
OTOH, the Actors might have the same goal but different capabilities. For example, Actors with disabilities need different access mechanisms to a building than unimpaired individuals. Same goal and therefore same use case but the Actors have different properties. This makes a lot of sense to me but I’ve only seen Actors that have different personal goals associated with use cases. The goal of the use case isn’t representing the goal of the Actor but the goal of the system in which the Actor is a part. So, as you suggest, Actor is probably better represented as a Block and Use Case as Activity. Still, the goal is lost in the transition from Use Case to Activity. The goal is implicit in the Activity but the Use Case declares it explicitly.
It seems to me that the proper usage of Use Case would require that there is only a single goal that is accomplished completely by the interactions with any single Actor. Each actor has the exact same goal but accomplishes it differently based on individual needs. If the goal requires more than one Actor, then the goal is not that of the users but of the system, itself. That’s the realm of Blocks, State Machines and Activities.
You might consider combining this article and the “dead Actor” article since the concepts are so closely related.
Thank you for the post. It sure made me think!
it is a very good idea to categorize diagrams. The categories structural and behavioral of the UML specification is one possibility.
SysML adds the requirements diagram that does not fit in one of these categories.
I like the feature of the modeling tool Enterprise Architect to show diagrams in a hand-written style. It looks really nice and
you could use it to show more informal diagrams. Formal diagrams, e.g. for simulation purposes, are shown in the classical style. There are different possible orthogonal sets of categories. Which one do you prefer?
I don’t understand your point that the goal is lost in the transition from Use Case to Activity. Where do I loose the goal? I think that we have
different understandings of the term “goal” in this context.
I like your idea to combine the article “death of the actor” and “death of the use case”. I’ll wait a bit for more comments and
then write an article that summarizes the articles and the comments.
I had good intentions about the idea of Use Case having a goal attribute but it doesn’t. I must have remembered that for non-UML description of use cases being a goal + scenarios (Cockburn?). Use Cases must have non-empty name attribute and perhaps the name is intended to be the goal (but then, why is it “name” and not “goal”?). It does seem that Use Case is redundant to Activity but Use Case is a Behaviored Classifier and Activity is a Behavior. Activities may have an associated context and in this usage the use case, with a name that specifies the goal, is the context.
In summary, a Use Case should communicate the goal of the Actor and that goal is the context for the (optional) Behavior(s). When I see an activity and ask why, the name of the associated Use Case should suffice to answer that question. The Use Case name should help to validate the Activity.
The example showed the Use Case and Activity having the same name. The Use Case name should be an outcome (achieve some outcome) and the Activity name should summarize the actions. It seems like the names would not normally be the same. The user is not trying to “detect fire and report.” The system is doing that in order to, perhaps, enable the user to “be aware of fires.”
I think key to the last part of your comment discussing the naming of the use case (uc) naturally depends on the viewpoint, from which the uc name is looked at. When naming a uc according to a goal or intention, the perspective would clearly be that of the initiating actor. I agree that in this case the activity should be named differently, indicating the corresponding actions of the system. But… Looking into the UML specification, a use case “represents a declaration of an offered behaviour”. IMO, this is clearly from the viewpoint of the system itself. The activity further details and specifies this offered behaviour, but still describes the same system aspect. With this in mind, assigning identical names to a use case can help to informally express this “relation”.
The SysML 1.3 spec implies the goal-case is primary and the offered-functionality case as secondary (see Section 14.1). I suppose the latter is different from Behavior in that it includes the context. In each case, the BehavioredClassifier provides context that is Actor dependent which is absent from the pure Behavior. Thus a uc is a BehavioredClassifier that has a relation to an external context element (Actor). However, I don’t see how this interpretation is specified explicitly in UML or SysML documents.
I’m open for both views about the uc, the system offerings as well as the actor’s intention/goal. Ultimately, for me it mainly matters when it comes to properly naming a uc. Here, in many situations, one may need to distinguish between the viewpoint.
In support of the system’s viewpoint:
* the second part of the quoted part in section 14.1 of the SysML 1.3 spec actually mentions the subject’s offered set of services.
* besides other purposes, uc are used to refine requirements. Reqs describe the system but not the actors’ intentions (of course, the reqs need to cover all system objectives and rationales can be used to annotate information about the intention).
* A model should model the system of concern, but not the internal state of the context (e.g. the actors). The system interacts with the actors exclusively through its defined interfaces and the exchanged information. The system design shouldn’t care about the actors’ goals (which would be an internal state of the actors) – just the actual stimulation and interaction on their interfaces.
I see your point. A UC for the purpose of discovering requirements has value and a UC for demonstrating capability has value, too. The former is intentionally exposing actor intentions and the latter must hide them. As you said perspective has to be made explicit. Perspective depends on the model objectives and either one can be useful.
I appreciate the importance you give to intentions, goals of Actors / System. I too find they “arise” before “actions are carried out and messages emerge”.
Sorry my earlier post was closed by mistake. I am unable to edit it.
Continuing, with clear distinction of intentions, goals from behavior and messages, it is possible to develop them separately and systematically.
One should start with intention and goal of a UC and conjure a dialog which may lead to it. Then the UC name, and its scope can be defined logically. The behavior (system internals) can be designed later.
If your approach is close to this please join me in “Redefining Use Case as Service Dialog: Draft Proposal” (to be posted on slideshare)
the use case element from the model language perspective is very simple. It has more a less only a name. Attributes like goal, trigger, result, and so on are
added by methodologies like Cockburn or my SYSMOD. You could add these data to your model by defining a stereotype. Instead of applying the
stereotype to the use case you could apply it to the activity. Now the activity has a goal, trigger, and so on. Again you don’t need the use case model element.
My approach to discard the use case element is a simplification. That’s the good part. On the other side it decreases the flexibility, e.g.
with the use case and the activity element you can use different names if you like.
You’re right that the actor himself don’t want to detect and report the fire. He wants that the system does it for him. To find a good
use case name I use the templates ” wants ” or ” wants that the system “.
Do you have a suggestion for a different name for the “Detect and report fire” use case?
My interpretation of an use case – it names one case of system use from external point of view, which is represented by an actor. That’s it.
The name of the use case must be defined form the actor point of view. I like the German name of use case much more – Anwendungsfall, it makes the difference between an use case and an activity much more reasonable.
I guess, the main reason of troubles or misunderstandings with the use cases caused by engineers who thinks in functions and structures 😉 An activity is a definition of a system function, but an use case is case and not a function. From my point of view an use case represents much more a user story than a system function.
My proposal is to reduce the meaning of an use case to the original definition – name of case of system use instead of extending the meaning closed to definition of an activity and then kill it due to redundancy. For every use case multiple scenarios are possible, at least two: basic scenario – everything works fine and exceptional scenario – something goes wrong. Scenarios can be defined in different forms: text, table, interaction (sequence) or even activity. And what i’m missing in UML is a definition of a scenario.
Roman Bretz’s interpretation is close to what is inteded by UML Use Case. It is unfortunate that the UML standard itself is not clear and precise about it.
The nature of Use Case is a Dialog between the System and the Actor (Role to be more precise) for Actor to reach a Specified Goal (under all conditions).
All scnarios are parts of the same Use Case. They represent different series of messages depending on the conditions of Actor and System and data & information contained in the messages.
With this distinction, Use Case Modeling is “very useful and profound” for modeling the system and its environment without getting into details of either the system or the environment.
The UML use case element is defined as a “specification of a set of behaviors performed by a subject”. An activity is such a behavior. I argue that you only need one behavior element and not a set. An activity itself is a specification of a set of many concrete scenarios (=instantiation of the activity), i.e. the activity already specifies the basic and alternate paths.
The definition: “specification of a set of behaviors performed by a subject” fits my understanding of use cases very well, but leaves also room for interpretations, because “behavior” is a technical term and do not specify its intention . That the reason why I like the term scenario more.
Let us try to analyse what are the most important things to define a scenario:
– some actors (including the object)
– interacting between the actors
– the time order
– constraints (optional)
And that why i prefer Sequence Diagrams to describe the scenarios (behaviors). Now the interesting part: the result of consolidation of the sequences is typically a number of common Activities used in different scenarios.
Using Activities from the beginning is also possible, but it makes focusing on interacting between different actors and the time order is much more difficult.
Your quote is an accurate reproduction of the definition of Use Case. But that is WHAT I FIND is wrong. I am suggesting that UC should NOT describe the “behavior” (which as you say is activity). A UC or what I recommend calling “Service Dialog” should only present the “messages” of dialog.
We will discover what “behavior” may be necessary within the “system” to generate the “data and information per D E Knuth” of system’s message. For this we need Sequence Diagrams but NOT for UC.
This relates to Roman’s post also.
nice discussion! I was puzzled to see the UML spec description as being an “offered functionality” rather than the “context for validating offered functionality.” Hmmm… the 2.5 spec is under review at the moment so I might suggest that elaboration. The abstract syntax supports the latter description.
I made a feeble attempt at renaming the uc but it is pretty hard to do hypothetically. However, given real stakeholders and real problems, it is a lot easier make the distinction between goal and activities that enable achievement.
UC might be under-specified such that it should be abstract. I don’t think there is a mechanism to do that, however. Stereotype only extends by adding tags and would not make an abstract class instantiable. I’m sure the OMG would not be able to define uc as abstract at this point anyway. A profile could disallow uc to ensure that a stereotyped uc is used instead.
I just experimented with creating the OCL to limit uc usage to only allow uc with Extension of a particular stereotype. I could see that it could be done but I would probably get it wrong a few times before coming up with what I really intended. I get the feeling that if one is smart enough to construct the rules they are also probably smart enough to avoid needing the rule…
Thanks, again, for the good discussion,
I do not think we interacted earlier. If you think it is necessary to “rename and redefine UC” I have a lots of analyses and recommendations. Our reasons and recommendations may differ. Let’s see if they complement each other. In my assessment OMG is missing major flaws in the “name and definition of UC”.
I invite you to review what I would upload to slideshare.
FWIW, I’m thinking that killing uc is not the right thing. UC makes complex expression possible even if it makes typical expression a tiny bit more than easy. Entertaining the proposal has deepened my understanding, for sure.
I’m still convinced that killing the use case model element is a valuable method. However our great discussion shows me that in practice it’s easier to keep it as it is. It’ll probably lead to confusion and will not only kill the use case, but also the benefit of doing it.
AA I appreciate your motivation for killing Use Case. I too have independently arrived at a similar conclusion but WHAT I want to KILL is the “current name and definition of Use Case” but NOT the concept itself.
BB The UC concept is indeed very profound. It identifies “dialog” as a crucial part of interaction distinct from the “Activities or Behavior” but does NOT say so precisely. UC is very effective in separating “requirements and design”.
I would like you and Roman to review my proposal “Redefining Use Case as Service Dialog: Draft Proposal” which I will upload on http://www.slideshare.net/putchavn
I could not find your proposal “Redefining Use Case as Service Dialog: Draft Proposal” on your slideshare page. Please send me a link to the document.
In our dialect of executable UML we treat use cases as a named set of elementary service requests required by an actor in order to achieve some valuable goal. We don’t specify much of the interaction logic here – this can be done by means of activity or sequence diagrams. However, what I think is very helpful on use case models is to specify inclusion, extension and particularly specializeation relationships amon use cases. They are very useful means to foster reusable interaction components in a early stave of a project. The semantics of similar relationships on activities is (currently) much weaker defined than for use cases.
You could also use specialization between activities. The include-relationship between use cases is similar to the callbehavioraction in activities. Only the extend-relationship between use cases are not available for activities. However I prefer to not use extend or as Martin Fowler said “Just pretend it doesn’t exist.”
My preference is to use Use Cases as functional requirement over shall statements. I find that they provide more context than shall statement and are easier for implementers to get the information they need to construct the product. Further tying a use to a user type makes it easier to understand the uses separation. This works well for security, training uses, maintenance, etc. In software that requires security, knowing who can do what is important.
One thing that a System Engineer needs to keep in mind is, someone else is going to construct the system they are composing, so they better make it understandable to other engineers and technicians.
I have seen a lot of dummy guys playing heros, reinventing wheel and so on. But this is something special even for me.
You don’t understand what Use Case is, nor do you try to learn or find out. You simply says it’s bad and you have a better way of doing… what exactly, if you don’t have the idea about what Use Case actually is?
Are you for real?
Go read some UML for beginners and learn the goddamn basics in the first place. I am terrified by number of people actually discussing with you.
Everyone wants to talk but no one can listen I would say.
I am not again the concept of use cases. Quite the contrary I recommend use cases to describe the functional requirements. The idea is to minimize the number of model elements to describe a system. Instead of using the use case model element to capture the use case concept, you can use an activity with stereotype use case. An activity is a special kind of a class and actors could be connected with classes. You can express the same information and do use case analysis, but with less model elements.
If you want to explicitly separate the purpose of a system (=use case) from the system functions (=activities), it makes sense to use both model elements.
4 years later I thought the very same.
I can see merit in eliminating actors and a separate diagram for use cases. In some systems, operators and users are quite different. Operators are an integral part of the system necessary to the function of the system, while users are external and use the system as a service. In addition, either can be human, software, or hardware. The actor symbol is somewhat misleading if the user is a software system and adds a psychological barrier to moving functionality between people, hardware and software. Without actors, use case diagrams don’t bring much in additional utility.
I think Use Cases do have a purpose: They just state requirements – and where they stem from.
Without bothering how they decompose.
I think the important task is to understand the system at hand by:
– Benefits of stakeholders even if they are systems
– Depict it without a functional analysis
– Get the gist and don’t overdue in details
The benefit of Use Cases is the simplicity and that it is almost impossible to make a functional design.
In my experiences, there aren’t a lot of people who understand the concept of Use Cases. Most people have a lot to say, and they do it. The results are Uses Cases which are better depicted by Activity Diagrams.
Yes, from the perspective of models it is better to use Activities and Blocks. The risk is complicated and detailed Diagrams which works with well-understood model elements but without understanding the purpose.
I have no silver bullet, and I have to admit that I needed some time to grasp the gist of UC.
Most of us are engineers who strive with making things perfect.