Improving the Agent Based Software Development Process

Download PDF
5 downloads 0 Views 247KB Size Report
Comment
Improving the Agent Based Software Development Process. PRABHAT RANJAN & A. K. MISRA. Department of Computer Science & Engineering. Motilal Nehru ...
Improving the Agent Based Software Development Process PRABHAT RANJAN & A. K. MISRA Department of Computer Science & Engineering Motilal Nehru National Institute of Technology, Allahabad -211004, Uttar Pradesh, INDIA [[email protected], [email protected]] Abstract Agent oriented software development is generally motivated by the need of open and adaptive systems develpoment that continuously change and evolve to meet new requirements. In this paper, we propose model-based technique that provides a specific model for the type of information to be gathered and uses this model to drive the domain specific analysis process. In the proposed agent-based system, the focus is on a clear separtion between the requirement gathering and analysis phases. The analysis methodology splits the analysis phase into the user_centric analysis and the system_centric analysis phases. Optimization of the system performance by exploiting the relationships and dependencies among roles and mapping criteria between roles to agents has also been proposed. The Gaia and ROADMAP models have been used as a fundamental ingredient to the new proposed agentbased modeling method.

cooperate with other roles for accomplishing the task. The roles define expected behaviors of the agents and are an important concept used for different purposes like modeling of structure of multi-agent system, modeling of protocols and components of agent design [17,18]. Moreover the implicit conflict among roles can also be identified. Identifying roles and mapping the roles to an agent are essential phases in many proposed AOSE methodologies like Gaia [11], PROMETHEUS [10], ROADMAP [19] and TROPOS [4]. Most of the current AOSE methodologies utilize the requirement gathering and analysis phases to collect the requirements in the concerned domain knowledge and execution environment. These methodologies do not consider the following: • During requirement gathering the requirements are gathered without taking into account the point of views of either customers/clients or end-users. •

These methodologies, do not gather the cognitive characteristics of each system user and as such developers fail to take advantage of richer requirements and their cognitive characteristics.

•

The requirement analysis is not performed from the user point of view. The system-oriented analysis puts a heavy burden of translation both on the analyst and the user, who need to understand the analysis for validation purposes.

•

In most of the cases, analysis model is a common communication medium between customers or clients and the analyst. The methodologies do not consider the communication between the end-user and analyst, who might also be interested in the analysis model.

1. Introduction Agent oriented software engineering (AOSE) has become a hot research area in recent years and it promises to construct open adaptive systems with complex and sophisticated behavior. In agent based system development research, the properties of the agents are not efficiently reflected in the development phase i.e. requirements gathering, analysis and design. The technique adapted to development of agent-based systems is goal and role oriented agents. A goal could be defined as a non-operational objective to be achieved by the composite system [2]. The concept of role has been advocated to model application domain agents, which evolve dynamically during their lifespan. Understanding the relationship among roles can help the system analyzer to refine and optimize the role model [1]. The role has the active property to

• Most approaches analyze the functional and nonfunctional requirements in a single module. Each type of requirement needs several iterations and interactions with the appropriate system users. Hence, it becomes quite difficult to analyze the

functional and non-functional requirements in a single module because the target users of each requirement might be different. •

The role/goal specification is not performed on a problem-orientation basis in the requirement gathering and analysis phases and moreover the specifications are at too low level (requirement gathering phase), specifying too many details.

•

The logical relationships and dependency among goals are not accounted for.

In the present paper, a model has been proposed, which exploits the user requirements in order to enhance the capabilities of requirement gathering and analysis phase.

2. A Conceptual Framework A Conceptual Framework has been proposed, which exploits the user requirements in order to enhance requirement gathering and user_centric analysis. It also reduces the complexity of the software and provides better quality with better user satisfaction. The specification and analysis phase in the original Gaia [11] and ROADMAP [19] methodologies has been extended and split into two parts to cover more specific requirement gathering as well as analysis. In most of the agent-oriented methodologies, the concept of agents has been introduced into the software requirement specification and analysis phases but this concept does not address the separate requirementgathering phase.

The proposed methodology is based on modelbased techniques and provides a specific model for the type of information to be gathered and uses this model to drive the user_centric requirement analysis, specification and system_centric analysis process. In the user_centric analysis phase, the requirementgathering models are refined iteratively until sufficient analysis information is captured. The user_centric analysis phase within this proposed model, serves as the initial input to the system analysis model. The product model, organization model, system user model and cognitive model have been introduced to support requirements gathering. The analysis model carries out the user centric and system centric analysis. The overall goals of the system are divided into sub-goals by using user_centric and system_centric analysis. The three logical relationships between sub-goals are identified. Each of the logical relationship is composed of five dependencies namely resource, task, interface, operational and social dependencies. The sub-goal/task is performed by cooperation of fewer roles. To optimize system performance in an agents-based system the concept of grouping of role by using dependencies namely resource, task, interface, operational and social dependencies and mapping the role to agent is performed. Fig 1 shows the proposed model. In the proposed model the Use Case Model, Interaction model and Protocol model are the same as that of ROADMAP methodology [19]. To enhance requirement gathering and analysis, the methodology should provide a clear separation between requirement gathering and analysis. The requirement gathering is based on model-based

Specification & System Analysis

Pre-System Analysis

Requirement Gathering

Product Model

Use Case Model

Organization Model

System User Model

Cognitive Model

User_centric Analysis Model

System _centric Analysis Model

Role Model

Interaction Model

Figure 1. Proposed Model : A Phase-Oriented View

Protocol Model

techniques and provides a specific model for the type of information to be gathered and uses this model to drive the user_centric and system_centric requirement analysis. The product model, organization model, system user model and cognitive model have been introduced to support requirements gathering [13]. The separate requirement-gathering phase has the following advantages: • The requirements gathered are from the system point of view as well as from the user point of view. •

The requirement-gathering model gathers very specific requirements about the domain.

•

Requirement gathering model, which is analysis independent, will make the model more understandable to domain experts as well as the developers. This will also give the choice to the developer of taking the appropriate decision about the overall system once the requirements are properly gathered.

•

The Scalability also increases due to the modular approach and as such large agent based systems can be developed.

•

Large Agent based open adaptive systems always evolve with the environment in which they operate and change with changing user’s requirements. Typical changes to requirements include adding or deleting requirements. Requirements are added in response to changing user’s need, or because they were missed out in the initial analysis. The separte requirement gathering phase gives greater assurance to developers that the captured requirements may be easily reused during system evolution or while making a similar system in future.

The product model, organization model, system user model and cognitive model capture information related to their specific domains and do not belong to a particular software development phase. The proposed model OV for requirement gathering is composed of a set of specific models (Pv, Ov, Uv, Cv). i.e. OV= {Pv, Ov, Uv, Cv} where, Pv is the product model based on product specific view Ov is the organization model based on organization specific view Uv is the system user model based on system user specific view and Cv is the user cognitive model based on cognitive characteristics

Each of the specific models Pv, Ov, Uv, Cv is composed of a set of model-based specific requirements RPi, ROi, RUi, RCi respectively. i.e. Pv = {RP1, RP2, RP3,----------------, RPn} Ov = {RO1, RO2, RO3,---------------, ROn} Uv = {RU1, RU2, RU3,---------------, RUn} Cv = {RC1, RC2, RC3,---------------, RCn} where, n is the total number of expected specific requirements RPi is the product specific requirements ROi is the organization specific requirements RUi is the system user specific requirements RCi is the user cognitive characteristics specific requirements. Each of the model-based specific requirements RPi, ROi, RUi, RCi is composed of a set of functional and non-functional requirements of the system, each of which serves some user goal in accomplishing the objectives of the overall system. i.e. RPi = {FRPi, NFRPi } ROi = {FROi, NFROi} RUi = {FRUi, NFRUi} RCi = {FRCi, NFRCi} where, FRPi, FROi, FRUi, FRCi are the functional requirements for product model, organizational model, system user model and user cognitive model respectively. NFRPi, NFROi,NFRUi, NFRci are the non-functional requirements for product model, organizational model, system user model and user cognitive model respectively. The cognitive functional requirements are system user’s basic cognitive capabilities such as spatial ability and preferred learning styles. It considers how a system user perceives, memorizes, acts, identifies goals etc. in a certain way and these are defined in cognitive functional requirements. The cognitive non-functional requirements are system user's preferences for particular styles of display, color, scaling, priorities and user-preference for different quality attributes.

3. Analysis Model In the current methodology, the analysis models are divided vertically into 2 domains: user_centric and system_centric domain specific models. These exploit the user and system requirements by performing the user_centric and system_centric requirement analysis. In these analysis models the requirement analysis is carried out in two different points of views [12,14]. Fig 2 shows the proposed analysis model. In evaluation of each stage, feasibility is first considered. That is, this specific module will only consider whether an analysis result satisfies all system

users’ requirements on the basis of gathering functional and non-functional information by the requirements gathering phase. In the first stage analysis the overall functional, non-functional and crosscutting requirements are analyzed by user point of view i.e. local evaluation/ user_centric/ high-level goal analysis. After performing the first stage analysis the feasibility/ acceptance study of problem definition from the user point of view is also done. If this is acceptable by the system user then it passes for the next stage analysis. In the second stage the overall functional and nonfunctional requirements are analyzed by system point of view and is called comprehensive evaluation/ lowlevel /system_centric goal analysis. The purpose of the comprehensive evaluation is to determine whether the high level goals are reasonable or practicable, and is used to form a true estimation of the quality and non-quality attributes. The system_centric analysis models can also be split horizontally into 3 domains: System oriented domain goal model, Architecture domain oriented goal model and Design domain oriented goal model.

The motive and advantages of separate System User centric analysis and System centric analysis are the following: • Clear separation of modules help in handling overall requirements. These modules also analyze/optimize requirements from user point of view and system point of view. • Non-functional requirement like aesthetics, quality, performance, time, cost etc. are more user_centric and they have to be optimized and suited to the user/client need and should be analyzed at the system user centric analysis model. • Since the internal functional requirements like Input Set, Output Set, Business Logic etc include the essential and core functions/operations that a system is supposed to perform; it has to be optimized from the system point of view and should be optimized at the system centric analysis model. •

In this way, the system user is able to take active part in the quality assurance, verification and validation purposes. Sub-Goal EC1

User_Centric Analysis

:

Critical Goal

Analysis

Sub-Goal ECn Pre- System Analysis

External Goal

Sub-Goal EMA1

Major Goal

: Sub-Goal EMAn Sub-Goal EMI1

Minor Goal

: Sub-Goal EMIn Refined

System Analysis

System_Centric Analysis

Sub-Goal PS1 Primary System Goal System Oriented Goal

Primary Architecture Goal

: Sub-Goal PSn

Architecture Oriented Goal

Sub-Goal SS1

Secondary Architecture Goal

:

Secondary System Goal

Sub-Goal SSn

Primary Design Goal

Sub-Goal PD1

: Sub-Goal PDn

Design Oriented Goal Secondary Design Goal

Sub-Goal SD1

: Sub-Goal SDn

Figure 2.

The Proposed Analysis Model

Sub-Goal PA1

: Sub-Goal PAn Sub-Goal SA1

:

Sub-Goal SAn

4. User Centric Analysis The main objective of agent-oriented user_centric analysis is to elicit agents from various requirement models viz. product model, organization model, system user model and cognitive model and then develop the system abstract model. In order to identify the requirements and knowledge about the user, environment, interaction characteristics and behavior of the organization, the user_centric analysis goes through the scenarios in the various models. On the basis of such acquired knowledge, the analyst assigns the agent behavior in the various models of each use case model. It is to be noted here that when either of the environment, interaction characteristics or the behavior of the organization changes, the acquired knowledge and the agent behavior change accordingly. In the pre-system analysis model, feasibility study of the problem definition from the different points of view is also done [8]. After getting the relevant information from the product model, organization model, system user model and cognitive model, the pre-system analysis model identifies the knowledge about the overall system requirements (functional and non-functional requirements). The overall requirements of the system are divided into two types namely: requirement oriented (external goal) and system_centric (internal goal). The requirement-oriented subsystem division is the external goal of the system, which does not consider the functionality, resources and other technical details of the system. The external goals are basically user_centric goals. The external goals are then decomposed into critical, major and minor goals. Some significant benefits of decomposition across the software development lifecycle include tractability, flexibility, comprehensibility, reusability, composability, scalability and evolvability. This approaches is to provide greater benefits during design. Critical Goal : A critical goal has the top priority in the pre-system analysis. Critical goal is basically system/organization/project-affecting goals in user point of view. These are goals that need to be taken care of immediately in order to prevent the system/project from being put in jeopardy. A critical goal must be taken care before the architecture can be validated. The critical goal is objective of system or most important function that software must perform. Major Goal : The second priority in the pre-system analysis is major goal. A major goal is basically user’s preference that has an impact on user satisfaction. In the concept of multi-user system application scenario, the users requirements differ according to their specific

user preference. Generally, in a system_centric approach the system would most likely produce the highest quality system and no other factors/ user’s preference to consider. The problem however is that sometimes the user does not really need such a best quality system, but rather a system that is just enough to convey the needed information. The major goals develop a system that best matches the user’s preference and therefore most satisfying to the user. Minor Goal : The third priority in the pre-system analysis is minor goal. A minor goal is users and systems additional need, those that might affect later releases. In case of conflicting requirements between different system user, the pre-system analysis agents shall interact with the user interface agents so that conflicts are resolved by negotiation with system user by shifting/transferring the system user requirements into different categories of goals viz: critical, major and minor. Critical goal shall not be shifted/ transferred under any circumstances to either major goal or minor goal in case of conflicting requirement. In case of conflicting requirement, the only enhancement, that may be applicable are: some major goals may be shifted/transferred to critical goal, some minor goals may be shifted/transferred to major. One important thing is that, in any further phases, the user_centric critical, major and minor goals shall not be changed. The critical, major, minor goals differ from one software system development to other. This difference arises because the software systems are developed for a number of different specific purposes. Fig 2 shows the proposed pre-system analysis. The user_centric specific goal (GU) is composed of a set of domain specific goals. i.e. GU = {GUC, GUM, GUN} where, GUC is the user_centric critical goal GUM is the user_centric major goal GUN is the user_centric minor goal Each of the user domain specific goals GUC, GUM, GUN is composed of a set of specific goals GUCi, GUMi, GUNi, respectively. i.e. GUCi = { GUC1, GUC2, GUC3,……… ……, GUCi } GUMi = { GUM1, GUM2, GUM3,……. ……, GUMi } GUNi = { GUN1, GUN2, GUN3,……… ……, GUNi } where, GUC1,GUC2,GUC3,….,GUCi is a user_centric critical goals GUM1, GUM2, GUM3,…….……, GUMi is a user_centric major goals and GUN1,GUN2,GUN3,…,GUNi is a user_centric minor goals The proposed model captures the purpose of a system in all perspectives. In this model careful decisions need to be made about what information the system will represent and how the information held by the system corresponds to the real world phenomena

being represented. The objective of this model is to find out the problem to be solved and the system boundaries, which define the fitness of the final delivered system into the current operational environment. In the agent-oriented user_centric analysis, the requirement-gathering models are refined iteratively until sufficient information/ requirements about the system are captured. The idea of sufficient information is that the requirements from the user point of view are converted into goals by user_centric analysis. So the user_centric analysis exploits the system users context and cognitive characteristics related requirements. The objective of this model is to find out the problem and the system boundaries, which define the fitness of the final delivered system into the current operational environment.

5. System Centric Analysis The system_centric analysis is the second stage and is also called as comprehensive evaluation. In system_centric analysis, the comprehensive evaluation of functional and non-functional i.e. low-level is performing. The purpose of the comprehensive evaluation is to determine whether the high level goal is reasonable or practicable, and to from a true estimation of the quality and non-quality attributes. The system_centric analysis is performed and if the analysis results do not meet the system user requirements, then a re-analysis is carried out again. In system development, the different domain requirements analysis are perform by different experts because each domain has some specific domain requirements and specific domain expert must analyze that domain requirements. The system oriented goal analysis is independent of the architecture and detail design. The system oriented analysis is carried out by expert teams who had nothing to do with the architecture, design, coding & implementation and verification & testing of the software. In the system domain analysis process, the three major tasks that are performed are [16]: Firstly, it performs the refinement process of user_centric goal. The analysis expert team does not change the user critical, major and minor goal. But, in some cases expert team only enhances the goal types i.e. some major goal is converted into the type of critical goal but vice-versa is not applicable in any case. Secondly, it analyzes the system_centric domain specific goal. The system_centric goal is the inputs, processing, outputs, control etc, which is closely related to the need of system. The goal model is mainly

