Pedagogical Product Line
Overview
Business Case
Scope
Requirements
Concept of Operations
Architecture
Unit Test Plans
Production Plans
System Test Plans
Brickles Product
Pong Product
Bowling Product
Bibliography
Glossary
Misc Documents

Arcade Game Maker Pedagogical Product Line: Architecture Documentation, Volume 2 - Software Architecture Views

Revision Control Table
Version Number Date Revised Revision Type A-Add,
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.

Primary Presentation


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

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).

Primary Presentation


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.

Primary Presentation


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

This view shows the classes that specialize MovableSprite (see following figure).

Primary Presentation


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).

Primary Presentation


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

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:

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:

  1. Each has its own icon on the screen.
  2. Each provides its own behavior when it is involved in a collision.
  3. 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

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