1 / 20

The Encounter game case study introduction to the Problem – the Encounter Game

COMP2110 Software Design in 2003 lecture 5 Requirements Specifications lecture 3 of 3. The Encounter game case study introduction to the Problem – the Encounter Game examples from the specification document. The Software Requirements Specification SRS.

davidtcoleman
Télécharger la présentation

The Encounter game case study introduction to the Problem – the Encounter Game

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMP2110 Software Design in 2003 lecture 5 Requirements Specifications lecture 3 of 3 The Encounter game case study • introduction to the Problem – the Encounter Game • examples from the specification document

  2. The Software Requirements Specification SRS The product of the Analysis phase isa well defined information model: • a set of labelled, organised requirements statements: • functional consumer and developer requirements • system requirements • performance requirements • a set of use cases or scenariosthat capture and express the relationships between the model and the real world of the problem • other explanatory models: • interfaces, states, decisions

  3. An overview of the Specification of the Encounter video game Specification document comes in 2 parts: http://cs.anu.edu.au/student/comp2110/resources/ Encounter-SRS/EncounterSRS-1.html and ... EncounterSRS-1.html you need to study this to prepare for tutorial in week 3 A Case Study of Encounter: Overview (1)

  4. The Encounter game is a computer based role playing game which simulates all or part of the lifetime of the player’s character includes characters not under player’s control, called foreign chacters game characters have a number of qualities: strength, speed, patience etc each quality has a numerical values the game is played over a map of areas (rooms) characters engage each other when in the same area the result of an engagement depends on the area and the values of the qualities of the two characters success is measured by living as long as possible with accumulated points A Case Study of Encounter: Overview (2)

  5. Get status Set qualities End game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Sample Encounter Screen kitchen COURTYARD living room dressing room Graphics reproduced with permission from Corel.

  6. User Interface for Setting Quality Values Shawn Current life points: 100.0 Choose the quality you wish to set Choose the value of the quality selected 16.3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. image

  7. User Interface for Setting Quality Values Shawn Current life points: 100.0 Choose the quality you wish to set Choose the value of the quality selected 16.3 Explanation OK Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Image The values of the qualities not specifically chosen remain in the same proportion to each other. Values less than 1.0 are counted as zero. E.g., before: strength = 10.0, endurance = 60.0, intelligence = 30.0, patience = 0.0 (current life points 10.0 + 60.0 + 30.0 + 0 = 100.0) change: strength from 10.0 to 20.0 after: strength = 20, endurance = 53.33, intelligence = 26.66 Graphics reproduced with permission from Corel.

  8. 2. Player requests a window for setting his character’s qualities.

  9. Encounter 1. System displays the foreign character in the same area as the player’s. 2. System exchanges data between the two characters. 3. System displays the results of the engagement in a message window. 4. Player dismisses window. Initialize Engage foreign character . . . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engage Foreign Character Use Case Details of use case player Actor (agency external to the application) Name of use case

  10. A use case expressed in text 2.2.3 "Engage Foreign character" use case Actor: player of Encounter 1. Systemdisplays the foreign character into the same area as the player 2. Systemexchanges data between the two characters 3. System displays the results of the engagement in a message window. 4. Player dismisses window.

  11. A use case expressed in text 2.2.3 "EngageEncounter Foreign character" use case Actor: player of Encounter 1. Systemdisplays themoves a foreign character into the same area asarea occupied by the playeror Player moves into the area containing a foreign character. 2. Systemexchanges data between the two characterscauses the two characters to engage. 3. System displays the results of the engagement in a message window. 4. Player dismisses window. 4. If either the player's character or the foreign character has no points, the game terminates; or 5. System moves the player's character to a random area different from that in which the encounter took place, and displays it there.

  12. A use case expressed in text - and refined 2.2.3 "Encounter Foreign character" use case Actor: player of Encounter 1. System moves a foreign character into the area occupied by the playeror Player moves into the area containing a foreign character. 2. System causes the two characters to engage. 3. System displays the results of the engagement 4. If either the player's character or the foreign character has no points, the game terminates; or 5. System moves the player's character to a random area different from that in which the encounter took place, and displays it there.

  13. :Encounter Game freddie: Foreign Character :Engagement :Engagement Display :Player Character 2.2 change quality values 3 create and show Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Sequence Diagram for Engage Foreign Character Use Case 1.1 create; display 1.2 create 2.1 execute

  14. From Sequence diagrams to Domain classes (1) • these sequence diagrams are figures 13.22, 13.23, 13.24 in Braude SD (with some changes) • use cases are a beginning point for requirements and analysis • alternatives include scenarios, event-action cases • no prescribed format: but writing the use cases • drags needs from the client • drives the analysis of the information modelto identify the “ingredients” - domain classesand some of the actions • drives refinement, organisation, improvement of specification

  15. From Sequence diagrams to Domain classes (2) Classes in the Encounter game classobject • from Initialize sequence diagram: • EncounterGame (a single object) • PlayerCharacter mainPlayerCharacter • Area dressingRoom • PlayerQualityWindow (a GUI class for the use case only) • from Encounter foreign character: • ForeignCharacter freddie • Engagement (a single object) Other domain classes can come frombrainstorming & paring down.

  16. The use cases do not provide all of the useful classes for writing and organising the specifications EncounterGame PlayerCharacter Area PlayerQualityWindow ForeignCharacter Engagement EngagementDisplay GameCharacter AreaConnection ConnectionHyperlink Other domain classes can come frombrainstorming & paring down door exit combat passageway result score rule quality . . . and more see fig 13.41 Other sources of Domain classes?

  17. Other sources of Domain classes? (2) ... brainstorming & paring down • Game: not a domain class, too general • GameCharacter : too general – replace by PlayerCharacter • ForeignCharacter : OK to keep, acts a bit differently from PlayerCharacter – so introduce EncounterCharacter as common parent • Quality : omit, try to handle as an attribute of EncounterCharacter • Room : we already have Area which covers this concept, no need to distinguish any difference

  18. Why look for the domain classes? • the domain classes are the key concepts (nouns) that should appear in most of our functional requirements statements • we want to easily match requirements with classes in the design: keeping the domain classes (and adding more classes) is a good starting point for design

  19. Information models – finite state model

More Related