|
|
| Submissions Due |
August 10th, 2005 |
| Notifications Sent |
September 5th, 2005 (Early Registration is Sept 8th) |
How To Attend
Participation in the workshop will be by invitation based on the submission of a position paper, or through special consideration.
Potential participants may submit requests for invitation under two categories:
Research Paper
New, yet preliminary EA research (3-5 pages - to be reviewed by three members of the PC, and posted on the website) These papers should discuss the
work presented using the Pet Store application as a basis. They do not
need to be entirely based on the Pet Store, but authors should show that
they have read the documents for the pet store, and should at least
comment on how their approach would or would not work with that system.
If you have any questions about this, please do not hesitate to ask.
The paper format should be IEEE Proceedings format.
Study Topic
If you're a student who's new to the world of EA, or a researcher with some questions left
unanswered, then this option is for you. A study topic identifies potentially open questions in EA,
and sets out a plan for how to answer those questions during the workshop -- based on the
presentations given, by interviewing the other participants, and through observing the application
of the case study (3 pages, maximum).
For instance: A potential question might be "What do all the requirements
analysis techniques take as their working concept of a 'concern'?". Your submission would
include the kinds of information you need to answer that question, the kinds of follow-up
questions you would ask, and the techniques you would be interested in finding out more about.
You would then spend the
workshop day observing the presentations by the research paper presenters, and asking them
questions related to your topic. This is a unique opportunity to conduct a mini-case study
where the creators of the techniques are at your disposal!
These submissions can be in any format, but IEEE proceedings format
is appreciated.
Submissions should be sent to elisa-at-cse.cuhk.edu.hk.
Call For Papers
Early aspects are crosscutting concerns in the early life cycle phases of software development,
including the requirements engineering, domain analysis and architecture design activities. Early aspects
cannot be localized and tend to be scattered over multiple early life cycle modules. This reduces the
modularity of the artifacts in the early life cycle. Conventional aspect-oriented software development
approaches have mainly focused on identifying aspects at the programming level and less attention has been
taken on the impact of crosscutting concerns at the early phases of the software process. The early software
development phases actually set the early design decisions and have a large impact on the whole system.
Therefore, coping with aspects at the early life cycle phases as such is a primary issue.
In previous editions of this workshop, held in conjunction with AOSD 2002-2005 and OOPSLA 2004, we looked at
different techniques, tools and languages that support early aspects (visit http://www.early-aspects.net/
for more information). This time we are going to discuss the results of early aspects techniques, tools and
languages applied to the same system: the famous Java Pet Store application. Looking at the same concrete
example shall provide basis for comparison and promote collaborations and cross-fertilization of ideas to
improve the various techniques, tools and languages.
The Case Study: The Pet Store
The Pet Store is a web application that was conceived and implemented originally as part of the J2EE
BluePrints program created by Sun Microsystems. The goal was to help developers to learn the J2EE platform
by means of a complete example. Today, most J2EE application servers ship with a full implementation of the
Pet Store as a sample application. Because it is easy to understand and yet large enough to constitute a
rich example, this application has been used in several benchmarks and other studies. It has also been
implemented using Microsoft .NET and other technologies besides J2EE.
A live demo of the Pet Store application is available at: http://www.intelliview.com/demo/ms_demo.php#
The following page contains the PDF and html versions of the book "Designing Enterprise Applications
with the J2EE Platform, Second Edition":
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/index.html. The book is the
original source of information about Pet Store. The sections that describe the Pet Store application are:
11.2, 11.3 and 11.4.1.
For an example of requirements specification, domain model and software architecture documents of the
Pet Store created using a traditional object-oriented approach, visit the following page:
http://www-106.ibm.com/developerworks/rational/library/1072.html
Submission Topics
Submissions to the workshop should be primarily case study reports on the Pet Store application with focus
on one or more of the following topics:
Aspect-oriented requirements engineering
How can we identify or model aspects at the requirements level?
What are ways to integrate and compose aspects with other modeling mechanisms, such as goals, viewpoints
and use cases, and establish tradeoffs?
How does one trace requirements aspects through later development stages and during re-engineering?
How are aspects identified at the requirements level validated?
Aspect-Oriented domain engineering
What are the criteria for domain aspect decomposition?
How can we derive aspects from domain knowledge?
How can we abstract and generalize domain aspects for reuse?
What are the composition relations between domain aspects?
How to represent domain aspects?
Aspect-oriented architecture design
How can aspects be used to support system quality attributes in the architecture?
How can we reason about architectures and aspects to know that the architecture is a good one?
How can we reason about tradeoffs among aspects?
How can we model the architecture to take aspects into account?
When designing an architecture, how and when can we identify aspects?
How can we set the scope for a software product line architecture using aspects?
How do aspects fit in the Model-Driven Architecture approach?
Mapping between aspects in requirements, domain analysis, and architecture
Should the mapping be formal or informal?
To what is a requirements concern mapped onto?
What language features are required to support a mapping?
What are the pros and cons of mapping?
Tool support and automation for aspect-orientation
Which tools are there to support aspect-oriented development?
Formalisms and notations for specifying early aspects
What formalisms can be used at early software development stages?
|
