XIII Международная студенческая научная конференция Студенческий научный форум - 2021

Введение

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

Существует несколько разновидностей программной реализации чатов:

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

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

Программы-чаты для общения в локальных сетях (например, Vypress Chat, Intranet Chat, Pichat). Часто есть возможность передачи файлов.

Чаты, реализованные поверх сторонних протоколов (например, чат, использующий ICQ).

Чаты, работающие по схеме клиент-сервер, это позволяет использовать их в сетях со сложной конфигурацией, а также управлять клиентскими приложениями (например, Mychat,Jabber).

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

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

Предметом работы – программное проектирование диаграмм вариантов использования для системы обмена мгновенными сообщениями.

Цель работы – спроектировать диаграммы вариантов использования для системы обмена мгновенными сообщениями.

Из поставленной цели вытекают следующие задачи:

 подключение к удаленному компьютеру;

 управление приложениями и процессами удаленного компьютера;

 управление устройствами удаленного компьютера;

 получение полной системной информации об удаленном компьютере;

 учет сетевого трафика;

 использование учетных записей и иерархии active directory;

 обеспечение безопасности и целостности передаваемой по сети информации путем шифрования;

 визуальное управление удаленным компьютером.

Глава 1. Объектно – ориентированное программирование

Понятия объектно-ориентированного анализа и объектно-ориентированного проектирования

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

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

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

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

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

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

Объектно-ориентированный анализ главный акцент делает на создании моделей реальной действительности на основе объектно-ориентированного мировоззрения.

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

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

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

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

Выделим следующие способы проведения объектно-ориентированного анализа:

– классический подход;

– анализ поведения;

– анализ предметной области;

– анализ вариантов;

– CRC-карточки;

– неформальное описание.

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

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

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

При данном подходе кандидатами в классы и объекты могут быть выбраны:

– осязаемые предметы (автомобили, датчики);

– роли (учитель, политик);

– события (посадка на Марс, запрос);

– взаимодействие (заем, встреча).

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

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

Анализ включает следующие этапы:

– построение скелетной модели предметной области при консультациях с экспертами в этой области;

– изучение существующих в данной области систем и представление результатов в стандартном виде;

– определение сходства и различий между разных системами при участии экспертов;

– уточнение общей модели для приспособления к нуждам конкретной системы.

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

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

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

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

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

CRC-карточки – Class-Responsibilities-Collaborators (Класс-От­ветственности-Сотрудники) – это простой и эффективный способ анализа сценариев.

Сотрудник – это другой класс, который взаимодействует с данным для обеспечения некоего общего набора поведений.

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

Таблица 1. CRC-карточка для класса Stack

Разработчики по ходу анализа сценария за­водят по карточке на каждый обнаруженный класс и дописывают в нее новые пункты.

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

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

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

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

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

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

Кроме того, по ходу работы возможно следующее:

– выделить излишек ответственности в новый класс;

– перенести ответственность с одного большого класса на несколько более детальных классов;

– передать часть обязанностей другому классу.

Элементы языка UML

Язык UML состоит из трех видов элементов:

сущности;

отношения;

диаграммы.

Сущности — это некоторые абстрактные объекты. Сущности являются основными элементами UML.

Связи между сущностями выражаются отношениями.

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

Если проводить параллели с естественным языком, то сущности — это существительные, пассивная составляющая, а отношения — глаголы, активные элементы.

Типы сущностей:

структурные;

поведенческие;

группирующие;

аннотационные.

Структурные сущности соответствуют концептуальным или физическим элементам системы.

Существует семь разновидностей структурных сущностей:

1. Класс (class) — описание совокупности объектов с общими атрибутами, методами, отношениями и семантикой. Данная абстракция соответствует понятию «класс» в языках программирования. Обозначение:

В верхней части прямоугольника записывается наименование класса, в средней перечисляются атрибуты, в нижней — методы (операции). Для атрибутов могут указываться тип и видимость. Для методов могут указываться видимость и тип возвращаемого значения. Видимость и типы соответствуют общепринятым в языках C++, Java, Ada. В зависимости от назначения модели, класс может отображаться с той или иной степени детальности, например, может указываться только наименование.

