それで、自転車のクラス図を作る仕事を与えられました。クラス図とは何か、その背後にある概念を知っています。
要件は、自転車がブレーキをかけたり、曲がったり、加速したりできることです。私にとって、自転車にはブレーキシステム、駆動システム、ステアリングシステムという3つの主要なコンポーネントがあります。また、各システムには、ブレーキハンドル、ペダル、ハンドルバーなど、アクション用の独自のアクティベーターがあります。
自転車が実際にブレーキをかけるには、ブレーキレバーを通過してブレーキシステムをトリガーする必要があります(レバーがレバーからブレーキシステムにどれだけ強く押し込まれているかのデータを渡します)。他の2つのシステムについても同様です。これは私がこれまでに思いついたものです:
私の質問:データを渡すことになっているアクティベーターとシステムの間の接続を説明するより良い方法はありますか?
クラスの設計に関しては、現実世界のオブジェクトをミラーリングすることよりも、brake()
のようなユースケースの背後にある思考を整理して複雑さを軽減することよりも常に心に留めておいてください。これは通常、レベルをよりフラットな組織に削減することによって達成されます。また、BrakeLever
のような特別なコンポーネントは、BrakeSystem
のような一般的なコンポーネントについては知らないはずです。
もっと作曲してみます。 Bike
すべきhave-aBrakeSystem
。 BrakeSystem
すべきhave-aBrakes
およびBrakeLever
。 BrakeLever
はBrakeSystem
のパブリックプロパティである必要があります。 BrakeLever
にはonPull
イベントがあり、BrakeSystem
はそのプライベートhandleBrakeLeverPull()
メソッドでリッスンする必要があります。 handleBrakeLeverPull()
は、プライベートreduceRPM()
メソッドを呼び出すことができます。次に、reduceRPM()
はWheel
s setWheelSpeed()
を使用します。 DriveSystem
とSteerSystem
も同様です。
すでに良い答えがありますが、考慮すべき他の考えがいくつかあると思います。
私はOzanに同意します。モデルには関連する詳細レベルが必要です。たとえば、自転車を販売するためのアプリケーションを作成する場合、価格が設定された記事の構造は非常にフラットになるでしょう。
ただし、デジタルツインが必要な場合は、たとえば、自転車をシミュレートしたり、センサーとアクチュエータで自転車を強化したり、自転車コンフィギュレーターを作成します。現実世界に近いモデルがあってもまったく問題ありません。
モデリングの意図を知らない:
モデルの指針となる原則は、コンポーネントの抽象化です。結果は、バイクとその3つの特定のサブシステムになります。これにより、自由度が増します。たとえば、レバーを使わずにペダルを後ろに引くとブレーキが作動する自転車があります。
サブシステムは、具体的に行ったように、またはより一般的な 複合パターン を使用してさらに分解できます。この場合、コンポーネントの数とタイプは実行時に変化する可能性があります。
最後に、UMLクラス図は、オブジェクトの構造を示すためだけにあります。 「接続が使用される」方法はすでに動作しており、 シーケンス や 通信ダイアグラム などの行動図でモデル化されます。