alexa Aspect Oriented Programming Perspective in Software Agents and Simulation | Open Access Journals
ISSN: 0976-4860
International Journal of Advancements in Technology
Like us on:
Make the best use of Scientific Research and information from our 700+ peer reviewed, Open Access Journals that operates with the help of 50,000+ Editorial Board Members and esteemed reviewers and 1000+ Scientific associations in Medical, Clinical, Pharmaceutical, Engineering, Technology and Management Fields.
Meet Inspiring Speakers and Experts at our 3000+ Global Conferenceseries Events with over 600+ Conferences, 1200+ Symposiums and 1200+ Workshops on
Medical, Pharma, Engineering, Science, Technology and Business

Aspect Oriented Programming Perspective in Software Agents and Simulation

M Fatih Hocaoglu*

Faculty of Engineering and Natural Sciences, Istanbul Medeniyet University, Istanbul/Turkey

*Corresponding Author:
Dr Mehmet Faith Hocaoglu
Faculty of Engineering and Natural Sciences
Istanbul Medeniyet University
Istanbul/Turkey
Tel: +90 216 280 33 33
E-mail: [email protected]

Received Date: April 21, 2017; Accepted Date: May 22, 2017; Published Date: May 29, 2017

Citation: Hocaoglu MF (2017) Aspect Oriented Programming Perspective in Software Agents and Simulation. Int J Adv Technol 8: 186. doi:10.4172/0976-4860.1000186

Copyright: © 2017 Hocaoglu MF. This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.

Visit for more related articles at International Journal of Advancements in Technology

Abstract

Agent-driven Simulation Framework-AdSiF provides a declarative scripting agent programming language. Stateoriented programming paradigm combined with multi-programming paradigms is at the background of script, which allows programming by extended state charts. Aspect-oriented programming paradigm draws a solution background related with scattered codes, scattered requirements and tangled requirements. While object-oriented programming paradigm gives a vertical software design, aspect orientation enhances this vertically deep design by horizontal association. Aspect-oriented programming paradigm, which is one of the components of AdSiF’s state oriented programming paradigm, provides a solution by a loosely-coupled script description to the problems mentioned. For this purpose, states and behaviours, which satisfy scattered requirements, are distributed to behaviour’s and behaviour lists, respectively and behaviour phase transitions based on behaviours and active states are allowed. In addition to all, Furthermore, in simulation and agent programming world, the solution provides a solution by shifting modelling aspects conditionally in run time for conceptually different modelling requirements and also tangled requirements. The solution carries aspect oriented programming from design time to execution time and provides a dynamically manageable, flexible, loosely coupled and high coherent design.

Keywords

AdSiF; Aspect oriented programming; Declarative language; Dynamic aspect; Script programming

Introduction

AdSiF can be defined in general terms as a declarative scripting language. The structure of AdSiF is a combination of multi programming paradigm and state-oriented programming [1]. The structural integration of Object-oriented programming (OOP), logic programming, Agent-based programming, and Aspect-oriented paradigms define ontological aspect of AdSiF.

The paradigms covered by AdSiF as well as reusability, interoperable and flexibility properties are in accordance with the world view. The integration of each paradigm with its world view provides a significant infrastructure for agent-based simulation modelling. This approach ensures that the application will be able to responsive with the characteristic of behavior planning and has autonomous and anthropomorphic ability, at the same time; simulation models will be more social, flexible and interoperable. Due to fact that the models reach available information in their environment and make reasoning based on collected information are two of main advantages of logic programming paradigm. Hence, it provides a Dual-world representation for simulation models.

In this study, the AdSiF solution approach of aspect based programming paradigm is handled. Then, the conceptual model of solution and its contributions to the modelling techniques are discussed by exemplifying. Thereinafter, the background information about aspect-oriented programming paradigm is explained comprehensively. In section 3, the solution of aspect-oriented programming paradigm, in section 4, a case study in the field of simulation will be provided. Lastly, the benefits of AdSiF aspect-oriented programming are dealt with in the conclusion part.

