Описание требований в контексте модели прецендентов 5

Вид материала

Реферат

Содержание Общая структура языка uml Описание требований в контексте модели прецендентов Диаграмма взаимодействий (interaction diagram) Основания анализа требований Диаграммы состояний Диаграммы развертывания (deployment diagram) 1 Общая структура языка uml Нотация языка UML. Значки или пиктограммы. Графические символы на плоскости Строки текста. 2 Uml диаграммы 3. Описание требований в контексте модели прецендентов Индивидуальный пользователь – Пользователь системы Вариант использования или прецедент (usage case) Алгоритм выделения вариантов использования Краткое описание (Пояснения). Заинтересованные лица и их потребности Предусловия и постусловия ... Полное содержание

Подобный материал:

• Описание современной модели доступного и качественного образования в Хабаровском крае, 55.82kb.
• Управление образования Исполнительного комитета муниципального образования города Казани, 1092.92kb.
• Г. Р. Серебряков опыт построения динамической межотраслевой равновесной модели российской, 330.44kb.
• Наблюдаемое количество требований, которое, как мы предполагаем, представляет собой, 18.87kb.
• Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские, 512.06kb.
• Лекция: Этапы проектирования ис с применением uml: Основные типы uml-диаграмм, используемые, 209.83kb.
• О недостатках модели Большого взрыва, 337.97kb.
• Магистерской программы по направлению 210400. 68 Носов, 65.27kb.
• Волгоградская Государственная Сельскохозяйственная Академия Описание проекта Название, 103.32kb.
• Использование компьютерных технологий для разработки моделей бизнес-процессов, 62.95kb.

Унифицированный язык моделирования Unified Modeling Language

(UML)

Справочные материалы


ПРИЛОЖЕНИЕ 3

К МЕТОДИКЕ CETIN

Разработчики:	АО «НИТ» ТОО «Компания системных исследований «Фактор»» ОЮЛ «Казахстанская Ассоциация IT-Компаний»
Согласовано:	АО «Национальный инфокоммуникационный холдинг «Зерде»»

Астана, 2011

СОДЕРЖАНИЕ

	ВВЕДЕНИЕ	3
1	ОБЩАЯ СТРУКТУРА ЯЗЫКА UML	4
2	UML-ДИАГРАММЫ	5
3	ОПИСАНИЕ ТРЕБОВАНИЙ В КОНТЕКСТЕ МОДЕЛИ ПРЕЦЕНДЕНТОВ	5
4	ДИАГРАММ Ы ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ	12
5	ДИАГРАММА ВЗАИМОДЕЙСТВИЙ (INTERACTION DIAGRAM)	13
6	ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ	16
7	ОСНОВАНИЯ АНАЛИЗА ТРЕБОВАНИЙ	17
8	ДИАГРАММА КЛАССОВ	18
9	ДИАГРАММЫ СОСТОЯНИЙ	22
10	ДИАГРАММА КОМПОНЕНТОВ	24
11	ДИАГРАММЫ РАЗВЕРТЫВАНИЯ (DEPLOYMENT DIAGRAM)	26

ВВЕДЕНИЕ


