Диссертация (1148239), страница 23
Текст из файла (страница 23)
Этоприводит к тому, что разработчик больше времени уделяет выполнению техдействий, которых от него требует CASE-инструмент, а не тех, которыенепосредственно необходимы для решения задач, из которых состоит разработкаПО. Например, строго формализованные языки моделирования имеют большоеколичество ограничений на создаваемые с их помощью модели: правилаиспользования элементов и связей между ними, которые, с одной стороны, не даютпроектировщику создавать некорректные диаграммы и позволяют отлавливатьошибки на ранних этапах разработки, но с другой — мешают естественномумыслительному процессу разработчика, заставляя его совершать предписанныеметодологией действия. Авторы [100] предупреждают, что подобный инструментбудет встречен своими пользователями негативно и не будет использоваться сполной эффективностью.
Инструмент должен помогать пользователю решатьзадачи, а не ставить перед ним новые. Например, в описанном выше случае мог быбыть полезен режим графического редактора, когда диаграммы создаются впроизвольном виде, без каких-либо ограничений, накладываемых семантикой языка,целостностью диаграмм или ограничениями самого редактора. Это бы болееспособствовало свободному креативному мышлению разработчика. Об этой141проблеме пишут и авторы [78]: CASE-среды хорошо поддерживают поздние фазыразработки, такие как проектирование и реализация, и довольно плохо — начальныефазы, на которых проходит понимание и анализ предметной области иразрабатываемой системы.
Для лучшей поддержки этих стадий CASE-средствадолжны иметь более простой, менее формальный и более гибкий интерфейс,позволяя разработчику думать о задаче, а не о том, как ее реализовать с помощьюданного инструмента.Удобный графический интерфейс используемых инструментов играет большуюроль даже сам по себе. Так, исследование [79], проведенное психологами, показало,что чем больше разработчикам нравится внешний вид CASE-среды, чем болееудобными для них кажутся входящие в ее состав инструменты, то не только онибудут пользоваться подобной средой с большей охотой, но и будут считать ее болееполезной, чем неудобная и непривлекательная среда. [114] также подтверждает, чтоудобство использования инструментального средства может быть не менее сильноймотивацией к использованию этого средства, нежели повышение в продуктивности,к которому этот инструмент может привести.В 2000-х годах CASE-инструменты продолжали свое развитие, но, большейчастью, в направлении совершенствования своих технических средств.
Рядсовременных исследований показывает успешные применения MDE-подхода кпромышленной разработке ПО ([60, 69, 75, 94, 108, 122, 133, 143]), однако в целомавторы соглашаются, что подобные случаи не являются характерными дляиндустрии. Использование модельно-ориентированных средств в настоящее время— это скорее элемент общей культуры компаний и работающих в нихпрограммистов, нежели общеупотребимая практика. Так, в [143] утверждается, чтоне более 15% компаний в области программной инженерии в США используютмодельно-ориентированные средства разработки. Основной проблемой этого авторывидят социально-экономически причины: даже в настоящее время программисты142обучаются с использованием традиционных текстовых средств разработки ПО, и этото, к чему они привыкают и не хотят менять.
Моделирование воспринимаютсябольшинством разработчиков как “рисование красивых диаграмм” — деятельность,которая отрывает от основного занятия (программирования), а потому зачастуюосуществляется неохотно (и, зачастую, постфактум). Кроме того, для большинствалюдей, сознательно выбравших для себя разработку ПО в качестве профессии,программирование является крайне творческой деятельностью, причем для многихпривлекательным в работе является не создание конечного продукта, а решениевозникающих технических задач.
Это приводит к тому, что любые попытки так илииначеубратьпрограммированиемоделированиемвоспринимаютсяизежедневнойвраждебно,работыаргументыизаменитьоегоповышениипродуктивности работы, качества создаваемого ПО или улучшения коммуникацийкак внутри команды разработчиков, так и за ее пределами оказываются дляпрограммистов неубедительными, и они находят способы вернуться к привычномуим программированию.И действительно, язык UML не является языком программирования, и стольширокое использование его обуславливается в большей степени тем, что онстандартизован и в определенной степени понятен даже людям, не являющимсятехническими специалистами (например, диаграммы UML могут использоваться приобщении с заказчиками).
К тому же, даже при условии наличия четко заданнойсемантики элементов языка (как, например, сделано в языке xUML) попыткипрограммировать на таком языке приводят к моделям огромной сложности,перегруженным деталями.ДаннуюпроблемустараютсярешатьCASE-средства,основанныенаспециализированных языках (предметно-ориентированные решения), создаваемыепод решение конкретных задач [102]. В рамках предметно-ориентированнойпарадигмы разработка ведется только в терминах визуальных моделей, а весь код143генерируется автоматически (и дальнейшее его редактирование “вручную” недопускается).
Для быстрого создания таких средств используются инструментальныесреды, называемые metaCASE-средствами или DSM-платформами. В отличие оттрадиционных CASE-средств, разрабатываемых годами большим коллективомразработчиков, DSM-решения, создаваемые на базе выбранной платформы однимили несколькими экспертами в течение нескольких дней или недель, не могут бытьнастолько же мощными функционально, однако большая часть необходимых дляработы инструментов в их составе присутствует. Достигается это тем, что сама DSMплатформа, как правило, содержит в себе довольно обширный набор инструментов,которые автоматически используются всеми DSM-решениями, создаваемыми наоснове данной платформы.
Ориентация на конкретную предметную областьдостигается настройкой и расширением средств платформы. Так, например,стандартная графо-графическая библиотека может быть дополнена конкретнымиизображениями фигур элементов для создания необходимого редактора диаграмм;по формальному описанию семантики, созданному разработчиком DSM-решения,средствами DSM-платформы может быть автоматически создан отладчик илигенератор исходного кода по моделям на данном языке и т.п.144Приложение B. Обзор подходов к заданиюисполнимой семантики визуальных языковB.1.
Непосредственное создание интерпретаторовНаиболее интуитивным с точки зрения реализации способом задания семантикиисполнения языков является непосредственное создание интерпретатора илиотладчика для конкретного предметного языка в виде отдельного модуля. Приработе данного модуля по модели генерируется машинный код, который затеминтерпретируется, а процесс исполнения отслеживается и определённым образомотображается пользователю. Также очевидна проекция стандартного функционалаотладчиков на такую систему.
Наличие машинного кода позволяет осуществлятьпошаговую интерпретацию, ставить точки останова, следить за хранящимисяданными и т.п.Однако бывают ситуации, когда применение данного подхода либо совершеннонеэффективно, либо вообще невозможно, например, в случае языков со сложнымипроекциями типов данных и операторов. Такими языками в том числе являются ивизуальные языки. Сложности могут возникать как при самой генерации машинногокода, так и при организации отслеживания хода исполнения. Поэтому следующимшагом может быть реализация отладчиков визуальных языков по двухуровневойсхеме, то есть при помощи генерации кода на некоем текстовом языке ииспользования существующего отладчика этого языка.Процесс отладки должен происходить в терминах этого исходного языка, т.е.отображать положение потока исполнения в исходных моделях, осуществлятьустановку точек останова в определённых местах моделей и др.
Поэтому, например,команда выполнения следующего шага отладки (step over) должна учитыватьизменение стека вызовов исходной программы, а не генерирующегося кода. Это145важно, поскольку каждому элементу модели на исходном визуальном языке можетсоответствовать несколько строк кода на целевом текстовом языке, поэтому длятого, чтобы установить точку останова в терминах исходного языка, необходимознать, на какую из этих строк кода нужно ставить точку останова в целевом языке.Кроме того, не всегда переход к следующему элементу потока исполнения висходной модели будет соответствовать переходу на следующую строку кода всгенерированном коде.Несмотря на понятную идею в плане реализации, данный подход требует отразработчиков новых предметных языков серьезных инженерных навыков дляорганизации точного и полного соответствия конструкций исходного визуальногоязыка конструкциям целевого текстового языка и взаимодействия этих конструкций.В связи с высокой технической сложностью задачи и тем, что данный подходориентирован на создание единичного отладчика для определённого языка,обобщениеподходадвухуровневойотладкинапредметно-ориентированноемоделирование выглядит нецелесообразным.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
