Разработка модели информационной системы с помощью StarUML

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

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

Диаграмма деятельности (Activity Diagram)

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

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

· состояния используются для представления не деятельностей, а действий (другая семантика состояний);

· на переходах отсутствует сигнатура событий.

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

Диаграммой последовательностей (Sequence Diagram) это диаграмма взаимодействий, заостряющая внимание на временной упорядоченности сообщений, которыми обмениваются объекты системы. Графически диаграмма последовательностей изображается в виде таблицы, объекты которой расположены в оси X, а сообщения в порядке возрастания времени - вдоль оси Y. На данной диаграмме изображаются толь те объекты, которые непосредственно учувствуют во взаимодействии.

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

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

Диаграмма компонентов

UML 2.x - диаграмма компонентов представляет собой тип структуры диаграмм, который показывает, как компоненты связаны с более крупными компонентами или системами программного обеспечения, а также показаны зависимости между этими компонентами.

Разработка компонентов предполагает, что построенные компоненты могут быть использованы повторно и заменены некоторыми другими компонентами. Компоненты в UML 2.x могут представлять собой логические компоненты и физические компоненты.

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

ь компоненты;

ь интерфейсы;

ь отношения зависимости, обобщения, ассоциации и реализации

Диаграмма развёртывания (Deployment Diagram)

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

Диаграмма сущность-связь (ER Diagram)

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model или entityrelationship diagram) - это модель данных, с помощью которой описываются концептуальные схемы. Представляет собой графическую нотацию, которая основана на блоках и на линиях связи, благодаря которым возможно описать объекты и отношения между моделями данных. В этом смысле ER-модель является метамоделью данных, то есть средством описания моделей данных.

ER-модель удобна при проектировании (моделировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем. Данный вид диаграмм позволяет выделить главные сущности и обозначить отношения между сущностями, имеющиеся в модели. Важно отметить что сами отношения также являются сущностями (выделяются в отдельные графические блоки), что позволяет устанавливать отношения на множестве самих отношений. ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest). На этапе перехода к реализации данной ER-диаграммы в виде реальной информационной системы или программы, происходит отображение ER-модели в более детальную модель данных реляционной (объектной, сетевой, логической, или др.) базы данных, которая называется физической моделью данных по отношению к исходной ER-диаграмме.

2.1.8 Архитектура StarUML 2.x

StarUML 2 - модифицируемая программная среда, предназначенная для моделирования ПО. Продукт располагает обширным арсеналом встроенных функций, а также позволяет добавлять дополнительные средства проектирования. Архитектура StarUML 2 представлена на рис. 2.1, где светлым цветом обозначена непосредственно платформа, а темным - объекты расширения, которые могут быть разработаны отдельно и затем интегрированы в систему.

*Подход: Подход определяет структуру проекта и основные параметры организации диаграмм.

*Профиль UML 2.x и расширение нотации: Профиль UML 2.x обеспечивает расширение набора спецификаций модели программного обеспечения через механизм расширения UML 2.x.

*Модельный фреймворк: Фреймворк делает часть модели программного обеспечения многократно используемой и позволяет применять её при разработке других моделей программного обеспечения.



Рис. 2.1 - Архитектура StarUML 2

*COM-объект расширения: позволяет добавлять новые функциональные возможности к StarUML 2.

*Расширение меню: Меню приложения StarUML 2 (главное меню и всплывающие меню) можно расширять.

*Расширение опций: опции настройки StarUML 2 могут добавляться пользователем. Написание дополнительных COM-объектов".

*Обработка событий: Различные события, возникающие в StarUML 2, могут быть перехвачены и обработаны.

*Внешнее API: внешнее API StarUML 2 позволяет получать извне доступ к различным функциональным возможностям и информации программы.

Модуль - пакет программ, который осуществляет добавление новых функциональных возможностей к StarUML 2. Модуль включает различные механизмы расширения StarUML 2. Как показано на рис. 2.2, дополнительный пакет может использовать подходы, фреймворки модели, профили UML 2.x, скрипты, расширения меню, расширения опций настройки, систему помощи и COM-объекты.

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

Рис. 2.2 - Модуль StarUML 2.x

