Прикладные и теоретические методы программирования

5.1.2. Объектно-ориентированный метод

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

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

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

Под процессом в ООП понимается проектирование классов объектов и взаимоотношений между ними (рис. 5.3).

Рис. 5.3. ЖЦ разработки ПС в среде ООП

Процесс разработки включает в себя следующие этапы:

• анализ – создание объектной модели (ОМ) ПрО, в которой объекты отражают реальные ее сущности и операции над ними;
• проектирование – уточнение ОМ с учетом описания требований для реализации – реализация ОМ средствами языков программирования С++, Java и др.
• сопровождение – конкретных задач системы;
• программирование использование и развитие системы, внесение изменений, как в состав объектов, так и в методы их реализации;
• модификация ПС – изменение системы в процессе ее сопро-вождения путем добавления новых функциональных возможностей, интерфейсов и операций.

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

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

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

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

Существует два типа моделей системной архитектуры:

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

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

5.1.3. UML-метод моделирования

UML (United Modeling Language) - унифицированный язык моделирования является результатом совместной разработки специалистов программной инженерии и инженерии требований [5.6, 5.7]. Он широко используется ведущими разработчиками ПО как метод моделирования на этапах ЖЦ разработки ПС.

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

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

Модель требований в UML - это совокупность диаграмм, которые визуализируют основные элементы структуры системы.

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

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

Атрибутами могут быть типы значений в UML:

• public (общий) обозначает операцию класса, вызываемую из любой части программы любым объектом системы;
• protected (защищенный) обозначает операцию, вызванную объектом того класса, в котором она определена или наследована,
• private (частный) обозначает операцию, вызванную только объектом того класса, в котором она определена.

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

Классы могут находиться в следующих отношениях или связях.

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

Зависимость между классами, при которой класс-клиент может использовать определенную операцию другого класса; классы могут быть связаны отношением трассирования, если один класс трансформируется в другой в результате выполнения определенного процесса ЖЦ.

Экземпляризация - зависимость между параметризированным абстрактным классом-шаблоном (template) и реальным классом, который инициирует параметры шаблона (например, контейнерные классы языка С++).

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

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

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

Диаграмма деятельности задает поведение системы в виде определенных работ, которые может выполнять система или актер, виды работ могут зависеть от принятия решений в зависимости от заданных условий или ограничений. В качестве примера использования диаграммы деятельности UML приведена структура программы "Оплатить услуги" (рис. 5.4). Данная диаграмма демонстрирует программу расчета и оплаты услуг. В ней выполняется ряд последовательных действий по расчету стоимости за услуги.

Рис. 5.4. Диаграмма программы расчета и оплаты услуг

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

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

Диаграмма реализации состоит из диаграммы компонента и размещения.

Построение ПС методом UML состоит в выполнении этапов ЖЦ, приведенных на общей схема реализации ПрО (рис. 5.5).

увеличить изображение
Рис. 5.5. Схема моделирования и проектирования ПС в UML

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

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