1.ИСПОЛЬЗОВАНИЕ АБСТРАКЦИЙ И СПЕЦИФИКАЦИЙ В РАЗРАБОТКЕ ПО

                    1.1.Абстракции программы

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

ции задачи. Эта декомпозиция основана на опознавании абстракций.

    Базовая парадигма в подходе к любой большой задаче ясна: необходи-

мо "разделять и властвовать". Абстракция представляет собой  эффектив-

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

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

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

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

цесса создания программ: декомпозиция используется для разбиения прог-

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

шить основную задачу; абстрагирование же предполагает продуманный  вы-

бор компонент.

    В общем случае, любую программу можно представить набором  следую-

щих процедурных абстракций. Причем процедура преобразования может  но-

сить как единичный характер, так и итеративный.

┌────────────────────────────────────────────────────────────────────┐

│                                                                    │

│┌────────────┐          ┌────────────────┐            ┌────────────┐│

││    Ввод    │ исходная │ Преобразование │преобразов. │   Вывод    ││

││            │═════════│                │═══════════│            ││

││ информации │информация│   информации   │информация  │ информации ││

│└────────────┘          └────────────────┘            └────────────┘│

│                                                             ║      │

│                                                 Выходная    ║      │

│                                              ══════════════╝      │

│                                                 информация         │

└────────────────────────────────────────────────────────────────────┘

  Рис.1.1.Абстракция программы  как  набора  процедур,  обрабатывающих

          данные.

    Анализируя рис.1.1, можно получить обобщенную абстракцию  процеду-

ры в следующем виде.

┌────────────────────────────────────────────────────────────────────┐

│                  Управляющая                                       │

│                ════════════════════╗                               │

│                  информация        ║                               │

│                                    ║                               │

│                                    ­                               │

│                              ┌───────────┐                         │

│          Входная             │           │   Выходная              │

│         ════════════════════│ Процедура │════════════════════    │

│          информация          │           │   информация            │

│                              └───────────┘                         │

│                                                                    │

└────────────────────────────────────────────────────────────────────┘

                   Рис.1.2.Абстракция процедуры

    Рассматривая программу не как набор процедур, а прежде  всего  как

некоторые наборы данных, каждый из которых  имеет  разрешенную  группу

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

┌────────────────────────────────────────────────────────────────────┐

│           Ввод                                                     │

│      ╔═══════════════                                              │

│      ║ информации                                                  │

│      ­                                                             │

│┌────────────┐                                        ┌────────────┐│

││  Исходная  │ Преобразование                         │  Выходная  ││

││            │══════════════════╗                ╔═══│            ││

││ информация │   информации     ║                ║    │ информация ││

│└────────────┘                  ║                ║    └────────────┘│

│                   ╔════════════╝                ║                  │

│                   ║                             ╚═════╗            │

│                   ║   ┌─────────────────┐             ║            │

│                   ║   │ Преобразованная │   Вывод     ║            │

│                   ╚══│                 │═════════════╝            │

│                       │   информация    │ информации               │

│                       └─────────────────┘                          │

│                                                                    │

└────────────────────────────────────────────────────────────────────┘

 Рис.1.3.Абстракция  программы  как  набора   данных,   обрабатываемых

         процедурами.

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

┌────────────────────────────────────────────────────────────────────┐

│               Процедуры                                            │

│              ═════════════════╗                                    │

│               управления      ║                                    │

│                               ­                                    │

│                          ┌──────────┐                              │

│          Процедуры       │          │     Процедуры                │

│         ════════════════│  Данные  │═══════════════              │

│          ввода           │          │     вывода                   │

│                          └──────────┘                              │

│                               ‑                                    │

│               Процедуры       ║                                    │

│              ═════════════════╝                                    │

│               преобразования                                       │

└────────────────────────────────────────────────────────────────────┘

                    Рис.1.4.Абстракция данных.

    Полученные абстракции процедуры и данных  лежат  в  основе  многих

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

ния. Условно эти методы можно разделить на формульные и графические.

    Наиболее широко используются абстракции процедур,  которыми  любой

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

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

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

рез параметризацию и абстракцию через спецификацию.

    Абстракция через параметризацию  позволяет,  используя  параметры,

представить фактически неограниченный набор различных  вычислений  од-

ной прграммой, которая есть абстракция всех  этих  наборов.  Например,

необходима прцедура сортировки массива целых чисел А.  При  дальнейшей

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

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

рез параметризацию обобщает процедуру сортировки  и  делает  ее  более

универсальной.

    Абстракция через параметризацию является важным средством  повыше-

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

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

вом чисел.  Дальнейшее  абстрагирование  позволяет  добиться  большего

обобщения процедуры. Например, можно определить абстракцию такой  про-

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

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

структурами.

    Абстракция через спецификацию позволяет абстрагироваться  от  про-

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

го, что что данная прцедура должна в итоге реализовать. Это достигает-

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

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

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

ры. В какой-то степени достаточно информативный  комментарий,  связан-

ный с процедурой, позволяет работать с ней без анализа тела  прцедуры.

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

пользование пар утверждений. Первое  утверждение  (начальное  условие)

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

связанного с входной информацией. Второе утверждение  (конечное  усло-

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

вершению данной процедуры в предположении, что для этой процедуры  бы-

ло удовлетворено начальное условие.

    При анализе спецификации для уяснения смысла обращения к  процеду-

ре следует придерживаться двух правил.

    1.После выполнения процедуры можно считать, что  конечное  условие

выполнено.

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

вает конечное условие.

    Эти два правила демонстрируют  два  преимущества,  предоставляемых

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

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

лом. Второе правило уточняет абстрагирование от тела  процедуры  путем

отказа от несущественной информации. Такое "забывание информации"  от-

личает абстракцию от декомпозиции.

    Абстракции через параметризацию и через спецификацию позволяют оп-

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

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

процедурная абстракция, абстракция через  данные  и  абстракция  через

итерацию используют оба способа.

    Процедурная абстракция позволяет расширить заданную некоторым язы-

ком программирования виртуальную машину  новой  операцией.  Такой  вид

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

виде набора независимых функциональных единиц. Однако часто оказывает-

ся более удобным добавить к виртуальной машине несколько объектов дан-

ных с новыми типами.

    Поведение объектов данных наиболее естественно представить в  тер-

минах набора операций, применимых к данным объектам. Такой набор вклю-

чает в себя операции по созданию объектов,  полученнию  информации  от

них и, возможно, их модификации. Таким образом, абстракция данных  (и-

ли тип данных) состоит из набора объектов.

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

дует рассмотреть абстракцию через итерацию. Абстракция через  итерацию

дает возможность не рассматривать информацию, не имеющую прямого отно-

шения к управляющему потоку или циклу.  Типичная  абстракция  итерации

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

ких-либо ограничений на последовательность обработки.

                  1.2.Процедурная абстракция

    Процедуры объединяют в себе методы абстракции  через  параметриза-

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

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

выходные. Более точно, это есть отображение  набора  значений  входных

аргументов в выходной набор результатов с возможной модификацией вход-

ных значений.

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

абстрагирования от "несущественных" подробностей и отношения к  решае-

мой задаче.

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

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

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

параметрами в момент использования  такой  абстракции.  Параметризация

позволяет обобщить модули, уменьшить объем программы и объем модифика-

ций.

    В абстракции через спецификацию фокусируется внимание  на  особен-

ностях, от которых зависит пользователь абстракции, при  абстрагирова-

нии от подробностей реализации этих особенностей.  Главное  преимущес-

тво абстракции через спецификацию заключается в несущественности  спо-

соба реализации.

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

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

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

жет быть создана или рассмотрена без необходимости анализа  реализации

какой-либо другой абстракции. Второй особенностью  является  модифици-

руемость. Если реализация абстракции изменяется,  но  ее  спецификация

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

часть программы.

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

деления абстракций. Абстракция будет определяться посредством специфи-

каций с использованием языка спецификаций.

    Спецификация процедуры состоит из заголовка  и  описания  функции,

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

док и типы входных и выходных параметров. Кроме этого, выходные  пара-

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

    Семантическая часть спецификации состоит  из  трех  предложений  -

requires (требует), modifies (модифицирует) и  effects  (делает).  Эти

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

жения requires и modifies обязательными не являются.

 ┌──────────────────────────────────────────────────────────────────┐

 │ pname = proc(входные данные) returns (выходные данные)           │

 │      requires  - этот оператор задает необходимые требования     │

 │      modifies  - этот оператор идентифицирует все модифицируемые │

 │                  входные данные                                  │

 │      effects   - этот оператор описывает выполняемые функции     │

 └──────────────────────────────────────────────────────────────────┘

        Рис.1.5.Шаблон спецификации для процедурных абстракций.

    Предложение requires задает ограничения, накладываемые на абстрак-

цию. Предложение requires необходимо в том случае, если процедура  яв-

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

чений недетерминировано. Если же процедура глобальна, то есть ее пове-

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

может быть опущено. В этом случае единственными требованиями, предъяв-

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

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

    Оператор modifies задает список имен входных параметров, модифици-

руемых процедурой. Если входные параметры не указаны, то это предложе-

ние может быть опущено.

    Предложение effects описывает работу процедуры со  значениями,  не

охваченными предложением requires. Оно определяет выходные значения  и

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

списке modifies. Предложение effects составляется исходя из  предполо-

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

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

поведении процедуры ничего не сообщается.

    На рис.1.6 приведено несколько процедурных спецификаций.  Процеду-

ры sort и search не изменяют входные данные, а процедура clear - изме-

няет, что отмечено в предложении modifies ее  спецификации.  Процедуры

sort и clear являются общими процедурами, поскольку их спецификации не

содержат предложений requires. Процедура  search  является  частичной;

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

отсортирован. Однако в предложении effects ничего не говорится  о  ре-

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

    Приведенная на рис.1.6 спецификация процедуры  sort  предназначена

для работы с массивом целых чисел. Эта процедура была бы более  полез-

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

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

лем. Для обеспечения подобного обобщения используется  абстракция  че-

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

 ┌──────────────────────────────────────────────────────────────────┐

 │ sort  = proc(a:array of int) returns (b:array of int)            │

 │      effects   - возвращает новый массив той же размерности,     │

 │                  что и a, содержащий элементы из массива a, упоря│

 │                  доченные по возрастанию                         │

 └──────────────────────────────────────────────────────────────────┘

 ┌──────────────────────────────────────────────────────────────────┐

 │ clear = proc(a:array of int)                                     │

 │      modifies  - a                                               │

 │      effects   - удаляет из массива a все повторяющиеся элементы │

 └──────────────────────────────────────────────────────────────────┘

 ┌──────────────────────────────────────────────────────────────────┐

 │ search= proc(a:array of int;x:int) returns (i:int)               │

 │      requires  - массив a упорядочен по возрастанию              │

 │      effects   - если элемент x принадлежит массиву a, то возвра-│

 │                  щается значение i, такое, что a[i]=x; в против- │

 │                  ном случае - значение i на единицу большее верх-│

 │                  ней границы массива a                           │

 └──────────────────────────────────────────────────────────────────┘

          Рис.1.6.Спецификации процедурных абстракций.

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

параметров могут не иметь смысла. Например, массивы могут быть  отсор-

тированы только в том случае, когда элементы, принадлежащие типу, упо-

рядочены. Ограничения на параметры типа предполагают  набор  некоторых

заданных операций над ними. Спецификация абстракции  должна  содержать

эти ограничения в предложении requires.

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

рис.1.7. Эти спецификации отличаются от спецификаций непараметризован-

 ┌──────────────────────────────────────────────────────────────────┐

 │ sort  = proc[t:type](a:array [t]) returns (array [t])            │

 │      requires  - t имеет операцию                                │

 │                    lt:proctype(t,t) returns(bool),               │

 │                  которая упорядочивает t                         │

 │      modifies  - a                                               │

 │      effects   - возвращает новый массив той же размерности,     │

 │                  что и a, содержащий элементы из массива a, упоря│

 │                  доченные по возрастанию                         │

 └──────────────────────────────────────────────────────────────────┘

 ┌──────────────────────────────────────────────────────────────────┐

 │ search= proc[t:type](a:array [t];x:t) returns (int)              │

 │      requires  - t имеет операции                                │

 │                    equal,lt:proctype(t,t) returns (bool),        │

 │                  такие, что t упорядочивается через equal, а     │

 │                  массив a упорядочен по возрастанию через lt     │

 │      effects   - если элемент x принадлежит массиву a, то возвра-│

 │                  щается значение i, такое, что a[i]=x; в против- │

 │                  ном случае - значение i на единицу большее верх-│

 │                  ней границы массива a                           │

 └──────────────────────────────────────────────────────────────────┘

          Рис.1.7.Спецификации параметризованных процедур.

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

содержащую параметры. Предложение requires помимо  прочих  ограничений

содержит ограничения, накладываемые на параметры. Если ограничения от-

сутствуют, то предложение requires может быть опущено.  Например,  аб-

стракция sort требует, чтобы параметр t имел операцию  lt,  упорядочи-

вающую t. Аналогично процедура search требует, чтобы ее параметр  под-

держивал как операцию lt, так и операцию equal. (lt - меньше, equal  -

равно).

    Параметризованная абстракция в действительности  представляет  со-

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

ции. Спецификация процедуры естественным образом получается из  специ-

фикации класса путем замены имени параметра его значением и  удалением

из предложения requires ограничений на тип параметра(ов).

    При  создании  процедурных  абстракций  желательно  наличие  таких

свойств, как минимальность, простота и обобщенность.

                 1.3.Абстракция типа данных

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

ций. Кроме операций, однако, базовый уровень  предусматривает  различ-

ные типы данных (целые, вещественные, логические, символьные, массивы,

записи и т.д.). Как указывалось выше, необходимо иметь возможность до-

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

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

    Необходимые типы данных зависят от области применения  программно-

го обеспечения. В каждом конкретном случае абстракция  данных  состоит

из набора объектов и набора операций.

    Новые типы данных должны включать в себя абстракции как через  па-

раметризацию, так и через спецификацию. Абстракции через  параметриза-

цию могут быть осуществлены так же, как для процедур.  Абстракции  че-

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

типа. Если рассматривать тип данных просто как набор объектов, то все,

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

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

терминах этого представления. В случае изменения  представления  прог-

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

    При включении операций в тип данных единственным  требованием  бу-

дет следующее: пользователи  (программы)  употребляют  непосредственно

эти операции, не обращаясь к представлению. Операции типа должны  реа-

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

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

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

через спецификацию.

    Если обеспечено достаточное количество операций, отсутствие досту-

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

Обычно должны быть операции по созданию и модификации объектов, а так-

же по получению информации об их значениях.

    Абстракции данных  -  наиболее важный метод в проектировании прог-

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

ния эффективной программы. При отсутствии абстракций данных  структуры

данных должны быть определены до начала реализации  модулей.  Абстрак-

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

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

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

программного обеспечения.  Чаще  предпочтительнее  изменить  структуры

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

няющимся требованиям. Абстрации данных сводят все изменения к  измене-

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

    Также как для процедур, значение типа не должно  задаваться  ника-

кой его реализацией. Вместо этого должна иметься определяющая его спе-

цификация. Так как объекты типа используются только вызовом  операций,

основная часть спецификации посвящена описанию того, что эти  операции

делают. Общий вид спецификации данных состоит из заголовка, определяю-

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

описания и секции операций.

      ┌─────────────────────────────────────────────────────────┐

      │    dname = data type is  список операций                │

      │    Описание                                             │

      │         Здесь приводится описание абстракции данных     │

      │    Операции                                             │

      │         Здесь задаются спецификации для всех операций   │

      │    end dname                                            │

      └─────────────────────────────────────────────────────────┘

              Рис.1.8.Общий вид спецификации абстракции данных.

    В секции описания тип описывается как целое. Иногда там дается мо-

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

объектов - таких, которые по предположению понятны тем, для  кого  эта

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

минах математических последовательностей.  В  секции  описания  должно

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

    В секции операций содержатся спецификации для всех операций.  Если

операция - процедура, то ее спецификация будет процедурной  специфика-

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

секции описания.

    Рассмотрим спецификацию абстракции данных intset. Наборы целых чи-

сел intset - это неограниченные множества  целых  чисел  с  операциями

создания нового, пустого набора, проверки данного целого числа на при-

надлежность данному набору intset и добавления или удаления элементов.

 ┌──────────────────────────────────────────────────────────────────┐

 │intset = data type is create, insert, delete, member, size, choose│

 │                                                                  │

 │Описание                                                          │

 │                                                                  │

 │ Наборы целых чисел intset - это неограниченные математические    │

 │ множества целых чисел. Наборы целых чисел изменяемые: операции   │

 │ insert и delete добавляют и удаляют целые числа из набора.       │

 │                                                                  │

 │Операции                                                          │

 │                                                                  │

 │ create = proc ()  returns (intset)                               │

 │        effects возвращает новый, пустой набор intset             │

 │                                                                  │

 │ insert = proc (s: intset, x:int)                                 │

 │        modifies s                                                │

 │        effects добавляет x к элементам s; после добавления -     │

 │                возврат                                           │

 │                                                                  │

 │ delete = proc (s: intset, x:int)                                 │

 │        modifies s                                                │

 │        effects удаляет x из s                                    │

 │                                                                  │

 │ member = proc (s:intset, x:int) returns (bool)                   │

 │        effects возвращает значение true, если x принадлежит s    │

 │                                                                  │

 │ size = proc (s: intset) returns (int)                            │

 │        effects возвращает число элементов в s                    │

 │                                                                  │

 │ choose = proc (s: intset) returns (int)                          │

 │        requires набор s не пуст                                  │

 │        effects возвращает произвольный элемент s                 │

 │                                                                  │

 │end intset                                                        │

 └──────────────────────────────────────────────────────────────────┘

             Рис.1.9.Спецификация типа данных intset.

    На рис.1.10 представлена спецификация типа данных  poly.  Полиномы

poly - это неизменяемые полиномы с целыми  коэффициентами.  Предостав-

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

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

равенство.

 ┌──────────────────────────────────────────────────────────────────┐

 │poly = data type is create,degree,coef,add,mul,sub,minus,equal    │

 │                                                                  │

 │Описание                                                          │

 │                                                                  │

 │ Полиномы poly - это неизменяемые полиномы с целыми коэффициентами│

 │                                                                  │

 │Операции                                                          │

 │                                                                  │

 │ create = proc (c,n:int)  returns (poly)                          │

 │        requires n>=0                n                            │

 │        effects возвращает полином cx. Например,                  │

 │                    poly.create(0,0) = 0                          │

 │                    poly.create(3,0) = 3 3                        │

 │                    poly.create(6,3) = 6x                         │

 │                                                                  │

 │ degree = proc (p: poly)  returns(int)                            │

 │        effects возвращает степень p, т.е. наибольшую степень при │

 │                ненулевом коэффициенте. Степень нулевого полинома │

 │                равна 0. Например,                    2           │

 │                    poly.degree(17) = 0  poly.degree(x +1) = 2    │

 │                                                                  │

 │ coef   = proc (p: poly, n:int) returns (int)                     │

 │        requires n>=0                                             │

 │        effects возвращает коэффициент члена p со степенью n. Воз-│

 │                вращает 0, если n больше степени p. Например,     │

 │                               3                                  │

 │                    poly.coef(x +2x+1,4) = 0                      │

 │                               3                                  │

 │                    poly.coef(x +2x+1,1) = 2                      │

 │                                                                  │

 │ add    = proc (p,q: poly) returns (poly)                         │

 │        effects возвращает полином, являющийся суммой полиномов p │

 │                и q                                               │

 │                                                                  │

 │ mul    = proc (p,q: poly) returns (poly)                         │

 │        effects возвращает полином, являющийся произведением поли-│

 │                номов p и q                                       │

 │                                                                  │

 │ sub    = proc (p,q: poly) returns (poly)                         │

 │        effects возвращает полином, являющийся разностью полиномов│

 │                p и q                                             │

 │                                                                  │

 │ minus  = proc (p: poly) returns (poly)                           │

 │        effects возвращает полином, являющийся разностью полиномов│

 │                z и p, где z - нулевой полином                    │

 │                                                                  │

 │ equal  = proc (p,q: poly) returns (bool)                         │

 │        effects возвращает значение true, если p и q имеют одинако│

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

 │                чение false - в противном случае                  │

 │                                                                  │

 │end poly                                                          │

 └──────────────────────────────────────────────────────────────────┘

        Рис.1.10.Спецификация абстракции данных для полиномов.

    Типы  -  выгодные параметры для данных, как и для процедур. Напри-

мер, рассмотрим абстракцию общего набора set, в котором элементы набо-

ра могут быть произвольного типа. Конечно,  не  все  типы  могут  быть

имеющими смысл параметрами общего набора. Так как общие наборы set  не

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

ределить, дублируют элементы друг друга или нет. Следовательно, специ-

фикация set, представленная на рис.1.11, требует, чтобы элементы  типа

имели операцию equal. Эти требования помещены сразу после заголовка.

 ┌──────────────────────────────────────────────────────────────────┐

 │ set = data type [t:type] is create, insert, delete, member, size,│

 │                             choose                               │

 │                                                                  │

 │Requires t имеет операцию                                         │

 │            equal:proctype(t,t) returns(bool),                    │

 │         то есть условие проверки равенства t                     │

 │                                                                  │

 │Описание                                                          │

 │                                                                  │

 │ Общие наборы set - это неограниченные математические наборы      │

 │ Эти наборы изменяемые: операции insert и delete добавляют и унич-│

 │ тожают элементы набора                                           │

 │                                                                  │

 │Операции                                                          │

 │                                                                  │

 │ create = proc ()  returns (set [t])                              │

 │        effects возвращает новый, пустой набор set                │

 │                                                                  │

 │ insert = proc (s: set[t], x:t)                                   │

 │        modifies s                                                │

 │        effects добавляет x к элементам s; после добавления -     │

 │                возврат                                           │

 │                                                                  │

 │ delete = proc (s: set[t], x:t)                                   │

 │        modifies s                                                │

 │        effects удаляет x из s                                    │

 │                                                                  │

 │ member = proc (s: set[t], x:t) returns (bool)                    │

 │        effects возвращает значение true, если x принадлежит s    │

 │                                                                  │

 │ size = proc (s: set[t]) returns (int)                            │

 │        effects возвращает число элементов в s                    │

 │                                                                  │

 │ choose = proc (s: set[t]) returns (t)                            │

 │        requires набор s не пуст                                  │

 │        effects возвращает произвольный элемент s                 │

 │                                                                  │

 │end set                                                           │

 └──────────────────────────────────────────────────────────────────┘

        Рис.1.11.Спецификация параметризованной абстракции данных.

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

poly. Например,

                pset = set[poly].

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

имеет операцию equal.

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

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

как целое. Неограниченные списки содержат элементы  некоторого  произ-

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

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

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

остальные элементы.

 ┌──────────────────────────────────────────────────────────────────┐

 │list = data type [t:type] is create,cons,first,rest,empty,equal   │

 │                                                                  │

 │Описание                                                          │

 │                                                                  │

 │ Списки - это неизменяемые неограниченные последовательности      │

 │ элементов типа t                                                 │

 │                                                                  │

 │Операции                                                          │

 │                                                                  │

 │ create = proc ()  returns (list [t])                             │

 │        effects возвращает новый, пустой список                   │

 │                                                                  │

 │ cons   = proc (x: list[t], i:t) returns(list[t])                 │

 │        effects возвращает список, у которого первый элемент i, а │

 │                остальные элементы - элементы x                   │

 │                                                                  │

 │ first  = proc (x: list[t]) returns(t)                            │

 │        requires x - не пуст                                      │

 │        effects возвращает первый элемент x                       │

 │                                                                  │

 │ rest   = proc (x: list[t]) returns (list[t])                     │

 │        requires x - не пуст                                      │

 │        effects возвращает список, содержащий все элементы x, кро-│

 │                ме первого                                        │

 │                                                                  │

 │ empty  = proc (x: list[t]) returns (bool)                        │

 │        effects возвращает значение true, если x - пуст, и значе- │

 │                ние false - в противном случае                    │

 │                                                                  │

 │ equal  = proc (x,y: list[t]) returns (bool)                      │

 │        requires t имеет операцию                                 │

 │                     equl:proctype(t,t) returns(bool),            │

 │                 то есть условие равенства t                      │

 │        effects возвращает значение true, если x и y содержат оди-│

 │                наковые (в соответствии с t.equal) и одинаково рас│

 │                положенные элементы                               │

 │                                                                  │

 │end list                                                          │

 └──────────────────────────────────────────────────────────────────┘

    Рис.1.12.Спецификация параметризованной абстракции данных для

             списков.

    Следует заметить, что списки как целое не налагают никаких  требо-

ваний на тип параметра. Таким образом, list[intset]  -  законный  тип.

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

она в предложении requires налагает на  t  требования.  Следовательно,

list[intset] имеет все операции списков, кроме операции equal, так как

intset не имеет операции equal.

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

которых элементы отсортированы по доступу. Упорядоченные списки -  из-

меняемы и параметризуемы по типу, который должен быть полностью упоря-

дочен его операциями lt и equal. То есть, упорядоченные списки не  со-

держат дублирующих друг друга элементов.

 ┌──────────────────────────────────────────────────────────────────┐

 │olist = data type [t:type] is create,addel,remel,is_in,empty,least│

 │                                                                  │

 │Requires  - t имеет операции                                      │

 │                    equal,lt:proctype(t,t) returns (bool),        │

 │            которые определяют упорядочение t                     │

 │                                                                  │

 │Описание                                                          │

 │                                                                  │

 │Упорядоченные списки olist - изменяемые списки элементов. Операции│

 │addel и remel модифицируют списки. Каждый элемент упорядоченного  │

 │списка отличается от остальных (как определяется t.equal). Опера- │

 │ция least возвращает наименьший элемент olist (как определяется   │

 │t.lt)                                                             │

 │                                                                  │

 │Операции                                                          │

 │                                                                  │

 │ create = proc ()  returns (olist [t])                            │

 │        effects возвращает новый, пустой список                   │

 │                                                                  │

 │ addel  = proc (s: olist[t], x:t)                                 │

 │        requires x не содержится в s; т.е. обращение к is_in(s,x) │

 │                 возвращает false                                 │

 │        modifies s                                                │

 │        effects вставляет x в s                                   │

 │                                                                  │

 │ remel  = proc (s: olist[t], x:t)                                 │

 │        requires x содержится в s; т.е. обращение к is_in(s,x)    │

 │                 возвращает true                                  │

 │        modifies s                                                │

 │        effects удаляет x из s                                    │

 │                                                                  │

 │ is_in  = proc (s: olist[t], x:t) returns (bool)                  │

 │        effects возвращает значение true, если s содержит элемент │

 │                равный x (используется t.equal), в противном слу- │

 │                чае возвращает значение false                     │

 │                                                                  │

 │ empty  = proc (s: olist[t]) returns (bool)                       │

 │        effects возвращает значение true, если s не содержит эле- │

 │                ментов, и значение false - в противном случае     │

 │                                                                  │

 │ least  = proc (s: olist[t]) returns(t)                           │

 │        requires список не пуст, то есть обращение к операции     │

 │                 empty(s) возвращает значение false               │

 │        effects возвращает элемент e из s, такой, что в s не суще-│

 │                ствует элемента, меньшего e(как определяется t.lt)│

 │                                                                  │

 │end olist                                                         │

 └──────────────────────────────────────────────────────────────────┘

    Рис.1.13.Спецификация параметризованной абстракции данных для

             упорядоченных списков.

    Абстракции данных либо изменяемы (с  объектами,  значения  которых

могут изменяться), либо неизменяемы. К определению этого аспекта  типа

следует относиться внимательно. В общем случае тип должен быть неизме-

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

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

должен быть изменяемым, если моделируется что-то  из  реального  мира.

Неизменяемый тип более надежен, чем изменяемый, однако менее  эффекти-

вен в связи с необходимостью частой очистки памяти (сбор мусора).

    Операции абстракции данных распадаются на четыре класса.

    1)Примитивные конструкторы. Эти операции создают объекты  соответ-

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

