10670

Моделирование динамики системы: временной аспект и структурная организация (Диаграмма взаимодействия)

Практическая работа

Информатика, кибернетика и программирование

Практическая работа № 34 Моделирование динамики системы: временной аспект и структурная организация Диаграмма взаимодействия Цель работы: изучение диаграмм взаимодействия: последовательностей и кооперации их семантическая эквивалентность. Типичные приемы модел...

Русский

2013-03-30

230 KB

31 чел.

Практическая работа № 3-4

Моделирование динамики системы: временной аспект и структурная организация (Диаграмма взаимодействия)

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

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

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

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

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

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

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


Рисунок 5.1 -
 Диаграммы взаимодействий

Диаграмма взаимодействий (Interaction diagram) описывает взаимодействия, состоящие из множества объектов и отношений между ними, включая сообщения, которыми они обмениваются. Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени - вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер.

Общие свойства

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

Содержание

Как правило, диаграммы взаимодействий содержат:

  •  объекты;
  •  связи;
  •  сообщения.

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

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

Диаграммы последовательностей

На диаграммах последовательностей внимание акцентируется прежде всего на временной упорядоченности сообщений. На рисунок 5.2 показано, что для создания такой диаграммы надо прежде всего расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные - правее (тем дальше, чем более подчиненным является объект). Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже. Это дает читателю наглядную картину, позволяющую понять развитие потока управления во времени.


Рисунок 5.2
- Диаграмма последовательностей

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

Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. (Обстоятельства жизненного цикла объекта можно указывать с помощью ограничений new, destroyed и transient, см. главу 15.)

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

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

Диаграммы кооперации

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


Рисунок 5.3
 - Диаграмма кооперации

У диаграмм кооперации есть два свойства, которые отличают их от диаграмм последовательностей.

Первое - это путь. Для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути (например, local показывающий, что помеченный объект является локальным по отношению к отправителю сообщения). Имеет смысл явным образом изображать путь связи только в отношении путей типа local, parameter, global и self (но не associations).

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

