Канонические диаграммы языка uml.
В рамках языка UML все вышеописанные представления о модели сложной системы фиксируются в виде специальных графических конструкций. Называемых «Диаграммы».
Диаграмма – графическое представление совокупности элементов модели в виде связного графа, вершинам и ребрам которого приписывается определенная семантика.
На языке UML определены следующие виды канонических диаграмм:
Диаграмма прецедентов или вариантов использования (use-case Diagram) +
Диаграмма классов (Class D) +
Диаграмма последовательности (Sequence D)
Диаграмма кооперации (Collaboration D)
Диаграмма состояний (State chart D)
Диаграмма деятельности (Activity D)
Диаграмма компонентов (Component D) +
Диаграмма развертывания (Deployment D)
Плюсом отмечены те, которым мы уделим внимание на курсе.
Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы.
При этом Диаграмма прецедентов представляет собой наиболее общую концептуальную модель сложной системы и она является исходной для построения всех остальных диаграмм.
Диаграмма классов представляет логическую модель сложной системы и отражает ее статические аспекты структурного построения.
Диаграммы кооперации и последовательности представляют собой разновидности логической модели и отражают динамические аспекты функционирования сложной системы.
Диаграммы состояний и деятельности предназначены для моделирования поведения системы.
Диаграммы компонентов и развертывания служат для представления физических компонентов сложной системы и, поэтому они относятся к физической модели.
Интегральную модель можно представить в виде этих канонических диаграмм, при этом каждая диаграмма на каждом этапе уточняет и конкретизирует общую модель.
Рисунок: посередине кружочек «Интегральная модель сложной системы», вокруг лучики, каждый из которых идет в один из видов канонической модели, обрамленный прямоугольничком.
Элементы графической нотации диаграммы прецедентов.
Диаграмма прецедентов – исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки.
Ее создание имеет следующие цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
Сформулировать общие требования к функциональному поведению проектируемой системы.
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Подготовить исходную документацию для взаимодействия разработчиков системы с её заказчиками и пользователями
Прецедент – это рассказ об использовании системы в процессе решения поставленных задач. Прецеденты необходимо придумывать очень детально, т.к. их основная идея состоит в исследовании и формулировке функциональных требований, путем написания маленьких рассказов (историй) из жизни моделируемой системы. Эти рассказы или истории представляют собой сценарии использования системы. Таким образом, содержание прецедента может быть представлено в виде дополнительного пояснительного текста, который раскрывает смысл или семантику действий при выполнении данного прецедента. Такой пояснительный текст и получил название сценарий.
Сценарий – специальная последовательность действий или взаимодействий между исполнителями (актерами) и системой. Его также называют экземпляром прецедента. Он представляет собой один конкретный сценарий использования системы или один проход прецедента.
Прецедент – набор сценариев использования, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой для достижения ощутимого результата для конкретного исполнителя.
Важной особенность описания прецедента является их ориентация на цели и задачи пользователя. В процессе их описания необходимо задавать следующие вопросы:
Кто является пользователем системы?
Каковы типичные сценарии использования системы?
Каковы цели и задачи пользователей?
Такой взгляд на систему больше ориентирован на пользователя, чем обычный список системных требований.
На языке UML прецедент изображается в виде эллипса, а его имя представляет собой пояснительный текст в виде существительного или глагола, начинающегося с заглавной буквы. Каждый прецедент представляет собой отдельный сервис, который предоставляется моделируемой системой по запросу актера. Это означает, что прецедент определяет один из способов применения системы. При этом сервис (прецедент), который инициализируется по запросу актера, должен представлять собой законченную последовательность действий. Это означает, что после того, как система закончит обработку по запросу актера, она должна, возвратиться в исходное состояние, в котором она снова будет готова к выполнению следующих запросов.
Актер – любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. При этом актером или действующим лицом или исполнителем называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. Таким образом, это может быть человек, техническое устройство, программа или любая другая система, которая служит источником взаимодействия на моделируемую систему. Следовательно, важной особенность описания прецедентов является их ориентация на цели и задачи актеров, то есть прецедент служит для описания сервисов, которые система предоставляет актеру. Другими словами, прецедент определяет набор действий, совершаемых системой при общении с актером.
Существует 3 типа актеров или исполнителей, внешних по отношению к разрабатываемой системе:
Основной тип, его задачи выполняются с использованием системы (например, кассир). Его нужно идентифицировать, чтобы определить цели пользователя, на основе которых формулируются прецеденты.
Вспомогательный тип, он обслуживает систему, например, предоставляет информацию (например, система авторизации платежей в POS-system, любая внешняя база данных, совершающая обмен с нашей системой). Его нужно идентифицировать, чтобы определить внешние интерфейсы и протоколы.
Закулисный тип, секретное, невидимое, скрытое, неочевидное. Он заинтересован в реализации прецедента, но он не является ни основным, ни вспомогательным исполнителем (например, налоговая служба). Его нужно идентифицировать, чтобы удостовериться, что все интересы определены и удовлетворены.
Вопросы для идентификации актеров в системе:
Какие организации или лица будут использовать систему?
Кто будет получать пользу от использования системы?
Кто будет использовать информацию от системы?
Будет ли использовать система внешние ресурсы?
Может ли один пользователь играть несколько ролей при взаимодействии с системой?
Могут ли различные пользователи играть одну роль при взаимодействии с системой?
Будет ли система взаимодействовать с законодательными, исполнительными, налоговыми и другими органами?
На языке UML стандартно актер или исполнитель изображается в виде человечка, а его имя представляет собой строку текста в виде существительного, начинающегося с заглавной буквы. Например:
Для изображения актеров можно также использовать прямоугольник для изображения классов, со стереотипом <<actor>>.
Также можно использовать стандартные графические стереотипы языка UML:
