ANU comp2110 Software Design lecture 5 COMP2110 Software Design in 2003 lecture 5 Requirements Specifications lecture 3 of 3 The Encounter game case study 0. introduction to the Problem – the Encounter Game 1. examples from the specification document
20
Embed
ANU comp2110 Software Design lecture 5 COMP2110 Software Design in 2003 lecture 5 Requirements Specifications lecture 3 of 3 The Encounter game case study.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ANU comp2110 Software Design lecture 5
COMP2110 Software Design in 2003 lecture 5 Requirements Specifications lecture 3 of 3
The Encounter game case study0. introduction to the Problem – the Encounter Game1. examples from the specification document
ANU comp2110 Software Design lecture 5
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
ANU comp2110 Software Design lecture 5
A Case Study of Encounter: Overview (1)
An overview of the Specification of the Encounter video gameSpecification document comes in 2 parts: http://cs.anu.edu.au/student/comp2110/resources/ Encounter-SRS/EncounterSRS-1.htmland ...
EncounterSRS-1.html
you need to study this to prepare for tutorial in week 3
ANU comp2110 Software Design lecture 5
A Case Study of Encounter: Overview (2)
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
ANU comp2110 Software Design lecture 5
Sample Encounter Screen
dressing room
kitchen
living room
COURTYARD
Set qualities
End game
Get status
Graphics reproduced with permission from Corel.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ANU comp2110 Software Design lecture 5
ANU comp2110 Software Design lecture 5
User Interface for Setting Quality Values
Shawn
Choose the quality you wish to set
16.3
Current life points: 100.0
Choose the value of the quality selected
image
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ANU comp2110 Software Design lecture 5
User Interface for Setting Quality
Values
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.,
OKGraphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ANU comp2110 Software Design lecture 5
2. Player requests a window for setting his character’s qualities.
ANU comp2110 Software Design lecture 5
Engage Foreign Character Use Case
Encounter
player
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
. . . .
Engageforeign
character
Name of use case
Details of use case
Actor (agency external to the application)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ANU comp2110 Software Design lecture 5
A use case expressed in text
2.2.3 "Engage Foreign character" use caseActor: player of Encounter1. System displays the foreign character into the same area as the player
2. System exchanges data between the two characters
3. System displays the results of the engagement in a message window. 4. Player dismisses window.
ANU comp2110 Software Design lecture 5
A use case expressed in text
2.2.3 "Engage Encounter Foreign character" use case
Actor: player of Encounter
1. System displays the moves a foreign character into the same area as area occupied by the playeror Player moves into the area containing a foreign character.
2. System exchanges data between the two characters causes 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.
ANU comp2110 Software Design lecture 5
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.
ANU comp2110 Software Design lecture 5
1.1 create; display
Sequence Diagram for Engage Foreign Character Use Case
2.1 execute
3 create and show
:EngagementDisplay
:Engagement
2.2 change quality values
1.2 create
:Player Character
:EncounterGame
freddie: Foreign
Character
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ANU comp2110 Software Design lecture 5
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 model
to identify the “ingredients” - domain classesand some of the actions
• drives refinement, organisation, improvement of specification
ANU comp2110 Software Design lecture 5
From Sequence diagrams to Domain classes (2)
Classes in the Encounter gameclass object
• 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.
ANU comp2110 Software Design lecture 5
Other sources of Domain classes?
The use cases do not provide all of the useful classes for writing and organising the specifications
Other domain classes can come frombrainstorming & paring down
• door• exit• combat• passageway• result• score• rule• quality• . . . and more see fig 13.41
ANU comp2110 Software Design lecture 5
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
ANU comp2110 Software Design lecture 5
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