Functional decomposition: Difference between revisions

Revision as of 04:16, 6 June 2023

Revision as of 04:28, 6 June 2023

Line 43:

{{weasel section|date=September 2019}}

Functional Decomposition is a design method intending to produce a non-implementation, architectural description of a computer program. Rather than conjecturing Objects and adding methods to them ([[Object-oriented programming|OOP]]), with each Object intending to capture some service of the program, the software architect first establishes a series of functions and types that accomplishes the main processing problem of the computer program, decomposes each to reveal common functions and types, and finally derives Modules from this activity.

For example, the design of the editor [[Emacs]] can initially be thought about in terms of functions:

<math>

e\, \equiv \text{state of the Emacs editor and running operating system}

</math>

<br>

<math>

e'\, \equiv e\text{ with some component/part of its state changed}

</math>

<math>

f: (e, lisp\,\,expression) \rightarrow e'

</math>

And a possible '''function decomposition''' of ''f'':

<math>

fromExpr: lisp\,\,expression \rightarrow

\begin{cases}

object, & \text{if success} \\

error, & \text{if failure}

\end{cases}

</math>

<math>

evaluate: (object, e) \rightarrow e'

</math>

<math>

print: (error, e) \rightarrow e'

</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. Arguably, 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===