23.08.2013 Views

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

304 Behaviour-Preserving Transformations<br />

10.1 Introduction<br />

Behaviour-preserving transformations form an important part <strong>of</strong> the SHE method. In<br />

this chapter we will develop a formal transformation system consisting <strong>of</strong> 15 behaviourpreserving<br />

transformations. This chapter is to a great extent based on [Voe, VvdPS96].<br />

10.1.1 Motivation<br />

During analysis and design, the Essential Behaviour Model is gradually transformed<br />

to incorporate high-level level structural decisions and constraints specified in the Architecture<br />

Structure Model. Similarly, the Extended Behaviour Model is transformed in<br />

accordance with the Implementation Structure Model. Of all possible transformations<br />

an important class can be distinguished. This class consists <strong>of</strong> transformations that<br />

introduce, modify or delete boundaries and channels in Instance Structure Diagrams<br />

(and in the underlying POOSL description). The transformations <strong>of</strong> this class are required<br />

to leave the (abstract) dynamic behaviour and functional behaviour invariant.<br />

The transformations can modify a system with respect to architecture and topology, but<br />

they should leave the overall functionality unchanged.<br />

One way to make sure that a performed transformation indeed preserves behaviour,<br />

is to verify that the system specifications before and after the transformation are in<br />

some way behaviour equivalent. However, due to the size <strong>of</strong> real-life specifications,<br />

such an a posteriori verification approach is <strong>of</strong>ten practically not feasible. Especially if<br />

transformations have a non-local impact, verification becomes cumbersome because <strong>of</strong><br />

state explosion problems.<br />

An alternative approach to verify transformations is to <strong>of</strong>fer a collection <strong>of</strong> simple transformations<br />

which are known to be behaviour-preserving in advance. This leads to the<br />

notion <strong>of</strong> behaviour-preserving transformation. By putting a number <strong>of</strong> these simple transformations<br />

in sequence, complex behaviour-preserving transformations can be obtained.<br />

If these transformations are applied to some initial system specification, specifications<br />

are obtained that are correct by construction (in the sense that they are equivalent to the<br />

initial specification).<br />

10.1.2 Related Work<br />

For about two decades behaviour-preserving (also called correctness-preserving or<br />

semantics-preserving) transformations, have been subject <strong>of</strong> active research in different<br />

fields <strong>of</strong> application. For example, [Cam89] and [Mid93] describe how behaviourpreserving<br />

transformations can be applied in high-level synthesis (synthesis <strong>of</strong> circuit<br />

structures from behavioural domain descriptions). The LotoSphere design methodology<br />

[Pir92, Pav92] uses correctness-preserving transformations to support system designers<br />

and implementers along the trajectory from initial, abstract specification, down to concrete<br />

design and implementation. A catalogue <strong>of</strong> LOTOS transformations is given in<br />

[Bol92]. Transformational programming [Fea87, Par90] is another related research field.<br />

Transformational programming consists <strong>of</strong> a collection <strong>of</strong> transformation approaches

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!