Обьектно- ориентированное проектирование Составитель Шаповалова С.В.

Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) -технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.

Методология ООАП связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE) Модель системы - совокупность взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы Процесс ООАП - последовательный переход от разработки наиболее общих моделей концептуального уровня к более частным и детальным представлениям логического и физического уровня

На каждом этапе ООАП данные модели последовательно дополняются все большим количеством деталей, что позволяет им более адекватно отражать различные аспекты конкретной реализации сложной системы. Процесс обработки информации – последовательность взаимодействия объектов Результат ООП – множество классов объектов с присоединенными методами обработки атрибутов Для объектно-ориентированного моделирования проблемной области используется унифицированный язык моделирования UML (Unified Modeling Language)

UML разработан в 1996г. группой ведущих компьютерных фирм мира OMG (Object Management Group) и фактически является стандартом по объектно-ориентированным технологиям В состав OMG - Digital Equipment Corp., HP, i- Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys Cтатус языка UML определен как открытый для всех предложений по доработке и совершенствованию. UML не является чьей-либо собственностью и не запатентован кем-либо, аббревиатура UML является торговой маркой

На рынке CASE-средств представлены десятки программных инструментов, поддерживающих нотацию языка UML , обеспечивающих прямую и обратную генерацию кода программ для наиболее распространенных языков и сред программирования (MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk) UML – используется во многих RAD-средcтвах, в CASE-средствах визуального и имитационного моделирования. UML - основа объектно-ориентированного моделирования систем, документирования бизнес-процессов, для представления знаний в интеллектуальных системах

Rational Rose (Rational) Natural Engineering Workbench (Software AG) ARIS Toolset (IDS prof. Scheer) и др. CASE-средства, использующие UML

Диаграммы UML 1.Диаграмма прецедентов использования (Use-case diagram) 2.Диаграмма классов объектов (Class diagram) 3.Диаграммы состояний (Statechart diagram) 4.Диаграммы взаимодействия объектов (Interaction diagram)

5.Диаграммы деятельностей (Activity diagram) 6.Диаграммы пакетов (Package diagram) 7.Диаграмма компонентов (Component diagram) 8.Диаграмма размещения (Deployment diagram)

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

Элементы диаграммы Актер – внешний пользователь процесса Прецедент использования (бизнес процесс)

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

Диаграмма прецедентов использования

В реализации прецедента использования можно выделить несколько потоков событий: 1.основной поток событий, который приводит к нужному результату наиболее коротким путем 2.альтернативные потоки событий В диаграмме описываются основные и альтернативные потоки событий

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

Некоторые прецеденты использования могут быть расширены деталями. Тогда создается дополнительный прецедент использования, с которым устанавливаются отношения расширения (extends)

Диаграммы классов объектов Class diagram отражают статическую структуру классов объектов Рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов Классы объектов могут иметь различные стереотипы поведения: объекты-сущности, управляющие объекты, интерфейсные объекты

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

К статическим отношениям относятся: обобщение, агрегация, ассоциация объектов Зависимость - отношение использования, согласно которому изменение в спецификации одного элемента (например, класса «товар») может повлиять на использующий его элемент (класс «строка заказа»). Часто зависимости показывают, что один класс использует другой в качестве аргумента 0…1 *

Отображение связей между классами

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

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

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

Состояние можно описать набором значений атрибутов и отношений, связанных с объектом Имя состояния уникально внутри своего класса объекта С каждым состоянием связано одно событие или более, которые могут его изменить Для состояния задаются имена всех связанных с ним переходов в другие состояния Переход состояний – изменение в состоянии объекта, которое вызывается событием Каждый переход состояния должен иметь уникальное имя

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

Пример диаграммы перехода состояний

Диаграмма взаимодействия объектов Для каждого прецедента использования может быть построена модель динамического взаимодействия объектов в форме: 1.диаграммы последовательностей (sequence diagram), показывающей последовательность взаимодействий на графе 2.кооперативной диаграммы (collaboration diagram), показывающей взаимодействие объектов в табличной форме

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

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

Диаграмма кооперативного поведения

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

Компоненты диаграммы

Диаграмма деятельности

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

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

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

Обеспечивающая часть ЭИС разбивается на пять пакетов: «Интерфейс» – взаимодействие пользователей с ЭИС по вводу-выводу информации, обмен сообщениями между подсистемами «База данных» – доступ к данным во внешней памяти «Управление задачами» – диспетчеризация и маршрутизация обработки объектов «Утилиты» – вспомогательные функции, например преобразование форматов данных Обеспечивающие пакеты – выполняют серверные функции для функциональных объектов-клиентов

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

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

Диаграмма компонентов

В модели размещения отображается топология расположения компонентов по узлам вычислительной сети Отдельный компонент всегда расположен на одном компьютере- сервере На одном компьютере- сервере может располагаться несколько компонентов интерфейсный объект

Технология объектно- ориентированного проектирования

Проектирование ЭИС на основе использования объектно-ориентированной CASE-технологии, основано на последовательном расширении и уточнении моделей на различных стадиях жизненного цикла ЭИС: –анализа системных требований, –логического проектирования, –физического проектирования, –реализации. (Обобщение методологий Objectory и Natural Engineering Workbench )

Анализ системных требований к ЭИС

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

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

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

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

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

Логическое проектирование ЭИС На данном этапе осуществляются детализация: моделей прецедентов использования, классов объектов, состояний, пакетов и разработка моделей, взаимодействия объектов деятельностей, определяется характер методов (процедур) обработки объектов

Логическое проектирование

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

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

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

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

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

Физическое проектирование ЭИС На этапе физического проектирования происходит детализация диаграмм классов объектов и пакетов с позиции их реализации в конкретной программно-технической среде.

Технология физического проектирования

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

Реализация ЭИС На этапе реализации ЭИС осуществляются: кодогенерация классов объектов, –программирование процедур методов классов объектов, –наполнение баз данных, –размещение компонентов по узлам вычислительной сети.

Технология реализации ЭИС

Генерация классов объектов в конкретной объектно- ориентированной программной среде (C++, Visual Basic, Pascal и т.д.), осуществляется на основе диаграммы классов объектов. Генерация шаблонов процедур методов класса объектов в конкретной объектно-ориентированной программной среде (C++, Visual Basic, Pascal и т.д.), производится на основе диаграммы взаимодействий объектов. Программирование процедур методов класса объектов с помощью объектно-ориентированного языка программирования выполняется на основе шаблонов процедур методов классов объектов по спецификациям диаграммы взаимодействий, диаграмм деятельностей и состояний объектов.

Литература Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», 2002