
- •Проектирование программного продукта
- •1.1 Назначение и область применения
- •В настоящий момент на рынке программного обеспечения присутствует ряд специализированных информационных систем в данной предметной области. Рассмотрим некоторые из них.
- •Программный продукт «акада вуз». Разработчик: Синергия Софт.
- •Дополнительные возможности:
- •Технические характеристики
- •Требования и временной график выполнения программного проекта
- •2 Разработка рабочего проекта
- •2.1 Разработка интерфейса программы
- •2.2 Жизненный цикл программы
- •2.3 Описание программы
- •Тестирование программы
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