School of Computing and Information Systems SWEN90004 Modelling Complex Software Systems
Assignment 1a, 2021
Released: 7 March 2021; Deadline: 23:59, 28 March 2021
The objectives of this assignment are: to convert a description of a system into a simulation model of that system; to implement that simulation in a shared memory concurrent programming language; to use the implemented simulation to explore the behaviour of a complex system; to gain a better understanding of safety and liveness issues in concurrent systems.
Background and context
There are two parts to Assignment 1 (a and b), each worth 10% of your final mark. This first part of the assignment deals with programming threads in Java. Your task is to implement a concurrent simulation model of a vaccine fill/finish inspection system.
Widespread vaccination is anticipated to have a substantial impact on reducing COVID-19 outbreaks. Globally, it is anticipated that 15 billion vaccine doses will be required. Delivering this many vaccine disease safely and efficiently requires effective production technologies. An important component of vaccine production is the fill/finish process, where vials are filled with vaccine and packaged. This process can be a bottleneck in production, as it is necessary to inspect packaged vials to ensure they meet government regulations. Visual inspection of vials involves checking that there are no foreign contaminants in the vial, that it is filled to the correct level, and that it is correctly sealed. Visual inspection can be time-consuming if applied to all vials, and a more efficient system is needed.
The system to simulate
The system to be simulated is a vaccine fill/finish inspection station (Figure 1). The purpose of the inspection station is to ensure that no defective vials of vaccine are packaged and distributed. The simulated part of the system is responsible for moving the vials through the inspection station on a disc- shaped carousel, which is rotated in a clockwise direction by a carousel driver and has five compartments, each of which can hold a single vial of vaccine at a time.
Vials are placed into the compartment at the first position of the carousel at random intervals by a producer. A scanner mounted on the carousel in compartment three performs a rapid assessment of vials as they pass, sounding an alarm when it detects a defective vial that requires a more detailed visual inspection. The scanner has high sensitivity (ie, it will always detect defective vials) and high specificity (ie, it will only sound the alarm for defective vials).
When the alarm sounds, the vial currently in compartment three will be moved to a bay for a more detailed inspection by an inspector. There is a single inspection bay which can hold only one vial at a time. If the visual inspection determines that a vial is defective, it will be tagged for destruction.
The inspected vial (either tagged or not) is then returned to position three of the carousel. Movement of vials to and from the inspection bay is handled by a single bi-directional shuttle, which can also hold only one vial at a time. Upon reaching position five of the carousel, vials are removed from the inspection station by a consumer. Beyond the scope of the subsystem you will simulate, tagged vials will be recycled, while those that are not tagged will be packaged for distribution.
Figure 1: The vaccine fill/finish inspection station to be simulated, showing: the rotating carousel con- taining five numbered compartments, each of which may be empty, or contain a vial of vaccine; the producer that places new vials into compartment one (when it is empty); the consumer that removes vials from compartment five (when it contains a vial); the scanner (red) that detects whether a vial should be inspected; the inspection bay, where vials are inspected and potentially tagged for destruction; and the shuttle, that moves vials backwards and forwards between the carousel and the inspection bay.
A partial solution
In the context of Java, it makes sense to think of the carousel and inspection bay as monitors. A possible set of active processes would then be:
Producer: Generates new vials and places them in compartment one (when it is empty). The times between arrivals should vary.
Consumer: Removes vials from compartment five.
Carousel Driver: Rotates the carousel as often as possible, but only when there is at least one vial in
compartments one to five.
Shuttle: Moves vials that have been flagged for inspection to the inspection bay, and then back onto the carousel.
We have made scaffold code available on LMS that follows this outline described above. The compo- nents we have provided are:
Producer.java and Consumer.java: , which are responsible for generating new vials and placing them on the carousel (producer), and removing vials from the carousel after inspection (consumer).
Carousel.java The carousel which holds vials of vaccine in compartment.
CarouselDrive.java Responsible for rotating the carousel.
Vial.java: Vials of vaccine can be generated as instances of this class.
Params.java: A class which, for convenience, gathers together various system-wide parameters, includ- ing a number of timing parameters.
Sim.java: The overall driver of the simulation. Note that this won’t compile until you have defined some additional classes.
This code will compile and run; however, the system does not perform as specified, as several compo- nents are missing and defective vials are not tagged before they are removed by the consumer.
Your first task is to implement a simulator for the system as described above. Use your simulator to explore the behaviour of the system, and identify any potential issues that may prevent the smooth operation of the vaccine fill/finish inspection station.
The simulator should produce a trace of events along the lines of that shown below:
V:001(d--) inserted V:001(d--) [ c1 -> c2 ]
V:001(d--) [ c2 -> c3 ] V:001(d--) [ c3 -> S ] V:001(d--) [ S -> I ]
V:002(---) inserted V:002(---) [ c1 -> c2 ]
V:002(---) [ c2 -> c3 ] V:001(dit) [ I -> S ] V:002(---) [ c3 -> c4 ] V:001(dit) [ S -> c3 ] V:002(---) [ c4 -> c5 ] V:001(dit) [ c3 -> c4 ]
V:002(---) removed V:001(dit) [ c4 -> c5 ]
V:003(d--) inserted V:003(d--) [ c1 -> c2 ]
V:003(d--) [ c2 -> c3 ] V:003(d--) [ c3 -> S ] V:003(d--) [ S -> I ]
In the above trace, the first vial (V:001) inserted into the carousel by the producer is defective (indicated by the “d” flag). Hence, when it reaches compartment 3 (c3) it is transferred to the shuttle (S) and then to the inspection bay (I) to be inspected. Once the inspection is complete (indicated by the “i” flag), it is tagged to be recycled (indicated by the “t” flag) and transferred back to compartment 3 (c3) by the shuttle. Upon reaching compartment 5 (c5), it is removed from the carousel by the consumer. Note the second vial (V:002) was not defective, it didn’t need to be inspected, and could proceed around the carousel while the first vial was still being inspected and removed before the first vial.
You should provide two solutions in this project:
Solution 1: First assume that all vials are returned to compartment 3 of the carousel after they have been inspected. This is not an ideal solution, but we want to see it implemented because Assignment 1b will make use of it.
Solution 2: As a second solution, introduce an additional carousel to take vials from the inspection bay after they have been inspected. This carousel needs just two compartments, one to receive vials from the inspection bay, and the other from which vials are removed for destruction (by a consumer).
Your second task is to write a reflection of approximately 500 words that evaluates the success or otherwise of your implementation, and identifies critical design decisions or problems. You should sum- marise insights you gained from experimenting with the simulator, in particular any issues you identifed with the performance of the system, and how the second solution addresses these (or not).
Note: You should complete this task using the Java concurrency constructs that we have covered in class (ie, monitors, etc); you should not make use of the high-level concurrency objects from the concurrency library.
Procedure and assessment
- The project should be done by students individually.
- Late submissions will attract a penalty of 1 mark for every calendar day it is late. If you have areason that you require an extension, email Nic well before the due date to discuss this.
- You should submit a single zip file via LMS. The zip file should include:
- Adirectorynamedsol_1containingallJavasourcefilesneededtocreateafilecalledSim1.class, such that running “javac Sim1.java” will generate Sim1.class, and running “java Sim1” will then start the simulator and execute your Solution 1 implementation.
- Adirectorynamedsol_2containingallJavasourcefilesneededtocreateafilecalledSim2.class, such that running “javac Sim2.java” will generate Sim2.class, and running “java Sim2” will then start the simulator and execute your Solution 2 implementation.
- A plain text file named reflection.txt containing your reflection. Please ensure that this is a plain text file; ie, not a doc, docx, rtf, or other file type that requires specific software to read.
All source files and your text file should contain your name and student number at the top of the file.
- If you use an IDE to implement your code, please ensure that it can be compiled and executed independently of the IDE (ie, by compiling and executing from a command line).
- We encourage the use of the LMS discussion board for discussions about the project. However, all submitted work must be your own individual work.
- This project counts for 10 of the 40 marks allocated to project work in this subject. Marks will be awarded according to the following guidelines:
Understanding Correctness Design
Structure & style Reflection
The submitted code is evidence of a deep understanding of con- current programming concepts and principles.
The code runs and generates output that is consistent with the specification.
The code is well designed, following appropriate principles of ab- straction, encapsulation, etc.
The code is well structured, readable, adheres to the code format rules (Appendix A), and is well commented and explained.
The reflection document demonstrates engagement with the project.
3 marks 2 marks 2 marks 2 marks 1 marks
Nic Geard 8 March 2021 ⃝c The University of Melbourne, 2021
A Code format rules
Your implementation must adhere to the following simple code format rules:
- Every Java class must contain a comment indicating its purpose.
- Every method must contain a comment at the beginning explaining its behaviour. In particular, any assumptions should be clearly stated.
- Constants, class, and instance variables must be documented.
- Variable names must be meaningful.
- Significant blocks of code must be commented.
However, not every statement in a program needs to be commented. Just as you can write too fewcomments, it is possible to write too many comments.
- Program blocks appearing in if-statements, while-statements, etc., must be indented consistently. They can be indented using tabs or spaces, and can be indented 2, 4, or 8 spaces, as long as it is done consistently.
- Each line should contain no more than 80 characters.
本网站支持 Alipay WeChatPay PayPal等支付方式
E-mail: email@example.com 微信号:vipnxx