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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

370 SHE Framework<br />

11.5.3 Implementation Structure Modelling<br />

The starting point for extended implementation structure modelling is in general the<br />

set <strong>of</strong> Architecture Structure Diagrams. These diagrams are refined and annotated with<br />

textual information that shows implementation decisions explicitly. The implementation<br />

technology for functional modules is annotated in the module symbols and the selected<br />

communication technology such as protocols are denoted on channels.<br />

The diagrams are not necessarily extended with new channels or modules. This is<br />

because the purpose <strong>of</strong> Implementation Structure Diagrams is to specify the structure on<br />

system level. After all, detailed implementation structures can be modelled in Extended<br />

Instance Structure Diagrams.<br />

Design decisions are motivated in an Implementation Decisions Statement that is integrated<br />

in a Requirements Catalogue.<br />

11.5.4 Extension <strong>of</strong> Message Flow Diagrams<br />

The Message Flow Diagrams <strong>of</strong> a system are extended, based on the implementation<br />

design decisions specified in Extended Implementation Structure Diagrams. Diagrams<br />

are refined by inserting objects or by changing objects. This requires a multidisciplinary<br />

point <strong>of</strong> view again. Aspects such as testability, maintenance and manufacturing can<br />

lead to functions that could not be specified before the implementation decisions were<br />

taken.<br />

All existing essential scenarios are evaluated for the consequences <strong>of</strong> the various implementation<br />

decisions. This can lead to a variety <strong>of</strong> new communications and corresponding<br />

functions. Examples are:<br />

imperfections <strong>of</strong> technology and the required reliability can lead to drastic changes<br />

<strong>of</strong> the architecture <strong>of</strong> a system, such as a duplication <strong>of</strong> sub- modules;<br />

addition <strong>of</strong> system interface modules that implement interface technology between<br />

terminators and system;<br />

detailed communication in user interfaces;<br />

self test functions;<br />

automatic call for maintenance functions;<br />

functionality <strong>of</strong> communication protocols;<br />

buffers, queues.<br />

The extension <strong>of</strong> the models with new objects is illustrated in Figures 11.19 and 11.20.<br />

Figure 11.19 shows a communication channel <strong>of</strong> an essential model. No decisions<br />

have been taken about how this communication can be performed. When the essential<br />

model is transformed to an extended model it may appear that the channel must be

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

Saved successfully!

Ooh no, something went wrong!