設計図・表はいつ(when)書くか、何を(what)書くか、どうやって(how)書くか
いつ・何時(when)
設計者であれば、仕事をはじめたり、計画する最初から設計図・表を書いてもよい。
何を(what)
設計図・表
計画書と設計書を兼ねるのであれば、計画言語(programming language)で書くとよい。
字下げ(tab)や空白、などにより、文字でも構造的に書いて図表と同じようにすることができる。
計画言語(programming language) で書いたものをソフトウェアが図表を自動生成してもよい。
図表から計画言語(programming language) を自動生成してもよい。
利用事例(use case)図・表
顧客がどのように系(system)を利用するかの事例を記述する。
会社であれば、社長の顔写真を貼っておくと効果的だという経験則がある。
設計図・表
ソフトウェアで設計図といえば、状態遷移図・表が真っ先に思い当たる。
状態遷移図から書いて、状態遷移表を自動生成して抜け漏れを探してもよい。
状態遷移表から書いて、状態遷移図を自動生成してもよい。
設計者が最初から書くのであれば、状態遷移表からをお勧めする。
ソフトウェアで設計書といえば、プログラムのソースコード。
設計図・表は、ソースコードよりも抽象的な表現だと嬉しい。
３０年くらい前に、通信ソフトウェアを時系列図(sequence chart)だけで書いていた時に、不具合が取れず、システムの状態を管理しないといけないことに気がついた。
時系列図から状態遷移図を作成するのは、通信規約の専門家であれば難しくない。
OS, DBの専門家でも同様だと推測する。
技能
時系列図から状態遷移図・表を書けない人がいるという話を小耳に挟んだ。
一つの時系列図からは、状態遷移図・表はいろいろ思い当たるかもしれない。
３つ以上の時系列図や、１０個以上の異常処理があれば、それなりの状態遷移図・表は書けないものだろうか。
構造設計をしたことがないと無理らしい。
基本技術の水準で設計の手法、仕組み、変化の種類が思いつけば、今回はどの設計にするかを図示できるはずなのだが。
連続系
離散系であれば状態遷移図・表だが、連続系だと状態方程式で管理するかもしれない。
状態方程式の構造を図で書くことがある。状態方程式はパラメータの表として管理することもできる。
図は設計の再利用と、変更点の明確化。
簡単な構造のプログラムであれば、想定している設計図は頭の中にあり、いきなりコードを書くこともできる。
想定している設計図が同じものしか使ったことがない人の集まりでは、設計図は出力することなく作業が済むかもしれない。
設計する人だけでなく、ソフトウェアを利用する人の意見を聞くときには、図を使って分析するとよい。
抽象的な図や、具体的な図の両方使うとよいかもしれない。
具体的なことばかり聴いていると、抽象的な次元で矛盾することを言われていることに気がつかず、プログラムがぐだぐだになっていくことがあるかもしれない。
状態遷移図・表
状態遷移図と状態遷移表は相互変換が可能である。
UMLの規格化の際にも、図形式か表形式かについては日本からの意見だと記憶している。
# 参考資料
ソースコードは設計書であり、コーディングは設計作業である
https://qiita.com/mdstoy/items/5510f94c9ed981cfbb85
Webページの高速化の為に画像周りでやったこと
https://qiita.com/mitani/items/727dbb1276cc0ba49ec4
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20190215 午後4時
ver. 0.02 みだし追加 20190215 午後５時
ver. 0.03 UML追記 20190215 午後6時
ver. 0.04 表題変更 20190218
ver. 0.05 利用事例 会社であれば、社長の顔写真を貼っておくと効果的だという経験則がある。 追記 20190224
ver. 0.06 参考資料追記 20190526
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.