2. Интерфейс (interface) — описание совокупности методов, которые определяют набор услуг, предоставляемых классом или компонентом (см. ниже). Обозначение:

Интерфейс описывает «видимое» извне поведение элемента через спецификацию операций. Интерфейс содержит только декларативную часть, реализация методов заключена в классе или компоненте, на которые он ссылается.

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

Обозначение:

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

4. Прецедент (use case) — описание последовательности выполняемых системой действий (в том числе вариантных), которые приводят к наблюдаемому результату, значимому для какого-либо пользователя системы (актера). Обозначение:

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

5. Компонент (component) — физическая заменяемая часть системы, которой соответствует некоторому набору интерфейсов и обеспечивает их реализацию. Компонент — это «обертка» для классов, компонентов, коопераций. Обозначение:

6. Узел (node) —это элемент реальной системы. Это вычислительный элемент, который обладает машинной памятью некоторого объема и, обычно, способностью обработки.

Поведенческие сущности:

1. Взаимодействие (interaction) — поведение, состоящее в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенной цели. Отдельное сообщение обозначается как

Здесь «2» — порядковый номер, «СозданиеСтроки()» — сообщение, стрелка определяет направление передачи сообщения и линия обозначает связь.

2. Автомат (state machine) — алгоритм поведения, определяющий последовательность состояний, через которые проходят объект или взаимодействие. Автомат определяется через диаграмму состояний. Отдельное состояние обозначается прямоугольником со скругленными углами:

Или:

Группирующие сущности:

Включают только одну разновидность — пакет.

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

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

Аннотационные сущности:

Также только одна разновидность — примечание(note). Используется для словесного описания чего-либо на диаграмме. Обозначается прямоугольником с загнутым правым верхним углом:

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

Основные классификаторы:

- класс;

- интерфейс;

- компонент;

- узел;

- прецедент;

- актер.

Отношения:

1. Зависимость (dependency) — семантическое отношение; показывает, что изменение спецификации независимой (или целевой) сущности влияет на зависимую, при этом обратное в общем случае неверно. Зависимость часто применяется для обозначения использования методами класса методов другого класса. Например, если в реализации класса Б используется операция А1 класса А, то зависимость Б от А обозначается следующим образом:

Зависимость показывается пунктирной стрелкой, направленной к независимой сущности (поэтому также называемой целевой).

2. Ассоциация (association) — структурное отношение, рассматривается ниже при описании диаграммы классов; обозначается линией.

3. Обобщение (generalization) — структурное отношение типа «наследование», т.е. показывает, что объект-потомок наследует структуру и поведение родителя.

4. Реализация (realization) — семантическое отношение, показывающее такую зависимость, когда один из элементов определяет запрос, а другой обеспечивает его выполнение

Диаграмма вариантов использования

Диаграмма вариантов использования (англ. use case diagram) в UML — диаграмма, отражающая отношения между акторами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.

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

Назначение

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

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

чётко отделить систему от её окружения;

определить действующих лиц (акторов), их взаимодействие с системой и ожидаемую функциональность системы;

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

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

Элементы

Для отражения модели прецедентов на диаграмме используются:

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

актор (англ. actor) — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Акторы не могут быть связаны друг с другом (за исключением отношений обобщения/наследования),

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

Отношения между прецедентами

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

обобщение прецедента — стрелка с не закрашенным треугольником (треугольник ставится у более общего прецедента),

включение прецедента — пунктирная стрелка со стереотипом «include»,

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

Правила

При работе с вариантами использования важно помнить несколько простых правил:

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

каждый прецедент имеет инициатора;

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

Выбор протокола транспортного уровня пал на протокол TCP/IP, по следующим причинам:

TCP/IP сокеты используются для реализации надежных поточных соединений между компьютерами в сети Internet.

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

Помимо этого TCP/IP сокеты позволяют реализовать подключение и к локальной машине.

Зачастую на практике для соединения по TCP/IP сокетам на компьютерах открываются определенные порты, что позволяет расширить и разграничить канал подключения компьютера.

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

Вначале каждой команды стоит знак #, после идёт сама команда, а после команды параметры присущи этой команде, в общем виде это выглядит так:

#<Команда> [<параметр1>{; <параметр1>}]

Полный список Специальных команд сервера и клиента, представлен ниже в таблице №1 и №2.

Таблица №1

Команды сервера

Команда	Интерпретация
#M<имя отправителя>; <сообщение>	Сообщение для всех подключённых клиентов.
#N<имя отправителя>	Клиент посылает своё имя (nickname)
#P<имя отправителя>; <имя получателя>; <сообщение>	Приватное сообщение
#F<имя файла>	Получение файла
#S<имя файла>	Отправка файла всем клиентам

Особенности:

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

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

Значение приватности не работает при пересылке файла.

Таблица №2

Команды клиента

Команда	Интерпретация
#F<имя файла>	Получение файла.
#K<новое имя>	Сервер прислал новый ник
#U{<имя>}	Сервер прислал список клиентов
#M<сообщение>	Общее сообщение
#P<имя отправителя>; <имя получателя>; <сообщение>	Приватное сообщение
#N	Запрос имени от сервера
#D<имя>	Отключение администратором
#A<сообщение>	Сообщение от администратора

Особенности:

Так же как и у сервера у клиента есть временная папка, которая очищается после закрытия программы.

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

Сообщение от администратора появляется не в общем чате а в всплывающем окне.

1.4 Взаимодействие клиента и сервера

Предположим что сервер запушен и нормально функционирует, рассмотрим типичные ситуации работы в сети:

1. Подключение клиента:

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

Сервер обнаружив новое соединение, отправляет на все соединения строку ‘#N’ (Запрос имени клиента).

Все подключенные клиенты в том числе и только что подключенный, получив запрос сервера отправляют на сервер строку ‘#Nимя’,где "имя" это имя клиента.

Сервер получив такую строку добавляет "имя" в список клиентов.

2. Отключение клиента:

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

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

Сервер заметив что кто то отключился, запрашивает у оставшихся подключений их имена послав строку ‘#N’ (Запрос имени клиента).

Все подключенные клиенты, получив запрос сервера отправляют на сервер строку ‘#Nимя’, где "имя" это имя клиента.

Сервер получив такую строку добавляет "имя" в список клиентов.

Если инициатива отключения исходит от администратора:

Сервер посылает строку ‘#Dимя’всем подключенным клиентам, где "имя" это имя клиента который должен отключиться.

Клиент узнав своё имя отключается от сервера

Если произошёл сбой работы сервера:

Клиент поняв что сервер не отвечает, разрывает соединение с неактивным сервером.

Если произошёл сбой работы клиента, то процедура отключения ничем не отличается от обычной.

3. Отправка общего сообщения:

Клиент посылает на сервер строку ’ #M сообщение’, где сообщение это текст который клиент хочет чтобы видели все участники чата.

Сервер получив эту строку не изменяя её, просто рассылает её всем клиентам включая отправителя.

Клиенты получив эту строку отображают ‘сообщение’ в компонент отображения.

4. Отправка приватного сообщения:

Клиент c именем ‘имя1’ посылает на сервер строку ’ #Pимя1; имя2; сообщение’, где ‘сообщение’ это текст который клиент хочет отправить клиенту с именем ‘имя2’, ‘; ’ - это разделитель.

Сервер получив эту строку не изменяя её, просто рассылает её всем клиентам включая отправителя.

Клиент получив эту строку, определив что он получатель отображают ‘сообщение’ в компонент отображения, все же остальные пропускают строку.

5. Отправка Файла:

Клиент посылает на сервер строку ‘#F имя файла’

сервер создаёт файл с именем ‘имя файла’.

Клиент посылает файл.

Клиент посылает строку ‘#S имя файла’’, что означает что клиент хочет отправить файл c именем ‘имя файла’, который уже находится на сервере всем остальным клиентам.

