Uml design

В первых трех частях(первая, вторая, третья) мы поговорили о UML в целом, семантике и преимуществах хорошей модели.

Настало время обсудить ещё и плохую модель, а также её ключевые отличия от хорошей

Плохая модель классов

Пришло время посмотреть на тип модели классов UML, который можно встретить во множестве проектов. А ещё, увы, который часто поощряется в книгах по UML.

Понадобится нам для сравнения с плохой моделью

Хорошая модель

Здесь у нас та же самая область применения, но совершенно другая модель. Вот что сразу видно:

1. Меньше классов и отношений

2. Более короткие и неполные названия связей

3. Нет ссылочных атрибутов или тегов идентификаторов

4. Менее точные (ориентированные на реализацию) типы данных по атрибутам

Более того, если посмотреть на эти 4 элемента суммарно, будет заметно, что некоторых правил приложения вообще нет, а те, что есть, неправильно сформулированы. Пока поговорим о поверхностных отличиях.

Меньше элементов модели

В плохой модели меньше классов, так как роли диспетчеров дежурный и выходной не моделируются. Что сводит на ноль смысл значения поля Время регистрации в системе для каждого диспетчера, который выходной. Это вводит определенную логику если то(для обработки пустых значения, чего не требовалось в хорошей модели) в действия и/или диаграммы состояний.

А ещё такая модель будет требовать от программиста (или компилятора) зарезервированного места для заведомо ненужного атрибута. В принципе, это не такая уж проблема, если у вас немного диспетчеров. А если их тысячи? А если мы при этом оставили элементы вида не применимо в большом количестве классов? Для некоторых систем наличие сотен тысяч экземпляров обычное дело, это всего лишь один из вариантов того, как более компактная модель приводит к менее эффективному коду. На практике можно встретить много случаев, когда более детализированная и крупная модель несёт в себе ДНК, которая нужна для более точной реализации правил приложения.

Само собой, у нас тут принцип Чем меньше тем лучше. Но лишь до тех пор, пока это не начинает работать за счет выражения правил. Ведь моделирование в целом процесс аналитический, разбирающий вещи на составляющие. А разработка и реализация это, наоборот, синтез. Разработки моделей, который выполняет объектно-ориентированный анализ, старается выявить и раскрыть все правила приложения. При этом используя столько компонентов, сколько для этого нужно.

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

Вот что еще вытекает из разницы между анализом и синтезом. Цели аналитика и исполнителя могут противоречить друг другу, более того, так обычно и бывает. Если попытаться сделать одну модель, которая будет стараться удовлетворять обе цели сразу, то она получится провальной. В итоге вы получаете сжатый анализ и раздутую реализацию (да-да, именно поэтому хорошие программисты часто избегают UML, кому такое понравится).

Наша же с вами цель разделить процессы разработки и моделирования, чтобы получить максимальные преимущества от обоих.

Более короткие имена

Плохая модель использует для обозначения связей общий стиль именования ролей. Когда вы создаете диаграмму классов как прямое представление реализации своего кода, роли хороши, тут спору нет. Но для целей анализа куда как эффективнее глагольные фразы.

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

Так как имя роли часто совпадает с именем связанного класса, их можно смело удалять, это не уменьшит выразительность модели. Авиадиспетчер и контролер это одно и то же? ОК, так и запишем.

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

Когда аналитик помещает точную глагольную фразу с обеих сторон каждой связи, он вынужден тщательно рассматривать мощность связи и обусловленность с каждой стороны. Это критично именно здесь выражены многие правила. Следует избегать общих, всеохватывающих глагольных фраз, таких как содержит, является группой, имеет и мое любимое связано с. Просто погуглите композиция и агрегация, чтобы понять, насколько легкомысленно использовать общие термины для выражения точных ассоциаций. Какое утверждение скажет вам больше? Блок памяти разбит на взаимоисключающие части |..* Область или блок памяти является (выберите один вариант агрегация / композиция) из области?

Если вы говорите, что диспетчер управляет трафиком внутри <некоторого числа> зон управления, это вынуждает вас подробно рассматривать правила приложения. Вы наверняка уже поняли, что это 0..* и что нулевой случай соответствует выходному диспетчеру. Если перефразировать все в качестве класса дежурный контролер управляет трафиком внутри <некоторого числа> зон управления, то у вас получится отразить множественность 1..* и закрепить важное правило. Перевернув глагольную фразу с активного залога на пассивный, вы получите контрольную зону, в которой содержится трафик, управляемый только одним дежурнымконтроллером. Он должен всегда быть, плюс должен быть на дежурстве в соответствии с правилами приложения. Глагольные фразы ведут модель к повышенной точности.

Зачем вообще со всем этим заморачиваться, если фразы не переведены в код? На самом деле, они могут появляться как сокращенные имена или как комментарии. Но компилятор модели недостаточно умен, чтобы понять текст в глагольной фразе и выбрать в соответствии с ним тот или иной тип разработки. Наверное, это тоже хорошо. Но всё равно ведь именно множественность и определяет выбор структуры данных и реализацию доступа.

Но как вы пришли к правильному множеству? Модели, у которых общие ассоциативные имена, почти всегда опровергают настоящую природу ассоциации и скрывают интересные граничные условия, которые и приводят к неправильной множественности, порождающей неправильный код.

Отсутствие тегов идентификаторов или ссылочных атрибутов

В наших примерах выше теги не играют какой-то роли, поэтому подробно на них останавливаться я не буду. Ссылочные атрибуты нужны лишь для того, чтобы показать, что данные на самом деле связаны в табличной форме. Современные компиляторы моделей предполагают существование ссылочных атрибутов и могут управлять ими в фоновом режиме. Тем не менее, существует ряд простых методов, с помощью которых можно распространять и объединять ссылочные атрибуты в рамках нескольких отношений, дабы выразить строгие атрибуты. Я так часто поступаю, поэтому сохраняю ссылочные атрибуты по умолчанию.

Предположим, что каждый экземпляр класса уникален. Автоматически. То есть код сгенерируется так, что каждая строка таблицы соответствует однозначно выбираемой сущности. Поэтому нам не нужно накладывать атрибут{I}на каждый класс. Получается, что если у вас есть какой-то класс под названием Thing, то вы можете дать ему искусственный атрибутThing.ID {I}, но это необязательно это верно только для искусственных идентификаторов.

Однако, все ограничения уникальности реального мира должны быть выражены всегда. Представьте, что вы моделируете взлетно-посадочные полосы с одинаковым курсом и стороной в нескольких аэропортах. У вас не может быть две ВПП с одинаковым курсом и стороной (скажем, два 28R). Это ограничение, и его надо выразить.

Как вы это сделаете?

Вот модель, позволяющая это сделать, если включить ссылочный атрибут в качестве компонента идентификатора.

При помощи тегов{I} и {R}в классе взлетно-посадочной полосы эта модель сообщает нам, что уникальный экземпляр ВПП можно выбрать с помощью подставления заголовка, стороны и кода аэропорта. 28L в SFO, например, это взлетно-посадочная полоса 28 слева в Международном аэропорту Сан-Франциско. Так у вас появляется возможность объединять идентификационные данные и ссылочные теги, чтобы выразить тот или иной факт о реальном мире. А именно несколько взлетно-посадочных полос могут иметь один и тот же курс и сторону, но не в одном аэропорту.

Менее точные типы данных

В хорошей модели мы видели строго определенные типы данных приложения. Плохая же полагается на нечетко определенные типы реализации. Давайте на примере атрибутаControlZone.Name. В хорошей модели он определялся как типCZoneID. На рисунке видно, что имена зон управления состоят изCZи целочисленного значения, например,CZ1,CZ2и прочее в таком духе. Возможно, это получится реализовать и при помощи нечетко определенных типов строк. А если мы в модели говорим, что нам нужна строка, что мы просим в реализации? Если программист (или компилятор) модели работает с более специфичным типом приложения, то сможет при необходимости выбрать более жесткий тип реализации.

