A transaction decomposition table is used to set off software entities against external atomic system functions, called transactions. The entries of the table then represent the work performed by the software entities during the transaction. For example, figure 7.4 says that the transaction start_controlling_temperature requires some actions to be taken by software entities: A BATCH object must perform action do_temperature_ramp, etc.
Transaction decomposition tables can also be used in combination with ERDs and DFDs. The left-hand column then represents entity types or data stores, and the entries contain the letters C, R, U or D to indicate whether an instance of the entity type is created, read, updated or deleted during the transaction. The resulting table is also called a CRUD table.
Transaction decomposition tables can also be used in JSD to discover communications. They also help to maintain traceability. Methodological details are provided elsewhere [18,17].
A transaction-use table is a simple way to discover entity types from required system transactions. The leftmost column lists external system functions and the top row lists the basic Create, read, Update and Delete actions. The entries list the entity types or relationships that are created, read, updated or deleted during the function. See figure 7.5. Elaborate examples are given elsewhere [18, chapter 8].
A function-entity type table is almost the same as a transaction decomposition table. The top row now lists higher-level system functions and the leftmost row represents subject areas, which are at a higher level of abstraction than entity types (a subject area may encompass several entity types). The entries contain C, R, U or D, as in simple transaction decomposition tables.
Function-entity types are used in Information Engineering to find subsystems. These are identified by clustering subject areas and functions in such a way to minimize data flows between the clusters. See [18, chapter 6] for details and examples.