Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am trying to model a use case diagram with two different front end applications. I have a web-based front end with different use cases than my front end for a tablet app. Some use case might have the same name but a different scenario.
My question is if it is a good way to use two system blocks in the diagram for each front end, or should I combine all uses cases in one system block? How can I model it in a UML correct and clear way?
UML use-cases and their boundaries
Setting the right boundaries is key to successful use-case modelling. According to the UML 2.5.1 specs:
A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure.
What matters is the system (i.e. the "subject" in use-case speak), the actors, and the behaviors that the subject offers to its actors (which, as QwertySO reminds us, supposed to provide value to the users, i.e. help to achieve the user's goal).
Use-cases focus on the users
From the point of view of your users, the expected functionality is independent of the from the front-endend. According to your comment, today:
the web frontend is targeting the actor admin with a use case: create a product. On the other side, the tablet front end is targeting the user to buy a product but is not made for the admin.
But tomorrow, your admins might want to use a PC, or a smartphone for the urgent tasks. And maybe some normal users would expect a voice interface rather than a tablet. The use-cases shall help us to focus on theses needs and not the way we are going to address them.
So, in principle, you should model your use-case independently of the front-end. You should not either show the split between front-end and back-end.
How to decompose the system
Use-cases are not meant to do functional nor structural decomposition. This kind of distinction is best performed in component diagrams that decompose your system into components and in deployment diagrams that map the components to the servers and devices.
If you have already a component decomposition in mind, and your component are independent, you could think of modelling the use-cases of a sub-system or a component. This is valid, since UML specs tell us:
A subject of a UseCase could be a system or any other element that may have behavior, such as a Component or Class. Each UseCase specifies a unit of useful functionality that the subject provides to its users
You can even model use-cases for a component, the actors being then the external actors and the other
But would this be helpful? You could have a use-case diagram for the admin application, with admin actors, and a system actor fo the back-end. But I'd not advise to go into that direction unless the app is a rich app with its own added value. If the app is just a front-end you'd just end-up with very redundant use-case diagrams (i.e. front-end UC and back-end UC would show the same use-cases) with a loss of end-to end relation to the real actor (i.e. the back-end UC would be associated with system actors corresponding to the front-end app, but you'd loose the direct link to the real actors).
In the end you might lose the main strength of UC, the focus on users and their goals. In exchange you'd have the burden to keep all the redundant models in sync but I don't quite see the advantage here. If you want to have more arguments about each alternative, you may also have a look here.
No, that's not good. Use cases are meant to show the added value a system under consideration delivers to actors of it. You are looking at implementation details. That is how the interface would look like. But for the added value this is completely irrelevant. You can create different implementations for the use cases so your collaborations will show either the one or the other front end. That will be part of the class design controlled by a requirement User may interact with frontend A and B.
Related
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.
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?
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.
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.
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.
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.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am coming from the Embedded Systems domain with more than 3 years experience.
In my current project, at the beginning, I was only responsible for only software development and the Team consisted of 3 people.
But, as time passes, hardware eng. and project lead eng. left the job respectively. So far, the project moved with a zero- architecture documentation to give an output as fast as possible. Later, new project lead took over the project and started from the begining with applying V-model. We started to create product specs->HLR->DLR on EXCEL. But now, He left the job too :). Now, I am alone on my way with nearly 700 pieces of well written product requirements. Anyway, I started to gathering and classfying requirements as non-functional, functional, business, stakeholder etc. As gathering non-functionals, I also classified them scalability, performance, regulatory, design contrains etc. So far, I did not draw any use-case. Please verify me here, what I know is that input of use-case are functional requirements. So, I created a use-case cards and now I am planning to write use-case cards for each functional requirements then also write a sequence diagram for each use-case card. Now till here, am I going right ? Does notations used in use-case such as include, extend etc. help me to create class diagram ? Is this also right way ?
Can classes be derived from use-cases?
When Ivar Jacobson invented use-cases he aimed at a development method that would be driven by the use-cases and allow to methodically derive the implementation from the use cases. That was his vision end of the 80s. His first attempt was called Objectory, which was bought by a larger company and lead to Rational Unified Process, which was generalized to be less proprietary into the Unified Software Development Process (Unified Process, or UP in short).
There is in particular one practice that allows to translate a use-case into classes: the Entity Control Boundary approach: use-cases become «control» classes, links between use-cases and actors become «boundary» classes, and «entity» classes are created for the business objects identified in (or derived from) the use-case narratives.
Once these first candidate classes are modelled, further work is undertaken during the design and classes may get reorganized to best fit into the solution (e.g. several boundary classes are regrouped for designing the GUI, and may thereafter be decomposed into UI elements, etc...).
But is this the best approach in your case?
UP is iterative and incremental, and fits well into modern version of the V-model, since the early iterations of the elaboration phase aim to stabilize the architecture and teh components (or sub-systems).
However, this may be a very time-consuming approach, especially considering the huge number of use-cases that you have. If you look at all the questions that modelling a use-case usually raises, especially if you add «include» and «extend», you risk to spend a lot of time (more than 300 days?) to draw robust use-case diagrams. And then, using ECB, your requirements might be outdated before you finish the design!
Alternatives
On the other side, some non-academic authors claim that every system has 3 to 5 really main use-cases: as a user I don't have 700 goals for using a system. So you'd better identify these and see how they relate. It's probable that many of the other requirements are far too detailed and could easily be assigned as additional information for the main use-cases.
In a similar thought, Ivar Jacobson has adapted his method to the current software engineering reality, with the use-case 2.0 approach. Don't misunderstand me, the UML would still be the same, but ECB no longer appears (modern frameworks influence much more the design of the boundaries than the use-case model, and entities are modelled using more focused approaches, such as DDD).
The idea behind use-case 2.0 is to slice the main use-cases into several smaller parts and start to develop something that makes sense for the user and can then be further refined.
I am trying to design a Use Case Diagram for an app like Stack Overflow. I have tried to add some basic functionalities in this diagram.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow, but have no idea of how to do so. Also, should there be another actor for Admin who manages user accounts, or not? And if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
What if other than these two actors, I decide to add a Mediator actor too, who forwards the problems to the mentor, and when a mentor solves it, it is the responsibility of mediator to mark it solved?
If you want to map all the use cases and actors in StackOverflow you can take the Tour and search for some known Q&A in the Help Center.
And yes, if you want to make an exhaustive list, then you should include every actor - including Admin and Mediator. However, I'm not sure that you can figure out the admin's use cases (or other managing roles in this platform) since you are a user and it isn't reflected to you.
If there are use-cases that are unique to a specific actor, then you should add that actor to the diagram - and use inheritance! (When actor b has all the cases of a plus more, then b is inherits a) - this one is called "Generalization of an Actor" (you can google search some examples).
As for your other questions:
Please note that Use Case Diagram is an addition to the Use Case Modeling, more like an appendix. When you are modeling - you explain lots of details about the use case (some of them you've mentioned), such as: Primary actor, Scope, User Story, Postconditions, Preconditions, Triggers, Flow, and many more... There are a lot of templates actually. You can review them Here.
You do not describe visually* any preconditions or post-conditions, however, you have some tools that can describe which cases are **included in a specific case (in order to use feature Y - you should go over feature X). Or, which cases extends other cases (while you are using feature X, you can (but not have to) use feature Y).
Hope it helped :)
I encourage you to use a modeler rather than to draw your diagram by hand.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow
The exhaustive list of the features of S.O. is certainly very be long, and you will have problem too see it because surely some parts are hidden to 'standard' users. What is your goal, to model S.O. or to use it as an exercise ? On the second case it is not necessary to manage all
should there be another actor for Admin who manages user accounts, or not?
Sure they are admins or 'super' users.
if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
A use case is not only an ellipse in a diagram, and a model is not ajust a list of diagrams. Yes each UC must have its description and the possible pre/post conditions etc
What if other than these two actors, I decide to add a Mediator actor too ...
I don't know if there are mediators, but I am quite surprised by the 'mentor' whose role is to answer. If you have him you make a separation between the roles consisting to ask and to answer, so the other role cannot be the very general user but probably must be more specific
You will have lot of remarks about the UC login for sure ;-)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am working on an open-source project which shows how to develop software iteratively using test-driven development and some ideas from domain-driven design. I know what I would do, however my formal skills (especially regarding UML) are a little bit rusty.
Below I am going to post my first steps with the diagrams and the explanations I would give to my readers.
I have the following questions:
The last step ends with the question But what will stich together these components?. How to show the reader the way in UML terms, while not skipping anything in the train of thought? What I plan to do is to let each component provide an Environment class. For the purpose of testing, a TestingEnvironment will gather all those environments and inject the right callbacks into the World. But which types of UML diagrams to use for showing my train of thought, and in which order? My problem is, somehow, that I know what I want to do, but I can't rationalize it to myself why I want to do it that way - I guess it has gotten a part of me to the point I don't make such decisions consciously any more.
What mistakes have I done so far, how to fix them, and most importantly: WHY?
Step 1
(0001_user_commands_use_cases.pdf)
(0002_user_commands_use_cases.pdf)
User Use Cases - Analysis
We are starting with an use case diagram (0001_user_commands_use_cases.pdf) as
part of the preliminary analysis stage. This diagram should only help us
understand what our client wants. These use cases may change over time, but
never the less, they help us understand the system we are going to develop.
Please follow the arrows while reading the following explanations.
The role the user plays when interacting first with our system will be Guest.
The Guest sends to the system some registration data, which we process.
In the diagram, we are describing what happens from a logistic point of view,
from the perspective of the client for which we write the application. We are
not referring yet to classes or objects, or the concrete workflow, which may
end up being quite different.
We are also not dealing with errors, because that would only add more
background noise to the idea - and because error handling does not add business
value to the system. Of course, a system has to be robust to errors, but keep
in mind that we're now just making the analysis - not the design of the system.
Logistically speaking, after the Guest has sent us the registration data, there
is a Registered User. A registered user can send us the login data, so that he
becomes an Authenticated User.
Following the diagram, we can see how only an Authenticated User can send to us
a request to log out of the system, thus becoming a Deauthenticated User.
Why a Deauthenticated User, and not a Guest back again? Basically, it comes
down to us not being able to foresee the future. We really have no idea how the
client will want us to extend the system - nor does he himself! Beside that,
the two roles, a Guest which we know nothing about, and a user which has just
deauthenticated, which we do know something about, are really different things.
Of course it may be that the Deauthenticated User will exist in our application
only for a very short period of time, or it may be that it's created for the
sole purpose of being destroyed back again, without being looked at by any
other subsystem of our ERP - but still I cannot stress it enough: logistically,
the role of a Deauthenticated User stands on its own.
The second diagram (0002_user_commands_use_cases.pdf) contains all the
information of the first diagram, with some added items. If you follow the
green arrows, you will see that the process is the same.
In the first diagram we notice how all three things done by the ERP system are
some kind of generalizations of a process. We have introduced this new generic
process in the second diagram as "Process Data".
Another element we have added in the second diagram is a generalization of the
three "Sending Data" elements. We are not sure how this will materialize in the
next stage (designing the system), but it looks like there's a generalization
there which may, in the end, make the system easier to maintain and extend.
We always seek new generalizations and abstractions because they have this nice
property of making the code maintainable and extendable.
Conclusion
----------
In our design, the ERP will do one central thing, "Process Data", data which
will come in in a standardized way, represented in our second diagram by the
"Send Data" use case.
We don't know how we will design these things yet, until now we have only
thought about the logistics, since we are doing just the analysis.
In the next commit, we are going to look closer at the application domain, in
order to better see the relations between all these notions and to enable us to
come up with a cohesive design.
Step 2
A rough overview of the components in the context of the application domain
Before looking at the diagram, let me first explain the thoughts I had prior to
coming up with this diagram.
We are going to design an ERP. What is this all about, and where lies the
business value in it?
We are supposedly making the product for a company which makes money by sending
products back and forth. This is the core domain of the application.
The basic idea is that a product P is moved from point A to point B, and in
this process, the company makes money.
The application will allow the company to make money by both being good at
organizing the workflow, and by making an existing workflow cheaper.
Let's say a product can be delivered to point C by taking the route A -> B ->
C, or the route A -> D -> C. The ERP must be capable of deciding which one is
better (in terms of money or time), and must manage the workflow it chooses.
So the whole point is supporting the movement of products around. Around what?
Around the world.
For this reason, let's first draw our first component: the World.
In a real project, I would continue by adding a Product component. I've chosen
not to yet, because this project is an educational one in nature, and I wanted
to get across new ideas about the architecture. If I had focused on the
products, I think there would be too much noise for the type of audience this
project is aimed at, a noise which would make the process of creating the
architecture and the architecture itself harder to understand.
We will introduce a Product component later, when the reader will feel at ease
with the architecture which, at that point, he will feel familiar with.
Instead of focusing on Products, we are going to focus on Users. This is,
incidentally, also the subject of the use cases we have drawn in the previous
commit. I think that any reader can relate to the concept of User.
So let's draw that component, the User.
Architecturally speaking, it's not that much of a difference between an User
and a Product. Instead of having Products moving around, we will have (for
now), users who live in the World and take different roles while interacting
with our system.
In the previous commit, we have concluded that there would be a standard way of
passing in data from the User to the system.
In terms of DDD (Domain-Driven Design), the data that gets into the system is
packed up as a Command. Since it looks like a good name, let's make a port of
the World component called Command Hub which will be used to receive and
process Commands from the outside.
Conceptually, the Command Hub will provide a Command Interface which any other
component can implement in order to send commands to the Hub, if it needs to.
We also want to make the components decoupled and thus reusable in different
types of applications, or to be able to combine them. This is achieved by
making an event-driven architecture.
For this reason, let's give the World component an Event Hub, which will
provide an Event interface.
But what will stich together these components?
This question is so pressing, because it's so central to our architecture, that
we will have to further investigate it.
This is not an asnwer, just a comment that would not fit into the comment box
(1) if you want to "teach your readers" something you can't do yourself, it is strange approach. Show your readers the way which works for you. Show the way "your train of thoughs runs", show the the mental images you saw in your mind, paper/pencil/photo in whatever visualization language you use
(2) you're skipping the uml-diagrams: UML 2.5 Behavior Diagrams as not useful? Even the uml-diagrams.org: UML Interaction Overview Diagrams not useful?
(3) this question looks like too broad(long) perhaps opinion-based and perhaps off-topic much more suitable for https://softwareengineering.stackexchange.com/help/on-topic
(4) for the recommended modeling workflow look at
(4.1) Cangnus's sequence diagramming comment in Stack Overflow: sequence diagram for books exchange
(4.2) BobRodes's use case scenario comment in Stack Overflow: Formal language for UML sequence diagrams
(4.3) Scott W. Ambler's Agile Modeling: Where Do I Start? for what when how and why Agile Modeling Best Practices
to name just a few
In conclusion of this my long comment, I don't see any mistakes you did. If this is description of how Test-driven Development and Domain-driven design works for you so well that you even use it subconsciously then it is just fine and ok. Being a good teach is not an easy task, good luck
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a scenario which involves a vending machine and then asks us to create to "model the problem domain". I've covered modelling very loosely and was hoping someone would clear this up.
From research it looks like a problem domain is just a domain model which in turn is pretty much a UML Class Diagram.
The examples I've seen look they're almost database schemas with a customer entity, order entity etc etc.
I'm just not sure what the differences are exactly.
So I just wondered if I was on the right track and would anyone mind elaborating on this or perhaps pointing me towards a concise definition. Thanks.
The "problem domain" is just the stuff you're interested in. In your case, it's all the stuff a vending machine does, and who interacts with it.
It boils down to a collection of use cases, which can be diagrammed in a use case diagram. What does the vending machine do? It takes coins from a buyer (the actor), gives change (maybe...so make sure you understand "extension points"), spits out stuff (always, because we aren't in the real world), and so on. Then maybe you can get creative with a different actor. A maintenance person takes out money, adds change, fills up the machine, runs a diagnostic stack, whatever. Each one of these is a use case. Put them together into a use case diagram.
If you want to go into detail about what each use case does, then use an activity diagram. One for each use case.
Any system (software or not and modeled or not) has structural and behaviour aspects.
The structural aspects are non-time bound aspects of your system, such as which classes your system is made up of, their associations and dependencies, how they are divided into subsystems, etc. Most of these elements are often referred to as classifiers.
The behaviour aspects shows how these structural aspects collaborates together over time to achieve the goals of the system, such as methods, state machines, workflows, use case realisations, etc.
The structural and behaviour aspects are what you specify when you are writing your code or creating a model.
Objects, are by definition instances of classes. This means that objects are the "things" that actually exists when the system executes. Hence, you do not program an object; you program a class, which when executed, is instantiated into one or several objects.
However, in many modelling languages (but not common in programming languages), you can also model specifications of scenarios, which show specifications of objects and how they interact, for example in UML you may create an object diagram, showing one example of how the system of objects (i.e., instantiated classes) might be structured and collaborate during execution.
Now, a system always strives to a achieve one or several goals for it's surrounding. The surrounding is made up of persons and/or another systems (actors) interacting with the system. This "surrounding" or "background", on which the system is situated in and makes sense in, is often called the "domain".
These "actors" have a "problem" they would like that the system helps them to solve. When this problem is modelled, one calls that model the "problem domain model" for the system. It states the logical structural and behaviour aspects of the problem domain, without stating how it is going to be implemented in a specific implementation of a system. I.e., it is not referring to implementation aspects, like Java, SQL, primary keys, transactions, reflection, angular, etc; it is instead focusing on the core structures of the domain, like Orders, Parties, Contracts, Products, etc.
The problem domain model is one of the most important "contracts" between the system developers and the persons paying for the system or being owners and users of the system. It makes it possible for you all to understand the problem to be solved in the same way and are makes sure that you all are using the same concepts to reason about it. Since it, by definition, is not a technical artefact, you should describe it using as simple notation (but still stringent and crisp clear) as possible so that also non-software professionals could understand and agree on it. Class diagrams (stripped from all technical details) and use case diagrams are two notation techniques available. But also object diagrams and activity diagrams could come in handy.
If you are interested in this, I deliver a course in advanced concept domain modeling on Udemy. Here is link and 90%-off code: https://www.udemy.com/get-your-concepts-straight/?couponCode=CONCEPTS29
Regards
Per