Вернемся к модели одного класса. У нас есть тип данных под названиемВысота, это можно определить как количество метров в диапазоне 70 000..-400 с точностью, скажем, 0,01. В отношении данного применения это было бы более точным. Конечно же, программист может захотеть реализовать это в виде данных типа float в C или любого другого типа, который соответствует нужной платформе.

Тут всё сводится к тому же принципу модель должна выражать истинные требования области применения. В максимально сжатом и точном объеме. Без ограничений в плане выбора метода написания кода. Ваша цель сделать модель такой, чтобы она выражала реальные условия области применения максимально сжатым образом. Это пригодится, чтобы расширить реальное применение с учетом возможных будущих требований. Допустим, сегодня модель используют только для самолетов с неподвижным крылом. А завтра захотят добавить еще и вертолеты, и вместо взлетно-посадочных полос у нас будут вертолетные площадки. Значит, есть смысл пересмотреть и самоопределение ВПП и посадочной поверхности.

Расширяете вы правила приложения или нет не так важно, главное построить точную модель любой реальности. Оставить модель расплывчатой это не попытка удовлетворить будущие требования, это попытка оправдать собственную лень.

Итак, атрибуты. Даже если мы позволим атрибуту быть свободно определенной строкой (такой как имя), мы сможем использовать типы данных длинное имя и короткое имя. Длинное может быть определено как строка до 80 символов длиной, а короткое до 10. Нацелены они могут быть как на один тип строк реализации, так и на разные.

Поведенческие ограничения в плохой модели не выражены, а вопросы оставлены без ответов

Пора рассмотреть модель в целом поглубже. Что говорит плохая модель о поведении приложения диспетчеров, правильна ли она?

В плохой модели ассоциация контролер равна 1:. Сторона допускает нуль. В итоге мы теряем то тонкое различие междудежурнымдиспетчером, которому не назначена зона управления, ивыходнымдиспетчером.

А вот как выглядит правило R2 в плохой модели: 0..1: 0..1. Эта ни к чему не обязывающая ассоциация охватывает и выходных диспетчеров, которые не вошли в систему, и станции дежурства, которые в данный момент не используются. Вот мы с вами и потеряли ограничение, указывающее, что во время дежурства диспетчер должен быть авторизован в системе.

Если диспетчер не использует станцию дежурства, может ли он все еще курировать зону управления? На этот вопрос модель отвечает Да, поскольку эти две ассоциации на плохой модели полностью независимы друг от друга.

Если диспетчер не курирует какие-либо зоны управления, может ли он при этом быть авторизованным на станции дежурства? И хорошие, и плохие модели позволяют это. И согласно правилам применения, это нормально.

На примере таблицы Самолеты одного класса мы рассмотрели вопросы, на которые могла бы ответить модель. Попробуйте спросить у плохой модели: Какие авиадиспетчеры сейчас не работают?. Она не может ответить на этот вопрос. Она может показать, какие диспетчеры не курируют зоны управления. Но ведь эти диспетчеры могут быть на дежурстве. Можно ли исправить это, добавив атрибут статуса в класс диспетчера в плохой модели? Само собой. Однако при этом вы все равно упускаете диспетчеров со значениемвыходной, которые при этом курируют зону управления.

Решение, включающее использование атрибута состояния, также требует императивного языка для управления ограничением. К чему это ведет? Больше кода и больше тестирования и все из-за одного атрибута статуса. Один атрибут статуса это не страшно. Временами. Но если злоупотреблять этим (а именно этим часто и занимаются), то сложность в моделях состояний и действий может стать очень велика.

Вот один пример невалидного сценария, разрешенного в плохой модели:

Изображение выше выглядит нормально, за исключением диспетчера 51 (Оуэн), который курирует зону управления CZ1, но не авторизован на станции дежурства.

В четвертой (и заключительной части) мы поговорим о преимуществах и недостатках обеих моделей (да, у плохой тоже есть преимущества) и о том, как сделать хорошую модель более лаконичной.

Актуальные вакансии компанииRetail Rocket

С переводом помогали: Бюро переводовAllcorrect

Редактор: Алексей @Sterhel Якшин

Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части о семантике и о том, что отличает хорошую модель.

UML и семантика, лежащая в его основе

Итак, мы рассмотрели пример лишь одного класса и заметили, что даже он охватывает сразу несколько правил. Используя табличное представление, мы получаем довольно жесткую структуру данных, поэтому можем думать о механике доступа к ним без учета конкретной реализации. Мы уже усвоили, что можем делать те или иные утверждения о том, что мы знаем, что можем вычислить, а что не можем. И все это без знания каких-то алгоритмов, диаграмм, действий или состояний. У нас просто есть схема одного класса, и этого уже достаточно, чтобы отвечать на вопросы и оценивать соответствие миру, которым планируем управлять. А представьте, что будет, когда бы добавим сотни классов и отношения.

Соблюдение ограничения идентификатора

У вас может возникнуть резонный вопрос где на самом деле применяется ограничение {I}. Модель классов устанавливает лишь требование идентификации. Когда код пишет программист или генератор модели, то должен иметь место систематический механизм обработки идентичности. При этом встроенная архитектура может использовать хэш-таблицу, а корпоративная полагаться на доступные механизмы БД для обнаружения и отклонения повторяющихся записей.

Хорошая модель

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

На рисунке ниже диаграмма классов условно хорошей модели

Некоторые части нотации выше представляют собой уже знакомый вам UML, но со своими особенностями. Поэтому мы пройдёмся по ним, рассмотрим структуру данных базовой таблицы, после чего ещё разок оценим общую картину. И потом уже сможем противопоставить хорошую модель плохой.

Классы авиадиспетчеров

В левой половине модели есть три класса: авиадиспетчер(Air Traffic Controller), выходной диспетчер (он же Off Duty Controller) и дежурный диспетчер (On Duty Controller). Вот как может выглядеть таблица суперкласса, заполненная примерными данными.

Смотрите, что имеем. Три авиадиспетчера, для каждого из которых мы точно знаем имя, дату рождения и квалификацию (рейтинг). В таблице у значения ID есть тег {I} что это значит? Правильно, что эти значения должны быть уникальными. В таблице есть данные, которые относятся к диспетчеру, независимо от того, находится ли сейчас авиадиспетчер на своём рабочем месте или у него выходной.

Обратите внимание на текст {disjoint, complete} около отношения обобщения R1 это пара стандартных тегов UML. Это значит, что каждый объект Авиадиспетчер может быть в состоянии дежурный диспетчер или выходной диспетчер. А элемент disjoint означает, что находиться в двух состояниях сразу авиадиспетчер не может. Complete же уточняет, что каждый авиадиспетчер точно находится или на работе, или не на работе. При этом статус каждого точно определен в любой момент времени.

Само собой, невозможно, чтобы какой-то объект, находящийся на дежурстве или вне дежурства, не был объектом Авиадиспетчер. Вот и получается, что R1 не представляет собой обобщение стиля наследования это, скорее, подтипирование реляционных подмножеств. Это XOR-моделирование классов, отличный инструмент для включения логики в структуру данных.

Дежурный диспетчер

Когда диспетчер находится на дежурстве, он должен быть зарегистрирован на месте дежурства, то есть на станции. При этом и ID самой станции, и время регистрации в системе для каждого из диспетчера сохраняются, и данные эти актуальны только во время дежурства.

Посмотрите на тег {R3} в атрибуте ссылки станции. Он значит, что станция соответствует идентификатору на другой стороне R3. В нашем случае это Duty_Station.ID.

Это очередной пример механики структуры данных, независимой от платформы. Допустим, вам интересно, на какой станции зарегистрирован диспетчер 53? Из структуры нашей таблицы понятно, что для ответа на этот вопрос достаточно просто найти строку с диспетчер 53 в столбце ID, а в столбце Станция получить значение S2.

