Overview

1.1 Identification

The Sykes/McGregor ArcadeGame Product Line will produce a series of arcade games ranging from low obstacle count to high. Each game is a one-player game in which the player controls, to some degree, the moving objects. The objective is to score points by hitting stationary obstacles.

1.2 Document Map

The Sykes/McGregor ArcadeGame Product Line is described in a series of documents. These documents are related to each other as shown in Figure DOCMAP. This map shows the order in which the documents should be read for the first time. Once the reader is familiar with the documents, the reader can go directly to the information needed.

This is the scope document. Its purpose is to define the boundaries of the product line. Design and implementation decisions are made to address the full scope of the product line but with no concern for any characteristics outside the product line.

Figure DOCMAP

1.3 Concepts

A software product line is a group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission and that are developed from a common set of core assets in a prescribed way.

A product line core asset is any deliverable that is intended for continuing use in the creation of multiple products. This may include reusable code modules and documents.

A product is any saleable or useable output produced from the product line assets.

Application engineering is the construction of a product using the product line architecture and selecting from the inventory of available product line components. It is accomplished by identifying the specific values for each variation point in the product line architecture.

Domain engineering creates, acquires, and manages the resources needed to build a set of products.

1.4 Reusable Components

In a product line, components are designed to be reusable within the context of the product line. That is, no attempt is made to make a component “as general as possible”. Each design decision is made with regard to the extent of the products in the product line.

1.5 Product line variation

The principle variations in the Sykes/McGregor ArcadeGame Product Line are:

· the rules of the game

· the types and numbers of pieces

· the behavior of pieces.

These are elaborated in the product line architecture document.

1.6 Readership

This document is intended to provide some level of information to all of the stakeholders in the Sykes/McGregor ArcadeGame framework. Managers will find the information needed to support product planning. Architects will find the information necessary to support commonality and variability analysis. Product developers will find the rationale for each product’s membership in the product line.

2 Product Line Context

2.1 In Scope

The context of the Syles/McGregor ArcadeGame Product Line is illustrated in Figure SCOPE. The two games shown inside the circle constitute the current definition of the product line. Those games outside the circle are out of scope and will not be constructed from the assets built for the product line.

Figure SCOPE

Each system in the product line has the following features:

· single player

· graphical view of game

· animation driven games

· moving and stationary objects

· rules about the interaction of game elements

The games may have multiple different players but only one is active for a particular match. For example, having a computer player is useful for testing purposes.

2.2 Out of scope

The Sykes/McGregor ArcadeGame product line does not address traditional “board” games. A framework for this type of game was provided in [McGregor 92] but is out of scope for this discussion. These games contain an element of strategy that is not included in the current product line. Board games usually allow multiple players.

3 Approach

The product line will be incrementally introduced into Sykes/McGregor. Brickles will be the first product in the product line. Assets will be created for that game taking into account the full scope of the product line. Once Brickles has been constructed, the Pong game will be implemented next. Finally, the Bowling game will be implemented. Additional games may be added to the product line later.

With each new product, necessary changes will be made to the architecture. Code assets will also be revised where necessary. This may seem like a violation of the primary goal of the product line approach but it isn’t. The intention as each product is produced is to produce the perfect set of product line assets. Realizing that this is unlikely to happen, we include this refinement process in our development approach.

4 References

[Bachmann 00t]	Bachmann F., et. al., The Architecture Based Design Method, SEI Technical Report, 2000. (http://www.sei.cmu.edu/publications/documents/00.reports/00tr001.html)
[Bass 98]	Bass L., Clements P. and Kazman R., Software Architecture in Practice, Addison-Wesley, 1998.
[McGregor 92]	McGregor, John D. and Sykes, David A. Object-Oriented Software Development: Engineering Software for Reuse, International Thomson, 1992.
[McGregor 01]	McGregor, John D. and Sykes, David A. A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001.
[Northrop 02]	Northrop L., Framework for Software Product Line Practice, SEI Report, 2002. (http://www.sei.cmu.edu/plp/framework.html)