CSCU9P6代写、Java程序语言调试、代写Mathematics、代做Java语言

日期：2020-03-11 10:42

? Computing Science and Mathematics

University of Stirling Page 1 of 11

University of Stirling

Computing Science and Mathematics

CSCU9P6 — Software Engineering II

Group project Spring 2020

For the purpose of this project each of you is required to operate as a member of a team. The

task of the team is to implement a working system in Java satisfying the object oriented design

described later in this document on page 7.

Lists of team members and monitoring officers, this description and project materials are on

Canvas and the Courses file server K:\CSCU9P6

The organization of the work is largely up to each team. However, for each team we will

appoint a project monitoring officer, and the team must meet with this officer at one project

meeting each of two separate weeks. The monitoring officer will attend for up to half an hour

(the group meeting might well continue for longer), and we appreciate that once the

implementation gets properly under way, shorter meetings may be appropriate with the

agreement of the monitoring officer. Attendance at these meetings is compulsory, and

non-attendance may result in No Mark being awarded for the course. You should give your

monitoring officer a brief, informal, progress report at the start of each meeting. Their normal

role will be to observe silently, in the background — they are not there to solve design

problems for you. If you wish to ask your monitoring officer for clarification of the problem,

then they may need to consult “higher authorities” for the expansion of details in the

requirements — a response will be provided as soon as possible, and, if appropriate, will be

disseminated publicly for the attention of all teams.

Sommerville’s and Pressman’s texts on software engineering provide guidance on organizing

teamwork. We recommend that each team appoints one of its members as project manager,

but this is up to you, and that you plan your work schedule using a Gantt chart. We also

recommend that, wherever possible, you think about and define very clearly the interfaces of

each Java class (the public operations offered) and work as individuals on separate classes (or

groups of classes).

Each group has been allocated a communal, shared folder on a Computing Science file server. If

your group number is nn ( 01, 02, etc) then your shared folder is in \\wsv\Groups\P6\nn.

Each member of the group has full access to all files created there; you might like to create a

subfolder per group member as a place to keep work but which is also accessible to other

members of the group if necessary (e.g. in case of illness).

Each group has also been allocated a Subversion repository on our server:

svn://svn.cs.stir.ac.uk/p6-nn where we recommend that you manage your central

versions of your project files. Each member of the group can checkout a copy of the project into

their own file space, or into personal sub-directories of the shared directory, regularly

committing any changes that they make, and synchronizing to fetch updates committed by other

members of the group.

Note: The best way for Eclipse/Together to access a project in the shared folder, is to Map a

Network Drive letter to the shared folder .

Remember: You should never have the same project folder open with Together

or Eclipse on more than one computer simultaneously, and there should be no

need for this! [But several copies separately checked out from Subversion by different

programmers is fine!]

? Computing Science and Mathematics

University of Stirling Page 2 of 11

I recommend that you use the Together project only for reference to the documentation, and

that for development you use the Java already extracted from the Together project, and work in

Eclipse (or an equivalent IDE) for the Java development, with the the most up to date project

files held in the Subversion repository. Please note that the versions of Together and Eclipse in

the labs are not compatible with each other, and you should not open one’s projects with the

other!

While you are working, it will be important to synchronize your work with the repository on a

regular basis, and in particular at the start and end of each session of work.

The Library has a collection of bookable meeting rooms — see http://stir.ac.uk/1wz

Further, you can now book free teaching rooms through the ResourceBooker at

https://resourcebooker.stir.ac.uk/ : log in with your Portal username and

password, choose Book a Teaching Room, and then look at Cottrell Central. Also, remember the

University’s "Empty space = study space" policy: "If you find a teaching room or computing lab

lying empty, you are welcome to make use of it."

Assessment arrangements

Each group will make a joint software development submission, and a single agreed

statement of individual contributions. Each student will submit an individual report.

Group software development submission

Each group will produce the following assessable output:

1. The final Java files, emailed as one Zip file to sbj@cs.stir.ac.uk named

Group-nn-Java.zip

2. You are not required to make any substantial alterations to the design/architecture of

the system. However, if you do, then you should submit a brief but clear description of

the alterations and the rationale for them, with relevant parts of the new class diagram.

3. Hard-copy documentation of the JUnit testing that you would carry out to demonstrate

the correctness of an implementation of the GateInfoDatabase class — for

