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

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

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

    Каждая  ассоциация обладает двумя ролями; каждая роль представляет собой направление  ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.

    Роль  может быть явно поименованная с  помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам  заказа называется "позиция заказа". Если такая метка отсутствует, роли присваивается имя класс - цели - таким образом, роль ассоциации от Заказа к Клиенту может быть названа  Клиент (термины "начало" (source) и "цель" (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).

 

     4.2 Диаграмма  взаимодействия

    Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов.

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

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

    Окно  Ввода Заказа посылает Заказу сообщение "приготовиться".

    Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

    Каждая  Строка заказа проверяет состояние  определенного Запаса товара:

    Если  данная проверка удовлетворяется (результат - true), то Строка заказа удаляет соответствующее количество товара из Запаса.

    В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую  поставку товара.

    Существуют  два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

    На  диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис.2).

    Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

 

    Рис.3 Диаграмма последовательности 

    Каждое  сообщение представляется в виде стрелки между линиями жизни  двух объектов. Сообщения появляются в том порядке, как они показаны на странице - сверху вниз. Каждое сообщение  помечается, как минимум, именем сообщения; при желании можно добавить также  аргументы и некоторую управляющую  информацию и, кроме того, можно показать само делегирование (self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

    Из  всей возможной управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нуженПовторныйЗаказ = "true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер - это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться).

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

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

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

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

    Рис.4 Параллельные процессы и активизации 

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

    В диаграмму последовательности на рис.3 введен ряд новых элементов. Во-первых, это активизации, появляющиеся явно в том случае, когда метод становится активным либо во время его выполнения, либо при ожидании результата выполнения какой-либо процедуры. Во-вторых, половинные стрелки обозначают асинхронные  сообщения. Асинхронное сообщение  не блокирует работу вызывающего  объекта. Таким образом, он может  продолжать свой собственный процесс. Асинхронное сообщение может  выполнять одну из трех функций:

    • создавать новую ветвь процесса (в этом случае оно связано с  самой верхней частью активизации);

    • создавать новый объект;

    • устанавливать связь с уже  выполняющейся ветвью процесса.

    Удаление  объекта показано с помощью большого знака "X". Объекты могут выполнить  самоуничтожение или могут быть уничтожены посредством еще одного сообщения.

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

 

5. Определение целей,  функций, входов  и выходов модельной  системы

    Язык UML предназначен для решения следующих  задач:

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

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

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

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

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

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

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

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

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

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

    С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или  ином языке программирования. Конечно, в первую очередь имеются в  виду языки, поддерживающие концепцию  ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его  современным средством решения  задач моделирования сложных  систем. В то же время, предполагается, что для программной поддержки  конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства. Наличие последних имеет  принципиальное значение для широкого распространения и использования  языка UML.

1. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей объектно-ориентированного анализа и проектирования.

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

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