Functionalities to be coded and estimated complexity Manager

Functionalities to be coded and estimated complexity
Manager: auditor registration 20pts
As a manager I want to register new managers for the system so
they can use the platform
Manager: manager registration 20 pts
Manager: client registration 20pts
Manager: Notified of unusual trading70pts
As a manager I want to be notified of unusual trading activities
that might indicate insider trading so I can be compliant with
the law
Manager: Set Activity logic 90pts
As a manager I want to be able to dynamically set the logic for
unusual activities so I can respond to new insider trading tactics
Manager: Set threshold logic 90pts
As a manager I want to be able to dynamically set the logic for
unusual thresholds so I can respond to new insider trading
tactics
Audior: Query Transactions 40pts

As an auditor I want to be able to query all transactions
completed between specific dates by specific clients to ensure
the clients are performing in a way that is legal.
Manager: Make Premium 20pts
As a manager I want the ability to make clients premium clients
Manager: Add Funds 20pts
As a manager I want to add funds to a client account
Manager: Deregister
Software Engineering Fundamentals 2020 Semester 1 Group
AssignmentProject Objective
Software engineering Fundamentals is a hybrid project based
course where the group project plays a major role in building
student capabilities. It requires you to analyse the requirements
of various stakeholders as a team and resolve any conflicts (or
vague requirements) with the tutor acting as the product owner,
before synthesising your solution iteratively, applying the
software engineering principles taught. One major goal of this
software engineering assignment is to facilitate teamwork and
you will be expected to use techniques such as CRC cards to
effectively distribute responsibilities across classes and
individual team members. Your team and technical experience
in this project will help to meet the course and the program
level objectives as well as act as a cornerstone project. The
milestone and face-to-face sessions are designed to improve
your communication skills. You will also be exposed to tools
common in the industry (Git, Trello, LucidChart, JUnit) that
foster teamwork and individual accountability.
Overview of Project and Assessment
You will get both formative (continuous) and summative (final)
assessments as part of this project and this section briefly
explains the assessment structure and the role it plays in

building your capabilities.
Assessment
Role
Marks
1.
Weekly progress marks
Weeks 3-12
Measuring your progress as an individual and as a team and
giving feedback
10 x 1
2.
Milestones Week 7 and 12
Present your requirements, design and implementation as a team
and as an individual member to get feedback.
2 x 5
3.
Face-to-face meetings
Week 9 and After submission in Week 12.
Designed to give more in depth feedback on your design,
implementation and testing. The initial one will focus on the
design aspects while the latter one will consider both functional
and qualitative aspects such as usability, reusability,
extensibility and maintainability. For individual part you will
be asked to explain how your individual contribution is aligned
with overall group design.
5 + 20
Team Formation (Formed by students)
Since SEF is currently common to students from a number of
degrees with different pathways we encourage teams to be self-
formed reflecting individual competencies and interests and the
more experienced student in the team may take a leadership role
(such as Scrum Master) facilitating teamwork and the transfer
of skills. Multiple assignments are provided in an attempt to
match your interests but all of them require you to demonstrate

your core competencies in requirements-gathering, analysis,
object oriented design, processes, implementation and testing.
Note all members of the team should be in the same group.
Project Weight
This project is worth 45% of your total grade for this course.
You are required to do only one of the seven project options.
(
PROJECT OVERVIEW I
)
1. Weekly Progress Marks (10 marks)
To get full marks each team is also expected to complete the
tutorial working as a team as well as meeting the weekly criteria
specified below.
Wk
Suggested Activities
Progress/ Activity
Milestone/ Meeting
3
Select the project and form the team – consider the strengths,
interests and experiences of team members
1 mark
4
Identify User Stories for Product/ Release Backlog
1 mark
5
Identify main domain classes and add responsibilities such that
objects can interact to get the first release done. Distribute
classes/responsibilities to members.
1 mark
6

Write Test Cases and start writing code to make them pass
(individual)
1 mark
7
Initial Milestone: Present partially completed product and get
feedback from tutor and class. Demonstrate working Test cases
(individual) and continue integrating code and testing.
1 + 5
marks
Initial Milestone
8
Plan second release incorporating feedback. Add classes, extend
class responsibilities and distribute work.
1 mark
9
Develop detailed Group UML Diagrams (class, use-case).
Initial Face to Face Meeting
1 + 5
marks
Initial Face to Face
10
Develop Individual UML Diagrams (sequence, state, object).
Demonstrate individual Test cases
1 mark
11
Develop Activity Diagrams.
Combine code and run integrations tests. Resolve conflicts.
Refactor design and code before final submission.
1 mark
12
Second Milestone: Present final product to tutor and class.
1+5

Final
13
Final Face to Face Marking of design and code by Class Tutor
20 marks
Final Face to Face
(
PROJECT OVERVIEW
II
)
2. Milestones 1 and 2 (10 marks)
A. Milestone 1 (5 marks) in Week 7
This first demo/presentation will award marks for both group
and individual work. Each individual member is expected to
undertake at least two major tasks or responsibilities. Some of
these responsibilities can be shared. For example, in the chess -
like game “show all valid move destinations for a piece” can be
a user- story/responsibility that must be shared by the Piece and
the Board classes. The subclasses of Piece such as Rook and
Knight may know valid moves but only the Board class knows
where the vacant and opponent squares are located. In such a
situation, those members writing the Rook and Knight classes
may override the method getAllValidMoves():Squares[], while
the person developing the Board class may write a method to
check which of these squares are free to move using
IsValidDestination(square). These two methods from different
classes may thus be combined to determine all valid
destinations. Students can defer non-model (GUI) aspects until
the “core- logic” is fully tested (by using a simple textual
interface).
Activity
Marks
Group Part

Presenting the Initial Release Backlog (design documents: Class
and Use Case diagrams) and demonstrating a partially
completed product.
2 marks
(4 mins)
Individual Part
Individual member is expected to explain his or her
role/obligation towards carrying out the main user-
stories/responsibilities, and any challenges faced.
3 marks
(4 x 1.5 mins)
B. Milestone 2 (5 marks) in Week 12
The second demo/presentation will award marks for both group
and individual work though more marks is awarded for group
work.
Activity
Marks
Group Part
Presenting the Final Release Backlog and demonstrating the
final product
2 marks
(3 mins)
Use a class diagram to present the overall design; use two
sequence-
diagrams to present the core functionality. Explain the design
rationale highlighting usability, maintainability, extensibility
etc.
2 marks
(3 mins)
Individual Part
Individual members explaining their role/ contribution and any

