程序代写代做代考 concurrency Java The University of Melbourne
The University of Melbourne
Department of Computing and Information Systems
SWEN40004 Modelling Complex Software Systems
Assignment 2b, 2015
Released: 11 May. Deadline: 29 May at 23:00
Objective
To use a higher-level modelling language to specify and reason about a concurrent system.
Background and context
Assignment 2 has two parts. The first part, 2a, was worth 10% of your final mark; this part,
2b, is worth 15%. In the first part you designed and implemented (in Java) a simulator for a
baggage handling system. In fact, two solutions were asked for: a solution that failed to ensure
progress of all components, and a second solution that avoided that problem. Now the task is
to model both systems in FSP, to use LTSA to check both, and to identify the problems that
may be discovered through modelling.
The tasks
There are three documents to submit and five sub-tasks to do. Remember to include your name
on each submitted document.
First, model and check the two solutions you submitted in Assignment 2a. For each:
• Model: Model your Java implementation in FSP. That is, reverse engineer a FSP model
from the Java code. Try to capture the essential interactions between the components—
no more than that. The models should contain comments that explain the design and its
components. As examples of what is expected for comments, see the published solutions
to the Week 9 and 10 workshops.
• Check: Specify what you believe are the relevant safety and liveness properties for your
FSP model. Use LTSA to check these properties.
When these four sub-tasks have been completed, reflect on the experience, keeping your discus-
sion to 400 words or less:
• Discussion: Which problems did you find in the two models as a result of using LTSA?
Were these problems also present in the Java implementation? If you find problems with
the Java solution submitted for 2a2, why do you think you picked these up now and not
before submitting the Java code? If you did not find problems with your 2a2 submission,
were you convinced when you submitted Part 2a2 that no problems existed? Why did you
believe this? Do you still believe there are no problems?
Procedure and assessment
The assignment should be completed by students individually. The submission deadline is Friday
29 May at 23:00. A late submission will attract a penalty of 2 marks for every calendar day it is
late. If you have a reason that you require an extension, email Harald well before the due date
to discuss this.
To tackle the assignment, first work through (and understand) the examples from lectures,
and do the workshop exercises. FSP is not difficult—it is simpler than most programming
languages, and much simpler than languages like Java. However, as with other languages, the
way to master it is to use it, and to learn by doing. Trying to do the assignment straight up
means you may struggle. Work through some easier examples first.
Submit a single zip file via the LMS. The file should include
• A file called bad.lts with an FSP model for task 2a1, including the relevant safety and
liveness properties.
• A file called good.lts with an FSP model for task 2a2, including the relevant safety and
liveness properties.
• A file called discussion.txt or similar, containing the discussion of issues.
• Optionally, and only where relevant, a directory containing an updated (corrected) Java
implementation for 2a2, in case LTSA discovered a problem.
We encourage the use of the LMS’s discussion board for discussions about the project. However,
all submitted work is to be your own individual work.
This project counts for 15 of the 50 marks allocated to project work in this subject. Marks
will be awarded according to the following guidelines:
Criterion Description Marks
Clarity, abstraction Descriptions of all actions and processes are clear and con-
cise. FSP models are at a suitable level of abstraction. Only
the behaviour relevant to interaction is specified, and there
is sufficient detail to implement the concurrency objectives
from the model.
4 marks
Correctness Both models accurately reflect the original implementations.
The “good” model behaves correctly, is free from deadlock,
does not violate any safety properties, and demonstrates
liveness properties.
4 marks
Completeness The model is complete. All components have been modelled
and all expected behaviour is present. All expected safety
and liveness properties have been described.
3 marks
Formatting The FSP source adheres to the code format rules from Part
2a where this makes sense, including the use of comments.
2 marks
Discussion The discussion shows understanding of the subject material. 2 marks
Total 15 marks
Why backwards?
A valid question: Why are we modelling the baggage handling system after implementing it?
Should it not be done the other way? Well, yes and no. Many people use modelling to understand
an existing code base (just look at the number of tools for reverse engineering UML models from
code bases). Reverse engineering is a great way to understand problems with an existing system;
for example, why a deadlock is occurring. It is true, however, that in most cases, it would be
cheaper and easier to do the modelling first.
The other reason why the assignment is “backwards” is that trying to model a system using
a new type of notation, such as FSP, will often end in disaster. We hope that, having gone
through the Java programming stage, you feel familiar with the system to be modelled and thus
can concentrate on the use of FSP. The exercise should be one of applying abstraction—a skill
that is of utmost importance in any engineering discipline.
Harald Søndergaard
10 May 2015
