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.
It highly depends on your goal of what to achieve with your design.
As it seems, you are not targeting a code generator that directly translates your class diagram into code. Hence, the diagram is just that: a pretty picture. You may want to first rethink the actual value you get from it and why you are making the effort. Contrast that to scribbling out the diagram on a whiteboard with your colleagues and once you're all satisfied, take a photo. What's the big difference?
As for your questions: Do you need to include architecture in the design stage - we'd hope so. The whole point of architecture is to be a framework into which you fit your design considerations. So clearly, you will have to take it into account.
Do you need to revise your diagram during code? This again depends on why you have that diagram. If you want it to describe your code, then obviously it needs to be revised. If all you need is to be able to tell people "look, this is how we envisioned it three years ago. Nothing in the code is anything close to that now though" then feel free to neglect it.
Should you however have a need for an up-to-date UML diagram, then I strongly suggest to move closer to actual modelling (as opposed to simple drawing) such that you can generate code and therefore ensure that the diagram is really corresponding to your code.
Finally a remark on your "100% of the time" way to write your code: While this has nothing to do with your actual questions, I urge you to reconsider your idea of writing business logic (like issuing a status) into action handlers. This violates many good design principles. If you like to read, you may want to take a look at the DDD book by Eric Evans to get a better idea of how business logic like that is served better.
Best Answer
This is a valid concern. I should be able to look at your UML diagram and have a fairly good idea what the methods do.
Well here's your problem. You're going about this all wrong.
No.
No.
No.
No.
You don't.
UML does a wonderful job of forcing you to look at your design from the point of view of the interface you're offering. You're looking at your interface and realizing it's confusing so you want to explain it. No.
Give the method a good name.
If that's not enough then you need to redesign. Stop making me look inside methods to understand what they do. If I look inside and am surprised by what it does then you've got problems that a doc block isn't going to fix. At the most a doc block should confirm what I suspected before looking inside.
The only thing I should learn when looking inside is HOW it does what it does. That info doesn't belong in your UML design anyway. That's an implementation detail.