プログラミングにおける役割ベースの情報モデリング

まえがき


この記事は、2010年のEducational Technologiesジャーナルに掲載されました。 私の意見では、プログラミングを教えることはプログラミング自体と同じくらい重要なので、Habrに適応させることにしました。 その中で、「なぜ?」という質問に答えようとしました。 初心者プログラマーだけでなく、すでに由緒ある達人にも役立つことを願っています。 興味があれば、猫の下で歓迎してください。



簡単な処分


そこで、まず、役割ベースの情報モデリングとは何かを判断しましょう。 ロールベースの情報モデリング(RIM)とは、モデルの開発および/またはその後の分析のための問題の定式化が、さまざまな社会的役割で行動する人々の観点から実行される情報モデリングを意味します。 このような方法論では、開発者が問題を特定し、タスクを設定し、モデルの構築に必要なオブジェクトのメインプロパティとセカンダリプロパティを特定し、ソフトウェアを含むさまざまなツールを使用してタスクを解決し、作業結果を予測および評価できる必要があります。



問題の原因


プログラミングするとき、私たちはしばしば開発者と同じ役割を果たし、プログラミング言語を学習するプロセスはこの立場に基づいています。 このアプローチでは、一部の言語構成要素(たとえば、コメント)が一見冗長に見え、適切な注意を必要としません。 RIM技術により、プログラミング言語の個々のツールの目的を新しい方法で明らかにし、問題の有能な解決策の重要性を強調することができます。 オランダの著名な科学者Edsger W. Dijkstraは、次のように述べています。「プログラマの製品は自分が書いたプログラムだと考えている人は、非常に間違っています。 プログラマーは、信頼できる決定を作成し、説得力のある議論の形でそれらを提示する義務があり、書かれたプログラムのテキストは、この証拠が適用される資料のみをサポートしています。

上記を例で示します。 再帰を使用して、奇数nの二重階乗を計算するプログラムを作成する必要があります。 二重階乗は、 nと同じパリティのすべての自然数の積であり、 nを含むことを思い出してください。

この問題の解決策の1つは、次のPascalプログラムです(当然、プログラムはn> 21では機能しないことがわかっていますが、一般性を損なうことなく、例として使用できます)。

プログラム奇要因;
 crtを使用します。
 var n:整数;
関数F(n:整数):倍長整数;
始める
	 n = 1の場合、F:= 1
	他に 
	 n = 3の場合、F:= 3
	それ以外の場合F:= n * F(n-2);
終わり;
始める
	 ClrScr;
	繰り返す
		 Readln(n);
	奇数(n)まで。
	書き込み(F(n));
	 Readln
終わり。




診断


開発者の観点から見ると、このプログラムはタスクを完全に解決しますが、 ユーザーの観点からソリューションを分析する場合は、提案されたオプションを確定する必要があります。

実際、プログラムをコンパイルして実行する場合、ユーザーにとっての作業プロセスは「ブラックボックス」との通信に似ています。入力プログラムは、奇数が入力されるまで数字を読み取り、出力で計算された答えを返します。 当然、プログラムの入出力にはユーザーへの指示が含まれている必要があります。

プログラム奇要因;
 crtを使用します。
 var n:整数;
関数F(n:整数):倍長整数;
始める
	 n = 1の場合、F:= 1
	他に 
	 n = 3の場合、F:= 3
	それ以外の場合F:= n * F(n-2);
終わり;
始める
	 ClrScr;
	繰り返す
		書き込み(「二重階乗を計算するには奇数を入力してください:」);
		 Readln(n);
	奇数(n)まで。
	書き込み(「数値の二重階乗」、n、「等しい」);
	書き込み(F(n));
	 Readln
終わり。


したがって、ユーザーの役割は、データの入出力の適切な設計に焦点を当てるのに役立ちますが、これは必ずしも明らかではありません。



完璧さに制限はありません


次に、サードパーティの役割であるサードパーティの開発者について考えます。 このような役割の必要性は、大規模なプロジェクトでは多数の開発者の調整されたアクションが必要であるという事実によるものです。 サードパーティの開発者にとって、プログラムの最も重要な要件はその理解しやすさです。これは、若いプログラマには明らかではないいくつかのプログラミングスタイルを観察することで達成できます。

1つのスタイルの概念は、わかりやすい変数名を使用することです。 たとえば、ハンガリーの表記法によると、変数の名前には、特にその型に関する情報が含まれている必要があります。変数pszLicFileContentsの名前は、固定サイズ(sz)の文字列へのポインター(p)であり、その型は変数pbContentの名前にエンコードされますLPBYTE、bVerified変数はbool型です。

