Technical Design of Software: Visual modeling. UML Class diagrams

My name is Andrii Vovk. I am an Android developer in AllStars-IT Ukraine. Let’s talk about technical design of software. I’d like to start with this article about visual modeling and UML Class diagrams.


Visual modeling has been conducted over the years as a means for communication between developers and as a part of decomposition – an important stage of a software development process: before starting coding, it’s a good practice to break up a complex system or a feature into simple discrete pieces, to ponder classes’ structure and interconnections, to capture the behavior of a system visually. This is where UML (Unified Modeling Language) comes into play.

The primary authors of UML – Jim Rumbaugh, Ivar Jacobson, and Grady Booch – originally had their own competing methods of visual modeling: OMT, OOSE, and Booch. Eventually, they joined forces and brought about an open standard of notations for documenting systems based on the object-oriented design principles.

UML has many types of diagrams, which are divided into two categories: static (or structural) which emphasize the static structure of a system using objects, attributes, operations and relationships; and dynamic (or behavioral) which describe the dynamic behavior of a system by showing collaborations among objects and changes to the internal states of objects. The most often used in software development are structural Class diagrams and behavioral Sequence diagrams.

In Class diagrams, a class is depicted as a rectangle with three horizontal sections: the upper section shows the name of a class; the middle section consists of attributes of a class; and the lowest section contains methods of a class. To indicate access modifiers for a class’ members, “-” (for private), “+” (for public) and “#” (for protected) prefixes are used.

An interface is represented as a circle with two horizontal sections under it: the upper section shows the name of an interface and the lowest section contains methods which an interface exposes. It’s also a usual practice to depict interface with a rectangle – the same way as class is drafted.

Relationships are graphically represented as lines: shared aggregation (aggregation) – with a hollow diamond at the aggregate (whole) end; composite aggregation (composition) is depicted similarly, but the diamond is filled with black color; to show inheritance or generalization in a UML diagram, a solid line from the child class to the parent class is drawn using an unfilled arrowhead; realization (implementation) is represented in a similar way, but with a broken line.

As you can see, UML is simple, flexible and does not have any dependencies on any technologies or programming languages.

So, when developing software, it may be a good idea to invest time in visual modeling of a system to see it in a “big picture” and base further development process on solid groundwork of technical design’s results.

I hope that this overview can help to improve your software development process and wish you happy engineering!


Sources: – “UML Overview” by Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy – “An introduction to the Unified Modeling Language” by Donald Bell – “Unified Modeling Language” from Wikipedia – “Java tales” by Sergey Nemchinskiy


Leave a Reply