Design Standards for ArchStudio
Because ArchStudio will be working towards different design goals, adhering to different stypes, etc. Here, we highlight important design standards that we have adopted as a community.
TODO: At appropriate times throughout these group meetings decide on what standards we want to keep or reject.
Accepted Design Standards
Rejected Design Standards
Design Proposals / Issues
- It should generally be possible to add new features to ArchStudio by creating new components and plugins without modifying existing components and plugins. When this is not possible, refactoring existing code to expose appropriate extension points should be considered. This will ease the process of release management, improve stability of core elements, and better support simultaneous extension by different parties. Some practices would seem to help with this are:
- Plugins that capture utilities and resources should not depend on/or be integrated with plugins that capture higher level concepts such as feature extensions or product definitions
- Specific example: placing utilities and resources in the main ArchStudio plugin should be avoided for ArchStudio 5
- Plugins should be as independent and generic as possible, taking a Koala-like approach of minimizing assumptions about usage context.
- As a rule of thumb, feature boundaries will likely dictate the number and size of plugins,
- Specific example: Archipelago has grown to include many different features, these include editors for architectures, statecharts, and activity diagrams, and additional functionality over those editors such as change sets and traceability. These features indicate that there should at least be 6 plugins for Archipelago (the Archipelago fw, 3 editor extensions, 2 feature extensions)
- Plugins that capture utilities and resources should not depend on/or be integrated with plugins that capture higher level concepts such as feature extensions or product definitions
- We need to determine when, how, and by how much to use plugin extensions, which are stored in the plugin.xml file for each plugin. Plugin extensions support schema-based, xADL-like extensions allowing a developer to add new types of information for their plugin and to read information from other plugins that conform to their published schema. This is a beneficial technology and is used, for example, to indicate whether your plugin defines a new Editor that eclipse can use. I see these plugin.xml files as defining the Eclipse architecture description. However, there is no linking mechanism in this architecture, which has made using it difficult. For example, it would be very beneficial if we could intercept when Eclipse gets all the editors defined in these plugin.xml files, and modify it so that Myx-based editors (such as Archipelago) use a special Myx-based editor class that waits until the Archipelago component starts up before trying to display the editor in Eclipse. Furthermore, the Eclipse architecture description (simply a conglomeration of each plugin's plugin.xml content) is read-only during runtime (is this still true? and for 3.4?). There are some benefits, however. This is the only way to get lists of information from multiple sources (such as, give me all the plugins that define an Editor, without the need of editing a single, large file. Also, the reflective editor for these plugins is aware of Eclipse concepts (such as, it's possible to have a field in an extension which expects a class name, and editing that field pops up a specialized dialog box making it easy to select a class rather than type it in from scratch). So they are at the same time not without benefit.
