Is drawing UML diagrams designing?

In this article I will describe a very important myth prevalent in the software development industry which I believe to a certain extent is the root cause behind the non usage of UML in the software development industry and will also help the readers understand the actual state of the software development industry.

The best way of putting this across is by sharing with you this real life scenario.

In my training programs, after I have finished discussing with my participants the importance of analysis and modeling as a tool to analyze complexity along with the need of standardized modeling languages like UML when I ask them the following question

"How many people in the class believe that drawing UML Diagrams like Class Diagrams, Use Cases, Use case Diagram, State Diagrams, Activity Diagrams etc is Designing?"

The first time I ask this question . almost in all of my programs almost all of my participants usually raise their hands agreeing that drawing these diagrams is designing.

Then I repeat the definition of standardized modeling languages and models along with its need and I again ask the same question . this time they change their answer and almost all of them accept that their understanding that drawing these UML diagrams as a part of designing is wrong and accept that drawing these UML diagrams is a part of analysis phase of the system.

I suggest that the readers should not get influenced by the answers of my participants . they should be able to decide on their own.

Take into account the following facts and decide it for yourself

  1. Analysis as a word means to "Understanding" or a process which leads to understanding.
  2. Understanding / Analysis as a word is always associated with complex problems / systems.
  3. The root cause of complexity mostly lies in the structural model of the problem or the system wherein more the number of structural components , more the possible interrelationships and more is the complexity of the system.
  4. For anyone to understand the structural complexity of the problem or the system, the prerequisite is that a person should be able to visualize the structural components and their interconnections.
  5. Modeling is the phase or the activity wherein a person tries to represent various aspects of the problem or the system in a form [graphical, physical or textual] which can be visualized by a human naked eye so that he can understand their interrelationships and the resultant complexity.
  6. In a nutshell human being cannot understand anything which is complex without modeling or modeling of the problem/system is a prerequisite for a person to understand the same.
  7. If only one stakeholder is supposed to understand the problem/system , non standardized graphical models [non standardized graphical models are those graphical models which can be interpreted in multiple ways like circles , rectangles , triangles] can used to represent the same. But if there are multiple stakeholders are supposed to understand the same problem or the system, then it is highly important that we should only use standardized graphical models [Standardized graphical models can only be interpreted in a single way] to represent different aspects of the problem/system so as to ensure all the stakeholders have a single understanding of the system.

In a nutshell we can say " UML Diagrams are nothing but standardized diagrams/models to represent the complexity of software systems from different perspectives and at different levels of granularity one to understand the complexity of the system and second to come out with a representation or a model so that all the stakeholders have a single understanding of a system".

Think about it

  1. Class Diagram is a graphical diagram which will help a person understand and represent the overall structural complexity of a system / subsystem.
  2. Use case diagram is a graphical diagram which will help a person understand and represent the overall behavioral complexity of a single system / sub system.
  3. Use cases are UML models which will help a person understand and represent the detailed behavioral requirement of a single functionality offered by a system in a jargon which can be easily understood by the customer and on a medium which can be very easily operated by the customer.
  4. State Diagram is a graphical diagram which will help a person understand and represent all the behaviors offered by a single system / sub system across multiple use cases / functionalities.
  5. Activity Diagram is a graphical diagram which will help a person understand and represent the complexity of the business logic of a particular functionality of a system.

Consider the above mentioned facts and think "Whether drawing UML Diagrams is designing"

I hope you will agree the purpose of all of these diagrams is two fold. First objective is to understand the complexity of the system from all the perspectives and at all levels of granularity and second objective is to represent it in a standard form so that all the stakeholders have a single understanding of the system.

Hence we can conclude drawing any of these diagrams is a part of analysis stage and should not be considered as designing.

It may look shocking .. but the fact is that majority of the stakeholders in the software development industry are confused between "Analysis" and "Design" and consider "Drawing UML diagrams as designing".

This confusion is not without a reason there is a very subtle point which led to people concluding that "Drawing UML Diagrams is Designing". I will discuss the same in one of the articles related to designing.

 
Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer

www.VPlanSolutions.co.in