4 курс (заочка) / Учебное пособие / Tekhnologii_programmirovania

- 13 -

преобразования информации. На каждом из этих этапов возможно появление ошибки из-за неправильного понимания исходного представления. Возникнув на одном из этапов проектирования либо разработки, ошибка преобразуется в новые ошибки и попадает в ПС.

2.2. Механизм перевода

Рассмотрим механизм [6], которой моделирует процесс перевода человеком информации из представления А в представление В (рис. 2).

Рис. 2. Механизм перевода

Механизм перевода осуществляется за 4 этапа:

–человек получает информацию, содержащуюся в представлении А с помощью своего читающего механизма R;

–запоминает полученную информацию в памяти M;

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

ипосылает результат пишущему механизму W;

–с помощью механизма W человек фиксирует новое представление информации в виде B.

На каждом из этих этапов или шагов человек может совершить ошибку.

На первом шаге с человеком может сыграть злую шутку его способность «читать между строк». Человек восстанавливает недостающую информацию в виде того, что он ожидает, а не в том виде, в котором её представлял автор документа А.

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

- 14 -

знание предметной области. Если человек поверхностно поймёт и запомнит информацию, то она будет искажена.

На третьем шаге забывчивость может привести к тому, что человек выберет из своей памяти не всю или не преобразованную информацию, не все или не те правила преобразования. В результате перевод будет осуществлён неверно. Эти ошибки происходят при большом объёме плохо структурированной информации.

На четвёртом шаге стремление человека быстрее зафиксировать результат приводит к тому, что представление информации оказывается неточным и создаётся ситуация для неправильной интерпретации в дальнейшем.

Основные пути борьбы с ошибками:

–сужение пространства перебора путём упрощения создаваемых систем;

–создание и поддержание требуемого уровня подготовки разработчиков;

–поддержание однозначности интерпретации представления информации;

–контроль правильности перевода информации.

3. Основные подходы к разработке ПС

Разработка ПС имеет ряд специфических особенностей [1]:

1.Разработка носит творческий характер. На каждом этапе нужно принимать обдуманные решения, производить какой-либо выбор, а не руководствоваться ка- кой-либо последовательностью механических действий. То есть разработка ПС близка разработке или проектированию сложных устройств. Творческий характер присутствует на всех этапах разработки ПС.

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

3.Продукт разработки (или ПС) при своём использовании не расходуется и не расходует используемых ресурсов.

-15 -

3.1.Жизненный цикл ПС

Втехнологиях программирования под жизненным циклом ПС понимают

весь период его разработки и эксплуатации, который начинается от момента возникновения замысла ПС и кончается с прекращением всех видов его исполь-

зования [2, 3, 7]. Жизненный цикл – это сложный процесс и он организован поразному для различных ПС и на него влияет специфика коллектива разработчиков. В настоящее время выделяют пять основных подходов к организации создания и использования ПС [1].

1.Водопадный подход. При таком подходе разработка ПС состоит из цепочки этапов. На каждом этапе этого подхода разрабатываются документы, которые используются на последующих этапах. В исходном документе – требования к ПС, в конце цепочки – программы, из которых состоит ПС.

2.Исследовательское программирование. Второй подход предполагает как можно быстрое создание либо реализацию рабочих версий ПС. После экспериментального применения разработанных программ проводится их модификация. Этот процесс итеративно повторяется. Такой подход был характерен для начальных этапов развития программирования и ВТ. В настоящее время такой подход применяется для разработки ПС, пользователи или заказчики которых не могут чётко сформулировать свои требования.

3.Прототипирование. Этот подход моделирует фазу исследовательского программирования вплоть до создания рабочих версий ПС. Эти рабочие версии используются для экспериментов с ними и для определения требований к ПС. В дальнейшем идёт разработка ПС по выработанным требованиям в рамках какоголибо другого подхода.

4.Формальные преобразования. Заключаются в разработке формальных спецификаций (либо требований) к ПС и дальнейшему превращению их в программы путём корректных преобразований. На этом подходе базируется компьютерная технология разработки ПС или CASE-технология [8].

5.Сборочное программирование предполагает, что ПС конструируется на основе уже имеющихся модулей. Предполагается некоторое хранилище (библиотека)

- 16 -

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

В рамках водопадного подхода выделяют стадии жизненного цикла (рис. 3):

1)разработка ПС;

2)производство программных изделий;

3)эксплуатация ПС.

Этап конструирования

Рис. 3. Стадии жизненного цикла при водопадном подходе

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

Этап внешнего описания включает в себя процессы, приводящие к созданию документа под названием «Внешнее описание». Документ описывает поведение ПС с точки зрения пользователя ПС или заказчика и также в нём фиксируются требования к качеству ПС.

Этап конструирования ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.

Этап кодирования ПС – это процесс создания текстов программ на языке программирования, их отладка и тестирование.

Этап аттестации. На нём проводится оценка качества созданного ПС. Если качество удовлетворяет пользователя, процесс разработки на этом заканчивается и заключается контракт (договор).

- 17 -

Программное изделие (ПИ) – это копия либо экземпляр разработанного ПС.

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

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

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

3.2. Понятие качества ПС

Каждое ПС должно выполнять те функции, которые задуманы разработчиками.

Качество ПС – набор или совокупность черт и характеристик, которые удовлетворяют заданным потребностям пользователя [1]. Повышение качества ПС по одному из таких свойств часто может быть достигнуто увеличением стоимости. Совокупность черт программного средства, образуемых требуемое качество, зависит от условий и характера эксплуатации ПС.

Критерии качества, связанные логически, образуют метрики или системы измерений. В ТП сложилось несколько метрик для оценки качества созданного программного обеспечения. Метрика Боэма основана на статистической обработке экспертных оценок 51 качественной характеристики: полнота функций, независимость от устройств, эффективность использования устройств и т.п. Метрика качества Джилба опирается на шкалу оценок надёжности, удобства сопровождения, адаптивности, универсальности, сложности, ясности и т.п. Метрика качества Холстеда выведена эмпирически на базе аналитических выражений для количественной оценки ПМ на основе оценок количества операций и операндов, числа вхождений наиболее часто встречающихся операций и операндов и т.д.

- 18 -

Однако в настоящее время в состав метрики принято включать следующие

критерии качества ПС [5, 6]:

1)функциональность;

2)надёжность;

3)лёгкость хранения;

4)эффективность;

5)сопровождаемость;

6)мобильность.

Функциональность – способность ПС выполнять заданный набор функций. Набор указанных функций определяется во внешнем описании ПС.

Надёжность подробно обсуждалась выше.

Лёгкость применения – это свойство ПС, позволяющее минимизировать либо уменьшить усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов.

Эффективность – отношения уровня услуг, предоставляемых ПС пользователю, к объёму использованных ресурсов.

Сопровождаемость – это свойство ПС, позволяющее уменьшить либо минимизировать усилия по внесению изменений или по модификации ПС для устранения в нём ошибок и его модификации.

Мобильность – способность ПС быть перенесённым из одной аппаратнооперационной среды (окружения) в другую, например, с одной ЭВМ на другую.

Функциональность и надёжность являются обязательными критериями качества ПС. Остальные критерии используются в зависимости от потребностей пользователя.

3.3.Обеспечение надёжности ПС – основная цель разработки

Втехнике известны четыре подхода к обеспечению надёжности [6]:

1)предупреждение ошибок;

2)самообнаружение ошибок;

3)самоисправление ошибок;

4)обеспечение устойчивости к ошибкам.

- 19 -

Цель первого подхода – не допустить ошибок в готовых продуктах или ПС. Для достижения этой цели обращают внимание на следующие моменты:

–борьба со сложностью;

–обеспечение точности перевода;

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

–обеспечение контроля принимаемых решений.

Самообнаружение ошибок в программе предполагает, что программа содержит некие средства обнаружения отказа при своём выполнении.

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

При разработке ПС нельзя напрямую использовать те средства, которые используются при разработке технических средств. Например, дублирование отдельных блоков и устройств. Выполнение двух копий одной и той же программы будет приводить к одному результату (правильному или наоборот). Кроме того, добавление в ПС дополнительных модулей приводит к его усложнению и в определённой степени мешает предупреждению ошибок.

Методы борьбы со сложностью

Есть два основных подхода:

–обеспечение независимости компонент системы;

–использование в системах иерархических структур.

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

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

Обеспечение точности перевода

Направлено на однозначную интерпретацию различных документов, а достигается это выполнением некоторых простых правил [1]:

1)понять задачу;

2)составить план;

- 20 -

3)выполнить план;

4)проанализировать полученные решения.

Преодоление барьера между пользователем и разработчиком

Может быть упрощено при выполнении следующих простых правил:

1)правильно понять чего хочет пользователь;

2)понять обстановку, в которой пользователь обитает и уровень его подготовки;

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

Контроль принимаемых решений

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

–смежный контроль;

–сочетание статических и динамических методов контроля.

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

Сочетание статических и динамических методов означает, что контролируется не только документ как таковой, но и процесс обработки данных, которые он описывает. Тем самым такой контроль учитывает двойственный характер ПС –

статическая форма и динамическое содержание.

4. Определение внешнего описания ПС

Разработка ПС начинается с процесса формирования требований к ПС. Исходя из довольно смутных представлений и пожеланий заказчика, должен получиться документ, достаточно точно определяющий задачи разработчика ПС. Этот документ и называют внешним описанием ПС (ВО ПС) [1]. Внешнее описание играет роль точной постановки задачи. Решение этой задачи должно представить разрабатываемое ПС. Кроме того, ВО ПС должно содержать информацию, необходимую

- 21 -

пользователю по применению ПС. Внешнее описание является стартовой информацией для трёх параллельно протекающих процессов:

1)разработка текстов программ, входящих в ПС (этап конструирования и кодирования);

2)разработка документации по применению;

3)разработка комплекта тестов для тестирования ПС.

Ошибки ВО ПС преобразуются в ошибки самого ПС и очень тяжелы по своим последствиям.

Исходным документом для разработки ВО ПС являются требования к ПС. Формирование требований – это длительный и трудный процесс, причём ите-

рационный, между пользователем и разработчиком. Трудности этого процесса проистекают по причине того, что пользователи не всегда чётко представляют себе назначение ПС. В связи с этим появляется необходимость того, чтобы при предъявлении требований к ПС провести системный анализ с целью выявления целесообразности создаваемого средства и принципиальной реализуемости данного ПС

[5].

Для выявления действительных потребностей пользователя создаётся (иногда) упрощённый вариант ПС или прототип.

Применение прототипа позволяет иногда существенно уточнить требования к ПС. Внешнее описание состоит из двух разделов:

1)описание поведения ПС определяет функции, которые оно должно выполнять, и поэтому такую часть называют функциональной спецификацией;

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

Структуру ВО ПС можно представить формулой [1]:

ВО ПС = Требования к ПС + Спецификация качества + Функциональная спецификация

- 22 -

Таким образом, ВО ПС определяет, что должно делать ПС и какими внешними свойствами обладать. При этом не рассматривается вопрос, как должно быть устроено ПС.

Результатом работы пользователя и разработчика должно быть принятие внешнего описания и заключение договора на разработку ПС.

4.1. Формирование требований к ПС

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

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

Известны три способа разработки требований к ПС [6]:

1)управляемая пользователем разработка;

2)контролируемая пользователем разработка;

3)независимая от пользователя разработка.

Первый способ предусматривает, что требования к ПС определяются заказчиком. Разработчик, в основном, уточняет неясные моменты с пользователем. В результате документ может быть в нескольких редакциях.

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

При независимой от пользователя разработке требования определяются без ка- кого-либо участия пользователя. Такой способ характерен для случаев создания ПС широкого применения.

Сточки зрения обеспечения надёжности ПС предпочтителен второй способ.

4.2.Формирование спецификации качества ПС (СК)

Разработка СК является, по существу, созданием моделей качества требуемого

ПС [1]. В этой модели должен быть перечень всех элементарных свойств, которые нужно обеспечить в создаваемом ПС. Объединение этих элементарных свойств в