Чаще всего вам придется моделировать неветвящиеся последовательные потоки управления. Однако можно моделировать и более сложные потоки, содержащие итерации и ветвления. Итерация представляет собой повторяющуюся последовательность сообщений. Для ее моделирования перед номером сообщения в последовательности ставится выражение итерации, например * [ i : = 1. . n] (или просто *, если надо обозначить итерацию без дальнейшей детализации). Итерация показывает, что сообщение (и все вложенные в него сообщения) будет повторяться в соответствии со значением заданного выражения. Аналогично условие представляет собой сообщение, выполнение которого зависит от результатов вычисления некоторого булевского выражения. Для моделирования условия перед порядковым номером сообщения ставится выражение, например [х>0]. У всех альтернативных ветвей будет один и тот же порядковый номер, но условия на каждой ветви должны быть заданы так, чтобы два из них не выполнялись одновременно (не перекрывались

UML не определяет никакого особенного формата для выражений в квадратных скобках при описании итераций и ветвлений; можно использовать псевдокод или синтаксис какого-либо конкретного языка программирования.

Примечание: Не показывайте явно связи между объектами на диаграмме последовательностей. Также не указывайте порядковый номер сообщения, поскольку он неявно определяется физическим расположением сообщения относительно верха или низа диаграммы. Итерации и ветвления показывать можно; при этом альтернативные ветви изображают с помощью отдельных сообщений, исходящих из одной точки. Как правило, на диаграммах последовательностей показывают только простые ветвления; более сложные изображаются на диаграмме кооперации. 

Семантическая эквивалентность

Поскольку диаграммы последовательностей и кооперации используют одну и ту же информацию из метамодели UML, они семантически эквивалентны. Это означает, что можно преобразовать диаграмму одного типа в другой без какой-либо потери информации, что и было показано на двух предыдущих рисунках. Это не означает, однако, что на обеих диаграммах представлена в точности одна и та же информация. Так, на упомянутых рисунках диаграмма кооперации показывает, как связаны объекты (обратите внимание на стереотипы local и global), а соответствующая диаграмма последовательностей - нет. С другой стороны, на диаграмме последовательностей могут быть показаны возвращаемые сообщения (сообщение committed), а на соответствующей диаграмме кооперации они отсутствуют. Таким образом, можно сказать, что диаграммы обоих типов используют одну модель, но визуализируют разные ее особенности.

Типичные примеры применения

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

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

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

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

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

Моделирование временной упорядоченности потока управления осуществляется следующим образом:

  1.  Установите контекст взаимодействия, будь то система, подсистема, операция, класс или один из сценариев прецедента либо кооперации.
  2.  Определите сцену для взаимодействия, выяснив, какие объекты принимают в нем участие. Разместите их на диаграмме последовательностей слева на право так, чтобы более важные объекты были расположены левее.
  3.  Проведите для каждого объекта линию жизни. Чаще всего объекты существуют на протяжении всего взаимодействия. Для тех же объектов, которые создаются или уничтожаются в ходе взаимодействия, явно отметьте на линиях жизни моменты рождения и смерти с помощью подходящих стереотипных сообщений.
  4.  Начав с сообщения, инициирующего взаимодействие, расположите все по следующие сообщения сверху вниз между линиями жизни объектов. Если необходимо объяснить семантику взаимодействия, покажите свойства каждого сообщения (например, его параметры).
  5.  Если требуется показать вложенность сообщений или точный промежуток времени, когда происходят вычисления, дополните линии жизни объектов фокусами управления.
  6.  Если необходимо специфицировать временные или пространственные ограничения, дополните сообщения отметками и присоедините соответствующие ограничения.
  7.  Для более строгого и формального описания потока управления присоедините к каждому сообщению пред- и постусловия.

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

В качестве примера на рисунок 5.4 показана диаграмма последовательностей, где описан поток управления, относящийся к инициации простого двустороннего телефонного разговора. На данном уровне абстракции есть четыре объекта: два абонента (Callers) - они названы s и r, безымянный телефонный коммутатор (Switch) и объект с, являющийся материализацией разговора (Conversation) между абонентами. Последовательность начинается с отправки одним абонентом (s) сигнала liftReceiver (поднятьТрубку) коммутатору. Коммутатор, в свою очередь, посылает абоненту сообщение setDialTone (задатьТоновыйНаборНо-мера), после чего абонент несколько раз посылает сообщение dialDigit (на-братьЦифру). Обратите внимание, что это сообщение имеет отметку времени dialing, которая используется во временном ограничении (время выполнения executionTime - меньше 30 секунд). На диаграмме не показано, что случится при нарушении ограничения, - для этой цели можно было бы включить отдельную ветвь или нарисовать другую диаграмму. Далее коммутатор посылает сам себе сообщение routeCall (маршрутизировать вызов), а затем создает объект (с) класса Conversation (разговор), которому делегирует остальную часть работы. Хотя это и не показано во взаимодействии, у с есть дополнительная обязанность, связанная с механизмом начисления платы за разговор (это должно быть выражено на другой диаграмме взаимодействий). Объект Conversation звонит второму абоненту (r), который асинхронно посылает сообщение liftReceiver (поднятие трубки). После этого объект Conversation говорит коммутатору, что надо установить соединение (connect), а коммутатор сообщает обоим абонентам, что они соединены (connect), после чего абоненты наконец могут начать обмен информацией - это и показано в присоединенном примечании.


Рисунок 5.4
- Моделирование временной упорядоченности потоков управления

Примечание: На диаграмме последовательностей можно моделировать изменения состояния, роли и значений атрибутов объекта. Для этого есть два способа. Во-первых, можно изобразить объект несколько раз с различными состояниями, ролями и атрибутами, а потом для обозначения изменений воспользоваться переходом со стереотипом become. Во-вторых, для изменения состояния можно прямо на линии жизни объекта поместить соответствующую пиктограмму состояния. 

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

Структура потоков управления

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

Моделирование структурной организации потоков управления состоит из следующих шагов:

  1.  Установите контекст взаимодействия. Это может быть система, подсистема, операция, класс или один из сценариев прецедента либо кооперации.
  2.  Определите сцену для взаимодействия, выяснив, какие объекты принимают в нем участие. Разместите их на диаграмме кооперации в виде вершин графа так, чтобы более важные объекты оказались в центре диаграммы, а их соседи - по краям.
  3.  Определите начальные свойства каждого из этих объектов. Если значения атрибутов, помеченные значения, состояния или роли объектов изменяются во время взаимодействия, поместите на диаграмму дубликаты с новыми значениями и соедините их сообщениями со стереотипами become и copy (см. главу 13), сопроводив их соответствующими порядковыми номерами.
  4.  Детально опишите связи между объектами, вдоль которых передаются сообщения. Для этого:
    •  сначала нарисуйте связи-ассоциации. Они наиболее важны, поскольку представляют структурные соединения;
    •  после этого нарисуйте остальные связи, дополнив их соответствующими

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

  1.  Начав с сообщения, инициирующего взаимодействие, присоедините все по следующие сообщения к соответствующим связям, задав порядковые номера. Вложенность показывайте с помощью нотации Дьюи.
  2.  Если требуется специфицировать временные или пространственные ограничения, дополните сообщения отметками времени и присоедините нужные ограничения.
  3.  Если требуется описать поток управления более формально, присоедините к каждому сообщению пред- и постусловия.

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

В качестве примера на рисунок 5.5 показана диаграмма кооперации, которая описывает поток управления, связанный с регистрацией нового студента, причем внимание акцентируется на структурных отношениях между объектами. На диаграмме представлено пять объектов: RegistrarAgent, r (Регистратура), Student, s (Студент), два объекта Course, cl и с2 (Курс) и безымянный объект School (Вуз). Поток управления пронумерован явно. Действие начинается с того, что RegistrarAgent создает объект Student и добавляет его к School (сообщение addStudent), а затем дает ему указание зарегистрироваться. После этого объект Student посылает себе сообщение getschedule, предположительно получив сначала Course, на который он хочет записаться. Затем объект Student добавляет себя к каждому объекту Course. В конце опять показан объект s с об новленным значением атрибута registered.


Рисунок 5.5
 - Моделирование организации потоков управления

Обратите внимание, что на диаграмме показаны связи между объектом School и двумя объектами Course, а также между объектами School и Student, хотя вдоль этих путей не передаются никакие сообщения. Связи просто поясняют, как Student может "видеть" два Course, на которые он записывается. Объекты s cl и с2 связаны с School ассоциацией; следовательно, s может найти cl и с2 во время обращения к операции getSchedule (которая может вернуть набор объектов Course) косвенно, через объект School.

Советы

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

Хорошо структурированная диаграмма взаимодействий обладает следующими свойствами:

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

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

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

Создание диаграмм взаимодействия

В этом упражнении будут разработаны диаграммы Последовательности и Кооперативные диаграммы, описывающие введение нового заказа в систему обработки заказов.

Постановка задачи

Поговорив с Бобом, Сьюзан поняла, что должна делать система обработки заказов, разрабатываемая ей для фирмы Robertson's Cabinets. Она нарисовала диаграмму Вариантов Использования. Изучив эту диаграмму, все пришли к согласию по поводу области применения системы.

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

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

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

  1.  Продавец вводит новый заказ.
  2.  Продавец пытается ввести заказ, но товара нет на складе.
  3.  Продавец пытается ввести заказ, но при его сохранении в базе данных произошла ошибка.

Затем она приступила к созданию диаграмм Последовательности и Кооперативных диаграмм для сценария "Ввести новый заказ".

Создание диаграмм Взаимодействия

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

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

Этапы выполнения упражнения

Создание диаграммы Последовательности

  1.  В окне Model Explorer откройте правой кнопкой мыши меню Add diagram для модели Система обработки заказов и выберете Sequence Diagram (рисунок 5.).
  2.   Назовите новую диаграмму "Ввод заказа".
  3.  Дважды щелкните на ней, чтобы открыть ее

Рисунок 5.6 - Добавление диаграммы деятельности

Добавление на диаграмму действующего лица и объектов

  1.  

Перетащите действующее лицо Продавец (Salesperson) из окна Model Explorer на диаграмму.

  1.  На панели инструментов Toolbox нажмите кнопку Object (Объект).
  2.  Щелкните мышью в верхней части диаграммы, чтобы поместить туда новый объект.
  3.  Назовите объект Выбор варианта заказа.
  4.  Повторите этапы 3 и 4, чтобы поместить на диаграмму все остальные объекты:

Форма Детали заказа

Заказ.

Добавление сообщений на диаграмму

  1.  На панели инструментов нажмите кнопку Stimulus (Сообщение объекта).
  2.  Проведите мышью от линии жизни актера Продавец к линии жизни объекта Выбор варианта заказа.

Рисунок 5.8 – Строка ввода

  1.  В появившейся строке ввода (рисунок 5.8) введите его имя - Создать новый заказ.
  2.  Повторите этапы 2 и 3, чтобы поместить на диаграмму дополнительные сообщения:

Открыть форму (между Выбором варианта заказа и Деталями заказа)

Ввести номер заказа, заказчика и число заказываемых предметов (между Продавцом и Деталями заказа)

Сохранить заказ (между Продавцом и Деталями заказа)

Создать пустой заказ (между Деталями заказа и Заказом)

Ввести номер заказа, заказчика и число заказываемых предметов (между Деталями заказа и Заказом).

# Save the order -- Сохранить заказ (между Деталями заказа и Заказом)

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

Рисунок 5.9 - Диаграмма Последовательности ввода нового заказа после завершения первого этапа работы.

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

Добавление на диаграмму дополнительных объектов

  1.  На панели инструментов нажмите кнопку Object.
  2.  Щелкните мышью между объектами Детали заказа и Заказ, чтобы поместить туда новый объект.
  3.  Введите имя объекта - Управляющий заказами.
  4.  На панели инструментов нажмите кнопку Object.
  5.  Новый объект расположите справа от Заказа.
  6.  Введите его имя - Управляющий транзакциями.

Назначение ответственностей объектам

  1.  Выделите сообщение Создать пустой заказ.
  2.  Нажмите комбинацию клавиш CTRL + D, чтобы удалить это сообщение.
  3.  Повторите этапы 1 и 2, чтобы удалить два последних сообщения:

Вести номер заказа, заказчика и число заказываемых предметов

Сохранить заказ

  1.  На панели инструментов нажмите кнопку Stimulus.
  2.  Поместите на диаграмму новое сообщение, расположив между объектами Детали заказа и Менеджер заказов.
  3.  Назовите его Save the order (Сохранить заказ).

Рисунок 5.10 - Диаграмма Последовательности с новыми объектами.

  1.  Повторите этапы 4 - 6, добавив сообщения с шестого по девятое и назвав их: Создать новый заказ - между Управляющим заказами и Заказом. Вести номер заказа, заказчика и число заказываемых предметов - между Управляющим заказами и Заказом. Сохранить заказ - между Управляющим заказами и Управляющим транзакциями. Информация о заказе - между Управляющим транзакциями и Заказом.
  2.  На панели инструментов нажмите кнопку Сообщение себе.
  3.  Щелкните на линии жизни объекта Управляющий транзакциями ниже последнего сообщения, добавив туда рефлексивное сообщение (кнопка SelfStimulus). Назовите его Сохранить информацию о заказе в базе данных.

Теперь диаграмма Последовательности должна выглядеть как на рисунке 3.

Создание Диаграммы кооперации

Рисунок 5.11 – Конвертация диаграмм взаимодействия

  1.  В окне Model Explorer откройте правой кнопкой мыши меню Add diagram для модели Система обработки заказов и выберете Sequence Collaboration Diagram. (рисунок 5.11).
  2.  Создайте диаграмму кооперации соответственно рисунку 5.12

Рисунок 5.12 - Диаграмма кооперации ввода нового заказа


 

А также другие работы, которые могут Вас заинтересовать

10638. Понятие религии. Религиозные ценности и свобода совести 83 KB
  Понятие религии. Религиозные ценности и свобода совести На вопрос Что такое религия различные люди в зависимости от того атеисты они или верующие дадут различный ответ. Научное определение религии ее природы сущности стремится уйти от пристрастности той или ино...
10639. Любовь (привязанность, дружба, эрос, милосердие) как нравственная и религиозная ценность 47.5 KB
  Любовь привязанность дружба эрос милосердие как нравственная и религиозная ценность Для того кто любит любовь является наивысшей ценностью определяющей всю жизненную стратегию. Огромной ролью любви в жизни человека можно объяснить то почему она довольно рано с...
10640. Цифровые элементы в информационно-управляющих системах 393 KB
  Цифровые элементы в информационноуправляющих системах Рассмотрев систему управления можно отметить следующее: объект управления характеризуется изменением энергетических и материальных потоков и соответственно изменением параметров или координат во вре
10641. Последовательностные схемы или дискретные автоматы с памятью 279 KB
  Последовательностные схемы или дискретные автоматы с памятью Сигнал на выходе автомата с памятью в дальнейшем – автомата в каждый момент времени определяется не только комбинацией входных сигналов в данный момент времени но и состоянием самого автомата в этот мом
10642. Дефекты, ошибки и риски в жизненном цикле программных средств 554 KB
  Дефекты ошибки и риски в жизненном цикле программных средств 1. Общие особенности дефектов ошибок и рисков в сложных программных средствах 2. Причины и свойства дефектов ошибок и модификаций в сложных программных средствах 3. Риски в жизненном цикле сложных пр...
10643. Технология программирования. Основные понятия и подходы 585.5 KB
  Технология программирования. Основные понятия и подходы Технология программирования и основные этапы ее развития Жизненный цикл и этапы разработки программного обеспечения ВВЕДЕНИЕ Программирование сравнительно молодая и быстро развивающаяся...
10644. Приемы обеспечения технологичности программных продуктов 295 KB
  Приемы обеспечения технологичности программных продуктов Понятие технологичности программного обеспечения. Модули и их свойства. Нисходящая и восходящая разработка программного обеспечения. ВВЕДЕНИЕ В условиях индуст...
10645. Обеспечения технологичности программных продуктов 617 KB
  Тема: Обеспечения технологичности программных продуктов 1.Структурное и неструктурное программирование. Средства описания структурных алгоритмов. Стиль оформления программы. 2. Эффективность и технологичность. 3. Программирование
10646. Тестирование программных продуктов 1.29 MB
  Тестирование программных продуктов Виды контроля качества разрабатываемого программного обеспечения Ручной контроль программного обеспечения Структурное тестирование Функциональное тестирование Тестирования модулей и к...