代写ISAD1000、代做Java/Python程序设计

日期：2024-10-22 09:10

Introduction to Software Engineering (ISAD1000/5004)

Semester 2, 2024

Due: Friday 18 October, 23:59 GMT+8

Weight: 50% of the unit mark

Note

This document is subject to clari1 Introduction

This is the 2 The Scenario

Your task will be to process output from a maze-generating program in order to create a

smoother, more appealing output for terminal display. The maze-generating program has

already been created for you; your task is solely to modify the output. Currently, the program

generates a simple maze and displays the maze in a format made up only of ‘+’, ‘-‘ and ‘|’

characters. While this is suitable for simple display, it is not the most intuitive to read for a

human and your task is to improve on this using Box-Drawing Characters (which are discussed

in more detail in section 2.1).

As an example, here is the kind of input you can expect (on the left) and how your program

should output the maze (on the right):Note that the primary display for this will be on the terminal. You may 2.1 Maze Structure

The Wikipedia article, but you will only need a

small subset of characters for this assessment. A maze may be made up of the following

characters (and their associated codes):

■  Full lines:

▸  ┃ (U+2503)

▸  ━ (U+2501)

■  Half lines (i.e. for open ends of walls):

▸  ╸ (U+2578)

▸  ╻ (U+257B)

■  Corners:

▸  ┏ (U+250F)

▸  ┛ (U+251B)▸  ┓ (U+2513 - Only used for the outside, top-right border)

▸  ┗ (U+2517 - Only used for the outside, bottom-left border)

■  Intersections:

▸  ┻ (U+253B)

▸  ┣ (U+2523)

If you happen to be familiar with mazes, this might not seem like a complete set, as the lines

are ever only being drawn up and right. However, the algorithm for creating the maze will

never generate a case where other characters (such as ╋ or ┳) would be used. Only the

characters listed above will be used.

The maze is structured as a 2D array, where each ‘cell’ is either linked or not linked to one of

its neighbours. As an example, if the program were to generate a “maze” where each cell was

linked to every neighbour it would generate (and your expected output would be):

… if no cell were linked, the following maze would be generated (and your expected output

would be):In order to determine which is the appropriate character, you will need to inspect a cell in this

2D array and look at each of its neighbours.

A full horizontal line can be determined in the following case, because the corner character

(‘+’) has walls (‘-‘) on the left and right, but not up or down:

NoteHINT: It is suggested that you read from the source maze and write to an output maze:

do not overwrite the source maze, as you will lose/overwrite information that may be

valuable for both earlier and later cells.

2.2 Maze Generating Program

As part of this assessment, you will be provided with a simple program that generates output

as outlined above. You are encouraged to use this program to become familiar with the