тов. (Операция create для наборов intset).

    2)Конструкторы. Эти  операции  используют  в  качестве  аргументов

объекты соответствующего им типа и создают другие  объекты  такого  же

типа. (Операции add и mul - конструкторы для полиномов, операции  cons

и rest - конструкторы для списков).

    3)Модификаторы.     Эти  операции  модифицируют  объекты  соответ-

ствующего им типа. (Операции insert и delete - модификаторы для  набо-

ров intset). Очевидно, что только изменяемые типы могут иметь  модифи-

каторы.

    4)Наблюдатели.  Эти  операции  используют  в  качестве  аргументов

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

Они используются для получения информации об объектах. (Операции size,

member и choose для наборов intset, операции coef, degree и equal  для

полиномов).

    Обычно примитивные конструкторы создают не все, а  только  некото-

рые объекты. Например, операция poly.create создает  только  одночлен-

ные полиномы, а операция intset.create создает  только  пустой  набор.

Другие объекты создаются конструкторами или модификаторами.  Например,

операция poly.add может быть использована для получения  полиномов,  у

которых количество членов больше одного, а  операция  intset.insert  -

для получения наборов с многими элементами.

    Модификаторы играют ту же роль для изменяемых типов,  что  и  кон-

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

ры, так и модификаторы; например, наборы intset могут  иметь  операцию

copy, которая создает новый набор, содержащий те же элементы, что и ее

аргумент. Иногда наблюдатели комбинируются с конструкторами или  моди-

фикаторами; например, операция remel для упорядоченных списков olist с

помощью операций least и remel может модифицировать список  и  возвра-

тить удаленный элемент.

    Тип данных является полным, если он обеспечивает достаточно опера-

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

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

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

насколько мало операций может иметь тип, оставаясь при  этом  приемле-

мым. Например, если для наборов intset будут существовать только  опе-

рации create, insert и delete, то программы не смогут  получить  ника-

кой информации относительно элементов набора (так как не имеется  наб-

людателей). Если к этим трем операциям добавить только одну - size, то

уже возможно получение информации об элементах набора (например,  мож-

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

нился ли размер). Но тип в этом случае получится неэффективным и  неп-

риемлемым.

    В общем случае абстракция данных должна иметь операции по  крайней

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

ные конструкторы, наблюдатели и либо конструкторы (если она неизменяе-

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

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

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

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

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

этого контекста. Если тип предназначен для общего использования, жела-

тельно иметь богатый набор операций. Введение дополнительных  операций

должно быть соотнесено с затратами на реализацию этих  операций.  Если

тип является полным, его набор операций может быть расширен процедура-

ми, функционирующими вне реализации типа.

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

основе анализа свойств объектов типа. Этот  анализ  осуществляется  на

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

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

всех объектов типа. Такое свойство называется инвариантом  абстракции.

Для доказательства используется метод индукции. Чтобы установить инва-

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

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

тод.

1)Показать, что свойство сохраняется для всех  объектов,  возвращаемых

примитивными конструкторами.

2)Показать, что свойство сохраняется для объектов,  возвращаемых  кон-

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

даваемых конструкторам в качестве аргументов.

3)Показать, что при выходе из модификатора  свойство  сохраняется  для

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

ве модификатора.

    Например, упорядоченные списки (рис.1.13) не содержат  дублирующих

элементов. Этот инвариант полезен для определения корректности  реали-

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

это свойство является инвариантом, устанавливается следующим образом:

1)оно сохраняется для единственного примитивного конструктора  create,

так как операция create возвращает новый пустой список;

