Como modelar locais, termos acadêmicos e diferentes coortes no OO

Estou trabalhando em um aplicativo para universidades. O caso é o seguinte:

Cada universidade possui vários programas acadêmicos. Cada programa tem muitos assuntos (módulos). Cada assunto pode ser oferecido em locais diferentes. O ano acadêmico é dividido em períodos e cada período dura várias semanas. Nem todos os módulos são oferecidos nos mesmos locais em cada semestre e os programas podem ser oferecidos a diferentes grupos de estudantes com datas de início diferentes no mesmo ano acadêmico.

Por exemplo, a Universidade A possui um programa de MBA oferecido em Nova York e Londres. O MBA possui 2 módulos por período (10 semanas) oferecidos nos dois locais (Say MBA-NY e MBA-L). É possível, e com base na demanda, ter uma terceira execução do programa (e, portanto, dos módulos neste termo), que inicia uma semana depois da ingestão normal. Portanto, há outro grupo de MBA-NY, mas com cronograma diferente. Mas esse grupo também faz parte do mesmo termo no currículo do MBA (ou seja, os dois grupos estão fazendo o Termo 2 do MBA).

Minha pergunta é como modelar locais, termos acadêmicos e execuções no projeto OO. A localização, os termos acadêmicos (e talvez as "execuções") são propriedades do objeto da universidade ou do objeto do programa? ou do objeto do módulo?

Atualização: Com base nas suas respostas, minha dificuldade é modelar os termos acadêmicos, as coortes e os diferentes cronogramas. Não é realmente o local, pois parece direto para mim. Eu apenas o incluí na descrição para mostrar as conexões.

Você não deve começar pensando em objetos. Supondo que você deseja construir um aplicativo de trabalho real (e este não é um exercício de modelagem de BS), você deve esclarecer os requisitos, ou seja, quais tarefas o aplicativo deve ser capaz de executar e projetar o modelo de dados necessário para suportar isso. O design do objeto é de nível mais baixo e desce a linha após esse design de alto nível.

A questão sobre locais, currículo, cronogramas, etc. faz parte da questão de projetar o modelo de dados para o aplicativo. Portanto, você ainda não deve pensar em termos de objetos ou propriedades. Você provavelmente deve projetá-lo na forma de um diagrama de entidade-relacionamento ou algum projeto conceitual semelhante.

Então, quando você tiver o modelo de dados e souber quais tarefas e operações o aplicativo deve executar, poderá começar a determinar quais objetos você precisa. Mas você ainda não está lá.

Parece que você está tentando criar um design orientado a objetos, mas com relações semelhantes a um banco de dados relacional. Geralmente, essa não é uma idéia muito boa - é uma idéia comum , está em muitos livros de programação e, na verdade, é provavelmente uma má idéia. Veja qualquer um dos muitos exemplos documentados de ORIM, Incompatibilidade de Impedância Relacional a Objetos, na Internet.

Objetos são classes de comportamentos. Quais comportamentos seu aplicativo tem?

Por exemplo: é um site em que você navega de uma lista de programas para um programa e de uma lista de locais e módulos? Sem considerar quaisquer preocupações de teste e injeção de dependência, isso levaria 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) { ... }
}

e assim por diante. O conteúdo das classes é modelado em como as coisas aparecem na interface, não como são armazenadas no banco de dados. Pode coincidir, mas isso não é garantido.

Observe que os métodos são construídos assumindo um aplicativo Web, em que cada nova solicitação que você deseja executar o mínimo de SQL possível, por exemplo, é mais provável que você precise de um método "obter locais pelo ID do programa " do que um "obter locais pelo Programa "porque você não deseja ser forçado a criar uma instância inteira de um programa para obter uma lista de locais.

Da mesma forma, você deve ter outros métodos, conforme necessário, para manipular esses objetos.

Obviamente, se você estiver criando aplicativos de desktop, as coisas serão diferentes. Por exemplo, você pode manter viva uma instância do Programa nas interações do usuário, e isso obviamente leva a uma estrutura diferente das chamadas de método.

Location é um objeto de negócios simples (embora não seja trivial necessário. Você pode descrevê-lo com a posição geográfica (desde que seja um local na Terra), bem como um nome, sua altura em relação ao nível do mar (qual?), etc.

Termtem uma relação de Programmeuma maneira que descreve sua duração e localização e possui várias restrições (quanto a que você pode ter). Portanto, também é um objeto de negócios.

Não tenho certeza do que "executar" significa nesse contexto.