UML or Unified Modeling Language is maintained as a standard by the OMG (Object Management Group - www.omg.org) since 1997.
As object-oriented programming languages became very popular in the 90s, various design techniques were released and became popular. However none covered the whole design process. In 1995 the "three amigos" i.e. Grady Booch, Ivar Jacobson, and James Rumbaugh, respectively authors of the Booch, OOSE (Object Oriented Software Engineering), and the OMT (Object Modeling Technique) modelling techniques, teamed up to combine techniques and notations under the "Unified Modeling Language" or UML. Two years later, UML became a standard design modelling language maintained by the Object Management Group standards body.
The current version of this standard is UML 2.4.1 (since 08/2011).
UML makes it possible to produce a visual and unified representation of a system's structural and behavioural characteristics through various elements such as activities, actors, processes, components, etc.
Hence UML can be used to help understand and manage complex concepts or architectures. UML is both suitable for simple or small projects with a few models or diagrams, and for complex and/or large projects through a complete set of models, e.g. requirements, use case, analysis, design, architecture, and database models.
UML 2.4 has 14 types of diagrams, divided into two categories as illustrated below:
You may wonder why an incomplete or incorrect diagram would be useful. Shouldn't it make sense to aim at producing the right representation straight from the start, by modelling what needs to be built and achieved?
This article deals with a simple approach: incomplete diagrams provide a visual representation of the system to be built, that once shown to stakeholders, product owners, dev teams, and project managers, will trigger feedback and discussions to move towards a shared vision.
This article deals with a recurring question in use case modelling: given a use case that’s automatically triggered by the system clock or timer, what actor should be used? To illustrate the options given in this article, I’ve chosen the example of a system that processes new card transactions on a daily basis, aim of the use case “Process customer transactions”.
In this context, it is common use to define as the primary actor the system’s clock or timer, since this actor triggers the use case. Is it the only approach or are there alternatives? This article deals with this subject through 3 alternatives.