Business Process Notation как подход к организации кода в проекте по разработке мобильного iOS приложения

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

Постановка проблемы

На сегодняшний день наиболее известны такие архитектурные паттерны как MVC, MVVM, MVP, Viper, Clean Code.

Все они в той или иной мере работают с тремя основными сущностями — Модель, Вью, Контроллер, добавляя время от времени некоторые дополнительные, например, Presenter.

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

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

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

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

Именно в такие моменты приходится переосмысливать общую архитектуру проекта и отвечать на вопросы “Зачем нужен тот или иной код, какую задачу он решает?”, “Где расположен код, реализующий ту или иную функциональность и как он работает?”. И т.д.

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

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

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

При этом, задача понимается как бизнес-процесс.

Что такое бизнес-процесс

Термин “бизнес-процесс” пришёл из концепции реинжиниринга бизнес процессов. Наиболее известная и основополагающая книга по этой теме — Michael Hammer, James Champy. «Reengineering the Corporation: A Manifesto for Business Revolution».

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

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

Существует несколько, достаточно разных, определений бизнес-процесса.

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

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

Бизнес-процесс всегда решает определённую задачу, у него есть цель и результат.

Бизнес-процессы могут взаимодействовать между собой.

Результат одного бизнес-процесса может быть использован другими бизнес-процессами.

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

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

Пример бизнес-процессов

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

Таким образом, мы имеем бизнес-процесс “Показать элементы”.

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

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

Все эти действия есть бизнес-процессы разных уровней декомпозиции.

Уровни бизнес-процессов

Полезно различать бизнес-процессы по трём уровням:

1-й уровень: Пользовательский

Это задачи, которые задаёт пользователь.

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

2-й уровень. Пользовательско-технический

Это первичное описание программы для решения пользовательских задач.

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

3-й уровень. Технический

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

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

Различение этих уровней помогает выделить те или иные бизнес-процессы по ходу разработки программы.

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

Обозначение (называние) бизнес-процессов

Задачи, которые решают те или иные бизнес-процессы, указываются в названиях папок в навигаторе проекта.

Идеальный вариант, когда в названии бизнес-процесса используются 2 слова: действие и объект, на который оно направлено. Например, Display Foods.

Но в ряде случаев может использоваться и большее количество слов. Например, Display Editing Meal.

Названия файлов

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

Один файл — одна задача

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

Для этого активно используются расширения.

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

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

Многозадачные файлы

В силу особенностей языка Swift и Xcode соблюдение данного правила — один файл одна задача — не всегда возможно.

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

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

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

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

Пример реализации подхода Бизнес-процесс нотация

Рассмотрим образец реализации Бизнес-процесс нотации на примере приложения, которое отслеживает количество калорий.

Бизнес-процессы верхнего уровня

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

Этот бизнес-процесс включает в себя бизнес-процессы второго уровня, которые показаны на Рис. 1

Здесь соблюдается алгоритм, показанный выше. А именно, что обозначение бизнес-процесса производится в названии папки.

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

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

Базовые бизнес-процессы приложения

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

Рассмотрим внутреннюю архитектуру первого из них.

Бизнес-процесс Manage Foods: Папки и дочерние бизнес-процессы

Как видим, бизнес-процесс Manage Foods включает в себя 6 дочерних бизнес-процессов.

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

• Model Food — моделировать продукт, создать модель объекта Food.

• Test Foods — тестировать продукты, т.е., в данном случае создать демо-данные для проверки. Разработчик решил их использовать для тестирования, а также оставить их как подсказку пользователям на первых этапах освоения приложения.

• Load Foods — загрузить данные о продуктах в приложение.

• Storage Foods — сохранить данные о продуктах в оперативной памяти приложения.

• Show Foods in the Table — показать данные о продуктах на экране.

• Edit Foods — редактировать данные о продуктах.

Бизнес-процесс Manage Foods: Файлы и объекты

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

1. Model Food

Первая папка Model Food обозначает код, который решает задачу создать модель объекта Food. И эта папка содержит один файл, который называется Food_Class_Global.swift.

Где:

• Food — это название объекта.

• Class — это тип объекта.

• Global — это локация объекта. В данном случае Global означает, что этот объект находится в глобальной зоне видимости.

2. Test Foods

Следующая папка — Test Foods — включает в себя код, который решает задачу проверки пригодности формата данных о продуктах для использования их в программе. Эта папка также содержит один файл с именем demoFoods_Variable_Global.swift.

При этом demoFoods — это название объекта, Variable — это тип объекта и Global это локация объекта в глобальной зоне видимости. Т.е., по сути, это Stub data.

3. Load Foods

Следующая папка — Load Foods — обозначает бизнес‑процесс загрузки данных в оперативную память приложения. Она включает в себя 2 файла:

loadRealOrDemoFoodsData_Method_ExtFoods.swift

Этот файл содержит в себе метод loadRealOrDemoFoodsData и является расширением класса Foods.

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

Данный файл как раз реализует это правило.

Заодно рассмотрим и его внутреннюю структуру.

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

Таким образом, структура файла проста и понятна. Обозначена задача и код решает эту задачу.

Как известно, именно к такой, простой и понятной структуре файла следует стремиться.

viewDidLoad_Method_ExtFoods.swift

Второй файл в этой папке также является расширением класса Foods и содержит в себе, как видно из названия файла , стандартный метод viewDidLoad.

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

4. Storage Foods: Бизнес-процессы разработки и бизнес-процессы выполнения программы

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

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

Именно этот момент и иллюстрирует Рис. 4, где папка Load Foods и соответствующий ей бизнес-процесс, предшествует папке Storage Foods. И файл с объявленным классом Foods появляется в навигационном дереве уже после используемых своих же расширений.

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

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

5. Show Foods in the Table

Следующий бизнес-процесс — показ данных на экране, в данном случае в таблице: Show Foods in the Table. Он содержит один файл, названный TableDataSource_Methods_ExtFoods.

Как видим, в названии этого файла используется слово не Method, а Methods, что означает, что в этот файл включены несколько методов.

Но в отличие от предыдущего файла с классом Foods, внутри которого может находиться несколько блоков кода для решения разных задач, внутри этого файла находится несколько методов, которые решают одну и ту же задачу — передача данных из оперативной памяти в таблицу, т.е., в видимую для пользователя часть приложения. Это типовые методы numberOfSections(in:), tableView(:numberOfRowsInSection🙂 и tableView(:cellForRowAt:).

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

Компоновка всех этих трёх методов в отдельное расширение класса Foods позволяет разгрузить базовый файл класса и сгруппировать код по принципу решения определённой бизнес-задачи.

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

Режимы показа данных

В этом же бизнес-процессе — Show Foods in the Table — есть два своих дочерних процесса: Sort Foods и Search and Filter Foods.

Эти дочерние бизнес-процессы реализуют ту же задачу показа данных, но в разных режимах: либо вывести на экран данные в определённом порядке, либо выбрать для показа только часть данных.

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

В целом, следует отметить, что активное использование расширений базового класса, в том числе вынос в них стандартных методов, таких как viewDidLoad и TableViewData Source методов, позволяет освободить, разгрузить базовый файл класса и таким образом нивелировать проблему Massive View Controller.

6. Edit Foods

Рассмотрим теперь дочерние процессы бизнес-процесса Edit Foods. Они показаны на Рис. 5.

Бизнес-процесс Edit Foods включает в себя следующие дочерние бизнес-процессы:

• Delete Food

• Pass Food to Edit

• Load Editing Food

• Storage Editing Food

• Prevent Input Error

• Pass Edited Food Back to Foods

• Get Edited Food in Foods

• Persist Edited Foods

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

Каждая задача в этом блоке реализуется в своём отдельном файле, что можно увидеть на Рис. 6.

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

Например, prepareForSegue, viewDidLoad, unwindSegue и др. Это позволяет легче ориентироваться в коде.

И теперь, на примере этих бизнес-процессов, необходимо сделать очень важное замечание.

Что такое Модель?

Что, в упомянутых в начале этой статьи архитектурных паттернах, понимается под Моделью?

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

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

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

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

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

Примечание

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

Типовые бизнес-процессы. Типовая архитектура

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

На Рис. 7 показаны дочерние процессы двух базовых бизнес-процессов приложения: Manage Foods и Manage Meals.

Как видим они полностью совпадают и включают в себя по 6 дочерних процессов:

• Model

• Test

• Load

• Storage

• Show

• Edit

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

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

Заключение

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

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

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

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

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

P.S.

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

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

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