concerned with the system goals by analyzing the system and organization objective. Thirdly, it separates the architecture and design domain specific goal from system domain specific goal. The architecture domain goal analysis process performs the refinement process of user and system domain specific goal as well as the architecture domain specific goal. It is independent of the design point of view. Particularly in an architecture environment, the quality of the architecture is critical for the design, implementation and quality of the final product. Mistakes and bad choices in the architecture design stage can be difficult and expensive to correct later in development. Good architecture design is indicated by software whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented. Good architecture design is indicated by an application whose functionality can be traced back to customer and end-user requirements. In the design domain goal analysis process performs the refinement process of user and system domain specific goal, architecture domain specific goal as well as it analyzes the design domain specific goal. It is independent of all other domain specific point of view. Expert teams who had nothing to do with the analysis carry out the software design. The system_centric specific goal (GS) is analyzed and divided into three system_centric specifics goal (GSO, GSA, GSD). i.e. GS = {GSO, GSA, GSD } where, GSO is the system_centric specifics goal, GSA is the system architecture -oriented specifics goal GSD is the system design-oriented specific goal (coding, implementation-oriented goal etc.) Each of the system domain specific goals GSO, GSA, GSD is composed of a set of domain-based specific goals GSOi, GSAi ,GSDi, respectively. i.e. GSOi = {GSO1, GSO2, GSO3,……………,GSOn} GSAi = {GSA1, GSA2, GSA3,…………….,GSAn} GSDi = {GSD1, GSD2, GSD3,……… ……,GSDn} where, GSO1, GSO2, GSO3,……………,GSOn is a systemcentric domain specific goals , GSA1, GSA2, GSA3,…………,GSAn is a architectureoriented domain specific goals, GSD1, GSD2, GSD3,……… …,GSDn is a system design-oriented domain specific goals and n is the total number of expected domain specific goals Each of the domain specific goals GSOi, GSAi ,GSDi is composed of a set of internal primary and secondary goals of the system, each of which serves some user goal in accomplishing the objectives of the overall system. i.e. GSOi = {PSOi, SSOi } GSAi = {PSAi, SSAi}

GSDi = {PSDi, SSDi} where, PSOi, PSAi, PSDi is the internal primary goals SSOi,, SSAi, SSDi is the internal secondary goals The primary goals are direct and main objective of the system and the secondary goals support the system so that the primary goals can do its work. In other word, the secondary goal is additional constraints with primary goal. Each of the internal primary and secondary domain specific goals is composed of a set of internal functional and non-functional goals. i.e. PSOi = { FSOi, NFSOi } SSOi = { FSOi, NFSOi } where, FSOi is the internal functional goals NFSOi is the internal non-functional goals Functional goals capture the intended behavior of the system in terms of services, tasks or functions the system is required to perform. Functional goals are generally specified by means of inputs, processing, outputs, controls, exceptions and entities. Functional goals are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Different types of methods are used to specify functional requirements. Use case driven approaches describe “the ways in which a user uses a system” that is why use case diagram is often used for capturing functional requirements [6]. Non-functional goals impose restrictions on the product being developed (product requirements), on the development process (process requirements), or they specify external constrains that the product/process must meet (external requirements) [5]. The distinction between functional and non-functional requirements may cause confusion. Non-functional characteristics [7,9] are used to distinguish them from functional requirements. Quality attributes define global properties of a system.

6. Role Model The role model divides the goal/sub-goal into tasks and further into sub-tasks. The sub-tasks are grouped on the basis of relative interconnectivity and closeness among them. The subtasks are performed by the cooperation of fewer roles. The role model describes the properties of a role. Once the system and user goals are known, one needs to examine how the overall goal could be broken up to enable the designer to identify agents and their properties, as well as allowing a division of labour in designing the agent based software system [3]. Decomposing goals means finding states that allow the goal state to be achieved more easily or finding

independent and dependent parts of the goal state such that, when the parts are achieved the whole is achieved. Suppose, the security attribute is analyzed and it gets decomposed by comprehensive evaluation into confidentiality and integrity sub-attributes. Confidentiality and integrity are sub attributes of the attribute security. Security Integrity

Confidentiality

Internal Confidentiality

External Confidentiality

Figure 3. Security Goal Decomposition

This is an overlapping situation, where confidentiality must be enforced before the execution of any operation and integrity must be used after it. Fig 3 shows the security goal decomposition. In this type of cases the logical relationship between the sub-goals is identify. The internal functional and non-functional goals are further decomposed into sub-goals. Each of specific goals is composed of a set of decomposed sub-goals with the logical relationship. = { FSO1, FSO2, LR} i.e. FSOi = {NFSO1, NFSO2, LR} NFSOi Where, FSO1, FSO2 are the functional primary and secondary sub-goals of the system NFSO1, NFSO2 are the non-functional primary and secondary sub-goals of the system LR is the logical relationship between the primary and secondary sub-goals. The logical relationship LR between the sub-goals is composed of (LRA, LRB, LRAB). i.e. LR = {LRA, LRB, LRAB} Where, LRA - Either the first sub-goal may be required after the second sub-goal ones. LRB - Either the first sub-goal may be required before the second sub-goal ones. LRAB – Both the sub-goal cannot be achieved in disregard to each other nor they independent of each other hence their ordering cannot be arbitrary and implemented with knowledge of how the other subgoal /attribute is achieved. The logical relationship LR between the sub-goals is composed of a set of specific interconnectivity dependency of the system, each of which serves some specific purpose of the system in accomplishing the objective of the overall system. LRA = {LRD, LTD, LID, LOD, LSD} LRB = {LRD, LTD, LID, LOD, LSD} LRAB = {LRD, LTD, LID, LOD, LSD} Where, LRD is specific resource interconnectivity dependency