Aspect Oriented Programming

Aspect-oriented programming (AOP) [2,3] aims to categorize different design objectives and to structure modular software [4]. The essential interests of aspect-oriented programming are especially scattered requirements and tangled requirements. Scattered requirements can be accepted as a significant obstacle to modularity. In the approach simulation environment, a model is interpreted that it is able to categorize anticipated behaviors by modeller for different conceptual world and resolution.

Aspect-oriented programing solution is considered as a solution which starts from requirement phase and consists of coding and modelling level includes analysis and architecture design. The AOP does not introduce a completely new design process but just a new means to enhance design [5]. As procedural programming brought functional abstraction and object oriented programming gave birth to object abstraction, aspect-oriented programming introduces concern abstraction [5,6].

In the literature, Aspect J-Like and Hyper J-Like solutions are commonly preferred. The essence of Aspect J-Like approach is defining point cuts. In the Hyper J-Like approach, the combining of state graphs belongs to independently developed models are provided and it requires refactoring differently from Aspect J-Like.

Aspect-oriented programming has been seen as an important support in software metrics especially in terms of modularity, simplicity and readability [7]. There has been relatively limited number of studies available in the literature on computational aspect of AOP parameters [8]. Kersten and Murphy have showed in NPY applications the success of AOP with the practical implementations and developed codes of practice [9].

In the article of Walker et al., an initial view of usability metrics for AOP has been provided [10]. Soares et al. have indicated the high performance of Aspect J applications particularly in web-based applications. The most remarkable study among other researches is carried out by [11], due to fact that it is directly related to our application area, AdSiF, which is agent-based application and provides agent programming language. They provide a computational assessment between template-based approach and Aspect-based programming for multi-agent programming systems. In this study, it is also concluded that agents provide an advanced modularity for cross cutting requirements.

Among previous studies on the integration of OOP design template-based software development and AOP, Vaira and Čaplinskas concentrate on generating design templates independent of the software paradigm. Additionally, they claim that design templates which can be applied to different paradigms are also available [12]. Tsang et al. have evaluated the interest separation performance of AOP. In the study, CK metrics [13] is utilized and the comparison of OOP and real time systems of AOP is clarified. In the result of this investigation, a developed modularity and a reduction in cohesion are observed [14]. The work on cohesion measurement properly in AOP is undertaken by [15] and they provide a generic framework to define cohesion.

Not only studies on generating abstracted designs and separation of design aspects created by AOP but also some studies especially pointing to solve semantic confusion between the designs of aspects are carried out recently [16]. Also, it is investigated from article that the coordination and cohesion of design aspects can be improved in parallel with reusability, modularity and extendibility metrics. A considerable amount of literature has been already published on modularity and much more information has become available to modularity strengthen [17].

In the application of safety and mission critical system includes non-functional requirements like error tolerance, tangled and scattered non-functional requirements are provided by AOP design pattern. These patterns are improved for error detection, error management, recovery mechanism and leakage controls in safety systems [18].

The essential approach in use of AOP in AdSiF is accepted as a model integrated computing (MIC) solution platform [19,20]. Generally speaking, in model integrated computing environment, the main concern is model and a software system is seen as a collection of models at different levels of abstraction. Every collection represents a different perspective of the system and from this perspective, each engineering task is considered to be the description of a model [21].

AdSiF Aspect Based Programming Solution