Сервер рассылает всем клиентам строку ‘#F имя файла’.

Клиенты создают файл.

Сервер посылает файл.

Глава 2. Построение диаграммы вариантов использования для программного продукта.

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

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

При работе с вариантами использования важно помнить несколько простых правил:

 каждый вариант использования относится как минимум к одному действующему лицу;

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

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

Итак, после автоматизации и внедрения утилиты Remote Administration Tools «настройка программного обеспечения компьютеров» включает в себя следующие прецеденты:

 подключение к управляемому компьютеру;

 получение системной информации о компьютере;

 получение информации о запущенных процессах и приложениях на администрируемом компьютере;

 перехват управления над клавиатурой и «мышью» администрируемого компьютера;

 переход в режим визуального управления;

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

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

Рисунок 1. Диаграмма вариантов использования

Построим таблицу, которая распределяет функциональные требования по субъектам и прецедентам.

В таблице 3 представлено распределение требований по субъектам и вариантам использования.

Таблица №3

Распределение требований по субъектам и вариантам использования

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

2.2 Описательная спецификация варианта использования

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

Таблица №4

Спецификация прецедента «Подключение к удаленному компьютеру»

Параметры прецедента	Описание
ВИ	Подключение к удаленному компьютеру.
ID	1
Краткое описание	Установление соединения между компьютерами администратора и пользователя.
Основное действующее лицо	Системный администратор.
Предусловия	Для установления связи между пользовательским и администраторским компьютерами необходимо, чтобы на обоих компьютерах были установлены серверные и клиентские части соответственно.
Основной поток	 прецедент начинается после установки соответствующего ПО на администраторский и пользовательский компьютеры; утилита проверяет наличие связи и устанавливает ее, в противном случае выдает сообщение о невозможности установления связи.
Альтернативные потоки	Нет.
Постусловия	Администратор получает возможность дальнейшего управления над удаленным компьютером.

Таблица №5

Спецификация прецедента «Получение системной информации об удаленном компьютере»

Параметры прецедента	Описание
ВИ	Получение системной информации об удаленном компьютере.
ID	2
Краткое описание	Запрос на получение системной информации об операционной системе, файловой системе и пр.
Параметры прецедента	Описание
Основное действующее лицо	Системный администратор.
Предусловия	Для получения системной информации о пользовательском компьютере необходимо, чтобы на обоих компьютерах были установлены серверные и клиентские части приложения.
Основной поток	 прецедент начинается после установления связи между клиентским и серверными машинами; администратор, используя функцию «получение системной информации», узнает необходимую ему информацию об управляемом компьютере.
Альтернативные потоки	Нет.
Постусловия	Нет.

Таблица №6

Спецификация прецедента «Информация о запущенных процессах и приложениях»

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

Таблица №7

Спецификация прецедента «Управление клавиатурой и «мышью» удаленного компьютера»

Параметры прецедента	Описание
ВИ	Управление клавиатурой и «мышью» удаленного компьютера.
ID	4
Краткое описание	Перехват управления над клавиатурой и «мышью» администрируемого компьютера в режиме визуального управления.
Основное действующее лицо	Системный администратор.
Предусловия	Перед получением управления над клавиатурой и «мышью» необходимо установить связь и перейти в режим визуального управления.
Основной поток	прецедент начинается после установления связи между клиентским и серверными машинами; при переходе в режим визуального управления администратор включает опцию перехвата управления над клавиатурой и «мышью»; приложение анализирует параметры визуального подключения и передает управление администратору.
Параметры прецедента	Описание
Альтернативные потоки	Нет.
Постусловия	Пользовательский компьютер работает под управлением системного администратора.

Таблица №8

Спецификация прецедента «Режим визуального управления»

Параметры прецедента	Описание
ВИ	Режим визуального управления.
ID	5
Краткое описание	Режим администрирования, при котором системный администратор получает возможность наблюдения за рабочим столом и визуального управления над удаленным компьютером.
Основное действующее лицо	Системный администратор.
Предусловия	Для перехода в режим визуального управления необходимо установить связь между клиентским и серверным компьютерами.
Параметры прецедента	Описание
Основной поток	прецедент начинается после установления связи между клиентским и серверным машинами; приложение анализирует параметры визуального подключения и передает управление администратору.
Альтернативные потоки	Нет.
Постусловия	Клиентское приложение переходит в режим наблюдения или режим визуального управления над пользовательским компьютером.

Таблица № 9

Спецификация прецедента «Запуск приложений на удаленном ПК»

Параметры прецедента	Описание
ВИ	Запуск приложений на удаленному ПК
ID	6
Краткое описание	Получение возможности удаленного запуска программ с использованием удаленной командной строки.
Основное действующее лицо	Системный администратор.
Предусловия	Для начала действия прецедента необходимо установление связи с удаленной машиной.
Основной поток	прецедент начинается после установления связи между клиентским и серверным машинами; клиентская сторона после заполнения окна и выбора опций, передает серверу переменную типа string. Сервер, прочитав поток, запускает приложение в командной строке.
Альтернативные потоки	Нет.
Постусловия	Нет.

2.3. Диаграммы последовательности

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

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

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

Главным Actor’ом является системный администратор. Администратор запускает приложение и подает запрос клиентскому приложению о подключении к серверной машине. Приложение требует ввод IP-адреса пользовательского компьютера. После ввода адреса, клиентское приложение подключается к пользовательскому компьютеру посредством функции connect(). После получения ответа от сервера о положительной наладке связи, приложение выдает сообщение об удачном подключении и ждет дальнейших действий администратора.

Далее администратор подает запрос на визуальное управление удаленным компьютером. Приложение формирует сообщение и, посредством функции ipcomand(‘GSS’), обращается к серверному приложению. Положительным ответом является сообщение ‘TRUE’ и открытие потока для передачи изображения удаленного рабочего стола. Далее клиентское приложение передает визуальное управление удаленным компьютером системному администратору.

2.4. Диаграммы деятельности

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

Деятельность начинается с запроса системного администратора на подключение к удаленной машине. Система проверяет, есть ли указанная машина в списке машин, если нет, то предлагает указать IP-адрес, после чего вызывает функцию connect (). В случае некорректности IP-адреса следует заново его указать. Если коммутация прошла успешно, то серверное приложение присылает положительный ответ. Далее клиентское приложение переходит в состояние ожидания дальнейших действий администратора. Системный администратор дает команду перехода в режим визуального управления. Клиентское приложение открывает поток и записывает в поток результат функции ipcomand(‘GSS’). Серверное приложение, находящееся в состояния чтения потока, начинает обрабатывать данные потока, после чего записывает в поток изображение удаленного рабочего стола и данные для управления удаленным компьютером. Клиентское приложение обрабатывает поток и передает управление системному администратору.

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

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

2.5. Статический вид системы

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

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

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

 спецификации исполнимого варианта программной системы;

 обеспечения многократного использования отдельных фрагментов программного кода;

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

На рисунке 4 изображена диаграмма компонентов, представляющая систему в виде отношения двух модулей - RATClient.exe и RATServer.exe посредством интерфейса, описанного на стороне сервера.

Каждый модуль включает в себя файлы с расширением *.pas, являющиеся файлами, содержащими исходный код приложения.

Рисунок 4. Диаграмма компонентов

Тестирование

Для тестирования была использована утилита VMware Workstation, создающая на локальном компьютере виртуальную машину. На виртуальной машине установлена операционная система MS Windows XP SP3.

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

Рисунок 5. Главное окно клиентского приложения

Далее необходимо добавить виртуальную машину в список администрируемых (рисунок 6).

Рисунок 6. Добавление виртуальной машины в список

Для дальнейших действий необходимо выделить этот элемент в списке нажатием левой кнопки мыши. Далее приложение находится в режиме ожидания дальнейших действий.

