実際に現場ではオブジェクト指向で開発を行う場合は「現実世界」を観察して設計図を描く？

Question

JAVAのオブジェクト指向を勉強・練習している者です。

説明が下手ですいませんが、「スッキリわかるJava入門 第2版 (スッキリシリーズ) 」の（P281）「手続き型プログラミングとの違い」のところを復習を兼ねて読み直しているのですが、

オブジェクト指向で開発を行う場合、プログラマはいきなりコードを書き始めることはしません。まずプログラムで実現しようとする部分の「現実世界」を観察します。例えば銀行振り込みの手続きをプログラム化する際には、それを観察してイメージ図（設計図）を描きます。

と、この書籍には書いておりますが、そもそも、実際に「プログラマはある仕事をプログラムで実現しようとする部分の「現実世界」を観察する」というのは開発現場とかではやるんですか？

この書籍を読んでみると、（オブジェクト指向を）わかりやすいようにあえて例えているみたいな感じで記載されているようにみえます。

つまり、お客さんのほうから「とある仕事をコンピュータ化してほしい」と依頼があったら、いきなりコードは書かず、プログラム化するところを観察してイメージ図（設計図）を描く。ということを現場ではやっているのでしょうか？

なんか私自身勘違いしているように見えますが、プログラム化するところを観察して設計図を描くというのは本当にやっているのでしょうか？

Answer 1

いちいちたとえがわかりにくい本だと思いますが、きっと UML のことを言いたいんだと思います。とくにクラス図とユースケース図のことではないですか？
続きを読めば UML が出てきませんか？
それで終わりですか？

本は通して読むことが大事です。
断片的に読まず、もう少し先、少なくとも結論まで読んでください。

Comments

[Zuishin]

別の言い方をすると、「人の言うことは最後まで聞きましょう」

Answer 2

こんにちは。

お客さんのほうから「とある仕事をコンピュータ化してほしい」と依頼があったら、いきなりコードは書かず、プログラム化するところを観察してイメージ図（設計図）を描く。ということを現場ではやっているのでしょうか？

まず、プログラムを作る前に、どんなプログラムを作るのか明確にする必要がありますね？ 曖昧なままだと作っている内に仕様を変えてしまって、いつまでたっても完成しないのが落ちですから。趣味プログラムでは時としてあると思います。
しかし、業務で開発する時にそれは許されません。発注元も受注先も悲惨なことになります。（残念ながら偶に聞きますが．．．）

現在、手でやっている業務の工数削減や時間短縮のためにコンピュータ・プログラム化するケースが結構多いです。その際、どのような手順で作業しているのか、現実世界を観察した上で、どのようなプログラムを開発すればその業務を効率化できるのか検討し、プログラムの仕様を明確化します。

この手順を省略したり、いい加減にしたりした時、冒頭の「残念ながら偶に聞きますが．．．」と言う結果が待っています。許されないことです。

Answer 3

お客さんのほうから「とある仕事をコンピュータ化してほしい」と依頼があったら、いきなりコードは書かず、プログラム化するところを観察してイメージ図（設計図）を描く。ということを現場ではやっているのでしょうか？

やっています。設計図をUMLで書いているとは限りませんが。

そもそも、いきなりコードが書けるような簡単なもの(例えば、今読んでいる書籍に記載されているサンプルコードのようなもの)は仕事として依頼がきたりはしません。

お客さんからは難しく、複雑な現実の仕事を効率化したい、しかも曖昧な内容で依頼がされるので、まずは現実をよく観察して、理解して初めてコードが書けるのです。