Lecture06 (1133563), страница 5
Текст из файла (страница 5)
Синхронизации двух видов — развилки(forks) и слияния (joins) — показываются жирными короткими линиями (кто-то можетпосчитать их и тонкими закрашенными прямоугольниками), к которым сходятся или откоторых расходятся потоки данных. Кроме синхронизаций, на диаграммах деятельностимогут быть показаны разветвления потоков данных, связанных с выбором того или иногонаправления в зависимости от некоторого условия.
Такие разветвления показываются ввиде небольших ромбов.Диаграмма может быть поделена на несколько горизонтальных или вертикальныхобластей, называемых дорожками (swimlanes). Дорожки служат для группировкидеятельностей в соответствии с выполняющими их подразделением организации, ролью,приложением, подсистемой и пр.Диаграммы деятельности могут заменять часто используемые диаграммы потоков данных(см. Лекцию 4), поэтому применяются достаточно широко.
Пример такой диаграммыпоказан на Рис. 35.Рисунок 35. Диаграмма деятельности.•Диаграммы сценариев (или диаграммы последовательности, sequence diagrams)показывают возможные сценарии обмена сообщениями или вызовами во времени междуразличными компонентами системы (здесь имеются в виду архитектурные компоненты,компоненты в широком смысле — это могут быть компоненты развертывания, обычныеобъекты, подсистемы и пр.). Эти диаграммы являются подмножеством специальногографического языка — языка диаграмм последовательностей сообщений (MessageSequence Charts, MSC), который был придуман раньше UML и достаточно долгоразвивается параллельно ему.aClient : ClientAccountManageranAccount : AccountОператорnew Client()createAccount (aClient)addAccount()new Account()deposit()Рисунок 36. Пример диаграммы сценария открытия счета.Компоненты, участвующие во взаимодействии, изображаются прямоугольниками вверхудиаграммы.
От каждого компонента вниз идет вертикальная линия, называемая его линией•жизни. Считается, что ось времени направлена вертикально вниз. Интервалы времени, вкоторые компонент активен, т.е. управление находится в одной из его операций,представлены тонким прямоугольником, для которого линия жизни компонента являетсяосью симметрии.Передача сообщения или вызов изображаются стрелкой от компонента-источника ккомпоненту-приемнику. Возврат управления показан пунктирной стрелкой, обратной ксоответствующему вызову.Эти диаграммы используются достаточно часто, например, при детализации сценариев,входящих в варианты использования.
Пример такой диаграммы изображен на Рис. 36.Диаграммы взаимодействия (collaboration diagrams) показывают ту же информацию, чтои диаграммы сценариев, но привязывают обмен сообщениями/вызовами не к времени, а ксвязями между компонентами. Пример такой диаграммы представлен на Рис. 37.aClient : Client1.
new Client()2.1.1. new Account()3. deposit()anAccount : Account2.1. addAccount()Оператор2. createAccount (aClient)AccountManagerРисунок 37. Диаграмма взаимодействия, соответствующая диаграмме сценария на Рис. 36.•На диаграмме изображаются компоненты в виде прямоугольников и связи между ними.Вдоль связей могут передаваться сообщения, показываемые в виде небольших стрелок,параллельных связи. Стрелки нумеруются в соответствии с порядком происходящихсобытий. Нумерация может быть иерархической, чтобы показать вложенность действийдруг в друга (т.е.
если вызов некоторой операции имеет номер 1, то вызовы,осуществляемые при выполнении этой операции, будут нумероваться как 1.1, 1.2, и т.д.).Диаграммы взаимодействия используются довольно редко.Диаграммы состояний (statechart diagrams) показывают возможные состояния отдельныхкомпонентов или системы в целом, переходы между ними в ответ на какие-либо события ивыполняемые при этом действия.Состояния показываются в виде прямоугольников с закругленными углами, переходы — ввиде стрелок.
Начальное состояние представляется как небольшой темный кружок,конечное — как пустой кружок с концентрически вложенным темным кружком. Вы моглиобратить внимание на темный кружок на диаграмме деятельности на Рис. 35 — он тожеизображает начальное состояние: дело в том, что диаграммы деятельности являютсядиаграммами состояний специального рода, а деятельности — частный случай состояний.Пример диаграммы состояний приведен на Рис.
38.Состояния могут быть устроены иерархически: они могут включать в себя другиесостояния, даже целые отдельные диаграммы вложенных состояний и переходов междуними. Пребывая в таком состоянии, система находится ровно в одном из его подсостояний.На Рис. 38 почти все изображенные состояния являются подсостояниями состояния Site.Кроме того, в нижней части диаграммы три состояния объединены, чтобы показать, чтопереход по действию cancel возможен в каждом из них и приводит в одно и то жесостояние Basket.Рисунок 38.
Пример диаграммы состояний, моделирующей сайт Интернет-магазина.Состояние может декомпозироваться и на параллельные подсостояния. Они изображаютсякак области внутри объемлющего состояния, разделенные пунктирными линиями, иханалогом на диаграммах деятельности являются дорожки. Пребывая в объемлющемсостоянии, система должна находиться одновременно в каждом из его параллельныхподсостояний.Помимо показанных на диаграмме состояний изображаемая подсистема может иметьглобальные (в ее рамках) переменные, хранящие какие-то данные. Значения этихпеременных являются общими частями всех изображаемых состояний.На Рис. 38 примерами переменных являются список видимых пользователем товаров,items, и набор уже отобранных товаров с количеством для каждого, корзина, basket.Переходы могут происходить между состояниями одного уровня, но могут также вести изнекоторого состояния в подсостояние соседнего или, наоборот, из подсостояния внекоторое состояние, находящее на том же уровне, что и объемлющее состояние.На переходе между состояниями указываются следующие данные:o Событие, приводящее к выполнению этого перехода.
Обычно событие — это вызовнекоторой операции в одном из объектов или приход некоторого сообщения, хотямогут указываться и абстрактные события.Например, из состояния Categories на Рис. 38 можно выйти, выполнив командубраузера «Назад». Она соответствует событию back, инициирующему переход всостояние Start page. Другой переход из состояния Categories происходит привыборе категории товаров пользователем. Соответствующее событие имеет параметр —выбранную категорию. Оно изображено как choose(category).o Условие выполнения (охранное условие, guardian). Это условие, зависящее отпараметров события и текущих значений глобальных переменных, выполнениекоторого необходимо для выполнения перехода.
При наступлении нужного событияпереход выполняется, только если его условие тоже выполнено.Условие перехода показывается в его метке в квадратных скобках.На Рис. 38 примером условного перехода является переход из состояния Basket всостояние Payment Method. Он выполняется, только если пользователь выполняеткоманду «Оплатить» (событие buy) и при этом в его корзине есть хотя бы один товар.o Действие, выполняемое в дополнение к переходу между состояниями. Обычно этовызовы каких-то операций и изменения значения глобальных переменных.Действие показывается в метке перехода после слеша (символа ‘/’). При этомизменения значений переменных перечисляются в начале, затем, после знака ‘^’,указывается вызов операции.Например, на Рис. 38 при выборе пользователем категории товаров происходит переходиз состояния Categories в Items list.
При этом список товаров, видимыйпользователю, инициализируется списком товаров выбранной категории.Диаграммы состояний используются часто, хотя требуется довольно много усилий, чтобыразработать их с достаточной степенью детальности.Литература к Лекции 6[1] Л. Басс, П. Клементс, Р. Кацман. Архитектура программного обеспечения на практике.СПб.: Питер, 2006.[2] IEEE Std 1016-1998 Recommended Practice for Software Design Descriptions.[3] IEEE 1471-2000 Recommended Practice for Architectural Description of Software-IntensiveSystems.[4] R. Kazman et al. SAAM: A Method for Analyzing the Properties of Software Architectures.Proceedings of the 16-th International Conference on Software Engineering, 1994.[5] Г. Буч, Дж.
Рамбо, А. Джекобсон. Язык UML. Руководство пользователя. М.: ДМК, 2000.[6] Дж. Рамбо, А. Якобсон, Г. Буч. UML: Специальный справочник. СПб.: Питер, 2002.[7] М. Фаулер, К. Скотт. UML в кратком изложении. М.: Мир, 1999.[8] И. Соммервилл. Инженерия программного обеспечения. М.: Вильямс, 2002.[9] Э. Дж. Брауде. Технология разработки программного обеспечения. СПб.: Питер, 2004..