Author Archives: Fadi Akram

Blog post 1 – UML Class Diagrams

For my first blog, I wanted to discuss UML Class Diagrams, a topic we covered in class. They help put programs in perspective by showing their structure. UML class diagrams have a very simple set up. Each class is represented by a box, and in each box, there are 3. All classes have these boxes, and all these boxes are divided in the same exact way. They look like this:

When writing class names, they must be in bold, and they must start with a capital letter. The font is also used to show other details like what kind of class it is. If it is in bold then it is a concrete class, if it is in bold and italics then it is an abstract class. If you want to denote a specific type of abstract class, like an interface, then it will use the same markdown setup as an abstract class, however, it will have the classifier «interface» on top of the class name. So, it should look like this:

Attributes are listed in a specific way, and this is something that I had a tough time getting used to. Generally, in programming languages we write the data type followed by the variable name, however in UML Class Diagrams, it’s the other way around. Attributes are listed first by name then by data type, and the two are separated by a colon. There is one more thing to touch on, and that is the visibility of the attribute. To denote a public attribute, there should be a (+) sign in front of it. To denote a private attribute, there should be a minus (-) sign in front. Finally static operations are distinguished by an underline font.

Finally, we get to operations. They work similar to attributes; the only difference is that operations are denoted with parentheses. The return type of the operation, its visibility, and so on works the same way as attributes. If a class a has a parameter, then it listed as an attribute but inside the parentheses. It should look something like this:

Note that the class name in this example should have been bolded.

Finally, we get to the last element that I will discuss, and that is relationships. Since these diagrams are meant to be a blueprint to show how programs are structured, we need to show how the classes interact with each other. Tis done with arrows. There are three different types of arrows that show different types of relations.

Solid Arrow: The class utilizes the attributes of the class it points to.

Hollow Arrow: The class extends the class it points to.

Dotted Arrow: The class implements the class it points to.

This is how they look like in use:

This is a very basic overview explaining my understanding of how UML Class Diagrams work. There are many other elements that left out such as multiplicities and composition. I recommend using the sourced I used for further reading:

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.


Hello everyone, welcome to my blog! I’m a senior computer science major at Worcester State University. I will be using this blog to document my journey in CS-343.

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.