Question

Question 6

UML is a modeling language that enables software engineers to document and exchange their designs with colleagues. One of the Agile principles states that documentation should be barely good enough. In your opinion, do you feel that creating UML diagrams is a waste of time or contrary to the agile principles? Do we need to do UML diagramming at all in Agile? If not, why? If so, how much and how often should we leverage UML?

Answer 1

Unified Modeling Language(UML) is used by software developers as modeling language. It is used to model system independent of programming language. It is a graphical language for visualizing, specifying, constructing, and documenting information about software-intensive systems. It enables software engineers to document and exchange their designs with colleagues.

Agile is software development approach that focuses on several iterative and incremental development approach, with each of those variations being its own Agile framework.

One of the Agile principles states that documentation should be barely good enough. This reduces use of UML, as:
a) UML is best-suited for the projects which are called a “Big upfront design approach”. In these projects, the requirements and designs are laid out prior to the start of the project. It is not very consistent with an Agile approach where the requirements and the design tend to evolve as the project is in progress.
b) In every iteration, there will be need to create new UML. This will increase the development time.
c) Over the years complexity and size of UML have increased. Right now there are 14 different types of UML, this increases complexity and time.
d) UML is no longer needed for communication, there is visio, powerpoint, box-line method, etc by which developers communicate.
e) In many projects, the software architecture is quite simple or it just follows a reference architecture, and hence there’s no strong need to create diagrams to represent and communicate the design.

However, we can not totally discard UML, as it has the following benefits:
a) This approach helps clarify the requirements, especially when companies are anxious to get on to the development phase. The use case diagrams allow consultants to present a high-level view of the project to their clients and make sure all parties have a clear understanding of the system functionality and operation of the planned system.
b) Creating diagrams comprising all the actors and use cases that make up a particular grouping of functionality allows consultants to use these diagrams as they gather information. It’s wise to continually refer to and refine these diagrams to better understand how things will need to work, whether in person or remotely.
c) The result is a more detailed listing of the customer’s exact requirements for each use case. For example, there might be three or four requirements that correspond with a single action depicted in the diagram. Any action must include at least one requirement, but may have several.
d) UML is Flexible. Stereotypes and profiles can let you tailor UML to your needs. In other words, you can have modeling elements and relations that are specialized for your domain or for the technologies you’re using.

Therefore, they can be used every time there is a change in design and increment. Further UML documentation can be reduced and only drawings can be used.