simplicity assume that the classes that it depends on are themselves all correct and so

may be used in the testing. The documentation must include the full code of the JUnit

tests, and a description of the rationale for the test cases chosen (well written

comments in the JUnit test code would be fine). You should also provide print-outs of

the results of applying the unit testing.

Of course, you should not restrict your own testing to just these cases! In the

demonstration later on, all use cases will be exercised.

4. A demonstration by the group of the working system.

Each group should hand in to the labelled box outside 4B89, or directly to Dr Jones, one

hard-copy of items 2 and 3 described above, on or before 17.00 on 27 March 2020. The cover

of the document should clearly identify the number of the group, but should not give the

names of the members.

The demonstrations will be arranged in due course.

Statement of individual contributions

This section is subject to change, pending the outcome of the Doodle poll.

When assessing group projects, care is taken to ensure that the marks awarded fairly reflect

individual contribution and effort. The marks awarded for this assignment will take into account

? Computing Science and Mathematics

University of Stirling Page 3 of 11

the individual reports, the individual contributions and effort as well as the group results. The

individual contributions will be used to give each student an adjusted mark based on the group

software development submission mark.

The group must submit one printed copy of the table provided attached to this document

(page 4), completed to show the relative contribution of each team member: Please distribute

100 points between the group members according to what the group agrees their contribution

to have been. Please double check that the sum of the row is 100.

Note that each member of the group must sign the form to indicate that it has been

discussed and agreed.

The group must attach to the form a brief statement listing the contributions of each

member. For this purpose the group will need to keep a record of who does what.

The statement of individual contributions should be posted into the assignment box by the

same deadline as the group submission, 17.00 on 27 March 2020.

Individual report

In addition, each individual group member must submit a short report (maximum two sides of

A4) discussing the management of the project:

? Describing how their group organized its collaborative work, with reference to the project

management topics studied in CSCU9P5,

? assessing how effectively the group worked towards achieving its goals,

? and discussing, with hindsight, whether and how the collaborative work organization

could have been different to give a better outcome or, if you think that no improvement

was possible, then why the particular organization was so effective.

Note: This short reflective report will be assessed on the quality of the analysis, discussion, and

writing, rather than than on whether an “approved” and effective organization was adopted.

The individual report must be submitted via Turnitin on Canvas by the same deadline as the

group submission, 17.00 on 27 March 20209. The report should have a title page giving the

module code, the title of the assignment “Group project individual report", your group

number and student number, but not your name. Pay attention to the layout and clarity of

your work.

Independent work as regards the individual report

Work which is submitted for assessment must be your own work. All students should note

that the University has a formal policy on plagiarism which can be found at

http://stir.ac.uk/1x0

? Computing Science and Mathematics

University of Stirling Page 4 of 11

Late submission

The standard University procedures dealing with non-submission and with late submission

apply. Assessed coursework submitted late will be accepted up to seven days after the

submission date (or expiry of any agreed extension) but the mark will be lowered by three

marks per day or part thereof. After seven days the piece of work will be deemed a

non-submission, and will result in the award of No Mark. This rule may be relaxed for students

who can show good cause for failure to submit. Good cause may include illness (for which a

medical certificate or other evidence will be required).

Assignment assessment

Although this is a group project, you will be given an individual mark for this assignment based

upon the following 3 factors:

1. The Group Submission

2. The Individual Contributions Form

3. The Individual Report

This assignment is worth 35% of the overall mark for CSCU9P6.

The Group Submission mark adjusted according to the Individual Contributions will account for

80% of your mark.

The Individual Report provides the remaining 20% of your mark.

? Computing Science and Mathematics

University of Stirling Page 5 of 11

Group number:

CSCU9P6 Group project Spring 2020

Individual Contributions

Please quantify the contribution that each member of your team has given to the group

work. Write the names of the members of the group in the first row below. Then, distribute

100 points between them, according to what the group agrees the contribution of each

member was to the development of the project.

For instance, in a four person group, if all the members have contributed equally, then each

member will receive 25.

Ensure that

1. the group number is include in the box above,

2. the names and contributions of your group members are given in the table below,

3. each member signs the form where indicated,

4. a brief statement of the contributions of each member is attached.

Contribution

Member 1 Member 2 Member 3 Member 4 Member 5

Name

Distribute 100

points

Signatures

1.

2.

3.

4.

5.

