You can download coursework 2 from here

rangesatanskingdomSoftware and s/w Development

Dec 2, 2013 (3 years and 8 months ago)

276 views

CC3008N coursework 2

Semester A 201
1
/1
2
:
Implement
the CC3007N
Get Fit Quick health
Club
.



This is a
Group

coursework
(
with individual mark allocation
)
worth 3
0%

of module total

Hand in to me in class by email or on CD before
4p
m Friday
Jan 1
3
th

201
2
. Viv
as will be
4p
m
-
6
pm the same day.
Do not
hand in to the UG Registry office.
Y
ou will receive a receipt
from me via email.
The front page should clearly show your
groups agreed recommended mark allocation for each group
member, if you agreed (see mark breakd
own
below
).

Progress Monitoring times are the practical labs week
9

and
week 1
1

failure

to
attend
these monitoring sessions will result in
a reduction to you
r

share of the group mark
.


Task

In this group coursework
,

you will implement the
CC3007N

Z
hotel
lift system
scenario using Java
and

the same group
composition as C
C
300
7
N. (a copy of
the CC3007N
specification

is enclosed at the end of this document). It is not
necessary to implement your Z schemas directly

but

i
t is
necessary to follow the
Z
scenario
.

T
here are marks for
implementing the constraints and rules imposed upon you by the
Z coursework specification.
The Z coursework is written
informally and will leave you with many decisions to make
when creating your Z specification. There are also many de
sign
decision you will need to make when implementing your formal
Z specification.


Remember:
T
his module is about the internal structure and
architecture of your program
. There are many marks for
having a definable structure to your classes
, readability a
nd
maintainability
. There are marks for using OOP features of Java
such as interfaces, abstract methods, abstract classes, inheritance
and polymorphism. You may apply Rogers’s process to one or
more sets of classes in this coursework

or any other process t
hat
results in good structure
.
If you ignore the structure of your
program and neglect to use the OOP features of Java
,

your
group mark will suffer significantly
.

There are also marks for
testing, code readability and using Javadoc comments.

(see mark
brea
kdown bellow)




There are no direct marks for providing a design
document;

you are not required to use a software
engineering approach because programming is an art and
not a science

and you already have the Z spec to help you
.
However, I need the following

information to help me
mark your work

o

Class diagram
,

including any abstract classes,
interfaces etc

o

Package diagram
,

showing any packages you have
created

o

A list of any new Exceptions

you have created

o

A list of the Z spec functionality implemented
,
includ
ing any constraints implemented and any bugs
or omissions

o

Strong evidence of testing your code against the Z
spec

constraints and requirements.
(no need for gui
testing, input validation etc



this is not a HCI
module
)

o

A list of who did what

towards the gr
oup
coursework.

o

A recommended mark allocation
for each member.

