HFOOAD Chapter 6 Solving really big problems

What is a big problem? ‣  Depends upon your point of view ‣  Individual ‣  Development team ‣  Organization

‣  One that require more than the available resources and skills ‣  Not enough time ‣  Not enough people ‣  Not enough …

2

3

Big problems are usually collections of small problems that are tied together.

Solving big problems usually involves solving the small problems first and then “gluing” the solutions together.

You are prepared for big problems

4

Iterative, incremental development

5

Iterative, incremental development is perhaps the most important tool in your toolbox. We can’t

stress the fact enough that you build great software iteratively and incrementally.

Now back to the regularly scheduled program.

Here’s your big problem

‣  Defining and representing a board configuration

‣  Defining troops and configuring armies or other fighting units

‣  Moving units on the board

‣  Determining legal moves

‣  Conducting battles

‣  Providing unit information

6

Gary’s Games provides frameworks that game designers can use to create turn-based strategy games. Unlike arcade-style shoot-’em-up games and games that rely on audio and video features to engage the player, our games will focus on the technical details of strategy and tactics. Our framework provides the bookkeeping details to make building a particular game easy, while removing the burden of coding repetitive tasks from the game design.

The game system framework (GSF) will provide the core of all of Gary’s Games. It will be delivered as a library of classes with a well-defined API that should be usable by all board game development project teams within the company. The framework will provide standard capabilities for:

The GSF will simplify the task of developing a turn-based strategic board game so that the users of the GSF can devote their time to implementing the actual games.

Project task list?

7

1

2

3

4

Project task list?

8

Talk to Gary and his employees

Gather information about the domain

Identify feature requirements

Outline initial scenarios or user stories

1

2

3

4

Customer conversation

9

10

A requirements hierarchy

11

Vision

Feature Feature Feature

Detail Detail

Detail

Detail

Detail

Detail

Introduction to traceability

12

F1 F2 F3 F4 F5 F6 F7 F8

U1 " "

U2 " "

U3 " "

U4 " "

U5 " "

U6 "

U7 " " "

U8 " " "

U9 " "

U10 " " " "

13

So, what exactly is a feature?

A feature is a high-level description of something an application or system must (or should) have or do.

Example: features of an ATM ‣  Accept debit and credit cards from any source ‣  Charges fees to non-host institutions ‣  Dispenses cash ‣  Accepts deposits ‣  Allows account transfers ‣  Allows balance inquiries ‣  Highly secure transactions ‣  Multi-lingual user interface

14

15

OK, now where do I get these features from?

Anyone who can provide requirements can describe features. Usually they come directly from the customer or the customer’s representatives.

GSF Features

16

1

2

3

4

5

6

GSF Features

17

Support various terrain types

Game-specific unit type support

Boards with squares of various terrain types

Various historical and fictitious scenarios

Support for add-on modules and scenarios

GSF manages administrative details

1

2

3

4

5

6

18

So now we start writing use cases and then we finally get to code, right?

You might just want to identify the use cases before you get into details.

The use case diagram

19

Actor

Use case

System

Simple ATM example

20

Traceability exercise

21

F1 F2 F3 F4 F5 F6

U1

U2

U3

Traceability exercise

22

F1 F2 F3 F4 F5 F6

U1

U2

U3

23

Can’t we just create a new use case like “Manage administrative details?”

But what’s it’s visible value and who is the actor?

I think there is a use case and a new actor that will fit here.

What do you think the new use case and actor are?

Revised use case diagram

24

Definition: Domain Analysis

25

Domain analysis is the process of identifying, collecting, organizing, and representing the relevant information of a domain, based upon the study of

existing systems and their development histories, knowledge

captured from domain experts, underlying theory, and emerging

technology within a domain.

Features in terms of the domain

26

Here’s a revised feature list in terms Gary can understand.

Major GSF concepts

27

Non-visible concepts

28

1

2

3

4

Non-visible concepts

29

Rule

Turn

Time period

…

1

2

3

4

Modules for the GSF

30

Modules for the GSF

31

Units

Utility

Board

Controller

Game

32

This is just what I want. When will it be done?

X

NOT our customer

Man, your game is going to suck. I want graphics. Do you think I’m going to look at a text display?

33

But the game player is right. Without some graphical interface, the games will never sell.

You’re right. But the users of the GSF will add the GUI. We just have to make sure that it can be done easily. Luckily there’s a perfect design pattern for this case.

What pattern should we use?

34

What we’ve learned about big problems

35

Additions to your toolbox

36