А можно пойти дальше и получить данные из таблицы станций, используя S2 как ключ. Тогда получится ответить и на более сложный вопрос, например, Кто из диспетчеров зарегистрировался в системе станции S2?. Опять ищем нужную строку в таблице дежурного диспетчера в столбце Станции и получаем значение ID диспетчер 53.

Суть этой проверки просто в том, чтобы показать, что данные в любой реализации так или иначе связаны. Но это не значит, что нам надо реализовывать свои действия в SQL и подобном. Я работаю с системами, которые удаляют ссылочные атрибут и заменяют их указателями, дескрипторами или индексами какого-либо рода.

Направления доступа для каждой связи обычно оптимизируются или отключаются при необходимости (ряд компиляторов моделей, например, сканируют язык действий, видят, что в определенном направлении связи не выполняется никаких операций записи, и пропускают код сеттера).

Есть компиляторы моделей, которые проделывают все это сами, выдавая хороший C, Java, C++ и (да-да) ассемблер. Но вот генерация какого-либо SQL это, конечно, вариант для систем типа БД.

Заметьте, что на атрибуте ID присутствует тег R1, который указывает, что он одновременно является идентифицирующим атрибутом дежурного диспетчера, соответствующего его ID в суперклассе диспетчер. Все отношения в хорошей модели склеены со ссылочными атрибутами.

Выходной диспетчер

Как это ни странно, для выходных диспетчеров данные не хранятся, по крайней мере, мы об этом пока не знаем. Главное назначение этого класса в том, что он показывает, что время регистрации в системе и ID станций не сохраняются для тех диспетчеров, которые не на службе. Этот трюк дает нам возможность не использовать значение не применимо в наших таблицах. Что плохого в этом значении? Если вы в принципе разрешаете такие пустые значения, то для обработки особых случаев в своем коде вы напрашиваетесь на логику если то. А еще требуете место для хранения, которое на самом деле не нужно приложению.

А еще смотрите как только диспетчер уходит с работы, данные станции и времени регистрации будут удалены (или заархивированы). Так как диспетчер не может одновременно и работать, и не работать, то при миграции объекта диспетчер он или получает, или теряет данным. Вот как это отображается в таблицах.

Авиадиспетчер

Так проводится различие между объектом диспетчер, который является суммой общих и конкретных данных, представленных в любой момент времени двумя экземплярами класса.

Зона управления(Control Zone)

Зона управления это область воздушного пространства, находящаяся в ведении одного ATC. Правило, которое мы зафиксируем, состоит в том, что каждая зона управления всегда должна быть подконтрольна какому-то диспетчеру. При этом для каждой зоны управления у нас тоже есть уникальное имя, количество трафика и назначенный для неё диспетчер. Возможно, вы придумаете и еще какие-то полезные атрибуты, скажем, объем, местоположение и прочее. Но пока для примера все же упростим.

Теперь мы можем ответить на вопрос Каким объемом трафика управляет диспетчер 53?.

Станция дежурства

У каждой станции дежурства есть уникальный идентификатор, общее местоположение объекта и максимальная пропускная способность (она же - объем трафика, которым станция может управлять).

И тут уже нет никаких ссылочных атрибутов, потому что у нас уже есть один в классе дежурного диспетчера. Теперь, если надо ответить на вопрос Сколько лет человеку, авторизованному на станции S2?, то мы сможем это сделать. Для этого берем значение S2 и проверяем таблицу дежурных диспетчеров на предмет нужной строки. Если она есть, переходим в таблицу диспетчер, ищем строку с S2 и получаем из столбца Дата рождения нужное значение. Сравните её с текущей датой (она вам всегда доступна как системный параметр), проведите несложные вычисления и возраст диспетчера у вас есть.