In the AdSiF modelling approach, a model contains all modeling perspectives and each of the different modelling perspective is considered as a behavior category. All the behaviors that an agent and/or a simulation model have are grouped under logically separated categories. In each category, semantically close behaviors are accommodated. For example, the behaviors related with moving capability for a human model are collected in a specific behavior category by separating them any other behaviors such as capabilities of cooking, reading, and writing. Separating semantically different behaviors from each other into categories gives modellers the ability to manage models according to behavioral aspects. Furthermore, AdSiF provides a solution for the problem to scatter behaviors or states which meets scattered requirements to behavior and behavior sets with low cohesion and high consistency [22]. This point of view ensures the allocation of scattered requirements with behavior perspective to model behavior and the classification of tangled requirement sets. The approach which is different from model integrated computing (MIC) is that same model is separated by different categories instead of taking modelling perspective apart different modelling. Similar perspective with Aspect J, it executes point of injections in the time of synchronization status operating, internal state transition, behavior triggering and event sending.

Behavior list can be defined as a set of behavior which provides a particular modelling perspective. Behavior lists are arranged in attempt to meet requirement groups with regard to represented perspective. A model has at least one active behavior category and the number of active category is not limited to one. A transition between different perspectives in the case of meeting defined conditions is made possible when a behavior category activate/inactivate different categories according to both change of simulation/agent environment and change in its status.

Aspect separation carried out behavior categories which provide a significance flexibility to manage cohesion and contradiction. Keeping behaviors that must be separated from each other (i.e. that causes conflict from time to time) in discrete behavior lists, designing activation conditions by negating means and taking place behaviors which there are dependencies in the active root list ensure high flexibility.

As shown in (Figure 1), FsaListBase is defined as a “public” derived from FsaList.0 and FsaList.1 It has two behaviors namely, Behavior.C and Behavior.D which is defined as a “private”. Public Behavior is created by derived Behavior by inheritance and considered as a Behavior which is able to perform functions executed in both two Behavior lists.

international-journal-of-advancements-in-technology-list

Figure 1: Structure of behavior list.

Separated behaviors from behavior list (Behavior.0 and Behavior.5 in FsaList.0 whereas Behavior.2, Behavior.3 and Behavior.4 are derived from FsaList.1) perform behavior operations belonging to two different aspect. Logical statement description called Act.1 and Deact.1 enable FsaList.0 behavior list that they belong active and passive in the case of meeting the requirements in run time. Similarly, the defined requirements are applicable for FsaList.1. FsaList.0 is identified as start-up behavior list of relevant model. Behavior.5 and Behavior.4 are determined as a startup behavior of behavior list.

Common requirements within different behavior perspectives of models contain either states which are scattered to behaviors and cover function of provided requirements or behaviors which meet requirements scattered to behavior lists. As it can be seen from (Figure 2), Func.0 function, a cross-cutting function, is distributed between function modules which provide scattered requirements by distributing it different behaviors into different behavior list with State.C. In a similar way, the function is transferred into either different models or different aspect of same model by distributing the requirement provided by Behavior.1 in different behavior lists. Distributed states or applications of behavior junction point may differ in distributed model or behavior list.

international-journal-of-advancements-in-technology-behavior

Figure 2: Aspect management with behavior list.

In our example, Behavior.1 and State.C in FsaList.0 are operating with internal state transition, whereas Behavior.1 that is triggered by an event in FsaList.1 and State.C are processing as a conditional activation. With this design, software design deepening in vertical axis is extended and associated with the horizontal axis.

In addition to behavior lists and solution applied with distributed states in behaviors, new requirements are obtained by integrating different models which different requirements set provide. The integration process takes place in two types; composition or aggregation. A model is modeled to include multiple sub-models. Compound models conserve all behavior structures. A top model contains all submodels undertakes time and event management of sub-models and for this purpose, it generates a simulation subset within itself.

In the design presented in Figure 3, a composition relationship between Model.A and SubModel.0 is defined while Model.A is associated Submodel.1 and SubModel.2 with aggregation relationship. Model.A takes on time management task of containing models and performs as an interface for event distribution. Each model which executes distribution carries out event process itself. When it is considered that each combined model manages different an aspect with behavior list, as in MIC, distributing aspects into models is carried out by the higher category model.

international-journal-of-advancements-in-technology-model

Figure 3: Aspect decomposition at the level of model.

Another major contribution of AdSiF to aspect-oriented programming is Delayed-Loaded Atomic Function Plug-ins (DlAFPs) which enables the loading of atomic functions operated by behavior states on processing time. This feature allows improvement and model enlargement even in run time and it is a significance measure of expandability of AdSiF. The approach provides a compact solution which has quiet low software cohesion and high consistency. AdSiF is accepted as a considerable development which transforms AOP from design phase to run time because of the fact that active behavior categories can be changed depending on defined conditions and user/ model interactions and plugins of related functions can be loaded in run time.

Managing scattered requirement

AdSiF provides a set of solutions to satisfy scattered requirements.

These are;

• State Distribution; a state invoking functions that satisfy a scattered requirement in its related phases is placed to the behaviors so that the behaviors activate the state at correct time to satisfy the requirement such as logging operations.

• Behavior and State Distribution; a whole behavior that satisfies a set of specific scattered requirements is put into the behavior lists that need to satisfy the requirements. The behavior is activated anytime that is needed by defining an activation condition. The activation condition decides when the behavior is activated and the behavior achieves a set of functions.

• Temporal Relation; the usage given above is based on the behavior that satisfies a scattered requirement set. A behavior directly invokes the behavior that satisfies a scattered requirement set. The main difference is modeling perspective. In the usage given above, the responsibility is in the behavior that satisfies scattered requirements. In this usage, the behavior invoking the scattered behavior is in charge of.

• Behavior conditional Phase Transition; It is possible to determine activation condition of a behavior depending any other behavior state transition. Similarly, any type of phase transition also is defined depending on any other behavior state transition such as cancelled phase, suspended phase, and resumed phase. In Figure 4, it is seen that a set of phase transition condition is attached to the behavior Fsa_Logging. The first and the second conditions mean if any behavior makes a state transition named State_0 (enter phase) and State_1 (exit phase), the behavior Fsa_Logging is activated. It is assumed the behavior Fsa_Logging is a behavior that satisfies a set of scattered (crosscutting concern) requirements. Similarly, as seen from the third condition, if the behavior named as Fsa_Step exits (state Phase) from its state named Step (state Name) the behavior Fsa_Logging is activated (drive Type) after a duration determined by attribute0, if the condition is satisfied given in the guard block (if Func_D returns true). The fifth condition means if the behavior Fsa_Analyze is finished the behavior Fsa_Logging is activated. It is also possible to declare a guard for all declarations as is done in the third declaration. As an opposite approach, in Figure 5, if the behavior Fsa_A enters State_1, the behavior Fsa_B is activated. The usage allows modelers make more specific definitions. The opportunities make aspect programming a declaration issue, not a function programming issue. The point is that scattered requirements are met by behaviors placed into behavior lists or states placed into behaviors that invoke functions that satisfy the requirements (crosscutting functions). The behaviors have their own semantics that are being able to be overridden in any simulation entity/ agent situated in inheritance hierarchy and also behavior lists have activation and deactivation conditions providing immediate reactions to the requirements arising in run time. Being able to satisfy a scattered requirement by a set of function wrapped by a state or a behavior provides designers a state and behavior phase based function execution. The designer may define a specific state transition phase to execute a set of function and he/she wants it to execute any time the phase transition happened. The conditional phase transition does not intervene model behaviors and functions because it is an indirect invocation.

international-journal-of-advancements-in-technology-transition

Figure 4: Indirect phase transition.

international-journal-of-advancements-in-technology-activation

Figure 5: Direct activation with temporal relation.

Managing Requirements

Each behavior list is designed to meet a set of requirements. As mentioned earlier, it is possible and offered to design a behavior list with a well-defined purpose aiming to satisfy a bunch of requirements connected each other. Since they may have activation and deactivation conditions, it is possible to react any requirements at the time they arise. This is also named as dynamic aspect management.

Dynamic aspect management

Dynamic aspect management is related with being able to activate or deactivate behavior categories in run time depending on constraints associated with them as activation condition and deactivation conditions, respectively. Since each behavior category or a set of category represent an aspect, an activated behavior category because of its satisfied activation condition is to transit to the aspect that suitable for the state that is defined by its activation condition. An activated aspect dynamically loads the function libraries that consist of functions to be reached by the behaviors. A deactivation condition also works as similar with an activation condition and it deactivates the aspects that are not suitable for conditions or the states that the entity is in.

Aspect management with relation

A relation is defined between two entities and it has two sides named left side and right side. Both sides may have more than one entity. A relation is defined depending on conceptual model. For example, the sentence “a commander commands the soldiers” consists of a relation such as “commanding” between commander and soldiers or “an F16 carries Type-A missiles” defines a relation between F16 and type-A missiles. It is possible to make definitions more general based on their inheritance structure. A relation define over root level entities is valid for the derived ones. More specialized relations are defined between higher level entities. Instead of defining a relation between fighter aircrafts and missiles also covers F16 and Type-A missiles. A relation serves basically for two tasks.

1. Messaging; the main point in messaging, to provide a mechanism for the entity that sends a message without necessity to know exactly what entity to be sent. The entity sending a message says “I am sending this message (event) to the entity that has a relation named Rel with me and located on left or right side of the relation” instead of saying “I am sending this message (event) to EntityA”. This provides an opportunity to be able to change the entity that receives message without making any change on the entity that sends the message. In other words, the relation establishes a loosely coupled interaction between entities.

2. Behavior Management; it is possible to declare a set of behavior lists and actions to activate, any time a relation is established between two entities and detached. The declaration is done for both sides and consists of what behavior category or categories are activated and what actions are executed. Establishing a relation may be seen as an activation condition for an aspect and detaching is vice versa.

Especially, behavior management with relation concept is strictly related with dynamic aspect management, since it can be used as an aspect activation and deactivation constraints

Aspects and Simulation Concerns

The concerns that are separated using aspect oriented programming approach of simulation are examined under two categories. The first category is named as simulation execution and it consists of synchronization, event scheduling policies, optimization and distribution [5]. The second one is about business layer. Business layer means what we expect from simulation entities do. While the simulation layer concerns deal with execution of simulation itself and it is independent from any implementation domain, the business layer is strictly related with implementation domain and the focus is to manage tangled and cross-cutting requirements by arranging behaviors so that entities have behavior categories that consist of behaviors satisfying a group requirements and behaviors and/or states that satisfy scattered requirements such as logging, security, graphical representations are scattered among different behavior categories.

Simulation execution concerns

The concerns taken into consideration under this category are established by many simulation tools more direct way and it is mostly not possible to change their solution approach. In this study, the main motivation is to make event scheduling policy, synchronization algorithms (parallel simulation execution), and distributed execution changeable, even in run-time. The main idea is to switch from an aspect to another depending on the condition the entity is in. An aspect may consist of a set of behavior either belonging domain (business) or belonging simulation management. Since the aspects that consist of managerial behaviors have higher importance, the behaviors that they have are executed before the domain behaviors. That means the simulation management functions are run before the domain functions. If a modeler desires to change simulation management algorithm to be executed or being executed, he/she defines activation and deactivation conditions for the behavior lists that each consist of a specific simulation management algorithm such as optimistic simulation algorithm, conservative algorithms etc. The behavior list with satisfied activation condition is activated and it undertakes the simulation management. The solutions exemplified below are modelled as separate behavior lists.

The fact that simulation management functions such as collecting and distributing events, requesting interval state transition times, requesting temporal relation time between behaviors are common function and the state surrounding the functions are used in different behaviors representing simulation management in different behavior lists. Distributing states and behaviors are to satisfy scattered low level simulation requirements. To be able to design our own time warp algorithm behaviors and the aspects consisting of behaviors allow us to separate a specific simulation management solution from other solutions and behaviors. The atomic functions are kept as atomic as reusable for any other algorithms.

It is aimed to show and exemplify how it is possible to satisfy simulation concern using state oriented approach based on AdSiF solution by given synchronization algorithms under this section

Time management and synchronization: Time warp mainly focuses on time management and event handling to be able to satisfy local causality constraints. For parallel/distributed simulation, it guaranties that a parallel/distributed simulation execution gives the same result with a local execution.

For both local and parallel/distributed execution, the algorithms for time management and event handling are designed as behaviors. Because of their high importance, the behaviors are processed before the domain behaviors. The management algorithms are collected in separated behavior lists. The management behaviors are interpreted by core script engine as is done for all behaviors. Modellers may design different time management, event handling and synchronization algorithms defining their algorithms as behaviors.

In Figure 6, a time advance based time management algorithm is modeled as a behavioral aspect. Atomic actions for time management such as collecting time requirements (by the function transition time), collecting and distributing events (Scheduled Event Time), handling temporally related behaviors (Temporal Relation Time) (activating, cancelling, suspending, or reactivation a behavior from a state or any other behavior), and determining event processing orders are called from management behavior states for a local simulation execution. Until all time requirements are determined and the minimum time selected, simulation time advance is not allowed (Set Advance Time). This is achieved by the synchronization object Sync. The events to be processed are sorted according to their importance criteria and importance parameter is calculated by a function declared by modellers. While the algorithm is based on scheduled events and state transition times (including temporal relations), it is possible to design a set of behaviors as another aspect based on next event time. In this case, next time to advance is determined according to both the next event time stamp to be processed and state transition times. For next event scheduling, optimistic and conservative approaches are applicable for local executions and distributed simulation. For parallel/distributed simulation, time warp implementation is shown here (Figure 7) for roll back mechanism [23] as an implementation of optimistic approach. Null message passing is as an implementation of conservative approach.

international-journal-of-advancements-in-technology-time

Figure 6: State time advance.

international-journal-of-advancements-in-technology-mechanism

Figure 7: Roll back mechanism.

Rollback mechanism, as seen in Figure 7, is given below;

• Check event to be processed and choice the event with the closest time stamp to the simulation clock (Fsa_TimeAdvance “Check Next Event” state),

• Is the event time is earlier than the simulation clock (Activate:In:Guard (SimulationClock > EventTimeLabel )) ?

• If yes, then roll back the simulation to an earlier time point than the event time (Δe) (Fsa_RollBack),

• If no, Check internal transition time (Δint) (Fsa_ StateTransitionTime) and temporal relation time (Δtr) (Fsa_ TemporalRelationTime),

• Find minimum time min={Δint, Δe, Δtr}

• Grant minimum time (State “Next Time”),

• If the current simulation time is equal to the event time, then consume event,

• Save simulation state vector,

• Go to the first step.

It is possible to design a behavioral model of more other time wrap algorithms such as Null message passing, centralized barrier, tree barrier, butterfly barrier [23] etc. It is contended giving an example to show how a time warp algorithm is modelled as state diagram and how it is ensured it manages simulation execution.

Business concerns

At business layer, depending on simulation conceptual mission model, simulation entities categorize their behaviors depending on requirements and they activate or deactivate according to the constraints attached to each. Activation and deactivation constraints are determined based on environment conditions and state of entities. Business layer concerns are placed at the top layer of the simulation concerns and the behavior categories and behaviors they consist of are executed after behaviors and behavior lists that of simulation concerns because of their low precedency level comparing with simulation concerns. Examples for business layer aspect definition are given in Section 7.1.

Application Categories for Simulation

In this section, application area has been considered from a more general overview and an application template for simulation applications in two basic categories which are having a purpose of analysis and education has been drawn. In analysis-aimed simulation application, modellers rarely need real-time and user-interactive operation. The main expectations are simulation run speed and log. Access to the highest possible speed, taking simulation run log at desired level of detail and under the required conditions/time are a significant requirement set in analysis simulations.

In education-aimed simulation application, real- timeless, graphical user interface and user-interaction are often encountered as the more important requirements. Although engineering calculations performed basically are same, varying requirements necessitate different functions based on common engineering solution for both categories. Solution in education-aimed simulations, categorically, gathers interface controls and execution speed controls in different behavior lists whereas in analysis-aimed simulations, high resolution run log behaviors and the behavior related the highest possible execution speed control are determined as an active the behavior list. Besides that, behaviors which are common to both cases and including engineering calculation algorithms are kept actively as a common behavior list.

Case studies

In this section, two illustrative example are given to show how different aspects are defined and implemented for an entity and how a relation to be used to change aspects.

Radar example: The application is related to searching and tracking behavior in radar model. Instead of developing two radars models as searching radar and tracking radar separately, one radar model which is able to perform in two different modes which are search and tracking is developed. Essential functions such as detection calculation, rotational movement in a given angle and direction are applied to both operating modes. The difference will be realized in behavior design which manages functions.

In tracking mode, radar rotation behavior which is designed so as to follow a specific target has taken place in the tracking behavior list, while in searching mod; it has been available in searching behavior list as a consistently rotational movement design.

In Figure 8, for two radar behaviors, being active and analysis execution behaviors located in root behavior identification are located. The rotational movement makes two radar types different from each other as seen in Figure 9. Two behavior lists shown in the figure above have presented the logging operation in behavior form as a state definition of behaviors with alternative design.

international-journal-of-advancements-in-technology-root

Figure 8: Root model behavior.

international-journal-of-advancements-in-technology-track

Figure 9: Search and track behaviors.

In response to a detection event received from Figure 8, target data analysis is executed and after the analysis, logging process is performed. Search radar behavior seen in Figure 9 makes angular rotation in defined time steps with Compute Duration time calculator and is carried out this rotation as a constraint for defined angle ranges. In track radar behavior, the rotation is performed by using calculated time for determined angle with turn event and a consistently repeated behavior is carried out. Besides, logging process is being proceeded as a behavior triggered by tracking behavior instead of being a state.

As seen in the example, logging operation as a cross cutting function is achieved by both distributing a state surrounding the function into behaviors and activating as a separate behavior that consists of the function.

Command and control example: A C2 model taken consideration keeps the behaviors that send weapon target pairs to tactical picture model and the behaviors being under command to create a command control structure in this example. A commander may be put under command of another commander by constituting a relation between two commanders. It is named as “Commands” relation and it can be used between two commanders. “Commands” relation is designed between two types of entities. The first one is a commander being under command and the other that commands. Being under command reports detections that it receives from its sensors and the commander that commands collects all the detection coming from the commanders that it commands and makes a decision and orders the commanders or one of the commanders that it orders what to do. Reporting detection and waiting for an order to do is defined as a specific behavior category and it is activated by the commander being under command that is located on right side of the relation (Commander-R-0 and Commander-R-1). The behaviors consisting of whole commander roles such as engagement, target evaluation are undertaken by the commander that commands and it is located on left side of the relation Commands. While the commander being commanded to make its behavior list shorten as enough as to send detection and implement what the order wants it to do deactivates rest of the behavior lists, the commanding commander undertakes all behaviors necessary to manage a set of sub-commanders and to achieve whole requirements of a commander.

From this point of view, in a scenario, different instances of the same entity may have different behavior categories, in other words, different behavioral semantics. In Figure 10, a C2 structure is established between three commander entities. Commander-C commands Commander-R-0 and Commander-R-1. The relation Commands is defined for this purpose and the commander that commands is located on left side of the relation and also a relation between Commander-C and Tactical Picture entity is established named as “Sends Information”. Using the relation, commander sends detection collected from the sensors to tactical picture entity to make them depicted on a map.

international-journal-of-advancements-in-technology-entities

Figure 10: Relations between entities.

As seen in Figure 11, Commander-C entity activates the behavior list named as “DepictDetectionsOnMap” to send detection information to the tactical picture model entity to depict them on a map. The behavior list consists of a set of behaviors for this purpose. Similar way a commander that has a relation named as “Commands” and it is located on left side of the relation, activates the behavior list named as “CentralC2” that consists of behaviors that are in charge of command and control functions. When the relation is broken, the behavior list named as “CommandeFsaList” is activated and the function Af_ SetReportAddress is executed. Any time establishing and breaking the relation activates related behavior lists and executes related functions.

international-journal-of-advancements-in-technology-relations

Figure 11: Behavior management by relations.

Notice that the relations, behaviors, and functions are defined by modellers they are not build-in structures. The usage allows modellers to manage dynamically a set of behaviors and functions satisfying dynamically arisen requirements and to handle changing roles in run time.

Conclusion

When AdSiF aspect-oriented programming is combined with Model Driven Architecture (MDA)/Model Driven Development (MDD), a quite powerful and flexible modelling platform is obtained. Thereby, AdSiF carries its designed environment and objects which built by object oriented programming one step further with behavior, situation description and reasoning mechanism.

Aspect-oriented programming approach provides a flexible solution by using behavior and behavior list of AdSiF as a design pattern to meet scattered and tangled requirements. With the help of this approach, it is possible to improve simulation and agent modeling whose maintenance and development are quite hard by preventing scattered code of atomic functions between which cannot establish a semantic link. AdSiF can be seen as a flexible and user friendly solution based on AOP in terms of providing scattered requirement (cross cutting requirements) with scripting programming language, allocating state definitions which covers requirement function to behaviors and using independent behavior forms in the behavior list.

Functional extensions includes activation/deactivation run time of a behavior list and software plugin run time provide a considerable flexibility in which aspect programming solution which is transformed design to simulation run time.

The solution gives more than one alternative solution to develop an aspect. These are distributing a state or a behavior that satisfies a scattered requirement or a set of requirement to behaviors and behavior lists, respectively and activating a scattered behavior by temporal relations, phase conditioned, or function conditioned. Indirect behavior activation (more generally behavior phase transition) because of its indirect invocation method, the solution does not intervene function source code and behaviors of simulation entities and/or agents, this support orthogonally criteria in software engineering. Any change on behaviors does not require changing source code or other behaviors.

Introducing relation concept into agent and simulation world makes dynamically change behavioral aspect of the entity in run time possible. Any time a relation established and broken a set of functions and a set of behavior lists (consisting of different aspect properties) are activated and deactivated, respectively. An entity may establish and break many relations in many times.

One of the major contributions of AdSiF to aspect-oriented programming is Delayed-Loaded Atomic Function Plug-ins. This feature allows improvement and model enlargement even run time and it is a significance measure of expandability of AdSiF. The approach provides a compact solution which has quiet low software cohesion and high consistency.

For distributed simulation, some of the time synchronization algorithms are modelled as behaviors. The behaviors are script declarations and they are interested by simulation/agent core engine. The layering and separating entity behaviors and allowing their execution depending on their priorities allow modellers to design their own simulation time management algorithm as a behavior set without making any change on interpreter core.

References

Select your language of interest to view the total content in your interested language
Post your comment

Share This Article

Relevant Topics

Recommended Conferences

Article Usage

  • Total views: 54
  • [From(publication date):
    August-2017 - Jul 28, 2017]
  • Breakdown by view type
  • HTML page views : 35
  • PDF downloads :19
 

Post your comment

captcha   Reload  Can't read the image? click here to refresh

Peer Reviewed Journals
 
Make the best use of Scientific Research and information from our 700 + peer reviewed, Open Access Journals
International Conferences 2017-18
 
Meet Inspiring Speakers and Experts at our 3000+ Global Annual Meetings

Contact Us

 
© 2008-2017 OMICS International - Open Access Publisher. Best viewed in Mozilla Firefox | Google Chrome | Above IE 7.0 version
adwords