As the queue is an important component in the sequence you are presenting, it should most definitely be present with a lifeline.
As the consumer explicitly listens for events from the queue, I would start the diagram with the listen call from the consumer to the queue.
After that, the producer can insert its event into the queue (possibly with an indication that a considerable amount of time can elapse between the listen call and the insertion of the event). At this point, I would use two return arrows. One back to the producer to indicate completion of the insert call, and the other to the consumer to indicate completion of the listen call.
This is under the assumption that the producer and consumer execute asynchronously.
It would look like this:
+---+ +---+ +---+
| P | | Q | | C |
+---+ +---+ +---+
| | listen |
| | <|------- |
| | |
| insert | |
| -------|> ++ |
| < - - - - ++ event |
| ++ - - - - >++
| | ++
| | ++
| | listen ++
| | <|------- ++
| | |
To indicate that the consumer is always listening, I have ended the diagram again with a listen call that hasn't returned.
Since this is a homework assignment, the best thing that you can do is ask your instructor for input. The person grading you has expectations, just like in the workplace your coworkers, managers, and customers have expectations. The expectations need to be defined by the person receiving the work.
That said, I can provide my take on how to structure a use case diagram for this particular situation.
The first thing that I would do is to identify the external-facing operations that your simulator system exposes. The text of your question identifies a few - load a configuration file, run the simulation, view statistics. Are there others? Can you pause simulations? Or adjust configuration in the middle of a simulation? Or export the statistics to various formats? Anything else that your system exposes to a user or outside system should be given a use case "bubble".
Next, I would define relationships between the use cases. The three relationships that appear on a use case diagram are extends, includes, and inherits. The extend relationship allows one use case to continue beyond the base use case. If Use Case B extends Use Case A, then all of the steps in Use Case A are completed prior to executing Use Case B. The includes relationship captures dependencies and allows behavior from one use case to be included in another. If Use Case B includes Use Case A, then the operation of Use Case A is available as part of Use Case B but does not state where during the execution of Use Case B it is used or if it is required or not. Finally, inheritance allows for a use case that inherits some of the operations of a different use case but changes or adds additional steps.
Third, I'd identify all of the actors on the use case. These would be human users or external systems that interact with the system under design. It may be wise to consider roles. Humans of different roles may have different access to functions.
Finally, I'd identify relationships between actors. One actor may be a superset of another actor, and this can be indicated on the diagram, making it cleaner and easier to read.
Scott Ambler has a good article on the use of use case diagrams and an article on reuse in use case diagrams. I find much of his work helpful when considering modeling and documenting software systems.
After all of that, I would have to recommend once again going to the person who will be using your use case diagram - in this case, the instructor grading you - to find out exactly what they need from you. In UML Distilled, Martin Fowler almost discourages the use of Use Case Diagrams in favor of other tabular or textual representations of use cases. Diagrams don't have as much value as other more detailed descriptions. Use case diagrams aren't things that you tend to see or use in industry, but you should be aware of their existence and how to read and create them should you be asked to do so.
Best Answer
In the UML specification, Section 11 describes component diagrams and Section 19 describes deployment diagrams. There's nothing that says that you can or can't include external systems, services, or components on either diagram type.
Personally, I would probably do the opposite of what you are doing. I would include external services on the deployment diagram and not on the component diagram.
The intention of the deployment diagram is to "capture relationships between logical and/or physical elements of systems and information technology assets assigned to them". The users of a deployment diagram include the people responsible for the physical infrastructure of the system. For these people, knowing that the system interacts with external services can be useful, especially if there are specific network ports that need to remain open in firewalls or ensure that physical resources that contain specific artifacts remain accessible to the outside world.
On the other hand, a component is a "modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment". The information here is more important to mapping requirements to pieces of the software system, planning for reuse, the specific interfaces between pieces of the system, providing a graphical overview of elements that may be decomposed in more detail in other views of the system. These are of more interest to software developers and architects who may not care as much about the specific nature of the services and where they live, but rather what is part of the system under development and how these pieces interact.
However, you should make the diagrams make sense to you. Maybe, for your audience, showing the external systems on deployment and component diagrams makes communication easier. UML is a communication tool - it provides a common language to communicate the design of a software system. My preference is to embrace many of the agile modeling techniques and stick to the standard notations and spirit of the language, but think about who am I making the diagram for and what will help them do their job.