ArchStudio Meeting: July 18, 2008
Meeting to discuss and decide on ArchStudio 5 metamodeling and data binding issues.
Logistics
- Location:
- ICS2-136 on the UCI Campus
- Time:
- 11AM-5PM (scheduled)
- Notes:
- BYO Lunch
- Attendees:
- TBD
Outcomes
- Open tickets updated
- Policy decisions were made, changes are on the wiki
- New xADL metamodel using XML Schema + extension patterns discussed and tentatively accepted
Agenda
Old Business
- Open ticket status
- Resolve consensus process and voting from the last week on policy issues
- Resolve repository organization issues
- TPS/SVN integration problems
- TPS Performance problems
- Ensuring archstudio-dev can be on the CC list for Trac tickets without requiring moderation.
New Business
Following is a list of questions we would like to attempt to answer at this meeting. Feel free to refine/expand the list, and send answers to Kari Nies.
- What should be the metamodel for a future version of xADL?
- How can/should the xADL metamodel be expressed?
- How will tools enforce syntactic rigor?
- When will tools enforce syntactic rigor?
- Currently, we use generated data-bindings as the primary approach here. Should we continue this practice?
- How will tools enforce semantic rigor?
- Currently, we use Archlight constraints and knowledgeable editors like Archipelago as the primary approach here. Should we continue this practice?
- How will this meta-model support divergent evolution?
- That is, how will the meta-model support two people making different, possibly incompatible extensions from a common base?
- How will this meta-model support convergent evolution?
- That is, how will the meta-model support two people taking different extensions to the same base and bringing them together again?
- How will this meta-model support cross-cutting aspects?
- Will this meta-model's tool support allow us to encapsulate the data store in a component like xArchADT where all interactions use serializable parameters?
- How will this meta-model's tool support integrate with Eclipse?
- How will this meta-model's tools deal with instance documents that refer to elements for which meta-models are not available (i.e., instance documents that contain elements whose syntax is defined in a piece of the meta-model you don't have?) How gracefully will it degrade?
- Challenge Case 1 (Divergent and Convergent Evolution)
- Assume that we define a construct in "official" xADL called a Fidget.
- Assume that one user comes along and extends the Fidget by adding a Gadget.
- Assume that another user comes along independently and extends the Fidget by adding a Widget.
- Assume that Gadgets and Widgets are semantically orthogonal.
- Question: How will your meta-model and tool solution support this situation?
- Question: How will your meta-model and tool solution support a user who wants to model Fidgets that have both Gadgets and Widgets? (Again, assume that they are semantically orthogonal, so there is no explicit feature-interaction problem).
- Question: How will you answer the above two questions if there are, say, 6-12 different semantically-orthogonal extensions defined?
- Challenge Case 2 (Aspect-oriented Evolution)
- Assume that we have defined several dozen elements in "official" xADL (Fidgets, Widgets, Gadgets, etc.)
- Assume that external users have come along and defined many more elements in their own projects
- Question: How can a user add a generic, uniform construct to all these existing constructs in your
meta-model?
- For a concrete example, consider a "Note" that adds a simple comment string to a construct.
- Does your meta-model require that the user identify all the applicable constructs explicitly?
- Question: How can a user add a generic, uniform construct to only a subset of these existing constructs in your meta-model?
