Hi Folks,
Here's a contribution on this discussion:
Business rules are OK for models with a higher level of abstraction; that is to say, for business models, logical models (or, if you prefer, the "domain" or "conceptual" models), use case models, and so forth. The UML does have a way of including these in your diagrams (and nicely implemented by EA), with notes attached to the element with a note link. You can either type the business rule directly in the note, type it in the Notes section of your element, or (if you are modeling a class or an interface) include an operation, and type it in the operation's notes section. IMHO, the latter should be the prefered way, and you can display your business rule in the note with "Link this note to an element feature" (right click on the note link, choose the aforementioned option, choose "Operation" as feature type, and then choose the operation that has the note). You can use these notes for your algorithms, business rules, or whatever (just adhere to the KISS principle: Keep It Simple...).
An example of this would be an operation to insert a new instance into a class; say (in the case of a procedure for an RDBMs), sp_ins_entity. You can either model these operations as class operations, or as operations of an interface. These operations work very nicely in sequence diagrams; for instance, a user interface class that has the responsibility of entity maintenance calls sp_ins_entity through a sequence message. And, if your model has enough detail, you can specify the operation's parameters in the "Parameters" section of the operation. Now you can try the "Operations" button in the Message Properties of your sequence message.
OCL is included in the UML standard, so you can use it in high-ceremony projects that require strict adherence to standards (or the like). It does take time to learn it, though, because it has more than its share of hard-to-learn specifications, so it is not suited for projects with very tight schedules. As an alternative to OCL strictures, you can try an "OCL-light" approach, with simply sticking to the algebraic part of the language, which is quite intuitive and easy to learn.
Once you go into your physical (or, if you prefer, your implementation) model, you can copy your analysis classes (the ones in your logical or conceptual model) into your implementation classes, interfaces or tables, in the implementation diagrams of your model. If you have created your operations as stated above, they will be copied into the implementation classes and interfaces. You can then refine and elaborate on them until they contain fully-functional code, which should be placed in the "Behaviour" section of the operation. This section is not displayable through "Link this note to an element feature", but who on Earth would like the whole functional code displayed in a diagram?
The "Notes" sections of the operation will contain a short description of the operation's responsibility, and an example on how to use it or invoke it ("Usage...").
The parameters section of the operation has the parameters, and so forth...
Now, you can display the "Notes" section of your operation in a diagram note with "Link this note to an element feature"; or (better still), generate your code with Ctrl + G (or "Generate DDL", as appropriate), and either see it in EA with Ctrl + E, or with the "View" button. In other words, the Operation's notes, behaviour, params (and other) sections are the NATURAL places for your code, either in their sketchy or in their fully functional versions. In OO and UML parlance, these are now a "Methods", and not just "Operations", but for modelling purposes it is allright to continue to refer to them as Operations.
I would like to point out that the UML does provide ways of spcifying Operations and Methods. Jim Rumbaugh's et al., The UML Reference Manual (1999) gives the full notation on on page 372. However, it is much easier and better to use EA's features than to blindly follow the specification.
I hope this works for you as well as it has worked for me.
jaimeglz
