OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 19 Июль, 2019 21:31

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




Начать новую тему Ответить на тему  [ Сообщений: 2 ] 
Автор Сообщение
СообщениеДобавлено: Понедельник, 16 Декабрь, 2013 17:28 

Зарегистрирован: Суббота, 02 Февраль, 2013 16:19
Сообщения: 16
Фредерик Брукс в 1986 году написал статью «Серебряной пули нет», где показал, что ряд средств, на которые в то время возлагались большие надежды, не станут «серебрянными пулями», т.е. средствами, которые повысят продуктивность программиста на порядок в ближайшее десятилетие после написания статьи. Одним из таких средств было визуальное проектирование. Приведу достаточно обширную цитату.

Цитата:
Графическое программирование. Излюбленной темой докторских диссертаций
в программной инженерии является графическое, или визуальное,
программирование - применение компьютерной графики в разработке программного
обеспечения.[9] Иногда перспективы такого подхода основываются на аналогии с
проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда
такой подход обосновывается, исходя из того, что блок-схемы являются
идеальным материалом при проектировании программ. Имеются мощные средства
для создания таких блок- схем.

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

Во-первых, как я всюду доказываю, блок-схема является весьма слабой
абстракцией структуры программы.[10] Лучше всего это видно из попыток Беркса,
фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне
необходимым управляющим языком высокого уровня. В том жалком виде - многие
страницы соединенных линиями прямоугольников, - в котором сегодня
разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность:
программисты рисуют их после, а не до создания описываемых ими программ.

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

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


Таким образом, Брукс приводит два аргумента: блок-схемы как средство помощи в разработке програм излишни и имевшиеся в то время мониторы неудобны для графической разработки программ. Ссылка [10] косвенно отсылает к главе 15 книги «Мифический человеко-месяц», где Брукс показывает, что хорошо написанная программа столь же выразительна, что и блок-схема.

Ответить на оба аргумента можно, наверное, так. Рисовать блок-схему алгоритма до написания программы на высокоуровневом ЯП излишне, равно как использовать её для документации кода на том же высокоуровневом ЯП. Но если есть компилятор/интерпретатор блок-схем, т.е. не требуется дублировать схему текстом программы, то блок-схема имеет право на существование. А что касается второго аргумента, сейчас разрешение 320×200 пикселей можно встретить разве что на мобильниках, разрешения экрана вполне должно хватать.

Мой вывод: программирование путём рисования блок-схем — вполне приемлемый подход, наравне с другими видами программирования. Наверное, стоит поковырять тот же Дракон.

Но: хорошо помню один пример. На кафедре, где я учился один аспирант разрабатывал прошивку для ПЛИС (кафедра делала оборонный заказ). Поначалу он использовал средства визуального программирования в САРП Altera Quartus — рисовал принципиальные схемы — квадратики и встроенные примитивы (И, ИЛИ, НЕ и другие) соединял линиями. Потом оказалось, что такой код нагляден, но трудносопровождаем, т.к. при изменении схемы приходится все эти квадратики и линии передвигать. Перешёл на программирование на Verilog’е.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Декабрь, 2013 18:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Выскажу кое-что, возможно, непривычное... для кого-то даже очень... :)

Оба аргумента Брукса во многом вневременные. Что доказывает и материальная инженерия тоже.

1. Что "блок-схема является весьма слабой абстракцией структуры программы" - думаю, хорошо показывает как раз концепция семредактирования. Язык можно уподобить материалу для "идеальных", "информационных" систем. Но. При этом надо хорошо подумать, какой именно язык. Главное требование - чтобы он был именно "сильной конкретикой". Тогда описание и "представляет собой многослойный двумерный объект, геометрия которого отражает сущность". Это, разумеется, для графической формы записи (понятно, что и топологию можно текстом описывать). У меня сформировалось понимание своё, какой язык этому должен удовлетворять. Интересны будут мнения других. Пример с переходом к записи принципиальных моделей от схем к тексту (эквивалентному) показывает лишь, что человеку удобнее править модель в такой записи.

2. Насчёт "сильной абстракции". Да, "Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения". Сие касается и схем, представленных здесь: viewtopic.php?p=84855#p84855 (хотя, казалось бы, за "своё" должен ратовать... но надо быть объективным :wink:) ...
Но. Это только потому, что мы не привлекаем первичную науку о деятельности (догадайтесь, какую :wink:)... Она и определяет общую точку зрения, точнее - целостное представление о деятельности (например, подлежащей программированию).
Когда будем рассматривать деятельность ещё и системно - тогда частные точки зрения будут открывать что-то важное для построения/коррекции полного образа...

3. Что "Настоящий рабочий стол позволяет обозревать и произвольно выбирать множество бумаг" - это легко понять тому, кто работал на плазах (увы, пока это по преимуществу люди из реального сектора, а не "идеального" :)). Автор ДРАКОНа здесь, считаю, прав (критикуя "ошибку Джеймса Мартина")... но тут вступают в силу пп. 1,2...


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

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


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

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


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

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