スレッドメモ

◆ [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)

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

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

◆ [fj][fj.news.policy] [1stannouce] fj.*第10期管理委員会委員選出投票のお知らせ

<bpdj2k$o6$1@cala.muzik.gr.jp> 笠原　励 (11/19)

fj ではニュースグループの作成/削除/憲章変更等を NGMP と呼ばれる手続き に従って行います. この手続きに従ったニュースグループ管理の実施のために, NGMP では「fj ニュースグループ管理委員会」と呼ばれる組織を選挙によって選 出することとしています.

投票期間は 11/19(水) 〜 12/9(火) の3週間です.fjに参加されている皆様の, 積極的な投票をお願い致します.

<bpf5jc$1mptkq$1@ID-37799.news.uni-berlin.de> shuji matsuda (11/19)

得体の知れないサーバーにアクセスしたくない人の為に、投票用紙を投稿してもらえませんか？

この、『webアクセスが無い人をニュースでの投票から排除する』という今回の選管の方針は非常に問題があると思う。

<20031119231316.814041.446533810@uranus.interq.or.jp> 笠原　励 (11/19)

前半部は随分な言いぐさですね。

後半部については、なぜPre announceを投稿した段階で言っていただけなかったのですか？

<3989221news.pl@insigna.ie.u-ryukyu.ac.jp> Shinji KONO (11/27)

だんだん複雑になっていくなぁ... なんとなく、

　　netnews の投票なんだから netnews への投稿で行う

って方がいいような気がする。で、それができないんだったら、メディアとして完全ではないってことなんでしょうね。

<20031127013359.5880680.-706032120@uranus.interq.or.jp> 笠原　励 (11/27)

上記の件に関して、選管として回答します。

「fjvvに関してはスクリプトの権利者の使用許諾が取れなかった。そのため、システムを新規作成することになったが、システムを熟考する余裕が足らず、今回のようなシステムになった」

ということです。

<bq3skg$1urhi8$4@ID-37799.news.uni-berlin.de> shuji matsuda (11/27)

スクリプトを書いたのは、沼田さん、木津さん、そして私です。『権利者』って誰のことなんでしょう？

<bq53tl$jlt$1@news-est.ocn.ad.jp> Noboru SAITO (11/28)

とまあ長々と書いてみましたが、個人的には普通にこういうシステムをさくっと立ち上げられるということは「すげー」と思ってしまうわけですが。

<20031129005944.4596018.248321944@uranus.interq.or.jp> 笠原　励 (11/29)

選挙に関しての意見・問い合わせは、まず選管（個人、全体どちらでも可）にお願いします。選挙に関しては、最初に選管に聞いていただきたいからです。

fj.news.policy（を始めとした各グループ）でアナウンス記事へのフォローの場合、アナウンス記事を読まなかったり、充分に読んでいないと、フォローの内容がおかしくなることが有り得ます。。

そのようなフォロー記事にフォローをして、スレッドが形成されると、話がヘンな方向に行ってしまう場合もあります。

<br4ihg$27sb92$1@ID-37799.news.uni-berlin.de> shuji matsuda (12/9)

今回の選管（笠原励、厨子直人、中村孝広）は、私の記憶する限り、

　　投票用紙をニュース配付しなかった初めての選管

ですが、最後まで一貫する独善的なやり方はあっぱれと言うべきでしょう。

<br4raf$k1j@utogw.gssm.otsuka.tsukuba.ac.jp> kuno (12/10)

空メールで投票用紙が取れるんなら別によさそうに思えたんですけど、何が悪いというご主張なのか説明していただけません?

<031210122542.M03343892@ims.ipc.kit.ac.jp> Tsukamoto Chiaki (12/10)

少なくとも一回 e-mail を送る手間が増えたことは確かですね.

<br9uhn$10nk8$2@ID-37799.news.uni-berlin.de> shuji matsuda (12/11)

fjvvの場合は、

投票管理の政治責任はとらないが、投票の信頼性に関しては可能な限りの情報を公開するので、各自御検討の程を、

