 |
 |
 |
|
 |
|||
| SSD09 - Supporting Information Structuring |
LSE09 - Informationsstrukturierung unterstützen
1 Allocation to V-Model and Methods Allocation
V-Model
SD1.1 - Recording of Actual Status and Analysis
SD1.5 - User-Level System Structure
SD2.4 - Allocation of User Requirements
SD5.1 - Description of SW Component/Module/Database
Method
ER - E/R Modeling
ELH - Entity Life History
NORM - Normalization
2 Brief Characteristics
This service unit defines the requirements for tools used to support the methods
3 Requirements
3.1 Requirements for Interfaces
| SSD09.I.1 | Granularity | The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface. |
| SSD09.I.2 | Input interface to SSD05 - Supporting Function Structure | It is possible to select functions directly collected with SSD05 from the object management as reference points for the generation of information structures. |
| SSD09.I.3 | Input interface to SSD07 - Supporting Modeling of Information Flows | It is possible to directly select processes, data flows, and data stores-from data flow diagrams collected with SSD07-from the object management as reference points for the generation of information structures. |
| SSD09.I.4 | Input interface to SSD21 - Transforming Databases, Data Structures Backwards | It is possible to integrate information structures-generated with SSD21 from logical schema specifications for databases and data structures-from the object management without further transformation. |
| SSD09.I.5 | Output interface to SSD11 - Supporting Database Specification | It is possible to transmit information structures without further transformation via the object management to SSD11 in order to be converted into logical schema specifications for databases and data structures. |
| SSD09.I.6 | Output interface to SSD21 - Transforming Databases, Data Structures Backwards | It is possible to transmit information structures via the object management without further transformation to SSD21 in order to be considered in the analysis of descriptions for databases and data structures. |
3.2 Requirements for the Methods Support
| SSD09.M.1 | ER - E/R Modeling | |
| SSD09.M.1.1 | Symbols | |
| SSD09.M.1.1.1 | Fundamental entity types | Symbols are available for the representation of fundamental entity types. |
| SSD09.M.1.1.2 | Attributive entity types | Symbols are available for the representation of entity types used to take out iteration groups. |
| SSD09.M.1.1.3 | Associative entity types | Symbols are available for the representation of entity types used to resolve N:M relationships. |
| SSD09.M.1.1.4 | Relationship types and cardinalities | Symbols are available for the representation of relationship types. |
| SSD09.M.1.1.5 | Aggregations |
Symbols are available for the representation of aggregations. Aggregations may be represented by a relationship of type "is part of". Entity types that are combined by such a relationship type in a higher-level entity type must be understood as entity subtypes for the corresponding entity supertype. |
| SSD09.M.1.1.6 | Specializations |
Symbols are available for the representation of specializations. Specializations may be represented by a relationship of type "is a". Entity types subordinated to an entity type as special case by this kind of relationship type must be understood as entity subtypes for the corresponding entity supertype. |
| SSD09.M.1.2 | Handling relationship types | |
| SSD09.M.1.2.1 | Rearranging relationship types | It is possible to rearrange relationship types. |
| SSD09.M.1.2.2 | Changing the relationship direction | It is possible to change the relationship direction of relationship types. |
| SSD09.M.1.2.3 | Relationship types always between entity types | It is guaranteed that only such relationship types are generated that are linking entity types with each other. |
| SSD09.M.1.2.4 | Cardinalities | It is guaranteed that only such relationship types are generated that were allocated discernible cardinalities in the E/R diagrams. |
| SSD09.M.1.3 | Description of entity types with attributes | |
| SSD09.M.1.3.1 | Attributes | It is possible to describe entity types by attributes. |
| SSD09.M.1.3.2 | Relationship types as attribute | It is possible to utilize relationship types as attributes. |
| SSD09.M.1.3.3 | Inheritance |
It is possible to transmit attributes to entity types. The inheritance of attributes is relevant when generating subtypes. |
| SSD09.M.1.3.4 | Attribute groups | It is possible to combine attributes in a group. |
| SSD09.M.1.3.5 | Renaming attributes | It is possible to rename attributes with the exception of key attributes or parts of concatenated keys. |
| SSD09.M.1.3.6 | Deleting attributes | It is possible to delete attributes. |
| SSD09.M.1.3.7 | Rejection of already allocated attribute names | When adding attributes, already allocated attribute names will be rejected. |
| SSD09.M.1.3.8 | Primary key | It is possible to distinguish attributes or attribute groups as primary keys. |
| SSD09.M.1.3.9 | Alternative primary key | It is possible to distinguish attributes or attribute groups as alternative primary keys. |
| SSD09.M.1.3.10 | Data type | It is possible to allocate a data type to attributes. |
| SSD09.M.1.3.11 | Value range | It is possible to allocate value ranges to attributes. |
| SSD09.M.1.3.12 | Deleting an entity type | It is guaranteed that prior to the deletion of an entity type the utilization of this entity type in aggregations and specializations will be displayed. |
| SSD09.M.1.3.13 | Automatic deletion of attributes | When deleting an entity type, it is guaranteed that all corresponding attributes are deleted automatically. |
| SSD09.M.1.3.14 | Overall model | It is possible to generate an overall model from entity and relationship types stored in various E/R models. |
| SSD09.M.1.3.15 | Partial data model | It is possible to generate partial data models from an existing overall data model. |
| SSD09.M.1.3.16 | Consolidations | It is possible to integrate a partial data model into an overall model whereby the integration takes place only after eliminating all inconsistencies. |
| SSD09.M.2 | ELH - Entity Life History | |
| SSD09.M.2.1 | Symbols | |
| SSD09.M.2.1.1 | State symbol | A symbol is available for the representation of the state of an entity type which can be labeled with the name of the state. |
| SSD09.M.2.1.2 | Transition symbol | A symbol is available for the representation of the transition from one state to another; it can be labeled with the name of the event changing the state. |
| SSD09.M.2.2 | State diagram | It is possible to generate a state diagram for each entity type automatically. |
| SSD09.M.2.3 | State changes | In a state diagram it is possible to represent all states and the events changing the states within the lifecycle of the allocated entity. |
| SSD09.M.2.4 | Integrity conditions | It is possible to allocate to an entity all integrity conditions that are relevant for the status changing events in the lifecycle. |
| SSD09.M.3 | NORM - Normalization | |
| SSD09.M.3.1 | Key attributes | It is possible to mark key attributes in a relation. |
| SSD09.M.3.2 | Functionally depending attributes | It is possible to mark functionally dependent attributes in a relation of key and parts of concatenated keys. |
| SSD09.M.3.3 | Transitively dependent attributes | It is possible to mark transitively dependent attributes that do not belong to the key. |
| SSD09.M.3.4 | First normal form | It is possible to transform an unnormalized relation automatically into relations in the first normal form, i. e. if the key in the unnormalized relationship as well as all attributes not functionally depending on the key have been marked. |
| SSD09.M.3.5 | Second normal form | It is possible to transform a relation in the first normal form automatically into relations in the second normal form, i. e. if in the relation of the first normal form-apart from the key-every attribute not belonging to the key and depending on a part of the concatenated key has been marked. |
| SSD09.M.3.6 | Third normal form | It is possible to transform a relation in the second normal form automatically into relations in the third normal form, i. e. if in the relation of the second normal form-apart from the key-all attributes not belonging on the key and transitively depending on each other are marked. |
| SSD09.M.3.7 | De-normalization | It is possible to automatically reset all normalizations of a relation. |
3.3 Requirements for Functions
none
3.4 Other Requirements
| SSD09.O.1 | Upward compatibility | It must be possible to process objects generated with an older release of the tool with the later release of that tool, without loss of information and functionality. |
| SSD09.O.2 | Procedural command language | The tool has a procedural command language that can be applied by the user to generate and run macros or procedures. |
| SSD09.O.3 | Complexity | There is no limitation of the complexity caused by the tool itself. |
|
|
|
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
|