My system will deal with Google map API to locate user's location after his/her request.
I am drawing the use case diagram and wondering if "Google Map API" should be an external actor to my system or not.
My system will deal with Google map API to locate user's location after his/her request.
I am drawing the use case diagram and wondering if "Google Map API" should be an external actor to my system or not.
Use cases represent the goals/intents that the system is required to achieve.
Actors represent users and external systems that interact with the system for the purpose of the use case. "Google MAP" could be such a system. But as it is only contributing to the use case for the purpose of supporting the goals of other actors, it would be secondary actor.
Important remark 1: presenting such a system on a use-case diagram makes sense only if the involvement of the external system is relevant from the point of view of the use-case goals (i.e. it's part of the user requirements). Technical infrastructures, such as cloud databases and similar external supporting systems should not be presented on a use case diagram: they are only technical solutions to the requirements.
Important remark 2: on the use-case you would have the external system, which is "Google MAP" and not "Google MAP API". The API is a technical artifact that specifies how to interact with the remote service. You could this interface in a component diagram, or in a deployment diagram,
... wondering if "Google Map API" should be an external actor to my system or not.
UML not being a methodology, you can decide. Craig Larman's UML approach proposes using the external service as supporting actor:
It might be interesting to abstract it to a Mapping System (rather than Google Maps), since this is a service provided by Apple, Google, Microsoft, etc. Each has likely a different API, but you could develop an adapter interface, so the core aspect of your internal system wouldn't need to know the details. Larman's book does a great job to explain how that could work.