*Поддержка специфических процессов: компонентов UML 2.x, RUP, Catalysis, XP...

*Поддержка специфических языков программирования: C/C ++, Python, C#, Visual Basic, Java, Perl, Object Pascal...

*Интеграция со специфическими инструментами: Visual SourceSafe, CVS, MS Word, Eclipse, Visual Studio .NET...

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

*Построение специфической рабочей среды (личной или стандартной для предприятия).

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

*Фреймворк модели: При разработке модуля, связанного со специфическими языками или платформами, фреймворк модели может предоставить готовую библиотеку классов или иной прикладной инструментарий. Любые типовые элементы проекта (например, «События», «Трансакции», «Безопасность», «Каталоги» ...), уже разработанные ранее, также могут быть добавлены в качестве фрагментов модели.

*Профиль UML 2.x: Профиль UML 2.x определяется для расширения нотации UML 2.x под специфические процессы, языки или фреймворки, включая введение дополнительных свойств элементов. Он имеет глобальный эффект в модуле.

*Расширение меню: Расширение меню используется, чтобы добавлять новые функциональные возможности и расширять главное меню или всплывающие меню, и тем самым позволить пользователю выбирать и выполнять новые функции. Это - критический элемент в разработке add-in`ов.

*Расширение опций настройки: add-in может иметь собственные параметры настройки. Для их редактирования StarUML 2 допускает использовать свой стандартный диалог управления опциями.

*Дополнительный COM-объект: Дополнительные функции могут быть реализованы с помощью языковых инструментов, подобных Visual Basic, Delphi, Visual C++, и C#. Вообще, объекты COM используются для разработки дополнительного GUI или реализации сложных функциональных возможностей. Скрипты используются для воплощения более простых функциональных возможностей. При программировании COM-объектов, обычно, используется API StarUML 2.

*Скрипт: Простое расширение функциональных возможностей может быть выполнено, с помощью скриптовых средств (JScript, VBScript, Python...). Они обычно взаимодействуют с приложением StarUML 2 через его API.

*Помощь: Помощь для add-in может быть создана на HTML и зарегистрирована локально или с указанием удалённого пути. [12 с. 7]

3. Разработка модели информационной системы консалтинговой компании в графической нотации UML

3.1 Описание диаграммы вариантов использования (Use Case Diagram)

Суть диаграммы вариантов использования состоит в следующем: проектируемая система представляется в виде множества сущностей или актёров, взаимодействующих с системой с помощью так называемых вариантов использования (ВИ). При этом актёром (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне путём обращения к тем или иным её службам. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актёру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой в процессе диалога с актёром.

В разрабатываемой модели выявлены актёры «Клиент», «Аналитик и «Менеджер», а также набор действий - заключение договора, подготовка, обработка и анализ данных. Между сущностью «Клиент» и «Заключение договора», «Менеджер» и «Управление взаимодействием с клиентами», «Аналитик» и «Подготовка данных», «Обработка данных», «Анализ и прогнозирование данных» определены отношения ассоциации. Между сущностью «Анализ и прогнозирование данных» и сущностями «Обработка данных», «Подготовка данных», «Создание отчёта» определены отношения включения (include). Между сущностью «Подготовка данных» и сущностями «Управление взаимодействием с клиентами», проставлены отношения расширения (extend). При этом на данном уровне абстракции ничего не говорится о том, каким образом будет реализовано взаимодействие актёров с системой. Диаграмма вариантов использования приведена на рис. 3.1.



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

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

Таблица 3.1 Сценарий варианта использования «Заключение договора»

Главный раздел
Вариант использования	Заключение договора
Актёры	Клиент, Менеджер
Цель	Составить договор
Краткое описание	Клиент совместно с Менеджером составляют договор об оказании услуг с помощью автоматизированной системы
Тип	Базовый
Ссылки на другие варианты использования	Включается в вариант использования «Модуль CRM система»

Таблица 3.2 Типичный ход событий

Действия актёров	Отклик системы
1. Клиент консультируется с Менеджером и сообщает ему требования для составления договора на оказание услуг. 2. Менеджер выбирает в системе «Создание нового договора».	3. Система предлагает менеджеру выбрать тип договора.
4. Менеджер выбирает тип договора из списка, предлагаемого Системой.	5. Система выводит на экран форму договора и предлагает менеджеру заполнить все необходимые поля.
6. Менеджер заполняет необходимые поля договора.	7. Система проверяет заполнение полей формы договора на наличие ошибок. Искл.1 Заполнены не все обязательные поля предлагаемой формы договора. Искл.2 Поля формы содержат ошибки.
9. Менеджер подтверждает сохранение документа.	8. Система предлагает пользователю сохранить созданный документ. 10. Система сохраняет документ в соответствующей директории.
11. Клиент проверяет правильность заполненных данных.	12. Система предлагает распечатать созданный документ.
13. Менеджер отправляет документ на печать.	14. Система проверяет подключение выбранного принтера. Искл.3 Выбранный для печати документа принтер не подключен. 15. Система выводит документ на печать. 16. Система выводит на экран сообщение об успешном завершении работы с новым документом.

Таблица 3.3 Исключения

Действие актёров	Отклик системы
Исключение 1. Заполнены не все обязательные поля предлагаемой формы договора
	8. Система информирует пользователя о наличии незаполненных полей.
6. Менеджер заполняет необходимые поля формы договора.
Исключение 2. Поля формы договора содержат ошибки
6. Менеджер вносит необходимые исправления.	8. Система выводит на экран сообщение о наличии ошибок в заполнении полей формы договора и подсвечивает поля, содержащие ошибки.
Исключение 3. Выбранный для печати документа принтер не подключен
13. Менеджер проверяет настройки печати и выбирает подключенный принтер.	15. Система выводит на экран сообщение «Выбранный для печати принтер не подключен»

Таблица 3.4 Сценарий варианта использования «Управление взаимодействием с клиентами»

Вариант использования	Управление взаимодействием с клиентами
Актёры	Менеджер
Цель	Обеспечить автоматизацию процесса
Краткое описание	Основной функциональный блок - система управления взаимоотношениями с клиентами.
Тип	Базовый
Ссылки на другие варианты использования	Включает в себя варианты использования: · Подготовка данных · Обработка данных · Анализ и прогнозирование · Создание отчёта

Таблица 3.5 Типичный ход событий

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

Таблица 3.6 Исключения

Действие актёров	Отклик системы
Исключение 1. Заполнены не все обязательные поля предлагаемой формы ввода нового клиента в базу данных
6. Менеджер заполняет необходимые поля формы.	5. Система информирует пользователя о наличии незаполненных полей.
Исключение 2. Поля формы содержат ошибки
6. Менеджер вносит необходимые исправления.	5. Система выводит на экран сообщение о наличии ошибок в заполнении полей формы ввода клиента в базу данных и подсвечивает поля, содержащие ошибки.

Таблица 3.7 Сценарий варианта использования «Модуль подготовки данных»

Вариант использования	Модуль “Подготовки данных”
Актёры	Аналитик
Цель	Собрать максимальное количество данных для совершения обработки и анализа данных.
Краткое описание	С помощью модуля подготовки данных Аналитик производит первичную обработку сведений, необходимых для принятия решения по запросу Клиента.
Тип	Базовый
Ссылки на другие варианты использования	Включается в вариант использования «Модуль CRM система»

Таблица 3.8 Типичный ход событий

Действия актёров	Отклик системы
1. Аналитик в соответствии с договором на оказание услуг определяет проблему и формулирует цель исследования для последующего принятия решения по запросу Клиента.
2. Аналитик собирает необходимые данные для исследования и вводит их в Систему в качестве входных данных для дальнейшей обработки. 4. Аналитик указывает в соответствующем поле программы путь к файлу с входными данными.	3. Система предлагает пользователю указать путь к файлу, содержащему входные данные. 5. Система загружает файл. Искл. 1 Некорректный формат загружаемого файла.
6. Аналитик выбирает инструменты обработки данных Системы, соответствующие типу и цели проводимого анализа. 8. Аналитик выбирает способ визуализации результатов обработки из списка (таблица, график, дерево и т.д.).	7. Система выполняет предварительную обработку данных и предлагает пользователю выбрать способ визуализации результатов. Искл. 2 Возникла ошибка при обработке данных. 9. Система выдаёт результат обработки в форме таблицы, графика, дерева и т.д.
11. Аналитик выбирает формат файла с результатами обработки из списка и подтверждает его сохранение.	10. Система предлагает пользователю сохранить результаты обработки данных в одном из доступных форматов. 12. Система сохраняет файл в указанном формате.

Таблица 3.9 Исключения

Действие актёров	Отклик системы
Исключение 1 Некорректный формат загружаемого файла
	5. Система выводит на экран сообщение о некорректном формате файла и предлагает пользователю изменить формат загружаемого файла и повторить попытку снова.
Исключение 2 Возникла ошибка при обработке данных.
	7. Система прекращает обработку данных и выводит на экран сообщение об ошибке, её возможной причине и рекомендуемых способах устранения.

Таблица 3.10 Сценарий варианта использования «Модуль обработки данных»

Вариант использования	Модуль “Обработки данных”
Актёры	Аналитик
Цель	Обработать данные для прогнозирования и автоматизации предприятия клиента
Краткое описание	Аналитик вводит предварительно обработанные данные в систему с целью их детального анализа и прогнозирования.
Тип	Базовый
Ссылки на другие варианты использования	Включается в вариант использования «Модуль CRM система»

Таблица 3.11 Типичный ход событий

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

Таблица 3.12 Исключения

Действие актёров	Отклик системы
Исключение 1. Выбран алгоритм «Деревья решений»
5. Аналитик с помощью диалогового окна Системы выбирает способ построения дерева решений.	4. Система предлагает пользователю выбрать способ построения дерева решений - автоматический или интерактивный. 6. Система анализирует входные данные в соответствии с алгоритмом и по окончании анализа выдаёт список иерархических правил, образующих дерево.
Исключение 2. Выбран алгоритм «Кластеризация»
5. Аналитик указывает соответствующие настройки в полях диалогового окна и запускает процесс кластеризации.	4. Система предлагает пользователю указать настройки параметров кластеризации (автоматически или вручную). 6. Система производит процесс обучения модели кластеризации.
Исключение 3. Выбран алгоритм «Ассоциативные правила»
5. Аналитик указывает настройки в полях диалогового окна и запускает процесс поиска ассоциативных правил.	4. Система предлагает пользователю указать настройки параметров построения ассоциативных правил. 6. Система производит поиск ассоциативных правил.

Таблица 3.13 Сценарий варианта использования «Анализ и прогнозирование данных»

Вариант использования	Анализ и прогнозирование данных
Актёры	Аналитик
Цель	Произвести анализ обработанных данных и сформировать прогноз, необходимый для принятия решения.
Краткое описание	Система с помощью встроенных алгоритмов анализирует обработанные на предыдущем этапе данные и формирует прогноз.
Тип	Базовый
Ссылки на другие варианты использования	Включается в вариант использования «Модуль CRM система»

Таблица 3.14 Типичный ход событий

Действия актёров	Отклик системы
1.Аналитик загружает обработанные Системой и сохранённые в необходимом формате данные в модуль анализа и прогнозирования данных. 3. Аналитик выбирает метод анализа из списка и подтверждает выбор.	2. Система предлагает выбрать алгоритм анализа данных. 4. Система запускает анализ данных.
6. Аналитик указывает соответствующие настройки в полях диалогового окна и запускает процесс прогнозирования.	5. По окончании анализа Система предлагает настроить параметры прогнозирования. 7. Система запускает процесс прогнозирования. Искл.1 Ошибка в процессе прогнозирования.
9. Аналитик выбирает из списка способы отображения результатов. 11. Аналитик нажимает кнопку «Сохранить результат».	8. Система предлагает выбрать способ визуализации результатов анализа и прогнозирования. 10. Система выводит на экран результаты анализа и прогнозирования в указанном виде. 12. Система сохраняет результаты анализа и прогнозирования.

Таблица 3.15 Исключения

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

Таблица 3.16 Сценарий варианта использования «Создание отчёта»

Вариант использования	Создание отчёта
Актёры	Менеджер
Цель	Создать отчёт.
Краткое описание	Создание отчёта на основе анализа и прогнозирования данных.
Тип	Базовый
Ссылки на другие варианты использования	Включается в вариант использования «Модуль CRM система»

Таблица 3.17 Типичный ход событий

Действия актёров	Отклик системы
1. Менеджер на основе полученных анализов и прогноза данных генерирует отчёт. 3. Менеджер выбирает подходящий формат для данного отчёта.	2. Система предлагает выбрать формат для генерации отчёта. 4. Система генерирует отчёт. Искл.1 Ошибка в процессе генерации отчёта.
5. Менеджер отправляет сгенерированный отчёт на печать.	6. Система отправляет отчёт на печать.

Таблица 3.18 Исключения

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

3.2 Описание диаграммы классов (Class diagram)

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

Диаграмма классов для разрабатываемой нами системы, приводится на рис. 3.2.

Рис. 3.2 - Диаграмма классов (Class diagram)

В таблице 3.19 представлены описательные спецификации диаграммы классов.

Таблица 3.19 Описательные спецификации диаграммы классов

Наименование	Комментарий
1. Server	Отвечает за контроль всей системы. С помощью сервера осуществляются все операции
2. DBMS	СУБД. В ней хранятся все данные о клиентах компании
3. CRM system module	Отвечает за управление взаимодействием с клиентом
4. Reporting module	Модуль отчётов
5. Module creating predictive models	Модуль создания прогностических моделей.
6. Data preprocessing module	Модуль предварительная обработка данных
7. Contract drafting module	Модуль составления договора
8. Processing algorithm module	Алгоритмы обработки данных
9. Data processing module	Модуль обработки данных
10. Client	Клиенты
11. Service	Услуги
12. Contract	Договора
13. Printer	Печать

Таблица 3.20 Описание структуры класса «CRM system module»

Наименование	Тип данных	Комментарий
contact	атрибут	Контакты (клиентская база)
status	атрибут	Статус клиента
reminder	атрибут	Номер телефона клиента
fillContact()	операции	Заполнить контакты
statusAssign()	операции	Выбрать статус клиенту
creatReminder()	операции	Создать напоминание
sendSMS()	операции	Отправить СМС оповещение
recordingCall()	операции	Запись звонков

Таблица 3.21 Описание структуры класса «Reporting module»

Наименование	Тип данных	Комментарий
reportNumber	атрибут	Номер отчёта
reportID	атрибут	Уникальный номер отчёта
reportGenerate()	операции	Сгенерировать отчёт
sendPrinting()	операции	Отправить отчёт на печать

Таблица 3.22 Описание структуры класса «Module creating predictive models»

Наименование	Тип данных	Комментарий
algorithmType	атрибут	Тип алгоритма
loadPRData()	операции	Загрузить пред обработанные данные
createPrognosticModel()	операции	Создать прогностическую модель
withdrawResults()	операции	Отправить отчёт на печать
saveResult()	операции	Вывести результаты (прогностическая модель)

Таблица 3.23 Описание структуры класса «Data preprocessing module»

Наименование	Тип данных	Комментарий
filePath	атрибут	Путь к файлу
createFile()	операции	Создать файл
loadFile()	операции	Загрузить файл
preproccesData()	операции	Предобработка данных
saveFile()	операции	Сохранить файл

Таблица 3.24 Описание структуры класса «Contract drafting module»

Наименование	Тип данных	Комментарий
filePath	атрибут	Путь к файлу
syntaxCheck()	операции	Проверка синтаксиса
saveDoc()	операции	Сохранить документ
printContract()	операции	Отправить контракт на печать

Таблица 3.25 Описание структуры класса «Processing algorithm module»

Наименование	Тип данных	Комментарий
lloadModel()	операции	Загрузить модель
fulfillForecast()	операции	Выполнить прогноз
setParamAlg()	операции	Установить параметры алгоритма
saveResult()	операции	Сохранить результат

Таблица 3.26 Описание структуры класса «Data processing module»

Наименование	Тип данных	Комментарий
typeOfAlgorithm	атрибут	Тип алгоритма
Data	атрибут	Данные
reportPath	атрибут	Путь к отчёту
downloadPrognocticModel()	операции	Скачать прогностическую модель
chooseAlgorithm()	операции	Выбрать алгоритм
processData()	операции	Обработать данные
saveReport()	операции	Сохранить отчёт

Таблица 3.27 Описание структуры класса «Client»

Наименование	Тип данных	Комментарий
Name	атрибут	Имя
personalInformation	атрибут	Паспортные данные
phoneNumber	атрибут	Телефонный номер
position	атрибут	Должность
companyName	атрибут	Наименование компании

Таблица 3.28 Описание структуры класса «Service»

Наименование	Тип данных	Комментарий
servicesName	атрибут	Наименование услуги
shortDescription	атрибут	Краткое описание предоставляемых услуг
serviceCost	атрибут	Стоимость услуг

Таблица 3.29 Описание структуры класса «Contract»

Наименование	Тип данных	Комментарий
filePath	атрибут	Путь к файлу
contractTyp	атрибут	Тип договора
contractNumber	атрибут	Номер договора
contractDate	атрибут	Дата заключения контракта
companyName	атрибут	Наименование компании
serviceName	атрибут	Наименование услуги

Таблица 3.30 Описание структуры класса «Printer»

Наименование	Тип данных	Комментарий
printing()	операции	Печать

3.3 Описание диаграммы последовательности (Sequence diagram)

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

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



Рис. 3.3 - Диаграмма последовательности для варианта использования «Заключение договора»

Рис. 3.4 - Диаграмма последовательности для варианта использования «Подготовка данных»



Рис. 3.5 - Диаграмма последовательности для варианта использования «Обработка данных»

Рис. 3.6 - Диаграмма последовательности для варианта использования «Управление взаимодействием с клиентами»



Рис. 3.7 - Диаграмма последовательности для варианта использования «Анализ и прогнозирование данных»

Рис. 3.8 - Диаграмма последовательности для варианта использования «Создание отчёта»

3.4 Описание диаграммы состояний (Statechart Diagram)

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

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

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

3.5 Описание диаграммы деятельности (Activity Diagram)

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

3.6 Описание диаграммы компонентов (Component Diagram)

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

Диаграмма компонентов для разрабатываемой нами системы приводится на рис. 3.7

Рис. 3.7 - Диаграмма компонентов (Component Diagram)

3.6 Описание диаграммы развёртывания (Deployment Diagram)

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

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

Рис. 3.8 - Диаграмма развёртывания (Deployment Diagram)

На рисунке 3.8 представлен пример диаграммы развёртывания для исследуемой консалтинговой компании. Псевдотрёхмерные параллелепипеды представляют собой узлы программного или аппаратного обеспечения.

3.9 Описание ER-диаграммы (ER Diagram)

В настоящее время ИС разрабатываются с помощью различных методологий разработки ПО. Как следствие, разработчикам требуется инструмент для моделирования данных на этапах анализа и проектирования. В нашем случае используется ER-диаграммы (Entity-Relationship, «Сущность-Связь»). Использование данного вида диаграмм являются, как правило, обязательным при разработке ИС. ER-диаграммы дают возможность строить модели логической структуры данных.

Рис. 3.9 - ER-диаграмма (ER Diagram)

3.10 Генерация кода для классов

На основе диаграммы классов, был сгенерирован код для классов. Для каждого класса создаются два файла: файл заголовка (.h) и файл спецификаций (.срр). Всего было создано 12 файлов.

Заключение

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

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

Изучены основные методики моделирования программного обеспечения (ПО) и выбрана наиболее подходящая из них для данной ситуации. Этой методикой является язык UML 2.x поскольку он является самым эффективным инструментом для моделирования программных систем.

Проанализированы существующие среды моделирования, которые используют UML 2.x. Для построения модели ИС для консалтинговой организации был выбран StarUML 2 поскольку данный программный продукт позволяет строить эффективные модели ПО обладает удобным интерфейсом и полностью соответствует стандарту UML 2.x.

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

По построенной модели сгенерирована заготовка программного кода для классов. Код был сгенерирован на языке C++.

Размещено на Allbest.ru

...