Автор работы: Пользователь скрыл имя, 13 Января 2013 в 22:36, дипломная работа
Дипломный проект рассматривает вопросы автоматизации, направленные на решение основных проблем в бизнесе страховой компании, занимающейся добровольным медицинским страхованием.
Целью дипломного проекта является повышение эффективности бизнеса страховой компании за счет увеличения гибкости её информационной системы.
Введение 9
Цель дипломного проекта 17
Постановка задачи 17
1 Специальная часть 19
1.1 Обоснование выбора сервис-ориентированной архитектуры 19
1.2 Выбор инструментальных средств проектирования и разработки 32
1.2.1 Обоснование выбора средств моделирования бизнес процессов 32
1.2.2 Обоснование выбора CASE средств проектирования 37
1.2.3 Обоснование выбора СУБД 38
1.2.4 Набор программных средств, используемых в ходе дипломного проектирования 38
1.3 Используемые методы и стандарты 39
1.3.1 Разработка, управляемая моделями 39
1.3.2 Независимость от платформы 42
1.3.3 Программная платформа 43
1.3.4 Модель требований FURPS 44
1.4 Формирование требований к разрабатываемой системе 46
1.4.1 Проект требований 47
1.5 Моделирование бизнес-процессов 49
1.5.1 Моделирование бизнес процесса как есть 49
1.5.2 Анализ бизнес-процессов «как есть». 53
1.5.3 Результаты имитации 55
1.5.4 Моделирование бизнес-процессов «как должно быть» 58
1.5.5 Анализ модели «как должно быть». Сравнение результатов 59
1.6 Разработка UML-модели системы 61
1.6.1 Трансформация модели бизнес процессов в UML-модель 61
1.6.2 Модификация полученной в результате трансформации UML-модели 63
1.7 Разработка сервисной модели 69
1.7.1 Трансформация в сервисную модель 69
1.7.2 Идентификация сервисов 71
1.7.3 Моделирование сервисов 73
1.8 Разработка базы данных 77
1.8.1 Трансформация UML-модели в логическую модель данных 77
1.8.2 Получение окончательной логической модели данных 81
1.8.3 Разработка физической модели данных 82
1.8.4 Генерация базы данных на основе физической модели данных 84
1.9 Реализация сервисов 85
1.10 Выводы 87
2 Экономическая часть 89
2.1 Экономическая эффективность от внедрения сервисов, реализованных на базе сервис-ориентированной архитектуры. 89
2.1.1 Абсолютный показатель изменения годовой трудоемкости обработки информации в результате внедрения SOA-решения для процесса заключения договора страхования 90
2.1.2 Абсолютный показатель изменения годовых затрат на обработку информации в результате внедрения SOA-решения для процесса заключения договора страхования 91
2.1.3 Относительные показатели изменения годовой трудоемкости и годовых затрат на обработку информации в результате внедрения проекта 97
2.1.4 Расчетный коэффициент эффективности единовременных затрат на разработку и внедрение проекта 98
2.1.5 Срок окупаемости единовременных затрат на разработку и внедрение проекта 104
2.2 Выводы 104
3 Экологическая часть и безопасность жизнедеятельности 105
3.1 Требования к организации рабочего места пользователя (сотрудника страховой компании) 105
3.2 Вредные излучения при работе компьютера и способы их минимизации 113
3.3 Заболевания, развивающиеся при работе за компьютером, и их профилактика 116
3.4 Выводы 118
Заключение 120
Список использованной литературы 122
Приложение А. 126
Проект требований 126
Приложение Б. 129
Модель бизнес-процессов 129
Приложение В. 139
Трансформированная модель бизнес-процессов в UML-модель 139
Приложение Г. 155
Трансформированная сервисная модель 155
Приложение Д. 162
WSDL описания сервисов 162
Приложение Е. 178
Исходный Java-код сервисов 178
Приложение Ж. 191
Логическая модель данных, полученная путем трансформации UML-модели 191
Приложение И. 202
SQL скрипт для генерации схемы базы данных 202
Выбор IBM DB2 обосновывается следующими преимуществами:
Таким образом, в дипломном проекте используются следующие средства для проектирования и разработки:
В дипломном проекте применяется технология разработки, управляемой моделями (model-driven development, MDD). Разработка, управляемая моделями, - это такой стиль разработки программ, когда главными артефактами являются модели, а по ним генерируется код и другие прикладные артефакты[13].
Разработка, управляемая моделями, потенциально способна значительно улучшить современную общепринятую практику разработки программного обеспечения. Преимущества MDD следующие:
1) Повышение производительности. MDD снижает стоимость разработки программного обеспечения с помощью генерации кода и артефактов по моделям, что повышает производительность труда разработчика.
2) Удобство обслуживания. Технологический прогресс приводит к тому, что компоненты решений становятся тяжелым наследством технологий предыдущих платформ. MDD создает удобную для поддержки архитектуру, изменения в которую вносятся быстро и связно, что позволяет более эффективно переводить компоненты на новые технологии.
3) Высокоуровневые модели остаются свободными от несущественных деталей реализации. Свобода от деталей реализации позволяет справиться с изменением базовых технологий платформ и их технической архитектуры. Часто решения с течением времени становятся ошибочными и перестают соответствовать текущему состоянию предметной области. Модели предметной области позволяют легко изменять проект решения, исследовать поведение системы в различных условиях. Таким образом, исправление ошибок становится менее накладным.
4) Повторное использование унаследованных компонентов. Существует возможность обратных трансформаций - из реализованных компонентов в UML. В таком случае снижается трудоемкость перевода компонентов на новую платформу или генерации интерфейсов, чтобы к унаследованному компоненту можно было обращаться через интеграционные технологии, например через Web-службы.
5) Адаптируемость. Возможность адаптации - это ключевое требование бизнеса, и IT-системы должны поддерживать его. При использовании MDD добавление или модификация бизнес-функции становится достаточно простым делом, поскольку инвестиции в автоматизацию уже сделаны. При добавлении новой бизнес-функции вам нужно только разработать поведение, относящееся к этой новой функции. Вся остальная информация, необходимая для генерации артефактов реализации, уже заключена в трансформациях.
6) Согласованность. Ручное применение практик кодирования и архитектурных решений весьма способствует появлению ошибок. MDD содействует тому, чтобы артефакты генерировались согласованно.
7) Повторяемость. Подход MDD особенно хорош, если его применять на уровне программы или организации. Это происходит потому, что возврат на инвестиции (ROI) на разработку трансформаций увеличивается при каждом их повторном применении. Использование опробованных и протестированных трансформаций также повышает предсказуемость при разработке новых функций и уменьшает риск, поскольку архитектурные и технические проблемы были уже разрешены.
8) Совершенствование общения с заинтересованными сторонами. В моделях опускаются детали реализации, несущественные для понимания логического функционирования системы. Следовательно, модели гораздо ближе к предметной области проблемы, что уменьшает разрыв между концепциями, понятными заинтересованным сторонам, и языком, каким выражается решение. Совершенствование процесса коммуникации способствует созданию решений, лучше соответствующих целям бизнеса.
9) Совершенствование общения при проектировании. Модели облегчают понимание и обоснования системы на уровне дизайна. Это позволяет сделать обсуждение системы более продуктивным. Тот факт, что модели являются частью определения системы, а не частью документации, означает, что модели никогда не будут устаревшими или недостоверными.
10) Фиксация опыта. Проекты и организации часто зависят от ключевых экспертов, которые регулярно создают практические решения. Если их опыт будет заключен в шаблонах и трансформациях, то их присутствие не будет обязательным, чтобы их опыт могли использовать другие участники проекта. Дополнительное преимущество, при условии, если к трансформациям прилагается достаточная документация, состоит в том, что знания организации сохраняются в шаблонах и трансформациях, если даже эксперты покинут организацию.
11) Модели как долгоживущие активы. В MDD модели - это важное достояние, в которых фиксируется то, что делают IT-системы организации. Высокоуровневые модели устойчивы к изменениям, связанным с совершенствованием платформенного уровня. Они изменяются только тогда, когда изменяются бизнес-требования.
12) Возможность отсрочки технологических решений. При использовании MDD ранняя стадия разработки приложения в основном касается моделирования. Это означает, что существует возможность отсрочить выбор конкретной технологической платформы или версии продукта до получения дополнительной информации. В предметных областях с чрезвычайно длительными циклами разработки, таких, как системы управления воздушным движением, этот момент является критическим. Платформа может вообще не существовать на момент начала разработки.
Применяя метод MDD, модели на различных уровнях являются не просто набросками, а частью определения системы. Эти модели имеют четкую семантику и могут быть преобразованы в артефакты реализации.
Метод MDD в дипломном проекте применяется на следующих этапах:
Для преобразований моделей и генерации кода применяется трансформация, автоматизирующая создание артефактов из моделей. Сюда входит генерация кода, а также генерация более детальных моделей. Как правило, трансформация применяется в пакетном режиме для всей модели.
Помимо независимого от платформы моделирования для реализации сервисов в дипломном проекте используются следующие стандарты[11]:
Для программной реализации
в дипломном проекте выбрана сп
Идеологи SOA ожидают, что во многих SOA проектах будет использоваться платформа J2EE. J2EE является промышленной технологией и в основном используется в высокопроизводительных проектах, в которых необходима надежность, масштабируемость и гибкость.
Реализованные сервисы предполагается разворачивать на сервере приложений IBM WebSphere Application Server Community Edition (IBM WASCE). IBM WASCE не единственные сервер приложений, на котором могут быть развернуты реализованные сервисы. В силу того, что используются независимые от платформы стандарты, решение об используемом сервере приложений можно принять непосредственно перед сборкой (компиляцией) сервиса.
В дипломном проекте для описания требований использована модель требований FURPS. Эта модель описана в международном стандарте IEEE Std 610.12-1990[14].
Аббревиатура FURPS состоит из первых букв английских названий соответствующих основных типов требований
В рамках этой модели четко разделяются функциональные и нефункциональные требования:
Функциональные требования (Functional requirements) описывают действия, которые должна уметь выполнять создаваемая программная система. Функциональные требования выстраиваются в вертикальную иерархию - от высокоуровневых через среднеуровневые к низкоуровневым, при этом уровней может быть различное количество - столько, сколько при проектировании требований сочтет нужным выделить системный аналитик.
Высокоуровневые и среднеуровневые функциональные требования в данной схеме именуются требованиями возможности (Features), а низкоуровневые - прецедентами (Use Cases), поскольку они непосредственно детализируются визуальными прецедентами, диаграммы которых строятся в инструменте моделирования. При вводе в систему IBM Rational RequisitePro требования возможности маркируются тегом FEAT, а требования-прецеденты - тегом UC.
В данном дипломном проекте все требования ведутся (собираются, систематизируются, модифицируются) в инструменте IBM Rational RequisitePro. В инструменте Rational Software Architect ведется только визуальная модель прецедентов (Use Case Model), диаграммы которой на разных своих уровнях связываются с низкоуровневыми функциональными требованиями (маркированными тегом UC), которые фиксированы в инструменте RequisitePro. Таким образом, различные диаграммы в RSA (диаграммы прецедентов (Use Case Diagrams), диаграммы деятельности (Activity Diagrams), диаграммы последовательностей (Sequence Diagrams)) с точки зрения управления требованиями иллюстрируют соответствующие требования, зафиксированные в RequisitePro.
Все требования, не являющиеся функциональными, относятся к нефункциональным требованиям (non-functional requirements). Нефункциональные требования описывают те или иные атрибуты системы или системного окружения, при этом они почти никогда не детализируются посредством прецедентов. В дипломном проекте нефункциональные требования заводятся в систему RequisitePro как дополнительные требования (Supplementary Requirements) и маркируются тегом SUPPL. Поскольку типов нефункциональных требований довольно много, для их разграничения у нефункциональных требований введен атрибут типа (с возможными значениями, выделенными на основе модели FURPS), который должен заполняться при вводе требования.
Требования к разрабатываемой системы были отнесены в ту или иную категорию по определенным критериям.
Функциональные требования. К функциональным требованиям относятся следующие: описания требуемой функциональности системы, т.е. описания того, что система должна уметь делать.
Высокоуровневые и среднеуровневые функциональные требования заведены как требования возможности - тег FEAT.
Низкоуровневые функциональные требования, которые постулируют конкретные производственные процессы, носящие динамический характер, благодаря чему они затем описываются через прецеденты и передаются на реализацию в разработку, заведены как требования-прецеденты - тег UC.
Нефункциональные требования заведены как дополнительные требования - тег SUPPL.
При заведении нефункциональные требования классифицируются по типу - им присваивается соответствующее значение атрибута Тип (Type):
В IEEE Standard Glossary of Software Engineering Terminology (1990) понятие требования трактуется следующим образом. Требование - это:
FEAT 1: Информация о клиенте. Система должна сохранять данные о клиенте.
FEAT 2: Поиск клиента по параметрам. Система должна обеспечивать поиск клиента, списка клиентов по заданным параметрам: