Programming-methodologies-quick-guide
プログラミング方法論-はじめに
在庫管理、給与処理、学生入学、試験結果処理などの現実の問題を解決するプログラムが開発されたとき それらは巨大で複雑になる傾向があります。 このような複雑な問題を分析し、ソフトウェア開発を計画し、開発プロセスを制御するアプローチは、「プログラミング方法論」と呼ばれます。
プログラミング手法の種類
ソフトウェア開発者の間で普及しているプログラミング方法論の多くの種類があります-
手続き型プログラミング
問題は、手順、またはそれぞれ1つのタスクを実行するコードのブロックに分類されます。 一緒に取られるすべての手順は、プログラム全体を形成します。 複雑さの低いレベルの小さなプログラムにのみ適しています。
例-加算、減算、乗算、除算、平方根、比較を行う計算プログラムの場合、これらの各操作は個別の手順として開発できます。 メインプログラムでは、各プロシージャはユーザーの選択に基づいて呼び出されます。
オブジェクト指向プログラミング
ここでは、問題の一部であるエンティティまたはオブジェクトを中心にソリューションが展開されます。 このソリューションは、エンティティに関連するデータを保存する方法、エンティティの動作方法、およびそれらが相互作用して凝集ソリューションを提供する方法を扱います。
例-給与管理システムを開発する必要がある場合、従業員、給与構造、退職規則などのエンティティがあります。 その周りにソリューションを構築する必要があります。
関数型プログラミング
ここでは、問題または目的の解決策が機能単位に分けられます。 各ユニットは独自のタスクを実行し、自給自足です。 次に、これらのユニットをつなぎ合わせて完全なソリューションを形成します。
例-給与処理には、従業員データのメンテナンス、基本給の計算、総給与の計算、休暇処理、ローン返済処理などの機能単位を含めることができます。
論理プログラミング
ここでは、問題は機能ユニットではなく論理ユニットに分類されます。 *例：*学校管理システムでは、ユーザーはクラスの先生、教科の先生、研究室のアシスタント、コーディネーター、アカデミック担当などの非常に明確な役割を持っています。 したがって、ソフトウェアはユーザーの役割に応じてユニットに分割できます。 各ユーザーは、異なるインターフェース、許可などを持つことができます。
ソフトウェア開発者は、これらの方法論の1つまたは複数の組み合わせを選択してソフトウェアを開発できます。 説明した各方法論では、問題をより小さな単位に分解する必要があることに注意してください。 これを行うには、開発者は次の2つのアプローチのいずれかを使用します-
- トップダウンアプローチ
- ボトムアップアプローチ
トップダウンまたはモジュラーアプローチ
問題は小さな単位に分割され、さらに小さな単位に分割される場合があります。 各ユニットは*モジュール*と呼ばれます。 各モジュールは、タスクを実行するために必要なすべてを備えた自給自足型のユニットです。
次の図は、給与処理プログラムの開発中にモジュール式アプローチに従って異なるモジュールを作成する方法の例を示しています。
ボトムアップアプローチ
ボトムアップアプローチでは、システム設計はコンポーネントの最下位レベルから開始され、コンポーネントは相互接続されてより高いレベルのコンポーネントを取得します。 このプロセスは、すべてのシステムコンポーネントの階層が生成されるまで続きます。 ただし、実際のシナリオでは、最初にすべての最低レベルのコンポーネントを知ることは非常に困難です。 したがって、ボトムアップアプローチは、非常に単純な問題にのみ使用されます。
電卓プログラムのコンポーネントを見てみましょう。
問題を理解する
典型的なソフトウェア開発プロセスは、これらの手順に従います-
- 要件収集
- 問題の定義
- システムデザイン
- 実装
- テスト
- ドキュメンテーション
- トレーニングとサポート
- メンテナンス
最初の2つのステップは、チームが問題を理解するのに役立ちます。これは、解決策を得るための最も重要な最初のステップです。 要件の収集、問題の定義、およびシステムの設計を担当する人は、*システムアナリスト*と呼ばれます。
要件の収集
通常、クライアントまたはユーザーは、問題や要件を明確に定義できません。 彼らは自分が望むものについて漠然とした考えを持っています。 そのため、システム開発者は、クライアントの要件を収集して、解決する必要がある問題、または提供する必要があるものを理解する必要があります。 問題の詳細な理解は、ソリューションが開発されているビジネス領域を最初に理解することによってのみ可能です。 ビジネスを理解するのに役立ついくつかの重要な質問が含まれます-
- 何が行われていますか？
- どうですか？
- タスクの頻度は？
- 決定または取引の量はどのくらいですか？
- 発生している問題は何ですか？
この情報を収集するのに役立ついくつかのテクニックは-
- インタビュー
- アンケート
- 既存のシステムドキュメントの調査
- ビジネスデータの分析
システムアナリストは、SMART（具体的、測定可能、合意済み、現実的かつ時間ベース）の要件を特定するために、明確かつ簡潔だが徹底的な要件ドキュメントを作成する必要があります。 そうしないと、結果として-
- 不完全な問題定義
- 不正なプログラム目標
- 必要な結果をクライアントに提供するための再作業
- コストの増加
- 配送遅延
必要な情報の深さにより、要件の収集は*詳細調査*とも呼ばれます。
問題定義
要件を収集して分析した後、問題のステートメントを明確に述べる必要があります。 問題の定義は、どの問題を解決する必要があるかを明確に示す必要があります。 明確な問題のステートメントを持っていることが必要です-
- プロジェクト範囲を定義する
- チームに集中し続ける
- プロジェクトを順調に進める
- プロジェクトの終わりに望ましい結果が達成されたことを検証する
ソリューションの特定
多くの場合、コーディングはソフトウェア開発プロセスの最も重要な部分であると想定されています。 ただし、コーディングはプロセスの一部にすぎず、システムが正しく設計されている場合、実際には最小限の時間がかかる場合があります。 システムを設計する前に、当面の問題の解決策を特定する必要があります。
システムの設計に関して最初に注意すべきことは、最初にシステムアナリストが複数のソリューションを考え出す可能性があることです。 しかし、最終的なソリューションまたは製品は1つだけです。 要件収集フェーズで収集されたデータの詳細な分析は、独自のソリューションを実現するのに役立ちます。 問題を正しく定義することも、解決策を見つけるために重要です。
複数のソリューションの問題に直面した場合、アナリストは、フローチャート、データフロー図、エンティティ関係図などの視覚資料を探します。 各ソリューションを詳細に理解する。
フローチャート
フローチャートとは、システム内のワークフローとデータフローをシンボルと図で示すプロセスです。 システムアナリストが問題の解決策を特定するのを支援する重要なツールです。 システムのコンポーネントを視覚的に示します。
これらは、フローチャートの利点です-
- 視覚的表現はプログラムロジックの理解に役立ちます
- 実際のプログラムコーディングの青写真として機能します。
- フローチャートはプログラムのドキュメント化にとって重要です
- フローチャートは、プログラムのメンテナンス中の重要な支援です
これらは、フローチャートの欠点です-
- フローチャートを使用して複雑なロジックを描くことはできません
- ロジックまたはデータ/ワークフローが変更された場合、フローチャートを完全に再描画する必要があります
データフロー図
データフロー図またはDFDは、システムまたはサブシステムを介したデータフローのグラフィカルな表現です。 各プロセスには独自のデータフローがあり、データフロー図のレベルがあります。 レベル0は、システム全体の入力および出力データを示します。 次に、システムはモジュールに分割され、レベル1 DFDは各モジュールのデータフローを個別に表示します。 モジュールは、必要に応じてサブモジュールにさらに分割され、レベル2のDFDが描画されます。
疑似コード
システムが設計された後、実装のためにプロジェクトマネージャーに引き渡されます。 コーディング。 プログラムの実際のコーディングはプログラミング言語で行われますが、これはその言語で訓練されたプログラマーのみが理解できます。 ただし、実際のコーディングが行われる前に、プログラムの基本的な動作原理、ワークフロー、およびデータフローは、使用するプログラミング言語と同様の表記法を使用して記述されます。 このような表記法は pseudocode と呼ばれます。
C の擬似コードの例を次に示します。 プログラマは、プログラムコードを取得するために各ステートメントをC 構文に変換するだけです。
数学的操作の特定
コンピューターへのすべての命令は、最終的に機械レベルでの算術および論理演算として実装されます。 これらの操作は重要です-
- 占有メモリスペース
- 実行に時間がかかる
- ソフトウェアの効率を決定する
- 全体的なソフトウェアパフォーマンスに影響
システムアナリストは、すべての主要な数学的操作を特定すると同時に、問題に対する独自の解決策を特定しようとします。
モジュラーテクニックの適用
実際の問題は複雑で大きなものです。 モノリシックソリューションが開発された場合、これらの問題が発生します-
- 1つの大きなプログラムの作成、テスト、実装が困難
- 最終製品の納入後の変更はほぼ不可能です
- プログラムのメンテナンスが非常に難しい
- 1つのエラーでシステム全体が停止する可能性があります
これらの問題を克服するには、ソリューションを*モジュール*と呼ばれる小さな部分に分割する必要があります。 開発、実装、変更、および保守を容易にするために、1つの大きなソリューションを小さなモジュールに分割する手法は、プログラミングまたはソフトウェア開発の「モジュラー手法」と呼ばれます。
モジュラープログラミングの利点
モジュール式プログラミングはこれらの利点を提供します-
- 各モジュールを並行して開発できるため、開発期間を短縮できます
- モジュールは再利用できます
- 各モジュールは個別にテストされるため、テストはより高速で堅牢です
- プログラム全体のデバッグとメンテナンスが簡単に
- モジュールは小さく、複雑さが低いため、理解しやすい
モジュールの特定
ソフトウェア内のモジュールを特定することは、気が遠くなるような作業です。なぜなら、正しい方法が1つあるからです。 モジュールを識別するためのいくつかのポインタがあります-
- データがシステムの最も重要な要素である場合、関連データを処理するモジュールを作成します。
- システムが提供するサービスが多様な場合、システムを機能モジュールに分割します。
- 他のすべてが失敗した場合は、要件収集フェーズでシステムを理解することにより、システムを論理モジュールに分割します。
コーディングの場合、プログラミングを容易にするために、各モジュールを再び小さなモジュールに分割する必要があります。 これも、上記で共有した3つのヒントを特定のプログラミングルールと組み合わせて使用して実行できます。 たとえば、C ++やJavaのようなオブジェクト指向プログラミング言語の場合、データとメソッドを持つ各クラスは単一のモジュールを形成できます。
ステップバイステップのソリューション
モジュールを実装するには、各モジュールのプロセスフローを段階的に説明する必要があります。 ステップごとのソリューションは、*アルゴリズム*または*擬似コード*を使用して開発できます。 段階的なソリューションを提供することは、これらの利点を提供します-
- ソリューションを読んでいる人は誰でも問題とソリューションの両方を理解できます。
- プログラマーと非プログラマーが等しく理解できます。
- コーディング中に、各ステートメントをプログラムステートメントに変換するだけです。
- これはドキュメントの一部であり、プログラムのメンテナンスを支援します。
- 識別子名、必要な操作などのマイクロレベルの詳細 自動的に解決する
例を見てみましょう。
制御構造
上記の例でわかるように、プログラムロジックを*順次*実行する必要はありません。 プログラミング言語では、*制御構造*は与えられたパラメータに基づいてプログラムの流れについて決定を下します。 これらはソフトウェアの非常に重要な要素であり、コーディングを開始する前に特定する必要があります。
アルゴリズムと*擬似コード*は、アナリストやプログラマーが制御構造が必要な場所を特定するのに役立ちます。
制御構造は、これらの3つのタイプです-
決定制御構造
決定制御構造は、実行される次のステップが基準に依存する場合に使用されます。 この基準は通常、評価する必要がある1つ以上のブール式です。 ブール式は常に「true」または「false」に評価されます。 基準が「true」の場合、ステートメントの1つのセットが実行され、基準が「false」と評価された場合に別のセットが実行されます。 たとえば、ifステートメント
選択制御構造
選択制御構造は、プログラムシーケンスが特定の質問への回答に依存する場合に使用されます。 たとえば、プログラムにはユーザー向けの多くのオプションがあります。 次に実行されるステートメントは、選択したオプションによって異なります。 たとえば、 switch ステートメント、 case ステートメント。
繰り返し/ループ制御構造
一連のステートメントが何度も繰り返される場合、繰り返し制御構造が使用されます。 繰り返しの回数は、開始する前にわかっているか、式の値に依存する場合があります。 たとえば、 for ステートメント、 while ステートメント、 do while ステートメントなど。
上の画像でわかるように、選択構造と決定構造の両方がフローチャートで同様に実装されています。 選択制御は、連続して行われる一連の決定ステートメントに他なりません。
これらのステートメントがどのように機能するかを示すプログラムの例を次に示します-
アルゴリズムを書く
問題を解決するために従う必要のあるステップの有限セットは、*アルゴリズム*と呼ばれます。 アルゴリズムは通常、実際のコーディングが行われる前に開発されます。 英語のような言語を使用して作成されているため、プログラマーでなくても簡単に理解できます。
時々、アルゴリズムは*擬似コード*を使用して記述されます。 使用するプログラミング言語に類似した言語。 問題を解決するためのアルゴリズムを書くことはこれらの利点を提供します-
- チームメンバー間の効果的なコミュニケーションを促進する
- 手元の問題の分析が可能
- コーディングの青写真として機能
- デバッグを支援
- メンテナンス段階で将来参照するためのソフトウェアドキュメントの一部になります
これらは、優れた正しいアルゴリズムの特徴です-
- 入力のセットがあります
- ステップは一意に定義されます
- 有限ステップ数
- 必要な出力を生成します
アルゴリズムの例
最初に、アルゴリズムを作成する実際の状況の例を見てみましょう。 これは、ペンを購入するために市場に行くためのアルゴリズムです。
このアルゴリズムのステップ4自体は完全なタスクであり、別のアルゴリズムを作成できます。 数値が正か負かをチェックするアルゴリズムを作成しましょう。
フローチャート要素
- フローチャート*は、プログラムの論理ステップのシーケンスを図で表したものです。 フローチャートは、単純な幾何学的形状を使用してプロセスを表し、矢印を使用して関係とプロセス/データフローを示します。
フローチャート記号
これは、フローチャートの描画に使用される一般的な記号の一部のチャートです。
| Symbol | Symbol Name | Purpose |
|---|---|---|
| Start Stop | Start/Stop | Used at the beginning and end of the algorithm to show start and end of the program. |
| Process | Process | Indicates processes like mathematical operations. |
| Input/Output | Input/Output | Used for denoting program inputs and outputs. |
| Decision | Decision | Stands for decision statements in a program, where answer is usually Yes or No. |
| Arrow | Arrow | Shows relationships between different shapes. |
| On-page Connector | On-page Connector | Connects two or more parts of a flowchart, which are on the same page. |
| Off-page Connector | Off-page Connector | Connects two parts of a flowchart which are spread over different pages. |
フローチャート開発のガイドライン
これらは、フローチャートを開発する際に留意すべき点です-
- フローチャートには、開始記号と停止記号をそれぞれ1つだけ含めることができます
- ページ上のコネクタは番号を使用して参照されます
- ページ外コネクタはアルファベットを使用して参照されます
- プロセスの一般的な流れは上から下または左から右です
- 矢印は互いに交差してはいけません
フローチャートの例
これは、ペンを購入するために市場に行くためのフローチャートです。
以下は、2つの数値の平均を計算するフローチャートです。
明確な指示の使用
ご存知のように、コンピューターには独自のインテリジェンスがありません。ユーザーが指定した*指示*に従うだけです。 *命令*はコンピュータプログラムの構成要素であり、したがってソフトウェアです。 明確な指示を与えることは、プログラムを成功させるために不可欠です。 プログラマーまたはソフトウェア開発者として、明確な指示を書く習慣を身に付ける必要があります。 これを行う2つの方法があります。
表現の明瞭さ
プログラム内の式は、算術計算または論理計算を行うための一連の演算子とオペランドです。 有効な式のいくつかの例を次に示します-
- 2つの値の比較
- 変数、オブジェクト、またはクラスの定義
- 1つ以上の変数を使用した算術計算
- データベースからデータを取得する
- データベースの値を更新する
明確な表現を書くことは、すべてのプログラマーが開発しなければならないスキルです。 そのような表現を書いている間、ここに留意すべきいくつかのポイントがあります-
明確な結果
式の評価では、明確な結果が1つ得られる必要があります。 たとえば、単項演算子は注意して使用する必要があります。
複雑な表現を避ける
1つの式で多くのことを達成しようとしないでください。 物事が複雑になり始めたら、2つ以上の表現に分けます。
指示のシンプルさ
明確な指示を書く必要があるのはコンピューターだけではありません。 後でプログラムを読んでいる人は誰でも（あなた自身も!!）命令が何を達成しようとしているかを理解できるはずです。 プログラマーは、しばらく経ってから再訪するときに自分のプログラムをハングアップしないことが非常に一般的です。 これは、そのようなプログラムの保守と変更が非常に難しいことを示しています。
簡単な指示を書くと、この問題を回避するのに役立ちます。 ここに簡単な指示を書くためのいくつかのヒントがあります-
- 巧妙な指示を避ける-巧妙な指示は、誰も適切に理解できない場合、後でその巧妙に見えないかもしれません。
- タスクごとに1つの命令-一度に複数のことをしようとすると、命令が複雑になります。
- 標準を使用-すべての言語には標準があり、それらに従ってください。 プロジェクトで一人で作業しているわけではないことを忘れないでください。プロジェクトの標準とコーディングのガイドラインに従ってください。
正しいプログラミング手法
この章では、優れたプログラムの作成方法について説明します。 しかし、それを行う前に、良いプログラムの特徴が何であるかを見てみましょう-
- ポータブル-プログラムまたはソフトウェアは、同じタイプのすべてのコンピューターで実行する必要があります。 同じタイプの場合、パーソナルコンピューター用に開発されたソフトウェアはすべてのPCで実行する必要があります。 または、タブレット用に作成されたソフトウェアは、適切な仕様を持つすべてのタブレットで実行する必要があります。
- 効率的-割り当てられたタスクを迅速に行うソフトウェアは効率的であると言われています。 コードの最適化とメモリの最適化は、プログラムの効率を上げるいくつかの方法です。
- 効果-ソフトウェアは、当面の問題の解決を支援する必要があります。 それを行うソフトウェアは効果的であると言われています。
- 信頼できる-プログラムは、同じ入力セットが与えられるたびに同じ出力を与える必要があります。
- ユーザーフレンドリー-プログラムインターフェイス、クリック可能なリンクとアイコンなど ユーザーフレンドリーである必要があります。
- 自己文書化-識別子名、モジュール名などのプログラムまたはソフトウェア。 明示的な名前を使用しているため、自分自身を説明できます。
優れたプログラムを作成する方法をいくつか紹介します。
適切な識別子名
変数、オブジェクト、関数、クラス、またはメソッドを識別する名前は、*識別子*と呼ばれます。 適切な識別子名を与えると、プログラムは自己文書化されます。 これは、オブジェクトの名前が何をするか、またはどの情報を保存するかを示すことを意味します。 このSQL命令の例を見てみましょう。
行10を見てください。 プログラムを読んでいる人に、生徒のID、名前、ロール番号を選択するように伝えます。 変数の名前から、これは一目瞭然です。 これらは、適切な識別子名を作成するためのいくつかのヒントです-
- 言語ガイドラインを使用する
- 明快さを維持するために長い名前を与えることをためらわないでください
- 大文字と小文字を使用する
- 言語で許可されている場合でも、2つの識別子に同じ名前を付けないでください
- 相互に排他的なスコープを持つ場合でも、複数の識別子に同じ名前を付けないでください
コメント
上の画像で、8行目を見てください。 次の数行のコードで、レポートカードを生成する生徒のリストを取得することを読者に伝えます。 この行はコードの一部ではありませんが、プログラムをより使いやすくするためにのみ与えられています。
コンパイルされていないが、プログラマーへのメモまたは説明として書かれたこのような式は、*コメント*と呼ばれます。 次のプログラムセグメントのコメントを見てください。 コメントは//で始まります。
コメントは次のように挿入できます-
- プログラムの目的を説明するためのプロローグ
- 論理ブロックまたは機能ブロックの最初および/または最後
- 特別なシナリオまたは例外についてメモします
読み取り中にコードの流れを壊すことで逆効果になることがあるため、余分なコメントを追加しないでください。 コンパイラーはコメントとインデントを無視するかもしれませんが、読者はそれらのそれぞれを読む傾向があります。
インデント
左マージンまたは右マージンからのテキストの距離は*インデント*と呼ばれます。 プログラムでは、インデントを使用して、論理的に分離されたコードブロックを分離します。 インデントされたプログラムセグメントの例を次に示します。
ご覧のとおり、インデントされたプログラムの方が理解しやすいです。 * forループ*から if に戻り、 for に戻る制御の流れは非常に明確です。 インデントは、制御構造の場合に特に役立ちます。
空白スペースまたは行の挿入もインデントの一部です。 インデントを使用できる場合と使用する必要がある状況を次に示します-
- プログラム内のコードの論理ブロックまたは機能ブロック間の空白行
- 演算子の周りの空白スペース
- 新しい制御構造の先頭にあるタブ
プログラミング方法論-デバッグ
プログラムまたはソフトウェアのエラーを特定して削除することを*デバッグ*と呼びます。 デバッグは理想的にはテストプロセスの一部ですが、実際にはプログラミングのすべてのステップで行われます。 コーダーは次に進む前に最小のモジュールをデバッグする必要があります。 これにより、テスト段階で発生するエラーの数が減り、テストの時間と労力が大幅に削減されます。 プログラムで発生する可能性のあるエラーの種類を見てみましょう。
構文エラー
- 構文エラー*は、プログラムの文法エラーです。 すべての言語には、識別子の作成、式の作成など、独自のルールセットがあります。 プログラムを書くため。 これらの規則に違反した場合、エラーは*構文エラー*と呼ばれます。 最新の*統合開発環境*の多くは、プログラムの入力時に構文エラーを特定できます。 それ以外の場合は、プログラムをコンパイルするときに表示されます。 例を見てみましょう-
このプログラムでは、変数prodは宣言されておらず、コンパイラによってスローされます。
セマンティックエラー
- セマンティックエラー*は、*論理エラー*とも呼ばれます。 このステートメントには構文エラーがないため、コンパイルして正しく実行されます。 ただし、ロジックが正しくないため、目的の出力が得られません。 例を挙げましょう。
13行目を見てください。 ここでプログラマは、除数が0であるかどうかをチェックして、0による除算を避けたいと考えています。 ただし、比較演算子==を使用する代わりに、代入演算子=が使用されています。 これで、「if式」が真と評価されるたびに、プログラムは「0で除算できません」と出力します。 間違いなく意図したものではありません!!
論理エラーはどのプログラムでも検出できません。目的の出力が得られない場合は、プログラマーがそれらを識別する必要があります。
ランタイムエラー
ランタイムエラーは、プログラムの実行中に発生するエラーです。 これは、プログラムに構文エラーがないことを意味します。 プログラムで発生する可能性のある最も一般的な実行時エラーの一部は次のとおりです-
- 無限ループ
- 「0」による除算
- ユーザーが入力した間違った値（たとえば、整数ではなく文字列）
コード最適化
品質と効率を改善するためにコードを変更する方法は、*コード最適化と呼ばれます。 コード品質*はコードの寿命を決定します。 コードを長期間使用して維持し、製品から製品に持ち越すことができる場合、その品質は高く、寿命が長いと見なされます。 逆に、あるバージョンのコードが短い期間だけ使用および保守できる場合、たとえばバージョンが有効になるまで、品質が低く、寿命が短いと見なされます。
コードの信頼性と速度が*コード効率*を決定します。 コードの効率は、ソフトウェアの高いパフォーマンスを確保するための重要な要素です。
コードの最適化には2つのアプローチがあります-
- 直観ベースの最適化（IBO）-ここでは、プログラマは自分のスキルと経験に基づいてプログラムを最適化しようとします。 これは小さなプログラムでは機能するかもしれませんが、プログラムの複雑さが増すと悲惨に失敗します。
- エビデンスベースの最適化（EBO）-ここでは、自動化されたツールを使用してパフォーマンスのボトルネックを見つけ、関連する部分を適宜最適化します。 すべてのプログラミング言語には、独自のコード最適化ツールのセットがあります。 たとえば、PMD、FindBug、およびCloverは、Javaコードを最適化するために使用されます。
時間が不足し、メモリが高価になるため、コードは実行時間とメモリ消費に対して最適化されます。 2つの間にバランスが必要です。 *時間の最適化*によりメモリの負荷が増加するか、*メモリの最適化*によりコードが遅くなると、最適化の目的が失われます。
実行時間の最適化
ユーザーに高速なサービスを提供するには、実行時間のコードを最適化する必要があります。 実行時間の最適化のためのいくつかのヒントがあります-
- 組み込みの実行時間最適化を備えたコマンドを使用する
- if条件の代わりにスイッチを使用
- ループ構造内の関数呼び出しを最小限に抑える
- プログラムで使用されるデータ構造を最適化する
メモリ最適化
ご存知のように、データと命令はメモリを消費します。 データとは、式の結果である中間データも指します。 また、最適化しようとしているプログラムまたはモジュールを構成する命令の数を追跡する必要があります。 ここに*メモリ最適化*のいくつかのヒントがあります-
- 組み込みのメモリ最適化を備えたコマンドを使用する
- レジスタに保存する必要がある変数の使用を最小限に抑える
- 何度も実行されるループ内でグローバル変数を宣言しないでください
- sqrt（）などのCPU集中型関数の使用を避けます
プログラムのドキュメント
ユーザーにソフトウェアまたはプログラムを説明するテキスト、イラスト、またはビデオは、「プログラムまたはソフトウェアドキュメント」と呼ばれます。 ユーザーは、プログラマー、システムアナリスト、および管理者からエンドユーザーまで誰でもかまいません。 開発のさまざまな段階で、異なるユーザー用に複数のドキュメントを作成できます。 実際、*ソフトウェアのドキュメント*は、ソフトウェア開発プロセス全体で重要なプロセスです。
モジュール式プログラミングでは、ソフトウェアの異なるモジュールが異なるチームによって開発されるため、ドキュメントはさらに重要になります。 開発チーム以外の誰かがモジュールを理解したい場合、またはモジュールを理解する必要がある場合は、適切で詳細なドキュメントがタスクを容易にします。
これらは、ドキュメントを作成するためのいくつかのガイドラインです-
- ドキュメントは読者の観点からのものでなければなりません
- 文書は明確でなければなりません
- 繰り返しはありません
- 業界標準を使用する必要があります
- ドキュメントは常に更新する必要があります
- 期限切れの記録が期限切れになると、期限切れのドキュメントはすべて廃止されます
ドキュメンテーションの利点
これらは、プログラムのドキュメントを提供する利点の一部です-
- ソフトウェアまたはプログラムのすべての部分を追跡します
- メンテナンスが簡単
- 開発者以外のプログラマは、ソフトウェアのすべての側面を理解できます
- ソフトウェアの全体的な品質を向上させます
- ユーザートレーニングを支援します
- 知識の分散化を確実にし、人々が突然システムを離れた場合のコストと労力を削減します。
サンプル文書
ソフトウェアには、多くの種類のドキュメントを関連付けることができます。 重要なもののいくつかが含まれます-
- ユーザーマニュアル-エンドユーザーがソフトウェアのさまざまな機能を使用するための手順と手順について説明しています。
- 操作マニュアル-実行されているすべての操作とそれらの相互依存関係をリストして説明します。
- 設計ドキュメント-ソフトウェアの概要を示し、設計要素を詳細に説明します。 *データフロー図、エンティティ関係図*などの詳細を文書化します。
- 要件ドキュメント-システムのすべての要件のリストと要件の実行可能性の分析があります。 ユーザーケース、実際のシナリオなどを含めることができます。
- 技術文書-アルゴリズム、フローチャート、プログラムコード、機能モジュールなどの実際のプログラミングコンポーネントの文書です。
- テスト文書-テスト計画、テストケース、検証計画、検証計画、テスト結果などを記録します。 テストは、集中的なドキュメントを必要とするソフトウェア開発の1つのフェーズです。
- 既知のバグのリスト-すべてのソフトウェアにはバグやエラーがあり、それらは非常に遅く発見されたか無害であるか、修正に必要以上の労力と時間を要するため削除できません。 これらのバグはプログラムのドキュメントに記載されているため、後日削除される可能性があります。 また、バグがアクティブ化された場合、ユーザー、実装者、および保守担当者を支援します。
プログラムのメンテナンス
- プログラムのメンテナンス*は、これらの結果のいずれかを達成するために配信後にソフトウェアまたはプログラムを変更するプロセスです-
- エラーを修正する
- 性能を上げる
- 機能を追加する
- 廃止された部分を削除する
ソフトウェアの公開後に発生するエラーを修正するにはメンテナンスが必要であるという一般的な認識にもかかわらず、実際には、メンテナンス作業のほとんどは、既存のモジュールにマイナーまたはメジャー機能を追加することを伴います。 たとえば、レポートにいくつかの新しいデータが追加され、エントリフォームに新しいフィールドが追加され、変更された政府の法律を組み込むために修正されるコードなどがあります。
メンテナンスの種類
メンテナンス活動は4つの見出しの下に分類することができます-
- 修正メンテナンス-オンサイトの実装後に発生するエラーが修正されました。 ユーザー自身がエラーを指摘する場合があります。
- 予防保守-将来のエラーを回避するために行われた変更は、予防保守と呼ばれます。
- 適応メンテナンス-作業環境の変更には、ソフトウェアの変更が必要な場合があります。 これは適応メンテナンスと呼ばれます。 たとえば、政府の教育ポリシーが変更された場合、学校管理ソフトウェアの学生結果処理モジュールで対応する変更を行う必要があります。
- 完全なメンテナンス-クライアントからの新しい要件を組み込むために既存のソフトウェアで行われた変更は、完全なメンテナンスと呼ばれます。 ここでの目的は、常に最新のテクノロジーを使用することです。
メンテナンスツール
ソフトウェア開発者とプログラマーは、ソフトウェアのメンテナンスを支援するために多くのツールを使用します。 最も広く使用されているもののいくつかを次に示します-
- プログラムスライサー-変更の影響を受けるプログラムの一部を選択します
- データフローアナライザ-ソフトウェア内のデータのすべての可能なフローを追跡します
- 動的アナライザー-プログラムの実行パスをトレースします
- 静的アナライザ-プログラムの一般的な表示と要約が可能
- 依存関係アナライザ-プログラムのさまざまな部分の相互依存関係の理解と分析を支援します