output and to use cases generated by this program to assist in testing (but they are NOT

suRuby. You do not need to learn this

language to use the program. There are four source code ■  binary_tree_demo.rb

■  binary_tree.rb

■  grid.rb

■  cell.rb

To run the program, you use the following command on either the lab machines or VMWare

Horizon:

ruby -I. binary_tree_demo.rb

The program will output the maze to the terminal and exit. You may wish to save the output to

a ruby -I. binary_tree_demo.rb > maze_output.txt

(Any name can be specimaze_output.txt)

3 The Tasks

For this assignment, you will create documentation for, and be assessed on, these tasks:

■  Version Control

■  Modularity Design

■  Modularity Implementation

■  Test Design■  Test Implementation

■  Summary of Work

ALL these tasks will primarily be assessed through your documentation. All code that you

create will, however, need to also be submitted to verify your work has been done.

3.1 Version Control

As part of this assignment, you are to apply version control to keep track of your work.

■  Create a short plan, identify what branches you will need, why you need them, and

when the branches will be merged.

■  Create a Git local repository for use throughout this assessment. The repository name

should be in the format of __ISE_Repo

▸  e.g. Brower_Arlen12345678_ISE_Repo

■  Commit all code and documents you create in the assessment

▸  You are expected to use meaningful commits; while there is no hard rule about

what each commit should contain, you are expected to show your ability to use

version control meaningfully. Marks are not awarded for number of commits.

■  Include evidence of your use of version control, such as an image of the log

Any other discussion or explanation on your use of version control should also be included in

the documentation.

Warning

Do not use GitHub, BitBucket, or any other similar online repositories. Doing so runs the

risk of potential collusion investigations. Similarly, do not upload your code to online

repositories even after the assignment due date; other students may have extensions or

deferred assessments.

3.2 Modularity Design

With the given scenario, you are to identify the most suitable modules you will need for your

software to achieve the required functionality, considering the good modularity principles

discussed in lectures/worksheets. You are to:■  Write down module descriptions for each module you decide to implement.

Descriptions should include:

▸  A meaningful name

▸  A clear and detailed explanation on the intended task of the module

▸  Imports, if any

▸  Export, if any

■  Explain your design decisions and how they conform to good modularity principles

Note

It’s rare that you will get the design 100% ideal from the very start. Design is often

iterative. This is actually a very good, interesting thing to include in your documentation

for this assessment. If you 3.3 Modularity Implementation

You are to implement the software using your designs, review the code you have written, and

refactor it. As part of this task, you should:

■  Implement the modules designed in the previous section

▸  You may use Java or Python for your implementation

▸  Your code must run on the lab machines or VMWare Horizon

■  Create a short review checklist to determine if you have followed good modularity

principles. You are expected to cover all basic guidelines covered in lecture 7.

■  Review your code using the prepared checklist, identifying any issues. You must use the

format suggested in worksheet 7 to record your results. Each module must be

reviewed.

■  If you have identi▸  If you refactor your code, explain how it is improved;▸  If you do not refactor your code, justify your decision

■  After refactoring, revise your preliminary descriptions of your modules.

■  At every stage, you should be making changes and committing those changes to the

repo whenever you have made a step you are satis3.4 Test Design

You are to design tests using both black box and white box methodologies.

■  Black box test design:

▸  For each module, according to module descriptions, design suitable test cases.

▸  Describe how you decide upon your test values for each test case

▸  Test cases should each also describe their expected output or behaviour

■  White box test design:

▸  Identify at least two modules where white-box testing will be bene▸  Design test cases to cover functionality of the selected modules using white box

testing

▸  You must test at least two di▸  Describe how you decide upon your test values for each test case

▸  Again, be comitting these test cases to the repo as you write and are satis3.5 Test Implementation

Implement your test designs in either Python or Java. You may use test ■  Identify the actual results for each test case

■  Identify any failures, and attempt to improve your code

▸  Be sure to document this process, as it again makes for useful discussion for this

assessment3.6 Summary of Work

You are to produce a table clearly showing your overall module design and the ■  Each module should have one row

■  For each module, you should identify if the following work has been done:

▸  Whether or not the module is complete;

▸  Whether or not the module’s tests have been designed;

▸  Whether or not the module’s tests have been implemented;

▸  Whether or not the module’s tests are successful

Additionally, your submission must include a short video roughly two minutes in length

demonstrating that your code is working. More information on this video is included in section

5 of this document.

4 Documentation

As noted, your work will primarily be assessed through your documentation. All information

outlined above must be included in your documentation and your documentation must be

submitted to Turnitin as a .pdf ■  A cover page; include the assessment name, your name in Blackboard, your student ID,

and your practical date/time.

■  An introduction; brie■  Discussion; re▸  You may include other information if you feel it would be useful to clarify

anything about your submission

Additionally, marks are allocated for a neat and professional document.

5 Video DemonstrationYour submission must include a short, two minute video that demonstrates your code

working. As part of this video state your name and student number 6 Assessment Submission

You are to submit your assessment in three locations on Blackboard:

■  Declaration of Originality submission point

■  A Turnitin submission point

■  A general submission point

6.1 Declaration of Originality submission point

As part of this submission, you will submit a Declaration of Originality stating that this work is

your own, has not copied anyone else, and any sources are appropriately referenced. This

may be a .pdf, .odt, or .docx 6.2 Turnitin submission

Your Turnitin submission will only include the Documentation .pdf as outlined above. No

source code 6.3 General submission point

The general submission point should include all ■  Your documentation .pdf ■  A .zip (not .rar, not .7z, etc.) ▸  Note that your Git repository is NOT just your working directory (source ■  A single README ■  Your short 2 minute video demonstrating how to run the system and test cases

7 Marking

The allocation of marks for this assessment are as follows:

■  Test Design

Academic Integrity

Please see the Coding and Academic Integrity Guidelines on Blackboard.

■  Version Control [16 marks]

■  Modularity Design [7 marks]

■  Modularity Implementation [20 marks]

▸  Black Box [16 marks]

▸  White Box [9 marks]

■  Test Implementation [20 marks]

■  Summary of Work [5 marks]

■  Documentation-speciacademicintegrity.curtin.edu.au.

The unit coordinator may require you to provide an oral justi