| |
| |
|
ENASE 2007 Advocatus Diaboli Forum Chairs
Brown, Robert B.K. University of Wollongong, Australia bobbrown@uow.edu.au
Loucopoulos, Peri Loughborough University, UK P.Loucopoulos@lboro.ac.uk
AD Forum Motivation
The Advocatus Diaboli (AD) Forum “court proceedings” play an important role in the mission of the ENASE working conferences. The AD Forum is directly inspired by an ancient, now discarded, mechanism within the Catholic Church whereby a so-called "Devil's Advocate" (AD) would assemble a prosecution case against candidates for canonization to sainthood. The AD was not required to necessarily believe the prosecution case they prepared, but was required to list every possible reason to reject the candidate's elevation. Proponents for canonization would then mount a defense, addressing each of the points raised by the AD.
Consistently with the motivating philosophy of ENASE conferences, the main agenda for AD forums is defined as to adversarially assess claims to novelty and utility for selected software engineering approaches. The AD sessions take place on each day of the ENASE conferences. They are divided case-wise by candidate software engineering (SE) approaches and are intended as putting these approaches on trial. For AD Forum at ENASE 2007 the candidate approaches are “3A”: agent-, agile-, and aspect-oriented software engineering.
ADF Scope
The three AD Forum topics are divided case-wise by candidate software engineering (SE) approaches and will each put one these approaches on trial. Prosecution cases have been prepared against each of these by invited expert authors. The candidate approaches are the “3A’s”: agent-, agile-, and aspect-oriented software engineering.
We specifically solicit defense papers, addressing and contesting the charges raised. Each submitted paper will present a defense for just one single specific case. Authors may submit multiple defense cases,2/04/09cted submissions. Acceptance or Rejection of each submission is independent.
To allow prospective authors to choose case(s) to address, and to see an outline of the prosec2/04/09Sheet” summaries of the prosecution cases from each of the following links:
<AGENTS>:
<AGILE> : <ASPECTS>
These “Charge Sheet” summaries each constitute the topics to be addressed in relevant Defense case submissions. Further, during the ADF ‘court sessions’, the final ‘judgement’ in each case will be determined by the success of valid, sound and compelling argumentation on these points.
ADF Publications
All invited AD prosecution papers, including their summary charge lists, and the defense papers will be published. Members of the Jury Panels will also contribute brief summary papers, outlining their findings. The publication opportunities are three-fold:
• the conference proceedings, under an ISBN reference, in paper and in CD-ROM support,
• a post-conference Springer book with the best conference papers, and possibly including the best papers and the summaries of the AD Forum,
• to coincide with ENASE, a special issue of Springer's Requirements Engineering journal entitled "Software Engineering meets Requirements" will be published after the conference and will constitute what is hoped to be the main publication opportunity for AD Forum contributions.
ADF Important Dates
March 5, 2007 Summary list of the charges by Devil Advocates
March 23, 2007 General Call for Defense Papers
April 30, 2007 Submission of "early" defense papers by authors who would like their papers to go to the proceedings (notification of acceptance on May 25 and the camera ready papers due on May 31, 2007)
May 25, 2007 Notification of acceptance/rejection
May 31, 2007 Camera-ready papers and registrations
June 15, 2007 Submission of defense papers not destined for ENASE proceedings and for a post-conference Springer book, but aimed at the special issue of the Requirements Engineering journal
July 22-25, 2007 AD Forum court proceedings at ENASE
October 1, 2007 Camera-ready papers for Springer book or for REJ special issue
ADF Submissions
Authors should submit a paper in English of up to eight A4 pages, carefully checked for correct grammar and spelling, using the ENASE’07-ADF on-line submission procedure. The guidelines for paper formatting provided at the conference website must be strictly used for all submitted papers. Authors must clearly indicate which of the three ADF ‘cases’ (Agile, Agents or Aspects) they are defending.
The submission format is the same as the camera-ready format. Please check and carefully follow the instructions and templates provided. The program committee will review all papers and the contact author (the author who submits the paper) of each paper will be notified of the result, by e-mail.
If the author is unable to use the web-based procedure then he/she can send the paper by e-mail to the secretariat attaching an additional file containing: the title, author(s), affiliation(s), contact details, a list of keywords and an abstract.
The ADF Process
1. Renowned experts are invited to serve as devil’s advocates to assemble strong and thorough prosecution cases against candidate SE approaches. The experts provide a summary list of charges.
2. The open AD Forum Call for Papers publishes the charge-lists drawn up against each candidate, and invite proponents to submit a defense for one or another SE approach.
3. Selected defense paper(s) for each case are chosen to be heard in the Forum court.
4. Each AD Forum court session is moderated by a Chair and the individual judgment rendered by an invited panel of three expert 'Jurists'. The Chair moderates all proceedings and adjudicates a final finding, drawing on the Jurists remarks.
5. Each AD Forum session is conducted as follows:
a. Opening remarks are made from the Chair.
b. The invited AD presents the prosecution case for 20 minutes. Their 'charge list' against the candidate SE approach remains on display throughout the proceedings.
c. The proponent then mounts a defense, addressing the charges, for 20 minutes.
d. The AD may have 5 minutes of rebuttal.
e. This is followed by 30 to 40 minutes of general discussion between all parties, including the jurists and forum attendees from the floor, moderated by the Chair, whose primary role is to maintain a constructive and civil debate. The Chair reserves the right to interrupt or redirect debate at any time, without appeal. Jurists have the right to interrupt presentations and discussions at any time to seek clarification on key points.
f. The three Jury Panel members render their individual 5 to 10 minute judgment on the case. They are not required to confer nor reach consensus.
g. Based on the Jurists comments, the Chair adjudicates a final result and renders closing comments. In particularly contentious or unresolved cases, the possibility exists that retrials or appeals may be heard in future ENASE AF Forums, time permitting.
It is hoped that these unique, informative and enjoyable AD Forums will elicit a profound debate which undercuts assumption, presumption and brand loyalty.
|
|
AGILE Specific Case: eXtreme Programming
- NFR – non-functional requirements
- Oral communication and automated acceptance tests do not sufficiently support some non-functional requirements, e.g. availability, usability, understandability and maintainability.
- Subsequent changes (e.g. requirements changes, incremental design, constant refactoring, shared code) influence the ability to assure expected availability levels.
- Demand of requirements traceability is a major obstacle to XP.
- Relying on the on-site customer as the requirements-giver has the danger of not getting the right people to specify requirements and to drive the development.
- Oral communication has the danger of never-ending refinements of requirements.
- Methodology of developing software
- Pair programming benefits do not compensate its overhead.
- There are interesting alternatives to pair programming, e.g. with less effort overhead.
- Test-driven development benefits do not compensate its overhead.
- Incremental design leads to a local optimum as opposed to a global one.
- It is impossible to predict the qualities of the final product of incremental design until you have the product.
- Management of the software system
- The customer inside the team is bound to take advantage of the situation or his knowledge about the team e.g. during the next bidding process.
- There is no manual on XP, only vague guidelines, call-to-arms-papers and “we did it this way” reports.
- It is difficult to prepare a complete XP manual without losing its agility.
- Without a manual and with the demand to follow all XP practices, the adaptive nature of XP results in a steep learning curve, and hence projects fail in the process of learning XP.
- ”XP is about social change” and thus it is very hard to implement XP in a well-established company.
- Economics
- Time-and-materials or Optional-Scope Contracts are rarely an option.
- The economic value of XP is strongly influenced by the debatable efficiency of pair programming and test-driven development practices.
- Evolving requirements and incremental design do not take into account that some design decisions made late are very expensive (even though following the XP practices is supposed to compensate for that).
AGENTS Specific Case: Multiagent Technology
- NFR – non-functional requirements
- Only little involvement of well-established AI knowledge representation methods for the modeling of early user requirements.
- Focus in requirements engineering is more on single agents than on multiagent technology.
- Low status of knowledge about the proven effects of multiagent technology to important system characteristics, such as scalability, robustness, maintability, etc.
- No multiagent technology project metrics available.
- Methodology of developing software
- Is there any adoption of multiagent technology by software engineers?
- No distinction between requirements analysis and requirements specification – without any motivation or explanation, nor with a clearly presented alternative approach.
- Systematic development, evaluation and standardization of architectural concepts is – like in AI – still weak, i.e. much weaker than similar work in younger software technologies, like components and web services.
- The multiagent technology community does not adopt even solid results from software engineering research and development.
- As there is a little transfer of knowledge from related disciplines it is rather difficult to decide whether a positive contribution can be expected to research in software engineering.
- Multiagent Technology does not "think" in terms of software engineering life cycles.
- There are lots of sophisticated formalisms for knowledge representation, interaction protocols, etc. Unfortunately, these are much too often in computationally not tractable logic languages. In contrast to AI, research in multiagent technology does not address the transformation of higher order logics into computationally tractable languages.
- Management of the software system
- No multiagent technology specific project management, planning and controlling concepts or methods exist.
- Research on testing multiagent systems is far behind related work on testing in software engineering.
- No work yet in multiagent technology with relation to software maintenance.
- Any successful software engineering approach requires an integration of work processes, methods, tools, documentation, etc. across all phases of the software engineering life cycle. Again, multiagent technology does not address this challenge – neither in the core multiagent domain nor as a potential contribution to the integration problem in conventional software engineering.
- Missing industrial tools.
- Inappropriate standardization efforts: FIPA as the relevant standardization body is far too weak. Most "finalized" standards are still of unacceptable quality.
- Outside of universities there are nearly no educational and training opportunities in multiagent technology
- Economics
- Several agent and multiagent implementation languages exist, also do implementation tools and frameworks. There is, however, only little work evaluating the quality and usefulness of these languages, tools and frameworks against currently available best practices in conventional software engineering (and also not against standards in "single AI" knowledge engineering).
- Lack of qualified experimental work in multiagent engineering (if this field can really exist on its own)
- There is nearly no work addressing the quantifications that are necessary before an engineering method can be employed in an industrial setting.
- Outside of universities there are nearly no educational and training opportunities in multiagent technology.
- Also missing career opportunities for multiagent technology experts.
ASPECTS
- NFR – non-functional requirements
- Difficult to understand, verify and maintain: The life-time of the program modules that define aspects (aspectual modules) is in principle independent of the life-time of other program modules. Aspects can be also oblivious to aspectual and/or to non-aspectual modules and be programmed by independent programmers.
- It is impossible to guarantee the correctness of aspect-oriented programs in a modular way. Emerging interactions among aspectual and non-aspectual modules may cause undesired side-effects.
- Methodology of developing software
- From an implementation point of view, aspects can be considered as program pieces which are woven into the other program pieces in complicated ways. Aspect-oriented programming is just a technique for patching problems with your code.
- Aspects can be also oblivious to aspectual and/or to non-aspectual modules and be programmed by independent programmers.
- Aspects may be superimposed on program modules (such as objects) in such a way that internal structure of the modules is affected and/or modified. Aspect-oriented languages violate one of the important software engineering principles: encapsulation.
- Aspect-oriented programming is based on a few simple concepts and is not rooted to fundamental issues in modeling.
- Management of the software system
- Aspect-oriented languages are too difficult to understand and use for a (regular) programmer. The programmers must therefore learn and master two languages: the underlying programming language; and aspect-oriented extensions. Moreover, there may be non-trivial dependencies between the two languages.
- Aspect-oriented technologies are premature for commercial use. In order to have wide-spread industrial applications using aspect technologies, a large set of industrial strength tools, programming languages and systems have to be available for (commercial) use.
- Economics
- Currently only a limited set of aspect-oriented languages and systems are available.
- There have been only a few industrial applications developed using aspect technologies.
- Aspects are examples of trivial program pieces and they have no domains. Most aspect-oriented program examples as presented today are trivial programming practices such as tracing.
|
|
|
