Общая структура языка UML

Лекция 1 УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML ОБЩАЯ СТРУКТУРА ЯЗЫКА UML   С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей, таких как: Семантика языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML. Нотация языка UML. Представляет собой графическую нотацию для визуального представления семантики языка UML.    Семантика определяется для двух видов объектных моделей: структурных моделей и моделей поведения. Структурные модели, известные также как статические модели, описывают структуру сущностей или компонентов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения. Модели поведения, называемые иногда динамическими моделями, описывают поведение или функционирование объектов системы, включая их методы, взаимодействие и сотрудничество между ними, а также процесс изменения состояний отдельных компонентов и системы в целом.      Формальное описание самого языка UML основывается на некоторой общей иерархической структуре модельных представлений, состоящей из четырех уровней: Мета-метамодель Метамодель Модель Объекты пользователя МЕТА-МЕТАМОДЕЛЬ  Уровень мета-метамодели образует исходную основу для всех метамодельных представлений. Мета-метамодель определяет модель языка UML на самом высоком уровне абстракции и является наиболее компактным ее описанием. С другой стороны, мета-метамодель может специфицировать несколько метамоделей, чем достигается потенциальная гибкость включения дополнительных понятий. Главное предназначение этого уровня состоит в том, чтобы определить язык для спецификации метамодели. Примерами понятий этого уровня служат метакласс, метаатрибут, метаоперация. МЕТАМОДЕЛЬ   Метамодель является экземпляром или конкретизацией мета-метамодели. Главная задача этого уровня - определить язык для спецификации моделей. Данный уровень является более конструктивным, чем предыдущий, поскольку обладает более развитой семантикой базовых понятий. Все основные понятия языка UML - это понятия уровня метамодели. Примеры таких понятий - класс, атрибут, операция, компонент, ассоциация и многие другие. МОДЕЛЬ   Модель в контексте языка UML является экземпляром метамодели в том смысле, что любая конкретная модель системы должна использовать только понятия метамодели, конкретизировав их применительно к данной ситуации. Это уровень для описания информации о конкретной предметной области. Однако если для построения модели используются понятия языка UML, то необходима полная согласованность понятий уровня модели с базовыми понятиями языка UML уровня метамодели. Примерами понятий уровня модели могут служить, например, имена полей проектируемой базы данных, такие как имя и фамилия сотрудника, возраст, должность, адрес, телефон. При этом данные понятия используются лишь как имена соответствующих информационных атрибутов. ОБЪЕКТ   Конкретизация понятий модели происходит на уровне объектов. В настоящем контексте объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 1000000". ПРИМЕР ЧЕТЫРЕХУРОВНЕВОГО МЕТАМОДЕЛИРОВАНИЯ ПРОСТЫХ ЗАПИСЕЙ О КОТИРОВКАХ АКЦИЙ ДИАГРАММЫ UML ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (ПРЕЦЕДЕНТОВ) ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ  Понятие варианта использования (use case) впервые ввел Ивар Якобсон и придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта ИС. Моделирование вариантов использования Моделирование вариантов использования (прецедентов) традиционно разделяют на • бизнес-моделирование (диаграммы бизнес-прецедентов) • системное моделирование (диаграммы прецедентов). В бизнес-моделировании делается акцент на саму организацию, в системном моделировании - на разрабатываемую систему. Понятие Бизнес-моделирование Системное моделирование Вариант Описывает особенности использования бизнеса (прецедент, Use case) Описывает действия системы в контексте бизнеса Действующее лицо (субьект, роль, Actor) Внешнее по отношению к организации Внешнее по отношению к системе (но может принадлежать организации) Сотрудник (Business worker) Принадлежит организации Не используется Расширение языка UML для построения бизнес-систем С использованием механизмов расширения языка UML были введены дополнительные графические обозначения для бизнес-моделирования (The UML Profile for Business Modeling). Графические изображения бизнес-актера (а), бизнес-сотрудника (б) и бизнес-варианта использования (в) Диаграммы бизнес-прецедентов Бизнес-актер (business actor) – индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес-системой, но не входят в нее, т.е. не являются частью моделируемой системы (рис. а). Примерами бизнес-актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы. Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнеспроцесса моделируемой системы (рис. б). Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том, что они являются субъектами и входят в состав моделируемой системы. Бизнес-вариант использования (business use case) — вариант использования, определяющий последовательность действий моделируемой бизнес-системы, направленных на выполнение отдельного бизнес-процесса (рис. в). Общее свойство бизнесвариантов использования состоит в том, что они являются концептуальной моделью отдельных бизнес-процессов моделируемой бизнес-системы. Графические изображения бизнес-актера (а), бизнес-сотрудника (б) и бизнесварианта использования (в) Диаграмма бизнес-прецедентов для системы продажи товаров по каталогу ДИАГРАММА ПРЕЦЕДЕНТОВ (ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ) Диаграмма вариантов использования (прецедентов, use case) является исходной концептуальной моделью системы в процессе ее проектирования и разработки. Для изображения того факта, что все варианты использования относятся к одной системе, подсистеме или компоненту они размещаются внутри прямоугольника. ОПРЕДЕЛЕНИЯ Суть диаграммы вариантов использования (прецедентов): проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. Актером, эктором (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит разработчик. Прецедент или вариант использования (use case) служит для описания сервисов (услуг), которые система предоставляет актеру. Каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. Варианты использования (прецеденты) Для включения в диаграмму выбранные варианты использования (прецеденты) должны удовлетворять следующим критериям: • вариант использования (прецедент) должен описывать, ЧТО нужно делать, а не КАК; • вариант использования (прецедент) должен описывать действия с точки зрения Актера; • вариант использования (прецедент) должен возвращать актеру некоторое СООБЩЕНИЕ; • последовательность действий внутри варианта использования (прецедента) должна представлять собой одну НЕДЕЛИМУЮ цепочку. Спецификация прецедента Структура документа, описывающего прецедент, может варьироваться, однако, типичное описание должно содержать следующие разделы: • Краткое описание; • Участвующие субъекты; • Предусловия, необходимые для инициирования прецедента; • Детализированное описание потока событий, которое включает: - основной поток событий описывает, что должно происходить во время выполнения варианта использования в наиболее распространенном (типовом) случае. Основной поток можно разбить, чтобы показать подчиненные потоки событий; - альтернативные потоки событий описывают исключительные ситуации (например, ввод неправильного пароля или необходимость выполнения дополнительных действий). • Постусловия, определяющие состояние системы, по достижению, которого прецедент завершается. СПЕЦИФИКАЦИЯ ПРЕЦЕДЕНТА СПЕЦИФИКАЦИЯ ПРЕЦЕДЕНТА Например, в контексте банкомата можно было бы следующим образом описать прецедент ValidateUser(ПроверитьПользователя). Основной поток событий. Прецедент начинается, когда система запрашивает у клиента его персональный идентификационный номер (PIN). Клиент ( Customer) может ввести его с клавиатуры. Завершается ввод нажатием клавиши Enter. После этого система проверяет введенный PIN и, если он правильный, подтверждает ввод. На этом прецедент заканчивается. Альтернативный поток событий. Клиент может прекратить транзакцию в любой момент, нажав клавишу Cancel. Это действие начинает прецедент заново. Никаких изменений на счету клиента не производится. Альтернативный поток событий. Клиент может в любой момент до нажатия клавиши Enter стереть свой PIN и ввести новый. Альтернативный поток событий. Если клиент ввел неправильный PIN, прецедент запускается сначала. Если это происходит три раза подряд, система отменяет всю транзакцию и не позволяет данному клиенту снова начать работу с банкоматом в течение 60 секунд.   АКТЕРЫ Актером может быть другая система, с которой взаимодействует данная система. Например, системе резервирования авиабилетов необходимо взаимодействовать с внешним приложением для проверки кредитной карточки клиента. В этом случае действующим лицом становится внешнее приложение. Эта система не будет изменяться, поскольку не попадает в рамки текущего проекта, хотя и взаимодействует с проектируемой системой. Любые подобные системы, находящиеся вне разрабатываемого проекта, станут действующими лицами. АКТЕРЫ  Общепринятым графическим обозначением актера на диаграммах в нотации языка UML 2.0 является фигурка "проволочного человечка", под которой записывается обязательное имя актера (рис. а). Поскольку актер является специализацией классификатора, он может изображаться также символом прямоугольника с ключевым словом <>, записанным в форме стереотипа выше его имени (рис. б). Дополнительно в языке UML 2.0 допускается изображать актера в форме предложенной разработчиком пиктограммы, внешний вид которой, по мнению самого разработчика, более наглядно иллюстрирует характер выполняемой им роли (рис. в). ПРИМЕЧАНИЯ Примечания (notes) в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта. В качестве такой информации могут быть: комментарии разработчика (например, дата и версия разработки диаграммы или ее отдельных компонентов). Применительно к диаграммам вариантов использования примечание может носить самую общую информацию, относящуюся к общему контексту системы. ПРИМЕЧАНИЯ  Графически примечания обозначаются прямоугольником с "загнутым" верхним правым уголком. Внутри прямоугольника содержится текст примечания. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся, соответственно, несколько линий. Примечания могут присутствовать не только на диаграмме вариантов использования, но и на других канонических диаграммах. ОТНОШЕНИЯ МЕЖДУ АКТЕРАМИ И ВАРИАНТАМИ ИСПОЛЬЗОВАНИЯ     Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов использования. В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: Отношение ассоциации (association relationship) Отношение расширения (extend relationship) Отношение обобщения (generalization relationship) Отношение включения (include relationship) КРАТНОСТЬ ОТНОШЕНИЯ АССОЦИАЦИИ Каждый экземпляр варианта использования "Оформить кредит для клиента банка" может иметь в качестве своего элемента единственный экземпляр актера "Клиент банка". Т.е. при оформлении кредита в банке необходимо иметь в виду, что каждый конкретный кредит оформляется на единственного клиента этого банка. ОСНОВНЫЕ ФОРМЫ ЗАПИСИ КРАТНОСТИ ОТНОШЕНИЯ АССОЦИАЦИИ       Для диаграмм вариантов использования наиболее распространенными являются четыре основные формы записи кратности отношения ассоциации: Целое неотрицательное число (включая цифру 0) - количество экземпляров актеров или вариантов использования, которые могут выступать в качестве элементов отношения ассоциации, в точности равно указанному числу. Два целых неотрицательных числа, разделенные двумя точками и записанные в виде: "первое число .. второе число". Эту запись следует понимать как множество целых неотрицательных чисел, следующих в последовательно возрастающем порядке: [первое_число, первое_число+1, первое_число+2, ..., второе_число]. Два символа (число или 0 и символ *), разделенные двумя точками. Здесь символ "*"обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации. Единственный символ "*", который является сокращением записи интервала "0..*“ количество отдельных экземпляров данного компонента отношения ассоциации может быть любым целым неотрицательным числом. 0 означает, что для некоторых экземпляров соответствующего компонента данное отношение ассоциации может вовсе не иметь места. Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение, равное 1. ОТНОШЕНИЕ ОБОБЩЕНИЯ (НАСЛЕДОВАНИЯ)   Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется предком или родителем по отношению А, а вариант А - потомком по отношению к варианту использования В. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования. Эта линия со стрелкой имеет специальное название - стрелка "обобщение". Оформить заказ на приобретение товара Оформить заказ на приобретение компьютера ОТНОШЕНИЕ РАСШИРЕНИЯ    Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим (базовым) вариантом, функциональность которого при определенных условиях определяется как объединение функциональности этих вариантов. Отношение расширения является направленным. Если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А. Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет"). ОТНОШЕНИЕ РАСШИРЕНИЯ  Отношение расширения включает в себя некоторое условие и ссылки на точки расширения в базовом варианте использования. Чтобы расширение имело место, должно быть выполнено определенное условие данного отношения. Ссылки на точки расширения определяют те места в базовом варианте использования, в которые должно быть помещено соответствующее расширение при выполнении условия. ОТНОШЕНИЕ ВКЛЮЧЕНИЯ   Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А при достижении точки включения включает в себя функциональные свойства, заданные для варианта В. Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом "include" ("включает") ОСНОВНЫЕ ГРАФИЧЕСКИЕ ЭЛЕМЕНТЫ ДВИ UML 2.0 ОБЩИЕ ПРАВИЛА ПОСТРОЕНИЯ ДВИ  Не рекомендуется моделировать связи между действующими лицами (хотя допустимо в отдельных случаях для наглядности). По определению, действующие лица находятся вне сферы действия системы. Следовательно, коммуникации между ними тоже выходят за рамки разрабатываемой системы. Для описания связи между действующими лицами служат диаграммы деятельности. ОБЩИЕ ПРАВИЛА ПОСТРОЕНИЯ ДВИ  Нельзя моделировать прямые связи между двумя прецедентами (хотя допустимо моделирование включающих и расширяющих отношений). Диаграмма показывает доступные прецеденты, но не документирует порядок их выполнения, поэтому не требуется указывать ассоциации между прецедентами.  Любой прецедент должен инициироваться действующим лицом, т.е. стрелка должна быть направлена от действующего лица к прецеденту. Исключением являются включающие и расширяющие отношения. ОБЩИЕ ПРАВИЛА ПОСТРОЕНИЯ ДВИ Базу данных рекомендуется считать уровнем, находящимся ниже всей диаграммы прецедентов. Можно ввести информацию в базу данных в одном прецеденте, а затем получить эту информацию в другом прецеденте. В этом случае информационный обмен между двумя прецедентами не нужно показывать ассоциацией, а следует отразить в Предусловии и Постусловии. ПОРЯДОК ПОСТРОЕНИЯ ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ    выделить группы действующих лиц (работающих с системой поразному, часто из-за различных прав доступа); идентифицировать как можно больше вариантов использования (функций, которые могут выполнять пользователи). При этом не следует делить функции слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат. Например, кассир может «продать товар» (это будет являться прецедентом), однако «ввод штрихкода товара для получения цены» самостоятельным прецедентом не является; дополнить прецеденты словесным описанием (сценарием). ДОПОЛНИТЕЛЬНЫЕ РЕКОМЕНДАЦИИ ПО РАЗРАБОТКЕ ДВИ 1. Рекомендуется вначале построить контекстную диаграмму, на которой отображаются основные варианты использования (функции) системы, а затем для каждого из них построить диаграммы декомпозиции (детализации). 2. Контекстная диаграмма может представлять собой несвязный граф. 3. Чрезмерная детализация вариантов использования не требуется. Следует помнить, что вариант использования – это относительно крупный блок функциональности системы. Для детализации в дальнейшем будут использоваться другие виды диаграмм, более подходящие для этой цели. 4. Для лучшего восприятия отдельная диаграмма (контекстная или декомпозиции) не должна быть перенасыщена элементами. Рекомендуется отображать на диаграмме не более 15 вариантов использования. 5. Располагать элементы следует так, чтобы была видна логическая последовательность выполнения вариантов использования и было минимум пересечений между отношениями. 6. На диаграммах не следует отображать особенности реализации вариантов использования и внутренней организации системы, связанные со спецификой используемых программных и аппаратных средств. Данные диаграммы в первую очередь предназначены для совместного с заказчиком определения функциональных требований к системе. Поэтому понимать (интерпретировать) отображенное на диаграммах и заказчик и разработчик должны одинаково. ОШИБКИ В ДВИ Ошибка визуализации отношений ОШИБКИ В ДВИ Ошибка визуализации отношений ОШИБКИ В ДВИ Ошибка использования отношений ОШИБКИ В ДВИ Ошибка визуализации и использования отношений ОШИБКИ В ДВИ