SAEAF Constraint Pattern
Jump to navigation Jump to search
Detail of the Specification Constraint Pattern
Choose a square or three, then document it.
the author is to the left of the /, the reviewer to the right.
|Specification||Enterprise / Business Viewpoint||Information Viewpoint||Computational Viewpoint||Engineering Viewpoint|
|Reference||Reference - Business Jane||Reference - Informational Patrick||Reference - ComputationalJohn||N/A|
|Analysis||Analysis - Business Jane||Analysis - Informational AMS/Wendell||Analysis - Computational AMS/John||N/A|
|Logical||Logical - Business Jane||Logical - Informational Cecil/Wendell||Logical - Computational John||N/A|
|Implementable||Implementable - Business Jane||Implementable - Informational Wendell||Implementable - Computational Dale||Implementable - Engineering|
- There are relationships between the various cells. The primary relationship between cells on the same row is one of "consistency". In other words, artifacts for the same "topic" must be consistent with each other across the row. This applies primarily from the Analysis level, through the Logical and Implementation levels. Some reference artifacts do need to have a consistency relationship with each other, but they are not topic specific.
- Relationships between cells in the same column is one of "traceability". Artifacts from the Analysis row must be traceable to equivalent reference artifacts, Logical artifacts must be traceable to their associated Analysis artifacts and Implementable designs must be traceable to their logical equivalents. The term "traceability" is used to mean the ability to confirm that the source of the semantics expressed at one level is derived from the level above. In some cases, artifacts at a lower are algorithmically transformed from equivalent artifacts from the row above. Therefore, the term "traceability" also implies "transformed from" where such algorithmic conversions are possible. Model driven design gains it's productivity and re-usability from such transformations.