Visual Contracts are a simple abstraction. They represent the information that normally appears in snapshots (object diagrams), plus some additional information that normally comes in the form of constraints. They are much more than that, but this explanation is enough for the moment.
My initial goal was to represent snapshots in the most compressed way possible. This was quickly done. The problem was to represent instances without increasing the number of boxes in the diagram, since this is what makes this kind of diagrams not scalable. As a byproduct, I was able to represent also the change. Because of the visual approach, and since my operators were very explicit — a nice feature my advisor wanted to have– the change can also be represented clearly: requisites, causality, effects.
I wanted to remain UML-compatible. I took UML diagrams, and I saw no reason for changing this. However, after the first year of having proposed my solution, the notation became more SEAM-compatible. SEAM is the methodology –including the notation– developed by the group that my advisor leads.
I must explain here that I used most of the notations that are now under the UML umbrella, before UML was born. I even developed virtual machines for real-time systems that implemented SDL, the last language UML adopted in the version 2.0. Therefore, I am not a fan of UML. As a senior architect, I’m used to work with it, but most of people assign it many wonderful properties and even miracles. This has always surprised me. We’ll blog about that aspect some time later.
As a result, Visual Contracts can nicely complement UML specifications.
