機能分解とは何ですか？

Question

機能分解、それは何のために有用で、何が賛否両論ですか？どのように使用されているのいくつかの実例がありますか？

Answer 1

機能分解は、複雑なプロセスを取り込んで、より小さな、より単純な部分に分解するプロセスです。

たとえば、ATMを考えてみましょう。あなたにプロセスを分解することができます：うまく

あなたのピンを入力してください銀行カード挿入ATM

まで

1. ウォーク

2. を...あなたが得ますポイント。

   同じようにプログラミングすることができます。カード

3. PIN検証を読ん

4. 転送処理の

   1. コード

   さらに分解することができ、それぞれが：ATMことを実行しているソフトウェアを考えます。サブシステムの最も分解された部分に到達したら、それらの部分のコーディングを開始する方法について考えることができます。それらの小さな部分をより大きな全体に合成します。このWikipediaの記事をチェックアウト：

   Decomposition (programming)

   機能分割の利点は、あなたがコーディングを始めると、あなたはおそらく、あなたのアプリケーションのために働くことができる最も簡単な要素に取り組んでいるということです。したがって、これらのコンポーネントを開発してテストするほうがはるかに簡単になります（もちろん、あなたのニーズに合わせてコードやプロジェクトを設計することができます）。

   明白な欠点は、時間の投資です。複雑なシステム上で機能的分解を行うには、コーディングが始まるまでにはるかに時間がかかります。

   私は個人的には時間がかかると思います。

Answer 2

ここでは、Cコンパイラの例を示します。

最初にプリプロセッサがあります：#includeと#defineとすべてのマクロを処理します。あなたはファイル名といくつかのオプションを与え、本当に長い文字列を返します。この関数をpreprocess(filename)としましょう。

次に、字句解析ツールがあります。それは文字列を取り、それをトークンに分解する。 lex(string)と呼んでください。パーサはトークンを取り出してツリーに変換し、parse(tokens)と呼ぶ。次に、ツリーをブロックのDAGに変換する機能があります。それをdag(tree)と呼んでください。コードエミッタemit(dag)を呼び出すと、ブロックのDAGを取り、アセンブラを吐き出します。

コンパイラは次のようになります。

emit(dag(parse(lex(preprocess(filename))))); 

私たちは、機能を理解しやすく、小さいの束の中に機能（compile機能）を理解することは、大きな困難を分解しました。パイプラインとして行う必要はありません。プログラムを次のように書くことができます：

process_data(parse_input(), parse_config()) 

これはより一般的です。コンパイラはかなり深いプログラムであり、ほとんどのプログラムは比較対象となります。

Answer 3

機能分解は、複雑な問題をデータ関係ではなく実行する必要のあるタスクに基づいて簡単な問題に分解する方法です。この用語は、通常、古い手続き指向の設計に関連しています。

A short description about the difference between procedure-oriented and object-oriented design.

Answer 4

はWorkBreakDown構造（WBS）、マインドマップとトップダウン開発が同じです - 基本的に小さく、より分かりサブ部分に大きな問題を壊します。

賛否

• （コードに衝動をresiting）プログラミングへの積極的なアプローチを可能にし、プロジェクトの複雑かつ/または危険領域を特定するのに役立ちます（ATMの例では、セキュリティがおそらくありますより複雑なコンポーネント）
• は、プロジェクト/コードの失敗の原因の1つ（Capers Jones経由）が欠落している - プロジェクトの後半まで考えられていないもの（そう、私は気付かなかった私は$を渡す前に人の残高を確認しなければならなかった）
• は仕事のより良いプログラミングのための部品のデカップリング、コードの共有と配布

短所が可能になります - 本当CONSは分解を行うことではありません、しかし

• を壊していないいくつかの一般的な間違いがあります（コードのプログラミング行に分解しないでください）...
• それぞれの人が、コンポーネントに対する洞察を彼らに提供するために必要な幸せな詳細レベルを決定する必要があります。既存のパターン/コードモジュールを使用して検討する（リワーク）
• が実際に

Answer 5

（案忘れよりも家を設計し、ちょうど一緒にいくつかのボードを爪に開始するように）機能分解をコーディングする際にスコープが

正しい内訳を使用していないことを確認するために顧客と検討していません機能要件文書を作成する前に役立ちます。何かのためにソフトウェアが必要な場合、機能的分解は「このソフトウェアが提供しなければならない機能は何か」という質問に答えます。ファイングレイン関数を定義するには分解が必要です。 "私はエネルギー効率測定のためのソフトウェアが必要"はあまりにも一般的です。そのため、システムが提供する必要があるすべての機能を明確に理解するまで、これをより小さな部分に分割しています。これは後でシステムの完全性のチェックリストとして使用できます。

機能要件文書（FD）は、基本的に機能分解のテキスト表現です。 FDから直接コーディングすることは、手続き型言語では問題ないかもしれませんが、オブジェクトを識別しないため、オブジェクト指向ソリューションでは十分ではありません。ユーザビリティの計画とテストにも適していません。

私の意見では、FDを作成するのに時間を取るべきですが、あまり時間をかけすぎないようにしてください。必要なすべての機能を見つけるために、システムに従っているプロセスを知っているすべての人に相談してください。

私はソフトウェアの設計、開発、販売で多くの経験を有しており、開発の第一歩として機能分解を使用しています。私は契約のベースとしてそれを使用するので、クライアントは彼らが得るものを知っています。私は何を提供しなければならないかを知っています。