CC BY
11
УДК 004
Миних Е.А. студент Федоренко Н.С. студент магистратуры Хакасский государственный университет им. Н. Ф. Катанова
научный руководитель: Иванцов А.А.
Россия, г. Абакан РАЗРАБОТКА АРХИТЕКТУРЫ ПРИЛОЖЕНИЯ ДЛЯ ВЕДЕНИЯ УЧЕТА ЗАЯВОК ОБСЛУЖИВАНИЯ КОМПЬЮТЕРНОЙ ТЕХНИКИ В ЦЕНТРЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ВУЗА Аннотация: В статье рассматривается принципиальная архитектура приложения для учета заявок пользователей о ремонте компьютерной техники и установки программного обеспечения в вузе. Раскрывается функциональная модель планируемого приложения на основе диаграммы вариантов использования.
Ключевые слова: автоматизация деятельности, сервисное обслуживание, диаграмма вариантов использования
Minikh E.A. student
Katanov Khakass State University Russia, Abakan Fedorenko N.S.
Katanov Khakass State University Russia, Abakan Scientific supervisor: Ivantsov A.A.
DEVELOPMENT OF AN APPLICATION ARCHITECTURE FOR KEEPING RECORDS OF APPLICATIONS FOR SERVICING COMPUTER EQUIPMENT AT THE UNIVERSITY INFORMATION
TECHNOLOGY CENTER Abstract: The article discusses the basic architecture of the application for recording user requests for the repair of computer equipment and software installation at the university. A functional model of the planned application is disclosed based on the use case diagram.
Keywords: activity automation, service, use case diagram
Автоматизация работы по сбору заявок для технического обслуживания компьютерной техники будет в значительной степени упрощена при разработке соответствующего программного продукта клиент-серверного типа, позволяющего создавать новые заявки и обрабатывать поступающие.
Для автоматизации работы отдела технических и программных средств обучения (ОТиПСО), сотруднику необходимо приложение - программа,
которая используется для работы с информацией в базе данных, кроме того, необходимо отдельное приложение - программа для подачи заявлений от сотрудников университета. Необходима база данных для хранения всей поступающей информации, помимо этого, необходимо приложение для сотрудника института, через которое будут поступать заявки в базу данных.
Система автоматизации должна позволять нескольким сотрудникам ОТиПСО вести работу с данными, а также она должна иметь возможность отправлять несколько заявлений от разных сотрудников одновременно. Поэтому, для данной системы удобнее всего использовать двухуровневую архитектуру «клиент - сервер».
В структуру системы автоматизации обычно входят три основных элемента:
• презентационный - графический интерфейс, созданный на основе окон и элементов управления, взаимодействующий с пользователем;
• прикладная логика - это набор алгоритмов, реализующих вычисления и контролирующих поток управления в приложении, генерация деловой информации на основе получаемых данных и защита ее целостности;
• сервисы данных - управляют информацией, отвечают за ее сохранение и обеспечивают функциональность, необходимую для обработки данных.
В разрабатываемых приложениях в качестве презентационного сервиса выступает пользовательский интерфейс сотрудника ОТиПСО, а также пользовательский интерфейс сотрудника университета, которые позволяют работать с необходимой информацией.
Интерфейс приложения сотрудника университета должен быть интуитивно понятен и не требовать от пользователя понимания принципов и особенностей технической реализации системы.
В качестве хранилища данных выступает сервер баз данных, позволяющий хранить, обрабатывать и выводить необходимую информацию. Чтобы разработать любую программу, сначала необходимо подробно изучить области деятельности, в которой должно работать будущее приложение, определить основные требования со стороны заказчика, а также оценить объем работы, которую необходимо выполнить.
Для реализации модели предметной области использован язык ЦМЪ. иМЬ - это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем.
Для того, чтобы правильно спроектировать программную систему, необходимо рассматривать ее с различных точек зрения, в этом может помочь системная архитектура.
Архитектура программной системы может быть описана с помощью четырех взаимосвязанных моделей или представлений (рисунок 1).
л * Учет ремонта и установки ПО
► Ц] Функциональная модель
► ЕИ Логическая модель
► ЕЁ] Динамическая модель
► [*] Физическая модель
Рисунок 1. Моделирование системной архитектуры
Функциональная, логическая, динамическая и физическая модель -каждая из них является одной из возможных проекций организации, а также способна рассмотреть ее на определенном этапе функционирования. Для предоставления функциональной модели воспользуемся диаграммой вариантов использования (use case diagram) (Рисунок 2).
Рисунок 2. Диаграмма вариантов использования
Диаграмму вариантов использования необходимо строить во время изучения технического задания. Она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющие собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой.
Use-case диаграмма включает изображения:
• актеров - лиц (групп лиц) или системы, взаимодействующие с нашей системой;
• вариантов использования (прецеденты) - сервисы, которые система может предоставить актерам;
• комментарии;
• взаимосвязи (отношения) между различными элементами диаграммы [1,2].
В данной диаграмме отображены следующие актеры:
1. Руководитель. Данный актер имеет полный доступ ко всем вариантам использования приложения.
2. Сотрудник ЦИТ. Данный актер имеет право на изменение, добавление данных, но не имеет прав на удаление.
3. Сотрудник института. Данный актер может только оставить электронную заявку и просмотреть информацию по установленному ПО и заявкам на ремонт.
Данное приложение можно разделить на две группы по вариантам использования:
1. Установленное программное обеспечение.
2. Ремонт оборудования.
Оба варианта декомпозируются на более мелкие варианты использования:
1. Прием заявлений на ремонт оборудования и установку ПО.
2. Просмотр состояния ремонта и установленного ПО в аудиториях.
3. Хранение записей.
Язык UML располагает несколькими видами отношений между актерами и вариантами использования:
• ассоциации;
• включения;
• расширения;
• обобщения.
В данном случае используется отношение «ассоциация» между актерами и вариантами использования, включения при декомпозиции вариантов использования на более мелкие варианты.
По разработанной функциональной модели программного продукта, на основании диаграмм вариантов использования, видна принципиальная схема дальнейшей реализации программного продукта.
Использованные источники:
1. Gemino, A., Parker, D.(2009) "Use case diagrams in support of use case modeling: Deriving understanding from the picture", Journal of Database Management, 20(1), 1-24.
2. Kawabata, R., Kasah, K. (2007). "Systems Analysis for Collaborative System by Use Case Diagram", Journal of Integrated Design & Process Science, 11(1), 13-27.
