Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

ЛекUML

.pdf
Скачиваний:
27
Добавлен:
10.05.2015
Размер:
1.62 Mб
Скачать

Z

 

 

 

«import»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

- C

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

X

 

 

 

 

 

 

 

 

Y

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

+ A

 

 

 

 

«import»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

+ D

-B

Вотношении определения видимости семантика зависимостей «access» и «import» одинакова. Различие между ними заключается в том, что использование зависимости «access» не влияет на пространство имен зависимого пакета — для доступа к элементу независимого пакета нужно указывать составное имя (с именами

вложенных пакетов разделенными ::), а при использовании зависимости «import» происходит расширение пространства имен зависимого пакета пространством имен независимого пакета (можно использовать простые имена, без ::). При этом накладывается ограничение: имена в этих пространствах имен не должны совпадать, в противном случае возникает конфликт имен и модель считается противоречивой.

Хотя пакеты не являются классификаторами, тем не менее для них можно указать отношение обобщения. Обычно отношение обобщения для пакетов применяется в следующей ситуации. Допустим, что имеется несколько однородных в некотором смысле пакетов, например, несколько альтернативных вариантов реализации одной и той же функциональности. В таком случае можно определить в модели абстрактный пакет, который обобщает конкретные варианты. Например, на рисунке ниже. представлена одна из возможных структур пакетов информационной системы отдела кадров, касающаяся управления данными. Пакеты Personnel Management и Staff Management зависят от абстрактного пакета Data Management,

который является обобщением пакетов Database Management и Files Management.

 

 

 

 

 

 

Personnel Management

 

 

Database Management

 

 

 

 

 

 

 

 

Data Management

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Staff Management

 

 

 

Files Management

 

 

 

 

 

 

 

 

 

 

6.1.3.Модели, системы и подсистемы

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

Одна и та же физическая система может быть описана с различных точек зрения. Описание физической системы называется моделью. Каждая модель описывает всю физическую систему в целом, но модели могут сильно отличаться степенью детальности, используемыми средствами и расстановкой акцентов. Это определяется целью, с которой составляется модель. Например, мы можем различать концептуальную модель, логическую модель и модель реализации для одной и той же физической системы. Если физическая система сложна и велика (а именно так обычно и

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

Таким образом, мы можем структурировать наше описание физической системы различным образом: можно разделить все описание на несколько моделей, чтобы описать систему в целом с различных точек зрения, а можно разделить систему на части и описать их по отдельности как подсистемы. Более того, можно

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

Для моделирования данных аспектов в UML предусмотрены соответствующие средства: модель и подсистема являются понятиями метамодели UML. С точки зрения языка модели и подсистемы являются разновидностями пакетов, поскольку во всех случаях речь идет о группировке элементов модели Синтаксически модели и подсистемы выделяются с помощью

ключевых слов «model» и «subsystem», соответственно.

Стандартные стереотипы пакетов

 

 

 

Стереотип

 

Описание

 

«facade»

Пакет, который содержит только ссылки на элементы,

 

определенные в других пакетах. Используется для

 

описания "внешнего вида" других пакетов.

 

«framework»

Пакет, содержащий образцы и шаблоны. Используется

 

для описания повторно используемых архитектурных

 

решений.

 

 

 

«metamodel»

Модель, которая описывает другую модель. Например,

 

метамодель UML.

 

 

«modelLibrary»

Пакет,

содержащий

определения

элементов

 

моделирования, предназначенных для использования в

 

других пакетах.

 

 

«profile»

Пакет,

содержащий

определения

элементов

 

моделирования, предназначенных для моделирования в

 

определенной предметной области.

 

«stub»

Пакет, представляющий только открытые части другого

 

пакета.

 

 

 

«systemModel»

Модель, содержащая несколько моделей одной

 

физической системы.

 

 

«topLevel»

Пакет, который является конем иерархии вложенности

 

пакетов.

 

 

 

6.1.4. Трассировка, гиперссылки и документация

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

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

Для удобной трассировки в UML предусмотрены специальные средства различного уровня. Таковыми являются зависимости со специальными стереотипами — «trace» и «refine». Данные зависимости являются внесистемными отношениями, т. е. отношениями между элементами модели, а не моделью отношений между моделируемыми сущностями.

Зависимость со стереотипом «trace» показывает причинные связи в модели, другими словами, показывает, что зависимая сущность имеет причиной своего существования независимую сущности.

Исходное требование в форме примечания

«trace»

«requirement»

Move

Move operation ...

 

 

«trace»

Соответствующий

вариант

использования

Реализующий пакет

машин Employee & Position Statecharts

состояний

Зависимость со стереотипом «refine» отражает последовательность разработки элементов модели. Если две сущности связаны зависимостью со стереотипом «refine», то это означает, что зависимая сущность является более детальным описанием того же самого моделируемого объекта, что и независимая сущность.

Выводы

7 +_ 2 сущности на одной диаграмме Диаграмма должна охватываться «одним взглядом»

Управление моделями – для того, кто моделирует, а не для компьютера

В проекте сосуществуют разные модели в разных представлениях на разных уровнях абстракции

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]