UML выполняет моделирование объектно-ориентированных распределенных систем (частичный перевод)

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

1. Элементы каркаса.

Архитектура каркаса состоит из четырех основных элементов:

- Метод декомпозиции

- UML основал методы выполнения моделирования,

- Методология выполнения моделирования,

- Объектно-ориентированные средства выполнения моделирования и анализа.

Элементы и их связь проиллюстрированы на Рисунке 1. Метод декомпозиции (МОД) обеспечивает основание для каркаса. Это определяет алгоритм для обнаружения приближенного решения при выполнении моделей. Ключевые характеристики алгоритма МОД следующие:

- Поддержка открытых, закрытых, и смешанных нагрузок,

- Поддержка одновременных владений ресурсом, которые возникают, например, с синхронных вызовов операции в системах, построенных на основе CORBA,

- Поддержка циклического вызова зависимости, как например, возникающего с интерфейсов возврата,

- Поддержка рекурсивных доступов, которые происходят, когда объекты вызывают сами себя, и

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

Алгоритм представлен в [1]. Сам МОД, тем не менее, не может быть использован для моделирования больших CORBA-основанных распределенных систем, это обуславливается низким уровнем смоделированной системы. Даже простая прикладная конфигурация уровня вливается в комплексную модель исполнения, поскольку все технические ресурсы (напр. сетевые адаптеры и сетевое время ожидания) смешаны с ресурсами приложений.

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

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

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

- Преобразование UML моделей в разрешимый формат, который требовался в алгоритме МОД,

- Реализация МОД - алгоритма, чтобы производить приближенное решение для модели, и

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

На Рисунке 1 эти задачи описывают шаги 3, 4, и 5.

2. Четыре модели представления

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

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

Представление PML обеспечивает точную текстовую нотацию чтобы представлять взаимосвязь элементов на диаграммах UML. Представление PML имеет ту же многоуровневую структуру что и представление UML, и распределение от UML до PML просто. Цель этого представления в том, чтобы фильтровать те характеристики, которые не имеют значение для моделирования, как например, графические изменения UML и чисто функциональные части модели UML. Однако представление PML имеет важную роль в разработке каркаса - к настоящему времени входной формат для реализации прототипа средства моделирования и анализа. Тем не менее, использование PML не обязательное, и любое другое представление представления человека UML могло бы использоваться взамен. Например, мы можем позже оптимизировать для человеческо-пригодной текстовой нотации UML, которая к настоящему времени называется OMG [3]. Для целей изучать каркас моделирования, тем не менее, PML подход достаточный. Последующие улучшения могут быть осуществлены как стандарты, которые интегрируются в коммерчески доступные средства. Абстрактный синтаксис для нотации PML приведен в Приложении A.

Представление AQN описывает систему в форме расширенной организации очереди сетей, которая может содержать одновременное владение ресурсом. Это представление допускает использование алгоритма МОД для решения модели. Представление AQN получено из представления PML расширяя объектные классы в объектные примеры, которые соответствуют индивидуальным ресурсам в системе. Кроме того, диаграммы сотрудничества и последовательности UML, описывающие поведение приложения и инфраструктура объединены в одну или более спецификаций нагрузки. Каждая спецификация нагрузки может быть представлена диаграммой сотрудничества, которая показывает, как системные ресурсы использованы этой конкретной нагрузкой.

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

Аналогичная расположенная ярусами архитектура общая в функционировании моделирования [4, 5], но верхнее представление часто является нотацией моделирования «умного выполнения», как например, вариант сетей Petri, чтобы поддерживать передовые методы моделирования. В нашем случае, мы используем нетехническое верхнее представление для скрытия наиболее мелких вопросов моделирования. Этот метод более выровнен с целями каркаса, который подчеркивает удобство функционирования и использование высокоуровневых абстракций.

3. Пример

Мы иллюстрируем каркас с простым примером сети, проверяющей систему. Система действует следующим образом. Множество объектов получателя принимают сообщения из сетевых элементов и пересылают их объектам отправителя, которые ответственны за выполнение соответствующих действий. Есть также база данных, чтобы поддерживать описания для действий. Эти объекты представлены CReceiver, CHandler и CDatabase классами. Для того чтобы проиллюстрировать использование интерфейсов, операции класса Chandler реально определены на интерфейсе CHandler.

Рисунок 3 демонстрирует статическую структуру системы. Запрос на обслуживание оценивается для операций в течение миллисекунд.

Модель имеет две нагрузки: загрузка фона для базы данных и основная загрузка. Нагрузки проиллюстрированы на Рисунке 4. Загрузка фона имеет предполагаемый показатель один запрос к базе данных в секунду. Основная загрузка представляет обработку сообщений, прибывающих из сетевых элементов. В шагах 1 и 2 сообщение получено и переслано получателю. В шагах 2.2 и 2.3 отправитель обращается к базе данных и выполняет соответствующие действия. Мы первоначально оцениваем частоту поступления 7 сообщений в секунду.

Система использует объектно-ориентированную структуру для выполнения объектной связи. Для короткого примера, мы промоделируем структуру с простыми задержками связи. Мы допускаем, что есть среднее число 3 мс задержки, когда отправитель и получатель находятся в других узлах, и 2 мс контекстная задержка свитча, когда они - в том же узле. Мы также моделируем аппаратный ресурс, представляя реальные CPU и дисковые ресурсы для всех узлов. Служебные запросы приложения выравнивают операцию. Определения для сетевой структуры и узлы проиллюстрированы на Рисунке 5.

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

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

Сначала фактическое выполнение происходит исключительно в аппаратных ресурсах в результате запроса на обслуживание связи. Программные ресурсы только управляют порядком доступа аппаратных средств. Это проиллюстрировано серым цветом на рисунке. Во-вторых, ресурс Ctxswitch иллюстрирует эффект пусковых свойств. Это используется три раза: один раз для сообщения AcceptJob и дважды для синхронного вызова GetActions. Тем не менее, нет контекстного преключателя для рекурсивного вызова DoActions.

AQN на Рисунке 7 был сгенерирован из простой модели только с тремя прикладными уровнями сообщений в единственном узле. Количество автоматически сгенерированных сообщений небольшая и диаграмма последовательности еще более удобочитаема. Тем не менее, более сложные модели должны ясно генерировать большие и неудобные диаграммы. Это наблюдение обеспечивает дополнительное оправдание для предлагаемых методов моделирования.

Когда передовая конфигурация на Рисунке 6 превращена в представление AQN, результат содержит двенадцать ресурсов и 35 сообщений между ними. Список значений ресурсов дан перед фактическими сообщениями нагрузки.

Точка, стоящая в конфигурации - расширение сообщения AcceptJob в несколько доступных ресурсов. Есть три примера ресурса в AQN и запрос на обслуживание сообщения AcceptJob делится равномерно между ними. К тому же, все доступы, которые сделаны в течение активизации AcceptJob поделены на три равные части. Обратите внимание как рекурсивный вызов DoActions был передан единственному отправителю в отличие от сообщения AcceptJob. Дело в том, что текущая работа уже получает доступ к одному из трех отправителей и не имеет смысла направлять рекурсивный доступ к любому другому отправителю. Это устройство преобразования может быть отображено явно на диаграмме сотрудничества.

4. Выводы и будущая работа

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

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

К настоящему времени на экспериментальном этапе уже обнаружена потребность в различных расширениях. Мы кратко упоминаем четыре очевидных направления разработки. Во-первых, только средства поддержки, текстовая нотация PML и естественный шаг должен обеспечить поддержку для графического моделирования. Это может быть осуществлено или с самостоятельно реализованным графическим расширениям или с существующим графическим средством моделирования. Использование формата XMI для обмена модели - привлекательная альтернатива. Во-вторых, каркас к настоящему времени не поддерживает все обычно использованные характеристики UML диаграмм сотрудничества и последовательности. В особенности способа запуска, остановки, и синхронизации потоков. Лучшая поддержка для потоков должна обеспечиваться новой нотацией UML и соответствующими дополнениями в алгоритм МОД. В-третьих, диаграммы состояния и деятельности к настоящему времени не использованы каркасом, но они могут связать информацию в удобном виде. Например, диаграмма деятельности могла бы быть использована, чтобы объединять многочисленные диаграммы сотрудничества вместе в сложном взаимодействии. Используя этот подход, диаграммы загрузки не будут чрезмерно расти. Наконец, текущий метод ограничивает доступное планирование дисциплин, распределений сервисного времени и частоту поступления распределений.

Эти ограничения по большей части унаследованы из алгоритма MVA, который мы используем в течение метода декомпозиции. Тем не менее, приближенные методы существуют, чтобы расширять эти ограничения (напр. [4]) и они могли бы быть интегрированы в алгоритм МОД.

Ссылки

1. Kahkipuro, P., The Method of Decomposition for Analyzing Queuing Networks with Simultaneous Resource Possessions, In Proceedings of the Communications Networks and Distributed Systems Modeling and Simulation Conference (CNDS’99), The Society for Computer Simulations International, San Diego, California, 1999.

2. Kahkipuro, P., UML Based Performance Modeling Framework for Object-Oriented Distributed Systems, In France, R., Rumpe, B. (eds.), «UML»’99 – The Unified Modeling Language : Beyond the Standard, LNCS 1723, Springer-Verlag, Berlin Heidelberg, Germany, 1999.

3. Object Management Group, A Human-Usable Textual Notation for the UML Profile for EDOC, Request for Proposal, OMG Document ad/99-03-12, Framingham, Massachusetts, 1999.

4. Agrawal, S.C., Metamodeling: A Study of Approximations in Queuing Models, MIT Press, Cambridge, Massachusetts, USA, 1985.

5. Haverkort, B.R.: Performance of computer communication systems: a model-based approach. John Wiley & Sons, New York, New York, USA, 1998.