challenges
1 mark
(4 x 1 min)
(
PROJECT OVERVIEW
IV
)
3. Face to Face Tutor Marking 1 & 2 (Total 25 marks)
Face to face marking is designed to give feedback and to award
marks for following processes, using industry tools, flexible
designs and the use of standard modelling notations.
A. Initial Face to Face Demo and Marking (Total 5 marks) in
Week 9
Activity: Group Part
2 Marks
Model a positive and a negative scenario for 4 main use
cases/user stories. You may use the storyboarding
technique/screenshots to show the sequence of interactions (1
mark). Design classes/methods that can collaborate to carry out
the 4 main user stories/use cases. Your initial class diagram
should be extended to show more details of methods (1 mark).
2 marks
(6 mins)
Activity: Individual Part
3 Marks
Each team member has to write two positive and two negative
JUnit test cases (exceptions must be thrown for negative ones)
for a significant method in an important domain class they are
assigned (2 marks).
Each individual student has to explain how these tests help
implement the different scenarios identified in the group part.
(1 mark)
3 marks
(2 mins each)

No submission required but students are expected to bring their
documents (storyboarding, scenarios, class diagrams) and
execute the test cases developed by each individual student.
B. Final Face to Face Marking (Total 20 marks) Submit in week
12 and Demoed in week 13
Group effort will be measured through overall class and use-
case diagrams, which should explain the overall requirements
and design decisions. Each individual member is expected to
demonstrate their individual contribution by detailing their part
of the use-case (a use case textual description) and class-
diagrams and by coming up with two other UML diagrams (a
sequence diagram and one of state/activity/object diagrams).
Tutors will check your diagrams are aligned with your code and
how group diagrams such as class and use case diagrams are
aligned with individual diagrams (sequence and state). Include a
table giving contribution of each member, allowing group mark
to be adjusted.
Activity: Group Part
10 Marks
Overall Class Diagram (group)
The class diagram must show all the methods, attributes,
associations and multiplicities. Name the associations wherever
possible.
Up to 2 marks for valid class diagram that captures all the main
classes, associations (with naming) with the correct
multiplicities. Standard UML notation expected.
The remaining 1 mark is allocated for consistency with
individual sequence diagrams (update the class diagram to
reflect the final sequence diagrams).
3 marks
Overall Use Case Diagram (group)
Up to 2 marks for a valid Use Case diagram capturing all
individual use cases. For the remaining 1 mark show all the
relationships including extends/includes.
3 marks

Group Evaluation (max 1 page report) including:
Lessons learnt about project/process management (2 marks)
Strengths and weaknesses of your system in terms of
reusability, extensibility, maintainability and usability (2
marks).
4 marks
Activity: Individual Part
Total 10 marks
Show detailed methods/attributes/associations relating to
individual contribution in the class diagram
2 marks
Show detailed explanation relating to individual contribution in
use case diagrams – present one use case textual description for
a significant use case.
2 marks
Sequence Diagram (individual)
2 marks
One of state/activity/object diagram
2 marks
Code explanation by individuals. The code must be refactored
and reflect the design.
2 marks
Submission Details: 29th May 2020 4.30 pm (week 12). No late
submission allowed.
Final Submission (Week 12):
All source code and diagrams must be bound together and be
submitted as a zip file called FinalSubmission.zip through
Canvas by Friday 11.59 Week 12 (29th May).
In additional all the design diagrams must be bound and
submitted to the Sessional Staff office (14.09.13) by
4.30 pm on the last day of the semester (29th May).
Assignments: Summary, Rationale and Common Aspects
These assignments are designed to facilitate an agile or test
driven approach for the first milestone, and a more rigorous

design and implementation for the second milestone using UML
notation and design/code refactoring. We have tried hard to
come up with interesting and varied projects to match your
interests and backgrounds. Your team should consider the
strengths and interests of your members when selecting the
project. You may also want to do some reading, testing and
feasibility studies before finalizing your assignment selection in
week 3. The first milestone is designed to enable students to
develop some working- software or a prototype as soon as
possible and get some feedback during the class presentation in
week 7. The second milestone will focus more on the design
aspects including extensibility and maintainability of the
software. In addition face-to-face feedback will be given to
each team in private in weeks 9 and 13.
Assignment (Project Options)
Description
Activity/Flow Diagram Visualiser
Diagram tool for creating and executing flow diagrams.
S&E Real Estate Agency
Buying, selling and renting properties.
Student Casual Employment System
A system to allow students to specify their availability and
skills for casual employment while allowing employers to select
and offer jobs to suitable applicants.
Project Teams Formation System
Software to form well matched teams based on preferences of
students, requirements of employer and constraints by project
manager.
Multiplayer Pacman Interactive Game
This fun multiplayer project is suitable for those interested in
working with distributed applications. It will require the use of
sockets, threads and synchronization or RMI. This is probably
one of the most technically challenging assignments. If
selecting this project you need very good programming and
debugging and design skills.

Project Management Software
This project will be great for those considering a project
management career; it will give you a head start with
scheduling and resource allocation, a common problem in
project management. This project requires some use of GUI and
events.
Internal Stock Trading System
A client server system for trading company shares between
employees. Requires an interest in network programming.
Collaborative Snakes & Ladders Game
This project requires you to extend the Snakes and Ladders
game for which some sample code is provided.
Note: Each group member must be from the same Tutelab
session.
PROJECT OVEVIEW V
Project Option 1. Activity/Flow Diagram Visualiser
Project Overview
You are required to analyse, design, implement and test a tool
for teaching students about Boolean logic and activity/flow
chart design. You will develop a tool that allows the user to add
various flow chart elements to a workspace area and to connect
them with flows (represented by arrows).
Elements consist of branching (represented by diamonds),
merging (also represented by diamonds), actions (represented by
rounded rectangles), a single start point (represented by a solid
black dot) and an end point (represented by a solid black dot
with a concentric circle around it).
Each branch will represent a decision and will contain a
Boolean condition that the user can enter and will have only one
arrow coming in, but two or more arrows coming out.
A branch represents either an IF statement ora DO-WHILE
statement, depending on whether there is a loop back to a
previous merge in the flow.
Each merge represents the end of an IF statement, or the

beginning of a DO-WHILE loop.
The user can define variables, assign values and perform
arithmetic equations/assignments and do simple input (READ)
and output (PRINT) using actions.
Below are two examples of Flow Charts with a DO-WHILE loop
and an IF-ELSE condition:
(
PROJECT OPTION 1: Page 1/2
)
The system must be able to save the flowchart and allow editing
of existing designs.
The file format is up to you, but either an XML structure or
serialization is recommended.
The flow chart must be able to be “executed”. The user can set
the delay between steps that are executed, and the program steps
through each instruction at the set speed. Alternatively, the user
can step through manually one instruction at a time. As each
instruction/action/decision is executed it must be highlighted in
RED. The system must have a console where input and output is
processed. When input is expected, a prompt should appear in
the console. Similarly when output is produced, it should be
printed to the console.
Whenever the user selects the execute option, the system must
validate the design first to ensure that it is executable (notifying
the user if it is not executable – with some indication of where
the error is). If validated successfully, the flow should then be
executed.
While the flow chart is being executed, the user should be able
to stop the execution by selecting stop.
All client queries must be directed to your product owner, your

