Об описаниях алгоритмов
Достаточно было много в кибернетике подходов и способов описания и представления алгоритмов. И словесный и блок-схемы и псевдокод и нормальные алгоритмы и через концепцию
Исполнитель, частными случаями которй являются машины Тьюринга и Поста
Полагаю что при использовании оформления только в стиле блок-схем мышление остается на хорошо если на уровне структурного программирования. Никак не показывается связь этих подходов, преобразование схем в автоматную модель. Что вполне соответствует концепции яз Паскаль, но никак не событийному программированию, поддерживаемому в визуальных средах, (Дельфи). Автоматный подход является основой диаграмм состояний широко потом используемым в моделировании бизнес процессов и в UML.
Оформление классическими блок-схемами неудобно для алгоритмов ряда задач (драйверов, управления устройствами, технологических процессов) сам стиль оформления которых требует не блок-схемы а автоматные схемы (например при оформлении многократной попытки устройства) (см. [1])
В то же время каждому, кто сдавал ПО наверное приходилось пользоваться Гостом 19, где, ни слова нет об оформлении блок-схем с позиций диаграмм состояний
Прошу читающих это высказать свои замечания и соображения на эту тему
Е.Багоцкий [email]eugrita@mail.ru[/email]
[1] “Введение в конечные автоматы», doc.sch130.nsc.ru/book/Book.ComputerNetworkTheHands/Glava 10/Index6.htm
[2] Автоматные схемы программ В.Любченко 1983 г. softcraft.ru/auto/ka/ash/ash.shtml
[3] “Алгоритм преобразует алгоритм”, wiki.likt590.ru/doku.php/tema:preobrazovanie_algoritmov._teorija_konechnyx_avtomatov
Исполнитель, частными случаями которй являются машины Тьюринга и Поста
Полагаю что при использовании оформления только в стиле блок-схем мышление остается на хорошо если на уровне структурного программирования. Никак не показывается связь этих подходов, преобразование схем в автоматную модель. Что вполне соответствует концепции яз Паскаль, но никак не событийному программированию, поддерживаемому в визуальных средах, (Дельфи). Автоматный подход является основой диаграмм состояний широко потом используемым в моделировании бизнес процессов и в UML.
Оформление классическими блок-схемами неудобно для алгоритмов ряда задач (драйверов, управления устройствами, технологических процессов) сам стиль оформления которых требует не блок-схемы а автоматные схемы (например при оформлении многократной попытки устройства) (см. [1])
В то же время каждому, кто сдавал ПО наверное приходилось пользоваться Гостом 19, где, ни слова нет об оформлении блок-схем с позиций диаграмм состояний
Прошу читающих это высказать свои замечания и соображения на эту тему
Е.Багоцкий [email]eugrita@mail.ru[/email]
[1] “Введение в конечные автоматы», doc.sch130.nsc.ru/book/Book.ComputerNetworkTheHands/Glava 10/Index6.htm
[2] Автоматные схемы программ В.Любченко 1983 г. softcraft.ru/auto/ka/ash/ash.shtml
[3] “Алгоритм преобразует алгоритм”, wiki.likt590.ru/doku.php/tema:preobrazovanie_algoritmov._teorija_konechnyx_avtomatov
Бот ?
Тож сначала подумал. Но не похож - долгоиграющий какой-то :)
Скорее спам.
Скорее спам.
Если это спам, то мне не понятно куда слать SMS чтоб увеличили.
Я вот не пойму: в чём вопрос?
Хотите использовать диаграммы состояний - используйте. Не найдёте в ГОСТ требований к оформлению - оформляйте как вам удобно. Суть проблемы-то в чём?
Я вот не пойму: в чём вопрос?
Хотите использовать диаграммы состояний - используйте. Не найдёте в ГОСТ требований к оформлению - оформляйте как вам удобно. Суть проблемы-то в чём?
Цитата:
В то же время каждому, кто сдавал ПО наверное приходилось пользоваться Гостом 19, где, ни слова нет об оформлении блок-схем с позиций диаграмм состояний
Вот ты не поверишь - никогда в жизни, кроме как на лабах в универе, я не сдавал блок-схемы при сдаче :)
Не говоря уже о том, чтобы кто-то требовал соответствия их ГОСТу (российскому? :rolleyes:...)
Не знаю, мы всегда просто рисовали схему из произвольных фигур, соединённых произвольными кривыми так, чтобы кому было положено понять - понимал. В ход при этом шли ещё жестикуляция и обсценная лексика. А когда я нарисовал блок-схему своего бота… Короче, разобраться со схемой было сильно сложнее, чем с кодом из ~10 000 строк на нескольких модулей и классов.:)
Между тем, бот был сделан довольно логично и ясно.
Между тем, бот был сделан довольно логично и ясно.
эт где ты такое рисовал?
На работе, вестимо. Дело в том, что я принимал проект для завершения, и блок-схемы там никто не рисовал, да и вообще из документации было только описание идеи и какие-то комментарии в коде. Потом я его полностью перефигачил по причине изменения матчасти, а уж только совсем потом шеф таки попросил нарисовать блок-схему. Я пролюбил два дня на это дело и примерно с третьей итерации выдал на-гора оный документ. Три итерации потребовалось потому, что схема оказалась очень сложной и сама нуждалась в отладке.:)
Правда, там был ещё политический момент, о котором здесь рассказывать неуместно; именно из-за него схема получилась слабо приемлемой для чтения, хотя суть работы отражала очень точно.
ЗЫ. По-моему, многие вещи лучше изображать не одной схемой, а коллекцией изображений с состояниями системы. Мне, например, можно было бы просто изложить все алгоритмы (а их там много) по отдельности. Было бы понятнее.
Правда, там был ещё политический момент, о котором здесь рассказывать неуместно; именно из-за него схема получилась слабо приемлемой для чтения, хотя суть работы отражала очень точно.
ЗЫ. По-моему, многие вещи лучше изображать не одной схемой, а коллекцией изображений с состояниями системы. Мне, например, можно было бы просто изложить все алгоритмы (а их там много) по отдельности. Было бы понятнее.
То, что классические диаграммы не нужны, вроде даже в "мифическом человеко-месяце" говорилось. Думаю, для алгоритмов лучше текстовое описание, комментарий, возможно, подкрепленный какой-нибудь таблицей. Графика удобна, когда надо показать связь функций или объектов. Алгоритм, насколько я понимаю, более низкоуровневая единица, самая простейшая функция.
Ну и спорное утверждение на десерт. Возможно, комментарий будет полезно подкрепить описанием на функциональном языке.
Ну и спорное утверждение на десерт. Возможно, комментарий будет полезно подкрепить описанием на функциональном языке.
Это если ФЯ понятен участникам обсуждения, а само описание сделано без фанатизма.