#scripting #refactoring #flowchart
#написание сценариев #рефакторинг #блок-схема
Вопрос:
У меня есть загруженный набор подпрограмм для проверки или загрузки текущего клиентского приложения. Это начинается с ярлыка на рабочем столе Windows, который вызывает файл .WSF. Это вызывает несколько .Файлы VBS, an .INI для настроек и, возможно, файл .BAT. Некоторые из этих скриптовых документов имеют внутренние функции. На заключительном этапе открывается база данных Microsoft Access, что влечет за собой макрос AutoExec, который запускает некоторый VBA, включая форму, которая имеет собственную процедуру загрузки в VBA.
Ни одна из этих деталей не является особенно важной (поэтому, пожалуйста, не добавляйте тег VBA И не критикуйте мою драгоценную сложность). Дело в том, что у меня есть множество инструментов и контейнеров, и они могут быть функционально вложенными.
Мне нужны лучшие методы для разбора этого в блок-схеме. В настоящее время я полагаюсь на любое или все из следующего:
- особый цвет
- большое окно, в которое помещается подпрограмма
- классический символ «передачи управления»
- возможно, пояснительный вызов
Не следует ли мне расширить свой словарный запас для построения потоковых диаграмм? В руководствах объясняются квадрат, ромб, круг и практически ничего больше. Конечно, FC может помочь мне справиться с такого рода вещами:
- Множество типов сценариев позволяет мне отвечать различным потребностям, и я хочу указать инструмент / язык.
- Подпрограмма может привести к прерыванию общей задачи или ошибке, и я хочу показать, как это обрабатывается (или последствия для) «охватывающих» подпрограмм более высокого уровня.
- Я хочу отличать «внутренние» подпрограммы от подпрограмм в другом файле сценария.
- Параллельная обработка сценариев может стать критической, поэтому я хочу отметить это.
- The .INI-файл позволяет мне предоставлять всем подпрограммам постоянные значения. Как это отображается на графике?
- Функция может иметь аргумент (ы) и возвращаемое значение / ссылку … Я не знаю, как эффективно ссылаться даже на это.
Пожалуйста, предоставьте рекомендации или укажите мне на более полезный ресурс. Если вы порекомендуете набор инструментов анализа (например, UML, с которым я еще не освоился), пожалуйста, также скажите мне, где я могу найти хорошее введение.
Меня не интересует программное обеспечение. Пожалуйста, считайте это упражнением на белой доске.
Комментарии:
1. На самом деле я не видел блок-схемы в дикой природе около 25 лет. Я бы действительно не рекомендовал их.
2. Спасибо… Тогда, возможно, у вас есть ответ на мой вопрос.
3. Не совсем, потому что я не понимаю, что это такое. Лучшая документация для кода — это, как правило, сам код с комментариями и обзорным документом / руководством по его использованию.
4. Я считаю FC важным для устранения логических ошибок. Если это старая школа, то я могу с удовольствием перейти на что-нибудь новомодное. Но в любом случае это может помочь вам понять мою ощущаемую потребность или рабочую цель.
5. Блок-схемы не могут устранять логические ошибки, поскольку они не являются строгими и не имеют грамматики.
Ответ №1:
Обсуждение вопроса предполагает, что блок-схемы не являются полезными или точными.
Точность зависит от того, как построены блок-схемы. Если они создаются вручную, они похожи на любой другой документ, созданный вручную, и устареют почти мгновенно; это делает созданные вручную блок-схемы действительно бесполезными, вот почему людям, как правило, нравится смотреть на код.
[Остальная часть этого ответа нарушает требование OPs «не интересуется программным обеспечением (для создания блок-схем)», потому что я думаю, что это единственный способ получить их в какой-то полезной форме.]
Если блок-схемы получены из кода с помощью соответствующего инструмента анализа с точностью до языка, они будут точными. Смотрите примеры на http://www.semanticdesigns.com/Products/DMS/FlowAnalysis.html Эти примеры семантически точны, хотя страницы там не предоставляют точной семантики, но это всего лишь деталь документации.
Трудно найти такие инструменты:-} особенно, если вам нужны блок-схемы, охватывающие несколько языков и несколько «парадигм выполнения» (OP хочет, чтобы его INI-файлы были включены; они представляют собой своего рода подразумеваемые операторы присваивания, и я почти уверен, что он хотел бы моделировать действия SQL, которые бесполезны для блок-схемы, потому что они, как правило, представляют собой чистые вычисления над таблицами).
Также неясно, полезны ли такие блок-схемы. Примеры на странице, которую я предоставил, должны быть полуубедительными; если вы примете во внимание все микроскопические детали (например, возможность прерывания потока управления, возникающего при каждом вызове подпрограммы [потому что каждый вызов может вызвать исключение]), эти диаграммы становятся ужасно большими и быстрыми. Тот факт, что диаграммы занимают много места (прямоугольники, ромбы, линии, много пробелов), довольно сильно усугубляет ситуацию. Как только они становятся большими, вы буквально теряетесь в пространстве, следуя дугам. Опять же, хорошая причина для людей избегать блок-схем для целых систем. (Другая причина, по которой людям нравятся текстовые языки, заключается в том, что они на самом деле могут быть довольно плотными; вы можете многое получить на странице с помощью сжатого языка, и подождите, увидите APL 🙂
Они могут оказать незначительную помощь в отдельных функциях, если функция имеет сложную логику.
Я думаю, маловероятно, что вы собираетесь получить точные анализаторы языка, которые создают блок-схемы для всех языков, которые вы хотите, что такие анализаторы могут красиво составлять свои блок-схемы (вы хотите, чтобы JavaScript, вызывающий C #, запускал SQL …?)
На что вы могли бы надеяться, так это на компромиссное решение: отображать код с различными гиперссылками на другие артефакты, на которые ссылаются. Вам все еще нужна способность создавать такой код с гиперссылками (см. http://www.semanticdesigns.com/Products/Formatters/JavaBrowser.html с одной стороны, это может сработать), но вам также нужны гиперссылки через границы языка.
Я не знаю ни одного инструмента, который в настоящее время это делает. И я сомневаюсь, что у вас есть интерес или сила воли создавать такие инструменты самостоятельно.
Комментарии:
1. Это потрясающий анализ, хотя я могу указать, что он не соответствует OP («Меня не интересует программное обеспечение»). Из этого я бы сделал вывод, что вы считаете, что OP не подлежит ответственности как данное, что я уважаю; и, конечно, я понимаю, что мне, вероятно, не хватает интереса или силы воли. Мне по-прежнему интересно узнать, считает ли кто-нибудь, что расширенный словарь блок-схем или лучшая техника помогли бы мне (я имею в виду в качестве упражнения на белой доске). Спасибо за ваш ответ.
2. Вы правы, я немного увлекся «программным обеспечением для выполнения этого», но я думал, что в начале своего ответа я ясно объяснил, почему: ручное создание таких документов в основном приводит к устареванию бумаги («каракулям на доске»), поэтому этот путь просто не работает в долгосрочной перспективе. Если ваша единственная цель — рисовать на доске для целей технического совещания, то на самом деле блок-схемы в значительной степени достаточно хороши. Единственное, что я бы добавил, это дуги «исключения» из вычислительных узлов, говорящие: «если это не удается, следуйте этой дуге исключения до …». ….
3. … но я не понимаю, как анализ на доске может учесть всю сложность, которую вы, похоже, хотите смоделировать полезным способом. И если вы хотите справиться со всей этой сложностью, я думаю, вы вернулись к инструментам, которые трудно достать.