Объектно-ориентированный подход

Основные принципы

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

Представим себе систему, состоящую из семьи (отец, ребенок, мать) и квартиры (помещения, мебель, техника). Было бы логично выделить в этой системе следующие категории сущностей: человек, предмет мебели, прибор, помещение. Даже ребенок (человек) может включить телевизор (прибор), выбрать понравившийся ему канал, отрегулировать громкость. При этом вся внутренняя структура телевизора от него скрыта: все детали помещены в ящик, снаружи которого есть только органы управления и экран. Ясно, что для правильной работы телевизора состояние внутренних деталей не менее (а возможно даже более) важно, чем состояние ручки изменения громкости. Но мало кто обращает на это внимание: весь внутренний мир телевизора помещен в некоторую оболочку, содержимым которой ведает только телевизор. Так мы замечаем в окружающем мире то, что называется инкапсуляцией – один из основных принципов объектно-ориентированного подхода.

Инкапсуляция – это принцип, заключающийся в построении оболочки вокруг некоторого набора данных и кода, обрабатывающего эти данные.

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

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

Для описания следующего принципа, лежащего в основе ООП, надо определить, что такое класс.

Как уже говорилось, разрабатываемая система представляется в виде набора объектов. В частности, объектами являются "Телевизор Горизонт-ТЦ375И No. 1234567", "Телевизор Янтарь No. 7654321". В некоторый момент бывает удобно сослаться не на конкретный телевизор, а на все телевизоры, независимо от их конкретной модели, года выпуска и серийного номера. В этом случае нам поможет понятие класса.

Класс – это группа сущностей (объектов), обладающих сходными свойствами, а именно: данными и поведением.

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

Под поведением объекта понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта.

В нашем примере можно выделить следующие классы и их представителей:

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

Наследование – это отношение типа "является разновидностью". В контексте рассматриваемого примера можно сказать, что Электроприбор "является разновидностью" Прибора, а Телевизор "является разновидностью" Устройства Отображения. Фактически, мы говорим, что один класс является наследником другого, если класс имеет все те свойства, что и предок, плюс еще некоторые дополнительные.

В случае с приборами из нашего примера можно построить такую иерархию наследования:

Третий принцип, лежащий в основании ООП, – полиморфизм – касается аспектов определения поведения объектов классов и распространения поведения вдоль иерархии наследования от предков к потомкам.

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

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

Еще один принцип ООП – это модульность, и это означает, что вся система должна быть разделена на части, называемые модулями. Это деление более крупное, чем разбиение на классы – модули должны их в себе содержать.

8.2. UML – история, назначение, состав и структура

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

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

В середине 90-х годов стали появляться новые улучшенные версии существующих методологий - особо можно выделить технику Booch'93, дальнейшее развитие OMT, и Fusion. Эти методы начали смешивать техники друг друга, в результате появилось несколько широко известных методологий, включая OOSE, OMT-2 и Booch'93. Но, в целом, каждый из них обладал своей спецификой и оставался обособленным от других, при этом обладая определенной силой.

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

Многие компании - производители ПО, понимая сложившиеся проблемы, выступили в поддержку создания UML - единого стандарта ОО моделирования.

Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method. Позднее в конце 1995 года к Rational присоединился Ivar Jacobson со своей компанией Objectory, и в новую технику был добавлен метод OOSE (Object-Oriented Software Engineering). В июне 1996 года был выпущен UML 0.9, а в октябре - предложен UML 0.91. После этого начался сбор реакции компаний-производителей программного обеспечения на это предложение.

К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. Это объединение стало мощным катализатором для продолжения работы по унификации методов. Как результат объединенных усилий, после проведения многочисленных экспертиз и консультаций, в январе 1997 года был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. Каждый из партнеров по OMG внес различный вклад в проект. Например, Hewlett-Packard обеспечивал связь между моделями UML и концепцией повторного использования, IBM разрабатывал язык OCL (Object Constraint Language), описывающий семантику языка, Microsoft развивал концепцию компонентного программирования и использования UML в репозитории, Oracle расширил рамки UML для моделирования бизнеса. Список велик, ведь каждая компания преследовала свои определенные цели, но соотнося их с общими пожеланиями. В результате в выигрыше остался каждый из участников проекта.

