Особенности имитационного моделирования производственных систем
Для анализа производственных систем, которые, во-первых, очень сложны, разноплановы, не имеют исчерпывающего математического описания, а, во-вторых, проходят ряд этапов проектирования, реализации и развития, адекватные математические модели, будь то логические или числовые, построить не представляется возможным. Естественным здесь является использование методов имитационного моделирования.
Система может быть однозначно описана набором значений производственных параметров, характерных для каждого конкретного ее состояния. Если эти значения внести в компьютер, то изменения их в ходе вычислительного процесса можно интерпретировать как имитацию перехода системы из одного состояния в другое. При таких предположениях имитационное моделирование можно рассматривать как динамическое представление системы путем продвижения ее от одного состояния к другому по характерным для нее операционным правилам. При имитационном моделировании производственных систем изменения их состояния происходят в дискретные моменты времени. Основная концепция имитационного моделирования системы и в этом случае состоит в отображении изменений ее состояния с течением времени. Таким образом, здесь определяющим является выделение и однозначное описание состояний моделируемой системы.
Имитационные модели позволяют без использования каких-либо аналитических или других функциональных зависимостей отображать сложные объекты, состоящие из разнородных элементов, между которыми существуют разнообразные связи. В эти модели может быть включен также и человек. Без принципиальных усложнений в такие модели могут быть включены как детерминированные, так и стохастические потоки (материальные и информационные). С помощью имитационного моделирования можно отображать взаимосвязи между рабочими местами, потоками материалов и изделий, транспортными средствами и персоналом. Несмотря на такие очевидные преимущества, прежде всего заключающиеся в широте и универсальности применения, при этом методе из вида упускается существо логических связей, что исключает возможность полной оптимизации получаемых на этой модели решений. Гарантируется лишь возможность отбора лучшего из просмотренных вариантов. Практически же имитационное моделирование во многих реальных случаях – единственно возможный способ исследования. После разработки имитационной модели с ней проводятся компьютерные эксперименты, которые позволяют сделать выводы о поведении производственной системы:
без ее реализации, если эта система находится в стадии проектирования;
без вмешательства в ее функционирование, если эта система действующая и такое вмешательство могло бы привести к нежелательным последствиям;
без разрушения действующей системы, если цель воздействия на нее состоит в определении допустимых пределов такого воздействия.
Появление и развитие методов компьютерного имитационного моделирования стало возможным также и в результате развития метода статистических испытаний, позволившего моделировать случайные события и процессы, занимающие большое место в реальных производствах. Имитационное компьютерное моделирование производственной системы можно использовать на всех этапах создания и эксплуатации этой системы:
до начала проектирования производственной системы с целью определения значимости и критичности ее параметров, а также оценки и оптимизации ее показателей;
на этапе разработки проекта системы с целью исследования и сравнения различных вариантов ее построения;
после окончания разработки системы и внедрения ее в эксплуатацию с целью получения информации, дополняющей и объясняющей производственную информацию, и для оценки эффективности системы.
При составлении имитационной модели и проведении с ее помощью моделирования исследуемого объекта необходимо решение нескольких связанных между собой задач. К ним относятся:
анализ моделируемой системы и составление ее формализованного описания, включая выявление информационно-логической структуры системы, идентификацию ее компонентов, выбор параметров, характеризующих состояние этих компонентов, разработку компьютерной модели системы, способной воспроизвести ее поведение, планирование эксперимента по развертыванию событий в компьютерной модели, отображающих события в моделируемой системе;
разработка методологии компьютерного статистического эксперимента, включая генерацию случайных или псевдослучайных чисел, имитацию различных случайных событий, статистическую обработку данных;
проведение собственно компьютерного эксперимента на имитационной модели, включая управление параметрами и переменными модели в ходе ее исследования на компьютере.
Тематический обзор*
1. ТЕХНОЛОГИя СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
1.1. Общая характеристика технологии создания программного обеспечения
Технология разработки программного обеспечения (ПО) определяется двумя факторами:
осуществляется ли разработка программ как составных элементов единой системы автоматизированной обработки информации либо как относительно независимого локального компонента общего программного комплекса;
какие программно-инструментальные средства используются для разработки и реализации задач на ЭВМ.
К программно-инструментальным средствам в первую очередь относятся алгоритмические языки и соответствующие им трансляторы, затем системы управления базами данных (СУБД) с языковыми средствами программирования в их среде, электронные таблицы с соответствующими средствами их настройки и т.п.
Рассмотрим технологию разработки программ на примере экономических задач.
Исторически сложившаяся технология разработки программ решения задач экономического характера строилась исходя из “позадачного” подхода, при котором слабо учитывались или вообще не учитывались программно-информационные взаимосвязи между отдельными задачами, а в качестве инструментальных средств программирования использовались исключительно алгоритмические языки. Принципиальная схема такого процесса представлена на рис. 1.1.
В зависимости от специфических особенностей конкретной задачи (ее вычислительной и логической сложности, состава и структуры исходной, промежуточной и результатной информации и т.п.), профессионального уровня подготовки специалистов и ряда других факторов некоторые этапы технологического процесса, представленные в общей схеме, могут быть объединены в более крупные этапы или реализовываться в неявном виде.
Первый этап технологического процесса представляет собой постановку задачи. На этом этапе раскрывается организационно-экономическая сущность задачи, т.е. формулируется цель ее решения; определяется взаимосвязь с другими задачами; указывается периодичность ее решения; устанавливаются состав и формы представления входной, промежуточной и результатной информации; характеризуются формы и методы контроля достоверности информации на ключевых этапах решения задачи; специфицируются формы взаимодействия пользователя с ЭВМ в ходе решения задачи и т.п.
Особое внимание в процессе постановки задачи уделяется детальному описанию входной, выходной (результатной) и промежуточной информации. При этом характеризуются:
форма представления отдельных реквизитов (цифровая, символьная и т.д.);
количество знаков (разрядов), выделяемых для записи реквизитов, исходя из их максимальной значности;
вид реквизита по его роли в процессе решения задачи (исходный, расчетный, нормативный, справочный и т.п.);
источник возникновения реквизита (документ, задача и т.п.).
Кроме того, для цифровой информации указываются: характер реквизита (целочисленный или дробный, причем для последнего дополнительно указывается количество десятичных знаков, выделяемых для записи дробной части числа), допустимый диапазон изменения величины реквизита (т.е. его максимальное и минимальное допустимое значение).
Для расчетных реквизитов дается соответствующее описание формул расчета и особо выделяются те реквизиты, которые используются при последующих решениях задачи, так как они подлежат сохранению в памяти ЭВМ.
Важной особенностью экономических задач является использование в процессе их решения массивов условно-постоянной информации, содержащей многократно используемые справочные, нормативные, расценочные, планово-директивные и другие сведения. Данная информация также детально специфицируется в соответствии с общими требованиями к описанию информации, и, кроме того, указывается периодичность внесения изменений в эти массивы.
Завершается постановка задачи описанием контрольного примера, демонстрирующего порядок решения задачи традиционным способом. Основное требование к контрольному примеру – отражение всего многообразия возможных форм существования исходных данных. Контрольный пример сопровождается перечислением различного рода как штатных, так и нештатных ситуаций, которые могут возникнуть при решении задачи, и описанием ответных действий пользователя в каждой конкретной ситуации.
Особенность реализации этого этапа технологического процесса заключается в том, что конечный пользователь разрабатываемой программы, хорошо знающий ее проблемную сторону, обычно хуже представляет специфику и возможности использования ЭВМ для решения задачи. В свою очередь, предметная область пользователя (особенно ее отдельные нюансы, способные оказать влияние на решение задачи) зачастую бывает незнакома разработчику программы, хотя он знает возможности и ограничения на применение ЭВМ. Именно эти противоречия являются основной причиной возникновения ошибок при реализации данного этапа технологического процесса разработки программ, которые затем неизбежно отражаются и на последующих этапах.
Отсюда вся важность и ответственность этого этапа, требующего осуществления корректной и полной постановки задачи, а также необходимости однозначного ее понимания как разработчиком программы, так и ее пользователем, в качестве которого обычно выступает постановщик задачи.
Второй этап в технологии разработки программ – экономико-математическое описание задачи и выбор метода ее решения. Наличие этого этапа обусловливается рядом причин, одна из которых вытекает из свойства неоднозначности естественного языка, на котором описывается постановка задачи. В связи с этим на нем выполняется формализованное описание задачи, т.е. устанавливаются и формулируются средствами языка математики логико-математические зависимости между исходными и результатными данными.
Экономико-математическое описание задачи обеспечивает ее однозначное понимание постановщиком (пользователем) и разработчиком программы. В процессе подготовки экономико-математического описания (модели) задачи могут использоваться различные разделы математики, особенно вычислительной и прикладной. При решении экономических задач наиболее часто для формализованного описания их постановок используются следующие классы моделей:
аналитические (вычислительные);
матричные (балансовые);
графические (частным видом которых являются сетевые).
Выбор класса модели, а иногда и конкретной формы ее представления внутри одного и того же класса в ряде случаев позволяет не только облегчить и ускорить процесс решения задачи, но и повысить точность получаемых результатов.
Хотя математическая запись постановки задачи, как правило, отличается высокой точностью отображения ее сущности, лаконичностью записи, а главное однозначностью понимания, далеко не для всех задач она может быть выполнена. Кроме того, математическое описание задачи в большинстве случаев трудно перевести на язык ЭВМ. Для задач, допускающих возможность экономико-математического описания, необходимо выбрать численный метод решения, а для нечисловых
задач – принципиальную схему решения в виде однозначно понимаемой последовательности выполнения элементарных математических и логических функций (операций).
При выборе метода решения задачи предпочтение отдается методу, который наиболее полно удовлетворяет основным требованиям:
обеспечивает необходимую точность получаемых результатов и не обладает свойством вырождения (т.е. бесконечного зацикливания на каком-либо участке решения задачи при определенном наборе исходных данных);
позволяет использовать готовые стандартные программы для решения задачи или ее отдельных фрагментов;
ориентирован на минимальный объем исходной информации;
способствует наиболее быстрому получению искомых результатов.
Сложность и ответственность этапа экономико-математического описания задачи и выбора (разработки) соответствующего метода ее решения часто требуют привлечения квалифицированных специалистов в области прикладной математики, обладающих знанием таких дисциплин, как исследование операций, математическая статистика, численный анализ, вычислительная математика и т.п.
Третий этап технологического процесса подготовки решения задач на ЭВМ представляет собой алгоритмизацию ее решения, т.е. разработку оригинального или адаптацию (уточнение и корректировку) уже известного алгоритма.
Алгоритмизация – это сложный творческий процесс. В основу процесса алгоритмизации положено фундаментальное понятие математики и программирования – алгоритм. Алгоритм – это конечный набор правил, однозначно раскрывающих содержание и последовательность выполнения операций для систематического решения определенного класса задач за конечное число шагов.
Любой алгоритм обладает следующими важными свойствами: детерминированностью, массовостью, результатностью и дискретностью.
Детерминированность алгоритма (определенность, однозначность) – свойство, определяющее однозначность результата работы алгоритма при одних и тех же исходных данных. Оно означает, что набор указаний алгоритма должен быть однозначно и точно понят любым исполнителем.
Массовость алгоритма – свойство, определяющее пригодность использования алгоритма для решения множества задач данного класса. Оно предполагает возможность варьирования исходными данными в определенных пределах. Свойство массовости алгоритма является определяющим фактором, обеспечивающим экономическую эффективность решения задач на ЭВМ, так как для задач, решение которых осуществляется один раз, целесообразность использования ЭВМ, как правило, диктуется внеэкономическими категориями.
Результатность алгоритма – свойство, означающее, что для любых допустимых исходных данных он должен через конечное число шагов (или итераций) завершить работу.
Дискретность алгоритма – свойство, означающее возможность разбиения определенного алгоритмического процесса на отдельные элементарные действия, возможность реализации которых человеком или ЭВМ не вызывает сомнения, а результат их выполнения вполне определен и понятен.
Таким образом, алгоритм дает возможность чисто механически решать любую задачу из некоторого класса однотипных задач.
Сложность и ответственность реализации этапа алгоритмизации объясняются тем, что для решения одной и той же задачи, как правило, существует множество различных алгоритмов, отличающихся друг от друга уровнем сложности, объемами вычислительных и логических операций, составом необходимой исходной и промежуточной информации, точностью получаемых результатов и другими факторами, которые могут оказать существенное влияние на эффективность выбранного способа решения задачи.
Процесс алгоритмизации решения задачи обычно реализуется по следующей схеме:
выделение автономных этапов процесса решения задачи (как правило, с одним входом и выходом);
формализованное описание содержания работ, выполняемых на каждом выделенном этапе;
проверка правильности реализации выбранного алгоритма на различных примерах решения задачи.
Составление (адаптация) программ (кодирование) является завершающим этапом технологического процесса разработки программных средств. Он предшествует началу непосредственно машинной реализации алгоритма решения задачи. Процесс кодирования заключается в переводе описания алгоритма на один из доступных для ЭВМ языков программирования. В процессе составления программы для ЭВМ конкретизируются тип и структура используемых данных, а последовательность действий, реализующих алгоритм, отражается посредством конкретного языка программирования.
Непосредственно к предыдущему этапу примыкает этап тестирования и отладки. Оба эти процесса функционально связаны между собой, хотя их цели несколько отличаются друг от друга. Тестирование представляет собой совокупность действий, предназначенных для демонстрации правильности работы программы в заданных диапазонах изменения внешних условий и режимов эксплуатации программы. Цель тестирования заключается в демонстрации отсутствия (или выявлении) ошибок в разработанных программах на заранее подготовленном наборе контрольных примеров. Процессу тестирования сопутствует понятие “отладка”, которое подразумевает совокупность действий, направленных на устранение ошибок в программах, начиная с момента обнаружения фактов ошибочной работы программы и завершая устранением причин их возникновения.
По своему характеру (причине возникновения) ошибки в программах делятся на синтаксические и логические.
Синтаксические ошибки в программе представляют собой некорректную запись отдельных языковых конструкций с точки зрения правил их представления для выбранного языка программирования. Эти ошибки выявляются автоматически при трансляции исходной программы (т.е. в процессе ее перевода с исходного языка программирования во внутренние коды машины) до ее выполнения. После устранения синтаксических ошибок проверяется логика работы программы на исходных данных. При этом возможны следующие основные формы проявления логических ошибок:
в какой-то момент программа не может продолжать работу (возникает программное прерывание, обычно сопровождающееся указанием места в программе, где оно произошло);
программа работает, но не выдает всех запланированных результатов и не выходит на останов (происходит ее “зацикливание”);
программа выдает результаты и завершает свою работу, но они полностью или частично не совпадают с контрольными.
После выявления логических ошибок и устранения причин их возникновения в программу вносятся соответствующие исправления и ее отладка продолжается.
Программа считается отлаженной, если она безошибочно выполняется на достаточно представительном наборе тестовых данных, обеспечивающих проверку всех ее участков (ветвей).
Процесс тестирования и отладки программ имеет итерационный характер и считается одним из наиболее трудоемких этапов процесса разработки программ. По оценкам специалистов, он может составлять от 30 до 50% в общей структуре затрат времени на разработку проектов и зависит от объема и логической сложности разрабатываемых программных комплексов.
Для сокращения затрат на проведение тестирования и отладки в настоящее время широко применяются специальные программные средства тестирования (например, генераторы тестовых данных) и приемы отладки (например, метод трассировки программ, позволяющий выявлять, все ли ветви программы были задействованы при решении задачи с заданными наборами исходных данных). После завершения процесса тестирования и отладки программные средства вместе с сопроводительной документацией передаются пользователю для эксплуатации. Основное назначение сопроводительной
документации – обеспечить пользователя необходимыми инструктивными материалами по работе с программными средствами. Состав сопроводительной документации обычно оговаривается заказчиком (пользователем) и разработчиком на этапе подготовки технического задания на программное средство. Как правило, это документы, регламентирующие работу пользователя в процессе эксплуатации программы, а также содержащие информацию о программе, необходимую в случае возникновения потребности внесения изменений и дополнений в нее. Сопроводительная документация призвана также облегчить процесс выявления причин возникновения тех или иных ошибок в работе программы, которые могут быть обнаружены уже в ходе ее эксплуатации пользователем.
При передаче пользователю разработанных прикладных программных средств создается специальная комиссия, включающая в свой состав представителей разработчиков и заказчиков (пользователей). Комиссия в соответствии с заранее составленным и утвержденным обеими сторонами планом проводит работы по приемке-передаче программных средств и сопроводительной документации. По завершении работы комиссии оформляется акт приемки-передачи.
В процессе внедрения и эксплуатации прикладных программных средств могут выявляться различного рода ошибки, не обнаруженные разработчиком при тестировании и отладке программных средств. Поэтому при реализации достаточно сложных и ответственных программных комплексов по согласованию пользователя (заказчика) с разработчиком этап эксплуатации программных средств может быть разбит на два подэтапа: экспериментальная (опытная) и промышленная эксплуатация. Смысл экспериментальной эксплуатации заключается во внедрении разработанных программных средств на объекте заказчика (как правило, параллельно с уже существующими методами решения задач) с целью проверки их работоспособности и удобства работы пользователей при решении реальных задач в течение достаточно длительного периода времени (обычно не менее года) Только после завершения периода экспериментальной эксплуатации и устранения выявленных при этом ошибок и учета замечаний программное средство передается в промышленную эксплуатацию.
Для повышения качества работ, оперативности исправления ошибок, выявляемых в процессе эксплуатации программных средств, а также выполнения различного рода модификаций, в которых может возникнуть необходимость в ходе эксплуатации, разработчик может по договоренности с пользователем осуществлять их сопровождение. Целесообразность привлечения высококвалифицированных специалистов для сопровождения программных средств у пользователя объясняется тем, что затраты на сопровождение программ значительно превосходят первоначальные затраты на их разработку (приобретение). Следует принимать во внимание, что по своему характеру и последовательности выполняемых действий внесение различного рода изменений в уже функционирующие программные средства представляет в значительной мере повторение рассмотренных выше этапов, начиная с постановки задачи и кончая внесением изменений в сопроводительную документацию.
Описанная схема технологического процесса разработки прикладных программных средств отражает их “жизненный цикл”, т.е. временной интервал с момента зарождения программы до момента полного отказа от ее эксплуатации.
1.2. Современные методы и средства разработки программного обеспечения
1.2.1. Современные методы разработки ПО
На протяжении всей истории программирования доминирующая роль отводилась проблеме определения методов и способов, облегчающих разработку и последующее сопровождение программ, сокращающих число ошибок при создании и модификации программ.
Опыт разработки больших и сложных программных комплексов показал, что рациональный подход к решению этой проблемы опирается на метод, имеющий несколько названий (метод нисходящего проектирования, метод пошаговой детализации, метод иерархического проектирования, top-down-подход), заключающийся в определении спецификаций компонентов системы путем последовательного выделения в ее составе отдельных составляющих и их постепенной детализации до уровня, обеспечивающего однозначное понимание того, что и как необходимо разрабатывать и реализовывать.
Этот метод является незаменимым при разработке сложных по характеру и больших по объему программ, когда к их разработке необходимо привлекать большое число программистов, работающих параллельно. Он позволяет концентрировать внимание разработчиков на наиболее ответственных частях программы, а также облегчает возможность постоянного контроля за ее работоспособностью по мере разработки, отладки и объединения отдельных составляющих программ за счет организации непрерывности этого процесса в течение всей разработки.
Для ускорения разработки программного комплекса часто вместо некоторых программ нижнего уровня, находящихся в процессе разработки, могут применяться специальные “программы-заглушки”. Программы-заглушки требуются только на ранних стадиях разработки для того, чтобы не сдерживать общий ход создания программного комплекса. Суть программы-заглушки заключается в том, что при обращении к ней в соответствии с заданным набором исходных тестовых данных она не формирует, а выбирает результат “решения” из заранее подготовленного набора. Благодаря этому обеспечивается возможность имитировать работу на ЭВМ реально создаваемой программы, а следовательно, осуществлять проверку работоспособности программ верхнего уровня еще до того, как будут разработаны и отлажены все составляющие программы нижнего уровня.
Реализация метода нисходящего проектирования тесно связана с другим понятием программирования – модульным проектированием, так как на практике при декомпозиции сложной программы возникает вопрос о разумном пределе ее дробления на составные части. Вместе с тем понятие модульности нельзя сводить только к представлению сложных программных комплексов в виде набора отдельных функциональных блоков. Модуль – это последовательность логически взаимосвязанных фрагментов задачи, оформленных как отдельная часть программы. При этом программные модули должны обладать следующими свойствами:
на модуль можно ссылаться (т.е. обращаться к нему) по имени, в том числе и из других модулей;
по завершении работы модуль должен возвращать управление тому модулю, который его вызывал;
модуль должен иметь один вход и выход;
модуль должен иметь небольшой размер, обеспечивающий его обозримость.
При разработке сложных программ, как правило, в них выделяют головной управляющий модуль, подчиненные ему модули, обеспечивающие реализацию отдельных функций управления, функциональную обработку (т.е. непосредственную реализацию основного назначения программного комплекса), а также вспомогательные модули, обеспечивающие сервисное обслуживание пакета (например, сбор и анализ статистики работы программы, обработка различного рода ошибочных ситуаций, обучение и выдача подсказок и т.п.).
Модульный принцип разработки программ обладает следующими преимуществами:
большую программу могут разрабатывать одновременно несколько исполнителей, и это позволяет сократить сроки ее разработки;
появляется возможность создавать (и многократно использовать в дальнейшем) библиотеки наиболее употребимых программ;
упрощается процедура загрузки больших программ в оперативную память, когда требуется ее сегментация;
возникает много естественных контрольных точек для наблюдения за осуществлением хода разработки программ, а в последующем для контроля за ходом исполнения программ;
обеспечивается более эффективное тестирование программ, проще осуществляются проектирование и последующая отладка.
Преимущества модульного принципа построения программ особенно наглядно проявляются на этапе сопровождения и модификации программных продуктов, позволяя значительно сократить затраты сил и средств на реализацию этого этапа.
Актуальная для начального периода развития и использования ЭВМ проблема разработки программ, занимающих минимум основной памяти и выполняющихся за кратчайшее время, в последующем в связи с резким падением стоимости аппаратной части ЭВМ, значительным возрастанием их быстродействия и объемов памяти сменилась необходимостью разработки и применения принципиально новых “индустриальных” методов составления программ. Все это нашло свое воплощение в разработке принципа структурного программирования. Одной из целей структурного программирования было стремление облегчить разработку и отладку программных модулей, а главное – их последующее сопровождение и модификацию.
В настоящее время структурное программирование – это целая дисциплина, объединяющая несколько взаимосвязанных способов создания ясных, легких для понимания программ. Эффективность применения современных универсальных языков программирования во многом определяется удобством написания с их помощью структурных программ.
Другое направление совершенствования процесса разработки прикладных программ – развитие программно-инструментальных средств программирования экономических задач. Основу таких средств программирования задач организационно-экономического управления составляют системы автоматизации программирования, или системы программирования, которые обеспечивают возможность решения широкого круга задач непосредственно в среде операционной системы ЭВМ.
При развитии этого направления следует учитывать специфику задач экономического управления:
доминирование задач с относительно несложными вычислительными алгоритмами и потребностью формирования различного рода накопительных итогов, т.е. задач “прямого счета”;
работа с большими массивами исходной информации (обычно упорядоченной определенным образом);
требование предоставления большинства результатной информации в виде документов табличной формы.
Решение указанных задач может быть осуществлено с использованием программно-инструментальных средств СУБД и электронных таблиц. Основное достоинство этих инструментальных средств заключается в том, что они предъявляют к пользователям меньшие требования в области программирования, обеспечивая в то же время достаточно быстрое и эффективное решение большинства задач экономического управления. В связи с этим они пользуются большой популярностью среди непрофессиональных программистов.
К наиболее развитым программно-инструментальным средствам относятся системы автоматизации проектирования (САПР) ПО, создание которых было начато в конце 70-х годов. Однако подобные разработки в то время слабо учитывали требования системного подхода, так как ограничивались автоматизацией лишь части этапов разработки ПО, причем, как правило, узкого класса задач. Вместе с тем появление и быстрое распространение современных персональных компьютеров среди профессиональных разработчиков ПО открыли новые перспективы в деле автоматизации благодаря их широким возможностям интерактивного взаимодействия. Так, за последнее десятилетие в области средств автоматизации программирования сформировалось новое направление под общим названием CASE-технология (Computer Aided Software Engineering).
CASE-технология представляет собой совокупность средств системного анализа, проектирования, разработки и сопровождения сложных программных систем, поддерживаемых комплексом взаимоувязанных инструментальных средств автоматизации всех этапов разработки программ. Благодаря структурным методам CASE-технология на стадиях анализа и проектирования обеспечивает разработчиков широкими возможностями для различного рода моделирования, а централизованное хранение всей необходимой для проектирования информации и контроль за целостностью данных гарантируют согласованность взаимодействия всех специалистов, занятых в разработке ПО.
Высокая “тяжесть” последствий ошибок, присущих этапу составления спецификаций для автоматизации информационной системы объекта, вызвала поиск путей сокращения их числа на этом этапе до минимума. Естественным решением проблемы была разработка формализованного аппарата для составления описания и последующего анализа информационной модели системы. Впервые такой подход с системных позиций был реализован сотрудниками Мичиганского университета под руководством проф. Д.Тайкроу в рамках проекта ISDOS (Information System Design and Optimization System – проектирование и оптимизация информационных систем).
В основу реализации проекта ISDOS были положены специально разработанный язык PSL (Problem Stain-lent Language – язык постановки задач), который обеспечивал описание целей, функций и задач систем организационно-экономического управления, и программный анализатор описаний PSA (Problem Statment Analizator – анализатор постановок задач), выполненных средствами PSL.
На языке PSL пользователь специфицирует параметры, определяющие входы и выходы информационной системы и их временные характеристики.
Проект ISDOS был первой западной системой автоматизированного формализованного анализа требований к программному обеспечению. Он состоял из взаимосвязанных модулей, которые обеспечивали:
ввод, контроль и кодирование спецификаций проектируемой системы;
анализ правильности постановки и согласованности задач;
выявление ошибок и выдачу сообщений пользователям, а также устранение дублирования в исходной информации;
преобразование постановок задач после проверки и корректировки исходных данных в машинные программы в соответствии с заданными требованиями к системе;
выделение основных элементов информационной системы.
Первая версия ISDOS, разработанная применительно к системам административного управления, впоследствии применялась в области управления правительственными организациями, космическими объектами, торговыми организациями и т.д.
Язык PSL также позволяет системному аналитику описать в формализованном виде требуемые результаты решения задач, необходимые входные данные, взаимосвязи между отдельными процедурами и данными, представить информацию о характеристиках отдельных модулей, процедур, данных и т.д.
Подсистема PSA анализирует поставленную и описанную с помощью PSL проблему и генерирует полезные для разработчика интегральные характеристики, такие, как формальные постановки задач, иерархические структуры данных, рекомендации по выбору ключевых слов, обобщенные блок-схемы алгоритмов обработки данных при решении задач и ряд других характеристик.
Постоянный поиск методов совершенствования процессов разработки прикладных программных средств обусловил появление в начале 80-х годов методологии, по которой разработка программы начиналась не после завершения процесса выработки окончательных требований к ней, а как только устанавливались требования на первый, “стартовый” (пилотный) вариант прикладной программы, позволяющий начать содержательную работу по ее реализации на компьютере. Это дало пользователю возможность, получая уже с первых шагов конкретное представление о характере реализации задачи, уточнять ее постановку. Тем самым облегчался процесс экспериментального поиска нужного решения автоматизации задачи. Благодаря тесному взаимодействию разработчика с заказчиком (пользователем) на самом ответственном этапе создания прикладных программ между ними достигалось быстрое взаимопонимание цели поставленной задачи и возможности ее автоматизации в данных конкретных условиях. Это повышало скорость разработки программ и послужило основанием для названия такой технологии RAD (Rapid Application Development – быстрая разработка программ), которая получила широкое распространение.
Другое направление разработки прикладных программных средств, олицетворяющее собой современный подход к реализации широкого круга задач для принятия управленческих решений, базируется на концепции создания специального хранилища данных (Data Warehouse). Основное отличие концепции Data Warehouse от традиционного представления баз данных заключается в следующем:
во-первых, в том, что актуализация данных в Data Warehouse означает не обновление элементов информации, а добавление новых элементов к уже имеющимся (что расширяет возможности проведения различного рода сравнительного анализа);
во-вторых, в том, что наряду с информацией, непосредственно отражающей состояние системы управления, в Data Warehouse аккумулируются и метаданные.
Метаданные (данные о данных) облегчают возможность визуального представления содержимого Data Warehouse, позволяют, “перемещаясь” по хранилищу, быстро отбирать необходимые данные для последующей обработки. Основные типы метаданных Data Warehouse отражают:
структуру и содержимое хранилища;
соответствие между исходными и выходными данными;
объемные характеристики данных;
критерии архивирования;
отношения между данными;
информацию по кодированию;
интервал жизни данных и т.п.
Концепция Data Warehouse поддерживается RAD средствами разработки прикладного ПО, благодаря которым даже неспециалист может быстро создавать программные приложения, подбирая необходимые прототипы программ, расширяя их набор путем объединения и настройки более мелких.
Создание программных приложений для Data Warehouse по RAD-технологии представляет собой достаточно простой итеративный процесс, состоящий из следующих пяти этапов:
отбора необходимых объектов для создания программных приложений;
установки переменных для просмотра и анализа данных;
различного рода настройки атрибутов в соответствии с требованиями отображения информации и алгоритмов обработки;
тестирования приложения, возвращаясь при необходимости к предыдущим этапам;
создания пользовательского интерфейса и пиктограмм.
Концепция Data Warehouse обеспечивает возможность разработки программных приложений для поддержки процессов принятия решений с использованием OLAP-систем. Система OLAP (On-Line Analytical Processing) предоставляет возможность разработки прикладного ПО информационных систем, ориентированных на организацию многомерных баз данных и создание корпоративных сетей, а также обеспечивает поддержку Web-технологий в сетях Internet/Intranet.
Успешное применение инструментальных средств OLAP-систем объясняется быстротой разработки приложений, гибкостью и широкими возможностями в области доступа к данным и их преобразования. В настоящее время на рынке ПО предлагается большое число OLAP-систем, разработчиками которых являются различные фирмы, например Arbor Software, IBM, Informix, Microsoft, Oracle, SAS Institute, Sybase.
1.2.2. Инструментарий технологии программирования
Инструментарий технологии программирования– программные продукты поддержки (обеспечения) технологии программирования.
В рамках этого направления сформировались следующие группы программных продуктов (рис. 1.2):
средства для создания приложений, включающие:
– локальные средства, обеспечивающие выполнение отдельных работ по созданию программ;
– интегрированные среды разработчиков программ, обеспечивающие выполнение комплекса взаимосвязанных работ по созданию программ;
средства для создания информационных систем (СASE-технология), представляющие методы анализа, проектирования и создания программных систем и предназначенные для автоматизации процессов разработки и реализации информационных систем.
1.2.3. Средства для создания приложений
Локальные средства разработки программ
Эти средства на рынке программных продуктов наиболее представительны и включают языки и системы программирования, а также инструментальную среду пользователя.
Язык программирования – формализованный язык для описания алгоритма решения задачи на компьютере.
Средства для создания приложений – совокупность языков и систем программирования, а также различные программные комплексы для отладки и поддержки создаваемых программ.
Языки программирования можно условно разделить на следующие классы (если в качестве признака классификации взять синтаксис образования конструкций языка):
машинные языки (computer language) – языки программирования, воспринимаемые аппаратной частью компьютера (машинные коды);
машинно-ориентированные языки (computer-oriented language) – языки программирования, которые отражают структуру конкретного типа компьютера (ассемблеры);
алгоритмические языки (algorithmic language) – языки программирования, не зависящие от архитектуры компьютера, для отражения структуры алгоритма (Паскаль, Си, Фортран, Бейсик и др.);
процедурно-ориентированные языки (procedure-oriented
language) – языки программирования, где имеется возможность описания программы как совокупности процедур (подпрограмм);
проблемно-ориентированные языки (universal programming language) – языки программирования, предназначенные для решения задач определенного класса (Лисп, Пролог, Симула и др.);
интегрированные системы программирования.
Другой классификацией языков программирования является их деление на языки, ориентированные на реализацию основ структурного программирования, и объектно-ориентированные языки, поддерживающие понятие объектов и их свойств и методов обработки.
Программа, подготовленная на языке программирования, проходит этап трансляции, когда происходит преобразование исходного кода программы (source code) в объектный код (object code), который далее пригоден к обработке редактором связей. Редактор связей – специальная программа, обеспечивающая построение загрузочного модуля (load module), пригодного к выполнению (рис. 1.3).
Трансляция может выполняться с использованием средств компиляторов (compiler) или интерпретаторов (interpreter). Компиляторы транслируют всю программу, но без ее выполнения. Интерпретаторы, в отличие от компиляторов, выполняют пооператорную обработку и выполнение программы.
Существуют специальные программы, предназначенные для трассировки и анализа выполнения других программ, так называемые отладчики (debugger). Лучшие отладчики позволяют осуществить трассировку (отслеживание выполнения программы в пооператорном варианте), идентификацию места и вида ошибок в программе, “наблюдение” за изменением значений переменных, выражений и т.п. Для отладки и тестирования правильности работы программ создается база данных контрольного примера.
Более мощным средством разработки программ являются системы программирования.
Системы программирования (programming system) включают:
компилятор;
интегрированную среду разработчика программ;
отладчик;
средства оптимизации кода программ;
набор библиотек (возможно с исходными текстами программ);
редактор связей;
сервисные средства (утилиты) для работы с библиотеками, текстовыми и двоичными файлами;
справочные системы;
документатор исходного кода программы;
систему поддержки и управления проектом программного комплекса.
Средства поддержки проектов – новый класс средств разработки программного обеспечения, предназначенный для:
отслеживания изменений, выполненных разработчиками программ;
поддержки версий программы с автоматической разноской изменений;
получения статистики о ходе работ проекта.
Инструментальная среда пользователя представлена специальными средствами, встроенными в пакеты прикладных программ, такими, как:
библиотека функций, процедур, объектов и методов обработки;
макрокоманды;
клавишные макросы;
языковые макросы;
программные модули-вставки;
конструкторы экранных форм и отчетов;
генераторы приложений;
языки запросов высокого уровня;
языки манипулирования данными;
конструкторы меню и многое другое.
Средства отладки и тестирования программ предназначены для подготовки разработанной программы к промышленной эксплуатации.