システム開発技法 階層的手法

システム開発技法 階層的手法

システム開発技法 階層的手法は、システム全体から最終的なプログラムモジュールへとトップダウンで階層的に分割して設計する技法です。
このエントリーをはてなブックマークに追加

階層的手法とは

システム開発者の皆様へ、システム設計方法にはいくつかあるが、私が長年用いてる階層的手法があります。階層的手法の考え方は その概念はシステム全体から最終的なプログラムモジュールへとトップダウンで階層的に分割して設計する技法です。上位のレベルでは、分割の構成要素は、サブシステム、ジョブ等、プログラムモジュールとは直接対応しない概念的まとまりになります。
私の理解は単純明快、例えば、給与明細書作成システムの場合

  • インプット:勤務データ
  • プロセス:給与明細書作成
  • アウトプット:給与明細書

インプット、プロセス、アウトプットについて順次ブレイクダウンして詳細化してゆくこと。
注:図ー1の「コール」はサブルーチンを言い表してはいない(プログラム段階ではサブルーチンコール)

階層的手法

図―1:階層的手法

業務フロー階層化一例

図ー2から図ー3にするとフローはスッキリします。図―3をブレイクダウンして順次詳細化を行います。

業務フロ-

図―2:組織とデータの例

業務フロ-階層化;例

図―3:組織とデータの例

階層的手法はダイクストラにより定義されました

詳細はダイクストラの構造化プログラミングとはをご覧ください
上記、リンク先内容を集約したダイクストラの構造化プログラミングをご覧ください 概要は

ダイクストラは、プログラマは正しいプログラムを作り出すばかりでなく納得のいくやり方で正しさを証明(検証)することも仕事の一つであるという立場を取っていた。プログラムがどんなに巨大化しても良く構造化(well-structured)されていれば、サイズに関係なくその正当性を検証できるというのが彼の信念であった。well-formed formula(論理式)に因んでいるwell-structuredには、数理論理学の証明論をソースコードにも導入する意図が込められていた。1967年のノート「Towards Correct Programs」でダイクストラは、良く構造化するための三つのメンタルツール(mental tool)をこのように示している。
  • 列挙(enumeration): 一人の人間の能力でできる範囲でプログラムの命令の妥当性を一つ一つ確認していく作業
  • 数学的帰納(mathematical induction): while文など計算機特有の多数の繰り返し文についてのみ数学的帰納法を用いて確認する作業
  • 抽象(abstraction): プログラムのブロックなどに名前をつけ、さらに中身を見ないで正しいと仮定することで検証作業を後回しにする操作

プログラムが正しいことを確認するには、それを証明しなければならない。テストはプログラムに対する疑いを全て取り除くには不十分であるという意見が上がった。これについてダイクストラは「テストはバグの存在を示すには有効だが、バグが存在しないことは証明できない」という表現を好んで用いた。構造化プログラミングの支持者らは、プログラムの正しさの重要性と証明の方法や表明(assertion)の使い方について熱心に説いた。理想的にはテストだけに依存せず、プログラムの正しさの証明も与えるべきだと言われている。所与のプログラムの正しさを後付けで証明することは、はじめから証明を意識して作られたプログラムの場合より難しいことが経験的に知られている。ダイクストラは、プログラミングと同時にプログラムの証明を(わずかに証明を先行して)進めることを推奨している。そのようなアプローチでプログラムの正当性の問題にあたれば、複雑な問題であっても知的管理が可能であると述べた。しかし形式的な証明は、時として非人間的な長さの記述になることもダイクストラは認めている]。同氏は、プログラムの証明が形式的であることにはこだわらないという意見を明らかにした。 エドガー・ダイクストラ(Edsger Wybe Dijkstra, 1930年5月11日 - 2002年8月6日)は、オランダ人の計算機科学者。1972年、プログラミング言語の基礎研究への貢献に対してチューリング賞を受賞。構造化プログラミングの提唱者。1984年から2002年に亡くなるまでテキサス大学オースティン校の計算機科学の Schlumberger Centennial Chair を務めた

エドガー・ダイクストラ

エドガー・W・ダイクストラ著『謙虚なプログラマー』について

詳細はエドガー・W・ダイクストラ著『謙虚なプログラマー』をご覧下さい。
日本語版はGoogle翻訳によるエドガー・W・ダイクストラ著『謙虚なプログラマー』をご覧ください
*この本はどこにも販売されていません。唯一無二の資料です。

下記は上記資料よりの抜粋です
プログラム構造の研究により、プログラム(同じタスクで同じ数学的内容を持つ代替プログラムでさえ)の知的管理性は大きく異なる可能性があることが明らかになりました。

    6つの論拠
    プログラム構造の研究により、プログラム(同じタスクで同じ数学的内容を持つ代替プログラムでさえ)の知的管理性は大きく異なる可能性があることが明らかになりました。違反するとプログラムの知的管理性が著しく損なわれるか、完全に破壊される規則がいくつか発見されました。
    1. プログラマーは知的に管理可能なプログラムのみを考慮する必要があるため、選択する選択肢ははるかに簡単に対処できるというものです。
    2. 知的に管理可能なプログラムのサブセットに制限することを決定した時点で、検討すべきソリューション空間の大幅な削減が達成されたということです。
    3. プログラムの正しさの問題に対する建設的なアプローチに基づいています。今日、通常の手法は、プログラムを作成してからテストすることです。しかし、プログラムのテストはバグの存在を示すのに非常に効果的な方法ですが、バグが存在しないことを示すにはまったく不十分です。プロ
    4. グラムの信頼度を大幅に上げる唯一の効果的な方法は、その正しさを説得力のある形で証明することです。
    5. プログラムを設計するために必要な知的努力の量がプログラムの長さに依存するという点に関係しています。必要な知的努力の量はプログラムの長さの2乗に比例して増加するという、ある種の自然法則があると言われています。 これは、私たちが使用しようとしているツールが私たち自身の思考習慣に与える影響に関するものです。
    6. 知識を広めるのではなく、方法論を教える最初の効果は、すでに能力のある人の能力を高め、知能の差を拡大することです。
    結論
    プログラミングの難しさを十分に理解した上でタスクに取り組む限り、控えめで洗練されたプログラミング言語に固執する限り、人間の心の本来の限界を尊重し、非常に謙虚なプログラマーとしてタスクに取り組む限り、私たちははるかに優れたプログラミング作業を行うことができます。
しばらくおまちください・・・

  • IT導入補助金が理解できていない、利用方法が分からない。
  • インボイス対応や電子帳簿保存法の意味が分からない。
  • 業務可視化の必要性や方法などわからず困っている。
  • RPAの対応方法方法などわからず困っている。
  • DXの取り組み方法などわからず困っている。
  • ・・・
  • どこに相談していいか分からない。

OAコーディネータズが解決します

今が変化をチャンスに変える時です。
新たなビジネス価値の創出や働き方の変革など、そして、
既存のビジネスのあり方や
システムをさらにITにより効率化し、
コスト削減や従業員の
生産性向上を進めていくことが重要です。

業務フローの作成、IT導入補助金導入、インボイス対応、電子帳簿保存法対応、DX、RPA、など無料相談実施中です、
この機会にご一緒に業務改革を行いましょう

このエントリーをはてなブックマークに追加

弊社のメンバーシップになりませんか。
OAコーディネターズとは

情報処理コンサルティング「 OAコーディネーターズ」

最上行へ

Copyright © OAコーディネターズ All Rights Reserved.