Related
Please I need help in understanding this two approaches in the uml world. I am a programmer who is new to uml. I just started learning uml lately but kept getting this phrase asked all the time. - Are you modelling or drawing?. An explanation is needed with clear examples.
This link hinted just a little but I am stil confused -- http://modeling-languages.com/drawing-tools-vs-modeling-tools/
UML is a modeling language, which has a graphical notation. Its semantic is precisely specified by UML 2.5 standard of the OMG and also the international standards ISO 19505-1:2012 and 19505-2:2012 (although the latter corresponds to UML 2.4.1).
THere are two different approaches to UML diagramming. And it's heavily influenced by the tools you use:
Drawing tools generally offer UML shapes to be used in drawings. But there is no deeper meaning behind the shapes. It's only pictures. These tools would allow you to mix a use case with a class or an actor in a deployment diagram. The advantage is that you can do what you want. The inconvenience is that what you want may not be compliant.
Real modeling tools let you combine only valid UML elements together and ensure consistency of what you draw with the deeper meaning of the UML language. And they build a true and comprehensive model behind the scene by combining all the facets of the different diagrams.
Modeling tools can do smarter things. They can relate for example a class to their object instantiations in sequence diagram. They can help you to find all the other models in which a specific class is used. If you rename a class or add a property in one diagram, it'll be automatically reflected in all the others.
Modeling requires more discipline, but it's more powerful in the end. Some modelling tools can even use their understanding of UML to generate code out of the model.
You can use UML diagrams in very free way and you can use them up to the specifications. There are even different UML tools - some support only free style diagrams/drafts, some check dependencies and correctness and thus create models. There are some tools in between (MS Visio is one of them)
Nothing is ideal and fitting for everything. For example, some strict tools (VP and EA) forbid to make number-named classes, but according to UML specification you MUST use number names for anonymous classes. But -sigh- we have what we have.
Use of UML as such is not strictly predefined. So, you can use it for freehand drafts, later work on them more thoroughly and make them models. Or do only drafts. Or only models. But at any moment you should know how strictly are you keeping up to specifications. Or at least, trying to keep up. But even very free draft can help you greatly to understand the task or to think in a more productive way.
Currently i am trying to figure out, then to use OWL and then to use UML to describe a domain of interest in a Software Engineering process.
I read this paper by Atkinson, which gives a very good overview about the difference and the equalities of OWL and UML on a semantic and a syntactic level.
However it does not provide a clear indication in which use-cases it might be better to use OWL instead of - for example - an UML class diagramm.
It might be the underlaying development process, which decides the modelling language to take (e.g. model-driven = go for UML, ontology-driven = go for OWL) but for myself it is this difference still not clear?
In both language I can build up a terminology, which I - as an ontology engineer - can reuse in order to infer new knowledge from it. As an Software Engineer I use this terminology for the construction of a (single) system.
So is the difference between OWL and UML just the field of study? Or could I use OWL in order to describe the construction of my (single) software system?
Moreover, this raises the question if the decision of which kind of modelling language to choose is only driven by the goal, which I try to accomplish?
A synthetic answer
UML is a (graphical) language for modeling
OWL is a language used for knowledge representation (KR) in a semantic perspective
In the first place, OWL purpose is not modeling. Using a KR technique is an option in the field of software engineering. It should be distinct from any software engineering process. Both languages have different purposes.
Of course, you could [use] OWL in order to describe the construction of [a software system]. But the interest of such a move would mainly be in automated reasoning about your software construction process and would not be very helpful in the context of a single project. This would only be effective if done for all your projects in order to have a consequent knowledge base (KB).
A detailed explanation
According to the W3C wiki section about OWL:
The W3C Web Ontology Language (OWL) is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things. OWL is a computational logic-based language such that knowledge expressed in OWL can be exploited by computer programs, e.g., to verify the consistency of that knowledge or to make implicit knowledge explicit
There should be some debate about what is a modeling language. For example, the Wikipedia article on the topic considers a broad sense which could also cover OWL. I consider here with the modeling term only the software engineering activity (which is the one you focus on in your question).
You might need modeling in order to define ontologies, just like you would need for the development of a software project. But this OWL modeling would not consider the software engineering elements but rather the domain data of your project. In other words, using UML in a software construction process aims to setup software elements. With OWL, you would not focus on these elements, unless you are trying automated reasoning about software construction.
Beside this, a relationship exists between UML and OWL. A note by Walter W. Change in the frame of the W3C discusses the question. I would summarize the question considering two distinct relations.
Using UML to represent OWL knowledge
An OMG specification called ODM (for Ontology Definition Metamodel) provides a metamodel for defining ontologies. In the frame of this specification, the use of an UML profile is introduced as a way to bridge a gap between both languages. In the ODM 1.1 specification, section 8.4.2:
The goal of a UML profile from the ODM perspective is to provide a bridge between the UML and knowledge representation communities on a well-grounded, semantic basis, with a broader goal of relating software and logical
approaches to representing information.
The UML profile use is introduced in an article. You might find such a profile in the ODM 1.0 specification resources, as a non-normative document. According to what is here considered, this UML profile might be a tool for modeling ontologies.
Using OWL/Semantic Web technologies to represent UML
RDF is the basis format used to write OWL ontologies.
An early (2000) academic work provides a semantic RDF document modeling the UML elements (based on the OMG specification). This work preceded the draft works on the OWL W3C recommendation (2002).
Actually OWL is available as profile in UML. See OMG specfication. So you can use UML with OWL profile in "one soup".
Let's start with the definitions.
Unified Modeling Language (UML) is a general-purpose, developmental,
modeling language in the field of software engineering, that is
intended to provide a standard way to visualize the design of a
system. (Wikipedia)
UML has many diagrams, but none of the classics is designed for ontology modelling. Therefore, researchers have created OWL with this purpose.
The W3C Web Ontology Language (OWL) is a Semantic Web language
designed to represent rich and complex knowledge about things, groups
of things, and relations between things. (W3C)
Such as said by Thomas Kilian in the other answer:
OWL is available as profile in UML. See OMG specfication. So you can
use UML with OWL profile in "one soup".
Therefore, OWL can be part of the set of UML diagrams used in a Software Engineering Process. The main benefit of OWL over classic UML diagrams is when you have to design a system using ontologies. The purpose of class diagrams is to represent classes, not ontologies. If your system does not rely on ontology, stick with the classic UML diagrams; you do not need OWL. If your system uses ontology and you need to represent it on a diagram, use OWL.
OWL is used to describe a domain and to be able to specifically, using semantics, specify knowledge of a domain as well as describe its specificities. Take for example the Friend of a Friend ontology. Using it you can describe how people relate to each other.
You might say that you can do the same thing using UML and you are correct. You can specify properties, relations, and so on, using OWL as well as UML. However, what you can't do with UML is infer domain knowledge. OWL, being a Semantic Web language, models a domain with either an Open or Closed World assumption. Basically you assume knowledge based on what is described in the domain. Then you can use specific instructions to infer knowledge using Rules or just be looking at predicates and statements you have created. Furthermore, you can use specific query languages such as SPARQL to query your ontology as much in the same way you would use SQL to query a database.
TL;DR: Using UML you specify how you would translate a specific domain into software, using OWL you specify knowledge about the domain as it is much richer than UML.
To amend the references of UML and OWL comparison there is a PhD thesis (in German) from Jesper Zedlitz Konzeptuelle Modellierung mit UML und OWL – Untersuchung der Gemeinsamkeiten und Unterschiede mit Hilfe von Modelltransformationen
(Conceptual Modeling with UML and OWL - Exploring the Similarities and Differences Using Model Transformations)
In this thesis studies if and in which extend it is possible to tranform between both modelling languages. In the conclusion (p. 222) it is stated that OWL has possibilities to do more complex modelling and therefore it is not always possible to transform from OWL to UML.
Actually from my work on ontologies in the previous time I see using ontology tools like Protege is very helpful and rich in describing relations between entities and using Tools like OLGA can help you in mapping this ontology to many object oriented language.
Yes, we haven't the capabilities of using graphical representations to design our models like UML but it provides a wide range of options to describe you model.
The importance and benefits of mapping the domain ontology to the UML model are in integrating the benefits and quality that these two modeling techniques provide. That is, if there are already domain ontologies with a certain level of authority, these knowledge bases can help in the creation of UML class diagrams, such as the axiomatic guarantees provided by the description logic that builds it, besides enabling UML power of inferences Provided by this formalism, with the transformation is intended to show the evidence that reuse of ontology can help to reduce ambiguity in class diagrams.
Is it appropriate to think of UML as a DSL?
I know that everybody thinks of UML as a way to draw pictures, but underlying the "view" of UML diagrams there is a model...and the "L" in UML stands for Language.
Another question - is SysML a DSL?
UML is a DSL.
A "domain specific language" lets one specify a problem or a solution in a narrow area of application; banking, telephony circuit design, .... One way to distinguish a DSL is that it cannot do general purpose computation (although there are some DSLs that can). Java, C#, Python and COBOL fail this test. (Some would say COBOL is domain-specific for "business" but its only serious concession to that is a decimal data type, and C# has that too.) ColdFusion fails this test; nonstandard syntax does not a DSL make, but IIRC ColdFusion has some support for generating HTML. Fortran fails this test, but its array(-section) sublanguage is only good for arrays and not general purpose computation. Verilog is very domain specific: it is designed to let you write down digital circuits.
UML focuses on specifying different aspects of how software is structured. [You'll note it can't do general purpose computation; one hallmark]. (It actually has 9 or more different aspects it addresses: classes, statecharts, deployment, ... I'll stick to the class aspect for this discussion). The class diagram aspect lets one describe how data is organized, and operations on that data. You can argue this about software so it can't be "domain-specific". What, building software isn't a problem domain?
SYSML is focused on expressing how systems are joined, so it fits this category too.
A more useful question to ask IMHO is, "If I think of UML as a DSL, what do I gain?" Here I don't think you get a lot. The concept of DSL is useful when you arguing for one you don't have (designed or possess) with the point being better expressiveness for a common problem, and might be useful for arguing "you don't want implement your system entirely in it because it isn't Turing capable". It is also useful if you want to explain that your language is going to have a lot of funny notations, precisely because they serve special purposes. People already know this about UML, so... nothing learned.
While I'm a big fan of DSLs, I'm also a big fan of GPLs (general purpose languages). I think in big systems you should necessarily find a "lot" of both: the DSLs to express what they can succinctly (cuts engineering and maintenance costs), and the GPLs to provide arbitrary computation and glue between the system parts. For me what counts in a language is:
what's the class of problem it claims to address and how well does it do it?
what's the syntax (and is it relatively standard for the problem domain)?
what are the precise semantics (this is where you learn the most)?
how good is the tool support?
how well does the DSL integrate into other parts of a big system?
how big and supportive is the community?
UML has (after 15 years) arrived at pretty good answers to these questions.
Homegrown DSLs often don't do so well, partly due to poor design, but often due to the fact that tool support is difficult to get. My company provides machinery to give DSL builders excellent support to improve this situation.
UML is NOT a DSL because UML can be used to model any vertical domain (insurance software, embedded systems,...)
UML is a (horizontal) DSL because UML is a specialized language to model software systems.
So UML is and is not a DSL depending on how you look at it. You could apply the same reasoning to many other languages like html or SQL. They are general because they can be used to represent/manipulate any kind of data but they are specific because they are focused on one task
Short answer - NO - to both questions.
Think of UML as a tool that lets you describe software architectures, software interactions and so on ... describe them in a general way, language agnostic.
DSLs are specialised syntaxes meant to make it easier to describe some specific set of problems
I think the answer to your first question depends on how to define "General" in the term "General Purpose Language". Wikipedia says it is not a DSL:
The opposite is:
a general-purpose programming language, such as C, Java or Python,
or a general-purpose modeling language such as the Unified Modeling Language (UML).
I am a MDA enthusiast so I think I can provide you a very detailed answer to your question.
What is the UML:
The Object Management Group (OMG), a consortium of companies aimed at providing standard languages and technologies, defined a meta-meta modeling language called "The Meta Object Facility" or MOF (http://www.omg.org/mof). A meta-model is a model describing a model or, in other terms, describing the vocabulary (the elements you can use in a model), the syntax (ho they relate each other) and their semantics (what does each entity mean and how its meaning changes in a given context, etc.). A meta-model plays the same role played by Context-Free grammars with respect to the languages they produce. You can thus think at a meta-meta model as a language you can use to define meta-model. This is what the OMG actually did with the UML. The UML language has a meta-model described by means of the MOF in two documents: The UML Infrastructure and the UML Supersturcture (http://www.omg.org/spec/UML).
The UML meta-model has been defined with the aim of been generic enough to cope with the modeling of different systems belonging to different domains. When you define a new UML model you create an instance of the UML meta-model. You could do that for many reasons: to analyse some characteristics of the system, to share some aspects of the system with other stakeholders and so on. However, one of the most important aspects of the OMG vision are model transformations. You can think at a transformation as a set of rules telling an interpreter how to explore a model and produce something else. You can basically transform a model into two different kind of thins, other models (Model2Model, M2M transformations, defined by means of the QVT language) or text such as code or documentation (Model2Text, M2T, transformations defined by means of the MOFM2T Transformation language). So it is VERY IMPORTANT to understand that a UML model is not its diagram. A diagram is just a pictorical representation of the model contents, useful for umans, but not machine readable. You can't apply transformations to a diagram.
The Eclipse Modeling Framework (EMF) is a very powerful (and FREE!) framework implementing all the technologies I have mentioned. A subset of the MOF is implemented in the Eclipse ECORE language. By means of the ECORE the UML meta-model is defined so grafical UML editors (i.e. Papyrus, TopCased, etc.) actually creates XMI representation of the graphically defined UML models conform to the ECORE representation of the UML meta-model. Such representation can be provided as input to transformations engine. The two transformation languages, and related engines, are also available in the EMF with the QVTo plugin and ACCELEO (implementing the MOFM2T transformation language).
As mentioned UML is intentionally generic. However it also provide lightweight extension mechanisms to extends original language vocabulary with domain specific constructs. This can be done by means of stereotypes. A stereotype is a sort of label (actually with meta-attributes) you can attach on model elements to create new entities in the language. You can for instance say in your models some of the classes could be requirements or something else. There are of course some rules, for instance when you stereotype a meta-class you can not violate its original semantics, just reduce it.
SySML is a profile of the UML http://www.omgsysml.org/. A SysML Block is just a UML class stereotyped as Block, a SysML Requirement is just another UML class stereotyped as Block and so on.
Profiling a meta-model like the UML is a quite easy way of creating a sort of DSL (as with stereotypes you add to a more general language some constructs which belong to your domain) which is compatible with the UML (i.e. you can use SysML and UML together). There is another way of creating a DSL which is defining its meta-model by means of the MOF (ECORE). In this case you create a brand new language which is conceptually at the same level of the UML itself.
Many people say UML is just about diagrams because in many cases they do not know what they are talking about. The topic is far more complex, interesting and promising.
UML is a general modelling language that is not specific to any domain whilst the S in DSL stands for Specific. UML is used for modelling systems that can also be represented by multi-purpose programming languages. DSL on the other hand are constrained programming/scripting languages which are specific to a particular domain.
I often draw a dataflow on a sheet of paper. Even the planning of my little tools is done on a paper.
There exists UML.
The problem is - I don't like it. All the tools I've used (Visio and a lot of online editors) are just not flexible for my hands. With a pencil you can easily draw shapes and connect them, describe them.
What could you suggest in order to create a diagram of data-flow, sequence diagram, etc. in the fastest, most natural and easiest way except on the computer not the paper :)
****Useful links as posted in comments:** SO Link #1 SO Link #2
Right now I am curious about 2 things and one of them was in my minds quite long ago:
1) Mindmap - I've tried a while ago, quite liked it but abandoned. Hoever will give it another try
2) Whiteboard. It would be the easiest and most natural method, except that taking a photo and storing it somewhere on a computer would make the process repetitive and boring.
Has anyone other interesting ideas? I would really like to hear what others are using to design their software and the progress of it.
Thanks a lot!
Why do you want to hand-draw the UML at all whether it's on paper or on the computer?
I agree that you need a model to represent the design. But even in large projects of about 500 man-months, I observed that only 3-4 sequence diagrams really matter and have a chance of surviving the entire lifecycle of the application. Those 3-4 sequence diagrams (and class diagrams that represent their static time relationships), usually represent the high level design of the application.
Or, look at it this way:
Any decent enterprise application will not have 20 different call flows. There will be one or two generic (or abstract) call flows, which all the concrete use cases implement. Let us take a simple Struts / EJB application. The generic flow will be something like - an action class calling a validator and then calling a stateless session bean, which in turn calls a domain class, which will call a DAO. All the use cases of the application just implement this flow with concrete classes that are specific to that use case.
Do you agree?
If you do not, I would like to hear about applications that have 20 different call flows and survived for 5 years after the first release.
If you agree with me, we are boiling down to 3-4 class and sequence diagrams even for large enterprise applications comprising several thousand classes. Why is it a big deal how you draw and maintain those 3-4 diagrams?
You might say that you want to document all the use cases for training or documentation purposes. During my last 14 years of experience in the real enterprise software world, I don’t remember seeing well 'maintained' UML documentation. First of all, good documents are difficult to produce and are not found that often. Secondly, they are out of sync with the code most of the time. Most of my experience is with large banks, insurance companies, Auto companies, etc. Those environments are just too hectic and their resources are limited (really? Are we talking banks? Yes, difficult to believe, but true) for 'maintaining' good documentation.
So am I suggesting that we get rid of UML?
No. We need visual models to represent complex systems. Human brains seem to be at their best when processing visuals. The visual cortex, which is responsible for processing the visual images, is the largest system in the human brain.
So what is a reasonable solution to easily produce and maintain UML models?
Probably we are better off using the current crop of UML tools to draw those 3-4 high-level UML diagrams. If you hate using them, check option 3 below.
For the diagrams at the next level of abstraction (any useful models should have different levels of abstraction), generate the UML from source code. You can generate both class and sequence diagrams.
In this age of agile methodologies, why not just write the shell classes and generate those 3-4 high-level UML class and sequence diagrams as well? This way there won't be any UML to maintain at all.
The source code is the truth.
Can you argue against that statement? If not, why not generate the models from the source code itself? I am not suggesting the round-trip engineering, by the way. I am just suggesting a one way trip - from code to models.
There are 2 main problems however with the generated UML.
When we hand draw a class diagram, we show the relations between the classes involved in a scenario. Most existing class diagram generating tools allow the user to drop the Java classes (the source code) into the tool and the tool automatically shows the relations between the classes. The problem here is, how does one know about the classes involved in a scenario to begin with?
The second problem is the verboseness of the generated diagrams. There are tools available to generate runtime sequence and class diagrams for a scenario. But the diagrams are often very verbose and defeat the purpose of models, whose purpose is to highlight the important aspects and filter out unimportant details.
Good UML generating tools should address both the above problems. There are a few tools in the Java domain that try to address these problems. Check the discussions below:
What tools should I use to visualize structure of my code
Are there any tools for detecting architectural and design patterns in code?
I hope I answered the original question:
Has anyone other interesting ideas? I would really like to hear what others are using to
design their software and the progress of it.
I am the author of the runtime UML generating tool MaintainJ, but I tried to address the original question in an objective manner. Your comments are welcome.
There are various tools that allow you to create diagrams based on textual input. There's some up-front learning in that you need to learn the syntax. However it's not hard to do. Once you have, creating diagrams can be very fast. There are some downsides; in most cases there's limited ability to change the layout/style. Significance of that will depend on whether you like their style or not.
There's a growing number, here's a few you might want to look at:
UMLet: desktop app, supports most UML plus various other diagrams. Can also create your own custom shapes & connectors. FOSS.
WebSequenceDiagrams.com: online sequence diagrams.
TextUML: desktop app. Focus is executable models, auto-generates class diagrams. FOSS. It also has an online commercial sibling.
hth.
I like using a whiteboard and a camera. For even more flexibility, use post-it notes on the whiteboard.
I use ER diagrams (on the whiteboard) to model my data, and message sequence charts (on the whiteboard) to model the data flow. I'll also do quick mockups of UI pages on the whiteboard.
Asides from that, I use Ruby/Rails to code server side and HTML/CSS/jQuery/JS on the client.
If even Visio is not flexible enough, I'd suggest a digital whiteboard or touchscreen with a whiteboard software. After some accommodation you could probably use a simple tablet (without display) as well - they are really cheap.
Regarding pure software: we are trying to achieve a "pen-like" input method with UML Lab, but it currently supports Class Diagrams only...
I think that the UML and code should be mixed using a class diagram. You model your architecture with the class diagram (e.g package, classes etc....) then you code your business finally multiple iterations between code and model.
I think that UML should more be oriented to code but not to focus on textual input.
The problem with standard languages, such as UML, is that you have to invest a considerable effort to learn the language and the modeling tools. These languages are defined by an expert consortium, e.g. OMG, that proposes a language specification suited to the biggest overlap of design problems in a certain domain.
Why not defining your own language that fits exactly to your needs and your specific problem? Such languages are termed Domain-Specific Languages (DSL). Instead of investing into learning a language that's complex, you invest into the definition of a languages that exactly suits your needs.
There are numerous approaches that support the definition of DSLs. The most widespread is the Generic Eclipse Modeling System (GEMS). Personally, I made great experience with GrGen due to its versatility and the possibility to automate working steps using graph transformation.
No. There are various other ways. UML is just an option.
Pen and Paper Prototyping is a great option too, it doesn't have to follow UML.
Mind Map is another great way.
For more adaptive software processes, UML use is encouraged to be as minimum as possible. Such as, teams that practice Agile or XP tend to use UML less and they would rather rely more on informal means to conceptualize the software. In a rigid structured company, UML can be rigorously followed.
I am trying to wrap my head around why we first approach the problem of design and decide upon a visual method (UML), instead of starting with formal specifications that happen to also be executable (RAD prototyping), we start with diagrams that can't be easily proven to work. So when it comes time to prove properties of a model, we find we need to define constraints into our design, so we design a formal syntax (OCL) to define the constraints on the model. I am having a hard time understanding this leap back to where we started.
I find OCL encumbered UML designs (even samples shown in brochures) unreadable, even more impenetrable than the myriad of UML symbols and conventions. So what I want to know is: What are the key areas where OCL is used in the working software development world today, and for whom is it relevant or worthwhile to learn? What does your job role look like? Do architects who never write code use UML and OCL, or do programmers who also design and architect the systems with the same team that implements it, use it too?
[updated: Secondly, it occurs to me that Agile development seems kind of opposed to "Heavyweight" procedures, and that a domain specific language for design diagram constraints like OCL doesn't seem very Agile. Is UML+OCL used in ANY "Agile" shops, or is it universally eschewed by Scrummers?]
Interesting question.
The "holy grail" of the Object Constraint Language was to provide a framework that when coupled with UML allowed a tool to transform that into a concrete Object Graph / Meta Model i.e. a set of classes that already had their basic structure and constraints wired in, so that all the developer had to do was implement business methods. (all this in a language independent way)
JBuilder from Borland tried supoprting this in their enterprise edition, and Delphi with ECO also made use of OCL in a practical way (though not as a transformation input) by supporting the Query abilities. In fact Anders Inver from Borland / BoldSoft, and one of the ECO team, wrote the forward on the OCL bible, The Object Constraint Language, Second Edition (addison wesley)
My personal opinion is that there is not enough pay back to warrant the learning curve. Without using specialised (and expensive) tools the UML/OCL model is still not easily testable in real terms, and the value you get is marginal (if anything) over itterative test driven development. The language independence thing is waaay overrated, lets face it once we start down the Java, C#, Delphi, C++ or whatever path, there is no way in hell we will re-generate in something else, its just not practical.
For what its worth, I am yet to see Model Driven Development with OCL actually used in the real world for a real project. (other than as a proof of concept) What seems to be working lately in the real world is Agile processes, Scrum etc and just itterative development using standard IDE's with standard languages and user stories (perhaps some UML on a whiteboard or storyboard).
The benefit of defining OCL constraints on your models is the possibility of specifying all the business rules of your domain that you cannot represent with the graphical constructs of the UML (for instance, multiplicities are constraints that can be graphically represented as part of an association definition, saying that the attribute A of class C has to be greater than 5 is also a constraint but in this case has to be defined in OCL since UML does not provide a graphical syntax for this)
Obviously, this would be very useful if code-generation tools would be able to take these constraints and automatically generate a code that enforces them (e.g. as if-conditions in Java methods or as triggers in databases that raise an exception when the data violates the rule).
Unfortunately, there aren't many tools offering this functionality (see a list here: http://modeling-languages.com/content/list-ocl-tools) but the situation is slowly improving
Much has changed.
UML 2.5 used Eclipse OCL tooling to remedy the numerous bugs in the UML 2.0...2.4 embedded OCL.
SysML is using Papyrus and Eclipse OCL tooling for SysML next.
Eclipse OCL provides a much stronger UI and an OCL2Java code generator so that OCL embedded in Ecore/UML provides much more acceptable/executable code.
Much has still to change.
The OCL embedded in UML has never been seriously executed.
The OCL definition of OCL itself is lamentable.
I worked with OCL Constraints as a small part of my bachelor thesis. Borland (now Microfocus) Together had an interesting approach thus generating Java code out of OCL Constraints. You defined that variable X should be >= 0 or not empty and Together created assert commands to verify it automatically.