UML прошел долгий путь от разобщенных методов и техник, преодолев первые попытки унификации, всеобщего обсуждения и оценки, в настоящее время претендуя на роль промышленного стандарта моделирования. В ноябре 1997 года OMG приняла UML как основную спецификацию для OMA (Object Modeling Architecture), "предоставляя разработчикам, работающим с любыми программными языками и на любых платформах, общий язык моделирования для построения распределенных приложений, внося необходимую согласованность в развитие этой сложной дисциплины" (Ричард Соли, председатель и исполнительный директор OMG).

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

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

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

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

· Обеспечить независимость от языка программирования и модели процесса - UML должен поддерживать все разумные языки программирования и модели процесса разработки ПО, принятой на конкретном предприятии.

· Дать формальное обоснование языка моделирования - формализация языка должна присутствовать, но в разумных пределах, чтобы не мешать легкости восприятия и простоте применения.

· Расширить рынок ОО инструментов - UML должен обеспечивать интероперабельность для объектно-ориентированных средств.

· Использовать наилучшие практические методы - UML собирает лучшее, что есть в мире средств моделирования, и интегрирует.

Унифицированный Язык Моделирования (Unified Modeling Language - UML) предназначен для спецификации, визуализации, конструирования и документирования отчуждаемых материалов существенно программных систем.

Прежде всего, UML наследует техники Booch, OMT и OOSE.

Во-вторых, перекрывает их.

В-третьих, надо отметить, что UML - это стандарт языка, а не стандарт процесса.

UML - квинтэссенция концепций моделирования, по которым был достигнут консенсус в среде ведущих мировых компаний-разработчиков ОО программного обеспечения, а именно:

· Соглашение о семантике и нотациях для разнообразных аспектов современного моделирования в лаконичной форме;

· Определение достаточной семантики для ожидаемых новых технологий: компонентное программирование, распределенные вычисления и т.д.;

· Реализация механизма расширения для наращивания будущих методов моделирования поверх UML;

· Определение достаточной семантики для организации репозитория моделей.

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

UML - это стандарт языка моделирования, а не методология моделирования. Чтобы ясно представлять себе это, рассмотрим те вопросы, которые лежат вне предметной области UML:

· Языки программирования - UML - язык визуального моделирования и не предназначен для визуального программирования, хотя инструментальное средство, поддерживающее нотации UML, может реализовывать кодогенерацию на основе построенных моделей.

· Инструментальные средства - UML не является спецификацией для разработки инструментального средства. В UML определена только модель семантики, но не определены модели интерфейса, хранения и поддержки времени выполнения. В настоящее время имеется целый ряд инструментальных средств, производители которых заявляют о поддержке UML - среди них можно выделить: Rational Rose, Select Enterprise, Platinum и Visual Modeler.

· Модель процесса - предприятия используют UML как единый язык при разработке всех компонентов проекта, но процесс разработки может быть реализован по-разному. Хотя наблюдается сходимость моделей процессов для разных организаций, но общего соглашения по данному вопросу не найдено. UML не навязывает свою модель процесса, но при разработке языка авторы имели в виду процесс, обладающий следующими свойствами: управляемый прецедентами, итеративный и инкрементальный.

Рассмотрим структуру языка с точки зрения компонент, составляющих его описание. Определение UML, является самодостаточным и включает в себя следующие документы: Семантика UML, Нотация UML, Спецификации языка OCL (Object Constraint Language) и Расширение UML.

Семантика UML

Описание семантики UML происходит на уровне метамодели и представляется тремя согласованными способами:

Абстрактный синтаксис - метамодель UML разбита на 9 взаимосвязанных пакетов, каждый из которых описывается диаграммами классов UML. Метамодель вмещает в себя около 50 классов, более 100 ассоциаций и 1000 ограничений.

Правила состоятельности - правила описываются английской прозой и с использованием языка ограничений OCL, объектно-ориентированного языка с равенством и ограниченными кванторами.

Описание элементов моделирования (семантика) - выполнено в английской прозе.

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

Определяемые пользователем расширения UML возможны благодаря наличию следующих встроенных в язык механизмов:

Стереотипы - позволяют определить подклассы существующих элементов моделирования, сохраняя форму, но вкладывая новое содержание и добавляя новые свойства;

Тэгированные значения - позволяют определять новые свойства элементов моделирования, что дает возможность привязать модели совершенно произвольную информацию;

Ограничения - позволяет определить подмножество элементов моделирования, наделенное определенными свойствами (например, упорядоченность). Могут быть описаны с помощью OCL.