• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Use of OCL(Object constaint Language)

 
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ranchers,

I personally feel OCL is a boon to 21st century Modeling.

Is it something which will be used by both the Business Stakeholders and IT Stakeholders in the future,to bridge the communication gap between them by specifying the Original or Changed Business Constraints involved in a particular Application.

What is the Future of OCL according to you guys...

thanks....
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The problem with formal specification languages like the OCL is that most people simply have problems wrapping their head around them. It's just not how people naturally think. I have seen a university professor writing a formal (algebraic) specification for a list (arguably one of the simplest and most well known data structures), so that accidentally true was defined to be the same as false...

Anyway, the best way to solve the communication gap between business and technical people is to actually have them communicate and collaborate day to day. Let them sit close together, ask each other questions when they arise - and implement close feedback loops, such as having a running, tested, deployable system demoed to the business people at the end of every week.

As for actually writing down stuff, it seems to me that approaches that take more example-based approach - such as automated acceptance testing using FitNesse - are much more likely to bridge the gap of understanding in the details of business rules.
 
Rakesh Chaudhary
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

The problem with formal specification languages like the OCL is that most people simply have problems wrapping their head around them. It's just not how people naturally think



I think its because the language is not very trivial,but with a editor having Code Sense and Syntax Highlighting its very much possible to grasp a repo for it.

to solve the communication gap between business and technical people is to actually have them communicate and collaborate day to day



I think its practically impossible,to have daily meeting's between the Business stakeholders and the IT stakeholders for a distributed project.

Instead of that they can have the Overview of their project by help of some visual specifications.And how great it would be if the visual specification has the business constraints embedded in it,in a form of language which is readable by all the teams.Like OCL.

automated acceptance testing using FitNesse



Are you trying to highlight something on Model Driven Testing.

For this approach too,I think we need a language which expresses or which makes the blueprints of a System under development more precise and informative,with a capability of generating code for the Business Logic as supported by some tools having OCL support.

Thanks
:roll:
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rakesh Chaudhary:
I think its because the language is not very trivial,but with a editor having Code Sense and Syntax Highlighting its very much possible to grasp a repo for it.



I don't think the primary problem is writing the language. The primary problem is reading it and knowing whether it actually describes what you want it to describe. Developers are trained in using these kind of languages. Heck, they probably became developers because they have a knack for using them and/or like to use them (and even they don't always get it right). Business people don't typically.

I think its practically impossible,to have daily meeting's between the Business stakeholders and the IT stakeholders for a distributed project.



Yes. That's one of the reasons why distributed projects are so much harder.

Instead of that they can have the Overview of their project by help of some visual specifications.And how great it would be if the visual specification has the business constraints embedded in it,in a form of language which is readable by all the teams.Like OCL.



I still don't think why you'd think that OCL is in fact "readable by all the teams".

Are you trying to highlight something on Model Driven Testing.



No. Just some plain and simple Acceptance Testing.

For this approach too,I think we need a language which expresses or which makes the blueprints of a System under development more precise and informative,with a capability of generating code for the Business Logic as supported by some tools having OCL support.



I'm not sure how code generation entered the picture.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic