2.4. Методологии программирования
Рассмотрим кратко перечисленные выше ядра методологий и их производные с учётом специфик. Подробное изложение этого материала можно найти в [1].
Методология императивного программирования
Методология императивного программирования– подход, характеризующийся принципом последовательного изменения состояния вычислителя пошаговым образом. При этом управление изменениями полностью определено и полностью контролируемо.
Происхождение.Это исторически первая поддерживаемая аппаратно методология. Она ориентирована на классическую фон-неймановскую модель, остававшуюся долгое время единственной аппаратной архитектурой, получившей широкое практическое применение.
Методы и концепции.Метод изменения состояний – заключается в последовательном изменении состояний. Метод поддерживается концепцией алгоритма. Метод управления потоком исполнения – заключается в пошаговом контроле управления. Метод поддерживается концепцией потока исполнения.
Вычислительная модель.Императивное программирование основано на описании последовательного изменения состояний вычислителя. В качестве математической модели императивное программирование использует машину Тьюринга – Поста – абстрактное вычислительное устройство, предложенное на заре компьютерной эры для описания алгоритмов.
Класс задач.Методология наиболее пригодна для решения задач, в которых последовательное исполнение каких-либо команд является естественным. Пример – управление современными аппаратными средствами. Поскольку практически все современные компьютеры императивны, эта методология позволяет порождать достаточно эффективный исполняемый код. С ростом сложности задачи императивные программы становятся всё менее и менее читаемыми. Программирование и отладка больших программ (например, компиляторов), написанных исключительно на основе данной методологии, может затянуться на долгие годы.
Методология объектно-ориентированного программирования
Методология объектно-ориентированного программирования– подход, использующий объектную декомпозицию, при которой статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы – в терминах обмена сообщениями между объектами. Этот подход можно рассматривать как дальнейшее развитие методологии структурного программирования на основе введения абстрактных структур данных и непосредственного представления объектов ПрО, удобного для их использования при программировании.
Происхождение.На возникновение объектного мышления оказали влияние моделирование и представление данных, графические пользовательские интерфейсы и системное программирование (с понятием «процесс»). Моделирование реальных систем потребовало естественного описания сущностей – объектов и событий. Позже оказалось, что концепции объектно-ориентированного программирования (ООП) являются достаточно полезным дополнением к традиционному структурному программированию.
Методы и концепции.Метод объектной декомпозиции – заключается в выделении объектов и связей между ними. Метод поддерживается концепциями инкапсуляции, наследования и полиморфизма. Метод абстрактных типов данных – метод, лежащий в основе инкапсуляции. Метод поддерживается концепцией абстрагирования. Метод пересылки сообщений – заключается в описании поведения системы в терминах обмена сообщениями между объектами. Метод поддерживается концепцией сообщения.
Вычислительная модель.Модель чистого ООП поддерживает явно только одну операцию – посылка сообщения объекту. Сообщения могут иметь параметры, являющиеся объектами. Само сообщение также является объектом.
Класс задач.Методология является мощным средством для моделирования отношений между объектами практически в любой ПрО. Особенно удобно и легко в объектах выразить взаимодействие между различными элементами графического интерфейса пользователя.
1.1. Методы программирования.
В основе того или иного языка программирования лежит некоторая руководящая идея, оказывающая существенное влияние на стиль соответствующих программ.
Структурное программирование
Структурное программирование — методология программирования, базирующаяся на системном подходе к анализу, проектированию и реализации программного обеспечения. Эта методология родилась в начале 70-х годов и оказалась настолько жизнеспособной, что и до сих пор является основной в большом количестве проектов.
Основу этой технологии составляют следующие положения:
Сложная задача разбивается на более мелкие, функционально лучше управляемые задачи. Каждая задача имеет один вход и один выход. управляющий поток программы состоит из совокупности элементарных подзадач с ясным функциональным назначением.
Простота управляющих структур, используемых в задаче. логически задача должна состоять из минимальной, функционально полной совокупности достаточно простых управляющих структур.
Разработка программы должна вестись поэтапно. На каждом этапе должно решаться ограниченное число четко поставленных задач с ясным пониманием их значения и роли в контексте всей задачи. Если такое понимание не достигается, это говорит о том, что данный этап слишком велик, и его нужно разделить на более элементарные шаги. Согласно требованиям структурного программирования, наиболее часто детально проработанные алгоритмы изображаются в виде блок-схемы. При их разработке используются условные обозначения согласно ГОСТу («следование», «ветвление», «цикл») (рис. 1).
Нисходящее проектирование
Метод предполагает последовательное разложение функции обработки данных на простые функциональные элементы («сверху вниз»). В результате строится иерархическая схема, которая отражает состав и взаимоподчиненность отдельных функций.
Она носит название функциональная структура алгоритма (ФСА) приложения, в которой отражаются:
цели предметной области (цель-подцель);
состав приложений (задач обработки), обеспечивающих реализацию поставленных целей;
характер взаимосвязи приложений с их основными характеристиками;
Рассмотрим функциональную структуру приложения (рис. 2).
Подобная структура отражает состав и взаимосвязь функций обработки информации для реализации приложений, не раскрывая логику выполнения каждой отдельной функции. Разложение должно носить строго функциональный характер, т.е. отдельный элемент ФСА описывает законченную содержательную функцию обработки информации, которая предполагает определенный способ реализации на программном уровне. Функции ввода/вывода информации отделяют от функций вычислительной или логической обработки данных. Для всех функций-компонентов осуществляется самостоятельная программная реализация, составные функции типа Ф1, ФМ реализуются как программные модули, управляющие функциями — компонентами, например, в виде программ-меню. По частоте использования функции делятся на однократно выполняемые и повторяющиеся.
Концепция модульного программирования
Так же как и для структурной технологии программирования, концепцию модульного программирования можно сформулировать в виде нескольких понятий и положений:
Функциональная декомпозиция задачи — разбиение большой задачи на ряд более мелких, функционально самостоятельных подзадач — модулей. Модули связаны между собой только по входным и выходным данным.
Модуль — основа концепции модульного программирования. Каждый модуль представляет собой «черный ящик» с одним входом и одним выходом. Модульный подход позволяет безболезненно производить модернизацию программы в процессе ее эксплуатации и облегчает ее сопровождение. Дополнительно модульный подход позволяет разрабатывать части программ одного проекта на разных языках программирования, после чего с помощью компоновочных средств объединять их в единый загрузочный модуль.
Реализуемые решения должны быть простыми и ясными. Если назначение модуля непонятно, то это говорит о том, что декомпозиция начальной или промежуточной задачи была проведена недостаточно качественно. В этом случае необходимо еще раз проанализировать задачу и, возможно, провести дополнительное разбиение на подзадачи. При наличии сложных мест в проекте их нужно подробнее документировать с помощью продуманной системы комментариев. Этот процесс нужно продолжать до тех пор, пока действительно не удастся добиться ясного понимания назначения всех модулей задачи и их оптимального сочетания.
Назначение всех переменных модуля должно быть описано с помощью комментариев по мере их определения.
Объектно-ориентированное программирование (ООП)
Идея ООП заключается в стремлении связать данные с обрабатывающими эти данные процедурами в единое целое — объект. ООП основано на трех важнейших принципах, придающих объектам новые свойства.
Этими принципами являются инкапсуляция, наследование и полиморфизм.
Инкапсуляция — объединение в единое целое данных и алгоритмов обработки этих данных. В рамках ООП данные называются полями объекта, а алгоритмы — объектными методами.
Наследование — свойство объектов порождать своих «потомков». Объект — «потомок» автоматически наследует от «родителей» все поля и методы, может дополнять объекты новыми полями и заменять (перекрывать) методы «родителя» или дополнять их.
Полиморфизм — свойство родственных объектов (т.е. объектов, имеющих одного общего «родителя») решать схожие по смыслу проблемы разными способами.
Представление о CASE — комплексах связано в нашем сознании с чем-то, не имеющим отношения к обычному программированию. Мощный толчок CASE-средства получили в пору внедрения объектно-ориентированной технологии разработки ПО, когда старого, проверенного временем метода проектирования «сверху вниз» стало явно недостаточно. Сегодня лидирующей в мире CASE-системой считается Rational Rose корпорации Rational Software. Система Rational Rose нацелена на создание модулей с использованием языка Unified Modeling Language (UML). Кстати, UML стал стандартным языком объектно-ориентированной разработки не без подачи Rational Software.
В компании Rational работают три создателя и евангелиста объектно-ориентированной разработки и языка UML. Это Гради Буч, Айвар Джекобсон и Джим Рамбаух. Последняя версия CASE-системы компании Rational Software Rational Rose 98 успешно применяется для создания коммерческого ПО и поддерживает популярные языки программирования Java, Си++, Смолток, Ада, Visual Basic, Power Builder и Forte. Разумеется, поддержка того или иного языка программирования зависит от того, о какой редакции пакета Rational Rose 98 идет речь.
Нельзя не отметить, что система Rose — признанный лидер среди средств визуального моделирования, и, используя ее, можно интерактивно разрабатывать архитектуру создаваемого приложения, генерировать его исходные тексты и параллельно работать над документированием разрабатываемой системы.
Преимущества от применения Rational Rose 98 значительны:
Сокращение цикла разработки приложения.
Увеличение продуктивности работы программистов.
Улучшение потребительских качеств создаваемых программ за счет ориентации на пользователей и бизнес.
Способность вести большие проекты и группы проектов.
Возможность повторного использования уже созданного ПО за счет упора на разбор их архитектуры и компонентов. Язык UML служит универсальным «мостиком» между разработчиками из разных отделов.