@kazuo_reve 嗅いだことありますか？不吉な臭い（仕様スメル・制約スメル・設計スメル・コードスメル）
を拝見sじた。思い当たることが多い『設計』について記録する。
設計スメル
設計スメルは設計書から検知できる臭いとする。
設計図がシーケンス図のみ
状態はあるが状態遷移表なし
特殊な状態あり
データの生存期間の定義なし
複数のレイヤで同様の状態を保持
#1 「設計図がシーケンス図のみ」
時系列の変化(sequence chart)の背景に、どういう状態があり、その状態遷移の一つの結果を記録しただけ。
他の時系列に対する対応が取れているかどうかわからないかもしれない。
個々の時系列に対応するよりも、状態遷移を管理すれば、簡単なプログラムで対応できるかもしれない。経験上95%くらいがこちら。
残りの内の4%は状態が分からない場合。状態が非公開のシステムなど。
残りの１％の事例は、例えばsequence chartが、256枚あり、どう考えても、状態の遷移の種類が256以下。
あるいは、状態の遷移の種類は数十以下で、そのうちの例外の種類によって256通りの可能性がある場合など、網羅できていることが確認取れればいい。
シーケンス図のみが、絶対駄目だという訳ではない。
安全分析をするのであれば、刻時図(timing chart)がないと話にならないし、
立場によっていろいろだろう。
1%くらいの場合は、シーケンス図のみ網羅できている場合がある。
なぜって、私、状態遷移はかけないけど、時系列図は好きで書いていて、全部状態遷移を網羅しちゃったということがあるから。
Uppaalを初めて知った時、おお、自分が手作業でやっていたことが、
自動でできるんだと驚いた記憶がある。
状態遷移から描くようにすればよかったと暫し反省した。
2 「状態はあるが状態遷移表なし」
状態の網羅性を確認するために、業界によっては状態遷移表を書く習慣がある。
状態の数が、４つ以上なら、確実に状態遷移表を描いた方がいいと思う。
状態の数が、３つだと悩む。表があった方が見通しはいい。ツールが自動で変換できないものを使っている場合には、まずツールの導入を勧めるか、
状態遷移図から状態遷移表を作成するツールを作ることを勧める。
ZIPC
をはじめ、状態遷移図を描く道具では、状態遷移図から状態遷移表を簡単に生成できるものがある。
UMLでも、2.4.1では、状態遷移表に関する言及がある。
E.2 Tabular Notation for Other Behavioral Diagrams
The approach for defining tabular notation for sequence diagrams should also be applicable to other major behavioral diagram types, such as state machine diagrams and activity diagrams.
なぜか2.5.1 では記述がない。
連続な状態
ここまでは、UMLなどで扱う離散な状態の話。
連続な状態は状態方程式で記述する。状態遷移表はない。
状態方程式は例えば、連立微分方程式で記述することがある。
連立微分方程式のPade近似と、Cコンパイラとモデルに基づく設計
連立微分方程式のPade近似解法 Fortran手による最適化とコンパイラの最適化、誤差の評価
連続と離散、時間と空間、物理量と生物量。統計と確率(2)
3 「特殊な状態あり」
「仕様スメル」の「（あいまいな）修飾語」が「特殊な」かも。
何が特殊でないかが確認できないと、特殊が何かがわからない。
何が特殊でないかを確認すると、特殊と言わずに、
「大きすぎる」「小さすぎる」「長すぎる」「短すぎる」「遅すぎる」「早すぎる」「太すぎる」「重すぎる」「軽すぎる」などのより具体的な表現になる可能性がある。
他の値の範囲から３倍以上離れているなど、時々ある事項ならあらかじめ定義しておくことがあるかもしれない。
別の視点から測ると、別の点が他の値の範囲から３倍以上離れていて、その値は他の値の範囲内にあるかもしれない。
すべての個数分だけ視点を用意したら、すべての点が一つの視点では特殊かもしれない。全部の点が特殊点だけからなる集合になることがある。
それは、特殊じゃない状態がない状態って言うんだろうか。
4 「データの生存期間の定義なし」
データの生存期間の定義がないと、昔の測定結果に基づいて、とんでもない操作をしてしまう可能性がある。データの生存期間が過ぎたら、また測定しなおすか、測定しなおすまでの間は初期値を使ったりするかなど、戦略または戦術がたててあるとよい。
Time to Live（TTL）とは？| TTL定義
DNSキャッシュ
5 「複数のレイヤで同様の状態を保持」
複数の階層で同様の状態を保持する場合は、
二重化している場合のほかには、自分と制御対象のような
相手の状態を自分も持っているが、その相手の状態も自分で持つような場合である。
何か操作をする前に、自己検証するため、現在の相手の仮想な状態と、その相手の状態を自分の測定結果として持っている状態との間の相互作用を確かめてから動作させるような仕組みになっている場合。
具体例は実際に関わっていないのであげにくいが、ゲーム機の場合にはあるかもしれない。
優先順位づけ
上の考察に基づいて、どの事象から優先順位をつけて対応するかを考えてみる。
特殊な状態については、さんざんぱら文句をつけた。
実際には、すべての点が特殊な値を持つような測定方法を探すのは、至難の技です。
人工衛星などの、地球環境から抜け出る制御を行う場合には考慮しますし、原子力のような危険性の高い対象についても考慮します。それ以外の場合は、ひとまず怪しいやつということで優先順位を１番にします。
1 特殊な状態あり
2 複数のレイヤで同様の状態を保持
3 データの生存期間の定義なし
4 設計図がシーケンス図のみ
5 状態はあるが状態遷移表なし
複数の層で同様の状態を保持するのは、その理由が明確な場合です。
次に対応できそうかなって。
３番目はデータの生存期間の定義なし。
いつものデータが初期データと誤差の範囲内であれば、特に問題にする必要がない場合もあるかもしれない。値のばらつきによって重要さがますかもしれない。
４番目はシーケンス図のみ。
どっちみち状態遷移は描いておいた方がいい。
シーケンスから推測できる範囲内だけでも。
状態遷移表がないのは、道具を用意すればいいだけだから一番優先順位を低くした。すぐにつくれるでしょっていう感じ。
立場によって、この順番はいろいろでよい。
優先順位がついていないとすれば、それが一番問題かもしれない。
あるいは、リーダの優先順位に左右されるといけないので、
優先順位をひとまず秘匿しているのかもしれない。
あとがき
コードは、いろいろな方法で検出することができるかもしれない。
RTL設計スタイルガイド Verilog HDL編(System Verilog対応版）
MISRA C まとめ #include
機械学習で、従来ではみつけにくかった課題も明らかにできるかもしれない。
Data Robotのセミナの際に、話があった。
究極は誰がかかわったかが、一番大きいことがしばしばある。
人名にも着目するといいかも。
ソースコードに人名が書いてないソースは、それが一番悪だということで。
仕様＝制約＝設計＝コード
RTL設計スタイルガイドでは、コードを書くことを設計と言います。
コンパイルすると、回路図を生成し、それが実装です。
C言語で書いたのが設計です。コンパイル、リンク、配置（ロケート）したものが実装です。一つのソースコードから多様な実装を産むことができます。
設計した結果を仕様という場合があります。
仕様から設計するとは限りません。
仕様から設計するとすれば、その仕様が不十分な時かもしれません。
設計した結果を仕様と呼ぶようにすれば、次から不十分な仕様で何かを始めることがなくなるかもしれません。
制約を集めたものを設計という場合があります。
制約のない設計は、どんな場合でも役立つか、何にも役立たないかの両極端なのかもしれません。
制約が仕様の一部になっている場合があります。すべての制約を記述したものを仕様とする場合などです。
制約と、設計と、仕様とが一体となって一つの塊になっているような場合です。
そして、仕様、制約、設計を記述するのがコードです。
仕様記述言語、制約記述言語、設計記述言語と、別々のコードになっている場合があるかもしれません。一つの言語で記述できる場合があるかもしれません。
設計で考察したことを、仕様、制約、コードでも検討できるほど、その視点ではあまり考えていないのかもしれません。ごめんなさい。
成功体験は語っても、成功体験に頼らないために。
清水吉男さんに見習いたいのは、「成功体験は語っても、成功体験に頼らない」こと。どうしても、うまく行くと有頂天になり、周りが見えなくなる。
清水吉男さんは、注意深く周りを見渡しながら、仕事をしている。
自分では、見習えない時は、周りの人に見習ってもらうのも手かも。
成功体験は語っても、成功体験に頼らないために。清水吉男・田中伸明・柏原一雄・佐々木 眞一。仮説・検証（153）
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.