Методология объектно-ориентированного программирования

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

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

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

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

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

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

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

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

Для иллюстрации принципа наследования можно привести следующий пример. Рассмотрим в качестве общего класс «Автомобиль». Данный класс определяется как некоторая абстракция свойств и поведения всех реально существующих автомобилей. При этом свойствами класса «Автомобиль» могут быть такие общие свойства, как наличие двигателя, трансмиссии, колес, рулевого управления. Если в качестве производного класса рассмотреть класс «Легковой автомобиль», то все выделенные выше свойства будут присущи и этому классу. Можно сказать, что класс «Легковой автомобиль» наследует свойства родительского класса «Автомобиль». Однако, кроме перечисленных свойств, класс-потомок будет содержать дополнительные свойства, например такое, как наличие салона с количеством посадочных мест 2-5.

В свою очередь, класс «Легковой автомобиль» способен порождать другие подклассы, которые вполне могут соответствовать, например, моделям конкретных фирм-производителей. Таким образом, можно рассматривать класс «Легковой автомобиль производства ВАЗ». Поскольку Волжский автомобильный завод выпускает несколько моделей автомобилей, одним из производных классов для предыдущего класса может быть конкретная модель автомобиля, например, ВАЗ-21083. Наконец, изготовленный автомобиль имеет уникальный заводской номер, отличающий один автомобиль от другого. Таким номером может быть, например, XTA-210830S1594301. В последнем случае класс будет состоять из единственного объекта или экземпляра, которым будет являться легковой автомобиль производства ВАЗ с указанным выше заводским номером.

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

Появление объектно-ориентированных языков программирования было связано с необходимостью реализации концепции классов и объектов на синтаксическом уровне. С точки зрения ООП класс является дальнейшим расширением структуры (structure) или записи (record). Включение в известные языки программирования С и Pascal классов и некоторых других возможностей привело к появлению соответственно C++ и Object Pascal, которые на сегодня являются наиболее распространенными языками разработки приложений. Распространению C++ и Object Pascal способствовало то обстоятельство, что язык C++ был выбран в качестве базового для программного инструментария MS Visual C++, а язык Object Pascal– для популярного средства быстрой разработки приложений Borland/Inprise Delphi.

Рис. 2 Иерархия вложенности классов для класса «Автомобиль»

За короткий период времени оба инструментария превратились в мощные системы разработки программ с соответствующими библиотеками стандартных классов, содержащих сотни различных свойств и методов. Применительно к среде MS Visual C++ 5/6 такая библиотека имеет специальное название – MFC (Microsoft Foundation Classes), т. е. фундаментальные классы от Microsoft. При этом производные классы наследуют свойства и методы родительских классов.

Процесс разработки программ в среде Borland/Inprise Delphi также тесно связан с использованием библиотеки стандартных классов – VCL (Visual Component Library) или библиотеки визуальных компонентов. Эта библиотека тоже построена по иерархическому принципу, в соответствии с которым компоненты нижележащих уровней наследуют свойства и методы вышележащих компонентов.

Графически изображения классов можно представить совокупностью вложенных либо связанных прямоугольников.

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

Если продолжить рассмотрение примера с классом «Легковой автомобиль», то нетрудно проиллюстрировать инкапсуляцию следующим образом. Основным субъектом, который взаимодействует с этим классом, является водитель. Вполне очевидно, что не каждый водитель в совершенстве знает внутреннее устройство легкового автомобиля. Более того, отдельные детали этого устройства сознательно скрыты в корпусе двигателя или в коробке передач. А в случае нарушения работы автомобиля, являющейся причиной неадекватности его поведения, необходимый ремонт выполняет профессиональный механик.

Инкапсуляция ведет свое происхождение от деления модулей в некоторых языках программирования на две части или секции: интерфейс и реализацию. При этом в интерфейсной секции модуля описываются все объявления функций и процедур, а возможно и типов данных, доступных за пределами данного модуля. Другими словами, указанные процедуры и функции являются способами оказания услуг внешним клиентам. В другой секции модуля, называемой реализацией, содержится программный код, который определяет конкретные способы реализаций объявленных в интерфейсной части процедур и функций.

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

Рис. 3 Иллюстрация сокрытия внутренних

деталей структуры классов

Третьим принципом ООП является полиморфизм. Под полиморфизмом (греч. Poly– много, morfos – форма) понимают свойство некоторых объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов относится тот или иной метод.

Рассмотрим, например, три объекта или класса: двигатель автомобиля, электрический свет в комнате и персональный компьютер. Для каждого из них можно определить операцию «выключить». Однако сущность этой операции будет отличаться для каждого из рассмотренных объектов. Так для двигателя автомобиля вызов метода двигатель_автомобиля выключить означает прекращение подачи топлива и его остановку. Вызов метода комната электрический_свет выключить означает простой щелчок выключателя, после чего комната погрузится в темноту. В последнем случае действие персональный_компьютер выключить может быть причиной потери данных, если выключение выполняется нерегламентированным образом.

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

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

Широкое распространение методологии ООП оказало влияние на процесс разработки программ. В частности, процедурно-ориентированная декомпозиция программ уступила место объектно-ориентированной декомпозиции, при которой отдельными структурными единицами программы стали являться не процедуры и функции, а классы и объекты с соответствующими свойствами и методами. Как следствие, программа перестала быть последовательностью предопределенных на этапе кодирования действий, а стала событийно-управляемой. Последнее обстоятельство стало доминирующим при разработке широкого круга современных приложений. В этом случае каждая программа представляет собой бесконечный цикл ожидания некоторых заранее определенных событий. Инициаторами событий могут быть другие программы или пользователи. При наступлении отдельного события, например, нажатия клавиши на клавиатуре или щелчка кнопкой мыши, программа выходит из состояния ожидания и реагирует на это событие вполне адекватным образом. Реакция программы при этом тоже связывается с последующими событиями.

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

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

 

Литература

1.1 Буч Г., Рамбо Дж., Джекобсон А. Классика CS. 2-е изд. – СПб.: Питер, 2006. – 736 с.

1.2 Леоненков А.В. Самоучитель UML. 2-е изд. перераб. и доп. – СПб.: БХВ-Петербург, 2004. 432 с.

1.3 Грехем И. Объектно-ориентированные методы. Принципы и практика. Пер. с англ. _ М.: Вильямс, 2004. – 880 с.

 

Лекция 2

Методологии моделирования и проектированиЯ информационных систем

 

1 Методология объективно-ориентированного анализа и проектирования

2 Методология системного анализа и системного моделирования