Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| research:sm:mdsocre [2009/05/20 18:58] – azambrano | research:sm:mdsocre [2009/05/20 19:04] (current) – azambrano | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | Concern requirements list using MDSOCRE notation. Here we show how the concrete concerns of our domain are expressed with the MDSOCRE approach. | ||
| + | <code xml> | ||
| + | <Concern name=" | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | It could be a ticket printer, a coin hopper.</ | ||
| + | </ | ||
| + | |||
| + | <Concern name=" | ||
| + | < | ||
| + | | ||
| + | < | ||
| + | the end of a game) shall be added to the player' | ||
| + | | ||
| + | | ||
| + | < | ||
| + | | ||
| + | the number of games played; since power reset, since door close and | ||
| + | since game initialisation. </ | ||
| + | < | ||
| + | that must be counted, including: play, cashout, bill in, coin in. </ | ||
| + | </ | ||
| + | |||
| + | |||
| + | <Concern name=" | ||
| + | < | ||
| + | | ||
| + | or another secure method that is not available to the player. </ | ||
| + | < | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | </ | ||
| + | |||
| + | <Concern name=" | ||
| + | < | ||
| + | information between a SM, and one or more host systems. </ | ||
| + | < | ||
| + | | ||
| + | (G2S 1.16) </ | ||
| + | < | ||
| + | games since initialisation. WonCnt: Number of primary games won | ||
| + | by the player. LostCnt: Number of primary games lost by the player </ | ||
| + | < | ||
| + | error conditions, tickets inserted, ticket printed.</ | ||
| + | </ | ||
| + | |||
| + | <Concern name=" | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | error conditions, tickets inserted, ticket printed.</ | ||
| + | </ | ||
| + | |||
| + | <Concern name=" | ||
| + | < | ||
| + | | ||
| + | to the interruption occurring. | ||
| + | < | ||
| + | while in an error condition, then upon restoring power, the specific error | ||
| + | | ||
| + | | ||
| + | < | ||
| + | | ||
| + | </ | ||
| + | |||
| + | <Concern name=" | ||
| + | < | ||
| + | displaying error conditions and illuminate the tower light for each | ||
| + | or sound an audible alarm. </ | ||
| + | < | ||
| + | lock up and require attendant intervention. Error conditions shall be | ||
| + | | ||
| + | | ||
| + | a critical error.</ | ||
| + | < | ||
| + | full, bill jam, external doors open. </ | ||
| + | < | ||
| + | the error conditions. </ | ||
| + | < | ||
| + | | ||
| + | </ | ||
| + | |||
| + | <Concern name=" Demo Mode"> | ||
| + | < | ||
| + | mode, which permits | ||
| + | | ||
| + | < | ||
| + | mode, any test that incorporates credits entering or leaving the | ||
| + | | ||
| + | | ||
| + | < | ||
| + | | ||
| + | the electronic meters.</ | ||
| + | < | ||
| + | were accrued during the test, diagnostic or demo mode shall be | ||
| + | | ||
| + | < | ||
| + | modes provided the meters indicate as such (GLI 11 4.17.1). </ | ||
| + | </ | ||
| + | < | ||
| + | | ||
| + | mode. Test/ | ||
| + | | ||
| + | modes should not be accessible to the player (GLI 11 4.17.2). </ | ||
| + | < | ||
| + | shall return to the original state it was in when the test mode was | ||
| + | | ||
| + | < | ||
| + | the machine shall clearly indicate that it is in a test mode, not normal | ||
| + | play (GLI 11 4.17.4). </ | ||
| + | </ | ||
| + | |||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ==== Composition rules ==== | ||
| + | |||
| + | Composition rules are used to express crosscutting relationships. Here we show the | ||
| + | composition rules, consisting of a Constraint tag that defines how the | ||
| + | base requirements are constrained by aspectual requirements. The Constraint | ||
| + | tag has actions, operators and outcome elements, used to express in detail | ||
| + | how the base is affected. | ||
| + | |||
| + | 1. Demo to Game: The demo requirements affect many of the definitions of the original requirements of Game, in order to alter the Game's behaviour for testing purposes. | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | 2. Game Recall to Game: Game Recall requirements affect many aspects of the Game's behaviour, its requirements call for recording pieces of information regarding game play. | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | 3.Meters to Game: Meters count activities of many functions defined in Game's requirements, | ||
| + | |||
| + | and | ||
| + | |||
| + | 10.Dependency of G2S on Meters: Some data reported to the RS is stored or can be derived from meters. G2S needs the meters to be up to date in order to accomplish its purpose. | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | |||
| + | 4.Program resumption to Game. Program resumption is analogous to persistence. It crosscuts all the places where important data, which needs to be restored, | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | 5.G2S to Game: this concern cut across many Game's requirements, | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | 6.Error Conditions to Game: Requirements in Game that could raise an error condition vary: from a bill inserted to a door opened. | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | 7.Proprietary Protocol to Game: This refers to another protocol used for the same purpose as G2S, that is to monitor the game's behaviour. | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | |||
| + | 11.Mutex between G2S and Proprietary Protocol: There is overlapping functionality defined in the requirements of both protocols and they cannot be active at the same time. | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | 12.Reinforcement of G2S with Error Conditions: Some parts of the G2S protocol are not mandatory for specific instances. When error conditions are tracked in the game, additional behaviour is made available in G2S, such as real time event reporting. | ||
| + | |||
| + | <code xml> | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | <Outcome action=" | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||