EECS3311 Software Design Fall 2020
Lab3
Implementing a Game with Undo/Redo Capability
Chen-Wei Wang and Kevin Banh Released Date: Monday, October 12
Due Date (Sections A & E): 11:59pm (EST), Sunday, November 1 Policies
– Your (submitted or un-submitted) solution to this lab exercise (which is not revealed to the public) remains the property of the EECS department. Do not distribute or share your code in any public media (e.g., a non-private Github repository) in any way, shape, or form. The department reserves the right to take necessary actions upon found violations of this policy.
• You are required to work on your own for this lab. No group partners are allowed.
• When you submit your lab, you claim that it is solely your work. Therefore, it is considered as an violation of academic integrity if you copy or share any parts of your Eiffel code during any stages of your development.
• When assessing your submission, the instructor and TA will examine your code, and suspicious submissions will be reported to the department/faculty if necessary. We do not tolerate academic dishonesty, so please obey this policy strictly.
– You are entirely responsible for making your submission in time.
• You are encouraged to submit multiple times prior to the deadline: only the last submission before the deadline will be graded.
• Practice submitting your project early even before it is in its final form.
• No excuses will be accepted for failing to submit shortly before the deadline.
• Back up your work periodically, so as to minimize the damage should any sort of computer failures occur. Follow this tutorial series on setting up a private Github repository for your Eiffel projects.
• The deadline is strict with no excuses: you receive 0 for not making your electronic submission in time.
• Emailing your solutions, or links to a cloud drive, to the instruction or TAs will not be
accepted.
– You are free to work on this lab on your own machine(s), but you are responsible for testing your code at a remote Prims lab machine before the submission.
1
Contents
1 Working on Your Own Machine 3
2 Grading Criterion of this Lab 3
3 Reporting Issues of the Oracle 3
4 Work Sequence for this Lab 3
5 Task 1 of Lab3: Required Tutorials 4
6 Developing Your ETF Project: GUI Mode vs. Command-Line Mode 5
7 Task 2 of Lab3: Studying the Undo/Redo Pattern 5
8 Task 3 of Lab3: Problems 5
8.1 BackgroundStory ……………………………………….. 5
8.2 DetailsRelevanttoYourDesign/Implementation ………………………… 6
8.3 AbstractUserInterface …………………………………….. 7
8.3.1 AbstractEventsoftheSpaceDefenderGame ………………………. 7
8.3.2 ETF:UseofEnumerationTypes …………………………….. 8
8.4 OutputtingtheAbstractState …………………………………. 9
8.5 Messages ……………………………………………. 10
8.6 Errors……………………………………………… 11
8.7 GettingStarted…………………………………………. 12
8.8 ModificationoftheClusterStructure………………………………. 13
9 Task 4 of Lab3: Design Document 14
10 Submission 15
10.1 Checklist before Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.2 Submitting Your Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11 Questions
12 Amendments
17 17
2
1
Working on Your Own Machine
To generate the ETF starter project for your Lab3, you must use the etf command that is available on either the virtual machine or your Prism account (via the remote labs).
You are expected to develop your own acceptance tests and perform automated regression testing constantly. This requires the execution of the oracle.exe you are given (which only works on Linux). See the following tutorial video for details:
For a generated ETF project to compile on your machine, you need to first download a library called MATHMODELS,
and then set a environment variable MATHMODELS which points to the location of its download.
We were reported that some students are unable to compile ETF projects (with some C-compilation errors), even though their previous lab projects compile successfully. In this case, you may just want to switch to remote labs or the virtual machine.
Grading Criterion of this Lab
When grading your submission (separate from the design document), your ETF project will be compiled and built from scratch, and then executed on a number of acceptance tests (similar to at01.txt, at02.txt, . . . given to you).
Each acceptance test is considered as passing only if the output generated by your program is character-by- character identical to that generated by the oracle. No partial marks will be given to a test case even if the output difference is as small as a single character.
You are given an oracle program for you to test if your software and the oracle produce identical outputs on all of your acceptance test files. It is your responsibility of writing your own acceptance tests in order to compare outputs from program against the oracle.
It is therefore critical for you to always switch to the command-line mode of your ETF project and use either diff or meld to compare its output and that of the oracle.
Reporting Issues of the Oracle
2
– –
– –
–
–
–
–
3
In case you find that the oracle.exe executable given to you does not behave as expected, post questions on the eClass forum.
4
Work Sequence for this Lab
1. Learn ETF (Section 5) and the Undo/Redo Design Pattern (Section 7). 2. Implement the game (Section 8):
– Commands outside of game (play and abort) – Initial state in game
– Starfighter movement
– Add projectiles
– undo and redo
3. Write the design document (Section 9).
3
5
Task 1 of Lab3: Required Tutorials
1. Tutorial Videos on ETF
– Before starting the above tutorial videos, set up a starter project as follows.
– Once you login into your Prism account, follow the steps below to get settled for the tutorial videos:
1.1 Type the following commands to create a new subdirectory ETF/bank in your workspace (assuming that a directory eecs3311-workspace is on your Desktop):
1.2 Inside the subdirectory bank, create a plain text file bank-events.txt:
cd ∼/Desktop/eecs3311-workspace mkdir ETF
mkdir ETF/bank
— declaration of system name
system bank
— declaration of event signatures
new(id: STRING)
— create a new bank account for “id”
deposit(id: STRING; amount: INTEGER)
— deposit “amount” into the account of “id”
withdraw(id: STRING; amount: INTEGER)
— withdraw “amount” from the account of “id”
transfer(id1: STRING; id2: STRING; amount: INTEGER)
— transfer “amount” from the account of “id1” to that of “id2”
1.3 Run the following command from your Prism account:
Noice that we do not distribute executables of the etf tool (for generating a starter project). You can get access to the ETF generator via your Prism account.
1.4 A list of files should be automatically generated.
1.5 If you decide to work through the tutorial videos on your Prism account, you may now get started.
1.6 If you decide to work on you own computer:
• Compress the generated starter project and transfer the zip file to your own computer:
• Proceed to Section 1 to set up the mathmodels library, which is required for compiling the generated ETF starter project.
2. Link to an optional Written Tutorial: Tutorial on ETF: a Bank Application
cd ∼/Desktop/eecs3311-workspace/ETF/bank etf -new bank-events.txt .
cd ∼/Desktop/eecs3311-workspace/ETF zip -r bank.zip bank
4
6
Developing Your ETF Project: GUI Mode vs. Command-Line Mode
– When an ETF project is first generated, GUI mode is the default.
– However, you are discouraged to develop your project using the GUI mode, as:
• You can only perform automated regression testing in the command-line mode.
• When we grade your submission, your submitted project will be executed in the command-line mode.
– Therefore, switch to the command line mode immediately:
switch: INTEGER
— Running mode of ETF application
do
— Result := etf_gui_show_history. — GUI mode
Result := etf_cl_show_history
— Result := unit_test — Unit Testing mode
end
7
Task 2 of Lab3: Studying the Undo/Redo Pattern
While you have freedom on designing classes under the model cluster, your implemented classes must satisfy the following requirements:
–
–
8 8.1
You must support the undo/redo features by following the pattern discussed in Chapter 21 from OOSC2 (available in your Lab3 starter).
In the model cluster, you must implement an inheritance hierarchy of commands (for the space defender game) as discussed on .
Remark: Do not get confused with these “model” commands (which are created in order to implement the undo/redo pattern) and the “user” ETF commands (which are generated to handle user events in, e.g., the batch mode). You should still only put error-message-related code in these ETF command classes.
Task 3 of Lab3: Problems Background Story
You receive a zero for this lab if you do not follow the undo/redo pattern covered in OOSC2.
page 700 in Chapter 21 of OOSC2
War . . . war never changes. It is the year 40000. Several millenniums ago, humanity had united and form a single Federation. With no internal conflicts, humanity was able to work together and explore beyond the solar systems. Historians call this the Golden Age. The Age of Explorations. Everything is a cycle though. The cycle of life and death. The cycle of day and night. With long periods of peace and prosperity, it was only a matter of time before conflicts began again. And so it did. From beyond the expanse of deep space, they came. They came from a dark shadowy area known as the Void – a location so treacherous even the accumulation of human technologies over the many years cannot scout it. Monstrous creatures seeking to extinguish the light of humanity. Rather then being sitting ducks, the Federation began researching a new class of military vessels – Starfighters, a prelude to the Age of Conflict. You, as a programmer for the Federation Army, have been tasked to develop a game to help pilots utilize the Starfighters.
5
8.2 Details Relevant to Your Design/Implementation
Each game takes place on a two-dimensional grid of locations. A user can start a game by invoking the play(r, c, m1, m2) command, where the argument values specify:
–randcaredimensionsofthegrid(with3≤r≤10and5≤c≤30). Rowsarelabeledbyalphabetsand columns by numbers.
– m1 is an integer value between 1 and 40, denoting the maximum sum of vertical and horizontal moves allowed in a single Starfighter movement.
The Starfighter’s movement path must be understood as a vertical move followed by a horizontal move.
For example, moving from (B, 3) to (D, 7) means to first move -2 units vertically to (D, 3), then 4 units horizontally to (D, 7). For this particular movements (consisting of |-2| + 4 = 6 moves) to be valid, the value of m1 should be ≥ 6. A Starfighter’s movement must be invoked by the move command.
– m2 is an integer value between 1 and 5, denoting the exact number of (horizontal) moves in a single projectile movement. Projectiles only move horizontally to the right.
The user can only use the play command when they are not in a game. For errors that can be triggered by the play command, see Section 8.6. When a new game starts, the Starfighter always spawns in the middle (i.e., ceiling of the row size of the grid divided by 2) of the first column. Once a game is started, it continues until either the Starfighter dies (because it collides with its own projectile) or the abort command is invoked by the user (which is allowed only when the user is in a game). In a game, there can be various characters on the grid.
1. means that location is empty.
2. S means that location contains the Starfighter.
3. * means that location contains a projectile from the Starfighter.
4. X marks the location where the Starfighter got destroyed.
During a game, we have the concept of turns. A turn occurs when: – The user invokes either the pass, move, or fire command; and – An error (see Section 8.6) does not occur.
A turn can be split into two parts:
First Part: All existing projectiles (see the Second Part below to see how a projectile is spawned) on the grid move to the right (by m2 spaces) in the chronological order of their creations (projectiles created earlier will move first). More precisely, every turn, they keep moving to the right even after they go off the grid. You may want to still keep track of those projectiles who have gone off the grid, as the user may invoke the undo command to bring them back to the grid.
If any projectiles collide with the Starfighter, the Starfighter is destroyed, in which case the current game is over: an X replaces the location where the projectile/Starfighter was, all projectiles that have not moved yet will finish their moves, but the next part of the turn involving the Starfighter will not occur.
Second Part: If the Starfighter is still alive (i.e,. without a projectile colliding with it), what happens next depends on the command invoked by the user:
– The pass command means the Starfighter does nothing.
– The fire command means the Starfighter fires a new projectile. On the turn it is first spawned, a projectile will originate in front of (i.e., to the immediate right of) the Starfighter. However, if the Starfighter is on the edge of the grid, invoking the fire command is still valid, but the projectile does not appear on the grid.
– The move command moves the Starfighter to another location on the grid. The Starfighter may move up to m1 spaces in total. If the Starfighter collides with a projectile during movement, the Starfighter is destroyed. An X replaces the location where the Starfighter was and the game is over.
6
Below are some additional notes to keep in mind.
1. There is no “grid-wrapping” when the Starfighter moves. For example, say the current position of the Starfighter
is on the top-left corner of the grid, it cannot move to the bottom-left when m1 is 1.
2. When a Starfighter moves, it moves vertically first, then horizontally.
3. When you check for collision, you may not just check the end location on whether there is something (either the Starfighter or a projectile) there. The Starfighter and projectiles actually have to travel a series of adjacent vertical moves followed by horizontal moves to the end position, meaning that if there is something along the travel path, a collision occurs.
During a game, the user can also undo or redo an invoked command that constitutes a turn. Note that: – Invalid moves do not constitute a turn, so they are not part of the undo/redo history.
– The undo/redo history is on a per-game basis: once the game is over, the undo/redo history is reset.
One approach to the above undo/redo problem is by storing the entire state of the game each turn and restoring those states as required. Would this be a good approach? See Section 7 for the appropriate design pattern for solving this problem.
8.3 Abstract User Interface
Customers need not know details of your design of classes and features. Instead, there is an agreed interface for customers. This is why we are using ETF: customers only need to be familiar with the list of events.
8.3.1 Abstract Events of the SpaceDefender Game
We assume the following abstract user interface (see also the space defender 1.grammar.txt file), which is used to generate the starter ETF project for your Lab3:
system space_defender_1
———————————————————————
— SpaceDefender System Types
———————————————————————
type MAX_ROW = 3..10
— max row size for board
type MAX_COLUMN = 5..30
— max column size for board
type ROW = {A, D, C, J, F, E, B, G, I, H}
— row
type COLUMN = 1..30
— column
type PLAYER_MOV = 1..40
–value for Starfighter movement
type PROJECT_MOV = 1..5
–value for projectile movement
———————————————————————
— SpaceDefender User Commands
———————————————————————
play(row: MAX_ROW; column: MAX_COLUMN; player_mov: PLAYER_MOV; project_mov: PROJECT_MOV)
— Starts a new game provided game
— has not been started yet or is over.
— Size of board specified here.
7
— The amount of spaces a Starfighter can move and the amount of
— spaces projectiles move are also specified here.
abort
— Ends the game prematurely. Only valid when game is
— in progress.
move (row: ROW; column: COLUMN)
— Moves the ship to location assuming movement is feasible.
— Note that this command will cause a turn to pass/occur.
pass
— Lets the ship pass a turn.
— Note that this command will cause a turn to pass/occur.
fire
— Ship fires a projectile.
— Note that this command will cause a turn to pass/occur.
undo
— Undo a turn in a game.
redo
— Redo a turn in a game that was undo.
The above abstract user interface is included in a text file space defender 1.grammar.txt, upon which you will invoke the etf program (available only on the red server) to generate a starter project.
8.3.2 ETF: Use of Enumeration Types
There is the declaration of an enumeration type in the above abstract user interface:
type ROW = {A, D, C, J, F, E, B, G, I, H}
And here is the abstract user command which makes use of the above enumeration type:
move (row: ROW; column: COLUMN)
Q. In the corresponding abstract user command class, i.e., ETF MOVE (in cluster abstract ui/user commands), how do you determine if the argument value row is which member (e.g., A, D) of the enumeration?
A. Observe the following inheritance hierarchy:
– ETF MOVE inherits ETF MOVE INTERFACE (in cluster generated code/abstract ui/user commands).
– ETF MOVE INTERFACE inherits ETF COMMAND (in cluster abstract ui/user commands).
– ETF COMMAND inherits ETF COMMAND INTERFACE (in cluster generated code/abstract ui/user commands).
– ETF COMMAND INTERFACE inherits ETF TYPE CONSTRAINTS (in cluster generated code/abstract ui/user commands). That is, ETF MOVE is a descendant class of ETF TYPE CONSTRAINTS and inherits all its features, including:
feature — constants for enumerated items A: INTEGER =1
D: INTEGER =2
C: INTEGER =3
J: INTEGER =4 F: INTEGER =5 E: INTEGER =6 B: INTEGER =7 G: INTEGER =8 I: INTEGER =9 H: INTEGER =10
8
Consequently, in the context of ETF MOVE, you can write:
class ETF_MOVE …
move(row: INTEGER_32 ; column: INTEGER_32) …
do
if row = A then …
elseif row = B then …
…
model.some_fun(A)
…
etf_cmd_container.on_change.notify ([Current])
end end
Notice that the ETF TYPE CONSTRAINTS class also shows how the enumerated type is implemented, by mapping each member to a unique integers: enum items: HASH TABLE[INTEGER, STRING]. However, you should not use this table to retrieve the “magic number” of each enumerated number (e.g., enum items[“A”]). Instead, just reference the member name like shown above.
8.4 Outputting the Abstract State
The information below constitutes the abstract state of your tool. The term “abstract” here suggests that we show only the relevant information to users, by filtering out all other (implementation-related) details of your software. For output, each indentation level consists of two white spaces.
Consider the following scenario, where the user invoked the pass command, but in Part 1 of the turn, some projectile collides with the Starfighter in location [B,6]. Consequently, Part 2 of the turn is skipped and the game is over.
->pass
state:8.0, ok
A projectile moves: [C,7] -> [C,8]
A projectile moves and collides with the Starfighter: [B,5] -> [B,6]
1 2 3 4 5 6 7 8 9 10 A__________ B_____X____ C_______*__ D__________ E__________
The game is over. Better luck next time!
1. Every line in each abstract state is indented by two spaces. The initial state displays only a welcome message (i.e., Welcome to Space Defender Version 1.), whereas each of the subsequent states has its first line displaying a state number (e.g., state:8.0) and whether the command used caused an error or not (e.g., ok).
A state number consists of two integers separated by a decimal point (.). The game starts at state number 0.0.
– Every invalid invocation of a command (triggering an error message) increments the second number by 1
and also outputs the fact the current state is in error.
– Every valid command increments the first number by 1, resets the second number to 0, and also outputs
the fact the current state is ok.
2. The next line depends on whether an error occurred or not, and whether the user is in game:
– If a valid command is used and the user is in a game, the output displays what happened in the turn:
• As specified in Section 8.2, a turn starts by projectile movements, so the output list all the projectile movements that occurred during that turn.
• The output indicates what happens in Part 1 of the turn:
⋄ If the Starfighter is destroyed by a projectile, then the output displays a game over message accord-
ingly; there will be no messages for Part 2 of the turn. 9
⋄ Otherwise, if the Starfighter is still alive, then the output displays what happened to it in Part 2 of the turn based on the command used.
• The output indicates what happens in Part 2 of the turn (if the Starfighter was not destroyed in Part 1): If the Starfighter gets destroyed after executing the command specified by the user, the output displays a game over message.
• After displaying messages regarding what happened during the turn, an ASCII representation of the board should be displayed:
⋄ The first line starts with two spaces for indentation, followed by column numbers. The pattern for displaying each column number is d (e.g., 5) or dd ( 23) where is an empty space and d is a numeric digit (starting from 1).
⋄ Each of the subsequent lines:
· Starts with two spaces for indentation
· Followed by the row alphabet (e.g., C) and a space
· The rest of the line represents contents of columns. Except for the last column, each column
starts with the content of the grid (i.e., , S, *, X), followed by two spaces. The last column displays the content of the grid without any trailing spaces.
– Otherwise, if either an error occurs or the user is not in a game (for example, the user invokes abort), a message is displayed explaining what happened.
3. When the undo command is invoked during a game, it goes backwards to the last valid state, if applicable. Similarly, when the redo command is invoked during a game, it goes forwards to the next valid state, if applicable.
For examples, invoking undo on state 5.3 brings the current game back to state 4.0, whereas invoking redo on state 5.3 brings the current game forwards to 6.0 (assuming that state 6.0 exists).
8.5 Messages
Here is the list of messages that may appear during normal operation of the game:
1. (Initial message):
“Welcome to Space Defender Version 1.”
2. (Abort message):
“Game has been exited.”
3. (Movement of Starfighter: origin to destination.) “The Starfighter moves: [r1,c1] -> [r2,c2]”
4. (Movement of Starfighter: collision.)
“The Starfighter moves and collides with a projectile: [r1,c1] -> [r2,c2]”
5. ([r,c] is the location of the Starfighter when it fires a projectile.) “The Starfighter fires a projectile at: [r,c]”
6. ([r,c] is the location of the Starfighter when a pass command is used.) “The Starfighter stays at: [r,c]”
7. (Movement of a projectile, origin to destination, where only [r2,c2] can be “out of the board”, meaning that once the projectile goes beyond the confines of the grid, it is not included in the abstract state.)
“A projectile moves: [r1,c1] -> [r2,c2]”
8. (Movement of a projectile, original to destination, where [r2,c2] is where the collision occurred inside the grid.)
“A projectile moves and collides with the Starfighter: [r1,c1] -> [r2,c2]”
9. (Game over due to Starfighter being destroyed.)
“The game is over. Better luck next time!”
10
8.6 Errors
Here is the list of error messages which can be triggered by different commands. For each command, the list also suggests the priorities (from the highest to the lowest) with which the appropriate error message should be produced (i.e., only one message can be produced at a time).
1. The abort command
– (Game needs to be started before the command can be used.)
“Not in game.” 2. The fire command
– (Game needs to be started before the command can be used.)
“Not in game.” 3. The move command
– (Game needs to be started before the command can be used.)
“Not in game.”
– (Location to move to is outside of specified board size.)
“The location to move to is outside of the board.”
– (Location to move to is outside of the specified Starfighter’s movement range.)
“The location to move to is out of the Starfighter’s movement range.”
– (Location to move to is where the Starfighter is already at.)
“The Starfighter is already at that location.” 4. The pass command
– (Game needs to be started before the command can be used.)
“Not in game.” 5. The play command
– (The command can only be used before the game has started.)
“Please end the current game before starting a new one.”
– (Movement parameter for the Starfighter is too large based on board size.)
“Starfighter movement should not exceed row – 1 + column – 1 size of the board.” 6. The redo command
– (Game needs to be started before the command can be used.)
“Not in game.”
– No further commands in the history to redo.
“Nothing left to redo.” 7. The undo command
– (Game needs to be started before the command can be used.)
“Not in game.”
– No further commands in the history to undo.
“Nothing left to undo.”
11
8.7 Getting Started
– First of all, make sure you have already acquired the basic knowledge about the Eiffel Testing Framework (ETF) as detailed in Section 5.
– Download the system space defender 1.zip file from the course eClass page and unzip it.
– Follow this tutorial video to get started from the downloaded starter file:
https://www.youtube.com/watch?v=Do_dpN66Jtk&list=PL5dxAmCmjv_5q9wBFXV- M4S4VbB1T0EJg&index=8
– The text file space_defender_1.grammar.txt is for you to generate the ETF project for your tool application.
– The input files (e.g., at01.txt, at02.txt, etc.) are example use cases for you to test your software. The corresponding expected output files (e.g., at01.expected.txt, at02.expected.txt, etc.) contain outputs that your software must produce to match.
– You are advised to, before start coding, study the given expected output files carefully, in order to obtain certain reasonable sense of how your tool is supposed to behave.
All your development will go into this downloaded directory, and when you make the submission, you must submit this directory. To begin your development, follow these steps:
1. Open a new command-line terminal. Change the current directory into this downloaded directory, type the following command to generate the ETF project:
Notice that there is a dot (.) at the end to denote the current directory.
2. There are two space defender 1 directories: one is the top-level directory that contains all generated ETF code and your development; the other is the sub-directory that contains the code of your model of tool. When you submit, make sure that you submit the top-level space defender 1 directory.
3. Open the generated project in Eiffel Studio by typing:
4. Once the generated project compiles successfully in Eiffel Studio, go to the ROOT class in the root cluster. Change the implementation of the switch feature as:
This overrides the default GUI mode of the generated ETF. To make it take effect, re-compile the project in Eiffel Studio.
5. Switch back to the terminal and type the following command:
Then you should see this output (rather than launching the default GUI of ETF): 12
etf -new space_defender_1.grammar.txt .
estudio19.05 space_defender_1.ecf &
switch: INTEGER
— Running mode of ETF application
do
— Result := etf_gui_show_history — GUI mode
Result := etf_cl_show_history
— Result := unit_test — Unit Testing mode
end
EIFGENs/space_defender_1/W_code/space_defender_1
Error: a mode is not specified
Run ’EIFGENs/space_defender_1/W_code/space_defender_1 -help’ to see more details
6. As you develop your ETF project for the space defender, launch the batch mode of the executable. For example:
This prints the output to the terminal. To redirect the output to a file, type:
The at01.actual.txt file stores the actual output from your current software, and your goal is to make sure that at01.actual.txt is identical to at01.expected.txt by typing:
or typing:
Of course, the actual output file produced by the default project is far from being identical to the expected output file.
7. You should first aim to have your software produce outputs that are identical to those of the expected output files (i.e., at01.expected.txt, at02.expected.txt, etc.).
8. Then, as you develop further for your ETF project, create as many acceptance test files of your own as possible. Examine the outputs and make sure that they are consistent with the requirements as stated in this document.
9. You are already given an oracle program for you to test if your software and the oracle produce identical outputs on all of your acceptance test files.
8.8 Modification of the Cluster Structure
You must not change signatures of any of the classes or features that are generated by the ETF tool (the only exception is the ETF MODEL and ETF MODEL CLASS in the model cluster, for which you may make any modifications). You may only add your own clusters or classes within model cluster as you consider necessary. However, when you add a new cluster, it is absolutely critical for you to make sure that a relative path (i.e., a path that is relative to the current project directory . and does not start with /) is specified to add that cluster in the project setting. Specifying an absolute path in your project will make your submitted project fail to compile when being graded, and this will result in an immediate zero for your marks with no excuses. So please, make sure you pay extra attention to all clusters that you add to the project.
EIFGENs/space_defender_1/W_code/space_defender_1 -b at01.txt
EIFGENs/space_defender_1/W_code/space_defender_1 -b at01.txt > at01.actual.txt
diff at01.expected.txt at01.actual.txt
meld at01.expected.txt at01.actual.txt
13
9 Task 4 of Lab3: Design Document
Complete and submit the following two parts: 1. Design Diagram
– Using draw.io, draw a design diagram which includes:
• The separation between the user commands and model clusters, e.g., slide 18 of Lecture 6
• The detailed architecture of your implemented design in the model cluster, which must include:
⋄ subclusters/classes related to the undo/redo design pattern
⋄ all other classes of your design
• In the model cluster, at least one of the classes (except the singleton access class, e.g., ETF MODEL ACCESS)
should be shown in the detailed view with proper routines, comments, and contracts.
– Include both:
• The diagram source file EECS3311 lab3 bon.drawio
• Its exported PDF file EECS3311 lab3 bon.pdf in the docs directory of your lab project.
– Refer to Requirements 1, 2, and 3 in your Lab2 instructions.
– Page Limit: 1 page
2. Design Decisions
Answer the following two questions (with explicit headings):
– How is the undo/redo design pattern implemented in the model cluster?
– How are polymorphism and dynamic binding realized in your design at compile time and runtime?
• Polymorphism refers to: 1) at compile time, a variable x is assignable to another variable y, if y’s static (declared) type is a descendant class of x’s static type; and 2) at runtime, a variable may be attached to (i.e., stores the address of) objects of different types.
• Dynamic binding refers to when executing a routine call x.r(. . . ) at runtime, the version of routine r invoked depends on the dynamic type of variable x (i.e., what type of object x is attached to).
– Include this one-page document EECS3311 lab3 report.pdf in the docs directory of your lab project. – Page Limit: 1 page
14
10 Submission
10.1 Checklist before Submission
1. Make sure the ROOT class in the root cluster has its switch feature defined as:
switch: INTEGER
— Running mode of ETF application
do
— Result := etf_gui_show_history. — GUI mode
Result := etf_cl_show_history
— Result := unit_test — Unit Testing mode
end
2. Make sure that the docs folder contains:
– The diagram source file: EECS3311 lab3 bon.drawio
– The one-page exported PDF file: EECS3311 lab3 bon.pdf
– The one-page document of design decisions: EECS3311 lab3 report.pdf
10.2 Submitting Your Work – Electronic Submission
1. You are expected to submit from a Prism lab terminal.
2. Produced outputs by your program must be identical to those produced by the oracle. You are responsible for testing enough input cases with the oracle give to you.
3. There are two space_defender_1 directories: one is the top-level directory that contains all generated ETF code and your development; the other is the sub-directory that contains the code of your model of space defender. When you submit, make sure you submit the top-level space defender 1 directory.
to the directory containing the top-level space defender 1 project directory:
4. Go
4.1 Run the following command to remove the EIFGENs directory:
eclean space_defender_1
4.2 Run the following command to make your submission:
• Here is a short tutorial video guiding you the process of submitting your labs/project from home (It is just an example for Lab0, and you would need to adapt it to Lab3).
• Submissions via Web Submit or email attachments are unacceptable and will not be graded.
• After you submit, there will be some automated program attempting to perform some basic checks on your program: if your submitted directory has the expected structure, if Eiffel project compiles, and
etc. Please be patient and wait until it finishes.
• You are encouraged to submit multiple times before the deadline (this also allows you to backup your work on the EECS server). Only the latest submission before the deadline will be graded.
• You may check the last submission status at any time:
• You may save the check result for later review:
submit 3311 Lab3 space_defender_1
feedback 3311 Lab3
15
feedback 3311 Lab3 > Lab3-check-result.txt
Note. You will receive zero for submitting a project that cannot be compiled.
16
11 Questions
There might be unclarity, typos, or even errors in this document. It is your responsibility to bring them up, early enough, for discussion. Questions related to the project requirements are expected to be posted on the on-line course forum. It is also your responsibility to frequently check the forum for any clarifications/changes on the project requirements.
12 Amendments
– Section 8.5, item 7. Changed from:
• (Movement of a projectile, origin to destination, where both [r1,c1] and [r2,c2] can be “out of the
board” if the projectile goes beyond the confines of the grid.) “A projectile moves: [r1,c1] -> [r2,c2]”
to
• (Movement of a projectile, origin to destination, where only [r2,c2] can be “out of the board”, meaning that once the projectile goes beyond the confines of the grid, it is not included in the abstract state.)
“A projectile moves: [r1,c1] -> [r2,c2]”
17