Weaving Semantic Aspects in HiLA

New paper: Weavign Semantic Aspects in HiLA, published in Proc. 11th Int. Conf. Aspect-Oriented Software Development (AOSD’12)

Abstract:

UML state machines are widely used for modeling software behavior. Due to the low-level character of the language, UML state machines are often poorly modularized and hard to use. High-Level Aspects (HiLA) is an aspect-oriented extension of UML state machines which provides high-level language constructs for behavior modeling. HiLA considerably improves the modularity of UML state machines by extending them by semantic aspects. This paper presents the weaving process for HiLA that we have shown to be sound with respect to the transition-system semantics of HiLA. In particular, we show how our weaving process deals with implicit state activation (and deactivation), maps semantic pointcuts to syntactic elements, and resolves potential conflicts between different aspects. The process has been implemented in an extension of the Hugo/RT UML translator and model checker, the correctness of our weaving is validated by model checking.

Aspect-Oriented UI Modeling

New paper: Aspect-Oriented UI Modeling with State Machines, presented on the 5th Int. Wsh. Model-Driven Development of Advanced User Interfaces (MDDAUI’10).

Abstract:

Separated modeling of User Interface (UI) widgets is a very natural way to tackle the complexity of UI models.  Due to interactions between widgets,  however, this is not always an easy task.  We propose an aspect-oriented approach to widget-oriented UI modeling: each widget’s behavior is modeled separately in a UML state machine; synchronization of the state machines is modeled in aspects and is woven into the widget models automatically.  The weaving process is transparent to the modeler.  This way, we can strongly increase the degree of separation of concerns in UI modeling and reduce the
complexity of UI models.

HiLA Web Site Launched

The home page of HiLA (High-level Aspects) is launched.

Final States: Actions

Since a FinalState is also a State, you might expect that it can also have an entry action, an exit action, and a do activity. However, the UML Specification [1, p527] forbits these actions. Why? They can very well be useful. For instance, in order to count how often a final state has been active in the execution history, a very natural way would be to define an extry action which increases the value of a counter. Now that no entry action is allowed in final states, you have to increase this counter on every transition leading to the final state, which makes modeling of this feature unnecessarily cumbersome.

[1] OMG. The Unified Modeling Language Superstructure. formal/2009-02-02

Final States: Deferrable Triggers

According to the UML Specification [1, p527], a FinalState is a subclass of State. Since every state may declare triggers as deferrable, so may each final state. But what can the deferrable triggers mean? Since a final state must not have any outgoing transition, it does not make sense to defer any trigger.

I guess a constraint that final states must not declare deferrable triggers was “forgotten” when the UML Specification was written.

[1] OMG. The Unified Modeling Language Superstructure. formal/2009-02-02

Transition Container

According to the UML Specification [1, p527] each transition in a UML state machine must have a region as its container.

As far as I can see, there is no need for this relation, since in order to navigate to transitions of a region it is also possible by first navigating to all vertices in that region and then to their incoming/outgoing transitions.

Moreover, I find this relation even ambiguous. Suppose the source and the target of a transition are located in different regions, which region is supposed to be the container of the target?

I do not see any reason for this relation to exist. Anybody knows the intention of defining it in the UML?

[1] OMG. The Unified Modeling Language Superstructure. formal/2009-02-02.