Here's a small model to show how to use the PSEval value. This could also be interesting if you're working with associations. I've created this web Article, the SysUser – which would be the logged-in user, probably. This is an article where users can comment. I've added the link row name i.e. if you navigate from the SysUser to the comments. If you go from the comment to the article, that's the inner link name. That's always a good way to set up if you have a link class like this – for associations. How is this stored? It is stored in the database as one table for the article, one table for the SysUsers, and one table for the comments. This is like two multi-links with one in one end and many here. What's going on here is that you have one comment in the table, one pointer to the SysUser, and one pointer or link or ID to the article. You need to know outside this model. The expression for that is: SysSingleton.oclSingleton.CurrentUser. The reason this is done here is so that the SysUser won't have tens of thousands of comments. In this case, we're assuming that we're not going to have huge amounts of comments for performance reasons. We select from the comments an article that, in this case, points to the self - because this navigation starts from the article, the self here is article. We are looking at the Current User's comments for this article. We take the first comment because this is a collection, but we know for a fact that this will be the only one. Looking at how we can increase the performance or the performance problems that we could have here, we must decide whether we're going to show a list of articles or one article. Let's say there are a thousand comments for each article. There would be a problem because if we are showing, for example, a hundred articles with a thousand comments, that means there are a hundred thousand comments. We need to load it into memory and sum it up. If we were to use the article view which shows the content, we would want to show how many likes this article has gotten and the list of comments which could also be a list of articles. We still want to show the like count and we have three different implementations of how to show the like count. One way would be to say article.comments and select for the likes and then show the number. That would require the system to load every comment object into memory and then filter out the ones that have like, that is not null and see how many they are. We decide to be smart here and use the PSEval value. We want an integer. We use the PSVAL value and we say self.comments - this is basically the same as it would be in the OCL. The OCL would load all the objects. PS (persistent storage) says we can just do this in SQL and not load the objects. We take the comments, select the ones that are liked and take the size of it. In this case, we are also subscribe to the article which means that this would be re-evaluated if the article changes. Anyway, this will work well to show how many likes you have. If this user likes or unlikes it, this value would not change. You would have a non-responsive UI because if the user then uses this action to toggle like, it would change from like to turn on and off the like to date here - it wouldn't update the user interface that we can see here, but stay the same. It is not re-evaluated because there is nothing triggering the re-evaluation. If we were to add all the comments as a way to say when to recalculate that would defeat the purpose because then we still load all the objects to look at them. What can we do? We could, for example, say that we will use PSVAL to get all the comments for this article into memory, but only the ones that have like on them. It would still load objects, but not all of them, only the liked ones up to 9,999 in this case, and then we would take the size of that. By loading the objects, we can take this size here after we have loaded the objects. In this case, it would be better. Another alternative would be to combine OCLPS and PSEval with OCL. We first pick out the comment the user has made. Then we find all the comments and all the objects that have liked on it, except my comment object. We sum these up. In this case, we're getting the objects and we're taking the size of the object. We load all the objects except my own objects, and we add my own comment - liked status - manually. This part will be executed in OCLPS () and this part will be in OCL (). The next variant would be to have this as an integer. Now, this should be the PSEval value. We have the integer and calculate the value of every comment except mine. In OCL, which is auto-subscribed, we calculate the liked form for only my comment. The effect of this will be that the UI will update when I like or unlike it, but if someone else does it, it won't update until my session reloads. It will feel like it's responding right away to my like setting, but to other like settings, it will delay because it will only reload when this value is needed the next time. It's slightly off, but I don't think anyone will notice and it's a huge performance boost.