mdd:todo

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
mdd:todo [2016/12/25 12:39] – created sultanisalymdd:todo [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 1: Line 1:
  
 +====== 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 
 +
 +/ показывает, что значением будет отношение
 +
 +**Хорошая модель**
 +Рассмотрим хорошую модель, учитывающую ограничения.
 +
 +{{:mdd:im1.png?200|}}
 +
 +Также для построения хорошей модели работы аэропорта, нам необходим класс 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 будет удален.
 +
 +В итоге получаем, что хорошая модель позволяет  избежать ошибок в последующей части работы, и экономит время на тестирование и дебаге.
 +
 +**Переходим к плохой модели **
 +{{:mdd:im2.png?200|}}
 +
 +Это то же самое приложение, но совсем другая модель. Поверхностное сравнение покажет следующее различия.
 +
 +1) Меньшее количество классов и отношения
 +
 +2) Более короткие и неполные имена на ассоциациях
 +
 +3) Отсутствие ссылочной атрибута или метки идентификатора
 +
 +4) менее точные типы данных Некоторые правила применения отсутствуют, и даже указано неправильно.
 + 
 +**Вывод**
 +То есть в итоге можно сделать вывод, что модель с наличием ограничений более безопасная, и надежная. Модель без них меньше и позволяет экономить ресурсы, однако есть опасность потратить больше времени на тестирование и дебаг.