私が苦労していることの一つは、コードを書く前にアプリケーションのアーキテクチャを計画することです。
アプリケーションに必要なことを絞り込むために要件を収集するという意味ではなく、クラス、データ、フロー構造全体をレイアウトする適切な方法について効果的に考え、それらの考えを繰り返して、IDE を開く前に信頼できる行動計画を念頭に置くことを意味します。現時点では、IDE を開いて空のプロジェクトを作成し、少しずつ書き始めて、そこからデザインを「成長」させるのは非常に簡単です。
UML はこれを実現する 1 つの方法だとは思いますが、私は UML の経験がないので、漠然としているように思えます。
どうやってあなたコードを書く前にアプリケーションのアーキテクチャを計画しますか? UML が最適な方法である場合、小規模なアプリケーションの開発者向けに簡潔で実用的な入門書をお勧めいただけますか?
ご意見をいただきありがとうございます。
ベストアンサー1
私は次のことを考慮します:
- システムが何をすべきか、つまりシステムが解決しようとしている問題は何か
- 顧客は誰で、彼らの希望は何なのか
- システムが統合しなければならないもの
- 考慮すべきレガシーの側面はあるか
- ユーザーインタラクションとは何か
- 等...
次に、システムをブラックボックスとして見てみます。
- そのブラックボックスとどのようなやり取りをする必要があるのか
- ブラック ボックス内で発生する必要がある動作は何ですか。つまり、ブラック ボックスがより高いレベルで望ましい動作を示すためにそれらの相互作用に何が発生する必要があるか (例: 予約システムからの着信メッセージを受信して処理する、データベースを更新するなど)。
すると、さまざまな内部ブラック ボックスで構成されたシステムの全体像が見えてきます。各ブラック ボックスは、同じ方法でさらに細分化できます。
UML はこのような動作を表現するのに非常に適しています。UML の多くのコンポーネントのうち、次の 2 つだけを使用してほとんどのシステムを記述できます。
- クラス図、そして
- シーケンス図。
記述する必要がある動作に並列性がある場合は、アクティビティ図も必要になることがあります。
UMLを学ぶための良いリソースは、マーティン・ファウラーの優れた本「UML Distilled」(Amazonリンク- スクリプトキディのリンクナチのためにサニタイズされています (-: )。この本では、UML の各コンポーネントの重要な部分を簡単に見ることができます。
ああ。私が説明したのは、Ivar Jacobson のアプローチとほぼ同じです。Jacobson は OO の Three Amigos の 1 人です。実際、UML は Three Amigos を構成する他の 2 人、Grady Booch と Jim Rumbaugh によって最初に開発されました。