Actor modeling
 |
In computer science, Actor modeling is a form of software modeling which focuses on software actors. Actor modeling is most prominently used for the early modeling of requirements; through this it becomes possible to understand who the users and stakeholders of a system are and what their interests and needs are regarding that system. The increasing complexity of today's systems makes it more appropriate to take this approach, instead of a traditional, more mechanically focused approach. When thinking along the dimensions of users and their needs, it is easier to comprehend what the system is designed to accomplish. This approach furthermore helps the users to define the requirements for the system. The approach of actor modeling is normally combined with the modeling of goals and tasks to give a better understanding of the situation the user is in. There are different modeling languages that support actor modeling; examples include i* and EEML.
The Actor
[edit]The central entity of the Actor modeling – the actor itself – can be any kind of entity that is performing action(s). It may for example be a person, a department, or an organization. The goal of actor modeling is to understand the actor better. To do so, it is important to understand the actor, who he is and why he does what he does. The actor has attributes that define it:
- The actor has goals, skills and responsibilities.
- The actor performs tasks with a certain purpose in mind.
- The actor depends on other actors, resources or tasks.
The Actor concept was initially developed on a platform of multiple independent processors in a network. Implementation on a multiprocessor machine provides several basic concurrency features including encapsulation of parallel synchronization and serialized message processing, which allow higher level concurrent features such as fork/join, async/await, pipeline processing and others. The actor code encapsulates the threading and synchronization management so that a class derived from it can use threading techniques without having to implement the low level plumbing details.
Relations
[edit]The different actors in the model are in general not interdependent. It is therefore necessary to be able to put the actors in context. This can be done through different kinds of relations:
- Connections between actors (what is the relation between the actors)
- Relations to tasks (what does the user do)
- Relations to goals (what is the goal of the user)
- Dependencies (the user is dependent on other entities: users, tasks, goals)
Roles
[edit]Roles allow an impersonalized representation of an actor. It is possible to model a role and connect that role to the actor that is filling that role. If the actor that fills the role stops to do so for whatever reason, it can be easily replaced by another actor that from that point on fills the role; this can be as a temporary replacement or as a long term arrangement. It is furthermore possible to assign new and/or different roles to an already existing actor. The advantage of this is that the model itself doesn't need to be changed; only the connections between the actors and the roles need to be redone.
Limitations of the Actor Model
[edit]Use of actors reduces mechanisms for race conditions but does not eliminate them. Data race conditions are possible if the messages or underlying logic touched by the actor objects includes mutable shared objects. Implementation of truly concurrent data structures is non-trivial. The actor model improves on some of these issues, but does not solve all of the problems. Deadlocks are possible under a number of situations. The Actor model implements message passing in the direction of the actor, but does not facilitate sending a request and receiving a specific status or a reply to a request. Synchronous replies require some sort of blocking logic. For information on objects which can provide this behavior, look at "futures".