2)оно сохраняется для операции addel(s,x). При возврате из этой опера-

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

элемент x. По предположению, до вызова в s не  было  дублирующих  друг

друга элементов. Кроме того, операция  addel  требует  (в  предложении

requires), чтобы x не содержался в s. Следовательно, набор s с  добав-

ленным элементом x не содержит дублирующих друг друга элементов;

3)оно сохраняется для операции remel(s,x), так как оно сохраняется для

s (по предположению), а операция remel только удаляет элементы из s.

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

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

чения текущего значения объекта. Первый шаг  индукции  -  установление

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

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

модификаторов.

                 1.4.Исключительные ситуации

    Процедурная абстракция есть отображение аргументов в результаты  с

возможной модификацией некоторых аргументов. Аргументы принадлежат об-

ласти определения процедуры, а результаты - области изменения.

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

подмножеству ее области определения. Например, операция choose для на-

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

бор. В приведенной выше спецификации типа данных intset (рис.1.9)  эта

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

которой области определения.

      ┌─────────────────────────────────────────────────────┐

      │ choose = proc (s: intset) returns (int)             │

      │        requires набор s не пуст                     │

      │        effects Возвращает произвольный элемент s    │

      └─────────────────────────────────────────────────────┘

    Но в этом случае, реализуя операцию  choose,  игнорируется  случай

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

Устойчивая программа - это такая программа, которая ведет себя коррек-

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

предсказуемым образом.

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

нии процедур, заданных на всей  области  определения.  Если  процедура

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

жна оповестить обратившегося к ней о возникшем затруднении. Таким  об-

разом, разрешение ситуации передается обратившемуся к процедуре, кото-

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

ствий ошибки.

    Проверка входных аргументов на принадлежность допустимому  подмно-

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

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

продукте. Однако это не самое  лучшее  решение.  Лучшим  является  ис-

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

себя от ошибок. Защитное программирование облегчает отладку  программ.

При эксплуатации ПО оно еще более ценно,  так  как  исключает  возмож-

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

Проверка на нелегальные аргументы может быть отключена только при  аб-

солютной уверенности в невозможности ошибки или если  проверка  приво-

дит к крайней неэффективности.

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

ситуации, добавим в спецификацию предложение signals. Это предложение

- часть заголовка. Оно следует за предложением returns. Если  исключи-

тельных ситуаций не имеется, оно может быть опущено.

    Как и раньше, секция effects должна определять поведение  процеду-

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

Так как это поведение включает в себя исключительные ситуации,  секция

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

тельной ситуации и что делает процедура в каждом таком случае.  Завер-

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

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

    С учетом всего вышесказанного, спецификация процедуры  choose  бу-

дет иметь вид:

 ┌──────────────────────────────────────────────────────────────────┐

 │ choose = proc (s: intset) returns (int) signals (empty)          │

 │        effects Если size(s)=0, то сигнализировать об исключитель-│

 │                ной ситуации empty, иначе возвратить произвольный │

 │                элемент s.                                        │

 └──────────────────────────────────────────────────────────────────┘

    При реализации процедуры с исключительными ситуациями работа прог-

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

кации работу процедуры. Если спецификация  включает  в  себя  исключи-

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

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

спецификации значения. Для выполнения этой задачи, программа,  возмож-

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

процедурах, к которым она обращается.

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

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

уровня, то есть вызывающая процедура также завершает работу сигнализа-

цией об исключительной ситуации с тем же самым или  другим  значением.

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

может осуществить некоторую локальную обработку. Такая обработка иног-

да необходима для достижения соответствия со спецификацией  вызывающей

процедуры. Например, операция типа данных  должна  гарантировать,  что

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

ления.

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

рует исключительную ситуацию, то есть обрабатывает ее сама.

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

в операциях которой удалены предложения requires и добавлены  исключи-

тельные ситуации в операциях addel, remel и least.  Полученная  в  ре-

зультате спецификация (рис.1.14) будет обладать большей  устойчивостью

по сравнению с исходной (рис.1.13).

 ┌──────────────────────────────────────────────────────────────────┐

 │olist = data type [t:type] is create,addel,remel,is_in,empty,least│

 │                                                                  │

 │Requires  - t имеет операции                                      │

 │                    equal,lt:proctype(t,t) returns (bool),        │

 │            которые определяют упорядочение t                     │

 │                                                                  │

 │Описание                                                          │

 │                                                                  │

 │Упорядоченные списки olist - изменяемые списки элементов. Операции│

 │addel и remel модифицируют списки. Каждый элемент упорядоченного  │

 │списка отличается от остальных (как определяется t.equal). Опера- │

 │ция least возвращает наименьший элемент olist (как определяется   │

 │t.lt)                                                             │

 │                                                                  │

 │Операции                                                          │

 │                                                                  │

 │ create = proc ()  returns (olist [t])                            │

 │        effects возвращает новый, пустой список                   │

 │                                                                  │

 │ addel  = proc (s: olist[t], x:t) signals(dupl)                   │

 │        modifies s                                                │

 │        effects  если x принадлежит s, сигнализирует об исключи-  │

 │                 тельной ситуации dupl, иначе вставляет x в s     │

 │                                                                  │

 │ remel  = proc (s: olist[t], x:t) signals(not_in)                 │

 │        modifies s                                                │

 │        effects  если x не принадлежит s, сигнализирует об исключи│

 │                 тельной ситуации not_in,иначе удаляет x из s     │

 │                                                                  │

 │ is_in  = proc (s: olist[t], x:t) returns (bool)                  │

 │        effects возвращает значение true, если s содержит элемент │

 │                равный x (используется t.equal), в противном слу- │

 │                чае возвращает значение false                     │

 │                                                                  │

 │ empty  = proc (s: olist[t]) returns (bool)                       │

 │        effects возвращает значение true, если s не содержит эле- │

 │                ментов, и значение false - в противном случае     │

 │                                                                  │

 │ least  = proc (s: olist[t]) returns(t) signals(empty)            │

 │        effects если s пуст, сигнализирует об исключительной ситуа│

 │                ции empty, иначе возвращает элемент e из s, такой,│

 │                что в s не существует элемента, меньшего e(как оп-│

 │                ределяется t.lt)                                  │

 │                                                                  │

 │end olist                                                         │

 └──────────────────────────────────────────────────────────────────┘

    Рис.1.14.Спецификация параметризованной абстракции данных для

             упорядоченных списков.

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

большинства ограничений, перечисленных в  предложениях  requires.  Эти

предложения следует оставлять только из соображений эффективности  или

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

ренным, что ограничения удовлетворяются.

    Cледует остановиться на взаимосвязи модификаций аргументов  с  за-

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

modifies спецификации указывает, что аргумент может  модифицироваться,

но не говорит о том,  когда  это  происходит.  Если  имеются  исключи-

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

ких-нибудь из них. Точное описание происходящего должно быть  приведе-

но в секции effects. Модификации должны быть  описаны  явно  в  каждом

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

ций, это означает, что они не совершаются вообще.  Например,  рассмот-

рим процедуру

 ┌──────────────────────────────────────────────────────────────────┐

 │                                                                  │

 │ addel  = proc (s: olist[t], x:t) signals(dupl)                   │

 │        modifies s                                                │

 │        effects  если x принадлежит s, сигнализирует об исключи-  │

 │                 тельной ситуации dupl, иначе вставляет x в s     │

 │                                                                  │

 └──────────────────────────────────────────────────────────────────┘

    Так как для случая, когда процедура addel сигнализирует об  исклю-

чительной ситуации dupl, не описано никаких модификаций,  s  модифици-

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

    Исключительная ситуация failure  является  неявной  исключительной

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

цификациях. Спецификация описывает поведение процедуры при ее работе и

для случая, когда аргументы удовлетворяют предложению requires. Исклю-

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

происходит сбой и она больше не отвечает своей спецификации или  когда

заданы неверные аргументы.

    Обычно исключительная ситуация failure не  может  быть  обработана

программой. Эта ситуация означает либо ошибку в математическом обеспе-

чении, либо сбой в аппаратной части.

                    1.5.Абстракции итерации

    Для работы с набором данных требуется некоторый общий метод итера-

ции, который удобен и эффективен и который сохраняет абстракцию  через

спецификацию. Итератор обеспечивает эти требования. Он вызывается  как

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

результатов, которые каждый раз выдает по одному. Полученные  элементы

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

няемые для каждого такого элемента. Использующий итератор  модуль  бу-

дет содержать некоторую структуру организации цикла. Каждый раз,  ког-

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

тело цикла. Затем управление возвращается в итератор, так что  он  мо-

жет выдавать следующий элемент. Следует отметить разделение обязаннос-

тей в такой форме взаимодействия. Итератор ответственен  за  получение

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

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

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

ния.

    Как и другие абстракции, итераторы должны  быть  определены  через

спецификации. Форма спецификации итерации аналогична форме для  проце-

дуры. Заголовок имеет вид:

  iname = iter(список входных данных)   yields(список выходных данных)

          signals (сообщение об исключительной ситуации)

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

тора. Итератор может совсем не выдавать объектов  на  каждой  итерации

или выдать несколько объектов. Число и тип этих объектов описываются в

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

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

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

signals. Например,

 ┌──────────────────────────────────────────────────────────────────┐

 │ elements = iter (s: intset) yields (int)                         │

 │          requires s не модифицируется в теле цикла               │

 │          effects Выдает элементы s в некотором произвольном по-  │

 │                  рядке, причем каждый элемент только один раз.   │

 └──────────────────────────────────────────────────────────────────┘

    Эта операция вполне  правдоподобна  для  набора  intset.  Операция

elements не имеет исключительных ситуаций. Если ей будет задан  в  ка-

честве аргумента пустой набор intset, она просто заканчивается, не вы-

давая ни одного элемента. Характерно, что использование итераторов ис-

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

как пустой набор intset) для соответствующих процедур (таких, как про-

цедура choose).

    Требование о том, чтобы набор s не модифицировался при использова-

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

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

являются совокупностью объектов. Поскольку  совокупность  используется

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

торый способ доступа ко всем элементам. Этот способ должен быть  эфек-

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

должен разрушать данную совокупность. Кроме того, он должен  обеспечи-

вать абстракцию через спецификацию.

    Итераторы являются механизмом, решающим эту задачу. Поскольку  они

выдают объекты по одному, не  требуется  дополнительного  пространства

для хранения объектов, и процедура может быть остановлена, когда  нуж-

ный объект будет найден. Метод выдачи объектов зависит от знания пред-

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

этого знания.

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

ляются операции над типами данных.

            1.6.Использование абстракций в языке Паскаль

    В языке Паскаль непосредственно не  обеспечиваются  ни  абстракции

