I am trying to create design document for a project which has all background processes in it.
The sequence of background processes are as follows:
Process P1->
Get all records(thousands) from database.
Analyze validity of records.
Send valid records to process P2.
Process P2 ->
Get valid records one by one.
Do first level processing of data.
Send this to process P3.
Process P3 ->
Get records one by one from process P2.
Based on processing results, update records in database.
I am trying to decide which diagrams to create in this case. Particularly, I am confused about Use Case Diagram. What will be the actor here? Is UseCase diagram even applicable in case of such background processes.
Describing a process is usually done with an activity diagram. If you want to describe a particular execution you should use a sequence diagram.
For a background process a use case isn't applicable I thought? User has no direct interaction with the process, unless you have it interfacing with some trigger that the end user controls.
Activity, Sequence Diagrams and Class Diagrams should be sufficient for your needs.
Related
I am Working on a project for Orders data visualization Dashboard.
This is the use case Diagram:
Currently I'm working on the activity diagram and my question is: Can the Manager and the Shipper login into the system and initiate their own activities in the same diagram?
An activity diagram "specifies behavior by sequencing subordinate units". It can perfectly have several initial nodes, e.g. one for Admin and one for Manager or Shipper. And when the activity is invoked, all those initial nodes would be activated at the same time, starting each a concurrent flow, each being performed at its own pace.
But this makes only sense if the Manager's actions and the Shipper's actions are really related, concurrent and somehow synchronized. E.g. every time an Admin login is performed, a Manager login would be expected.
If the Manager flow as well as the Shipper flow are both independent and in reality unsequenced, you should use separate activity diagrams. In this case, trying to squeeze them into a single diagram could even be misleading.
Additional remarks, unrelated to your question:
Typically you'd have a separate activity diagram for each use case. It's not an obligation, but it's a common practice to describe what happens for a specific use-case. In your case, it would mean that only the Ship Order and the Update product stock would be in a situation where actions could be interdependent.
When activity diagrams are used to design systems, it shows in principle what happens inside the system. The actors are outside the system. So the partitions (columns) would in principle not show what an actor does, but what the system does in relation with an actor. Of course, if you use activity diagrams for process modeling, it would be a different story.
Yes, they can. With each InitialNode a flow begins and the tokens run down the actions independently. Probably at a certain time you will have some synchronization between both (this is not mandatory but otherwise it would probably rather pointless to have two independent flows in the same diagram). In that case you either have a MergeNode (bar) to wait for both tokens to arrive or an action has two incoming edges waiting for both tokens in order to commence.
I am developing a simple microservice that has a cyclical nature:
waits until someone pubblish a message on an MQTT topic
performs actions
sends a reply and then waits for the next message
I need to share with others all the steps of creating this microservice.
I was thinking of using an activity diagram but all the examples I found don't seem to cover this type of behavior.
What is the more appropriate UML diagram to describe cyclic operation and why?
One thing to keep in mind is that there is no command to stop receiving messages, it starts receiving as soon as it is started and stops only when it is terminated.
You decribe the details of an activity that is best modelled with an activity diagram.
There are more than one way to model your case. For example:
The cyclic nature of what you describe is already an implementation view: you imagine a loop in your code that repeats the steps. You can show such a control flow in your diagram if you want.
You could as well model a single iteration as an activity, and consider that the activity starts when there's something to process.
Finally, you could use object flow and their build-in bufering capabilities to model the full system including your queue.
This is best modeled by using an activity diagram.
Waiting for an incoming message can be modeled by an Accept Event action. Sending back a reply can be modeled by a Send Signal action.
The pictures below are almost equivalent. The left picture starts processing an incoming message even when the processing of the previous message has not yet ended. The right picture waits for the previous message to be fully processed and then starts accepting a new message.
I would recommend the picture on the left, because it is the simplest. If you want to stress the cyclical nature, or if it is important to convey that the service only processes messages one by one, you could choose the picture on the right.
I'm looking for a way how to model two activity flows (in an activity-diagram),
where it doesn't matter, which one starts first,
but the second one has than to wait, until the first ends.
I know, there exist the start (split) and end (join) of concurrent activities.
But they don't fit my needs.
Do you know any way how to randomly start the first flow but than process sequentially?
Use Activity or Sequence diagram,
Use an Initial Node or two for the random signal.
You can also use Join for getting the signal into account.
Use Decision node (not Fork!) for switching the flow.
I am new to the world of UML and have so far learnt the basics of use case, activity and deployment UML diagrams. I have a requirement of where users interact with a system e.g. user sending an email, which is then processed by a system and then sent to an agent (person) who then responds and interacts once again with a system.
I am having a hard time picturing these requirements and whether it should be a combination of use case, activity or deployment. Can I intermingle them? What is standard practice?
As you know, use cases are used to capture requirements. When identifying and detailing use cases, you look at the problem from the perspective of users. Only focus on what an actor expects the system to do. First step is to identify the use cases and actors and then detail the use case flows.
1- Identify the use cases and actors
In your example send email could be a use case initiated by the end user (your actor). What happens next (e.g system sending a notification to the agent) could be modeled as part of the flow of this use case.
Another use case could be the agent actor handling what they have to do after receiving the notification from the system (a prerequisite of this use case could be that a notification has been received).
Note that you could combine these two use cases together and have the agent as a secondary actor (secondary actor interacts with the use case but does not initiate it). Whether you do this or not, is a modeler's choice and depends on the size of use cases, number of use cases and many other things.
2- Detail the use cases
After identifying use cases and actors, you should detail use cases. The most important part is to detail the use case flow (step by step interactions of actor and system). This can be written as text or drawn as an activity diagram.
So to answer your question: yes it is possible and very common to combine activity diagrams and use cases; that is an activity diagram drawn to show the flow of steps of a use case.
Deployment diagrams on the other hand are totally irrelevant to the requirement elicitation phase. They model the physical structure of the system and how hardware components and software components interact.
In fact, it is very odd that you have learned component diagrams before class diagrams, sequence diagrams, state diagrams and many other diagrams.
I need to know this differences in order to undestand how to use them right.
Which are the differences of DFD and Activity diagram?
Actually, it's reasonably logical. You only have to look at the names.
In data flow diagrams, the lines between "boxes" represent data that flows between components of a system. Because these only show the flow of data, they do not give an indication of sequencing.
In activity diagrams, those lines are simply transitions between activities and do not represent data flow at all. They more represent the sequencing of activities and decisions. You can tell from these what order things happen in.
That's a simplistic explanation but should be a good starting point. Further information can be garnered from Wikipedia for DFDs and activity diagrams.
Explicit bias: I'm a DFDs proponent.
#John is correct that Activity diagrams can be used to represent object flow. #pax equally correct they seldom are.
Two big DFD advantages for me:
Link to object model. Data stores on a DFD provide a really nice way to link the data produced / consumed to the object model. Very useful for consistency and ensuring your thinking is joined up.
They de-emphasise control flow. Far too often designs over-constrain sequencing. Activity diagrams do support concurrency - but it requires the user to (a) remember and (b) use it. So the default is over-serialisation. DFDs don't. They lay bare the real sequence dependencies without any extra effort on the part of the user. Consequently they also make it easier to see causal relationships. If processes a and b both require data input D then it's obvious on the diagram. And hence parallel activity is obvious.
Don't get me wrong - I'm not against Activity diags. Where control flow is the primary consideration I'll use an AD over a DFD. But empirically I'd say I find DFDs a more useful tool in ~70-80% of cases.
Of course, YMMV.
Just a humble opinion from someone who has had to explain processes, both computer and manual, to upper management and CIOs. I have found simple is better and pound-for-pound, DFDs get the message across when I am actually "asked" about details. That being said, the better approach is to always practice the story line and answer in simple answers.
One final comment regarding the age of tools and products. Remember that in most cases these are running the business and work pretty darn good. The adage "you break it (or replace it) and you own it" can make you a hero or make you into a clown.
We have a CIO who wants to replace all mainframe application for the simple reason that they are old technology. One must weigh the consequences and understand if the replacement can handle workload. Have you ever wondered why JPMC, Credit Swiss, Walmart, and Bank of America to name a few still run mainframes?
My apologies for taking it in that direction. Just make sure, whatever analysis tool is used, that all aspects of the replacement are documented including workload, I/O, concurrent users, adoption curve, and scalability.
Data Flow represents flow within one module or one independent code. However Sequence Diagram represents sequence of activity in between different modules.
Yes at some points they may pass the same messages.
I basically use Sequence diagram in interface documents which will be shared with other modules/elements, however DFD will be used in Low level design documents which will be used to develop the code within one module or network element.
If we look closer to a dataflow diagram, we can notice that when a node collects data from all its edges, it starts to process them. And to process, it needs an activity token, which represents access to a processor. Usually the process of obtaining that token is omitted, but it has to exist. Typically, the whole node as a token is put in a double-ended queue, where on the other end of that queue free activities (processors or threads) are stored. A thread pool is a perfect example of such a queue, and the nodes ready to work are represented as tasks. As soon as a node meets activity, they both are taken from the queue and actual processing starts. When processing finishes, activity is returned to the queue. This way we can think of activity as a special kind of token.
So both dataflow and activity diagrams are just simplified variants of a general active-data-flow diagram, with either activities or data tokens omitted. But generally, both kinds of tokens can be represented in a diagram simultaneously.
Programmers used to think about threads as activities, but if we look at them closer, we notice that when a thread is ready to execute, it gets in a line to processors, and real execution starts only when a free processor switch to that thread. This is absolute analogy as tasks are executed on a thread pool. So from simplified point of view, a thread is an activity, and from more rigorous point of view a thread is a data token and the only real activity is a physical processor. This shows that activity tokens are not different from data tokens. And indeed, we can omit the route of node chasing an activity and consider a dataflow node as an activity itself, which starts to work immediately when all its edges (inputs) contain data.