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

Унифицированный язык моделирования 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)–случай использования.

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

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

выделить задачи (цели) пользователя

определить для каждой из них отдельный вариант использования

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

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

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

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

Предусловия

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

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

Постусловия

Рассмотрим эти основные части.
^ Краткое описание (Пояснения).
Вводные элементы

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

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

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

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

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

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

Взаимодействие между исполнителями

Верификация (обычно со стороны системы)

Изменение состояния системы

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




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

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