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 is intended to illustrate the advantages of using the Diagram Filters, functionality added in EA version 9. Two case studies based on my current experience illustrate the purpose of Diagram Filters:
1- to filter dependency connectors between provided and required interfaces on a UML Component diagram,
2- to show the differences between the specifications and two implementations through the use of UML State Chart diagram.
OMG celebrates the 15 year anniversary of UML!
Developed in 1995, UML modelling language became a standard in 1997 through its official version 1.1.
UML is currently in its version 2.4.1, until the next version 2.5 is released.
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.