UML Diagrams — Part II
PS: This is a continuation of the blog UML — Part I. If you have not read it I highly recommend you do.
Introduction
Just to brush you up, in the last blog, we introduced ourselves with the UML diagram. We also decided on a problem statement for an activity-based diet application. In this post, we are going to construct all the Structural Diagrams for the same
Class Diagram
This diagram is an important diagram in the overall design and development process. It defines the classes required by the system. For those folks who don’t know what classes and objects are
Objects are collections of operations that share a state and classes serve as templates from which objects can be created[1]
I recommend you read this blog by Lucas Soares before moving on forward as it might be helpful for you to understand the basics of OOPs before moving forward.
Moving on to creating our class diagram, this diagram consists of all the classes required in the application. In order to make it more organized, each class is represented as shown below
Here the attributes and methods as we know can be of 3 types represented as
+ : public
- : private
# : protected
Thus, for our example say we need the classes as Food, Nutrition, HealthTips, User, DailyInfo, etc. Thus the class diagram will contain all the members and methods placed inside those classes. This will also contain the relationships between the different classes. Now if you have done a bit of object-oriented programming you may know the standard inter-class relations like association, inheritance, etc. The below figure illustrates how these relations are displayed in the class diagram
One of the most commonly used relations is the association where two classes are correlated to each other and inheritance where one or more (child) classes inherit some properties from one or more (parent) classes
So now the class diagram for our problem statement may look something like this
Note the different styles of arrows, here the solid filled arrow indicates that the (child) AuthInfo and (child) HealthInfo inherit from the (parent) User class. Also since Workout is a part of the overall HealthInfo we indicate it with a hollow rhombus.
This is just my impression of the system and by no means is a full and final solution to the problem. If you have any other suggestions I would love to hear them in the comments.
Object Diagram
Object Diagram as suggested by the name is a diagram that represents all the instances of the classes created in the class diagram.[2] The usage of this diagram is fairly limited, and it is majorly used to show examples of data structure used in the application. The latest convention of UML is UML 2.5 does not explicitly contain an object diagram but specifies just a notation for instances of the created classes.
As we are using the latest UML syntax we won’t be drawing it for our problem statement.
Component Diagram
The Component Diagram is an aggregation of the entire class diagram. This means that each component is a group of multiple classes or other components. This diagram is extremely useful when the given problem statement has a huge amount of classes present and it may become too crowded to draw a class diagram for the same.
A component is represented as shown in the figure below
The squares on the side are called ports and it is the entry or exit point for data to and from the component. Similar to class diagrams these diagrams also have a certain set of relations displayed in the image below
Thus, the component diagram for our problem statement may look something like this
As shown in the above figure the component diagram is just the abstraction of the class diagram. This means it is more generic and has a lot fewer components than the class diagram. Take our problem statement itself, if you see the class vs component diagrams the component diagram is much more clutter-free than the class diagram. Apart from this the component diagram also helps to organize the development of the application in a more structured manner where the components can run independently of each other. This is really important, let’s understand this concept with an example
You are going on a trip in your vehicle, and suddenly you get a flat tire. 😑
Now what? Do you throw away your car? No, right you might repair the puncture or in the worst case replace the tire, not the entire car. This is because the tire is a component in the entire car ecosystem and the rest of the car can function without it. Note, functioning does not necessarily mean it can achieve its goal, in our example, the car cannot travel from one location to another which is the goal of any vehicle, but the engine still functions.
Great! Let’s move on to the deployment diagram
Deployment Diagram
The deployment diagram is a diagram which actually shows how the system will be implemented on the hardware[4]. It consists of all the necessary components required in actually deploying the application. It is one of the most important diagrams for the deployment team, as it lists out all the required components the deployment team needs to work on.
Let’s move on to explain it further using our problem statement as an example. The deployment diagram for the same is given below
As you can see there are some familiar relations in the diagram so we won’t go much into the details about it. The new thing is the cuboid structure, this is called a node. A node is an entity that executes various systems, subsystems and processes that are related to the various components in the application.
The above diagram is relatively a basic level and good for understanding purposes, but in reality, each node has a ton of activities, processes and methods written inside which help a great deal while actually deploying the project.
Conclusion
Wow! If you made it this far, you really have a great learning capacity 🙇. It’s been a long post, packed with new concepts, so I will recommend you to take a problem statement of your own and practise drawing all the structural diagrams on that, so you can get a better understanding of how to create one, before moving to Part 3.
Anyway, now that we have the structure and deployment plan of our application ready let’s move on to the activity diagrams of the same so that we can make it as foolproof as possible.
Don’t worry take a break have a cup of tea or coffee ☕️, refresh yourself and then move on to UML — Part III 😄
References
[1] Rentsch, T., 1982. Object-oriented programming. ACM Sigplan Notices, 17(9), pp.51–57.
[2] Pokkunuri, B.P., 1989. Object-oriented programming. ACM Sigplan Notices, 24(11), pp.96–101.
[3] Files, A.N.M.C., 2013. Omg unified modelling language (omg UML). Object Management Group, pp.1–752.
[4] Bell, D., 2003. UML basics: An introduction to the Unified Modeling Language. The Rational Edge.
Find my writings interesting you can find my other articles here.
