Разработка информационной системы для предприятия по установке газового оборудования (стр. 5 из 15)
На рисунке 2.1 представлена схема клиент-серверной архитектуры.
Рисунок 2.1 – Клиент-серверная архитектура.
Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название - трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. Многоуровневая архитектура приложения (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компоненты которых выполняются на разных компьютерах. Частным случаем, Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:
- компонент, ответственный за управление данными, выполняется на сервере баз данных;
- компонент, выполняющий обработку данных, выполняется на сервере приложений;
- компонент, реализующий интерфейс с пользователем, исполняется на рабочей станции.
В данном проекте выбрана клиент-серверная архитектура, т.к. информационная система будет использовать одну базу данных на нескольких рабочих станциях. Сеть модели “клиент-сервер” уменьшает потребность Компьютеров-клиентов в оперативной памяти, поскольку вся работа с файлами выполняется на сервере. Серверы в клиент-серверных системах способны хранить большое количество данных. Благодаря этому на компьютерах-клиентах освобождается значительный объем дискового пространства для других приложений. Наконец, управление всей системой, включая контроль за ее безопасностью, становится, намного, проще, так как все файлы и данные централизованно размещаются на сервере или на небольшом числе серверов. Упрощается также резервное копирование.
Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами.
Диаграмма компонентов системы представлена на рисунке 2.2.
Рисунок 2.2 – Диаграмма компонентов информационной системы.
Диаграмма развертывания дополняет физическое представление системы, сформированное диаграммой компонентов. В зависимости от сложности проекта диаграмма данного вида может строиться либо нет. Если приложение планируется сделать локальным, не требующим мощных серверов, то нет смысла разрабатывать диаграмму развертывания. Но если разрабатываемая система планируется распределенной, то без диаграммы развертывания не обойтись.
Диаграмма развертывания, как и диаграмма компонентов, составляется на завершающем этапе проектирования. Когда уже определена логическая структура функционирования системы [21]. Диаграммы развертывания могут применяться и на этапе анализа. Например, при анализе уже существующей системы, можно строить диаграмму развертывания. Это облегчит понимание физического устройства системы и позволит в дальнейшем ее модифицировать.
1.9 Проектирование пользовательского интерфейса
Пользовательский интерфейс представляет собой совокупность программных и аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером.
Пользовательский интерфейс клиентской части приложения выполнен в виде Windows-приложения.
Пользовательский интерфейс автоматически настраивается в соответствии с правами доступа текущего пользователя, то есть пользователю отображаются только доступные ему функции. На рисунке 2.3 представлен прототип пользовательского интерфейса.
Рисунок 2.3 – Прототип пользовательского интерфейса
Пользовательская среда информационной системы предприятия состоит из следующих частей:
- главное меню приложения;
- основная часть.
Главное меню приложения служит для доступа ко всем функциям системы.
Основная часть выполнена в виде панели с закладками, открываются формы, непосредственно с которыми работает пользователь.
Таблица 2.1. – Структура Главного меню
| № п/п | Название | Описание |
| 1 | 2 | 3 |
| 1 | Файл | |
| 1.1 | Войти в систему | Позволяет пользователю войти в систему |
| 1.2 | Выйти в системы | Позволяет пользователю выйти из системы |
| 1.3 | Выход | Выход из приложения |
| 2 | Правка | |
| 2.1 | Отменить | Позволяет отменить последнее произведенное пользователем действие |
| 2.2 | Повторить | Позволяет повторить отмененное ранее действие |
| 2.3 | Копировать | Позволяет скопировать данные в буфер обмена |
| 2.4 | Вырезать | Позволяет вырезать данные в буфер обмена |
| 2.5 | Вставить | Позволяет вырезать данные в буфер обмена |
| 3 | Заказ | |
| 3.1 | Создать заказ | Позволяет создавать новый заказ |
| 3.2 | Просмотреть активные | Позволяет просмотреть активные заказы |
| 3.3 | Просмотреть все заказы | Позволяет просмотреть все созданные заказы |
| 1 | 2 | 3 |
| 3.4 | Просмотреть прайс | Позволяет просмотреть прайс оборудования |
| 4 | План работ | |
| 4.1 | Сформировать новый | Позволяет формировать новый план работ |
| 4.2 | Просмотреть активные | Позволяет просмотреть активный план работ |
| 4.3 | Просмотреть все | Позволяет просмотреть все созданные планы на выполнение работы |
| 5 | Акт | |
| 5.1 | Создать акт | Позволяет создать новый акт |
| 5.2 | Просмотреть акты | Позволяет просмотреть все выставленные акты |
| 6 | Окно | |
| 6.1 | Упорядочить | Позволяет упорядочить открытые формы |
| 6.2 | Список открытых форм | Позволяет переключаться между открытыми формами |
| 7 | Справка | |
| 7.1 | Помощь | Открывать справку по информационной системе предприятия |
| 7.2 | О программе | Выводит информации о разработчиках и версии программы |
1.9 Проектирование базы данных
Основными целями проектирования базы данных являются:
- представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей;
- создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;
- разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы.
В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации – концептуальные требования к системе. Именно конечный пользователь в своей работе принимает решения с учетом получаемой в результате доступа к базе данных информации. От оперативности и качества этой информации будет зависеть эффективность работы организации. Данные, помещаемые в базу данных, также предоставляет конечный пользователь.
Реляционная модель данных в подавляющем большинстве случаев вполне достаточна для моделирования любых данных [17, 18, 26]. Однако проектирование базы данных в терминах схемы отношений на практике может вызвать большие затруднения, т.к. в этой модели изначально не предусмотрены механизмы описания семантики предметной области. С этим связано появление семантических моделей данных, которые позволяют описать конкретную предметную область гораздо ближе к интуитивному пониманию и, в то же время, достаточно формальным образом.
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
- обследование предметной области, изучение ее информационной структуры;
- выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами;
- моделирование и интеграция всех представлений;
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
Построение мощной и наглядной концептуальной схемы базы данных позволяет более полно оценить специфику моделируемой предметной области и избежать возможных ошибок на стадии проектирования схемы реляционной базы данных. На рисунке 2.4 пример концептуальной модели, на базе анализа сущностей
Рисунок 2.4 - Концептуальная модель данных
Спецификация таблиц базы данных представлена в приложении Б. На основе полученной концептуальной модели и данных приложения Б разработана логическая модель данных проектируемой подсистемы.
Логический уровень – это абстрактный взгляд на данные, на этом уровне данные представляются так же, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией СУБД. При проектировании базы данных было создано несколько таблиц для хранения используемой в системе информации.