Файл: Институт информационных технологий и автоматизации.docx

3. Мобильная платформа это специальная версия «1С: Предприятия», предназначенная для работы на мобильных устройствах, которые функционируют под управлением поддерживаемых операционных систем мобильных устройств.

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



Рисунок 3.2 - Связи компонентов в клиент-серверном варианте

На рисунке 3.2 изображены виды подключения клиентских приложений в случае клиент-серверного варианта работы системы «1С:Предприятия».



Рисунок 3.3 - Связи компонентов в файловом варианте

На рисунке 3.3 изображены виды подключения клиентских приложений в случае файлового варианта работы.

Виды клиентских приложений

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

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

• 
  тонкий клиент это приложение, которое может выполнять ограниченный набор действий на клиентском компьютере. Для работы с данными необходим вызов серверной части прикладного решения. Т.е. на сервер выносится практически все действия, которые формируют существенную нагрузку на систему. При работе в тонком клиенте четко выражена разница между клиентским и серверным кодом. Разработчик должен четко понимать, где исполняется разрабатываемый код и что он может и должен делать;
  
• 
  веб-клиент это веб-приложение, работающее в веб-браузере (из списка поддерживаемых). В силу особенностей модели безопасности веб-браузеров, на прикладное решение, работающее в веб-клиенте, накладывается большее количество ограничений, нежели на прикладное решение, работающее в тонком клиенте;
  
• 
  мобильный клиент это клиентское приложение, работающее под управлением операционных систем для мобильных устройств (iOS, Android, Windows). Особенность данного вида клиентского приложения заключается в том, что кроме стандартной функциональности системы «1С: Предприятие», в нем предоставляется доступ к возможностям, специфичных для мобильных устройств: доступ к фотокамере, геопозиционированию, уведомлениям и т. д.;
  
• 
  отдельно следует выделить технологию мобильной платформы. Мобильная платформа это специальная версия «1С: Предприятия», предназначенная для исполнения мобильных приложений на мобильных устройствах, которые функционируют под управлением операционных систем iOS, Android и Windows. Мобильная платформа реализована в архитектуре тонкого клиента, работающего с файловым вариантом информационной базы, расположенной на мобильном устройстве. Комбинация мобильной платформы и конфигурации образует приложение на мобильной платформе. Для функционирования мобильного приложения не требуется наличие постоянного канала связи с каким-либо компонентом внешней сетевой инфраструктуры. В случае необходимости, можно реализовать внешнее взаимодействие с помощью различных механизмов мобильной платформы.
  

---

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

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

• 
  управляемое приложение;
  
• 
  файловый и клиент-серверный варианты доступа;
  
• 
  клиентское приложение может работать под управлением операционных систем: Windows (обычная и мобильная), Linux, macOS, iOS, Android;
  
• 
  возможен доступ с использованием веб-сервера с помощью тонкого клиента, веб-клиента и мобильного клиента;
  
• 
  возможно использование мобильного приложения;
  
• 
  обычное приложение;
  
• 
  файловый и клиент-серверный варианты доступа;
  
• 
  клиентское приложение может работать под управлением операционных систем: Windows (только обычная), Linux, macOS;
  
• 
  невозможен доступ с использованием веб-сервера;
  
• 
  невозможно использование мобильного приложения.
  

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

---

3 ПРОЕКТНАЯ ОБЛАСТЬ

3.1 Построение диаграммы вариантов использования

Для представления функций пользователя воспользуемся диаграммой вариантов использования, языка моделирования UML. Данные диаграммы используются для определения влияния пользователей на систему, обозначения ролей, определение состава пользователей и пр. [15].

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

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

Рисунок 2.1.1 – Диаграмма вариантов использования «Заказчик»

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

• 
  заказать мероприятие;
  
• 
  написать заявление в творческую группу;
  
• 
  согласовать договор;
  
• 
  принимать участие в мероприятии;
  
• 
  осуществить оплату.
  

На рисунке 2.1.2 представлена диаграмма вариантов использования для категории пользователя «Исполнитель».


Рисунок 2.1.2 – Диаграмма вариантов использования «Исполнитель»

На данном рисунке представлены следующие сценарии:

• 
  работает в ЦД «Нефтяник»;
  
