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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

номер	термин	значение
1	сотрудник	работник предприятия выполняющий определенные действия, имеющий фамилию, имя и отчество
2	удаленные пользователи	инспекторы, агенты страховой компании, проверяющие, т. е. сотрудники, которые по долгу службы проводят рабочий день не в собственном офисе
3	Сценарий	некоторая последовательность действий, иллюстрирующая поведение системы
4	Страховщики	страховые организации, которые вправе осуществлять обязательное страхование гражданской ответственности владельцев транспортных средств в соответствии с разрешением (лицензией)
5	Страхователи	лица, заключившие со страховщиком договор обязательного страхования
6	ОСАГО	обязательное Страхование Автогражданской Ответственности
7	ДСАГО	добровольное страхование автогражданской ответственности
8	Полис ДСАГО	полис добровольного страхования автогражданской ответственности перед третьими лицами
9	страховой случай	наступление гражданской ответственности владельца транспортного средства за причинение вреда жизни, здоровью или имуществу потерпевших при использовании транспортного средства, влекущее за собой в соответствии с договором обязательного страхования обязанность страховщика осуществить страховую выплату
10	страховые тарифы	ценовые ставки, установленные в соответствии с настоящим Федеральным законом, применяемые страховщиками при определении страховой премии по договору обязательного страхования и состоящие из базовых ставок и коэффициентов
11	Класс	Описание набора объектов, обладающих одинаковыми свойствами
12	компенсационные выплаты	платежи, которые осуществляются в соответствии с настоящим Федеральным законом в случаях, если страховая выплата по обязательному страхованию не может быть осуществлена
13	Интерфейс	Набор операций, используемых для определения сервисов, предлагаемых классом или компонентом
14	ИБ	Информационная база организации
15	Сигнал	Асинхронное сообщение, передаваемое между объектами
16	Прецедент	Описание последовательностей действий, осуществляемых системой для предоставления пользователю результата
17	Реализация	Устройство механизма или системы
18	Ограничения	Расширяют семантику элемента, обеспечивая возможность добавлять новые правила
19	Помеченные значения	Обеспечивают возможность определять новые элементы модели UML на основании уже существующих элементов
20	СУБД	Система управления базой данных

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

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

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

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

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

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

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

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

Таблица 2

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

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

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

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

Таблица 3

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

Наименование лица	Кого представляет	Роль
Сотрудник	Организацию	Работник фирмы
Пользователь	Физическое лицо	Клиент

Таблица 4

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

Наименование	Описание
Сотрудник	Работник организации
Клиент	Физическое лицо, являющееся клиентом организации

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

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

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

Таблица 5

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

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

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 содержит следующие атрибуты.

Имя	Описание	Тип
ID	Идентификационный номер клиента	Integer
Fam	Фамилия клиента	String
Im	Имя клиента	String
Otch	Отчество клиента	String
Adress	Место жительства	String
desc	описание	String
NomerDogovora	Знак автора	String
Data zaklucheniya	Дата заключения договора	Date

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

Имя	Описание
OpenClientBD ()	В результате данной операции происходит открытие формы клиента с результатом запроса по поиску конкретного человека, заключившего договор с организацией
Open Client ()	Открытие клиентской формы из меню, для добавления нового клиента

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

Имя	Описание	Тип
CloseForm	В данном атрибуте содержится логическое выражение, Отражающее закрытие формы меню	Boolean

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

Имя	Описание
OpenMenu ()	Открытие формы главного меню, в котором осуществляется работа с системой, производится открытие форм, таких как клиент и поиск
Return Menu ()	Операция возврата в главное меню, после закрытия форм клиент и поиск

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

Имя	Описание	Тип
Fam	Фамилия клиента	String
Im	Имя клиента	String
Otch	Отчество клиента	String
NomerPolisa	Номер страхового свидетельства	Integer
NomerAvto	Номерной знак транспортного средства	String

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

Имя	Описание
OpenSearch ()	Открытие формы поиска из главного меню
Return Search ()	Операция возврата на форму поиска, обнаружения отсутствия клиента в базе
Soobshit ob ots	Выдача системного сообщения пользователю, об отсутствии клиента в БД

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

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

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

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

Имя	Описание
AddNewClientBD ()	Отправка запроса на добавление нового клиента организации
AddEditClientBD ()	Отправка запроса на внесение в базу изменений об уже существующем клиенте
SearchBD ()	Формирование результирующей информации и выдача данных о запрашиваемом клиенте на соответствующей форме клиент

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

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

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

Имя	Описание	Тип
LogIn	Логин пользователя	String
Password	Пароль пользователя	String
Access	Доступ разрешен, либо запрещен	Boolean

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

Имя	Описание	Сигнатура
Authorization	Проверка правильности ввода данных пользователем при входе в систему, операция возвращает значение логического типа.	+ Authorization (): Boolean

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

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

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

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

Имя	Описание	Сигнатура
PrintPolis	Операция реализует печать полиса, данные берутся из БД

Рисунок 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 с.

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

Постановка задачи: описание бизнес-процесса

Предположим, пользователь – посетитель сайта хочет купить курс по бизнес-анализу и оплатить его онлайн банковской картой. При этом он может получить скидку, применив промокод. Промокод действует только на определенный курс и ограничен по времени. Данные о промокоде хранятся в СУБД Учебного Центра (УЦ): сам промокод, курс, на который он распространяется, размер скидки, срок действия (дата валидности) и состояние (новый, выдан, использован, истек). Сам процесс оплаты, т.е. непосредственного списания денег с банковской карты выполняется на стороне банковского платежного шлюза. Выполняемую при этом последовательность шагов можно упрощенно представить следующим образом:

1. пользователь выбирает курс по бизнес-анализу и нажимает кнопку «Купить»;
2. открывается страница оплаты курса на сайте учебного центра с формой договора покупки курса и чек-боксом о наличии промокода;
3. пользователь вводит свои данные в форму договора покупки курса;
4. пользователь отмечает наличие промокода в чек-боксе;
5. открывается поле ввода промокода и кнопка проверки его валидности;
6. пользователь вводит промкод;
7. пользователь проверяет его валидность, кликнув на кнопку «Проверить»;
8. выполняется проверка валидности промокода с учетом данных по нему, которые имеются в СУБД УЦ.
9. Если промокод валиден (т.е. привязан к выбранному курсу и дата действия его еще не истекла) и находится в состоянии «выдан», цена курса меняется с учетом скидки по промокоду. Иначе цена курса остается прежней и пользователю показывается сообщение о невозможности применить этот код по одной из следующих причин: уже использован, не применим к выбранному курсу или закончился срок его действия.
10. соглашаясь с ценой (пересчитанной или прежней), пользователь нажимает кнопку «Оплатить». При этом в сторону платежного шлюза посылается запрос со всеми параметрами заказа, где сумма списания равна итоговой цене, рассчитанной с учетом скидки по промокоду, если ее удалось применить.
11. открывается веб-страница платежного шлюза с формой ввода данных банковской карты пользователя и суммой списания;
12. пользователь вводит реквизиты своей банковской карты и нажимает кнопку «Оплатить». При этом на сервер банка в систему «Антифрод» отправляются детали заказа и данные карты, чтобы проверить заказ на мошенничество.
13. в платёжный шлюз возвращаются результаты проверки заказа на мошенничество. Если заказ признан мошенническим, оплата отклоняется и платеж считается неуспешным. Иначе платёжный шлюз списывает деньги со счёта клиента.
14. Платёжный шлюз возвращает сайту УЦ статус платежа (успешный или неуспешный).
15. На странице оплату сайта УЦ отображается статус платежа.
16. При успешном платеже в СУБД УЦ меняется состояние промокода на «Использован».

Хотя при проектировании систем не рекомендуется включать в описание бизнес-процессов детали интерфейса, для простоты и наглядности рассматриваемого примера, мы нарушим это правило. Теперь рассмотрим, как данное текстовое описание последовательности шагов показать в виде UML-диаграммы последовательности. Кстати, проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест. А посмотреть, как строить другие виды UML-диаграмм (классов, состояний и вариантов и использования), можно в этой статье.

UML-диаграмма последовательности

Итак, в UML-диаграмме описанной последовательности будут участвовать объекты:

• Пользователь;
• страница оплаты сайта учебного центра (Сайт УЦ);
• СУБД УЦ;
• Платежный шлюз;
• Антифрод-система.

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

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

Таким образом, UML-диаграмма последовательности позволяет достаточно наглядно показать взаимодействие между разными объектами, детализируя какими сигналами прямыми и ответными они обмениваются. Чаще всего это требуется для иллюстрации интерактивного взаимодействия между разными сервисами или объектами одной системы, например, когда при регистрации клиентского обращения запускается задача ответственному сотруднику на его обработку. Более детально разобраться с sequence-диаграммой и другими моделями UML вам поможет специализированный курс «UML для бизнес-аналитика».

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

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

