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

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

Фактически структурный подход поглощается объектно-ориентированным подходом.

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

При этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описы­вается в терминах обмена сообщениями между объекта­ми.

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

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

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

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

Например, описание класса "магазины" может включать:

- некоторые атрибуты, индивидуальные для каждого объекта этого класса — конкретного магазина: "название", "адрес", "штат сотрудников", "текущий счет";

- методы: "формирование заказов на поставку товаров", "передача товара со склада в торговую секцию" и т.д.

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

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

То, что объекты имеют способность наследовать характеристики (методы и данные) одного или более объектов, обеспечивает повторное использование программного кода. Это приводит к значительному уменьшению затрат на создание ПО, повышает эффективность ЖЦ ПО (сокращает длительность фазы разработки).

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

Известные объектно-ориентированные методологии:

- Rumbaugh (OMT) (Рамбо);

- Booch (Буч);

- Martin/Odell.

Они базируются на интегрированных (общих) моделях трех типов:

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

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

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

Главными недостатками объектно-ориентированных методологий является:

- отсутствие стандартизации для представления объектов и взаимосвязей между ними;

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

Для преодоления этих недостатков авторы известных методологий Буч (Booch), Рамбо (Rumbaugh) и Якобсон (Jacobson) объединились с целью выработки унифицированной методологии, получившей название UML (Unified Modeling Language).

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

В UML используются следующие ключевые диаграммы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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