スレッドメモ

◆ [oosquare-ml] 設計と実装 (was [ 募集 ] 分析・設計の勉強会 )

[03926] HAMAI Kyoichi (11/4)

まず、設計とは何か、実装とは何か、が問題なのだと思います。私の認識では、設計とは「（動作）モデルの構築」であり、実装とは「コードの記述」です。

モデルを構築しても、その内容を伝えなければ他人にとってはモデルを構築していないのと同じですから、その内容を伝えるためにモデルを何らかの方法で記述する必要があります。その際、多くの場合において、ソースコードとして直接記述した方が良い。と私は思っています。

[03931] Nakajima Katsuyuki (11/15)

そんなことしたら、みんな設計書なんて作らなくなっちゃいませんか。それとも、設計書がいらない開発に限定した話でしょうか。

通常の開発では、内部設計はともかく外部設計の文書化は必要です。

これによってコミュニケーションギャップが問題になるというのであれば、文書標 準の導入やレビューの実施により解決します。 同期が気になるというなら、コードの「FDD」なんてお奨めです。

[03936] HAMAI Kyoichi (11/21)

設計書って本当に必要でしょうか？ 多くのオープンソースでの開発では、設計書は作られていないように思えます。 ユーザーマニュアルなどは必要かもしれませんが、これは設計書とは言えない でしょう。

[03944] Satoshi Sawada (11/27)

オブジェクトの広場らしい議論をしましょうよ。(^^)

> 外部設計書：作成するものの機能について記述した設計書
> 　　　　　　システム構造・実装方法・プログラミングについてはふれない
> 　　　　　（ユーザ用マニュアルに対応する設計書：機能仕様書？）

配置図・コンポーネント図・ユースケース図
分析モデル

> 内部設計書：プログラム内容に特化した設計書
> 　　　　　　実現方法、クラスの関連や仕様、処理方法などを記述

クラス図・相互作用図・ステートチャートなど。
設計モデル・実装モデル

って感じでしょか？

[03946] Satoshi Sawada (11/27)

> 上記でいえば外部設計書一式と設計モデル、ステートチャート図は省略不可
> じゃないですかね。

外部仕様書の目的にもよると思います。 でも最低限のユースケース図だけは必須だと思います。 ユースケースがないと何を実現するのかわからない。

それと、ソフトウェアのアーキテクチャをソースコードから読み取るのは 非常に困難でしょう。ソースコードを見ても、木を見て森を見ず、です。

アーキテクチャは、ユースケースと同じレベルで誰もが必要な情報だ と思います。

[03959] hiroki kugimoto (12/5)

外部設計書は要らないとおっしゃる方は、議論以前の問題と考えます。 たぶん、

１．しかりとしたビジネス用のアプリケーションソフトウェアを作ったのことが

ないか、

２．設計＝内部設計との我流の理解に凝り固まっている

のでしょう。

例えば「帳票を決めるのは要件定義」とか不思議な意見を出しそうに思います。 頼むからちゃんと勉強し直して下さいお願いします、というか。

[03981] HAMAI Kyoichi (12/10)

簡単に言えば、「（ソース以外の）ドキュメントを強制するな」ということ であって、「ドキュメントを書くな」ということではありません。

契約でドキュメントが必須な場合も、開発が事実上終了してからソースから ドキュメントを起こせばいいように思います。

ソースとドキュメントとの二重管理は、注意力や労力を浪費させます。 データベースの設計などでも、矛盾や修正もれを引き起こしやすい二重管理 にならないようにするのが原則です。ソースとドキュメントとの一元化は、 Knuthの文芸的プログラミングなど、ずっと以前から提唱されてきました。

[03983] hiroki kugimoto (12/10)

設計書が要らないとか後でプログラムから起せばよいとか考える方、あなたは、 少なくとも問題意識を持つという点では、ちゃんと勉強をすれば、何も考えない 人よりももっと素晴らしいエンジニアになれる可能性を秘めていると思います。 ただしあなたは今間違いなく視点が狭いです。今のうちに正しく勉強し直してく ださい。

[03985] Eiji Yamane (12/11)

気分を害す可能性がある方は削除でゴー。

あっ、先にいっときますが、自称アジャイラ−だから、 徹頭徹尾「不要な文書は悪」というのが個人的見解です。

設計書がないとPDCAができないのですね？

P-計画ゲーム/イテレーションプランニング
D-イテレーション
C-受入れ試験
A-次計画ゲーム/イテレーション（ついでにリファクタリング）

