Real-time extensions to structured analysis (SA/RT) are popular in industrial practice. Despite the large industrial experience and the attempts to formalize the various "dialects," SA/RT notations are still imprecise and ambiguous. This article tries to identify the semantic problems of the requirements definition notation defined by Hatley and Pirbhai, one of the popular SA/RT "dialects," and discusses possible solutions. As opposed to other articles that give their own interpretation, this article does not propose a specific semantics for the notation. This article identifies imprecisions, i.e., missing or partial information about features of the notation; it discusses ambiguities, i.e., elements of the definition that allow at least two different ("reasonable") interpretations of features of the notation; and it lists extensions, i.e., features not belonging to the notation, but required by many industrial users and often supported by CASE tools. This article contributes by clarifying whether specific interpretations can be given unique semantics or retain ambiguities of the original definition. The article allows for the evaluation of formal definitions by indicating alternatives and consequences of the specific choices.
Pezze', M., Baresi, L. (1998). Toward Formalizing Structured Analysis. ACM TRANSACTIONS ON SOFTWARE ENGINEERING AND METHODOLOGY, 7(1), 80-107 [10.1145/268411.268429].
Toward Formalizing Structured Analysis
PEZZE', MAURO;
1998
Abstract
Real-time extensions to structured analysis (SA/RT) are popular in industrial practice. Despite the large industrial experience and the attempts to formalize the various "dialects," SA/RT notations are still imprecise and ambiguous. This article tries to identify the semantic problems of the requirements definition notation defined by Hatley and Pirbhai, one of the popular SA/RT "dialects," and discusses possible solutions. As opposed to other articles that give their own interpretation, this article does not propose a specific semantics for the notation. This article identifies imprecisions, i.e., missing or partial information about features of the notation; it discusses ambiguities, i.e., elements of the definition that allow at least two different ("reasonable") interpretations of features of the notation; and it lists extensions, i.e., features not belonging to the notation, but required by many industrial users and often supported by CASE tools. This article contributes by clarifying whether specific interpretations can be given unique semantics or retain ambiguities of the original definition. The article allows for the evaluation of formal definitions by indicating alternatives and consequences of the specific choices.I documenti in IRIS sono protetti da copyright e tutti i diritti sono riservati, salvo diversa indicazione.