DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 11:49

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 2 ] 
Автор Сообщение
СообщениеДобавлено: Суббота, 02 Август, 2014 16:48 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Абстракция управляющих конструкций и язык ДРАКОН.
Методологический разрыв


Пышкин Е. В. Структурное проектирование: основание и развитие методов. С примерами на языке C++: Учеб. пособие. — СПб.: Политехнический университет, 2005. — 324 с. — ISBN 5-7422-1000-0

Цитата:
Начало исследований в связи с совершенствованием абстракций управляющих конструкций приходится на 90-е гг., когда несовершенство управляющих конструкций большинства языков высокого уровня (не претерпевших существенных изменений за десятилетия развития вычислительной техники и областей ее применения) стало отмечаться многими специалистами.

В литературе эта ситуация обычно называется методологическим разрывом между состоянием теории программирования и запросами практики проектирования, имеющей дело с возрастающей сложностью разрабатываемого программного обеспечения [Лекарев, 1997].

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

Некоторые языки дополнительно содержат конструкции мультиветвления, управления переходами и др., но, в общем и целом, множество абстракций управления довольно стабильно.

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

С этим связано появление технологий программирования, развивающих и улучшающих основной языковой инструментарий проектировщика (см. гл. 7—8).

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

Ознакомление студентов с состоянием дел в этой области является, по мнению автора, важной составляющей процесса обучения структурному проектированию, поскольку обеспечивает решение следующих методических задач:

            Студенты изучают структурное программирование не как обособленную вычислительную платформу и не противопоставляют его другим методологиям программирования.

            Студенты учатся выделять концепции, общие для разных методологий программирования, и понимать различия в реализации этих концепций.

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

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

Е. В. Пышкин о языке ДРАКОН:
http://kspt.ftk.spbstu.ru/media/files/p ... xcerpt.pdf
Цитата:
7.2. Визуальный язык ДРАКОН

Интересным средством, нацеленным на визуализацию структурно-императивного проектирования, является язык ДРАКОН (Дружелюбный Русский Язык, Который Обеспечивает Наглядность) и соответствующая теория [Паронджанов, 1999].

Язык ДРАКОН был разработан в НПО автоматики и приборостроения (г. Москва) и применен при построении ПО космического корабля «Буран».

Разработчики визуального формализма на основе языка ДРАКОН, критикуя неадекватность изобразительны средств схем алгоритмов и программ, отталкивались от двух руководящих принципов:

— Легкость понимания программ – более важное требование, чем удобство их написания.

— Текст не является наиболее адекватной формой формализации знаний.

В результате синтаксис ДРАКОН-схем содержит довольно большое число графоэлементов (икон).

Алгоритм в виде ДРАКОН-схемы может изображаться в двух основных видах – в виде примитива (используемого для алгоритмически простых задач) и в виде силуэта (используемого для запутанных, разветвленных алгоритмов). Пример примитива программы, распознающей идентификаторы в некотором файле, представлен на рис. 7.7.

Рис. 7.7. ДРАКОН-примитив

Силуэт состоит из набора так называемых веток, соответствующих отдельным частям алгоритма. На рис. 7.8 представлен силуэт алгоритма распознавания очередного идентификатора. Некоторые элементы ДРАКОН-схемы пояснены на рисунке с помощью выносок.

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

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

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

Учитывая, что важным аспектом проектирования с использованием ДРАКОН-схем является обеспечение эргономичности восприятия, вводится правила построения эргономичных схем, определяющие пространственное размещение веток:

Порядок работы веток «слева направо».

Порядок размещения передачи управления веткам «слева направо».

При необходимости передачи управления на уже обработанную ветку (так называемый «веточный цикл») используют специальный адресный символ ветки с черным треугольником вверху.

Нетрудно заметить, что схема на рис. 7.8 соответствует перечисленным правилам.

Рис. 7.8. ДРАКОН-силуэт

Для реализации отдельных функциональных блоков применяются текстовые средства программирования на основе известных алгоритмических языков. В [Паронджанов, 1999] перечисляется ряд гибридных визуально-текстовых языков из семейства ДРАКОН, в которых обеспечено строгое разграничение визуального синтаксиса (ДРАКОН- схемы) и текстового синтаксиса (например, языков C и Pascal).

В этом смысле конструктивная идея разграничения визуальной и текстовой составляющей
проектирования родственна L-сети М.Ф. Лекарева.

