Разработка подсистема автоматизации учебно-учетной деятельности в спортивной школе

Автор работы: Пользователь скрыл имя, 27 Мая 2014 в 09:42, дипломная работа

Краткое описание

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

Содержание

Введение……………………………………………………………………… 6
1. Анализ методов и средств построения систем автоматизации учебно-учетной деятельности в спортивном учреждении …………………….
8
1.1 Организационная структура спортивной школы как объекта внедрения средств информатизации ……........................................
8
1.2. Общие принципы разработки и функционирования систем автоматизации учебно-учетной деятельности …………………….
14
1.3. Сравнительный анализ инструментальных средств построения систем автоматизации учебно-учетной деятельности....................
24
1.4 Цель и задачи дипломного проектирования……………………….. 34
2. Разработка информационного обеспечения системы автоматизации учебно-учетной деятельности в спортивной школе …………………...
35
2.1 Особенности формирования информационных моделей на основе концепции баз данных………………………………………………
35
2.2. Формирование логической и концептуальной моделей структурирования данных с использованием CASE-средств .......
48
3 Разработка программного обеспечения информационной системы автоматизации учебно-учетной деятельности спортивной школе …...
63
3.1 Выбор языковых и программных средств реализации программного обеспечения …...........................................................
63
3.2 Модульная структура программного обеспечения………………… 65
3.3 Организация пользовательского интерфейса информационной системы автоматизации учебно-учетной деятельности в спортивной школе…………………………………………………...
68
4 Организационно-экономическая часть…………………………………... 75
4.1 Краткая характеристика разрабатываемого программного продукта (ПП) и этапов его разработки……………………………
75
4.2 Определение трудоемкости разработки ПП………………………... 76
4.3 Распределение трудоемкости по этапам разработки и определение состава исполнителей………………………………...
78
4.4 Расчет сметной стоимости и договорной цены разработки ПП…... 80
4.5 Анализ конкурентоспособности программного продукта………… 86
4.5.1 Анализ технической прогрессивности………………………… 88
4.5.2 Анализ изменения функциональных возможностей…………. 89
4.5.3 Анализ соответствия разрабатываемого ПП нормативам…… 89
4.5.4 Оценка годовых эксплуатационных издержек потребителя… 89
4.5.5 Анализ экономических параметров ПП………………………. 91
4.5.6 Оценка конкурентоспособности……………………………….. 93
4.6 Оценка экономической эффективности…………………………….. 93
4.7 Анализ технико-экономических показателей разработки и эксплуатации ПП…………………………………………………….
95
5. Безопасность жизнедеятельности………………………………………... 96
5.1 Организация рабочего места ………………………………………... 97
5.2 Режим освещенности рабочего места ……………………………… 98
5.3 Микроклимат помещения………………………………………….... 99
5.4 Уровень шума………………………………………………………… 100
5.5 Психофизиологические нагрузки…………………………………… 101
5.6 Обеспечение электробезопасности ………………………………… 101
5.7. Обеспечение пожаробезопасности…………………………………. 102
Заключение…………………………………………………………………... 104
Список литературы………………………………………………………….. 105
Приложение А. Фрагмент листинга программных модулей……………... 107

Прикрепленные файлы: 1 файл

Диплом Ибрагимова.doc

— 1.40 Мб (Скачать документ)

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

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

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

Работа проектировщика существенно упрощается, если есть возможность изучить структуру сложной системы с помощью схемы, а не анализировать подробные текстовые описания спецификаций требований пользователей. Для представления сущностей и связей между ними обычно используются диаграммы «сущность-связь» (ER-диаграммы). Это позволяет всегда иметь под рукой наглядный образ моделируемой части предприятия [8].

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

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

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

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

На следующем этапе локальная концептуальная модель данных проверяется с конкретной целью: выявить наличие в ней избыточных данных и устранить этот недостаток, если он будет обнаружен. На этом этапе проводится исследование «один к одному» и удаление избыточных связей.

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

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

Полученная реляционная схема проверяется с использованием правил нормализации для определения того, является ли ее структура правильной. Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, удалении и изменении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Выделяют три основных нормальных формы: 1НФ, 2НФ и 3НФ. Таблица находится в 1НФ тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. Таблица находится во 2НФ, если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3НФ, если она удовлетворяет определению 2Ф и не одно из ее не ключевых полей не зависит функционально от любого другого не ключевого поля.

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

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

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

Связь между двумя сущностями отображается с использованием механизма «первичный ключ/внешний ключ». При определении того, в каком отношении должен находиться атрибут (атрибуты) внешнего ключа, необходимо вначале выяснить, какая из сущностей, участвующих в связи, является родительской, а какая дочерней. Родительской называется сущность, которая передает копию своего первичного ключа в отношение, представляющее дочернюю сущность, для использования в качестве внешнего ключа [8].

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

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

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

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

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

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

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

Среди многообразия средств моделирования систем в методологиях структурного анализа наиболее часто и эффективно применяются следующие диаграммы:

  • ERD (Entity Relationship Diagrams) – диаграммы «сущность-связь»;
  • DFD (Data Flow Diagrams) – диаграммы потоков данных совместно со словарями данных и спецификациями процессов.

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

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

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

Для проектирования описанных выше диаграмм используются CASE – средства (Computer Aided Software Engineering).

Для проектирования ERD используют программное средство ERwin, которое представляет собой набор средств концептуального моделирования данных. ERwin реализует проектирование схемы базы данных и генерацию ее описания на языке целевой СУБД.

Для проектирования DFD используется программное средство BPwin, которое является ведущим инструментом визуального моделирования бизнес-процессов. BPwin дает возможность наглядно представить любую деятельность или структуру в виде модели.

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

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

Учебная группа – таблица, содержащая сведения о группе, обучающейся в спортивной школе (таблицу 2.1).

Тренера – преподаватели – таблица, содержащая данные о преподавателях (таблицу 2.2).

Ученики – таблица, содержащая индивидуальные данные об учащихся             (таблицу 2.3).

Информация о работе Разработка подсистема автоматизации учебно-учетной деятельности в спортивной школе