Артем Спиридонов

MVC? Легко.

==== Метод входа ====
Сущность - сессии авторизации.
Попытка входа - создание записи с правилами валидации. Правила валидации проверяют, что введено то, что надо, пользователь не заблокирован, пароль совпадает и т.д.
В случае удачного входа колбеком ставить куку. В куке токен, ключ от которой хранится в записи сессии в БД.

==== Поддержка сессии ====
При каждом запросе, в том числе AJAX, считываем авторизационную куку. Ищем сессию, проверяем ключ, активность сессии (истечение), права пользователя.
Можем записать в свойства пользователя, что он онлайн.
Можем записать в класс авторизованного пользователя его свойства (или хотя бы идентификатор).

==== Выход ====
Если нет куки - ничего не делать, просто редирект на главную.
Если есть кука - найти сессию и деактивировать её. Можно удалить куку. Можно не удалять, если вы собираете цифровой след - к примеру, хотите отслеживать мультиачье и т.п.

University содержит множество экземпляров Professor.

В смысле? Университет может порождать множество экземпляров университетов, а профессор - профессоров. И они не могут наследовать - профессор не имеет ни свойств, ни методов университета.

Как верно подсказал коллега выше, принадлежность к университету - обычное свойство профессора, причем может быть многие-ко-многим. Следовательно, ответ на ваш вопрос: обычный геттер.

Честно? Всего две книжки. Хотя бы по диагонали.

• "Рефакторинг" Мартин Фаулер
  
• "Архитектура корпоративных приложений" Мартин Фаулер
  

Расширение сознания гарантированно.

UML и DFD карандашом или фломастерами. Фломастерами удобнее, потому как в цвете комфортнее восприятие.

Если нужно для презентации - в Libreoffice Impress.

Сложная структура уже является ошибкой проектирования. Все должно быть примитивно и при возможности многоуровнево ("разделяй и властвуй" - слышали такое?). На любом конкретном аспекте, БЛ, DFD, функциональная логика, API - результат должен быть примитивным, и умещаться на одном листе А4.

Если не умещается - значит есть чего делить и упрощать. Это очень просто.

Кстати, хорошо спроектированный софт пишется очень быстро.

1. Проектировать решения, прежде чем писать код. Цветными фломастерами в тетрадке. Записывать микроТЗ, прежде чем писать код. В тетрадку или в любой текстовый редактор. Вообще, код написать просто, вы в курсе, да? Придумать, что написать - это другой вопрос.
   
2. Использовать личный список задач, вне зависимости от того, что используют коллеги. Если требуют использовать корпоративный - используйте его и личный. Любой таск-менеджер, а еще лучше - записывать даже самые мелкие задачи в тетрадку и вычеркивать при изменении статуса цветным фломастером.
   
3. Работать ритмично. N минут работы, M минут отдыха, где N от 20 до 90, M от 5 до 20.
   
4. Заняться физкультурой. Обязательно каждый день гулять. Здоровое питание, полный отказ от алгоколя и кофе, принимать витамины курсами.
   
5. На работе заниматься только работой. Не на работе работой не заниматься. Можно завести два телефона (или двухсимочный телефон) и отключать симки, в зависимости от времени дня и других факторов. Не использовать мессенджеры, скайп, джаббер, аську и т.д. Не отвлекаться на соцсети и т.д.
   

Эти простые вещи помогли мне увеличить продуктивность примерно в десять раз.

И да, вы используете VCS и фреймворки?