Слабости объектно-ориентированного подхода

Объектно-ориентированному процессу обычно не хватает одной важной детали: устойчивости данных. Структурыданныхпоопределениюобъектно-ориентированы.

[...] Тем не менее, если целевая система управления базами данных (СУБД) – реляционная, что сейчас является типичным случаем, отображение (mapping) провести не так просто. По этой причине часто применяются традиционные техники моделирования данных – создание логической и физической моделей данных.

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

Предложено несколько решений проблем моделирования уровня данных – и почти все имеют некоторый объектно-ориентированный «оттенок». Они включают профили или языки DSL, не основанные наUML. Но все они упускают некоторые важные детали, когда дело доходит до собственно решения проблемы моделирования данных:

1. Мы продолжаем использовать прецеденты (usecase, варианты использования) как основной инструмент захвата процессов и данных, а для них нет способов проверки достоверности и верификации. Далее, недостаточно точныепрецеденты являются неполными, и от них мало пользы; а излишне подробные прецеденты вызывают при реализации склонность к принятию технологически необоснованных и преждевременных решений, хотя являются документами [лишь] стадии анализа.

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

3. Как указывает Терри Хэлпин (TerryHalpin) [43], мы должны учитывать, что реляционная модель, применение которой мы оправдываем (сознательно или нет), использует нестабильные по своей природе атрибуты; она требует дополнительных способов описания ограничений (для атрибутов и отношений); она склонна предполагать/навязывать бинарные отношения, вводя неестественные способы описания предметной области и искусственные элементы/сущности, заделывающие ее собственные дыры; а модели «сущность-связь» являются слегка «навязанными» (auto-explicit) для большинства людей.

К счастью, все не так плохо. Существуют предложения, такие как моделирование ролей объектов (objectrolemodeling,ORM⁴), которые хоть и не новы (они существуют с 1970-х), но могут стать «свежей кровью» в поисках новых лидеров для сражения с проблемой нехватки эффективных, верифицируемых, методичных и поддерживающих автоматизированные средства структур моделирования данных.

Ответы на вопросник будут следующими:

1. Да.

2. Да.

3. Да.

4. Да.

5. Да.

6. Да.

7. Да.

4.2.9. СпецификацияUMLв общем полу-формальна. Эта нехватка точной семантики может привести к серьезным проблемам, таким как различные или неточные интерпретации. [44]

Разве не ужасно, что язык, который должен помогать разработчикам и/или проектировщикам описывать внутренности программы, не имеет синтаксического словаря, который можно было бы считать общим? ДэйвТомас (Dave Thomas)пытаетсяобъяснить, почему так получилось:

UMLпрекрасно обосновался в OMG. Язык казался таким простым, что не было нужды беспокоиться, были ли уже работающие реализации. [Так как]он был ясно определен в изображениях и знакомых концептах, не было нужды в серьезном описании семантики.

Все казалось таким невинным, простым и очевидным: стандартизовать нотации объектно-ориентированного моделирования, чтобы методологам и разработчикам не приходилось спорить о том, как символически обозначаются классы, методы и т.д. Большинство из нас вздохнули с облегчением, посчитав, что глупым и, по нашему мнению, вредным спорам о нотации пришел конец, и лишь немногие были обеспокоены правильностью найденного ответа. [45]

Но OMG осознала этот недостаток и искала способ его устранения; самой явной попыткой стал язык ограничений объектов (ObjectConstraintLanguage, OCL) [46], дополняющий UML с версии 1.4 и состоящий из формального языка описания ограничений и (в основном с версии 2.0) запросов.

Хотялично я, учитывая, что это предикативный и декларативный язык, не считаю очевидным решение о его использовании для описания операций.

Есть также люди вроде Луиса Рейносо (LuisReynoso)и других [47], организовавших эксперименты; они собрали статистические данные, подтверждающие, что это не ясный язык, недостаточно ясный даже для описания ограничений (что является его первоначальной задачей), и что существуют проблемы с легкостью изучения и способностью к сжатию – очередной прыщ на плоскости общей семантики UML.

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

В документе спецификации [4, 5] конструкции UMLвключают раздел, озаглавленный «Семантика», который просто не справляется с возложенной на него задачей объяснения значения и использования каждой конструкции, или же делает это очень расплывчато. Например, относительно заметки, или комментария (небольшого квадрата, один из верхних углов которого загнут), раздел «Семантика» говорит буквально следующее:

Семантика: комментарий не дополняет элемент семантически, но может представлять полезную читателю модели информацию. [4]

Если мы немного обдумаем эти слова и поищем примеры его эффективного использования, мы увидим, что:

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

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

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

· И много-много других случаев.

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

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

Ответы на вопросник будут следующими:

1. Да.

2. Да.

3. Да.

4. Да.

5. Нет.

6. Да.

7. Да.

Результаты и заключения

Вразделе «Классификация» предложеныподходы, помогающиепонятьизъяныUMLвсоответствиисих симптоматикойи серьезностью. Эти подходы выражены с помощью списка простых вопросов, в котором серьезность недостатка возрастает с каждым следующим вопросом, и утвердительный ответ серьезнее отрицательного.

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

Таблица 2 –Обобщение изъянов UML

Каждое «Да» было изменено на «X», была добавлена новая колонка с их суммой по строкам (чем их больше, тем серьезнее недостаток). Затем получившаяся таблица была упорядочена по значению в новой колонке, давая в результате таблицу 3.

Таблица 3 –Обобщение изъянов UML, упорядоченных по серьезности

Прежде чем делать какие-либо выводы, отметим, что они не учитывают всей критики, полученной UML – только ту, что была лучше аргументирована (более чем одним автором) или очевидна.

Итак:

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

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

Изъян в сфере общего применения требует самого серьезного отношения, необходимо его срочное устранение любой ценой.

2. Все изъяны начинают с «погрома» в научной сфере, а затем переходят к коммерческой. То, что сегодня является проблемой прототипа, завтра становится проблемой индустрии.

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

4. Изъяны, не касающиеся сфер общего применения, всегда требуют для своего устранения изменения существующих артефактов; более того, они провоцируют создание новых артефактов и, как правило, новых подъязыков, профилей или языков DSL.

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

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

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

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

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

Программная и инженерная индустрии входят в состояние неопределенности, схожее с имевшим место в 80-90-е годы перед официальным появлением UML, отчасти лишающее нас способности предвидеть развитие или стагнацию, что могут ждать нас в будущем. Однако я верю, что время не потрачено зря, что мы исправим наши прежние ошибки и станем свидетелями плодов общих усилий – или нового языка (может, UML 3, а может, OML 2 [22]), или ряда языков, которые, хоть и будут братьями, получат собственную специализацию. В конце концов, тогда мы сможем сказать, что правда развились, технологически и человечески.

Да будет так.

Сноски

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

2. Это просто пример техник, которые упомянуты, что можно понять лишь по прочтении всего текста, который я, из-за ограничений места, не привожу.

3. Ирония в том, что книга, на которую ссылается Бен Эттлингер (BenEttlinger) не считается хорошей, в соответствии с записью вhttps://www.accu.org/bookreviews/public/reviews/u/u003393.htm, где она расценивается как НЕ РЕКОМЕНДОВАННАЯ. Хотя, несомненно, онанеединственная, ида, естьдругиеработы, превосходноописывающиеиспользованиеUMLкак нотации данных. Например:

· “Object Relational Wrappers” (Lee Fesperman)

· “The UML and Data Modeling” (Rational Software)

· “Mapping Objects to Relational Databases” (Scott W. Ambler)

· “Expressiveness in Conceptual Data Modeling” (A. H. M. TerHofstede and Th. P. Van Der Weide)

4. Лучшееместодляпоискаресурсовпоэтойтеменаходитсяна https://www.orm.net.

5. Ссылки сделаны автором.