Дипломная работа: Автоматизация "личного кабинета" консультанта по недвижимости (на примере организации Росинформ)

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
48
сервисы данных – определение структуры данных, хранение и выборка
информации, защита целостности данных.
Главная задача презентационного сервиса, или пользовательского
интерфейса, – взаимодействие с пользователем. В современных операционных
системах, поддерживающий графический интерфейс пользователя
презентационный сервис создается на основе окон и элементов управления.
Прикладная логика, или бизнес-правила, – это набор алгоритмов,
реализующих вычисления и контролирующих поток управления в приложении.
Бизнес-правила определяются конкретным видом деятельности человека, на
который рассчитано приложение. На их основе формулируются базовые
требования к приложению, ими руководствуются разработчики. На практике
бизнес-правила как раз и являются той целью, которую должно реализовать
приложение.
Сервисы данных управляют информацией, отвечают за ее сохранение и
обеспечивают функциональность, необходимую для обработки данных.
В системе автоматизации ООО Росинфом в качестве презентационного
сервиса выступает пользовательский интерфейс клиентского приложения,
который позволяет пользователю при работе с программой оперировать
понятиями предметной области.
В качестве сервиса данных выступает сервер баз данных, позволяющий
хранить, обрабатывать и выводить необходимую информацию.
Относительно сервиса прикладной логики дело обстоит несколько
иначе. Дело в том, что система автоматизации ООО Росинфом построена по
двухуровневой архитектуре клиент-сервер, но за реализацию прикладной
логики отвечает как сервер, так и клиент. На сервере баз данных при помощи
механизма хранимых процедур реализуются базовые закономерности
предметной логики, а также логика, которая с течением времени подвергается
изменениям, так как изменение кода хранимой процедуры – процесс более
простой, чем изменение кода клиентского приложения, при котором требуется
49
полная перекомпиляция приложения. Предметная логика, которая не
изменяется с течением времени, реализована в коде клиентского приложения.
Кроме того, клиентское приложение должно предоставлять
пользователю удобный графический интерфейс для работы с данными.
Интерфейс приложения не должен требовать от пользователя понимания
принципов и особенностей технической реализации системы.
Код приложения получает доступ к серверу посредством некоторого
механизма доступа к данным, при этом обязательна поддержка возможности
работы через компьютерную сеть.
Общая схема развертывания системы ООО Росинфом приведена на
(Рисунок 10).
Рисунок 10. Схема развертывания системы ООО Росинфом
50
Проектирование таблиц базы данных.
Для выполнения физического проекта будущей базы данных бала
использована реляционная модель представления данных [13], так как
подавляющее большинство современных СУБД реализовано именно на основе
этой модели.
На основании логической модели данных и выделенных сущностей
системы автоматизации «Росинфом » были выделены таблицы базы данных.
В ходе детального рассмотрения результатов анализа предметной
области было выявлено большое количество информационных полей, которые
должны храниться для каждой из сущностей при этом выделились еще
некоторые сущности.
В целях устранения избыточности хранимых данных была проведена
нормализация таблиц баз данных.
Нормализация – это процесс приведения структур данных в состояние,
обеспечивающее лучшие условия выборки, включения, изменения и удаления
данных. Это достигается разбиением одной большой таблицы на две более
мелкие таблицы. Конечной целью нормализации является получение такого
проекта базы данных, в котором каждый факт появляется лишь в одном месте,
т. е. исключена избыточность. Это делается не столько с целью экономии
памяти, сколько для исключения возможной противоречивости хранимых
данных.
В ходе проведения нормализации все таблицы базы данных были
приведены к третьей нормальной форме, так как третья нормальная форма
обеспечивает хороший баланс между пользой от устранения дублирования
данных и накладными расходами вычислительных ресурсов, затрачиваемых на
обеспечение целостности данных. Кроме того, с возрастанием уровня
нормализации таблиц возрастает сложность запросов для добавления, выборки,
изменения и удаления данных.
51
Выводы
1. В соответствии с результатами исследования предметной области
была построена диаграмма потоков данных системы автоматизации
«Росинфом», с помощью которой были выделены основные подсистемы,
потоки данных между ними, а также проанализирован характер связей между
подсистемами.
2. Выделены основные сущности системы автоматизации, определены
отношения между ними, в результате чего была построена инфологическая
модель данных, которая в дальнейшем будет использоваться при
проектировании физической модели базы данных.
3. Подробное рассмотрение процессов внутри подсистем и между
ними позволило осуществить выбор комерческой организации системы в
пользу двухуровневой архитектуры «клиент-сервер».
4. На основании рассмотрения инфологической модели данных был
определен набор таблиц базы данных. Все таблицы были приведены к третьей
нормальной форме, так как третья нормальная форма обеспечивает баланс
между пользой от устранения избыточности данных и накладными расходами,
необходимыми для поддержки целостности данных.
52
ГЛАВА 3. ПРОГРАММНАЯ МОДЕЛЬ СИСТЕМЫ
Прежде чем приступать непосредственно к реализации системы,
необходимо осуществить выбор платформы, на которой система будет
функционировать, а также выбрать средство разработки, с помощью которого
будут реализованы модули системы.
3.1. Выбор платформы для выполнения реализации системы
автоматизации «Росинфом »
Любая платформа для функционирования программного обеспечения
есть совокупность аппаратного обеспечения и операционной системы ОС,
функционирующей на средствах вычислительной техники.
Можно сказать, что выбор аппаратной платформы и ОС для реализации
системы автоматизации ООО Росинфом был предопределен поскольку бюджет
не включал покупку новых аппаратных средств и ОС.
Относительно выбора операционной системы можно сказать, что дело
здесь обстоит аналогично выбору аппаратной платформы. Принятым
стандартом де-факто на предприятии является операционные системы
семейства Microsoft Windows. Все эти ОС поддерживают общий интерфейс
прикладного программирования (API), это в частности означает, что
приложение, работающее на одной из ОС Windows будет работать на всех ОС
семейства Windows, независимо от внутренней архитектуры операционной
системы. Исключением являются лишь некоторые приложения, чье
функционирование непосредственно связано с прямым обращением к
аппаратному обеспечению, а также приложения, которые предъявляют
специальные требования к уровню надежности сервисов операционной
системы (аппаратные отладчики, диагностические средства, серверное ПО и т.
д.).
Следует отметить, что исходя из требований физической модели
системы необходимо обеспечить, чтобы клиентское приложение не
предъявляло специальных требований к ОС и было способно функционировать
на любой ОС семейства Windows.
Источник: https://baza.diplomsite.ru/previewfile/2504