Преподаватель который помогает студентам и школьникам в учёбе.

Модель клиент-сервер

Содержание:

Введение

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

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

Цель курсовой работы –

Для достижения поставленной цели необходимо решить следующие задачи:

- описать принцип технологии и модель клиент-сервер;

- рассмотреть архитектуру модели клиент-сервер;

- дать характеристику объекта исследования;

- дать оценку эффективности реализации модели клиент-сервер;

- разработать меры по оптимизации модели клиент-сервер;

- дать оценку эффективности предложенных рекомендаций.

Объект исследования – модель «клиент-сервер».

Предмет исследования – коммуникационные взаимодействия в рамках модели «клиент-сервер».

Научную базу работы составили труды таких ученых, как Басовский Л.Е., Бережецкая А.С.., Грекул В.И., Голубкова Е.П., Томпсона А.А., Мазур И.И., и других

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

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

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

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

Глава 1. Теоретические основы архитектуры информационной системы

1.1. Принцип технологии и модель клиент-сервер

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

Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).

Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. Протоколов на самом деле очень много и каждый протокол позволяет оказывать ту или иную услугу.

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

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

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

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

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

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

Изменение структуры ИС возможно только через возврат на ранние этапы. Для уменьшения возвратов используется управление структурой во время функционирования – конфигурирование ИС. Под конфигурированием информационной системы понимается процесс приведения «компонента» или «системы» в соответствие с различными требованиями, без изменения основного кода.

Для реализации конфигурирования необходимо в структуре информационной системы и/или ее отдельных элементов, реализующих функции управления функционированием. Существуют различные варианты такого управления: Конфигурирование (настройка) отдельных компонентов. Реализуется реализацией в компонентах так называемых точек изменчивости, которые определяются одним или несколькими изменяемыми параметрами, которые определяют особенности функционирования компонента. Точки изменчивости (points of variability) – части компонентов, на которых реализованы решения, вероятность внесения последующих изменений в которые высока, и которые должны легко изолироваться.

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

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

1.2. Архитектура модели клиент-сервер

Информационная система с родовой архитектурой характеризуется постоянной топологией (каркасом) и интерфейсами, через которые возможно присоединение к каркасу различных компонентов. Такая структура позволяет проводить конфигурирование системы путем замены отдельных компонентов, не затрагивая структуры ИС в целом.

Для реализации необходимы механизмы связывания, которые обеспечивают взаимодействие компонентов в системе. Механизм конфигурирования осуществляет управление путем «замены» компонентов в неизменном каркасе. Третий тип конфигурирования реализуется на основе архитектуры с высокой степенью гибкости.

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

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

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

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

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

Конфигурирование второго и третьего типа не может производиться только в одном из слоев информационной системы, а требуют, изменений в связанных уровнях. Например, изменения, вносимые в структуру данных, требуют изменения интерфейса пользователя, а также компонентов бизнес-логики для их обработки. Конфигурирование третьего типа дает наибольшие возможности по изменению информационной системы во время эксплуатации, однако требует введения специальных механизмов для реализации управления структурой ИС.

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

Методика – общие правила взаимодействия с элементами, функциями, инструментами для субъекта, выполняющего действие, обеспечивающие получение результатов определенного класса; Элементы – это объекты объединение, соединение, преобразование или обработка которых, обеспечивает получение результата;

- Функции – это операции, которые можно применять к одному или нескольким элементам, в результате выполнения функции могут появляться производные элементы;

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

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

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

На уровне бизнес-логики механизмы конфигурирования, чаще всего, реализуются путем описания компонентов с помощью специального или универсального скриптового языка,

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

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

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

Простая схема взаимодействия клиент-сервер

Рисунок 1.1 – Модель «клиент-сервер»

К одному серверу может обращаться сразу несколько клиентов (действительно, на одном сайте может находиться несколько посетителей). Также стоит заметить, что количество клиентов, которые могут одновременно взаимодействовать с сервером зависит от мощности сервера и от того, что хочет получить клиент от сервера.

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

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

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

Двухуровневая модель взаимодействия клиент-сервер

Рисунок 1.2 - Двухуровневая модель взаимодействия клиент-сервер

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер). Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами.

Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.

Многоуровневая архитектура взаимодействия клиент-сервер

Рисунок 1.3 - Многоуровневая архитектура взаимодействия клиент-сервер

Типичный пример трехуровневой модели клиент-сервер. Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных.

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

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

Глава 2. Анализ реализации модели клиент-сервер на примере ЭИС

2.1 Характеристика объекта исследования

Индивидуальный предприниматель Панферов А. Н. предлагает услуги по проведению работ по дезинсекции и дератизации. Наша компания работает с 18 марта 2007 года. Все применяемые препараты имеют сертификаты и разрешения Минздрава РФ.

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

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

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

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

Международный стандарт ISO 9001:2008 и российский национальный стандарт ГОСТ ISO 9001-2011 (ISO 9001:2008) можно считать одними из наиболее объективных доказательств стабильности и порядочности компании. При организации госзаказов и проведении тендеров наличие такого сертификата все чаще включается в список ключевых требований к претенденту. Для партнеров и инвесторов ISO 9001 также является залогом надежности и прозрачности системы менеджмента качества в компании. Как говорят аналитики, «наличие сертификата можно сравнить с «одежкой», по которой встречают», и, как правило, он иллюстрирует репутацию компании лучше, чем дорогостоящие PR-кампании.

Организационно-управленческая структура ИП Панферова А. Н. имеет следующий вид (рис. 2.1):

Рисунок 2.1- Организационно-управленческая структура ИП Панферова А. Н.

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

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

2.2. Оценка эффективности реализации модели клиент-сервер

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

Чтобы сделать работу компании более эффективной ИП Панферов А.Н. потребовалась ЭИС, при помощи которой можно было бы решать следующие задачи:

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

В настоящее время компания ставит следующие технические задачи перед ЭИС:

Обучить персонал и запустить в работу первоначальный типовой функционал ЭИС
Импорт и последующая синхронизация клиентов и договоров существующей единой учетной системы (ЕУС) и ЭИС.
Регистрация новых клиентов в ЭИС (ручная и автоматическая, загрузка из внешней системы.
Загрузка бухгалтерской документации из ЕУС (актов, счетов фактур) для передачи клиентам в удобном им месте.
Загрузка платежных документов из ЕУС (для отслеживания оплат по клиентам).
Расширение функционала по работе с картами клиентов (загрузка полной детализации по движениям по картам клиентов).
Организация учета движения карт клиентов.

В рамках обработки информации с ЭИС необходимо учитывать следующие критерии:

- своевременная и полная информация при реализации управленческих процессов;

- проектирование достоверной и понятной системы;

- сопоставимость и доступность;

-экономический эффект от внедрения ЭИС, то есть затраты на обработку заказов не должны быть выше получаемого эффекта от внедрения ЭИС;

- отсутствие информационной перегрузки;

- адаптация к информационным потребностям пользователей ЭИС.

При проектировании программного обеспечения ЭИС для работы с клиентами в ИП Панферов А.Н. были учтены все вышеперечисленные принципы. В результате внедрения ЭИС алгоритм работы менеджера изменится. Применение ЭИС в работе с клиентами дает возможность частично пересмотреть анализируемые процессы.

Далее опишем бизнес-процессы, возникающие при внедрении информационной системы. На рисунке 2.2 изобразим иерархию бизнес-процессов, учитывающих внедрение ЭИС при работе с клиентами.

Рисунок 2.2 – Дерево иерархий бизнес-процессов

На рисунке 2.3 изобразим процесс деятельности менеджера ИП Панферов А.Н.

Правила обработки заказов по ISO 9001:2008

Должностные инструкции

Указания руководства

Суммы выплат поставщикам

Данные о задолженностях клиентов

Данные о долгах поставщикам

Данные о задолженностях клиентов

Деятельность менеджера ИП Панферов А.Н.

Прайс-лист

Цены покупателей

Данные о долгах поставщикам

Персонал склада

MS Excel

ЭИС

Менеджер

Экономический отчет

Данные об остатках по складу

Суммы оплат клиентов

Данные об остатках по складу

Рисунок 2.3 – Контекстная диаграмма деятельности менеджера ИП Панферов А.Н.

На рисунке 2.4 представлена декомпозиция процесса деятельности менеджера ИП Панферов А.Н., который представляет собой разрозненные элементы в последствие замененные ЭИС.

Рисунок 2.4 – Декомпозиция процесса деятельность менеджера ИП Панферов А.Н.

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

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

Этап приема расходных материалов предполагает обзвон поставщиков (рис. 2.5). На данном этапе ЭИС выступает в качестве средства для поиска поставщиков и списка клиентов по срокам получения расходных материалов и оказания услуг. В результате обзвона и согласования цены заявки составляется список поставщиков расходных материалов, а также указанием специалиста, оказывающего услуги по обработке помещения.

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

Рисунок 2.5 – Декомпозиция этапа прием заявки

Далее по результатам прихода расходных материалов и заказа услуг на обработку помещений менеджер формирует итоговую сумму заказа и необходимое количество расходных материалов. С помощью ЭИС формируется список заказов. В результате оказания услуг и на основании расходных накладных с помощью ЭИС менеджер рассчитывает сумму оплаты заказа. В конце дня менеджер формирует таблицу «Расход», данные которой систематизируются автоматически (рис. 2.6).

Рисунок 2.6 – Декомпозиция процесса обработка заявки

На заключительном этапе менеджер формирует отчет по результатам данных в таблицах «Приход» и «Расход», данные о долгах и задолженностях, формируют отчет. Данный этап в работе ЭИС характеризуется автоматическим формированием отчета об оказании услуг по обработке помещений от вредителей, отчета о расходе материалов и экономического отчета (рис. 2.7).

Рисунок 2.7 – Декомпозиция процесса формирование отчета

Разработка и внедрение ЭИС даст возможность снизить офисных приложений, используемых менеджером, что приведет к снижению нагрузки менеджера и повышению производительности труда.

В результате реализации алгоритма действий работа менеджеров с поставщиками значительно улучшится. Использование ЭИС при работе с клиентами позволит отслеживать динамику заказов и повысить лояльность. Перенос базы данных, используемых менеджерами в базу данных ЭИС, является необходимым условием для реализации проекта.

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

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

Глава 3. Разработка рекомендаций по повышению эффективности модели клиент-сервер

3.1. Меры по оптимизации модели клиент-сервер

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

Дерево функций ЭИС представлено на рисунке 3.1.

Рисунок 3.1 – Дерево функций системы ЭИС

Модули, представленные в ЭИС, подразделяются на три категории:

- модули ввода информации;

- модули вывод информации;

- модули хранения данных.

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

Схема сценария диалога – это формализованный способ в структурной форме описания диалога пользователя с ЭИС. Необходимо сформировать все уровни, на которых пользователь принимает решение относительно следующего действия, а также обосновать решение по применению именно этой технологии.

Структура сценария диалога пользователя с ЭИС представлена на рисунке 3.2.

Рисунок 3.2 – Структура сценария диалога

Далее сформулируем описание программных модулей ЭИС.

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

На рисунке 3.3 представлено дерево программных модулей, отражающее схема пакета.

Рисунок 3.3 – Структурная схема пакета

В таблице 3.1 приведены программные модули и их описание.

Таблица 3.1 – Программные модули и их функции

Системное название	Рабочее название	Выполняемые функции
Accepting	Прием	Ввод сведений о приеме заказов
Release	Выдача	Ввод сведений о выполнении заказов
Order	Заказы	Ведение справочника заказов
Price	Цена	Ведение прайс-листов
Reports	Отчеты	Формирование отчетов

Далее опишем реализацию базы данных ЭИС.

3.2. Оценка эффективности предложенных рекомендаций

База данных разрабатываемой ЭИС имеет следующие таблицы:

1. Order – содержит данные о наименовании и количестве заказов

2. Accepting – содержит название заказчика, дату приема, сумму к оплате.

3. Release – содержит название исполнителя заказа, дату выполнения и сумму к получению.

4. Customer – содержит название заказчика, адрес, телефон, дату оказания услуги и выполнения заказа, предполагаемое количество расходных материалов, сумму к оплате.

5. Price – содержит информацию о цене заказа.

6. Executor – содержит информацию о выполнении заказа: ФИО мастера, табельном номере, телефоне, количестве израсходованного материала, оплаченную сумму, денежное вознаграждение за заказ.

7. Accepting/Order – содержит информацию о номере приема, наименовании заказа и стоимости.

8. Release/Order – содержит информацию о номере заказа, наименовании заказа и стоимости.

Далее опишем структуру таблиц разработанной базы данных с детальным описанием полей.

Структура таблицы Order представлена в таблице 3.2.

Таблица 3.2 – Структура таблицы Order

Имя поля	Тип таблицы	Описание	Ключ
ID Order	Счетчик	Код заказа	+
Name	Текстовый	Наименование заказа	-
Netto (1)	Числовой	Количество в текущей работе	-

Структура таблицы Accepting представлена в таблице 3.3.

Таблица 3.3 - Структура таблицы Accepting

Имя поля	Тип таблицы	Описание	Ключ
ID Accepting	Счетчик	Код приема	+
Data	Дата	Дата приема заказа	-
ID Customer	Счетчик	Код заказчика	+
Amount payable	Денежный	Сумма к оплате	-

Структура таблицы Release представлена в таблице 3.4.

Таблица 3.4 - Структура таблицы Release

Имя поля	Тип таблицы	Описание	Ключ
ID Release	Счетчик	Код приема	+
Data	Дата	Дата оказания услуги	-
ID Executor	Счетчик	Код получателя услуги	+
Amount repay	Денежный	Сумма полученная	-

Структура таблицы Price представлена в таблице 3.5.

Таблица 3.5 - Структура таблицы Price

Имя поля	Тип таблицы	Описание	Ключ
ID Price	Счетчик	Код цены	+
Data	Дата	Дата	-
ID Order	Счетчик	Код заказа	+

Структура таблицы Supplier представлена в таблице 3.6.

Таблица 3.6 - Структура таблицы Customer

Имя поля	Тип таблицы	Описание	Ключ
ID Supplier	Счетчик	Код заказчика	+
Name	Текстовый	Название заказчика	-
Contact	Текстовый	Контактное лицо	-
Address	Поле МЕМО	Адрес	-
Phone	Текстовый	Телефон	-
Amount Materials	Числовой	Количество материала на заказ (прогнозное)	-
Outstanding amount	Денежный	Сумма к оплате	-

Структура таблицы Shopper представлена в таблице 3.7.

Таблица 3.7 - Структура таблицы Executor

Имя поля	Тип таблицы	Описание	Ключ
ID Executor	Счетчик	Код исполнителя	+
Name	Текстовый	ФИО мастера	-
Tabel number	Текстовый	Табельный номер	-
Phone	Текстовый	Телефон	-
Amount Materials	Числовой	Количество израсходованных материалов
Remuneration	Денежный	Сумма к оплате за выполнение заказа (з/п мастера)
Amount owed	Денежный	Сумма полученная	-

Структура таблицы Accepting/Order представлена в таблице 3.8.

Таблица 3.8 - Структура таблицы Accepting/Order

Имя поля	Тип таблицы	Описание	Ключ
ID	Счетчик	Код связки	+
ID Accepting	Счетчик	Код приема	+
ID Order	Счетчик	Код заказа	+
Netto (2)	Числовой	Прогнозное количество материалов	-
Amount	Денежный	Сумма	-

Структура таблицы Release/Order представлена в таблице 3.9.

Таблица 3.9 - Структура таблицы Release/Order

Имя поля	Тип таблицы	Описание	Ключ
ID	Счетчик	Код связки	+
ID Release	Счетчик	Код выполнения	+
ID Order	Счетчик	Код заказа	+
Netto (3)	Числовой	Количество израсходованных материалов	-
Amount	Денежный	Сумма	-

Логическая модель базы данных представлена в Приложении.

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

Рисунок 3.4 – Физическая модель базы данных ЭИС

Далее опишем схему функционирования ЭИС.

Схема функционирования ЭИС отражает механизм, выполняющий операции БД в ответ на команду пользователя внутри системы.

Схема взаимосвязи программных модулей и информационных файлов представлена на рисунке 3.5.

Рисунок 3.5 – Схема функционирования ЭИС

Таким образом, разработанная модель клиент-сервер является эффективной и отражает все текущие задачи компании, что позволяет рекомендовать ее к реализации.

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

Заключение

В заключении подведем итоги проведенного исследования.

Список литературы

1. Микита Р.М., Рогозов Ю.И., Свиридов А.С., Стукотий Л.Н. Концепция построения информационной модели предприятия. Телекоммуникации. 2014. №8.

2. Хавьер Гарсия, Герман Голдшмидт, «Разработка составных бизнес-сервисов на базе сервисно-ориентированной архитектуры». 2014. – C. 45-49

3. Порождающее программирование: методы, инструменты, применение: пер. с англ. / К. Чарнецки, У. Айзенекер. СПб.: Питер, 2005. 730 c.

4. Рогозов Ю. И., Свиридов А.С., Дегтярев А.А. Построение классификации характеристик программного обеспечения с целью идентификации понятий предметной области как характеристик // Информатизация и связь. 2011. N3. С. 80 – 83.

5. Рогозов Ю.И., Свиридов А.С., Кучеров С.А., Жибулис Ю.А. Подход к реализации БД со статической структурой на основе модели данных EAV. Известия Южного федерального университета. Технические науки. 2016. Т. 103. № 2. С. 87-92.

6. Fischer, G. and E. Giaccardi. Meta Design:A framework for the future of end user development. End User Development: Empowering People to flexibly Employ Advanced Information and Communication Technology. H. Lieberman, F. Paterno and V. Wulf, Springer. 9: 427 – 457.

7. Patterns&practices, Microsoft Corporation. Three-Layered Services Application. http://msdn.microsoft.com/en-us/library/ff648105.aspx

8. Rogozov Y.I., Sviridov A.S., Kutcherov S.A., Bodrow W. Purpose-Driven Approach For Flexible Structure-Independent Database Design. В сборнике: ICSOFT 2010 – Proceedings of the 5th International Conference on Software and Data Technologies 5th International Conference on Software and Data Technologies, ICSOFT, 2016. С. 356 – 362.

9. Лядова Л.Н. Метамоделирование как основа средств оперативной разработки профессионально-ориентированных информационных систем // Математика программных систем: межвузовский сборник научных статей. Пермь: Пермский государственный национальный исследовательский университет, 2016. C. 20 – 32

10. Рогозов Ю.И. Понятие метасистемы как методологической основы создания системы. // Промышленные АСУ и контроллеры. 2015. №2. – C. 55-60

11. Magento™ creates huge success with enterprise e-commerce platform & community built on Zend Framework // http://www.docstoc.com

Приложение

Логическая база данных ЭИС