クラス、メソッドの設計をしている中で下記のようなことで頭をよく悩ませます。
- 業務とユースケースは紐づいているのか
- 意味不明な用語を使ってないか
- ユースケースを実現するためのクラス作り方、分け方は合っているのか
- 責務が他のクラス、メソッドに漏れ出てないか
などなど
モデリング経験の少なさで詰まることが多いため個人的に日常生活にあるものでモデリングの勉強をしています。その一部を紹介します。
ルール
なるべく一般的な用語やその物に精通している人たちが使っている用語でまとめていくこと。
使う側の用語とシステムが紐づかなくなるから、ちゃんとした用語を使用するように心がけてます。
手順
決まりきった手順はないですが、自分が整理するときの手順を軽く紹介。
- ユースケースを洗い出す
- モデリング対象の要素を洗い出す
- 状態遷移があるか洗い出す
- 要素と状態遷移をモデルで表現する
- 実装してみる -> 長くなるのでここは別途、、、m(_ _)m
お題
アコースティックギター
ユースケースを洗い出す
- 弦を抑える
- １つの弦を抑える（単音）
- 複数の弦を同時に抑える（コード）
- 弦を鳴らす
- ダウンストローク
- アップストローク
要素を洗い出す
- 指板
- フレット
- 弦
- 音階
- フレットと弦のペアで音階が決まる
- 複数のフレットと弦のペアで音階が決まる
状態遷移があるか洗い出す
- 出音: true/falseでいいかも
モデル
今後
この後モデリングした結果を実装していきます。
実装した結果、うまく表現できてない要素やユースケースが現れてくると思います。
その時は今のモデルに何か誤りがある可能性があるため、モデルの見直しをかけて実装に再度落とし込んでいきます。
そのサイクルを繰り返すことによりモデルが洗練されてくるはずです。
まとめ
モデリングについて書いてみました。
モデルの見直しを行いリファクタリングをし続けることは実プロジェクトではなかなか難しいかもしれません。（すぐリリースできる環境になかったり、改善に時間が割けなかったり、、、）
でも、それをすることで自分達が作っているものをよく知れたり、バグの危険がある箇所を対処できたり、変更に強くなったりメリットはたくさんあります。
自分としてはこういう活動を繰り返すことで自分のモデリング力を上げていけたら楽しいと思うので、一つの勉強方法として取り組んでみてはいかがでしょうか。
ここまで読んでいただいてありがとうございましたm(_ _)m