P. Gibson and D. Mery. Always and eventually in object models. In ROOM2, June 1998.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....veri cation is not available. Thus we are required to validate the invariant at run time. The Decorator pattern facilitates immediate implementation. A Java implementation of the Decorator pattern, instantiated It is beyond the scope of this work to examine this process in detail: see reference [18]. 5 1 CLASS Junction USING TrafficLight 2 STRUCTURES A Junction(TrafficLight, TrafficLight) 3 INITIALIZE A Junction(A TrafficLight(Red) 4 A TrafficLight(Red) 5 INVARIANT A Junction(tl1,tl2) REQUIRES 6 tl1=Red or tl2 =Red 7 TRANSFORMERS Switch( 9 A Junction(tl1, tl2) Switch( 10 A ....

P. Gibson and D. Mery. Always and eventually in object models. In ROOM2, June 1998.

....requirements model. In practice it is more feasible to expect the customer and analyst to work together during the construction and refinement of requirements (as well as at the testing stages) 3. 3 Always and Eventually Although we have listed a large number of different types of requirements, [26] shows that the notions of always and eventually are central to telephone users models of their needs. Always properties are simply stated as invariants to be proved and eventually requirements are integrated into our models as fairness assumptions on objects which serve concurrent requests. 3.4 ....

Paul Gibson and Dominique Mry. Always and eventually in object models. In ROOM2, Bradford, June 1998.

....hides the how of the system to be developed. They have operational requirements which are usually expressed as sequences of actions (or events) which they would (or would not) like to be possible when they use the system. They also have logical requirements based on always and eventually concepts [22] they require some things to be true always and these must be expressed as safety properties; and they require that some things must eventually happen and these must be expressed as liveness properties. The designer must be able to understand the abstract needs of the client and transform these ....

....of liveness and fairness properties. No one model can treat each of these aspects, yet each of these aspects of the conceptualisation are necessary in the synthesis and analysis of formal requirements models. We are in the process of integrating the di erent semantics into one coherent model [14, 18, 20, 22]. 2.4 Why object oriented We advocate an object oriented approach to structuring our requirements models. Object oriented methods encompass a set of techniques which have been, and will continue to be, applied in the successful production of complex software systems [7, 8, 4, 28] The methods ....

Paul Gibson and Dominique Mry. Always and eventually in object models. In ROOM2, Bradford, June 1998.

....automatic detection of many interactions [17] ffl A fairness view which allows the client to describe properties of the system which must eventually be true even though they have no direct control over them. A temporal logic provides an ideal means of specifying and verifying such requirements[11]. A composition mechanism defines a creation mechanism which is reusable (i.e. can be applied to different sets of components) Clearly, we have to be more precise as to the meaning of a component. From the customer s point of view, and hence at the requirements level of abstraction, a component ....

Paul Gibson and Dominique M'ery. Always and eventually in object models. In ROOM2, Bradford, June 1998.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC