After the
GotoPoint,Ais incremented and we move to the bottom rowof the diagram, heading
left. The number of modes, ?¬?ve, and their names are built into the system, so the
system can say the name of the ?¬?rst mode and ???press 1.??? In the If object we check that
A has not yet reached the value of the last mode, ?¬?ve, and if so we jump to repeat for
the next mode from the GotoPoint. After the ?¬?fth mode has been read and the test in
If fails, we exit via Stop back to the VoiceMenu diagram, where we wait for the user
to press a key corresponding to a mode.
7.4.2 Use Scenarios
As we mentioned above, the two modeling languages aimed to provide a natural way
to describe and specify the desired behavior of the voice menu, and of the voice
elements and system calls that made up each segment of speech. The VoiceMenu
language was speci?¬?c to the domain of voice menus, which was a common basis
shared by Domatic??™s developers, clients, and clients??™ end-users. It could thus easily be
used as a medium of conversation between all these stakeholders, and allowed
speci?¬?cation of systems at a high level of abstraction.
A likely use scenario would have been for a Domatic employee to work with a
client to design the voice menu, directly using the VoiceMenu modeling language in
the DSM tool. If example texts were speci?¬?ed in the top-level elements, a slight
modi?¬?cation of the generator would allow working prototypes to be built and tested
immediately.
Pages:
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292