Визуальный язык ДРАКОН образует наглядную среду для первоначального обучения программированию и мог бы быть весьма полезен при организации школьных курсов информатики.

Методы проектирования, ориентированные на ДРАКОН-схемы, позволяют преодолеть алгоритмическую сложность. Вопрос о преодолении структурной сложности ПО и сложности построения хороших абстракций данных предметной области остается открытым.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 21 Октябрь, 2014 07:58 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Паронджанов писал(а):
Абстракция управляющих конструкций и язык ДРАКОН.
Методологический разрыв


Пышкин Е. В. Структурное проектирование: основание и развитие методов. С примерами на языке C++: Учеб. пособие. — СПб.: Политехнический университет, 2005. — 324 с. — ISBN 5-7422-1000-0

Е. В. Пышкин о языке ДРАКОН:
http://kspt.ftk.spbstu.ru/media/files/p ... xcerpt.pdf
Цитата:
7.2. Визуальный язык ДРАКОН

Интересным средством, нацеленным на визуализацию структурно-императивного проектирования, является язык ДРАКОН (Дружелюбный Русский Язык, Который Обеспечивает Наглядность) и соответствующая теория [Паронджанов, 1999].

..................
..................

Методы проектирования, ориентированные на ДРАКОН-схемы, позволяют преодолеть алгоритмическую сложность.
Вопрос о преодолении структурной сложности ПО и сложности построения хороших абстракций данных предметной области остается открытым.
Последний вопрос представляет самостоятельный интерес для обсуждения:
проблема визуализации данных на блок-схемах алгоритмов (и программ).
Это большая перспектива для Дракон-методологии:
от нее навряд ли следует уходить.

Здесь есть два аспекта:
1) Данные в традиционном понимании как информационные данные алгоритмов и программ ЭВМ.
2) Обобщенные данные, включая материальные данные алгоритмов управления материальными процессами (и управляющих программ технического оборудования):
управления продвижением, манипулированием, обработкой, хранением и т.п. материальных объектов и потоков.

Во втором случае этот вопрос целесообразно рассматривать в рамках
обобщенных автоматизированных систем - в полном диапазоне по степени автоматизации:
от нуля - "ручные" системы, например, переноска больного на носилках двумя санитарами,
и выше,
вплоть до единицы, например переноска больного (раненого) на носилках двумя (военными) роботами-санитарами.

Пример такой потребности:
медики уже сами рисуют такие материальные данные дракон-алгоритмов.
Это следует из фильма с участием В.А. Паронджанова,
в котором фигурирует книга из дружественной нам медицинской Прибалтики.
Правда картинку нам не показали, а очень хотелось бы увидеть,
как надо правильно переносить больных на носилках по дракон-алгоритму.

Другое дело - как обеспечить систематическое расширение визуализации,
не ломая уже сложившейся визуальной дракон-методологии.
Вот в чем вопрос.

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

Например:

1) «вопрос» вместо общеупотребительного «условие»:
"вопрос" - это хорошее смысловое уточнение к термину "условие",
поскольку это вопросительное (проверочное) логическое условие, а не директивное условие.
И не случайно часто в ромбиках логических условий часто ставится обозначение условия с вопросом.

2) «вставка» вместо «предопределенный процесс» или «подпрограмма»:
"вставка" - это хорошее короткое уточнение смысла изображения
именно как вставки (в смысле компиляции), а не вызова подпрограммы или подагоритма (по интерпретации).

3) «шампур» вместо «основная ветвь программы».
Кстати говоря, в многопоточном программировании шампур соответствует понятию основного (или главного) потока, от которого порождаются параллельные потоки.

Достоинство термина:
"шампур" - однословный короткий термин, а «основная ветвь программы» или "«основная ветвь алгоритма" - разница самоочевидная;
"шампур": графический стержень (толстая линия) с насаженной на него операторной начинкой:
очень образная суть дела, еще и с подвесками вторичных шампуров.

Недостаток термина:
"шампур" в алгоритмике и программировании - это какая-то бытовуха, жаргон и т.п.?
А почему бы и нет.
Англосаксы в этом плане не церемонятся. Например:
"железо" (iron) в информатике - в исходном смысле это "метиз": металлоизделия в хозяйственном магазине;
кеш: загашник, заначка и т.п. - промежуточный обменный буфер для ускорения доступа (в параллельном программировании, в интернете и т.п.).
Привыкли и не возражаем.
А у нас "шампур" - мы тоже не лаптем щи хлебаем.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 2 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB