Use Case Diagrams, Actors and Associations

Let's talk a little more about actors.
Actors represent something outside the system that either affects the system or the system affects.  The significance here is that an actor is outside of the system.  You are not going to build it.  You are not going to model its behavior.  Even though UML and SysML use stick figures to show actors on diagrams, all actors are not people.  Actors may represent people (for example, the user) or they may represent hardware (a sensor or an effector) or they may represent another subsystem.
Any of you who have attended any of my classes know that I am about to get on my soap box now.  Hard engineering disciplines (electrical, mechanical, chemical, civil) will never take Systems and Software engineers seriously as long as we use these silly indicators and cutesy terms (e.g., fuzzy logic).  Therefore, if you are going to show use case diagrams to your colleagues or customers who are not fluent in UML/SysML, change the picture of the actor to what it represents in the real world (a tank, a letter carrier, the physical actuator).  Better modeling tools let you make this substitution (if yours does not, contact me and I'll put you in touch with a sales guy).  OK, now I'll step off my soapbox and go back to the discussion.

When developing systems, actors represent anything you are not getting paid for.  In an IT system, the actor may represent the server -- or better, an application running the server.  In an aircraft flight control system, use an actor to represent the pilot (not the stick because it is part of the aircraft and generally falls under the auspices of the flight control subsystem), the inertial navigation system (it is not part of flight controls), and the surfaces (when you execute the model, you want to confirm they are moving the correct direction).

When developing software, use cases represent a single feature of the code (more on this when we discuss Use Cases and the Development Process).  In these cases, the actor represents the other parts of the code that interact with that feature.  Let me clarify.  A reusable machine control framework includes the concept of generic inputs and outputs.  No matter how the physical hardware works, the application interfaces with I/O using the same (virtual) calls.  The use case Read_Discrete_Inputs has an association with a Client actor.  This actor represents any part of the code that requires a discrete input.  By definition, the Client is internal to the system, but it is external to the feature.  Therefore, as far as Read_Discrete_Inputs is concerned, Client is external.  In other words, your point of view determines internal versus external.

Associations show the virtual connections between actors and use cases.  They indicate which use cases an actor affects and which actor the use case affects.  Most, but not all, use cases have associations with actors.
Associations provide another purpose when reviewing the model.  They indicate the potential interfaces.  Specifically, the association between a User actor and use case indicates that the system requires some form of user interface -- a GUI, a push button, a retinal scanner.  It forces the Systems Engineer to think about what may be missing from the overall specification.

One last point, in the early days of the UML, we showed associations as arrows.  These arrows caused misunderstandings and provided little additional information.  Therefore, I recommend that you show the associations without arrowheads.