• 
  выполняет мероприятие или ведет группу;
  
• 
  отображается в расписании мероприятий или групп.
  

На рисунке 2.1.3 отображена диаграмма вариантов использования для пользователя «Методист».


Рисунок 2.1.3 – Диаграмма вариантов использования «Методист»

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

• 
  ввести данные по мероприятию;
  
• 
  ввести данные по исполнителям;
  
• 
  сформировать расписание;
  
• 
  заключить договор;
  
• 
  ввести данные по группам;
  
• 
  ввести данные по педагогам;
  
• 
  сформировать предварительную смету;
  
• 
  сформировать отчет по наполненности групп;
  
• 
  сформировать отчет по мероприятиям;
  
• 
  сформировать отчет по исполнителям [14].
  

---

Директора ЦД «Нефтяник» в первую очередь интересует финансовая стабильность организации, поэтому его основные функции следующие (см. рис.4.1.4).
Рисунок 2.1.4 – Диаграмма вариантов использования «Директор центра»

Определив состав пользователей, выполним проектирование для каждой подсистемы отдельно

3.2 Проектирование подсистем

Выполним проектирование работы каждой подсистемы. На рисунке 2.2.5 представлен алгоритм работы подсистемы «Методист».

Рисунок 2.2.5 – Алгоритм работы подсистемы «Методист»
Алгоритм работы подсистемы следующий:

1. 
   Если новый клиент, тогда создание нового клиента.
   
2. 
   Данные заносятся в соответствующую таблицу – Клиенты.
   
3. 
   Иначе по введенным данным получение информации о клиенте, который находится в базе.
   
4. 
   Определить какой вид услуг ЦД «Нефтяник» его интересует – работа в группе или проведение мероприятия.
   
5. 
   Если группа – сформировать запрос на свободные места в группе, внести клиента в группу.
   
6. 
   Выписать квитанцию за пользование услуг группы (стоимость фиксированная).
   
7. 
   Если выбрано мероприятие, то клиенту предоставляется перечень услуг и их стоимость, данные выбираются из таблицы «Услуги».
   
8. 
   Формируется предварительная смета.
   
9. 
   Данные по этой операции заносится в таблицу «Смета».
   
10. 
    Для проведения анализа данные по смете и оплате квитанциями заносятся в таблицу «Поступления».
    
11. 
    Из таблицы «Группы» извлекаются данные для определения популярности групп.
    
12. 
    Если новый педагог, внести информацию о педагоге в таблицу «Педагоги».
    
13. 
    Если новый исполнитель, внести информацию по исполнителю.
    

На рисунке 4.2.6 представлен алгоритм работы подсистемы «Директор».



Рисунок 2.2.6 – Алгоритм работы подсистемы «Директор центра»

Алгоритм подсистемы следующий:

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

---

Выполним построение логики решения с системой, которая создается в результате разработки и документального сопровождения методиста ЦД «Нефтяник» г. Ноябрьск при работе с клиентом, выполнении работ, заказанных клиентом (работа с группой и проведение мероприятия) и формировании отчетности.

На рисунке 2.7 представлен логика решений при работе с клиентом, который посещает ЦД «Нефтяник».

Логика представлена тремя действующими лицами:

• 
  клиент;
  
• 
  методист;
  
• 
  система автоматизации;
  

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

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

Данная информация будет полезна при непосредственной программной реализации инструментов поддержки работы методиста ЦД «Нефтяник».



Рисунок 2.2.7 – Логика решения при работе с клиентом
На рисунке 2.2.8 представлена логика решения при выполнении работ, которые были определены при посещении клиента ЦД «Нефтяник».

В данной логике принимают участие четыре объекта:

• 
  методист;
  
• 
  группа;
  
• 
  мероприятие;
  
• 
  система автоматизации.
  

Необходимо отметить, что объекты «Группа» и «Мероприятие» созданы искусственно – фактически это функции методиста, однако для удобства наглядности и разграничения было выполнено такое разбиение.


Рисунок 4.2.8 – Логика решений при выполнении работ
На рисунке 2.2.9 представлена логика решений формирования отчетности. Данный сценарий представлен только двумя объектами – директор и система автоматизации, как было определено ранее доступно формирование следующих отчетов:

---