How to Build Articulate Class Models and get Real Benefits from UML

Leon Starr, Software Model Engineer, Model Integration, LLC., www.modelint.com, San Francisco, California, USA

Изложение в pdf http://www.uml.org/HTB_Articulate_Class_Models_OMG.pdf

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

Кратко у плохой модели следующие преимущества и недостатки: [+] Она работоспособна, то есть её недостатки не ломают её. [+] Она быстрее строится [-] В ней возможно использование неверных конфигураций, и эти конфигурации будут использоваться на следующих этапах, что может привести к некорректной работе. [-] Время сэкономленное за счет отсутствия ограничений может быть потрачено на дебаг ошибок, возникших из-за их отсутствия.

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

Причины использования uml диаграмм

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

Причины по которым ограничения удобно ставить в моделях класса:

1)Многие правила легко и более эффективно выражается в модели класса. 2)Правила в модели класса весьма заметны для пользователей и экспертов приложений. 3)Увеличение видимости. 4)Как правило более простая проверка правил в статических конструкциях. 5)Возникнет меньше правил в действиях. 6)Проще обновить, настроить. 7)Конфигурируемость и жесткий соблюдение основных принципов. 8)В процессе построения модели разработчик лучше поймет и структурирует все детали.

Отслеживаем несколько самолетов летающих вокруг аэропорта и хотим избежать их столкновения и контролировать их. Приложение должно хранить информацию о каждом самолете.

Aircraft

Получили абстракцию в виде uml класса, на данном этапе мы оторваны от конкретного языка программирования.

В данной ситуации возникают правила, например, минимальное расстояние между самолетами.

Ограничение {I} показывает, что значения tail number не повторяются.

Давайте теперь сконцентрируемся на пустой таблице, и поймем какие правила необходимо ввести.

1) У каждого самолета уникальный номер

2) Нет двух самолетов с одинаковым номером

3) Каждый самолет имеет высоту надо уровнем моря

4) Каждый самолет имеет курс

5) Каждый самолет имеет скорость

Правила 1-2 уже заданы, 3-5 следствие реляционного правила о заполненности каждой ячейки.

Далее, введем новые атрибуты для самолета, обобщающие предыдущие, они помогут более ясно описать класс.

Aircraft

/ показывает, что значением будет отношение

Рассмотрим хорошую модель, учитывающую ограничения.

Также для построения хорошей модели работы аэропорта, нам необходим класс Air Traffic Controller

А также класс On Duty Controller

Идентификаторы R1 и R3 ссылочные атрибуты.

Также введем класс Control zone

Для каждой зоны управления имеется уникальное имя, кол-во трафика и присвоенный ATC.

Введем класс Duty Station

Ссылочный атрибут здесь не указан, но он был уже указан в таблице Duty Controler. То есть мы сможем ответить на вопросы и серии «Сколько лет человек вошли в станции S2?»

Правила выражающие хорошую модель аэропорта

1)Контролер воздушного движения либо включен, либо выключен{R1}

2)Исполнитель обязанностей должен быть зарегистрирован в одной из duty station.{R3}

3)В любой момент времени Duty station может или не может управляться одним duty controler.{R3}

4)Control zone должна иметь только одного duty controler в любой момент.{R2}

5)Duty Controller может или не может быть направлять трафик в одной или более Control Zone на все время. {R2}

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

1)Что должно произойти, когда внеслужебное контроллер становится на дежурстве?

И ответ на него 1) Для начала дежурства необходимо войти в доступную станцию и обновление дежурного предыдущий экземпляр duty controler будет удален.

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

Переходим к плохой модели.

Это то же самое приложение, но совсем другая модель. Поверхностное сравнение покажет следующее различия.

1) Меньшее количество классов и отношения

2) Более короткие и неполные имена на ассоциациях

3) Отсутствие ссылочной атрибута или метки идентификатора

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

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