90 likes | 102 Views
Explore the challenges in integrating MAS into conventional SE environments and how to enhance adoption by aligning methodologies, frameworks, and standards. Learn to leverage MAS benefits like goal-directed process selection, automatic exception handling, and common shared data. Discover strategies to influence key stakeholders and advance MAS adoption in software engineering practices.
E N D
The MAS – SE Gap: Bridging the DivideMichael GeorgeffPrecedence Health Care&Monash UniversityAutonomous Agents and Multiagent Systems, Estoril, Portugal, May 2008
Why aren’t we having an influence? We have not identified the value proposition for MAS across sufficient application domains to make it compelling; We have not translated the way we describe MAS into the framework used in conventional SE development environments We have not sufficiently focused on the key ideas, instead selling a whole package of complex concepts and mechanisms that go beyond the needs of mainstream SE; and We have not sufficiently well integrated our methodologies, frameworks and languages with existing standards and development infrastructures.
OfferP1 OfferP2 OfferP3 OfferP4 Conventional Hard-Wired Process Selection C1 OfferP1 C2 OfferP2 Close Sale Assess Customer C3 OfferP3 C4 OfferP4 The names of the called processes and the conditions (C1, etc) determining which to call in which circumstances are included in the calling process, complicating design, validation, reuse, and change. Development of called and calling processes cannot proceed independently of one another.
Goal: Offer Product Goal: Offer Product Goal: Offer Product Goal: Offer Product Condition: C4 Condition: C1 Condition: C3 Condition: C2 OfferP2 OfferP4 OfferP3 OfferP1 AO: Goal-Directed Process Selection Assess Customer Offer Product Close Sale Loosely Coupled Conditions of use are contained in the called processes. Processes are “loosely coupled”– i.e., selection is made dynamically at run time based on context of use (applicability). The called processes can be created/changed independently of each other and the calling process. Benefits multiply when the requested goal is reused in other calling processes.
Goal: Offer Product Goal: Offer Product Goal: Offer Product Goal: Offer Product Condition: C2 Condition: C4 Condition: C1 Condition: C3 OfferP2 OfferP3 OfferP1 OfferP4 AO: Automatic Exception Handling If any selected process fails or is unsuccessful, the call is repeated (reposted) and any newly matching processes invoked. Assess Customer Offer Product Close Sale Retry on failure Using goal-directed processing, no coding is needed in the calling process or the called processes for handling exceptions or failures. Conventional languages require explicit exception-handling links and routines to be coded into the process flows, rapidly turning into spaghetti code.
OfferP1 OfferP2 OfferP3 OfferP4 Conventional SE: Hard-Wired Data Flow Data D1 C1 OfferP1 Data D2 C2 OfferP2 Close Sale Assess Customer Data D3 C3 OfferP3 C4 Data D4 OfferP4 The data (D1, etc) needed by the sub-processes has to be passed from the calling process to the called processes (via parameters or interface dialogue). This requires the calling process to know what data the called processes need. This reduces process independence, complicating development, maintenance and change. Development of called and calling processes cannot proceed independently of one another.
Goal: Offer Product Goal: Offer Product Goal: Offer Product Goal: Offer Product Condition: C4 Condition: C1 Condition: C2 Condition: C3 OfferP3 OfferP1 OfferP2 OfferP4 AO: Common data shared across processes Assess Customer Offer Product Close Sale Shared Data D (Beliefs) Common data is shared among processes, so that there is no need to explicitly code the data flow. The calling process is simple and independent of the data needs of the called processes. The called processes can therefore be created/changed independently of each other and the calling process. Benefits multiply when the requested goal is reused in other calling processes. Get D1 Get D2 Get D3 Get D4
Loosely Coupled Loosely Coupled Loosely Coupled AO: Agents as Services Enterprise Services Bus Agents separate the interface from the implementation and provide a Services Interface to each other and to other components. Internal goals and shared data are localized to an agent. The Services Interface supports loosely coupled Services and Event-Driven processing. Semantics of goal-directed processing is extended to the service level. Seller Agent Shipping Agent
What do we have to do? Influence the influencers: Get uptake from the Gartner’s, Forresters, and large early adopters of the technology. Transform the story into something that conventional SEs understand. Make it an extension or progression of service oriented and event driven architectures. Identify the weak points in SOA and show how MAS solves these problems. Focus on the concepts and methodologies, not new languages. Let the concepts and methodologies drive extensions to BPEL, SOA. Focus on and standardize the key ideas, preferably by extensions to existing concepts. Don’t try to sell the whole package. Or alternatively, give up on the enterprise level and focus instead on niche markets requiring high flexibility, high complexity software solutions.