2019 №1-2 - перейти к содержанию номера...
Постоянный адрес этой страницы - https://nppir.ru/01np119.html
Ссылка для цитирования этой статьи:
Брумштейн Ю.М., Васильев Н.В. Анализ целей и практических вопросов редактирования описаний алгоритмов в научных статьях // Научная периодика: проблемы и решения, 2019 №1-2, https://nppir.ru/01NP119.html (доступ свободный). Загл. с экрана. Яз. рус., англ.
Анализ целей и практических вопросов редактирования описаний алгоритмов в научных статьях
УДК 004.9: [009+001.9+002]
Брумштейн Юрий Моисеевич
Астраханский государственный университет, Астрахань, Россия
Кандидат технических наук, доцент
ORCID: https://orcid.org/0000-0002-0016-7295
eLibrary: https://elibrary.ru/author_profile.asp?authorid=280533
E-mail: brum2003@mail.ru
Васильев Никита Вячеславович
Астраханский государственный университет, Астрахань, Россия
Программист отдела Интернет-технологий
ORCID: https://orcid.org/0000-0001-6305-1938
E-mail: nikivas@mail.ru
Аннотация. Приведены типичные цели использования текстовых описаний и схем алгоритмов (ТОиСА) в статьях по различным отраслям наук. Проанализирован состав частных характеристик, по которым оцениваются ТОиСА. Обоснована целесообразность сопоставления потенциально возможных вариантов представлений ТОиСА путем сравнения следующих сочетаний характеристик «полнота описания алгоритма – простота восприятия описания – занимаемая площадь страницы».
Охарактеризованы цели, общие принципы выбора решений и практические действия редакторов при редактировании ТОиСА в научных статьях.
Рассмотрены возможности и ограничения использования авторами в статьях ссылок на описания алгоритмов, размещенные во внешних источниках; недочеты, встречающиеся при использовании такого подхода.
Обсуждены достоинства и недостатки использования текстовых описаний алгоритмов, в т.ч. в сочетании с формулами, графиками, а иногда и таблицами. Охарактеризованы основные недочеты, встречающиеся при использовании авторами такого подхода, принципы устранения этих недочетов.
Указаны возможности и ограничения использования программно-технических средств для представления алгоритмов в графической форме, включая различные типы схем.
Обоснованы цели и области применения для представления алгоритмов IDEF- и DFD-диаграмм, диаграмм акторов (Use-Case); UML-диаграмм. Перечислены типичные недостатки, встречающиеся в таких диаграммах, обсуждены методы их устранения.
Исследованы достоинства/недостатки диаграмм Ганта и сетевых графиков как средств описания алгоритмов в статьях. Указаны типичные недочеты, встречающиеся при использовании данных средств; принципы устранения этих недочетов.
Рассмотрены возможности и ограничения представления алгоритмов в виде блок-схем (укрупненных и детализированных); типичные недочеты, встречающиеся в таких схемах; возможные действия научных редакторов по выявлению и устранению недочетов.
Обсужден ряд вопросов, связанных с представлением алгоритмов в виде фрагментов программного кода; проанализированы возможности и ограничения такого подхода; его достоинства и недостатки.
Охарактеризованы также некоторые дополнительные возможности расширения функциональности ТОиСА, которые могут быть использованы в электронных периодических изданиях.
Ключевые слова: научные журналы; научные статьи; редактирование; алгоритмы; текстовые описания; схемы; способы представления; IDEF-диаграммы; DFD-диаграммы; UMLдиаграммы; диаграммы Ганта; сетевые графики; блок-схемы; способы создания диаграмм; фрагменты программного кода; языки программирования; верстка статей.
Введение
Для многих научных статей важной (а иногда и обязательной) частью их содержания может быть характеристика алгоритмов, используемых для решения рассматриваемых задач. Однако авторы статей, представляемых для публикации в научных журналах (НЖ), не всегда рационально выбирают способы представления алгоритмов; допускают в текстовых описаниях и схемах алгоритмов (ТОиСА) различные недочеты. В рамках редакционно-издательской обработки статей (прежде всего научного редактирования) эти недочеты необходимо устранять. При этом необходимо руководствоваться современными требованиями к редактированию научных статей [2,4,24,25], включая правила представление схем алгоритмов; обеспечивать соблюдение в текстах описаний к алгоритмам стилистических норм [29], в частности исключать тавтологии хотя бы в пределах фраз; учитывать конструктивные замечания и предложения рецензентов [33] по статьям; поддерживать эффективность взаимодействия научных редакторов с авторами при работе над статьями [26, 27]; соблюдать правила публикационной этики [6], в т.ч. в отношении указания авторов описываемых алгоритмов или их прямых аналогов (прежде всего, используемых в качестве «базовых вариантов» при разработке модифицированных алгоритмов).
Следует также учитывать, что в процессе редакционно-издательской обработки статей осуществляется работа с различными видами объектов, включая ГО. При работе с фразами, имеющими достаточно сложные конструкции, задействуются различные «виды внимания» [15]. Возможно и «умственное утомление» при длительной работе с текстами, особенно имеющими большое количество длинных фраз. Поэтому потенциально возможен «пропуск» рецензентами и редакторами части недочетов, имеющихся в статьях.
Однако в существующих публикациях целый ряд практически важных вопросов, связанных с созданием и редактированием ТОиСА, рассмотрен недостаточно комплексно. Поэтому целью данной статьи является попытка исправить существующее положение. Авторы считают, что материалы статьи могут быть полезны как научным редакторам НЖ, так и авторам представляемых в них статей.
Общие вопросы, относящиеся к описаниям алгоритмов в научных статьях и принципам их редактирования
Статьи могут быть целиком посвящены конкретному алгоритму (например, [1,21,34]) или сравнению совокупности (группы) алгоритмов – например, [10,14]. При этом термин «алгоритм» обычно содержится в названии работы (например, [1,10,23]), а в ее тексте кроме описания алгоритма/алгоритмов обычно приводятся результаты их исследований, в т.ч. в форме результатов вычислительных экспериментов.
Однако чаще характеристика алгоритма (или алгоритмов) является лишь одной из компонент статей. Если авторы используют структурирование статей по шаблону IMRAD (introduction, methods, results, discussion), то наиболее естественными местами размещения ТТОиСА являются части, посвященные описанию методик сбора и/или обработки данных (информации), иногда – методик проведения экспериментов.
В зависимости от содержания статьи научные редакторы могут (при необходимости) предложить авторам следующее: корректировку названия статьи с включением в него слова «алгоритм»; устранение «речевой избыточности» [8] заголовков; исправления в аннотацию статьи – с отражением в ней в явной форме используемого алгоритма (алгоритмов); включение термина «алгоритм» в состав ключевых слов; при необходимости – введение отдельных заголовков для разделов, соответствующих рассматриваемым в статьях алгоритмам.
В отношении некоторых видов схем, предназначенных для представления алгоритмов, существуют специальные регламентирующие документы (например, [22]). Они определяют правила представления этих схем, в т.ч. в различных «нотациях». Фрагменты этих нормативных документов могут воспроизводиться и в статьях (например, [17]) – в связи с описанием алгоритмов. Кроме того, авторы статей (и редакторы) обычно учитывают также сложившуюся практику представления схем алгоритмов.
Если существующие правила (или сложившаяся практика) представления алгоритмов в статьях необоснованно нарушаются, то редакторы могут предложить авторам устранить допущенные недочеты. Однако, необходимо отметить, что по крайней мере в отношении графических схем представления алгоритмов регламентирующие (методические) документы не охватывают все многообразие схем, встречающихся в научных статьях.
Качество описания алгоритмов в статьях может значительно влиять на оценки качества статей в целом [18], принятие решений о целесообразности их публикации. Непосредственно в отношении описаний алгоритмов могут оцениваться такие параметры качества: полнота описания (необходимость и достаточность всех фрагментов текста и ГО), относящихся к описанию алгоритма; удобочитаемость (понятность) описания; наличие нарушений существующих норм оформления «стандартизованных» ГО и др.
Описания (характеристики) алгоритмов могут встречаться в научных статьях, относящихся к различным отраслям наук. Наиболее часто ТОиСА используются в статьях по техническим и физико-математическим наукам. При этом типичными целями применения ТОиСА являются следующие: формализованная характеристика процесса выполнения вычислений – обычно с использованием некоторых логических операций проверки условий, в т.ч. в рамках применения численных методов (например, [7]); представление процессов получения и обработки данных, в т.ч. в АСУ реального времени технологическими процессами [32]; представление когнитивных диаграмм различных процессов [13] и др.
Отдельно отметим достаточно обширный класс научных статей по методам программирования; разработанным программным средствам, их функциональности [35] и пр. В таких работах описания алгоритмов могут относиться не только к методам вычислений, но и к порядку подготовки исходных данных, их верификации и пр.; к методикам проверки работоспособности программных систем и пр.
Для статей по экономическим наукам ТОиСА могут использоваться для представления «бизнес-процессов» [22]; различных схем сбора информации, в т.ч. связанной с экономическими и социально-экономическими процессами; схем анализа информации и, возможно, принятия решений [19], а также их практической реализации; схем управления подразделениями, организациями [20], социально-экономическими системами (в т.ч. на уровне регионов и отдельных стран) и пр.
В статьях по биологическим наукам ТОиСА могут применяться при описании взаимодействий отдельных частей в моделях биологических и экологических систем; различных функциональных подсистем человека и животных; методов динамического управления характеристиками состояния живых систем (например, [28]) и др.
В области химических наук ТОиСА могут быть необходимы при характеристике процессов анализа и/или синтеза соединений, процессов взаимодействия химических веществ, при управлении химико-технологическими процессами [9] и пр.
В области машиностроения описания алгоритмов могут относиться к характеристике последовательностей операций в технологических процессах обработки материалов; сборке изделий из отдельных деталей; проверке функциональности и характеристик оборудования – в т.ч. в процессе эксплуатации (последнее применение, впрочем, относится в большей степени к «Инструкциям по эксплуатации», чем к научным статьям).
Приведенный выше набор направлений и конкретных примеров применения ТОиСА носит иллюстративный характер и, конечно же, не претендует на функциональную полноту.
В представляемых статьях могут встречаться следующие подходы к представлению сведений об алгоритмах. (а) В текстах статей размещаются только упоминания об алгоритмах в виде ссылок на другие работы тех же или иных авторов, в которых соответствующие алгоритмы описаны достаточно подробно. Такой прием эффективен для минимизации текстов статей – при условии, что работы, на которые даются ссылки, находятся в открытом доступе. (б) Подробные описания алгоритмов размещаются в открытом доступе на Интернет-ресурсах, не являющихся научными статьями, монографиями или учебниками, а в статьях на них даются только ссылки. Возможные варианты размещения таких материалов: справочные, информационные и аналитические материалы на Интернет-сайтах; личный сайт автора (или одного из авторов) статьи в Интернете; специальная секция сайта того же НЖ в т.ч. предназначенная для размещения дополнительных материалов к статьям (такой подход используют лишь немногие российские издания). В последнем случае на внешних (по отношению к статьям) ресурсах помимо описаний алгоритмов могут находиться и варианты их программной реализации. Последнее в ряде случаев дает возможность читателям статей самостоятельно проводить исследования работы алгоритмов (например, для математических моделей систем) с заданием различных входных параметров, получением соответствующих результатов, оценкой их адекватности и пр. (в) В основном тексте статьи алгоритм только упоминается, а его описание перенесено в приложение к работе (чтобы разгрузить основной текст от технических подробностей). Такой подход в российских журналах применяется также редко. (г) Алгоритм описывается в основном тексте статьи с приведением всех необходимых формул, графических объектов (ГО) и пр. При этом важно, чтобы описание алгоритма не доминировало по объему над остальным текстом (кроме случая, когда сам по себе анализ алгоритма является основной целью статьи).
С позиций научного редактирования в отношении описаний алгоритмов в статьях необходимо контролировать (и при необходимости корректировать) следующее. (1) Отсутствие «логических недоговоренностей» при описании алгоритмов. При этом следует учитывать, что авторы вправе описывать алгоритмы с различной степенью подробности; исключать из описания некоторые технические детали и пр. (2) Однозначность приведенного описания алгоритма, т.е. исключение возможностей двусмысленных толкований описываемых действий. (3) Простоту восприятия описания алгоритма, в т.ч. отсутствие слишком длинных фраз. (4) Занимаемкю ТОиСА площадь листа – это особенно существенно в печатных изданиях. В ряде случаев редакторы могут предлагать авторам более компактное размещение ТОиСА, позволяющее уменьшить занимаемую площадь листа без отказа от воспроизведения логически важных фрагментов текста. Кроме того, иногда возможно «масштабирование» схем алгоритмов для экономии площади. Отметим, что в случае статей чрезмерного объема, которые необходимо сокращать, одним из возможных «объектов-кандидатов» на уменьшение объемов текста и графики может быть и ТОиСА.
В случае использования ГО в ТОиСА при редактировании статей необходимо контролировать следующее: наличие расшифровок для всех сокращений, используемых в ГО (в основном тексте или в подрисуночных подписях); разборчивость элементов ГО применительно к печатным вариантам изданий. Следует также учитывать, что если схемы алгоритмов были представлены авторами в цвете, то при печати журналов на бумаге эти цвета обычно воспроизводятся в тонах серого. Печать «в цвете» на бумаге из-за дороговизны используется редко. При этом в некоторых журналах (например, «Информационные технологии»), все цветные иллюстрации выносятся на обложки или специальные листы-вкладки. Однако размещение ГО «отдельно» от текстов статей может усложнять их чтение.
Поэтому в некоторых случаях для редакторов НЖ может быть целесообразным предлагать авторам в схемах алгоритмов менять цветные стрелки на пунктирные, штрих-пунктирные и пр. Для различения типов связей между объектами в схемах алгоритмов могут быть также использованы линии различной толщины, двойные линии и пр. Для различения блоков в блок-схемах вместо цветных заливок могут быть использованы различные «степени плотности» заливок серым цветом.
Современные программные средства предоставляют авторам достаточно широкий спектр возможностей по выбору различных элементов в ГО, включая типы стрелок и иных объектов. При этом необходимо, чтобы все ГО были «сгруппированы» или находились внутри «рамки рисунка». Это обеспечивает возможности масштабирования ГО при техническом редактировании статей, их верстке и пр. Возможность такого масштабирования особенно важна при двухколоночной верстке, в т.ч. с «обтеканием» рисунков текстом.
В общем случае при научном редактировании статей, содержащих описания алгоритмов приходится учитывать следующие факторы. (1) Необходимость соблюдения авторских прав на тексты статей и графические объекты в них [3,4,5]. Как следствие все корректировки ТОиСА должны с авторами согласовываться.
(2) Установленные ограничения на общие объемы статей, а также допускаемые в них предельные количества ГО (последний вид ограничений есть лишь в некоторых изданиях). В результате редакторам журналов иногда приходится просить авторов представить ТОиСА в более компактном виде.
(3) Зависимости стоимостей опубликования статей (материалов) от их объемов, особенно в коммерческих изданиях. Следствие – предложения редакторов по более полному описанию алгоритмов в статьях могут отвергаться авторами по чисто финансовым соображениям.
(4) Ограничения по срокам сдачи очередных номеров НЖ в редакцию (типографию). Следствие – слишком большие объемы корректировок ТОиСА, предлагаемые редакторами авторам, могут приводить к переносам их статей в последующие номера, т.к. авторы могут просто не успевать достаточно быстро сделать все необходимые исправления. При этом у редакторов номеров может не быть «резервных» статей для замены тех материалов, публикация которых вынужденно сдвигается на более поздний период.
(5) Возможность того, что авторы просто не согласятся с предлагаемыми корректировками ТОиСА исходя из собственного понимания логики работ.
(6) Неопределенности в сроках получения ответов от рецензентов – особенно, если скорректированные версии статей необходимо направлять им на повторное рецензирование.
(7) Потенциальную возможность (вероятность) передачи авторами в другие издания уже частично отредактированных статей (если с точки зрения авторов редакторами предъявляются чрезмерные требования в отношении объемов/трудоемкостей корректировок ТОиСА или статей в целом. Как следствие трудозатраты на рецензирование и редактирование статей с позиций НЖ окажутся непродуктивными (бесполезными).
(8) Необходимость соблюдения общих ограничений по трудоемкости научного и технического редактирования работ, их верстки при выпуске отдельных номеров периодических печатных изданий.
В силу перечисленных факторов принятие решений научными редакторами отдельных статей (или номеров в целом) в отношении корректировок ТОиСА обычно носит многокритериальный характер; часто осуществляется в условиях неопределенностей и некоторых рисков.
В заключение раздела отметим, что в п.1 и п.2 ст.1259 Гражданского кодекса (ГК) РФ «алгоритмы» в явной форме не упоминаются как потенциальные объекты авторских прав (однако п.1 допускает расширительное толкование, т.к. последним объектом в нем указываются «другие произведения»). В тоже время по п.5 ст. 1259 ГК РФ « Авторские права не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач, открытия, факты, языки программирования». Однако тексты научных статей, включающие описания алгоритмов, являются объектами авторских прав как «литературные произведения» (п.1 ст.1259). Отметим еще, что по п.1 ст.1259 ГК РФ «К объектам авторских прав также относятся программы для ЭВМ, которые охраняются как литературные произведения». Здесь речь идет, очевидно, о листингах программ, а не об исполнимых файлах. Таким образом, алгоритм, представленный в виде совокупности строк программного кода, может быть самостоятельным объектом авторских прав (вне зависимости от того, содержит ли он комментарии к исполняемым операторам или нет).
Названия многих широко используемых алгоритмов (а, особенно, групп алгоритмов) носят устоявшийся/традиционный характер и обычно не включают фамилии их авторов. При описаниях модифицированных алгоритмов обычно указывается «класс», к которому принадлежит алгоритм, а также назначение алгоритма (например, [1]). В редких случаях авторы статей используют для разработанных ими алгоритмов собственные наименования, в т.ч. включающие указания на области применения алгоритмов [2].
Ссылки на алгоритмы: типичные недочеты в представляемых статьях и подходы к их устранению при редактировании
Типичный случай, когда в статьях целесообразно не описывать алгоритмы, а давать ссылки на такие описания во внешних источниках – полноценное представление ТОиСА требует слишком много места, которое не может быть выделено в конкретной статье в силу ограничений на ее объем. При этом можно дать ссылку на монографию, методическую работу или даже учебник, где алгоритм описан в полном объеме. Это может быть не только работа авторов статьи (или одного из авторов), но и публикация иных авторов, в т.ч. классическая публикация зарубежных авторов на иностранном языке. Ссылки на русскоязычные учебники могут быть оправданы, если в них алгоритмы представлены более полно, чем в первоисточниках. Однако при этом в статьях целесообразно упоминать и авторов-разработчиков алгоритмов (в силу необходимости соблюдения их авторских прав, научного приоритета и пр.) или «стандартное» название алгоритма. Как пример применения ссылок на алгоритмы, описанные во внешних источниках, приведем [10].
Использование в статьях копий ТОиСА из предыдущих публикаций авторов (включая монографии) может существенно снижать показатели «доля оригинального текста», который выдают автоматизированные системы контроля (типа размещенной на www.antiplagiat.ru). Как следствие, редакции могут возвращать авторам статьи с требованием довести «процент оригинального текста» до минимально необходимого уровня, требуемого правилами изданий. При таких условиях изъятие из текста статьи ТОиСА и замена их ссылкой является простым и быстро реализуемым решением.
Типичные недочеты, встречающиеся при использовании ссылок на другие работы.
А) В работе, на которую дается ссылка в отношении ТОиСА, их описание представлено недостаточно полно (не информативно).
Б) Работа, на которую дается ссылка, недоступна вообще или труднодоступна (Например, это может быть работа, депонированная в отраслевом органе научно-технической информации. При этом оплату за получение текста работы по электронной почте быстро провести нельзя).
В) Работа, на которую дается ссылка, находится в платном доступе. Менталитет большинства российских авторов таков, что они избегают платить личные средства для доступа к информации, необходимой им для понимания научных статей. Отметим, в связи с этим, что доступ к статьям, опубликованным в изданиях Springer и некоторых других издательств для физических лиц обычно является платным. Однако бесплатный доступ к таким материалам можно получить, например, с компьютеров вузов – за счет прямых договоров вузов (или их объединений) с такими издательствами; путем использования возможностей, представляемых фондами-грантодателями и пр.
Г) Ссылка, приводимая вместо описания алгоритма, является «не корректной», т.е. по ней не удается найти работу-оригинал (например, из-за ошибок в библиографическом описании).
Помимо библиографической ссылки на работу, включенную в список источников к статье, авторы могут приводить и гиперссылку на источник информации об алгоритме (в т.ч. непосредственно в тексте статьи). Это обеспечивает возможность прямого перехода на нужный материал при чтении текста статьи. Однако если материал, на который дается ссылка, не включен в библиографический список, то это снижает наукометрические показатели его авторов, а также тех изданий, в которых такие материалы были опубликованы. Поэтому научные редакторы должны обращать внимание авторов на необходимость (целесообразность) включения материалов, на которые даются гиперссылки, в библиографические списки к статьям.
Необходимо отметить, что с течением времени гиперссылки на Интернет-источники могут становиться некорректными – например, из-за изменения места расположения файла; заменой его более актуальным файлом с другим именем и пр. Однако для материалов научного характера изменение их Интернет-адресов (и, как следствие, появление «некорректных» ссылок на них) в целом не характерно.
Важным средством упрощения доступа читателей к источникам, на которые даются ссылки, является использование DOI (пока, однако, оно присваивается лишь немногим статьям российских авторов и редко воспроизводится после библиографических описаний источников). Некоторой альтернативой использования DOI может быть применение в библиографических списках гиперссылок на опубликованные статьи, которые находятся в архивах номеров журналов, размещенных на Интернет-сайтах издательств в открытом доступе. В связи с этим отметим, что гиперссылки на материалы, размещенные в открытом доступе на сайте www.elibrary.ru, будут «срабатывать» только если пользователь предварительно вошел в систему под своим «логином-паролем», т.е. авторизовался.
Текстовые описания алгоритмов: возможности; основные недочеты, встречающиеся в статьях; подходы к их устранению
В статьях, поступающих для публикации в научные издания, встречаются различные варианты использования текстовых описаний ТОиСА. Кроме того, как уже отмечалось выше, текст ТОиСА может содержать формулы и/или графические объекты.
А) Простейшим вариантом ТОиСА, является описание несложного алгоритма в виде текста без выделения отдельных пунктов (нумерованных или маркированных). При этом может использоваться разделение текста на абзацы (с целью выделения отдельных этапов для алгоритмов) – например, [7]; «маркированные списки» – например, [30].
В варианте «А» (как, впрочем, и в последующих) возможно включение в описания алгоритмов формул (например, [23]), графиков, диаграмм.
Достоинство варианта «А»: краткость (компактность) описания. Недостаток – отсутствие выделения отдельных пунктов затрудняет представление логики алгоритма, отличающейся от последовательного выполнения операций. Поэтому такой подход рационален, преимущественно для т.н. «линейных» алгоритмов.
При научном редактировании текста описаний алгоритмов по варианту «А» зачастую необходимо разбивать используемые авторами слишком длинные фразы на части (такие фразы нередко используются авторами для «логической группировки» действий в рамках алгоритмов).
В некоторых случаях также бывает целесообразным представить текст описания алгоритма в виде большего количества абзацев или ввести нумерацию отдельных пунктов.
Б) Текстовое описание алгоритма с нумерацией отдельных пунктов (один уровень иерархии) – как примеры приведем [9,30]. Это дает возможность достаточно подробно описать логику работы не слишком сложных алгоритмов действий (операций, вычислений и пр.); при необходимости – указать направления переходов к нумерованным пунктам при выполнении тех или иных логических условий. При этом в минимальном варианте можно нумеровать только точки начала «последовательности выполняемых операций, не содержащих проверки логических условий» .
Достоинства варианта «Б»: значительно лучшие возможности описания логики алгоритмов, чем для варианта по пункту «А». Недостатки: одноуровневой рубрикации может оказаться недостаточной для сложных алгоритмов; если нумерованных пунктов в описании много, то характеристика алгоритма может оказаться трудной для восприятия; проследить сложную логику переходов на основе таких текстовых описаний с нумерпованными пунктами может быть затруднительным.
При научном редактировании необходимо проследить, чтобы номера пунктов в ТОиСА не «пересекались» с нумерацией блоков текста статьи, используемой в других целях. При необходимости авторам может быть рекомендовано перейти от цифровой нумерации пунктов в алгоритмах к буквенной.
В) Дальнейшим развитием направления по пункту «Б» может быть использование текстовых описаний с двумя иерархическими уровнями – нумерацией пунктов и подпунктов в них (в качестве разделителя при нумерации подпунктов может быть применена точка). Кроме того, для указания соподчиненности подпунктов по отношению к пунктам могут быть применены отступы.
Достоинства варианта «В»: возможности более «глубокого» (детального) описания логики алгоритмов по сравнению с вариантом по пункту «Б», в т.ч. и внутри отдельных пунктов. Недостатки: текстовое описание становится более громоздким; проанализировать по нему все потенциально возможные логические ветви работы программы иногда весьма трудно.
При научном редактировании текстов описаний алгоритмов целесообразно контролировать отступы текста, соответствующие иерархическим уровням (это дополнительное средство наглядного представления структуры); правильность указания авторами ссылок на пункты и подпункты. Причина – при многократных переделках авторами статей в описаниях алгоритмов зачастую остаются ссылки, соответствующие прежним вариантам нумерации.
Использование программных средств для создания совокупностей графических объектов, используемых при характеристике (описании) алгоритмов
Как уже отмечалось, современные программные средства представляют достаточно широкие возможности по созданию ГО, предназначенных для ТОиСА.
Средства «деловой графики» имеются практически во всех текстовых редакторах (процессорах), применяемых в настоящее время. При этом, например, в наиболее широко используемом программном средстве Microsoft Word от версии к версии функциональность средств деловой графики постепенно наращивается; появляются новые виды готовых ГО, которые могут быть вставлены пользователями в разрабатываемые ими изображения. В частности это средство обычно используется при создании когнитивных диаграмм [13]; некоторых видов диаграмм бизнес-процессов.
В качестве специализированного средства для работы с «деловой графикой» обычно позиционируется программное средство Microsoft Visio. Его преимущество, наличие обширных библиотек готовых ГО, которые могут произвольным образом компоноваться пользователем при создании необходимых схем алгоритмов.
В качестве стандартного средства работы с изображениями (включая их создание, масштабирование, корректировку, дополнение другими элементами и пр.) отметим в первую очередь программное средство «Paint», входящее в состав операционной системы Windows.
Для создания схем алгоритмов могут быть использованы и некоторые системы автоматизированного проектирования (CAD—systems), при условии, что они включают в себя необходимые библиотеки элементов.
Средства представления структуры программ (включая автоматическое форматирование их текстов) имеются в различных «средах программирования». Есть также статьи, относящиеся к созданию программных сред для поддержки разработки блок-схем (например, [17]). Однако утилиты для полностью автоматического построения блок-схем по текстам программ, написанным на языках программирования (ЯП) высокого уровня, в настоящее время практически не встречаются.
Во многих средах разработки есть также средства наглядного представления связей между таблицами в разрабатываемых «базах данных», которые могут использоваться в различных алгоритмах. Такие схемы баз данных в настоящее время включаются преимущественно в бакалаврские работы, магистерские диссертации и пр., но не в научные статьи. Основная причина – представление сложной структуры системы связей в таких схемах обычно требует использования листов большого формата (более чем А4), которые в научных журналах практически не встречаются. Однако такие схемы для «баз данных» могут быть представлены в качестве «дополнительных материалов» к статьям – см. выше.
В ряде случаев авторами статей при характеристике алгоритмов бизнес-процессов используются и диаграммы Ганта (обычно в виде скриншотов изображений, полученных при использовании программы Microsoft Project). Однако при представлении сложных диаграмм Ганта размещенный на них текст может быть слишком мелким для печати в научных журналах (даже на листах с альбомной ориентацией). В научных статьях встречаются и некоторые функциональные аналоги диаграмм Ганта, в т.ч. предназначенные для описания процессов, представленных в виде UML-диаграмм [36].
Однако такие диаграммы могут представляться в качестве «дополнительных материалов» к статьям, поскольку практически все программные средства для работы с графикой обеспечивают возможности масштабирования изображений, в т.ч. и при использовании средств просмотра ГО на мобильных устройствах.
Для представления последовательностей действий в статьях могут также применяться сетевые графики. Однако средство их построения в Microsoft Project, дает слишком громоздкие (большие по размеру) ГО. Поэтому авторы при необходимости использования сетевых графиков в статьях обычно применяют совокупность нумерованных кружочков, связанных с помощью стрелок. Такие объекты ими создаются вручную, а затем группируются. Расшифровки «содержания» отдельных кружочков выносятся в подрисуночные подписи.
При научном редактировании необходимо контролировать, чтобы такие расшифровки были даны для всех кружочков. Отметим также, что при ручном формировании сетевых графиков для представления различных типов связей между объектами может быть использовано следующее: стрелки разного типа (например, пунктирные стрелки для необязательных или временных связей); стрелки разного цвета или толщины (что может отражать различные типы связей) и пр.
Для создания «онтологических схем» (например, [12]) существуют специальные редакторы, которые позволяют такие схемы строить автоматически в процессе разработки. «Онтологические схемы» сами по себе, конечно, не являются алгоритмами, но могут использоваться при описании алгоритмов для обоснования их логики.
Диаграммы IDEF (различных типов) и DFD применяются, обычно, при информационно-логическом проектировании алгоритмов, программных средств, а также бизнес-процессов. Эти диаграммы формируются автоматически при использовании соответствующих специализированных программных средств. В вузах среди них наиболее популярным сейчас является, очевидно, RAMUS – разработчик Ramus Soft Group. Эту программу можно скачать с различных сайтов, например с http://softrare.ru/windows/ramus. Для RAMUS есть легальные бесплатные версии, например Ramus Educational 1.2.5.
Значительно большей функциональностью обладает средство AllFusion Process Modeler. Однако оно платное и достаточно дорогое по российским меркам.
Для создания диаграмм Use-Case (диаграмм акторов), UML-диаграмм также существуют специализированные программные средства – например, Rational Unified Process. Из них могут (при необходимости) заимствоваться полученные изображения – путем использования нужных фрагментов скриншотов. При описаниях алгоритмов в научных статьях UML-диаграммы используются (например, [36]), но относительно редко. Применение диаграмм акторов для научных статей не характерно.
Блок-схемы как средство представления алгоритмов: возможности, ограничения, типичные встречающиеся недочеты; подходы к их устранению
Использование блок-схем является традиционным средством описания алгоритмов – прежде всего используемых в программах для ЭВМ (например, [16]). Регламентация вопросов представления блок-схем, алгоритмов управления оборудованием и пр. в нормативных документах (включая ГОСТы), носит достаточно полный характер – см. например, [17]. Однако в публикуемых статьях нередко встречаются значительные отклонения от требований нормативных документов в отношении представления блок-схем. Это особенно характерно для публикаций по экономике и менеджменту, включающих характеристики последовательности действий, выбора решений и пр.
Блок-схемы широко используются в учебных материалах и монографиях, в меньшей степени – в научных статьях (например, [2,20]. При этом применяются следующие варианты представления блок-схем.
А) Блок-схемы, целиком размещаются на одном листе в портретной или альбомной ориентации (например,[2]). При этом может применяться числовая нумерация блоков (например, [20]), что обеспечивает удобство указания ссылок на блоки в текстовых пояснениях к алгоритмам. Кроме того, нумерация блоков позволяет, при необходимости, дать их подробные текстовые расшифровки в подрисуночных подписях [2].
Достоинства варианта «А»: относительная простота описания алгоритма; легкость его восприятия в графической форме. Недостатки: так можно описать лишь относительно простые алгоритмы; внутри блоков алгоритма (особенно логических, представляемых в виде ромбиков) можно разместить лишь очень короткие фрагменты текста. Возможные способы преодоления последнего недостатка: более подробные пояснения к отдельным блокам выносятся в текстовые комментарии, размещенные справа от блоков – около края листа; комментарии к блокам даются в виде текста до или после блок-схемы (такой подход обычно требует нумерации блоков). Еще одним недостатком является необходимость искусственного представления операторов типа «case» или «if — else if — else if ….. else» (которые обеспечивают возможность разветвления логики по многим направлениям) в виде совокупности логических блоков-ромбиков, каждый из которых осуществляет проверку лишь единственного логического условия. В последнем случае блок-схемы занимают большую площадь листа, чем соответствующие им фрагменты программного кода.
Наверное, наиболее типичным недостатком блок-схем, встречающихся в научных статьях, является использование прямоугольных блоков (соответствующих одной операции или их последовательности) с входами с разных сторон прямоугольников (по нормативным документам вход должен быть только один и только сверху). Кроме того, в рамках научного редактирования необходимо проверять, следующее: все переменные (обозначения), используемые в блок-схемах описаны в тексте или имеют расшифровки в подрисуночных подписях.
При «не сгруппированных» ГО в блок-схемах последние могут «разрываться» между страницами, что нежелательно с точки зрения их восприятия. Поэтому в таких случаях редакторы обычно просят авторов проводить группировку ГО.
Б) Блок-схема большого объема приводится на двух последовательных листах, при этом стрелки-соединители блоков «переходят» с одного листа на другой. Достоинство: возможность представления блок-схем с большим количеством элементов, чем для пункта «А». Недостатки: блок-схема должна размещаться на двух последовательных листах, находящихся на развороте (т.е. это должны быть «четная и нечетная» страницы – как при портретной, так и при альбомной ориентациях); необходимо согласование положений «половинок» блок-схемы – для совпадения соединительных линий. Первое требование при техническом редактировании может приводить к переносу значительных по величине блоков текста, что иногда нарушает логику изложения.
В) Приводится укрупненная блок-схема алгоритма, а затем для отдельных блоков даются их расшифровки в виде детализированных блок-схем. Достоинства: так можно совместить представление основной логики алгоритма (на укрупненной блок-схеме) и детальную характеристику логики для отдельных блоков. Недостатки: если из «детальных блок-схем» осуществляются переходы на другие блоки «укрупненной блок-схемы», то проследить логику работы программы может быть достаточно трудно.
При научном редактировании должна контролироваться в основном полнота описания алгоритма. При этом часть блоков из укрупненной блок-схемы может использоваться без их детальной расшифровки.
Отметим, что использование в статьях блок-схем обычно требует некоторых текстовых комментариев. Поэтому замена текстовых описаний алгоритмов на блок-схемы иногда не дает выигрыша в отношении сокращения размеров статей. Кроме того, блок-схемы не всегда позволяют представить логику работы программы в достаточно удобном виде. В этом отношении они могут «проигрывать» UML-диаграммам, в таких случаях.
А) При описании параллельных алгоритмов (где ключевую роль играют моменты синхронизации потоков отдельной программы, или, реже, вычислительных кластеров).
Б) При описании логики, затрагивающей множество классов, что характерно для абсолютного большинства сложных объектно-ориентированных программ.
В) Иногда – в тех случаях, когда требуется детальное описание работы какого-то из элементов, представляющих логику программы.
Использование фрагментов программного кода для представления алгоритмов: анализ достоинств и недостатков подхода, используемых языков программирования
Одним из вариантов представления алгоритмов является использование фрагментов программного кода (ФПК) – обычно на ЯП высокого уровня. Такой подход широко применяется в изданиях учебного характера, но встречается и в научных статьях, монографиях.
Достоинства подхода. (1) Формализованное представление алгоритмов в виде ФПК позволяет избежать каких-либо неоднозначностей в их толковании. (2) Использование комментариев непосредственно в составе ФПК позволяет достаточно удобно представить логику выполнения операций. (3) Применение в необходимых случаях отступов для операторов дает возможность удобно представить их иерархию (соподчиненность), вложенность логических блоков и пр. (4) Основной ФПК может включать вызовы подрограмм и за счет этого быть достаточно компактным и легким для понимания. При этом для подпрограмм в необходимых могут быть приведены отдельные ФПК. Такой подход может рассматриваться как некоторый аналог пункта «В» предыдущего раздела.
Недостатки. (1) Для понимания алгоритма, представленного в виде ФПК, читатель должен владеть соответствующим ЯП. (2) Для описания алгоритма с целью его компактности (в т.ч. в отношении длин строк) приходится использовать сокращенные мнемонические названия переменных – это может затруднять их восприятие. (3) При описании алгоритмов с глубокой вложенностью циклов (или с многоуровневыми логическими условиями) площадь листа может использоваться не эффективно, т.к. заполненность строк символами будет невысокой из-за многочисленных отступов. (4) Практически во всех ЯП обозначения переменных и других объектов русскими буквами не допускаются. Поэтому приходится использовать либо транслитерации названий объектов на латиницу (обычно сокращенные), либо применять переводы названий терминов на английский (чаще всего, также сокращенные). Если таких сокращений переменных много и они «не интуитивны», то это будет затруднять понимание логики работы алгоритма. (5) В случае длинных строк в операторах ФПК, возможны такие решения: использование альбомной ориентации страниц, на которых размещены ФПК; масштабирование скриншота с ФПК по размеру листа – преимущественно для листов с портретной ориентацией; искусственное разбиение операторов ФПК на две или большее количество строк, в т.ч. за счет переноса на предыдущие или последующие строки комментариев к операторам.
В общем случае применяемые в ФПК обозначения переменных могут быть расшифрованы так: в тексте статьи до ФПК; непосредственно внутри ФПК с помощью комментариев; в подрисуночной подписи к ФПК; в тексте статьи после ФПК. Если в ФПК применяется много переменных, то при научном редактировании иногда может быть целесообразным введение специальных таблиц с обозначениями переменных и их содержательными расшифровками.
Как уже отмечалось ранее, для представления в статьях ФПК используются, в основном, ЯП высокого уровня, причем с течением времени популярность различных языков в качестве средства публикации алгоритмов менялась.
На первом этапе развития ИТКТ в качества «языка публикаций» алгоритмов абсолютно преобладал АЛГОЛ. Были изданы многочисленные «алгольные сборники» алгоритмов; монографии, основанные на использовании таких алгоритмов (например, [31]) и т.д.
На следующем этапе (1970-1990-ые годы) ФПК публиковались, в основном, на ЯП ФОРТРАН различных версий (несколько позже и на PL/I), а также на различных версиях (диалектах) ЯП Basic (как пример приведем [11]). Одновременно в учебной литературе широко использовалось представление алгоритмов на ЯП Паскаль.
Позже предпочтения изменились и в настоящее время большинство алгоритмов представляется на ЯП «С», «С#», «С++», «Java», а в последнее время и на «Python».
Отметим, что в ряде случаев авторы монографий (и, в меньшей степени статей) ранее использовали и некоторые «псевдоязыки», позволяющие лучше представить логику алгоритма за счет использования интуитивно понятных обозначений объектов и операций.
Перенос ФПК из сред программирования непосредственно в научные статьи, монографии, учебники возможен двумя основными способами.
А) Копированием необходимого фрагмента кода из «среды программирования» через «буфер обмена». При этом в некоторых случаях в ФПК могут добавляться дополнительные комментарии, а слишком длинные строки разбиваться на части. Отметим, что цветовые выделения зарезервированных ключевых слов в ФПК при печати НЖ на бумаге представляются тонами серого цвета
Б) Получением скриншота с экрана «среды программирования», содержащего часть программного кода. В дальнейшем нужная часть изображения может быть из скриншота «вырезана» в графическом редакторе и, при необходимости, масштабирована – для вставки в текст статьи в качестве ФПК. Однако если необходимый размер ФПК большой, то иногда приходится использовать перенос фрагментов изображений из двух и более скриншотов экранов.
Размещение ФПК непосредственно в статьях, предназначенных для печати в «бумажных» журналах, возможно в двух вариантах: внутри текста статьи; в качестве приложения (после текста работы, но перед списком источников). Первый вариант предпочтителен при сравнительно небольших ФПК и позволяет лучше связать фрагмент листинга с текстом статьи; второй вариант имеет преимущество при длинных листингах, фрагменты которых обсуждаются в различных частях работы.
В случае монографий «на бумаге» листинги программ могут размещаться в виде приложений в конце издания, а также на прилагаемых к изданиям лазерных дисках. Изредка встречается и вариант, когда листинги программ размещаются на «страницах сайтов поддержки» изданий.
В соответствии с современными подходами в области программирования, при написании программ с целью уменьшения количества ошибок используются некоторые формальные приемы/правила. Их соблюдение может обеспечиваться как самими программистами при написании кода, так и в автоматическом режиме. В частности отметим возможности «сред программирования» (IDE), в которых осуществляется формирование кода (текстов) программ; их проверка и пр.
Например, для представления кода в удобочитаемом виде большинство IDE используют автоматическую структуризацию кода, т.е. приведение его к шаблонному виду. При этом осуществляется не только форматирование отступов для операторов и перевод строк, но и применение «стиля кода» (CodeStyle). Отметим, в частности, следующие IDE. (1) CLion – для ЯП C++. (2) Intellij IDEA – для языка программирования Java. (3) Rider – для языка программирования C#. (3) PHP Storm (для языков веб-разработки, таких как, например, PHP, JS, а также JS подобные (jsx и т.п.). (4) Pycharm – для языка программирования Python. (5) GoLang – для языка программирования GO. (5) RubyMine – для языка программирования Ruby. (6) Похожие функциональные возможности имеет и технология Intellisense от Microsoft, используемая в Microsoft Visual Studio. (7) Автоматическая реализация некоторых из описанных далее возможностей есть и в среде программирования на «С» для популярных в России микроконтролллеров Arduino.
Итак, основные приемы обеспечения удобочитаемости кодов программ.
1) Использование отступов для представления структуры программы, включая показ вложенности операторов и блоков операторов. Это касается, в частности, операторов цикла; операторов проверки логических условий и пр.
Использование отступов при представлении текста программы (или ФПК для включения в тексты статей) особенно важно для ЯП типа Python, где отсутствуют другие разделители групп «функциональных элементов» кода, например – фигурные скобки.
Обычно для отступа используется «одинарная табуляция». При ручном наборе кода в некоторых ЯП применяются две «позиции» отступа. Причина – однократный отступ иногда не бросается в глаза. В тоже время применение более чем двух позиций отступа «растягивает» тексты программ со сложной структурой по горизонтали – это может быть неудобно для включения ФПК в статьи.
2) В языках типа «С», «Java»,«PhP» и т.п. представление с одинаковыми отступами начала блоков операторов и «закрывающих» их фигурных скобок. Однако использование единственных фигурных скобок в строках кода «растягивает» ФПК по вертикали.
3) Применение цветовых выделений для «функциональных элементов» кода программы, включая зарезервированные ключевые слова ЯП (такие слова опознаются «средами программирования» автоматически), для комментариев и пр. Сразу же отметим, что при монохромной печати НЖ на бумаге цветовые выделения в листингах программ преобразуются в различные градации серого. Поэтому последующий текст пункта «3» важен, в основном, в таких случаях. (а) Статьи изначально предназначаются для электронного издания (Интернет-журнала), в котором допускаются цветные иллюстрации – обычно с некоторыми ограничениями по количеству цветов и пространственному разрешению. (б) ФПК в статьях представляются в виде цветных иллюстраций на бумаге (например, на вкладках). (в) ВПК предназначаются для использования в составе «дополнительных материалов» к статьям – эти материалы размещаются на сайтах НЖ в электронной форме.
Большинство IDE поддерживают выделение слов в коде не более чем пятью различными цветами. При этом работа программистов с кодом осуществляется, чаще всего, с использованием «темной темы» (фона экрана). Однако, как правило, имеются и возможности перенастройки IDE на «белый фон» (например, в Microsoft Visual Studio).
Для «светлых тем» при выделении «функциональных элементов» кода преобладают синий, фиолетовый, зеленый (цвета морской волны) и желтый цвета. Для темных тем – оранжевый, синий и зеленый.
Существенно, что используемый набор цветов зависит от ЯП и IDE. Так для ЯП С#, в абсолютном большинстве IDE преобладающим цветом для выделения «зарезервированных слов» и «классов» является синий; для выделения «названий классов» и «структур» – зеленый (цвета морской волны), для выделения «названий интерфейсов» – желтовато-зеленый.
Для языка программирования PHP при выделении «функциональных элементов» кода преобладают оранжевый и желтый цвета. Кроме того, строки (строковые выражения) выделяются зеленым или красным цветом – в зависимости от применяемого IDE.
Итак, для «темной темы» используется белый шрифт для кода программы с оранжевым, фиолетовым или синим выделением в коде «функциональных элементов». Включение в статьи, предназначенные для размещения в «бумажных НЖ», ФПК с темным фоном (например, в виде скриншотов экранов), неудобно для восприятия. Поэтому при редактировании статей естественным кажется решение преобразовать представленный авторами рисунок в виде скриншота с темным фоном в «негативное изображение». Это можно сделать в целом ряде программ – например, в распространяемом на бесплатной основе Irfan View (www.irfanview.com). Однако помимо замены черного фона на белый при этом изменятся и общепринятые (привычные) цвета для «функциональных элементов» кода программы, что усложнит восприятие ФПК в статьях. Поэтому редакторы НЖ могут рекомендовать авторам подготовить и прислать скриншот ФПК с использованием «светлой темы». Альтернативой является применение редакторами графических редакторов, позволяющих заменить только черный цвет фона на белый.
В тоже время для статей, предназначенных для публикации в «электронных НЖ», может быть предпочтительным использование для ФПК привычного для читателей-программистов темного фона «среды программирования» и набора цветов для групп «функциональных элементов».
4) Как правило, каждый из операторов листинга программы размещается в отдельной строке. Однако, например, в ЯП Basic (ряда диалектов) и некоторых других допускается размещение нескольких операторов в одной строке. Это может быть полезным для обеспечения компактности представления алгоритма в виде ФПК.
В языке ФОРТРАН (практически во всех версиях) специально предусмотрена возможность размещения операторов с длинными арифметическими выражениями в нескольких строках). Однако для обеспечения простоты восприятия ФПК обычно лучше использовать более короткие операторы (с введением вспомогательных переменных).
5) Комментарии к операторам в ЯП, используемых для публикаций ФПК, являются не обязательными. Они могут быть двух типов: размещаться в тех же строках, что и исполнимые операторы; размещаться в предыдущих или последующих строках – обычно с теми же отступами, что и сами комментируемые операторы. В ряде случаев для групп операторов даются «блоки комментариев», размещенные в нескольких строках. «Блоки комментариев» могут включаться и перед «функциями»» – для указания параметров входных и выходных данных, поддерживаемых исключений, автора функции и другой необходимой информации (это соответствует стилю JavaDoc и ему подобных). При этом считается, что написание комментариев непосредственно в «коде метода»/функции является примером плохого стиля программирования и отрицательно влияет на читабельность программного кода, понимание его алгоритма.
При редактировании статей необходимо исключать дублирование в текстовой части статей при описаниях алгоритмов того, что включено в ФПК.
Отметим, что в те годы, когда для публикаций использовался в основном язык ФОРТРАН, необходимый объем комментариев определялся исходя из тезиса «текст программы должен быть самодокументируемым», т.е. полностью включать в себя все необходимые сведения, необходимые для понимания логики программы, подготовки исходных данных, интерпретации результатов и пр. Поэтому в ряде случаев использовались весьма подробные комментарии, занимающие много строк текста. Сейчас, по крайней мере в научных статьях, чрезмерное количество комментариев к операторам программы может усложнять восприятие приводимых ФПК.
Некоторые дополнительные возможности электронных научных журналов в отношении представления описаний алгоритмов и ссылок на них
Электронные научные журналы уже занимают важное место в научной периодике России и других стран. Перечислим основные преимущества таких изданий с точки зрения представления информации об алгоритмах.
1) По алгоритмам, описываемым в статьях, могут быть представлены «дополнительные материалы», в виде отдельных файлов, на которые даются гиперссылки непосредственно из текста статьи. Такие файлы могут содержать не только листинги программ, но и быть исполнимыми файлами (и, как следствие, допускать проведение вычислительных экспериментов над рассматриваемыми в статьях алгоритмами). При этом размеры «дополнительных материалов» могут быть достаточно значительными, что позволяет «разгрузить» текст публикуемой статьи.
2) В качестве дополнительных материалов могут применяться и анимированные изображения, что позволяет удобно представить различные этапы (фазы) реализации некоторых алгоритмов.
3) Использование текстов статей и дополнительных материалов в электронной форме обеспечивает возможности показа ФПК и схем алгоритмов с сохранением тех цветов, которые используются авторами в представляемых материалах.
4) Возможность масштабирования текстов статей, представленных в электронной форме, в значительной степени может также снимать проблему разборчивости обозначений (особенно индексов) в формулах, используемых при характеристике алгоритмов; на схемах алгоритмов и пр.
Выводы
1. Описания алгоритмов являются важной частью значительного количества статей, публикуемых в научных журналах.
2. Эти описания могут быть представлены в различных формах и с разной степенью детальности. При выборе таких форм (или их комбинаций) должны учитываться соображения полноты представления алгоритма, простоты его восприятия, экономичности использования площади листов (особенно в печатных изданиях).
3. При редактировании статей, содержащих алгоритмы, должно учитываться следующее: необходимость обеспечения полноты и понятности описания алгоритмов; требования о соблюдении авторских прав на тексты статей и ГО в них, а также отражения научных приоритетов разработчиков алгоритмов; установленные ограничения на общие объемы статей, допускаемые в них максимальные количества ГО; зависимости стоимостей опубликования статей от их объемов; предопределенные графики выхода номеров; неопределенности в сроках получения ответов от рецензентов и авторов в процессе редакционно-издательской обработки статей и пр. Поэтому принятие решений научными редакторами статей (или номеров в целом) обычно носит, многокритериальный характер; осуществляется в условиях неопределенностей и некоторых рисков.
4. Имеются достаточно развитые программно-технические средства формирования различных представлений алгоритмов в графической форме. Однако возможности для редакторов исправления недочетов в ГО, представленных авторами, обычно весьма ограничены.
ИСТОЧНИКИ
- Агеев А.А., Кельманов А.В., Хамидуллин С.А., Шенмайер В.В., Пяткин А.В. Приближенный полиномиальный алгоритм для задачи очистки и редактирования данных //Математические методы распознавания образов. 2017. Т. 18. № 1. С. 46-47.
- Боброва Т.Н., Колпакова Л.А. Алгоритм подбора техники для выполнения технологических операций в растениеводстве //Вестник НГАУ, 2014, №4(33) – с.161-167
- Брумштейн Ю.М., Кострыкина С.С. Научное и техническое редактирование статей по физико-математическим и техническим наукам в российских журналах //Научная периодика: проблемы и решения. 2017. Т. 7. № 3. С. 151-179.
- Брумштейн Ю.М., Кострыкина С.С. Анализ направлений и особенностей использования информационно-телекоммуникационных технологий при подготовке, опубликовании, продвижении русскоязычных статей по физико-математическим и техническим наукам //Вестник Евразийской науки, 2018 №2, https://esj.today/PDF/04ECVN218.pdf (доступ свободный). Загл. с экрана. Яз. рус., англ.
- Брумштейн Ю.М. Научные статьи: общий анализ с позиций авторского права. //Интеллектуальная собственность.Авторское право, 2011-№3, с.4-17
- Брумштейн Ю.М. Анализ вопросов соблюдения публикационной этики в практике деятельности российских научных журналов // Интернет-журнал «Науковедение» Том 9, №3 (2017), с.1-31. http://naukovedenie.ru/PDF/23EVN317.pdf (доступ свободный). Загл. с экрана. Яз. рус., англ
- Брумштейн Ю.М. Анализ возможных подходов к методам компьютерного моделирования некоторых специальных задач геофильтрации //Известия Волгоградского государственного технического университета. 2014. Т. 22. № 25 (152). С. 5-11.
- Гусева Л.А. Редактирование заголовков в научных изданиях //В сборнике: Культура. Литература. Язык. Материалы конференции «Чтения Ушинского». 2010. С. 53-58.
- Джамбеков А.М. Нечеткая система управления процессом каталитического риформинга //Прикаспийский журнал: управление и высокие технологии. 2015. № 4 (32). С. 268-280.
- Долженко А.М., Рыбалко К.К., Робченко М.Н. Сравнение скорости сходимости различных видов генетических алгоритмов //Современные тенденции развития и перспективы внедрения инновационных технологий в машиностроении, образовании и экономике. 2016. № 1. С. 176-178.
- Дьяконов В.П. Справочник по алгоритмам и программам на языке бейсик для персональных ЭВМ.-М.:Наука. Гл.ред. физ.-мат. лит., 1987.-240с.
- Жирнова А.В., Петрова И.Ю., Плешакова Л.А. Информационная поддержка управления процессом реабилитации детей с ограниченными возможностями здоровья в условиях учреждений социального обслуживания //Прикаспийский журнал: управление и высокие технологии. 2017. № 4 (40). С. 104-109.
- Камаев В.А. Когнитивное моделирование социально-экономических систем.- Волгоград: ИУНЛ ВолГТУ, 2012.- 136с.
- Костина М.А., Мельникова Е.А. Алгоритмы искусственного интеллекта в задаче визуализации графа //Вектор науки Тольяттинского государственного университета. 2014. № 3. С. 32-35.
- Котюрова М.П. Виды внимания при редактировании погрешностей в научных текстах //Филологические заметки. 2007. Т. 2. С. 229-235.
- Лапчик М.П. Метод блок-схем в программировании //Пособие для студентов / Редактор В.В. Куликов. Омск, 1969.
- Латышева И.О., Суховерхов А.М. Cреда визуальной разработки блок-схем //Научно-технический вестник Санкт-Петербургского государственного университета информационных технологий, механики и оптики. 2007. № 41. С. 4-11.
- Логунова О.С., Ильина Е.А., Окжос К.М. Система поддержки принятия решения для оценки качества статей научного журнала //Фундаментальные исследования. 2016. № 2-3. С. 492-497.
- Локтионова Ю.Н., Мухаметдинова А.А. Проблемы анализа финансового состояния банков //Новая наука: От идеи к результату. 2016. № 12-1. С. 172-177.
- Макаров С.Л. Управление организационной культурой крупных промышленных предприятий на этапе внедрения инноваций //Бизнес. Образование. Право. 2013. № 1 (22). С. 161-165.
- Малыхина М.П., Частикова В.А., Власов К.А. Исследование эффективности работы модифицированного генетического алгоритма в задачах комбинаторики //Современные проблемы науки и образования. 2013. № 3. С. 32.
- Методология функционального моделирования IDEF0. Руководящий документ. М.:Госстандарт России, 2000г.
- Подосенова Т.Б. Алгоритм быстрой декомпозиции квазиэкспоненциальных зависимостей //Наука и современность. 2015. № 38. С. 184-190.
- Потапова Н.В. К вопросу об особенностях редактирования текста произведения научной литературы //Известия высших учебных заведений. Проблемы полиграфии и издательского дела. 2008. № 2. С. 125-131.
- Привалова В.М. «Создание, редактирование и публикация научной статьи мирового уровня». Аналитический обзор и практический семинар //Известия Самарского научного центра Российской академии наук. Социальные, гуманитарные, медико-биологические науки. 2017. Т. 19. № 3-1. С. 5-11.
- Сапожникова С. Проблемы сотрудничества и сотворчества автора и редактора //Развитие личности. 2015. № 2. С. 43-55.
- Соколова И.С. Роль комплаенса авторов научной статьи естественнонаучной тематики в процессах её редактирования //Социосфера. 2010. № 1. С. 13-14.
- Сокольский В.М., Брумштейн Ю.М. Анализ некоторых математических моделей реализации поликомпонентного внутривенного наркоза //Прикаспийский журнал: управление и высокие технологии.- Астрахань, 2012, №1, с.102-110
- Ткаченко Ю.В. Ошибки, наиболее часто допускаемые в материалах гуманитарной направленности //Вестник Приднестровского университета. Серия: Гуманитарные науки. 2014. № 1 (46). С. 46-51.
- Туякова З.С., Ефимова Ю.С. Этапы принятия решений в процессе формирования и реализации профессионального суждения бухгалтера //Интеллект. Инновации. Инвестиции. 2016. № 8. С. 40-47.
- Уилкинсон Дж.Х., Райнш С. Справочник алгоритмов на языке Алгол. Линейная алгебра.- М.:Машиностроение, 1976. — 390 с.
- Учаев Д.Ю., Брумштейн Ю.М., Ажмухадедов И.М., Князева О.М., Дюдиков И.А. Анализ и управление рисками, связанными с информационным обеспечением человеко-машинных АСУ технологическими процессами в реальном времени //Прикаспийский журнал: управление и высокие технологии. 2016. № 2 (34). С. 82-97.
- Филиппов С.А. Возможные подходы к организации рецензирования работ в эру Интернет //Современные проблемы науки и образования. 2015. № 1-1. С. 67.
- Фоменко А.Н. Алгоритм оценки машин и оборудования для разных целей оценки //Вопросы оценки. 2015. № 4 (82). С. 10-13.
- Brumshtein Yu. M. Information about Software Tools: Structure, Sources, and Contents // Scientific and Technical Information Processing, 2017, Vol. 44, No. 2, pp. 75–86. (DOI: 10.3103/S0147688217020034)
- Gorbova O.V. Modeling work of sorting station using UML //Наука та прогрес транспорту. 2015. № 1 (55). С. 129-138.
Analysis of the purposes and practical questions of algorithms descriptions editing in scientific articles
Brumsteyn Yury Moiseevich
Astrakhan state university, Astrakhan, Russia
ORCID: https://orcid.org/0000-0002-0016-7295
eLibrary: https://elibrary.ru/author_profile.asp?authorid=280533
E-mail: brum2003@mail.ru
Vasilyev Nikita Vyacheslavovich
Astrakhan state university, Astrakhan, Russia
ORCID: https://orcid.org/0000-0001-6305-1938
E-mail: nikivas@mail.ru
Abstract. In this paper are given the typical purposes of algorithms text descriptions and diagrams (ТDaD) representation in the articles on different branches of sciences. The composition of private characteristics, according to which are evaluated ТDaD, is analyzed. Authors are justified feasibility of comparison potentially possible options of ТDaD representations by comparing of the following characteristics combinations «algorithm description completeness – simplicity of description perception – the occupied page space».
The purposes and the general principles of editors choices of decisions and practical actions are described, when editing ТDaD in scientific articles.
The possibilities and restrictions for usage of links to the algorithms descriptions, placed in external sources, are considered; also – the defects, which are found when using such approach.
Authors are discussed merits and demerits of text descriptions usage for algorithms, including in combination with formulas, diagrams, tables. The main defects, which are found when using such approach by authors, the principles of these defects elimination are described.
In this article are specified opportunities and restrictions of program technical means usage for algorithms representation in the graphical form, including different types of diagrams.
Authors are justified the purposes and scopes for algorithms representation of IDEF- and DFD-charts, charts of actors (Use-Case); UML charts. The typical shortcomings, which are found in such charts, are listed; methods of their elimination are discussed.
Also in the paper are probed advantages/shortcomings of Gantt charts and network diagrams as means of the algorithms description. The typical defects, which are found in articles, when using these means, are specified; also – principles of these defects elimination.
Authors are considered the possibilities and restrictions of algorithms (integrated and detailed) representation as flowcharts; the typical defects, which are found in such diagrams; possible actions of scientific editors for these defects detection and elimination.
In this paper also is discussed the number of questions, concerned with the algorithms representation in the form of program code fragments; opportunities and restrictions of such approach are analyzed; also – their merits and demerits.
Some additional opportunities of ТDaD functionality extension, which can be used in electronic periodicals, are described.
Keywords: scientific journals; scientific articles; editing; algorithms; text descriptions; diagrams; representation methods; IDEF chart; DFD chart; UML chart; Gantt chart; network diagrams; flowcharts; charts creation methods; program code fragments; programming languages; articles imposition.
Уважаемые читатели! Комментарии к статьям принимаются на русском и английском языках.
Комментарии проходят премодерацию, и появляются на сайте после проверки редактором.
Комментарии, не имеющие отношения к тематике статьи, не публикуются.