設計について

質問

プログラム作成を他人に依頼できるように設計書を作りたいのですが、書き方がわかりません。その設計書があれば誰がコーディングしても同様のものができるような設計書を作りたいです。
そこで、ソフトウェアの設計の入門書で良書はありませんか？SE関係の本を書店で読んだところ、それらは依頼者からの要求を仕様書に落とし込むような技術を説明しているような本でした。そういったものでなく作るものが決定していて、それを作る際の指針となるデータ構造やGUI設計といったものの参考となる書類の作成をしたいです。
一般論でお願いします。

回答No.5

MrBan · ベストアンサー

#2です。
すみません。リンクがおかしいですね。順に以下です。

「改訂版 組込みソフトウェア向け開発プロセスガイド」
「実践UML―パターンによるオブジェクト指向開発ガイド」
「UMLコンポーネント設計―コンポーネントベースソフトウェアのための開発プロセス」

お礼

やはりUMLがコーディング規約を記す上で最も強力なツールの１つなんですね
紹介いただいた書籍を早速読んでみたいと思います
ありがとうございました

回答No.6

lv4u

>>私がリーダとなり他のメンバーにプログラム（各関数やメソッドなど）の使用を支持(指示)するときに用いる設計書を書くと考えてもらってもいいです。
そこからそのソースコードを公開して誰でも拡張、改造できるようにするためのリファレンスのようなものを作れればなおよいです。

感覚的には、質問者さんの望まれるようなものは現状では、「無いものねだり」「存在しない」と思えます。

回答No.4

MrBan

#2です。
業務でもない限り昨今「そんな詳細な仕様書を予め書くか？」と思うだけで、回答自体は設計一般の話として書いてます。

結局、相手には判断材料のない部品の作成を依頼するならほぼソースコードと同等な日本語資料を提示する以外になく、
そうでないならば、システムの概要から理解させて誤解を少しでも排除するしかない、ということはよろしいですか。

「明示的に示していないことが同じ理解になるとは限りませんし、　複数の意味に取れることはどちらに取られるか分かりません」

仕様書とはつまり、「その規定範囲で」一意に何かを規定する文書ですので、
仕様漏れや曖昧なもの、また誤解させやすいものはその時点で作り手に依存します。

「完全」を目指すならば当然「全て」を記載するしかないわけです。
但し、普通はそこまでは不要、むしろ「ブラックボックス」にして気にしなくていいようにします。
よくできた仕様は「必要十分の約束事」だけが規定されています。

> どのダイアグラムをどの場合に使用すべきかというのが今ひとつわかりません。

補足を拝見する限り、あまりシステム設計とかには力をおいていないような印象を受けていますが、どの次元を求められているのかよくわかりません。
あなたが逆の立場で依頼されるなら、どんな情報が必要ですか。
システムを仕様化して、ソフトウェアを仕様化して、部品を仕様化して…と下っていくわけですが、全部ですか？
もしそうであれば、(タイミングチャート以外?は)ほぼ全部の図が必要かと。

> 実際はクラス図＋αがあればコーディングだけはできるでしょうが、

全体像を多角的に表現して初めて一意に伝わるのであって、実装レベルでも局所的な静的構造だけでおなじになるとは限りません。
書き手の理解によって動作が合わないことも実際ありますので、目的に合致するには、振る舞いや状態も規定するなど＋α部分が重要です。

> 私がリーダとなり他のメンバーにプログラム（各関数やメソッドなど）の
> 使用を支持するときに用いる設計書を書くと考えてもらってもいいです。

誰が書いても同じように「使い方を直接指示する」のであれば、「プログラム詳細仕様書」を書いてください。
日本語でソースをそのまま書くようなイメージです。もしくは、擬似ソースコードでサンプル提示してもいいです。

「誰が書いても同じように使われるようなプログラムを提供したい」なら、
まず「他の使い方ができないように設計する」のが設計のセオリーです。
その上で、「インタフェース仕様」として「制約」や「契約」等を明記してください。サンプルコードを提示するとなお効果的です。
(Doxygen等で生成できるようにヘッダ/インタフェースを実装するのもいいと思います)

> そこからそのソースコードを公開して誰でも拡張、
> 改造できるようにするためのリファレンスのようなものを作れればなおよいです。

また、使うだけなら仕様書(インタフェースを一意に規定)でいいのですが、
ソースの改造などまでしたいということであれば、ちゃんと設計書を用意してください。
利用するだけの人間には通常不要でも直そうとした時に影響範囲などを特定するにたる情報、
それを設計するに際して検討した代案や外部制約、要件などの追跡性を確保する必要があります。
また、ユニットテストなど検査項目も予め用意しておくといいでしょう。

■手持ち書籍より

設計書の一般的な分類、書式などは以下を紹介しておきます。
http://www.amazon.co.jp/組込みソフトウェア向け開発プロセスガイド-BOOKS-独立行政法人-情報処理推進機構-ソフトウェア・エンジニアリング・センター/dp/4798115630/ref=sr_1_1?ie=UTF8&s=books&qid=1241553856&sr=1-1

UMLで設計よりの本だと、例えばこのあたりとか。
http://www.amazon.co.jp/実践UML―パターンによるオブジェクト指向開発ガイド-クレーグ-ラーマン/dp/4894710773/ref=tag_dpp_lp_edpp_img_ex
http://www.amazon.co.jp/UMLコンポーネント設計―コンポーネントベースソフトウェアのための開発プロセス-コンポーネントソフトウェアシリーズ-ジョン-チーズマン/dp/489471387X

回答No.3

tsuduki999

たまにある、設計する会社で詳細設計まで書いて
コーダの会社に、コーディングと内結までをお願い(委託)するようなケースなのですかね？

その場合、#2 の方がいうように、
すべてを日本語でコーディングしてあげないとだめです。

逆に言えば、コーダの人は、書かれたとおりにしか記述しませんので、
詳細設計を記述する段階ですべてを検討しておかなければなりません。
# たとえば、関数とか、分岐とか、同期部分とか
# その設計書は「業務指示書」にあたるので書いてないことは
# 不都合に気がついても普通に無視されます。

きっと本はないんじゃないかな？
普通は、概要や機能詳細まで書いて、以降はよろしく～というパターンが多いと思うので。。。

一般論でいえば、
設計書の書式に従って、自分で日本語のコーディングをしてくださいで
FAではないでしょうか。

補足

>たまにある、設計する会社で詳細設計まで書いて
>コーダの会社に、コーディングと内結までをお願い(委託)するようなケースなのですかね？

#2の補足でも書きましたが違います。
仮に私が友人数人と趣味でゲームを作るとして、私がリーダとなり他のメンバーにプログラム（各関数やメソッドなど）の使用を支持するときに用いる設計書を書くと考えてもらってもいいです。そこからそのソースコードを公開して誰でも拡張、改造できるようにするためのリファレンスのようなものを作れればなおよいです。

本がなければWEBページでもかまいません。よろしくお願いします。

回答No.2

MrBan

まず、まともなプログラマ=製造の専門家に対して作成を依頼するのであれば、
製造の詳細については専門家に任せて要求する仕様だけを決めた方が大抵よいものができます。餅は餅屋です。
(「専門家」でない人/会社に依頼すると大抵痛い目を見ますのでそもそもお勧めしません)

故に、書籍は要件定義等の「お願いするための情報整理」に焦点が当たります。
つまり、「外観上の動作」について仕様を決めて、後は任せるわけです(任せられる人に頼むわけです)。
# データ構造が素人考えではないか？最適解か？などは専門家の方が精通しているのが普通です。

そういったレベルを逸脱して、本当にソースレベル等の詳細まで
「その設計書があれば誰がコーディングしても同様のものができるような設計書」を作る時間を掛けると、
結局「製図用紙に製品全体の精密図面が引く作業を全部やる」ということですから、
プログラム製造の場合、(試験等は別にして)自分で製造できてしまったりすることもままあります。
# 業務保守等を考えなくていいものなら、自分で書いた方が多分早いです。

これがお望みであれば、日本語でソースコード全部書いてるのと大差ない詳細な処理動作を全て記述してください。
それで、誰が「翻訳」してもほぼ同様なソースになります。
# 「プログラム詳細仕様」の作成は実質プログラミング(の一部)ですので、
# 自分でもソース自体を書こうと思えば書ける人しかまともなものは作れません。プログラミングの本で学んでください。

もしくは、例えば「(MDAを視野に)UMLで書く」のはいかがでしょうか。
http://www.amazon.co.jp/MDA-モデル駆動アーキテクチャ-David-S-Frankel/dp/4434038133
とりあえず「機械でもソースに翻訳できる」くらい詳細に仕様を表現すれば、
おそらく(UMLが読めるプログラマなら)誰に頼んでもほぼ同様なものができます。

そこまででなくてもよく、本当にデータ構造やGUIなどだけに限って口を出したいなら、
「データ構造定義図」や「画面仕様書」等を調べて見てください。
但し、「設計に部分的に口を出す」とそこがシステムのネックにもなりやすいので、
実装上で調整の余地を残しておく方がよいかもしれず。
設計者自身にそれなりの実装経験等がないと
「誰がコーディングしても同様に」するのは難しいかと思います。

補足

回答ありがとうございます

回答を拝見したところ、業務内容をIT化する依頼を私がベンダやソリューション提供会社にしようとしている、ビジネスシーンを想定されているのではないでしょうか？
しかし、質問の際にも言いましたように一般論での回答をお願いしたいです。

また、UMLについて言及されていますが、UMLの個々のダイアグラムはだいたい理解しています。しかし、実際にそれらを使用したことがないので、どのダイアグラムをどの場合に使用すべきかというのが今ひとつわかりません。前述したように個々のダイアグラムについてはそれなりにわかるので、逆に完成したソースコードからクラス図を作ったり、利用シーンを想定してユースケース図を作成するといった学校の課題みたいなものはできるでしょう。

ともかくUMLに限らず、当初の質問のように「誰がコーディングしても同様に」を実現できる文書作成術が学べる書籍なり資料を教えてください。実際はクラス図＋αがあればコーディングだけはできるでしょうが、それ以上の、ビジネススキルとして役立つ知識が身につくなどあればなおよいです。例えばコーディングとは直接関係のないソフトウェアの運用手順書なんかですね。

どうぞよろしくおねがいします。

回答No.1

中京区 桑原町（@l4330）

IPO・・・Input、Process、Output、これを明確にすれば書式は問いません。
人や機械から入力された物を、どの様に処理して、どんな結果を出すのか
これを明確にすれば仕様書作りやプログラムは専門家が作ってくれます。
例
Input・・・「か」の文字と「変換」キーの入力
Process・・・「か」で始まる1文字の漢字とその意味を探し出しす
Output・・・探し出した漢字を縦一列に意味をその横に表示する

補足

仕様書も自分で作りたいのですが