Автоматизация деятельности предприятия по установке газового оборудования

Размещено на http://www.allbest.ru/

1. Анализ предметной области

газ потребитель энергетический

Целью программного комплекса, разработанного в рамках дипломного проекта, является автоматизация деятельности предприятия по установке газового оборудования «ДонГАЗ».

Для того чтобы внести ясность в понятия газификации, воспользуемся определениями, данными в Федеральном законе от 31.03.1999 N69 ФЗ «О ГАЗОСНАБЖЕНИИ В РОССИЙСКОЙ ФЕДЕРАЦИИ» [45].

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

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

Основами создания и развития единого рынка газа на территории Российской Федерации являются:

- формирование круга потребителей газа на основе широкого внедрения газа как энергетического и топливного ресурса в производство и быт на территориях субъектов Российской Федерации - развитие газификации;

- создание экономически взаимовыгодных отношений потребителей и поставщиков газа;

- создание условий надежного обеспечения газом потребителей различных категорий;

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

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

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

Бизнес актер (business actor) - индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес - системой, но не входят в неё, т.е. не являются частью моделируемой системы.

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

Сотрудник (business worker) - индивидуум, который действует внутри моделируемой бизнес системы, взаимодействует с другими сотрудниками и является участником бизнес - процесса моделируемой системы.

Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том, что они являются субъектами и входят в состав моделируемой системы.

Бизнес - вариант использования (business use case) - вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес - процесса.

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

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

На рисунке 1 представлена схема бизнес-процесса по формированию заказа клиента.

Рисунок 1. Бизнес-процесс «Формирование заказа клиента»

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

На рисунке 2 представлена схема бизнес-процесса расчет с клиентом.

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

Рисунок 2. Бизнес-процесс «Расчет с клиентом»

На рисунке 3 представлена схема бизнес-процесса контроль по срокам гарантии.

Рисунок 3. Бизнес-процесс «Контроль по срокам гарантии»

Целью данного бизнес-процесса является контроль по срокам гарантии установленного оборудования. Этот бизнес-процесс является неотъемлемой частью взаимодействия с клиентом.

На рисунке 4 представлена схема бизнес-процесса формирование заказа на оборудование.



Рисунок 4. Бизнес-процесс «Формирование заказа на оборудование»

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

На рисунке 5 представлена схема бизнес-процесса формирование прайса оборудования.

Рисунок 5. Бизнес-процесс «Формирование прайса оборудования»

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



Рисунок 6. Бизнес-процесс «Составление плана работ»

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

На рисунке 7 представлена схема бизнес-процесса составление индивидуального плана работ для внештатных сотрудников.

Рисунок 7. Бизнес-процесс «Составление индивидуального плана работ для внештатных сотрудников»

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

На рисунке 8 представлена схема бизнес-процесса составление акта о выполненной работе.

Рисунок 8. Бизнес-процесс «Составление акта о выполненной работе»

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

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

На рисунке 9 представлены объекты, составляющие бюджетную классификацию Российской федерации. В таблице 1 представлена расшифровка объектов представленных на рисунке 9.



Рисунок 9. Объекты и сущности предметной области

Таблица 1. Объекты и сущности предметной области

Наименование	Описание
1	2
client	клиент
equipment	оборудование
nacenka	процентная наценка на оборудование
price	прайс
postavshik	поставщик
manwork	менеджер по работе с клиентами
order_client	заказ клиента
order_postavshik	заказ на оборудование
maininstal	начальник отдела по установке оборудования
count	счет
act	акт о выполненной работе
employeelist	список внештатных сотрудников
empinstal	сотрудник отдела по установке оборудования

2. Анализ существующих решений по автоматизации предметной области

Среди существующих программных решений по автоматизации следует отметить автоматизированную информационную систему "Информационная система предприятия" Разработчик: "ИНФОРЕСУРС", на платформе "1С: Предприятие 8". Конфигурация имеет сертификат "Совместимо! Система программ 1С: Предприятие" и позволяет эффективно организовать работу с документами в электронной форме.

Основные возможности программы:

- единый архив документов и справочной информации;

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

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

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

- возможность работы с электронной почтой и хранение всей корреспонденцию.

Канцелярия:

- регистрация первичных документов и хранение их электронных копий;

- формирование реестров документов;

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

- учет важных документов по местам хранения;

- работа со списками документов - группировки документов в дела;

- автоматизация документооборота;

- все документы системы включены в систему документооборота;

- схемы обработки (маршруты движения) документов доступны для редактирования и настройки под особенности работы;

- организация очередей обработки документов.

Другие возможности:

- напоминания;

- оперативный журнал событий, заданий;

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

- аудит действий пользователя в системе;

- средства совместной работы над документами - блокировки, удостоверение содержания;

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

Технические особенности реализации: Конфигурация для своей работы требует установленную программную оболочку "1С: Предприятие 8", не защищена аппаратным ключом и поставляется с исходными текстами модулей. Фрагменты конфигурации, отвечающие за использования внешних справочников через Интернет, обмен документами, поставляются без исходных текстов и не могут быть изменены. В конфигурации предусмотрена возможность локализации и работа пользователей на нескольких языках в рамках одной информационной базы. Особенности лицензирования: Основная поставка дает право на работу с одной информационной базой (информационная база может быть распределенной) и не ограничивает пользователя рамками локальной сети. Дополнительная лицензия позволяет работать одновременно с любым количеством поставок.

3. Выбор методологии проектирования информационной системы

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

Существует две основных методологии проектирования:

- методология структурного проектирования;

- методология объектно-ориентированного проектирования.

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

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

Наиболее распространенные модели структурного подхода:

SADT - Structured Analysis and Design Techniques - описывает модели и функциональные диаграммы;

DFD - Data Flow Diagrams - диаграммы потоков данных;

ERD - Entity Relationship Diagrams - диаграммы «сущность - связь».

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм [38].

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

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

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

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

- возможность повторного использования кода;

- повышение безопасности кода за счет инкапсуляции;

- гибкость при модификации и расширении системы;

- отсутствие необходимости разработки классов с нуля, за счет наследования;

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

4. Сбор требований

Основная цель рабочего процесса определения требований состоит в том, чтобы направить процесс разработки на получение правильной системы. А правильная система - это система, которая делает то, что необходимо и ничего более. Требование - это характеристика или условие, которому должна удовлетворять система [40].

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

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

На этапе формирования и анализа требований в соответствии с технологией разработки программного обеспечения Microsoft Solution Framework (MSF):

- осуществляется сбор требований;

- составляются профили заинтересованных лиц;

- разрабатываются варианты использования.

Сбор требований осуществлялся на основе использовании метода интервьюирования.

В процессе интервьюирования заказчик выдвинул следующие требования, которым должна отвечать система:

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

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

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

- система должна иметь возможность наращивания в программной части;

- система должна позволять экспорт выходных документов



5. Спецификация требований

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

Спецификация требований - процесс документирования системы в структурированном, доступном всем и управляемом формате. Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту. SRS позволяет определить предметную область программного продукта, рассматриваемого относительно трех его основных составляющих: данных, процесса и поведения. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом, приемке проекта и связанных с проектом функциях [42, 9]. SRS имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний.

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

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

Разработанная спецификация для информационной системы представлена в приложении А.



6. Анализ и моделирование требований

Для того чтобы определить функциональные требования, предъявляемые к системе, необходимо, прежде всего, выявить лиц заинтересованных в этой системе, а затем определить тот функционал, который им требуется для осуществления своей профессиональной деятельности [2, 42].

Заинтересованные в системе пользователи, которые были выявлены в процессе исследования бизнес-процессов и предпроектного обследования предприятия, представлены на рисунке 10.

Рисунок 10. Пользователи системы

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

Дадим краткую характеристику каждому классу пользователей системы.

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

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

Сотрудник отдела по установке оборудования - занимается внештатными сотрудниками, также принимает участие в составление плана работ.

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

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

На рисунке 11 представлены варианты использования системы менеджером по работе с клиентами.

В процессе выполнения прецедента «Формирование заказа» пользователь выполняет поэтапное формирование заказа, последовательно вводя данные о клиенте.

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

В процессе выполнения прецедента «Передача заказа в отдел по установки оборудования» происходит передача заказа для дальнейшего его выполнения.

Рисунок 11. Варианты использования системы менеджером по работе с клиентами



В процессе выполнения прецедента «Внесение изменений» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент «Утверждение заказа».

В процессе выполнения прецедента «Контроль по срокам гарантии» пользователь следит за сроками гарантии на оборудование.

В процессе выполнения прецедента «Расчет с клиентом» пользователь формирует счет.

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

В процессе выполнения прецедента «Формирование заказа поставщикам» пользователь выполняет поэтапное формирование заказа поставщикам.

В процессе выполнения прецедента «Утверждение заказа поставщикам» в системе фиксируется состояние заказа, и дальнейшая его модификации.

В процессе выполнения прецедента «Внесение изменений в заказ поставщикам» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент «Утверждение заказа поставщикам».

В процессе выполнения прецедента «Составление акта о выполненной работе» пользователь составляет акт о проделанной работе.

В процессе выполнения прецедента «Составление плана работ» пользователь составляет план работ в соответствии с принятым заказом.

В процессе выполнения прецедента «Формирование прайса» пользователь формирует прайс, следит за ценами, обновляет их.



Рисунок 12. Варианты использования системы менеджером по персоналу

На рисунке 13 представлены варианты использования системы сотрудником отдела по установки оборудования.

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

В процессе выполнения прецедента «Формирование заказа поставщикам» пользователь выполняет поэтапное формирование заказа поставщикам.

В процессе выполнения прецедента «Внесение изменений в заказ поставщикам» пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент «Утверждение заказа поставщикам».

В процессе выполнения прецедента «Составление плана для сотрудников» пользователь составляет план работ в соответствии с принятым заказом для каждого внештатного сотрудника в отдельности.

В процессе выполнения прецедента «Определение коэффициента участия сотрудников» пользователь определяет степень участия сотрудника.

В процессе выполнения прецедента «Формирование списка внештатных сотрудников» пользователь формирует список сотрудников для выполнения работ.

На рисунке 14 представлены варианты использования системы администратора автоматизированной системы.

В процессе выполнения прецедента «Регистрация пользователя» администратор регистрирует в системе новую учетную запись.

В процессе выполнения прецедента «Блокирование пользователя» администратор временно блокирует учетную запись пользователя. Если пользователь в это время подключен к системе, то он уведомляется о том, что его учетная запись заблокирована, после чего происходит его отключение от системы.

Рисунок 13. Варианты использования системы сотрудником отдела по установки оборудования



Рисунок 14. Варианты использования системы специалистом администратором

В процессе выполнения прецедента «Удаление пользователя» администратор удаляет учетную запись пользователя и списка зарегистрированных в системе.

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

7. Аттестация требований

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

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

- обзор требований - процесс просмотра системной спецификации на предмет неточных описаний и ошибок;

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

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

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

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

В качестве методологии проектирования обосновано применение объектно-ориентированного подхода.

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

8. Архитектурное проектирование

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

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

Архитектуры информационной системы требуется соблюдение следующих условий:

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

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

- направленность в разработке;

- возможность к адаптации;

- необходимость гибкости.

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

Программные архитектуры, используемые в настоящее время:

- файл-серверная;

- клиент-серверная;

- многоуровневая.

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

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо хранения файлов базы данных, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к центральному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают в нем процессы обработки данных. В ответ пользователь получает уже обработанный набор данных. Между клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а только данные, которые необходимы клиенту. Запрос пользователя длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел.

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

На рисунке 15 представлена схема клиент-серверной архитектуры.



Рисунок 15. Клиент-серверная архитектура

Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название - трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. Многоуровневая архитектура приложения (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компоненты которых выполняются на разных компьютерах. Частным случаем, Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:

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

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

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

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

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

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

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

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

Диаграмма развертывания, как и диаграмма компонентов, составляется на завершающем этапе проектирования. Когда уже определена логическая структура функционирования системы [21]. Диаграммы развертывания могут применяться и на этапе анализа. Например, при анализе уже существующей системы, можно строить диаграмму развертывания. Это облегчит понимание физического устройства системы и позволит в дальнейшем ее модифицировать.

9. Проектирование пользовательского интерфейса

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

Пользовательский интерфейс клиентской части приложения выполнен в виде Windows-приложения.

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



Рисунок 17. Прототип пользовательского интерфейса

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

- главное меню приложения;

- основная часть.

Главное меню приложения служит для доступа ко всем функциям системы.

Основная часть выполнена в виде панели с закладками, открываются формы, непосредственно с которыми работает пользователь.

Размещено на Allbest.ru