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

Взаимодействие программных систем

В этой статье я поговорю об связях между программами. Связи между программами или, выражаясь иначе, взаимодействие программ друг с другом в подавляющем большинстве случаев заключается в получении данных одной программой от другой. Например, программа электронных торгов может запрашивать у какой-то другой программы курс валют. Или текстовому редактору может передавать введенный пользователем текст операционная система, используя драйвер клавиатуры. Программы могут предоставлять набор функций для взаимодействия – API. Или даже иметь целые механизмы взаимодействия, называемые протоколами, когда используется множество последовательных вызовов функций, например, для сложного согласования каких-либо параметров. Большим шагом вперед является создание универсальных структур – XML и Json. Программы могут взаимодействовать с другими программами и «невежливым» способом — без протоколов и открытых API: парся данные страницы в случае грабберов, внедряясь в исполняемые файлы как вирусы или, наоборот, убивая их в случае антивирусов.

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

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

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

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

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

Построена на «инфрастурктуре» (например, на операционной системе или на какой-либо платформе – например, IBM Notes, или внутри социальной сети).

Часто программы позволяют расширять свою функциональность: текстовые редакторы и электронные таблицы позволяют создавать макросы, браузеры – добавлять расширения, все CMS – дополнять их сторонними компонентами и плагинами. Некоторые программы идут дальше по этому пути и по сути являются платформами для запуска других приложений: например, браузеры или ibm lotus notes.

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

При этом и операционные системы, и платформы, и даже CMS, которые ставят из-за единственного компонента, во многих случаях гораздо сложнее той программы, ради которой их используют, они могут включать множество самых различных обеспечивающих работу функций: разделять ресурсы, предоставлять механизм авторизации, упрощать обращение к базе данных. Это происходит и за счёт своей универсальности (например, операционная система Windows содержит несколько подсистем Win32, OS/2) для обеспечения работы для всех возможных программ.

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

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

Вторую мысль озвучил Питер Норвиг в докладе Everything is Miscellaneous. Она показалась мне удивительной: если Вы посмотрите на отдельно взятого шимпанзе и отдельно взятого человека, то увидите, что между ними много общего. Ну, то есть понятно, что шимпанзе немного сильнее, человек немного умнее, но в целом, их внешний вид немного похож, их физические и даже пусть с большой натяжкой интеллектуальные возможности сопоставимы. Но теперь если Вы взглянете на культуру шимпанзе и культуру человечества, то увидите колоссальную разницу. Цивилизацию людей даже нельзя сопоставить с цивилизацией шимпанзе. Почему-то это напомнило мне о том, что 0.99 и 1.01 вроде бы не сильно отличаются, но при возведении в какую-нибудь большую степень одно число будет стремиться к нулю, а другое – к бесконечности.

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

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

Взаимосвязь между прикладными и управляющими программами

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

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

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

Рис. 2.3. Взаимосвязь между прикладными и управляющими программами

Правила взаимосвязи программ

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

1. Независимость подготовки. Организация связи между программами должна допускать совершенно независимое составление программ и их компиляцию. Это особенно важно, если программы не связаны одна с другой. В мультипрограммной системе программист не может судить о том, какие программы должны выполняться совместно с другими.

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

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

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

5. Гибкое распределение емкости ЗУ и времени. Распределение емкости ОП и памяти на дисках, приписывание программам блоков ввода-вывода и управление разделением времени должны основываться на потребностях выполняемых программ.

Связь между приложениями

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

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

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

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

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

Безопасная передача данных между двумя приложениями

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

Задача

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

Вариант #1: QUERY DEEPLINK

Самый очевидный вариант — передавать токен в Query DeepLink. Выглядеть это будет примерно так:
slave://main?sessionId=686A885A4FB644053C584B9BE2A70C7D
В этом случае реципиент сможет извлечь sessionId и пользоваться им, не запрашивая у пользователя авторизацию. Со стороны разработчика выглядит, что задача выполнена, но давайте копнем немного глубже.

DeepLink Hijacking

Поскольку любое приложение может зарегистрировать схему tinkoff://, OS может открыть не то приложение. Это возможно из-за того, что нет никакой регистрации и ограничений на использование схем. Вредоносное приложение может зарегистрировать схему tinkoff:// и перехватить запрос к приложению Tinkoff и запустить себя. В этом случае sessionId попадет к злоумышленникам, и ваш аккаунт будет скомпрометирован. Кроме того, DeepLink Hijacking позволяет проводить фишинг, например, отображая поля для ввода логина и пароля.

Концептуально процесс выглядит так:

Есть 2 решения этой проблемы. Первое — AppLinks-технология больше не позволяет разработчикам настраивать схему, вместо этого используются http/https. В этом случае OS берет ссылку slave.com/profile и связывается с хостом slave.com для проверки. Второе — Intent URL — вместо вызова slave:// вызывается intent://, куда передается уникальный идентификатор приложения, которое нужно запустить. Выглядит это так:

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

Session Fixation

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

Как это выглядит в нашем случае:

3rd Party Leakage

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

Вариант #2: CONTENT PROVIDER

Как будем делать? Определим у master Content-Provider и заставим slave сходить в этот Content-Provider за токеном.

Таким образом, мы избавляемся от риска передачи не тому приложению токена в случае DeepLink Hijacking и делаем невозможным атаку Session Fixation. Но у нас появляются другие проблемы — в текущем варианте вообще любое приложение может запросить токен в любой момент времени, даже если мы не инициировали его запуск.

Protection Level

В большинстве случаев вам нужно проверить, что slave подписано тем же ключом, что и master, то есть принадлежат одному автору. Для этого случая в менеджере пакетов есть метод checkSignatures, который проверяет подписи приложений. Чтобы воспользоваться этой функцией необходимо добавить permission с protectionLevel=«signature» у Content-Provider в манифесте приложения:

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

Permission Race Condition

Есть одна очень неприятная особенность в том, что имена у permission не уникальные, чем может воспользоваться вредоносное приложение и зарегать permission с нашим именем и protectionLevel=«normal» до нас. В этом случае, при установке нашего приложения, в OS уже будет существовать permission и он не перезапишется. Следовательно, наш content-provider останется без защиты и с разрешенным доступом от любого приложения.

Different Signatures

К сожалению, далеко не всегда приложения подписаны одним ключом, например, какое-то из приложений куплено, или «так исторически сложилось», но бесшовный переход все равно нужен. В этом случае мы берем проверку подписи на себя.
Как это можно реализовать:
У Content-Provider есть метод getCallingPackage(), по которому мы можем получить packageId обратившегося за данными приложения, а по packageId можем получить список подписей и проверить их с встроенными.

Кажется, что мы сделали все идеально, но нет.

Fake id vulnerability

Проблема заключается в том, что когда Android создает chain-of-trust, процесс проверки сравнивает только subject, а не проверяет подпись в поле certificate’s signer. В результате злоумышленник может построить chain-of-trust без фактической подписи.

Из-за этой ошибки генерируется неправильная цепочка сертификатов, которая может включать в себя легитимные сертификаты, встроенные в APK, но фактически не использовавшиеся для подписи приложения. В конце оставлю ссылку на коммит, который исправляет данную уязвимость. Проблема исправлена в версии android 4.4, так что нам остается повысить API Level до 19.

Выводы

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

Взаимодействие программных систем

В этой статье я поговорю об связях между программами. Связи между программами или, выражаясь иначе, взаимодействие программ друг с другом в подавляющем большинстве случаев заключается в получении данных одной программой от другой. Например, программа электронных торгов может запрашивать у какой-то другой программы курс валют. Или текстовому редактору может передавать введенный пользователем текст операционная система, используя драйвер клавиатуры. Программы могут предоставлять набор функций для взаимодействия – API. Или даже иметь целые механизмы взаимодействия, называемые протоколами, когда используется множество последовательных вызовов функций, например, для сложного согласования каких-либо параметров. Большим шагом вперед является создание универсальных структур – XML и Json. Программы могут взаимодействовать с другими программами и «невежливым» способом — без протоколов и открытых API: парся данные страницы в случае грабберов, внедряясь в исполняемые файлы как вирусы или, наоборот, убивая их в случае антивирусов.

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

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

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

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

