A Formal Semantics of Data Flow Diagrams

Larsen, Peter Gorm; Plat, Nico; Toetenel, Hans

doi:10.1007/bf03259387

Cited by 31 publications

(13 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Other graphical notation communities have found that a formal semantics contributes to a solution, see [7,11] and papers in [3] for examples. The semantics presented in this paper could serve this purpose for Problem Frames.…”

Section: Introductionmentioning

confidence: 99%

Problem frame semantics for software development

2005

View full text Add to dashboard Cite

This paper presents a framework for understanding Problem Frames that locates them within the Requirements Engineering model of Zave and Jackson, and its subsequent formalization in the Reference Model of Gunter et al. It distinguishes between problem frames, context diagrams and problem diagrams, and allows us to formally define the relationship between them as assumed in the Problem Frames framework.The semantics of a problem diagram is given in terms of 'challenges', a notion that we also introduce. The notion of a challenge is interesting in its own right for two reasons: its proof theoretic derivation leads us to consider a challenge calculus that might underpin the Problem Frame operations of decomposition and recomposition; and it promises to extend the notion of formal refinement from software development to requirements engineering.In addition, the semantics supports a textual representation of the diagrams in which Problem Frames capture problems and their relationship to solutions. This could open the way for graphical Problem Frames tools.

show abstract

Section: Introductionmentioning

confidence: 99%

Problem frame semantics for software development

2005

View full text Add to dashboard Cite

show abstract

“…If not, the abstract problem model and the methods can be changed until the solution meets the specifications. Formal declarations such as Z are distinguished from less formal notations such as data flow diagrams [20] because they have a formal semantics that assigns a precise meaning to any formula in the declaration.…”

Section: Using Z Notation For Process Planningmentioning

confidence: 99%

Formal Modelling of Process Planning in Combined Additive and Subtractive Manufacturing

Afsharizand

Nassehi

Dhokia

et al. 2014

Enabling Manufacturing Competitiveness and Economic Sustainability

View full text Add to dashboard Cite

Decision-making models for manufacturing technologies are becoming increasingly complex due to on-going rapid developments in additive and subtractive (Addtractive) manufacturing. Decision-making in manufacturing technologies should be based on machine and resource capabilities. Currently, multi-process manufacturing models have many shortcomings when describing machining capabilities, and in some cases, modelling approaches used in decision-making are ambiguous and poorly constrained. In this research, a formal modelling approach is proposed to facilitate modelling of machining capability and associated Addtractive operations. This mathematically based formal method allows system properties to be described in a well-defined manner. The ISO-standardised Z notation (named after Zermelo-Fraenkel set theory) has been utilised to build a state-oriented formalism model for machining capabilities and associated operations.

show abstract

“…Researchers have formalized DFDs [27,26] and attempted reverse engineering DFDs from code [6]. Liu et al proposed Conditional Data Flow Diagrams (CDFDs) [29] to resolve many of the ambiguity problems in Yourdon's DFDs.…”

Section: Related Workmentioning

confidence: 99%

Checking threat modeling data flow diagrams for implementation conformance and security

Abi-Antoun

Wang

Torr

2007

Proceedings of the Twenty-Second IEEE/ACM International Conference on Automated Software Engineering

View full text Add to dashboard Cite

Threat modeling analyzes how an adversary might attack a system by supplying it with malicious data or interacting with it. The analysis uses a Data Flow Diagram (DFD) to describe how data moves through a system. Today, DFDs are represented informally, reviewed manually with security domain experts and may not reflect all the entry points in the implementation. We designed an approach to check the conformance of an implementation with its security architecture. We extended Reflexion Models to compare as-built DFD recovered from the implementation and the as-designed DFD, by increasing its automation and thus its adoptability. We also designed an analysis to assist DFD designers validate their initial DFDs and detect common security design flaws in them. An evaluation of the approach on subsystems from production code showed that it can find omitted or outdated information in existing DFDs.Parts of this work were conducted while the first author was an intern in the Center for Software Excellence at Microsoft. Abi-Antoun's work is supported in part by NSF grant CCF-0546550, DARPA contract HR00110710019, the Department of Defense, and the Software Industry Center at Carnegie Mellon University and its sponsors, especially the Alfred P. Sloan Foundation. Report Documentation PageForm Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. Threat modeling analyzes how an adversary might attack a system by supplying it with malicious data or interacting with it. The analysis uses a Data Flow Diagram (DFD) to describe how data moves through a system. Today, DFDs are represented informally, reviewed manually with security domain experts and may not reflect all the entry points in the implementation. We designed an approach to check the conformance of an implementation with its security architecture. We extended Reflexion Models to compare as-built DFD recovered from the implementation and the as-designed DFD, by increasing its automation and thus its adoptability. We also designed an analysis to assist DFD designers validate their initial DFDs and detect common security design flaws in them. An evaluation of the approach on subsystems from production code showed that it can find omitted or outdated information in existing DFDs.

show abstract

A Formal Semantics of Data Flow Diagrams

Cited by 31 publications

References 18 publications

Problem frame semantics for software development

Problem frame semantics for software development

Formal Modelling of Process Planning in Combined Additive and Subtractive Manufacturing

Checking threat modeling data flow diagrams for implementation conformance and security

Contact Info

Product

Resources

About