Разработка унифицированного языка моделирования UML началась в конце 1994 года, когда Г.Буч и Дж.Рэмбо из Rational Software Corporation начали их работу по объединению методов Г.Буча и Дж.Рэмбо . Метод Буча (Booch'93) был ориентирован на моделирование программного обеспечения сложных систем. Метод Рамбо (ОМТ - Object Modeling Technique) был ориентирован на анализ процессов обработки данных в информационных системах.

Осенью 1995 года Ивар Якобсон и его компания Objectory присоединились к Rational Software и к этим усилиям по объединению методов с тем, чтобы интегрировать их в рамках метода OOSE (Object-Oriented Software Engineering), ориентированного на анализ требований к бизнес-приложениям,

Начиная работы по унификации, авторы методов решили сосредоточить свои усилия на достижении четырех целей:

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

Предпринятые Г.Бучем, Дж.Рэмбо и И.Якобсоном усилия привели к появлению в июне и октябре 1996 года документов, представляющих версии UML 0.9 и 0.91. В качестве языка моделирования UML выступает как язык для спецификации, визуализации, конструкции и документации программного обеспечения.

Важную роль в создании языка UML сыграла его поддержка Группой по управлению объектами OMG (Object Management Group). Группа OMG объединяет около 300 ведущих компьютерных фирм. Язык UML приобрел статус второго стратегического направления деятельности OMG. В 1997 г. были созданы версии языка UML 1.0 и 1.1.

В дальнейшем такие компании как IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies и Softeam присоединились к партнерам UML, предлагая некоторые свои идеи. В результате совместной работы с партнерами UML была предложена пересмотренная версия языка UML 1.1. Эта версия языка была представлена на рассмотрение OMG и была одобрена осенью 1997 года. В 1998 г была создана версия UML 1.2, а в 1999 г - версия UML 1.3.

В 2010 году опубликована последняя формальная спефицикация версия UML 2.3, в которой внедрен Object Constraint Language (OCL) язык определяющий правила для элементов модели

1 ОБЩАЯ СТРУКТУРА ЯЗЫКА UML


Описание языка UML состоит из двух взаимодействующих частей, таких как:

• Семантика языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.
  
• Нотация языка UML. Представляет собой графическую нотацию для визуального представления семантики языка UML.
  

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

В языке UML используется четыре основных вида графических конструкций:

• Значки или пиктограммы. Значок представляет собой графическую фигуру фиксированного размера и формы, которая не может увеличивать свои размеры для чтобы разместить внутри себя дополнительные символы.
  
• Графические символы на плоскости. Такие двумерные символы изображаются с помощью некоторых геометрических фигур и могут иметь различную высоту и ширину с целью размещения внутри этих фигур других конструкций языка UML.
  
• Пути, которые представляют собой последовательности из отрезков линий, соединяющих отдельные графические символы. Пути всегда соприкасаются с другими графическими символами на обеих границах соответствующих отрезков линий.
  
• Строки текста. Служат для представления различных видов информации в некоторой грамматической форме.
  

Язык UML имеет сложную иерархическую структуру, показанную на рис.1




Рисунок 1. Структура языка UML

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

Язык UML имеет четыре вида сущностей: структурные, поведенческие, группирующие и аннотационные сущности. Они показаны на втором уровне структурного дерева языка UML (рис.1).

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

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

2 UML ДИАГРАММЫ

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

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

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

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

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


3. ОПИСАНИЕ ТРЕБОВАНИЙ В КОНТЕКСТЕ МОДЕЛИ ПРЕЦЕНДЕНТОВ


Идея описания функциональных требований в виде прецендентов была сформулирована в 1986 г. Иваром Якобсоном (Ivar Jacobson)– одним из разработчиков UML.

Основными ее преимуществами были простота и полезность. Наиболее важный вклад в проблему определения сущности прецендентов и способа из описания внес Алистер Кокбурн (Alistair Cockburn)

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

Преценденты – это механизм упрощения этапа формулировки требований для всех заинтересованных лиц. По существу, это рассказы об использовании системы в процессе решения поставленных задач.

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

Сила механизма прецедентов состоит в возможности масштабировать уровень сложности и формальности описания в зависимости от реальных потребностей.

Рассмотрим задачу разработки информационной системы «Е-лицензирование». Опишем функциональные требования к системе в виде прцендентов.

В разрабатываемой информационной системе «Е-лицензирование» (далее Система) предполагается, что прием заявления для получения лицензии будет осуществляться через web-портал Министерства экономического развития и торговли. Пользователь для получения доступа к Системе регистрируется на портале и получает пароль. Администратор системы вводит нового пользователя в базу данных портала. Для ввода заявления на получение лицензии Заявитель должен загрузить в Систему пакет документов и заполнить электронную форму. В пакет документов входят: нотариально заверенные копии устава и свидетельства о государственной регистрации заявителя в качестве юридического лица - для юридического лица; копия документа, удостоверяющего личность - для физического лица; нотариально заверенная копия свидетельства о государственной регистрации заявителя в качестве индивидуального предпринимателя - для индивидуального предпринимателя; нотариально заверенная копия свидетельства о постановке заявителя на учет в налоговом органе; документ, подтверждающий уплату в бюджет лицензионного сбора за право занятия отдельными видами деятельности.

При заполнении формы необходимо указать код квитанции об оплате лицензии. Система выдает пользователю уникальный код заявки. Заполненная заявка попадает в соответствующий гос.орган (Учредительный орган) через Систему. Статус заявки изменяется с «Заявка отправлена» на «Заявка получена». Учредительный орган отправляет заявку на рассмотрение к эксперту, который рассматривает заявление и прикрепленный к нему пакет документов. В случае, если пакет документов неполный, то заявителю отправляется уведомление, в котором сообщается об этом. Если документация полная, то заявление и пакет документов передаются на рассмотрение лицензионной комиссии. При этом статус заявки на портале изменяется со статуса «Заявка доставлена» на «Заявка на в процессе рассмотрения».

Если комиссия приняла решение о выдаче лицензии, то эксперт инициирует смену статуса заявителя с «Заявка в процессе рассмотрения» на «Заявка рассмотрена» и «Лицензия получена». Заявителю предлагается распечатать квитанцию об оплате услуг и получить либо бумажную либо электронную форму документа. Система генерирует электронную версию лицензии в pdf-файле, который доступен заявителю в любое время через его профайл в ИС Е-лицензирование. Данный файл также доступен контролирующим органам и лицензиарам через базу данных Е-лицензирование. Через портал любой пользователь имеет возможность просмотра электронной версии, указав при этом реквизиты заявителя, например, ИНН. Система вносит данные о лицензии и заявителе в БД, которую может использовать лицензиар и контролирующие органы.

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

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

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

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

В случае принятия решения о приостановке действия лицензии эксперт использует интерфейс Системы для инициации процесса приостановления лицензии. Для этого он выбирает лицензианта в БД Системы и изменяет статус лицензии с «активная» на «остановлена». Затем отправляет письмо по электронной почте и через он-лайн форму извещает заявителя о причинах приостановки действия лицензии. Данные о приостановлении лицензии и ее причинах заносятся в БД лицензий.

В случае принятия решения об отзыве лицензии эксперт использует интерфейс Системы для инициации процесса отзыва лицензии. Для этого он должен выбрать заявителя из списка в БД лицензий и изменить статус лицензии с «активная» на «отозвана». Затем отправляет письмо по электронной почте и через он-лайн форму извещает заявителя о причинах отзыва лицензии. Данные об отзыве лицензии и ее причинах заносятся в БД лицензий.

Действующие лица

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

Действующие лица могут:

• Только снабжать информацией систему
  
• Только получать информацию из системы
  
• Снабжать информацией и получать информацию из системы.
  

В модель желательно включить краткое описание каждого ДЛ, в котором нужно указать роль ДЛ при взаимодействии с системой.

Действующими лицами (акторами) в модели информационной системы «Е-лицензирование» являются:

• Индивидуальный пользователь – предприниматель или его доверенное лицо;
  
• Администратор организации - уполномоченный сотрудник организации (администратор), который проводит регистрацию Заявителя непосредственно на портале системы с использованием пользовательского сертификата, выданного удостоверяющим центром;
  
• Пользователь системы – любое физическое или юридическое лицо, зарегистрировавшееся в систем. Является обобщением действующего лица Заявитель. Поскольку Пользователем Системы может быть как Заявитель, так и представитель контролирующего органа, лицензиат или любой пользователь, зарегистрировавшийся на портале и т.д.
  
• Заявитель - Физическое или юридическое лицо, обратившееся в соответствующий лицензиар с заявлением о выдаче лицензии и (или) приложения к лицензии. Является обобщением действующих лиц Администратор организации и Индивидуальный пользователь;
  
• Лицензиат - Физическое или юридическое лицо, имеющее лицензию
  
• Контролирующий орган – орган, контролирующий процесс выдачи и получения лицензии, например, Управление лицензиями
  
• Платежная система – банковская система, через которую производится оплата услуг за лицензирование;
  
• Портал - единая точка доступа к разнородным информационным ресурсам и приложениям;
  
• БД ИС – база данных информационной системы «Е-лицензирование»
  
• Администратор системы – сотрудник, отвечающий за работоспособность системы.
  
• Уполномоченный орган -Государственный орган, осуществляющий разработку и проведение государственной политики и координирующий деятельность других государственных органов в области лицензирования
  

Рисунок 2. Нотация UML для актора «Заявитель»


В UML вводится понятие обобщения действующих лиц (акторов), которе обеспечивает возможность внести поведение, общее для двух и более действующих лиц, в действующее лицо –родителя.

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

На более высоком уровне актор Пользователь системы является обобщением действующих лиц Заявитель, Лицензиант, Эксперт, Контролирующий орган.




Рисунок 3. Нотация UML для обобщения действующих лиц.


Варианты использования


Поведение системы – это ее реакция в ответ на внешние события. В языке UML внешне наблюдаемое и допускающее тестирование поведение фиксируется в виде прецендентов или вариантов использования.

Вариант использования или прецедент (usage case)–случай использования.

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

Алгоритм выделения вариантов использования:

1. выделить задачи (цели) пользователя
   
2. определить для каждой из них отдельный вариант использования
   

Имя варианта использования должно соответствовать названию задачи, например, задаче оформления заявления на получение лицензии должен соответствовать вариант использования «Подача заявки».

Более конкретно детали определяются в документе, называемом Поток событий. Обычно он содержит:

Развернутое описание прецендента (варианта использования):

• Краткое описание
  
• Предусловия
  
• Основной поток событий
  
• Альтернативный поток событий
  
• Постусловия
  

Рассмотрим эти основные части.

Краткое описание (Пояснения).

Вводные элементы

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

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

Заинтересованные лица и их потребности

Этот список играет более важную роль, чем кажется на первый взгляд. А.Кокбурн писал: «Система реализует соглашение между заинтересованными лицами. Поведение системы описывается с помощью вариантов использования… Вариант использования, как соглашение о поведении., включает все возможные аспекты поведения, связанные с удовлетворением запросов заинтересованных лиц». Начиная описание вариантов использования с описания заинтересованных лиц и их интересов, можно более точно определить функции системы.

Предусловия и постусловия

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

Результаты или постусловия

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

Основной поток событий или Основной сценарий

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

Основной поток событий (Основной сценарий)

Описываются следующие виды действий:

1. Взаимодействие между исполнителями
   
2. Верификация (обычно со стороны системы)
   
3. Изменение состояния системы
   

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




Рисунок 4. Нотация UML для варианта использования «Подача заявки»

Описание варианта использования «Подача заявки»


Краткое описание

Данный вариант использования позволяет Заявителю осуществить подачу заявления на получение лицензии путем заполнения электронной формы на Портале.

Предусловия

Заявитель должен быть зарегистрированным пользователем в Системе и предварительно оплатить налоговый сбор за получение лицензии.


Основной поток событий

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

В процессе заполнения формы заявитель должен:

• отсканировать необходимые документы и загрузить в форму через окно загрузки
  
• заполнить форму используя код квитанции оплаты лицензии
  

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

Заполненная заявка на получение лицензии попадает в Учредительный орган.

Постусловия

Система показывает изменение статуса заявки в профайле заявителя в системе (с «заявки отправлена» на «заявка получена»). Система при смене статуса заявки отправляет письмо извещение (уведомление) заявителю.

Система генерирует уникальный код Заявки и отправляет его заявителю.

Альтернативный поток событий

Если при проверке завершения подачи заявки по каким-либо причинам процесс не завершен, то выдается сообщение и вариант использования завершается.

Обобщения вариантов использования

Отношение обобщения между вариантами использования используется для того, чтобы показать, как один вариант использования может быть обобщен до другого, родительского варианта использования. Примером обобщения вариантов использования «Подача заявки на получение дубликата», «Подача заявки на переоформление лицензии», «Подача заявки на возобновление лицензии является вариант использования «Подача заявки»



Рисунок 5. Пример обобщения вариантов использования

4. ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ USE CASE DIAGRAM

Поведение разрабатываемой системы, то есть функциональность, обеспечиваемая системой, описывается с помощью функциональной модели, которая отображает системные прецеденты или варианты использования (use case) , системное окружение (действующих лиц или актеров) и связи между вариантами использования и актерами (диаграммы Вариантов использования -use case diagram).

Диаграмма вариантов использования (Use case diagram) – это графическое представление всех или части действующих лиц, вариантов использования и их взаимодействий в системе.

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

Диаграммы вариантов использования и их взаимосвязей имеют второстепенное значение при работе над прецедентами. Прецеденты – это текстовые документы. Работать над прецедентами – это значит составлять текстовые описания. В таком ракурсе диаграмма лишь иллюстрирует способы использования системы внешними пользователями.

В языке UML для вариантов использования и действующих лиц поддерживается несколько типов связей, это:

• Связи коммуникации (communicate) –описывающие связи между действующими лицами и вариантами использования. Может быть двусторонней (от действующего лица к варианту использования и от варианта использования к действующему лицу) и односторонней (от действующего лица к варианту использования или от варианта использования к действующему лицу). Изображается в виде стрелки. Направление стрелки показывает, кто инициирует коммуникацию
  
• Связи включения (include) и расширения (extend) –отражающие связи между вариантами использования. Различные прецеденты могут иметь одинаково функционирующие фрагменты. Связь включения позволяет одному варианту использования использовать функциональность другого. Она изображается в виде стрелки и слова << include >> .
  
• Связь расширение позволяет варианту использования только при необходимости применять функциональные возможности, предоставляемые другим вариантом использования. Изображается в виде стрелки от дополнительно прецедента к базовому и слова <> (расширение).
  
• Обобщения действующего лица (actor generalization) – между действующими лицами. Такие связи показывают, что у нескольких действующих лиц имеются общие черты. Если обобщение действующих лиц представляет полезную информацию, то включайте это в диаграмму, если нет, то не стоит включать их в обобщение
  

При описании бизнес-процесса «Регистрация на портале» может быть составлена следующая локальная диаграмма вариантов использования:




Рисунок 6. Локальная диаграмма вариантов использования


5. ДИАГРАММА ВЗАИМОДЕЙСТВИЙ (INTERACTION DIAGRAM)


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

Взаимодействие – представляет собой набор сообщений, свойственных поведению некоторой системы, которыми обмениваются объекты в соответствии с установленными между ними связями.

Диаграмма взаимодействий (interaction diagram) – описывает взаимодействия, состоящие из множества объектов и отношений между ним, включая сообщения, которыми они обмениваются.

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

Диаграмма последовательностей (sequence diagram) – это диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений, графически представляющая собой таблицу, объекты которой располагаются вдоль оси Х, а сообщения – в порядке возрастания – вдоль оси У. В UML объект на диаграмме последовательностей обозначается прямоугольником, содержащим подчеркнутое название объекта. Каждый объект имеет свою временную линию, изображаемую пунктиром под объектом. Последовательности сообщений располагаются сверху вниз по вертикали. Каждая вертикальная линия является линией жизни.

Сообщения, передаваемые между объектами, изображаются стрелками, направленными от клиента-отправителя сообщения к поставщику –получателю сообщения.



Рисунок7. Диаграмма последовательности «Регистрация на портале»


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

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

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

.

Рисунок 8. Диаграмма кооперации «Регистрация на портале»

6. ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ

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

Диаграмма деятельности (Activity diagram)-показывает поток перехода от одной деятельности к другой.

Деятельность – это продолжающийся во времени неатомарный шаг вычислений в автомате.

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

Диаграмма деятельности состоит из:

• Состояний деятельности и состояний действия
  
• Переходов
  
• Объектов
  

Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние деятельности или действия. Для описания потока управления используются переходы (transaction) - показывающие путь от одного состояния действия /деятельности в другое. Такие переходы называются нетриггерными., поскольку управление по завершении работы в исходном состоянии немедленно передается дальше.

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

Можно встретить и параллельно выполняемые потоки, что характерно для моделирования бизнес-процессов. В UML для организации таких потоков используется синхронизация. Точка слияния представляет собой механизм синхронизации нескольких параллельных потоков выполнения- каждый из них ждет, пока все остальные достигнут этой точки, после чего выполнение продолжается в рамках одного процесса. В эту точку входят один или несколько переходов, а выходит один.




Рисунок 9. Диаграмма активности «Просмотр статуса лицензии»


7. ОСНОВАНИЯ АНАЛИЗА ТРЕБОВАНИЙ


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

Под объектом понимается некоторая сущность (реальная или абстрактная) конкретной предметной области, обладающая состоянием, поведением и индивидуальностью.

Объект –это термин, описывающий реальные, конкретные предметы.

Состояние объекта характеризуется перечнем всех его возможных (обычно статических) свойств и значениями каждого из этих свойств (обычно динамических). Состояние объекта описывается его переменными.

Данные объекта называются его атрибутами. Атрибут –свойство объекта. Хотя их значения меняются время от времени, сами атрибуты остаются неизменными.

Поведение объекта (или его функциональность) характеризует то, как объект взаимодействует с другими объектами или подвергается взаимодействию других объектов, проявляет свою индивидуальность. Поведение объекта представляется его операциями.

Индивидуальность - это такие свойства объекта, которые отличают его ото всех других объектов. Индивидуальность означает, что каждый объект уникален.

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

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

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

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

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


8. ДИАГРАММА КЛАССОВ


Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов, интерфейсов, коопераций , а также связей (отношений) между ними.

Диаграммы классов содержат:

• Классы
  
• Интерфейсы
  
• Кооперации
  
• Отношения зависимости, обобщения и ассоциации
  

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

1. для моделирования словаря системы. Моделирование словаря системы предполагает принятие решения о том, какие абстракции являются частью системы, а какие –нет.
   
2. Для моделирования простых коопераций. Кооперация – это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения, более значимого, чем простая сумма составляющих его элементов.
   
3. Для моделирования логической схемы базы данных. Логическую схему можно представлять как чертеж концептуального проекта БД.
   

Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой.

Графически класс изображается в виде прямоугольника. Классы характеризуются: именем, атрибутами и операциями. У каждого класса должно иметься имя (текстовая строка), уникально отличающее его ото всех других классов.

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

Следуя этим рекомендациям, определим для Системы «Е-лицензирование» восемь классов анализа:

• Пользователь
  
• Заявитель
  
• Заявка
  
• Документ
  
• Квитанция
  
• Лицензия
  
• Уведомление
  
• Заключение
  

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

Класс может иметь любое число атрибутов (в частности, не иметь ни одного атрибута).



Рисунок 10. Нотация UML для класса «Лицензия» с указанием атрибутов


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

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

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

Операции реализуют связанное с классом поведение. Операция включает три части –имя, параметры и тип возвращаемого значения. Параметры –это аргументы, получаемые операцией «на входе». Тип возвращаемого значения – результат действия операции.

Нотация операции в UML:

Имя Операции (аргумент1:тип данных аргумента 1, аргумент2:тип данных аргумента 2, …); тип возвращаемого значения

Рисунок 11. Класс «Лицензия» с присвоенными операциями

Добавление аргументов к операциям

Аргументы, или параметры, операции –это получаемые ею входные данные. Например операция СЛОЖИТЬ может иметь два параметра Х и У и складывать их. При желании можно задавать значения аргументов по умолчанию. Тогда нотация UML будет иметь вид:

Имя операции (аргумент1: тип данных аргумента 1= значение по умолчанию аргумента 1):тип возвращаемого значения операции)


Связи

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

• зависимость (dependency),
  
• обобщение (generalization)
  
• ассоцирование (association).
  

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

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

Объекты класса-потомка могут использоваться везде, где могут использоваться объекты класса-предка. Это свойство называют полиморфизмом по включению, имея в виду, что объекты потомка можно считать включаемыми в класс-предок. Графически обобщения изображаются в виде сплошной линии с большой незакрашенной стрелкой, направленной к суперклассу.

Одиночное наследование является достаточным в большинстве практических случаев применения связи-обобщения. Однако в UML допускается и множественное наследование, когда один подкласс определяется на основе нескольких суперклассов.

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

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

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

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

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

Кратностью (multiplicity) роли ассоциации называется характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации (в UML экземпляр ассоциации называется соединением – link). Наиболее распространенным способом задания кратности роли ассоциации является указание конкретного числа или диапазона. Например, указание «1» говорит о том, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, причем в каждом экземпляре ассоциации может участвовать ровно один объект класса с данной ролью.


Таблица 1-Значения множественности

Множественность	Multiplicity	Значение
*	N	Много
0	Zero	Нуль
1	One	Один
0..*	Zero or More	Нуль или несколько
1..*	One or More	Один или несколько
0..1	Zero or One	Нуль или один

Рисунок 12. Связи на диаграмме классов


Стереотип – механизм, используемый для создания нового элемента моделирования (для создания новых типов классов). Стереотип класса указывается под его именем и заключается в двойные скобки « stereotype» .

Основные стереотипы:

• Граничные классы (boundary classes )()
  
• Классы-сущности (entity classes)()
  
• Управляющие классы (control classes)()
  

Класс-сущность используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы.

Граничные классы обеспечивают взаимодействие между окружающей средой и внутренними элементами системы.

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





Рисунок 13. Диаграмма классов с указанием стереотипов


9. ДИАГРАММЫ СОСТОЯНИЙ


На диаграмме состояний отображают жизненный цикл одного объекта, начиная с момента его создания и кончая разрушением.

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

Состояние (state) –это некое положение в жизни объекта, при котором он удовлетворяет определенному условию, выполняет некоторое действие или ожидает события.

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

Переходы между состояниями

Переходы (state transitions) – представляют собой смену исходного состояния последующим (которое может быть тем же, что и исходное).

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

Особые состояния

Есть два особых состояния на диаграмме состояний -это начальное (Start state)и конечное (Stop state).

Каждая диаграмма может иметь одно и только одно начальное состояние, т.к. объект может находиться в целостном состоянии сразу после его создания.

Объект может иметь несколько конечных состояний.

Параметры переходов

С переходом между состояниями может быть связано условие (guard condition) и/или действие (action). Переход может вызвать также событие (event).

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

И действие, и проверка условий представляют собой поведение объекта и обычно реализуются в виде операций.

Нотации UML для параметров перехода:

Название события [граничное условие]/действие

Название класса.Отправка сообщения

Параметры состояний

Действия, сопровождающие возможные переходы в определенное состояние, можно рассматривать как входные действия (entry action) для этого состояния.

И наоборот, действия, сопровождающие переходы из данного состояния, являются для него выходными (exit action).

Поведение, возникающее внутри состояния называется деятельностью (activity)

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


Р
исунок 14. Нотация UML для параметров состояний


10. ДИАГРАММА КОМПОНЕНТОВ (COMPONENT DIAGRAM)


Компонентом (Component) – называется физический модуль кода.

Компонентами бывают как библиотеки исходного кода, так и исполняемые файлы. Например, в С++ файл тела класса (.СРР) и заголовочный файл (.Н) будут отдельными компонентами. После создания компонентов их помещают на диаграмму классов. Единственный тип связи между компонентами – это связи.

Диаграммой компонентов (Component diagram) –называется диаграма, на которой показаны компоненты системы и связи между ними.

На такой диаграмме можно видеть исходный код и исполняемые компоненты системы.

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

Component (Компонент) –соответствует программному модулю с хорошо определенным интерфейсом.




Рисунок 15. Нотация UML для компонента


В поле Stereotype окна спецификации можно определить его тип (ActiveX, Applet, Application, DLL, исполняемый файл и др.) С помощью таких диаграмм удобно моделировать динамику поведения класса. Как правило, диаграммы состояний не требуется создавать для каждого класса, многие проекты обходятся и без них.

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




Рисунок 16. Нотация UML для спецификации и тела подпрограммы


Subprogram specification and Body (спецификация и тело подпрограммы) – представляют видимую спецификацию подпрограммы и тело ее реализации. Обычно подпрограмма состоит из коллекции стандартных программных компонентов и не содержит определений класса.

Main Program (Главная программа) –файл, содержащий корень программы.




Рисунок 17. Нотации UML для главной программы, спецификации и тела пакета


Package Specification and Body (Спецификация и тело пакета) Пакет в данном случае –это реализация класса. Спецификацией пакета является заголовочный файл со сведениями о прототипах функций. На С++ это файл с расширением .Н Тело пакета содержит код операций класса. На С++ это файл с расширением .СРР ,

Task Specification and Body (Спецификация и тело задачи) – изображают пакеты, имеющие независимые потоки управления. Исполняемый файл обычно представляют как спецификацию задачи с расширением .ЕХЕ



Рисунок 18. Нотации UML для спецификации и тела задачи


Сlasses (Классы) – позволяет соотнести классы с компонентами. Это позволяет определить в каком физическом файле следует сохранить код класса. С каждым компонентом можно соотнести один или несколько файлов. В результате в логическом представлении после имени класса появится имя соответствующего компонента, заключенного в скобки.

Зависимости между компонентами

Единственно возможный тип связи между компонентами – это зависимость, означающая, что один компонент зависит от другого.

Зависимость между компонентами обозначается пунктирной линией, направление которой показывает направление зависимости : А B – компонент А зависит от компонента В, иначе: в компоненте А содержится класс, зависящий от какого-то класса в компоненте В.

Эти связи имеют значение при компиляции. А не может быть скомпилирован до В.

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




Рисунок 19. Диаграмма компонент


11. ДИАГРАММЫ РАЗВЕРТЫВАНИЯ (DEPLOYMENT DIAGRAM)


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

Процессором (processor) –называется любая машина, имеющая вычислительную мощность, т.е. способная производить обработку данных.

В эту категорию попадают серверы, рабочие станции и другие устройства, содержащие физические процессоры.

Добавление деталей к описанию процессора

В спецификации процессора можно добавить информацию о его стереотипе, характеристиках и планировании.

Стереотипы используются для классификации процессоров. Например, это могут быть компьютеры под управлением UNIX и другие ПК. Чтобы различать их, можно определить стереотипы.

Характеристики процессора – это его физическое описание. Оно может включать скорость компьютера и его память.

Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование процессов. Доступны следующие параметры:

Preemptive (С приоритетом) – высокоприоритетные процессы имеют преимущества перед низкоприоритетными

Non preemptive (без приоритета) - у процессов нет приоритета. Текущий процесс выполняется до своего завершения, после чего начинается следующий

Cyclic (циклический) - управление передается между процессами по кругу. Каждому процессу предоставляется определенное время на выполнение, затем управление переходит к следующему процессу.

Exucutive (Исполнительный) – существует некоторый вычислительный алгоритм, который управляет планированием процессов

Manual (Вручную) – процессы планируются пользователем.

Устройством (device) - называется аппаратура, не обладающая вычислительной мощностью. Например,это устройства ввода-вывода, принтеры, сканеры. Процессоры и устройства называются узлами (nodes) сети.

Как и в случае описания процессоров можно определять различные детали устройств. Это стереотипы, применяемые для классификации устройств и характеристики.

Добавление связей.

Связью (connection) – называется физическая связь между двумя процессорами, двумя устройствами или процессором и устройством.

Чаще всего связи отражают физическую сеть соединений между узлами сети.

Рисунок 20. Фрагмент Диаграммы компонент

Добавление процессов

Процессом (process)- называется поток обработки информации (execution) , выполняющийся на процесоре.

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

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