LTD is specific sub-task interconnectivity dependency LID is specific interface interconnectivity dependency LOD is specific operational interconnectivity dependency LSD is specific social interconnectivity dependency The sub-goal/task is performed by cooperation of fewer roles. An agent-based system consists of software entities called agent, which interact with themselves and other resources to perform goals. Each agent plays some role in the environment. To optimize system performance in an agents-based system, the concept of grouping of role by using dependencies namely resource, task, interface, operational and social dependencies and mapping the role to agent is performed. By doing so roles within a group can interact with each other. We optimize the system performance to minimize the overall interaction, data transmission and competition of shared resource between roles/agents by using the dependencies namely resource, task, interface, operational and social dependencies. The proposed grouping algorithm partitions the overall system roles/agents into several groups. Optimal group size can be obtained by performance parameter (η) [15]. The grouping of overall system roles/agents is depends on the following criteria: • Frequently interaction (RI) between roles •

•

Closely related role ( RR) on the basis of o

Performing similar nature of task

o

Role capabilities

o

Role dependencies

Roles using shared resource (RSR)

An agent-based system consists of software entities called agent, which interact with themselves and other resources to perform goals. Each agent plays some role in the environment. In general, an agent can play more than one role, but it is very application specific to map the role to agent. The mapping between the role and the agent can be one to one, one to many, many to one, or many to many. In most cases, there may be a one-toone correspondence between roles and agents. But an agent may also play some closely related roles for purpose of convenience and modularity. The role instances only exist in association with agent instances. Role’s life begins when the agent acquires it according to current condition. When condition changes, agent drops previous role and acquires the new role. The agent will play different roles at different time and in different conditions during its life cycle. A role identified by its name RN. Role description RD is composed of a set of six specific characteristics. i.e. RD = { RT, RA, RC, RB, RST, RCC} Where, RT is the Role Type

RA is the Role valid Activation RC is the Role Cardinality RB is the Role Behavior (Norms and Rule) RST is the Role specific Task RCC is the Role certain Capabilities. Roles Type RT is composed of a set of four specific role of the system, each of which serves some specific task of the system in accomplishing the overall objective of the system. i.e. RT = { IR, DR, PIR, PDR} Where, IR is the Independent Role. An independent role may be acquired or dropped without any consideration of other roles. DR is the Dependent Role. A dependents role has some form of dependency relation with other roles. PIR is the Partially Independent Role. A partially independent role is performed/handled for some specific role instance or sub-tasks independently and all other instance of role or sub-tasks is dependent on other role. PDR is the Partially Dependent Role. A partially dependent role has some specific role instance or subtasks dependency relation with other role and all other instance of role or sub-tasks is performed/ handled independently. In Partially Independent and Partially Dependent case, an agent may acquire or drop the role only in case of the role instance being independent. Understanding the dependency or relationship among roles help the system analyzer to refine and optimize the role model. It also optimizes system performance in an agentsbased system by analyzing dependency or relationship among roles. The role valid activation RA gives number of times a role can be taken by an agent. The cardinality of role RC specifies the maximum limit on its instances at any time with any agent. The behavior of role RB describes that the role requires certain nature of behavior to perform a task. There are some specific norms and rules to perform a task. In some cases, the role behavior conflict arises. For example, in an organization if a staff member who is also a private consultant may have conflicting job responsibility? In this case different roles by the same person is possible, but it would require appropriate rule and norms to resolve the conflicting behavior. The role specific task RST is responsible for achieving, or helps to achieve some system specific task. The certain capabilities of role RCC describe how well an agent may play that role in light of the capability it possesses. Capabilities are key to determining exactly which role can be assigned to what tasks in the organization. Role may interact with another role only if they belong to the same group. Interaction is done through asynchronous message passing. If the message fails to