Часто программы позволяют расширять свою функциональность: текстовые редакторы и электронные таблицы позволяют создавать макросы, браузеры – добавлять расширения, все CMS – дополнять их сторонними компонентами и плагинами. Некоторые программы идут дальше по этому пути и по сути являются платформами для запуска других приложений: например, браузеры или ibm lotus notes.

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

При этом и операционные системы, и платформы, и даже CMS, которые ставят из-за единственного компонента, во многих случаях гораздо сложнее той программы, ради которой их используют, они могут включать множество самых различных обеспечивающих работу функций: разделять ресурсы, предоставлять механизм авторизации, упрощать обращение к базе данных. Это происходит и за счёт своей универсальности (например, операционная система Windows содержит несколько подсистем Win32, OS/2) для обеспечения работы для всех возможных программ.

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

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

Вторую мысль озвучил Питер Норвиг в докладе Everything is Miscellaneous. Она показалась мне удивительной: если Вы посмотрите на отдельно взятого шимпанзе и отдельно взятого человека, то увидите, что между ними много общего. Ну, то есть понятно, что шимпанзе немного сильнее, человек немного умнее, но в целом, их внешний вид немного похож, их физические и даже пусть с большой натяжкой интеллектуальные возможности сопоставимы. Но теперь если Вы взглянете на культуру шимпанзе и культуру человечества, то увидите колоссальную разницу. Цивилизацию людей даже нельзя сопоставить с цивилизацией шимпанзе. Почему-то это напомнило мне о том, что 0.99 и 1.01 вроде бы не сильно отличаются, но при возведении в какую-нибудь большую степень одно число будет стремиться к нулю, а другое – к бесконечности.

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

Какую связь между приложениями я должен выбрать?

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

Есть ли какой-нибудь готовый к использованию механизм для Android?

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

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

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

Есть ли какой-нибудь готовый к использованию механизм для Android?

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

Однако для более произвольных видов подписки (например, «отправьте мне все сообщения, которые имеют определенные значения в определенных JSON-закодированных объектах» ) вам придется реализовать фильтрацию самостоятельно.

Может ли ContentProvider нажимать сообщения на зарегистрированного получателя, используя запрос в качестве фильтра?

Основы сетей и протоколов интернет

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

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

Основные сетевые термины

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

• Соединение — в сетях, соединение означает возможность передавать данные между устройствами. Перед тем как начнется передача данных, должно состоятся соединение, параметры которого описаны протоколом;
• Пакет — это основной структурный блок данных в сети. Все данные передаются в виде пакетов, большие данные разделяются на небольшие пакеты, фиксированного размера. В каждом пакете есть заголовок, в котором находится информация о данных, пункте назначения, отправителе, строке жизни пакета, времени отправки и т д;
• Сетевой интерфейс — это физическое или виртуальное устройство, которое позволяет компьютеру подключиться к сети. Если у вас есть две сетевые карты на компьютере, то вы можете настроить сетевой интерфейс для каждой из них. Также сетевой интерфейс может быть виртуальным, например, локальный интерфейс lo;
• LAN — это ваша локальная сеть, к ней подключены только ваши компьютеры и больше никто не имеет к ней доступа. Это может быть ваша домашняя или офисная сеть;
• WAN — это глобальная сеть интернет, обычно этот термин применяется для обозначения всей сети интернет, также этот термин может относиться к сетевому интерфейсу;
• Протокол — набор правил и стандартов, которые определяют команды и способ коммуникации между устройствами. Существует множество протоколов и мы их рассмотрим ниже. Самые популярные из них — это TCP, UDP, IP и ICMP, также есть протоколы сети интернет более высокого уровня, например, HTTP и FTP;
• Порт — это адрес на компьютере, который связан с определенной программой. Это не сетевой интерфейс и не местоположение. С помощью портов программы могут общаться между собой;
• Брандмауэр — это программное обеспечение, которое контролирует все сетевые пакеты, проходящие через компьютер. Проходящие пакеты обрабатываются на основе правил, созданных пользователем. Также брандмауэр может закрывать определенные порты, чтобы сделать работу компьютера более безопасной;
• NAT -это служба преобразования сетевых адресов между локальной и глобальной сетью. Количество свободных сетевых адресов в сети уменьшается, поэтому необходимо найти решение, и решением стало создания локальных сетей, где несколько компьютеров могут иметь один IP адрес. Все пакеты приходят на роутер, а он уже потом с помощью NAT распределяет их между компьютерами.
• VPN — это виртуальная частная сеть, с помощью нее можно объединить несколько локальных сетей через сеть интернет. Используется в большинстве случаев для обеспечения безопасности.

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

