Разработка информационной системы "Цветы" для компании "AMF тАУ международная сеть доставки цветов"

Дипломная работа - Компьютеры, программирование

Другие дипломы по предмету Компьютеры, программирование



управления данными

Согласно архитектуре шаблона MVC(Model/View/Controller) любое хорошее Windows-приложение должно содержать:

Модель (Основы модели: диаграммы и схемы данных);

Вид (Основы вида: формы, запросы);

Контроллер (Основы контроллера: формы, запросы, отчеты и интерфейс).

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

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

В системе обозначений UML таким описанием является представление использования (use-case-view). Это представление может состоять из нескольких диаграмм использования (use-case-diagram), которые описывают отдельные части системы и систему в целом.

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

В информационной системе Цветы выделен 1 класс пользователей (1 роль), которой соответствует 1 внешних субъект, изображённых на диаграмме (см. Рис.1).

Оператор - имеет право использовать все функции данной ИПiветы. Основные функции приведены на диаграмме использования (см. рис.1).

Рис.1 Диаграмма использования ИПiветы

Каждому аспекту использования (Принять заказ (см. рис.2), (Прайс-лист (см. рис.3), (Формирование отчетов (см. рис.4), (Работа с персоналом (см. рис.5)) можно сопоставить собственные диаграммы активности.

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

Рис.3 Диаграмма использования Прайс-лист

Рис.4 Диаграмма использования Формирование отчета

Рис.5 Диаграмма использования Работа с персоналом

Создание модели представления данных

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

Диаграмма классов представлена на рисунке 3.

Класс Акты должен содержать следующие атрибуты:

) код акта;

) код клиента;

) код специалиста;

) дата;

) время;

) итог.

Класс Клиенты должен содержать следующие атрибуты:

) код клиента;

) ФИО;

) адрес;

) телефон.

Класс Услуги должен содержать:

) код услуги;

) тип услуги;

) наименование;

) цена.

Класс Типы услуг должен содержать:

) код типа услуг;

) наименование.

Класс Специалисты должен содержать:

) код специалиста;

) ФИО.

Рис. 3 Диаграмма классов Computers Media

Создание модели представления данных

Для введения исходных данных в ИС Computers Media мы используем входной документ акт приема заказа, в котором указываются:

- данные о клиенте;

причина неисправностей;

- дата акта;

- стоимость.

Выходным документами будут:

Акт приема заказа;

Копия акта приема заказа, предназначенная для клиента.

1.3 Физическая модель данных

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

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

При проектировании таблиц вовсе не обязательно использовать Microsoft Access 2003. Сначала лучше разработать структуру на бумаге. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

)Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами.

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

)Каждая таблица должна содержать информацию только на одну тему.

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

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

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

Таблица Акт должна содержать:

) Код акта (значение счетчик);

) Код клиента (числовое значение);

) Код Мастера (числовое значение);

<