Как я отмечал выше, такая процедура актуальна только в контексте чтения или выполнения модели. Когда вы добавляете модели состояний и действий, вы можете прогонять их в симуляторе, который управляет переходами состояний, очередями событий, совместной работой и доступом к данным/вычислениями. Как только вы сможете заставить это работать, вы сможете сгенерировать или написать код.

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

Может показаться сложным, но это не так ведь к многим элементам модели можно применить один системный паттерн переноса, вместе с несколькими параметрами конфигурации для локальной настройки. Поэтому нескольких таких паттернов вам хватит если не для обработки всего кода сразу, то для большей его части уж точно. В кропотливой ручной разработке кода для каждого класса нет необходимости.

Иллюстрированный сценарий

Таблицы хороший способ описания абстрактной структуры данных. Но при тестировании может быть полезна иллюстрация, позволяющая увидеть, могут ли эти таблицы соответствовать конкретному сценарию реального мира.

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

Одна станция бездействует, и ни она, ни выходной диспетчер не имеют связи с зонами управления.

В общем, наша хорошая модель на самом деле позволяет обработать реалистичный сценарий.

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

Поэтому я всегда стараюсь рисовать диаграмму в свободной форме, потом модель UML, и уже после этого сравниваю их. Такая валидация работает в обе стороны. Можно ли заполнить таблицы данными, приведенными на иллюстрации сценария? Могу ли я создать убедительную иллюстрацию сценария, используя только данные в моих таблицах? Если я обнаруживаю новый сценарий, я проверяю, подходят ли его данные модели.

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

Ещё одно преимущество в том, что пользователи и эксперты по иллюстрированной модели могут дать мне отличную детальную обратную связь, нежели по модели или диаграмме последовательности. Увы, существующие инструменты UML поддерживают лишь аспект моделирования и анализа в виде тех самых фигурок-квадратиков-линий, огромный пласт инструментов анализа еще не освоен.

Поэтому не бойтесь придумывать свои собственные значки и обозначения элементов, берите понравившиеся клипарты и используйте обозначения UML для воплощения абстракций.

В третьей части мы поговорим о правилах и ограничениях, присущих хорошей модели, а также начнём разбирать плохую модель классов.

С переводом помогали: Бюро переводовAllcorrect

Редактор: Алексей @Sterhel Якшин

Продолжение цикла статей из серии "Как посмотроить четкие модели классов и получить реальные преимущества от UML". В первых двух частях (первая, вторая) мы обсудили общий принципы UML, о семантике и признаках хорошей модели. В этой части разберем как поведение системы можем быть выражено в модели.

Отношения в области управления воздушным движением

В предыдущих частях мы по большей части говорили о классах, но у хорошей модели есть еще две критически важные ассоциации, R2 и R3. Давайте подробнее про каждую из них.

R2: управление внутренним трафиком

Посмотрите на R2 на диаграмме, что необычного? Правильно, стиль наименования ролей немного отличается от привычного для диаграмм классов UML. В этом примере так сделано специально для плохой модели я буду использовать обычный, менее описательный стиль.

Чтобы прочитать обозначенную глагольными фразами связь, начните с одной стороны этой связи и прочитайте по порядку фразу, мощность связи и имя класса на противоположной стороне, рисунок вам в помощь.

Если проще Дежурный диспетчер управляет движением в пределах либо ни одной, либо многих зон управления. То есть этот диспетчер может хоть и быть на дежурстве, но при этом не курировать ни одной зоны управления в текущий момент времени.

Но при этом В зоне управления есть трафик, управляемый точно одним дежурным диспетчером. То есть эта зона вообще в любой момент времени железно курируется тем или иным диспетчером, она не остается без присмотра. Причем одна зона в конкретный момент времени курируется только одним диспетчером, это важно.

R3: авторизация в системе

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

Правила, выраженные хорошей моделью

ОК, с элементами модели мы с вами разобрались. Давайте теперь оценим правила и ограничения, которые выражены не только отдельными элементами, а всеми, учитывая и сочетания между ними

1. В каждый взятый момент времени авиадиспетчер либо находится на службе, либо отсутствует {R1}.