Что такое диаграмма последовательности?

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

В UML объект на диаграмме последовательности изображается в виде прямоугольника, содержащего подчеркнутое имя объекта. Объект может быть назван одним из трех способов: именем объекта, именем объекта и его класса или просто именем класса (анонимный объект). Три способа именования объекта показаны на рисунке ниже.

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Объекты диаграммы последовательности

1. Показать порядок взаимодействия между объектами. Смоделируйте поведение взаимодействия как передачу сообщений и динамически покажите взаимодействие между объектами, описав, как сообщения отправляются и принимаются между ними.
2. По сравнению с другими диаграммами UML диаграмма временной последовательности уделяет больше внимания хронологическому порядку взаимодействия.
3. Он может визуально описать процесс параллелизма.

Элементы диаграммы последовательности

1. Актер – Системные субъекты, которыми могут быть люди, машины, другие системы, подсистемы; используется для представления на диаграмме временной последовательности.

2. Объект. Существует три способа именования объектов:

1. Включает имя объекта и имя класса, например: live class: class, на диаграмме временных рядов с «object: class».
2. Показывает только имя класса, то есть это анонимный объект, например: :course; на временной диаграмме с «: class».
3. Показывает только имя объекта, но не имя класса, например: лектор; на временной диаграмме он представлен «объектом».

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

3. Порядок объектов

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

Линия жизни

Пунктирная линия, идущая вниз от значка объекта на временной диаграмме, указывает, как долго объект существует.

• Фокус управления (также известный как период активации) — это символ периода времени, в течение которого объект будет выполнять соответствующую операцию. Его можно интерпретировать как пару скобок { } в семантике C; представлен небольшим прямоугольником. Он представляет собой период, в течение которого элемент выполняет операцию. Верх и низ прямоугольника соответствуют времени начала и завершения соответственно.

• Сообщения обычно классифицируются как синхронное сообщение, асинхронное сообщение и возвратное сообщение.

Обратите внимание, что

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

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

• Возвратное сообщение указывает на возврат из вызова процедуры.

Сообщения о создании и уничтожении

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

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

Сообщение  деструктора  уничтожает получателя. Есть и другие способы указать, что цель уничтожена во время взаимодействия. Только когда для уничтожения цели установлено значение «после деструктора», вам нужно использовать деструктор.

Не мгновенное сообщение

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

Фрагменты комбинации

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

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

Пример – сценарий размещения заказа

Член корабля, который хочет разместить заказ онлайн. Заказанные товары будут отправлены участнику курьером или обычной почтой, в зависимости от его статуса членства (VIP, постоянный член). Если участник выбирает вариант уведомления в заказе, магазин отправит участнику уведомление с подтверждением.

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Другой пример: разместить заказ

Диаграмма последовательности представляет собой двумерную диаграмму, на которой горизонтальная ось представляет объекты, а вертикальная ось представляет время, где сообщения передаются горизонтально между объектами и располагаются вертикально в хронологическом порядке. В примере показана диаграмма Sequence с тремя участвующими объектами: Customer, Order и Stock. Даже формально не зная нотации, вы, вероятно, сможете получить довольно хорошее представление о том, что происходит.

1. Шаг 1 и 2: Клиент создает заказ.
2. Шаг 3: Клиент добавляет товары в заказ.
3. Шаг 4, 5: Каждый предмет проверяется на наличие в инвентаре.
4. Шаг 6, 7, 8: Если товар есть в наличии, он добавляется в заказ.
5. Шаг 9 возврат
6. Шаг 10, 11: сохранить и уничтожить порядок

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Часто используемые фрагменты комбинации

Типы фрагментов включают ref, assert, loop, break, alt, opt и neg, ref, sd.

Оператор	Значение
альтернативный	Альтернативные множественные фрагменты: будет выполняться только тот, условие которого истинно.
выбрать	Необязательно : фрагмент выполняется только в том случае, если предоставленное условие истинно. Эквивалентно альту только с одной трассировкой.
номинал	Parallel : каждый фрагмент выполняется параллельно.
петля	Цикл : фрагмент может выполняться несколько раз, а сторож указывает основу итерации.
критический	Критическая область : фрагмент может иметь только один поток, выполняющий его одновременно.
отрицательный	Отрицательный : фрагмент показывает недопустимое взаимодействие.
ссылка	Ссылка : относится к взаимодействию, определенному на другой диаграмме. Рамка нарисована, чтобы покрыть линии жизни, участвующие во взаимодействии. Вы можете определить параметры и возвращаемое значение.
сд	Диаграмма последовательности : используется для обозначения всей диаграммы последовательности.

Обратите внимание, что:

• Можно комбинировать кадры, чтобы захватывать, например, петли или ответвления.
• Комбинированные  ключевые слова фрагмента: alt, opt, break, par, seq, strict, neg, Critical, ignore, рассматривает, утверждает и зацикливается.
• Ограничения обычно используются для отображения временных ограничений сообщений. Они могут применяться к времени одного сообщения или интервалам между сообщениями.

Примеры комбинированных фрагментов

(1) Выбор (Alt) — альтернативный фрагмент предоставляет несколько защищенных альтернативных фрагментов (разделенных операндами взаимодействия), т. е. используется для указания взаимоисключающих вариантов выбора между двумя или более последовательностями сообщений, что эквивалентно классическому if..else…:

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

(2) Option (Opt) — содержит последовательность возможных вхождений или ненаступлений, что означает, что необязательный фрагмент выполняется только в том случае, если какое-либо защитное условие истинно:

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

(3) Цикл (Loop) — Цикл позволяет повторять фрагмент до тех пор, пока какое-либо охранное условие не станет ложным:

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Ломать

Разрыв позволяет выйти из окружающего цикла, когда некоторая защита становится истинной:

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Разрывы чаще всего используются для моделирования обработки исключений. В этом примере диаграммы последовательности используется фрагмент комбинации разбиения, поскольку он рассматривает условие баланса < суммы как исключение, а не как альтернативный поток. Чтобы прочитать этот пример, мы начинаем с верхнего левого угла последовательности и читаем вниз. Когда последовательность достигает возвращаемого значения «баланс», она проверяет, меньше ли баланс суммы. Если баланс не меньше суммы, следующим отправленным сообщением будет сообщение addDebitTransaction, и последовательность продолжится как обычно.

Параллельно

Параллельный фрагмент позволяет выполнять несколько взаимодействий параллельно:

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Рамки

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

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Ссылка (Ссылка)

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

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Протоколы

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Сотрудничество

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Сценарии

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Сигналы и приемы

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

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

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

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

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Критический

ИЗМЕНИТЬ ЭТУ ДИАГРАММУ ПОСЛЕДОВАТЕЛЬНОСТИ

Другие типы фрагментов

• Строгий
• Утверждать
• Рассмотреть возможность
• Игнорировать
• Область, край
• отрицательный

Сводка обозначений диаграммы последовательности

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

Диаграмма последовательностей (sequence diagram)

Только что мы познакомились с диаграммой объектов, которая показывает отношения между объектами в некоторый момент времени, т. е. предоставляет нам снимок состояния системы, являясь статической. Диаграмма же последовательностей отображает взаимодействие объектов в динамике. Что значит «в динамике»? Как раз с этим нам и предстоит разобраться.

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

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

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

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

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

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

А вот что описывает следующая диаграмма (рис. 2.13), попробуйте догадаться самостоятельно. Только, чур, не подсматривать в нижеследующий текст лекции!

Ну как, догадались? А мы даже и не сомневались! Конечно, это же работа обычного домового лифта, которым мы пользуемся каждый день! Кстати, посмотрите на имена объектов — видно, что это уже несколько иной стиль проектирования, чем в предыдущем примере. И наконец, еще один пример (рис. 2.14):

Узнаете свой мобильный?

Диаграмма взаимодействия (кооперации, collaboration diagram)

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

Следует отметить, что использование диаграммы последовательностей или диаграммы взаимодействия — личный выбор каждого проектировщика и зависит от индивидуального стиля проектирования. Мы, например, чаще отдаем предпочтение диаграмме последовательностей. На обозначениях, применяемых на диаграмме взаимодействия, думаем, не стоит останавливаться подробно. Здесь все стандартно: объекты обозначаются прямоугольниками с подчеркнутыми именами (чтобы отличить их от классов, помните?), ассоциации между объектами указываются в виде соединяющих их линий, над ними может быть изображена стрелка с указанием названия сообщения и его порядкового номера.

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

Но давайте же, наконец, перейдем к примерам (рис. 2.15):

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

Надеемся, что и эта диаграмма не смогла поставить вас в тупик. Скорее всего, она описывает процесс управления учебными курсами (очевидно, путем создания их из готовых модулей) для некоего учебного центра. Как видите, все просто!

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

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