UML: Панацеяилиболезнь?
Guillermo Camilo Torres Díaz
National University of San Agustín of Arequipa—Perú
gtorres@unsa.edu.pe
Сентябрь 2008
Относитсяк:
UnifiedModelingLanguage
Резюме: Мыужезнаем, чтоунифицированныйязыкмоделированиянесовершенен; но насколько велико это несовершенство? Эта статья пытается ответить на этот вопрос; используя работы разных исследователей (выявляющих и изучающих дефекты UML), она обнаруживает серьезные несовершенства в нем как целом. Наконец, она объясняет, почему необходимы срочные изменения либо в механизмах расширяемости языка, либо – что лучше – создание пакета языков моделирования. (19 печатных страниц)
Содержание
· Введение
· Обзор фактов
· Классификация
· Разделяй и поражай: цель
· Результаты и заключения
· Сноски
· Список интернет-источников
Введение
UML, появившисьВ 1990-х [1], становится вехой в истории разработки программного обеспечения; его создание отмечает начало эры, в которой методологи, разработчики, исследователи и менеджеры пользуются (по крайней мере) одними и теми же элементами работы и разработки – одним словарем.
Несмотря на то, что в начале он удовлетворяет многие нужды, предоставляя конструкции, которых формально достаточно для использования при разработке различных процессов (особенно касающихся программного обеспечения); и хотя он является де-факто стандартом для разработки объектно-ориентированных систем [2] и официальным стандартом ObjectManagementGroup (OMG), сегодня UML недостаточен.
В следующем разделе, «Обзор фактов», мы рассматриваем историю языка. Затем, в разделе «Классификация», мы объясняем классификацию, которая будет использоваться в таксономии его изъянов;все они приводятся в разделе «Разделяй и поражай». Мы заканчиваем разделом «Результаты и заключения», а также соответствующими соображениями.
Обзор фактов
В свое время UML стал ответом – естественной реакцией индустрии на распространение множества различных методологических течений в разработке программного обеспечения в 1980-х и 1990-х. Действительно, в своем обзоре ОО-методов Йен Грэхэм (IanGraham) приводит их более 50 [9] – каждый со своим языком, иконографией, цветами и даже, можно сказать, со своим гимном – причем ни один из них не характеризуется как лучший. Даже Гради Буч (GradyBooch) упоминает, что UML был создан именно как объединяющая сила, которая была единогласна принята как стандарт OMG в ноябре 1997 года. «Этот язык ввел стандартную нотацию и фундаментальную семантику, дав своим пользователям возможность описывать и сообщать проекты программ, как никогда раньше.»[3]
(Врезка 1)
Проверяем нактоуз
РазработкаUMLначинаетсяв конце 1994 года, ГрадиБучиДжимРамбо (JimRumbaugh) изRationalSoftwareCorp.начинаютработатьнадунификациейсвоихметодов (БучиOMT:ObjectModelingTechnique (Техника моделирования объектов)) зимой 1995-го; книмпозжеприсоединяетсяИварЯкобсон (IvarJacobson) со своейкомпаниейObjectoryиееметодомOOSE (Object-OrientedSoftwareEngineering, объектно-ориентированная программная инженерия), после чего они станут известны как «три друга».
Результатом усилий Буча, Рамбо и Якобсона стал UMLверсии 0.9 в июне и 0.91 в октябре 1996 года. В течение 1996 года авторы UMLмотивировали сообщество делиться своими соображениями. Полученные на протяжении 1996 года отзывы сообщества были учтены, но было ясно, что проекту требуется еще большее внимание.
События 1996 года доказали, что многие организации видели в UMLстратегическую ценность для своего бизнеса. Запрос предложения (RequestforProposal, RFP), изданный ObjectManagementGroup (OMG), стал катализатором объединения сил организаций в подготовке единого ответа на этот запрос. Rationalосновала консорциум UMLPartners, несколько компаний-членов которого выразили желание предоставить ресурсы для работы над основательным определением UML 1.0.
ВнеговошлиDigital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI иUnisys. Это сотрудничество привело к созданию UML 1.0, языка моделирования, очень хорошо определенного, выразительного, мощного и подходящего для общего применения; он был представлен OMGв январе 1997 как первоначальный ответ на упомянутый запрос предложения.
Такжевянваре 1997 IBM, ObjecTime, PlatinumTechnologyиSofteam также представили отдельный ответ на данный запрос. Затем эти компании объединились в консорциум и предложили свои идеи; консорциум создал пересмотренную версию ответа: UML1.1.
Подход UMLверсии 1.1 прояснял семантику UML 1.0и учитывал вклад новых партнеров.
Он был представлен на подтверждение и рассмотрение в OMGи принят зимой 1997.
Обобщение статьи OMGNEWS
https://omg.org/news/pr97/umlprimer.html
Уместно упомянуть, что Мартин Фаулер (MartinFowler) – в более детальном описании событий среды, приведших к созданию этого стандарта – разъясняет, что первая версия, которую они представили в OOPSLA (в октябре 1995) называлась «унифицированный Метод», являлась результатом работы Буча и Рамбо, версией 0.8, до присоединения Якобсона.
(МартинФаулериКендаллСкотт (Kendall Scott); UML Distilled Second Edition: A Brief Guide to Standard the Object Modeling Language)
OMGопределяетUMLкак:
Визуальный язык спецификации, конструирования и документирования механизмов систем. Это язык общего назначения, который может использоваться с большинством методов объектов и/или компонентов, во всех сферах применения (например, здравоохранения, финансов, телекоммуникаций, аэрокосмической) и платформах реализации (например,J2EE,.NET). [4]
Не все его компоненты в равной степени важны, но все они заслужили одинаковое внимание OMG, которая принимала новые подверсии с изменениями, или добавлениями их самих или их семантики, пока не была выпущена версия 2 (в текущей подверсиии – 2.2). Это обозначило начало создания нового лица языка, настолько значительное, что теперь при его упоминании было необходимо отличать версии 1 .x от версии 2.
Таблица 1 приводит список диаграмм версии 2 .x и ее отличий от версии 1. x.
Таблица 1 –Список диаграмм с соответствующими эквивалентами версий UML
| Множество диаграмм | Диаграмма | ||
| Тип | Подтип | UML 1.x | UML 2.x |
| Structure diagrams (Структурные диаграммы) | Class Diagram (Диаграмма классов) | ||
| Objects Diagram (Диаграмма объектов) | |||
| Components Diagram (Диаграмма компонентов) | |||
| Deployment Diagram (Диаграмма развёртывания) | |||
| Package Diagram (Диаграмма пакетов) | |||
| - | CompoundStructureDiagram (Диаграмма составной/сложной структуры) | ||
| Behavior Diagrams (Диаграммы поведения) | Interaction Diagrams (Диаграммы взаимодействия) | Sequence Diagram (Диаграмма последовательности) | |
| - | General Diagram of Interaction | ||
| - | Communication Diagram | ||
| - | Time Diagram | ||
| Activity Diagram (Диаграмма деятельности) | |||
| Use Case Diagram (Диаграмма прецедентов) | |||
| State Diagram (Диаграмма состояний) | StatemachineDiagram (Диаграмма конечного автомата) |
Классификация
UMLимеетразноезначениедлякаждогоизнас.Вот почему можно составить множество различных классификаций и таксономий изъянов –сделанных по ошибке или недосмотру – которые каждый может в нем найти. По этой причине я ищу промежуточную точку зрения, в которой принимаются во внимание графическая часть и семантика языка, с простыми подходами, которые помогут нам описать и понять каждый отдельный изъян.
Эти подходы выражены в виде списка простых вопросов, в котором серьезность изъяна возрастает при положительном ответе на каждый следующий вопрос.
Вопросыследующие:
1. Касается ли изъян сферы общего применения?
2. Проявляется ли изъян в основном при применении в академической (научной) сфере?
3. Проявляется ли изъян в основном при применении в коммерческой сфере?
4. Подразумевает ли изъян недостаток (или несколько) в некоторых аспектах, не относящихся лишь к графическому представлению?
5. Входит ли в список предложений изменение одного или более артефактов или создание новых элементов диаграмм?
6. Подразумевает ли изъян неоднозначность или недостаток семантического описания?
7. Входит ли в список предложений создание одного или нескольких новых средств?
Разделяй и поражай: цель
С предложенными подходамимы будем способны в общих чертах понять, насколько серьезны недостатки или слабости этого языка. Помня об этом, рассмотрим список недостатков и слабостей, выделяемых в имеющихся исследованиях.
Список
4.2.1. UMLнепредлагаетподходящихконструкцийдляфреймворков
Фреймворк это коллекция нескольких полностью или частично реализованных компонентов с предопределенными паттернами кооперации между ними. Поэтому некоторые компоненты разработаны так, чтобы быть заменимыми. Эти компоненты называются точками вариации или «горячими» точками фреймворка.
Приложение, основанное на некотором фреймворке, повторно использует не только его исходный код, но и, что более важно, его архитектурный дизайн. Конструкций, предоставленных UML, недостаточно для содействия разработке фреймворка. Не существует способа (естественного или явно выводимого) указать в диаграммах UMLточки вариации или ограничения инстанцирования[их экземпляров]. [6]
Объектно-ориентированные фреймворки обрели популярность в индустрии разработки программного обеспечения в 1990-х. Многие были разработаны в коммерческой и научной сферах, сильно различаясь по целям и областям применения. Фреймворки, объединенные с компонентами, тогда, как и сейчас, обещали широкие возможности повторного использования. [7]
Если у фреймворков есть такой потенциал, становится важным иметь возможность описывать их эффективным, формальным и структурированным образом, без допущения «утопания» их модульности и характерной семантикив множестве конструкция, обозначаемых «стереотипными».
Итак, ответы на вопросник будут следующими:
1. Да, фреймворки уже используются повсеместно; нет специализированной и уникальной ниши, использующей их единолично.
2. Да, они применяются и преподаются в научных областях.
3. Да, ониприменяются в индустрии в целом.
4. Нет, фреймворки уже учтены в языке, но образом, не подходящим для их представления и объяснения системной архитектуры.
5. Да, решения предлагают изменения артефактов, особенно диаграммы классов.
6. Нет.
7. Нет, они предполагают обогащение уже существующих.
4.2.2. UMLнедостаточенкакстандартныймеханизмобеспечения интероперабельности CASE-средствприинтеграцииприложенийобходногоинжиниринга.
СUMLCASE-технология достигла следующего уровня зрелости: согласованность общей нотации помогает и издателям, и разработчикам сконцентрироваться на более важных вещах, чем решение проблем вроде «как рисовать стрелки» или «как отображать классы – в виде треугольников или облаков».
Одной из этих более важных вещей является понятие обходного инжиниринга (roundtripengineering, вариант – «двунаправленный инжиниринг»). Оно подразумевает, что программист создает код из диаграмм проекта, изменяет этот код – при необходимости – в отдельной среде разработки и имеет возможность пересоздать диаграммы проекта так, чтобы они отражали этот код. Противоположный процесс также возможен.
Такой способ объектно-ориентированной разработки особенно проявляется в итеративном процессе, что, несомненно, делает обходной инжиниринг очень важным моментом. В действительности же, так какUMLориентирован на объектно-ориентированные проектирование и разработку, ему недостает некоторых концептов, необходимых для моделирования исходного кода должным образом – в частности, концепта «вызова метода»или «доступа к атрибуту».
Конечно, возможно расширить UML, чтобы внедрить эти концепты; но тогда придется отказаться от защиты стандарта, а значит, и надежности, необходимой для обеспеченияинтероперабельности. [8]
Ужев 1970-хвозможностьполучить весь исходныйкодсистемыпростоизанализаидиаграммпроектабылаимечтойразработчиков, ихимерой, предлагаемойвсемипоставщиками –так и оставшейся, впрочем, незавершенной. Средипрочих, СтивенМеллор (StephenMellor) идругие[11] объявляли, чторешилипроблемунехваткисемантикиUML, чтобы иметь возможность разрабатывать средства, генерирующие не просто очертания или каркас исходного кода, но весь исходный код любого приложения, смоделированного с использованием его языка xtUML, производного/подмножества UML, дополненного языком OCL (ObjectConstraintLanguage, язык ограничений объекта)
Лично я не думаю, что этого может быть достаточно; OCL это язык выражения ограничений – декларативный язык, не выражающий действий. Одной из альтернатив было его дополнение языком OAL (ObjectActionLanguage, язык действия объекта), но она все еще находится на стадии изучения.
Прежде чем продолжить, следует понять, что проблема интероперабельности двояка. С одной стороны, UML сам по себе не обеспечивает достаточно глубокое покрытие исходного кода; поэтому любые изменения в наших моделях вызывают изменения в нем (исходном коде). К тому же изменения, производимые нами в исходном коде не обязательнобудут обнаруживаться нашими средствами автоматизации (CASE или карандашом и бумагой), стремящимися отразить изменениями модели. С другой стороны, хотя это и второстепенно, существует проблема взаимодействия различныхCASE-средств:
(а) Ни одно из них не покрывает всех элементов языка (особенно сейчас, с его расширением) и (б) даже покрытие одной и той же области они производят с различной детализацией. Также, хотя и ведутся работы в этом направлении, такие как CASEDataInterchangeFormat (CDIF, формат обмена данными CASE), MetaDataInterchangeSpecification (MDIS, спецификация обмена метаданными) или новейший, предложенный OMGв 1999 году,MetadataInterchangeFormat (XMI, формат обмена метаданными), мы все еще не можем открыть в одном из них модель, созданную в другом, не потеряв некоторую часть информации – если она вообще загрузится.
Из-за ограничений CASE-средств при разработке систем, помимо высокой цены наиболее сложных (и полезных)из них, количество пользующихся ими разработчиков, невелико; поэтому не так много и тех, кто почувствует недостаток, описанный в этом пункте.
Ответы на вопросник будут следующими:
1. CASE-средства не используются так широко, чтобы можно было говорить об их всеобщем применении.
2. Нет; CASE-средства, хотя они и используются, не получили широкого распространения в научной среде.
3. Да; они активно продвигаются в индустрии, и некоторые компании полагаются на них.
4. Да; дело здесь в недостатке не графики, а совершенно другого уровня семантики и некоторого типа синтаксического управления конструкциями.
5. Да, решение предполагает изменения в существующих артефактах.
6. Да; серьезная нехватка таких концептов как, например, «доступ к атрибуту» и «вызов метода».
7. Да; для решения этой проблемы были предложены не только новые артефакты, но и новые языки.
4.2.3. UMLнепозволяетсохранятьдополнительнуюинформацию, относящуюсякпаттернам.[10]
Паттерн проектирования описывает общее решение проблемы, имеющей место во многих проектах. Проектировщики программного обеспечения адаптируют решение паттерна к конкретному проекту. Паттерны проектирования обычно моделируются в UML. Однако UMLне позволяет приводить дополнительную информацию о применении паттерна или вхождении в его состав других паттернов. Поэтому разработчикам сложно идентифицировать паттерны проектирования в моделях программных систем. Преимущества паттернов проектирования подвергаются опасности, потому что разработчики не могут общаться друг с другом, используя терминологию паттернов, которые они используют, или принимаемых конструкторских решений (…), так как конструкции, предлагаемые стандартом, недостаточны для их идентификации в приложениях и композициях.
Элементы паттерна – классы, операции и атрибуты каждого из них – в общем случае играют роль, провозглашенную в их именах. Однако применение паттерна может включать изменение имен классов, операций и атрибутовтерминами, соответствующими области применения. Поэтому информация о роли паттерна теряется, становится неясным, какие элементы модели участвуют в паттерне. UML не позволяет приводить дополнительную информацию, относящуюся к паттерну, когда паттерн применяется в программной системе. [10]
Мы используем различные диаграммы UML (или любой другой нотации) для того, чтобы иметь возможность рассмотреть систему с разных точек зрения. Сила визуализации заключается в предоставлении внутренней перспективы сложных отношений между данными, усложняющихся по мере роста систем.
Мы должны разделить все то множество информации, с которым нам приходится иметь дело при разработке системы, чтобы иметь возможность выбирать наиболее важные элементы. Как сказал Стефан Зигфрид (StefanSigfried), «на сложность влияет не само число деталей, но число деталей, которые мы должны учитывать одновременно».[14]
Мы должны иметь возможность визуализировать конструкции, используемые при реализации определенной системы – тем более, если она включает специализированные конструкции вроде паттернов проектирования, – чтобы после определения они могли обсуждаться, повторно использоваться или заменяться при необходимости. Мы должны иметь возможность указывать, какой тип паттерна использован в некоторой части подсистемы покупок или почему и как мы использовали паттерн «одиночка» (singleton)вместо «абстрактной фабрики» (abstractfactory).
Это примеры типов оценок, которые мы обычно делаем, и проектировочных решений, которые мы принимаем как архитекторы/разработчики и которые желательно передавать просто и с сохранением целостности.Если по диаграмме нельзя с первого взгляда определить, какой паттерн (ошибка в оригинале–patron вместо pattern) мы используем, или как один класс участвует в более чем одном паттерне, нам, возможно, придется дорабатывать наш проект и, по крайней мере, дополнить его документами, объясняющими нашу работу новым коллегам или инвесторам, – делая диаграммы и эти дополнительные документы взаимозависимыми.
Так как дополнительная документация – это роскошь, которой еще и сложно обладать, возможно, нам следует придерживаться решения, предложенного авторами, обнаружившими этот изъян [10], или схожими [12, 13]; хотя они дороги с точки зрения пространства и разработки, они помогут, по крайней мере, удовлетворить нашу нужду и в ясности, и простоте.
Ответы на вопросник будут следующими:
1. Да, применение в этой сфере становится все более широким.
2. Да, это в полной мере научная тема.
3. Да, эта область очень активно продвигается в индустрии.
4. Нет; в основном, дело в графическом отображении информации о паттернах, обеспечении возможности использования преимуществ заключающихся в них решений.
5. Да, артефакты будет нужно обогатить.
6. Нет; паттерны включены в спецификацию языка, и для каждого паттерна имеется документация, созданная с основательным использованием UML.
7. Нет.
4.2.4. UMLнедостаточен для моделирования встроенных систем реального времени.[15, 16]
Большинство технически сложных систем – от простых контроллеров медленных процессов, построенных на дешевых процессорах, до распределенных систем, построенных на десятках мощных компьютеров, контролирующих критичные устройства, такие как машины, воздушные суда и атомные электростанции – содержат в своей основе компьютеры реального времени, контролирующие и направляющие их операции.
За прошедшее время было предложено несколько методов их анализа и разработки. На данный момент многие заинтересованы в тех из них, что являются объектно-ориентированными, из-за их «естественно» подхода к решению проблем. КнимприсоединяетсяUML, выбранныйв качествеязыкавыраженийпримоделировании этого типа систем.
Однако объектно-ориентированные методы и языки выражений изначально сосредотачиваются на описании внутреннего программного обеспечения систем и взаимодействии с внешними пользователями (людьми), игнорируя тот факт, что системы реального времени взаимодействуют в первую очередь с физической средой, которая контролирует или направляет их, и с которой они составляют практически неделимое целое, так что нельзя моделировать одно без учета другого – не говоря уже о включении физических законов, непрерывных величин, дифференциальных уравнений и переменных времени.
Будучи стандартом,UML довольствуется ролью языка выражений объектно-ориентированных методов, используемых разработчиками этого типа систем – хотя, на первый взгляд, он не вполне подходит для моделирования физических процессов.
Двумя наиболее важными недостаткамиUML, с точки зрения инженера этих систем, являются слабая поддержка потока данных и сложность описания системной архитектуры. Даже после учета этих проблем в спецификации суперструктуры UML 2.x, при всем интересе к ним инженеров аппаратной части, разумно полагать, что эффективность UML в этих областях оставляет желать лучшего.
Инженеры [таких] систем часто используют потоки данных для описания общего поведения и определения ключевых алгоритмов управляющих систем. В настоящее время единственным инструментом, на который они могут полагаться, является диаграмма деятельности, крайне ограниченно реализующая истинный поток данных и ориентированная на разработку классов, а не системы вообще. Они [инженеры этих систем] также часто беспокоятся о точности представления сложной архитектуры системы в целом, для чего едва ли подходит диаграмма развёртывания в ее нынешнем состоянии. Отсюда:
[…] Области, которые недостаточно определены в UML, включают:
- Точную семантику пассивных и активных объектов.
- Отношения между пассивными объектами и конечными автоматами.
- Избирательный характер действий вызова и отправки типа активного объекта (что может нарушать принцип инкапсуляции)
[...] Такжеследуетрассмотретьвозможностьвведенияследующиххарактеристик:
- Непрерывныепеременные
-Уравнения
-Режимработы во времениипроизводныеотнего (диапазонызначенийпеременных)
Разработка моделей систем реального времени затрагивает научные области, достаточно сложные для создания для них собственного пространства концептов и определений. В свою очередь,емунужнавыразительность, которой, ядумаю, недостичьлишьспомощьюконструкцийUML2 .x. ВотличиеотUML 1 .x, в котором специализированно можно разрабатывать только профили, с созданием UML 2 выросли возможности разработки специфических для области языков (DSL), являющихся расширениями мета-моделиUML.
Это может являться преимуществом для моделей данного типа; но относиться к данной возможности следует очень осторожно и с позиций UML, дабы не потерять защиту стандарта.
Ответы на вопросник будут следующими:
1. Нет.
2. Да.
3. Да.
4. Да.
5. Да.
6. Да.
7. Да.
4.2.5. НаданныймоментUMLнедостаточендлямоделированияагентови/илисистем, основанныхна (множественных) агентах. [17, 18]
Объектно-ориентированная парадигма представляет приложение как композицию объектов, взаимодействующих друг с другом, посылая и принимая сообщения. Объекты содержатся в классах. Далее, взаимоотношения между классами могут представляться в виде отдельных иерархий. Объекты есть реактивные сущности: они принимают сообщения и реагируют на специфические внешние события.
Агентно-ориентированная парадигма делает следующий шаг и рассматривает приложение как состоящее их одного или более автономных агентов. Все агенты постоянно принимают входные данные. Они отвечают на действия среды, в которой находятся, совершая действия, которые влияют на среду. Далее, агенты проактивны: они оценивают ситуацию и действуют в соответствии с ней. Агенты не нуждаются в сообщениях или особых инструкциях для совершения действий.
Приложения, разрабатываемые сейчас по агентно-ориентированной технологии, предназначены, в частности, для диагностики аэрокосмических дефектов; симуляции миссий; администрирования бизнес-процессов, воздушного движения, телекоммуникаций [...].
В отличие от объектов, агенты имеют цели и работают проактивно для их достижения. С одной стороны, процедуры объектов это просто процедуры, закодированные программистом для обработки различных сообщений [...]. С другой стороны, агент может синтезировать план с учетом непредвиденных программистом обстоятельств и учиться на собственном опыте [...].
В результате всестороннего исследования объектно-ориентированногопроектирования и техник анализа было обнаружено, что они не могут непосредственно применяться при разработке мультиагентных систем.
Более того, некоторые авторы описывают мультиагентные системы как особый тип распределенных систем (объектов с собственными нитями выполнения) с особыми характеристиками, имеющий более высокую сложность, чем объектно-ориентированные системы; и эта сложность вызвана объединенным поведением множества взаимодействующих простых агентов. [19] Однимизвыделяемыхаспектов этой области являетсяпроблемаассоциаций (семантики); а именно:UMLрассматривает в основном бинарные отношения – оставляя без внимания n-арные отношения поведения, которые агенты имеют между собой и с окружающей средой.
Хотя UML 2 .x вводит важные улучшения, которые могут использоваться при моделировании этого типа систем – например, параметризованные отношения сотрудничества (кооперации) или новаямодульная организация диаграмм последовательности, состояний или деятельности; и хотя предлагаемые решения включают новые профили [18, 20, 21], которые иногда предупреждают (к удивлению пользователя), что недостаточны для выполнения своего предназначения [23] – также существуют более серьезные предложения, целые методологии [24, 25] с собственными языками (иногда инклюзивными (inclusive), основанными на UML) и специфическими языками для обмена информацией и моделирования отношений между агентами (то есть протоколами [48, 49]), которые пытаются заделать все дыры, которые этот язык оставляет после себя в этой области.
Ответы на вопросник будут следующими:
1. Нет.
2. Да.
3. Да.
4. Да.
5. Да.
6. Да.
7. Да.
(Врезка 2)
DomainSpecificModelingLanguage (DSML, специфический для областиязык моделирования)
Когда мы говорим о классификации языков программирования и моделирования, становится все более полезно различать языки общего назначения (GeneralPurposeLanguage, GPL)и языки, специфические для области (DomainSpecificLanguage, DSL). Примерами универсальных языков программирования являются Smalltalk, C++ и Java. Примерами специализированных языков программирования являются YACCдля компиляторов и LISTв области ИИ. Наиболее известным примером языка моделирования общего назначения является UML. Примером специфического для области языком моделирования является SysML – подмножество UML, предназначенное для инженерных приложений.
DSMLсоздается специально для решения проблем определенной области, он не стремится и не планирует использоваться для решения проблем вне этой области.В отличие от языков моделирования общего назначения, созданных для решения проблем в любой области.
Каковы преимущества использования DSML, например SysML, вместо GPML, например UML?
Ответ, конечно, зависит от конкретного DSML, который вы проектируете или выбираете, от того, как хорошо он адаптирован для удовлетворения нужд области вашего конкретного приложения. Тем не менее, если предположить, что выбранныйDSMLподходящим образом адаптирован и реализован, мы можем рассчитывать на то, что будем иметь дело со следующими преимуществами и недостатками.
Преимущества:
· Уже построенные высокоуровневые абстракции; DSMLпредоставляет экспертам области абстракции, определенные на том же уровне их области. Следовательно, эксперты могут быстро изучать, применять и расширять DSMLбез необходимости в значительных затратах времени на обучение.
· Скрытие информации о конструкциях и безотносительных деталей. Языки DSMLне включают конструкции и детали, не относящиеся к области вашей проблемы. В результате эксперты области не отвлекаются на сущности, не подходящие для решаемой проблемы.
Недостатки:
· Стоимость разработки, реализации и поддержки.
Так как в последнее время стали доступны лишь коммерческие инструменты DSMLпервого поколения, наибольшим недостатком использования DSMLв данный момент является то, что вам придется реализовывать и поддерживать ваш DSMLсамостоятельно. Тем не менее, если вы уже используете GPML, например, UML, у вас может быть возможность создать DSMLдля вашего проекта, хотя существуют некоторые препятствия (такие, как ограниченные возможности модификации (настройки) через стереотипы UML 2).
· Отставание отGPML по возможностям генерации кода. Если автоматизированная генерация кода важна в вашем проекте моделирования, в общем случае вы обнаружите, что языки DSMLотстают по возможностям генерации кода от GPML, особенно по оптимизированности. Хотя эта ситуация улучшится при достижении зрелости инструментов GPML.
PivotPoint Technology Corp.
* Некоторыеавторыупотребляютаббревиатуру «DSL» (DomainSpecificLanguage, специфический для области язык), подразумеваяDSML, но это обобщение неоднозначно, ведь также существуют специфические для области языки программирования.
4.2.6. UMLнедостаточен для разработки аспектно-ориентированных систем.[26, 27]
[...] Цельюсистемыявляетсяудовлетворениетребованиямили, вболееобщемсмысле, интересам (интерес – что-либо, заботящее акционера, будь это конечный пользователь, спонсор проекта или разработчик…)
[...] Затем идет декомпозиция проблемы на меньшие отдельные модули1 – часть процесса, называемого в компьютерной науке «разделением обязанностей».
В идеале мы хотим иметь возможность аккуратно разделить различные обязанности между модулями некоторого вида и исследовать и разрабатывать каждый из них отдельно, по одному за раз. Впоследствии мы объединяем эти программные модули для получения целой системы. Таким образом, концепт разделения обязанностей и концепт модульности есть две стороны медали. Однако существует возможность того, что существующие техники (например, ориентация на объект в общем2) не дают возможности разделения на модули.
Причиной сложности содержания этих свойств в различных модулях является их влияние (то есть пересечение)на большое количество других свойств, составляющих систему(то есть пересечение с ними). По этой причине они известны как пересекающиеся интересы, проявляясь в (а) разрозненном коде, когда реализация каждого отдельного свойства не содержится в одном модуле, и (б) связанном коде, когда каждый модуль содержит информацию о нескольких различных свойствах. Результатом является приложение, очень сложное для понимания, поддержки и дальнейшегоразвития. Общими примерами пересекающихся интересов являются некоторые нефункциональные требования, например, распределение и безопасность.
Код, реализующий каждое из этих свойств, не может быть инкапсулирован в единственный класс и обычно разделяется между несколькими классами.
Аспектно-ориентированная разработка программного обеспечения (Aspect-orientedsoftwaredevelopment, AOSD) имеет целью решение проблемы пересекающихся интересов, предоставляя средства для их систематической идентификации, разделения, представления и композиции.
Пересекающиеся интересы инкапсулируются в отдельных модулях, называемых аспектами, что может повысить локализацию. Результатом является лучшая поддержка модульности, что снижает затраты на разработку, поддержку и дальнейшее развитие.
Хотя AOSD и стала темой важных исследований в последние годы, было уделено недостаточно внимания методам оценки аспектно-ориентированных проектов и их реализаций. В общем, в литературе рассматриваются только некоторые изолированные случаи оценки реализаций AspectJ, сосредотачивающихся на проблемах разделения обязанностей. Так происходит в основном потому, что очень сложно оценить влияние множества факторов без использования систематического анализа и средств поддержки. В результате программные инженеры предположили, что свойством, оказывающим наибольшее влияние на аспектно-ориентированные системы, является разделение обязанностей.
Тем не менее, некоторые новейшие исследования [28, 29]5 показали, что нужно учитывать и другие фундаментальные принципы разработки программного обеспечения помимо этого разделения.
Даже когда эти авторы не говорят прямо – как Янь Хань (YanHan) и другие [30] – что UML 2 .x не поддерживает аспектно-ориентированное моделирование, они позволяют понять причину этого: общая теория объектно-ориентированной разработки во времена создания UML не подходила (и едва ли подходит сейчас) для решения проблем пересекающихся требований (или интересов); следовательно, UMLмыслимыйлишь в терминах объектов и компонентов, все еще не может предложить элементы выражения этого нюанса в развитии общей теории объектно-ориентированной разработки.
Это усиливается тем фактом, что решения, предлагаемые разными авторами в данной ситуации, простираются от (я должен их упомянуть) расширений и профилей UML до (и таких большинство) новых языков [30, 31, 32, 33], основанных на мета-моделиUML. Конечно, то, что они основаны на одной и той жемета-моделиUML, не обязательно делает их совместимыми с ней.
А ответы на вопросник будут следующими:
1. Нет.
2. Да.
3. Нет.
4. Да.
5. Да.
6. Да.
7. Да.
4.2.7. UMLникак не поддерживает моделирование графического интерфейса пользователя.[34]
Пользовательскийинтерфейсявляетсязначительнойчастьюбольшинстваприложений; еготакжеследуетмоделироватьсиспользованиемUML. Фактически, UML является естественным кандидатом на роль нотации для его моделирования. Однако сейчас не существует явного способа моделирования пользовательского интерфейса с использованием UML. [35]
...Хотя о UML можно думать как о довольно полном языке моделирования, имеющем несколько диаграмм для отображения взаимоотношений и позволяющем описать структуру и поведение приложения на нескольких уровнях абстракции, очень мало внимания было уделено нуждам разработчиков интерфейса. В результате попытки разработки пользовательских интерфейсов в UML сталкиваются с проблемой сложности естественного выражения характеристик интерфейсов. [38]
…Классических диаграмм, предоставляемыхUML, таких как диаграммы классов или состояний, недостаточно для моделирования всех аспектов гипермедийных систем – например, моделирования навигационного пространства и графического представления этой модели. [39]
Ещеболееобобщенно:
Пакет UMLнесправляется с моделированием взаимодействиячеловек-компьютер. [36]
UML считается доминирующим языком моделирования в программной индустрии. Однако поддержка им интерактивных систем все еще считается недостаточной. Распространено ошибочное мнение, что модели, разработанные при проектировании внутренних элементов приложения, подходят и для проектирования взаимодействия, что делает аспекты удобства использования приложения более критичными. [37]
Список авторов, обвиняющих (включая и последнюю версию) UML в недостаточной поддержке моделирования уровня представления (или взаимодействия) можно продолжить, но мы все равно не найдем того, кто бы пытался объяснить причину этого тяжкого и неслыханного упущения.
Так как работа любой программы, даже самой маленькой, прямо или косвенно зависит от взаимодействия с пользователем (даже простейшая консольная программа в некоторый момент начинает взаимодействовать с пользователем), и так как система является совокупностью программ, взаимодействие, которое она может организовывать с пользователями, становится впечатляющим.
Ситуация становится еще более печальной, если мы рассмотрим программы-игры, представляющие важный сектор программной индустрии, где взаимодействие с пользователем не просто важно, а первостепенно.
ВUML прослежи