? Computing Science and Mathematics

University of Stirling Page 6 of 11

(This page deliberately left blank)

? Computing Science and Mathematics

University of Stirling Page 7 of 11

SAAMS project specification

Introduction

In this assignment you will be implementing an information system for the management of

aircraft during their arrival, unloading, loading and departure from Stirling Airport: the Stirling

Airport Aircraft Management System, SAAMS. Note that SAAMS is a support system for the

people associated with the airport and aircraft: it provides information for the staff, passengers

and non-travelling public about the status of aircraft, and regulates the progress of the aircraft

through the various stages of its visit. SAAMS does not directly control the aircraft, nor any

physical systems — though it does have a minimal interface with each visiting aircraft’s

on-board computer for the automatic transfer of flight details. SAAMS’ principal interfaces with

the real world are through screens, most of which are touch sensitive or are equipped with a

mouse and keyboard: airport staff view information, receive instructions, and enter status

updates and other information via the screens. All “real actions” are carried out by “real

people”; in particular, all actions “required of an aircraft”, such as taxiing to a certain passenger

gate to unload passengers, are notified to the aircraft’s crew by airport staff via radio.

Fortunately, Stirling Airport has a perfect, but simple existence: there is no freight nor baggage

to worry about, aircraft never break down seriously (and never while taxiing/landing/taking

off), there is no in-flight catering, there are no “transit” passengers, passengers “check in” only

at the departure gate (like a bus), all aircraft arrive with a pre-planned and immutable onward

flight plan, the airport never closes, and SAAMS never crashes and is not started and stopped

(and so does not have to preserve its state between runs) — and there are probably all manner

of other gross simplifications, but never mind.

The system is to be implemented on a computer system with the various interface devices

distributed around the airport, and connected via special purpose networking. Of course, this is

just an exercise, so the devices will be “only a simulation” and all the interface devices will

appear as separate windows on a single PC screen — but this is actually very close to a real

implementation where the separate windows actually appear on separate PCs (or maybe

simpler devices) distributed around the airport.

You will be provided with a Together design model at an intermediate/late stage in the design

process: use cases, a class diagram, a large state diagram encoding the “life line” of each

aircraft as it visits the airport (that is, the states that instances of the ManagementRecord

class held by SAAMS pass through), a small state diagram encoding the lifecycle of each

passenger gate, and some sequence diagrams.

? The Together model can be found in K:\CSCU9P6\GroupProject\SAAMS. You should

copy this folder to your group working folder. Remove the Read-only attributes.

To make use of this model, you should launch Together, switch to the Modelling perspective

and use File menu / Import. In the Import dialogue box choose “Existing projects into

workspace” and then Next. Click Browse to Select root directory, and browse to locate your

copied SAAMS folder. Then click Finish. This folder also contains the outline Java code

generated by Together, plus a skeleton Main class in Main.java.

It is probably best if individuals take private copies for initial exploration of the project

contents.

? More information/suggestions are given in the SAAMSREADME.txt file — read it.

? Computing Science and Mathematics

University of Stirling Page 8 of 11

? Remember to survey the Descriptions in the Properties Pane when you click on use cases,

classes, methods, attributes... A lot of information/design decisions are described there. A

good way to view the Descriptions is to select the Description line in the Properties pane

and then click on the "..." that appears in the selected line — a separate window with the

description will pop up.

? You need to decide on an architectural framework for the application. MVC was in the

designer’s mind, so that is recommended — look carefully at the stereotype annotations on

the classes (e.g.<<entity>> on the class diagram).

[Caveat: It is sometimes more trouble than it’s worth splitting boundary classes into

separate controller and view classes — this is the case when part of the “view” is used for

the input of a “control” action, such as when the user can choose from a list of displayed

items. However, the MVC scheme can still be followed. You will see that the boundary

classes have the stereotype <<boundary/view/controller>> to hint at this!]

? You will need to check on, and refine, the implementations that Together has implemented

for the associations.

? You may need to introduce new classes — but not necessarily. You may decide to split

some classes up/merge classes. However, probably no significant changes to the class

structure will be required, and none are expected.

? Other refinements of the object model will certainly be necessary: in particular new

attributes and methods.

? Whatever changes you make, make sure that they are rational revisions of the structure

that you have been given, and not arbitrary replacements of large chunks of design.

? Various resources are available to help with the low level design and implementation:

o On-line documentation of the Java class libraries, eg at URL

https://docs.oracle.com/javase/8/docs/api/

o The MVC example (from practicals) in K:\CSCU9P6\Practicals

o A demonstration of how a Java Swing JList of selectable items could be used to

implement an interactive graphical user interface in

K:\CSCU9P6\Using-JList-example (“select an item from a displayed list,

then click a button to take an action”)

? The actual user interfaces do not need to be beautiful, nor too clever — just lists, buttons

and text fields/areas, will be fine.

? You should not use threads or concurrency.

The “life line” of visiting aircraft

The key to understanding what SAAMS is all about is an understanding of how an individual

aircraft’s visit to Stirling Airport is managed. Of course, SAAMS must be able to handle a

number of aircraft at once, and not just one! Here is the story of an aircraft A’s visit, to be read

in conjunction with the ManagementRecord (abbrev. MR) state diagram and Gate state

diagram:

? Computing Science and Mathematics

University of Stirling Page 9 of 11

1. A enters Stirling Airport’s local airspace, is noticed by the radar/transceiver system, has

its flight descriptor downloaded from the on-board computer into SAAMS automatically

(a free MR is configured), and is assigned either the state “in transit” (if it doesn’t want

to land at Stirling), or “wanting to land”. A then appears on the Local Air Traffic

Controller’s (LATC’s) screen, with its status shown, and also on the Ground Operations

Controller’s (GOC’s) screen if it wants to land. [Note: In this exercise the radar and flight

descriptor download (and, later on, upload) will have to be a screen interface through

which we can enter events and data, although in the real system they would be

automatic devices, albeit with equivalent interfaces to SAAMS.]

2. If A is simply in transit, then at some later point the radar notifies that it has lost contact

with A, and A’s MR is cleared, that is becomes free again (in a future extension perhaps

it could be archived, but that is not required here).

3. The GOC starts the permission to land sequence by verifying the availability of space on

the ground (from other information displayed on the GOC screen, a glance out the

window, etc). Once this is done A’s status is changed to “ground clearance granted”.

This is seen by the LATC on the LATC screen, and when the LATC decides that the

air-space is clear and that A is clear to approach and land, the LATC radios this to the

pilot and changes A’s status to “landing”, and later to “landed” when A is safely on the

ground (a binocular check out of the window?). A may disappear from the LATC screen

at this point (because it is no longer in or needing airspace), but remains on the GOC

screen until it has finally departed again.

4. A must wait on the tarmac for notification by the GOC (by radio) of which gate to taxi

to. The gate must have been “free”, and becomes “reserved” for A by the GOC. A enters

“taxiing” status, and should appear on a console display at the gate. [Note: NONE of

these decisions is taken by SAAMS — it simply provides information to the human

operators, who make decisions and enter changes.]

5. When A arrives at the gate, the gate staff press a button to indicate that it has

“docked”, and A’s status changes to “unloading” (and the gate becomes “occupied”).

When all the passengers have disembarked, gate staff press a button to indicate that

unloading is complete, and A’s status changes to “clean and maintain” (for cleaning and

a routine maintenance check — no bird damage to the engines, tyres OK, etc).

6. At this point, A will appear on the Cleaning Supervisor’s screen, and the Maintenance

Inspector’s screen, requesting them to send teams. When the cleaning and

maintenance checks are finished, the Cleaning Supervisor and the Maintenance

Inspector update A’s status via their screens. Cleaning is always successful, but the

maintenance check may reveal faults. If so, the aircraft must await repairs and is then

re-cleaned (in case the repairs made a mess) and re-checked (just to be sure). A variety

of states capture this process, the principal ones being “awaiting repair” (whose

successor is “clean and maintain” again) and “ready for refuelling” (which is only

sensible once A has a clean bill of health). While A is “awaiting repair”, its MR will

contain a (short) text description of the problem — this is entered by the Maintenance

Supervisor when indicating that the maintenance check failed.

7. When A enters enters the “ready for refuelling” state it appears on the Refuelling

Supervisor’s screen requesting a fuel tanker to be sent to the gate. The fuel tanker

operator informs the Refuelling Supervisor when refuelling is complete and the

Refuelling Supervisor updates A’s status. A enters the state “ready for passenger

boarding”, which is displayed on the gate console.

? Computing Science and Mathematics

