This project is read-only.

OCL Specification

Topics: Developer Forum
May 4, 2007 at 6:31 PM
Edited May 4, 2007 at 7:13 PM
Here is a message from Lucas Ontivero:

Hi Justin
Look this: OCL Specification (Document of interest)
OCL is a language that now is part of UML 2. Maybe e# could be compatible
with OCL. Taht would be great.

May 4, 2007 at 7:13 PM
This is pretty interesting, I don't really know anything about OCL I must admit, I'm looking through the document but it's fairly large so I'll have to absorb it slowly. I'd be interested in hearing more about what you thought about how OCL could apply to E# and how to make it more compatible.

Of course while designing E# I had a lot of concepts from UML in my head already but the interesting thing I'd have to say about UML in general is that E# mostly exists to counter some of the limitations that I percieve in UML. I mean if UML is so great why bother with E# at all? I think the problem with UML is simply how complicated it is and, by nature, how visual it is. Which might be a strange way to think about things but I find that it is actually MUCH easier to do design in a more traditional coding style. Of course when you're just talking about classes it is a little to fine grained for large systems but I also find when using UML it ends up being nearly as confusing. I mean I like UML for visualizing broad generalities of a system but once you get into details and adding too many methods and fields and whatnot it gets ugly. This is really why E# was invented.

The OCL Language description says this:
"OCL expressions can be used to specify operations / actions that, when executed, do alter the state of the system. UML
modelers can use OCL to specify application-specific constraints in their models. UML modelers can also use OCL to
specify queries on the UML model, which are completely programming language independent." This is something I can get behind. A primary concern of NBusiness is the specification of actions or "behaviors".

I would love to have some sort of graphical editor ontop of the language someday, but I envision it to be about as useful as the class designer for C# is today. I mean it's useful to look at but who really uses it to develop the code? What's useful about the class designer is that it's optional and behind the scenes you have the powerful language of C# to really drive the details. This is the problem with UML I think, behind the scenes is what? Nothing really, I guess you can generate code from your UML of course but that's not quite the same as E#.

At least that is the way I feel when I try to dig into it. Being able to actually design my system in the same style that I use to code my classes I think is really necessary. But if the UML style designer synch'd via code generation with E# code behind... to me that is powerful. Along side intellisense and whatnot I believe you end up with something equivalent but far more practical since it appeals to the way that developers already are accustomed to thinking about things.

Perhaps this is also the thought process behind OCL? I'm not sure yet I'll have to read more, if so then I could definitely envision some further cohesion. After looking through the document briefly I must say that I'm not real pleased with some of the syntax :) Of course this is just my preference but one goal of E# is to be extremely clear and easy to learn. That being said, there is no reason why the EntityCodeProvider framework couldn't be used to leverage NBusiness with a different language implementation. I definitely kept that in mind when I started out and it should be fairly easy to do it!

I'd love to hear more about this though, I'll try to read some more when I get some time.

May 8, 2007 at 4:16 AM
Justin, OCL specifications are hard, large and boring therefore I recommend follow document, it is very easy and interesting.

I am 100% agree with you respect to UML but I ccoulnd't to explain my idea very well.
I think that e# could implement validation rules compatible with ocl concepts or contraints. When I say "compatible"
I really want to say samething similar to "ocl syntax style".
Why? because it allow to make expressions as:

  • A company has at least one address
  • Every company director has a assistant.
  • Assistants must be older than 40 years old
  • Nobody can to earm more than company director
  • Employers who work in more than one project must to earn more

It could to grant a enormous power of expression to e# language.
May 8, 2007 at 5:05 PM
I see what you mean here, these are some interesting points. Some of the constraints you list there could be possible to do with some minor tweaks to the way validation rules work:
validate Addresses mincount 1; //for A company has at least one address, this assumes you create a "mincount" custom validation rule.
validate Assistants mincount 1; //every company director has an assistant
validate Assistants minage 41; //assistants must be older than 40 years, this would require a custom rule.
I'd have to change things so that you can validate relationships as well as fields, which shouldn't be too hard actually.

Doing the other two might also be possible to do as validation rules but since it would require quite a bit of data access to validate it might be better suited as a custom action during a persist:
action VerifySalary when persisting; //custom code might throw an exception if the company director earns less than someone else etc.
Thanks for the good ideas, I'll look into that document and see if I can get some more.
Jun 12, 2007 at 3:23 PM
I made a work item for Applying Validation Rules to Relationships like you suggested, and I finished it up last night. Any validation rule can be applied to fields or relationships now. Validation rules just look at the passed in value from the property so you'll probably want to apply rules that correspond to collections. The "required" and "Min/Max Length" rules make the most sense right now but it is possible to create new custom rules as well.