Продолжение цикла статей из серии "Как посмотроить четкие модели классов и получить реальные преимущества от UML". В первых двух частях (первая, вторая) мы обсудили общий принципы UML, о семантике и признаках хорошей модели. В этой части разберем как поведение системы можем быть выражено в модели.
Отношения в области управления воздушным движением
В предыдущих частях мы по большей части говорили о классах, но у хорошей модели есть еще две критически важные ассоциации, R2 и R3. Давайте подробнее про каждую из них.
R2: управление внутренним трафиком
Посмотрите на R2 на диаграмме, что необычного? Правильно, стиль наименования ролей немного отличается от привычного для диаграмм классов UML. В этом примере так сделано специально — для плохой модели я буду использовать обычный, менее описательный стиль.
Чтобы прочитать обозначенную глагольными фразами связь, начните с одной стороны этой связи и прочитайте по порядку фразу, мощность связи и имя класса на противоположной стороне, рисунок вам в помощь.
Если проще — «Дежурный диспетчер управляет движением в пределах либо ни одной, либо многих зон управления». То есть этот диспетчер может хоть и быть на дежурстве, но при этом не курировать ни одной зоны управления в текущий момент времени.
Но при этом «В зоне управления есть трафик, управляемый точно одним дежурным диспетчером». То есть эта зона вообще в любой момент времени железно курируется тем или иным диспетчером, она не остается без присмотра. Причем одна зона в конкретный момент времени курируется только одним диспетчером, это важно.
R3: авторизация в системе
Тут видно, что дежурный диспетчер зарегистрирован ровно на одной станции. Если проще, то он может быть на дежурстве только в условиях, когда он успешно зарегистрировался в системе и для него есть свободная станция. При этом станция в любом момент времени может как управляться дежурным диспетчером, так и не управляться им. Поэтому верно будет выражение «Станция управляется либо ни одним, либо одним дежурным диспетчером».
Правила, выраженные хорошей моделью
ОК, с элементами модели мы с вами разобрались. Давайте теперь оценим правила и ограничения, которые выражены не только отдельными элементами, а всеми, учитывая и сочетания между ними
В каждый взятый момент времени авиадиспетчер либо находится на службе, либо отсутствует {R1}.
Дежурный диспетчер должен быть зарегистрирован на одной станции {R3}.
В любой момент времени станция может управляться или не управляться одним дежурным диспетчером, авторизованным в системе {R3}.
Зона управления должна иметь свой трафик, управляемый точно одним дежурным диспетчером в каждый момент времени {R2}.
Дежурный диспетчер может управлять или не управлять трафиком в одной или нескольких зонах управления в каждый момент времени {R2}.
Какие же в хорошей модели выражены поведенческие ограничения?
Мощность и фраза на каждой стороне — вот что имеет главное значение для установления точных правил. Давайте зададим несколько поведенческих вопросов. Только по-честному, положите перед собой хорошую модель и попытайтесь ответить на каждый вопрос сами. Поехали.
Что должно произойти, когда выходной диспетчер выходит на дежурство?
Если на дежурстве остался только один диспетчер, может ли этот диспетчер уйти с дежурства?
Если каждая зона управления курируется, может ли другой выходной диспетчер зарегистрироваться в системе?
Если есть 5 дежурных диспетчеров и 5 станций, что нужно сделать, чтобы отключить станцию для проведения работ по обслуживанию?
Если есть 3 зоны управления и 3 дежурных диспетчера, то каково максимальное число зон управления, курируемых одним и тем же дежурным диспетчером?
Если предположить, что есть хотя бы один экземпляр зоны управления и только один дежурный диспетчер, то может ли этот дежурный диспетчер уйти с дежурства?
А теперь проверьте себя. Вот как правильно.
Чтобы стать дежурным, необходимо войти в доступное место службы «станция дежурства». Элемент «выходной диспетчер» будет удален и заменен новым элементом «дежурный диспетчер», ссылающимся на тот же элемент диспетчера. (Добавочно обратите внимание — во встраиваемых системах создание и удаление внутри модели иногда производится предварительным выделением области памяти и переключения бита, чтобы показать, действительно ли данный элемент существует. Так что существуют и другие способы реализации создания/удаления, отличные от конструкторов и деструкторов.)
А вот в этом вопросе больше одного правильного ответа. Каждая из зон управления требует курирования. Допустим, у нас существует один или несколько экземпляров зоны управления, тогда ответом будет «нет». Невозможно перенести элемент «дежурный диспетчер», не нарушив левую сторону связи R2, если только количество экземпляров зоны управления не равно нулю. Тогда ответом будет «да». Если бы был только один другой дежурный диспетчер, то зоны управления можно было бы сначала передать, но в данном случае этого нет, так что это не вариант.
Да, может. Дежурный диспетчер не обязан курировать какие-либо зоны управления. Следовательно, число дежурных диспетчеров ограничивается только наличием станций.
Поскольку имеется равное число станций и дежурных диспетчеров, мы можем предположить, что каждая станция используется. Поэтому нам нужно, чтобы дежурный диспетчер вышел из системы, но для этого нам нужно снять ATC с дежурства. И чтобы сделать это, мы должны сначала убедиться, что все зоны управления, руководимые этим дежурным диспетчером, сначала будут переданы другому дежурному диспетчеру.
Три. Для дежурного диспетчера допустимо иметь в ведении 0 зон управления, поэтому один из них может управлять всеми тремя зонами. В этом случае у двух других дежурных диспетчеров не будет назначенных зон управления. Главное — убедиться, что каждая зона управления курируется.
Нет. Один из выходных диспетчеров должен сначала стать дежурным, а потом уже все зоны управления должны быть переданы.
Давайте снова с иллюстрацией, которая нужна для хорошей модели. Вот дежурный диспетчер уходит с дежурства
Заполненные таблицы диспетчеров при этом обновляются вот так:
Авиадиспетчеры
ID {I} | Имя | Дата рождения | Рейтинг |
Диспетчер 53 | Тошико | 12 июня 1975 года | A |
Диспетчер 67 | Гвен | 28 марта 1981 года | B |
Диспетчер 51 | Оуэн | 23 декабря 1974 года | C |
Наша цель в том, чтобы создать модель, допускающую лишь валидные наборы данных. Ведь если в такие структуры можно вводить только валидные данные, нам не надо будет нагружать код необходимостью проверки последствий от невалидных данных. Более строгие модели классов — это изначально меньше кода, меньше тестирования, но при этом более высокое качество. С чисто практической точки зрения это может показаться (и оказаться) весьма труднодостижимым. Но стремиться к этому стоит, равно как и задавать трудные вопросы и отвечать на них. У плохой модели с этим проблемы.
В четвертой статье рассмотрим пример плохой модели и ее отличия от хорошей.
Актуальные вакансии компании Retail Rocket
С переводом помогали: Бюро переводов Allcorrect
Редактор: Алексей @Sterhel Якшин