University of Stirling Page 10 of 11

8. A then accepts passengers on board while it is not full: each passenger enters details (at

least name), which are recorded in A’s MR. When boarding is complete, or the gate staff

decide that no more passengers are presenting themselves, the gate staff “close the

flight” by pressing a button on the gate console. The passenger list is uploaded from A’s

MR to A’s on-board computer by the radar/transceiver system, and A becomes “ready

to depart”.

9. Since A is now “ready to depart” it now appears once again on the LATC screen

requesting a departure air slot. When the LATC is able to allocate a slot (determined

from national air traffic control information, not dealt with by SAAMS), the LATC

updates A’s status to “waiting to taxi”, and A’s presence on the GOC screen indicates

that it is requesting permission to taxi across the tarmac.

10. When there is space on the tarmac for taxiing, the GOC grants taxiing permission, A’s

status is updated to “waiting for permission to take off” (during which it taxis to the

runway). Take-off permission is granted by the LATC once the local airspace is clear, and

A’s status changes to “departing through local airspace”. The radar eventually detects

that A has left the local airspace and A’s MR is cleared, that is becomes free again (in a

future extension perhaps it could be archived, but that is not required here).

About the interfaces

The “life line” description above gives a lot of information about the information displayed on,

and about the interactions via, each interface screen.

SAAMS has the following seven “real” interfaces:

? The LATC screen shows all aircraft “in transit” through local airspace, “wanting to land”,

“ground clearance granted”, “landing”, “ready to depart”, “waiting to taxi”, “waiting for

permission to take off”, and “departing through local airspace”. The LATC can only alter the

status of aircraft with “ground clearance granted”, “landing”, “ready to depart” and

“waiting for permission to take off” — these aircraft should be selectable on the screen,

with the means to action the relevant changes of status. In the other states, the aircraft are

visible on the screen for information and for continuity while the LATC has any concern

about them, and it should not be possible for the LATC to change their status. A suitable

display will be one or more textual lists (see the ListInterface demo), with buttons

for actions. Dynamic switching of views is not necessary — and probably not appropriate

for a high pressure activity like ATC. The LATC screen should also have an area where the

flight details (flight code, origin, destination, number of passengers, etc) can be displayed

on request (select an aircraft, and click a button). (Again, see the List interface demo.)

? The GOC screen is similar in principle to the LATC screen (details can be deduced from the

“life line”). In addition the GOC will need to see the status of each passenger gate in the

airport.

? The Cleaning Supervisor’s, Maintenance Inspector’s, and Refuelling Supervisor’s screens are

all rather similar: they show aircraft currently needing the appropriate attention (with gate

location), and allow indication of completion of the relevant activity. The maintenance

screen is fractionally more complex as aircraft may also be “awaiting repair”, and a textual

description of the required repair must be entered as an aircraft enters this state.

? The gate consoles have a simple display for information about the approaching or docked

aircraft and any relevant flight details (flight code, destination, number of passengers, etc),

with control buttons for various status changes (see the “life line”).

? Computing Science and Mathematics

University of Stirling Page 11 of 11

? There may be many information screens in public areas of the airport. They accept no input

(although they may be scrollable text), and simply display brief status information about

(some of) the aircraft currently managed by SAAMS (e.g. they might not show aircraft while

being cleaned or repaired, and they might not distinguish between all states: for example

“wanting to land”, “ground clearance granted”, and “landing” could be abstracted into

“landing”).

In the demonstrated system it will be sufficient to provide one LATC screen, one GOC screen,

one Cleaning Supervisor’s screen, one Maintenance Inspector’s screen, one Refuelling

Supervisor’s screen, three gate consoles, and two public information screens (although it

should be easy, in principle, to have more of any of these if required).

In addition to these “real” interfaces, there is one simulated device required: the

radar/transceiver. This can be implemented as a screen with:

1. The means to provide flight descriptor information for an arriving aircraft, with a button

to click for the state transition “enters local airspace and downloads flight descriptor”

(step 1. of the lifeline), which causes the data to be sent to the aircraft management

database,

2. the means to display an uploaded passenger list, and

3. a list of selectable aircraft currently either “in transit” or “departing through

localairspace” with another button for the state transition “leaves local airspace” (in

practice the radar would track all relevant aircraft automatically and report their

departure via a “virtual click”!).

Good luck!

Simon Jones 18/02/2020