Printable versions of Call for Papers WORD
(Univ. of Kent at Canterbury)
Popular approaches to specification are based on either states or actions (events). Abadi and Lamport ('93) observe that, while these approaches are, in some sense, equivalent ('an action can be modeled as a state change, and a state can be modeled as an equivalence class of sequences of actions'),
they have taken, in the past, 'very different formal directions', and they 'tend to differ also in practice'.
Some people believe that the first step in system development should be the identification of the right global state structure. Other people start characterizing the system by describing its interactions with the environment, that is, by identifying event patterns (e.g. use cases), without worrying about the state.
- What is the shape of your mental landscape, when you start conceiving a complex
(concurrent, reactive, distributed) system? Is it a structure of state variables (relations, functions), or a pattern of events in time?
- Is the choice between a state-oriented and an event-oriented approach dependent on the type of system to be described? How?
- How does a system description in natural language affect the choice between state-oriented and event-oriented formalisation? How does the requirements analysis process affect the choice?
- The two approaches don't have to be mutually exlusive. Is it easy/desirable to move from one to the other? At which stage of development would one do that?
- Can one integrate the two approaches, keeping their individual advantages? If so, can one formally refine a purely state-oriented or purely event-oriented description into a hybrid one?
Formal specification approaches, such as ASM, B, CSP, Predicate/Transition Nets, TLA, Z, often imply a strong bias towards one or the other extreme of the 'ST.EVE' spectrum. On the other hand, software engineers often choose a language without explicitly locating it along the spectrum, the choice being driven by a mix of technical and opportunistic (if not 'religious') reasons.
If you are interested into an open-minded discussion on these questions, please consider sharing your opinions and experiences with us at the Workshop, and send us a contribution.
Contributions (abstract, extended abstract, or full paper) should be submitted in PostScript or PDF format, and sent by e-mail to email@example.com J.Derrick@ukc.ac.uk, by the date below.
Abstract, extended abstract, or full paper June 30
Communication of acceptance July 31
Submissions will be reviewed for relevance to the workshop, and informal proceedings will be distributed to the participants. Extended versions of high quality papers will be considered for inclusion in a Special Section of the Software and Systems Modeling Journal (Springer-http://www.sosym.org/)