ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 16.03.2024
Просмотров: 105
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
инии с треугольной незакрашенной стрелкой на конце, направленной от реализующей сущности к реализуемой (рис. 10).
На рис. 10 классы OpenDocCmd и CloseDocCmd реализуют интерфейс Command.
Примечания – это комментарии на диаграммах. Примечания могут существовать сами по себе или быть связаны пунктирной линией с эле ментами, которые они комментируют (рис. 11). Они могут присутствовать на диаграммах любого типа.
Рис.11.Примечаниеиспользуетсякаккомментарийкодномуилиболееэлементамдиаграммы
Когда требуется смоделировать конструкцию, отсутствующую в UML, но похожую на один из его элементов, можно взять символ существующей конструкции UML, пометив его ключевым словом, чтобы показать, что используется нечто другое.
Примером может служить интерфейс. Интерфейс (interface) в UML означает класс, в котором все операции открытые и не имеют тел методов. Это соответствует, например, интерфейсам в Java.
Поскольку это специальный вид класса, то он изображается с помощью пиктограммы с ключевым словом
«interface». Обычно ключевые слова представляются в виде текста, заключенного во французские кавычки («елочки»). Вместо ключевых
слов можно использовать специальные значки, но тем самым вы заставляете всех запоминать их значения.
Некоторые ключевые слова, такие как {abstract}, заключаются в фигурные скобки. В действительности никогда не понятно, что формально должно быть в кавычках, а что в фигурных скобках. К счастью, если вы ошибетесь, то заметят это только настоящие знатоки UML. Но лучше быть внимательными.
Некоторые ключевые слова настолько общеупотребительны, что часто заменяются сокращениями:
«interface» часто сокращается до «I», а {abstract} – до {A}. Такие сокращения очень полезны, особенно на белых досках, однако их применение не стандартизовано. Поэтому если вы их употребляете, то не забудьте найти место для расшифровки этих обозначений.
Если в UML ссылаются на операции и атрибуты, принадлежащие классу, а не экземпляру класса, то они называются статическими. Это эквивалентно статическим членам в Cподобных языках. На диаграмме класса статические элементы подчеркиваются (рис. 12).
Рис.12.СтатическаяоперациявклассеOrder
Диаграммы взаимодействия (interaction diagrams) описывают взаимодействие групп объектов в различных условиях их поведения. UML определяет диаграммы взаимодействия нескольких типов, из которых наиболее употребительными являются диаграммы последовательности.
Обычно диаграмма последовательности описывает один сценарий. На диаграмме показаны экземпляры объектов и сообщения, которыми обмениваются объекты в рамках одного прецедента (use case). Прецедент (use case) — множество сценариев, объединенных по некоторому критерию и описывающих последовательности производимых системой действий, доставляющих значимый для некоторого действующего лица результат.
Фактически, диаграмма последовательности — это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектноориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.
Рассмотрим простой сценарий. Предположим, что у нас есть заказ, и мы собираемся вызвать команду для определения его стоимости. При этом объекту заказа (Order) необходимо просмотреть все позиции заказа (Line Items) и определить их цены, основанные на правилах построения цены продукции
в
строке заказа (Order Line). Проделав это для всех позиций заказа, объект заказа должен вычислить общую скидку, которая определяется индивидуально для каждого клиента.
На рис. 13 приведена диаграмма, представляющая реализацию данного сценария. Диаграммы последовательности показывают взаимодействие, представляя каждого участника вместе с его линией жизни (lifeline), которая идет вертикально вниз и упорядочивает сообщения (или обращения к каждому участнику); сообщения также следует читать сверху вниз.
Можно видеть, что экземпляр заказа посылает строке заказа сообщения getQuantity и getProduct.
Можно также видеть, как заказ применяет метод к самому себе и как этот метод посылает сообщение getDiscountInfo экземпляру клиента.
Рис.13.Примердиаграммыпоследовательности(централизованноеуправление)
Однако диаграмма не все показывает так хорошо. Последовательность сообщений getQuantity, getProduct, getPricingDetails и calculateBasePrice должна быть реализована для каждойстроки заказа, тогда как метод calculateDiscounts вызывается лишь однажды. Такое заключение нельзя сделать на основе этой диаграммы, но позднее будет введено дополнительное обозначение, которое поможет в этом.
В большинстве случаев можно считать участников диаграммы
взаимодействия объектами.
На приведенной диаграмме участники поименованы с использованием стиля anOrder. В большинстве случаев это вполне приемлемо. Вот более полный синтаксис: имя : Класс, где и имя, и класс не обязательны, но если класс используется, то двоеточие должно присутствовать. Такой синтаксис используется на рис. 16.
Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответствует времени нахождения в стеке одного из методов участника.
Именование бывает часто полезным для установления связей между участниками на диаграмме.
Как видно на диаграмме, вызов метода getProduct возвращает aProduct, имеющего то же самое имя и, следовательно, означающего того же самого участника, aProduct, которому посылается вызов getPricingDetails. Обратите внимание, что обратной стрелкой обозначен только этот вызов с целью показать соответствие. Многие разработчики используют возвраты для всех вызовов, но можно применять их, только когда это дает дополнительную информацию; в противном случае они просто вносят неразбериху. Не исключено, что даже в данном случае можно было опустить возврат.
У первого сообщения нет участника, пославшего его, поскольку оно
На рис. 10 классы OpenDocCmd и CloseDocCmd реализуют интерфейс Command.
Примечания и комментарии
Примечания – это комментарии на диаграммах. Примечания могут существовать сами по себе или быть связаны пунктирной линией с эле ментами, которые они комментируют (рис. 11). Они могут присутствовать на диаграммах любого типа.
Рис.11.Примечаниеиспользуетсякаккомментарийкодномуилиболееэлементамдиаграммы
Ключевые слова
Когда требуется смоделировать конструкцию, отсутствующую в UML, но похожую на один из его элементов, можно взять символ существующей конструкции UML, пометив его ключевым словом, чтобы показать, что используется нечто другое.
Примером может служить интерфейс. Интерфейс (interface) в UML означает класс, в котором все операции открытые и не имеют тел методов. Это соответствует, например, интерфейсам в Java.
Поскольку это специальный вид класса, то он изображается с помощью пиктограммы с ключевым словом
«interface». Обычно ключевые слова представляются в виде текста, заключенного во французские кавычки («елочки»). Вместо ключевых
слов можно использовать специальные значки, но тем самым вы заставляете всех запоминать их значения.
Некоторые ключевые слова, такие как {abstract}, заключаются в фигурные скобки. В действительности никогда не понятно, что формально должно быть в кавычках, а что в фигурных скобках. К счастью, если вы ошибетесь, то заметят это только настоящие знатоки UML. Но лучше быть внимательными.
Некоторые ключевые слова настолько общеупотребительны, что часто заменяются сокращениями:
«interface» часто сокращается до «I», а {abstract} – до {A}. Такие сокращения очень полезны, особенно на белых досках, однако их применение не стандартизовано. Поэтому если вы их употребляете, то не забудьте найти место для расшифровки этих обозначений.
Статические операции и атрибуты
Если в UML ссылаются на операции и атрибуты, принадлежащие классу, а не экземпляру класса, то они называются статическими. Это эквивалентно статическим членам в Cподобных языках. На диаграмме класса статические элементы подчеркиваются (рис. 12).
Рис.12.СтатическаяоперациявклассеOrder
Диаграмма последовательности (Sequence diagram)
Диаграммы взаимодействия (interaction diagrams) описывают взаимодействие групп объектов в различных условиях их поведения. UML определяет диаграммы взаимодействия нескольких типов, из которых наиболее употребительными являются диаграммы последовательности.
Обычно диаграмма последовательности описывает один сценарий. На диаграмме показаны экземпляры объектов и сообщения, которыми обмениваются объекты в рамках одного прецедента (use case). Прецедент (use case) — множество сценариев, объединенных по некоторому критерию и описывающих последовательности производимых системой действий, доставляющих значимый для некоторого действующего лица результат.
Фактически, диаграмма последовательности — это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектноориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.
Рассмотрим простой сценарий. Предположим, что у нас есть заказ, и мы собираемся вызвать команду для определения его стоимости. При этом объекту заказа (Order) необходимо просмотреть все позиции заказа (Line Items) и определить их цены, основанные на правилах построения цены продукции
в
строке заказа (Order Line). Проделав это для всех позиций заказа, объект заказа должен вычислить общую скидку, которая определяется индивидуально для каждого клиента.
На рис. 13 приведена диаграмма, представляющая реализацию данного сценария. Диаграммы последовательности показывают взаимодействие, представляя каждого участника вместе с его линией жизни (lifeline), которая идет вертикально вниз и упорядочивает сообщения (или обращения к каждому участнику); сообщения также следует читать сверху вниз.
Можно видеть, что экземпляр заказа посылает строке заказа сообщения getQuantity и getProduct.
Можно также видеть, как заказ применяет метод к самому себе и как этот метод посылает сообщение getDiscountInfo экземпляру клиента.
Рис.13.Примердиаграммыпоследовательности(централизованноеуправление)
Однако диаграмма не все показывает так хорошо. Последовательность сообщений getQuantity, getProduct, getPricingDetails и calculateBasePrice должна быть реализована для каждойстроки заказа, тогда как метод calculateDiscounts вызывается лишь однажды. Такое заключение нельзя сделать на основе этой диаграммы, но позднее будет введено дополнительное обозначение, которое поможет в этом.
В большинстве случаев можно считать участников диаграммы
взаимодействия объектами.
На приведенной диаграмме участники поименованы с использованием стиля anOrder. В большинстве случаев это вполне приемлемо. Вот более полный синтаксис: имя : Класс, где и имя, и класс не обязательны, но если класс используется, то двоеточие должно присутствовать. Такой синтаксис используется на рис. 16.
Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответствует времени нахождения в стеке одного из методов участника.
Именование бывает часто полезным для установления связей между участниками на диаграмме.
Как видно на диаграмме, вызов метода getProduct возвращает aProduct, имеющего то же самое имя и, следовательно, означающего того же самого участника, aProduct, которому посылается вызов getPricingDetails. Обратите внимание, что обратной стрелкой обозначен только этот вызов с целью показать соответствие. Многие разработчики используют возвраты для всех вызовов, но можно применять их, только когда это дает дополнительную информацию; в противном случае они просто вносят неразбериху. Не исключено, что даже в данном случае можно было опустить возврат.
У первого сообщения нет участника, пославшего его, поскольку оно