Schedule - Opponents - Topics and guidelines
The presentation of papers is splitted in four sessions :
Here is the workshop schedule : A presentation of 8 minutes is allocated for each paper and then a discussion is conducted on the topic.
Please note that you will have access to the following equipment :
In order to not waste any time it would be a good idea that :
|
Time
|
Place
|
Activity
|
09.00-09.15 |
Introduction - brief presentations of participants | |
09.15-10.15 |
Session 1 (papers 3, 11, 12) | |
10.15-10.30 |
Discussion of schedule (if time permits) | |
10.30-11.00 |
Coffee break | |
11.00-12.00 |
Session 2 (papers 6, 7, 9) | |
12.00-12.30 |
Session 3 - beginning (papers 8, 13) | |
12.30-13.30 |
Lunch break | |
13.30-14.00 |
Session 3 - end (paper 4) | |
14.00-15.00 |
Session 4 (papers 1, 2, 5) | |
15.00-15.30 |
Coffee break | |
15.30-16.45 |
Work group | |
16.45-17.30 |
Plenary session -- summary | |
For each paper one opponent is designated by the organizing committee. His task is to read the paper and be prepared to initiate the discussion by means of relevant questions. The assignment of opponent proposal is presented in the following table:
Each paper fits within one of the four topics so that it has been included in one of the four sessions that we will have during the workshop (of course it is our interpretation). When you prepare your presentation, please try to address the questions or the problems mentioned in the topics described hereafter (especially the ones proposed in the topic associated to your session).
Form and Transform, Dealing with evolution (session 1)
In this topic, we would like to explore the way methodologies, languages and tools can help us or at the contrary bother when dealing with hierarchy construction and evolution. The papers of the session more precisely raise two questions:
Class composition (session 2)
Is class composition worthwhile? Pro: it is powerful. Con: the resulting software is complex and hard to maintain
Different kinds of subclassing relationships (session 3)
In UML it is possible to provide a more accurate definition of the kind of inheritance to use through the specification of tagged values and/or UML profiles. Should we use this facility when we design an application? How many kinds of inheritance relationships are needed? If we use several kinds of relationships is it suitable to get also several kinds of inheritance relationships within programming languages or systems ? How many kinds does your language/system/.. have or should have according to your point of view ?
Contradiction between desired subtyping/specialization relation and language mechanism (session 4)
What to do when the desired subtyping relation that one would like to exploit in one's program does not match the particular subclassing mechanism that one has employed to create that program ?
When programming, inheritance is often employed as a reuse mechanism,
with no intent to create a subtype. And subtypes can be built through many mechanisms other than inheritance. What facilities should languages offer to deal with this distinction, and how can existing languages be used to address it?
(*) Menu is identical to the "flash" one
This page was updated on 06/21/2004
Maintainer : Philippe Lahire (lahire@#REMOVE-THIS#unice.fr) Do not forget to remove #REMOVE-THIS# from the electronic address