DAIMIHenrik Bærbak Christensen1 Mandatory Project Software Reliability and Testing

DAIMIHenrik Bærbak Christensen2 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

DAIMIHenrik Bærbak Christensen3 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

DAIMIHenrik Bærbak Christensen4 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.”

DAIMIHenrik Bærbak Christensen5 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

DAIMIHenrik Bærbak Christensen6 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:

DAIMIHenrik Bærbak Christensen7 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

DAIMIHenrik Bærbak Christensen8 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

DAIMIHenrik Bærbak Christensen9 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

DAIMIHenrik Bærbak Christensen10 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-sword 2: health-potion 3: small-shield head: (none) weapon-hand:heavy-sword shield-hand:(none) torso:small-armour legs:(none)

DAIMIHenrik Bærbak Christensen11 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-axe 2: health-potion 3: frostbite-sword

DAIMIHenrik Bærbak Christensen12 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

DAIMIHenrik Bærbak Christensen13 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

DAIMIHenrik Bærbak Christensen14 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...

DAIMIHenrik Bærbak Christensen15 Architecture

DAIMIHenrik Bærbak Christensen16 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”

DAIMIHenrik Bærbak Christensen17 Approach 1 The standard OO modelling paradigm however fails... class Paladin implements Actor public int dexterity() { return dex; }... } Why?

DAIMIHenrik Bærbak Christensen18 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.

DAIMIHenrik Bærbak Christensen19 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

DAIMIHenrik Bærbak Christensen20 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!

DAIMIHenrik Bærbak Christensen21 Code Example: Base Level

DAIMIHenrik Bærbak Christensen22 Meta Level The Meta Level can populate abstractions by reading configuration files.

DAIMIHenrik Bærbak Christensen23 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

DAIMIHenrik Bærbak Christensen24 Event: Base

DAIMIHenrik Bærbak Christensen25 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

DAIMIHenrik Bærbak Christensen26 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

DAIMIHenrik Bærbak Christensen27 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

DAIMIHenrik Bærbak Christensen28 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

DAIMIHenrik Bærbak Christensen29 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.)

DAIMIHenrik Bærbak Christensen30 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.

DAIMIHenrik Bærbak Christensen31 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

DAIMIHenrik Bærbak Christensen32 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.