Software modeling diagrams

Author : DAOUDI Samir | Context : MSc Software Engineering – Object Oriented Analysis

Introduction
Due to the complexity of some software-solutions and especially the complexity of the inner design and objects composing the solution, software architects tend to use graphical tools to represent the composition and interaction between objects (Unhelkar, 2005). We’ve seen in the past weeks some diagrams as the use-case where the requirements were translated into a graphical representation with different actions, operations and links. Based on that representation of requirements, software architects and developers might start designing the classes with their properties and methods. These classes are the representation of objects required within the software-solution and are supposed to handle certain information and/or perform specific actions. For this reason there is a set of communication between objects for different reasons: Request information, fire an action, respond to stimulus …etc.
It is important to understand the communication between objects (what information is passed in which form and what response is sent back). In addition to the communication side, objects are not static and constant in memory. They can be in different states depending on specific conditions. These changes can be represented by the state machine graph where the different states in which an object can be are represented linked with arrows showing the event which fires this change (Grady, 2006).

Interaction diagram represents the different objects involved in a specific scenario with the interaction and links between these objects. The interaction is part of the dynamic behavior of the system being developed (Deacon ,2005). Interaction diagrams are a good representation and easy to understand graphs representing
– The order of sending messages between objects
– The type of data being sent
– The expected reply
– The type of call (synchronous or asynchronous) …etc.

State chart is used to represent the different states that any objects can be at any time during its existence. The state chart focuses on one object at time. There is no representation of the other objects even those that cause the actual object’s state to change. It start with the initial state of the object and all the states are represented in the graph and linked with arrows holding details about what caused the object to change from the previous state to the actual one. These diagrams are useful to understand the different situations an object can be in and also to plan the correct tests in order to check that the object behaves as expected in all situations.

Operation specification is the review of the different operations in the class, after enhancing and reviewing the interaction between classes (Unhelkar, 2005); we might find new operations required and get new details about the type of information being passed as input or output. In addition to all these details, defining what happens before and after the operation become clear thanks to the State Chart and Interaction Diagrams.

I personally have been involved in some software development projects where the complexity of the project was fairly significant, however for some reasons we did not use the interaction diagram neither the State Chart. The only approaches we used were:
– Converting the end-users and stakeholders’ requirements into more technical document by hiding the useless information and detailing the most important requirements.
– Using UML diagrams to design the database schema and relation between tables (Primary Keys, Foreign Keys and some constraints).
– Using UML diagrams to represent classes with the following details (Base classes and inheritance, type of classes, properties and methods).

The interaction was not represented graphically, however the technical description of requirements was considerably good to let us as developers understand what communication and interaction between objects should be established.
Honestly, during this week I’ve seen the advantages of using these diagrams, certainly it adds some tasks for the analysis and design phase, but the advantage of these diagrams is that they allow an easy understanding and clear image of what is being done within the solution and I think they should be really valuable for the maintenance and upgrade of the solution. If we aim to change some specifications in the software, we can easily target the objects involved in this functionality and the interaction between them in order to better plan how to apply the modifications.