Файл: Анализ методов современного программирования.pdf

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

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

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

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

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

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

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

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

Инструменты. Rational Rose - средство визуального моделирования ОО ПС. Rose является CASE- средством, графические возможности которого основаны на использовании UML и позволяют проектировать разные виды диаграмм с заданием всех свойств, отношений и взаимодействий. Средства системы обеспечивают проектирование и моделирование общей модели процессов (абстрактной) предприятия до конкретной (физической) модели классов создаваемой ПС. Допускается прямое и обратное проектирование, т.е. доработка старой системы. Результатом моделирования является визуальная логическая модель системы, которая дополняется моделями конкретных классов на ЯП.

В рамках Rational Rose поставляются Rose DataModeler для проектирования системы и баз данных, Rational Rose Professional для прямого и обратного проектирования шаблонов системы на ЯП, Rose Enterprise для проектирования предприятия и др.

2.5 Компонентное программирование

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

Информационная часть содержит описание: назначение, дата изготовления, условие применения (ОС, платформа и т.п.), возможность ПИК, среды окружения и др.

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

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

Внутренняя часть - это программный фрагмент кода, кластер, системная или абстрактная структура,

представленные в виде проекта компонента, спецификации, выходного кода и др. Данная часть компонента включает:

• интерфейс (interface),
• реализацию (implementation),
• схемы развертки (deployments).

Интерфейс отображает способ обращения к другим компонентам с помощью средств языков IDL или APL. В нем указываются типы данных и операции передачи параметров для взаимодействия компонентов друг с другом. Каждый компонент может реализовывать определенную совокупность интерфейсов.

Реализация - это код, который будет выполняться на компьютере с использованием заданных интерфейсов. Компонент может иметь несколько реализаций в зависимости от ОС, модели данных и соответствующей системы управления БД.

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

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

Компонент может быть представлен разными структурами.

Контейнер - структура, в которой заданы функции, порядок их выполнения, вызываемые события, сервис, интерфейс, необходимый для обращения к провайдеру сервиса.

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

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

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

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

Композиция компонентов из каркасов включает следующие типы:

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

ПИК - это готовые компоненты, которые используются в других ПС [15], они упрощают и сокращают сроки разработки новых ПС благодаря:

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

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

Инструменты. Примером инструментария по разработке ПС из ПИК является система RSEB [17]. В ней реализован метод, основанный на нотации UML, объектно-ориентированном методе и использовании ПИК многократного применения. Построение разных ПС проводится с использованием элементов Use Case. Компонент в RSEB — это тип, класс или любое другое программное средство (например, Use Case анализа, проектирования или реализации), разработка которого осуществляется с учетом его многократного применения. Компонентная система в RSEB рассматривается как ПС, содержащая ряд ПИК и повторно используемых нефункциональных характеристик. В качестве примера компонентной системы можно привести повторно используемые каркасы графических пользовательских интерфейсов и математические библиотеки [18]. Практически компонентная система позволяет производить другие прикладные системы, если в ней выделены родовые подсистемы с многократно используемыми решениями. Инженерия предметной области в системе RSEB состоит из двух процессов конструирования:

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

Система OOram также обеспечивает поддержку инженерии разработки ПС с помощью ПИК на основе следующих процессов [19]: создание модели, например ролевой, ее синтез и разработку спецификации объектов; процесс разработки системы в соответствии с ЖЦ, начиная с формулирования требований и заканчивая введением в действие ПС; процесс производства ПС из набора компонентов многократного применения в соответствии с этапами: анализ рынка, разработка и упаковка продукта, маркетинг ПИК и др.

2.6 Аспектно-ориентированное программирование (АОП)

Возможности. АОП базируется на методах ООП разбиения задач ПрО на ряд функциональных компонентов, а также на аспектах (синхронизации, взаимодействия, защиты и др.), которые встраиваются в отдельные компоненты как некоторые их реализации и влияют на композицию компонентов [10]. В качестве аспекта может быть некоторая идея, которая интересует нескольких заинтересованных лиц и представляется в виде варианта использования, функции, как обязательный элемент компонента или программы. Некоторые аспекты могут действовать на протяжении ЖЦ процесса разработки, они кодируются, тестируются и упрощают результат разработки. Как правило, создание продукта связано с выполнением разных ролей в процессе разработки, которые могут выполнять агенты с такими функциями: определение архитектуры, управление проектом, повышение качества и продуктивности разработки ПС.

Так как современные языки программирования не позволяют инкапсулировать аспекты в проектные решения системы, то в некоторые инструментальные компонентные системы введен механизм фильтрации входных сообщений, с помощью которых выполняется изменение параметров и имен текстов аспектов в конкретном компоненте. «Нечистый» код компонента (код с пересекаемыми его аспектами) требует разработки новых подходов к композиции компонентов, ориентированных на ПрО и на выполнение ее функций [15].

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