Анализ и моделирование на UML 5 page

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

Диаграммы коммуникации

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

Кроме отображения связей, которые представляют собой экземпляры ассоциаций, можно также показать временные связи, возникающие только в контексте взаимодействия. В данном случае связь «local» (локальная) от объекта Order (Заказ) к объекту Product (Продукт) – это локальная переменная, а другими временными связями являются «parameter» (параметр) и «global» (глобальная). Эти ключевые слова употреблялись в UML 1, но пропали из UML 2. Они полезны, поэтому я надеюсь, что разработчики от них не откажутся.

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

Вложенная десятичная нумерация нужна, потому что требуется исключить неопределенность при самовызовах. На рис. 4.2 четко показано, что метод getDiscountInfo вызывается из методаcalculateDiscount.

Однако в случае применения линейной нумерации, как на рис. 12.1, нельзя будет сказать, вызывается ли метод getDiscountInfo из метода calculateDiscount или из более общего методаcalculatePrice. Схема вложенной нумерации позволяет обойти эту трудность.

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

Кроме чисел в сообщениях можно увидеть и буквы. Эти символы обозначают различные потоки управления. Так, A5 и B2 могут быть различными потоками; сообщения 1a1 и 1b1 могут быть различными потоками, параллельно вложенными в сообщение 1. Буквы, обозначающие потоки, можно увидеть также и на диаграммах последовательности, хотя это и не дает визуального представления о параллельности.

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

и «delete» соответствуют общепринятым соглашениям.

(http://it-gost.ru/articles/view_articles/94, http://www.planerka.info/item/Diagrammy-kommunikacij-UML)

18. Паттерны проектирования и каркасы на UML

(Туривный С.)

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

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

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

Рис. 14.1. Изображение паттерна в форме параметризованной кооперации

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

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

№

Название паттерна

Перевод

Назначение паттерна

Abstract Factory

Абстрактная фабрика

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

Adapter(синоним - Wrapper)

Адаптер (Обертка)

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

Bridge

Мост

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

Builder

Строитель

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

Chain of Responsibility

Цепочка обязанностей

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

Command

Команда

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

Composite

Компоновщик

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

Decorator

Декоратор

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

Facade

Фасад

Предоставляет единый интерфейс к множеству операций или интерфейсов в системе на основе унифицированного интерфейса для облегчения работы с системой.

Factory Method

Фабричный метод

Определяет интерфейс для разработки объектов, при этом объекты данного класса могут быть созданы его подклассами.

Flyweight

Приспособленец

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

Interpreter

Интерпретатор

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

Iterator

Итератор

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

Mediator

Посредник

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

Memento

Хранитель

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

Observer

Наблюдатель

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

Prototype

Прототип

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

Proxy

Заместитель

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

Singleton

Одиночка

Для выбранного класса обеспечивает выполнение требования единственности экземпляра и предоставления к нему полного доступа.

State

Состояние

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

Strategy

Стратегия

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

Template Method

Шаблонный метод

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

Visitor

Посетитель

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

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

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

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

На рис. 28.3 показан такой каркас, названный ЦиклическийИсполнитель. Среди прочего каркас включает кооперацию (ОбщиеСобытия), охватывающую множество классов событий (см. главу 20), и механизм (ОбработчикСобытий) для циклической обработки событий. Клиент, построенный на базе этого каркаса (к примеру, СердечныйСтимулятор) может пользоваться абстракциями из кооперации ОбщиеСобытия путем порождения производных классов, а также применять механизм ОбработчикСобытий.

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

(http://www.intuit.ru/studies/courses/32/32/lecture/1026?page=3, http://dit.isuct.ru/ivt/books/CASE/case11/ch28.htm#Heading7)

19. Управление моделями

(Туривный С.)

Пакет Управление моделями

Пакет Управление моделями (Model Management) специфицирует базовые элементы языка UML, которые необходимы для формирования всех модельных представлений. Именно в нем определяется семантика модели (Model), пакета (Package) и подсистемы (Subsystem). Эти элементы служат своеобразными контейнерами для группировки других элементов модели.

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

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

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

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

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

Рис. 3.9. Графическое изображение подсистемы в языке UML

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

(http://dit.isuct.ru/ivt/books/CASE/case6/gl3/gl3.html#16)

20. Влияние UML на процесс разработки

Администрирование в информационных системах

1. Общая характеристика стандартов управления IT инфраструктурой (ITIL, ITSM, ISO20000, MOF). Области применения, основное содержание, цели применения.

2. Модель MicrosoftInfrastructureOptimisation. Уровни, содержание, переход между уровнями.

3. Этап Планирования по стандарту MOF (MicrosoftOperationsFramework) или ITILv.3.
Состав, функции.

4. Этап Развертывания (Предоставления) по стандарту MOF (MicrosoftOperationsFramework) или ITILv.3. Состав, функции.

5. Этап Эксплуатации по стандарту MOF (MicrosoftOperationsFramework) или ITILv.3. Состав, функции.

6. Этап Управления по стандарту MOF (MicrosoftOperationsFramework) или ITILv.3. Состав, функции.

7. Локальные сети Ethernet. Активное оборудование. Коммутаторы L2, L3, их характерные особенности.

8. Архитектура стека TCP/IP (уровни, назначение, потоки данных, примеры протоколов), адресная информация в TCP/IP. IP адреса, IP-сети, порты TCP\UDP.

9. Соединение IP сетей. Маршрутизация в IP. Трансляция адресов (NAT). Проксирование.

10. Система DNS.

11. Обеспечение безопасности в корпоративных сетях на канальном и сетевом уровнях (VLAN, RADIUS, VPN).

12. Надежность систем. Показатели надежности. Уровни надежности по классификации HP.

13. Обеспечение сохранности данных. Резервное копирование данных (н азначение, стратегии, реализация). RAID (Назначение, уровни, особенности).

14. Системы шифрования. Виды алгоритмов шифрования, общие характеристики. Общая архитектура PGP.

15. Сертификаты. Назначение, устройство, области применения.

16. Контроль доступа к ресурсам. ACL. Мандатный доступ.

17. Идентификация, Аутентификация, Авторизация. Понятие, назначение, примеры.

18. Службы каталогов на примере ActiveDirectory. Виды объектов, основные понятия, роли контроллеров домена, протокол LDAP.