2.2 Жизненный цикл программы

2.2.1 Моделирование потоков данных.

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

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

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

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

Автоматизированная информационная система – это основной объект в нашей системе. Главный участник – это преподаватель. Поэтому потоки данных только внутри этих двух объектов (рисунок 6).

Рисунок 6 – Контекстная диаграмма

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

Рисунок 7 – Начальный уровень

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

Рисунок 8 – Декомпозиция процесса «Учета видов деятельности»

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

Рисунок 9 – Декомпозиция процесса «Планирование деятельности»

2.2.2 Моделирование данных и разработка базы данных.

Моделирование данных будет разрабатываться программой ERwin которая имеет два уровня представления модели – логический и физический.

Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например, «Фамилия сотрудника», «Отдел». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

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

При создании ER-модели были выделены следующие сущности (рисунок 10).

Рисунок 10 – Схема отношений между сущностями

Разработанная таким образом модель была использована для генерации базы данных в среде MS Access на рисунке 11.

Рисунок 11 – Модель схемы данных в MS Access