{
    "attributes": [
        {
            "key": "_type",
            "type": "STRING",
            "value": "Requirement"
        },
        {
            "key": "keywords",
            "type": "STRING",
            "value": "component category, abstract feature, feature group"
        },
        {
            "key": "implemented",
            "type": "STRING",
            "value": "0"
        },
        {
            "key": "from_Author",
            "type": "STRING",
            "value": "Eugene Gerlits 11-05-31"
        },
        {
            "key": "text",
            "type": "STRING",
            "value": "Component categories constrain possible abstract features & feature groups"
        },
        {
            "key": "_description",
            "type": "STRING",
            "value": "There are several feature kinds: access features, feature groups, ports & etc. Depending on the component category the standard defines a subset of feature types that may be declared in a component type declaration. Allowed feature types are specified for each component category. There are almost always abstract features and feature groups among them. The problem is that an abstract feature or a feature group may be defined in such a way that a possible refinement of it will newer belong to the feature types allowed for the component category. For instance, the Data component category permits subprogram and subprogram group access features & abstract feature & feature group. It implies that an IN/OUT abstract feature may not be declared in a Data type declaration, but there are not a word about it in the standard."
        },
        {
            "key": "solution",
            "type": "STRING",
            "value": "examination of the structure of the abstract feature and feature group"
        }
    ],
    "uuid": "ad102c46-18d4-4ea4-b3e1-eb454a21d60e"
}