данных или итераций, ни абстракция через параметризацию. Тем не  менее

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

Паскаль, все же можно с успехом применять эти  абстракции.  Для  этого

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

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

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

    Рассмотрим по очереди абстракции процедур, данных  и  итераций,  а

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

               1.6.1.Абстракции процедур и функций

    1.  В общем случае нецелесообразно проектировать абстракции, кото-

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

стракции бкдет зависеть от того контекста, в котором она находится.

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

Паскаль зададим некоторую процедуру failure. Эта процедура  помещается

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

программе.

 ┌───────────────────────────────────────────────────────────────────┐

 │  procedure failure (s:error_msg)                                  │

 │        modifies  выходной поток на основном устройстве вывода     │

 │        effects   печатает следующую строку на основном устройстве │

 │                  вывода: "Сбой. Программа окончилась из-за: +S",  │

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

 └───────────────────────────────────────────────────────────────────┘

                     1.6.2.Абстракции данных

    В общем случае эти абстракции могут быть основаны на объектах, за-

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

ве. Рассмотрим второй случай, который дает большую  гибкость  за  счет

некоторой неэффективности.

    Зададим спецификацию абстракции данных для очереди целых чисел.

 ┌───────────────────────────────────────────────────────────────────┐

 │ intqueue = data type is q_new, q_isempty, q_append, q_remfirst    │

 │                                                                   │

 │ Описание                                                          │

 │     Типы данных intqueue используются для хранения значений типа  │

 │ целого числа. Элементы могут извлекаться из очереди или удалять-  │

 │ ся из нее только по методу FIFO (First Input-First Output)        │

 │ Операции                                                          │

 │ function q_new:intqueue                                           │

 │        effects  Возвращает новую очередь без элементов в ней      │

 │ function q_isempty (q:intqueue): boolean                          │

 │        effects  Возвращает значение true, если в очереди q нет    │

 │                 элементов, в противном случае возвращает значе-   │

 │                 ние false                                         │

 │ procedure q_append (q:intqueue; e:integer)                        │

 │        modifies  q                                                │

 │        effects  Добавляет элемент  e  в конец очереди  q          │

 │ function q_remfirst (q:intqueue): integer                         │

 │        requires  чтобы очередь  q  не была пустой                 │

 │        modifies  q                                                │

 │        effects  Возвращает элемент из начала очереди  q  и        │

 │                 удаляет этот элемент из очереди  q                │

 │ end intqueue                                                      │

 └───────────────────────────────────────────────────────────────────┘

    Рис.1.15.Спецификация абстракции данных для очереди целых чисел.

    Решение хранить абстрактные объекты в неупорядоченном массиве про-

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

размер по мере работы программы. Реализация такого  абстрактного  типа

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

редаче в процедуру некоторого абстрактного объекта  всегда  передается

только ссылка. При модификации  абстрактного  объекта,  модифицируется

тот объект, на который указывает ссылка, а не сама ссылка. Таким обра-

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

параметры типа var. Кроме того, представление объекта некоторой  ссыл-

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

помощи функций.

    В результате тип intqueue будет иметь следующее представление

type

    intqueue = ^intqueue_rep;

    intqueue_rep = ^intqueue_elem;

    intqueue_elem = record

             var  : integer;

             next : intqueue_rep;

             end;

    Теперь для объявления переменных некоторого абстрактного типа дос-

таточно указать

    var q:intqueue;

    Смысл этого объявления  состоит  в  том,  что  в  стеке  отводится

пространство для некоторой  неинициализированной  переменной q.  Когда

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

цедуры, освобождается только этот указатель.

    Чтобы гарантировать правильное освобождение пространства, для каж-

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

ваемая destroy.

 ┌───────────────────────────────────────────────────────────────────┐

 │ procedure q_desstroy (q:intqueue)                                 │

 │       modifies  q                                                 │

 │       effects  В неупорядоченном массиве освобождается вся        │

 │                память, занимаемая очередью  q                     │

 └───────────────────────────────────────────────────────────────────┘

    По соглашению нельзя  освобождать  абстрактные  объекты  непосред-

ственно. Вместо этого необходимо обращение к операции destroy для  ти-

па данного объекта.  На  рис.1.16  приведена  реализация  типа  данных

