Glossary of Terms
Copyright 2007 Isotope28
Abstractive Decomposition
A technique for managing complexity via hierarchy. A set of entities on a diagram with a common theme are grouped together and placed onto another diagram. The collection is replaced on the original diagram with a single entity with an abstract name that represents the subset. The name of the new diagram is matched to the abstract entity to ensure traceability, and the UML subsystem icon (pitchfork) is added to the abstract entity to indicate the existence of the sub-diagram. The test for proper abstractive decomposition is that each of the sub-entities remain consistent with the name of the abstract entity. For example, an abstract use case Withdraw Cash” might have several decomposed use cases on another diagram of the same name, and the sub-use cases might be “Withdraw Cash from Checking”, “Withdraw Cash from Savings”, and “Credit Cash Advance”.
Abstractive decomposition is equivalent to the concept of inheritance in object-oriented philosophy. Abstractive decomposition the is preferred technique for decomposition due to its ease of scalability into very large systems.
Functional Decomposition
Another technique for managing complexity via hierarchy. A single behavior is decomposed into constituent behaviors, and each constituent behavior is represented separately. Functional decomposition is the antithesis of abstractive decomposition. Function decomposition, while often required, does not scale to large systems, and should be avoided where abstractive decomposition will serve.
Nested Decimal Notation
Nested decimal notation was first used for Data-Flow-Diagrams (DFDs) in the early days of structured programming analysis. Nested decimal notion helps relate the artifacts in a hierarchy by carrying the number of the parent diagram to the sub diagram, and adding more numbers after the decimal. For example, an abstract use case might carry the name “5. Report Results”. The UML subsystem icon (pitchfork) indicates a sub-diagram exists, and each detailed use case on the sub diagram will carry the parent number, but add their own. For example, the sub-use cases might be “5.2 Report Sales”, “5.2 Report Competitor Prices”, and “5.3 Report Inventory Levels”.