Уровни сетей и модель OSI

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

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

Модель OSI

Так сложилось исторически, что когда дело доходит до уровней работы сетей, используется модель OSI или Open Systems Interconnect. Она выделяет семь уровней:

• Уровень приложений — самый верхний уровень, представляет работу пользователя и приложений с сетью Пользователи просто передают данные и не задумываются о том, как они будут передаваться;
• Уровень представления — данные преобразуются в более низкоуровневый формат, чтобы быть такими, какими их ожидают получить программы;
• Уровень сессии — на этом уровне обрабатываются соединения между удаленным компьютерами, которые будут передавать данные;
• Транспортный уровень — на этом уровне организовывается надежная передача данных между компьютерами, а также проверка получения обоими устройствами;
• Сетевой уровень — используется для управления маршрутизацией данных в сети пока они не достигнут целевого узла. На этом уровне пакеты могут быть разбиты на более мелкие части, которые будут собраны получателем;
• Уровень соединения — отвечает за способ установки соединения между компьютерами и поддержания его надежности с помощью существующих физических устройств и оборудования;
• Физический уровень — отвечает за обработку данных физическими устройствами, включает в себя программное обеспечение, которое управляет соединением на физическом уровне, например, Ehternet или Wifi.

Как видите, перед тем, как данные попадут к аппаратному обеспечению им нужно пройти множество слоев.

Модель протоколов TCP/IP

Модель TCP/IP, еще известная как набор основных протоколов интернета, позволяет представить себе уровни работы сети более просто. Здесь есть только четыре уровня и они повторяют уровни OSI:

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

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

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

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

• MAC или (Media Access Control) — это протокол низкого уровня, который используется для идентификации устройств в локальной сети. У каждого устройства, подключенного к сети есть уникальный MAC адрес, заданный производителем. В локальных сетях, а все данные выходят из локальной сети и попадают в локальную сеть перед тем, как попасть к получателю, используются физические MAC адреса для обозначения устройств. Это один из немногих протоколов уровня соединения, с которым довольно часто приходится сталкиваться.
• IP ( Internet Protocol) — расположен уровнем выше, за MAC. Он отвечает за определение IP адресов, которые будут уникальными для каждого устройства и позволяют компьютерам находить друг друга в сети. Он относится к сетевому уровню модели TCP/IP. Сети могут быть связанны друг с другом в сложные структуры, с помощью этого протокола компьютеры могут определить несколько возможных путей к целевому устройству, причем во время работы эти пути могут меняться. Есть несколько реализаций протокола, но наиболее популярной на сегодняшний день является IPv4 и IPv6.
• ICMP (Internet control message protocol) — используется для обмена сообщениями между устройствами. Это могут быть сообщения об ошибках или информационные сообщения, но он не предназначен для передачи данных. Такие пакеты используются в таких диагностических инструментах, как ping и traceroute. Этот протокол находится выше протокола IP;
• TCP (Transmission control protocol) — это еще один основной сетевой протокол, который находится на том же уровне, что и ICMP. Его задача — управление передачей данных. Сети ненадежны. Из-за большого количества путей пакеты могут приходить не в том порядке или даже теряться. TCP гарантирует, что пакеты будут приняты в правильном порядке, а также позволяет исправить ошибки передачи пакетов. Информация приводится к правильному порядку, а уже затем передается приложению. Перед передачей данных создается соединение с помощью так называемого алгоритма тройного рукопожатия. Он предусматривает отправку запроса и подтверждение открытия соединения двумя компьютерами. Множество приложений используют TCP, это SSH, WWW, FTP и многие другие.
• UDP (user datagram protocol) — это популярный протокол, похожий на TCP, который тоже работает на транспортном уровне. Отличие между ними в том, что здесь используется ненадежная передача данных. Данные не проверяются при получении, это может выглядеть плохой идеей, но во многих случаях этого вполне достаточно. Поскольку нужно отправлять меньше пакетов, UDP работает быстрее, чем TCP. Поскольку соединение устанавливать не нужно, то этот протокол может использоваться для отправки пакетов сразу на несколько машин или IP телефонии.
• HTTP (hypertext transfer protocol) — это протокол уровня приложения, который лежит в основе работы всех сайтов интернета. HTTP позволяет запрашивать определенные ресурсы у удаленной системы, например, веб страницы, и файлы;
• FTP (file transfer protocol) — это протокол передачи файлов. Он работает на уровне приложений и обеспечивает передачу файла от одного компьютера к другому. FTP — не безопасный, поэтому не рекомендуется его применять для личных данных;
• DNS (domain name system) — протокол того же уровня, используемый для преобразования понятных и легко читаемых адресов в сложные ip адреса, которые трудно запомнить и наоборот. Благодаря ему мы можем получить доступ к сайту по его доменному имени;
• SSH (secure shell) — протокол уровня приложений, реализованный для обеспечения удаленного управления системой по защищенному каналу. Многие дополнительные технологии используют этот протокол для своей работы.

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