intqueue, включая и операцию destroy.

 ┌───────────────────────────────────────────────────────────────────┐

 │ Type  IntQueue = ^IntQueue_Rep;                                   │

 │       IntQueue_Rep = ^IntQueue_Elem;                              │

 │       IntQueue_Elem = Record                                      │

 │           i : Word;                                               │

 │           Next : IntQueue_Rep;                                    │

 │           End;                                                    │

 │                                                                   │

 │ Function q_new:IntQueue;                                          │

 │ Function q_isempty(q:IntQueue):Bollean;                           │

 │ Procedure q_append(q:IntQueue; e:Word);                           │

 │ Function q_remfirst(q:Intqueue):Word;                             │

 │ Procedure failure(s:String);                                      │

 │                                                                   │

 │ Function q_new:IntQueue;                                          │

 │ Var q:IntQueue;                                                   │

 │   Begin                                                           │

 │     new(q);                                                       │

 │     q^:=nil;                                                      │

 │     q_new:=q;                                                     │

 │   End;                                                            │

 │                                                                   │

 │ Function q_isempty(q:IntQueue):Bollean;                           │

 │ Var buf:bollean;                                                  │

 │   Begin                                                           │

 │     buf:=(q^=nil);                                                │

 │     q_isempty:=buf;                                               │

 │   End;                                                            │

 │                                                                   │

 │ Procedure q_append(q:IntQueue; e:Word);                           │

 │ Var last,elem:IntQueue_Rep;                                       │

 │   Begin                                                           │

 │     new(elem);                                                    │

 │     elem^.i:=e;                                                   │

 │     elem^.next:=nil;                                              │

 │     if q_isempty(q) then q^:=elem                                 │

 │     else begin                                                    │

 │            last:=q^;                                              │

 │            while  last^.next <> nil  do                           │

 │              last:=last^.next;                                    │

 │            last^.next:=elem;                                      │

 │          end;                                                     │

 │   End;                                                            │

 │                                                                   │

 │ Function q_remfirst(q:IntQueue):Word;                             │

 │ Var oldq:IntQueue_Rep;                                            │

 │   Begin                                                           │

 │     if q_isempty(q) then failure ('К функции q_remfirst           │

 │                          обратились с пустой очередью')           │

 │     else begin                                                    │

 │            q_remfirst:=q^^.i;                                     │

 │            oldq:=q^;                                              │

 │            q^:=q^^.next;                                          │

 │            dispose(oldq);                                         │

 │     end;                                                          │

 │   End;                                                            │

 │                                                                   │

 │ Procedure failure(s:String);                                      │

 │   Begin                                                           │

 │     OutTextXT(320,200,s);                                         │

 │     Readln;                                                       │

 │     Halt(0);                                                      │

 │   End;                                                            │

 └───────────────────────────────────────────────────────────────────┘

        Рис.1.16.Реализация операций типа данных intquaeue.

                     1.6.3.Абстракция итерации

    Для реализации итератора создадим тип некоторого специального  ви-

да, называемый генератором. Генераторы имитируют работу итераторов.  У

каждого генератора есть три функции и одна процедура. Эти три  функции

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

ли элементы были выданы. Процедура уничтожает объект генератора.

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

(рис.1.17). Функция qelems_create выполняет некоторую работу  по  ини-

циализации, то есть возвращает некоторый объект с типом  qelems.  Вто-

рая функция qelems_next выдает каждый раз один элемент при обращении к

ней и модифицирует объект генератора qelems, чтобы указать,  что  этот

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

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

qelems_destroy освобождает пространство, которое было выделено при ра-

боте функцией qelems_create и qelems_next.

 ┌───────────────────────────────────────────────────────────────────┐

 │ qelems = generator type is qelems_create, qelems_done,            │

 │                            qelems_next, qelems_destroy            │

 │ Описание                                                          │

 │     Генераторы qelems используются для выполнения итераций по     │

 │ элементам очередей целых чисел IntQueue.                          │

 │ Операции                                                          │

 │ function qelems_create (q:IntQueue): qelems                       │

 │       effects  Возвращается некоторый объект qelems, который      │

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

 │                в очереди q                                        │

 │ function qelems_done (qi:qelems): boolean                         │

 │       requires  Чтобы очередь целых чисел intqueue, используемуя  │

 │                 для создания элементов qi, не модифицировалась    │

 │                 после того, как создан элемент qi                 │

 │       effects  Возвращается значение true, если все элементы в    │

 │                очереди целых чисел intqueue, используемой для     │

 │                создания элементов qi, были "выданы" после того,   │

 │                как был создан элемент qi. В противном случае      │

 │                возвращается значение false                        │

 │ function qelems_next (qi:qelems): word                            │

 │       requires  Чтобы очередь целых чисел intqueue, используемуя  │

 │                 для создания элементов qi, не модифицировалась    │

 │                 после того, как создан элемент qi, и чтобы сущест-│

 │                 вовал некоторый элемент в очереди целых чисел     │

 │                 intqueue, который еще не был выдан                │

 │       modifies  qi                                                │

 │       effects  Возвращается некоторый элемент в очереди чисел     │

 │                intqueue, используемой для создания элемента qi.   │

 │                Этот элемент очереди не был выдан после того, как  │

 │                был создан элемент qi. Элемент qi модифицируется   │

 │                для того, чтобы отметить тот факт, что данный      │

 │                элемент был "выдан"                                │

 │ procedure qelems_destroy (qi:qelems)                              │

 │       modifies  qi                                                │

 │       effects  Освобождается вся память из неупорядоченного       │

 │                массива, занимаемая элементом qi                   │

 │ end qelems                                                        │

 └───────────────────────────────────────────────────────────────────┘

      Рис.1.17.Спецификация типа данных генератор для очередей.

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

цией очереди целых чисел intqueue, имеет вид:

 ┌───────────────────────────────────────────────────────────────────┐

 │ type                                                              │

 │     qelems = ^qelems_rep;                                         │

 │     qelems_rep = ^intqueue_elem;                                  │

 │ function qelems_create (q:intqueue): qelems;                      │

 │     var qi:qelems;                                                │

 │     begin                                                         │

 │          new(qi);                                                 │

 │          qi^:=q^;                                                 │

 │          qelems_create:=qi;                                       │

 │     end;                                                          │

 │ function qelems_done (qi:qelems): bollean;                        │

 │     begin                                                         │

 │          qelems_done:=(qi^=nil);                                  │

 │     end;                                                          │

 │ function qelems_next (qi:qelems): word;                           │

 │     begin                                                         │

 │          if qi^=nil                                               │

 │             then failure('К функции qelems_next обратились        │

 │                           с пустой очередью генератора')          │

 │          else begin                                               │

 │                    qelems_next:=qi^^.i;                           │

 │                    qi^:=qi^^.next;                                │

 │               end;                                                │

 │     end;                                                          │

 │ procedure qelems_destroy (qi:qelems);                             │

 │     begin                                                         │

 │          dispose(qi);                                             │

 │     end;                                                          │

 └───────────────────────────────────────────────────────────────────┘

     Рис.1.18.Реализация генератора для типа данных очередь целых

              чисел intqueue.

    В результате этой реализации осуществляется доступ  к  представле-

нию очереди целых чисел intqueue. Следует отметить, что  представление

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

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

    Пример суммирования всех членов очереди примет вид:

    sum:=0;

    qi:=qelems_create(q);

    while  not (qelems_done(qi))  do

        sum:=sum+qelems_next(qi);

    qelems_destroy(qi);

                2.ВВЕДЕНИЕ В ИНЖЕНЕРНОЕ ПРОГРАММИРОВАНИЕ

            2.1.Цели и задачи инженерного программирования

    П р о г р а м м н о е   о б е с п е ч е н и е - это совокупность

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

тельной системы(ВС).

    И н ж е н е р н о е   п р о г р а м м и р о в а н и е - это такое

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

потенциальные возможности ЭВМ реализуются на  пользу  человеку  с  по-

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

документации.

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

тия инженерного программирования. Важность инженерного  программирова-

ния обуславливается следующими двумя тенденциями:

- ПО является сложным изделием и стоимость его все более возрастает;

- ПО оказывает значительное и все возрастающее воздействие  на  общес-

твенное благосостояние.

    Стоимость ПО, разработанного в  США,  характеризуется  следующими

данными.

                Табл.2.1.Стоимость ПО в США

┌──────────────────┬─────────────────────────────────────────────────┐

│                  │        Стоимость ПО                             │

│   Годы           ├──────────────────────┬──────────────────────────┤

│                  │        млрд $        │        %% ВНП            │

├──────────────────┼──────────────────────┼──────────────────────────┤

│                  │                      │                          │

│    1980          │         40           │        2,0               │

│                  │                      │                          │

│    1985          │        190           │        8,5               │

│                  │                      │                          │

│    1990          │        297           │       13,0               │

└──────────────────┴──────────────────────┴──────────────────────────┘

    Общемировые тенденции роста стоимости ПО  можно  проиллюстрировать

тем, что стоимость ПО по сравнению со стоимостью  технических  средств

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

                                             Западноевропейская оценка

 Доля пол-  100 ---------------------------        .................

 ной стои-      |            |     .......|........       ..  ..

 мости, %%      |    ТС      | ....       |   ..        ..      ..

                |          ..|.           |      ..   ..          ..  ..

                |        ..  |            |         ..              ..

             50 |------------|------------|        Японская оценка

                |       .    |            |

                |      .     |            |

                |   ...      |     ПО     |

                |..          |            |

              0 ---------------------------

              1955          1970        1985

         Рис.2.1.Тенденции изменения стоимости ТС и ПО

    Подобный рост спроса на ПО предъявляет существенные  требования  к

инженерному программированию:

- существенно повысить производительность труда при разработке ПО;

- повысить эффективность сопровождения ПО, так как оно составляет око-

ло половины стоимости ПО (рис.2.1).

    Рост спроса на ПО является следствием того, что автоматизация тру-

да человека с помощью ЭВМ становится все более и более  выгодной.  Эта

тенденция может быть подтверждена следующими данными. В настоящее вре-

мя в США более половины работающих используют ЭВМ в  своей  профессио-

нальной деятельности, не обязательно зная как функционируют ТС  и  ПО.

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

ПО. Еще более глубокое воздействие ЭВМ и ПО оказывают на частную жизнь.

    Исходя из этого возникает еще ряд требований к  инженерному  прог-

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

ПО, которое гарантирует, что ВС являются:

- исключительно надежными

- удобными в использовании

- естественными

- проверяемыми

- труднодоступными для злоупотреблений

- оставляющими главную роль за человеком, а не за машиной.

    Попытка сформулировать общую  цель  инженерного  программирования,

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

ний, обречена на неудачу, так как  некоторые  требования  противоречат

друг другу.

    Пример противоречий: пяти бригадам программистов дано  одно  и  то

                         же задание по программированию. Однако  перед

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

               Табл.2.2.Оценки результатов работы бригад

┌─────────────────────┬──────────────────────────────────────────────┐

│Цель бригады -       │ Оценки (1-наилучшая, 5-наихудшая)            │

│                     ├────────┬───────────┬───────┬────────┬────────┤

│оптимизировать       │затраты │число опе- │объем  │ясность │четкость│

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

├─────────────────────┼────────┼───────────┼───────┼────────┼────────┤

│Затраты труда        │   1    │     4     │  4    │   5    │   3    │

│                     │        │           │       │        │        │

├─────────────────────┼────────┼───────────┼───────┼────────┼────────┤

│Число операторов     │   2    │     1     │  2    │   3    │   5    │

│программы            │        │           │       │        │        │

├─────────────────────┼────────┼───────────┼───────┼────────┼────────┤

│Объем требуемой      │   5    │     2     │  1    │   4    │   4    │

│памяти               │        │           │       │        │        │

├─────────────────────┼────────┼───────────┼───────┼────────┼────────┤

│Ясность программы    │   4    │     3     │  3    │   2    │   2    │

│                     │        │           │       │        │        │

├─────────────────────┼────────┼───────────┼───────┼────────┼────────┤

│Четкость выходных    │   3    │     5     │  5    │   1    │   1    │

│данных               │        │           │       │        │        │

└─────────────────────┴────────┴───────────┴───────┴────────┴────────┘

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

несчастью) не столь проста.

    Существует большое количество предлагаемых в  качестве  рекоменда-

ций "стандартов" программирования: "разрабатывайте сверху-вниз",  "до-

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

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

определяйте этапы", "привлекайте к работе пользователя" и т.д.  Каждый

из этих советов способствует выполнению  определенных  требований,  но

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

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

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

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

торых в зависимости от ситуации в различной степени помогает  или  ме-

шает достижению конкретной цели.

    Эффективность инженерного программирования основывается на осущес-

твлении двух основных подцелей:

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

- реализация эффективного процесса разработки и сопровождения ПО.

    Каждая из этих подцелей состоит из следующих трех компонентов:

- учет человеческих факторов

- управление ресурсами

- программотехника (технология программирования).

    В общем случае цели инженерного  программирования  можно  предста-

вить следующей иерархической структурой (рис.2.2).

            ┌─────────────────────────────────────────────┐

            │  Эффективность инженерного программирования │

            └───────┬───────────────────────────────┬─────┘

                    │                               │

┌───────────────────┴────────┐          ┌───────────┴────────────────┐

│   Качество программного    │          │   Эффективность процесса   │

│        изделия             │          │       разработки ПО        │

└───┬───────────┬───────────┬┘          └┬───────────┬──────────┬────┘

    │           │           │            │           │          │

┌───┴────┐  ┌───┴────┐  ┌───┴────┐  ┌────┴───┐  ┌────┴───┐  ┌───┴────┐

│Человеч.│  │Управлен│  │Програм-│  │Человеч.│  │Управлен│  │Програм-│

│факторы │  │ресурсам│  │мотехник│  │факторы │  │ресурсам│  │мотехник│

└────────┘  └────────┘  └────────┘  └────────┘  └────────┘  └────────┘

Легкость    Эффектив-   Специфици-  Планируе-   Анализиру-  Осуществи-

использова  ность       рованность: мость       емость эф-  мость

ния         Сбаланси-   полнота     Организу-   фективности Подтверж-

Удовлетво-  рованность  непротиво-  емость      затрат      даемость

рение пот-  Измеряе-    речивость   Укомплек-   Планируе-   Полнота и

ребностей   мость       безопас-    тованность  мость       непротиво-

пользовате-             ность       штатов      Оценивае-   речивость

ля                      осуществи-  Руководи-   мость       требований

Реализация              мость       мость       Контроли-   Подтвержда-

потенц.спо-             проверяе-   Контроли-   руемость    емость

собностей               мость       руемость    Выполняе-   Проектируе-

пользовате-             Правиль-    Автомати-   мость       мость изде-

ля                      ность       зируемость  сроков и    лия

Следование              Адаптиру-   Следование  бюджета     Программи-

модифицир.              емость:     модифицир.              руемость

"золотому"              структури-  "золотому"              Комплекси-

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

                        независи-                           Внедряе-

                        мость                               мость

                        понятность                          Сопровож-

                                                            даемость

                                                            Снимаемость

                                                            Управляе-

                                                            мость кон-

                                                            фигурацией

        Рис.2.2.Структура целей инженерного программирования.

                         2.2.Типы пользователей

                      2.2.1.Уровни пользователей ПО

    Можно выделить три квалификационные категории пользователей, кото-

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

    К первому уровню относятся разработчики ПО - специалисты в  облас-

ти применения ЭВМ, способные разрабатывать базовые методы, средства  и

оснащение ПО, общесистемное  ПО,  инструментальные  и  технологические

средства, осуществлять генерацию и настройку ПО на условия конкретного

применения.

    Ко второму - те, кто хорошо знает тонкости  построения  системы  и

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

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

гут разрабатывать специализированное ПО, используя общесистемное ПО.

    К третьему относятся пользователи, работающие в системе с  помощью

ориентированного на них языка взаимодействия. Процесс  работы  в  этом

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

нию расчетов, анализу результатов и принятию решений.

          2.2.2.Психофизиологические особенности взаимодействия

                человека и ЭВМ

    ЭВМ дополняет человека, но не заменяет его,  поэтому  рассмотрение

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

    Л о г и ч е с к и й   м е т о д   р а с с у ж д е н и я. У челове-

ка он основан на интуиции, на использовании накопленного опыта и вооб-

ражения. Метод ЭВМ строгий и систематический. Наиболее удачным являет-

ся сочетание когда ЭВМ реализует отдельные расчетные процедуры,  а  их

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

проектируемого объекта.

    С п о с о б н о с т ь   к   о б  у  ч  е  н  и  ю. Человек  обуча-

ется постепенно, степень "образованности" ЭВМ определяется ее програм-

мным обеспечением. Желательно, чтобы количество  информации,  получае-

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

бованию пользователя.

    О б р а щ е н и е   с   и н ф о р м а ц и е й.  Емкость мозга  че-

ловека для сохранения детализированной информации невелика,  но  обла-

дает интуитивной, неформальной возможностью ее организации.  Эффектив-

ность вторичного обращения к памяти зависит от времени. В ЭВМ  емкость

памяти большая, организация формальная и  детализированная,  вторичное

обращение не зависит от времени. Поэтому целесообразно  накапливать  и

организовывать информацию автоматическим путем и осуществлять ее  быс-

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

    О ц е н к а   и н ф о р м а ц и и.  Человек умеет хорошо разделять

значимую и несущественную информацию. ЭВМ таким свойством не обладает.

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

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

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

    О т н о ш е н и е   к   о ш и б к а м.  Человек  часто  допускает

существенные ошибки, исправляя их интуитивно, при этом метод обнаруже-

ния ошибок чаще всего также интуитивный. ЭВМ, наоборот,  не  проявляет

никакой терпимости к ошибкам и метод обнаружения ошибок строго  систе-

матичен. Однако в области формальных  ошибок  возможности  ЭВМ  значи-

тельно больше, чем при обнаружении неформальных. Поэтому нужно обеспе-

чить возможность пользователю вводить в ЭВМ исходную информацию в сво-

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

ким выражениям и к разговорной речи. ЭВМ выполняет контроль и преобра-

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

ки и формального устранения ошибок. Затем желательно обратное преобра-

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

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

    О б р а щ е н и е   с о   с л о ж н ы м и   о п и с а н и я м и.

Человеку трудно воспринять большое количество информации. Поэтому сле-

дует поручать ЭВМ автоматическое разбиение сложных конфигураций на от-

носительно независимые части, охватываемые одним взглядом.  Естествен-

но, что изменения, сделанные в одной из этих частей, должны  автомати-

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

     Р а с п р е д е л е н е   в н и м а н и я   н а   н е с к о л ь -

к о   з а д а ч.  Выполнить это условие человеку, в основном, не  уда-

ется.  При решении подзадачи приходится отвлекаться от основной  зада-

чи. Поэтому в ЭВМ организована система  прерываний,  восстанавливающая

состояние основной задачи к моменту, нужному для пользователя.  Анало-

гичным образом ЭВМ обслуживает процедуру анализа нескольких  вариантов

решения.

    П а м я т ь   п о   о т н о ш е н и ю   к   п р о в е д е н н о й

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

что ему запланировано еще сделать. Этот недостаток компенсируется ЭВМ,

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

цедурах и предстоящей работе.

    С п о с о б н о с т ь   к   с о с р е д о т а ч и в а н и ю. Эта

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

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

Усталостью обуславливается рассеянность,  удлинение  реакций,  нецеле-

сообразные действия. В связи с этим интерактивная система  с  разделе-

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

пользователя.

    Т е р п е н и е. При многократном повторении одних и тех же дейст-

вий человек может испытывать чувство досады. Поэтому  предусматривает-

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

анализе этих данных. К этому же относится включение в системы макроко-

манд или гибкие сценарии.

    С а м о ч у в с т в и е.  ЭВМ должна беречь самочувствие пользова-

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

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

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

лем, определяющим ход и направление процесса проектирования.

    Э м о ц и о н а л ь н о с т ь. Это чувство свойственно человеку и

чуждо ЭВМ. ПО должно возбуждать у пользователя положительные эмоции  и

не допускать отрицательных.

          2.3.Классификация ПО и количественные характеристики

    В основу первой классификации может быть положен объем  ПО,  выра-

жаемый числом исходных команд (ЧИК). Этот термин -  исходные  команды,

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

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

семблеров. Исходные команды не включают комментарии и штатное  ПО,  но

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

описание.

    Исходя из числа исходных команд (ЧИК)  можно  классифицировать  ПО

следующим образом по размеру:

                Малый...........  2 000 ЧИК

                Промежуточный...  8 000 ЧИК

                Средний......... 32 000 ЧИК

                Большой.........128 000 ЧИК

    Введем следующие обозначения. Будем  считать,  что  человеко-месяц

(ЧМ) состоит из 152 часов рабочего времени. Тогда  для  преобразования

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

             для получения человеко-часов....умножить ЧМ на 152

             для получения человеко-дней.....умножить ЧМ на 19

             для получения человеко-годов....разделить ЧМ на 12

    Если возможна предварительная оценка разрабатываемого ПО  в  тыся-

чах исходных команд (КЧИК), то затраты труда в ЧМ и  сроки  разработки

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

                       1,05                      0,38

          ЧМ=2,4*(КЧИК)               СР=2,5*(ЧМ)

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

         Табл.2.3.Характеристики проектов распространенного типа

┌──────────────────┬───────────┬───────────────┬──────────┬──────────┐

│Размер ПО, КЧИК   │ Затраты   │ Производитель-│ Сроки,   │ Средние  │

│                  │ труда, ЧМ │ ность, ЧИК/ЧМ │ месяцы   │ штаты, ЧИ│

├──────────────────┼───────────┼───────────────┼──────────┼──────────┤

│Малый, 2          │    5,0    │     400       │    4,6   │    1,1   │

├──────────────────┼───────────┼───────────────┼──────────┼──────────┤

│Промежуточный, 8  │   21,3    │     376       │    8,0   │    2,7   │

├──────────────────┼───────────┼───────────────┼──────────┼──────────┤

│Средний, 32       │   91,0    │     352       │   14,0   │    6,5   │

├──────────────────┼───────────┼───────────────┼──────────┼──────────┤

│Большой, 128      │  392,0    │     327       │   24,0   │   16,0   │

└──────────────────┴───────────┴───────────────┴──────────┴──────────┘

    Приведенные в табл.2.3 данные относятся  к  коммерческим  програм-

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

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

т.п. Необходимо помнить, что затраты на такую  разработку  примерно  в

три раза выше, чем на персональную программу.

    Данные табл.2.3 получены на основании анализа 63  проектов  разра-

ботки ПО для разных типов ЭВМ, разных объемов, разного назначения, ис-

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

    Второй характеристикой для классификации ПО может  служить  качес-

твенная оценка. Различают три типа ПО: распространенный, полунезависи-

мый и встроенный.

    Р а с п р о с т р а н е н н ы й   тип характеризуется тем, что  ПО

разрабатывается относительно небольшой группой  специалистов  в  усло-

виях своей организации. Большинство связанных с проектом  людей  обла-

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

организации.

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

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

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

    В проекте распространенного  типа  налагаются  относительно  менее

жесткие ограничения на соответствие ПО требованиям и спецификациям ин-

терфейса.

    Другими характерными чертами ПО  распространенного  типа  являются

следующие:

- стабильные условия разработки проекта;

- минимальная необходимость новых системных и алгоритмических решений;

- относительно малое поощрение за раннее завершение проекта;

- относительно малый размер (как правило, до 50 КЧИК).

    В с т р о е н н ы й   тип отличается от других жесткими  ограниче-

ниями на характеристики ЭВМ и правила использования интерфейса.  Такое

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

руководств и вычислительных процессов. (Пример - система  резервирова-

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

    При разработке встроенного ПО, как  правило,  отсутствует  возмож-

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

при модификации требований и интерфейса. Поэтому большие затраты  тру-

да на установление соответствия ПО своим спецификациям  и  обеспечение

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

    По сравнению с распространенным встроенный  проект,  как  правило,

планируется при меньшем объеме информации об условиях его  реализации.

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

для избежания огромных накладных расходов.

    После завершения проектирования изделия лучшей стратегией  осущес-

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

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

кодирования и автономной отладки.

    П о л у н е з а в и с и м ы й   тип ПО занимает промежуточное поло-

жение между распространенными и  встроенными  типами.  Промежуточность

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

- промежуточные значения характеристик проекта;

- смещение характеристик распространенного и встроенного типов.

    Обычно не превосходит 300 КЧИК.

    Теперь можно расширить табл.2.3 характеристиками для  двух  других

типов (табл.2.4).

        Табл.2.4.Оценки для разработки ПО разных типов

┌───────┬────────┬────────────────────────────────────────────────────┐

│Харак- │Тип раз-│            Оценки для размеров                     │

│терис- │работки ├───────┬──────────┬─────────┬─────────┬─────────────┤

│тики   │        │ малый,│ промежу- │ средний │ большой │очень большой│

│       │        │ 2 КЧИК│ точный,  │ 32 КЧИК │ 128 КЧИК│512 КЧИК     │

│       │        │       │ 8 КЧИК   │         │         │             │

├───────┼────────┼───────┼──────────┼─────────┼─────────┼─────────────┤

│Затраты│Распр.  │  5,0  │  21,3    │     91  │   397   │             │

│труда, │Полун.  │  6,5  │  31,0    │    146  │   687   │    3250     │

│ЧМ     │Встр.   │  8,3  │  44,0    │    230  │  1216   │    6420     │

├───────┼────────┼───────┼──────────┼─────────┼─────────┼─────────────┤

│Произво│Распр.  │  400  │  376     │    352  │   327   │             │

│дитель-│Полун.  │  308  │  258     │    219  │   186   │     158     │

│ность, │Встр.   │  241  │  182     │    139  │   105   │      80     │

│ЧИК/ЧМ │        │       │          │         │         │             │

├───────┼────────┼───────┼──────────┼─────────┼─────────┼─────────────┤

│Сроки  │Распр.  │  4,6  │  8,0     │     14  │    24   │             │

│разра- │Полун.  │  4,8  │  8,3     │     14  │    24   │      42     │

│ботки, │Встр.   │  4,9  │  8,4     │     14  │    24   │      42     │

│месяцы │        │       │          │         │         │             │

├───────┼────────┼───────┼──────────┼─────────┼─────────┼─────────────┤

│Среднее│Распр.  │  1,1  │  2,7     │    6,5  │    16   │             │

│число  │Полун.  │  1,4  │  3,7     │   10,0  │    29   │      77     │

│исполни│Встр.   │  1,7  │  4,2     │   16,0  │    51   │     157     │

│телей  │        │       │          │         │         │             │

└───────┴────────┴───────┴──────────┴─────────┴─────────┴─────────────┘

              1.05

 4M = 2.4*КЧИК    - распространенный

              1.12

 4М = 3.0*КЧИК     - полунезависимый

              1.20

 4М = 3.6*КЧИК     - встроенный

              2.4.Жизненный цикл программного обеспечения

    Рассмотрим жизненный цикл программного обеспечения, то  есть  про-

цесс его создания и применения от начала до конца. Этот  процесс  сос-

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

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

    Первая стадия - определение требований и спецификаций, может  быть

названа стадией системного анализа. Общие требования  к  ПО  -  надеж-

ность, технологичность, правильность, универсальность,  эффективность,

информационная согласованность и т.д. Они дополняются требованиями за-

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

мые функции и возможности, режимы функционирования, требования точнос-

ти и надежности и т.д., то есть вырабатывается описание системы с точ-

ки зрения пользователя. При определении спецификаций производится точ-

ное описание функций ПО, разрабатываются и утверждаются входные и про-

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

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

ми, специфицируются средства расширения и модификации  ПО,  разрабаты-

ваются интерфейсы обслуживающих и основных подсистем, решаются  вопро-

сы базы данных, утверждаются  основные  алгоритмы.  Итогом  выполнения

этого этапа являются эксплуатационные и  функциональные  спецификации,

содержащие конкретное описание  ПО.  Разработка  спецификаций  требует

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

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

четкие и реальные требования.

    Эксплуатационные спецификации содержат сведения  о  быстродействии

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

т.д.

    Функциональные спецификации определяют функции, которые должно вы-

полнять ПО, то есть в них определяется что надо делать, а не  как  это

делать.

    Спецификации должны быть полными, точными и ясными. Полнота исклю-

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

заказчиков иных сведений, кроме  содержащихся  в  спецификациях.  Точ-

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

кость понимания как заказчиком, так и  разработчиком  при  однозначном

толковании.

    Значение спецификаций:

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

  закон для разработкчика;

2.спецификации используются для проверки готовности ПО;

3.спецификации являются неотемлимой частью  программной  документации,

  облегчают сопровождение и модификацию ПО.

    Второй стадией является проектирование ПО. На этом этапе:

1.формируется структура ПО  и  разрабатываются  алгоритмы,  задаваемые

  спецификациями;

2.устанавливается состав модулей с  разделением  их  на  иерархические

  уровни на основе изучения схем алгоритмов;

3.выбирается  структура  информационных  массивов,  составляющих  базу

  данных;

4.фиксируются межмодульные интерфейсы.

    Цель этапа - иерархическое разбиение сложных задач создания ПО  на

подзадачи меньшей сложности. Результатом работы на этом этапе  являют-

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

нецелесообразна.

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

программирование модулей. Этап менее сложен по сравнению со всеми  ос-

тальными. Проектные решения, полученные на предыдущей  стадии,  реали-

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

ся к создаваемой системе. Одна из задач -  обоснованный  выбор  языков

программирования. На этой же стадии решаются все вопросы, связанные  с

особенностями типа ЭВМ.

    Четвертая стадия -  отладка  ПО,  заключающаяся  в  аппробировании

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

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

бюджет. Этап предполагает выявление в программах ошибок, проверку  ра-

ботоспособности ПО, а также его соответствие спецификациям.

    Пятая стадия - сопровождение, то есть процесс исправления  ошибок,

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

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

вызвано, как минимум, двумя причинами: во-первых, в ПО остаются  ошиб-

ки, не выявленные при тестировании; во-вторых, пользователи в ходе эк-

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

шем совершенствовании.

    В общем случае, в процессе  разработки  ПО  требуется  осуществить

несколько итераций.

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

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

2.6.

       Табл.2.5.Затраты по стадиям жизненного цикла ПО

                   ┌──────────────────────────────────────────┐

                   │       Сведения из разных источников      │

┌──────────────────┼────────┬─────────┬───────┬────────┬──────┼───────┐

│Стадии жизненного │Гласс Р.│Энкарнач-│Боэм Б.│Федорчук│Вишня-│       │

│цикла программного│Нуазо Р.│чо Ж.    │       │Чернень-│ков   │Среднее│

│обеспечения       │        │         │       │кий     │      │       │

├──────────────────┼────────┼─────────┼───────┼────────┼──────┼───────┤

│Определение требо-│    10  │    15   │    6  │    6   │   6  │   8,6 │

│ваний и специфик. │        │         │       │        │      │       │

├──────────────────┼────────┼─────────┼───────┼────────┼──────┼───────┤

│Проектирование    │    10  │    12   │   18  │    5   │   6  │  10,2 │

├──────────────────┼────────┼─────────┼───────┼────────┼──────┼───────┤

│Программирование  │    10  │    12   │    9  │    7   │   6  │   8,8 │

├──────────────────┼────────┼─────────┼───────┼────────┼──────┼───────┤

│Отладка           │    20  │    15   │   17  │   15   │  14  │  16,2 │

├──────────────────┼────────┼─────────┼───────┼────────┼──────┼───────┤

│Сопровождение     │    50  │    46   │   50  │   67   │  68  │  56,2 │

│──────────────────┼────────┼─────────┼───────┼────────┼──────┼───────┤

│Всего             │   100  │   100   │  100  │  100   │ 100  │ 100   │

└──────────────────┴────────┴─────────┴───────┴────────┴──────┴───────┘

    Табл.2.6.Основные параметры стадий жизненного цикла ПО

┌────────────────────┬──────────────┬─────────────┬──────────────┐

│Стадии жизненного   │  Количество  │  Обнаруже-  │  Затраты на  │

│цикла программного  │  ошибок,%%   │  ние ошибок │  устранение  │

│обеспечения         │              │  %%         │  ошибок,%%   │

├────────────────────┼──────────────┼─────────────┼──────────────┤

│Определение требо-  │              │             │      9       │

│ваний и спецификаций│              │             │              │

├────────────────────┼──────────────┼─────────────┼──────────────┤

│Проектирование      │     61-64    │             │      6       │

├────────────────────┼──────────────┼─────────────┼──────────────┤

│Программирование    │     36-39    │             │     10       │

├────────────────────┼──────────────┼─────────────┼──────────────┤

│Отладка             │              │      46     │     12       │

├────────────────────┼──────────────┼─────────────┼──────────────┤

│Сопровождение       │              │      54     │     63       │

└────────────────────┴──────────────┴─────────────┴──────────────┘

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

представить сетевым графиком разработки ПО.

              ┌──┐                ┌──┐                ┌──┐

              │13│                │13│                │ 8│

    ┌─────────┴──┤      ┌─────────┴──┤      ┌─────────┴──┤

    │ Разработка │─────│ Проектиро- │─────│ Документи- │──────┐

    │ требований │      │ вание      │      │ рование    │      │

    └────────────┘      └────────────┘      └────────────┘      │

      ‑         │                  │                            │

      │         │        ┌──┐      │                            │

      │         ­        │ 8│      │              ┌──┐          │

      │        ┌─────────┴──┤      ­              │ 8│          ­

 ┌────────┐    │ Подготовка │     ┌───────────────┴──┤      ┌───────┐

 │ Начало │    │ данных для │     │ Программирование │      │ Конец │

 └────────┘    │ отладки    │     └──────────────────┘      └───────┘

      │        └────────────┘                      │            ‑

      │         │          │                       │            │

      │         │          └───────────────────┐   │            │

      │         │                              │   │            │

      ­         ­                              ­   ­            │

    ┌────────────┐      ┌────────────┐      ┌────────────┐      │

    │ Планирова- │      │ Разработка │      │ Испытание  │      │

    │ ние отладки│─────│ драйверов  │─────│ программно-│──────┘

    │            │      │ тестов     │      │ го изделия │

    └─────────┬──┤      └─────────┬──┤      └─────────┬──┤

              │ 8│                │25│                │17│

              └──┘                └──┘                └──┘

              Рис.2.7.Сетевой график разработки ПО.

       (цифры означают время в %% от полного времени первых

        четырех этапов жизненного цикла)

                    2.5.Общие принципы разработки ПО

                    2.5.1.Общие принципы

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

функциям, формам реализации. В этом смысле ПО  -  сложная,  достаточно

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

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

ПО.

    Ч а с т о т н ы й   п р и н ц и п. Основан на выделении в алгорит-

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

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

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

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

"Частые" операции стараются делать более короткими.

    П р и н ц и п   м о д у л ь н о с т и.  Под модулем в общем случае

понимают функциональный элемент рассматриваемой системы, имеющий офор-

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

средства сопряжения с подобными элементами или элементами более  высо-

кого уровня данной или другой системы.

    Способы обособления составных частей ПО в отдельные  модули  могут

быть существенно различными. Чаще всего разделение происходит по  фун-

кциональному признаку. В значительной степени  разделение  системы  на

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

    П р и н ц и п   ф у н к ц и о н а л ь н о й   и з б и р а т е л ь-

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

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

рого существенно превосходит имеющийся объем оперативной памяти. В  ПО

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

быть в состоянии готовности для эффективной организации вычислительно-

го процесса. Эту часть в ПО называют ядром или монитором. При формиро-

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

требованиям. В состав монитора, помимо чисто управляющих модулей, дол-

жны войти наиболее часто используемые модули. Количество модулей  дол-

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

ком большим. Программы, входящие в состав монитора, постоянно  хранят-

ся в оперативной памяти. Остальные  части  ПО  постоянно  хранятся  во

внешних запоминающих устройствах и загружаются  в  оперативную  память

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

    П р и н ц и п   г е н е р и р у е м о с т и.   Основное  положение

этого принципа определяет такой способ исходного представления ПО, ко-

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

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

ля.

    П р и н ц и п   ф у н к ц и о н а л ь н о й   и з б ы т о ч н о с-

т и.  Этот принцип учитывает возможность проведения одной и той же ра-

боты различными средствами. Особенно важен  учет  этого  принципа  при

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

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

    П р и н ц и п   "п о   у м а л ч и в а н и ю". Применяется для об-

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

при работе с уже готововым ПО. Принцип основан на хранении  в  системе

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

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

    Эту информацию ПО использует в качестве заданной,  если  пользова-

тель забудет или сознательно не конкретизирует ее. В данном случае  ПО

само установит соответствующие значения.

                    2.5.2.Общесистемные принципы

    При создании и развитии ПO рекомендуется применять следующие обще-

системные принципы:

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

  нию, функционированию и развитию ПО определяются  со  стороны  более

  сложной, включающей его в себя системы;

- принцип системного единства, который состоит  в  том,  что  на  всех

  стадиях создания, функционирования и  развития  ПО  его  целостность

  будет   обеспечиваться   связями   между   подсистемами,   а   также

  функционированием подсистемы управления;

- принцип развития,  который  предусматривает  в  ПО  возможность  его

  наращивания и совершенствования компонентов и связей между ними;

- принцип комплексности, который заключается в том, что ПО обеспечива-

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

  для всего объема данных в целом на всех стадиях обработки;

- принцип информационного  единства,  то  есть  во  всех  подсистемах,

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

  символы, условные обозначения и способы представления;

- принцип совместимости, который состоит в  том,  что  язык,  символы,

  коды и средства обеспечения ПО согласованы, обеспечивают  совместное

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

  системы в целом;

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

  компоненты ПО  инвариантны  к  обрабатываемой  информации,  то  есть

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