Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "ArCon"
(New page: link to ArCon project proposal Description of the new features to be implemented in 2013) |
|||
| Line 1: | Line 1: | ||
link to ArCon project proposal | link to ArCon project proposal | ||
| − | Description of the new features to be implemented in 2013 | + | Description of the new features to be implemented in 2013 |
| + | |||
| + | '''ArCon shall:''' | ||
| + | |||
| + | 1. Be able to read combined architecture models | ||
| + | |||
| + | 2. Enable selection of model scope for analysis | ||
| + | |||
| + | 3. Enable command line start | ||
| + | |||
| + | 4. Perform proactive online check | ||
| + | |||
| + | 5. Provide domain specific modeling support based on the architecture model | ||
| + | |||
| + | 6. Enable generation of architecture documentation | ||
| + | |||
| + | 7. Be able to create profile from architecture (meta) model | ||
| + | |||
| + | 8. Be able to handle one or more stereotypes for rule activation | ||
| + | |||
| + | 9. Be able to follow dependency to active architecture model | ||
| + | |||
| + | 10. Handle different severity levels | ||
| + | |||
| + | 11. Be able to filter warnings | ||
| + | |||
| + | 12. Be integrated with Kepler | ||
| + | |||
| + | 13. Provide infrastructure to express arbitrary rules (e.g. not possible to express with static analysis) | ||
| + | |||
| + | 14. Display warning markers in model browser | ||
Revision as of 06:19, 15 March 2013
link to ArCon project proposal
Description of the new features to be implemented in 2013
ArCon shall:
1. Be able to read combined architecture models
2. Enable selection of model scope for analysis
3. Enable command line start
4. Perform proactive online check
5. Provide domain specific modeling support based on the architecture model
6. Enable generation of architecture documentation
7. Be able to create profile from architecture (meta) model
8. Be able to handle one or more stereotypes for rule activation
9. Be able to follow dependency to active architecture model
10. Handle different severity levels
11. Be able to filter warnings
12. Be integrated with Kepler
13. Provide infrastructure to express arbitrary rules (e.g. not possible to express with static analysis)
14. Display warning markers in model browser