構造化プログラミングはまだ必要ではないのか？
■ このスレッドは過去ログ倉庫に格納されています
構造化プログラミングで言うところの「抽象化データ構造とその操作の抽象文の共同詳細化」はオブジェクト指向のクラスで実現された。
しかし、オブジェクト指向だけでは、階層化と段階的詳細化と段階的抽象化が実現できない。
まだ構造化プログラミングは必要なのではないのか？
しかし、今は風化しているように思えて仕方がないし、ダイクストラの考えを知っていれば、もっとマシなコードが書けそうだが。
（Wikipedia の構造化プログラミング）
https://ja.wikipedia.org/wiki/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0 コード書くときに「これはオブジェクト指向、あっちは構造化プログラム」っていちいち意識するかバカ者 >>2
とはいえオブジェクト指向だけで説明できないことも多い。
クラスにすれば全て解決ではない。
構造化プログラミングを意識しないと無駄なクラスをたくさん作ることになる。 >>1
構造化プログラミングについて少し歴史的なことをメモしておこう
構造化定理は逐次的プログラム（つまり並行して動作し得る複数のプロセス・スレッド・タスクが存在せず単一のプログラムカウンタで済むプログラム）について
３基本構造（順接、分岐、反復）の表現能力に関する数学的事実を述べた定理に過ぎず、書かれるプログラムの信頼性とか読み易さ・理解し易さとは無関係
それをさも関係があるように錯覚させたのが実務畑のHarlan D. Millsの狡猾なところであり、またある意味では有能なところでもある
つまり、多くのプログラマはバカだから単純なクライテリアでなければ理解できないから、バカ向けの単純なクライテリアを与えてやった、これが確信犯Millsの功績であり罪過でもある
言い換えればDijkstraの高尚な“structured programming”の精神などはバカな大衆プログラマには理解不能で豚の耳に念仏だとMillsは悟っていたから
Dijkstraの提唱した“structured programming”という標語だけ借りて中身はバカ向けに完全に換骨奪胎したのがMills流の“structured programming＝goto-less programming”という一種の運動
そして、この運動を権威づけるために使ったのが単なる表現定理に過ぎない構造化定理だったわけだ
つまり「この運動が正しいことはちゃんと数学で保証されてるんだよ！」って権威づけをしたわけね
アカデミアの世界にずっと身を置いていたDijkstraとは違い、MillsはIBMの研究員として開発現場の指導なども行って現場プログラマのほとんどはバカばかりだと嫌というほど思い知らされていたはず
だからこそ「正しいが難し過ぎてバカには正しく理解するのは不可能」なDijkstra流の高尚な“structured programming”からキャッチフレーズの“structured programming”だけ流用して
「正しくないがバカにも理解し実行できて多少は効果が見込める」Mills流の低俗な“structured programming”を広めたのだよ
そしてMichael Jacksonパパが構造化定理に基づいて事務処理向けのプログラミングを入出力データ構造の対応から３基本構造を用いる形で系統的に導出する手法として
JSP (Jackson Structured Programming) を提案して大人気を博したことでMills流の低俗な“structured programming”運動は一層の盛り上がりを見せたというわけ >>1
Wikipediaより
>1987年の第9回ソフトウェア工学国際会議(ICSE)において、Millsは会場にチューリング賞受賞者がいないことを確かめると
>「ダイクストラやホーア達はどこへ行ってしまったのか。我々はもう彼らから学ぶものがないのか。」とその現状を批判した
>（しかし木村泉の見解が当たっていたとするならば、「ソフトウェア工学」をそういったものにしていった張本人こそが、その発言をしたMillsであるということになる）。
酷いよなあ
ダイクストラの研究を粉砕した張本人がよくこんなことを言えるわ （きちんとクラスが整理された上での）OOPこそ構造化プログラミングの結実したものと思っていたんだが違うのか 今はオブジェクト指向さえできれば十分という風潮がある。
しかし、オブジェクト指向は主にクラスを使うというだけであって、
綺麗で分かりやすいプログラムを書けるかどうかとは別問題。
構造化プログラミングは綺麗で分かりやすいプログラムを書く手法としては今でも大事かと。 >>8
>オブジェクト指向は主にクラスを使うというだけであって
そりゃいくら何でも偏見 COBOL、VB、Java…と時代が流れても馬鹿は馬鹿なコードを書く。 >>1
選択するようなもんじゃないじゃん・・・
何で片っぽだけで存在出来ると思ってんの？ >>1 がクソコードしか書けないのは分かったからいちいちスレ立てんな。 >>13
いや、ｽﾚ建ての言い分は稚拙かもしれないが、
型クラスベース+継承でソフトウエアを表現すると
依存の茂みを作ってスパゲティーの山になる欠点に薄々気がついて
王様の耳はロバの耳と、あえて言っているのかもしれない… >>14
オブジェクト指向で却ってややこしくなった面もあるかもね オブジェクト指向技術はエディタの機能で代替できるような気がする。
エディタにはコードの検索や置換機能があるし、
VimやSublime,サクラエディタで高速に既存コードを再利用できる。
だからエディタの機能やVimを極めれば継承とかほぼ要らないし、
再利用性重視でなくてもいい。
変更の影響範囲とかもエディタを使って洗い出せば、管理できる。
だからオブジェクト指向の高度な機能を使わなくてもエディタや
ツールで代替えできる。
コードの差分はGitやWinMergeで洗い出せる。
オブジェクト指向のガチガチの設計を書くととにかく
変数名、メソッド名などの名前が長くなる。
名前が横に長いと非常に読みにくく画面外に隠れるし、
名前というのはスペース区切りもカンマ区切りもないわけだから、
上記のエディタ機能で編集がやりにくい。
だからJavaみたいなガチガチのオブジェクト指向ってもう今の時代
必要ないんだと思う。JavaScriptやPythonくらいのオブジェクト指向
だけで十分だもの。
Javaの作法の時代遅れ感とか、馬鹿馬鹿しさってそろそろ気付くべき。 >>12
>>1
>まだ構造化プログラミングは必要なのではないのか？
条件が整えば不要になると自分で書いてるじゃん。 >>15
2010年のインタビューでは、オブジェクト指向の御大は「実現方法に欠点があった」と考えてるようだ。
オブジェクト指向プログラミングは間違いだったか?
https://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang
>このインタビューを受けたのは、Erlangの最初の開発者であるJoe Armstrong博士とSmalltalk、OOP、パターンに長い間関係している
>Ralph Johnson博士だ。私たちは「間違った道」を当てもなくさまよって
>きたが、これはオブジェクトの考え方の実現方法に欠点があったため
>であり、この考え方自体の欠点ではないと2人は述べた。 >>18
これってクラスが良くないってこと？
Erlangの仮想マシンのプロセスみたいなものが良いってこと？ そもそもオブジェクト指向は、データとアルゴリズムをクラスとして組み合わせただけのこと。
構造化プログラミングみたいに綺麗なコードを書くためのものではない。 >>21
なるほど、構造化プログラミングは設計手順でもあるのかー
オブジェクト指向だとドメイン駆動とかユースケース駆動なんかが
それにあたるのかね
Wikipediaの構造化プログラミングには↓こう書いてあって
> プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する
これってオブジェクトの設計にも当てはまるよね
オブジェクトは構造化の手段の一つとみることもできそう >>22
つーか、ダイクストラが抽象化データ構造という概念を提案していて、
それがオブジェクト指向のクラスに似た考えだった。 >>22
> > プログラムを記述するのではなく、機能を抽象化した「仮想機械」を想定し、その「仮想機械が提供する命令群」でプログラムを構成する
>
> これってオブジェクトの設計にも当てはまるよね
> オブジェクトは構造化の手段の一つとみることもできそう
ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね
オブジェクト指向がそのように暴走しだした時＝オブジェクト原理主義が始まったから、オブジェクト指向を熱心に使う人々の大半は構造化プログラミングとは無関係になり、
オブジェクト指向で作られたプログラムはDijkstraが考えていたようなプログラムの正しさを論じやすいようにしっかりとした構造を持つものではなく、
まるで簡単に取り外しできて自由に回転できる自由継手ばかりで組み上げられたようなクネクネとして「形」というものが良く見えない代物になった
確かに細かいオブジェクトを自由に組み合わせて作れば部品の追加や削除は容易になるが、プログラムの正しさを論じるには余りにも自由度が高すぎて見通しが悪すぎる >>24
>ところがSimula 67の頃はともかく、Smalltalk-80以降のオブジェクト指向の人々は暴走して上の構造化プログラミングでの抽象機械という思考上の粒度とは
>およそ対応しないほど細かい粒度のオブジェクトをどんどん使い始めた、例えば「１つの数だって立派なオブジェクトだ！」といった形でね
確かにオブジェクト指向はそんなものだと漠然と思っていたけど
何でもオブジェクトにすればいいってものではないよなあ。
結局、オブジェクト指向の導入によってプログラムは難解になっただけだった。
柔軟性は上がったけど可読性は低下した。 >>25
暴走というより、プログラミングの可能性追究の過程だからね。
「可読性という産業的な面の利便性」とは別の、今で言えば自動プログラミングの方向だし。 Smalltalk で何でもオブジェクトになるのは文法と実装からほぼ必然なので許してやれ >>29
Smalltalkはオブジェクト指向を突き詰めたらどうなるのかを実現した言語だし >>28
「わかりみ」は文法違反の単なる誤用で日本語の意味のある単語としては認められない
＞本文中の他の「?み」の例、つまり「ありがたみ」や「悲しみ」それに漱石が使った「淋しみ」は
＞どれも形容詞「ありがたい」・「悲しい」・「淋しい」の語幹に「み」を付けて名詞化した言葉であるが「わかりみ」は違う
上に加えると
「わかりみ」の語根「わかり」は動詞「わかる」の連用形なので形容詞のように体言にかかり修飾することすらできない単語で
それに「〜み」を付けた形を日本語の言葉として使うのは単なる無知を曝け出しているだけのこと >>1
ダイクストラの提唱した検証を前提としたプログラミングが必要か？という
疑問であれば、これから必要だし今後はさらに重要になると断言できる
実際、24時間365日 正しく動作するバグ0の品質要求が当たり前な
組み込み開発の一部では、必須の技術要素になりつつある
ただし、ソフトウェア検証への対比としてオブジェクト指向を挙げる事に違和感がある
ソフトウェア検証とオブジェクト志向は互いに交差する概念であって対立はしない
実際、たとえば VDMにオブジェクト指向を導入したVDM++が登場しているし、
Alloy は最初からオブジェクト指向の概念を前提として設計されている >>31
言語学上はある表現が間違ってる云々といった議論は意味を持たない
例えば、あらゆる方言は標準語から見れば「誤り」だがそのような主張をする人はいない
一定の範囲で通用しているならそれは「正しい」言葉なのだ >>33
>実際、24時間365日 正しく動作するバグ0の品質要求が当たり前な
>組み込み開発の一部では、必須の技術要素になりつつある
具体的にどうやっているんだ？ >>35
開発したいシステムの外部仕様をVDMやAlloyといった形式的仕様記述言語で
記述し、それをツールを使って検証、詳細化という手法で実装言語に変換
詳細に関しては「組込み 形式手法」や「組込み 仕様記述」でググると、
大量の入門やら事例やらを扱う文書が見つかる
個人的にお勧めの教科書(入門書)は以下の２冊：
・形式手法入門
https://www.amazon.co.jp/dp/4274211886/
・組み込みソフトへの数理的アプローチ
https://www.amazon.co.jp/dp/4789838080/
このム板にも専用スレがある（過疎ってるけど
・【Alloy】形式言語による仕様記述【VDM】
http://mevius.2ch.net/test/read.cgi/tech/1357387746/ >>36
ありがとう。今の組込はそんなことをやっているんだなあ。 >>32
> Smalltalkなんて死んだ言語
Smalltalkは現役バリバリの言語処理系だが？→http://pharo.org/
そんなことも知らんとかアンテナ低すぎだぞ！wwwwww >>38
アンテナ強すぎてノイズ拾ってるんちゃうんか？ >>39
アンテナ「強」すぎとかググり力以前に日本語wwww セックスが強いとも言うし
匂いが強いとも言うのよ
強いって言葉は何にでも使っていいの万能なの ググり力ってなんすか？www日本語エントロピーが拡散してますよ try - catch の大域脱出は構造化プログラミングに入るの？
許されてるのかどうかが知りたい 例外処理やついでに継続なんかは本質的にGOTOだからもちろんダメだろ 構造化は今でも必要だと思うよ
初期の(今でも?)プログラミングで作られた物が大変だったのは
何もかもが広域だったから
構造化にしてもオブジェクト指向にしても
アクセス範囲を狭小化したのが一番効果が大きい
余りにも何処からでもアクセスされてるとそのアクセスパターンが発散してしまって
組み合わせ数が多くなりすぎて事前予測不可能になる(テストしきれない)
オブジェクト指向プログラミングは粒度が最小化可能な物で
それによってアクセスパターンを最小化してバグを発生させ難く出来る
この部分に一番効用が有る
人間の認識限界
これを理解しているかどうかが鍵となる
エドガーダイクストラが言った一番の要点はアクセス範囲の極小化する為に構造化を提唱した
だからcobolみたいにdataなんちゃらーとプロセデュアなんちゃらーみたいに
処理とアクセスする物が分離されている物が一番問題があると指摘した
basicは変数が広域なので問題が有ると指摘した
クラス型オブジェクト指向プログラミングシステムでは
クラス内に変数とその処理をパッケージングしてアクセス範囲を完全に限定した
だからpropery get/set みたいな内部変数を直接外部から操作するような書き方や
それしか出来ないような言語は問題が有るし
問題有りだと騒がれる >>44
try - catch は乱暴な仕組みだよなあ。
下の階層の例外を漏らさず捕獲する。
言い換えると下の階層を信用していない仕組み。
この仕組みのせいでますます適当にプログラミングできるようになったかもしれない。 むしろ逆だろ
適当なプログラミングするやつをカバーするために例外機構ができた >>49
現実に合わせるとそうなるのかねえ
構造化プログラミングは理想に過ぎないのか 入れ子にできるし
扱うフローが正常か異常かの違いかのお >>52
見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと >>54
> 見た目的には構造化されているけど、大域脱出はある意味gotoに近いものがあるかと
脱出でのgotoは検証のしやすさを乱さないからDijkstra本来の構造化プログラミングの精神には反しない（というのを昔、誰かが書いてたように思うが詳しいことは覚えてない）
問題は例えば制御構造（複合文）の内部のラベルに向かって構造の外側からgoto文等のジャンプによって制御を移す（飛び込む）ケース、確かCとかでは許されたのでは
これを許すと検証が非常に面倒になるので構造化プログラミングとしては許し難い暴挙 とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし
検証しようとシグネチャに例外の種類を明記させると大変面倒なことになるしなー
Swiftや、C++の新規格みたいに最近は例外を投げるか投げないかだけを明記するのが流行りっぽい >>58
> とはいえ、関数ポインタ(継承含む)があると例外は検証できなくなるし
関数ポインタが許される言語の検証は例外処理の検証以上に厄介だよ
現実問題として関数ポインタや手続き（関数）の引数・結果値としての手続き（関数）を許す言語の検証は
非常に労力を要することなるので実用的ではないと思うが 複数返り値さえあれば例外なんてほとんど必要ないのに >>構造化プログラミング
今でもCOBOLとPL/1では生きてるぞ >>67
酷いなそれw
フローチャートの書き方と完全に誤解していないか？ >>67
> Wikipedia の構造化プログラミングが I.hidekazu という奴のせいで酷い内容になっている。
・・・
> こいつは構造化定理と構造化プログラミングの区別ができているのか？
>>68
> 酷いなそれw
> フローチャートの書き方と完全に誤解していないか？
というか、このI.hidekazuって奴はDijkstraとMillsとは同一人物だとでも思ってるみたいね（苦笑） >>70
何をネタ元にしたらこんな記事が書けるのか？ >>67
ノートで抗議している人がいるけど聞く耳持つのかねえ？ 加筆前と大して変わってないぞ
図が入って連接・選択・繰り返しがわかりやすくなったくらいだろ
お前らろくに読んでないんじゃないか？ >>75
正しさの検証手法が詳しくなったよね
それ以外はまったく同じ
全部読んだ お前らろくに読みもせずにこのスレのバイアスだけで文句言ってるだろ
池沼どもが >>76
>>77
お前、I.hidekazu本人だろ？とっとと死ねよwww >>74>>76>>77
文頭からして全然異なっている。KMExyDFm の頭はおかしいのか？
https://ja.wikipedia.org/w/index.php?title=%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0&;oldid=69685367
＞ソフトウェアの複雑な制御フローを連接・選択・繰り返しおよびネスティング（nesting）の多層化[1]によって整理しながらプログラミングを行うダイクストラ流段階的詳細化法[2]を言う[3]。
これってノートでも指摘されているように段階的抽象化と段階的詳細化の区別が全然できていない。
＞単純にgoto文を使用しないgoto-lessプログラミングと理解されていることが多い[4][5]。
ここの「理解」を他の人が「誤解」に修正したらI.hidekazuが以下の返信。
＞平成30年8月21日 (火) 14:21 I.hidekazu (会話 | 投稿記録) . . (37,161バイト) (-361) . .
＞(歴史的発展に関する記述を脚注を使って整理した。ほか細かい整理。
＞goto lessプログラミングは十分ではない理解ではあるものの、誤解という強い表現を使うほどではないので理解にさせてください。)
つまりI.hidekazuに言わせると、構造化プログラミングを構造化定理と取り違えても誤解というほどの間違いではないということらしい。
明らかに構造化プログラミングと構造化定理の区別ができていない！ >>80
不十分な理解ということだろ
言ってること間違ってないじゃん
＞単純にgoto文を使用しないgoto-lessプログラミングと理解されていることが多い[4][5]。
この文削除でもいいくらい
誤解という言葉はそれってあなたのただの感想ですよねってことになる
感想文書くところじゃないから理解に修正したんだろ
削除してもいいくらいのクソ情報だよ >>81
お前、I.hidekazu本人じゃないの？ノートに似たようなことを書いているよな。
＞加えて、goto文の論争についてはバッサリ削除してしまっていいと思います。--I.hidekazu（会話） 2012年11月23日 (金)
それと、goto文の話以外は反論できないのか？まあ、できないだろうな。 >>82
それができていないのはあんただろ。
「誤解」が事実であって、「誤解という強い表現を使うほどではない」は完全に感想。 >>80の続き
概要からしておかしい。I.hidekazuは概要のほとんどをフローチャートの説明にしている。
しかし、構造化プログラミングはそういうものではない。
「構造化プログラミングとは何か？」はノートに書いている人の方が正しい。
https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
＞・良く構造化されたプログラム (well-structured programs) → 制御フローのことではない
＞・大きなプログラムの理解を助ける段階的抽象化 (step-wise abstraction) → これの反語が段階的詳細化
＞・抽象データとその操作の抽象文の共同詳細化 (joint refinement) → オブジェクト指向のクラスに似た考え
＞・プログラムの階層化（真珠のネックレスとしてのプログラム） (Programs as necklaces strung from pearls) → 段階的抽象化よりも大きな単位の階層化
＞
＞「連接・選択・繰り返し」については、段階的抽象化の一要素に過ぎないのです。
概要の最後にI.hidekazuはこんなことを書いている。
＞これを解決する手段としてダイクストラが開発技法として導入したのが抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である。
「抽象（abstract）及びフローチャートのネスト」が段階的詳細化って頭沸いているのか？
抽象的な設計から始めて詳細化していくのが段階的詳細化。
コードの一部を括り出して抽象化していくのが段階的抽象化。
I.hidekazuは完全に理解ができていない。 >>83
違うよ、俺は完全に中立な第三者、その俺から見ても
修正前のものは感情的すぎるというか気持ち悪い
執筆者の感情と客観的な事実が混ざってどす黒い色になってる
こんなの書いてるから日本のWikipediaはバカにされるんだよ
>>84
誤解は事実ではないんですよ、みんなは誤解してるんだという思いなんですよ
書いた人間の思いが誤解という言葉には詰まっています
> 誤解という強い表現を使うほどではない」は完全に感想。
これが構造化プログラミングの中に書かれてたらヤバイですよ
でも書かれてないから問題ないんです
執筆者がどういう思いを持っているかを本文に書くべきではありません
あくまで中立に客観的に平等にそして公平に書くべきです >>86
>>85を読んでお前の池沼な頭で反論してみろ。
構造化定理と構造化プログラミングは完全に別物なんだよ！ >>87
そうやって罵詈雑言並べ立てて
相手が悪いかのようにしないと
正当性を主張できないんでしょ？
もうその時点でどうかと思うよ
>>85を読んだけど
I.hidekazuが言ってることが正しいと思った ID:KMExyDFm は、ID:HVFTZtzY が書いていることを理解できていないみたい。
こういう人が来ると疲れるわ。
本質的なことは>>4に書かれているけど、ID:KMExyDFm はこれも理解できないのかなあ？ >>88
>I.hidekazuが言ってることが正しいと思った
その根拠は？ 完全にI.hidekazuに論破されてるじゃん
書き換えて正解だよ >>89
それは全部Wikipediaに書いてあるよ
だから問題ないよね >>90
鬼絡みして相手を疲れさせようって魂胆かな
読めばわかるよね、自明だよ そんなに気に入らないなら自分で修正すれば良いのに
このスレでろくに読みもせずになんとなく間違ってる
雰囲気だから叩いておこうという卑しい心が透けて見えるよ
ほんとくだらない >>89
I.hidekazu本人が来ているだけなので何言っても無駄ですよ。
>>91
意味がわからん。I.hidekazuは誰も論破していない。
まあ、本人だからそういうことにしたいのだろうが。
>>92
書かれていない。Mills がどのようにして構造化プログラミングをダイクストラから奪ったのかが説明不足すぎる。
>>93
>読めばわかるよね、自明だよ
つまり反論できないってことか。 >>95
読解力ないからわからないだけでしょ
100回読み直したら？
> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である
日本語文法わかる？ >>96
お前（I.hidekazu）、本当にアホだな。
段階的詳細化：抽象設計→詳細設計
段階的抽象化：プログラムコード→コードを括り出して抽象化
日本語文法が分かっていないのはお前だ！
だからWikipediaにあんなことを書くのだろうが！ >>97
及びの意味を考えろよ
単語の意味だけ考えて文章のコンテキストを読めてない
文盲って言うのかな、戦後の日本の国語教育の失敗だよね
結論を言うとWikipediaはいまのままでいい
読書感想文のような客観性のない感情論は削除しまくってもいいと思うけどね
消したら消したでアホどもが騒ぐからしかたなく残してるんだろうな
日本語のWikipediaの品質が低いのはそうしたアホなくせに時間だけは
持て余してるオタクどもに配慮しなければいけないからだろ I.hidekazu = ID:KMExyDFm は、ここで敗北すると面子丸つぶれなので必死。
I.hidekazuでGoogle検索するとここが出て来るからなwww >>98
>及びの意味を考えろよ
一［接］《漢文訓読で接続詞に使う「及」の字を「および」と読んだところから》複数の事物・事柄を並列して挙げたり、別の事物・事柄を付け加えて言ったりするのに用いる語。と。ならびに。また。そして。「生徒及び父兄」「国語、数学、及び英語は必修」
[補説]多くの語を並列するときは、最後にくる語との間にだけ置くことが多い。
二［名］及ぶこと。届くこと。
明らかに一の意味だ。
> 抽象（abstract）及びフローチャートのネスト（nest）すなわち段階的詳細化[17]である
つまり、I.hidekazuは「抽象が段階的詳細化に含まれる」と言っているわけだな。
アホじゃん。 ■ このスレッドは過去ログ倉庫に格納されています