2. Дежурный диспетчер должен быть зарегистрирован на одной станции {R3}.

3. В любой момент времени станция может управляться или не управляться одним дежурным диспетчером, авторизованным в системе {R3}.

4. Зона управления должна иметь свой трафик, управляемый точно одним дежурным диспетчером в каждый момент времени {R2}.

5. Дежурный диспетчер может управлять или не управлять трафиком в одной или нескольких зонах управления в каждый момент времени {R2}.

Какие же в хорошей модели выражены поведенческие ограничения?

Мощность и фраза на каждой стороне вот что имеет главное значение для установления точных правил. Давайте зададим несколько поведенческих вопросов. Только по-честному, положите перед собой хорошую модель и попытайтесь ответить на каждый вопрос сами. Поехали.

1. Что должно произойти, когда выходной диспетчер выходит на дежурство?

2. Если на дежурстве остался только один диспетчер, может ли этот диспетчер уйти с дежурства?

3. Если каждая зона управления курируется, может ли другой выходной диспетчер зарегистрироваться в системе?

4. Если есть 5 дежурных диспетчеров и 5 станций, что нужно сделать, чтобы отключить станцию для проведения работ по обслуживанию?

5. Если есть 3 зоны управления и 3 дежурных диспетчера, то каково максимальное число зон управления, курируемых одним и тем же дежурным диспетчером?

6. Если предположить, что есть хотя бы один экземпляр зоны управления и только один дежурный диспетчер, то может ли этот дежурный диспетчер уйти с дежурства?

А теперь проверьте себя. Вот как правильно.

1. Чтобы стать дежурным, необходимо войти в доступное место службы станция дежурства. Элемент выходной диспетчер будет удален и заменен новым элементом дежурный диспетчер, ссылающимся на тот же элемент диспетчера. (Добавочно обратите внимание во встраиваемых системах создание и удаление внутри модели иногда производится предварительным выделением области памяти и переключения бита, чтобы показать, действительно ли данный элемент существует. Так что существуют и другие способы реализации создания/удаления, отличные от конструкторов и деструкторов.)

2. А вот в этом вопросе больше одного правильного ответа. Каждая из зон управления требует курирования. Допустим, у нас существует один или несколько экземпляров зоны управления, тогда ответом будет нет. Невозможно перенести элемент дежурный диспетчер, не нарушив левую сторону связи R2, если только количество экземпляров зоны управления не равно нулю. Тогда ответом будет да. Если бы был только один другой дежурный диспетчер, то зоны управления можно было бы сначала передать, но в данном случае этого нет, так что это не вариант.

3. Да, может. Дежурный диспетчер не обязан курировать какие-либо зоны управления. Следовательно, число дежурных диспетчеров ограничивается только наличием станций.

4. Поскольку имеется равное число станций и дежурных диспетчеров, мы можем предположить, что каждая станция используется. Поэтому нам нужно, чтобы дежурный диспетчер вышел из системы, но для этого нам нужно снять ATC с дежурства. И чтобы сделать это, мы должны сначала убедиться, что все зоны управления, руководимые этим дежурным диспетчером, сначала будут переданы другому дежурному диспетчеру.

5. Три. Для дежурного диспетчера допустимо иметь в ведении 0 зон управления, поэтому один из них может управлять всеми тремя зонами. В этом случае у двух других дежурных диспетчеров не будет назначенных зон управления. Главное убедиться, что каждая зона управления курируется.

6. Нет. Один из выходных диспетчеров должен сначала стать дежурным, а потом уже все зоны управления должны быть переданы.

Давайте снова с иллюстрацией, которая нужна для хорошей модели. Вот дежурный диспетчер уходит с дежурства

Заполненные таблицы диспетчеров при этом обновляются вот так:

Авиадиспетчеры

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

В четвертой статье рассмотрим пример плохой модели и ее отличий от хорошей.

С переводом помогали: Бюро переводовAllcorrect

Редактор: Алексей@Sterhel Якшин