ソフトウェア分析および設計ツール

ソフトウェアの分析と設計には、要件仕様を実装に変換するのに役立つすべてのアクティビティが含まれます。要件仕様は、ソフトウェアからのすべての機能的および非機能的期待を指定します。これらの要件仕様は、人間が読める形式で理解できるドキュメントの形をしており、コンピューターはそれとは何の関係もありません。

ソフトウェアの分析と設計は中間段階であり、人間が読める形式の要件を実際のコードに変換するのに役立ちます。

ソフトウェア設計者が使用する分析および設計ツールをいくつか見てみましょう。

データフロー図

データフロー図は、情報システム内のデータの流れをグラフで表したものです。着信データフロー、発信データフロー、および保存されたデータを表すことができます。DFDは、データがシステムをどのように流れるかについては何も言及していません。

DFDとフローチャートの間には顕著な違いがあります。フローチャートは、プログラムモジュールの制御フローを示しています。DFDは、システム内のデータの流れをさまざまなレベルで表します。DFDには、制御要素または分岐要素は含まれていません。

DFDの種類

データフロー図は論理的または物理的です。

Logical DFD -このタイプのDFDは、システムプロセス、およびシステム内のデータのフローに重点を置いています。たとえば、銀行のソフトウェアシステムでは、異なるエンティティ間でデータを移動する方法です。
Physical DFD-このタイプのDFDは、データフローが実際にシステムにどのように実装されているかを示します。より具体的で、実装に近いものです。

DFDコンポーネント

DFDは、次のコンポーネントセットを使用して、データのソース、宛先、ストレージ、およびフローを表すことができます-

Entities-エンティティは、情報データのソースと宛先です。エンティティは、それぞれの名前が付いた長方形で表されます。
Process -データに対して実行されたアクティビティとアクションは、円または角の丸い長方形で表されます。
Data Storage -データストレージには2つのバリエーションがあります-両方の小さい辺がない長方形として表すことも、片側だけが欠けている開いた辺の長方形として表すこともできます。
Data Flow-データの移動は、先のとがった矢印で示されています。データの移動は、ソースとしての矢印の基部から宛先としての矢印の頭に向かって示されています。

DFDのレベル

Level 0-最高の抽象化レベルDFDは、レベル0 DFDと呼ばれ、情報システム全体を、基礎となるすべての詳細を隠す1つの図として示します。レベル0DFDは、コンテキストレベルDFDとも呼ばれます。

Level 1-レベル0DFDは、より具体的なレベル1DFDに分類されます。レベル1DFDは、システム内の基本モジュールとさまざまなモジュール間のデータフローを示します。レベル1DFDは、基本的なプロセスと情報源についても言及しています。

Level 2 -このレベルでは、DFDは、レベル1で説明したモジュール内でデータがどのように流れるかを示します。

高レベルのDFDは、必要なレベルの仕様が達成されない限り、より深いレベルの理解を備えた、より具体的な低レベルのDFDに変換できます。

構造図

構造図は、データフロー図から派生したグラフです。これは、DFDよりも詳細にシステムを表します。システム全体を最も機能の低いモジュールに分解し、システムの各モジュールの機能とサブ機能をDFDよりも詳細に説明します。

構造図は、モジュールの階層構造を表しています。各レイヤーで特定のタスクが実行されます。

構造図の作成に使用される記号は次のとおりです-

Module-プロセス、サブルーチン、またはタスクを表します。制御モジュールは、複数のサブモジュールに分岐します。ライブラリモジュールは再利用可能であり、どのモジュールからでも呼び出すことができます。
Condition-モジュールのベースにある小さなひし形で表されます。これは、制御モジュールが何らかの条件に基づいて任意のサブルーチンを選択できることを示しています。
Jump -コントロールがサブモジュールの中央でジャンプすることを示すために、モジュール内を指す矢印が表示されます。
Loop-曲線の矢印は、モジュール内のループを表します。ループの対象となるすべてのサブモジュールは、モジュールの実行を繰り返します。
Data flow -末尾に空の円が付いた有向矢印は、データフローを表します。
Control flow -末尾に黒丸が付いた有向矢印は、制御フローを表します。

HIPO図

HIPO（Hierarchical Input Process Output）ダイアグラムは、システムを分析し、文書化の手段を提供するための2つの体系化された方法の組み合わせです。HIPOモデルは、1970年にIBMによって開発されました。

HIPOダイアグラムは、ソフトウェアシステムのモジュールの階層を表します。アナリストは、HIPOダイアグラムを使用して、システム機能の高レベルのビューを取得します。関数を階層的にサブ関数に分解します。これは、システムによって実行される機能を示しています。

HIPOダイアグラムは、文書化の目的に適しています。それらのグラフィック表現により、設計者と管理者はシステム構造の図解を簡単に理解できます。

モジュール内の制御とデータのフローを示すIPO（入力プロセス出力）図とは対照的に、HIPOはデータフローまたは制御フローに関する情報を提供しません。

例

HIPOダイアグラム、階層表示、IPOチャートの両方の部分は、ソフトウェアプログラムの構造設計とその文書化に使用されます。

構造化された英語

ほとんどのプログラマーはソフトウェアの全体像に気付いていないので、マネージャーが指示したことだけに頼っています。正確で高速なコードを開発するためにプログラマーに正確な情報を提供することは、より高度なソフトウェア管理の責任です。

グラフや図を使用する他の形式のメソッドは、人によって解釈が異なる場合があります。

したがって、ソフトウェアのアナリストや設計者は、StructuredEnglishなどのツールを考え出します。コーディングに必要なものとそのコーディング方法の説明に他なりません。構造化英語は、プログラマーがエラーのないコードを書くのに役立ちます。

グラフや図を使用する他の形式の方法は、人によって解釈が異なる場合があります。ここでは、構造化英語と擬似コードの両方が、その理解のギャップを緩和しようとしています。

構造化英語は、構造化プログラミングパラダイムで平易な英語の単語を使用します。これは最終的なコードではなく、コーディングに必要なものとそのコーディング方法の一種の説明です。以下は、構造化プログラミングのいくつかのトークンです。

IF-THEN-ELSE,  
DO-WHILE-UNTIL

アナリストは、データディクショナリに格納されているのと同じ変数とデータ名を使用するため、コードの記述と理解がはるかに簡単になります。

例

オンラインショッピング環境での顧客認証の同じ例を取り上げます。顧客を認証するこの手順は、構造化英語で次のように記述できます。

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
   Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
   PRINT error message
   Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

構造化英語で書かれたコードは、日常の話し言葉に似ています。ソフトウェアのコードとして直接実装することはできません。構造化英語はプログラミング言語に依存しません。

擬似コード

擬似コードは、プログラミング言語により近い形で記述されています。コメントや説明が満載の拡張プログラミング言語と見なすことができます。

擬似コードは変数宣言を回避しますが、C、Fortran、Pascalなどの実際のプログラミング言語の構造を使用して記述されています。

擬似コードには、構造化英語よりも多くのプログラミングの詳細が含まれています。これは、コンピューターがコードを実行しているかのように、タスクを実行するためのメソッドを提供します。

例

n個までのフィボナッチを印刷するプログラム。

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
   if a greater than b 
   {
      Increase b by a;
      Print b;
   } 
   else if b greater than a
   {
      increase a by b;
      print a;
   }
}

デシジョンテーブル

デシジョンテーブルは、条件とそれに対処するために実行するそれぞれのアクションを構造化された表形式で表します。

これは、エラーをデバッグおよび防止するための強力なツールです。同様の情報を1つのテーブルにグループ化し、テーブルを組み合わせることで、簡単で便利な意思決定を実現します。

デシジョンテーブルの作成

デシジョンテーブルを作成するには、開発者は基本的な4つの手順に従う必要があります。

対処すべきすべての可能な条件を特定する
識別されたすべての条件に対するアクションを決定します
可能な最大のルールを作成する
各ルールのアクションを定義する

デシジョンテーブルはエンドユーザーが検証する必要があり、最近では重複するルールとアクションを排除することで簡素化できます。

例

インターネット接続に関する日常の問題の簡単な例を見てみましょう。まず、インターネットの起動中に発生する可能性のあるすべての問題と、それぞれの可能な解決策を特定します。

列の条件下で発生する可能性のあるすべての問題と、列のアクションの下に予想されるアクションをリストします。

	条件/アクション	ルール
条件	接続済みを表示	N	N	N	N	Y	Y	Y	Y
	pingは機能しています	N	N	Y	Y	N	N	Y	Y
	ウェブサイトを開く	Y	N	Y	N	Y	N	Y	N
行動	ネットワークケーブルを確認してください	バツ
	インターネットルーターを確認する	バツ				バツ	バツ	バツ
	Webブラウザを再起動します							バツ
	サービスプロバイダーに連絡する		バツ	バツ	バツ	バツ	バツ	バツ
	アクションを実行しない

表：デシジョンテーブル–社内インターネットトラブルシューティング

実体関連モデル

実体関連モデルは、実世界の実体とそれらの間の関係の概念に基づくデータベースモデルの一種です。現実世界のシナリオをERデータベースモデルにマッピングできます。ERモデルは、属性、制約のセット、およびエンティティ間の関係を使用してエンティティのセットを作成します。

ERモデルは、データベースの概念設計に最適です。ERモデルは次のように表すことができます。

Entity -ERモデルのエンティティは実世界の存在であり、次のようなプロパティがあります。 attributes。すべての属性は、対応する値のセットによって定義されます。domain。

たとえば、学校のデータベースについて考えてみます。ここでは、学生はエンティティです。学生には、名前、ID、年齢、クラスなどのさまざまな属性があります。
Relationship -エンティティ間の論理的な関連付けは呼び出されます relationship。関係は、さまざまな方法でエンティティにマッピングされます。マッピングカーディナリティは、2つのエンティティ間の関連付けの数を定義します。

カーディナリティのマッピング：
- 1対1
- 1対多
- 多対1
- 多対多