(This may be at the front of the report if the group
agrees or provided by each member in sealed
envelopes where there is disagreement. (the latter has
not happened yet)




The structure
, readabi
lity and maintainability

of the
program will be assessed and must be well documented,
clear and sensible including
javadoc
comments for all
classes,
types and names for
attributes, parameters, return
types and variables




You will need some sort of
GUI for
the program

so that
you can demonstrate it. However, the
usability, prettiness
etc of this interface will NOT be assessed
. This
coursework is about program structure.
You will
lose
marks if you can’t provide a working demo

and you
should aim to
demo all th
e features you have attempted
to implement
. If a feature is not fully working you may
demonstrate that feature anyway. The
marking scheme
credits work in progress and incomplete features
.




You must store and retrieve
lift log
data

from a non
-
volatile store
. Your can use file handling or JDBC
database access
.
Each approach will get identical marks if
done well because each poses different and unique
challenges.

You could use:

o

text
file
(bufferedReader and Writer)

o

binary data
file
(dataInput dataOutput strea
ms)

o

Java serialization

into a file
.

o

JDBC (Java database Connectivity) (it will be up to
you to get an database account (e,g, msql account
from Alex Tarry
(
a.tarry@londonnmet.ac.uk
)
and
check the firewall on

the student machines does not
block the connection)




Your individual contribution will be assessed and it is
VITAL that all work is clearly attributed to one or more
students so that I know who did what
. This can be done by
putting comments at the top of

each java file and using the
footer in the report. You may also wish to provide a
summary of who did what.
If you contribute nothing you
will receive no share of the group’s mark

(so the
members who did contribute will get a larger share of the
mark
pie
)


A coursework of this size can be daunting I suggest you begin
by deciding which order to implement the functionality needed,
choose appropriate data structures and decide which technology
you will use to store the data. I further suggest that you split
the
project up into phases so that at the end of each phase you have
a documented and working program that you can then add more
functionality to. It is very dangerous to try to implement
everything in one go.
At whatever stage you finish at you
need to pr
ovide a working demonstration. Feature heavy but
non
-
working implementations will be penalised, as will
poorly structured working programs.


Mark Breakdown

Your

group will be awarded a single mark out of 600
(the pie)
according to
:




Code/Object/Package/cla
ss
Structure

(10 marks)



Javadoc

commenting and
code

understandability

(5
marks)



Ease of
maintenance

and ease of
extension

(10 marks)



Use of
Database

and
or
File storage

(
10

marks)



Strong evidence of
testing

including
module
,
integration

and
system
.

(10 mar
ks)



Amount

of Z specification

correctly

implemented (
55

marks) including whether you have met
the
constraints


Once the group mark (pie) has been determined the marks
will be divided amongst the group members according to
each members’ contribution to the
group.

Students who do no
work towards the group work will not be “carried by the group”
and will receive no slice of the mark pie. This will leave the pie
to be divided up amongst those who actually contributed.



Your slice of the mark pie will be determ
ined by:




Your contribution to the group in terms of quantity
and quality
.

(
Y
ou must document what you have done
even if it was only a feasibility study or a prototype which
did not get used in the final version
.

These

still count as a
contribution)



Attend
ance of monitoring
sessions

in weeks 9 and 11



Your personal report

(reflectivity and looking at what
you have learnt and achieved is an important part of
learning and poor personal reports will result in a loss of at
least
(
5%

marks)
.



If the group agrees o
n an allocation the groups allocation
will be taken into account


I am aware that group coursework can be stressful and that some
members of the group may contribute more than others. I will
try to help mediate problems and there is a mechanism for the
maj
ority of the group to decide the share of the marks its
members will receive.
However, this allocation of marks is
not final and is only a suggestion to the markers.



What is expected to be handed in for the group:



Java Source code with Javadoc comments o
n cd

or email



Implementation decision report indicating the data
structures used, file format/database tables used. Choice of
data types such as String for customer id etc.



Evidence of extensive unit/module and integration testing



Agreed record of who has

contributed
what
(this is vital
because each member of the group is individually
marked on their contribution)

and an allocation of
marks between the participants.



Log of any meetings and progress log documenting what
was done in what order. Note this wil
l be asked for in
tutorials and cannot be written at the end of the project.


What is expected to be handed in for each
member:



A reflective account of the project. I.e. what you have
learnt about group work, any new technologies or
techniques learnt. Wha
t you have found out about
yourself, what you found difficult, problems encountered
etc
.

1 to 2 pages should be sufficient



An evaluation of your own contribution and an evaluation
of the finished product. An evaluation of the process
including discussing
whether you believe that
programming from a Z specification helped or hindered
your programming and why you chose to program from
the specification or
not.

1 to 2 pages should be sufficient



If you can not agree on the allocation of marks or on
who did what

you must provide a signed and sealed
envelope documenting what you believe you contributed
towards the group project and detailing any problems
encountered in the group.
This document is confidential
between you and me.
However, I may need to investigate
any issues it raises.


Advice

I have run this
group
coursework for 6 years and
success seems
to be as dependent upon how well the group works together

and is organised as how well you can program.
I have seen
groups containing several good programmers get
a poor overall
mark because of poor communication, arguments, lack of
organisation and underestimating the difficulty of the
coursework. I have seen groups without strong programmers do
well because they have started early, worked hard and remained
as a gr
oup.


Do not underestimate the importance of regular meetings, of
being a team and working together and delivering on time. You
may want to create a project plan, assign a group leader, put
version numbers in comments at the top of each file
, keep
backups

of earlier versions in case something goes wrong or a
change breaks your code

etc. I cannot stress enough the
importance that you work together and meeting together. Every
group last semester who had trouble organising group meetings
or had poorly attende
d group meetings suffered as a result. Meet
early. Meet often

be a team and feel part of the team
. This is a
big
coursework (like the Z coursework)

and can

t be done in a
rush.


Good luck

James


















CC3007N

Formal Methods of Specification

Gro
up Coursework:

Health Club


2.

Problem description


Get Fit Quick health club (GFQ) is a health club operating in the UK. The club in the past has
had problems balancing demand on its facilities (sauna, gym, etc.) and has decided that it
needs a booking s
ystem to keep track of demand. Members can check availability of slots
and facilities, their current bookings, their membership details, and book specific slots and
general purpose slots.

For the purpose of this coursework, only GFQ staff can access all t
he data. Each facility is
bookable in fixed units of time called slots. The duration of a slot depends upon the type of
the facility. Some slots contain fixed classes with one or more instructors. The remaining
slots are for general
-
purpose use. Diffe
rent slots in the same facility may have different
maximum capacities depending upon the space required and any extra equipment needed.


2.1.

Overview

Prospective members can browse the list of available facilities based on the day of the
week, month, and
type.

Prospective members can also register with GFQ online by providing their personal details
(e.g. name, address, e
-
mail address, gender, date of birth, credit card number, fitness needs,
etc.). Once a registration is accepted, the person becomes a GFQ

member and then he/she
will be able to book facilities and slots.

The health club is open from 7am to 10pm every day except for Christmas day and New
Year’s Day.

There are three types of membership: platinum, gold and lead. They differ according to when

members can book slots and how many slots they can book per week.

Searches should facilitate any special conditions, e.g. type of slot, availability, day restrictions,
and membership type restrictions. When a suitable class or slot is found based on the
members' search criteria, a booking can be made. The booking confirmation (including the
booking reference) is sent to them via e
-
mail. The health club has the following facilities:


Facility

Slot length

Capacity of a slot or class and other
conditions

Sauna (male only, age 18+)

15 min

8

Sauna (female only, age 18+)

15 min

8

Sauna (mixed, age 16+)

15 min

8

Sun
-
bed (max 1 slot per day
per member)

15 min

3

Holistic studio

1 hour

Yoga 20

Pilates 20

Body balance 20

No general slots available to members

A
vailable for hire by non
-
members of GFQ

General Studio

1 hour

Karate 15

Dance 30

Aerobics 30

Body pump 15

Step classes 15

No general slots available to members

Available for hire by non
-
members of GFQ

Gym

1 hour

No classes

General usage 30

Swimming Poo
l

1 hour

Aquarobics 20

Swimming 20

General usage 20 (when no class is on)



2.2.

Example (of a daily timetable)

Facility:

Swimming Pool;

Date:

10/10/2011;

Capacity:

20;

Slot length:

1 hour.

7am

8am

9am

10am

11am

12am

1pm

2pm

Aquarobics

Swimming
class

Ge
neral
usage

General
usage

General
usage

General
usage

General
usage

General
usage

Remaining
places 18

Remaining
places 20

Remaining
places 10

Remaining
places 15

Remaining
places 5

Remaining
places 20

Remaining
places 4

Remaining
places 15


3pm

4pm

5pm

6
pm

7pm

8pm

9pm

General
usage

General
usage

General
usage

General
usage

Aquarobics

Swimming
class

General
usage

Remaining
places 18

Remaining
places 20

Remaining
places 20

Remaining
places 5

Remaining
places 0

Remaining
places 11

Remaining
places 14



2.
3.

Information held for entities


Members

are described with, at least, the following data attributes: member number, name,
contact details, date of birth, credit card number, gender, e
-
mail address and membership
type (platinum, gold, lead).

Staff

are des
cribed with, at least, the following data attributes: staff number, name, contact
details, date of birth.

Facilities

are described with, at least, the following data attributes: type (e.g. sauna), length of
slot, capacity.

Bookings

are described with, at l
east, the following data attributes: booking number,
facility
number
,
member number, name, slot details.


You may add more entities as appropriate.


2.4.

Constraints


Ensure the system satisfies all the constraints listed below. You may add additional
co
nstraints provided they are reasonable/realistic, well justified in your report and not
contradicting the given ones.



Prospective members are able to search and check availability of facilities and slots.



A member can only place a booking for him/herself
.



Members can change their own booking only up to 24 hours before the slot begins.



A booking must be for a slot at a facility.



Only people over 16 years of age can register to become GFQ members.



Only GFQ staff are able to remove or amend members, classes
and facilities from the
database.



Each facility has a maximum capacity for each class and slot as indicated in the table
above.



Platinum membership cardholders can book facilities at any time. No limitations on
total duration of slots booked per week.



Gol
d membership cardholders can only use facilities from 9am to 5pm weekdays and
after 5pm on weekends. No limitations on total duration of slots booked per week.



Lead membership cardholders can only use facilities from 9am to 5pm weekdays and
after 5pm on w
eekends and can only book a maximum of 6 hours of slots per week.



One person cannot be booked for more than one slot at the same time.



To minimise the risks of skin burning, no member can use a sun
-
bed for more than one
slot per day.



To avoid overzealous m
embers straining themselves, no member may book more than
3 hours of slots per day.



A booking can be made up to 1 week in advance.



Booking cancellations or amendments can be allowed up to 24 hours before the slot
begins.



Young adults from 16 to 18 years ol
d may only use the mixed sauna and must remain
respectfully attired.



A member may not be removed from the database if there is an active booking under
his/her name.



For any given facility time slots never overlap. Hour long slots start on the hour; 15
minu
te slots start on the hour, 15 minutes past, 30 minutes past and 45 minutes past
the hour.



Identification numbers for members, slots, facilities, and bookings may never be
changed once they have been issued.



Gym does not have classes.



When there is no clas
s running, the holistic and general studios may be booked by
people who are not members of GFQ at a premium rate for public events, meetings etc.



GFQ members may not book slots in the holistic and general studios.



2.5.

Operations:


The specification must

support at least the operations defined below.


Operations available to prospective members:



SEARCH facilities to display all the slots, which satisfy all the criteria specified by the
user. This schema should allow null entries for any criterion, where
null would mean
that the user doesn't have preferences for that particular criterion.



REGISTER_MEMBER to register a person as GFQ member.


Operations available to GFQ members:



All the above, apart from registration.



BOOK_SLOT to book an available slot on a

facility.



AMMEND_BOOKING to change a booking.



CANCEL_BOOKING to cancel a booking.


Operations available to GFQ staff:



All the above.



CHECK_SLOT_AVAILABLE to output the number of remaining places in a slot.



ADD_SINGLE_CLASS for staff to add a single new cl
ass to a facility to the GFQ
database (e.g. swimming 5pm 10/10/2011).



ADD_CLASS for staff to add a class to a facility which occurs every week, month, etc
(e.g. swimming every 5pm Saturday from 10/10/2011).



CHANGE_CLASS_DETAILS to be able to change any det
ail regarding a class in the
database.



CANCEL_CLASS deletes all occurrences of that class for that facility at that time from
a given date (e.g. the 5pm weekly Saturday swimming class is cancelled due to lack of
demand).



CANCEL_SINGLE_CLASS deletes a singl
e class (e.g. swimming 5pm 10/10/2011 is
cancelled due to the swimming instructor being ill). Any members with bookings should
also be informed of the cancellation.



AMEND_MEMBERS_BOOKING to change a member’s booking.



CHANGE_MEMBER_DETAILS to change any de
tail regarding a member in the
database.



DELETE_ MEMBER to completely remove a member from the database.



BOOKED_ MEMBERS to list all the members with active booking given slot for a given
facility.



MAY_BOOK_SLOT to see if a given member can book a specific

slot.