Для того чтобы узнать системную информацию о виртуальной машине нужно в меню Менеджер (рисунок 7) выбрать пункт Системная информация. Результат изображен на рисунке 8.

Рисунок 7. Меню Менеджер

Рисунок 8. Получение системной информации о виртуальной машине

В меню Менеджер выбираем пункт Диспетчер задач для просмотра запущенных на удаленном компьютере процессов (рисунок 9).

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

Рисунок 9. Диспетчер задач

Для запуска программы Блокнот на удаленном компьютере выберем пункт меню Менеджер-Запуск программ. В открывшемся окне в строку «выполнить» напишем “notepad” и нажмем кнопку Выполнить (рисунок 10). Результат представлен на рисунке 11.

Рисунок 10. Дистанционный запуск программ

Рисунок 11. Результат дистанционного запуска программы

Для отправки короткого сообщения в диалоговом окне Windows перейдем в меню Менеджер-Отправка сообщения.

Откроется окно, предлагающее ввести текст сообщения и выбрать вид окна. Введем сообщение «Внимание!», выберем вид окна «предупреждение» и нажмем «Отправить» (рисунок 12). Результат представлен на рисунке 13.

Рисунок 12. Отправка сообщения на удаленный рабочий стол

Рисунок 13. Сообщение от администратора

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

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

Перейдем в режим визуального управления и откроем меню свойств папки «Мои документы» (рисунок 14).

Результат изображен на рисунке 15.

Рисунок 14. Режим визуального управления

Рисунок 15. Удаленный рабочий стол

Заключение

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

В ходе разработки была поставлена задача изучениы:

Предметом работы – программное проектирование диаграмм вариантов использования для системы обмена мгновенными сообщениями.

Цель работы – спроектировать диаграммы вариантов использования для системы обмена мгновенными сообщениями.

Из поставленной цели были выполнены следующие задачи:

подключение к удаленному компьютеру;

управление приложениями и процессами удаленного компьютера;

управление устройствами удаленного компьютера;

получение полной системной информации об удаленном компьютере;

учет сетевого трафика;

использование учетных записей и иерархии active directory;

обеспечение безопасности и целостности передаваемой по сети информации путем шифрования;

визуальное управление удаленным компьютером.

Приложение построено на основе «клиент-серверной» технологии и предполагает наличие хотя бы одного клиентского и одного серверного компьютера.

Среди остальных подобных программ Remote Administration Tools выделяет простота реализации и некоммерческая направленность проекта.

Список использованной литературы

1 Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. - СПб.: Питер, 2016. - 672 с.

10. Донской М.А. Пользовательский интерфейс. - СПб.:БХВ-Петербург, 2019. - С. 25-42.

11. Хавронская А.М. Оценка технико-экономической эффективности программных средств // Методические указания по выполнению экономического раздела дипломных проектов и работ (для студентов специальности 050704). - Алматы: КазНТУ, 2020.

2 Высокопроизводительные сети. Энциклопедия пользователя: Марк А. Спортак и др. - К.: ДиаСофт, 2018. - 432 с.

3. Кульгин М. Технологии корпоративных сетей. Энциклопедия - СПб.:Питер, 2020. - 704 с.

4. Гук М. Аппаратные средства локальных сетей. Энциклопедия - СПб.:Питер, 2017. - 576 с.

5. Компьютерные сети. Учебный курс (MSCE 70-058) - М.:Русская редакция, 2018. - 552 с.

6. Дж. Д. Рули. Сети Windows NT 4.0 - К.:BHV, 2017. - 800 с.

7. Мельников Д.А. Информационные процессы в компьютерных сетях. Протоколы, интерфейсы, модели - М.: КУДИЦ-ОБРАЗ, 2019. - 256 с.

8. УильямР. Windows XP Professional. Справочник администратора. М.:Русская Редакция, 2018. - 561 с.

9. Семенов А.Б., Стрижаков С.К., Сунчелей И.Р. Телекоммуникационные технологии - М.:Компьютер-Пресс, 2017. - 608 с.

Код для цитирования: Скопировать