Rationale » History » Version 2
J. Wienke, 10/05/2011 04:25 PM
| 1 | 1 | J. Wienke | h1. Structure Proposal |
|---|---|---|---|
| 2 | 1 | J. Wienke | |
| 3 | 1 | J. Wienke | h2. Requirements |
| 4 | 1 | J. Wienke | |
| 5 | 2 | J. Wienke | In general, the following requirements try to enforce the general *reusability* of data types. |
| 6 | 2 | J. Wienke | |
| 7 | 2 | J. Wienke | * *Visibility*: Data definitions must be easily visible when searching for them to foster reuse. This includes: |
| 8 | 1 | J. Wienke | ** Folder browsing |
| 9 | 1 | J. Wienke | ** Code completion |
| 10 | 2 | J. Wienke | * *Structuredness*: A structured view on the data is required as an orthogonal perspective to the general visibility in order to find functionally coherent groups of data definitions. |
| 11 | 2 | J. Wienke | * *Stability*: A core set of data definitions must be kept stable as much as possible in order to shield depending software from frequent changes. |
| 12 | 2 | J. Wienke | * *Extendability*: New data type definitions are constantly required. Adding them to the repository must have a low barrier to motivate data type sharing. |
| 13 | 2 | J. Wienke | * *Addressability*: A certain revision of a data type must be uniquely addressable and accessible in order to conserve system states. |