という立場です。もちろん、実際に投票のログ（一万行近い）を取得している人もいますし、確認状況も皆、普通に取得していました。それだけの情報を得て、文句を言った人は一人もいませんでしたね。

<br9ur6$1bl1@utogw.gssm.otsuka.tsukuba.ac.jp> kuno (12/11)

自慢話ですか ^_^; 久野

P.S. いや、fjvvスクリプトはよくできてると思いますよ。一方であそこまでしなけりゃいけないのかという気分にさせられるという欠点があるというか ^_^;;

<br9vsm$v9s9$1@ID-37799.news.uni-berlin.de> shuji matsuda (12/11)

この話は、結局、どこまで投票者の負担を許容するのか、ということにもなります。投票行為に負担をいくらかけてもよいというのなら、それこそ、私の端末まで来て、投票せよ、と言ってもよい訳です。私は、電子メールアドレスの到達性を確保することはギリギリ許容されるという意見です。論理的限界は先の一往復半です。今回の様にその負担をあげると、投票する人、得にNOを投票する人が減るでしょう。実際、河野さんなんか、もっとNOの嵐が来ないとおかしい（笑）。

<bra0kl$1cic@utogw.gssm.otsuka.tsukuba.ac.jp> kuno (12/11)

それはさておき。私は、現在「選管やる人手をあげてください」といって手をあげてくれた人がやったものがfjの選挙である、それ以外に道はないと思っています。

<031212124200.M01344968@ims.ipc.kit.ac.jp> Tsukamoto Chiaki (12/12)

> 　選管としてはNGMPに即して、活動を行いますが、分を超えたものについては、
> 判断しかねる部分もありますので、あらかじめご了承ください。

NGMP には大したことは書いてありません. 選管に要求されているのは首の上に載っているものをちゃんと使うことです. まあ, 貴方にとっては分を超えているかも知れない.

<brlroh$4qkia$1@ID-37799.news.uni-berlin.de> shuji matsuda (12/16)

この度の選管の広報は、『選管として』以下の様に放言しております。 それに対して、『権利者』とは誰のことを指すのか？という私の質問に対しては だんまりを決め込んでいます。何を隠しているのだろうか。

<brls8f$j8u@utogw.gssm.otsuka.tsukuba.ac.jp> kuno (12/16)

昨年も選管の中で騒ぎになったりしたので。この際fjvvのスクリプ トを公開するとかどうですか? 権利関係については私はよく知らないん ですが最初の作者が松田さんなんで松田さんが作った時点の状態で公開 するとか。

◆ [fj][fj.comp.lang.c] typedefと関数ポインタ

<20031122173333.F99C.INGRAM@os.rim.or.jp> Hyu-ga Hiroya (11/22)

int (*fp)(int);

と記述すると
intを1つ引数にもち、intを返す関数のポインタ変数fpを
宣言することになりますが、

typedef int (*fp)(int);

と記述すると、
intを1つ引数にもち、intを返す関数のポインタ型名「fp」
を作成することになります。

このtypedefの使用例は構文例外なのでしょうか。決り文句だと考えていればいいとは思うのですが。

<YAS.03Nov24155804@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (11/24)

はい。Ｃ言語を使っている人でも、なかなか気が付かない所ですよ ね。ひゅうがさんの記事をみて、ああそういうことだったのかと思っ た人もたくさんあると思います。私も typedef の話をする時には、 「まず変数宣言をするふりをして、頭に typedef を付けると型に なる」と説明しています。

<3989209news.pl@insigna.ie.u-ryukyu.ac.jp> Shinji KONO (11/25)

なんとなく、

> typedefの使い方としては、
> typedef 型名 新型名;
> というのがまず基本にあると思います。

って考えたくなるけど、違うんだよね。

   typedef 定義式

ですよね。

<YAS.03Nov28041505@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (11/28)

あと、cdecl というプログラムがあって、英語で説明してくれます。