UML Diagrams — Part III
PS: This is a continuation of the blog UML — Part II. If you have not read it I highly recommend you do.
Introduction
Just to brush you up, in the first blog, we introduced ourselves with the UML diagram. We also decided on a problem statement for an activity-based diet application. Next, we created the structural diagrams for our problem statement which consisted of Class, Component and Deployment diagrams. In this post, we are going to construct the behavioural diagrams for the problem statement to test how the application would behave in different scenarios.
Use Case Diagram
The use case diagram is an important factor in keeping the client or stakeholder of your project in the loop with the development. One might call it a blueprint of the complete application[1]. The use case diagram simulates how the application might be used by different users, and what all can the users do inside the application.
In order to simulate the users, the diagram has a bunch of “actors” who can roleplay any type of user of the system. These actors are denoted with a stick figure. The system or application is enclosed inside a boundary and various activities are displayed inside it. The actors can interact with these activities and thus give us the flow of how the application may be used.
As always, there are some specific relations between different entities which are shown in the figure below
Now let’s move on and see how actually the use case diagram may be used on our problem statement
As mentioned earlier in our problem statements the actors are roleplaying the customer and admin roles. The system is depicted by the boundary and the activities have certain communication links between each other and the actors.
Do you notice something familiar about the activities present in the system? Yes, exactly they are closely correlated with the classes in the class diagram.
Now, by seeing this use case diagram it is easily understandable why it is so favoured by the clients and stakeholders. Previously all the diagrams which we drew were very technical and it would take a lot of thinking to understand them for a non-technical person, but the use case diagram is in a sense easy to understand. Thus, the clients or stakeholders can give the development team input regarding the process and flow of the system.
Activity Diagram
This is another very important diagram for both the development team as well as the clients and stakeholders. As the name suggests the diagram displays all the activities that are going to take place inside the system.[2] This can be a very hard task to do, if not done right. So the UML gives us a bunch of rules for drawing these diagrams.
We will explore these rules in a methodological manner and in a little bit of depth as most of these rules are reused in the sequence diagram
Objects and lifetime
Objects in an activity diagram are the entities from which various activities are derived. For example, if the cash counter is an object, then cash collection, cash deposit, cash withdrawal, etc. may be the activities under the cash counter. An object is displayed using a rectangle as shown below
Notice the dotted line below the object, that is called the lifetime of the object. A lifetime is a total time for which the object exists inside the application. This means that if the bank opens at 10 am and closes at 6 pm the cash counter won’t be open till 10 pm. Thus, the lifetime of the object is from 10 am to 6 pm
Notations
Like all the other diagrams, the activity diagram also depicts the relationship between the other activities, thus the notations of the same are listed below
So, after all, that, let’s actually move on to our problem statement and draw an activity diagram for the same
Now, you can see how easy it is for a non-technical person to see how to system may be used and suggest some changes if the system is not behaving in an expected manner. The development team can also backtrack this to the class diagram easily due to the objects and class relation and make some changes before actually starting the development of the project.
Sequence Diagram
This diagram is really similar to the activity diagram in many cases, but the key difference here is that it displays the sequence in which the activities are going to be performed. This is especially helpful when you have complex systems including authentication as it drastically reduces the possibility of showing a user something he is not supposed to see and other cases similar to it.
We will also see some concepts which are different from the activity diagram and the notations used here
Object activation
Now unlike the activity diagram, we have an object activation phase in the sequence diagram. Continuing with our cash-counter example, a cash counter has a lifetime from when the bank opens to when it closes, but this does not mean that there are continuous cash transactions going on. Thus, whenever there is a cash transaction going on we “activate” the cash counter and after the transaction is complete we “deactivate” it. This activation process is shown as follows
Notation
These are the notations in the sequence diagram
So the sequence diagram for our problem statement can be like follows
Conclusion
Finally! We have everything we need to start the development process, satisfy the client, deploy the project and profit from it. Phew 💦, that was a lot of work! Now if you are someone like me, who has not yet worked on a huge team project containing hundreds of employees, you might think this is a bit overkill. Well, in a way you are right 😅, you do not need all these steps for a small scale project as most of these things can be discussed, but imagine working on the development of a huge application, like say Google. If you do not have such solid documentation of everything, it might be impossible to keep the project on track and achieve the goal. Thus, UML diagrams are a huge part of all the software engineering process.
Anyway, if you felt some interest in this topic, this blog trilogy is not even the tip of the iceberg. There is a ton of material available online and also in the references for each of the blog posts.
Hope you enjoyed the series, stay tuned until we explore something new again 👋
References
[1] Gemino, A. and Parker, D., 2009. Use case diagrams in support of use case modelling: Deriving understanding from the picture. Journal of Database Management (JDM), 20(1), pp.1–24.
[2] OMG Unified Modeling Language Superstructure Specification, version 2.1.1. Document formal/2007–02–05, Object Management Group, February 2007.
[3] Files, A.N.M.C., 2013. Omg unified modelling language (omg UML). Object Management Group, pp.1–752.
Find my writings interesting you can find my other articles here.
