Ильин А.А., Евсюков В.В., Ильин Р.А. Информатика

Подождите немного. Документ загружается.

–

251

–

правило, позволяет повысить производительность исполняемого программного

кода на 10 - 15%, однако сам процесс оптимизации требует значительных

временных затрат.

В результате компиляции создается

объектный модуль,

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

полученную программу еще невозможно, так как в ней не указаны конкретные

адреса используемых ячеек оперативной памяти (при запуске программы на

выполнение она предварительно переписывается в ОЗУ). Поэтому объектный

модуль должен быть обработан специальной программой –

редактором связей,

в результате чего создается загрузочный модуль с относительными адресами

памяти. При размещении загрузочного модуля в оперативной памяти, начиная

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

быть определены на основе имеющихся относительных адресов. При

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

модуль готовые последовательности машинных команд, реализующие

конкретные

операции. Время компиляции программ значительно увеличивается

при обработке данных со сложной структурой, особенно со структурой,

изменяющейся во время выполнения программы. При этом непосредственно в

процессе выполнения программы в машинный код приходится вставлять

множество дополнительных проверок, анализировать наличие ресурсов

операционной системы, динамически (т. е. в процессе выполнения

программы) их захватывать и освобождать

и др. В результате эффективность

полученного в результате компиляции машинного кода значительно снижается.

В целом для компиляторов характерны следующие особенности:

• откомпилированная программа работает на несколько порядков

быстрее, чем эта же исходная программа выполняется с использованием

интерпретатора;

• в отличие от интерпретатора, компилятор при выполнении программы

не занимает место в

ОЗУ (выгружается оттуда после завершения компиляции);

• программа в виде загрузочного модуля может быть перенесена на

другие компьютеры (со схожими наборами машинных команд).

На практике находят применение трансляторы, реализованные в виде

интерпретатора-компилятора, позволяющего на этапе разработки и отладки

программ преобразовывать отдельные операторы в режиме интерпретатора, а

по завершении отладки исходная

программа транслируется полностью в

объектный модуль в режиме компиляции. Подобный подход позволяет

сократить время отладки и обеспечить эффективное исполнение программы.

–

252

–

6.2. ТЕХНОЛОГИИ СИСТЕМНОГО ПРОЕКТИРОВАНИЯ

ПРОГРАММНЫХ СРЕДСТВ

Выбор технологии разработки конкретных приложений определяется

рядом факторов, важнейшими из которых являются:

• степень взаимосвязи приложения с другими приложениями

(приложение зачастую является элементом единой системы

автоматизированной обработки информации);

• тип используемых программно-инструментальных средств;

• сложность решаемой задачи.

Достаточно простой и широко распространенный на практике подход

предполагает разработку автономного приложения

, практически не

учитывающего или слабо учитывающего информационное взаимодействие с

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

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

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

разработки приложения для решения экономической задачи с таким подходом

включает в себя ряд этапов (рис.6.2).

На первом

этапе осуществляется постановка задачи, представляющая

собой точную формулировку решения задачи на компьютере с описанием

входной и выходной информации. При этом формулируется цель и

периодичность решения задачи; конкретизируются состав и формы

представления входной, промежуточной и результатной информации;

определяется необходимость контроля значений различных реквизитов и др.

Необходимая для решения задачи входная информация может быть

представлена в

виде первичных документов как ручного, так и машинного

заполнения, содержимого баз данных (в компьютере и на носителях

информации), приходящих по каналам связи сообщений. При их описании

конкретизируется тип каждого используемого реквизита (числовой,

символьный, дата и др.) и его разрядность (достаточная для ввода

потенциально самого “длинного” значения); необходимая точность описания

реквизита (посредством

задания числа десятичных знаков после запятой);

возможный диапазон изменения значений реквизитов. Аналогичная

информация задается и для выходных результатов.

–

253

–

Постановка

задачи

Экономико-

математичекое

описание

Разработка

алгоритма

Программирование

Тестирование и

отладка

Приемно-сдаточные

испытания

Опытная

эксплуатация

Промышленная

эксплуатация

Рис. 6.2. Обобщенная схема процесса разработки приложения

Кроме того, при подготовке приложения, предполагающего его

последующее использование в интерактивном режиме работы с управлением

ходом обработки данных со стороны пользователя, значительное внимание

уделяется организации иерархического меню и отображению различного рода

элементов управления (в окнах для Windows-приложений). Только тесное

взаимодействие постановщика задачи (он же, как

правило, и есть будущий

пользователь создаваемого приложения) и программиста (исполнителя)

способно обеспечить формирование эффективного пользовательского

интерфейса, так как постановщик, в целом, знает, что необходимо реализовать

в приложении, а программисту известны типовые, широко используемые в

практике разработки приложений, решения.

Значительна роль пользователя при постановке задачи и при задании

контрольного примера, предполагающего

формирование выходных данных

(выходных документов, массивов, сообщений и др.) в соответствии с

используемыми входными данными. В целом формирование контрольного

примера носит компромиссный характер, поскольку при достаточно кратком

его описании (представлении) необходимо адекватно отобразить многообразие

возможных изменений входных данных. При этом пользователь должен

акцентировать внимание программиста на возможности возникновения тех или

иных нештатных ситуаций, которые могут проявиться в процессе решения

задачи, а также конкретизировать характер действий пользователя при их

появлении.

Следует отметить большую роль пользователя на этапе постановки

задачи в процессе разработки требуемого приложения. Именно пользователь,

выступающий в роли постановщика задачи, знает ее специфические

особенности (говорят, что хорошо поставленная задача – это уже

половина

успеха). Однако, как правило, пользователь значительно хуже ориентируется в

современном инструментарии программирования, представляя лишь

простейшие возможности его использования. В свою очередь, программист во

многих случаях не способен самостоятельно учесть потенциально возможные

нюансы, невнимание к которым на этапе разработки приложения способно

значительно снизить впоследствии потребительскую ценность приложения.

–

254

–

Практика показывает, что изначальная постановка задачи со стороны

пользователя характеризуется отсутствием большого объема сведений,

необходимых для последующей разработки приложений. При этом, зачастую,

пользователь считает, что отсутствующие сведения априори должны быть

известны программисту. Поэтому, во многих случаях постановка задачи (как

этап разработки приложения) превращается в итерационную процедуру

взаимодействия пользователя и программиста. Недопонимание

между

пользователем и программистом на этапе постановки задачи может повлечь за

собой серьезные последствия, связанные со значительной переделкой

результатов, получаемых на последующих этапах разработки приложения. Для

своевременного устранения возможного недопонимания необходимо

добиваться корректности и полноты постановки задачи с опорой на

формализованные процедуры, предполагающие формирование однозначно

трактуемых описаний.

Второй этап разработки

приложения связан с экономико-

математическим описанием

задачи и выбором метода ее решения. Для

простых вариантов подлежащих решению экономических задач возможно

вырождение данного этапа, если вид входных данных и результатов их

обработки при наличии алгоритма обработки позволяет программисту

однозначно понять суть его последующих действий при разработке

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

автоматизированных ин6формационных

систем, определение адекватной

модели, описывающей поведение многосвязных динамических процессов,

может оказаться наиболее сложным и трудоемким этапом разработки. При

этом к выполнению проекта приходится подключать квалифицированных

специалистов (группы специалистов) в области математики, системного

проектирования и моделирования, управления и др.

В целом при разработке экономико-математической модели и

определении метода решения задачи часто

используют несколько классов

моделей:

• аналитические (вычислительные);

• матричные (балансовые);

• графические и др.

Грамотный выбор модели и метода решения являются основой

уменьшения трудоемкости решения задачи с обеспечением требуемой

точности результатов обработки. При выборе метода решения из ряда

возможных принимают во внимание ряд факторов:

• возможность обеспечения решения задачи с

заданной точностью при

любых возможных значениях входных данных;

–

255

–

• возможность реализации метода решения задачи с использованием

ранее разработанного программного обеспечения (как типового, так и узко

специализированного);

• время решения задачи;

• стоимость приобретения, при необходимости, программных средств.

Результатом завершения работ по данному этапу разработки приложения

является получение формализованного описания задачи, содержащего логико-

математические зависимости, связывающие результаты обработки с входными

данными.

Третий этап технологического процесса создания приложения связан с

разработкой

алгоритма решения задачи. Алгоритм решения задачи отражает

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

условия, соотношения для контроля правильности полученных результатов.

Алгоритм должен учитывать все возможные ситуации, которые могут

возникнуть при решении задачи.

Следует отметить, что очевидность алгоритма (отсутствие других

вариантов) характерна только для элементарных задач. В подавляющем

большинстве случаев (даже и для

простых задач), как правило, существует

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

сложности и, соответственно, различными объемами выполняемых

вычислительных и логических операций, точностью получения результатов и

другими свойствами. Программная реализация различных алгоритмов решения

одной и той же задачи отличается временем решения задачи и, зачастую,

предполагает использование различных объемов памяти.

В практике

решения задач в сфере экономической деятельности,

предполагающих получение многовариантных решений (при различных

значениях входных данных и влияющих условий) широкое применение находят

таблицы решений. В общем случае они выглядят как электронные таблицы; при

этом совокупность строк и столбцов позволяет задать (определить) все

множество значений различных комбинаций реквизитов (результатов их

обработки, условий,

ограничений и др.), для каждого из которых в отдельной

ячейке (т.е. для определенных значений данных и ограничений) отображается

выходной результат. Эффективной основой построения таблиц решений

являются электронные таблицы.

Этап программирования связан с непосредственным формированием

исполняемой программы (приложения); он заключается в преобразовании

алгоритма решения задачи в конкретную последовательность машинных

команд. Характерной особенностью этого этапа является стремление

разработчика (программиста) к максимальной автоматизации процесса

генерации программного кода. При этом, как правило, используются системы

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

–

256

–

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

библиотек с готовыми решениями, средства оптимизации сгенерированного

кода программы и др. Наибольшую эффективность процессу

программирования (с позиции сокращения времени на разработку и создания

дружественного пользовательского интерфейса) обеспечивает применение

систем программирования, ориентированных на реализацию визуального

программирования. При использовании визуального программирования

подавляющая часть

обеспечивающего реализацию пользовательского

интерфейса (окна, кнопки и др.) машинного кода генерируется автоматически,

а на разработчика возлагается функция компоновки схемы интерфейса (выбор

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

места их расположения и др.) и написание на языке высокого уровня

небольшого количества операторов, выполняющих непосредственную

обработку данных при активизации тех

или иных событий.

Следует отметить, что в зависимости от сложности и характера решаемой

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

использовать инструментальные средства, встроенные в пакеты прикладных

программ и, в первую очередь, в электронные таблицы (непосредственный ввод

формул, формирование макросов и др.) и системы управления базами данных

(язык структурированных запросов SQL,

различного рода конструкторы и

мастера и др.).

Непосредственно с этапом программирования связан

этап отладки и

тестирования

. Под отладкой понимается совокупность действий,

ориентированных на обнаружение и устранение ошибок, возникающей в

процессе разработки программы. В целом программирование и отладка

составляет единое целое, поскольку они являются двумя составляющими

итерационной (многократно повторяющейся) процедуры внесения

дополнительной совокупности операторов на языке высокого уровня и

проверки их работоспособности. Все современные подходы программирования

предполагают разделение общей

задачи на множество относительно

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

из которых осуществляется посредством самостоятельных итерационных

процессов программирования и отладки. После завершения отладки отдельных

модулей программы осуществляется отладка программы в целом,

предполагающая достижение согласованного, взаимосвязанного

функционирования входящих в ее состав модулей.

После получения работающей версии программы, позволяющей решать

поставленную задачу

, осуществляется процесс ее тестирования,

представляющий собой последовательность действий, ориентированных на

проверку правильности работы программы во всем допустимом диапазоне

изменения входных данных, а при наличии в ней операций взаимодействия с

–

257

–

внешней средой (прием и передача данных и др.) и корректность выполнения

этих операций. При этом возникновение нештатных ситуаций (некорректные

данные, их отсутствие и др.) не должно нарушать работоспособность

программы и, напротив, должно вызывать формирование на экране дисплея

соответствующих сообщений, помогающих пользователю в определении его

последующих действий. Тестирование выполняется на большом количестве

примеров, обеспечивающих выполнение всех возможных направлений

развития процесса обработки данных при решении задачи.

На практике тестирование дополняет итерационную последовательность

фаз программирование–отладка, поскольку обнаружение факторов

неправильной работы программы сопровождается внесением необходимых

изменений в программу. С учетом высокой трудоемкости тестирования (до

десятков процентов от общего объема трудозатрат на разработку) широко

применяют

специализированные программные средства тестирования,

например, генераторы тестовых данных. Однако, даже у известных фирм,

связанных с разработкой широко используемых в мировой практике

приложений, в процессе эксплуатации этих приложений обнаруживается

существенные изъяны (например, “бреши” в системе защиты ресурсов),

снижающие доверие к производителю.

Завершение разработки приложения сопровождается формированием

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

инструктивные материалы для работы с приложением. Как правило, в состав

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

пользователя при эксплуатации приложения, определяющие возможности и

конкретные действия по внесению изменений и дополнений и др. Передача

разработанного программного обеспечения в эксплуатацию сопровождается

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

соответствии с ранее

сформулированными требованиями как заказчиком

(пользователем), так и разработчиком. Как правило, начальный этап

эксплуатации (экспериментальная эксплуатация) предполагает наблюдение за

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

быстрым устранением выявляемых недоработок. После устранения всех

выявленных в процессе экспериментальной эксплуатации недоработок

программное средство передается в промышленную эксплуатацию.

Описанные в разделе этапы в

целом характеризуют жизненный цикл

программного обеспечения, обычно включающий в себя:

• формирование требований к программному обеспечению;

• проектирование;

• реализацию;

• тестирование;

• ввод в действие;

–

258

–

• эксплуатацию и сопровождение;

• снятие с эксплуатации.

Они характерны как для небольших приложений, создаваемых одним

разработчиком в течение нескольких дней, так и для проектов значительной

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

программистов в течение многих месяцев, а может быть и нескольких лет (при

создании крупных систем автоматизации, разработки операционных систем

др.). Разработка сложных, трудоемких проектов предполагает использование

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

системного проектирования программных средств.

При проектировании современных экономических информационных

систем основная доля трудозатрат приходится на разработку прикладного

программного обеспечения и баз данных. Еще в 70-х годах в США возник

кризис программирования, проявившийся в том, что большие проекты

стали

выполняться со значительным отставанием от запланированных сроков

разработки и/или с заметным превышением сметы расходов. Во многих случаях

не удавалось обеспечить требуемые функциональные возможности и уровень

производительности при эксплуатации программного продукта.

В целом причинами возможных неудач являются: неполное

формулирование требований к разрабатываемому программному продукту, а,

зачастую, и изменение требований и

спецификаций непосредственно по ходу

разработки; недостаточный объем задействованных при разработке ресурсов

(финансовых, людских и др.); неудовлетворительное планирование и

недостаточная компетентность управления проектом; слабая поддержка со

стороны высшего руководства и др. Особенно следует отметить влияние

временного фактора, практически всегда приводящего к возникновению

экстремальных условий выполнения проекта в рамках конкуренции с другими

производителями программных продуктов.

Необходимость контроля процесса создания программного обеспечения,

гарантированной оценки стоимости разработки и сроков ее выполнения,

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

объективную потребность перехода к индустриальным способам создания ПО.

Соответствующее направление создания ПО получило название программная

инженерия (software engineering). В процессе его становления и развития явно

выделяются два этапа: период 70-80-х

годов, когда систематизация и

стандартизация процессов создания ПО осуществлялась на основе

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

сборочному способу создания ПО на основе объектно-ориентированного, а

затем и визуально-ориентированного подходов. Основой реализации второго

этапа явилось резкое увеличение производительности средств вычислительной

техники и массовое распространение компьютерных

сетей.

–

259

–

Для современных крупных проектов в области экономических

информационных систем, как правило, характерны следующие особенности:

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

элементов данных и взаимосвязей между ними;

• взаимодействие значительного числа входящих в состав системы

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

• необходимость интеграции с ранее разработанными и используемыми

приложениями;

• отсутствие полных аналогов, что даже в простейших случаях

предполагает “привязку” типового решения к реальным условиям;

• необходимость совмещения в системе регламентных (периодически

решаемых) и не регламентных (разовые запросы произвольной формы) задач;

• функционирование разрабатываемого программного обеспечения в

среде с разнотипными средствами вычислительной техники;

• длительный период проектирования и

внедрения результатов в связи

со сложностью задач и различной степенью готовности отдельных структурных

подразделений организации-заказчика к внедрению и др.

Успешная реализация проекта изначально предполагает разработку

полных и непротиворечивых моделей

архитектуры ПО, отражающих

совокупность взаимосвязанных структурных элементов системы, а также

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

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

архитектуры системы.

Адекватные модели служат основой взаимодействия всех участников

проекта и в значительной степени гарантируют корректность архитектуры.

Важная роль в процессе реализации проекта отводится языку моделирования,

который содержит в

своем составе элементы модели - базовые концепции

моделирования и их семантику, нотацию - визуальное представление элементов

моделирования, руководство по использованию – правила применения

элементов в рамках построения тех или иных типов моделей программного

обеспечения. Нотация представляет собой совокупность графических объектов,

которые используются в моделях; она является синтаксисом языка

моделирования. Большинство существующих методов объектно-

ориентированного анализа и проектирования включает в себя как язык

моделирования, так и описания процесса моделирования. Язык моделирования

– это нотация (в основном графическая), которая используется методом для

описания проектов. Необходимо отметить, что в отличие от широко

трактуемого понимания сущности моделирования, конечной целью разработки

ПО является создание эффективно работающих приложений (написание

совокупности

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

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

–

260

–

описывающих различные аспекты архитектуры ПО (как статическую

структуру, так и динамику поведения системы).

Наглядность и формализм структурного и объектно-ориентированного

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

возможности разработчикам и заказчикам (будущим пользователям системы)

взаимодействия при анализе возможных технических решений

непосредственно с момента начала проектирования. Реализация таких

подходов требовала соответствующих программно

-технологических средств,

позволяющих, в отличие от традиционной (ручной) разработки ПО,

значительно снизить вероятность появления ошибок в проектных решениях и

просчетов при тестировании разработанной системы, повысить качество

документации, сократить сроки проектирования и др.

Результатом поиска в области создания программно-технологических

средств для разработки сложных экономических информационных систем

явилось создание CASE-средств, охватывающих

весь комплекс задач по

созданию и сопровождению программного обеспечения для таких систем. В

целом CASE-технология представляет собой совокупность методов

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

форме моделировать предметную область, анализировать эту модель на всех

этапах разработки и сопровождения ЭИС и разрабатывать приложения в

соответствии с запросами пользователей.

Одним из

базовых понятий программной инженерии является понятие

жизненного цикла программного обеспечения, определяемого как период

времени, начинающийся с момента принятия решения о необходимости

создания ПО и заканчивающийся в момент его полного изъятия из

эксплуатации. Состав процессов, формирующих жизненный цикл ПО,

регламентируется международным стандартом ISO/IEC 12207:1995 “Information

Technology – Software Life Cycle Processes” (ISO – International Organization for

Standardization – Международная организация по стандартизации, IEC –

International Electrotechnical Commission – Международная комиссия по

электротехнике). Стандарт определяет структуру жизненного цикла,

содержащую процессы,

действия и задачи, которые должны быть выполнены

во время создания ПО. Понятие

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

набор компьютерных программ, процедур и, возможно, связанной с ним

документации и данных. Положения стандарта являются общими для любых

моделей жизненного цикла, методов и технологий разработки ПО, однако они

не конкретизируют особенности реализации процессов.

В состав жизненного цикла ПО обычно включают следующие этапы:

• формирование требований к

программному обеспечению;

• проектирование и тестирование;

• ввод в действие;