Разработка информационной системы учета призывников в администрации на примере администрации (стр. 4 из 12)

¾ прикладной уровень, который реализует основную логику приложения и на котором осуществляется необходимая обработка информации;

¾ уровень управления данными, которые обеспечивает сохранение данных и доступ к ним.

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

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

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

Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название - трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. МНОГОУРОВНЕВАЯ АРХИТЕКТУРА ПРИЛОЖЕНИЯ (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компонеты которых выполняются на разных компьютерах. Частным случаем Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:

¾ компонент, ответственный за управление данными, выполняется на сервере баз данных;

¾ компонент, выполняющий обработку данных, выполняется на сервере приложений;

¾ компонент, реализующий интерфейс с пользователем, исполняется на рабочей станции [4].

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

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

Диаграмма компонентов разрабатывается для следующих целей:

¾ визуализации общей структуры исходного кода программной системы;

¾ спецификации исполнимого варианта программной системы;

¾ обеспечения многократного использования отдельных фрагментов программного кода;

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

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

Рисунок 2.2 – диаграмма компонентов информационной системы.

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

Диаграмма размещения представлена ниже на рисунке 2.3.

Рисунок 2.3 – диаграмма размещения информационной системы.

2.2 Проектирование интерфейса информационной системы

Разработка пользовательского интерфейса включает те же основные этапы, что и разработка программного обеспечения:

1. Определение типа интерфейса и общих требований к нему.

2. Определение сценариев использования.

3. Определение пользовательской модели интерфейса.

4. Программирование и тестирование программных интерфейсов.

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

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

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

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

Пользовательский интерфейс проектируемой информационной системы имеет следующую структуру: после запуска приложения открывается главная форма, которая содержит основное меню, состоящее из 3-ти пунктов меню: Файл, Данные, Помощь. Прототип пользовательского интерфейса ПРИЛОЖЕНИИ Б.

2.3 Проектирование баз данных

Основными целями проектирования базы данных являются:

¾ представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей;

¾ создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;

¾ разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы [16].

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

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

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

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

Реализация логической модели начинается с определения концептуальной модели, определяющей основные сущности, сохраняемые в виде таблиц реляционной базы данных. ПРИЛОЖЕНИЕ В.

На рисунке 2.4 пример концептуальной модели, на базе анализа сущностей

Рисунок 2.4 – Концептуальная модель данных ИС.

Доработка этой концептуальной модели с учетом атрибутов таблиц позволяет перейти непосредственно к логической модели БД.

На рисунке 2.5 пример логической модели, на базе анализа сущностей

Рисунок 2.5 – Логическая модель данных ИС.

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