Out Of Context

By Jon McDonald
A rose by any other name is still a rose.

I have had the opportunity to speak with a number of different groups recently, covering everyone from systems engineers focused on specifications and documentation to software teams, architects and implementation groups. Each group has their own unique language, their own unique way of communication. Some of the most entertaining conversations have taken place when the meetings have had more than one of these groups represented. Each group uses certain words that are overlaid with significant assumptions based on their specific domain. I’ve seen extended animated discussions due to this difference in interpretation of the same words.

In applying ESL design techniques we need to bridge these various domains, hopefully enabling a common understanding between the groups representing these differing domains. With all the different semantics it can be very difficult to achieve consensus even though the competing statements may actually be describing the same things.

I believe one of the central pillars of ESL is the adoption of the concept that elements communicate using abstract transactions. In my mind this statement is very simple and very clear, but unfortunately it must be interpreted in other contexts. What I think of as a transaction may be thought of as a message to a software developer, an event to systems engineer or a signal to an architect. Each of these groups uses different terms and in some cases the same term is used in different ways from one company to another.

As I’m thinking about this I am struggling with a way of expressing this in a concise unambiguous way. What is this transaction that is so central to ESL? In many people’s minds ESL and Transaction Level Modeling are synonymous. “A transaction is a message between elements.” While that’s a true statement it isn’t a very satisfactory definition because it relies on another heavily loaded term, “message,” which is has different implications for different groups.

What if I define this transaction concept as the communication of some instruction with the data associated with that instruction? That may be a bit better, but it’s still incomplete. I have to add that the communication occurs as a conceptual atomic activity. There we have another incredibly loaded phrase, “conceptual atomic.” To me this is very concise and carries a very specific meaning, but for those of you interpreting this outside the context of my mind it may not be as clear.

I’m beginning to feel like I’m in the midst of an extended animated discussion with myself, which I don’t believe is a productive activity. Unfortunately, I believe the only conclusion I am able to draw is that we must rely on the heavily overloaded terms used in the various domains. Our challenge is using the right term in the appropriate domain to communicate the correct understanding, which is after all the very basis of the transaction to begin with.

–-Jon McDonald is a technical marketing engineer for the design and creation business at Mentor Graphics.