1.3. Спецификация программ

Спецификация модуля включает в себя:

Проектирование:

1. описание функции модуля;

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

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

Планирование:

1. распределение работы между группой исполнителей;

2. определение очередности реализации;

3. определение способа отладки и способа проверки достоверности результатов.

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

Этап реализации:

1) написание модуля;

2) отладка;

3) документирование (в соответствии с ЕСПД – единой системой проектной документации);

4) сдача конечного продукта.

1.4. Метод пошаговой детализации

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

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

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

Правила пошаговой детализации

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

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

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

2. Предыстория объектно-ориентированного программирования

Объединение данных с алгоритмами является естественным для образа мышления человека. Кроме того, объединение такого рода конгломератов по некоторым признакам в классы является не только следствием привычного образа мышления, но и удобным средством для декомпозиции и упрощения структуры программ. Сначала следует выяснить, какие принципы необходимы (и достаточны) для практического применения таких объединений в программировании.

Довольно давно, практически сразу после появления языков третьего поколения (в 1967 году), некоторые исследователи решили несколько преобразовать постулат фон Неймана о том, что данные и программы неразличимы в памяти машины: пусть данные и программы если не станут одним и тем же, то сильно к этому приблизятся. Разрабатывая систему моделирования сложной системы, они столкнулись с задачей, решение которой без декомпозиции оказалось невозможным. Попытки обосновать декомпозицию и привели к уже полученным нами выводам. Недостатком можно считать чрезмерную «размытость» подхода, его объяснение скорее на уровне понимания и интуиции, чем на уровне правил [1]. Наконец, усилия многих программистов и системных аналитиков, направленные на формализацию подхода, увенчались успехом.

Были разработаны три основополагающих принципа того, что потом стало называться объектно-ориентированным программированием (ООП): наследование, инкапсуляция, полиморфизм.

Результатом их первого применения стал язык Simula-1, в котором был введен новый тип - объект. В описании этого типа одновременно указывались данные (поля) и процедуры, их обрабатывающие, - методы. Родственные объекты объединялись в классы, описания которых оформлялись в виде блоков программы. При этом класс можно использовать в качестве префикса к другим классам, которые становятся в этом случае подклассами первого. Впоследствии Simula-1 был обобщен и появился первый универсальный объектно-ориентированный язык программирования Simula-67 (67 - по году создания).

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

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

Разберем три принципа, которые стали почти достаточными для реализации концепции ООП. Предварительно введем определения слов объект и класс.

Объект - совокупность (разнотипных) данных (полей объекта), физически находящихся в памяти ЦВМ, и алгоритмов, имеющих доступ к ним.

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

Класс - тип (описание структуры данных и операций над ними), предназначенный для описания множества объектов.

Каждый класс может иметь подклассы - классы, обладающие всеми или частью его свойств, а также собственными свойствами. Класс, не имеющий ни одного представителя (объекта) обычно называют абстрактным.