If I have a front-end application that reads from the API of a backend, then I would have a data flow chart like this, because the data flows from the backend to the frontend:
However, when I would like to emphasize that this is a read only API, and that the front-end cannot write to the backend, I feel like have to turnaround the arrow, saying "The Frontend reads from Backend":
But this would conflict with the data-flow arrow, because the arrow indicates the direction of the flow:
How do you represent a read/write relation to a data-flow diagram?
Data-flow diagrams use arrows to show the direction of the flow of data. Whether you use Gane & Sarson or Yourdon & DeMarco), a unidirectional arrow means an unidirectional flow:
Your first diagram means that the data flows from the back-end to the front-end and only in that direction. There is no need to tell that it's read-only, because the flow is unidirectional.
If you wanted the front-end to read and write data from/to the back-end, you'd need a second arrow in the opposite direction. A common practice is to use a bidirectional arrow (Yourdon uses it in several examples, Gane and Sarson even recommend it for keeping diagrams simple).
If you want to have it read-only, but indicate the data elements used to find the relevant data, you may use Gane & Sarson's notation of "search argument specification" (which is meant to apply to data stores and not processes):
Source: Structured System Analysis, Chris Gane & Trish Sarson
Your second diagram would be misleading: not only would it show the flow in the wrong direction, but in addition, the DFD convention is to label the arrows with the kind of data that flows along:
Arrows should be named to indicate the meaning of the data that moves along the flow that is, a noun.
Data flows with a verb name signify a process that has been omitted. Data flow in and out of a process must be altered in some way. -
Source : Visual Paradigm tutorial
This convention explain also why double-sided arrows are quite rare in practice, as soon as you label the flow: the flow back would have a slightly different name (e.g. updated data, corrected data, validated data).
The only ambiguity in your diagram is who initiates the flow: is it the front-end that reads or the back-end that writes? But this is normal: it's not the purpose of this kind of diagrams to go in such details. You could add an arrow "request data" to show that the front-end initiates the communication, but this would quickly overload your diagram and the added precision would come at the expense of the readability.
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!
I want to develop mobile applications, but I only focus on frontend development not on the backend.
I want to make a UML diagram, but I am confused about what to do, at this point I think I will make a use case diagram, a use case description, and an activity diagram. Do i need to add other diagram types like sequences or other? and if so what i need to make that diagram??
When drawing diagrams, you can draw them either from the entire system or just it's part perspective. Of course it is normal to use both approaches in a single project. It all depends what is your goal and what are you trying to model.
When looking at the FE, you can of course draw at least following diagrams:
Use case diagram to indicate what functions are offered by the FE. It will often be similar to UC diagram of the entire system, however it will definitely not contain the APIs exposed by the system for other systems to integrate as those are BE specific. Besides, you may have different front-ends (e.g. fat vs thin client), offering different functionalities
Activity diagram to show flow (e.g. screens' flow, e.g. per UC)
Class diagram to show data structures used by FE (they often differ to some level to the BE part, however usually are generated by the FE-BE integration layer)
Sequence diagram or Communication diagram to indicate points of integration with BE, especially in complex cases
Of course there can be much more, depending on your specific situation (e.g. timing diagram can be important in your specific case)
Having said that, take into account that you don't need to draw any diagrams. The idea of modelling is to draw those diagrams, that are needed, i.e. help grasp some ideas that may be otherwise be difficult to understand.
I was reading about statechart diagrams, which are diagrams that model the different states that one or more instances of one or more classes can be.
An object can go from one state to the other through a transition, which is represented using arrow with an event and eventually a action to that event over and respectively below it.
My problem now is that I don't understand exactly what are OR and AND decompositions in a statechart diagram. Could you please give me an explanation (since I've not found around any)?
I would really appreciate a concrete example with the corresponding picture or diagram.
The following picture is an example for an OR. Consider a token traveling from Initial to the Choice (diamond). Here the token travels either to the left or right guided by the constraints which test the condition checked in Choice. From then where they are they next transit through the following unnamed diamond to Continued. You might leave away the joining diamond and draw the transitions directly to Continued.
The AND condition looks like this:
The first Fork(the bar) duplicates the token and sends them to Either and Or. The Join behind these states waits for two tokens to arrive before it sends only one token further to Continued.
Fork and Join use the same symbol. They wait until all incoming tokens arrive and then send as many tokens as there are outgoing transitions. So they are actually some split personality. But mostly they are used the one or the other way.
Could you please let me know whether flow chart can be consider for use case modelling? As far as I know it just represents a flow of events and do not have any actors, so cannot be considered for modelling.
Can some some experts confirm this?
Flow charts are the ancestors of activity diagrams and as such very rudimentary. You can use flow charts along with use case modeling, but it is not a good idea. First you will limit yourself in the language (think of a native speaker vs. a foreigner that knows only a little vocabulary). Second is that activity diagrams are matured to a standard within UML. So you can expect more people to be able to read and understand them correctly. And last: activity diagrams are the basis for BPMN which is going to be the next step after use cases (it brings a whole set of new standardized language elements which allows expression of what is in and behind a use case).
And yes, your basic assumption is correct: no relation to actors. So you'd need to find ways to express that outside the flow chart.
See also Wikipedia.
Can I use directed named association on component diagram to show fact that "sys A" sends data to "sys B"?
Example:
No, you should use general purpose dependency instead, with optional title.
However, the title is not very common in this context. Better use some other diagrams (sequence for example) to show the communication details (e.g. open connection, send data, close connection, etc).
If there is a well defined interface between those systems, you can indicate that as well like this:
Association is used between two classes to show that their instances are potentially connected (again, not for data flow indication).
In UML 2.0 the concept behind association is vague, read this article: http://www.uml-diagrams.org/uml-core.html (search for "Semantic Relationship"). Association denotes a "semantic relationship" between two components, and I think it wouldn't be appropriate for data flow.
I think that even dependency isn't appropriate for data flows: maybe the client depends from the supplier, maybe the opposite is true... so the arrow can be very confusing.
The lollipop notation is the best, IMHO: it shows clearly that there is a component providing an interface, and another one requiring it. You can use stereotypes on the interface to show the type of communication/data transfer, and labels to make clear what data is transferred.
The book "Documenting Software Architectures" adopts another style, using prevalently associations: see p.145. It's similar to your initial proposal, but with explicit roles and without arrows. I think isn't a really satisfactory solution, without stereotypes...
If sys A sends information to sys B and you're not interested in how exactly the transmission takes place, then that is a classic application of the Information Flow connector.
A Dependency would in this case say that sys A needs (is dependent on) sys B for something. An Information Flow often (but not always) goes in the opposite direction of a Dependency, since it is typically the receiver that needs the sender.
There are many different ways of showing these types of relationships, and the best one depends on the situation. If your focus is on the type of information being transmitted, then Information Flow is the best fit. If your focus is on the way the transmission takes place, something with an Interface, possibly an Assembly, is better.
EA actually allows you to specify an Information Flow over an Assembly, so you could even combine the two. It's all down to what exactly you want to express.