Week 7 of 2009

Since nobody made any suggestions for the next build, I've gone with the first choice I gave last week, i.e. finish implementing model population as a precursor to full simulation support.

I started with referential and polymorphic attribute instances. In a deployed system, referential values (and polymorphic values mapped to referential values) would be accessed rarely if at all. Furthermore, all referential and polymorphic values must ultimately map to existing base values or be undefined. Thus, both can be calculated on demand (unless watchpoint mappings involving those attributes exist) apart from the fact that their values are accessed repeatedly when object instance tables are viewed in OOA Tool. As a consequence, referential and polymorphic values are cached in OOA Tool but this caching would not normally be required in a deployed system. These cached values need to be cleared whenever dependent base values or navigated relationship instances are changed. There is a balance to be made here between the amount of effort required to determine if a cached value should be cleared and the amount of effort required to calculate the cached value. If watchpoint mappings are listening to referential or polymorphic attribute changes (not recommended) then we will need to spend a considerable amount of time deciding whether to clear and recalculate those values. Watchpoint mappings (see Recursive Design subsystem) are not implemented in OOA Tool yet.

I then started looking at mathematically dependent attributes (called derived attributes in Executable UML). This is going to be the main feature in Build 014 since it will allow Action Language code to be executed for the first time in OOA Tool. After looking over all the mathematically dependent attributes defined in the OOA of OOA, I quickly realized that a simple one-in one-out function was not sufficient to calculate all of those attributes. Some attributes could be calculated on demand since the calculation would always be quick. However, other calculations may be very expensive. So expensive that ways need to be found to limit the number of times those values are recalculated. A Maximum Recalculation Interval is useful here for human-only information such as statistics and pretty labelling. There is no point recalculating such values more often than a human can process them. Delayed recalculation is an interesting topic which warrants further discussion. There are also situations where all object instances should have one or more mathematically dependent attribute values calculated at once, e.g. subsystem number ranges. Thus, a value calculation may map to one or more mathematically dependent attributes and may apply to one or all object instances. Next week I will add support for value calculations and implement mathematically dependent attribute instances (before implementing statement block execution logic).

Since I spent the week thinking about attributes and attribute instance implementation, I also deciding to have a think about attribute classification. I wanted to be sure I hadn't made any mistakes here. I did in fact decide to move the Naming attribute which was defined on Simple Attribute to Base Attribute after doing this analysis. I captured some of this analysis in the previous blog. The IE numbered bullet bug caused me some grief here and I ended up bypassing numbered bullets in that blog, yuk!