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.

Hi,

Visual Contracts were the subject of my Ph.D work. They were fun, but a bit too scientific. As a consequence, sometimes not even me could understand what VCs were about.

I’ll try to make them available to everybody interested. Visual Contracts are sketchy. They may be useful for understanding initial requirements and validating by animating a draft of the initial understanding of the specification. However, they can also add information now included in approaches that add semantic content to the description of Web services such as the SWSO and WSMO.

We will discuss all the practical uses, the mathematical aspects that can easily be used to characterize the dynamics of a system, and how to integrate it to more mature and complementary approaches like LightSwitch.