Выводы

В этой статье мы рассмотрели основы сетей и протоколов, которые используются для организации их работы. Конечно, этого совсем недостаточно, чтобы понять все, но теперь у вас есть определенная база и вы знаете как различные компоненты взаимодействуют друг с другом. Это поможет вам понимать другие статьи и документацию. Если вас серьезно заинтересовали основы сети интернет, то тут не хватит нескольких статей. Вам нужна книга. Обратите внимание на Камер Д. Сети TCP/IP. Принципы, протоколы и структура. В свое время я ее прочитал и мне очень понравилось.

Name already in use

PiRIS / articles / 5_1_1_10_uml_use_case.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

0 contributors

Users who have contributed to this file

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Диаграмма прецедентов (вариантов использования или Use Case)

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

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

Актор это калька с английского Actor что расшифровывается как действующее лицо (Act — действие, суффикс -or — человек, осуществляющий действие)

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

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

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

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

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

Базовыми элементами диаграммы вариантов использования являются вариант использования и актор.

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

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

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

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

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

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

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

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

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

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

Имя актора должно быть достаточно информативным с точки зрения семантики. Для этой цели подходят наименования должностей в компании (например, Продавец, Кассир, Менеджер, Президент).

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

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

Отношения на диаграмме вариантов использования

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

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

В языке UML имеется несколько стандартных видов отношений между акторами и вариантами использования:

• ассоциации (association relationship)
• включения (include relationship)
• расширения (extend relationship)
• обобщения (generalization relationship)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разбор скринкаста семинара «Системный анализ и проектирование»

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

Работа возможна только для авторизованного пользователя.

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

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

В Visio создаёте новый документ и открываете Дополнительные фигуры -> Программы и базы данных -> Программное обеспечение -> Сценарии выполнения UML

Цвет моих диаграмм отличается от сделанных в Visio, т.к. я делаю в visual-paradigm онлайн

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

Рисуем прямоугольник подсистемы:

В нашей системе это обычный пользователь и авторизованный пользователь. Рисуем их рядом с нашей подсистемой, причём учитываем, что авторизованный пользователь наследует (обобщает) свойства обычного пользователя (может прикрепить карту) и рисуем связь «обобщение»:

Определение вариантов использования

Обратите внимание: связи между акторами и прецедентами прямые и рисуются без всяких стрелок

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

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

Но при регистрации возникают дополнительные действия (прецеденты): ввод ФИО, лицевого счёта и пароля, и не обязательный ввод данных карты.

Для обязательных прецедентов используется отношение включения, для не обязательных — расширения

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

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

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

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

Итоговый вариант диаграммы прецедентов:

Задание для самостоятельной работы:

Программа для фитнес-центра по распределению фитнес – расписания и контроля его соблюдения

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

Клиенты могут зарегистрироваться в системе, указав ФИО, телефон, пароль, дату рождения, фото профиля, пол.

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

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

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

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

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