Определение прецедентов использования
Для описания функциональных требований к системе используется моделирование прецедентов. Разработку спецификаций программной системы начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемой программной системы и перечень отдельных аспектов ее поведения в процессе взаимодействия с конкретными пользователями (отдельные физические лица, взаимодействующие системы, источники и потребители информации различной физической природы). Функциональные требования к системе документируются во время разработки с помощью модели прецедентов использования, которая иллюстрирует планируемые функции системы (прецеденты использования), их окружение (актеров) и связи между ними [14].
Прецеденты — это подробные процедурные описания вариантов использования системы всеми заинтересованными лицами, а также внешними системами, т.е. всеми, кто (или что) может рассматриваться как актеры (асФгБ), иначе — действующие лица. По сути, прецеденты — это своего рода алгоритмы работы с системой с точки зрения внешнего мира. Прецеденты являются основой функциональных требований к системе. Они позволяют описывать границы проектируемой системы, ее интерфейс, а затем выступают в качестве основы для тестирования системы заказчиком с помощью приемочных тестов.
Актеры не являются частью системы, они представляют любые объекты, взаимодействующие с системой (пользователи, датчики, другие системы и др.). Актер может:
- • только вводить информацию в систему;
- • только получать информацию от системы;
- • вводить и получать информацию от системы.
Актеры выявляются на основании изучения предметной области, для которой предназначена разрабатываемая система, а также по результатам общения с заказчиком системы и экспертами. Для определения актеров в системе можно использовать следующие вопросы.
- • Кто заинтересован в данных требованиях?
- • Где будет применяться данная система?
- • Кто выигрывает от использования системы?
- • Кто обеспечивает систему информацией и применяет эту информацию, а также удаляет ее?
- • Кто занимается поддержкой системы?
- • Использует ли система внешние ресурсы?
- • Выполняет ли один человек несколько ролей?
- • Выполняют ли несколько человек одну и ту же роль?
- • Взаимодействует ли система с уже действующими системами?
Модель прецедентов использования — это диалог между актерами
и системой. Прецеденты использования представляют функциональность системы, т.е. то, какие возможности система предоставляет актерам. Набор прецедентов использования системы охватывает все способы ее применения.
Прецедент использования — это последовательность выполняемых системой транзакций, приводящих к измеримому результату, важному для конкретного актера.
Для определения прецедентов использования в системе можно использовать следующие вопросы.
- • Какую задачу выполняет каждый актер?
- • Будет ли актер создавать, сохранять, изменять, удалять или считывать информацию из системы?
- • В каком из прецедентов использования будет создаваться, сохраняться, изменяться, удаляться или считываться эта информация?
- • Потребуется ли актеру уведомлять систему о внезапных внешних изменениях?
- • Необходимо ли оповещать актеров о наступлении каких-либо событий в системе?
- • Какой прецедент использования будет поддерживать систему?
- • Могут ли все функциональные требования быть выполнены с помощью прецедентов использования?
В зависимости от цели выполнения конкретной задачи различают следующие варианты диаграмм использования:
- • основные, обеспечивающие выполнение функций проектируемой системы;
- • вспомогательные, обеспечивающие выполнение настроек системы и ее обслуживание;
- • дополнительные, служащие для удобства пользователя (реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).
В качестве примера рассмотрим построение диаграмм вариантов использования для проведения анализа функциональных требований и пользователей системы тестирования, которая является модулем обучающей системы. Система тестирования прежде всего требуется следующим заинтересованным лицам:
- • обучаемому (студенту);
- • составителю тестов (преподавателю);
- • преподавателю, принимающему экзамен;
- • сотруднику деканата, осуществляющему контроль за успеваемостью;
- • администратору сети и баз данных учебного заведения.
На начальном этапе создания системы можно ограничиться только двумя важными для разработчика системы ролями действующих лиц:
- • роль студента (тестируемого);
- • роль администратора (он же преподаватель, он же составитель тестов).
Соответственно основные прецеденты (варианты использования) для системы тестирования следующие.
Прецедент для студента:
• П1 — пройти тестирование.
Прецеденты для администратора:
- • П2 — создать (изменить) тест;
- • ПЗ — просмотреть результаты тестирования;
- • П4 — добавить (изменить) пользователей и др.
Каждый вариант использования можно описать кратко или подробно. Краткая форма содержит название, действующие лица, тип варианта (основной, вспомогательный, дополнительный) и его краткое описание. Для примера составим краткое описание варианта использования для прецедента П1 в форме следующей таблицы (табл. 5.1).
Таблица 5.1. Вариант использования для прецедента П1
Действующие лица (актеры)
Регистрация студента, запуск теста, выбор ответа из нескольких предложенных или ввод ответа, завершение теста, получение оценки
Подробное описание варианта использования для прецедента П1 может быть выглядеть следующим образом (табл. 5.2).
Таблица 5.2. Вариант использования Прохождение теста
1. Студент вводит свои данные (ФИО, группа), т.е. регистрируется в системе
2. Система создает на диске файл с результатом тестирования и предлагает выбрать тест
3. Студент выбирает тест
4. Система запускает тест
5. Студент последовательно отвечает на вопросы
6. Система регистрирует правильные и неправильные ответы
7. Студент завершает тестирование
8. Система подсчитывает процент правильных ответов
9. Студент ожидает результата
10. Система демонстрирует результат и предлагает его сохранить
11. Студент решает, сохранить результат или нет
12. Если выбрано сохранение, система запи-сывает результат в файл
13. Студент завершает работу
14. Система завершает работу
Для большей наглядности используют диаграммы вариантов использования. При этом используются обозначения, которые приведены на рис. 5.22. ((а) — актер, б) — вариант использования, в) — связь).
Рис. 5.22. Диаграмма варианта использования
Для приведенного описания прецедентов диаграмма может выглядеть так, как показано на рис. 5.23.
Естественно, все варианты использования сразу определить, как правило, не удается: новые варианты постоянно фиксируются по ходу разработки системы и даже в процессе эксплуатации. Но чем больше вариантов выявлено в процессе уточнения спецификаций, тем лучше, так как при этом получают более точную модель предметной области, что уменьшает вероятность ее пересмотра при добавлении функций.
Концептуальная модель (англ. — Conceptual model) — это определенное множество понятий и связей между ними, являющихся структурой рассматриваемой области. На диаграммы такой модели будут смотреть, их будут обдумывать, но с самой моделью ничего делать не будут. Это не означает, что модель не нужна, это означает, что модель используется только для управления мыслительным процессом, для понимания. Поэтому такие модели называются концептуальными [15].
Использование case-технологий для проектирования баз данных
Инструментальные средства, позволяющие в наглядной форме моделировать предметную область. Разработка приложений в соответствии с информационными потребностями пользователей. Case-средства создания, исполнения и проверки элементов архитектуры, дизайна.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | учебное пособие |
| Язык | русский |
| Дата добавления | 28.04.2017 |
| Размер файла | 160,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Производство измерений (наблюдений)
Занесение данных на бумажный носитель в источнике данных
Высылка данных и носителей в центр сбора
Составление документации на передаваемые данные
Заполнение форм отчетности
Составление акта экспертизы
Пересылка данных в промежуточный центр сбора
Сбор данных в промежуточном источнике
Производство наблюдений, заполнение книжек и журналов наблюдений
Подготовка справочной информации, создание схемы данных
Занесение данных на технический носитель
Обработка данных на ЭВМ
Контроль и корректировка данных
Прикладная обработка данных на месте
Комплектование данных на носителе
Копирование данных на сменный носитель для передачи в центр данных
Прием и контроль отчета в организации — владельце данных
Передача отчетных материалов в центр данных
Каталогизация, копирование, контроль физического состояния
Поиск, трансформация, прикладная обработка, передача, визуализация
Реализация действий, объяснение, обучение
5. Создание диаграмм прецедентов
Прецеденты, участвующие в создании БД, представлены на рис.4, идентификация исполнителей и прецедентов дана в табл.10. Описания прецедентов «Оплата по кредитной карточке» и «Оплата по договору» даны в табл.11 и 12. Рекомендации по созданию диаграмм включают:
— создание отдельных диаграмм для каждой системной операции;
— разбиение диаграмм на несколько, если она оказалась слишком сложной;
— использование в качестве отправной точки постусловий, указаний в описании операции, а также описание прецедентов;
— разработку диаграммы взаимодействия с учетом решения этих задач.
Рисунок 4 — Прецеденты БД
Определим транзакцию как объект, содержащий следующие пять компонент:
· СОБЫТИЕ в системе или ее внешнем окружении;
· СИГНАЛ к системе;
· ДЕЙСТВИЕ системы;
· ОТКЛИК от системы;
· ВЛИЯНИЕ на систему или ее окружение.
Например, в системе управления космическим кораблем прецедент может быть представлен как совокупность следующих компонент:
· СОБЫТИЕ — Диспетчер замечает, что корабль движется слишком быстро.
· СИГНАЛ — Замедлить скорость корабля на 210 м/сек.
· ДЕЙСТВИЕ — Определить какой из тормозных ракетных двигателей включить и на какое время.
· ОТКЛИК — Сигнал тормозному двигателю ракеты для его включения на 4.8 сек.
· ВЛИЯНИЕ — Корабль замедлил скорость до 210 м/сек.
Следующий пример относится к компании, устанавливающей газовое отопление на дачных участках:
· СОБЫТИЕ — Владелец дачи устал пилить и колоть дрова для камина и решил установить газовое отопление.
· СИГНАЛ — Информация о Владельце и его даче, а также дата начала обслуживания.
· ДЕЙСТВИЕ — Добавить данные о Владельце дачи в базу данных клиентов.
· ОТКЛИК — Разрешение на предоставление услуг.
· ВЛИЯНИЕ — В освободившееся от дровяных работ время Владелец дачи проектирует систему автоматизации газовой компании.
Рисунок 5 — Уточнение диаграммы авторизации
Диаграммы авторизации пользователей продемонстрированы на Рис.6.
Рисунок 6 — Диаграмма авторизации пользователей
Таблица 10 — Идентификация исполнителей и прецедентов
Влияет на безопасность
Разрешение (выдача пароля)
Влияет на безопасность
Представление меню для регистрации
Представление меню для входа в систему
Предоставление перечня услуг
Отметка об обращении к услуге
Влияет на развитие системы
Дает разрешение на оплату по:
— Списанию за счет ранее внесенной суммы
Влияет на прибыль
Таблица 11 — Описание прецедента «Оплата по кредитной карточке»
Пользователь выбрал услуги
Система подсчитывает стоимость выбранных услуг и выдает на экран
Пользователь принимает решение согласиться со стоимостью и сообщает информацию, необходимую для оформления оплаты по кредитной карточке (название карточки, ПИН код)
Система генерирует запрос на оформление оплаты по кредитной карточке т и отправляет его во внешнюю службу авторизации кредитов
Служба авторизации кредитов авторизует оплату
Система получает подтверждение на выплату платежа от службы авторизации, заносит информацию об оплате и подтверждение от службы авторизации. Система оплаты кредитов должна перечислить необходимую сумму на счет института
Таблица 12 — Описание прецедента «Оплата по хоздоговору»
Пользователь выбрал услуги
Система подсчитывает стоимость выбранных услуг и выдает на экран
Пользователь согласился со стоимостью
Система списывает со счета подсчитанную сумму
Пользователь не согласен со стоимостью
Система предлагает уточнить выбранные услуги
На рис.7 дан пример прецедента для проектирования Web портала.
Рисунок 7 — Прецедент Web портала — услуга
(пользователь выбирает, оплачивает и получает услугу)
Ранжирование прецедентов производится на основе следующих критериев, табл.13:
— оказывает существенное влияние на архитектуру системы;
— важность информации и внутренняя структура проекта обеспечивается за счет сравнительно небольших усилий;
— включает рискованные, сложные или срочные функции;
— требует дополнительного исследования или применения новой и ненадежной технологии;
— представляет основной экономический процесс;
— напрямую обеспечивает повышение эффективности.
Таблица 13 — Ранжирование прецедентов
Оплата стоимости услуг
Концептуальная модель должна помочь выделить типовой ход событий при работе с БД:
— пользователь вводит критерии запроса;
— СУБД анализирует критерии, сравнивает со значениями в БД и выдает на экран;
— пользователь просматривает результаты и, если его они не удовлетворяют, то он уточняет критерии запроса.
На основе концептуальной модели можно описать системные операции по форме табл.14 и выделить предположения и упрощения для прецедентов, табл.15.
Таблица 14 — Описание системной операции
Имя операции и ее параметры (словесное описание обязанностей данной операции)
Ввести (записать) данные
Имя типа (понятие, программный класс, интерфейс) — системная
Ссылка на функции системы
Использовать самый быстрый доступ к БД
Исключительная операция (Если значение параметра выходит за допустимые пределы, то выдать сообщение об ошибке)
Информация, не касающаяся интерфейса пользователя (например, число обработанных записей)
Предельные значения параметров заранее известны системе
Декларируемся изменения состояния объектов концептуальной модели (создание или удаление экземпляров, модификация атрибута, формирование и разрыв ассоциаций)
Предположения и упрощения
Рассматривается отдельный центр данных, не являющийся частью более крупной организации
Для каждого типа кредитной карточки задействована своя служба авторизации (банк, выдавший карточку)
Списание за счет ранее внесенных сумм
Поддерживается частичная оплата
Отметка об обращении
Сведения о всех запросах выполненных и невыполненных, регистрация в журнале
Сведения об услугах заносятся в отдельную таблицу
Таким образом, необходимо описать все процессы, прецеденты, операции. Факторами, требующими увеличения продолжительности цикла разработки, являются:
— проведение исследований, например, на разработку инфраструктуры;
— введение новой технологии или методов;
— отсутствие специалистов в предметной области;
— значительная распределенность процесса, конкуренция и согласование деятельности групп участников;
— появление новых сотрудников;
— параллельная работа групп участвующих в проекте;
— работа над проектом в распределенных коллективах;
— большие коллективы разработчиков.
Заключение
Для успешного использования case средств должны быть, прежде всего, адекватно описаны процессы сбора и обработки данных, построены полные и непротиворечивые функциональные модели БД. Накопленный к настоящему времени опыт проектирования БД показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов.
Case продукты имеют сходные черты, в число которых входят:
— поддержка создания логических моделей, не зависящих от СУБД, и генерации физических моделей на их основе;
— поддержка нескольких типов СУБД, включая не только серверные, но и настольные;
— поддержка специфических особенностей тех или иных СУБД ведущих производителей (генерация триггеров, управление физическим хранением данных);
— способность осуществлять обратное проектирование на основе либо имеющейся БД;
— возможность генерации отчетов и проектной документации на основе созданной модели;
— возможность сохранения модели в репозитарии, который во многих случаях может быть разделяемым;
— поддержка генерации кода для одного или нескольких средств разработки или языков программирования.
Успешное внедрение CASE-средств обеспечивает такие выгоды как:
— высокий уровень технологической поддержки процессов разработки и сопровождения БД;
— положительное воздействие на производительность программных средств, качество продукции, соблюдение стандартов, документирование;
— позитивность отдачи от инвестиций в CASE-средства.
CASE-средства не дают немедленный эффект, он может быть получен только спустя какое-то время. Реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение. CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.
Тенденциями развития CASE-инструментов являются:
— создание условий, снижающих степень свободы проектировщика и поддерживающих множество задач. Классическим примером такого подхода являются продукты, поддерживающие стандарты IDEF0 и обеспечивающие глубокую проработку проекта вплоть до генерации программного кода.
— охват лишь отдельные фрагментов проектного цикла и поставляет сервис для выражения «творческих» взглядов на проектирование.
В первом, узком, но глубоком подходе попытки усилить возможности инструмента в направлении получения программного кода приводят к ограничению множества типов отношений и объектов, которые можно описывать с использованием инструмента. Плата за такой сервис — предопределенная системная архитектура программного кода.
Второй — широкий, но мелкий подход, подразумевающий расширение множества отношений и объектов, реализуем только при разделении труда, когда «неглубокий» инструмент снабжается необходимыми интерфейсами для использования продуктов других разработчиков.
CASE средство нацелено на то, чтобы обеспечить возможность эффективного использования (выживаемости) БД; существенно снизить затраты на поддержку жизненного цикла системы. CASE обеспечивает построение моделей, и — на основе этих моделей — поддерживает построение конкретной реализации собственно программного обеспечения.
Ключами к успеху выполнения проекта с помощью case-средств являются эффективное взаимодействие между его участниками; стремление применять наиболее простые решения, отвечающие требованиям; использование обратной связи как можно чаще и, начиная с ранних стадий; критическая оценка собственных решений; понимание того, что все участники проекта могут вносить свой существенный вклад в проект.
- предпочитайте простоту (не вводите дополнительные свойства объектов, не требующиеся сегодня, архитектурные, аналитические требования должны быть как можно более простыми и понятными для всех заинтересованных лиц, не перегружайте диаграмму излишними деталями);
- обеспечивайте будущую работу (создавайте необходимую документацию по программному продукту и его поддержке);
- вносите изменения последовательно (сначала строите диаграмму высокого уровня и далее развивайте);
- привлекайте больше заинтересованных лиц — заказчиков, пользователей;
- обеспечьте быструю обратную связь с заказчиками, пользователями;
- знайте инструментальные средства создания БД;
- каждый участник разработки БД должен иметь возможность работать с case;
- тестируйте созданные модели данных;
- используйте стандарты именования для названий атрибутов, методов, отношений.
- обновлять модель данных нужно только при острой необходимости.
Список литературы
1. Вендров А.М. CASE — технологии. Современные методы и средства проектирования информационных систем. — М.: — Финансы и статистика, 1998. http://www.interface.ru/logworks/caset/glava4/glava4_1.htm
2. Ларман Крэг. Применение UML и шаблонов проектирования: Введение в объектно — ориентированный анализ и проектирование. — М. — Санкт-Петербург- Киев. 2001. — Издательский дом «Вильямс. — 496 с.
3. Новичков А. Система генерации проектной документации Rational SoDA // Журнал «КомпьютерПресс». 2001. № 10. www.compress.ru
4. Федоров А., Елманова Н. Средства проектирования данных // Журнал «КомпьютерПресс». 2001. — № 1.
Перечень вопросов для самопроверки
Какие case-средства Вы знаете?
Составьте список процессов, происходящих при создании БД
Какие события и операции происходят в подсистеме создания БД?
Что делают системные операции в подсистеме выполнения запросов?
Когда использование CASE-систем и технологий эффективно? Как это связано со способом получения прикладного программного обеспечения на предприятии — покупкой готового пакета или заказной разработкой?
Размещено на Allbest.ru
Подобные документы
Функционально-модульный и объектно-ориентированный подходы к разработке CASE-технологий, принцип алгоритмической декомпозиции с выделением функциональных элементов. Основные требования к блокам анализа, проектирования, реализации и инфраструктуры.
контрольная работа [17,0 K], добавлен 27.09.2010
Определение понятия CASE-технологий. Использование комплексного инструментария ER/Studio для создания логической и физической модели данных, генерирования баз данных на платформе СУБД Access. Процедура добавления атрибутов и сущностей, создания связей.
контрольная работа [2,2 M], добавлен 21.12.2011
Анализ структуры и методологии CASE-средств. Методологии проектирования, используемые в CASE-средствах. Основные понятия о системах электронного документооборота, их создание с помощью CASE-средств. Объектно-ориентированное и структурное проектирование.
курсовая работа [67,9 K], добавлен 18.07.2014
Использование CASE-средств для поддержки процессов создания и сопровождения информационных систем. Задачи графического редактора диаграмм, документатора и администратора проекта. Основные возможности IBM Rational Professional Bundle и IBM Rational Rose.
реферат [28,1 K], добавлен 30.05.2012
Создание базы данных, где будет храниться, обрабатываться вся необходимая информация. Построение с помощью CASE-средства Microsoft Visio концептуальной модели, дающая возможность отображения всех выделенных сущностей, их атрибутов и связи между ними/
курсовая работа [514,4 K], добавлен 29.11.2008
Этапы разработки модели базы данных: составление логической схемы и создание на ее основе физической формы графическим инструментарием Erwin. CASE-технологии для проектирования прикладного программного обеспечения и конфигурационного управления проектом.
контрольная работа [370,7 K], добавлен 03.01.2011
Возможности программы DBDesigner. Проектирование и реализация информационно-поисковой системы с помощью CASE-средства DBDesigner в среде Intranet. Этапы проектирования базы данных, установление соединения с базой данных на сервере, синхронизация.
2.4. Определение прецедентов (вариантов использования)
Диаграмма прецедентов служит для выявления и формального представления требований заказчика к проектируемой системе [10]. Диаграмма описывает, какие возможности будет предоставлять система конечному пользователю, какую будет предоставлять информацию, на какие запросы отвечать, какие будет генерировать отчеты. При этом механизм функционирования системы от пользователя скрыт и на диаграмме прецедентов не показывается.
В роли конечного пользователя может выступать человек (например, студент, покупатель или оператор) или техническое устройство (например, мобильный телефон, банкомат).
Разработку информационного или программного обеспечения начинают с анализа функциональных требований, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого ИС или ПО и особенности поведения ИС или ПО в процессе взаимодействия с конкретными пользователями.
Прецеденты (варианты использования – Use Cases) – это подробные процедурные описания вариантов использования системы всеми заинтересованными лицами, а также внешними системами. Заинтересованные лица и внешние системы рассматриваются как актеры (actors) – действующие лица (в переводной литературе могут называться акторами). Действующие лица могут называть сущностями системы. Термин «сущность» объединяет понятия субъект (сущность, производящая действия) и объект (сущность, над которой производятся действия). По сути, варианты использования — это алгоритмы работы с системой с точки зрения внешнего мира.
Прецеденты отражают функциональные требования к системе, описывают границы проектируемой системы, ее интерфейс, а затем выступают как основа для тестирования системы заказчиком с помощью приемочных тестов.
В зависимости от цели выполнения конкретной задачи различают следующие варианты использования:
— основные, обеспечивают выполнение функций проектируемой системы;
— вспомогательные, обеспечивают выполнение настроек системы и ее обслуживание;
— дополнительные, служат для удобства пользователя (реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).
Пример. Определить варианты использования и построить диаграммы вариантов использования для системы тестирования.
Система тестирования работает со следующими заинтересованными лицами: обучаемый и тестируемый (студент); составитель тестов и экзаменатор (преподаватель).
Основные прецеденты (варианты использования) будут следующие.
Прецедент для студента: П1 – пройти тестирование.
Прецеденты для преподавателя: П2 – создать/изменить тест; П3 – просмотреть результаты тестирования.
Вариант использования можно описать кратко или подробно. Краткая форма описания содержит название варианта использования, его цель, действующих лиц, тип варианта использования (основной, второстепенный или дополнительный) и его краткое описание.
Использование диаграммы прецедентов для проектирования информационной системы "Интересный маршрут" Текст научной статьи по специальности «Компьютерные и информационные науки»
Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Гусев А.А.
Выявлены значение и роль UML-диаграмм , предназначенных для проектирования информационных систем. Рассмотрены основные составляющие диаграммы прецедентов , а также приведен пример использования данного вида диаграммы при проектировании информационной системы «Интересный маршрут».
Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Гусев А.А.
USE OF PRECEDENTS DIAGRAM TO DE SIGN "INTERESTING ROUTE" INFORMATION SYSTEM
The article considers the importance and the role of UML -diagrams in the design of information systems. The basic concepts of the UML -diagram are considered. An example of usage of this type of diagrams in the design of the "Interesting route" information system is provided.
Текст научной работы на тему «Использование диаграммы прецедентов для проектирования информационной системы "Интересный маршрут"»
ИСПОЛЬЗОВАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ ДЛЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ «ИНТЕРЕСНЫЙ МАРШРУТ» Гусев А. А.
Донской государственный технический университет, Ростов-на-Дону, Российская Федерация
USE OF PRECEDENTS DIAGRAM TO DE SIGN "INTERESTING ROUTE" INFORMATION SYSTEM
Don State Technical University, Rostov-on-Don, Russian Federation
The article considers the importance and the role of 6ML-diagrams in the design of information systems. The basic concepts of the UML-diagram are considered. An example of usage of this type of diagrams in the design of the "Interesting route" information system is provided.
Keywords: information system, design, UML-diagrams, actors, precedents.
Выявлены значение и роль UML-диаграмм, предназначенных для проектирования информационных систем. Рассмотрены основные составляющие диаграммы прецедентов, а также приведен пример использования данного вида диаграммы при проектировании информационной системы «Интересный маршрут».
Ключевые слова: информационная система, проектирование, UML-диаграммы, актеры, прецеденты.
Введение. Проектирование — это важнейший этап в процессе создания информационной системы, с него должна начинаться ее «жизнь». На данном этапе определяются основные характеристики будущей системы, ее архитектура, компоненты, интерфейсы и их взаимосвязи между собой. Для перехода к данному этапу необходимо исследовать предметную область информационной системы, определить основных конкурентов и пользователей, установить задачи, которые будет решать информационная система.
В настоящее время существует множество средств проектирования информационных систем, одним из которых является UML-диаграмма. UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык широкого профиля, предназначенный для создания абстрактной модели или UML-модели некоторой информационной системы. UML использует графические обозначения, применяется в области разработки программного обеспечения [1].
UML не относится к языкам программирования, но на основе UML-моделей, в некоторых случаях, можно автоматически сгенерировать программный код. Основное предназначение этого языка — это визуализация, проектирование и документирование программных систем.
UML-диаграммы используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур. Язык UML позволяет разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для
представления общих понятий, сконцентрироваться на проектировании и архитектуре. Для моделирования динамических аспектов системы используются UML-диаграммы прецедентов. Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая из таких диаграмм показывает множество прецедентов, актеров и отношений между ними.
Основная часть. Диаграмма прецедентов — один из видов UML-диаграмм, который используется для создания модели системы с точки зрения прецедентов (вариантов использования). Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов.
Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и понимания их внутреннего устройства при обратном проектировании [2].
Актёры диаграммы — это набор ролей пользователя, который может быть человеком или системой, взаимодействующего с другой системой. Актеры диаграммы могут быть связанны друг с другом только в случае наследования.
Прецеденты диаграммы представляют собой действия, приводящие актера к конечному результату, которые выполняет система. Как правило, прецедент связан с непрерывным сценарием (последовательностью действий), в ходе которого актеры обмениваются данными с системой посредством определенного вида сообщений. Как правило, сценарий отображается на диаграмме прецедентов в определенном виде комментария, присущего UML-диаграммам. Один прецедент может участвовать сразу в нескольких сценариях.
Между прецедентами в UML-диаграмме образуются связи. Всего различается 3 типа связей:
1. Обобщение прецедента;
2. Включение прецедента;
3. Расширение прецедента.
При работе с UML-диаграммой прецедентов важно помнить несколько правил [3]:
1. Каждый прецедент должен относиться минимум к одному актеру;
2. Каждый прецедент имеет инициатора;
3. Каждый прецедент приводит к конечному результату.
Рассмотрим пример применения UML-диаграммы прецедентов на основе проектирования информационной системы «Интересный маршрут».
Информационная система «Интересный маршрут» будет разрабатываться под мобильную платформу Android. Основное ее назначение — обмен собственными маршрутами между пользователями. Предполагается, что информационная система обладает следующим набором функций:
1. Разграничение прав доступа;
2. Просмотр маршрутов следования;
3. Комментирование существующих маршрутов;
4. Возможность оценивать маршрут;
5. Добавление своих маршрутов;
6. Возможность поиска маршрута;
7. Определение местоположения пользователя.
Пользователь информационной системы может выполнять одну из трех ролей:
• Гость (неавторизованный пользователь системы);
• Основной пользователь системы (авторизованный пользователь);
В таблице 1 представлены все актеры системы и соответствующие им прецеденты [4]. Актеры расположены в порядке увеличения количества доступных ему задач. Актеры, указанные ниже, могут выполнять все функции актера, указанного выше, а также свои специфические функции.
Актеры и соответствующие им прецеденты
Гость Поиск маршрутов
Гость Просмотр информации по маршруту
Гость Просмотр комментариев маршрута
Гость Прохождение маршрута
Гость Продолжение незаконченного маршрута
Основной пользователь системы Управление профилем
Основной пользователь системы Управление маршрутом (добавление, редактирование, удаление)
Основной пользователь системы Добавление комментариев к маршрутам
Основной пользователь системы Оценка маршрута
Администратор Управление пользователями системы
Администратор Модерация информации маршрутов
Администратор Модерация комментариев
На рис. 1 представлена иМЬ диаграмма прецедентов информационной системы «Интересный маршрут».
Рис. 1. Диаграмма прецедентов информационной системы «Интересный маршрут»
Из рис. 1 видно, что каждый прецедент относится к определенному актеру. Большинство прецедентов включают в себя более детальные функции системы. Актеры (роли пользователя системы) наследуют друг друга, т. е. чем выше роль, тем больше действий может выполнять пользователь [5].
Так как информационная система «Интересный маршрут» разрабатывается под мобильную платформу Android, а средства разработки под данную мобильную платформу не поддерживают автоматическую генерацию кода на основе UML, невозможно рассмотреть все преимущества UML-диаграмм. Несмотря на это, использование данного вида диаграмм позволило подробнее рассмотреть взаимодействие пользователей системы между собой, а также определить действия, которые они могут выполнять в информационной системе, что в дальнейшем может повлиять на архитектуру всей системы в целом.
Заключение. Диаграммы прецедентов являются мощным средством проектирования информационных систем, которые предназначены, в первую очередь, для определения функциональных требований к системе. Данный вид диаграмм позволяет определить, как функции, позволяющие пользователю получить некоторый конечный результат от информационной системы, могут повлиять на ее архитектуру в целом, а также как при этом должны себя вести ее компоненты [6]. В некоторых языках программирования поддерживается автоматическая генерация кода на основе UML-диаграмм, что облегчает работу программистам. Нельзя не отметить и тот факт, что наличие визуальных схем работы проектируемой информационной системы облегчит задачу тестирования готового продукта в дальнейшем и позволит определить точность реализации требований пользователей.
1. Маклаков, С. В. Создание информационных систем с AIIFusion Modeling Suite / С. В. Маклаков. — Москва : Диалог-МИФИ, 2003. — 432 с.
2. Маклаков, С. В. BPWin и ERWin. CASE-средства для разработки информационных систем / С. В. Маклаков. — Москва : Диалог-МИФИ, 2000. — 256 с.
3. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Д. Рамбо, И. Якобсон. — Москва : ДМК Пресс, 2006. — 496 с.
4. Фаулер, М. UML. Основы / М. Фаулер. — Санкт-Петербург : Символ-Плюс, 2004. —