Объектно-ориентированный подход. 
Программная инженерия. 
Визуальное моделирование программных систем

На основе структурного подхода сформировалась концепция объектно-ориентированного метода (программирования, анализа, проектирования, баз данных), — фактически целая философия разработки систем и представления знаний на базе мощного подхода [5]. Основное отличие объектно-ориентированного анализа и проектирования от структурного состоит в декомпозиции проблемы на понятия (объекты), а не на функции.

Исторически развитие этой области началось с объектноориентированного программирования. В 1980;90-х годах появились объектно-ориентированные методы разработки программного обеспечения, предложенные Г ради Бучем (Booch), Джеймсом Рамбо (ОМТ — Object Modeling Technique) и Айваром Якобсоном (OOSE — Object Oriented Software Engineering).

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

В течение 1994—1996 гг. упомянутые разработчики объединили свои усилия иод эгидой Rational Software Corporation для создания единого языка моделирования, который воплотил бы все существенные и успешные разработки в данной области и стал бы стандартом языка объектно-ориентированного моделирования.

Грандиозный труд, в котором наряду с Rational участвовали представители таких крупных компаний, как Microsoft, IBM, Hewlett-Packard, Oracle, Platinum Technology и нескольких сотен других, завершился созданием в январе 1997 года версии 1.0 унифицированного языка моделирования UML (Unified Modeling Language) [9].

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

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

Буч отметил также ряд преимуществ ООП.

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

По сути, все современные приложения являются объектноориентированными, а некоторые языки программирования (например, Java) предполагают использование объектноориентированных структур.

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

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

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

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

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

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

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

• • Управление проектом сложно осуществлять. Менеджеры измеряют степень продвижения разработки с помощью четко определенной декомпозиции работ, элементов комплекта поставки и ключевых этапов. При объектной разработке с помощью «детализации» не существует четких границ между этапами, а проектная документация непрерывно развивается. Приемлемое решение в такой ситуации заключается в делении проекта на небольшие модули и управлении ходом разработки за счет частого выпуска выполняемых версий этих модулей (некоторые из этих выпусков могут быть для внутреннего применения, а другие — поставляться заказчику).
• • Проблема использования объектного подхода связана с возрастающей сложностью решения, что, в свою очередь, сказывается на таких характеристиках программного обеспечения, как приспособленность к сопровождению и масштабируемость.

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

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

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