Примечания:

1. Стереотип «controller» на изображении класса является ни к чему не обязывающим словом, указывающим лишь на то, что класс играет роль контроллера. Обозначение предназначено для более полного понимания учащимися назначения экземпляров класса в системе. StarUML игнорирует этот стереотип, генерируя каркас кода как для обычного класса.

2. Поскольку, как правило, объект типа «контроллер» в системе присутствует в единственном экземпляре (хотя, может быть несколько типов контроллеров), то он реализуется еще с использованием паттерна «одиночка» (singleton) . На данной диаграмме вместо значка «класс» можно также было использовать значок «объект», символизирующий то, что экземпляр класса данного назначения в системе один.

3. Класс «контроллер» связан с остальными ассоциациями без указания типа, что ничего не говорит об особенностях реализации данных связей. Это обозначение применено здесь для упрощения вида диаграммы.

Оценка модели:

На данном этапе развития системы модель с достаточной полнотой удовлетворяет принципам проектирования архитектуры. Каждый класс имеет достаточное сцепление (на текущем уровне знаний учащихся).

Принцип единственности ответственности также выполняется (почти, не считая контроллера, но такова его судьба).

Принцип минимального знания (закон Деметера) выполняется (на первый взгляд, ибо конкретной реализации нет, и проверить не на чем).

Принцип DRY выполняется – ни один класс не повторяет функциональности другого.

Принцип открытости/закрытости выполняется: для создания нового типа уравнения или нового алгоритма решения не нужно модифицировать существующие классы (кроме контроллера, но об этом ниже), а можно создать новые.

Принцип обратной совместимости НЕ выполняется, поскольку реализация другого алгоритма решения потребует класса с другим интерфейсом, что, в свою очередь, повлечет за собой изменения в контроллере. Это также говорит о том, что связанность классов не достаточно низкая со всеми вытекающими последствиями. Но в данной ситуации вступает принцип YAGNI. Если заказчик ограничится только квадратными уравнениями, то данной модели будет вполне достаточно.

Вывод:

Есть о чем подумать и куда развиваться. Скорее всего, понадобиться еще один шаг для унификации интерфейсов (обобщения имеющихся понятий). Но это в следующем номере.

Заключение

В данном примере рассмотрена только модель одной части системы, а именно – модуля для демонстрации решения квадратных уравнений. Каждая следующая подсистема будет добавлять в модель свои классы. Например, подсистема контроля знаний может оперировать такими понятиями: «генератор коэффициентов уравнения» (создает коэффициенты для различного количества корней), «коллекция данных пользователя» (содержит результаты пользовательских вычислений), «проверяющий решения», «выставляющий оценку», «пользователь», «оценка» и т.п. Кроме того, в этой подсистеме появляется слой ORM, так как данные о пользователе хранятся в БД. В зависимости от выбранного типового (или не типового) решения реализации DOM, могут быть использованы классы «транзакция», «mapper», «dataset» и т.п.