View
214
Download
0
Tags:
Embed Size (px)
Citation preview
DAIMI Henrik Bærbak Christensen 1
Mandatory Project
Software Reliability and Testing
DAIMI Henrik Bærbak Christensen 2
Aim
To use techniques from the course to– implement a reliable software system– assess system qualities, notably reliability
This entails– test case definition using BB and WB techniques– tactics to make the system testable
– integration testing and test planning
– using review techniques
DAIMI Henrik Bærbak Christensen 3
Context
SRaT World– A simple Role Playing Game (RPG)
• inspired by my kid’s pass time: Diablo II and Titan Quest
– Architectural driver• customizability to support building new RPG’s • modularity to support parallel development
DAIMI Henrik Bærbak Christensen 4
Customizable property
We require that our RPG is highly customizable. For instance it should be able to model both– Diablo II:
• “Barbarian slay beastmen on the cold plains wearing the FrostBite axe and Holy Shield and gain experience points and a level.”
– The EVU Student Trial• “Diploma student solves mandatory exercise 1 in SRaT using
BlackBox testing and gain intelligence. Next he attacks the SRaT oral exam, wins, and has solved the first quest.”
DAIMI Henrik Bærbak Christensen 5
Why?
Why does this make a reasonable project? Because
– Set of relatively isolated modules• all groups do not solve same assignment• thus: realistic integration testing scenario• thus: force you to implement stubs / testability tactics
– Each module/task is relatively small• implementation burden not too big• complexity not overwhelming for using BB and WB
– on the other hand they are larger than System.abs
– Review of other groups’ work that have solved similar modules
DAIMI Henrik Bærbak Christensen 6
What is a RPG?
A Hero– explores worlds– slash enemies– pick up items
• weapons/armour• life potions• gold
– grows stronger• healthier• stronger• more intelligent• learns skills
– trades• gold and items
– solves quests• get rid of “bosses” to go to next quest
Demo: http://www.blizzard.com/diablo2/demo.shtml
DAIMI Henrik Bærbak Christensen 7
Architectural considerations
Our focus will be on the domain production code– we work in parallel with the GUI team but they are
slow
– to develop we aim at two interfaces• a keystroke driven one
– to play around, exploratory testing, debug
• JUnit driven: systematic testing and reliability estimation
– we ignore real-time game play and prototype it using a turn based approach
DAIMI Henrik Bærbak Christensen 8
The worlds (area)
The areas are simply a matrices of tiles (of various types)
Areas are connected by portals – entering a portal and you a instantly teleported to another area...
row = 0
col = 3
item (sword)
portal
hero
nasty enemy
DAIMI Henrik Bærbak Christensen 9
Key-stroke based interface
Vision:– we give commands to our hero using 1-2(-3?)
keystrokes
Use-case 1
– “a9”: attack enemy at NorthEast tile– “p3”: pickup item at SouthEast tile
“m9”: move NorthEast
DAIMI Henrik Bærbak Christensen 10
Inventory and worn items
A hero wears and carries things that he finds– “ic”: display items carried (inventory)
– “iw”: display items worn
– “w1”: wear item #1 from inventory• (items know that they can be worn, and where they are worn)
– “u2”: use item #2 from inventory• (items know they can be used)
1: bronze-sword2: health-potion3: small-shield
head: (none)weapon-hand: heavy-swordshield-hand: (none)torso: small-armourlegs: (none)
DAIMI Henrik Bærbak Christensen 11
Trading
At some tiles (at a trader) you may sell items for gold or buy new items using your gold– “it”: display inventory of trader
– “b1”: buy item #1 from trader inventory (if enough gold)
– “s3”: sell item #3 from my inventory for gold
1: battle-axe2: health-potion3: frostbite-sword
DAIMI Henrik Bærbak Christensen 12
Items and attributes
Our hero has attributes– primary
• health, dexterity (behændighed), strength, ...– health = 0 => you die and game over...
• level and experience points• gold (cash carried)
– items also have attributes• weapons: the damage they can inflict• requirements: what level, strength, dexterity, etc, is required
to wear this weapon/armour?• “+”: wearing/carrying certain items boost your dexterity,
strength, attack ability, etc.• use: using a health-potion increases your health
DAIMI Henrik Bærbak Christensen 13
Complex item attributes
In Diablo II item attributes can be rather complex Deadly sceptre of flame
– damage: 7-13– required strength: 25– required level: 3– +22% enhanced damage– 1-5 fire damage– +2 prayer (paladin only)– +50% damage to undead
DAIMI Henrik Bærbak Christensen 14
The central tale
RPGs are about violently slashing your enemies in an orgy of blood...– (proper entertainment for a 9 year old, sigh...)
Attacking:– chance of hitting (hero)– chance of blocking (enemy)– damage by hit enemy “health” decrease– hero attribute “experience-point” increase
• experience-point > next-level-threshold level++
Quests– Slaying the quest’s “boss” and you go on to the next...
DAIMI Henrik Bærbak Christensen 15
Architecture
DAIMI Henrik Bærbak Christensen 16
Architecture and Design
How do we make such a system?
Well – it seems really object oriented...
We can point on numerous objects with attributes and actions...
However, the challenge was to cover all possible RPGs: “Diablo II” and “EVU Student at Aarhus”
DAIMI Henrik Bærbak Christensen 17
Approach 1
The standard OO modelling paradigm however fails...
class Paladin implements Actor public int dexterity() { return dex; } ... }
Why?
DAIMI Henrik Bærbak Christensen 18
The customizable property
The above model seems awkward at best for modelling the “EVU Student Trial” RPG...
We need an architecture that is much more flexible and define abstractions at a more abstract level.
DAIMI Henrik Bærbak Christensen 19
Buschmann: Reflection pattern
The answer is the Reflection pattern (Posa 1 book): Meta modelling = a model of a model
Architecture consists of two levels: – Base and Meta
Base contains only central abstractions– actor, events, items, game loop (model of model)
Meta contains all specifics– attribute sets– events as attribute manipulations and interpretation– = the model itself
DAIMI Henrik Bærbak Christensen 20
Base level
The base level defines concrete data storage classes with minimal interpretation of variables.
All variables are kept in java.util.Map:– (String, value) pairs like (“health”, 84);
Advantage:– Attribute set is open-ended and can be defined at will
by meta level• actor.getAttributes().putInt(“dexterity”,12);
Disadvantage:– No compile time checking! – ... we have to rely on – well – testing!
DAIMI Henrik Bærbak Christensen 21
Code Example: Base Level
DAIMI Henrik Bærbak Christensen 22
Meta Level
The Meta Level can populate abstractions by reading configuration files.
DAIMI Henrik Bærbak Christensen 23
Base Level
Events express dynamics Define an Event interface whose execute
method takes all possible parameters
Implementing classes can by dynamically loaded by the class loader and identified by their name
DAIMI Henrik Bærbak Christensen 24
Event: Base
DAIMI Henrik Bærbak Christensen 25
Meta
The main game loop receives key-stroke that must be translated into events– “a9” = invoke ‘triggeredExecute’ on instance of
AttackEvent.
Define an “EventBinding” translator– (“a”,AttackEvent.class)
– dynamic class loading
:Game
keyEvent
:EventBinding
getAssociatedEvent
lookup
event
event:Event
triggeredExecute
manipulate actors, areas, items, etc.
DAIMI Henrik Bærbak Christensen 26
Roles: Actor
Actor (animate object)– has attributes
• health, dexterity, skills, experience ...
– has inventory• items picked up but not in use
– wears items• weapons in hands, helmet, armour
– has location in area– may perform events
Example: Hero, all the different types of enemies
Object
Actor
DAIMI Henrik Bærbak Christensen 27
Role: Area
Area– n*m matrix of tiles
Example: “The Wastelands”
Tile– (knows image file)– has attributes: passable/impassable– has 0-1 Object– has 0-1 Event
Example: a wall tile (impassable), a grass tile with a weapon item, a portal with a “portal” event.
Area
Tile
n*m
DAIMI Henrik Bærbak Christensen 28
Role: Item
Item (inanimate object)– has attributes
• semantics is defined by events
Example: – rusty axe with attack strength 2-4
• interpretation defined by attack event
– a shield with defence +10%• interpretation defined by attack event
– life potion with 100% health• interpretation defined by use event
– dexterity charm with +2 dexterity• interpretation defined by attack event (and possibly others)
Object
Item
DAIMI Henrik Bærbak Christensen 29
Role: Event
Event:– defines a state change on actors and/or area
Example:– attack event reduce health of defender and increase experience
of attacker– portal event relocate actor at new position in new area– move event (may) relocate actor at new position in same area
(unless new position is impassable)– use event removes item from inventory and increase actor
attributes (potion -> health)– pick up event removes item from tile and adds it to actor
inventory– wear event removes an item from inventory and adds it to actor
wear list (weapon in hand, etc.)
DAIMI Henrik Bærbak Christensen 30
Event subtypes
TriggeredEvent:– an event triggered by user action
Example: – User presses ‘a9’ -> hero attacks
enemy NorthEast of him
AutomaticEvent:– an event triggered by game loop
Example:– an enemy automatically execute “attack event” when
the hero is-near. “is-near” = within one tile radius.
DAIMI Henrik Bærbak Christensen 31
Status
A draft specification will be prepared for Wednesday 7th and published on the web– Will include partial implementation of base layer
• all interfaces + attribute map code
– Example “game specification files”– Learning tests to kickstart
DAIMI Henrik Bærbak Christensen 32
Status
The spec will be flawed!
Use your testing techniques to discover the ambiguities and defects in the spec !
Report them on the discussion forum (AULA)
Read the forum + web site regularly to adjust to specification revisions.