Проектирование автоматизированной информационной системы "Деканат вечернего факультета", подсистемы ведения оперативных данных

Автор: Пользователь скрыл имя, 28 Апреля 2013 в 12:40, дипломная работа

Описание работы

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

Содержание

Введение 8
1 Постановка задачи 11
2 Технико-экономическое обоснование темы. 13
3 Теоретическая часть 17
3.1 Информационные системы. 17
3.2 Базы данных. 18
4 Проектная часть. 20
4.1 Логическое моделирование предмета разработки 20
4.1.1 Модель вариантов исользовния 20
4.1.2 Модель классов системы 22
4.1.3 Поведение предмета разработки 23
4.1.4 Взаимодействие объектов системы по времени 24
4.2 Разработка структуры базы данных 24
4.2.1 Инфологическое проектирование базы данных 24
4.2.2 Выбор модели данных 38
4.2.3 Даталогическое проектирование базы данных 39
4.2.4 Ограничение целостности данных 55
4.2.5 Физическая модель базы данных 57
4.3 Выбор и обоснование СУБД 64
4.4 Выбор и обоснование языка программирования 66
4.5 Разработка информационного обеспечения системы 67
4.5.1 Проектирование серверной части 67
4.5.2 Проектирование клиентской части 68
4.5.3 Проектирование пользовательского интерфейса 70
5 Разработка документации 74
5.1 Требования к оборудованию и программному обеспечению 74
5.1.1 Конфигурация оборудования серверной части 74
5.1.2 Конфигурация оборудования клиентской части 74
5.1.3 Программное обеспечение серверной части 75
5.1.4 Программное обеспечение клиентской части 75
5.2 Общие сведения о программе 75
5.3 Руководство системного администратора 76
5.3.1 Установка серверной части приложения 76
5.4 Руководство пользователя 77
6 Тестирование программного обеспечения 85
6.1 Тестирование методом «белого ящика» 86
6.2 Системное тестирование 88
6.3 Тестирование методом «черного ящика» 88
6.4 Результаты испытаний 90
7 Экономическая часть 91
7.1 Технико-экономическое обоснование проекта 91
7.2 Составление плана-графика разработки 92
7.3 Составление сметы затрат на разработку 94
7.4 Выводы по эффективности использования программы 98
8 Безопасность и экологичность проекта 101
8.1 Введение 101
8.2 Анализ вредных и опасных факторов 101
8.3 Требования к рабочей мебели для снижения психофизиологических перегрузок и эргономические параметры рабочего места оператора ПК 109
8.4 Рационализация режима труда и отдыха для снижения умственного утомления 111
8.5 Обеспечение пожарной безопасности 113
8.6 Экологичность проекта. 116
Заключение 117
Список используемой литературы 118
Приложение. Листинг наиболее значимых частей программы 120

Работа содержит 1 файл

RED_2.3.doc

— 3.10 Мб (Скачать)

Основные причины выбора среды программирования Microsoft Visual Studio следующие:

  • Эффективная совместная работа в группе
  • Быстрая разработка приложений
  • высокоуровневый доступ к Базе Данных.
  • Интегрированный отладчик.

Более подробно актуальность выбранных  средств разработки описана в  пунктах 4.3, 4.4.

Таким образом, можно утверждать, что разработка информационной системы является актуальной задачей, как с экономической, так и с технической точки зрения.

 

 

 

 

3 Теоретическая часть

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

• выполнение вычислений;

• накопление и обработка информации.

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

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

3.1 Информационные системы.

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

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

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

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

Таким образом, при разработке информационной системы приходится решать две основные задачи:

• разработка базы данных, предназначенной для хранения информации;

• разработка графического интерфейса пользователя клиентских приложений.

3.2 Базы данных.

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

В настоящее время наиболее широко распространены реляционные СУБД. Несмотря на очевидную привлекательность  и растущую популярность объектно-ориентированных СУБД (ObjectStore, Objectivity, O2, Jasmin), пока все же преобладают реляционные базы данных, которые хорошо отлажены, развиты и к тому же поддерживают стандарт SQL-92 (к таким системам относятся, например, Oracle, Informix, Sybase, DB2, MS SQL Server).

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

При разработке базы данных необходимо учитывать специфику той СУБД, для которой эта разработка проводится. Несмотря на существование стандарта ANSI SQL 92, практически все SQL-серверы используют свои реализации SQL, содержащие расширения стандарта. Тем не менее, на начальном этапе при разработке общей структуры базы данных (на уровне концептуальной модели) особенности используемой СУБД можно не учитывать.[13]

 

 

4 Проектная часть.

Проектирование системы это  один самых  важных этапов создания программного обеспечения. На нем происходит  подробная организация структуры  системы, разработка основных алгоритмов решения задачи и их программная реализация.

4.1 Логическое моделирование предмета разработки

