In an earlier post, I identified ISO20022 as a model-driven success story. Here, I give some other examples of model-driven from e-Government and telecommunications. They are not all at the same level of maturity, but the reason why a model-driven approach makes sense is the same.
The Origins of OCL
September 12th, 2012
Edward Willink writes about the origins of OCL. Ed represents Nomos Software on the OCL and QVT RTFs at the OMG.
It is nearly 20 years since, in 1994, OCL evolved at IBM from Syntropy as a ‘business engineering language’. It is nearly 10 years since, in 2003, OCL 2.0 was split off from UML 2.0.
To understand the history of OCL, it is necessary to understand the history of UML, which arose in the 1990s as a compromise between competing modeling notations. This compromise is easy to criticize but to do so can ignore UML’s many successes, not least of which is that we no longer argue about the shape of a class; the Booch clouds have been consigned to history. UML and its SysML extension provide the standard graphical notations that can be used for a very wide range of modeling activities. Of course the real problem with UML is that it is too big and it lacks precision and so this is where progress is being made. Executable UML defines a subset with much more rigorous semantics. OCL provides the technology to express semantics rigorously.
OCL is a natural evolution from the original formula translation in Fortran. Data and objects are accommodated by ‘dot’ operators as in Pascal or C or Java, so OCL is object-oriented. UML models are used as the type system for these objects so that OCL is model-oriented. Concepts from functional languages and lambda calculus are adopted so that OCL is collection-oriented, with the ‘arrow’ operator providing operations and iterations on collections of objects. The ideas for OCL originated within IBM and with the benefit of hindsight may seem rather obvious; they represent a very pragmatic compromise between the lack of precision of informal language and formal languages such as Z that are perceived to be too complex and consequently unapproachable to many programmers.
The problems of ‘business engineering’ are still very much with us 20 years on. In modern parlance, how do we ensure more effective communication between business and IT? How do we capture business logic as an architecturally distinct component of a software system? OCL and models still have a role to play.