Для начала несколько слов про include и про extend. Если вы программируете активно, то знаете, что такое include. В паскале это uses, в php include и require. Т.е. то что нужно всегда.
То есть в вашем случае - чтобы пройти тест - нужно обязательно авторизоваться. Думаю тут вы все понимаете правильно.
Расширение - то что возникает в определенный момент при соблюдении некотрого условия. Т.е. в вашем случае просмотреть информацию о классе расширяется возможностью просмотреть информацию об ученике.
Правда тут не понятно - Разве ученик может просматривать информацию о классе? И какую информацию о классе? Знаете мне бы лично было бы неприятно, если бы мои результаты тестирования были доступны другим ученикам. Разные понимаете бывают ученики. Кроме того, а чем ваш пользователь отличается от ученика? Что пользователю для того чтобы посмотреть информацию о классе и об ученике, вовсе не надо авторизоваться? Довольно непонятная логика...
Теперь о моих фраза по поводу граничных и управляющих классах.
Когда действующее лицо взаимодействует с системой, то он взаимодействует через некоторый интерфейс. Это естественно. с одной стороны человек, с другой машина. Они оперируют разными представлениями информации, требуется согласование. Как вы его добиваетесь - делаете некий интерфейс: консольный текстовый или графический, а может это будет голосовой, это неважно. Важно то что есть четкая обязанность - сопрягать одно действующее лицо с другим. Обычно в ООП этим занимаются граничные классы (но не обязательно интерфейсы, если вы понимаете о чем я).
Правила хорошего программирования и проектирования подразумевают, что вы предоставляете доступ к данным не напрямую, а через формы - то есть интерфейсы, граничные классы.
Например при авторизации вы предоставляете форму авторизации: два поля - логин и пароль, кнопка для подтверждения.
При нажатии на кнопку - обрабатывается событие, которму может сопоставляться некий набор действий - шифрование данных переданных в форму, соединения с баззой данных, выполнения запроса поиска соотвествия введенной в форму информации и информации в БД, выдача подтверждения или обработка исключений. Опять же по правилам ООП каждый класс или объект имеет свои обязанности: один отвественен за соединения с БД, другой за обработку исключений и т.п. Это может выполнять и один класс или группа - это уже как вы решите, ваш опят ваш профессионализм. Конечно, у вас может быть так, что форма будет включать в себя и интерфейс и управление. Как например в MS Access, когда мы делаем форму с помощью мастера, то соединение стаблицей, изменение данных и т.п. происходит прозрачно для нас, но это плохой стиль программирования и проектирования, он хорош для локальных систем, однопользовательских.
Потому правилами (но не законами, которые надо выполнять неукоснительно) для ВИ определено наличие граничного класса (boundary) для каждого актера, взаимодействующего с ВИ, наличие классов-сущностей, которые отвечают за сохранение данных, но необязательно перзиентных, т.е. сохраняемых на внешних носителях памяти, и наконей управляющих классов -control.
А вообще совет - изучите хотя бы общие основы ООП и UML, хотя бы на
www.intuit.ruА насчет реализации того, что вы написали. Ну невсе ли равно как вы это сделаете - как удобнее, какие ребования предявляет вам ваш заказчик. А вот имеет смысл рисовать ВИ или нет, тут нужно здорово подумать, может имеет смысл сначала написать сценарии в тексте, пусть это будут просто истории от имени некоего учителя и ученика.
И кстати не путайте роли и реальных пользователей.
Вы говорите что админа не будет , а так ли?? Кто же будет обслуживать программу? Учитель? но он будет выполнять вероятно роль админа? В общем подумайте внимательно
Электронное тестирование учеников