tutor in this project. You may also post general questions to the
Canvas Discussion Board.
Bonus:
As a bonus, you should implement the ability to have unlimited
undo and redo of changes to the flow diagram. A second bonus
is the ability to translate the diagram into equivalent Java code.
(
PROJECT OPTION
2
: Page 1/4
)Project Option 2. S&E Real Estate AgencyProject Overview
You are required to analyse, design, implement and test a stand-
alone prototype for S&E Real Estate Agency, which manages
the rental and sale of properties. In this initial stand-alone
system you are not required to allow concurrent or web access;
however you are required to design the system in a way that
allows for extensibility, maintainability and reusability. You
should also ensure all user accounts are password protected and
can access or edit only the information related to their role and
identity. Assume staff are already registered in the system w ith
their e-number and password. The public should be allowed to
view and search for Property and Open Day details specifying
suburb and price range. You are not required to handle property
images at this stage.All client queries must be directed to your
product owner, your tutor in this project. You may also post
general questions to the Canvas Discussion Board.
Requirements:
Customers
· All customers must supply their name and email address when
they register and specify whether they are vendors (selling) ,
landlords (leasing) or whether they are interested in buying or
renting properties. All customers are given a unique ID if
registration is successful.
· Those customers buying or renting properties are to be
allowed to add suburbs that are of interest to them. Such

customers are to be informed whenever a new property is listed
(for rent or sale) in a suburb that is of interest to them. They
should also be notified when an inspection is created and
cancelled.
· Those customers selling or leasing properties are allowed to
add their properties to the system and edit the details, however,
the properties are not listed until an employee is assigned to sell
or rent it.Employees
· The company currently has a number of full-time and part-
time employees. All employees are paid a salary. Part-timers are
paid a salary that is proportional to the hours they worked. e.g.
a half-time employee gets 50% of the full time salary. Part-
timers are required to enter their hours into the system each
month and get the branch manager to approve it.
· When an owner adds a new sale or rental property, the branch
manager inspects the necessary documents handed over
(physically) before assigning a single employee to it.
· Sales consultants are tasked with selling a property on behalf
of a vendor. They are paid a base salary plus a bonus which is
40% of the commission S&E receives from the final sale price
of each house the consultant sells. Sales consultants advertise
the property, liaise with the vendor, organise legal documents,
conduct inspections and facilitate negotiations between the
vendor and potential buyers.
· Property managers are tasked with the long term management
of rental properties on behalf of a landlord. The tasks of the
property manager include advertising the property, conducting
inspections, reviewing tenant applications, checking
maintenance reports, organising maintenance works, paying
bills from property accounts and deducting management fees
from property accounts.
· The branch administrator does various office duties including
receiving documents, scanning documents into the system,
collecting rent, crediting the branch account with money
received, and running the payroll at the end of each month. The
payroll includes salaries for all staff, commissions on property

sales and payments to landlords.Inspections
· Each sales consultant and property manager is required to
schedule inspections for the properties assigned to them. They
must specify the property, date and time for each inspection that
they have arranged.
Properties
· All properties must specify property address, suburb, and the
property capacity (number of bedrooms/bathrooms/car spaces)
· Properties come in various types (house, unit, flat, townhouse,
and studio).
For Sale Properties
· The sales commission is negotiated between the sales
consultant and the vendors from 2 to 5% of the final selling
price. All properties sold by S&E Real Estate Agency are done
either through negotiation or auction.
· Before conducting any inspections a “Section 32” must be
compiled by a legal professional. This is scanned into the
system and then copies are made available to
buyers.Negotiation:
· The vendors are required to specify the minimum price they
are willing to consider. A vendor can increase the minimum
amount any time (reflecting the change in property values),
unless it is for sale by auction.
· When a formal offer is made on a property (that exceeds the
minimum amount), the vendor has 3 days to either accept or
reject the offer. The buyer can withdraw (i.e. undo) the offer at
any time during this period and other offers can be taken during
this period. An offer is implicitly rejected by the vendor if they
do not respond within the 3 day period. During the 3 day period
inspections can still be conducted.
· Whenever an offer is accepted by the vendor, the buyer is
required to make a 10% down-payment within 24 hours. No
further offers can be taken during this 24 hour period. The
buyer making the offer can change their mind on a purchase up
until the deposit is paid.
· When the deposit is received the property is considered “under

contract” and all future inspections are then cancelled. If the
deposit is not received within 24 hours then the property stays
on the market and new offers can be taken. During the 24 hour
period inspections can still be conducted.Auction:
· Vendors are required to select an auction date and properties
that are up for auction can only be booked for inspection for
dates before the auction date.
· The vendors may choose to specify the minimum reserve price
for the auction (or may choose to have no reserve). Once the
bidding process has begun, the minimum reserve can no longer
be altered.
· When a bid is made, it must exceed any previous bid on the
property by at least $1000. The auction ends when there have
not been any bids for 30 seconds or more.
· When the auction ends, the bidder with the highest bid (that
meets any minimum reserve price) is given 24 hours to give a
deposit of 10%. If the highest bidder fails to provide a deposit
within 24 hours, then the next highest bid is considered (again
assuming it has met any minimum reserve).
· This process repeats until there are either no valid bids left (or
no bids that meet the minimum reserve).
· A property that fails to sell under auction, can be put up for
auction again (however any minimum reserve must be reduced
by at least $10,000 or removed all together, no reserve can be
added to a property that has previously failed to sell without a
reserve).
· When the deposit is received the property is considered “under
contract” and cannot be put up for sale or auction again until
the sale is finalised.
(
)Rental Properties
· The management fee for a property is usually a standard 8% of
the rental amount. If the same landlord has two or more
properties with S&E then a discount rate is automatically given

which is 7% for each property. The management fee can also be
negotiated down further to a minimum of 7% for a single
property and 6% for multiple properties.
· Landlords offering properties for rent must specify the weekly
rental and acceptable contract durations (e.g. 6 months, 1 year
or 2 years). Potential renters must make an application
specifying the weekly rental and contract duration desired.
These may be different from the rent and duration on the offer.
· There must be at least one applicant on each application.
Personal details such as each applicant’s income, occupation,
current and past employers/rental contracts, length of current/
past employment/rental etc. are captured in the system. These
may be edited at any time by the customer.
· When an application is received the landlord has 3 days to
either accept or reject the application. Any applicant can
withdraw (i.e. undo) the offer at any time during this period and
other applications can be taken during this period. An
application is implicitly rejected by the landlord by not
responding within the 3 day period. During the 3 day period
inspections can still be conducted.
· When an application is accepted the applicant(s) have 24
hours to pay one month’s rent in advance plus a once off
payment called the “bond”. The bond is calculated as 4 weeks
rent and this amount must be immediately paid into the REIV
trust account. No further applications can be taken during this
24 hour period. The applicant can change their mind up until the
rent and bond is paid.
· When the rent and bond is received within the 24 hour period
the property is considered “let”, the applicant becomes the
tenant and all future inspections are cancelled. If the rent and
bond is not received within 24 hours then the property stays on
the market and new applications can be taken. During the 24
hour period inspections can still be conducted.
Scope can be roughly defined as:

1. In scope are all system functions related to listing, searching,
offering/accepting, and payment of salary, rent, deposits and
commissions. Customer details must be captured if they are
involved in buying or renting.
2. Out of scope – Functionality related to property tax, first
home buyers grants and insurance.
3. Limited scope – Functionality of external systems with which
the new system must interface such as legal services for
compiling section 32s, marketing services for advertising
properties in papers and with bill boards etc. You may need to
show that these tasks are done, but no structural data relating to
those aspects are to be maintained in your system.
Sales Requirements
Authorized users (manager, employee assigned) should be
allowed to view the current state of any property currently in
the market. A property is not considered sold when the deposit
is paid. It is only sold when the full sale price has been paid by
the buyer to the vendor which is called ‘settlement’. Modelling
settlement (i.e. paying parts of the purchase price to creditors
such as banks and lawyers) is out of scope.
Rental Requirements
Authorized users (manager, employee assigned) should be
allowed to view the current state of any property listed for
rental or currently being rented. In the life time of the property
there may be many different tenants and applications for
tenancy. The rent may only be changed after the term of the
lease expires.
(
PROJECT OPTION 2: Page
3
/4
)Bonus: Networked Auction system
The current auction system is processed centrally with bids
being manually recorded in the system by the auctioneer. In the
full system, there needs to be networked client applications that

can be used to submit bids remotely to the central server where
the details of the bid are stored and the current highest bid
details are transmitted to all the clients.
General RequirementsPersistence
All data entered must be persisted. The data may be stored as
flat files, serialized files or in databases.
Design Documents
Detailed design documents are needed including class, use case,
sequence, activity and state diagrams. In the initial stages the
UML diagram in sketch mode should be shown to the product
owner (tutor). Scenario modelling and storyboarding should also
be shown to the product owner before detailed design and
implementation commences.
Teamwork
Teamwork marks will be based on your group and individual
contribution during the feedback sessions and your contribution
to Trello. Your team contribution will be reflected based on
how well your individual contribution (through individual
design diagrams such as use case textual descriptions, sequence
diagrams and JUnit test cases) are consistent with the overall
design and implementation and testing goals. In the final face-
to-face marking you will be required to fill a peer review form,
which will help determine your group contribution. If your team
is using Git your contribution also will be taken into account
when determining your group marks.
Project Option 3. Student Casual Employment System
Project Overview
You are to gather requirements, analyse, design, implement and
test a proposal for Student Casual Employment System to
facilitate students to find contract and ongoing part-time jobs.
In the initial stage you are required to develop a stand-alone
system without concurrent or web access; however as a software
engineer you are required to design the systems allowing for
extensibility, maintainability and reusability. You should also
ensure all user accounts are password protected and can access
or update only the information related to their role and identity.

Project Scope
This requirements specification applies to the proposed Student
Employment System as described below. The scope of the
proposed system is restricted to the following functions:
· Registration of student applicant accounts
· Registration of employer accounts
· Creation and updating of job preference and availability
· Adding and updating Employment Records and References by
applicants
· Uploading of CVs (text files) by applicants
· Searching for suitable applicants by employers based on job
preference and availability
· Shortlisting and Ranking candidates by employers based on
availability, experience and CV
· Automatic email notification of inviting suitable interview
times to highly ranked candidates
· Selecting interview times by shortlisted candidates
· Updating candidate based on interview and reference check
· Creation of job offers outlining employment details and
notification by emails
· Accepting or rejecting job offers by applicants
· Complaints about applicants by employers and about
employers by applicants.
· Blacklisting of applicants.
Requirements:
Applicants
Applicants are restricted to university students but are classified
into local and international students. Local students have no
restriction on employment hours while some jobs will not be
applicable to international students because of hours (maximum
20 hours per week) or other legal or security requirements.

Applicants should be allowed to update past employment
records, references, qualifications, licenses (driving) and
availability. Availability should specify the type (part-time,
full-time, internship), period and applicable job-categories (one
or more from the predefined list). There can be multiple
availabilities, such as a p/t position during semester and an
internship during the summer break. The applicant status must
be updated to available, pending, unknown or employed based
on the employment outcomes and the date of last student
update. To avoid employers wasting their time with students
already employed or have since become unavailable due to other
priorities, their employment status should be changed to
unknown automatically, two weeks after the last update and
must be regularly updated by students if their availability is still
valid.
Employers
Employers should be allowed to search for matching candidates
based on availability and other credentials as well as shortlist,
rank, mail and set possible interview times for selected
applicants. Employers also want to record the results of their
interviews and reference checks in case future opportunities
arise for unsuccessful applicants. For the successful applicants
the details of job offers and responses by applicants must be
captured in the system. Students successful in their application
and being made an offer should be shown as pending thus
avoiding other employers viewing their details and shortlisting
them.
(
)System Maintenance Staff
Maintenance staff have access to all employer and applicant
records. Repeated complaints (three or more) should result in
employers/student accounts being provisionally blacklisted.
During this state, employers cannot offer jobs and students
cannot accept roles. Both still have read only access (able to

view data but not make any changes).
Maintenance staff can view the list of provisionally blacklisted
members and either fully blacklist them or remove the
provisional blacklist – returning the profile to a regular state.
Fully blacklisted employers cannot view availability or offer
jobs and cannot make any changes to the state of the system.
Fully blacklisted student applicants have their profiles
completely disabled – they can log in, but cannot perform any
functions or view any details.
Maintenance staff can also revert any fully blacklisted account
back to normal, but only after 3 months has elapsed from the
date of the full blacklist.
Maintenance staff also may add new job categories such as
“fruit-picking”, “Driver” etc.
Security
The system will limit access to employer details to prevent
students directly contacting them. The system hides phone and
other private details about employers so students can’t contact
them directly. All users should be allowed to change their
username/password.
Reporting Requirements
The following reports are needed to improve and fine tune the
system.
1. Listing of employers making offers, sorted based on the
number of offers made in the specified period
2. List of complaints about specific applicant or employer
3. Jobs offered and accepted by a given job applicant in the past
4. All past offers for a particular category of job.
Archival
Archiving past records is out of scope.
Persistence
Design Documents

Teamwork
how well your individual contribution through individual design
diagrams (such as use case textual descriptions, sequence
to-face marking you will be required to fill a peer revi ew form,
(
)Project Option 4. Project-Teams Formation SystemProject
Overview
You are required to analyse, design, implement and test a tool
for a student-projects manager allowing a fair allocation of
students to teams based on preferences, academic records, skills
and personality types. The project manager assigns a team of 4
students to work as part of a capstone project team where
external clients act as product owners. Students work for 16
weeks on such projects each semester. Currently there are many
more clients (project initiators) than project teams, and teams
are often formed in an ad hoc manner with a poor match
between team members, between teams and projects resulting in
poor student and employer satisfaction. Moreover, the
university regulation imposes specific constraints when forming
teams. Your system design should allow for extensibility,
maintainability and reusability as the tool may be made

available to other institutions.
Requirements:
Client representative
The clients (project initiators) should be invited to make a
presentation with the aim of getting a suitable team to undertake
their project. Each project initiator specifies the roles required
such as Database Administrator (DBA), programmers, leader,
UI designer etc. In addition the project initiator specifies a
number of frameworks they prefer team members for a specific
role to be familiar with. For example, a client may prefer the
person assigned the DBA role to be familiar with Oracle and the
programmer to be familiar with Java and C++.
Student representative
Students should be asked to state their preferences for the first
4 preferred clients (in the order of preference) even if their
preferences cannot always be met. Students should also be
allowed to specify their two preferred roles along with
frameworks, skills or programming languages relevant to those
roles. Students should also be allowed to state up to 3 members
they would not like to form a team with.
Project Manager
I am required to ensure no more than 1 female student is placed
in one team (hard constraints) to ensure gender-balance as less
than 20% of our current students are female. I also classify my
students into 6 personality types (A to F) based on observation
and class tests. For each team formed there must be at least one
of personality type A or B. Moreover, no two members of the
same personality types can be placed in one team (soft
constraint). Every team also should have one member with at
least 5 years of previous work experience (soft constraint).
Every team should have at least two or more students with GPA

3, while no team should have an average GPA exceeding 3.5
(hard constraints). I should be allowed to change the values for
GPAs as the student cohort may vary from year to year.
Stage 1
In the initial stage, I want to discard the projects unpopular with
students by selecting just those students with the most number
of preferences. For example if I have 100 students, I want to
select only the 25 most popular projects (assume all teams have
exactly 4 students).
(
)
Stage 2
In the second stage, I want to assign students to teams based on
preferences and constraints specified by students, cli ents and
myself as the project manager. Some of these constraints are
“hard” constraints and cannot be violated. For the “soft”
constraints, I would like to be able to specify a weight (say 1 to
4) such that the scheduling algorithm (allowing optimal
matching) will give priority to meet the constraints with greater
weights first. The system should allow me to change the weight
for different constraints thus placing greater emphasis on
specific constraints. The scheduling algorithm should come up
with a numerical number showing how good the fit is for each
individual team. For example, if there are 6 soft constraints
which are met, three of which have weight 3 and 3 of which
have weight 2, then the overall satisfaction will be 15
(3x3+3x2). The algorithm should also ensure teams are more or
less equally well fitted.
Stage 3
In the final stage, I want to be able to swap members between
teams manually as long as the overall fitness value for swapped
teams does not change by more than the specified value (to be

input). The tool should facilitate a trial-based approach to
ensuring that the teams formed can be effective.Bonus Marks
Allow graphical user interface for swapping members Allow
visualizing individual and overall fitness
(
Project
4
Project
3
Project
2
Constraint
1
Constraint
2
Constraint
3
Project 1
0
5
10
15
)
Persistence
Design Documents

Teamwork
(
PROJECT OPTION
4
: Page 2/2
)Project Option 5: Multiplayer Interactive Pacman GameProject
Overview
You are required to analyse, design, implement and test a
multiplayer version of the Pacman game where two monsters
(controlled by the server) chases and eats up the player pieces
moving in the predefined grid shown below. The players and
monsters can also move along the arrows shown below to end
up along the opposite edge. The aim of the game is for the
players to escape from the monsters and for the monsters to
block the players’ escape routes and eat up the players. You
game should be designed to be extensible, maintainable and
reusable.All client queries must be directed to your product
owner, your tutor in this project. You may also post general
questions to the Canvas Discussion Board.
Initial Waiting Stage

The first player to login should specify the number of players
(between 2 and 4). The game should start when the required
number of players login and joins in.
Initialization Stage
Each player should be allowed to specify one of the four
remaining corners as the starting cell (top-left, top- right,
bottom-left, bottom-right) in the order they join the game. The
two monsters should initially be placed in the cell at the centre
and be made to move towards the nearest player (least number
of cells in between). The two monsters should coordinate to
with each other to try and block/trap players escape.
Game Play Stage
When two or more players are at equal distance, the monsters
may choose to move towards any one of them randomly. A
player can block any other player by being stationed along the
escape route (with the aim of getting the other player eaten).
Each player has a food piece that they can drop to delay the
monster. A monster must wait for a period of time for the food
to digest before starting the chase again. The game should stop
when only one player is left, who is considered to be the
winner. You may use either sockets and threads (using your own
protocol) or Java RMI (easier) to implement the game.
Post-Game Stage
A protocol should be devised allowing a new game to be played
if all player want to continue. Otherwise the current scores
should be updated on the server.
Bonus: Allow the board grid to be created at run-time (with
variations in configuration).
Project Option 6: Project Management Software
Project Overview
A project manager has approached you to develop a customised
project management software. You are required to analyse,

design, implement and test this tool using an agile approach.
Your system should be made reusable, extensible and
maintainable as requirements continue to evolve.
Requirements:
Jack (the Project Manager)
Currently I am allocating staffs to activities in an ad hoc
manner resulting in project delays and cost overruns. I need
you to design and develop a Task and Staff Scheduler that
assists me to complete the projects I manage within time and
budget. The project involves two parts: scheduling activities
and allocating staffs to activities. For each activity I can
estimate the duration in weeks, the type of skills needed and the
number of staff needed. For each such activity I can also
specify any dependencies on previous activities (if any). The
critical path and the earliest project completion time are
computed based on dependencies on previous activities and the
duration of activities. My main problem however, is allocating
staff to activities as staff may be working on a number of
projects in parallel; staff in our companies can be working
either 20%, 40%, 60% 80% or 100% on a project reflecting the
number of days per week they are engaged in the projects.
I select the staffs for an activity based on whether they have all
the skills needed. Very often full-time staff are underutilised in
specific weeks while in some other weeks we had to hire many
contract staffs. I would like to minimise the number of contract
staff as they expect premium rates to be paid on an hourly basis.
This year, I want a new system that will help me plan all the
activities for all the projects at the beginning of the year and
maximise the usage of our permanent staff. I want the system to

compute the expected project completion date based on the start
date for the project (first dummy activity in the project), the
duration and dependencies (predecessors) for each activity. For
each activity, I also estimate the average number of staff
required (can be fractional) and their required competency
levels in needed skills. Secondly, I would like to have the
option to move the activities not lying along the critical -path
and to experiment with assigning different staff with the
intention of minimizing the dependencies on external staff.
I would like your system to come up with some initial staff
assignments using some simple heuristics, such as assigning the
least experienced full-time staffs first to activities (as more
experienced staff can fit into many different and complex
activities). After assigning all the full-time staff, assign
inexpensive, less experienced contractors first. I would still like
to have an option to change these staffs around manually to do
some trial- and-error.
The system must be able to determine the total cost of the
project based on the allocated staff hours and their hourly rates.
(
)Jim a Full-time developer
I would like a system where I can specify at the beginning of
the year the weeks that are blocked (I am not available due to
annual leave or other duties). I would also like to specify weeks
where I’m partially blocked off as I have a fair amount of non-
project related duties. In such weeks I would like to specify my
availability as 20%, 40%, 60%, 80% and 100%. Though I am
multi-skilled my level of competency and experience vary
significantly. I would like to specify my competency level
explicitly for different skills in a scale of 1 to 10, so that the
manager can select me for activities where I can be really
productive. For example, I am highly competent in Java (10) but

I am weak in Python (4) and domain modelling (4).
Timothy an External Contractor
In the past we had to charge high rates as there were a number
of weeks in a row where we got no work at all followed by
intensive periods. Most contractors including myself prefer to
work on an activity lasting for at least two weeks or more. We
tend to be more productive and happy when working for a
longer period, and are even willing to charge less. I would
therefore like the system to allow me specify different rates for
contracts lasting 1 week, 2 weeks and 4 weeks or more.
Persistence
Design Documents
Teamwork
Bonus Requirements
A GUI version of the project
(

PROJECT OPTION
7
: Page 1/3
)Project Option 7: Internal Stock Trading SystemProject
Overview
You are required to analyse, design, implement and test an
internal stock trading system for employees of a group of
companies involved in manufacturing. In the initial stage you
are required to develop a client server application (RMI or
sockets) without web access; however as a software engineer
you are required to design the systems allowing for
extensibility, maintainability and reusability.
This project is a client server application and is therefore better
suited to those who have already completed Further
Programming or Network Programming.
Requirements by Product Owner
I want a stock trading software for a group of companies where
employees given bonus shares are allowed to trade their stocks.
In the initial development phase the stock trading will run as a
separate system (not linked to the employee benefit system).
The Stock Trading Server Functionality
The server should run continuously allowing new orders to be
added and withdrawn until it is brought down at the end of the
day. Only six stocks belonging to the group are currently traded
(see below). The server must initially start with the following
stock prices. The stock prices will vary as trades are completed.
Server must reject buy/sell orders that are not within ± 5 cents
of the last trade, or are less than 5 cents.
OSX (250)
Ria (340)
NIBC (290)

Vienta (170)
BHT (260)
Cones (470)
Separate queues must be created for items waiting to be sold or
bought at different prices.
· Server must verify and only accept buy/sell orders which are
within +/- 5 cents of the last trade, down to a minimum of 5
cents. If a buy/sell order is valid, a transaction ID (newly
generated) must be assigned (of the form TR080428000001) and
client must be notified.
· Newly ordered items can be traded immediately if there are
offers from ready buyers or sellers in the queue with the
required quantity of stock and within specified price. If only
part of the offer can be traded now, an offer with the remaining
quantity must be added to the buy/sell priority queue. For
example, if for a new sell order of 5000 BHT shares at 250
cents, only 1000 shares can be traded at that price (or higher)
now, the remaining quantity is 4000.
· Buy or sell orders queued at the same price, must be traded on
a first come first served basis. However if the prices are not the
same, the queues offering the highest possible price must be
traded first when selling, and lowest possible price when
buying.
· The maximum number of shares must be traded whenever an
item is offered. Partial trades must be conducted if only partial
match can be found for an offer. A trade affects both the client
making a new offer and the clients with offers in the queue. All
affected clients must be notified of the result of trade. Note a
trade may cause offers waiting in the queue to be removed or
the remaining quantity to be updated. Two different cases are
given below, applicable when a new buy offer is made. (Similar
cases apply for sell offers). It is assumed that offers for sell
queues are arranged with higher priority for lower price – as
lower priced offers will be traded first with a potential buyer.
Similarly, buy queues are arranged with higher priority for

higher prices as higher priced offers will be traded first with a
potential seller.
Example 1:
Assume only two offers are queuing to sell BHT shares, first
one (from client A) for 1000 shares at 270 and the second (from
client B) one for 1000 shares at 280. At this stage, if another
client (client C) offers to buy 1500 BHT shares at 290, the offer
at 270 (from client A) must be removed from the sell queue, and
the quantity for the one queuing at 280 (from client B) must be
reduced to 500 (resulting in two trades). Also, buyer (client C)
gets a trade done with all 1500 shares he/she offered to buy. All
three clients (A, B, and C) must be notified of the trade and
their trade details must be saved.
Example 2:
Assume only three offers are queuing to sell BHT shares, first
one (Client A)for 1000 shares at 270, second one (client B) for
1000 shares at 280, and third one (client C) for 1000 shares at
295. At this stage if a client (client D) offers to buy 2500 BHT
shares at 290, the offers at 270 and 280 (client A and B) must
be removed from the sell queue (resulting in two trades) but the
offer queuing at 295 (client C) must be left intact as this price
is higher than what the buyer is willing to pay. As the buyer
(client D) gets only a partial trade done, with 2000 shares, an
offer for the remaining quantity, 500 BHT shares at 290 must be
placed in the buy queue. All three affected clients (A, B and
D) must be notified of the trade and their trade details must be
saved.
Registration
Before clients are allowed to buy and sell shares, a registration
process must be completed passing username and password.
Server must validate the following:
· Username must be unique.
· Username and password must have at least 8 characters.
If registration is successful, server must generate a unique
account-ID and notify the client. All subsequent transactions
including buying, selling withdrawing and viewing must pass

valid username and password. Account-ID should be used for all
orders and transactions (i.e. database records should be
associated with account-IDs rather than usernames).
Viewing Stock Prices
I need a view option that allow clients to view the foll owing
using appropriate GUI
· Current Stock price (based on last trade)
· Current buy/sell orders queued by this customer
The second option must show stock code, remaining quantity,
desired price and current price (last traded price).
Buy/Sell Options
You must provide options for placing buy and sell orders for
any of the shares currently traded at specified price. The share
price offered must be quoted in cents, in steps of 1 cent.
Maximum number of shares purchased in one trade must be
limited to 10,000. The server is required to validate the data
sent. If the server detects any anomaly and throws an exception,
it must be caught and displayed, otherwise the transaction ID
generated and returned by the server must be displayed (which
may be required for future transactions).
When an order is placed the client must be notified of the
quantity bought/sold and the quantity being queued. If a queued
item is bought/sold at a later time the server must notify all
clients affected by the trade using callbacks. A good user
interface must alert clients when a queued item is traded (using
UI elements such as pop-up).
Withdraw Order
This option must allow clients to withdraw all remaining unsold
stocks in any buy/sell orders made earlier, by quoting the
transaction ID for the order.
(
PROJECT OPTION 7: Page
3

/3
)Monitoring Unusual Patterns
System should send notification to management when unusual
buy or sell activities are noted possibly indicating some insider
trading. The system should allow unusual activities and
thresholds to be defined dynamically through the interface.
Transaction History
Auditors and clients must be allowed query all transactions
completed between specific dates by specific clients. The server
must access the completed trades to access the required
information.
Sever Shutdown
When the server is brought down all queued items must be
discarded.
Persistence
All trades done must be persisted. The data may be stored as
Bonus Mark: Chart Option for Premium Clients
This option offered only to premium clients must allow users to
view the specified stock price movement in the last 30 minutes
using appropriate graphs. These graphs must be dynamically
updated. The stock price data stored must be restricted to last
30 minutes. You must also do the necessary scaling to fit the
graph.
(
13:45
...
13:15
)2.88

2.70
Design Documents
Teamwork
Project Option 8: Collaborative Snakes and Ladders
GameProject Overview
You are required to analyse, design, implement and test a
collaborative snakes and ladders game, where snakes are free to
roam around while humans (represented by pieces) aim to
destroy all the snakes after acquiring special powers (when one
piece reaches 100). You are required to design the system
allowing for extensibility, maintainability and reusability as the
game rules may be changed in the next version. The purpose of
this assignment is to create a Collaborative Snakes and Ladders
game. This adds many rules and stages to the traditional game,

making it more strategic and collaborative. You will be
provided with the necessary methods to draw the board,
snakes and ladders allowing you to focus on the design and
implementation of the collaborative version of the game
(instead of the low level GUI details).
Canvas Discussion Board. Note you may also make up your own
collaboration game rules or incorporate other objects subject to
you getting approval from your tutor.
Background: Standard Snakes and Ladders Game
Snakes and Ladders Game is an ancient game created to depict
the struggle faced by humans through good and evil forces as
they go through life. The ladders represent moving up to a
higher moral plane with the help of benevolent beings, while
going down the snakes represent being dragged down to a more
immoral level through evil powers. Snakes and Ladders game
was designed for 2 or more players and is played on a board
with 100 squares numbered 1 to 100. Play begins on square 1
and finishes on square 100. Players take turns to roll a dice and
move along the number rolled. If a player rolls a 6, the player
may, after moving, immediately take another turn; otherwise
play passes to the next player in turn. If a player lands on a
square that has the bottom of a ladder upon it, the position is
automatically advanced to the top of the ladder. Similarly, if a
player lands on a square, which has the head of a snake upon it,
then the player must automatically follow down to the tail of the
snake. The winner is the player who is first to land on the
square numbered 100. You must roll the exact number needed to
land on 100.Actors in the proposed electronic version: Admin,
Human Controller, Snake Controller
The first actor playing the role of admin creates the board
layout before commencement of the game in stage
1. The other two actors are the ones controlling the placement
of snakes (snake controller) and pieces (human controller) take

turns to move as the game is played in stages 2 and 3.
Overview of Main Stages and Actors
In the first stage the 5 snake and 5 ladder objects are laid on the
board by the admin. The 4 pieces representing the location of
humans are initially all placed in position 1.
In the second stage the human controller try to overcome the
snakes (evil) by getting one of the pieces representing humans
to reach the location 100 within 50 turns (subject to throwing a
dice each time and adhering to specific constraints outlined
below). Snakes are moved by the snake controller by moving a
snakehead diagonally one unit at time (subject to specific
constraints). In the 2nd stage if one of the pieces managed to
get to 100 within the stipulated number of times, the 3rd stage
commences.
In the third stage the remaining pieces (all excluding the one
reaching 100) are given special powers to move and to destroy
the snakes by landing on their tails (there is no need to throw a
dice in the 3rd stage). Snakes can also destroy a piece, if the
snakehead moves to the location of any piece or if a piece lands
on top of a snakehead.
(
PROJECT OP
TION
8
:
Page 1/3
)Detailed Requirements by Game Designer:
Initial Stage
· The Board layout controller should be allowed to lay 5 snakes
and 5 ladders with the specified end points. The difference
between snakes and ladder end-points (Snake head and tail or
ladder top and base) cannot be more than 30.
· The ladder top or base cannot be placed on a snake’s head
location and a ladder base cannot be placed on top of another

ladder’s head. There should be no ladder base at location 1 and
no ladder top at location 100.
· A snake’s head cannot be placed on top of an existing ladder
head, ladder base or next to another snake’s head (to prevent all
the snakes clinging together). Only one snake (head) can be in
locations 81 to 100 at any one time.
· Once all the snakes and ladders are placed four pieces
(representing humans) should be placed in the initial position of
1.
Second Stage
· In this stage the main aim is for the human controller to get
one piece representing human to reach 100 having already
climbed 3 distinct ladders, while the snake’s controller attempts
to prevent this happening. (Note: no piece representing a human
should be allowed to reach 100, without having climbed at least
3 ladders before). Only one snakehead can be in locations 81 to
100 at any one time.
· When a snake’s head moves over a player or a player moves
over a snake’s head the player is pulled down to the tail
position and the player remains in a paralysed state for 2 moves.
A player can prevent a snake from moving to a specific location
by placing a snake guard (losing a turn), and the location will
be guarded until the end of the stage. The number of snake
guards is limited to 3.
· Whenever it is the turn of the snake, the snake’s head can be
moved diagonally by 1 unit (in any direction) subject to snake
endpoints remaining within the board. When the snakehead
moves to a new location the difference between the top and the
base of the snake (snake length) remain constant.
· When a dice is thrown, the human controller must move one of
the pieces by the dice value unless all humans are in a paralysed
state or cannot move by that value. A piece can only climb a
given ladder only once. Moreover, a player can land at 100 only
if that piece had already climbed at least 3 distinct ladders
before. At this stage the final stage commences.
Final Stage

· In this stage the human controller has to destroy all the snakes
without losing any piece, within 20 moves. Players can use the
new acquired powers to move along the path of a knight piece in
a chessboard or to the adjacent diagonally placed element.
· A snake can be made to destroy a player in this stage by
placing a snakehead on the player or by getting the player to
land on a snakehead. Both pieces and snakes take turns to move.
· Moving the snakehead diagonally results in relocating the
snake (the head and tail of the snake must remain within the
board).
· If all the snakes are destroyed without any loss of a human
piece the humans are the winners but if even if a single human
piece is destroyed the snakes are considered the winners and the
game comes to an end.
(
PROJECT OPTION
8
:
Page 2/3
)Who is this Project suitable for?
This project is suitable for those having an interest in graphics
and multimedia but lacking the knowledge of underlying
graphics (sample code provided for drawing the entities snakes,
ladders, pieces and the board). This project therefore allows
students to focus on the OO design instead of the underlying
GUI constructs (Swing). You will be expected to pick up some
basic Java Swing but the sample code should be adequate for
most of the functionality.
Other Requirements
Allow a login feature for the players controlling the human and
snake characters.Bonus: (both of the following)
· The strategy for the ladders and snakes must be automated
allowing the game to be played without inputs for moves of
ladders and snakes with the objective of making the players win
and lose the game respectively.

· Allow the game state to be saved and retrieved.
Design Documents
Teamwork
(
)
Stock Trading System
Client
Manager
Auditor
Login
Sell
Notify Unusual trading
<<include>>
M1

M2
M3
M4
Query Transactions
<<include>>
M1
M2
M3
M4
Buy
Register
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
View Price
View Queued Orders
Premium Client
View chart
M1
M2
M3
M4
M1
M2
M3
M4
M1

M2
M3
M4
<<include>>
M1
M2
M3
M4
M1
M2
M3
M4
<<include>>
M1
M2
M3
M4
<<include>>
M1
M2
M3
M4
<<include>>
M1
M2
M3
M4
Withdraw Order
Notify unsuccessful
Set threshold logic
Set activity logic
<<extend>>
M1
M2
M3
M4

<<extend>>
M1
M2
M3
M4
<<extend>>
M1
M2
M3
M4
<<extend>>
M1
M2
M3
M4
M1
M2
M3
M4
Add Funds
Withdraw Funds
M1
M2
M3
M4
<<include>>
M1
M2
M3
M4
<<include>>
M1
M2
M3
M4
Make Premium

<<include>>
M1
M2
M3
M4
M1
M2
M3
M4
View Transaction History
M1
M2
M3
M4
<<include>>
M1
M2
M3
M4
Register User
Register Manager
Register Auditor
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
Deregister
M1

M2
M3
M4
<<extend>>
M1
M2
M3
M4
<<extend>>
M1
M2
M3
M4
<<extend>>
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
Set Logic
M1
M2
M3
M4
M1
M2
M3
M4
M1

M2
M3
M4
StockMarket
<<Stereotype>>
parameter
Login
<<Stereotype>>
parameter
Order
<<Stereotype>>
parameter
M1
M2
M3
M4
User
<<Stereotype>>
parameter
0..1
Client
<<Stereotype>>
parameter
Manager
<<Stereotype>>
parameter
M1
M2
M3
M4
Auditor
<<Stereotype>>
parameter
ClientLogin
<<Stereotype>>

parameter
ManagerLogin
<<Stereotype>>
parameter
AuditorLogin
<<Stereotype>>
parameter
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
ViewPrice
<<Stereotype>>
parameter
PremiumClient
<<Stereotype>>
parameter
M1
M2
M3

M4
ViewQueued
<<Stereotype>>
parameter
ViewHistory
<<Stereotype>>
parameter
ViewChart
<<Stereotype>>
parameter
NotifySuccessful
<<Stereotype>>
parameter
NotifyUnsuccessful
<<Stereotype>>
parameter
QueueOrder
<<Stereotype>>
parameter
Buy
<<Stereotype>>
parameter
Sell
<<Stereotype>>
parameter
MatchOrder
<<Stereotype>>
parameter
QueryTransactions
<<Stereotype>>
parameter
Transactions
<<Stereotype>>
parameter
SuccessfulOrder
<<Stereotype>>

parameter
Withdraw
<<Stereotype>>
parameter
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
UnusualTrade
<<Stereotype>>
parameter
Shutdown
<<Stereotype>>
parameter
AddFunds
<<Stereotype>>
parameter
MakePremium
<<Stereotype>>
parameter
SetLogic
<<Stereotype>>
parameter
SetThresholdLogic
<<Stereotype>>
parameter
SetActivityLogic
<<Stereotype>>

parameter
Registration
<<Stereotype>>
parameter
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4

M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4

M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
M1
M2
M3
M4
User:users[]
Stock:Stocks[]
-memberName
-memberName
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
userName:String
password:String
emailAddress:String
+getMemberStatus():String

-memberName
mainMenu()
-memberName
-memberName
-memberName
-memberName
-memberName
-memberName
-memberName
-memberName
-memberName
-memberName
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
-memberName
-memberName
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()

Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()

Sell()
MainMenu()
Transaction:Transactions[]
Query()
Transaction:Transactions[]
logTransaction()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
Stock:String
Volume:Integer
Value:Integer
Buy()
Sell()
MainMenu()
UnusualTrade:UnusualTrades[]
checkTransaction()
shutdown()
register()
deregister()

StockMarketLoginOrderUser0..1ClientManagerAuditor ClientLo
ginManagerLoginAuditorLoginViewPricePremiumClientViewQ
ueuedViewHistoryViewChartNotifySuccessfulNotifyUnsuccessf
ulQueueOrderBuySellMatchOrderQueryTransactionsTransaction
sSuccessfulOrderWithdrawUnusualTradeShutdownAddFundsMa
kePremiumSetLogicSetThresholdLogicSetActivityLogicRegistra
tionUser:users[]Stock:Stocks[]-memberName-
memberNameStock:StringVolume:IntegerValue:IntegerBuy()Sel
l()MainMenu()userName:Stringpassword:StringemailAddress:St
ring+getMemberStatus():String-memberNamemainMenu()-
memberName-memberName-memberName-memberName-
memberName-memberName-memberName-memberName-
memberName-
l()MainMenu()-memberName-
l()MainMenu()Stock:StringVolume:IntegerValue:IntegerBuy()S
ell()MainMenu()Stock:StringVolume:IntegerValue:IntegerBuy()
Sell()MainMenu()Stock:StringVolume:IntegerValue:IntegerBuy
()Sell()MainMenu()Stock:StringVolume:IntegerValue:IntegerBu
y()Sell()MainMenu()Stock:StringVolume:IntegerValue:IntegerB
uy()Sell()MainMenu()Stock:StringVolume:IntegerValue:Integer
Buy()Sell()MainMenu()Stock:StringVolume:IntegerValue:Integ
erBuy()Sell()MainMenu()Stock:StringVolume:IntegerValue:Inte
gerBuy()Sell()MainMenu()Transaction:Transactions[]Query()Tr
ansaction:Transactions[]logTransaction()Stock:StringVolume:In
tegerValue:IntegerBuy()Sell()MainMenu()Stock:StringVolume:I
ntegerValue:IntegerBuy()Sell()MainMenu()UnusualTrade:Unusu
alTrades[]checkTransaction()shutdown()register()deregister()

Functionalities to be coded and estimated complexity Manager

Functionalities to be coded and estimated complexity Manager

Recommended

Recommended

More Related Content

Similar to Functionalities to be coded and estimated complexity Manager

Similar to Functionalities to be coded and estimated complexity Manager (20)

More from SusanaFurman449

More from SusanaFurman449 (20)

Recently uploaded

Recently uploaded (20)

Functionalities to be coded and estimated complexity Manager