19 янв. 2008 г.

Семантический разрыв передачи знаний между стадиями технического дизайна и написания кода

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

Далее цитата из курса "Визуальное моделирование: теория и практика"
Семантический разрыв визуальных моделей и программного кода

...визуальные модели, действительно удобные в работе, "склонны" терять исполняемую семантику. Другими словами, информация, которая в них содержится, оказывается недостаточно полной и детальной, чтобы по ней вычислитель мог бы выполнить свою работу. Ведь никакая "умная" генерация не может добавить то, что отсутствует изначально. Если же визуальные модели усложнять, чтобы они были пригодны для использования вычислителем, то очень часто они теряют наглядность и становятся бесполезными. Кому нужны непонятные, но полные описания программного обеспечения, выполненные с помощью визуальных моделей? Есть тексты на языках программирования, есть документы, есть возможность спросить, в конце концов, разобраться в коде самому…

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

Где выход?

Неудача решения вопроса с генерацией "в общем виде" не говорит о том, что это невозможно в частных случаях. Необходимо лишь понизить степень общности ситуации. Это можно сделать, создавая кодогерационные решения для ПО отдельных видов. Генерация кода по визуальным моделям успешно применяется в промышленности в следующих областях:
* в разработке схем реляционных баз данных;
* при создании событийно-ориентированных систем реального времени;
* при формализации бизнес-процессов компаний.
Эти области и будут подробно рассмотрены в этом курсе лекций.

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

конец цитаты

Есть очень занимательная статья о контекстной технологии программирования (1 и 2). Но она, ровным счетом, ничего не проясняет, хоть и выглядит как "решение всех наших проблем".

Можно лишь сделать вывод, что решение проблемы можно искать в:
* более высоком уровне абстракции языка, на котором ведется разработка;
* использование средств традиционных для проектирования представлений предметной области,но не на полную катушку, а частично.
Первое - нам не подходит, так как у нас с этим полный консенсус и никто язык менять не соберется. Второе - уже лучше, так как опыт показывает, что умл хорош на очень отдаленных от реализации стадиях, но потом, когда сложность диаграмм растет вместе с темпами их эволюции использовать умл становится просто не возможно.

Все это навеяло новую и очень необычную для меня мысль. А что если не пытаться заставить программистов следовать пусть даже 300 тысяч раз хорошей и академичной технологии программирования? Что если инструмент формализации предметной области, действительно, мог бы подстроиться под язык реализации?
Привыкшие быть ломателями стереотипов мышления неумытых программистов сами будут ломаться под новый инструмент. Прекрасно! Вот только я пока не знаю ничего про этот инструмент. И кстати, все это похоже на то, как сумасшедший разговаривает сам с собой. Усиленно что-то сам себе доказывает не получая ответа.
Отправить комментарий