6: Coordinating Software Development
Spring 2008, David Matuszek
This is a simulation of Programmers working on a software project. At each weekly meeting they decide on a number of tasks to be performed by each person. Each task takes a certain amount of time, and each person does their tasks in order. All tasks are finished in time for the next meeting.
Your assignment is to write a simulation of this software project.
Programmer is to be implemented by a separate
At each meeting, each programmer takes on some number of tasks. The amount of time required for each task is determined at the meeting (use a random number, from 4 to 20 hours). Each programmer will have enough tasks to require at least 32 hours, but not more than 40 hours. Since all the programmers are MCIT graduates, they always finish their tasks in the allotted time.
In your simulation, each Programmer uses
pause for the
appropriate amount of time. (In our simulation, one millisecond of computer
time represents one hour of Programmer time.)
In our example we will assume four Programmers:
Bob, Carol, Ted, and Alice. Your program should, of course, allow for any
number of programmers (use an
ArrayList or similar to keep track
of them). Each programmer has a name and an individual task list, and each
Programmer executes in a separate Thread.
As soon as each task is finished, the Programmer merges it into the project repository. That is, if Alice finishes her first and second tasks before Ted finishes his first task, then the program reports Alice's first and second tasks before it reports Ted's first task. Do this by using a synchronized queue; each Programmer (Thread) can insert something onto the queue at any time, and what they insert is a statement that they have finished the task, along with the amount of time it took. You should print out the queue just before the next meeting.
When each Programmer is done with all of their tasks for the week, they wait for all the other Programmers to finish, then they have a meeting and decide on the next week's set of tasks. Since this is a fairly short software project, it will be completed after four weeks.
Output should look something like this:
Output Meeting #1 Bob has tasks requiring 11, 11, 8, 7 hours. Carol has tasks requiring 16, 14, 9 hours. Ted has tasks requiring 18, 11, 6 hours. Alice has tasks requiring 5, 9, 7, 18 hours. Alice finishes task number 11 after 5 hours. Bob finishes task number 1 after 11 hours. Alice finishes task number 12 after 14 hours. Carol finishes task number 5 after 16 hours. Ted finishes task number 8 after 18 hours. Alice finishes task number 13 after 21 hours. Bob finishes task number 2 after 22 hours. Ted finishes task number 9 after 29 hours. Carol finishes task number 6 after 30 hours. Bob finishes task number 3 after 30 hours. Ted finishes task number 10 after 35 hours. Bob finishes task number 4 after 37 hours. Carol finishes task number 7 after 39 hours. Alice finishes task number 14 after 39 hours. Meeting #2 Bob has tasks requiring 11, 8, 6, 15 hours. etc. ... Project completed! Order in which tasks were completed: 11 1 12 5 8 13 2 9 6 3 10 4 7 14 15 25 21 26 22 18 16 19 23 27 28 20 17 24 29 33 40 37 30 34 35 38 41 31 39 36 42 32 50 43 47 53 44 48 45 51 46 54 52 49
In the above example, Bob is assigned tasks 1 through 4, Carol gets tasks 5, 6, and 7, Ted gets tasks 8, 9, and 10, and Alice gets tasks 11 through 14.
All four programmers set to work simultaneously. Alice's first task (#11) is the shortest--5 hours--so she is the first to finish a task. Bob's first task (#1) takes 11 hours, so he finishes that six hours later; by then, Alice is six hours into her second task (#12). Then Alice finishes her second (9 hour) task three hours later. Next, Carol finishes her first task (#5, requiring 16 hours), then Ted finishes his 18 hour task (#8).
At this point (after 18 hours), Alice is four hours into her third task, Bob is seven hours into his second task, Carol is two hours into her second task, and Ted is just starting his second task. Work continues in this way until all tasks are completed.
Tasks are numbered sequentially; task numbering does not start over each week.
Task synchronization is another area (along with GUIs) where JUnit testing is not very useful, so it is not required (or even recommended) for this project. You will have to decide if your program is behaving correctly by carefully examining your output. We will have to do the same , so be sure your output is complete and self-explanatory.
We will also be looking at the quality of your code. This means the usual: Good variable names, no unnecessarily complex code, correct formatting, etc. Since this assignment is all about tracing program behavior (to see if things happen in the correct order), it doesn't really make sense to separate computation from input/output; you should print out events as they occur.
Like recursion, threads are simple in theory, but can be extremely confusing when you first encounter them. This assignment can actually be written with a simple, clean design; but your program will probably be much more complex than it needs to be. We may award bonus points if we see any particularly well-designed programs.
As always, good Javadoc is required. If you haven't already been doing so, you should generate the Javadoc and look at the results in a browser; seeing how it looks will help you improve it.
Zip the complete project, including the generated Javadoc, and submit via Blackboard before midnight, Thursday March 6.