Диаграмма вариантов использования uml страховая компания

компании

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

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

На
данное время наиболее популярными
являются разные решения, разработанные
на основе современных информационных
технологий. Для страховых компаний
рынок современных ІТ-технологий
предлагает разные по аппаратному составу
и программному обеспечению – от отдельных
систем, наборов приложений и модулей к
универсальным системам, которые
обеспечивают довольно полную автоматизацию
всех производственных, технологических
и вспомогательных процессов.

Так,
модульная информационная система
ІNSTRAS-4 предназначена для комплексной
автоматизации учета в страховых и
перестраховочных компаниях. Основное
назначение ІNSTRAS-4 – повышение
конкурентоспособности страховой
компании за счет важного улучшения
управляемости. Замыкает все данные и
все бизнес-процессы в страховой компании
в единое информационное пространство,
согласовывая и оптимизируя их. Обеспечивает
комплексную автоматизацию всех ключевых
отделов и служб страховой (перестраховочной)
компании. Представляет собой могущественный
инструмент преобразований и
совершенствования работы компании,
создания и вывода на рынок новых страховых
продуктов. Разрешает организовать
бесперебойный обмен информацией с
филиалами, агентствами и точками продаж.
Включает интерфейс к наиболее популярным
на украинском рынке программам
бухгалтерского учета. Допускает
минимальные расходы на приобретение,
внедрение, поддержку, сопровождение и
развитие.

Для
использования в страховом маркетинге
предлагается еще целый ряд программных
продуктов. Например, Marketіng Expert и БЕСТ
Маркетинг – для стратегического
планирования, Касатка и Маркетинг Микс
– для стратегического и оперативного
планирования. Программа Marketіng Analytіc
предназначена для анализа, прогноза,
планирования и содержит в себе элементы
CRM. Программа Sales Expert обеспечивает
управление прямыми продажами.
Специализированные программные продукты,
предназначенные для решения задач
планирования, имеют и другие встроенные
маркетинговые инструменты, используемые
для SWОТ-анализа и ряда других маркетинговых
операций в процессе обработки данных.
В той или иной мере вышеперечисленные
программные продукты можно применять
с целью прогнозирования и разработки
сценариев развития событий в интересах
решения маркетинговых задач страховой
компании.

Рынок
ІТ-технологий предлагает и другие
информационные решение. Например,
система Contact Manager является универсальным
средством администрирования рабочего
времени и управления системой сбыта.
Она позволяет эффективно контролировать
деловую активность сотрудников системы
продаж на всех уровнях руководства,
отслеживать историю контактов специалистов
агентской сети – от первого телефонного
звонка к заключению договора. Contact
Manager интегрирован с системой операционного
учета договоров. Возможна интеграция
с технологиями саll-центра, бизнес-планирования
и отчетности.

Новая
версия информационной системы UNІCUS EASY
ОСАГО v. 1.6. представляет собой
автоматизированное рабочее место (АРМ)
работника страховой компании и позволяет
выполнять следующие операции:
полнофункциональную продажу полисов
ОСАГО; урегулирование убытков; учет
бланков строгой отчетности; экспорт
данных в формате XML во внешние информационные
базы.

Система
ІCІ (Іnsurance Company Іnformatіon System), которая
выпускается фирмой T-systems, адаптируется
к разнообразнейшим бизнесам-моделям и
может рассматриваться как промежуточный
вариант между индивидуальным и стандартным
программным обеспечениями. В этой
системе комплексной автоматизации,
разработанной специально для страховых
компаний, есть такие современные функции,
как CRM, управление документооборотом,
ведение статистики и другие. Эта система
легко интегрируется с уже имеющимися
в страховой компании бэк-офисными
решениями. Программа Connect Іnsurance,
разработанная австрийской компанией,
работает по принципу “tіme to market” (процесс
от возникновения идеи о новом страховом
продукте до его выхода на рынок) и
модернизации системы продаж страховой
компании без внесения изменений в
существующую ІT архитектуру.

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

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

Разработка
информационной системы традиционно
проводится в три этапа: объектно-ориентированный
анализ предметной области; концептуальное,
логическое и физическое моделирование
информационной системы; программная
реализация разработанной модели.

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

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

Проектирование
начинается с формулирования требований
к разрабатываемой системе, определения
функций, которые она должна реализовывать,
и задач, которые она должна решать. На
основе этих данных формируется диаграмма
вариантов использования (рис.125). В нашем
случае диаграмма вариантов использования
(«прецедентов») основывается на
требованиях, функциях, задачах страховой
компании, которые должна выполнять
разрабатываемая система. Согласно
диаграмме, прецедент «Работа с данными»
является основой для прецедентов:
получение данных; введение данных;
модификация данных; просмотр данных;
контроль правильности введенных данных.

Прецедент
«Обработка данных» является основой
для прецедентов: просмотр данных; сверка
данных; формирование отчета; выдача
исходной информации.

Прецедент
«Работа с исходной информацией» является
основой для таких прецедентов: просмотр
данных; обработка исходной информации;
формирование отчетов.

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

Рисунок 125 – Диаграмма
вариантов использования

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

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

Рисунок 126 — Диаграмма ассоциаций
классов

Клиент-агент
передает записанные исходные данные
клиента-страхователя (страховой полис)
клиенту-оператору ввода, который, в свою
очередь, обрабатывает эти данные и
заносит в ПК (сохранение в базу). Также
клиенту-оператору ввода поступают
бухгалтерские данные от клиента-бухгалтера.
После того, как все данные обработаны
и сохранены в базе, клиент-оператор
ввода формирует исходную информацию
(в виде отчета определенной формы) и
передает клиенту-бухгалтеру для сверки.
В свою очередь, клиент-бухгалтер после
просмотра и обработки полученной
информации также формирует исходную
информацию (в виде отчета определенной
формы). Сформированные и обработанные
данные, как клиентом-оператором ввода,
так и клиентом-бухгалтером передаются
клиенту-группе конечных пользователей.
Вербальное описание процесса работы
страховой компании с клиентами разрешает
выделить следующие классы:
клиент-страхователь, клиент-агент,
клиент-оператор ввода, клиент-бухгалтер,
клиент-группа конечных пользователей,
входящие данные, исходящие данные. На
рис. 127 представлена детализация классов.

Рисунок 127 – Диаграмма детализации
классов

Диаграмма
последовательностей показывает измерение
времени по взаимодействию объектов
(рис. 128). В нашем случае фигурка представляет
страхователя (исполнителя), который
инициирует последовательность, хотя,
в принципе, эта фигурка не является
частью диаграммы последовательностей.
Объект «Оператор ввода» получает
сообщение от агента, после чего происходит
обработка полученных данных. В процессе
работы объект «Оператор ввода» получает
асинхронное сообщение от объекта
«Бухгалтер» (т.е. объект «Бухгалтер» не
ожидает ответа от объекта «Оператор
ввода»). После обработки данных объект
«Оператор ввода» передает данные объекту
«Бухгалтер» в виде синхронного сообщения,
т.е. ожидает ответ от объекта «Бухгалтер»,
а именно идет уточнение со стороны
объекта «Бухгалтер» в виде условия:
обработанные данные верны или обработанные
данные неверны. В случае данные неверны
— идет доработка, а в случае данные верны
— происходит отправление сообщения
конечному пользователю, т.е. группе
конечных пользователей.

Рисунок 128 – Диаграмма
последовательности

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

На
рис. 129 показана диаграмма кооперации
работы страховой компании. Диаграмма
описывает последовательность информации,
которая поступает объекту в виде
сообщения. В нашем случае некоторые
сообщения являются дочерними относительно
других. Они представлены с использованием
десятичной точки для обозначения уровня
вложенности. Так, объект «Оператор
ввода» может передать обработанные
данные объекту «Бухгалтер» только после
того, как получит бухгалтерские данные
от этого же объекта. Так как без
бухгалтерских данных невозможно
сформировать конечные данные. В свою
очередь, конечные данные объект «Группа
конечных пользователей» от объекта
«Оператор ввода» получает только после
передачи исходящих
данных от
объекта «Бухгалтер».

Рисунок 129 –
Диаграмма кооперации

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

Диаграмма
деятельности реально описывает все,
что происходит во время операции или в
процессе. В нашем случае диаграмма видов
деятельности разбивается на «плавательные
дорожки» – параллельные сегменты,
которые отвечают ролям (рис. 130).

Рисунок 130 – Диаграмма деятельности

На
диаграмме компонентов в нашем случае
для работы с данными необходим компонент
«Таблица», а для представления данных
таблицы – интерфейс «Работа с данными».
В свою очередь, работа с данными может
содержать просмотр данных, регистрацию
новых данных, редактирование данных,
формирование отчета по заданному
условию. Выделим следующие интерфейсы:
«Просмотр», «Редактирование», «Выбор»,
«Автоматический подбор» и «Отчет» (рис.
131).

Система
была реализована в среде программирования
Borland
Delphi
и внедрена в отделении страховой компании
[22-25]. Проведенный расчет экономической
эффективности показал, что срок
окупаемости системы составит 0,15 года.

Рисунок 131 – Диаграмма компонентов

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Содержание:

ВВЕДЕНИЕ

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

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

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

ГЛАВА 1 Аналитическая часть

1.1 Описание предметной области. Постановка задачи.

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

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

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

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

• расчет суммы взносов и подготовку к печати договора страхования;

• возможность выбора видов страхования из перечня действующих;

• составление перечня действующих договоров;

• формирование отчета по видам страхования;

• составление извещений клиентам об истечении сроков действия договоров в ближайшие две недели;

• подсчет и подготовка к печати отчета по итогам работы страховой компании за заданный период времени.

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

Область применения

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

Таблица 1

Определения, акронимы и сокращения

Возможности системы

Данная система предоставляет следующие виды работ:

• добавление информации о новых клиентах страховой фирмы;

• добавление новых видов страхования уже существующим в информационной базе клиентам;

• формирование данных для оценки статистики случаев ДТП клиентов;

• поиск наиболее подходящих параметров страхования;

• предоставление информации, необходимой для консультации клиентов

Формулировка проблемы

Таблица 2

Описание заинтересованных лиц и пользователей

Потенциальные потребители

Сотрудники, клиенты страховой фирмы.

Таблица 3

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

Таблица 4

Пользователи

Пользовательская среда

Распространенная операционная система Windows 7/Vista/XP

Интерфейс в виде таблиц, а так же специальных форм ввода данных.

Таблица 5

Основные потребности заинтересованных лиц/пользователей

1.2 Предлагаемые мероприятия по улучшению технологии решения задачи

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

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

Для данного способа также характерны следующие недостатки:

Невысокая скорость и точность выполнения расчетов.

Неэффективное использование рабочего времени.

Возможность потери важных документов (заявки, данные клиентов, договора)

Бюрократия – увеличивающийся «поток» бумажной работы.

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

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

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

Таблица 6

Возможности продукта

Проектные ограничения

Система должна функционировать в среде наиболее распространенных операционных средств, необходим доступ к сети интернет.

Стоимость проекта

Стоимость проекта не может превышать 1 000 000 рублей

Лицензирование и установка

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

Функциональные возможности продукта

Ввод данных в систему, поиск клиентов, анализ и оценка текущего состояния клиентов.

Вход в систему

Осуществляется по средствам вызова приложения и регистрации пользователя в системе.

Требования к качеству

Готовность:

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

Удобство использования:

работа с таблицами и формами ввода.

Сопровождаемость:

сопровождается системным администратором, который следит за работой ИС.

Приоритеты

Отсутствуют

Прочие требования к продукту

Отсутствуют

Используемые стандарты

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

ISO 16071 — эргономика взаимодействия «человек-система». Руководящие указания по доступу к интерфейсам «человек-машина»

ISO 16982 — эргономика взаимодействия человек-система. Методы, основанные на удобстве применения, для обеспечения проектирования, ориентированного на человека

Системные требования

32-разрядный (x86) или 64-разрядный (x64) процессор с тактовой частотой 1 гигагерц (ГГц) или выше;

1024 мегабайт оперативной памяти (ОЗУ);

Интегрированная видеокарта с 256 Мб памяти;

Сервер должен обладать как минимум 10 Тб внешней памяти, сетевым маршрутизатором для подключения всех рабочих мест к серверу, с последующим увеличением характеристик. Находиться в отдельном защищенном от сотрудников месте;

Требования к окружающей среде

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

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

Требования к электропитанию:

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

Электропитание ПК осуществляется от однофазной сети переменного тока напряжением 220 (20 В с частотой 50 — 60 Гц. Для питания ПК необходимо использовать отдельную электролинию, к которой не должно быть подключено сильноточное и коммутационное оборудование. Согласно Правилам устройства электроустановок.

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

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

Требования к документации

Руководство пользователя

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

Диалоговая помощь

Приложение имеет краткую справку, по работе с системой.

Руководство по установке, конфигурированию

Инструкция по установке и конфигурированию предоставляется вместе с продуктом в виде текстового файла.

Маркировка и упаковка

Маркировка отсутствует, поставляется на информационном носителе.

ГЛАВА 2 Проектная часть

2.1 Выбор средства для моделирования предметной области решаемой задачи

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

Язык UML объединил наиболее известные методы OOA/OOD и очень быстро приобрел широкую популярность среди разработчиков программного обеспечения.

Основными «строительными блоками» UML являются диаграммы, которые условно можно разделить на две категории:

структурные модели, описывающие структуру системы, классы, компоненты, подсистемы и т.д.;

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

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

Моделирование бизнеса с помощью UML предполагает по-следовательное построение двух видов моделей:

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

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

Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

диаграммы поведения системы (behavior diagrams):

диаграммы взаимодействия (interaction diagrams):

диаграммы последовательности (sequence diagrams) и

кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; – диаграммы реализации (implementation diagrams):

диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В данном учебном пособии для примера моделирования системы выбран программный инструмент моделирования StarUML [7]. Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML [7]. StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (модельно- настраиваемая архитектура), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.

Инструмент поддерживает возможность добавить плагины к базовой системе. Несмотря на то, что записано на языке Delphi, эти плагины могут быть записаны на любом COM-совместимом языке, таком как C++, Delphi, C# и VB.

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

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

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

Из прочих достоинств можно выделить:

— Генерация кода в языки: C#, Java, С++

-Поддержка работы с фреймворками

-Удобный графический редактор

-Полное соответствие стандарту UML 2.0

— Возможность расширения функционала (про это написано отдельное руководство разработчика)

-Экспорт документации в форматы: DOC, PPT, TXT, XLS…

— Поддержка паттернов

— Импорт проектов Rational Rose

— Приятный размер дистрибутива

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Диаграмма вариантов использования

Рисунок 1 Диаграмма вариантов использования

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

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

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

1. Ввод данных о новом клиенте – вариант использования дает возможность агенту заполнить данные о новом клиенте.
2. Заключение нового договора — вариант использования позволяет агенту заключить новый договор, с уже существующим в БД клиентом.
3. Продление уже существующего договора – вариант использования позволяет страховому агенту продлить страховой договор, то есть оформить аналогичный договор на предстоящий период.
4. Обновление данных — данный вариант использования позволяет агенту отредактировать данные о клиенте и внести изменения в БД.
5. Получение сгруппированной информации – различного вида отчеты и формы, содержащие данные, необходимые для анализа текущего состояния организации.
6. Расчет стоимости полиса – вариант использования позволяет клиенту провести расчет возможной стоимости страховой услуги в данной организации.

Диаграмма последовательности.

Рисунок 2 Диаграмма последовательности

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

На данную диаграмму помещены следующие объекты:

• Страховой агент – действующее лицо;
• «ZapyskProgrammi» — содержит форму авторизации в программе
• «ZapyskGlavnoiFormi» – содержит форму главного меню, необходимого для навигации по системе.
• «OtkritieFormiPoiska» – содержит форму в которую необходимо ввести данные о клиенте, для поиска его в базе данных.
• «OpenFormClient» – основная форма работы с клиентскими данными: отображает личные данные клиента, а так же данные о личном транспорте и оформленные страховки.
• «DataBase» – содержит информацию о клиентах и заключенных договорах.
• «PrintPolis» — процедура, выполняющая печать полиса.

Сообщения между объектами на диаграмме:

• «Authorization» — авторизоваться в программе;
• «Access Denied» — доступ запрещен;
• «Soobshit ob oshibke» — системное сообщение пользователю, о том что авторизация не удалась;
• «OpenMenu» – открыть форму главного меню;
• «OpenSearch» – открыть форму поиска клиента по различным параметрам;
• «SearchBD» – запрос к базе данных на поиск клиента, по указанным параметрам;
• «ReturnSearch» — возврат на форму поиска, в случае если процедура поиска не удалась;
• «Soobshit klient otsytstvyet» — выдача системного сообщения об отсутствии клиента в базе;
• «ReturnMenu» — возврат в меню;
• «OpenClientBD» — открытие клиентской формы, после удчано выполненного запроса;
• «OpenClient» — открытее клиентской формы для внесения в БД нового пользователя;
• «AddNewClientBD» — запись нового клиента в базу;
• «AddEditClientBD» — сохранение в БД измененных данных о клиенте;
• «PrintPolis» — печать сформированного полиса.
• «CloseProgramm» — завершение работы с программой

Кооперативная диаграмма

Рисунок 3 Кооперативная диаграмма.

Иерархия классов системы

Класс (class) — это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.

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

Рисунок 4 Иерархия классов системы.

Рисунок 5 Главная диаграмма классов.

Описание классов

Классы пакета Boundaries.

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

Класс Client содержит следующие атрибуты.

Операции класса Client

Класс Menu содержит атрибуты.

Операции класса Menu

Класс Search содержит следующие атрибуты.

Операции класса Search

Классы пакета Entities.

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

Класс BD не содержит никаких атрибутов, так как он только передает управление СУБД, которая в свою очередь выполняет все операции по работе с запросами пользователей.

Операции класса BD

Классы пакета Control

Рисунок 8 Диаграмма классов пакета Control

Класс Open содержит следующие атрибуты.

Операции класса Open

Классы пакета View

Рисунок 9 Диаграмма классов пакета View

Класс Print не содержит никаких атрибутов, так как данный класс реализует только печать страхового договора.

Операции класса Open

Рисунок 10 Диаграмма классов «страховой агент»

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

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

Рисунок 11 Диаграмма состояний «страховой агент»

/

ЗАКЛЮЧЕНИЕ

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

В процессе выполнения данного курсового проекта была разработана объектно-ориентированная модель информационной подсистемы для учета товаров с использованием языка UML.

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

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

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

• диаграмма вариантов использования;
• диаграмма последовательности;
• кооперативная диаграмма;
• диаграмма классов;
• диаграмма состояний;
• диаграмма компонентов;

В качестве среды разработки информационной подсистемы был использован программный продукт Rational Rose Enterprise Edition.

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1. Леоненков А. В., «Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose, М. Интуит.ру, 2006 – 320с.
2. 11. Мартин Фаулер, Кендалл Скотт, «UML. Основы», Символ-Плюс, Санкт-Петербург, 2007 – 192с.
3. 12. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон, «Язык UML. Руководство пользователя», СПб ДМК Пресс, Санкт-Петербург, 2004 – 432с.
4. 13. Вендров А.М., «Проектирование программного обеспечения экономических информационных систем», М. Финансы и статистика, 2006 – 544с.
5. http://bugabooks.com/book/8-avtomatizirovannye-it-v-yekonomike/73-104-avtomatizirovannaya-informacionnaya-sistema-straxovoj-firmy-i-texnologiya-ee-funkcionirovaniya.html, АИС страховой фирмы и технология ее функционирования;
6. Мартин Фаулер, Кендалл Скотт, «UML. Основы», Символ-Плюс, Санкт-Петербург, 2007;
7. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон, «Язык UML. Руководство пользователя», СПб ДМК Пресс, Санкт-Петербург, 2004;
8. Автоматизированные информационные технологии в экономике: Учеб. для вузов / М. И. Семенов, И. Т. Трубилин, В. И. Лойко, Т. П. Барановская; Под ред. И. Т. Трубилина.- М.: Финансы и статистика, 2003.- 414 с.
9. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования SADT (Structured Analysis & Design Technique): Пер. с англ. М.: МетаТехнология, 1993. – 240 с.

Время на прочтение
10 мин

Количество просмотров 159K

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

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

Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования UML (англ. «Unified Modeling Language») – стандартизированный язык моделирования при проектировании программ.

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

Когда разработчик создаёт своё приложение, он в первую очередь задумывается над двумя вопросами:

• Что будет делать приложение?

• Кто будет пользоваться этим приложением?

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

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

Диаграмма вариантов использования

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

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

В этой системе можно выделить следующие группы пользователей:

• Обучающиеся

• Преподаватели

• Классные руководители

• Заместители директора

Заместители директора есть, а где же сам директор?

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

Каждая из групп пользователей может пользоваться нашей системой по-своему.

Обучающиеся могут:

• Смотреть расписание

• Просматривать свои оценки

Преподаватели могут:

• Размещать материалы для уроков

• Выставлять оценки в электронный журнал

Классные руководители могут делать все то же самое, что и преподаватели плюс:

• Составлять расписание родительских собраний

Заместители директора могут:

• Составлять расписание

• Публиковать посты с важной информацией

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

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

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

А почему мы описываем так мало возможностей?

А теперь, когда мы выделили группы пользователей и функциональность системы, начнём строить диаграмму, чтобы зафиксировать и структурировать полученные данные.

Построение диаграммы

Каждая группа пользователей на диаграмме вариантов использования обозначается человечком, под которым записывается имя группы людей, которую он обозначает. Давайте изобразим группу пользователей «Преподаватели»:

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

В терминологии UML, этот человечек называется актёром (англ. «actor»). В общем случае, актёр обозначает любые сущности, использующие систему. Этими сущностями могут быть люди, технические устройства или даже другие системы.

Так же изобразим актёров для оставшихся групп пользователей:

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

В терминологии UML, этот эллипс называется вариантом использования (англ. «use-case»). В общем случае, вариант использования – набор действий, который может быть использован актёром для взаимодействия с системой.

Связи между элементами

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

Отношение ассоциации

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

Мы соединили актеров с вариантом использования с помощью сплошной линии без стрелки. Такая линия называется отношением ассоциации.

Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.

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

Почему отношение ассоциации называется так и не иначе?

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

Добавим еще вариантов использования и соединим их с соответствующими актёрами:

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

Отношение обобщения

Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:

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

2. Соединить каждого актёра со всеми нужными вариантами использования. Это может породить множество пересечений линий, что не самым лучшим образом скажется на читаемости диаграммы.

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

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

Разумеется, мы воспользуемся третьим путём. В этом нам поможет, так называемое, отношение обобщения. Отношение обобщения обозначается сплошной линией с полой треугольной стрелкой.

Отношение обобщения означает, что некоторый актёр (вариант использования) может быть обобщён до другого актёра (варианта использования).  Стрелка направлена  от частного случая(специализации) к общему случаю.

Ниже представлены несколько примеров использования отношения обобщения.

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

Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».

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

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

Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.

Присоединим это к основной диаграмме:

Отношение включения

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

1. Расписание занятий

2. Расписание мероприятий

3. Расписание каникул

Всё это составляется заместителем директора, поэтому покажем это на диаграмме. Для этого будем использовать отношение включения. Отношение включения обозначается пунктирной линией с V-образной стрелкой на конце, над стрелкой добавляется надпись “include”.

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

Когда мы используем отношение включения, мы подразумеваем, что составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего варианта использования.

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

Снова вернёмся к нашему основному примеру.

Как итог, наша диаграмма принимает следующий вид:

В целом, на этом можно остановиться. Хоть наш пример и демонстрационный, он немного отражает функциональность реального приложения. Тем не менее, остался еще один элемент, который мы не рассмотрели.

Отношение расширения

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

Во время дистанционного обучения школьникам необходимо выполнять домашние задания и присылать их в виде архива или фотографий учителям. Получается, нужно добавить возможность прикреплять файл к сообщению в нашей системе. Чтобы отобразить это на диаграмме мы будем использовать отношение расширения. Отношение расширения обозначается пунктирной линией с V-образной стрелкой на конце (похоже на отношение включения), над стрелкой добавляется надпись “extend ”.

В UML пунктирная линия с V-образной стрелкой, в общем случае, называется отношением зависимости. Для диаграммы вариантов использования выделяют различные виды зависимостей: отношение включения и отношение расширения. Чтобы их различать, над стрелками пунктирной линией пишут “include” и “extend” соответственно.

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

Два нижних варианта использования описывают возможные «расширения» для базового варианта использования. Исходя из этого примера, мы можем сделать важное замечание.

Можно сказать, что отношение расширения — это выборочное отношение включения. Если отношение включения обозначает, что элемент обязательно включается в состав другого элемента, то в случае отношения расширения это включение необязательно.

Понимание этого критически важно для грамотного использования этого вида отношений.

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

Как итог, получим такую диаграмму:

Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!

Что делать, если я путаюсь в направлении стрелок?

При построении диаграмм UML часто возникает путаница, в какую сторону направлена та или иная стрелка. Это пройдёт после небольшой практики. Общая рекомендация к запоминанию правильного направления стрелок на диаграмме вариантов использования: стрелка обычно направлена от «зависимого» объекта к «независимому» (от специального к общему). Например:

Тем не менее, в любом правиле есть исключение. Этим исключением является отношение расширение:

Общие рекомендации:

1. Диаграммы очень просто изменять. Не нужно пугаться того, что требования к программе могут измениться или что вы что-то забыли отобразить на диаграмме. Вы можете добавить элементы к диаграмме, когда вам угодно.

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

3. Старайтесь не допускать пересечений соединительных линий. Это может затруднить чтение диаграммы для вас и для ваших коллег.

4. Не дублируйте варианты использования на диаграмме. Если приходится дублировать варианты использования, то элементы диаграммы надо постараться расставить по-другому.

5. Пользуйтесь специальными компьютерными программами для построения диаграмм. Это существенно упростит весь процесс моделирования.

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

Границы системы, акторы и варианты использования: что такое диаграмма Use Case

Проектируя программную систему, аналитик прежде всего отвечает на вопрос, что она должна делать, т.е. какие возможности представлять для разных пользователей. Для описания таких вариантов использования в UML есть одноименная диаграмма – Use Case. Она позволяет наглядно показать границы системы и ее функции, сгруппированные по контексту – прецеденты. При том, что каждый прецедент фактически отражает одно или сразу несколько функциональных требований, UML-диаграмма Use Case и одноименная форма представления требований – это разные вещи, хоть и связанные между собой. Подробнее об этом мы рассказывали в отдельной статье.

В качестве иллюстративного примера рассмотрим систему онлайн-оплаты учебного курса. Пользователем этой системы является клиент. В терминологии UML он будет называться актор – сущность за пределами системы, которая взаимодействует с ней. На UML-диаграмме Use Case он изображается в виде человечка. Актору «Клиент» доступен основной вариант использования – «Оплатить договор» (на проведение обучающего курса по бизнес-анализу).  Расширением этого варианта использования является «Оплатить со скидкой по промокоду», который уменьшает сумму платежа. Этот вариант использования является опциональным и расширяет основной, поэтому он будет связан с основным через связь extend, которая выглядит как пунктирная стрелочка с соответствующей надписью.

Далее следует детализировать, как именно выполняется процесс оплаты, раскрыв прецедент со схемы Use Case на UML-диаграмме последовательности. Однако, чтобы сделать это с привязкой к внутренним сущностям нашей программной системы, классам, следует сперва описать их на UML-диаграмме классов. Как это сделать, мы рассмотрим далее.

Ликбез по ООП или как построить UML-диаграмму классов

UML соответствует объектно-ориентированной парадигме программирования (ООП), ключевым понятием которой является класс. Класс – это абстракция сущностей с одинаковыми свойствами (атрибутами, полями) и поведением (методами, функциями). Классы могут быть связаны друг с другом через наследование и ассоциации. При наследовании класс-потомки имеют (наследуют) атрибуты и методы класса-родителя, а также свои собственные. А конкретные значения этих атрибутов задаются в реализации классов в виде их отдельных экземпляров, называемых объектами. Например, ООО «Рога и Копыта» и Иванов Иван Иваныч – это конкретные реализации классов «Юрлицо» и «Физлицо» соответственно. В частности, у объекта класса Физлицо есть поля с паспортными данными (ФИО и № паспорта), а у юрлица обязательно должны быть название и ИНН. При этом оба этих класса наследуют от родителя (Класс «Клиент») общие для них атрибуты (тип, номер телефона, email и адрес).

Ассоциация означает логическую связь между объектами разных классов. Например, договор на обучение связан с курсом. Поскольку в договоре нужно обязательно указать курс, эти классы будут связаны не простой ассоциацией, а ее более сложным вариантом – агрегацией. В этом случае у класса, который является целым, появится значок в виде незакрашенного ромбика. Если связь между объектами разных классов настолько сильная, что при уничтожении целого, уничтожаются и его части, ромбик будет закрашенным. Такая связь называется композицией и является самым сильным вариантом ассоциации. Можно также указать кратность связи, к примеру, в 1-м договоре на обучение могут быть указаны сразу несколько курсов. При этом над концами связи отобразятся мультипликаторы, обозначающие ее кратность.

Таким образом, в нашей системе интернет-оплаты договора с применением промокода по конкретному курсу будут следующие классы:

• Клиент – абстрактный класс-родитель для классов «Юрлицо» и «Физлицо»;
• Физлицо;
• Юрлицо;
• Договор;
• Курс;
• Промокод;
• Платеж.

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

Теперь, имея диаграмму классов, которая на концептуальном уровне описывает доменную область проектируемой системы, можно показать, как объекты разных классов взаимодействуют друг с другом на UML-диаграмме последовательности (Sequence).

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

А в заключение покажем, как выглядит жизненный цикл объектов класса «Промокод» с помощью UML-диаграммы состояний (StateChart или State Machine). На мой взгляд, из всех UML-диаграмм она самая простая и понятная без дополнительных объяснений. Начиная со стартового события, объект последовательно проходит разные стадии жизненного цикла, меняя свое состояние в зависимости от некоторых условий.

Как описать архитектурные аспекты проектируемой информационной системы с помощью UML, читайте в нашей новой статье.

Проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест.

Открытый тест по UML: основы бизнес-анализа для начинающих

А научиться самостоятельно разрабатывать эти и другие UML-диаграммы вам поможет специализированный курс «UML для бизнес-аналитиков». Только практика на реальных примерах. После 8-часового интенсива вы сможете дополнять текстовые схемы представления требований User Story и Use Case UML-диаграммами вариантов использования и детализировать их далее в диаграммы деятельности, последовательности и состояний, чтобы наглядно объяснить разработчикам, что именно должна делать программная система.

Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML — слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту.

Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process [1], а Розенберг — ICONIX [2]). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.

Диаграмму вариантов использования есть смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются также диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно вы можете использовать ее для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).

На диаграмме использования изображаются:

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

На мой взгляд, наиболее правильный порядок построения диаграммы следующий:

1. выделить группы действующих лиц (работающих с системой по-разному, часто из-за различных прав доступа);
2. идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат. Например, кассир может «продать товар» (это будет являться прецедентом), однако «ввод штрих-кода товара для получения цены» самостоятельным прецедентом не является;
3. дополнить прецеденты словесным описанием (сценарием):
   • для каждого прецедента создать разделы: «главная последовательность» и «альтернативные последовательности»;
   • при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них.

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

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

Цель — развитие у детей математических навыков.
Платформа: Linux, Windows, Android.
Функциональность:

• для учеников:
  • выбор подготовленного учителем блока заданий;
  • выполнение заданий;
• для учителя:
  • подготовка для учеников блоков заданий;
  • добавление в систему ученика;
  • просмотр отчетов.

При первом запуске система должна позволять ввести пароль учителя. Задания представляют собой математические задачи на сложение, вычитание, умножение и деление. В блоке задач могут быть задачи различных типов (указывается количество). Помимо ввода типа выполняемой в примере операции необходимо указывать допустимые диапазоны чисел (или даже отдельные числа, т.к. при изучении таблицы умножения часто сначала учат умножение на 2, затем на 5, а только потом все остальное). Кроме того, для операции вычитания необходимо иметь возможность установить вычитаемое меньше уменьшаемого (т.к. в противном случае результат будет отрицательным, а отрицательные числа в школе проходят гораздо позже).

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

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

Название прецедента: регистрация ученика

Действующее лицо: учитель

Цель: добавить ученика в систему, получив его пароль

Предусловия: учитель осуществил вход в систему

Главная последовательность:

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. система добавляет ученика;
5. учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно.

Альтернативная последовательность (возврат в главное меню без добавления ученика):

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель нажимает кнопку «назад»;
4. учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются).

Альтернативная последовательность (добавление ученика, уже имеющегося в системе):

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.

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

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

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

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

Таким образом можно показать, что у учителя появляется возможность (но не обязанность) удалить набор задач при просмотре отчетов если все ученики выполнили этот набор.

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

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

Наиболее типичными ошибками при построении этого вида диаграмм являются:

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

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

Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.

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

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

1. Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. – М.: ООО “И.Д. Вильямс”, 2010. – 720 с.
2. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
3. Бабич А. В. Введение в UML // Интернет университет информационных технологий. 2008. URL: http://www.intuit.ru/studies/courses/1007/229/info (дата обращения: 19.03.2016).
4. Леоненков, A.B. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose: учеб. пособие Текст. / A.B. Леоненков. М.: Интернет-Ун-т информ. технологий: БИНОМ, Лаборатория знаний, 2006. — 320 с.