Arcade Game Maker Pedagogical Product Line: Architecture Documentation, Volume 2 - Software Architecture Views
| Revision Control Table | ||||
| Version Number | Date Revised | D-Delete, M-Modify |
Description of Change | Person Responsible |
| 1.0 | 7/03 | A | Created document | JDMcGregor |
| 2.0 | 6/04 | M | Responded to review comments | JDMcGregor |
| 3.0 | 4/05 | M | Edited document | KERiley |
Introduction
The Arcade Game Maker (AGM) product line is a set of relatively simple systems. This version of the software architecture is simple as well, but it may become more complex as change cases in the requirements model are planned and implemented.
The architecture attains the qualities prescribed for it in Arcade Game Maker Pedagogical Product Line: Requirements Model: that is, the games are fast and realistic.
This second architecture volume provides detailed models of the games' architectural models. For background information that supports these models, see Arcade Game Maker Pedagogical Product Line: Architecture Documentation, Volume 1 - Beyond Views.
Allocation Deployment View
Allocation Deployment View Packet 1: Game
As shown in the following figure, we intend to deploy all products in the AGM product line on a single processor. Each game in the product line will have the same relationships with the available driver packages that make up the external environment. Therefore, this document focuses only on Game's software architecture.
Process Allocation for AGM Games
Game responds to mouse and keyboard events and controls the display through calls provided in the language library.
Element Catalog
Elements and their properties. The following table displays element details.
| Elements and Responsibilities for Allocation Deployment View Packet 1: Game | |
| Element | Responsibilities |
| Game | This is the generic representation for an AGM game. Each game will have a specialization of this class as its top level. |
| Operating System | The usual operating system interface provides drivers for the devices that are needed by the game. |
Relations and their properties. The relationship in this view is dependency. The Game has dependencies on three drivers in the operating system that are realized by calls on library methods.
Element interfaces. Game's interface is a GUI that provides the basic start/exit/pause behavior.
Element behavior. Game is the top level of each AGM game. The general behavior is an action loop that runs until the player exits the game or the game is over. Game-specific behavior is provided by the specialized Game class.
Context Diagram
This is the top level of the product. There is no context other than an executable running on the supported platform.
Variation Guide
Game is the generic product. For details, see the Module Generalization View Packet 1: Game section.
Architecture Background
Game provides the basic behavior for any arcade game. The specializations add details to provide the specifics of a game.
Other Information
No other information applies.
Related View Packets
- Game internals are provided in the Module Decomposition View Packet 1: Game section.
- Specializations of the generalization are provided in the Module Generalization View Packet 1: Game section.
Module Decomposition View
In this section, we describe the basic structure of an AGM game. Game variations are addressed by substitution, parameterization, and specialization. Game-specific behaviors are provided by game-specific implementations of the interfaces in this document.
Module Decomposition View Packet 1: Game
The previous figure shows the Game component as the representation for the generic product. The following figure shows that component's interface as the top-level interface of the system (defined in the GameBoard Interface section) and the other major interfaces that are at the first level of decomposition within the GameInterface (defined later in this document).
Module View Decomposition of Game Component
Element Catalog
Elements and their properties. The following
table displays element details.
| Elements and Responsibilities for Model Decomposition View Packet 1: Game | |
| Element | Responsibilities |
| GameBoard interface | This container component holds all the elements needed for the game. |
| ScoreBoard interface | This interface keeps and presents the score as the game specifies. It is defined in the ScoreBoard Interface section. |
| SpeedControl interface | This interface controls how often a tick is issued to the GameBoard. It is defined in the SpeedControl Interface section. |
Relations and their properties. The primary relation is composition. Game is responsible for creating, managing, and killing the elements it composes.
Element interfaces. Game interface is the program's GUI. It provides the user with Game start, stop, pause, and save behaviors. The other interfaces are documented as follows:
Element behavior. The behavior is the game that is displayed to the user.
Context Diagram
Game is the top level of the product and the
top-level context.
Variation Guide
Game and ScoreBoard will each be replaced by a
game-specific implementation as described in the
Module Generalization View section.
Architecture Background
Game encapsulates game-specific behavior. It
arranges the GameBoard, keeps score, and determines the won/lost status based
on its rules. The composed elements are mostly generic and can be reused and
rearranged to implement other games.
Other Information
No other information applies.
Related View Packets
Module Decomposition View Packet 2: GameBoard
This view shows the class dependencies for the GameBoard class. The following figure shows the related classes.
GameBoard Module Decomposition
Element Catalog
Elements and their properties. The following
table displays element details.
| Elements and Responsibilities for Module Decomposition View Packet 2: GameBoard | |
| Element | Responsibilities |
| EventHandlerInterface | This interface defines a standard interface through which events are passed from the interaction devices. |
| StationarySprite | This is an abstract class for many items that will be placed on the GameBoard and hit by moving objects. Item behavior varies from reflecting to absorbing moving objects. |
| MovableSprite | This is an abstract class for many items that will be placed on the GameBoard and moved according to some algorithm. Item behavior varies from perfect reflective bouncing to random movement. |
Relations and their properties. The primary relation is composition. GameBoard composes the elements that make the game behavior.
Element interfaces.
Element behavior. No behavior applies.
Context Diagram
GameBoard is shown in context in the
Module View Decomposition of Game Component
figure.
Variation Guide
GameBoard is a container. Game adds the desired
MovableSprites and StationarySprites to the GameBoard. The GameBoard can take
an arbitrary number of Sprites chosen from the classes shown in the
MovableSprite Specialization View and
StationarySprite Classes figures.
Architecture Background
GameBoard is designed as a component
container. It delivers events to the components it holds. For example, it
delivers timer ticks to its MovableSprite objects so that they can move.
Other Information
No other information applies.
Related View Packets
Sprites are defined in the Module Generalization View Packet 2: Sprite section.
Module Generalization View
Module Generalization View Packet 1: Game
This view shows the specialization of Game by three classes – shown in the following figure.
Primary Presentation
Game Generalization
Element Catalog
Elements and their properties. The following
table displays element details.
| Elements and Responsibilities for Module Generalization View Packet 1: Game | |
| Element | Responsibilities |
| Game | This abstract class defines game functionality that is common to all products. |
| BricklesGame | This class adds Brickles-specific behavior. |
| PongGame | This class adds Pong-specific behavior. |
| BowlingGame | This class adds Bowling-specific behavior. |
Relations and their properties. The relation is generalization/specialization.
Element interface. All elements in this view implement the Game interface.
Element behavior. No behavior applies.
Context Diagram
Game is shown in context in the
Module View Decomposition of Game Component
figure.
Variation Guide
No variation within each element.
Architecture Background
Each Game class inherits the abstract Game
class, including the basic simulation loop that is a protected method in the
abstract class.
Other Information
No other information applies.
Related View Packets
No packets apply.
Module Generalization View Packet 2: Sprite
This view shows the classes that specialize the Sprite class (see following figure).
Primary Presentation
Sprite Basic Classes
Element Catalog
Elements and their properties.
The following table displays element details.
| Elements and Responsibilities for Module Generalization View Packet 2: Sprite | |
| Element | Responsibilities |
| Sprite | This abstract class defines the generic behavior and state for any element on the screen including position and bitmap. |
| MovableSprite | This class defines the moving behavior of screen elements and adds it to the general behavior. |
| StationarySprite | This class defines the obstacle behavior of screen elements and adds it to the general behavior. |
Relations and their properties. The relation is generalization/specialization.
Element interfaces. No interfaces apply.
Element behavior. No behavior applies.
Context Diagram
The two specializations are shown in the
GameBoard Module Decomposition figure.
Variation Guide
No variation applies.
Architecture Background
The abstract class is used for two purposes:
(1) as a common type for defining parameters; and (2) to define common behavior
that will be shared by a number of subclasses.
Other Information
No other information applies.
Related View Packets
- Module Generalization View Packet 3: MovableSprite
- Module Generalization View Packet 4: StationarySprite
Module Generalization View Packet 3: MovableSprite
This view shows the classes that specialize MovableSprite (see following figure).
MovableSprite Specialization View
Element Catalog
Elements and their properties. The following
table displays element details.
| Elements and Responsibilities for Module Generalization View Packet 3: MovableSprite | |
| Element | Responsibilities |
| MovableSprite | This class defines the moving behavior of screen elements and adds it to the general behavior. |
| Paddle | This class adds the constrained movement of a Sprite that travels horizontally only. |
| Puck | This class adds the moving behavior of a bouncing ball in a gravity field. |
| BowlingBall | This class adds the behavior of a ball being thrown with various spin values. |
Relations and their properties. The relation is generalization/specialization.
Element interfaces.
Element behavior. The principle elements that move are paddles, pucks, and bowling balls. They may be further specialized for other games.
The following figure presents the abstract algorithm for moving Sprites around the GameBoard.
Basic Move Algorithm for MovableSprites
Context Diagram
The following figure shows the context within which
MovableSprite is defined.
Context for MovableSprite View
Packet
Variation Guide
The variation is in which class to select.
Individual classes only vary by the MovableSprite's initial location on the
playing field.
Architecture Background
Specializations are added to this structure
because MovableSprites with different behaviors from those already defined are
needed to populate a game.
Other Information
No other information applies.
Related View Packets
No packets apply.
Module Generalization View Packet 4: StationarySprite
This view describes the classes that specialize StationarySprite (see the following figure).
StationarySprite Classes
Element Catalog
Elements and their properties. The following
table displays element details.
| Elements and Responsibilities for Module Generalization View Packet 4: StationarySprite | |
| Element | Responsibilities |
| StationarySprite | This class defines the obstacle behavior of screen elements and adds it to the general behavior. |
| BrickPile | This class is a container that holds Bricks. |
| Brick | This class is an obstacle that breaks when hit by a MovableSprite. |
| Wall | This class reflects MovableSprites according to Newtonian physics. |
| LeftWall | This specialization of Wall knows that it is to the left of the board. |
| RightWall | This specialization of Wall knows that it is to the right of the board. |
| Floor | This class is an obstacle that absorbs MovableSprites. |
| Ceiling | This class reflects MovableSprites. |
Relations and their properties. The relation is generalization/specialization.
Element interfaces. These elements all implement the StationarySprite interface defined in the StationarySprite Interface section.
Element behavior. The following figure shows the role of the StationarySprites in detecting collisions. After each tick, the GameBoard updates the position of each MovableSprite to its new location and then compares the BoundingBox of each MovableSprite with the BoundingBox of every StationarySprite. When an overlap occurs, a collision has been detected and a CollisionException is thrown.
Collision Detection Algorithm
the next figure shows how a collision is handled. The CollisionException is caught, and a message is sent to the StationarySprite involved in the collision. The StationarySprite follows its behavior and sends the appropriate message to the MovableSprite.
Handling a Collision
Context Diagram
The next figure shows the context within which
StationarySprite is defined.
Context for StationarySprite View
Packet
Variation Guide
The variation is in which class to select.
Individual classes only vary by the MovableSprite's initial location on the
playing field.
Architecture Background
This is the design that adds the most value.
Other Information
No other information applies.
Related View Packets
No other packets apply.
Component-and-Connector View
In this section, allocation and module views are supplemented with an operational view (see next figure) using a component-and-connector view type. This view provides a look at the computation flow through the system.
Component-and-Connector View Packet 1: Control Loop
The game-specific implementation of the Game interface provides the main control loop that drives the game. As such, it must be implemented for each specific game.
Primary Presentation
Control Loop
Element Catalog
Elements and their properties. The following table displays element details.
| Elements and Responsibilities for Component-and-Connector View Packet 1: Control Loop | |
| Element | Responsibilities |
| Player | The player of the game is responsible for initiating play. |
| Game | Game provides the user interface and the game-specific control loop and calls start on the GameBoard. |
| GameBoard | The GameBoard controls the timer and responds to its ticks until the game is stopped, paused, or completed. |
| Timer | The timer delivers ticks at specified intervals that correspond to the setting of the SpeedControl. |
Relations and their properties. The relation shown in the above figure is method invocation. Each arrow represents a synchronous or asynchronous invocation of a method on the called object.
Element interfaces.
Element behavior. No behavior applies.
Context Diagram
This is the top-level system as shown in the Process Allocation for AGM Games figure.
Variation Guide
The variation in this scenario comes when a game-specific variant of Game is substituted. This diagram does not change, but the conditions under which the won and lost messages are sent do change.
Architecture Background
Separating the timer from the GameBoard allows the speed of the game to be changed very easily. The timer controls movement on the screen and is isolated from the game to provide autonomy of the GameBoard.
Other Information
No other information applies.
Related View Packets
No other packets apply.
GameBoard Interface
Interface Identity
GameBoard
Resources Provided
Resource Syntax
Board(Point p, Size s,EventHandlerDefinitions ehd)
void
startMovement()
void stopMovement()
void setSpeed(int newValue)
int
getSpeed()
void tick()
void addMovablePiece(IComponent ic, String s)
void addMovablePiece(IComponent ic)
void removeMovablePiece(IComponent
ic)
VOID ADDSTATIONARYPIECE(ICOMPONENT IC, STRING S)
void
addStationaryPiece(IComponent ic)
VOID REMOVESTATIONARYPIECE(ICOMPONENT IC)
void resetList()
boolean isMember(Icomponent ic)
boolean isMoving()
Resource Semantics
Board(Point p, Size s,EventHandlerDefinitions ehd)
Pre: true
void startMovement()
Post: self.isMoving = true
Pre: true
void stopMovement()
post: isMoving = false
pre: true
void setSpeed(int newValue)
post: self.getSpeed() =
newValue
pre: true
int getSpeed()
post: return speed
pre: true
void tick()
post: none
pre: true
void addMovablePiece(IComponent ic, String s)
post:
self.isMember(ic) = true
pre: true
void addMovablePiece(IComponent ic)
post:
self.isMember(ic) = true
pre: self.isMember(ic)
void removeMovablePiece(IComponent ic)
post: self.isMember(ic) = false
pre: true
void addStationaryPiece(IComponent ic, String s)
post:
self.isMember(ic) = true
pre: true
void addStationaryPiece(IComponent ic)
post:
self.isMember(ic) = true
pre: self.isMember(ic)
VOID REMOVESTATIONARYPIECE(ICOMPONENT IC)
post: self.isMember(ic) = false
pre: true
void resetList()
post: forall ic.isMember(IComponent)
self.isMember(ic)=false
pre: true
Boolean isMember(Icomponent ic)
Post: return true if
ic is in Board
Pre: true
Boolean isMoving()
Post: return true if this is in
moving state
Resource Usage Restrictions
- Only one instance of GameBoard may be present in a system.
- This component has no dependencies on the physical rules or the game rules.
Locally Defined Data Types
Error Handling
Sprites may throw exceptions that are caught by the game instead of the GameBoard implementation. They are not errors. They are an integral part of the logic of the game being played.
Variation Provided
The main variation in GameBoard is the set of event handlers. They are defined in a single object that is provided as a parameter to the constructor. Definitions cover all mouse and keyboard events.
Quality Attribute Characteristics
GameBoard is the basis for the animation. It provides an implementation that results in the smooth movement of the moving Sprites. "Smooth movement" is defined as the game piece changing locations without unexpected pauses caused by the refresh rate of the graphics as opposed to the movement of the mouse or other controller.
Element Requirements
GameBoard requires the following elements from the .Net library:
- System.ComponentModel.Container
- System.ComponentModel.IComponent
The container holds the IComponents. Its list facilities manipulate the Sprites.
Rationale and Design Issues
The GameBoard interface provides a single point to which games come to place elements on the GameBoard that is shown to the player. The interface separates the creation of the GameBoard object from the configuration process.
Usage Guide
The rules of the game are distributed among the game elements (the Sprites). Because the GameBoard is a container for the action, there are few constraints on the use of the container. The state machine for the GameBoard is shown in the next figure.
Usage of the GameBoard
The state machine is purposely simple and does not preclude future games from adding Sprites while the game is in progress (not applicable in current games).
Sprite Interface
Interface Identity
Sprite
Resources Provided
Resource Syntax
Sprite(Point p,Size s)
void collideWith(Sprite m);
void
paint(PaintEventArgs e);
void setBoundingBox();
PictureBox
getPicture();
Rectangle getBoundingBox();
Rectangle
getBoundingBox(Sprite s);
bool overLaps(Sprite s);
bool
overLaps(Rectangle r);
Resource Semantics
Pre: true
Sprite(Point p,Size s)
Post: self exists
Pre: true
void collideWith(Sprite m);
post:
pre: true
void paint(PaintEventArgs e);
POST: CURRENT STATE OF
SELF IS REPRESENTED ON SCREEN
pre: true
void setBoundingBox();
post: self's bounding box is
updated
pre: true
PictureBox getPicture();
Post: return the bounding box
of image
Pre: true
Rectangle getBoundingBox();
Post: return the bounding
box of Sprite
Pre:true
Rectangle getBoundingBox(Sprite s);
Post: return
self.boundingBox
Pre: true
bool overLaps(Sprite s);
post: return true if
s.getBoundingBox().overlaps(self.getBoundingBox())
pre: true
bool overLaps(Rectangle r);
post: return true if
self.getBoundingBox().overlaps(r))
Resource Usage Restrictions
This interface specifies abstract concepts. It is not intended to be used.
Locally Defined Data Types
No types apply.
Error Handling
No error handling applies.
Variation Provided
No variation applies.
Quality Attribute Characteristics
No specific qualities apply. Sprite is too abstract.
Element Requirements
A Rectangle element must have been defined.
Rationale and Design Issues
This definition fills an important domain role. It represents the Sprite concept, which has a long history in computer-based games in our design.
Usage Guide
Sprite is used as the basis for concrete component definitions.
MovableSprite Interface
Interface Identity
MovableSprite (specialization of previous section: Sprite Interface)
Resources Provided
Resource Syntax
MovableSprite(Point p, Size s)
void paint(PaintEventArgs e)
bool
moving()
void startMoving()
void stopMoving()
void reverseX()
void reverseY()
void move()
Resource Semantics
Pre: true
MovableSprite(Point p, Size s)
Post: self exists
Pre: true
void paint(PaintEventArgs e)
post: current state of
self is represented on screen
pre: true
bool moving()
post: return true if self is moving
otherwise false
pre: true
void startMoving()
post: self.moving = true
pre: true
void stopMoving()
post: self.moving = false
pre: true
void reverseX()
post: X component of direction is
reversed
pre: true
void reverseY()
post: Y component of direction is
reversed
pre: self.moving = true
void move()
post: self has moved to new
Location
Resource Usage Restrictions
A MovableSprite can be used anywhere a Sprite or MovableSprite is specified.
Locally Defined Data Types
No types apply.
Error Handling
No error handling applies.
Variation Provided
The types of MovableSprites differ from each other in three ways:
- Each has its own icon on the screen.
- Each provides its own behavior when it is involved in a collision.
- Each provides its own algorithm that controls the path it follows as it moves.
Quality Attribute Characteristics
The division between stationary and movable Sprites is a performance enhancement effort. That is, by only having some of the game pieces recomputed a new location on each pulse of the game, there is less overhead for the animation.
Element Requirements
No additional state variables, beyond those in Sprite, are required.
Rationale and Design Issues
Stationary and movable Sprites are treated separately for efficiency. In most games, players score points when stationary and moving Sprites collide. Because collision checking occurs after each movement, this is a significant point at which to enhance performance. By dividing Sprites into two stationary and movable groups, collision checking takes less time.
Usage Guide
MovableSprites are the main actors in a game. They provide the action that keeps the player's attention. MovableSprites are added to the GameBoard at product creation time by the product builder.
StationarySprite Interface
Interface Identity
StationarySprite ( specialization of Sprite Interface's Sprite )
Resources Provided
Resource Syntax
StationarySprite(Point p, Size s)
Resource Semantics
Pre: true
StationarySprite(Point p, Size s)
POST: SELF EXISTS
Resource Usage Restrictions
A StationarySprite can be used anywhere a Sprite or StationarySprite is specified.
Locally Defined Data Types
No types apply.
Error Handling
No error handling applies.
Variation Provided
Each StationarySprite can be instantiated as absorbing or non-absorbing. When an absorbing StationarySprite collides with a MovableSprite, the MovableSprite is deleted from the game.
Quality Attribute Characteristics
The division between stationary and movable Sprites is a performance enhancement effort. That is, by only having some of the game pieces recomputed a new location on each pulse of the game, there is less overhead for the animation.
Element Requirements
No additional state variables, beyond those in Sprite, are required.
Rationale and Design Issues
Stationary and movable Sprites are treated separately for efficiency. In most games, players score points when stationary and moving Sprites collide. Because collision checking occurs after each movement, this is a significant point at which to enhance performance. By dividing Sprites into two stationary and movable groups, collision checking takes less time.
Usage Guide
StationarySprites form a game's boundaries and obstacles in a game and are added to a GameBoard as the game is constructed.
ScoreBoard Interface
Interface Identity
ScoreBoard
Resources Provided
Resource Syntax
ScoreBoard(String newFileName, String initialScore)
void
storeScore()
void getScore()
void setScore(String newScore)
void
showScores()
Resource Semantics
Pre: there exists a file with name newFileName
ScoreBoard(String
newFileName, String initialScore)
Post: self.getScore() = initialScore
Pre: true
void storeScore()
post: score has been stored
pre: true
int getScore()
post: return current score
pre: true
void setScore(String newScore)
post: self.getScore() =
newScore
pre: true
void showScores()
post: true
Resource Usage Restrictions
File system must have 1 KB of available space.
Locally Defined Data Types
No types apply.
Error Handling
An exception is thrown if the newFileName parameter does not exist or there are insufficient permissions to create that file.
Variation Provided
Only the string in which the initial and current scores are stored can change. No variation is provided.
Quality Attribute Characteristics
The scoreboard must be readable. This restricts the combinations of background and text colors.
Element Requirements
- The element requires the file system API to open and close the file.
- The element is a specialization of the Panel component that provides windowing capability.
Rationale and Design Issues
The score is maintained as a string within the ScoreBoard, and each game converts its score to a string. Strings allow different games to have different formats and numbers of scores. For example, Brickles has a single score, Pong has two simultaneous scores, and Bowling has scores for all 10 frames.
Usage Guide
This simple component provides a simple interface. The component is placed in the game window.
SpeedControl Interface
Interface Identity
SpeedControl
Resources Provided
Resource Syntax
SpeedControl(int initialSpeed)
void setSpeed(int newSpeed)
int
getSpeed()
void resetSpeed()
Resource Semantics
pre: true
SpeedControl(int initialSpeed)
post: self.speed =
initialSpeed
pre: true
void setSpeed(int newSpeed)
post: self.speed =
newSpeed
pre: true
int getSpeed()
post: return = speed
pre: true
void resetSpeed()
post: speed = defaultSpeed
Resource Usage Restrictions
No restrictions apply.
Locally Defined Data Types
No types apply.
Error Handling
No error handling applies.
Variation Provided
No variation applies.
Quality Attribute Characteristics
No characteristics apply.
Element Requirements
No requirements apply.
Rationale and Design Issues
This is a very simple structure.
Usage Guide
Just create an instance.
EventHandler Definitions
Interface Identity
EventHandler Definitions
Resources Provided
Resource Syntax
void MouseDown(object sender,MouseEventArgs e);
void MouseUp(object
sender,MouseEventArgs e);
Rectangle MouseMove(object sender,MouseEventArgs
e);
void MouseEnter(object sender,EventArgs e);
void MouseLeave(object
sender,EventArgs e);
void KeyDown(object sender,KeyEventArgs e);
Resource Semantics
pre: mouse is attached and mouse driver has been loaded
void
MouseDown(object sender,MouseEventArgs e);
post: MouseDown action has been
executed
pre: self.isInvoked(MouseDown())
void MouseUp(object
sender,MouseEventArgs e);
post: MouseUp action has been executed
pre: mouse is attached and mouse driver has been loaded
Rectangle
MouseMove(object sender,MouseEventArgs e);
Post: MouseMove action has been
executed
pre: mouse has entered the window for which this is the mouse event
handler
void MouseEnter(object sender,EventArgs e);
post: MouseEnter
action has been executed
pre: mouse has left the window for which this is the mouse event handler
void MouseLeave(object sender,EventArgs e);
post: MouseLeave action has
been executed
pre: keyboard is attached and the keyboard driver has been loaded and a
key has been down
void KeyDown(object sender,KeyEventArgs e);
post:
KeyDown action has been executed
Resource Usage Restrictions
Devices must be attached.
Locally Defined Data Types
No types apply.
Error Handling
No error handling applies.
Variation Provided
The actions taken as a result of each hardware event can be redefined in each new implementation of this interface. In fact, each game uses a different implementation of this interface, which is provided as a parameter for the GameBoard component.
Quality Attribute Characteristics
Each handler routine should be sufficiently efficient to meet the "smooth movement" characteristic of the animation. The MouseMove event will be invoked frequently, so that implementation is very efficient. The response time need not meet the maximum number of events that the hardware is capable of generating since this will vary from one controller to another.
Element Requirements
No outside elements are required by the routines because of the interface. Each implementation may use some specific outside elements.
Rationale and Design Issues
This interface allows the GameBoard component to be generic. Each game requires a different set of actions when the player moves the mouse or presses or releases a button. Placing these actions in an object allows the GameBoard to be a container that delegates the events to the parameter object.
Usage Guide
This interface is stateless. The methods are invoked by events in the order in which they occur.
Evolved Architecture
The requirements model defines a couple of change cases. The high-level architecture shown in the Process Allocation for AGM Games figure will evolve to the more complex structure shown in the last figure as those change cases are implemented. The evolved architecture contains the database in which the scores and state of the game will be stored.
Evolved Architecture