Разработка масштабных проектов вызывает необходимость в грамотной постановке процесса моделирования с использованием дополнительных средств. Моделирование бизнес-процессов и ифнормационного обеспечения можно начать с постоения диаграмм в нотации язка UML.

4.1.1 Модель вариантов исользовния

Диаграмма вариантов использования (прецедентов) является исходным концептуальным представлением системы в процессе ее проектирования и разработки. Диаграмма состоит из актеров, вариантов использования и отношений между ними. Каждый вариант использования определяет некоторый набор действий, совершаемых системой при взаимодействии с актером. При этом в модели никак не отражается то, каким образом будет реализован этот набор действий.[15]

Действующие лица:

  • администратор – осуществляет управление пользователями, редактирование служебной информации (справочников);
  • пользователь – ведет учет оперативных данных приказах,  перемещениях студентов, успеваемости. Просмотр различной информации.

Основные варианты использования:

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

Диаграмма вариантов использования:

Рисунок 4.1. Диаграмма вариантов использования

4.1.2 Модель классов системы

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

Основные классы системы:

  • Приказ (ID: Номер Приказа, Дата Приказа, Тип Приказа);
  • Студент (ID: Код, ФИО, Пол, Дата Рождения, Адрес) – суперкласс
    • Учащиеся
    • Выпускники
    • Отчисленные;
  • Группа (ID: Код, Номер, Дата Создания);
  • Ведомость (ID: Номер, Дата, Группа, Преподаватель, Дисциплина).

Диаграмма классов:

 

Рисунок 4.2. Диаграмма классов

4.1.3 Поведение предмета разработки

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

Рассмотрим алгоритм работы системы  при вводе данных пользователем (Рис 4.1.3).

Рисунок 4.3. Диагрмма активностей

4.1.4 Взаимодействие объектов системы по времени

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

Построим диаграмму для отображения взаимодействия основных объектов разрабатываемой системы (рис. 4.1.4).

Рисунок 4.4. Диаграмма последовательностей

4.2 Разработка структуры базы данных

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

4.2.1 Инфологическое проектирование базы данных

Первым и наиболее важным этапом проектирования БД является разработка ER-диаграммы.[20]

Выделим и опишем сущности, необходимые для обеспечения информационных потребностей пользователя:

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

Рассмотрим, как связаны все сущности между собой.

При связи сущностей “Студент” и “Приказ” у обеих сущностей степень связи N, так как приказ может содержать N студентов, сутдент может содержаться в N приказов. Класс принадлежности обеих сцщностей необязательный, так как приказ при формировании может не содержать студентов, а студент может не числиться ни в одном из приказов (например, абитуриент).

 

Рисунок 4.5

При связи “Приказ” и “Тип приказа” сущность “Приказ” имеет степень связи N, а сущность “Тип приказа” - 1, так как приказ может иметь только 1 тип, но тип приказа относится к нескольким приказам. Класс принадлежности сущности “Приказ” необязательный, а сущности “Тип приказа” - обязательный, так как приказ должен иметь какой-либо тип, , а тип приказа необязательно относится к какому-либо документу.

 

Рисунок 4.6

При связи “Приказ” и “Основание приказа” сущность “Приказ” имеет степень связи N, а сущность “Основание приказа” - 1, так как приказ может иметь только 1 основане, но основание приказа относится к нескольким приказам. Класс принадлежности сущности “Приказ” необязательный, а сущности “Основание приказа” - обязательный, так как приказ должен иметь какой-либо тип, а тип приказа необязательно относится к документу.

Рисунок 4.7

При связи “Приказ” и “Форма обучения” сущность “Приказ” имеет степень связи N, а сущность “Форма обучения” - 1, так как приказ может включать только 1 форму обучения, но форма обучения может быть указана во многих приказах. Класс принадлежности сущности “Приказ” необязательный, а сущности “Форма обучения” - обязательный, так как приказ должен включать форму обучения, а конкретная форма обучения необязательно должна быть указана в приказах.

Рисунок 4.8

При связи “Приказ” и “Основа обучения” сущность “Приказ” имеет степень связи N, а сущность “Основа обучения” - 1, так как приказ может включать только 1 основу обучения, но основа обучения может быть указана во многих приказах. Класс принадлежности сущности “Приказ” необязательный, а сущности “Основа обучения” - обязательный, так как приказ должен включать основу обучения, а конкретная основа обучения необязательно должна быть указана в приказах.

Рисунок 4.9

При связи “Приказ” и “Группа” сущность “Приказ” имеет степень связи N, а сущность “Группа” - 1, так как в приказе может быть указана 1 группа, но группа может быть указана во многих приказах. Класс принадлежности сущности “Приказ” необязательный, а сущности “Группа” - обязательный, так как приказ должен указывать группу, а конкретная группа необязательно должна быть указана в приказах.

Информация о работе Проектирование автоматизированной информационной системы "Деканат вечернего факультета", подсистемы ведения оперативных данных