- •История развития программных технологий.
- •Жизнь реального мира и его отражения.
- •Информация и знаковые системы.
- •Абстракция знаковой системы.
- •Трудности определения знака.
- •Класс объекта и его экземпляры.
- •Класс субъекта и его деятельность.
- •Собственная жизнь знаков.
- •Рефлексивность развития культуры.
- •Абстрактная вычислительная машина.
- •Парадигмы современного программирования.
- •Рефлексия программного обеспечения.
- •Инструментальные средства программирования.
- •Типовая среда программирования.
- •Структурное программирование.
- •Управляющие структуры.
- •Наследие структурного программирования.
- •Иерархия представлений.
- •Нисходящее и восходящее проектирование.
- •Динамика нарастания детализации.
Типовая среда программирования.
«Упражнение дает больше, чем хорошее природное дарование».
Протагор из Абдеры, ок 480-410 гг.до н.э.
Типовая среда программирования на языке С++ состоит из многих частей, как это показано на Рис.2.4.4. Условно их можно разбить на два класса: индивидуальные инструментальные средства разоработки программ и коллективные. Первые хорошо известны, это: язык, редактор, различные библиотеки, компилятор, компоновщик, загрузчик, отладчик и т.п. Это относительно независимая от технологии программирования часть инструментальных средств. Значительно более серьёзно связана с технологией разработки программного обеспечения корпоративная часть среды программирования. Она непосредственно включает в себя средства системного анализа и проектирования больших задач, поддержки их маршрута разработки и тестирования, управления архитектурой программного комплекса, сопровождения версий и многое другое.
Структурное программирование.
«Не делать никаких уступок жизни есть признак безрассудства».
Демокрит, ок 470-370 гг.до н.э.
К 70-м годам ХХ века был накоплен серьёзный опыт ошибок и проваленных программных проектов. Был сформулирован и принцип Дейкстры, требующий глубокого понимания логической сущности задачи для создания эффективных программных решений. Но для больших систем он оказался неприменим – слишком высокой оказалась их логическая сложность. Но усилия по функциональной систематизации алгоритмов и соответствующей организации текстов программ оказались не напрасны – появился язык «Паскаль». Он изначальной был ориентирован на программирование без оператора «goto» и наследовал лучшие традиции «Алгола».
Прежде всего было осознано, что не все операционные возможности надо предоставлять программистам, а свободу использования предоставленных им желательно иногда разумно ограничивать. Например ЭВМ «Наири-2», на которой автору пришлось делать лабораторные работы, допускала модификацию данных-команд в процессе работы приложения, что является грубейшим нарушением всех системных принципов (но крайне выразительным приемом). Автор языка «Паскаль» Н.Вирт был лаконичен в своей формуле:
«Программа = Данные + Алгоритмы».
Очередной виток рефлексии «программирования процесса программирования» завершился разделением информационной и исполнительной части программ, определяя между ними интерфейс на основе допустимых терминов для отображения алгоритмов:
данные, над которыми выполняются операции;
операции, которые должны выполняться;
последовательность выполнения операций.
Со стороны языков структурного программирования были ограничены управляющие структуры, предоставляемые программисту. В обязательном порядке использовалась иерархическая функциональная вложенность модулей конструкций языка, как основной архитектурный прием.
Управляющие структуры.
«Если перейти меру, то всякое приятное становится неприятным».
Демокрит, ок 470-370 гг.до н.э.
Будучи выдающимся достижением на пути самоозознания программистами своего занятия, невозможно представить развитие языков императивного типа без идей структурного программирования. Так как с самого начала С был языком структурного программирования, то любая форма управления в языкеС (и С++)выражается в терминах:
следование;
структура if(выбор);
структура while(повторение).
Но и этого оказалось недостаточно для преодоления новых рубежей сложности. Проблемы только начинались, т.к. надо было создавать программные системы, которые даже на концептуальном уровне невозможно было осознать одному человеку (например, главному хирургу в методе хирургической бригады). А как в такой ситуации управлять и контролировать ход работ? О качестве производимого продукта можно уже и не говорить...