Моделирование и проектирование программного обеспечения Лекция 8. Реализация вариантов использования. Диаграммы последовательностей
Пример диаграммы последовательностей
Пример диаграмма последовательности (2)
Пример варианта использования Для описания участников (с их линиями жизни) и сообщений, рассмотрим пример из простой системы регистрации курсов. Вариант использования AddCourse (добавить курс)
Исходный анализ созданного прецедента представлен на рисунке в виде высокоуровневой диаграммы классов анализа. Спецификация ВИ и диаграмма классов обеспечивают объем информации, достаточный для создания диаграммы последовательностей.
На рис. показана диаграмма последовательностей, реализующая поведение, описанное прецедентом AddCourse. Согласно спецификации UML 2, имена диаграмм взаимодействий могут начинаться с приставки sd, для обозначения того, что данная диаграмма является диаграммой взаимодействий. Это нормально, т. к. все это – часть процесса анализа.
Линии жизни размещаются горизонтально, чтобы минимизировать число пересекающихся линий на диаграмме. Их местоположение относительно вертикальной оси отражает момент их создания. Пунктирная линия, находящаяся внизу, показывает существование линии жизни в течение времени. – время на диаграммах последовательностей развивается сверху вниз, – линии жизни выполняются слева направо.
Диаграммы взаимодействий не являются дословными копиями ВИ; – это иллюстрации того, как классы анализа реализуют поведение прецедента. Обратите внимание, что рис. показывает реализацию поведения ВИ, но не является точным представлением каждого его шага. В шагах 1 и 2 ВИ участвует какой-то пользовательский интерфейс, которым не рассматривается детально вплоть до этапа проектирования, поэтому на диаграмме последовательностей он опущен. Слой пользовательского интерфейса, который помогает прояснить некоторые вещи, может быть добавлен в диаграмму последовательностей во время проектирования. В анализе нас интересует только основное поведение классов анализа.
Пример варианта использования «Удалить курс из системы регистрации курсов»
Уничтожение объекта Уничтожение объекта обозначается большим крестом, завершающим линию жизни, как показано на рис. Если момент уничтожения объекта неизвестен или неважен, линия жизни завершается без креста.
Самоделегирование Самоделегирование: линия жизни объекта посылает сообщение самой себе. Это создает вложенную активацию. Самоделегирование распространено в ОО системах. Объекты предлагают ряд открытых сервисов (открытых операций), которые могут быть вызваны клиентскими объектами. Но, как правило, они также имеют и закрытые «вспомогательные» операции, разработанные специально для вызова самим объектом.
В данном примере линия жизни :RegistrationManager посылает сама себе сообщение findCourse( "UML" ), чтобы найти UML-объект курса, если таковой существует. Закрытые операции объекта могут быть вызваны только самим объектом средствами самоделегирования.
Активации Вытянутые прямоугольники, расположенные на пунктирной линии под линией жизни, показывают, когда на данной линии жизни находится фокус управления. Эти прямоугольники называются – активациями, или – фокусом управления. Активации показывают, когда фокус управления располагается в данной линии жизни. Термины «активация» и «фокус управления» являются стандартными.
На рис. фокус управления сначала находится на актере :Registrar. Он посылает сообщение addCourse("UML") актеру :RegistrationManager, который инициирует операцию addCourse(…) с параметром "UML". Во время выполнения этой операции фокус управления находится у :RegistrationManager.
Отметим, фокус управления фокус управления :RegistrationManager вложен в фокус управления актера :Registrar. – это вполне нормально – один объект, имеющий фокус управления, инициирует операцию другого объекта, создавая вложенный фокус управления. – этот объект затем может инициировать операцию еще одного объекта, еще более углубляя вложенность фокуса управления, и т. д. В рамках выполнения операции addCourse(…) актер :RegistrationManager создает новый объект uml:Course.
В последнее время разработчики моделей часто не используют активации: – отчасти это объясняется плохой поддержкой активаций некоторыми инструментами UML, – отчасти тем, что обычно активации не так важны, особенно в моделях анализа. В исполняющейся ОО системе активации и так просматриваются через обычную семантику вызова операции. – На практике читать сложные диаграммы последовательностей без активаций может быть немного проще. Обычно активации используются, только если они не уменьшают читаемость диаграммы.
Документирование диаграмм последовательностей Замечательное свойством диаграмм последовательностей – возможность добавлять в них «описания действий - сценарии» путем размещения примечаний в нижней левой части диаграмм. – Это делает диаграмму намного более понятной заинтересованным лицам, которые не являются специалистами в UML, например пользователям или экспертам. Сценарий может состоять из фактических шагов ВИ или краткого обзора того, что происходит на диаграмме, представленного в текстовой форме. В любом случае сценарий может быть полезным дополнением, особенно если диаграмма сложна.
Состояние экземпляра Сообщение, получаемое экземпляром, может вызвать изменение его состояния. Состояние определяется как «условие или ситуация в ходе жизни объекта, в течение которой он удовлетворяет некоторому условию, осуществляет некоторую деятельность или ожидает некоторое событие».
Конечный автомат описания ВИ Для каждого описания ВИ можно создать конечный автомат, описывающий жизненный цикл его экземпляров с точки зрения – состояний, в которых они могут находиться, и – событий, которые обуславливают переходы между этими состояниями. Не все сообщения приводят к изменению состояния. – Например, сообщение, которое возвращает значение некоторого атрибута и не имеет никаких побочных действий, никогда не генерирует изменения состояния.
Инварианты состояния Состояние экземпляров на линиях жизни объектов можно показать с помощью инвариантов состояния (state invariants). Добавление инвариантов состояния на диаграмму последовательностей может быть весьма полезным методом анализа, поскольку позволяет фиксировать ключевые состояния жизненного цикла линии жизни. Они отражают важные состояния системы и могут быть основой для конечных автоматов.
Пример ВИ из простой системы обработки заказов Обработки заказов, имеющей следующие ограничения: – заказ должен полностью оплачиваться единовременным платежом; – позиции, указанные в заказе, могут поставляться только после оплаты; – позиции доставляются покупателю в течение 28 дней после оплаты.
Пример: диаграмма последовательностей для ProcessAnOrder (обработка заказа) Сразу после создания экземпляр Order выполняется переходит в состояние unpaid (не оплачено) (изображается в виде прямоугольника с округленными углами). Это сообщает о том, что все вновь создаваемые экземпляры Order находятся в состоянии unpaid. При получении сообщения acceptPayment() (принять платеж), которое должно обозначать полную оплату, экземпляр переходит в состояние paid (оплачено).
После этого экземпляр DeliveryManager (менеджер по доставке) посылает сообщение deliver() (доставить). Он передает это сообщение экземпляру Order, что приводит к его переходу в состояние delivered (доставлено). Если класс Order также имеет автомат, его состояния должны соответствовать всем инвариантам состояний, присутствующим на его диаграммах последовательностей.
Пример: диаграмма последовательностей для ProcessAnOrder (обработка заказа) Ограничения записываются в фигурных скобках и размещаются на (или рядом) линиях жизни. Ограничение, обозначенное на линии жизни, указывает на что-то, что должно быть истинным для экземпляров, начиная с этого момента и далее. Ограничения часто формулируются на естественном языке.
На рисунке показано ограничение продолжительности. Линия жизни объекта :Customer имеет две метки, A и B, и ограничение {B – A
На линию жизни может быть помещен любой тип ограничения. Широко распространены ограничения значений атрибутов экземпляров.
На рис. не используется активация и возвраты сообщений. Основное внимание данной диаграммы направлено на сроки и структуру взаимодействия. Активации и возвраты не добавляют в данную диаграмму полезную информацию.
Комбинированные фрагменты и операторы Диаграммы последовательностей можно разделить на области, называемые комбинированными фрагментами (combined fragments). Комбинированные фрагменты разделяют диаграмму последовательностей на области с различным поведением. У каждого комбинированного фрагмента есть один оператор (operator), один или более операндов (operands) и нуль или более сторожевых условий (guard conditions). Оператор определяет, как исполняются его операнды.
Сторожевые условия определяют, будут ли исполняться эти операнды. Сторожевое условие – это логическое выражение, и операнд исполняется тогда и только тогда, когда это выражение истинно. Одно сторожевое условие может применяться ко всем операндам или каждый операнд может иметь собственное уникальное сторожевое условие. Сторожевые условия определяют, будут ли выполняться данные операнды.
Наиболее важные операторы ДП Операт ор Полное имя Семантика opt optionЕдинственный операнд выполняется, если условие истинно (как if … then). alt alternativesВыполняется тот операнд, условие которого истинно. Вместо логического выражения может использоваться ключевое слово else (как select … case). loop Имеет специальный синтаксис: loop min, max [condition] повторять минимальное количество раз, затем, пока условие истинно, повторять еще (max – min) число раз break Если сторожевое условие истинно, выполняется операнд, а не все остальное взаимодействие, в которое он входит. ref referenceКомбинированный фрагмент ссылается на другое взаимодействие. par parallelВсе операнды выполняются параллельно. critical Операнд должен выполняется без прерывания.
Ветвление с помощью операторов alt Оператор opt показывает, что его единственный операнд выполняется, если сторожевое условие истинно. В противном случае выполнение продолжается после комбинированного фрагмента. opt эквивалентен программной конструкции: if (условие1) then действие1
Ветвление с помощью операторов alt Оператор alt эквивалентен программной конструкции: if (условие1) then операнд 1 else if (условие2) then операнд 2... else if (условиеN) then операнд N else операнд M
Пример использования оператора alt в ДП
Пример: спецификации варианта использования ManageBasket
Пример: диаграмма классов анализа варианта использования ManageBasket
Пример: диаграмма последовательностей варианта использования ManageBasket
Оператор цикла loop Очень часто на диаграммах последовательностей необходимо показать циклы. Это описывается с помощью операторов loop и break, как показано. Оператор loop действует следующим образом: loop min «количество раз» then while (условие истинно) loop (max min) «количество раз» В синтаксисе loop необходимо обратить внимание на следующие моменты: – оператор loop без max, min или condition является бесконечным циклом; – если задано только min, значит, max = min; – condition обычно является логическим выражением, но может быть и произвольным текстом, смысл которого ясен.
Оператор break Оператор break может использоваться для обозначения – условия прекращения loop и – того, что происходит после этого. У оператора break только одно сторожевое условие, и если оно истинно, исполняется тело break, а loop прерывается. Самое главное, что после завершения break loop не возобновляется. Комбинированный фрагмент break логически находится вне цикла: он не является его частью. Поэтому фрагмент break всегда должен изображаться вне loop, но пересекаться с ним.
Организация итераций операторами loop и break
Распространенные циклы Наиболее распространенные циклы
Применение циклов Наиболее распространенным применением циклов является перебор коллекции объектов. Например, цикл может применяться как возможная реализация операции findCourse(...) класса RegistrationManager.
Эта операция возвращает объект Course с соответствующим именем (name) или null, как показано на рис. Имя конца ассоциации с кратностью больше 1 можно использовать как коллекцию объектов. В данном случае для представления коллекции объектов Course используется имя courses (курсы).