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

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

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

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

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

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

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

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

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

Aircraft

Tail Number {I}

Altitude

Speed

Heading

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

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

TailNumber{I} Altitude Speed Heading

N17846D 8,000 ft 135 mph 178 deg

N12883Q 12,300 ft 240 mph 210 deg

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

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

Tail Number{I} Altitude Speed Heading

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

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

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

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

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

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

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

Aircraft

TailNumber{I} Altitude Speed Heading Latitude Longitude /Climb Rate

TailNumber{I} Altitude Speed Heading Lat Long /Climb Rate

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

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

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

ID{I} Name Date_of_birth Rating

ATC53 Toshiko Jun 12,1975 A

ATC67 Gwen Mar 28,1981 B

ATC51 Owen Dec 23,1974 C

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

ID{I,R1} Time_logged_in Station{R3}

ATC53 9/27/08 3pm S2

ATC67 9/27/08 11am S1

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

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

Name{I} Traffic Controller{R2}

CZ1 12 ATC53

CZ2 4 ATC53

CZ3 8 ATC67

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

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

ID{I} Location Capacity S1 Front 20

S2 Front 45

S3 Center 30

Ссылочный атрибут здесь не указан, но он был уже указан в таблице 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) менее точные типы данных Некоторые правила применения отсутствуют, и даже указано неправильно.

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