Dans la méthode NIAM, nous avons vu qu'un acteur est un objet comme un autre, modélisé à travers un concept (ensemble). C'est normal, dans un aspect limité aux propriétés statiques d'un modèle conceptuel.

Au contraire, dès qu'il s'agit de préciser des fonctions, et de les utiliser dans des procédures qui font intervenir le temps, l'utilisateur d'un système d'information devient un concept prépondérant : non seulement il est le destinataire du logiciel (le client), mais en plus il est actif vis à vis des procédures internes de ce logiciel :

• il est en interaction permanente avec lui,

• à travers les interfaces matérielles (l'écran, le curseur-souris, le clavier)

• les boîtes de dialogue,

• il contrôle la cohérence des données externes,

• examine la pertinence des résultats,

• et découvre souvent des erreurs du logiciel !

Il intervient pour déclencher ce qu'on appelle des « évènement » dans la terminologie des langages à objets. Un événement intérieur à un logiciel peut en déclencher d'autres en cascade.

Dans un système d'information, l'acteur n'est pas seulement un être humain. Ce peut être toute cause de déclenchement d'une procédure, comme un autre logiciel, relié au système par une interface, ou le résultat de l'action d'un automate.

Les acteur peuvent se différencier selon une typologie, par exemple associée au degré de liberté d'action qu'ils ont sur le système : ceux qui ont seulement le droit d'extraire et d'afficher certaines informations, ceux qui peuvent renseigner certains objets, ceux qui ont tous les droits d'accès (l'administrateur). Le lecteur est sans doute familiarisé avec ce concept d'acteur largement utilisé dans une SGBD, ou dans un système d'exploitation comme Windows, qui sont des systèmes d'information.

Dans UML, un acteur extérieur est représenté par un petit bonhomme, et le système formel, dont le contenu est supposé inconnu par lui, par un rectangle.