I have an ecommerce where users can ask questions on the product and the users who bought it can answer the questions and also vote on the questions like amazon , which means that the system will technically send all answers and votes to the user and the user will send answers and votes also.
So the same data is exchanged between the system and the customer, how can I represent it in a context diagram? I added an arrow head in both ends , is this correct?
Dataflow diagrams frequently use unidirectional flows between processes or between processes and entities, but bidirectional flows with an arrow on both sides are a common practice that is perfectly valid.
The authors who popularised the two mainstream variants of DFD modelling Gane & Sarson or Yourdon & DeMarco), both refer to it in their foundational books: Yourdon uses it in several examples, Gane and Sarson even recommend it for keeping diagrams simple.
Related
I'm trying to create a Use Case Diagram of Order System. But I'm curious if the 'send notification' and 'add order' is connected since before ordering, the inventory will check for the stock. I'm thinking of connecting the two using 'extend'. What do you think?
Whenever you wonder if use-cases are related because of some sequential or causal relationship, you are no longer in use-case analysis, but in one of the following situations:
Functional analysis: you’re doing functional decomposition, i.e. breaking down a functionality in more elementary functions (e.g. the includes for Ship order): this is not forbidden but leads to very complex diagrams that are difficult to read and use in practice due to unnecessary details and mixed levels of abstraction.Solution: don’t! Simplify your diagram and focus on user’s goals.
Designing a flow of activities: this is wrong, since there shall be no order/sequential relationship between use-cases, and use-cases shall not be confused with events or preconditions(e.g. item is not out of stock) Solution: go for an activity diagrams, which are meant for exactly this kind of modelling.
misusing use-cases for user-interface design (suspicion that all the generate xxx corresponds to windows to show data to the actor): this usually leads to bad user-interfaces and incomplete analysis of the user’s goals.
I think your (impressive and comprehensive) diagram corresponds to the first two situations. I recommend to simplify, focus on the user goals, and for each use case that is more complex, make an activity diagram for the flow.
I am very concerned when I see in the table “use-case(process)”, and it appears that this is an exercise you are trying to do. This is plain wrong: a use case is an actor’s goal and not a process. Processes are typically modelled with activity diagrams. If this comes from an UML tutorial, then immediately change tutorial!
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.
I have this kind of situation where I have multiple actors which share the same use case.
I cannot figure out from which point of view I should write the flow of events and describe the sequence diagram of this specific use case, having more than one single actor.
You: I have multiple actors which share the same use case.
... from which point of view I should write the flow of events
Use-cases are goal-oriented. They are not supposed to be a functional decomposition nor a sequence of actions. It's not me, but Ivar Jacobson, the inventor of use-cases, in Use-Case 2.0:
A use case is all the ways of using a system to achieve a particular goal for a particular user. (Page 4)
So use-cases are meant to provide the big picture. Your use-case diagram should identify these independent goals. Of course, behind each use case, you have some narrative that describe the interaction between the actors and the use-case:
The purpose of a use-case narrative is to tell the story of how the system and its actors work together to achieve a particular goal. (...)
Use-case narratives can be developed at different levels of detail ranging from a simple outline, identifying the basic flow and the most important variants, through to a comprehensive, highly detailed specification(Page 47)
One way of describing this flow, is how Geert Bellekens explained in the comments: describing the scenario telling who does what in which order. A variant of this presentation is a tabular form: a column for the actor actions and a column for the actor actions.
Now, if you're at the beginning of the design, and especially if you have several actors, this kind of UC description forces you to make a decision about the way you design the interactions. A more creative variant is to describe essential use-cases: instead of describing the flow of event, you make a table describing mapping more in detail the intents (i.e. intentions) of the actors (in one or n columns) to the corresponding responsibilities of the system (in a separate column).
You can then start to think about possible sequences, but also about alternative sequences that could provide a better user experience or a more optimal flow of information. The flexibility is so high that you could even design voice-driven or NLP driven interfaces in which the sequence is not predetermined but could be different for each use-case execution.
I would like to know:
how to convert users stories into sequence diagrams?
and what is the most easy diagram to understand (for customer)?
Traditionally, a use case is converted into sequence diagrams (through a "use case realization" collaboration for traceability). User stories are different from use cases in that the latter provide a set of distinct steps to take whereas the former concentrate on a need and reason.
If you were to to take a use case, each of the steps in the use case would be represented by messages in the sequence diagram. The use case actor (the "user" in the user story) would be the initiating timeline and a second timeline would be the "system". You could then iterate on that sequence diagram to extract various system components (thereby building a domain model for your application).
Does that make sense to you?
how to convert users stories into sequence diagrams?
There is no straightforward easy way. There is not enough information as user story is basically one or few sentences of text. Converting use cases to sequence diagrams is easier and can be partially automated
what is the most easy diagram to understand (for customer)?
it depends on who is the customer. In general, overview diagrams, e.g. BPMN style should be easy to read. See my answer to the question "UML diagram for dependency between systems" for some options and useful links
suggested readings
Enterprise Architect video - how to convert use case into a diagram -http://www.sparxsystems.com/resources/demos/use-case-analysis/structured-use-case-scenarios.htm
Enterprise Architect - various ways how to capture requirements and communicate them to stakeholders - http://www.sparxsystems.com/products/ea/requirements.html
Mike Cohn's page (defined the term "user story") about user stories - http://www.mountaingoatsoftware.com/agile/user-stories
Alistair Cockburn's page (defined the term "use case") about use cases - http://alistair.cockburn.us/Use+Cases
Some examples of tools for creation of sequence diagrams: https://www.websequencediagrams.com/, http://creately.com/diagram-type/uml-sequence-diagrams, you can Google out many more examples both free and payed both online and offline
In my opinion, what works best with the customers are not use cases. They are too abstract and complicated even for the most of developers. And when they are finally approved, you're never sure whether the customers actually understood them correctly.
I suggest the mix of UML activity diagrams and user interface prototypes (non UML) as far the best tool to work on this level of analysis with non technical business people.
Activities model their business in an intuitive, easy to understand and clear way.
UI Prototypes as well, so they can see how they business maps to screens.
Behind the curtains, I like to support activities with a formal and accurate domain class model, invisible to customers of course, but open to developers and making a nice technical backbone of the future system.
User stories fit perfectly in this modelling set, you can even make them less formal and more high-level, as the rest will fill the information gap. Sequences can now be build using domain objects, connecting 2 views - customers' and developers'.
I avoid use cases strongly, whenever possible (although I personally like them).
Generally in UML, you model roles as opposed to people however if there is a use case to model people (along with their names, contact details, etc), is there a known way of depicting this?
For example do I create a superclass called "Person" and generalize the roles followed by a specialization of a real person?
I took a look at some of your other questions and now I realise I completely misunderstood and you're probably trying to model an organization and the people in it.
ArchiMate is a semantic layer on top of UML that is intended for architecture modelling. Real people get described in the business layer, as actors.
A business actor is defined as an organizational entity capable of (actively) performing behavior.
A business actor performs the behavior assigned to (one or more) business roles. Examples of business actors are humans, departments, and business units. A business actor may be assigned to one or more business roles. The name of a business actor should preferably be a noun.
Now generally the person fills a spot in the organization that in a couple years could be filled by another person. The structure / architecture of the organization would not change and as such the actor can be described by the name of their position, say, "Head of department" rather than by their name and phone number.
Still, I understand that it may be handy to have this sort of information available when you want to contact them.
UML-model-wise, I'd think that the actor Head of Department is a class, realizing a business role that's also a class, and that Joe with phonenumber 12345 is an object of that class.
But practically, I'd think this is too much detail for the level at which you're describing the organization. I'd suggest you stick a UML note on those few actors of key contacts whose names you think are worth mentioning in the diagram. But administrate the rest of them in a system that's more fit for this, like your company's ADS or Contacts in Microsoft Outlook.