Файл: Моделирование предметной области «Ведение договоров по страхованию автотранспортных средств» с помощью UML (Описание предметной области).pdf

Персональный компьютер (далее ПК) предназначен для эксплуатации в закрытом отапливаемом помещении с влажностью не выше 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) - это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.

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