Cómo modelar ubicaciones, términos académicos y diferentes cohortes en OO

Estoy trabajando en una aplicación para universidades. El caso es este:

Cada universidad tiene varios programas académicos. Cada programa tiene muchas materias (módulos). Cada tema se puede ofrecer en diferentes lugares. El año académico se divide en términos y cada término dura varias semanas. No todos los módulos se ofrecen en los mismos lugares cada trimestre y los programas se pueden ofrecer a diferentes grupos de estudiantes con diferentes fechas de inicio dentro del mismo año académico.

Por ejemplo, la Universidad A tiene un programa de MBA ofrecido en Nueva York y Londres. El MBA tiene 2 módulos por período (10 semanas) que se ofrecen en ambos lugares (por ejemplo, MBA-NY y MBA-L). Es posible y, según la demanda, tener una tercera ejecución del programa (y, por lo tanto, de los módulos en este término) que comienza una semana más tarde que la ingesta normal. Entonces, hay otro grupo MBA-NY pero con una línea de tiempo diferente. Pero, este grupo también es parte del mismo término en el plan de estudios de MBA (es decir, los dos grupos están haciendo el Término 2 de MBA).

Mi pregunta es cómo modelar ubicaciones, términos académicos y ejecuciones en el diseño OO. ¿Las propiedades de ubicación, términos académicos (y quizás "carreras") son propiedad del objeto universitario o del objeto del programa? o del objeto del módulo?

Actualización: según sus respuestas, mi dificultad es modelar los términos académicos, las cohortes y los diferentes plazos. No es realmente la ubicación, ya que me parece sencilla. Lo acabo de incluir en la descripción para mostrarle las conexiones.

No debes comenzar pensando en objetos. Suponiendo que desea construir una aplicación de trabajo real (y este no es un ejercicio de modelado BS), comenzaría aclarando los requisitos, es decir, qué tareas debería poder realizar la aplicación, y diseñando el modelo de datos necesario para respaldar esto. El diseño del objeto es más de bajo nivel y viene después de este diseño de alto nivel.

La pregunta sobre ubicaciones, currículum, cronogramas, etc. forma parte de la cuestión de diseñar el modelo de datos para la aplicación. Por lo tanto, no debería pensar realmente en términos de objetos o propiedades todavía. Probablemente debería diseñarlo en forma de diagrama de entidad-relación, o algún diseño conceptual similar.

Luego, cuando tenga el modelo de datos y sepa qué tareas y operaciones debe realizar la aplicación, puede comenzar a determinar qué objetos necesita. Pero aún no estás allí.

Parece que está intentando hacer un diseño orientado a objetos pero con relaciones similares a las de una base de datos relacional. En general, esta no es una muy buena idea: es una idea común , está en muchos libros de programación, y en realidad es probablemente una mala idea. Vea cualquiera de los muchos ejemplos documentados de ORIM, desajuste de impedancia relacional de objetos, en Internet.

Los objetos son clases de comportamientos. ¿Qué comportamientos tiene su aplicación?

Por ejemplo: ¿es un sitio web donde navega desde una lista de programas a un programa y una lista de ubicaciones y módulos? Sin tener en cuenta ninguna preocupación de pruebas e inyección de dependencia, esto conduciría a algo como:

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) { ... }
}

y así. El contenido de las clases se basa en cómo aparecen las cosas en la interfaz, no en cómo se almacenan en la base de datos. Puede coincidir, pero eso no está garantizado.

Tenga en cuenta que los métodos se crean asumiendo una aplicación web, donde cada nueva solicitud desea ejecutar la menor cantidad de SQL posible, por lo que, por ejemplo, es más probable que necesite un método "obtener ubicaciones por ID de programa " que "obtener ubicaciones por programa". "ya que no desea verse obligado a crear una instancia completa de un Programa para obtener una lista de ubicaciones.

Del mismo modo, debe tener otros métodos según sea necesario para manipular estos objetos.

Por supuesto, si está creando aplicaciones de escritorio, las cosas son diferentes. Por ejemplo, puede mantener viva una instancia del Programa en las interacciones de los usuarios, y esto, por supuesto, conduce a una estructura diferente de las llamadas al método.

Location es un objeto comercial sencillo (aunque no necesariamente trivial. Podría describirlo con la posición geográfica (siempre que sea una ubicación en la tierra), así como un nombre, su altura en relación con el nivel del mar (¿cuál?), etc.

Termtiene una relación de Programmeuna manera que describe su duración y ubicación y tiene varias restricciones (en cuanto a cuánto puede tener). Por lo tanto, también es un objeto comercial.

No estoy seguro de lo que significa "ejecutar" en este contexto.