Автор работы: Пользователь скрыл имя, 17 Мая 2015 в 22:02, курсовая работа
На базе разработанной информационной системы обеспечивается решение следующих задач:
Расширение сферы безбумажного делопроизводства и документооборота внутри организации;
Управление прайс-листами и услугами организации;
Организация рекламных кампаний
Подготовка и заключение договоров со сторонними организациями;
Оформление приема, перевода и увольнения работников;
Разграничение прав доступа;
ВВЕДЕНИЕ 11.
1 СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ 13.
1.1 Описание предметной област 13.
1.4 Определение логической структуры АИС 14.
1.4.1 Логическое проектирование 14.
1.4.2 Логическая модель АИС 15.
1.4.3 Нормализация 21.
1.5 Разработка информационно-логической структуры системы 22.
1.5.1 Краткое описание методологии UML 22.
1.5.2 Диаграмма вариантов использования 23.
1.5.3 Диаграмма классов 28.
1.5.4 Диаграмма состояний 32.
1.5.5 Диаграмма деятельности 35.
2 КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ 37.
2.1 Физическая модель базы данных 37.
2.2 Выбор и обоснование программных средств разработки 41.
2.3 Выбор технических средств и ресурсный анализ 42.
2.3.1 Расчет необходимого объема памяти 42.
2.3.2 Расчет времени реакции системы 43.
2.3.3 Требования к комплексу технических средств 44.
2.4 Разработка программного обеспечения 45.
2.4.1 Структура программной системы 45.
2.4.1.1 Диаграмма компонентов 46.
2.4.1.2 Диаграмма развертывания 47.
2.4.1.3 Описание модулей системы 48.
2.4.3 Разработка интерфейса системы 50.
3 ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ АИС УПРАВЛЕНИЯ УСЛУГ ПРЕДПРИЯТИЯ И ЕГО ПЕРСОНАЛА 55.
3.1 Планирование и организация процесса разработки 55.
3.2 Технико-экономическое обоснование автоматизированной информационной системы (АИС) 62.
3.2.1 Расчет затрат на разработку автоматизированной информационной системы (АИС) 63.
3.2.2 Расчет-прогноз минимальной цены разработки автоматизированной информационной системы (АИС) 65.
3.2.3 Оценка безубыточности и расчет целесообразного объема продаж 67.
3.2.4 Расчет единовременных затрат на внедрение 69.
3.2.5 Расчет текущих затрат на функционирование АИС 71.
3.2.6 Расчет экономических результатов от внедрения 72.
3.2.7 Методы расчета экономической эффективности инвестиционных (капитальных) затрат 73.
4 БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ 77.
4.1 Обеспечение безопасности объекта автоматизации 79.
4.1.1 Информационная безопасность в СУБД SQL Server 2008 80.
4.1.3 Оценка надежности разработанной АИС 83.
4.2 Оценка напряженности трудового процесса пользователя АИС 85.
4.2.1 Нагрузки интеллектуального характера 85.
4.2.1.1 Содержание работы 85.
4.2.1.2 Восприятие сигналов (информации) и их оценка 86.
4.2.1.3 Распределение функций по степени сложности задания 87.
4.2.1.4 Характер выполняемой работы 88.
4.2.2 Сенсорные нагрузки 88.
4.2.2.1 Длительность сосредоточенного наблюдения (в % от времени смены)…… 88.
4.2.2.2 Плотность сигналов (световых, звуковых) и сообщений в среднем за
1 час работы 89.
4.2.2.3 Размер объекта различения при длительности сосредоточенного
внимания (% от времени смены) 89.
4.2.2.4 Наблюдение за экраном видеотерминала (ч в смену) 89.
4.2.2.5 Нагрузка на слуховой анализатор 90.
4.2.2.6 Нагрузка на голосовой аппарат (суммарное количество часов наговариваемых в неделю) 90.
4.2.3 Эмоциональные нагрузки 90.
4.2.3.1 Степень ответственности за результат собственной деятельности. Значимость ошибки 90.
4.2.3.2 Степень риска для собственной жизни. 91.
4.2.3.3 Ответственность за безопасность других лиц 91.
4.2.3.4 Количество конфликтных производственных ситуаций за смену 91.
4.2.4 Монотонность нагрузок 92.
4.2.4.1 Продолжительность выполнения простых производственных заданий или повторяющихся операций. 92.
4.2.4.2 Время активных действий (в % к продолжительности смены)…… 92.
4.2.4.3 Монотонность производственной обстановки (время пассивного
наблюдения за ходом техпроцесса, в % от времени смены) 92.
4.2.5 Режим работы 93.
4.2.5.1 Фактическая продолжительность рабочего дня 93.
4.2.5.2 Сменность работы 93.
4.2.5.3 Наличие регламентированных перерывов и их продолжительность
(без учета обеденного перерыва) 93.
4.2.5.4Общая оценка напряженности трудового процесса 93.
ЗАКЛЮЧЕНИЕ 97.
СПИСОК СОКРАЩЕНИЙ 99.
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ 100.
Разработка унифицированного языка объектно-ориентированного моделирования Unified Modeling Language (UML) обуславливалась требованиями, предъявляемыми к языку моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода, сильные стороны известных методов, и давал бы четкую модель системы, отражающую все ее значимые стороны, и обеспечивал наилучшую поддержку моделирования.
Унифицированный язык объектно-ориентированного моделирований (UML) явился средством достижения компромисса между объектно-ориентированными методами, лидерами в этой области в девяностых годах, которые имели свои сильные и слабые стороны:
UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:
UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.
В терминах языка UML определены следующие виды диаграмм:
UML был создан для определения, визуализации, проектирования и цитирования в основном программных систем, также бизнес-систем, и других систем различной природы.
1.5.2 Диаграмма вариантов
Для управления процессом разработки АИС и определения функциональных требований к системе построена диаграмма вариантов использования (use case diagram), которая определяет общие границы и контекст моделируемой предметной области.
Разработанная исходная концептуальная модель используется для ее последующей детализации в форме логических и физических моделей, а е, для выполнения проектирования и тестирования системы (см. раздел 1.6).
Диаграмма вариантов использования состоит из актантов (актеров), для которых система производит действия и собственно действия Use Case, которое описывает то, что актант хочет получить от системы.
Данная система состоит из следующих актантов:
Актанты, являясь пользователями системы, обобщаются к одному актанту «Пользователь» и используют определенный необходимый им функционал (вариант использования) разработанной системы.
При начале работы с АИС управления услуг предприятия и его персонала пользователь инициирует процесс «Входа в систему», который использует систему аутентификации и авторизации пользователя. Таким образом, активизируются дополнительные действия такие как «Установить подлинность», «Определить права доступа» и «Настроить интерфейс».
Каждый актант данной системы инициирует определенные варианты использования, соответствующие их ролям. Ниже приведено описание взаимодействий актантов и вариантов использования.
Администратор инициирует вариант использования «Вести административные функции», который является обобщением административных действий данного актанта, таких как «Вести информацию по Пользователям», «Разграничение прав».
Актант «Сотрудник отдела кадров», инициирует вариант использования «Вести информацию о пользователях системы», «составление графика работ».
Актант «Сотрудник отдела информационно аналитического отдела» использует подсистему выбора справочника, для чего инициирует обобщающий вариант использования «Вести справочную информацию», который расширяется на «Вести информацию по сторонним организациям», «Вести информацию по филиалам», вариант использования «Вести информацию по прайс листам» и «Вести информацию по договорам».
Диаграмма вариантов использования для АИС управления услуг предприятия и его персонала показана на рисунке 1.2
Для основных вариантов использования составлены сценарии их использования (текстовое описание).
Рассмотрим сценарий для варианта использования «Войти в систему». Вариант использования: Войти в систему.
Краткое описание: Осуществляет процедуры аутентификации и авторизации пользователя. Определяет роли и настраивает интерфейс, в соответствии с правами доступа пользователя системы.
Актант: Пользователь.
Предусловия: Пользователь должен выполнить вход в операционную систему и активизировать запуск программы. Основной поток событий:
А1: Пользователь отклоняет вход и нажимает кнопку «Отмена».
А2: Введено неправильное имя или пароль пользователя.
Альтернативы:
А 1: Пользователь отклоняет вход нажатием кнопки «Отмена».
А 1.1. Система закрывает окно для ввода имени пользователя и пароля и завершает работу программы.
А2: Введено неправильное имя или пароль пользователя.
A2.1 Система предупреждает пользователя о неправильно введенном имени или пароле и сообщает о невозможности выполнения входа, после чего пользователь повторяет ввод, либо отклоняет вход в систему. Последнее действие пользователя завершает выполняет варианта использования.
Постусловия: При успешном выполнении варианта использования система отображает главное окно программы с настроенным в соответствии с определенными параметрами пользователя интерфейсом.
Актант: Администратор.
А2 Администратор инициирует вариант использования «Вести информацию по пользователям» и «Разграничение прав» разрешая соответствующие права доступа или отклоняя их. Последнее действие актанта завершает выполнение варианта использования.
Постусловия: При успешном выполнении варианта использования, решается проблема установки соединения с базой данных EPOS и осуществляется загрузка.
1.5.3 Диаграмма классов
Диаграммы классов используются для моделирования статического вида системы с точки зрения проектирования.
Построенные диаграммы классов используются для документирования программной системы (см. раздел 2.3), являются основой для разработки полной модели системы путем дополнения их диаграммами состояний и взаимодействий.
Основным компонентом диаграмм является класс, который служит для обозначения множества объектов, обладающих одинаковой структурой, поведением и отношениями с объектами других классов .
Для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) существует три специальных графических примитива:
Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Управляющий класс изображен в форме прямоугольника класса со стереотипом ««control»»;
Этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции присоединенными или хранимыми процедурами. Класс – сущность изображен также стандартным образом в форме прямоугольника класса со стереотипом ««entity»»;
Диаграммы классов для АИС управления услуг предприятия и его персонала показаны на рисунках 1.3 -1.4
1.5.4 Диаграмма состояний
Диаграмма состояний (statechart diagram) изображает все возможные состояния, в которых может находиться конкретный объект разработанной АИС, а также изменения состояния объекта, которые происходят в результате влияния некоторых событий на этот объект.
Разработанная диаграмма описывает возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла.
Под состоянием понимается абстрактный мета класс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Для указания на условия или обстоятельства, при которых будет выполняться деятельность, определенная выражением действия, используются метки действия. Перечень меток действия имеет фиксированные значения, которые не могут быть использованы в качестве имен событий. Эти значения следующие:
entry - указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);
exit - указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);
do - специфицирует выполняющуюся деятельность ("do activity"), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия. В последнем случае при завершении события генерируется соответствующий результат;
include - используется для обращения к подавтомату (вложенному автомату, использующемуся для внутренней спецификации процедур и функций, образующих поведение исходного объекта), при этом следующее за ней выражение действия содержит имя этого подавтомата.
Во всех остальных случаях метка действия идентифицирует событие которое запускает соответствующее выражение действия. Эти события называются внутренними переходами и семантически эквивалентны переходам в само это состояние, за исключением той особенности, что выход „з этого состояния или повторный вход в него не происходит. Это означает, что действия входа и выхода не выполняются .
Диаграмма состояний для АИС управления услуг предприятия и его персонала показаны на рисунке 1.5
1.5.5 Диаграмма деятельности
Диаграмма деятельности (activity diagram) представляет собой специальный тип диаграммы состояний, описанной выше, в которой представлены состояния действия и транзакции, имеющие место по завершении операций.
Для возможности реализации особенностей процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий, разработана диаграмма деятельности, основным направлением использования которой является детализация особенности алгоритмической и логической реализации выполняемых системой операций.
Диаграмма деятельности разделяется на «дорожки» (swimlanes), в каждой из которых размещены элементы, принадлежащие одной подсистеме разработанной АИС.
На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения.
Диаграмма деятельности для АИС управления услуг предприятия и его персонала показана
на рисунке 1.6.
2 КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ
2.1 Физическая модель базы данных
Физические модели отображают всю информацию, необходимую для разработки системы для воплощения логической модели в систему базы данных. Существует два уровня физических моделей: модель трансформации и DBMS модель, является также «моделью данных проекта», описывающей отдельную часть всей структуры данных, предназначенную для обеспечения конкретного участка автоматизации.