satisfy constraints (RT, RA, RC, RB, RST, RCC) from any roles concerned, the message will be rejected and action will be taken to handle the error. The cohesion of the whole system is maintained by the fact that role may belong to any number of groups depending upon the above-mentioned criteria, so that the communication between two groups may be done by roles that belong to the both group. At the time of grouping of roles and mapping to the agent we take care of the role specific characteristics (RT, RA, RC, RB, RST, RCC), which is describe in the role description RD. The addition and deletion of role into group and mapping to agent is permitted only when the role specific characteristics constraints RT, RA, RC, RB, RST, RCC are valid. If any role constraint is violated, it raises corresponding exception.

7. Concept of Grouping and Mapping The proposed Grouping and mapping methodology is as follows: Assumptions : Every role has a unique ID. Role ID is dependent on the group. Every role must come/assign into any one the group. Initially we assign role to agent mapping is one–toone. 1. Initially find out the total number of role in the agent based system i.e. Rn. where, Rn would be the total number of expected role and n is varying from 1 to n. 2. Apply the first criteria RI representing frequent interaction between the roles and make group of the role. i.e. GI = {RIn, η} Where, GI is the group by apply the interaction criteria RIn ={RI1, RI2,……., RIn} would be the total number of expected frequent interaction specific role η : ρ(RI) is a performance function which defines the time of interaction between each subset of roles. The performance function must satisfy the constraints that by adding role in a group never decrease the performance of the system. Formally, this is defined as follows: RIn are sets of role such that RI1 RI2 , If RI1, RI2 then η(RI1) ≥ η(RI2). The group size of GI is decided by performance parameter η. 3. If group size of GI < Rn then apply the second criteria RSR else exit. 4. Apply the second criteria RR representing closely related role and make group of the role. i.e. GR = { RRn , η} Where, GR is the group by applies the closely related role criteria

RRn = {RR1, RR2, ……..,RRn} is the set of role which is performing similar nature of task, similar role capabilities and role dependencies. η : ρ(RR) is a performance function which defines the time of executing each subset of tasks by role. The performance function must satisfy the constraints, that the adding task never decreases the performance of the system. Formally, this is defined as follows: RRn are sets of role such that RR1 If RR1, RR2 RR2 , then η(RR1) ≥ η(RR2). The group size of GR is decided by performance parameter η. 5. After applying the second criteria we find out the intersection of group i.e. GI ∩ GR The performance function must satisfy the constraints, that the removal of role from GI and GR and assigning it to intersection of group GI ∩ GR does not decreases the performance of the system. If group size of (GI + GR + GI ∩ GR) < Rn then apply the third criteria RSR else only apply first (RI) and second (RR) criteria is applied and exit. 6. Apply the third criteria RSR representing roles using shared resource and make group of the role. i.e. GSR = {RSRn, η} Where, GSR is the group by apply the third criteria RSR RSRn = {RSR1, RSR2, ……..,RSRn} is the set of role which is using shared resource. η : ρ(RSR) is a performance function which defines the time/amount of access shared resource by role. The performance function must satisfy the constraint, that the adding shared resource role never decreases the performance of the system. Formally, this is defined as follows: If RSR1, RSR2 RSRn are sets of shared resource role such that RSR1 RSR2 , then η(RSR1) ≥ η(RSR2). 7. After applying the third criteria we find out the intersection of group i.e. GI ∩ GSR , GR ∩ GSR and GI ∩ GSR ∩ GR The performance function must satisfy the constraints, that the removal role from GI, GR and GSR and assigning it to intersection of group GI ∩ GSR , GR ∩ GSR and GI ∩ GSR ∩ GR does not decreases the performance of the system. 8. Map the individual group of GI, GR, and GSR to individual capable agent which is having desired characteristics depending upon the group. At the time of mapping role group GI, GR, and GSR to agent, the mapping must satisfy the role constraints. The mapping of roles to agents should never violate any role constraint (RT, RA, RC, RB, RST, RCC), and if any role constraint is violated, it raises corresponding exception. 9. Map the intersections of group (GI ∩ GSR, GI ∩ GR, GR ∩ GSR and GI ∩ GSR ∩ GR ) to individual capable

agent which is having desired characteristics depending upon the group intersection. 10. At the time of mapping intersections of role group GI ∩ GSR, GI ∩ GR, GR ∩ GSR and GI ∩ GSR ∩ GR to agent, the mapping must satisfy the role constraints. The mapping of roles to agents should never violate any role constraint (RT, RA, RC, RB, RST, RCC), and if any role constraint is violated, it raises corresponding exception. The system performance is optimal when the intersections of the group are minimal.

8. Conclusions The proposed methodology enhances the effectiveness / efficiency of the requirement gathering by providing separate and specific models for each type of information /requirements gathered. The proposed gathering and analysis methodology are both system_ centric and user_ centric, hence it is bound to increase the user satification level and also help in ease of use. The provision of new and separate module will also increase the scalability of the system and helps in understanding the problem domain. The proposed grouping of role and mapping of roles to agents for optimized agent based systems performance is highly application dependent. Optimal group size is obtained by user-defined performance parameter (η). It is found that that the system performance is optimal when the intersections of the group are minimal.

[5] [6] [7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

9. Future Work [16]

We are currently working to refine and validate the proposed methodology, by taking an example of real life case study.

[17]

10. References [1]

[2]

[3]

[4]

Chiung Hui, Leon Lee and Alan Liu, “A Method for AgentBased System Requirements Analysis”, Proceedings of the IEEE Fourth International Symposium on Multimedia Software Engineering (MSE’02), 2002. C. Rolland, C. Souveyet, and C. Ben Achour, "Guiding Goal Modeling Using Scenarios", IEEE Transactions on Software Engineering, 24(12), December 1998. D. Kinny, M. Georgeff, and A. Rao., “A methodology and modelling technique for systems of BDI agents”, Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in a Multi- Agent World (MAAMAW-96), January 1996. F. Giunchiglia, J. Mylopoulos and A. Perini., “ The Tropos Software Development Methodology: Processes”, Models and Diagrams. Technical Report No. 0111-20, ITC - IRST, Nov 2001.

[18]

[19]

G. Kotonya and I. Sommerville, “Requirements Engineering: Processes and Techniques”. Wiley, 1998. G. Schneider and J. Winters, “ Applying Use Case - A Practical Guide”, Addison-wesley, 1988. J. Mylopoulos, L. Chung and B. Nixon, “Representing and Using Non –Functional Requirements: A Process- Oriented Approach”. IEEE Transactions on Software Engineering, Vol. 18, No. 6, pp. 483-497, June 1992. K. Saleh and A. Al-Zarouni,“Capturing Non- Functional Software Requirements Using The User Requirements Notation”, The 2004 International Research Conference on Innovation in Information Technology (IIT’04), 2004. L. Chung, B.A. Nixon, E. Yu and J. Mylopoulos, “NonFunctional Requirements in Software Engineering”, Kluwer Academic Publishers, Dordrecht, 2000. L. Padgham and M. Winikoff, “Prometheus: A Methodology for Developing Intelligent Agents”, Proceedings of the Third International Workshop on Agent Oriented Software Engineering, at AAMAS 2002. Bologna, Italy, July 2002. M. Wooldridge, N. Jennings and D. Kinny, “The Gaia Methodology for Agent-Oriented Analysis and Design”, Journal of Autonomous Agents and Multi-Agent Systems 3 (3), 285-312, 2000. P. Kuan, S. Karunasekera and L. Sterling, “Improving Goal and Role Oriented Analysis for Agent Based Systems”, Proceedings of the 2005 Australian Software Engineering Conference (ASWEC’04), 2005. P. Ranjan and A. K. Misra “An Enhanced Model For Agent Based Requirement Gathering And Pre-System Analysis”, Proceedings of 13th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS) 2006, Potsdam, Germany, March 27th-30th, 2006. P. Ranjan and A. K. Misra, “A Hybrid Model for Agent Based System Requirements Analysis”, ACM SIGSOFT Software Engineering Notes, Volume 31, No. 3, May 2006. P. Ranjan , Soumya Suravita, R.K. Singh and A. K. Misra, “Improved Performance of Agent Based Placement Cell System - A Performance Efficient Role Clustering Technique”, WSEAS Transactions on Computers, Issue 10, Volume 5, October 2006 . P. Ranjan and A. K. Misra, “Agent Based System Development – A Domain-Specific Goal Approach”, ACM SIGSOFT Software Engineering Notes, Volume 31, No. 6, Nov’ 2006. R. Depke, R. Heckel and J. M. Kuster, “Improving the Agent_Oriented Modeling Process by Roles”, Proceedings of the fifth International conference on Autonomous Agents (ACM AGENTS’01), 28 May – 1 June, Montreal, Canada, 2001. R. Depke, R. Heckel and J. M. Kuster, “ Roles in Agent_Oriented Modeling”, International Journal of Software Engineering and Knowledge Engineering, Volume 11, No. 3, 2001. T. Juan, A. Pearce and L. Sterling. "ROADMAP: Extending the Gaia Methodology for Complex Open Systems", Proceedings of the First International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS), p310, Bologna, Italy, July 2002.