Education is an admirable thing, but it is well to remember from time to time that nothing that is worth
knowing can be taught. (Oscar Wilde)

Some irrelevant musings about Delphi programming and my life.


Subscribe in a reader

February 10, 2007

Adding a custom Ocl Operation to ECO

Some Background Info
To get myself acquainted with ECO and ASP.NET, I started with a simple (but long time overdue) pet project: a web based bug reporting utility. Noting fancy, mind, just a way for my users to report bugs or feature requests, and a way for myself to mark submitted reports as "opened", "closed" or, as is often the case, "needs more info". I'll be blogging about my first experiences with ECO at a later date.

In the model for my bug reporting tool, I have a "Session" class, a transient singleton with an association "CurrentUser" to a "User" class. That makes it possible to refer to the current user with the Ocl expression: "Session.AllInstances->first.CurrentUser".

Soon I realised that I was using this Ocl expression almost everywhere. Especially in the state diagram for reports, where I wanted to express transition guards like "a submitted report can only be deleted by the submitter" (Session.AllInstances->first.CurrentUser = User), or "only an administrator can mark a submitted project as open" (Session.AllInstances->first.CurrentUser.IsAdministrator). This certainly had the duplicate code smell all over it.

Asking about this in the ECO newsgroup, Oleg Zhukov suggested to define a custom Ocl operation (Thanks Oleg!).


Defining the custom operation
Defining a custom Ocl operation is not as complicated as it might seem (although it can take some time finding the relevant documentation on the net). It involves overriding two methods from the base class "OclOperationBase", and installing the derived operation into the oclservice. Let's start with the interface:

uses
  Borland.Eco.Ocl.Support;

type
  OclCurrentUser = class(OclOperationBase)
  strict protected
    procedure Init; override;
  public
    procedure Evaluate(Parameters: IOclOperationParameters); override;
  end;

Not much to see there, so on to the implementation. In the overridden Init method, we can define the number of parameters our custom Ocl operation will take and set their types. An Ocl operation always needs at least one parameter. This parameter represents the context of the Ocl operation. In this case we want to be able to use the "CurrentUser" operation with any type of context.

To complete the initialisation we call the InternalInit method, providing a name, the input parameter array, and the return type for our custom Ocl operation. In most of the examples that are floating round the net the return type is a predefined type like Support.StringType or Support.IntegerType. In our case however, we need to return a user object ("user" being a class in the model). We get the Ocl type for our user class by using the GetClassifierByType() and GetOclTypeFor() functions.

uses
  Borland.Eco.UmlRt;

procedure OclCurrentUser.Init;
var
  OCLParameters: array of IOclType;
  Classifier: IClassifier;
  OclType: IOclType;
begin
  SetLength(OclParameters, 1);
  OclParameters[0] := Support.AnyType;
  Classifier := Support.Model.GetClassifierByType(Typeof(User));
  OclType := Support.GetOclTypeFor(Classifier);
  InternalInit('currentuser', OclParameters, OclType);
end;

That's the initialisation done. Now let's get on with the evaluation. We already know the Ocl expression to return the current user, so we can just call the Ocl service to evaluate this expression.

The last task is setting the result parameter. We have two options: SetOwnedElement() and SetReferenceElement(). It's my feeling that SetOwnedElement() should be used for returning objects created by the operation itself, so that in our case SetReferenceElement() is the way to go. However, both options seem to work without problems (and documentation is lacking), so perhaps someone can shed some light on this?

uses
  Borland.Eco.ObjectRepresentation,
  Borland.Eco.Services;

procedure OclCurrentUser.Evaluate(Parameters: IOclOperationParameters);
var
  OclExpression: string;
  OclService: IOclService;
  Element: IElement;
begin
  OclExpression := 'Session.AllInstances->first.currentuser';
  OclService := Support.OclService;
  Element := OclService.Evaluate(OclExpression);
  Parameters.Result.SetReferenceElement(Element);
end;


Installing the custom operation in run- and designtime
All the above takes care of defining our custom operation. Installing it into the OclService is a breeze. Just add one line of code to the constructor of the EcoSpace:

constructor TBugReportsEcoSpace.Create;
begin
  inherited Create;
  InitializeComponent;
  // TODO: Add any constructor code here
  OclService.InstallOperation(OclCurrentUser.Create);
end;

Are we all done now? Well, almost. Although the custom operation is now known in runtime, and functions as expected, the operation is not yet known in design time. This has as a side effect that when we try to validate a model using the custom operation, we'll get an error: "undefined operation: CurrentUser". Luckily that's easily solved. By adding an attribute to our EcoSpace we can make the Ocl operation known at design time:

[EcoOclOperation(typeof(OclCurrentUser), true)]
TBugReportsEcoSpace = class(Borland.Eco.Handles.DefaultEcoSpace)
private
...

Side note: in this article about the same subject, Jesper Hogstrom remarks "Due to a very small. Minor... Miniscule... let's call it oversight, the attribute cannot be applied twice", and provides an alternative solution if you want to add more than one design time Ocl operation. It seems however that in the meantime this oversight has been fixed.


Calling the custom operation
When calling the custom operation, there are two "gotchas" to be beware of. The first is not forgetting the parentheses (i.e. calls must be in the form "CurrentUser()"), and the second is that an Ocl operation always needs a context. Although (for this operation) it doesn't matter what the context is, a context must be provided. When using the custom operation in a state diagram, the context is understood to be the class we're designing the state diagram for, so we can use "CurrentUser()" on its own. When evaluating the custom operation in code, we have to provide the context ourselves.

// context can be anything, but must be provided
Element := OclService.Evaluate('42.CurrentUser()');
Currentuser := User(Element.AsObject);

3 comments:

Peter Morris said...

Very clearly written, thanks!

Sinuhe said...

Very well written. I have an another problem (as an ECO newbie), hopefully you can help: in good old Delphi days, if I bind a dataset to a DBGrid, the Dataset will take care of formatting my column values through persistent TDataField members (or GetValue/SetValue). However ECO IV expression handle does not offer any properties like that, so I don't known how I can nicely format my data output? Create a derivative attribute then using OclExpression maybe a solution, but it is not perfect because by inputting, I must validate and re-parsing too much myself. Do you have any idea how I can?
Many thanks

Robert Cram said...

I am not sure I clearly understand your problem. I think your are right in assuming that creating a derived (settable) attribute would be the way to go, but I fail to see how this would mean more parsing and validating. If you want you can mail me with more specifics, and I will try to help you (use the mail address in my profile).

Another option is to visit the forums at http://www.capableobjects.com. Most people there know a lot more about ECO than I do.

Interesting Links