книги / Проектирование систем управления технологическими процессами и производствами
..pdfЛогический модуль является основой (фундаментом) структур ного программирования.
Структура программы определяется на основании структуры файлов (необходимо сопоставить структуры входных и выходных файлов) и детализации операционных диаграмм. Тщательный анализ соответствия входных и выходных данных позволяет вывить воз можные проблемы (невозможность получения требуемой после довательности входных данных, невозможность или сложность реа лизации обработки данных и др.) до того, как будут затрачены значительные усилия на составление программы.
При определении структуры программы проверяют:
-точность и достаточность детализации имеющихся специфи
каций;
-наличие источников всех выходных данных;
-принципиальную возможность решения прикладной задачи;
-корректность выполненного ранее обобщения или детали зации структуры файла;
-уровень сложности будущей программы.
Такой подход позволяет,создать программу, структура которой допускает применение принципа модульности.
Структура программы включает в себя:
-управляющий модуль;
-модуль обработки входных данных;
-модуль обработки выходных данных;
-модули вычислений;
Проектирование программного обеспечения базируется на мето дах анализа структуры файлов и проектирования логики программы. Прежде чем приступать к разработке логики программы необходимо разобраться в типовых структурах данных и подходах к анализу структуры файлов.
Проектирование программного обеспечения включает в себя логическое и физическое проектирование.
Логическое проектирование структуры программы предназ начено для решения прикладной задачи, а не для решения задачи, связанной с выбором конкретного языка программирования и кон кретной технической платформы. Решение прикладной задачи требу
ет выделения ряда простых модулей, которые и составят будущую программу.
Логическое проектирование структуры программы включает в себя следующие стадии:
-разработка структуры всех входных и выходных данных, которые не были включены в спецификации программы;
-выбор управляющего файла;
-уточнение структуры управляющего файла в соответствии с требованиями к обработке данных;
-выявление соответствия между данными и файлами;
-разработка укрупненной структуры программы;
-раскрытие содержания модулей, составление алгоритма программы;
-введение дополнительных модулей, обеспечивающих завер шение процесса обработки данных;
-оценка полученных результатов.
При разработке логической структуры программы необходимо пользоваться принципом предварительного считывания, предпола гающего считывание следующей порции данных по завершении текущей обработки. Чтение данных должно осуществляться с по мощью самостоятельной подпрограммы, в которую включаются все необходимые дополнительные функции (проверка упорядоченности данных, целостность данных и т.д.). Разработка подпрограммы чтения данных позволит значительно сократить общее время, затраченное на разработку системы и ее отладку. Модули, не выполняющие в разрабатываемой программе никаких действий, необходимо исключить из структуры программы.
По завершении разработки логической структуры программы необходимо провести ее критический анализ. Цель анализа - определить, насколько просто дальнейшее сопровождение разра батываемой программы и как полно выполнены требования, сформулированные в спецификациях.
Уточнение проекта проводится с учетом ограничений, которые оказывают влияние на проект программы, а именно:
-сметы затрат;
-технических средств;
-сроков завершения работ;
-объемно-временных характеристик выполнения программ. Последовательность операций при уточнении проекта:
-проверка приемлемости размера модулей;
-объединение или разъединение модулей;
-выявление общих функций;
-выделение самостоятельных модулей;
-корректировка проекта с учетом ограничений, наклады ваемых техническими средствами и программным обеспечением;
-критический анализ внесенных уточнений.
При дедуктивном подходе к разработке программ “сверху - вниз” возможны случаи, когда некоторые функции должны будут выпол няться в нескольких местах программы. Эти функции должны быть выделены в общий модуль. Могут вводиться ограничения на объем оперативной памяти или дискового пространства либо на применение прикладного пакета программ. В таких ситуациях в проект вносятся необходимые корректировки и производится критический анализ введенных уточнений.
Оптимизация программы связана с необходимостью улучшения каких-либо характеристик работы программы. Структурное програм мирование обычно удовлетворяет требованиям простоты разработки и поддержания высоких эксплуатационных характеристик програм мы, но объемно-временные характеристики выполнения программы могут не удовлетворять заказчиков. В этом случае необходимо провес ти работы по оптимизации. Однако моменту оптимизации программы должен предшествовать этап попытки добиться требуемых пара метров за счет увеличения объема оперативной памяти, исполь зования более новых компиляторов и более производительных ЭВМ.
Физическое проектирование программы
В процессе физического проектирования решаются следующие задачи:
-объединение взаимосвязанных логических модулей в один физический;
-разработка иерархической схемы физических модулей;
-разработка спецификации интерфейсов между физическими модулями;
- критический анализ результата физического проектирования. Физическое проектирование должно учитывать следующие
факторы:
-ограничения на максимальный размер модулей;
-производительность технических средств;
-возможность применения общих программ;
-простоту тестирования и отладки программ;
-возможность применения языков программирования низкого
уровня; - возможность одновременного использования труда несколь
ких программистов.
При разработке физических модулей целесообразно придер живаться правила (как и при логическом проектировании), согласно которому каждый модуль должен иметь одну точку входа и одну точку выхода. Однако это правило необязательное. Слепое следование ему может значительно усложнить физическую реализацию программы.
Кодирование программного продукта
Исходный текст программы является важной частью докумен тации на автоматизированную систему, поэтому необходимо прило жить максимальное усилие, чтобы он был понятен. Кодирование, или программирование, прикладной задачи базируется на принципах структурного программирования, включает программирование инте грированных распределенных приложений и языки программи рования.
Принцип структурного программирования
Принцип структурного программирования (кодирования) заклю чается в возможности “перевода” спецификаций программы на любой язык программирования. Структурное программирование (коди рование) включает:
-оформление текста программы;
-оформление логических модулей;
-введение имен данных;
-упрощение сопровождения программы;
-исключение безусловных операторов перехода;
-использование вложенных условных операторов;
-проведение критического анализа текста программы.
При оформлении текста программы особое внимание следует уделить использованию и размещению комментариев, в которых рас крываются назначения логических модулей. Необходимо указывать назначение идентификаторов, обрабатываемых файлов, перечень ссылочных документов. Рекомендуется использовать пропуски между строками программы, а каждый новый модуль начинать с новой страницы. Обычно комментарии составляют от 50 до 70 % от общего объема текста программы. Примечания, включаемые в текст про граммы, необходимо выделять и не смешивать с операторами языка программирования.
Логические модули оформляются таким образом, чтобы при озна комлении с ними не нужно было обращаться к другим разделам программы. В комментариях раскрывается назначение модуля, приводятся его описание, способы вызова и передачи параметров. При необходимости приводятся сведения взаимодействия модуля с другими приложениями. Каждую типовую логическую структуру необходимо реализовывать при помощи одних и тех же языков программирования.
Введение в программу мнемонических имен значительно облегчает процесс ее сопровождения. Имена объекта должны быть уникальны, обычно они определяются еще на этапе системного анализа. Мнемонические имена должны быть понятны пользователю и соответствовать наименованию объекта. Двусмысленность имен должна отсутствовать.
Программа должна быть максимально понятной и гибкой. Гиб кость обеспечивается тщательным проектированием системы и правильным кодированием с максимальным использованием воз можностей языка программирования.
Структурное кодирование (программирование) исключает использование безусловных операторов перехода типа “Go /о”. Текст программы при структурном проектировании составляется “сверху вниз” (оператор безусловного перехода усложняет отслеживание логики программы и не соответствует логике решения прикладной задачи).
Использование вложенных условных операторов типа “I f - then - else” позволяет эффективно представить логику структурированной
программы. Вложенные условные операторы применяются для организации обработки иерархических структур данных.
Критический анализ текста программы позволяет проконтроли ровать точность соответствия текста программы спецификациям, его понятность и соблюдение стандартов, действующих в организации. Необходимо убедиться в том, что спецификация правильно преоб разована в конструкции языка программирования и программа легко понимается. На все возникшие замечания подготавливаются ответы, а при необходимости изменяется текст программы.
6.2. Программирование интегрированных распределенных приложений
Если с самого начала при проектировании и разработке програм много обеспечения имеется в виду открытая система управления, то в процессе эксплуатации и модернизации СУ проблем практически не возникает. Однако практика показала, что ни в одной действи тельно серьезной распределенной информационной системе не удается обойтись без применения технологии интеграции. В основе этого лежит подход, предложенный международной группой OMG (Object Management Group).
К факторам, стимулирующим использование методов интеграции разнородных информационных ресурсов, относятся:
1)неоднородность,распределенность и автономность инфор мационныхресурсов системы. Неоднородность ресурсов может быть Синтаксической (при их представлении используются разные модели данных) и/или семантической (используются разные виды семан тических правил, детализируются и/или агрегируются разные аспекты предметной области). Возможна неоднородность информационных ресурсов, обусловленная использованием разных компьютерных платформ, операционных систем, систем управления базами данных, систем программирования и т.д.;
2)потребность в интеграционном комплексировании компонен тов автоматизированной системы. Естественным способам орга низации сложной системы является ее иерархически вложенное по строение;
3)реинжинерия системы. После создания начального варианта СУ неизбежно последует процесс ее непрерывных переулок и
доработок (реинжинерии), обусловленный развитием и изменением соответствующих процессов организации. Реконструкция системы не должна быть революционной. Все компоненты, не затрагиваемые процессом реинжиниринга, должны сохранять работоспособность;
4) решения проблем унаследованных систем. Любая компью терная система со временем становится неотъемлемой частью орга низации. Постоянно приходится решать задачу встраивания уста ревших информационных компонентов в систему, основанную на новых технологиях;
5) необходимость повторного использования ресурсов. Техно логия разработки ПО СУ должна способствовать использованию уже существующих компонентов, что в конечном итоге позволит перейти от ручного труда программистов к интенсивным методам (объектноориентированным) сборки, ориентированной на конкретную область применения автоматизированной системы;
6) необходимость продления жизненного цикла автоматизиро ванной системы. Чем дольше живет и приносит пользу СУ, тем это выгоднее для организации. Естественно, что для этого должна существовать возможность добавления в нее компонентов, спроек тированных и разработанных в другой технологии.
Основной задачей разработки программного обеспечения явля ется интеграция неоднородных БД, предоставление пользователям системы глобальной схемы БД и автоматическое преобразование операторов манипулирования БД глобального уровня в операторы, понятные соответствующим локальным СУБД.
Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети. А значит, дополнительно к собственным проблемам интеграции приходится решать все про блемы, присущие распределенным СУБД: управление глобальными транзакциями, сетевая оптимизация запросов и т.д. Для внешнего представления интегрированных БД обычно используется реляцион ная модель данных. В последнее время стали использовать объектноориентированные модели, однако практической основой является реляционная модель.
Языки программирования
Как известно, программа - это набор машинных команд, которые следует выполнить электронно-вычислительной машине для реали
зации того или иного алгоритма, описывающего решение прикладной задачи. Существует два типа программ-посредников, работающих с исходными текстами:
1) программа-компилятор - переводит исходный текст програм мы в машинный код и записывает его на жесткий магнитный диск в форме исполняемого (загрузочного) файла. После этого программа выполняется независимо от исходного текста;
2) программа-интерпретатор - всегда работает совместно с ис ходным текстом программы. Производится разбор инструкций исходного текста и ее немедленное исполнение.
Врежиме интерпретатора программа работает значительно медленнее, чем аналогичная программа в машинном коде. Это связанно с тем, что каждая инструкция разбирается отдельно во время выполнения, а не заранее, как при компиляции.
Внастоящее время существует следующая классификация языков программирования:
-языки ассемблера, где каждая команда чаще всего представ ляет собой одну машинную команду, записанную в символическом коде;
-универсальные языки программирования высокого уровня типа BASIC, FORTRAN, PASCAL и другие, где каждой команде соответствует несколько машинных команд либо целая подпрограмма
вмашинном коде;
-процедурные языки программирования типа TURBO BASIC, TURBO PASCAL, TURBO C++ и другие, включающие в свой состав текстовый редактор, командный язык и средства отладки;
-объектно-ориентированные языки программирования типа DELPHI, VISUAL BASIC, VISUAL C++ и другие, включающие целый спектр возможностей, позволяющих не только писать и отлаживать программы, но осуществлять управление программными проектами;
-командные и объектно-ориентированные языки управления базами данных типа PROGRESS, ORACLE, INGRESS, VISUAL FOX PRO и другие, позволяющие эффективно манипулировать данными
винформационных системах как на уровне отдельных записей, так и на уровне объектов.
Сточки зрения разработчиков программного обеспечения язык программирования должен предоставлять возможность разраба тывать программы в диалоговом режиме, то есть включать в себя:
-командный язык, позволяющий управлять запуском программ на выполнение;
-контроль изменений, то есть ведение учета по всем изме нениям в разрабатываемой программе;
-инструментальные средства проектирования программы, поддерживающей иерархическую организацию программы;
-редактирование исходного текста программы;
-средства интерактивной отладки и корректировки про граммы;
-управление программным проектом, то есть ведение опера тивной информации о сгенерированных объемах программ, числе компиляций и выполненных тестах;
-использование элементов структурного программирования, т.е. осуществление автоматического генерирования структуры про граммы.
6.3. Модель жизненного цикла разработки программного обеспечения
Под моделью жизненного цикла (ЖЦ) понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении разработки программного обеспечения. Модель ЖЦ зависит от специфики СУ и условий, в которых она создается и функционирует. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ программного обеспечения СУ, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Наибольшее распространение получила каскадная модель жизненного цикла разработки программного обеспечения.
В изначально существовавших однородных СУ каждое при ложение представляло собой единое целое. Для разработки такого типа приложений применяется каскадный метод. Основной его характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем этапе (рис. 6.3). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Рис.6.3. Структурная схема каскадного метода разработки программного обеспечения СУ
Положительные стороны каскадной модели разработки програм много обеспечения:
-на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
-выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответ ствующие затраты.
Однако эта модель имеет ряд недостатков, вызванных, прежде всего тем, что реальный процесс создания ПО СУ никогда полностью не укладывался в такую жесткую схему. Основным недостатком каскадного подхода является существенное запаздывание с получе нием результатов.
Циклический процесс разработки программного обеспечения каскадным методом (рис. 6.4) целесообразно применять при постро ении СУ, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с тем, чтобы предо