【中級】今から取り組むUML入門 第2回 UML図の読み方と書き方
UMLには(1)システムの静的な側面を示す図，(2)システムの動きを説明する図，(3)システムの構成などを説明する図があり，システムをさまざまな視点から分析し，その結果を図示することができる。今回は，クラス図，ユース・ケース図，ステート・チャート図などのUMLの全図の表記法を説明する。説明するのは図記号や矢印の意味などの表記上のルールで，難しい理屈は無い。限られたページ数で細かい表記ルールまでは説明できないが，簡単な図を読んだり書いたりするには今回説明したことだけで十分である。 システム設計書やプログラム設計書の表記法として有効なUML（Unified Modeling Language）＊を初心者向けに解説するセミナーの第2回である。前回は，UMLの基盤であるオブジェクト指向＊の考え方と，それがUMLの9種類の図で表記できることを説明した。今回は，それぞれの図の役割と基本的な書き方を説明
プログラム設計書とは何か? ドキュメントには何を書くべきか? - K.Maebashi's はてなブログ
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - yvsu pron. yas その「プログラム設計書」が何を指してるのかわからないから土壇場で混乱する - @katzchang.contexts 下のリンクより： *1：「ほとんどプログラムと対応するようなロジックが記述されているようなもの」と言われても、俺としては「よくわからない、見せてほしい」と聞きたいところです。 ひがさんの趣旨と合っているかはわかりませんが、たとえば私が開発中*1のプログラミング言語Diksamのコンパイラには、以下のような関数があります。関数の引数の型チェックのための関数です。 http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/11.html#68 dkc_compare_parameter(ParameterList *p
意図が伝わる設計書作成の心得【第4回】
「仕様書」は，設計者とプログラマをつなぐ重要なコミュニケーション・ツールだ。それゆえ，安易な書き方をすると問題を起こす。よく議論されるのは，「仕様書の内容はどこまで詳しく書くのが適当か？」という点だろう。過剰品質を避け，効率的に書きたいところだが，きちんと意図が伝わることが大前提である。二つの実例を通して，そのキー・ポイントを紹介する。 今回から，題材を「仕様書」に移して設計書作成の心得を紹介していこう。 前回までは，ユーザーからの要望聴取を基に作成する基本設計書を題材として，設計者とユーザーとのコミュニケーションを軸に展開してきた。これに対し，今回から取り上げる「仕様書」は，基本設計書を基にシステムを実装するプログラマやSEに対して，より具体的なシステムの詳細を伝える設計書である（図1）。 このような設計書は「詳細設計書」や「プログラム仕様書」など，様々な名前で呼ばれていることと思う。ま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
