6.1. Типовые логические структуры проектирования программного обеспечения

могут быть физически реализованы в виде самостоятельно компили­ руемых компонентов. Последние, в свою очередь, могут состоять из внутренних модулей.

Рис. 6.2. Типовые подструктуры описания данных:

1)последовательная подструктура (последовательное выполнение операторов обработки данных);

2)подструктура Ветвления (аналог оператора IF - ELSE - THEN);

3)подструктура Выбора (аналог оператора CASE);

4)подструктура Цикла (аналог оператора DO WHILE)

Логический модуль является основой (фундаментом) структур­ ного программирования.

Структура программы определяется на основании структуры файлов (необходимо сопоставить структуры входных и выходных файлов) и детализации операционных диаграмм. Тщательный анализ соответствия входных и выходных данных позволяет вывить воз­ можные проблемы (невозможность получения требуемой после­ довательности входных данных, невозможность или сложность реа­ лизации обработки данных и др.) до того, как будут затрачены значительные усилия на составление программы.

При определении структуры программы проверяют:

-точность и достаточность детализации имеющихся специфи­

каций;

-наличие источников всех выходных данных;

-принципиальную возможность решения прикладной задачи;

-корректность выполненного ранее обобщения или детали­ зации структуры файла;

-уровень сложности будущей программы.

Такой подход позволяет,создать программу, структура которой допускает применение принципа модульности.

Структура программы включает в себя:

-управляющий модуль;

-модуль обработки входных данных;

-модуль обработки выходных данных;

-модули вычислений;

Проектирование программного обеспечения базируется на мето­ дах анализа структуры файлов и проектирования логики программы. Прежде чем приступать к разработке логики программы необходимо разобраться в типовых структурах данных и подходах к анализу структуры файлов.

Проектирование программного обеспечения включает в себя логическое и физическое проектирование.

Логическое проектирование структуры программы предназ­ начено для решения прикладной задачи, а не для решения задачи, связанной с выбором конкретного языка программирования и кон­ кретной технической платформы. Решение прикладной задачи требу­

ет выделения ряда простых модулей, которые и составят будущую программу.

Логическое проектирование структуры программы включает в себя следующие стадии:

-разработка структуры всех входных и выходных данных, которые не были включены в спецификации программы;

-выбор управляющего файла;

-уточнение структуры управляющего файла в соответствии с требованиями к обработке данных;

-выявление соответствия между данными и файлами;

-разработка укрупненной структуры программы;

-раскрытие содержания модулей, составление алгоритма программы;

-введение дополнительных модулей, обеспечивающих завер­ шение процесса обработки данных;

-оценка полученных результатов.

При разработке логической структуры программы необходимо пользоваться принципом предварительного считывания, предпола­ гающего считывание следующей порции данных по завершении текущей обработки. Чтение данных должно осуществляться с по­ мощью самостоятельной подпрограммы, в которую включаются все необходимые дополнительные функции (проверка упорядоченности данных, целостность данных и т.д.). Разработка подпрограммы чтения данных позволит значительно сократить общее время, затраченное на разработку системы и ее отладку. Модули, не выполняющие в разрабатываемой программе никаких действий, необходимо исключить из структуры программы.

По завершении разработки логической структуры программы необходимо провести ее критический анализ. Цель анализа - определить, насколько просто дальнейшее сопровождение разра­ батываемой программы и как полно выполнены требования, сформулированные в спецификациях.

Уточнение проекта проводится с учетом ограничений, которые оказывают влияние на проект программы, а именно:

-сметы затрат;

-технических средств;

-сроков завершения работ;

-объемно-временных характеристик выполнения программ. Последовательность операций при уточнении проекта:

-проверка приемлемости размера модулей;

-объединение или разъединение модулей;

-выявление общих функций;

-выделение самостоятельных модулей;

-корректировка проекта с учетом ограничений, наклады­ ваемых техническими средствами и программным обеспечением;

-критический анализ внесенных уточнений.

При дедуктивном подходе к разработке программ “сверху - вниз” возможны случаи, когда некоторые функции должны будут выпол­ няться в нескольких местах программы. Эти функции должны быть выделены в общий модуль. Могут вводиться ограничения на объем оперативной памяти или дискового пространства либо на применение прикладного пакета программ. В таких ситуациях в проект вносятся необходимые корректировки и производится критический анализ введенных уточнений.

Оптимизация программы связана с необходимостью улучшения каких-либо характеристик работы программы. Структурное програм­ мирование обычно удовлетворяет требованиям простоты разработки и поддержания высоких эксплуатационных характеристик програм­ мы, но объемно-временные характеристики выполнения программы могут не удовлетворять заказчиков. В этом случае необходимо провес­ ти работы по оптимизации. Однако моменту оптимизации программы должен предшествовать этап попытки добиться требуемых пара­ метров за счет увеличения объема оперативной памяти, исполь­ зования более новых компиляторов и более производительных ЭВМ.

Физическое проектирование программы

В процессе физического проектирования решаются следующие задачи:

-объединение взаимосвязанных логических модулей в один физический;

-разработка иерархической схемы физических модулей;

-разработка спецификации интерфейсов между физическими модулями;

- критический анализ результата физического проектирования. Физическое проектирование должно учитывать следующие

факторы:

-ограничения на максимальный размер модулей;

-производительность технических средств;

-возможность применения общих программ;

-простоту тестирования и отладки программ;

-возможность применения языков программирования низкого

уровня; - возможность одновременного использования труда несколь­

ких программистов.

При разработке физических модулей целесообразно придер­ живаться правила (как и при логическом проектировании), согласно которому каждый модуль должен иметь одну точку входа и одну точку выхода. Однако это правило необязательное. Слепое следование ему может значительно усложнить физическую реализацию программы.

Кодирование программного продукта

Исходный текст программы является важной частью докумен­ тации на автоматизированную систему, поэтому необходимо прило­ жить максимальное усилие, чтобы он был понятен. Кодирование, или программирование, прикладной задачи базируется на принципах структурного программирования, включает программирование инте­ грированных распределенных приложений и языки программи­ рования.

Принцип структурного программирования

Принцип структурного программирования (кодирования) заклю­ чается в возможности “перевода” спецификаций программы на любой язык программирования. Структурное программирование (коди­ рование) включает:

-оформление текста программы;

-оформление логических модулей;

-введение имен данных;

-упрощение сопровождения программы;

-исключение безусловных операторов перехода;

-использование вложенных условных операторов;

-проведение критического анализа текста программы.

При оформлении текста программы особое внимание следует уделить использованию и размещению комментариев, в которых рас­ крываются назначения логических модулей. Необходимо указывать назначение идентификаторов, обрабатываемых файлов, перечень ссылочных документов. Рекомендуется использовать пропуски между строками программы, а каждый новый модуль начинать с новой страницы. Обычно комментарии составляют от 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 и другие, позволяющие эффективно манипулировать данными

винформационных системах как на уровне отдельных записей, так и на уровне объектов.

Сточки зрения разработчиков программного обеспечения язык программирования должен предоставлять возможность разраба­ тывать программы в диалоговом режиме, то есть включать в себя: