Что такое клиентское приложение

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

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

Что нужно продумать в первую очередь

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

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

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

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

Интеграция с CRM. Нужно выгружать информацию о клиентах в CRM. Это поможет в послепродажном обслуживании, обработке жалоб. Также вы сможете контролировать работу с клиентом и сохранить его данные.

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

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

Повышение клиентского сервиса

Резюме

Возможности, которые дает клиентское приложение, высоки. Для того, чтобы пользователи вновь и вновь приходили к вам, сервис должен быть продуманным до мелочей. Только тогда оно будет полезным и удобным. Счастливый клиент платит дольше. Первая покупка это всегда аванс, вторая — подтверждение, и если клиент остался доволен, то он с вами надолго!

Источник

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

Что такое клиент? Клиентский компьютер и клиентское приложение

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику Сервера и протоколы. Также я решил, что на моем блоге просто необходима рубрика Вопрос-ответ, в которой будет два раздела: «Что такое?» и «Как сделать?». Большинство публикаций на моем блоге довольно большие и подробные, но в этих разделах я буду стараться ответить на один простой вопрос коротко, понятно и с примерами. Грубо говоря, каждая запись — это ответ на вопрос, который задает новичок в сфере web.

Что такое клиент? Клиентский компьютер и клиентское приложение

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

Общее определение термина клиент

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

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

Если говорить про информатику, то клиент – это программное средство или физическое устройство, которое посылает запросы серверу (поставщику услуг)

Клиентский компьютер

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

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

Клиентская программа/приложение

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

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

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

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

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

Источник

Архитектура клиентского приложения (механизмы структуризации)

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

Игровая компания немца разрабатывала 3 вида игр:

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

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

Поначалу над игрой работало два программиста и один 3D-моделлер. Когда я присоединился к команде, не было ни проработанного игрового дизайна (или человека за него отвечающего), ни платформы, на которой можно было бы сделать игру.

На второй день после моего устройства на работу ко мне подошел владелец компании и спросил: “Когда будет готова игра?”. К тому времени у меня был опыт работы в игровой индустрии и, согласно этому опыту, разработка такой несложной игры командой из 3-4 человек занимала около года. Так я и сказал, что потребуется где-то около года.

На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.

Для такого жесткого требования по срокам были и объективные предпосылки. У немца был заключен контракт с издательством, согласно которому он получал фиксированную сумму денег на разработку плюс процент от продаж. Но процент от продаж он получал только в том случае, если игра будет сдана в срок. А срок сдачи игры совпадал с его днем рождения.

После добавления в команду 4-го программиста, на повестке дня встал вопрос о выборе начальства. Как обычно формируют проектную команду? Согласно правильному подходу, сначала ищется руководитель, а затем уже он нанимает под себя остальных сотрудников. Здесь же было сделано все наоборот. Сначала были найдены сотрудники, а затем начальство стало смотреть, кто из них может быть руководителем. Ладно бы, если бы при выборе руководителя во главу угла поставили бы профессиональные навыки.

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

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

Руководитель: “Где игра про яблоки?”

Программист: “Еще не сделана”.

Руководитель: “Когда будет сделана?”

Программист: “Не знаю. Мне непонятно, что программировать”.

Руководитель: “Ну ты же — программист! Придумай!”

Систему разработки игр в игровой студии можно представить в виде иерархии из 4-х системных уровней.

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

Второй системный уровень — это игровой дизайн. Он не должен представлять “дизайн игры в вакууме”. Наоборот, он должен опираться на имеющиеся ресурсы.

Например, бюджет упомянутой игры для девочек был незначительным. К тому же, на разработку могла быть потрачена лишь половина суммы, т.к. вторая половина предназначалась для покупки оборудования (компьютеров, телевизоров, девкитов, тесткитов) и лицензирование программ для художников и программистов. Небольшой бюджет разработки и ограничения платформы исключали возможность использования в игре реалистичной графики и реалистичной физики. Денег не было на приобретение лицензии технологически продвинутого движка, а игровая консоль не позволяла использовать шейдеры. Приходилось использовать то, что уже есть — бесплатный 3D-движок NintendoWare компании Nintendo.

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

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

Платформа включает в себя определенные технические и управленческие инструменты. В качестве технических инструментов выступают:

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

Например, после того, как был придуман и описан гейм-дизайн каждой мини-игры и была реализована платформа, один программист мог реализовать одну мини-игру в черновом качестве за 3 рабочих дня. Еще 2 дня требовались для того, чтобы добавить в мини-игру мультиплеер и навести некоторые красивости. Таким образом, создание одной мини-игры в финальном качестве обходилось в 5 человеко-дней. Между тем, как до этого момента (при отсутствующих дизайне и технологической платформе) проходили недели, а работа — не двигалась.

История вторая

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

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

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

Тестовое задание звучало так:

Разработать текстовый онлайн-редактор наподобие того, что используется в Google Docs.

Необходимо было поддержать следующие возможности:

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

Промежуточные итоги

Подводя итоги, можно утверждать, что в обеих историях была допущена одинаковая ошибка — пропуск системного уровня [6].

В первой истории при работе над игрой для девочек были пропущены “уровень игрового дизайна” и “уровень технологической платформы”, что привело к застопориванию работы над проектом и увеличению времени разработки. Работа над проектом была разблокирована только после того, как были добавлены недостающие уровни: проработан игровой дизайн и реализована (пусть и легковесная) платформа.

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

Иерархия системных уровней

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

Выявление системных уровней — это первый шаг к разработке архитектуры. Если вы читали книгу по объектно-ориентированному анализу и проектированию, то наверняка не раз видели, как автор задается вопросом: “Как находить кандидаты в классы?”. Возможно, программируя, вы и сами задавали себе такой же вопрос.

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

Трехслойная архитектура

Фаулер [7] и руководство компании Microsoft по проектированию архитектуры приложений [5] выделяют три системных уровня (другими словами — три слоя абстракции), на которые можно разделить разрабатываемое приложение.

Примечание: Оригинальную версию диаграммы можно посмотреть на сайте Microsoft

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

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

Третий слой абстракции — это слой взаимодействия с пользователем. Данный слой включает компоненты пользовательского интерфейса.

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

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

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

Пятиуровневая архитектура

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

Ограничения

Предлагаемая архитектура имеет ряд ограничений:

Во-первых, она была опробована мной и коллегами при создании 5-ти чистых клиентских приложений. Т.е. не было серверной составляющей, не использовалась СУБД, а приложения запускались на десктопных компьютерах и мобильных устройствах.

Четыре приложения предназначены для создания и редактирования различных игровых ресурсов. Пятое приложение — это сервисная программа, предназначенная для оказания услуг.

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

Описание

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

Если разработка приложения ведется на языке программирования C++, то, как правило, в инфраструктурный уровень включают:

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

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

Модель данных объединена с источником данных, в качестве которого используются файлы в форматах XML или JSON. Для хранения данных не используется СУБД.

Модель данных представляет собой объектную модель предметной области [7, с. 140] и состоит из самосериализуемых классов, объекты которых загружают себя из файла и сохраняют себя в файл.

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

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

Согласно Фаулеру [7, с. 140] объектная модель предметной области относится к бизнес-логике. Поэтому, проводя прямое сопоставление предложенной пятиуровневой модели с классической трехслойной архитектурой [5], трудно соотнести, какому слою абстракции соответствует модель данных. Получается некоторый микс между источником данных, слоем доступа к данным и частью бизнес-логики. Он оправдан, когда нет необходимости разносить по физическим уровням (tires) хранение данных (СУБД) и их обработку (сервер приложений).

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

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

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

Подобный подход может быть применен, если приложению не нужно оперировать большим массивом данных и/или использовать СУБД. В противном случае уровень модели данных придется все-таки разделить.

Рисунок “Сравнение классической трехслойной и пятиуровневой архитектур”

Третий уровень — это уровень сервисов или служб. С моей точки зрения именно этот слой соответствует слою бизнес-логики из руководства компании Microsoft. Однако такое соответствие формально, потому что в случае программ для редактирования трудно понять, что является бизнес-логикой. Если пользователю просто нужно создать и/или отредактировать документ (например, визуальный эффект или анимационный блюпринт), то что считать бизнес-логикой? Сам процесс редактирования? В приложениях-редакторах нет финансовых проводок и нет системы управления производственным процессом. К бизнес-логике можно было бы отнести объектную модель предметной области. Но она уже располагается на уровне модели данных.

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

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

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

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

В GPS-навигаторе сервисов больше. Потому что это приложение предназначено для оказания услуг пользователям. К числу таких сервисов относятся:

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

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

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

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

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

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

Связь с шаблоном проектирования “Модель — Вид — Контроллер”

Концепция “Модель — Вид — Контроллер” была сформулирована норвежцем Трюгве Реенскаугом в 1978/79-ом годах во время его работы в лаборатории Xerox PARC [8]. Она предполагает разделение структуры приложения на три составляющих:

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

Некоторые трактовки отождествляют Контроллер с бизнес-логикой приложения [8].

Хотя концепция “Модель — Вид — Контроллер” и не имеет устоявшегося взгляда на элемент Контроллер, тем не менее, она предполагает отделение данных от их визуализации.

В этой связи, можно сказать, что и трехслойная архитектура, описанная в руководстве Microsoft [5], и пятиуровневая архитектура, излагаемая в настоящей статье, в той или иной мере отвечают концепции “Модель — Вид — Контроллер”. Критерии, использованные для разделения приложения на системные уровни, отчасти пересекаются с критериями, используемыми в “Модель — Вид — Контроллер” для выделения ее компонентов.

Организация же выделенных элементов в виде слоев однозначно задает их соподчиненность и устраняет различные вопросы на тему “Должен ли Контроллер знать о Виде?” или “Должна ли Модель обновлять Вид при своем изменении?”.

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

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

На уровне редактирования используется архитектура “Документ — Вид”, которая является подвидом шаблона проектирования “Модель — Вид — Контроллер”. Данная архитектура предполагает выделение классов Документ (отвечает за хранение и преобразование данных и, по сути дела, является оберткой над классами из модели данных) и Вид (отвечает за визуализацию данных и обработку команд от пользователя).

Использование архитектуры “Документ — Вид” позволяет специфицировать взаимодействие между моделью и представлением (видом), добавить возможность редактирования модели данных и поддержать возможность отмены операций.

Пример 1. Редактор All Sparks

Обзор

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

Главное окно редактора All Sparks

На треках размещаются компоненты. Пользователь может выбирать эти компоненты из списка Component List и перетаскивать их на треки.

В качестве компонентов выступают:

Компоненты располагаются на треках

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

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

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

Редактор свойств

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

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

Визуальный эффект в окне просмотра

Архитектура

Архитектуру редактора визуальных эффектов можно представить в виде иерархии из 5-ти системных уровней:

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

Второй системный уровень — это модель данных. Модель данных описывает структуру визуального эффекта: треки, компоненты на них, свойства компонентов.

Каждый класс модели данных имеет методы Load и Save, которые предназначены для загрузки и сохранения объекта из/в XML. Для чтения и записи XML используется LINQ to XML.

Третий системный уровень — это уровень сервисов и служб. В настоящий момент данный слой содержит только один сервис. Это — компилятор. Компилятор осуществляет преобразование эффекта в бинарный формат, который затем может быть использован движком.

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

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

Четвертым системным уровнем является уровень редактирования. Он реализует две архитектуры:

Пример 2. Редактор Genome

Обзор

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

Впервые блюпринты были реализованы в движке Unreal Engine 4 [2]. Они используются для разных целей, в том числе, для “программирования” логики игровой сцены или поведения персонажа.

В современных видеоиграх для создания качественной картинки 3D-аниматорам приходится делать очень много различных анимаций. Если речь идет о создании человекоподобного персонажа, то нужно анимировать множество движений: походку, бег, прыжок, приседание, поднимание рук (вместе и каждой руки по отдельности) и т.д.

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

Современные 3D-движки позволяют смешивать различные персонажные анимации, т.е. проигрывать их одновременно. Такое требуется для плавного перехода от одной анимации к другой или же когда одна анимация проигрывается на одной части скелета персонажа, а другая — на другой. Для того, чтобы задать логику подобного смешения и используется редактор анимационных блюпринтов. Впервые он появился в движке Unreal Engine 4. И поскольку он показался удобным нашим 3D-аниматорам, то потребовалось создать подобный редактор и у нас.

Главное окно редактора Genome

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

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

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

Машина состояний

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

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

Узлы с различными входными и выходными сокетами

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

Соединительные линии между сокетами задают потоки данных и потоки управления. Для организации потоков управления существуют специализированные сокеты, которые в анимационном графе называются animation pose, а в графе событий — exec.

Подробнее о блюпринтах, узлах и сокетах можно прочитать в Blueprints Visual Scripting из руководства Unreal Engine 4 Documentation [2]. В редакторе Genome был использован аналогичный подход.

Архитектура

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

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

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

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

Модель данных разделена на две части. Первая часть — это обобщенная модель данных для любого графа и любого блюпринта. Она представляет собой иерархический граф. Граф содержит узлы и соединительные линии. Некоторые узлы могут содержать в себе другие графы.

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

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

Уровень редактирования разделен на три части. Первая часть — это библиотека, которая содержит базовые классы для архитектуры Документ/Вид и для управления Undo/Redo. Эта библиотека используется как в редакторе анимационных блюпринтов, так и в редакторе визуальных эффектов.

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

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

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

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

Пример 3. GPS-навигатор

Обзор

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

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

К таким услугам относятся:

Архитектура

Архитектура GPS-навигатора может быть представлена уже известной нам иерархией из 5-ти системных уровней.

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

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

Уровень модели данных может быть разделен на два подуровня:

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

Изначально карты в исходном формате поступают на вход компилятора, который преобразует их в промежуточный формат. Как правило, в качестве исходного формата выступает GDF 3.0. Это текстовый файл с определенной разметкой. Нередко одна карта, представленная в GDF 3.0, “весит” более одного гигабайта. Чтобы представить дорожную сеть Великобритании, необходимо 7 таких карт. В качестве промежуточного выступает бинарный формат, который позволяет представить полную информацию в компактной форме.

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

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

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

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

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

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

Для доступа к картографическим данным используется слой доступа к данным.

Таким образом, модель данных для GPS-навигатора включает в себя:

Можно выделить такие модули:

Можно выделить 3 основных функции, которые можно делегировать уровню редактирования:

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

Итоги

Подведем итоги рассмотрения архитектур трех приложений.

Источник