Блок-схемы алгоритма

[eugrita]

Можно по-разному изображать алгоритмы.
Но даже к самой традиционной блок-схеме, правила которой регламентированы Гостом N 19 у меня есть пара каверзных вопросов.
1)как быть если некая формула включает в себя значения каких-то еще функций. Например $ p:= c_1M(x)+c_2N(x,y) $
Есть стандартная нотация для подпроцесса (процедуры), но для процесса, возвращающего результат (функции) нет. Тогда по-моему, правильно так

Хотя приходится неоправданно вводить промежуточные переменные
Такое типично скажем, для языка Фортран в котором для реализации формулы есть даже т.н. оператор-функция. Но вообще говоря более общий вид задания функции -даже не формулой а своим алгоритмом. И тогда
заменить вызов функции прямым написанием формулы в главном алгоритме не удастся. Как быть?
2)можно ли при оформлении 2-х циклов с общим началом писать их в одном а не в двух блоках начала цикла, т.е. так

3) Можно ли при оформлении блок-схем математических алгоритмов использовать 2-х и многобуквенные обозначения переменных наподобие идентификатора переменной в яз программирования. В математике в формулах стремятся использовать 1-символьные имена переменных (ну может быть с верхним или нижним индексом). Ведь если это можно тогда надо для обозначения оператора умножения использовать точку или *
Иначе непонятно, где кончился идентификатор одной и начался идентификатор другой переменной.(а то админы этого и других научных форумов бьются насмерть за то чтобы в формулах не писать точки для знака умножения, а как тогда в блок-схемах?)
4)Некоторые студенты любят на блок-схемах конкретных алгоритмов рисовать блоки общего вида типа "составление модели задачи", "подготовка данных" и т.п. Мне кажется это недопустимо. Алгоритм на то и алгоритм, что конкретен и лишних обозначений нет. Хотя блок-схемы часто используют не только для оформления математических алгоритмов, но и каких-то действий, бизнес-процессов. Тогда - да, в таком стиле
5)Хотелось бы получить ответ на тему альтернативных официальных способах оформления алгоритмов. Например, есть язык Дракон. Являются ли его схемы стандартом.
6)хочу коснуться вопроса связи CASE-диаграммы с моделью или алгоритмом. Конечно, скажем, IDEF0, IDEF-3 или DFD-диаграммы это не алгоритмы, это скорее выбор уровня детализации модели. Мне кажется переходя от нее к классической блок схеме, можно сказать, что каждому элементу CASE-диаграммы (работе) соответствует подпроцесс (процедура) классической блок-схемы. Так ли это?

[Pavia]

1)

Цитата:

Такое типично скажем, для языка Фортран в котором для реализации формулы есть даже т.н. оператор-функция. Но вообще говоря более общий вид задания функции -даже не формулой а своим алгоритмом. И тогда
заменить вызов функции прямым написанием формулы в главном алгоритме не удастся. Как быть?

Ну так посмотри на гост он и разрабатывался во времена фортрана. И по сути не соответствует действительности.
Что касается по существу просто используй прямоугольник. Тебя не заставляют описывать каждую строчку программы. И вообще там упомянута возможность разной детелизации описания процесса. Правда нормы не установлены. А вообще на предприятии должно быть ОСТП, и более детально я тебе не расскажу так как непосредственно этим должен заниматься нормоконтроль, а от вас только предложения.

2)

Цитата:

Можно ли при оформлении блок-схем математических алгоритмов использовать 2-х и многобуквенные обозначения переменных наподобие идентификатора переменной в яз программирования

Если говорить про математику то тут соглашусь одно буквенных достаточно.
ГОСТ 19.003

Цитата:

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

Но не исключено, что есть какой-то гост про математику.

Цитата:

. Ведь если это можно тогда надо для обозначения оператора умножения использовать точку или *

Запись должна быть лаконичной и не допускать 2-х смысленного понимания поэтому знак умножения надо показывать.
3)

Цитата:

Некоторые студенты любят на блок-схемах конкретных алгоритмов рисовать блоки общего вида типа "составление модели задачи", "подготовка данных" и т.п. Мне кажется это недопустимо.

Всё что не запрещено, то разрешено. В ЕСКД это лучше описано чем в ЕСПД. Схемы делятся в зависимости от основного назначения подразделяют на следующие типы:

Цитата:

структурные;
функциональные;
принципиальные (полные);
соединений (монтажные);
подключения;
общие;
расположения;
объединенные.

Думаю ЕСПД подпадает под ЕСКД. Вот требуйте от студента не структурную схема, а функциональную или принципиальную.
Функциональная допускает "составление модели задачи", "подготовка данных" . А вот принципиальную уже строга со всеми переходами.
Структурная схема вообще не требует ввода вывода, а только что откуда куда.
браузер->веб сервер -> СУБД <- датчик

[eugrita]

Боюсь эти понятия функциональные;принципиальные,соединений и др...
выходят вообще за рамки понятия "блок-схема " а относятся к более широкому классу структурных схем устройств например в электронике, САР но никак к программам и алгоритмам.
Я согласен что блок-схема как форма описания для современного взгляда на алгоритмизацию устарела. То же описание языка Дракон начинается с критики блок-схем и дифирамбами в адрес схем яз.Дракон.
Тем не менее в школах и ВУЗах алгоритмы изучаются на основе классических блок-схем, нравится это нам или нет.
И поэтому преподавание курса алгоритмизация и программирования должно учитывать все нюансы и недостатки языка блок-схем и сравнение с альтернативными формами представления алгоритмов.
2)правда есть т.н. парадигмы программирования, в частности функциональное направление (языки), Lisp, Refal
Можно ли говорить об отличии описаний моделей задач для этих языков от классических блок-схем ?Другими словами, для каждого стиля программирования (функционального, компонентного,cобытийного) использовать свою форму представления алгоритмов. При этом конечно терминологически отличая эти формы представления от классических блок схем.

[Pavia]

Цитата:

Я согласен что блок-схема как форма описания для современного взгляда на алгоритмизацию устарела.

Ни чуть она не устарела. Я говорил что ГОСТ старый и плохо проработан.

Цитата:

но никак к программам и алгоритмам.

То есть вам силы воли не хватает чтобы взять ответственность на себя. Классификацию по на назначению.
Но при этом вы легко согласились взять классификацию по виду.

Цитата:

для каждого стиля программирования (функционального, компонентного,cобытийного)

Как так?
Вообще-то разные схемы и преподают .

[eugrita]

Ну так хорошо.Вот достаточно давно выделен "функциональный" стиль программирования. Языки Lisp,Hascell, Miranda. Общеизвестные научные среды Mathcad,Matlab,Mapple (точной их классификации по стилю не видел, зато есть классификация их прародителя- языка APL который отнесен к функциональному стилю.
-Привожу для ясности цитату из одной статьи
На практике отличия математической функции от понятия «функции» в императивном программировании в том, что императивные функции могут опираться не только на аргументы, но и на состояние внешних по отнош к функции переменных, а также иметь побочные эффекты и менять состояние внешних переменных. Таким образом, в императивном программировании при вызове одной и той же функции с одинаковыми параметрами, но на разных этапах выполнения алгоритма, можно [b]получить разные данные на выходе из-за влияния на функцию состояния переменных[/b]. А в функциональном языке при вызове функции с одними и теми же аргум мы всегда получ одинаковый результат: выходные данные зависят только от входных. Это позволяет средам выполнения программ на функциональных языках кешировать результаты функций и вызывать их в порядке, не определяемом алгоритмом
--------------------------------------------------------
Если принять все это то фактически надо признать, что классическими блок-схемами описывается только функциональное программирование.
В самом деле, в нем, по определению результат функции однозначно определяется ее вызовом с определенным набором аргументов.
Но тоже самое мы делаем при вызове подпроцесса на блок-схеме алгоритма.
Указывая в ней определенный набор аргументов подпроцесса и автор и читатель блок-схемы рассчитывает на однозначность получаемых результатов и об отсутствии влияний на результат прочих факторов.
Достоинством блок-схем всегда была их лаконичность и конкретность

[Circiter]

2eugrita

Цитата:

классическими блок-схемами описывается только функциональное программирование

Да ну, не верю. Это как раз таки чистая императивщина -- программа представлена последовательностью действий, явно изменяющих состояние программы. Для формальной работы с функциональными алгоритмами больше всего подходит $\lambda$-исчисление, и никакие диаграммы удовлетворительно его вообще заменить не могут, ну разве что какие-нибудь диаграммы потоков, виртовские ну и т.д.

Цитата:

Можно ли при оформлении блок-схем математических алгоритмов использовать 2-х и многобуквенные обозначения переменных наподобие идентификатора переменной в яз программирования

Можно и нужно. Но приходится использовать короткие "математизированные" -- исключительно из-за геометрических ограничений.

Цитата:

можно ли при оформлении 2-х циклов с общим началом писать их в одном а не в двух блоках начала цикла

Думаю, так делать нельзя. Да и стрелка у вас там кажется должна в сам блок итерирования входить слева, разве нет? Или я с блоком условия (ромб) перепутал?

Цитата:

Есть стандартная нотация для подпроцесса (процедуры), но для процесса, возвращающего результат (функции) нет

По-моему, можно функции-подпрограммы оформлять как и главную блок схему, только писать в блоках начала и конца "начало имя_функции"/"конец имя_функции". Прием данных и возврат результата можно оформит как обычный ввод-вывод (с помощью параллелограмма) или в pascal-стиле, т.е. описать формальные параметры в скобках у имени функции, а возвращать результат можно присваиванием этому имени.

Извините, в стандарт не заглядывал и не помню, что там было написано. Думаю вам не составит труда найти и скачать соответсвующие гост'ы. Когда-то тоже приходилось рисовать эту дурость, но тетрадки потом сдал учителям и в хламе ничего не осталось. :)

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

[eugrita]

А вот как вам еще такая классификация видов алгоритмов?
(официально приводится в виде методич.указаний студентам)
виды алгоритмов: вычислительные, диалоговые, графические, алг обработки данных, управления объектами и процессами и др
http://www.examen.ru/add/School-Subjects/Mathematics-and-Computer-Science/Computer-Science/9860/9878
Произнеся А надо произнести и Б: Показать примеры, особенности представления (блок-схем) каждого из перечисленного вида.
---------------------------------------------------------------------------
Помню еще 70-е гг, ИМАШ, математик Р,Б,Статников занимался многокритериальной оптимизацией - ну каждая его статья не обходилась без слов интерактивный ... для того то времени. Это и понятно, общий алгоритм многокритериальной оптимизации (нахождение множества Парето) каждый пользователь приспосабливает к своим целям. Без индивидуального диалога с программой здесь не обойтись. Но это - мои частные наблюдения.
А где общеобразовательное зерно: примеры, особенности алгоритмов каждого типа???

-- Вс дек 18, 2011 10:38:07 --

Да с этим я не спорю.
По поводу вызова-то функции лишь вопрос как писать в прямоугольнике с двойными рамками слева и справа:
так : $y=c_1f(x)+c2g(x,y)$ или лепить 2 (или несколько)таких прямоугольников с введением промежуточных переменных типа
$p_1=f(x)$ $p2=g(x,y)$
а потом еще в прямоугольном блоке писать $y=c_1p+c_2g$
или в один прямоугольник с двойными рамками можно запихнуть формулу
$y=c_1f(x)+c2g(x,y)$

Circiter в сообщении #516655 писал(а):

2eugrita

Цитата:

классическими блок-схемами описывается только функциональное программирование

Да ну, не верю. Это как раз таки чистая императивщина -- программа представлена последовательностью действий, явно изменяющих состояние программы. Для формальной работы с функциональными алгоритмами больше всего подходит $\lambda$-исчисление, и никакие диаграммы удовлетворительно его вообще заменить не могут, ну разве что какие-нибудь диаграммы потоков, виртовские ну и т.д.

Цитата:

Можно ли при оформлении блок-схем математических алгоритмов использовать 2-х и многобуквенные обозначения переменных наподобие идентификатора переменной в яз программирования

Можно и нужно. Но приходится использовать короткие "математизированные" -- исключительно из-за геометрических ограничений.

Цитата:

можно ли при оформлении 2-х циклов с общим началом писать их в одном а не в двух блоках начала цикла

Думаю, так делать нельзя. Да и стрелка у вас там кажется должна в сам блок итерирования входить слева, разве нет? Или я с блоком условия (ромб) перепутал?

Цитата:

Есть стандартная нотация для подпроцесса (процедуры), но для процесса, возвращающего результат (функции) нет

По-моему, можно функции-подпрограммы оформлять как и главную блок схему, только писать в блоках начала и конца "начало имя_функции"/"конец имя_функции". Прием данных и возврат результата можно оформит как обычный ввод-вывод (с помощью параллелограмма) или в pascal-стиле, т.е. описать формальные параметры в скобках у имени функции, а возвращать результат можно присваиванием этому имени.

Извините, в стандарт не заглядывал и не помню, что там было написано. Думаю вам не составит труда найти и скачать соответсвующие гост'ы. Когда-то тоже приходилось рисовать эту дурость, но тетрадки потом сдал учителям и в хламе ничего не осталось. :)

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

[arseniiv]

eugrita в сообщении #516674 писал(а):

А вот как вам еще такая классификация видов алгоритмов?
(официально приводится в виде методич.указаний студентам)
виды алгоритмов: вычислительные, диалоговые, графические, алг обработки данных, управления объектами и процессами и др
http://www.examen.ru/add/School-Subject ... /9860/9878
Произнеся А надо произнести и Б: Показать примеры, особенности представления (блок-схем) каждого из перечисленного вида.

Да плюньте на неё. Это какие-то гуманитарии, наверно, выдумали от скуки.

[eugrita]

В ГОСТ 19.701-90 (ИСО 5807-85) от 1992 г. приводится следующий стандарт обозначений цикла

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

В http://tat67183862.narod.ru/shem.htm и на некоторых сайтах говорится что
"Конструкция "цикл с параметром" отдельно ГОСТом не регламентируется, но приведенное
обозначение (шестиугольник) разрешено использовать для различных целей, поэтому такое
изображение цикла на блок-схеме часто встречается в литературе по программированию."


Вопрос. Мне обозначение на 2 рис Д представляется более удобным и компактным.
Можно ли нго использовать при оформлении блок -схем алгоритмов в частности, в курсовых
для ВУЗов?