ただし、厳密なタイピングは常に人工的な手段で効果的に置き換えることはできません。また、これらの人工的な手段を維持することで努力を正当化できるとは限りません。 現代のアプローチでは、SelectedIndexInTable、OpenedFileNameという意味でのみ変数に名前を付けることを提案しています。

また、プログラムのソースコードを作成すると、その明瞭さが向上します。 Pascalプログラミング言語では、プログラム演算子を区切り文字「;」および「。」を使用して1行にリストできますが、このようなレコードが理解不能で理解しにくいことは明らかです。 示した例では、変数定義ブロック、ループ、入力および出力演算子はインデントされています。 たとえば、Pythonなどのプログラミング言語では、適切なコード設計なしではプログラムを実行できません。

さらに、コメントはコードの明瞭さを大幅に向上させるのに役立ちます。 プログラムまたはモジュールオブジェクトの各オブジェクトとすべてのパブリックメソッド、および存在する場合は変数、さらに内部メソッドと変数の必須コメント、および内部関数について詳しくコメントすることをお勧めします。特に複雑で重要な点についてコメントする必要があります。 関数を記述する前に、コメントで動作を詳細に説明することを提案するアプローチがあります。

 {getlines関数は、キーボードから入力された行を読み取り、str配列に書き込み、読み取った行数を返します}
関数getlines(var str:文字列の配列):整数;
 var
	 i:整数;  {ラインカウンター}
始める
	 i:= 0;  {カウンターの初期化}
 {ファイルの終わりに達するまで、次の行を読み、カウンターを増やします}
	 eof(入力)ではありません
	始める
		 Readln(str [i]);
		 inc(i);
	終わり;
 {読み取られた行数を返す}
	 getlines:= i;
終わり; 


ソースコードへのコメントの支持者は、コメントが暗黙的に開発者をあいまいなコードを書くように押すと主張する反対者がいることに注意する必要があります(コメントには説明があります)。 しかし、開発者のトレーニングレベルは異なるため、既存のジレンマから抜け出す最適な方法は、プログラムの最も複雑なセクションの理解可能なコードとコメントの共生です。

上記のアプローチに従って、提案した例のプログラムテキストを次のように変更する必要があります。
プログラム奇要因;
 crtを使用します。
 var n:整数;
 {DoubleFactorial関数は、渡された数値nの二重階乗をカウントします}
関数DoubleFactorial(n:整数):倍長整数;
始める
 {最初の2つの条件は、二重階乗の定義から取得されます}
	 n = 1の場合、DoubleFactorial:= 1
	他に 
	 n = 3の場合、DoubleFactorial:= 3
 {再帰関数呼び出し}
	その他のDoubleFactorial:= n * DoubleFactorial(n-2);
終わり;
始める
	 ClrScr;
	繰り返す
		書き込み(「二重階乗を計算するには奇数を入力してください」);
                 Readln(n);
	奇数(n)まで。  {奇数を入力するまで数字を入力し続けます}
	書き込み(「数値の二重階乗」、n、「等しい」);
	書き込み(DoubleFactorial(n));
	 Readln
終わり。 


したがって、プログラミング教育におけるロールベースの情報モデリングの使用により、問題を解決するためのモデルを開発する段階ですでに起こりうる問題を特定し、プログラミング言語の設計の可能性をより広く見て、開発者をプログラムコードの適切な設計とユーザーの世話に集中させることができます。



PS


当然、Habrを読んでいる人のほとんどは、これらすべてが私なしで知られていたと言うでしょう。 街の舞台のオリンピックの問題を確認するまで、私もそう思いました。 ほとんどの参加者のコードの設計が不注意であることに驚きました。プログラムはブラックボックスの原則に基づいて機能していました。 ファイルの名前とタスク番号によってのみ、提出する必要があるもの(ファイル、一連の数字または文字)を決定できました。 オリンピアードのタスクでは、作業速度と正確さが重要であることを理解していますが、「うまく機能する」という原則が採用され、日常のプログラミングでそれを考えるときがきました。

貧弱なインターフェース、不便なダイアログデザインなどでプログラムをscります。 そして、これは、私の意見では、開発に対する技術的なアプローチの結果であり、「定義上、すべてのユーザーは愚かだ」と彼らは言います。

私の記事では、ROMEの原理を簡単に概説しようとしました。これは、製品をさまざまな角度から見ることを教えてくれます。 誰かが役に立つことを願っています。



All Articles