При разработке бизнес-приложения в первую очередь внимание уделяется видимым задачам. Создаются таблицы, определяются связи, разрабатываются формы ввода данных и автоматизируются рабочие процессы. Как только первые пользователи получают возможность работать с решением, кажется, что значительная часть проекта завершена. Однако при практическом использовании начинается этап, который в долгосрочной перспективе оказывается более сложным. Приложение, используемое в бизнесе, необходимо поддерживать, расширять и адаптировать к новым требованиям. Изменения должны документироваться, новые версии — распространяться, а имеющиеся данные — надежно переноситься. К этому добавляются различные права доступа пользователей, резервное копирование данных, анализ ошибок и вопрос о том, где будет развернуто решение: локально, на собственном сервере или в облаке.
Многие платформы разработки в первую очередь сосредоточены на создании самого приложения. Для обновлений, документирования, развертывания и эксплуатации позже добавляются дополнительные инструменты и индивидуальные процедуры. Со временем формируется техническая среда, состоящая из множества отдельных компонентов, которые можно удержать вместе лишь с значительными затратами. Поэтому SchallOS придерживается более комплексного подхода. Платформа призвана сопровождать бизнес-приложение не только на этапе его создания, но и на протяжении всего жизненного цикла: от разработки, документирования и развертывания до обновлений и постоянной эксплуатации.
От миграции с FileMaker на собственную платформу
Изначально проект SchallOS был запущен с целью миграции существующих решений на базе FileMaker. На протяжении десятилетий FileMaker зарекомендовала себя как мощная среда для разработки индивидуальных приложений баз данных. В частности, тесная взаимосвязь между моделью данных, макетом и программной логикой обеспечивает быструю и практичную разработку.
Однако полноценное решение FileMaker состоит не только из таблиц и видимых масок. Оно включает в себя вычисления, скрипты, права доступа пользователей, макеты печати, интерфейсы и множество специфических операционных сценариев. Пригодная для использования платформа-преемник должна учитывать все эти взаимосвязи и впоследствии обеспечивать их независимое функционирование.
Исходя из этой задачи, SchallOS постепенно превратилась в самостоятельную платформу. Должна быть обеспечена возможность миграции существующих решений FileMaker, при этом новые приложения можно будет разрабатывать непосредственно в SchallOS. После полной миграции FileMaker больше не потребуется для производственной эксплуатации.
Разработка, время выполнения и эксплуатация остаются разделенными
Платформа разработки SchallOS состоит из нескольких подразделений, каждое из которых выполняет четко определенные задачи.
- Студия SchallOS — это среда разработки. Именно в ней создаются структуры данных, макеты, формулы, функции, языки и версии. В состав Studio также входит мастер миграции для существующих решений FileMaker.
- SchallOS Runtime запускает опубликованные приложения. Она предоставляет пользовательский интерфейс и необходимую программную логику, не предоставляя при этом автоматически доступ ко всем инструментам разработки.
- SchallOS Control управляет целями развертывания, подключениями к базам данных, профилями среды выполнения, обновлениями и техническими проверками.
- SchallOS Cloud предоставляет приложения в виде централизованно управляемого онлайн-сервиса. При этом не предполагается создание отдельного облачного формата. Локальные, серверные и облачные установки используют одну и ту же базовую архитектуру решения.
Такое разделение предотвращает бесконтрольное смешение процессов разработки, эксплуатации и администрирования. При этом все области остаются технически согласованными друг с другом.
Решение для различных моделей работы
Бизнес-приложение может начинаться с небольшого проекта, а затем расширяться. На первых порах, возможно, достаточно будет одной локальной рабочей станции. Позже к проекту присоединятся новые сотрудники, появится центральный сервер или несколько филиалов. Поэтому SchallOS должна обеспечивать одно и то же базовое решение для различных форм эксплуатации: локально в браузере, в виде приложения для Windows или macOS, с использованием SQLite или PostgreSQL, а также в качестве SaaS-решения в облаке.
Не каждая форма эксплуатации обладает одинаковыми техническими характеристиками. К локальной базе данных предъявляются иные требования, чем к централизованной многопользовательской системе. Однако решающим фактором является то, что макеты, функции и модель данных не нужно разрабатывать заново для каждой конкретной задачи.
Жизненный цикл является частью архитектуры
В SchallOS документация, журналы событий и обновления не добавляются к готовому приложению задним числом. Они являются неотъемлемой частью базовой архитектуры. Структура и производственные данные управляются отдельно. Изменения, внесенные в ходе разработки, могут регистрироваться в журнале и объединяться в релизы. Обновления можно проверять, распространять и, в случае проблем, контролируемо откатывать. Встроенный искусственный интеллект помогает не только при работе с формулами и функциями, но и при составлении документации и общении с клиентами.
Таким образом, SchallOS объединяет области, которые в традиционных проектах зачастую рассматриваются отдельно. Разработка приложения больше не является завершением технического процесса, а представляет собой первый этап долгосрочного жизненного цикла.
SSC и SSD как переносимые контейнеры структур и данных
Многие приложения, работающие с базами данных, хранят структуру, пользовательский интерфейс, программную логику и рабочие данные в одном тесно связанном блоке. Вначале это удобно, но затрудняет последующие обновления, миграции и использование различных режимов работы. Как только появляются несколько клиентов, более крупные массивы данных или индивидуальные расширения, обмен полным файлом приложения быстро становится проблематичным.
Поэтому SchallOS принципиально отделяет описание решения от его бизнес-данных. Приложение в основном состоит из двух взаимосвязанных контейнеров: SSC для структуры и SSD для производственных данных.
Оба контейнера вместе составляют полноценное решение, но выполняют разные задачи. SSC описывает структуру и принцип работы приложения. SSD содержит данные, которые формируются в процессе его использования.
SSC описывает порядок применения
Файл SSC представляет собой переносимый контейнер структур решения SchallOS. В нём, в частности, содержатся:
- Определения таблиц и полей
- Отношения
- Макеты и объекты макета
- Формулы и собственные функции
- Функциональный контейнер
- Триггеры и навигация
- Информация о языках и переводах
- Документация
- Сведения о версиях и выпусках
Таким образом, SSC не содержит самих данных о клиентах, товарах, заказах или счетах. Он определяет, какие структуры данных существуют, как они отображаются и какие функции с ними работают. Семантическое значение решения также входит в этот контейнер. Помимо технического названия, поле может иметь предметно-логическое описание, переводы, правила валидации и указания для уровня искусственного интеллекта. Благодаря этому структура становится не только машиночитаемой, но и более понятной для разработчиков, а также облегчает документирование и миграцию.
Таким образом, SSC представляет собой переносимую модель приложения, которую можно дорабатывать и публиковать независимо от конкретного набора данных.
На SSD хранятся рабочие данные
Файл SSD представляет собой контейнер данных данного решения. Он содержит записи, формирующиеся в ходе повседневной работы, например, данные о клиентах, предложениях, заказах, счетах, складских операциях или сроках. Кроме того, в нем могут храниться профильные истории и события, связанные с данными. К ним относятся, например, изменения статуса, утверждения, импорт данных или изменения в особо важных полях. Термин «SSD» в данном контексте обозначает не физический носитель данных, а логический уровень данных приложения. Технический способ хранения этих данных зависит от выбранного варианта развертывания и адаптера базы данных.
Для локального однопользовательского приложения можно использовать IndexedDB. Настольное приложение может работать с SQLite, тогда как в крупных многопользовательских приложениях используется PostgreSQL. Во всех случаях SSD остается функциональным контейнером данных, даже если способы их технического хранения различаются.
Два контейнера должны однозначно составлять одну пару
Разделение структуры и данных не должно приводить к тому, что любые контейнеры будут произвольно комбинироваться друг с другом. SchallOS должен иметь возможность проверить, действительно ли SSC и SSD относятся к одному и тому же решению и совместимы ли их версии. Для этого можно использовать идентификаторы решений, идентификаторы контейнеров, версии структур, контрольные суммы и подписи. Таким образом, перед запуском или обновлением можно определить, является ли данная комбинация допустимой и были ли уже выполнены необходимые операции по миграции данных.
Эта проверка, например, предотвращает случайное открытие контейнера структуры другого приложения с производственным набором данных. Кроме того, она предотвращает активацию новой версии SSC в том случае, если SSD ещё не подготовлен к необходимой для этого структуре данных.
Переносимость между различными формами деятельности
Разделение SSC и SSD создает основу для эксплуатации приложения в различных средах. Нет необходимости заново разрабатывать макеты, формулы и логику функций для каждого адаптера базы данных.
В качестве решения можно начать с локального использования IndexedDB, позже перейти на SQLite, а при росте числа пользователей — на PostgreSQL. Также возможен переход в облачную среду.
Такой переход остается контролируемым техническим процессом. Различные базы данных имеют свои собственные возможности и ограничения. Поэтому данные не переносятся в другую систему просто нажатием кнопки. Перенос, проверка и, при необходимости, откат должны выполняться явно.
Однако такая архитектура гарантирует, что смена системы хранения данных не повлечёт за собой автоматическую необходимость полной переработки всего приложения.
Обновления без замены данных клиентов
Одно из основных преимуществ такого разделения становится очевидным при выпуске новых версий. Изменения часто затрагивают макеты, формулы, функции или модель данных. При этом существующие бизнес-данные должны оставаться неизменными.
Поэтому разработчик может выпустить новую версию SSC, при этом SSD клиента остается на месте эксплуатации. Если требуются новые поля или таблицы, они добавляются посредством определенных этапов миграции. Перед обновлением можно создать резервную копию текущего состояния. Затем проверяются структура, миграция данных и работоспособность. Только когда SSC и SSD вновь приходят в согласованное состояние, обновление считается завершённым.
Эта возможность обновления предусмотрена не только для самой системы SchallOS. Она также доступна для клиентских решений, разработанных на базе SchallOS.
Варианты, разработанные по индивидуальному заказу, остаются отслеживаемыми
Индивидуальное бизнес-программное обеспечение у разных клиентов зачастую развивается по-разному. Одному клиенту требуются собственные поля, другому — дополнительные макеты или специальный интерфейс. Без четкой структуры это быстро приводит к появлению отличающихся друг от друга полных копий, которые впоследствии становится трудно поддерживать совместно. В SSC, напротив, общие компоненты продукта и расширения, разработанные под конкретного клиента, могут быть прослеживаемыми по версиям и тщательно задокументированными.
Архитектура не берет на себя за разработчика решение о том, какое изменение следует включить в общий продукт. Однако она обеспечивает прозрачность происхождения и зависимостей каждого изменения.
В сочетании с протоколами разработки и релизами это позволяет при последующих обновлениях лучше определить, какие компоненты необходимо заменить, дополнить или оставить без изменений.
Многоязычность является частью переносимой структуры
Языковой уровень также интегрирован в SSC. Названия не хранятся исключительно в виде фиксированных значений в отдельных объектах макета, а могут ссылаться на семантические записи, содержащие несколько языковых версий.
Благодаря этому такое поле, как „Номер счета“, может отображаться на разных языках без необходимости создания полностью нового макета для каждого языка. Мигрированное решение FileMaker может быть автоматически преобразовано в многоязычный формат и переведено в ходе миграции.
Автоматический перевод не заменяет экспертную проверку. Особенно тщательной проверке подлежат юридические и отраслевые термины. Однако архитектура системы обеспечивает, чтобы многоязычность была частью решения с самого начала, а не приходилось потом с трудом внедрять её в каждую форму.
Основа для обеспечения долгосрочной ремонтопригодности
На первый взгляд SSC и SSD выглядят как простое разделение на приложение и данные. Однако на самом деле они составляют основу для переносимости, обновлений, различных адаптеров баз данных, раздельного резервного копирования и различных моделей эксплуатации.
В SSC описывается, что такое решение и как оно работает. В SSD содержится то, что возникает в процессе его использования и что необходимо сохранить на постоянной основе для данной компании.
Благодаря такому четкому разделению приложение может развиваться без необходимости полной замены всего массива данных при выпуске каждой новой версии. В то же время система хранения технических данных может расширяться или меняться без необходимости полной переработки макетов и бизнес-логики.
SchallOS Studio как интегрированная среда разработки
SchallOS Studio — это раздел платформы, в котором создаются новые бизнес-приложения, а также осуществляется миграция или доработка существующих решений FileMaker. Здесь в рамках единой среды осуществляется управление таблицами, полями, связями, макетами, формулами, функциями, языками и версиями.
Разработчикам FileMaker этот подход к работе должен показаться привычным. Изменения вносятся не только в абстрактные файлы исходного кода, но и остаются связанными с видимыми компонентами приложения. Разработчик может редактировать макет, выбрать поле, изменить его свойства и сразу же проверить, как эти изменения повлияют на приложение.
Тем не менее, SchallOS не ставит перед собой цель полностью воссоздать FileMaker. В первую очередь перенимаются проверенные основные идеи: быстрая разработка, мгновенная обратная связь и тесная взаимосвязь между моделью данных, пользовательским интерфейсом и бизнес-логикой. Техническая основа, напротив, будет реорганизована и ориентирована на переносимые структуры, программирование с использованием искусственного интеллекта, документирование и контролируемые релизы.
Макеты, объекты и свойства
Важной составляющей SchallOS Studio является режим макета. Именно в нем создаются формы ввода, списки, диалоговые окна, области навигации и другие элементы пользовательского интерфейса решения.
К возможным объектам макета относятся, в частности, поля, тексты, кнопки, объекты списка, области вкладок, всплывающие окна, контейнеры и элементы навигации. Объекты можно выделять, размещать и настраивать с помощью инспектора.
При этом объект макета содержит не только сведения о размере, положении и отображении. Он также может быть связан с источниками данных, триггерами, формулами, функциями и семантическими обозначениями. Например, объект поля ссылается на поле в модели данных, может иметь языкозависимую надпись и запускать определённые функции при входе в него или выходе из него.
Поскольку каждый объект является составной частью SSC, изменения макета можно версионировать, документировать и впоследствии целенаправленно распространять посредством обновления. Таким образом, пользовательский интерфейс не остается изолированным графическим уровнем, а становится структурированной составной частью всего приложения.
Модель данных и семантические описания
Таблицы, поля и связи также создаются и редактируются в SchallOS Studio. Там можно полностью создавать новые приложения. При миграции из FileMaker мастер миграции по возможности переносит существующие структуры и затем предоставляет их для дальнейшей обработки.
В SchallOS поле состоит не только из технического названия и типа данных. Оно может дополнительно содержать предметное описание, правила валидации, стандартные значения, переводы и примечания к документации.
Эта информация служит нескольким целям. Она облегчает другим разработчикам понимание решения, способствует автоматическому формированию документации и предоставляет встроенному ИИ более полный контекст. Например, вместо того, чтобы просто распознавать, что поле называется „Статус“, платформа может определять, идет ли речь о статусе заказа, статусе оплаты или внутреннем статусе обработки.
Кроме того, можно описать связи между таблицами и задокументировать их предметный контекст. Благодаря этому меньше знаний остаётся скрытыми исключительно в голове первоначального разработчика.
Формулы с расчетом в режиме реального времени
SchallOS имеет собственную среду для работы с формулами. Формулы создаются в редакторе формул и вычисляются в режиме реального времени во время редактирования. Благодаря этому изменения в выражении можно сразу же проверить с помощью подходящих тестовых значений или текущего набора данных.
Язык формул поддерживает типичные вычисления, необходимые в бизнес-приложениях. К ним относятся математические операции, работа с текстом, вычисления даты и времени, логические условия, ссылки на поля, переменные и вложенные выражения.
На данный момент набор доступных команд меньше, чем набор функций FileMaker, формировавшийся на протяжении десятилетий. SchallOS не обязан в неизменном виде воспроизводить каждую историческую команду FileMaker. Гораздо важнее наличие четко структурированной и расширяемой среды формул.
Дополнительные команды можно будет добавить позже, если они понадобятся для реализации определенных решений или миграций. В этом случае встроенный ИИ также может помочь перенести существующий алгоритм или разработать недостающую функцию с учетом архитектуры SchallOS.
Пользовательские функции для повторно используемых вычислений
Помимо встроенных команд, SchallOS поддерживает пользовательские функции. Они принимают параметры, выполняют заданный расчет и возвращают результат. Это позволяет управлять повторяющимися правилами из одного централизованного места. Примерами могут служить расчёт цен, определение сроков, форматирование, проверка диапазонов номеров или обработка импортированных значений.
Пользовательские функции также вычисляются в режиме реального времени и могут быть сразу же протестированы в редакторе формул. Если впоследствии функция будет исправлена или расширена, это повлияет на все формулы, в которых она используется.
Кроме того, можно описывать и документировать собственные функции. Благодаря этому параметры, возвращаемое значение, примеры и известные случаи ошибок остаются понятными. Набор функций решения превращается в библиотеку, готовую к повторному использованию, вместо того чтобы состоять из множества скопированных отдельных вычислений.
Функциональные контейнеры для более сложных процессов
Более сложные бизнес-процессы в SchallOS организуются с помощью функциональных контейнеров. С их помощью можно, например, создавать записи, проверять значения, управлять диалоговыми окнами, формировать документы или взаимодействовать с внешними интерфейсами. Функциональный контейнер содержит не только исполняемый код. К нему также относятся предметно-техническое описание, входные параметры, возвращаемые значения, зависимости, разрешённые возможности и явно исключённые операции.
Несколько объектов макета могут использовать один и тот же контейнер функций. Благодаря этому нет необходимости заново создавать функцию для формирования счета для каждой кнопки или каждого макета.
В случае мигрированных решений существующие скрипты FileMaker могут оставаться в фоновом режиме в качестве обучающего и справочного слоя. Они помогают понять первоначальный замысел и прежний порядок действий. Однако новый исполняемый код генерируется с учетом архитектуры SchallOS.
Миграция и разработка новых решений в одной среде
SchallOS Studio — это не только среда для существующих решений FileMaker. Новые приложения могут создаваться полностью в рамках этой платформы.
При миграции мастер сначала переносит существующие таблицы, поля, связи, макеты и другие распознаваемые компоненты. Затем разработчики могут проверить импортированную структуру, очистить её и поэтапно перенести в новую функциональную архитектуру.
При этом не предполагается создание неизменённой копии всех прежних особенностей. Сформировавшиеся в ходе истории обходные пути можно пересмотреть и заменить более чёткими структурами. При этом сохраняются профессиональные знания, заложенные в существующем решении.
Впоследствии как новые, так и перенесённые приложения будут использовать одни и те же инструменты, контейнеры и способы публикации.
Изменения становятся контролируемыми выпусками
Изменение, внесённое в студии, не становится автоматически рабочим обновлением. На этапе разработки могут присутствовать незавершённые макеты, предварительные формулы или ещё не проверенные функции.
Поэтому связанные между собой изменения можно регистрировать в сессиях изменений (Change Sessions) и впоследствии привязывать к релизу. Только после проверки и утверждения на их основе формируется опубликованная версия SSC.
Помимо новой структуры, релиз может также включать необходимые операции по миграции данных, указания на версии, зависимости, этапы тестирования и документацию. Таким образом, собственно разработка четко отделяется от развертывания на рабочих экземплярах среды выполнения.
Таким образом, SchallOS Studio — это не просто среда, в которой происходит разработка и программирование приложения. Она объединяет визуальную разработку, модель данных, формулы, функции, документацию и публикацию в единой среде.
Сохраняется привычная тесная связь между разработчиком и конечным приложением. В то же время создается техническая основа, на которой можно продолжать разработку решений, обеспечивающих их переносимость, прозрачность и возможность долгосрочного обслуживания.
ИИ — там, где рождаются формулы и функции
В настоящее время во многих средах разработки искусственный интеллект в основном предоставляется через отдельное окно чата. Разработчик описывает проблему, копирует исходный код или формулы в чат, а затем переносит результат обратно в проект. При этом языковой модели часто не хватает важной информации о таблицах, полях, связях и предметном значении приложения.
Поэтому SchallOS напрямую интегрирует ИИ в инструменты разработки. Он доступен там, где происходит редактирование формул, пользовательских функций и контейнеров функций. Благодаря этому ИИ получает не только отдельный вопрос, но и текущий контекст решения.
Например, в редакторе формул ИИ знает редактируемое выражение, доступные поля и ожидаемый тип результата. В пределах контейнера функций он также может получить доступ к его описанию, параметрам, возможностям и зависимостям.
Таким образом, ИИ становится не отдельной вспомогательной программой, а неотъемлемой частью самой среды разработки.
Поддержка в редакторе формул
Формулы управляют множеством процессов в бизнес-приложении. Они рассчитывают цены, проверяют условия, определяют сроки или влияют на отображение объектов макета. Встроенный ИИ в редакторе формул может, в частности:
- объяснить существующую формулу
- проанализировать возможные ошибки
- Дополнить условия
- упростить выражение
- перенести формулу FileMaker
- или создать новый расчет на основе технического описания.
Например, разработчик может задать, что заказы, превышающие определенную чистую стоимость, требуют дополнительного утверждения, если не заключен рамочный договор. ИИ может сгенерировать на основе этого формулу, используя поля, имеющиеся в решении. Результат отображается в виде обычной формулы. Её можно просматривать, изменять и вычислять в режиме реального времени. Таким образом, ИИ не создаёт никаких скрытых процессов, поведение которых было бы трудно отследить.
Если нужной команды нет, ИИ также может помочь создать подходящую пользовательскую функцию или расширение среды формул. Благодаря этому набор команд SchallOS, который поначалу может казаться ограниченным, остается расширяемым.
Пользовательские функции на основе технических требований
Повторяющиеся вычисления можно централизованно управлять с помощью пользовательских функций. ИИ может на основе описания сгенерировать функцию с уникальными параметрами, возвращаемым значением и задокументированным поведением.
Такая функция могла бы, например, рассчитывать сроки предоставления скидки, проверять диапазоны номеров или унифицировать импортированные значения. Помимо собственно распечатки, можно также создавать тестовые значения, примеры и возможные варианты ошибок.
Это облегчает не только первоначальное программирование. При последующих изменениях ИИ сможет распознать, какое значение имеет данная функция и в каких местах она используется.
Таким образом, анонимный расчет превращается в задокументированный и готовый к повторному использованию компонент решения.
Функциональный контейнер как описанная программная логика
Более сложные процессы в SchallOS организуются с помощью функциональных контейнеров. Функциональный контейнер может, например, создавать наборы данных, проверять вводные данные, управлять диалоговыми окнами, генерировать документы или вызывать внешние интерфейсы. Основой служит структурированное описание. Оно может определять:
- какую задачу выполняет эта функция
- какие параметры передаются
- какой результат ожидается
- к каким таблицам и полям разрешен доступ
- какие еще функции используются
- и какие действия прямо исключаются.
На основе этих заданий ИИ генерирует исполняемый код функционального контейнера. Благодаря этому разработчику больше не нужно составлять алгоритм исключительно из множества отдельных шагов скрипта. Его задача в большей степени сводится к точному описанию требуемой функции, определению её границ и последующей проверке.
Тем не менее сгенерированный код остается видимым. Его можно читать, тестировать, дорабатывать и сравнивать между различными версиями. Также можно сохранять предыдущие версии и при необходимости восстанавливать их. Таким образом, ИИ берет на себя программирование, но не несет профессиональной ответственности.
Сценарии FileMaker в качестве учебного слоя
В случае мигрированных решений FileMaker существующие скрипты зачастую содержат значительную часть бизнес-логики, сформировавшейся на протяжении многих лет. Они показывают, какие поля изменялись, какие условия проверялись и какие дополнительные процессы запускались.
Эти скрипты не будут на постоянной основе включены в SchallOS в качестве исполняемого уровня выполнения. В результате многие прежние технические зависимости и обходные пути просто перенеслись бы в новую систему. Вместо этого исходный скрипт FileMaker может оставаться в фоновом режиме соответствующего функционального контейнера. Он служит ИИ в качестве слоя обучения, справочного материала и понимания.
ИИ может на основе этого определить функциональную цель прежнего рабочего процесса. Затем он программирует новый код в соответствии с архитектурой SchallOS. При этом исторические конструкции, такие как частые смены макета, глобальные поля или контекстно-зависимые вспомогательные скрипты, не обязательно должны переноситься без изменений. Их использование будет продолжено только в том случае, если они действительно необходимы для собственно бизнес-процесса.
Тем не менее исходный скрипт сохраняется в качестве источника информации. В случае возникновения вопросов в будущем можно будет проследить, как изначально был реализован тот или иной алгоритм в решении FileMaker.
Способности и ограничения четко определены
Функциональный контейнер не должен иметь возможности обращаться к произвольным областям приложения только на основании общего описания. Поэтому можно явно определить разрешенные возможности и ограничения.
Например, функция может иметь право на чтение и изменение записей в определенной таблице, но при этом не иметь права на удаление записей или внесение изменений в системные настройки. Если сгенерированный код использует неразрешенную возможность, SchallOS может это обнаружить и заблокировать его выполнение или публикацию.
Таким образом, описание функционального контейнера служит не только для документирования. Оно становится частью модели тестирования и безопасности. Это ограничение особенно важно в случае кода, сгенерированного ИИ. Языковая модель получает четко очерченные рамки действия, в то время как платформа контролирует, находится ли сгенерированная функция в пределах этих рамок.
Правильный контекст улучшает результаты
Качество функции, сгенерированной ИИ, зависит не только от размера используемой языковой модели. Решающим фактором является то, получает ли модель необходимую информацию. SchallOS может формировать контекст на нескольких уровнях:
- текущего вопроса
- в открытом редакторе
- в выбранном поле или функциональном контейнере
- соответствующих таблицах и связях
- существующие формулы и функции
- семантические описания
- Документация и история изменений
- а также при миграции — исходному скрипту FileMaker.
Благодаря этому ИИ может работать значительно точнее, чем при обработке отдельного запроса в общем чате.
В то же время не обязательно предоставлять полное решение для каждой задачи. Контекст можно ограничить той информацией, которая действительно необходима для данной функции.
Сменные модели вместо постоянной привязки
ИИ-слой не должен постоянно зависеть от одной конкретной модели или поставщика. Различные задачи предъявляют разные требования к качеству, скорости, затратам и защите данных.
Для сложной миграции может потребоваться особенно мощная модель. Простое объяснение или корректировка формулы, возможно, можно осуществить с помощью более компактной модели. В случае чувствительных или закрытых сред в долгосрочной перспективе также можно использовать локально развернутые модели.
Поэтому постоянная база знаний заключается не в языковой модели, а в решении SchallOS: в описаниях, структурах, ссылках на скрипты, коде, тестах и документации. Модель ИИ остается заменяемым инструментом, который на основе этого контекста генерирует исполняемый код или понятные предложения.
Прозрачный процесс разработки с использованием ИИ
SchallOS сочетает непосредственную работу с бизнес-приложениями с программированием на основе искусственного интеллекта. Формулы можно напрямую объяснять и генерировать. Пользовательские функции создаются на основе повторно используемых предметно-логических спецификаций. Контейнеры функций объединяют семантические описания с видимым и проверяемым кодом.
В случае мигрированных решений скрипты FileMaker сохраняются в качестве дополнительного уровня обучения. Они помогают понять существующие бизнес-процессы, не закрепляя при этом прежние технические зависимости на постоянной основе.
При этом роль разработчика не исчезает. Она меняется. Четкие требования, продуманная архитектура, тестирование и экспертный контроль становятся важнее, чем ручной ввод каждого отдельного шага программы. Именно в случае программного обеспечения, критически важного для бизнеса, эта ответственность остается незаменимой.
Текущий обзор использования локальных систем искусственного интеллекта
Документация и журналы событий как часть приложения
Документация по бизнес-приложению зачастую составляется только после завершения разработки. В условиях дефицита времени внимание в первую очередь уделяется новым полям, макетам, формулам и функциям. Описание внесенных изменений планируется подготовить позже.
Однако с увеличением временного интервала становится все сложнее проследить исходные решения. Зачастую уже невозможно точно установить, почему была добавлена та или иная функция, какие объекты были затронуты и какие частные случаи необходимо было учесть. Поэтому SchallOS не рассматривает документирование как дополнительную задачу, выполняемую задним числом. Соответствующие изменения фиксируются в качестве событий уже на этапе разработки и связываются с затронутыми компонентами решения.
На основе этой информации впоследствии можно создавать техническую документацию, примечания к выпуску, отчеты для клиентов или протоколы выполнения работ. Таким образом, документация основывается не только на воспоминаниях или записях, сделанных вручную, но и на фактически внесенных изменениях.
События на нескольких уровнях
Решение SchallOS не ограничивается одним общим протоколом. Платформа различает различные уровни событий, каждый из которых выполняет свои задачи.
- Сайт Протокол структуры фиксирует изменения в SSC. К ним относятся, например, новые таблицы и поля, измененные макеты, измененные формулы или новые контейнеры функций.
- Сайт Журнал событий данных относится к SSD. В нем фиксируются профессионально значимые операции, происходящие в ходе эксплуатации, например, изменения статуса, утверждения, отмены или изменения важных записей.
- К этому следует добавить Производственные события из Runtime и SchallOS Control. К ним относятся, в частности, развертывание, обновления, проверки, резервное копирование и операции отката.
Эти области остаются раздельными, но могут быть связаны между собой. Протокол разработки не должен становиться запутанным из-за повседневных изменений в записях о клиентах. И наоборот, внутренние технические детали не должны автоматически включаться в деловую историю счета или заказа.
Протокол структуры отражает ход разработки решения
Изменения в таблицах, полях, макетах, формулах и контейнерах функций можно сохранять в виде структурированных событий. В записи можно указать, какой объект был изменен, каково было его предыдущее состояние и какое новое состояние было создано. Кроме того, можно указать разработчика, время, техническое обоснование, соответствующий заказ и запланированную версию релиза.
Например, при добавлении нового процесса утверждения заказов могут возникнуть несколько технических изменений. Создается поле статуса, расширяется макет, корректируется формула и программируется новый функциональный контейнер.
Протокол структуры сохраняет эти отдельные события. При этом их можно объединить в рамках одной общей функциональной задачи. Благодаря этому становится очевидным, что несколько технических изменений в совокупности образуют новый бизнес-процесс.
Сессии «Change» объединяют связанные между собой работы
Задача разработки часто состоит из множества мелких шагов. Чисто хронологический перечень отдельных изменений не смог бы в полной мере отразить их взаимосвязь.
Поэтому SchallOS может объединять связанные между собой задачи в «сессии изменений». «Сессия изменений» описывает конкретную задачу, расширение или исправление ошибки и объединяет все связанные с ней события. Например, она может включать:
- описание должностных обязанностей
- затронутые таблицы и макеты
- измененные формулы и функции
- проведенные испытания
- нерешенные вопросы
- а также привязка к клиенту или заказу.
Несколько сессий изменений можно впоследствии отнести к одному релизу. Таким образом устанавливается прослеживаемая связь между заданием на разработку, техническими изменениями и выпущенной версией.
ИИ преобразует технические события в понятную форму
Уровень документирования подключен к встроенному ИИ системы SchallOS. Благодаря этому зарегистрированные события могут автоматически обрабатываться для различных целевых групп.
Технический отчет разработчика требует иной информации, чем сообщение для клиента. В то время как разработчику нужны конкретные названия полей, контейнеры функций и данные о миграции, клиента в первую очередь интересует, какая функция была добавлена и какую пользу она приносит. Поэтому ИИ может обобщать одни и те же события в разных формах:
- в качестве внутренней технической документации
- в виде понятной информации для клиентов
- в качестве примечаний к выпуску
- в качестве отчета по проекту
- или в качестве подтверждения выполнения работ по счету.
Тексты не создаются произвольно на основе общего описания. Они выводятся на основе сеансов изменений, семантических описаний объектов и фактических изменений структуры.
При этом сгенерированный текст остается связанным со своими источниками. Разработчик может проверить, на каких событиях основано то или иное утверждение, и перед использованием исправить или утвердить его формулировку.
Отчеты о производительности для разработчиков и клиентов
Для разработчиков индивидуального программного обеспечения документация имеет также экономическое значение. Услуги должны быть понятно разъяснены заказчику, а оплата за них часто производится по часам или по пакетам работ.
На практике такие отчеты об оказанных услугах часто составляются лишь незадолго до выставления счета. Для этого приходится просматривать электронные письма, заметки и напоминания.
SchallOS может соотнести фактически зарегистрированные события разработки с конкретным заказчиком, проектом или заказом. На основе этого ИИ формирует соответствующие записи для отчета о выполненных работах. Например, несколько технических изменений можно объединить в одну понятную позицию:
Расширение системы управления заказами за счет внедрения двухэтапного процесса утверждения, включая проверку статуса, права доступа пользователей и настройку формы ввода данных.
Основные технические процессы по-прежнему остаются доступными для просмотра. Описание для клиента представляет собой лишь понятное краткое изложение. Окончательный выбор остается за разработчиком. Не каждое техническое событие автоматически подлежит оплате, а внутренние испытания или исправления не обязательно должны отдельно указываться в счете.
События на уровне данных
Даже в режиме производственной эксплуатации можно регистрировать все предусмотренные события, связанные с данными. К ним относятся создание и изменение записей, смены статуса, разрешения, импорт, экспорт или автоматически выполняемые процессы. В записи может фиксироваться:
- какой пользователь или процесс инициировал это действие
- какая запись была затронута
- какие значения были изменены
- какая функция была выполнена
- и была ли операция успешно завершена.
Конкретное решение определяет, какие события и с какой степенью детализации будут сохраняться. Небольшая исправление в тексте имеет иное значение, чем изменение уже выставленного счета. Таким образом, журнал событий данных формирует функциональную историю SSD. Он способствует оказанию технической поддержки, анализу ошибок и обеспечению прослеживаемости важных бизнес-процессов.
Такой протокол также может служить основой для требований аудита. Однако необходимо проверить, соответствует ли он всем правовым или отраслевым требованиям в конкретном случае.
Документация также сопровождает выпуски и обновления
Зарегистрированные события разработки одновременно поступают в конвейер выпусков и обновлений. При выпуске новой версии SchallOS может автоматически составить список добавленных функций, исправленных ошибок и измененных структур данных. На этой основе формируются списки технических изменений, рекомендации для пользователей и информация по миграции.
После установки можно отследить, какая версия была установлена на конкретный экземпляр среды выполнения и какие изменения в ней содержались.
Также документируются такие события в процессе эксплуатации, как резервное копирование, тестирование или возможный откат. Благодаря этому впоследствии можно не только определить, что именно было разработано, но и когда и с каким результатом было внедрено изменение в производственную среду.
Растущая база знаний
Сочетание журнала событий, семантических описаний и поддержки искусственного интеллекта позволяет в долгосрочной перспективе создать базу знаний обо всем решении. При последующих изменениях можно будет учитывать не только текущий код. Также будет понятно, когда была внедрена та или иная функция, какова была бизнес-причина этого и какие другие области были затронуты в то время.
Именно в случае бизнес-приложений, развивавшихся на протяжении многих лет, эти знания имеют решающее значение. Кажущийся излишним частный случай может иметь важное историческое обоснование. Без документации существует риск, что при последующей доработке он будет случайно удален. Поэтому SchallOS сохраняет не только технические характеристики, но и историю разработки, а также связанные с ней решения.
Таким образом, документация становится активной составляющей приложения. Она способствует разработке, взаимодействию с клиентами, выставлению счетов, технической поддержке, выпуску обновлений и обеспечению долгосрочной обслуживаемости — на основе событий, которые действительно произошли в системе.
Системный конвейер обновлений для платформы и приложений
Бизнес-программное обеспечение редко остается неизменным в течение длительного времени. Новые требования, изменения в законодательстве, исправления ошибок и технические усовершенствования регулярно приводят к появлению новых версий. При этом недостаточно просто обмениваться файлами. Перед каждым обновлением необходимо проверить, какая версия используется, требуется ли адаптация структур данных и как можно восстановить предыдущее состояние в случае сбоя.
Во многих индивидуальных приложениях такие процедуры разрабатываются уже на этапе внедрения. Обновления затем распространяются с помощью ручных инструкций, резервных копий и скриптов, разработанных специально для конкретного клиента. С каждой последующей установкой возрастает риск появления различных версий и нестандартных решений.
Поэтому SchallOS рассматривает обновления как системную функцию платформы. По одному и тому же базовому конвейеру обновляются как сама система SchallOS, так и разработанные на базе платформы клиентские решения.
Разработчику не нужно сначала разрабатывать собственную процедуру обновления для нового приложения. Управление версиями, проверка, распространение и ведение журнала с самого начала являются частью общей архитектуры.
Разделение SSC и SSD обеспечивает защиту производственных данных
Возможность обновления напрямую связана с разделением структуры и данных. SSC содержит макеты, формулы, контейнеры функций, определения языка и модель данных приложения. SSD содержит производственные бизнес-данные соответствующей компании.
Поэтому при выпуске новой версии не происходит замена всего приложения, включая все данные клиентов. Вместо этого может быть выпущен новый SSC, в то время как существующий SSD остается в эксплуатации.
Если новая структура требует дополнительных полей, таблиц или изменения форматов данных, для этого выполняются четко определенные этапы миграции. Производственные данные адаптируются к новой структуре под контролем и не заменяются незаметно на другой набор данных.
Такое четкое разделение позволяет продолжать разработку приложений на протяжении многих лет, не прибегая при каждом обновлении к переносу всех бизнес-данных в новый полный файл.
От этапа разработки до выпуска
Не каждое изменение в SchallOS Studio сразу же готово к использованию в рабочей среде. На этапе разработки в программе могут присутствовать предварительные макеты, незавершенные функции или еще не протестированные формулы.
Поэтому связанные между собой изменения сначала фиксируются в сессиях изменений и привязываются к запланированному релизу. Только после проверки и утверждения на их основе формируется опубликованная версия. Релиз может включать, в частности:
- уникальный номер версии
- обновленный SSC
- необходимые переносы данных на SSD
- технические требования
- Зависимости от среды выполнения или адаптеров
- Этапы проверки и тестирования
- Примечания к выпуску
- а также информацию для возможного отката.
Основу для этого обеспечивает уровень документирования. На основе зарегистрированных событий разработки можно автоматически формировать списки технических изменений и понятные инструкции для пользователей.
Таким образом, релиз состоит не только из измененных файлов. В нем также описывается, что именно было изменено, какие требования предъявляются и как следует проверить установку.
SchallOS Control управляет распределением
SchallOS Control обеспечивает оперативное управление обновлениями. В этой системе отображается, какие экземпляры имеются, какие версии были отслежены по install и какие обновления доступны. Перед установкой Control может, в частности, проверить:
- доступен ли целевой объект
- какая версия среды выполнения и SSC используется
- какой адаптер базы данных активен
- можно ли создать подходящую резервную копию
- и выполнены ли все условия выпуска.
Это позволяет предотвратить выполнение обновления на установке, которая не соответствует техническим требованиям или не была должным образом подготовлена.
Кроме того, не обязательно сразу же распространять обновление на все системы. Сначала его можно внедрить в тестовой среде или на отдельных установках. Только после успешного тестирования производится более широкое внедрение.
Для этого можно предусмотреть различные каналы обновлений, например стабильные производственные версии, предварительные версии, внутреннее тестирование или версии, адаптированные под потребности конкретных клиентов.
Идентификаторы и уникальные номера версий
Пакеты обновлений могут снабжаться контрольными суммами и цифровыми подписями. Благодаря этому SchallOS Control определяет, является ли пакет полным, происходит ли он из указанного источника и не был ли он изменен с момента публикации.
Кроме того, проверяется, действительно ли данный релиз относится к данному решению. Новый SSC не должен быть случайно подключен к SSD другого приложения.
Уникальные идентификаторы решений, версии структуры и версии модели данных обеспечивают прослеживаемость состояния системы. Также можно выявить необходимые промежуточные этапы. Например, установка не может быть обновлена напрямую с очень старой версии до самой последней, если предварительно необходимо выполнить миграцию данных.
Резервное копирование, миграция и проверка
Перед структурным обновлением производится резервное копирование текущего состояния. Конкретный способ резервного копирования зависит от используемого адаптера базы данных. Для локальной установки IndexedDB или SQLite требуются иные методы, чем для сервера PostgreSQL.
Затем проводится проверка пакета обновлений, создается новая структура install и, при необходимости, выполняется миграция данных. После активации следует проверка. В ходе проверки SchallOS может, например, контролировать:
- имеются ли все ожидаемые таблицы и поля,
- была ли миграция данных выполнена в полном объеме,
- соответствуют ли количество записей и контрольные суммы,
- и правильно ли выполняются важные функции.
Только после успешного завершения этих проверок обновление считается установленным на версии 1TP12. Простой перенос файлов для этого недостаточен. Решающим фактором является то, что структура, данные и среда выполнения впоследствии вновь должны образовывать согласованное и работоспособное целое.
Откат в случае сбоя обновлений
Несмотря на тщательную подготовку, обновление может завершиться неудачей. Неожиданные старые данные, некорректная миграция или неучтенная зависимость могут привести к тому, что новую версию невозможно будет безопасно активировать. На случай таких ситуаций в процедуру обновления входит откат. При этом восстанавливаются предыдущая версия SSC, сохраненное состояние SSD и предыдущая конфигурация.
Однако не каждое обновление можно откатить на произвольный период времени. Если после установки уже были обработаны новые производственные данные в соответствии с измененными правилами, полный возврат к прежней версии может оказаться затруднительным. Поэтому в релизе должно быть четко определено, при каких условиях возможен откат.
В некоторых случаях целесообразнее выполнить корректирующее последующее обновление, чем восстановить более старую версию данных. Платформа предоставляет технические возможности для этого, однако конкретное решение зависит от характера изменения и его значимости с профессиональной точки зрения.
Даже сама система SchallOS использует этот конвейер
Конвейер обновлений предназначен не только для клиентских решений. SchallOS Studio, Runtime, Control и другие компоненты платформы также обновляются с помощью тех же базовых механизмов. Новые версии платформы могут содержать расширения среды формул, усовершенствования уровня искусственного интеллекта, новые адаптеры баз данных или исправления, связанные с безопасностью. Здесь также требуются номера версий, зависимости, сигнатуры и проверки.
Таким образом, инфраструктура используется и постоянно тестируется в процессе работы самой платформы. Приложения, разработанные с помощью SchallOS, используют те же методы.
Таким образом, разработчик получает не просто теоретически предусмотренную функцию обновления, а конвейер, который является неотъемлемой частью как эксплуатации, так и дальнейшего развития всей системы.
Планируемое направление развития будущих версий
Преимущество конвейера обновлений заключается не только в автоматической рассылке новых файлов. Решающую роль играет объединение таких этапов, как разработка, документирование, резервное копирование, миграция, тестирование и откат, в рамках единого рабочего процесса.
Сама платформа SchallOS и разработанные на её основе приложения используют одну и ту же базовую инфраструктуру. Разделение SSC и SSD позволяет структуре развиваться, при этом обеспечивая защиту производственных данных и их контролируемую адаптацию.
Таким образом, решение, разработанное с использованием SchallOS, с самого начала предусматривает возможность обновления до будущих версий. Именно в случае бизнес-программного обеспечения, которое должно использоваться в течение многих лет, такая возможность обновления является не просто дополнительной функцией, а существенным условием для обеспечения долгосрочной поддержки и надежной работы.
Runtime, Control и Cloud для различных моделей эксплуатации
Среда разработки должна обладать широкими возможностями. Разработчики должны иметь возможность изменять структуры, создавать макеты, редактировать формулы и публиковать новые функции. В то же время при повседневной эксплуатации готового бизнес-приложения эти инструменты, как правило, не требуются.
Поэтому SchallOS разделяет разработку, выполнение и администрирование на отдельные компоненты. SchallOS Studio предназначен для разработки. SchallOS Runtime обеспечивает выполнение опубликованных приложений. SchallOS Control управляет их техническим развертыванием. SchallOS Cloud предоставляет ту же базовую архитектуру в виде централизованно управляемого онлайн-сервиса.
При этом не создаются независимые друг от друга приложения. Все области работают с одними и теми же структурами SSC и SSD. Режим работы задается с помощью развертывания, адаптера базы данных и профиля среды выполнения.
SchallOS Runtime выполняет опубликованные решения
SchallOS Runtime связывает SSC приложения с соответствующим SSD и предоставляет доступ к определённым в нём макетам, формулам и функциям. К среде выполнения относятся, в частности, отображение и управление макетами, чтение и редактирование записей, вычисление формул и пользовательских функций, выполнение контейнеров функций, навигация и управление диалоговыми окнами, многоязычность, а также подключение к предусмотренному адаптеру базы данных.
Однако среда выполнения не содержит автоматически всех инструментов SchallOS Studio. Она не может создавать новые пары решений SSC/SSD и не имеет мастера миграции для решений FileMaker.
Таким образом, развернутое клиентское приложение остается четко отделенным от самой среды разработки.
Профили определяют возможности среды выполнения
Не каждая установка требует одинакового набора функций. Приложение, предназначенное исключительно для конечных пользователей, возможно, должно выполнять только опубликованные макеты и бизнес-процессы. Внутренняя установка может потребовать дополнительных функций администрирования или диагностики.
Для этого SchallOS использует профили времени выполнения и профили возможностей. Они определяют, какими техническими возможностями обладает конкретный экземпляр.
Например, профиль может определять, доступен ли режим макета, разрешен ли импорт или экспорт данных, отображаются ли диалоговые окна администрирования, можно ли изменять локальные настройки или разрешено ли использование определенных интерфейсов.
Эти профили дополняют права пользователей в рамках самого решения. Права пользователей определяют, какие профессиональные действия может выполнять тот или иной человек. Профиль среды выполнения, в свою очередь, определяет, какие технические возможности в принципе предоставляет конкретная установка.
Благодаря этому одну и ту же базовую среду выполнения можно использовать для различных групп клиентов и сценариев применения, не прибегая к разработке отдельной версии программы для каждого варианта.
От локальной однопользовательской системы до серверной среды
Решение SchallOS может развертываться в различных режимах работы. Например, для локальной однопользовательской системы данные SSD можно хранить в IndexedDB. Многоуровневое настольное приложение может использовать SQLite. Для более крупных многопользовательских решений предусмотрена централизованная база данных, такая как PostgreSQL.
Эти модели работы обладают различными характеристиками. IndexedDB подходит, прежде всего, для локальных браузерных приложений. SQLite — это проверенная платформа для локальных приложений и небольших установок. PostgreSQL подходит для централизованных многопользовательских систем с профессиональным управлением серверами.
SchallOS не рассматривает эти технологии как полностью взаимозаменяемые хранилища. Смена адаптера требует контролируемой передачи данных, проверки и, при необходимости, отката. Общая архитектура SSC/SSD гарантирует, что макеты, формулы и бизнес-логика не придется разрабатывать заново для каждого адаптера базы данных.
Настольные приложения и работа в браузере
Решения SchallOS должны работать как в браузере, так и в виде автономных приложений для Windows и macOS. Настольная среда выполнения может более тесно интегрироваться в соответствующую операционную систему, контролируемо использовать локальные файлы и, при соответствующей настройке, временно работать в автономном режиме. Она может хранить данные локально с помощью IndexedDB или SQLite либо обращаться к центральной базе данных PostgreSQL.
В браузере приложение отображается с помощью собственной среды выполнения SchallOS. Для этого не требуется ни сервер FileMaker, ни FileMaker WebDirect. Таким образом, после переноса мигрированное решение FileMaker больше не работает в фоновом режиме на основе файла FileMaker. Макеты, формулы и функциональная логика выполняются в рамках архитектуры SchallOS.
SchallOS Control управляет экземплярами
SchallOS Control представляет собой операционный центр управления платформой. Здесь осуществляется управление тем, какое решение работает на какой целевой системе и какие технические требования к ней предъявляются. Control может, в частности, отображать:
- какие пары SSC/SSD были развернуты
- какая версия среды выполнения — installiert
- какой адаптер базы данных используется
- какой профиль возможностей применяется
- какие обновления доступны
- и когда данная инстанция проверялась в последний раз.
Целью развертывания может быть, например, локальное приложение для Windows, среда выполнения macOS, собственный сервер PostgreSQL, тестовая среда или облачный экземпляр.
Служебные данные, такие как адреса серверов, права доступа к базам данных, лицензии или привязки к локальным устройствам, не должны включаться в переносимый SSC. Они управляются в защищённой конфигурации соответствующего экземпляра.
Подписанные решения и контролируемое распространение
Наличие переносимых контейнеров решений не должно означать, что любое приложение можно произвольно изменять или запускать на непредназначенных для этого системах. Поэтому опубликованные пакеты SSC/SSD могут быть связаны с идентификаторами решений, контрольными суммами, подписями и информацией об экземплярах. При запуске среда выполнения может проверить, не был ли SSC изменен и имеет ли он действительную подпись, принадлежит ли SSD к правильному решению, совместимы ли обе версии между собой и имеется ли действительный профиль развертывания.
В зависимости от модели лицензирования предоставление доступа может быть привязано к экземпляру, серверу, устройству или определенному кругу пользователей. При этом SchallOS Control также управляет необходимыми изменениями, такими как смена сервера, повторная активация или восстановление установки.
SchallOS Cloud как модель предоставления услуг SaaS
SchallOS Cloud предоставляет приложения в виде централизованно управляемого онлайн-сервиса. При этом облако не использует собственный, отличающийся от стандартных формат решения. Приложение, разработанное в SchallOS Studio, можно привязать к экземпляру облака и сделать доступным через браузер. Среда выполнения, база данных, резервное копирование, мониторинг и обновления управляются централизованно. Для разработчиков и клиентов это означает модель SaaS, при которой не требуется заново разрабатывать приложение специально для отдельной облачной платформы.
Принципиальная переносимость сохраняется. Решение можно впоследствии перенести на собственный сервер или в другую поддерживаемую среду, если это позволяют объем данных, функциональные возможности и технические требования. Переход остается контролируемой миграцией, но не требует полной переработки приложения.
Решение может развиваться вместе с вашими потребностями
Новое приложение сначала можно разработать локально и протестировать с использованием небольшого набора данных. Позже его можно развернуть в качестве внутренней среды выполнения, перенести на SQLite или PostgreSQL и, наконец, опубликовать в виде серверного или облачного решения. Таблицы, макеты, формулы, контейнеры функций, переводы и документация при этом остаются частью одной и той же структуры решения.
Не каждый прототип без доработок превращается в масштабное корпоративное приложение. Многопользовательский режим, безопасность, производительность и резервное копирование по-прежнему требуют тщательного планирования. Однако эта платформа позволяет избежать ситуации, когда рост неизбежно влечет за собой полную смену технологий.
Таким образом, Runtime, Control и Cloud объединяют различные модели эксплуатации в рамках единой архитектуры. Приложение разрабатывается один раз, а затем контролируемым образом предоставляется для конкретного использования — локально, на собственном сервере или в качестве SaaS в облаке.
С удовольствием. Я бы поместил этот раздел сразу после главы об ИИ или в качестве дополнения к главе 4. В нём поднимается важная мысль: ИИ не привязан к конкретному поставщику, а рассматривается, как и адаптеры баз данных, в качестве взаимозаменяемой инфраструктуры.
Адаптер ИИ вместо привязки к производителю
SchallOS сознательно отделяет собственно слой ИИ от используемых языковых моделей. Платформа не привязана исключительно к одному поставщику или конкретной среде выполнения. Вместо этого можно настраивать различные адаптеры ИИ и управлять ими централизованно.
Эти адаптеры обеспечивают связь между SchallOS и используемыми языковыми моделями. Благодаря этому сама среда разработки остается независимой от того, отправляется ли запрос к локальной модели или к облачному сервису.
Таким образом, ИИ становится взаимозаменяемым компонентом платформы — аналогично адаптерам баз данных для IndexedDB, SQLite или PostgreSQL.
Централизованное управление в SchallOS Control
Настройка ИИ осуществляется централизованно через SchallOS Control. В этой системе можно создавать и управлять любым количеством адаптеров ИИ. Поддерживаются как локальные модели, так и облачные сервисы.
Локальные модели можно подключить, например, с помощью Ollama или LM Studio. Для многих задач разработки вполне достаточно компактной локальной модели, которая полностью выполняется на собственном компьютере.
Кроме того, можно настроить облачные модели, такие как ChatGPT, Claude или другие совместимые сервисы. Каждый адаптер имеет собственную конфигурацию, включающую, например, учетные данные, конечные точки, названия моделей и другие технические настройки. Благодаря этому создается централизованный обзор всех доступных систем искусственного интеллекта в рамках одной установки SchallOS.
Настроил один раз — доступно везде
Одним из главных преимуществ этой архитектуры является то, что адаптер ИИ, настроенный один раз, используется не только в одном конкретном месте. Как только адаптер настроен в SchallOS Control, он становится доступным для всей платформы. Его можно использовать, например:
- в редакторе формул
- в пределах функциональных контейнеров
- для автоматического ведения документации
- при миграции решений FileMaker
- в Adapter Studio
- или в будущих инструментах разработки на базе искусственного интеллекта.
Поэтому разработчику не нужно повторно настраивать учетные данные или модели. Управление осуществляется централизованно, а отдельные компоненты просто выбирают нужный адаптер.
Подходящая модель для конкретной задачи
Не каждая задача разработки требует одинаковой вычислительной мощности. Для краткого объяснения формулы зачастую достаточно небольшой локальной модели. В то же время для масштабных миграций или сложных задач программирования может оказаться полезной более мощная облачная модель.
Поэтому SchallOS позволяет выбирать различные адаптеры в зависимости от конкретного случая применения. Например, разработчик может установить, что простая документация всегда создается локально, тогда как особенно объемные задачи передаются во внешнюю модель. Это позволяет лучше сбалансировать скорость, конфиденциальность данных и затраты.
Возможность использования в будущих моделях
Развитие в области искусственного интеллекта происходит чрезвычайно быстрыми темпами. Новые модели появляются с короткими интервалами, а существующие системы постоянно совершенствуются. Поэтому SchallOS не привязывается надолго к какому-либо одному поставщику. Решающим фактором является не название конкретной модели, а стандартизированный адаптерный интерфейс.
Благодаря этому впоследствии можно будет добавлять новые локальные или облачные системы ИИ без необходимости изменения самой среды разработки. Такая открытость соответствует базовой архитектуре SchallOS. Как и в случае с адаптерами баз данных, адаптеры ИИ также должны оставаться взаимозаменяемыми, в то время как Studio, среда выполнения и само приложение могут продолжать работать без изменений.
Таким образом, искусственный интеллект станет неотъемлемой частью платформы — независимо от того, какие модели или поставщики завоюют рынок в ближайшие годы.
От миграции FileMaker к независимой программной платформе
SchallOS возник в результате многолетней работы с FileMaker. Многие основные идеи платформы основаны на опыте использования индивидуальных решений в области баз данных и ERP, которые на протяжении многих лет развивались вместе с производственными потребностями компаний.
FileMaker обладает особыми преимуществами в области быстрой разработки. Модель данных, макеты и программная логика расположены рядом друг с другом, изменения становятся заметны сразу, а первые работоспособные решения можно создавать сравнительно быстро.
В SchallOS эта тесная взаимосвязь между разработчиком, данными и пользовательским интерфейсом должна сохраниться. Однако техническая основа будет создана заново. SchallOS использует собственную среду выполнения, собственные контейнеры структур и данных, функциональный уровень на базе искусственного интеллекта, а также собственную инфраструктуру для документации, развертывания и обновлений.
Таким образом, FileMaker остается важной отправной точкой и потенциальным источником существующих решений. Однако для дальнейшей эксплуатации он больше не требуется.
Миграция — это нечто большее, чем просто импорт макета
Готовое решение FileMaker состоит не только из таблиц, полей и видимых масок. Значительная часть ваших предметных знаний заложена в формулах, скриптах, триггерах, связях, списках значений и многочисленных особых случаях.
Эффективная миграция должна учитывать эти взаимосвязи и перенести их в новую архитектуру. Таблицы, поля, связи и макеты при этом можно в значительной степени перенести в структурированном виде. Формулы и пользовательские функции переносятся в среду формул SchallOS или адаптируются.
Что касается скриптов FileMaker, то в первую очередь важно понимать их функциональное назначение. Их можно сохранить в качестве учебного и справочного слоя в фоновом режиме новых функциональных контейнеров. Однако исполняемый код будет перепрограммирован с помощью ИИ в соответствии с архитектурой SchallOS. Таким образом, в новой системе не будет среды выполнения FileMaker. Существующее решение постепенно превратится в самостоятельное приложение SchallOS.
Автономная работа после миграции
После полной миграции ни FileMaker Pro, ни FileMaker Server, ни WebDirect не потребуются. Новое приложение использует SchallOS Runtime, SSC в качестве контейнера структур и SSD для рабочих данных. Формулы, контейнеры функций, многоязычность, документация, журналы событий и обновления предоставляются платформой SchallOS.
В зависимости от требований решение может работать локально, в виде приложения для Windows или macOS, на собственном сервере или в качестве SaaS-сервиса в облаке SchallOS Cloud.
Таким образом, устраняется привязка к одной конкретной проприетарной среде выполнения. Технические зависимости от этого не исчезают полностью — любое современное программное обеспечение требует операционных систем, баз данных и серверных служб. Однако структура, бизнес-логика и данные остаются переносимыми и могут использоваться с помощью документированных адаптеров и способов развертывания.
Новые возможности для разработчиков FileMaker
Для разработчиков FileMaker система SchallOS не должна означать полный разрыв с прежним способом работы. Знания в области моделей данных, разработки макетов и бизнес-процессов по-прежнему остаются ценными.
Прежде всего изменяется подход к реализации программной логики. На смену длинным цепочкам скриптов приходят семантически описанные контейнеры функций. ИИ генерирует исполняемый код на основе заданных задач, параметров и ограничений. Разработчик проверяет результат и по-прежнему несет ответственность за архитектуру и предметную корректность.
Кроме того, больше внимания уделяется истории разработки. Изменения могут автоматически регистрироваться, документироваться и объединяться в релизы. Тот же конвейер обновлений, через который обновляется сама система SchallOS, доступен и для собственных клиентских решений.
Таким образом, работа частично переориентируется с ручного ввода отдельных шагов программы на точное описание, проверку и структурирование бизнес-процессов.
Не только для перенесенных приложений
Миграция FileMaker по-прежнему остается важной составляющей SchallOS, однако это не единственное направление её применения. Новые приложения можно полностью разрабатывать в SchallOS Studio.
В долгосрочной перспективе может быть обеспечена поддержка и других исходных систем. Однако для каждого такого расширения потребуются собственные процедуры анализа и миграции. Различные платформы разработки имеют свои собственные концепции, которые невозможно адекватно реализовать с помощью поверхностного универсального импорта.
Опыт, полученный в ходе миграции с FileMaker, создает для этого основу. Однако основная цель SchallOS заключается в разработке и эксплуатации независимых бизнес-приложений.
Запланированный запуск — осенью 2026 года
Публичный запуск SchallOS запланирован на осень 2026 года. До этого момента основные компоненты платформы будут продолжать объединяться, тестироваться и готовиться к первым производственным сценариям использования. Не все функции, запланированные на долгосрочную перспективу, будут полностью реализованы уже на этапе запуска. Решающее значение имеет надёжное ядро, на основе которого можно будет контролируемым образом развертывать дополнительные адаптеры баз данных, функции искусственного интеллекта, возможности миграции и модели эксплуатации.
Сначала будет Программное обеспечение gFM-NEXT ERP от gofilemaker.de будет опубликовано на новой платформе SchallOS, как ожидается, в сентябре 2026 года. Поэтому запуск платформы разработки SchallOS чуть позже, осенью 2026 года, должен ознаменовать не завершение разработки, а начало практического применения.
Полный жизненный цикл приложения
Проект SchallOS начался с вопроса о том, как перенести существующие решения FileMaker в современную среду. В результате была создана платформа, которая учитывает не только миграцию и разработку, но и документирование, развертывание, хранение данных, обновления и долгосрочную эксплуатацию. При этом Studio, Runtime, Control и Cloud выполняют четко разграниченные задачи в рамках единой архитектуры. Поэтому цель заключается не просто в замене FileMaker другим инструментом разработки. SchallOS призвана объединить проверенную тесную взаимосвязь между разработчиком, данными и пользовательским интерфейсом с помощью переносимых контейнеров, программирования на основе искусственного интеллекта и единой модели эксплуатации.
Отправной точкой служит концепция FileMaker-DNA. Цель заключается в создании независимой платформы, на которой можно будет в долгосрочной перспективе разрабатывать, эксплуатировать и поддерживать как существующие, так и новые бизнес-приложения.
Часто задаваемые вопросы
- Что именно представляет собой SchallOS и чем оно отличается от классического приложения на базе данных?
SchallOS — это платформа для разработки, запуска и управления индивидуальным бизнес-программным обеспечением. Она включает в себя не только таблицы, макеты и функции, но и программирование с использованием искусственного интеллекта, документацию, журналы событий, развертывание и обновления. SchallOS Studio служит для разработки, Runtime выполняет готовые приложения, Control управляет установками, а Cloud предоставляет решения по модели SaaS. Таким образом, платформа сопровождает приложение от момента его создания до долгосрочной эксплуатации. - Для каких разработчиков и компаний предназначена система SchallOS?
SchallOS ориентирована, в первую очередь, на разработчиков FileMaker, компании-разработчики программного обеспечения и создателей индивидуальных бизнес-приложений. Компании, уже использующие решения FileMaker, также получают возможность постепенно перенести свои приложения в независимую среду. Кроме того, новые решения могут создаваться полностью в SchallOS. Для руководителей и лиц, принимающих технические решения, особенно интересно то, что разработка, эксплуатация, документация, обновления и различные формы развертывания организованы в рамках единой платформы. - Является ли SchallOS в основном заменой FileMaker?
FileMaker является важной отправной точкой, но не постоянной технической основой SchallOS. В систему перенимаются проверенные идеи, такие как визуальная разработка и тесная связь между данными, макетами и функциями. Однако среда выполнения, хранение данных, функциональная логика и инфраструктура обновлений создаются самостоятельно. SchallOS может переносить существующие решения FileMaker, но также подходит для новых приложений. После полной миграции FileMaker больше не требуется для производственной эксплуатации. - Можно ли полностью автоматизировать миграцию моего существующего решения FileMaker?
Таблицы, поля, связи, макеты и другие заданные структуры можно перенести в значительной степени автоматически. Однако в случае сложной бизнес-логики требуется дополнительная проверка. Скрипты FileMaker часто содержат смену макетов, глобальные переменные, плагины или особые случаи, возникшие в прошлом. ИИ может анализировать эти процессы и создавать на их основе новые функциональные контейнеры. Тем не менее, комплексное решение должно быть проверено разработчиком и, при необходимости, откорректировано. Миграция значительно сокращает объем ручной работы, но не заменяет глубокого понимания сути приложения. - Что произойдет с существующими скриптами FileMaker после миграции?
Скрипты могут оставаться в фоновом режиме новых функциональных контейнеров в качестве обучающего и справочного слоя. Однако они не будут выполняться без изменений. ИИ анализирует, какую предметную задачу выполняет скрипт, какие поля используются и какие условия проверяются. Затем он программирует новый исполняемый код в соответствии с архитектурой SchallOS. Исходный скрипт сохраняется в качестве исторического источника знаний и может быть учтён при возникновении вопросов или необходимости расширения в будущем. - Что такое SSC и SSD, и почему для решения требуется два контейнера?
SSC содержит структуру приложения, в том числе таблицы, поля, макеты, формулы, контейнеры функций, языки и документацию. SSD содержит производственные данные, такие как клиенты, товары, заказы или счета-фактуры. Оба контейнера взаимосвязаны, но выполняют разные задачи. Такое разделение позволяет создавать новые версии структуры до 1TP12 без необходимости замены всего массива данных. Кроме того, можно изменять способы хранения данных, резервное копирование и модели эксплуатации без необходимости полной переработки приложения. - Какие преимущества дает разделение структуры и данных?
Благодаря этому обновления, резервное копирование и миграции можно осуществлять гораздо более контролируемым образом. Новый SSC можно опубликовать, при этом SSD с данными клиентов останется неизменным. Необходимые изменения структуры выполняются посредством заранее определённых процессов миграции данных. Кроме того, SSC можно проанализировать или передать другому разработчику без раскрытия конфиденциальных бизнес-данных. Также упрощается переход с IndexedDB на SQLite, PostgreSQL или в облако, поскольку не требуется заново создавать макеты и функциональную логику. - Можно ли использовать одно и то же решение как локально, так и на сервере, а также в облаке?
В принципе, да. Решение SchallOS можно запускать локально в браузере, в виде приложения для Windows или macOS, с использованием SQLite, на сервере PostgreSQL или в качестве SaaS в SchallOS Cloud. При этом функционал приложения остается неизменным. Однако различные формы эксплуатации предъявляют свои собственные требования к многопользовательскому режиму, резервному копированию, производительности и администрированию. Поэтому переход осуществляется контролируемым образом посредством передачи данных и проверки. Архитектура SSC/SSD позволяет избежать необходимости ведения совершенно нового проекта для каждой цели. - После успешной миграции мне по-прежнему потребуется FileMaker или сервер FileMaker?
Нет. После полной миграции приложение будет выполняться в среде SchallOS Runtime. Для работы в браузере также не требуются ни сервер FileMaker, ни WebDirect. Прежняя система FileMaker может быть сохранена в качестве справочного материала или архива, но не является обязательным условием для продуктивной эксплуатации. Макеты, формулы, функции, доступ к данным, обновления и развертывание перенимаются SchallOS. Таким образом, для мигрированного приложения отпадают прежние зависимости от среды выполнения FileMaker. - Как искусственный интеллект интегрирован в SchallOS?
ИИ доступен непосредственно в редакторе формул, в пользовательских функциях, контейнерах функций и на уровне документации. Он знает не только текущий вопрос, но и соответствующие поля, таблицы, описания и зависимости. В случае мигрированных решений в качестве исходной информации может дополнительно служить исходный скрипт FileMaker. ИИ может объяснять формулы, генерировать код, анализировать ошибки и составлять документацию. Модели должны оставаться взаимозаменяемыми, чтобы можно было учитывать качество, затраты и конфиденциальность данных. - Действительно ли ИИ программирует код функциональных контейнеров?
Да. Разработчик описывает задачу, параметры, ожидаемый результат и допустимые возможности. На этой основе ИИ генерирует исполняемый код. Этот код остается видимым, поддается проверке и может быть зафиксирован в виде версии. Разработчик может запрашивать изменения, проводить тестирование, а также сравнивать или восстанавливать предыдущие версии. Таким образом, ИИ берет на себя значительную часть работы по программированию, но не несет профессиональной ответственности. Особенно в случае критически важных для бизнеса процессов требования, права и возможные побочные эффекты по-прежнему должны тщательно контролироваться. - Какие возможности предлагает редактор формул?
Редактор формул поддерживает типичные математические, логические и текстовые вычисления, а также вычисления даты и времени. Формулы и пользовательские функции обрабатываются в режиме реального времени и могут быть немедленно протестированы. Начальный набор команд меньше, чем накопленный за долгие годы набор функций FileMaker. Однако среда формул поддаётся расширению. Отсутствующие функции можно добавить или реализовать с помощью собственных пользовательских функций. При этом встроенный ИИ может переносить существующие формулы FileMaker или разрабатывать новые вычисления. - Что автоматически документирует SchallOS?
На структурном уровне фиксируются изменения в таблицах, полях, макетах, формулах и контейнерах функций. На уровне данных можно регистрировать изменения записей, смену статуса, утверждения, импорт и другие бизнес-события. К этому добавляются эксплуатационные события, такие как развертывания, обновления и резервное копирование. Связанные между собой работы по разработке можно объединить в сессии изменений (Change Sessions) и впоследствии привязать к релизу. Таким образом создается понятная история приложения, а не просто набор записей, сделанных задним числом. - Может ли SchallOS на этой основе формировать отчеты по клиентам и услугам?
Да. Встроенный ИИ может на основе зарегистрированных событий формировать техническую документацию, отчеты для клиентов, примечания к выпуску или отчеты о результатах работы. При этом несколько технических изменений можно объединить в одно понятное описание бизнес-преимуществ. Исходные события остаются доступными для просмотра, что позволяет разработчику проверить формулировки. Не каждое изменение подлежит автоматическому начислению. Поэтому выбор, оценка и утверждение окончательного отчёта о выполненных работах остаются за разработчиком. - Как работает конвейер обновлений?
Изменения сначала собираются в сессиях изменений (Change Sessions) и объединяются в один релиз. Релиз может содержать новый SSC, необходимые миграции SSD, предварительные условия, сигнатуры, проверки и информацию об откате. SchallOS Control проверяет целевой экземпляр, создает резервную копию, а затем выполняет обновление. После установки проводится проверка соответствия структуры, данных и важных функций ожидаемому состоянию. Один и тот же базовый конвейер используется как для самой системы SchallOS, так и для разработанных на её основе клиентских решений. - Чем отличаются Runtime, Control и Cloud?
SchallOS Runtime обеспечивает выполнение опубликованных приложений и предоставляет макеты, формулы и контейнеры функций. SchallOS Control управляет экземплярами, адаптерами баз данных, профилями среды выполнения, обновлениями и техническими проверками. SchallOS Cloud предоставляет среду выполнения и хранение данных в виде централизованно управляемого SaaS-сервиса. SchallOS Studio остаётся основной средой разработки. Все компоненты используют одни и те же базовые структуры SSC и SSD, но выполняют чётко разграниченные задачи в рамках жизненного цикла приложения. - Как обеспечивается защита прав, установок и конфиденциальных данных?
Права пользователей определяют, какие функциональные действия пользователь может выполнять в рамках решения. Профили выполнения (Runtime) и профили возможностей (Capability) дополнительно определяют, какими техническими функциями вообще располагает данная установка. Пакеты SSC и SSD можно защитить с помощью идентификаторов, контрольных сумм и подписей. Также можно ограничить контекст ИИ, чтобы не обрабатывались автоматически все данные клиентов. Для особо чувствительных сред можно использовать собственные серверы или, в будущем, локальные модели ИИ. Конкретная конфигурация безопасности зависит от конкретного случая применения. - Когда планируется выпуск SchallOS?
Публичный запуск запланирован на осень 2026 года. В первую очередь внимание будет уделяться Studio и Runtime, разделению SSC и SSD, миграции существующих структур FileMaker, формул, пользовательских функций, контейнеров функций, запрограммированных с помощью ИИ, документации, журналов событий, развертыванию и обновлениям. Кроме того, SchallOS Control будет играть ключевую роль в управлении установками. Не каждая функция, запланированная на долгосрочную перспективу, должна быть полностью реализована уже на этапе запуска. На первом этапе решающее значение имеет надежное ядро для первых производственных приложений.