どこにも、コードレベルの設計書いらないんですが、、、

あっ、ちなみに最終イテレーションでドキュメントは書きましたよ。一応。
　・概念モデル
　・フレームワークアーキテクチャ図
　・保守指針
　・ER
　・テーブルレイアウト
＃までは、次フェーズとか引継ぎにも使えました。
　・画面仕様書
　・Javadoc
は、ドキュメント書く時以外誰も開いてなかったな。（爆）

[03986] Kazuya Maebashi (12/11)

問題は、どんな文書が悪で、どんな文書が必要か、ということです。

>３．コードは何をしているかはそれで分かるが、それがなんのために、というの
>はわからない。

重要です。それに、コードは何をしているかはわかるが、それがバグっていたら、 「何が正解か」がわからなくなってしまう。
# いやまあできるだけDesign by Contract的にすべきかとは思いますが、
# 完全にできるわけじゃなし。

>４．いきなりコードにはいる前に概要設計とか方針設計みたいのがあるのでは？
>それは文書として残しとかなくてよいの？

「概要設計とか方針設計みたいの」の方が抽象度が高いので、 コードよりは手っ取り早く全体を把握できますよね。 それに、最終的にコードを読むとしても、「どこから読み始めるべきか」 という情報を与えるだけでも重要です。

>５．人間は言語（＝文書やコード）（左脳）だけでなく、図（右脳）をうまく活
>用して考えたほうがよい（２の補足）

コメントでは図がかけませんよね。javadocならがんばれば可能だけど、 手間を考えるとあんまり実用的じゃないような。

[03988] hiroki kugimoto (12/11)

> また、設計書は設計の結果であって、保守などの目的でプログラムに用がある
> 時以外に必要無いものだと思っていたのですが、そうでないなら開発設計以外
> に設計書に含まれる目的や意味は何なのでしょうか？

設計書の目的や意味ですが、設計書は「プロセスをトレースできる資料になる」 ことが重要で、その結果色んな役割を果たすのだろうと思います。

設計書を作るべき、というのはすなわち、この例で言いたい事を強調してみれば
「失敗しないための方法」
です。

[04004] Hirohide Yazaki (12/11)

１つのメソッド内の、あるいはそれより多少広い範囲の意図であればソースコー ドのメソッド名や変数名、ロジックの書き方等で表現できると思います（リファ クタリングの大半がそのためにありますよね）。ただし複数のクラス間の関係や コラボレーションの意図とか、全体の方針（意図という言葉では少し違和感があ るので）のようなものをソースコードだけで表現できるのでしょうか、私はでき ないと思います。あるいはそれが、なんとかできるとしてもソースコードで表す ことが最適な方法なのでしょうか？

[04006] 寺田 英雄 (12/11)

少なくとも、組込みシステムや、リアルタイム制御システム、デバイス ドライバ開発において、「（外部／内部）設計書は不要です。」 などといったら失笑を買うだけです。 プロならばそういう仕事の仕方はありえないからです。

上記のようなシステムでは、タスク分割、動作タイミング（時間制約）、 メモリ配置、割り込みの使い方、リソース競合の回避法、エラー処理方法等々、 さまざまな角度から十分に検討を加えて最終設計に到達します。 ホワイトボードに簡単な図を書いて、「とりあえず」コーディングを 始められるような代物ではありません。

[04026] Nakajima Katsuyuki (12/13)

皆さん、「設計書が不要」ではなく「酷い設計書が不要」という見解は、ほぼ一致し ていますね。

[04028] Eiji Yamane (12/13)

一致していません。
＃少なくとも私は。

一致しているのは、いかなるスキルの人に対してもミスリーティングを 誘発しないドキュメントはどんな技術者をもってしても困難であり、 そんな困難なものと如何に付き合っていけばよいかと議論し、 前向きに検討していかなければいけないと言う心持だけだと思います。

そして、そんな状況にあるにも関わらず全ての作業をドキュメント前提で 行うのはいかがなものかと言うことだと思います。

[04031] Satoshi Sawada (12/15)

そして、そこを狙ったとすると、仕様書作成にかけるべき適正なコストはかなり小さくなるのではないかと思います。では、何を書けばいいのかと言うと、前から主張しているとおり、ユースケースとアーキテクチャであり、もう少し書いたとしても、分析レベルのモデリングくらいじゃないか、と思います。

その後は、コーディングしてみなきゃ分からない。コーディングの過程で必要になったときに関係者を集め、ホワイトボードを前に設計を議論して解決すればいいのです。