Part 3 : The ABCs of UML diagramming

This is the final post in this series, which was first kicked off last week. Just to remind you where we left off in Part 1; we talked about various UML building blocks, such as Things and what it encompasses. Things are further subdivided into (a) Structural, (b) Behavioral, (c) Grouping and (d) Annotational. In Part 2, we carried on our discussion of Things while leaving the aspects of Relationships and Diagrams to be explained in this final post.


One of the most important building blocks of UML is the Relationships that are depicted in a UML diagram. Relationships tell us what elements are associated to each other. This type of association describes the particular functionality of applications. The different types of relationships are listed below.

(a) Dependency

This is a relationship that exists between two things where a change in one element may affect the other one.

(b) Association

This is a set of links, which connects elements of a UML model. This type of relationship also illustrates how many instances of an object are involved in that relationship.

(c) Generalization

A Generalization is defined as a relationship that makes a connection between a specialized element and a generalized element. This describes an inheritance relationship within the world of objects whereby a specialised object will inherit the behaviours and properties of the generalized parent object.

(d) Realization

A Realization is somewhat different from the relationships mentioned above and depicts the relationship between an interface and an implementation of a class. A responsibility is described by one element while the other implements it.


What we have discussed in Part 1  and Part 2 of this series is beneficial if you are about to draw UML diagrams; all the various elements and relationships that have been highlighted thus far are utilized to complete a UML diagram.

So now where do we go from here? The answer is back to another two-part series that was posted close to a month ago.  This series will offer you a detailed look into UML diagrams and its subcategories i.e. Structural Diagrams and Behavioural Diagrams. Ideally both these two series of articles will cover the length and breadth of UML diagrams. If you haven’t read it already, you can embark on that knowledge-infused journey, right here. :0)

Posted via email from Creately | Comment »

PART 2: What type of UML diagram should you be using?

As promised here is Part 2 of our UML post. As mentioned previously, today I will be giving you a short and sweet run through of Behavioural Diagrams, which also forms a vast part of UML diagrams. To put it simply behavioral diagrams capture the dynamic aspect of the system. The word “dynamic” in this context can be described as being the changing parts of the system.

Unlike Structural Diagrams, Behavioural Diagrams can be subdivided into five types of diagrams.

Use Case Diagrams

Use case diagrams consist of a set of use cases, actors and their respective relationships. These diagrams seek to represent the use case view of a system. A diagram of this type illustrates the functionality of a system. So a use case diagram is utilized to represent the relationships that exist among the functionalities and their controllers (internal/external), which are known as actors.

Sequence Diagrams

A sequence diagram is also commonly known as an interaction diagram. A diagram of this type deals with certain sequences, which are messages that flow from a certain object to another. It is important to note that the interaction that is present between the components of a system is significant from an implementation and execution perspective. So a sequence diagram is utilized to visualize the sequence of calls in a system when it comes to performing a functionality that is specific.

Collaboration Diagram

Another form of an interaction diagram is known as a collaboration diagram. This type of a diagram illustrates the structural organization of the system and the messages that are sent or received. These structural organizations consists of various objects and links. The specific aim of a collaboration diagram is to visualize the organization of objects and their respective interaction.

State Chart Diagram

A state chart diagram is utilized to illustrate the event driven state change of a system. It basically describes the state change of a class and interface amongst other things. A state chart diagram is used to visually represent the reaction of a system through internal or external factors.


Activity Diagram

An activity diagram would illustrate the flow of control in the system. This means that such a diagram consists of both activities and links. The flow is usually sequential, concurrent or even branched. The activities are the functions within a system. Ideally, activity diagrams are usually used to illustrate the flow of controls in a given system. Such diagrams are excellent when it comes to have an idea of knowing how a system will work when it is executed.

So that pretty much concludes a basic assessment of the various types of UML diagrams. I hope both posts were useful in enhancing your knowledge when it comes to software design and communication. As always, I encourage you to get in touch with us with any issues you may have with diagramming (general or specific). While I think we have substantially covered UML as a subject in this space, expect to see some interesting and thought-provoking posts starting Monday fromIndu. Till then – Happy Diagramming!

Posted via email from Creately | Comment »