Information Technology Reference
In-Depth Information
Table 1. Roles description
Role
Description
User identification R
It manages the user identification process to gain access to or come
out of enclosure.
Facilitate access R
It manages the door actuator to provide the users authenticated
correctly with access.
Control infrared R
It aims to update statistics when the infrared sensor detects a person
located in front of it.
Control contact R
Itsobjectiveistomonitorthedoor state thanks to the information
perceived by the contact sensor installed in the door.
Management
tailgat-
It is responsible for detecting and notifying when the anomalous
situation named tailgating happens.
ing R
Management
sabotage
It is responsible for detecting and notifying when someone, different
from the security guard, blocks the door.
door R
Intercommunication R
It is responsible for managing the communication between software
entities for person access control.
For every scenario a goal is identified that represents the goal to be achieved
by the scenario. In the proposed multi-agent system approach, several agents
communicate and coordinate to pursue the common general goal Control en-
trance and exit .Inthe goal overview diagram , this general goal has been refined
into five goals ( Control Entrance , Control Exit , Tailgating , Sabotage Door ,and
Disable Module ) related to the scenarios identified. Similarly, some of these goals
have also been decomposed into several sub-goals to denote how to achieve each
parent goal. Roles are identified by clustering goals, and linking perceptions and
actions (see details in Table 1).
3.2 Architectural Design Phase
Usually, applications need also reading and/or writing data to achieve the func-
tionality related with some roles. This information is specified during the ar-
chitectural design phase in the data coupling diagram (see Fig. 2a). A data is
information managed by agents or beliefs representing agent knowledge about
the environment or itself. For example, a data ( BDD ) should be available to val-
idate every ticket introduced. Furthermore, there are data to count how many
people cross each module ( Trac ), to have control on the enclosure capacity
level ( OccupationLevel ) and determine if a user goes in or goes out the enclo-
sure ( ModuleConfiguration ). Therefore, notice that dataareabletohaveany
granularity.
Once the functionality of the roles has been described through their relations
with other entities (percepts, actions, goals and data), the guidelines offered by
Prometheus to decide the types of agents that are included in the system are
applied during the second phase namely architectural design. In general terms,
these guidelines consist of grouping roles to obtain the system. The cohesion
and coupling criteria are used to decide which the best groupings are to ease
their maintenance. These two concepts are essential to obtain a suitable soft-
ware development that is distinguished by its maximum cohesion and minimum
coupling. In the proposed case study, to achieve the system requirements, an
agent is introduced for each role identified (see Fig. 2b).
 
Search WWH ::




Custom Search