Использование блок-схемы или схемы для подпрограмм по программам

Question

У меня есть занятый набор процедур для проверки или загрузки текущего клиентского приложения. Он начинается с ярлыка на рабочем столе Windows, который вызывает файл .WSF. Это вызывает несколько файлов .VBS, .INI для настроек и, возможно, файл .BAT. Некоторые из этих документов сценария имеют внутренние функции. На последнем этапе открывается база данных Microsoft Access, которая включает макрос AutoExec, который запускает некоторые VBA, включая форму, которая имеет собственную подпрограмму загрузки в VBA.

Ни одна из этих деталей не является особенно важной (поэтому, пожалуйста, не добавляйте тег VBA, ИЛИ не критикуйте мою драгоценную сложность). Дело в том, что у меня есть множество инструментов и контейнеров, и они могут быть функционально вложенными.

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

• отличный цвет
• большая коробка с рутиной
• классический символ передачи управления
• возможно, объяснительный призыв

Разве я не должен увеличивать свой словарный запас в блок-схемах? Учебники объясняют квадрат, ромб, круг и ничего больше. Конечно, ФК может помочь мне разобраться с такими вещами:

1. Изобилие типов сценариев позволяет мне отвечать различным потребностям, и я хочу указать инструмент / язык.
2. Подпрограмма может привести к прерыванию общей задачи или ошибке, и я хочу показать, как ее обрабатывать (или последствия для) подпрограмм более высокого уровня.
3. Я хочу отличить "внутренние" подпрограммы от подпрограмм в другом файле сценария.
4. Одновременная обработка сценариев может стать критической, поэтому я хочу отметить это.
5. .INI-файл позволяет мне предоставлять всем подпрограммам постоянные значения. Как это намечено?
6. Функция может иметь аргумент (ы) и возвращаемое значение / ссылку ... Я не знаю, как эффективно процитировать даже это.

Пожалуйста, предоставьте руководство или укажите мне на очень полезный ресурс. Если вы порекомендуете набор инструментов для анализа (например, UML, который я еще не освоил), пожалуйста, также скажите мне, где я могу найти хорошее введение.

Я не заинтересован в программном обеспечении. Пожалуйста, примите это к сведению.

Answer 1

Обсуждение вопроса предполагает, что блок-схемы не являются полезными или точными.

Точность зависит от того, как построены блок-схемы.Если они построены вручную, они похожи на любой другой документ, созданный вручную, и почти мгновенно устаревают;это делает ручные блок-схемы действительно бесполезными, поэтому людям нравится смотреть на код.

[Остальная часть этого ответа нарушает требование ОП «не интересоваться программным обеспечением (для создания блок-схем)», потому чтоЯ думаю, что это единственный способ получить их в какой-то полезной форме.]

Если потоковые диаграммы получены из кода с помощью соответствующего инструмента анализа с точным языком, они будут точными.См. Примеры в http://www.semanticdesigns.com/Products/DMS/FlowAnalysis.html Эти примеры семантически точны, хотя страницы там не предоставляют точную семантику, но это просто детали документирования.

Трудно найти такие инструменты: -} особенноесли вам нужны потоковые диаграммы, которые охватывают несколько языков и несколько «парадигм выполнения» (OP хочет, чтобы его INI-файлы были включены; это какие-то неявные операторы присваивания, и я вполне уверен, что он хотел бы смоделировать действия SQL, которые неблок-схемы полезны, потому что они, как правило, являются чистыми вычислениями по таблицам).

Также неясно, являются ли такие блок-схемы полезными.Примеры на странице, которую я предоставил, должны быть достаточно убедительными;если принять во внимание все микроскопические детали (например, возможность дуги потока управления ABORT, исходящей от каждого вызова подпрограммы [потому что каждый вызов может вызвать исключение]), эти диаграммы становятся ужасно большими, быстрыми.Тот факт, что диаграммы занимают много места (прямоугольники, ромбы, линии, много пробелов), усугубляет это.Как только они становятся большими, вы буквально теряетесь в пространстве вслед за дугами.Опять же, хороший повод для людей избегать блок-схем для целых систем.(Другая причина, по которой людям нравятся текстовые языки, на самом деле они могут быть довольно плотными; вы можете получить много на странице с кратким языком, и подождите, пока не увидите APL:)

Они могут быть незначительнымипомощь в отдельных функциях, если функция имеет сложную логику.

Я думаю, что маловероятно, что вы получите анализаторы с точным языком, которые генерируют блок-схемы для всех языков, которые вы хотите, чтобы такие анализаторы могли правильно составлять свои блок-схемы (Вы хотите, чтобы JavaScript вызывал C # с запущенным SQL ...?)

На что можно надеяться, так это на компромиссное решение: отобразите код с различными гиперссылками на другие ссылочные артефакты.Вам все еще нужна возможность создавать такой гиперссылочный код (см. http://www.semanticdesigns.com/Products/Formatters/JavaBrowser.html, чтобы узнать, как это работает), но вам также нужны гиперссылки через языковые границы.

Я не знаю ни одного инструмента, который в настоящее время делаеттот.И я сомневаюсь, что у вас есть интерес или сила воли для создания таких инструментов самостоятельно.