Расчетно-конструкторская часть

3 Расчетно-конструкторская часть

 

В процессе разработки программного продукта важную роль играет проектирование приложения.

Разработку приложения необходимо начать с анализа предметной области и постановки задачи.

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

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

Чтобы сформулировать реальные требования к системе, необходимо как можно больше информации о предметной области.

Данная информационная система “Приемная комиссия” предназначена для приемной комиссии Челябинского монтажного колледжа, поэтому набор требований к ней я составила, исходя из требований заказчика.

  3.1 Описание исходных данных для проектирования системы

 

Рассмотрим определение требований информационной системы «Библиотеки вуза». Данная система предназначенной для абстрактного заказчика, поэтому набор требований к ней составляется, исходя из собственного представления о задаче автоматизации работы библиотеки вуза.

Сформулируем требования к нашему проекту.

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

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

3)              ИС «библиотеки вуза» должна обеспечить выполнение следующих действий:

·           Прием новых читателей;

·           Прием новый печатных изданий;

·           Учет своевременный сдачи и отслеживание задолжников;

4) ИС «Библиотеки вуза» должна поддерживать обслуживание различные категории читателей, обладающих специфическими характеристиками:

·           Студенты вуза;

·           Разовые читатели (абитуриенты, стажеры);

·           Преподаватели;

·           Другие работники вуза;

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

·           5) ИС «Библиотеки вуза» должна отслеживать читателей, нарушающих правила пользования библиотекой – задолжников.

Создание графа в соответствии с требованиями к системе

Система будет решать следующие функции:

1. Формирование каталога книг.

1.1 Ввод данных о поступившей литературе.

1.2 Просмотр отчетов по запросам.

2. Составление карточки читателя.

2.1. Запись нового читателя.

 2.1.1 Ввод книг выдаваемых читателю.

2.2. Получение отчетов карточки читателя и выданных ему книгах.

3. Ввод данных о читателях задолжниках.

3.1 Ввод данных.

3.2 Получение отчетов о текущих задолжниках.

4. Поиск книги.

4.1 Выбор критерия поиска.

4.1.1 Получение отчетов о результате поиска.

5. Выход из программы.

6. Справка.

Представление графа сценария задачи представлено на рисунке 1.

Рис.1 Граф сценария задачи «Библиотека вуза» 3.2 Разработка контекстной диаграммы

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

Контекстная диаграмма показана на рисунке 2.

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

 

3.3 Разработка программной системы

 

3.3.1 Описание системы с использованием языка моделирования UML

Приступим к созданию модели приложения «Библиотеки вуза». На основе описанных требований и ограничений выделим классы пользователей системы, определим требования к ним и дадим описание системы с точки зрения пользователя. В системе обозначений UML таким описанием является представление использования (Use-Case View). Это представление может состоять из нескольких диаграмм использования (Use-Case Diagram), которые описывают отдельные части системы и систему в целом. Сначала составим диаграмму использования, описывающую систему в целом

Описание системы с данного языка моделирования представлено на рисунках 3,4.

	Администратор

Рисунок 4 – Представление работы системы в целом

 

 

Рисунок 4 – Представление работы системы в целом

3.3.2Технология проектирования баз данных

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

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

При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее:

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

-       База данных должна обеспечивать получение требуемых данных за приемлемое время, т. е. отвечать заданным требованиям производительности.

-       База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.

-       База данных должна легко расширяться при реорганизации и расширении предметной области.

-       База данных должна легко изменяться при изменении программной и аппаратной среды.

-       Загруженные в базу данных корректные данные должны оставаться корректными.

-       Данные до включения в базу данных должны проверяться на достоверность методом верификации.

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

Этапы проектирования базы данных с учетом рассмотренных выше аспектов представлены на рисунке 5.

Рисунок 5 – Проектирование базы данных

3.3.3 Определение сущностей

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

При проектировании базы данных книжного магазина можно выделить следующие сущности:

-               ЧИТАТЕЛЬ;

-               ПЕЧАТНОЕ ИЗДАНИЕ;

-               ВЫДАЧА;

-               КАТАЛОГ;

-               ЧИТАТЕЛЬ-ЗАДОЛЖНИК;

  3.3.4 Определение взаимосвязей между сущностями и создание модели данных

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

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

Определим для вышеперечисленных сущностей взаимосвязи.

Полученная после этого информационная модель представлена на рисунке 6.

Рисунок 6 – Информационная модель на втором этапе

Все связи между объектами (рисунок 6) являются связями «один ко многим», то есть одной записи данных первого объекта (основного) соответствует несколько записей второго объекта (подчиненного).