联系方式

  • QQ:99515681
  • 邮箱:99515681@qq.com
  • 工作时间:8:00-23:00
  • 微信:codehelp

您当前位置:首页 >> C/C++程序C/C++程序

日期:2020-10-15 09:17

EECS3311 Fall 2020
Lab Exercise 2
Implementing and Specifying a Database
Released Date: Monday, September 28
Due Date (Sections A & E): 11:59pm (EST), Sunday, October 11
– Check the Amendments section of this document regularly
for changes, fixes, and clarifications.
– Ask questions on the course forum on the eClass site for Sections A and E.
Never share code on the course forum.
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 Learning Outcomes of this Lab Exercise 3
2 Background Readings 3
3 (Optional) Tutorials on the Iterator Design Pattern 3
4 Important Syntax for this Lab: Relation, Hash Table, Tuples 3
5 Lab1 Solution & Grading Tests 4
6 Problem 4
6.1 The DATABASE ADT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2 Design Decision: Abstraction Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.3 Design Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4 Implementing the Iterator Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Task 1: Developing Software 8
7.1 Work Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2 What if You Get Stuck? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3 How to Read the Given Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8 Grading Scheme (for Software) 10
9 Task 2: Drawing a Design Diagram 11
9.1 What Classes to Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.3 Requirement 1: Page Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.4 Requirement 2: Diagram Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.5 Requirement 3 Using draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10 Submission 15
10.1 Checklist before Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2 How to Submit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11 Amendments 17
2
1 Learning Outcomes of this Lab Exercise
1. Implement functionalities of a database which has alternative implementations: a balanced binary search tree
vs. linear data structures
2. Specify contracts (preconditions and postconditions) for the implemented functionalities.
3. Apply the Iterator Pattern.
4. Define a Generic Class.
5. Draw professional architectural diagram using the draw.io tool.
6. Practice Test-Driven Development (TDD):
– Write unit tests (using the ESpec library) as soon as a unit of functionality becomes executable.
– Accumulate a suite of test classes (each of which containing test cases) for regression testing.
– Use the debugging tool in EStudio IDE when failing tests.
– Add more test until all the normal scenarios (where actual outputs of your programs match the expected
outputs) and the abnormal scenarios (where contract violations are expected) are tested in your developed
test suite.
2 Background Readings
– Introductory tutorial videos from Lab0:
https://www.youtube.com/playlist?list=PL5dxAmCmjv_4bxISJrwPoBrzVdCfVgVnN
– Lecture Materials (and relevant parts of the lecture recordings) on:
? Writing Complete Postconditions
? Abstractions via Mathematical Models
? Drawing a Design Diagram
? Case Study: Abstraction of a Birthday Book
? Design Pattern: Iterator
3 (Optional) Tutorials on the Iterator Design Pattern
Here we provide optional tutorials on hands-on practices of the iterator design pattern which you may review before
starting your development:
– Tutorial Videos on Generic Parameters and the Iterator Pattern:
https://www.eecs.yorku.ca/?jackie/teaching/tutorials/index.html#generic_parameter
– Tutorial Videos on Information Hiding and the Iterator Pattern
https://www.eecs.yorku.ca/?jackie/teaching/tutorials/index.html#information_hiding
– Tutorial on Making a Birthday Book (implemented using HASH TABLE) ITERABLE
4 Important Syntax for this Lab: Relation, Hash Table, Tuples
Two tests demonstrating these constructs are included in the STARTER TESTS:
– test hash table retrieval
– test relation and tuples
3
5 Lab1 Solution & Grading Tests
– The trees cluster in your starter project contains starter version of the three classes which you were given in
Lab1: BALANCED BST, TREE NODE, and SPLAY TREE.
– Feel free to replace these three classes by the submitted version of your Lab1.
– Or, alternatively, by the end of the first week after Lab2 is released, we will distribute solution and grading tests
of Lab1, in which case you may choose to either 1) use the solution version for these tree classes; or 2) use a
fixed version of your Lab1 submission (using the grading tests) when you submit your Lab2.
Note. We cannot release the solution and grading tests right away because some of your fellow students were
legitimately granted with extension on Lab1.
6 Problem
6.1 The DATABASE ADT
– The DATABASE ADT supports the storage and retrieval of a collection of entries. Each entry consists a data value
and a search key (which may be of different types). Each search key uniquely identifies a data value.
– A client of the DATABASE ADT is expected to instantiate types of the search keys and their associated data
values. For example, the declaration db: DATABASE[STRING, DATE] intends to have a birthday book, where
each entry consists of a person’s string name and their birthday date.
– Recall the design principle you learned in Lab0: Program from the Interface, Not from the Implementation.
In this lab exercise, we will explore this design principle in more depth:
1. The DATABASE class is deferred, meaning that the class is only partially implemented (with at least one
routine unimplemented(deferred)) and the class cannot instantiated directly. For example, by declaring a
variable with the static type DATABASE:
db: DATABASE[STRING, DATE]
It is forbidden to use DATABASE also as a dynamic type, as not all routines have their implementations ready:
create {DATABASE[STRING, DATE]} db.make
2. We consider two alternative implementations of a database:
2.1 A TREE DB implements the database via a client-supplier relation with the BALANCED BST (which is a
deferred class with an effective descendant class SPLAY TREE). That is, in the context of TREE DB all
database operations are defined in terms of BALANCED BST features.
2.2 A LINEAR DB implements the database via the following implementation strategy, where there are two
linear data structures:
? An array storing the search keys
? A hash table mapping keys to their associated values
For example:
keys ?→ "Suyeon" "Yuna"
values ?→ Key Value
"Suyeon" 2013-8-31
"Yuna" 2016-6-20
Each item in the names array can be used to identify a value stored in the values table. In the above
example, the data value 2013-8-31 can be identified by names[1].
Remark. One may argue that the keys array is redundant, as its content is equivalent to the set of
search keys of the values hash table. The main purpose of this redundancy is for you to practice the
combined use of the two data structures, while ensuring that their stored items are consistent.
Q. How can we ensure the consistency between names and values?
A. Consistency constraints are specified as a class invariant of the DATABASE class:
4
key_data_pair_count_same:
keys.count = values.count
all_key_exists_in_data:
across keys is i_key
all
values.has_key (i_key)
end
6.2 Design Decision: Abstraction Function
In order to satisfy the Information Hiding and Single-Choice design principles, we will use the following abstraction
function to write contracts for database routines:
model: REL[K, V]
– It is important for you to explore the various commands and queries in the REL class (part of the mathmodels
library).
– Understand that:
? At the implementation level, given a search key, we can retrieve either void (if the key does not exist) or a
value object.
? At the abstract relation level, we formulate each search using the relational image operation: given a
search key, we can retrieve either an empty set (if the key is not a member of the relation’s domain) or a
singleton set (if the key is a valid domain value).
5
6.3 Design Architecture
The following fragments (with omissions of details) present the most important design architecture for this lab exercise:
deferred class DATABASE[K -> COMPARABLE, V]
. . .
feature -- Abstraction Function
model: REL[K, V]
deferred
ensure
. . . -- other postcondition omitted
all_model_pairs_exist_as_key_value_tuples: . . .
end
feature -- Deferred Routines
insert(p_key: K; p_value: V)
require
no_previous_entry: . . .
deferred
ensure
entry_added: . . .
end
. . . -- other deferred routines omitted
feature -- Basic, Intermediate, Advanced
override(p_key: K; p_value: V)
do
. . .
Current.insert(p, k) -- for illustration only
. . .
ensure
overriden_result: . . .
end
. . . -- other effective routines omitted
end
class TREE_DB[K -> COMPARABLE, V]
inherit DATABASE[K, V]
. . .
feature {ES_TEST} -- Restricted Attributes
bst: BALANCED_BST[K, V]
feature -- Abstraction Function
model: REL[K, V]
do
. . .
-- postcondition inherited from {DATABASE}.model
end
feature -- Implemented Routines from DATABASE
insert(p_key: K; p_value: V)
-- precondition inherited from {DATABASE}.insert
do
. . .
-- postcondition inherited from {DATABASE}.insert
end
-- basic, intermediate, advanced features from DATABASE
-- are all inherited verbatim without being redefined.
end
class LINEAR_DB[K -> {COMPARABLE, HASHABLE}, V]
inherit DATABASE[K, V]
. . .
feature {ES_TEST} -- Restricted Attributes
keys: ARRAY[K]
values: HASH_TABLE[V, K]
feature -- Abstraction Function
model: REL[K, V]
do
. . .
-- postcondition inherited from {DATABASE}.model
end
feature -- Implemented Routines from DATABASE
insert(p_key: K; p_value: V)
-- precondition inherited from {DATABASE}.insert
do
. . .
-- postcondition inherited from {DATABASE}.insert
end
-- basic, intermediate, advanced features from DATABASE
-- are all inherited verbatim without being redefined.
end
1. The class DATABASE is deferred (partially implemented) and has two effective (fully implemented) descendant
classes TREE DB and LINEAR DB:
2. In class DATABASE:
(2a) Deferred routines in the two feature sections Abstraction Function (i.e., model) and Deferred Routines
(e.g., insert) have their implementations deferred to the two descendant classes.
(2b) Think of routines under the Deferred Routines section as basic building blocks that can be reused to
build the more sophisticated routines in the Basic, Intermediate, and Advanced sections.
(2c) Effective routines in the Basic, Intermediate, and Advanced feature sections (e.g., override) are implemented
at this level of the parent class DATABASE (and they are not redefined in the descendants).
Q. How do you implement these routines?
A. Knowing that we are not allowed to access the restricted attributes in its descendants (i.e., bst in
TREE DB, keys; and values in LINEAR DB):
6
– We can only call routines which are declared at this level (e.g., model, insert, override).
– That is, we implement these routines by referring to those routines in the Deferred Routines section
(which are basic building blocks), assuming that these deferred routines will be implemented in the
effective descendants TREE DB and LINEAR DB.
– Also, given that you will ultimately implement the DATABASE class (and its two effective descendants)
as iterable, you may also consider writing something like:
across Current is t -- Current database is iterable
loop
-- use of tuple ‘t‘ here
end
(2d) All (deferred and effective) routine contracts (pre- and post-conditions) are specified at the level of the parent
class DATABASE, so that they are inherited verbatim to the two effective descendants without duplicates
(satisfying the single-choice design principle).
Q. How do you specify these routine contracts?
A. Knowing that DATABASE cannot be used as a dynamic type, and assuming that all deferred routines in
this class will be implemented in both descendants TREE DB and LINEAR DB:
– For the postcondition of model, you may use any of the deferred queries (e.g., search, has key).
– For the pre- and post-postcondition of other routines, you may refer to the model query or, similarly,
any of the deferred queries.
3. What happens at runtime?
(3a) Say we declare and create two variables:
t db, l db: DATABASE[STRING, DATE]
Consequently, both t db and l db has the same static type being the deferred class DATABASE.
(3b) And say we instantiate the two variables as follows:
create {TREE DB[STRING, DATE]} t db.make
create {LINEAR DB[STRING, DATE]} l db.make
Consequently, variable t db has its dynamic type being the effective class TREE DB and variable l db has
its dynamic type being the effective class LINEAR DB.
(3c) Q. What happens when we make the following two calls?
t db.model
l db.model
A. According to (2a) and the principle of dynamic binding :
– The call t db.model invokes the version of model implementation in TREE DB (meaning that a mathematical
relation is produced from the underlying splay tree).
– The call l db.model invokes the version of model implementation in LINEAR DB (meaning that a mathematical
relation is produced from the underlying array and hash table).
– However, upon the termination of each implementation, according to (2d), the same postconditions
inherited from {DATABASE}.model are checked.
(3d) Q. What happens when we call routines from the Implemented Routines from DATABASE section? e.g.,
t db.insert("Suyeon", 2013-8-31)
l db.insert("Yuna", 2016-6-20)
A. According to (2a) and the principle of dynamic binding :
– The call t db.insert(. . . ) invokes the version of insert implementation in TREE DB (meaning that an
insertion into the underlying splay tree occurs).
– The call l db.insert(. . . ) invokes the version of insert implementation in LINEAR DB (meaning that
an insertions into the underlying array and hash table occur).
– However, upon the termination of each implementation, according to (2d), the same postconditions
inherited from {DATABASE}.model are checked.
7
(3e) Q. What happens when we call routines from the Basic, Intermediate, or Advanced section? e.g.,
t db.override("Suyeon", 2013-10-15)
l db.override("Yuna", 2016-8-13)
A.
– According to (2c) and the principle of dynamic binding , both calls t db.override(. . . ) and l db.override(. . . )
invoke the only version of override implementation in class DATABASE.
– According to (2b), each of these routines is built on top of the deferred routines (which are implemented
in the two effective descendants). For the purpose of illustration, say the override routine makes use
of the insert routine:
deferred class DATABASE
. . .
override(p_key: K; p_value: V)
do
. . .
Current.insert(p, k) -- for illustration only
. . .
ensure
overriden_result: . . .
end
. . .
end
Consequently, the call of t db.override(. . . ) replaces the Current object by t db, boiling down to
t db.insert(. . . ) on the underlying splay tree. Similarly, the call of l db.override(. . . ) replaces the
Current object by l db, boiling down to l db.insert(. . . ) on the underlying array and hash table.
– Again, upon the termination of each implementation, according to (2d), the same postconditions inherited
from {DATABASE}.override is checked.
6.4 Implementing the Iterator Design Pattern
From a public client’s point of view, the two iteration cursor classes (i.e., TREE IT for TREE DB and LINEAR IT for
LINEAR DB) allows them to retrieve one entry at a time. However, there is a subtle difference which you must account
for when implementing these two cursor classes:
– The TREE IT returns entries in a descending order: from the entry with the largest key to the entry with the
smallest key.
– The LINEAR IT works like a LIFO stack: the order in which entries are retrieved corresponds to the reverse
chronological order in which they were inserted into the database. For example, say we insert entries in this
order: e1, e2, e3; then, when we retrieve them, it should be: e3, e2, e1.
7 Task 1: Developing Software
7.1 Work Sequence
1. Download the starter code (database.zip) from the course eClass.
2. Unzip and compile the project in EStudio.
3. Start by running the Workbench System (Run, then Run Workbench System), and you will see the initial results
of running all starter tests:
8
4. We suggest the following workflow on completing this lab:
4.1 Finish all implementation of deferred features in the class LINEAR DB.
4.2 Implement model feature in LINEAR DB.
4.3 Implement model feature in TREE DB.
4.4 Finish all postconditions of deferred features in DATABASE.
4.5 Make DATABASE iterable by uncommenting the inherit clause.
4.6 Also make TREE DB and LINEAR DB iterable by uncommenting Iteration Cursor block.
4.7 Implement TREE IT and LINEAR IT so TREE DB and LINEAR DB are iterable.
4.8 Uncomment the two iterator tests and add iterator tests in make in STARTER TEST to run iterator tests.
4.9 Finish all postconditions of model in DATABASE.
4.10 Implement Basic, Intermediate, and Advanced features in DATABASE.
4.11 Finish all postconditions of Basic, Intermediate, and Advanced features in DATABASE.
7.2 What if You Get Stuck?
When you are not sure about how a database feature should be implemented or specified, always consult with:
– Section 3
– Section 6
– Given test cases in STARTER TESTS
All Boolean test queries given to you should be treated as a precise documentation on how the features under
development are expected to be used. You are expected to study them in order to have a clearer idea for your
development.
– Comments for the feature
– Hints for the TODO
9
7.3 How to Read the Given Tests
Tests included in class STARTER TESTS cover all to-do features in class DATABASE and thus TREE DB and LINEAR DB.
– Tests in STARTER TESTS are grouped by features to test. To read about tests related a particular feature, there
are two ways for you to easily find them. For example, if you want to look up tests for {DATABASE}.insert:
(Approach 1) Recall how we find ancestors of the ARRAY class in the introductory tutorial (Video 2)? By
right-click drag-and-drop the insert feature into the Feature panel, you can choose to show its callers.
(Approach 2) Simply search for the string "insert" in STARTER TESTS.
– The deferred/abstract class TEST ENVIRONMENT defines commands for setting up databse data for testing: reset as tree db,
reset as linear db, and env int int. These setup commmands are inherited to the STARTER TEST class, and
they exist to make re-usable the setup procedure of the same database data. You may also reuse these setup
commands when creating your own test cases, or you can just create your setup commands.
– Tests in the STARTER TEST class are named systematically:
? The name of each test feature has the prefix of dbt indicating it is a DATABASE test.
? What follows the name prefix, dbt, indicates the feature being tested. For example, dbt insert1 represents
test # 1 for {DATABASE}.insert.
? All the local variables are prefixed with l .
? All the attached variables are prefixed with a .
? All the iteration variables in across notation are prefixed with i .
– Tests in the STARTER TEST class only covers some of the cases of implementation.
– It is highly recommended that you create postcondition tests yourself to test the postconditions.
8 Grading Scheme (for Software)
In this lab, there are two submission categories we are going to grade you: Software Project (3%) and Diagram (2%).
In this Section we describe how the software part of your Lab2 will be graded. See Section 9 for the requirements on
the design diagram.
When we grade you submission, a set of test cases are run automatically on your submitted project (given a large
number of submissions we receive). Consequently, there are two common reasons for your submission receiving a zero
for this lab (and in fact, for all subsequent labs and the project):
– When your submitted project does not compile (in which case it is not even possible to run test cases on your
submitted software).
– When your submitted project compiles, but it passes none of the grading tests (e.g., incorrect implementation,
infinite loops, infinite recursions).
That is, if your submitted code compiles, then the more test cases it passes, the higher marks you will receive. More
precisely, we divide all test cases into two non-overlapping categories:
1. Starter
10
– The STARTER TESTS class given to you corresponds to all tests in the starter category.
– You must implement the following correctly in order to pass all starter tests:
? All TODO features from the LINEAR DB class
? All TODO features from the TREE DB class
? All TODO features from the DATABASE class
? Inheritance from ITERABLE in DATABASE, and the correct implementations of the two iteration cursor
classes TREE IT and LINEAR IT
2. Grading
– The GRADING TESTS class is not given to you.
– GRADING TESTS class tests all the contracts you should have written as well as corner implementation cases
of the the following features:
? All TODO features from the DATABASE class.
The following table summarizes the distribution of percentage weight of each test category:
Test Category Summed Weight of this Category
Grading 50%
Starter 50%
9 Task 2: Drawing a Design Diagram
For the purpose of this lab, you are required to draw a digram that summarizes your design: a view from the clients
that see contracts of routines and relations between classes, whereas all implementation details are hidden.
9.1 What Classes to Include
Your diagram must include all clusters and classes from the database project:
– Cluster database: DATATASE, TREE DB, LINEAR DB
? All these three classes in this cluster must be shown in the detailed view. The detailed view of each class
should include the following features (when applicable) and their contracts:
 Abstraction function (model query)
 Routine insert from the Deferred Routines section
 Routines interval image (from the intermediate section) and inner join (from the advanced section)
Note 1. Where contracts are inherited, you do not need to repeat them, e.g., model of TREE DB does
not include the postcondition inherited from model of DATABASE.
Note 2. For the model query, you must show a client-supplier relation between REL and DATABASE.
? For TREE DB, you must include the client-supplier relation via bst.
? For LINEAR DB, you must include the client-supplier relations via keys and values, both with an emphasis
of the data structure (i.e., ARRAY and HASH TABLE).
Classes in all clusters below should only be shown in the compact view.
– Cluster trees: BALANCED BST, TREE NODE, SPLAY TREE. You must show the proper client-suppler and inheritance
relations among these three classes.
– Cluster iterators: TREE IT, LINEAR IT
– Classes related to the iterator pattern: ITERABLE, ITERATION CURSOR
– Cluster tests: STARTER TESTS only. You are only required to show a client-supplier from STARTER TESTS to
DATABASE.
11
9.2 Contracts
– You do not need to show all contracts. Show the more sophisticated ones (e.g., ones involving logical quantifiers).
– Do not use the across syntax; instead, use their logical counterparts ? or ?. That is, when there is a logical
correspondence for the Eiffel operator you use (e.g., ∧ for and), always use the logical operator in your diagram
for neatness and precision.
– Here is an example of showing a (partial) contract view of an array-based container (your submitted diagram
will be graded using this as the standard):
– Make sure that:
? A tag, if any, should be included for the corresponding contract.
? For quantifications, we simply use two colons (:) to separate parts, rather than | and ? as in math. This
makes it easier for you to draw.
9.3 Requirement 1: Page Limit
You are only allowed one page for your design diagram.
9.4 Requirement 2: Diagram Syntax
Your diagram syntax must conform to what is covered in the lecture: see here.
9.5 Requirement 3 Using draw.io
To prepare your design diagram, you must use the program and library template (which can be found in the docs
folder of your starter project) as instructed below:
– Download a library template EECS3311 BON Library.xml from the course eClass page and save it to the desktop.
– Launch your web browser and go to draw.io.
– Choose Create New Diagram.
12
– Enter EECS3311 lab2 bon.drawio in the Filename text box, then click on Create to create a blank diagram.
Later on, every time you make a change and need to save, you will need to browse to the same
location to overwrite the existing, old version.
– Now we import the library template (located in the docs folder of your starter project): File, then Import
from, then Device, then browse to the xml library file and open.
13
– Now you should see on the left panel a section called EECS3311 BON Library.xml.
Browse through the list of items that you may use. Hovering your mouse over an item in the library will pop up
a description of what it represents. For this lab, you will need: e.g., the detailed and compact views of classes,
relevant math symbols.
Tips: When writing a mathematical formula in your diagram, you may find it the easiest to: 1) click on the
symbol you need (then a separate text box will pop up); and 2) cut and paste the symbol to where you need in
your formula.
– Once you are happy with your diagram source file (which is a drawio file), make sure you save it. Then, go to
File, then Export as, and then PDF.
– Then tick the Crop box then Export.
14
– Enter EECS3311 lab2 bon.pdf in the Filename text box, then click on Download to your desktop.
– Now move both
? The diagram source file EECS3311 lab2 bon.drawio
? Its exported PDF file EECS3311 lab2 bon.pdf
to the docs directory of your lab project.
10 Submission
10.1 Checklist before Submission
1. Complete all contracts and implementations indicated with “-- TODO” in the starter code.
2. Tests related to the iterator pattern are initially commented out in the starter tests.
Your submitted project must compile with these comments removed.
– Do not modify any tags of the contracts. Do not modify signatures (names and types) of existing features.
You may add auxiliary features to existing classes if necessary.
– You should exercise the test-driven development method that was taught.
– Write and pass as many tests as possible on your software, as only passing the given tests will not ensure
good quality of your development.
3. Use draw.io to draw a BON Architecture Diagram.
– When completing your drawing, also export the diagram into a PDF.
– Move the source of your draw.io drawing (name it EECS3311 lab2 bon.drawio) and its exported PDF
(name it EECS3311 lab2 bon.pdf) to the docs directory of your project.
10.2 How to Submit
To get ready to submit:
– Close EStudio
– Delete the EIFGENs directory from your project directory database.
– Please make sure the directory and project structures of your project are identical to following (with no EIFGENs):
15
By the due date, log into your account at the red server and submit via the following command:
submit 3311 Lab2 database
where database is your project directory for Lab2.
– 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 Lab2).
– 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:
feedback 3311 Lab2
– You may save the check result for later review:
feedback 3311 Lab2 > Lab2-check-result.txt
16
11 Amendments
List of changes, fixes, or clarifications will be added here.
– Changed the export status of attributes in LINEAR DB and TREE DB.
feature {ES TEST} → feature {ITERATION CURSOR, ES TEST}
17

版权所有:留学生编程辅导网 2021,All Rights Reserved 联系方式:QQ:99515681 电子信箱:99515681@qq.com
免责声明:本站部分内容从网络整理而来,只供参考!如有版权问题可联系本站删除。