Editing Syntactic methods

{{Multiple issues|
{{Orphan|date=November 2020}}
{{No footnotes|date=November 2020}}
}}

In [[software engineering]], '''syntactic methods''' are techniques for developing correct software [[Computer program|programs]].  The techniques attempt to detect, and thus prevent, certain kinds of defects ([[computer bug|bugs]]) by examining the structure of the code being produced at its [[syntactic]] rather than [[semantic]] level.

==Usage==

Syntactic methods are often used when [[formal methods]] are not an option, and are often a simpler and, more importantly, cheaper alternative. In non-[[mission-critical]] systems, [[formal methods]] may prove to be too expensive for the benefit they provide. The costs of modelling, personnel, execution and development may often outweigh the benefits gained by preventing possible failures. This approach revolves around the use of an ''abstract [[dependency graph]]'' which is created from the system in question. An abstract dependency graph is a [[directed graph]], a graph of [[vertex (graph theory)|vertices]] connected by one-way edges. Most often, the vertices and edges of the graph represent the inputs and outputs of functions in or components of the system. By inspecting the created abstract dependency graph, the developer can detect ''syntactic anomalies'' (or ''Preece anomalies'') in the system. While anomalies are not always defects, they often provide clues to finding defects in a system. Therefore, the anomalies in a system help point the developer in the right direction in finding defects.

==Anomalies==

There are four main types of anomaly:

* ''Redundancies'' &ndash; A chunk of the graph is redundant if its terminals can be reached if the chunk is removed from the graph
* ''Conflicts'' &ndash; A system contains conflicts if the same inputs can imply different outputs
* ''Circularities'' &ndash; A loop in the graph indicates a circularity in the system
* ''Deficiencies'' &ndash; A chunk is deficient if a subset of inputs leads to no terminals

While anomalies often point to defects, they can just as easily reflect normal intended functionality in the system. It is up to the developer to look into anomalies in order to determine whether they are clues to problems or simply false alarms.

By creating a visual [[directed graph]] of a system, there are several obvious visual flags that indicate the above anomalies:

* a sub-graph with no input is probably missing something important;
* while looking at the transitive closure of a system (all nodes downstream from a node), a node in its own transitive closure indicates a circularity;
* while looking at the transitive closure of a system, subsumption between pairs of rows indicates redundancy;
* conflicts are somewhat more difficult as they become more semantic than syntactic.

When formal methods prove too costly, a system can be checked solely on its [[syntax]]. This is not as thorough, as it only looks at a system on a surface level. However, it does give a developer many clues as to where a system's defects may lie.

==General references==
*"Syntactic theory of software architecture." Dean, Thomas R., Cordy, James R. [[IEEE Transactions on Software Engineering]] 21 (4), pp.&nbsp;302–313 (1995)
*"Syntactic type abstraction"  Grossman, D., Morrisett, G., Zdancewic, S. [[ACM Transactions on Programming Languages and Systems]] 22 (6), pp.&nbsp;1037–1080
*"A new algorithm for slicing unstructured programs."  Harman, M., Danicic, S. [[Journal of Software Maintenance and Evolution]] 10 (6), pp.&nbsp;415–441
*"Reverse engineering of embedded software using syntactic pattern recognition"  Fournigault, M., Liardet, P.-Y., Teglia, Y. Trémeau, A. Robert-Inacio, F.''Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)'' Volume 4277 LNCS - I, 2006, Pages 527–536.  (2006)

==External links==
*[http://www.informatik.uni-hamburg.de/TGI/forschung/projekte/asmics_eng.html "Project: Algebraic and Syntactic Methods in Computer Science (ASMICS 2)"] Université Paris 7, Laboratoire Informatique Théorique et Programmation (working group)
*[http://www.eg.org/EG/DL/Conf/EG83/papers/EUROGRAPHICS_83pp133_142.abstract.pdf "Syntactic Methods in Computer Graphics"] by Pavel Slavik

{{DEFAULTSORT:Syntactic Methods}}
[[Category:Formal methods]]