OOで場所、学術用語、さまざまなコホートをモデル化する方法

私は大学向けのアプリに取り組んでいます。ケースはこれです：

各大学にはいくつかの学術プログラムがあります。各プログラムには多くの主題（モジュール）があります。各科目は異なる場所で提供できます。学年は学期に分かれており、各学期は数週間続きます。すべてのモジュールが同じ場所で各学期に提供されるわけではなく、プログラムは同じ学年度内の異なる開始日を持つ異なる学生グループに提供できます。

たとえば、A大学はニューヨークとロンドンでMBAプログラムを提供しています。MBAには、1学期（10週間）ごとに2つのモジュールがあります（MBA-NYとMBA-Lなど）。需要に応じて、通常の摂取量よりも1週間遅れて開始するプログラム（したがって、この用語ではモジュール）の3回目の実行を行うことができます。したがって、別のMBA-NYグループがありますが、タイムラインが異なります。ただし、このグループは、MBAカリキュラムの同じ用語の一部でもあります（つまり、2つのグループはMBAの用語2を実行しています）。

私の質問は、場所、学術用語、OOデザインでの実行をモデル化する方法です。場所、学術用語（およびおそらく「実行」）は、大学オブジェクトまたはプログラムオブジェクトのプロパティですか？またはモジュールオブジェクトの？

更新：あなたの回答に基づいて、私の困難は学問の用語、コホート、および異なるタイムラインをモデル化することです。それは私にはまっすぐに見えるので、実際には場所ではありません。説明にそれを含めて、接続を示します。

オブジェクトから考えることから始めるべきではありません。実際に機能するアプリケーションを構築する場合（これはBSモデリングの演習ではありません）、要件（アプリケーションで実行できるタスク）を明確にし、これをサポートするために必要なデータモデルを設計することから始めます。オブジェクトの設計はより低レベルであり、この高レベルの設計の後にラインダウンします。

場所、カリキュラム、タイムラインなどに関する質問は、アプリケーションのデータモデルの設計に関する質問の一部です。したがって、まだオブジェクトやプロパティの観点から考える必要はありません。エンティティリレーションシップ図、または同様の概念的な設計の形で設計する必要があります。

次に、データモデルがあり、アプリケーションが実行する必要があるタスクと操作がわかったら、必要なオブジェクトの決定を開始できます。しかし、あなたはまだそこにいません。

オブジェクト指向の設計をしようとしているようですが、リレーショナルデータベースに似たリレーションを使用しています。これは一般にあまり良い考えではありません。これは一般的な考えであり、多くのプログラミングの本に含まれており、実際にはおそらく悪い考えです。文書化されたORIMの多くの例、オブジェクトリレーショナルインピーダンスミスマッチをインターネットでご覧ください。

オブジェクトは動作のクラスです。アプリケーションにはどのような動作がありますか？

例：プログラムのリストからプログラム、ロケーションとモジュールのリストに移動するWebサイトですか？テストや依存性注入の問題を考慮しないと、次のような結果になります。

public class Programme
{
  public static List<Programme> All() { ... }
  public static Programme GetById(int id) { ... }
  public List<Location> GetLocations() 
  { 
     return Location.GetByProgrammeId(Id);
  }
  public int Id { get; set; }
}

public class Location
{
   public static List<Location> All() { ... }
   public static List<Location> GetByProgrammeId(int id) { ... }
}

等々。クラスの内容は、DBに格納される方法ではなく、インターフェイスに表示されるものに基づいてモデル化されます。偶然かもしれませんが、それは保証されていません。

メソッドはWebアプリケーションを想定して構築されていることに注意してください。新しいリクエストを実行するたびにSQLをできるだけ少なくしたいため、たとえば、「プログラムによる場所の取得」メソッドよりも「プログラムIDによる場所の取得」メソッドが必要になる可能性が高くなります。 "ロケーションのリストを取得するためにプログラムのインスタンス全体を作成することを強制されたくないので。

同様に、これらのオブジェクトを操作するには、必要に応じて他のメソッドが必要です。

もちろん、デスクトップアプリケーションを構築している場合、状況は異なります。たとえば、ユーザーインタラクション全体でプログラムインスタンスを存続させることができる場合がありますが、これはもちろん、メソッド呼び出しの異なる構造につながります。

Location は単純なビジネスオブジェクトです（それほど重要ではありませんが、地理上の位置（地球上の場所である場合））と名前、海抜に対する高さ（どれか）などで説明できます。

TermProgrammeそれはその期間と場所を説明するという点で関係があり、（いくら持つことができるかに関して）いくつかの制約があります。したがって、これもビジネスオブジェクトです。

この文脈で「実行」が何を意味するのかわからない。