Functional decomposition: Difference between revisions

Revision as of 12:24, 5 May 2019

Revision as of 20:36, 14 August 2019

Line 110:

</math>

This leads one to the plausible Module, Service, or Object, of an interpreter (containing the function ''fromExpr''). Function Decomposition arguably yields insights about re-usability, such as if during the course of analysis, two functions produce the same type, it is likely that a common function/[[cross-cutting concern]] resides in both. To contrast, in [[Object-oriented programming|OOP]], it is a common practice to conjecture Modules prior to considering such a decomposition. This arguably results in costly [[refactoring]] later. FD mitigates that risk to some extent. Further, arguably, what separates FD from other design methods- is that it provides a concise high-level medium of architectural discourse that is end-to-end, revealing flaws in upstream [[requirements]] and beneficially exposing more design decisions in advance. And lastly, FD is known to prioritize development. As arguablyArguably, if the FD is correct, the most re-usable and cost-determined parts of the program are identified far earlier in the development cycle.

===Signal processing===