Благодарности
Автору статьи из зазеркалья «Профессия 1С:Программист сегодня». Эрику Эвансу за его замечательный труд «Предметно ориентированное проектирование - Структуризация сложных программных систем». Фредерику Бруксу за его «Мифический человеко-месяц или как создаются программные системы». Awk и Comol за посиделки в «курилках». Доржи за возможность публиковаться на Инфостарте. Alraune за её не простой труд. И моей супруге за терпение и понимание.
РЕКОМЕНДАЦИИ
К сожалению, статья получилась сложная, старался как мог, чтобы было проще, но увы.
Статья состоит из двух частей: первая часть содержит очень краткий конспект книги Эрика Эванса,
на мой взгляд должна читаться без затруднений, так как содержит экстракт мыслей, которые и так летают в воздухе.
Подробнее, можно почитать в первоисточнике. Вторая часть содержит описание Виртуальной машины,
которая реализуют идеи первой части на практике. После прочтения первой статьи, стоит сделать паузу.
Не стоит читать урывками обе части одновременно, ибо авторы разные, стиль разный, терминология тоже отличается.
С удовольствием внесу в статьи любые изменения направленные на повышение её читабельности.
ЧАСТЬ ПЕРВАЯ. ПОЗНАВАТЕЛЬНАЯ (Очень краткий конспект*)
1. Введение в 3D структурирование сложных программных систем
Проектирование программного обеспечения - это постоянная битва за простоту. Эрик Эванс(С)
Проблемно-ориентированное проектирование (DDD) (англ. Domain-driven design) — это набор принципов и схем, помогающих разработчикам создавать изящные системы объектов. При правильном применении оно приводит к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит сложная бизнес-логика, устраняющая промежуток между реальными условиями области применения продукта и кодом. (Wiki)
В процессе разработки программного обеспечения хватает всевозможных трудностей. Главное - это естественная сложность предметной области, к которой относится решаемая задача. Всякий раз, когда при разработке программного обеспечения возникает необходимость автоматизировать созданные человеком сложные системы, избежать этой сложности нельзя - ею можно только "овладеть".
Для этого необходима хорошая предметно-ориентированная модель, проникающая значительно дальше поверхностного взгляда на проблему. Если в такой модели удастся правильно отразить внутреннюю структуру предметной области, то разработчики программного обеспечения получат именно тот инструмент, в котором они нуждаются. Хорошая модель предметной области представляет огромную ценность, но построить ее нелегко. Умеют это делать немногие, а научить других этому искусству очень трудно.
Ведущие программисты считали моделирование предметных областей (domain modeling) и проектирование архитектуры программных объектов на этой основе (domain design) ключевой методологией разработки сложных программных систем на протяжении вот уже более двадцати лет. Тем не менее, за это время было написано удивительно мало об основных задачах (что делать) и методах (как делать) этой области знания.
Но, несмотря на отсутствие четкой формализации, в профессиональной среде постепенно "вызрела" система взглядов и подходов, которую я называю предметно-ориентированное проектирование (domain-driven design, ППП).
1.1 Роль и выбор модели
Модель и архитектура программы взаимно определяют друг друга. Именно тесная связь между моделью и ее программной реализацией определяет важность и необходимость самой модели, а также гарантирует, что проделанный при ее разработке анализ отражен в конечном результате, Т.е. в работающей программе.
Связь между моделью и реализацией помогает также в процесс е дальнейшей доработки программы и выпуска ее новых версий, поскольку и сам программный код можно интерпретировать, основываясь на понимании модели. (См. главу 3.)
Модель это дистиллированное знание. Модель представляет собой согласованный между разработчиками способ структуризации знаний из предметной области, а также выделения элементов, представляющих наибольший интерес.
Автор в дальнейшем часто употребляет слово distillation как термин, означающий очищение совокупности информации от всего лишнего, выделение самой сути. Это процесс, издавна лежащий, например, в основе математического моделирования.
Однако в большинстве программных проектов главные приоритеты совершенно другие. Самые талантливые программисты не очень-то рвутся узнать достаточно о той прикладной области, с которой они работают, не говоря уже о том, чтобы усовершенствовать свои навыки моделирования этой области. "Технари" любят четко поставленные в количественных терминах задачи, на которых можно отточить свои технические умения.
А работа с предметной областью - это что-то зыбкое и непонятное; она требует освоения новых сложных знаний, которые кажутся не очень-то нужными для повышения квалификации программиста.
В итоге технический специалист-программист приступает к работе в сложной, обширной, автоматизированной среде разработки, пытаясь решить прикладную задачу за счет развитых программных технологий. Изучение и моделирование предметной области он оставляет другим. Но сложность расчетной части программы не нужно обходить. Избегать схватки означает рисковать, что программа окажется не у дел.
Был запущен процесс переработки знаний, который сделал всю последующую работу эффективной: накопление знаний и разработчиками, и специалистами в предметной области, и другими членами группы; создание основ единого языка; замыкание цепи обратной связи через программную реализацию.
В конце концов, путешествие в неведомое должно с чего-то начинаться.
1.2 Единый язык модели
По крайней мере, так должно быть. Но в самом начале модель может просто не быть готовой к тому, чтобы выполнять все эти функции. Ей может недоставать семантического богатства специализированного жаргона из предметной области. Но такие жаргоны и нельзя там использовать в чистом виде, ведь в них содержатся противоречия и двусмысленности.
Профессиональному языку может не хватать гибкости и активности, вложенной программистами в код - либо потому, что они не считали эти черты частыо модели, либо потому, что программирование носит процедурный характер и отражает понятия модели только в неявной форме.
Может показаться, что возникает замкнутый круг. Но процесс переработки знаний может породить и более качественную модель, если разработчики в достаточной мере привержены единому языку на основе модели. Настойчивое употребление Единого языка обязательно выявит слабые места в Модели, и группа путем эксперимента найдет альтернативунеуклюжим понятиям или соотношениям. По мере обнаружения пробелов в языке будут появляться новые слова. Изменения в языке следует приниматъ как изменения в модели - соответственно группа разработчиков должна вносить изменения в диаграммы классов, переименовывать классы и методы в исходном коде или даже изменять функции программы при изменении значения того или иного термина.
1.3 Проектирование по модели
Проектирование по модели предметной области (model-driven design) ликвидирует разрыв между аналитической моделью и архитектурой, поскольку в ходе него ищется такая модель, которая бы служила обеим целям. Если не вдаваться в чисто технические подробности, каждый объект в программной архитектуре играет концептуальную роль, определенную в модели. Это требует от нас большей придирчивости в выборе модели, поскольку она должна выполнять две совершенно различные задачи.
Если архитектура программы или хотя бы некая ее центральная часть, не соответствует структуре модели предметной области, то такая модель практически бесполезна, и правильность работы программы тоже нужно поставить под подозрение.
Проблема возникает тогда, когда разделяются две задачи, которые согласно принципу Проектирование по модели должны "идти в связке" - моделирование и программная реализация.
Предметно-ориентированное проектирование (DDD) ставит своей задачей применение модели для решения задач, стоящих перед приложением. Посредством переработки знаний группа разработчиков фильтрует (дистилирует) поток хаотической информации и делает из него работоспособную модель. Проектирование по модели (model-driven design) создает тесную связь между моделью и реализацией. А Единый язык является каналом, по которому вся нужная информация расходится между программистами, специалистами в предметной области и непосредственно программным продуктом.
В результате возникает программа, богатые функциональные возможности которой базируются на фундаментальном понимании сути предметной области, Б которой она работает.
Чтобы модель и ее реализация не отставали одна от другой, усиливая эффективность друг друга, необходимо принимать определенные виды решений. Синхронизация модели и программной реализации требует внимания к деталям отдельных структурных элементов программы.
Тщательность проработки в мелком масштабе дает разработчикам твердую основу, на которой можно применять стратегии и приемы моделирования из частей III и IV.
Существует много способов членения программной системы, но по накопленному в программной индустрии опыту и неписаным соглашениям преимущество отдается Многоуровневой архитектуре (layered architecture), состоящей из нескольких достаточно стандартных уровней. Метафора многоуровневости настолько широко распространена, что большинство программистов воспринимают ее естественно, интуитивно.
Разбейте сложную программу на уровни. Внутри каждого уровня разработайте связную структуру, полагающуюся только на нижние уровни и зависящую только от них. Чтобы обеспечить связь с верхними уровнями, используйте стандартные архитектурные шаблоны. Сосредоточьте весь код, относящийся к предметной модели, в одном уровне, и изолируйте его от кода интерфейса пользователя, прикладных операций и инфраструктуры. Объекты предметной области, избавленные от необходимости выводить самих себя на экран, хранить в базах данных, распределять задачи и т.п. ,можно сосредоточить на выражении модели этой области. Это позволяет модели развиться до достаточно сложной и в то же время достаточно понятной, чтобы заключить в себе существенные знания о предмете и эффективно их применить.
Если инфраструктура реализована в форме Службы (Services), вызываемых через
интерфейсы, то многоуровневость и разделение уровней достигается вполне естественно, без принципиальных затруднений. Но некоторые технические проблемы требуют более "навязчивых" форм инфраструктуры. В подобных инфраструктурных средах Frameworks) реализуются в интегрированной форме новые функции инфраструктуры, и одновременно эти среды навязывают другим уровням определенные способы реализации.
1.4 "Антишаблон" интеллектуального интерфейса пользователя (SMART UI)
Подытожим наш разговор о шаблоне многоуровневой архитектуры в объектных приложениях. Разделение интерфейса пользователя, уровня прикладных операций и предметной области так часто пытаются реализовать и так редко достигают этого, что его полная противоположность тоже заслуживает отдельного рассмотрения.
Во многих программных проектах принимается и должен приниматься в дальнейшем намного менее структурированный подход к проектированию, который я называю
интеллектуальный интерфейс пользователя (SMART UI). Это подход, альтернативный предметно-ориентированному проектированию (DDD) и категорически с ним несовместимый. Если принимается именно он, большую часть написанного в этой книге можно выбросить. Меня интересуют ситуации, в которых интеллектуальный интерфейс пользователя неприменим, поэтому я иронично называю его "антишаблоном". Но обсуждение этого подхода создает полезный контраст и помогает прояснить, как и почему выбирается более трудный путь, которому посвящена вся остальная часть книги.
Истинное учение гласит (повсеместно, в том числе и в остальных частях этой книги), что предметная область и интерфейс должны быть отделены друг от друга! Фактически без такого разделения трудно применить какие бы то ни было методы, рассматриваемые в нашей книге далее. Поэтому «SMART UI» можно считать "анти-шаблоном" в контексте предметно-ориентированного проектирования программ.
1.5 Причины доминирования объектной парадигмы
В настоящее время основная парадигма - объектноориентированная. В основе разработки наиболее сложных проектов лежит именно работа с объектами. Объектно-ориентированный подход стал доминировать по ряду причин. Частично сыграли свою роль естественные свойства объектов, частично так сложились обстоятельства, а некоторые преимущества вытекают уже просто из широкой распространенности этой парадигмы.
1.6 Углубляющий рефакторииг
В процессе разработки полезных моделей необходимо понять три истины:
- Создание сложных, хорошо проработанных моделей предметных областей возможно, и они стоят затраченного на них труда.
- Практически не существует другого способа построить такую модель, кроме итерационного процесса рефакторинга с тесным взаимодействием между специалистами предметной области и программистами, желающими узнать о ней больше.
- Реализация и успешное использование таких моделей могут потребовать высокой квалификации в области проектирования и моделирования.
Кроме удобства внесения изменений в код, гибкая архитектура способствует еще и усовершенствованию самой модели. Проектирование по модели (model-driven design) стоит на двух "столпах": пусть углубленная модель делает возможной выразительную архитектуру, но ведь и сама архитектура помогает в развитии предметного знания, заключенного в модели, если достаточная ее гибкость позволяет разработчику экспериментировать, а достаточная наглядность - ясно видеть, что происходит. Эта вторая половина цикла обратной связи весьма важна, поскольку нужная нам модель - это не просто красивый набор идей, а основа работы программной системы.
Сначала рефакторинг - потом наращивание функций
1.7 Процесс познания
Чтобы построить программную архитектуру, хорошо приспособленную к решению прикладной задачи, вначале следует создать модель, которая бы выражала основные понятия (концепции) предметной области.
Медленно, но уверенно разработчики ассимилируют знание и перерабатывают его в компактную форму модели. Углубленные модели могут возникать постепенно, после серии небольших операций рефакторинга, каждый раз выполняемых над одним объектом: здесьоткорректировали ассоциацию между тем и этим, там передали обязанности оттуда туда. Но бывает, что постепенный рефакторинг открывает дорогу чему-то новому совсем не так систематично. Каждое усовершенствование кода и модели открывает разработчику глаза на что-то новое. А ясность восприятия создает потенциальную возможность для качественно нового вывода или идеи. И поток модификаций вдруг приводит к модели, которая соответствует реальности и приоритетам пользователя на более глубоком уровне, чем ранее. Универсaльность и наглядность внезапно возрастают, а сложность при этом куда-то испаряется.
Такого рода скачок - это не стандартный прием. Это событие.
ЧАСТЬ ВТОРАЯ. ПРАКТИЧЕСКАЯ.
|
Поскольку целью проектирования является простота использования, окончательную оценку проекта системы дает достигнутое отношение функциональности к сложности концепций. Ни функциональность, ни простота в отдельности не являются признаками хорошего проекта. Фредерик Брукс(С) |
2. «Виртуальная машина» в рамках технологий 1с
Для обеспечения концептуальной целостности системы необходимо отделить архитектуру от реализации. Один главный архитектор (или небольшая группа), действуя в интересах пользователя, решают, что должно входить в систему, а что не должно. «Очень крутая» идея может быть отвергнута, если предлагаемая возможность не вписывается в общий дизайн системы. Простота очень важна; может быть полезным реализовать только часть возможностей, на которые способна система, потому что если система слишком сложна, часть её возможностей будут оставаться неиспользованными.
Для некоторого заданного уровня функциональности лучшей оказывается та система, в которой можно работать с наибольшей простотой и непосредственностью.
Концептуальная целостность, в свою очередь, требует, чтобы проект исходил от одного разработчика, или небольшого числа их, действующих согласованно и в унисон.
На практике, использование семейства стандартов проектирования информационных систем IDEF и т.п. показало, что тонны документации на выходе таких технологий, приводят к тому, что один человек не в состоянии держать у себя в голове всю модель целиком. Таким образом, назрела необходимость создания некоторой модели, которая просто и наглядно отражает предметную область задач управления предприятием.
О самой модели мы поговорим в другой раз, сейчас хотелось бы акцентировать внимание на некотором механизме, который позволяет умозрительной модели решать практические задачи. Назовем этот механизм «Виртуальная машина». Не смотря, на то что сама учетная модель и виртуальная машина возникли одновременно и взаимно друг друга дополняли, у виртуальной машины появилость свойство проектировать/исполнять любую учетную модель предназначенную для задач управления предприятия. Такое свойство Виртуальной машины позволяет разрабатывать Кейсы – стандартные модели управления/учета. Основным строительным элементом Кейсов являются Картриджи. Картридж представляет из себя форму с основным табличным полем и панелью кнопок. Функционирование картриджей осуществляет универсальная обработка. В состав Кейса могут входить элементы следующих типов:
- Справочник.Картриджи
- Справочник.ВидДокументов
- Справочник.ВидСправочников
- Справочник.Кнопки
- Справочник.КнопкиОтчетов
- Справочник.БиблиотекаЗапросов
- Справочник.События
- Справочник.Шаблоны
2.1 Полезные свойства «Виртуальной машины»
Современный мир стремительно меняется. Если до 21 века смена технологий проходила медленее, чем смена поколений людей, то на сегодня, смена технологий происходит каждые 5 лет, что не позволяет разработчикам совершенствовать собственные инструменты и нарабатывать стандартные шаблоны реализаций. Итак, Виртуальная машина представляет из себя некоторый слой, который содержит/реализует квинтэсенцию знаний, очищенную от ограничений текущего уровня развития технологий. То есть, содержит абстрактную модель предметой области и обеспечивает взаимодействие с пользователем наличными средствами. Такая независимость позволяет эволюционно совершенствовать независимо и параллельно следующие направления:
- Модели предметной области
- Виртуальную машину
- Прикладные конфигурации
- Платформу 1С
Структура виртуальной машины предполагает совместимость снизу вверх моделей предметной области. Сами модели предметной области могут быть экспортированы в xml формате, что обеспечивает достаточную гибкость. Кроме того, виртуальная машина может быть реализована с помощью любых интерпретирующих систем, что значительно расширяет область применения моделей предметных областей далеко за рамками платформы 1с, то есть проявляется свойство кроссплатформенности.
И все же, стандартные возможности 1с, позволяют значительно упростить исходный код Виртуальной машины. Нужно отдать должное, что если бы не 1С 8.х , то возможно, что материализация данной абстракции была бы не возможна.
Свойство функциональной непосредственности, позволяет описывать предметную область на языке заказчика, то есть позволяет в описании задач не выходить за пределы принципов первой нормальной нормы. То есть, описывать и утверждать ТЗ в виде простых таблиц, которые в свою очередь описывают поведение виртуальной машины. Таким образом отпадает необходимость в трудоемком программировании, что существенно снижает количество технических ошибок и уменьшает время на тестирование. Результат работы виртуальной машины свободен от ошибок программиста, что приводит к высокой скорости/надежности разработки. Кроме этого позволяет сократить цепочку на обслуживание с «User - Super key user - Account manager - Team lead - Developer - QA engineer - Account manager - Super key user – User» до цепочки «User - Architect/Developer – User»
Функциональная непосредственность пораждает еще два полезных свойства Самодостаточность и Самодокументируемость.
Виртуальная машина самодостаточна и может расширять свою функциональность за счет все тех же Картриджей. К примеру функциональность типа help-desk, органайзера, управлением почтой, управление Б/П, загрузкой из экселя, анализ действий пользователей входит в состав базового Кейса.
Самодокументируемость позволяет генерировать по требованию как входящую так и исходящую документацию по проекту. Заявки пользователей могут проходить множество различных стадий, в конце концов оседая в корпоративной базе данных в виде FAQ с ссылкой на конкретный объект конфигурации. Выполненные заявки пользователей становятся основанием для «Акта выполненных работ». Документация генерируется по требованию, то есть не обязательно, что хорошо согласуется с принципами Agile.
В целом использование виртуальной машины существенно повышает качество разработки при одновременном увеличении скорости, отменяя принцип «или быстро или качественно». Расширение функциональности не требует обновлений конфигурации и может производиться в режиме «онлайн». Для принятия изменений следует выйти/войти в форму. Виртуальная машина в равной степени ориентированна на потребности всех участников процесса, как на разработчиков, так и на конечных пользователей. Встроенный картридж «help-desk», позволяет не только обеспечить эффективное взаимодействие между программистом и пользователем, в итоге он позволяет оформить финансовые документы по проекту.
Технологичность обновлений заложена в самой идее Виртуальной машины. Имплементированная один раз в типовую конфигурацию Виртуальная машина позволяет превратить процесы обновлений конфигурации и прикладных Кейсов в простые и очевидные операции.
По большому счету именно наличие таких свойств и подтолкнуло автора на пост Ледовое побоище
2.2 Принципы ООП в механизмах виртуальной машины
2.2.1 Классические принципы
Инкапсуляция (лат. in capsula) — механизм языка программирования, предоставляющий возможность обрабатывать несколько единиц данных как одну единицу.
Наследование — механизм языка, позволяющий описать новый класс на основе уже существующего (родительского, базового) класса. Класс-потомок может добавить собственные методы и свойства, а также пользоваться родительскими методами и свойствами. Так как 1С не поддерживает механизма наследования Виртуальная машина реализует собственный механизм наследования/переопределения функций.
Полиморфизм (в рамках данной статьи)- механизм, который позволяет формировать исполняемый код платформы/языка SQL в процессе выполнения.
Виртуальная машина в своих механизмах использует принципы ООП для реализации максимальной гибкости. Если инкапсуляция полностью наследуется от платформы 1С, механизм наследования элементов Кейсов реализуется средствами самой виртуальной машины. Механизм наследования позволяет кастомизировать Кейсы от разработчиков для нужд конкретного предприятия. Команда платформы «Выполнить» позволяет реализовать высокую степень полиморфизма исполняемого кода.
Событийность.
Простота – основная парадигма Виртуальной машины. Кейсы не содержат сложных алгоритмов, кейсы содержат управляющие структуры с инкапсулированными в них обработчиками стандартных событий. Таким образом можно сказать, что виртуальной машиной рулят события.
В принципе – события всегда рулят!
2.2.2 Особые принципы
Поведение «по умолчанию»
Так как документы создаются в информационном окружении Картриджа, а в частности на основании выбранных строк появляется возможность львиную долю информации переносить из контекста. Наряду с возможностью переопределения стандартных событий по условию принадлежности текущего пользователя к той или иной группе, появляется возможность автоматически заполнять реквизиты значениями «по умолчанию». Разработчикам свойственно упускать из виду этот принцип, однако следует напомнить, что именно автозаполнение форм существенно влияет на эргономику приложения. Ключевую роль в адаптации к требованиям конкретного пользователя играют обработчики событий входящие в состав Кейса.
Использование шаблонов
Простота кодирования стандартных обработчиков предполагает наличие готовых шаблонов для решения стандартных задач. Виртуальная машина переориентирует разработчика использовать вместо навороченных библиотек процедур и функций готовые шаблоны стандартных решений.
Независимость
Свойство независимости позволяет легко распараллеливать работы над моделями предметной области. Независимость картриджей гарантирует, что картриджи не влияют на работу друг друга. Картриджи сами по себе не содержат алгоритмов или структур данных. Они на абстрактном уровне обеспечивают интерфейс между пользователем и функциональными элементами: таблицами и функциональными кнопками.
Зависимости
Автоматический анализ зависимостей позволяет прогнозировать поведение модели при изменении её элементов. Все изменения внесенных программистом протоколируются для отражения их в сопроводительной документации.
От простого к сложному
Практически все типовые конфигурации предполагают во время внедрения переход от одной типовой сложной схемы к другой еще более сложной. Существенные доработки влекут за собой массу отказов уже работающих функций. Таким образом, приходиться перекраивать сложные модели, чтобы получить еще более сложную модель.
Картридж типового Кейса является основным строительным элементом системы, учитывая независимость картриджей, их можно безболезненно удалить из системы. В нашем случае из комбинаций простых картриджей можно собрать сколь угодно сложную систему не перегружая её избыточной сложностью.
Мутация объектов
Виртуальная машина содержит стандартные документы и справочники, функциональность которых может расширяться «на лету» дополнительными реквизитами и табличными частями. Современные программные комплексы предполагают огромное число ссылок объектов друг на друга. В случае, если изменение вида документа ведет к удалению старого объекта и к созданию нового, данная манипуляция сопряжена с определенными трудностями при сохранении целостности цепочек ссылок. В случае, когда используются документы-контейнеры, то изменения вида документа не приводят к серьезным последствиям, если новый вид документа не предполагает смену документа-контейнера.
Принцип совместимости
Виртуальная машина включает в себя механизм, который обеспечивает совместимость Кейсов снизу вверх. Развитие функциональности Виртуальной машины не влияет на работоспособность Кейсов, что позволяет разработчику накапливать свой опыт в готовых наработках без затрат на обеспечение совместимости. Работоспособность Кейсов на различных версиях 1С 8.2, 8.3 также обеспечивается на уровне Виртуальной машины. Возможен переход на более низкую версию виртуальной машины, без фатальных ошибок.
Принцип роста
Виртуальная машина берет на себя решение рутинных задач, сокращая количество промежуточных субъектов. Модель Кейса позволяет совместить в одном человеке три роли: программиста, архитектора и тестера. Что позволяет программистам перейти на более абстрактный уровень прикладного моделирования, а архитекторам решать задачи, для которых требовалась специфические навыки программиста. Таким образом, проектирование на базе модели позволяет одному человеку охватить больший объем прикладной области.
2.3 Многослойность «Виртуальной машины»
Итак, виртуальная машина предполагает некоторую многослойность. Слой, который обеспечивает прикладной уровень - будем называть Кейсом.
Модель Кейса полностью реализуется средствами виртуальной машины. В него входят картриджи, функциональные кнопки, кнопки отчетов, виды документов, схема проводок и структура регистров. На базе виртуальной машины можно построить любое количество типовых Кейсов. Адаптация прикладных решений в таком случае происходит не на уровне конфигурации 1С, а на уровне элементов типовых Кейсов.
Модель Кейса полностью реализует функциональность конечного приложения. Требования пользователей полностью фиксируются в рамках информационных структур Модели (настроечных справочников Виртуальной Машины), что позволяет формализовать процесс документирования ТЗ. Сохранив ТЗ в Кейсе приложения, на выходе получаем то, что требовал заказчик, без искажений, который мог бы внести программист при "ручном" кодинге. Таким образом, Виртуальная машина реализует принцип "что заказано, то и сделано!"
2.4 Архитектура Виртуальной машины
Основным строительным элементом Кейса являются Картриджи, которые представляют из себя формы пользовательского интерфейса, которые обеспечивают взаимодействие конечного пользователя с механизмами Виртуальной машины. К примеру, Картридж для оформления сделок может выглядеть следующим образом:
Первый ряд кнопок одинаков для всех картриджей, второй ряд кнопок определяет функциональность самого картриджа. На форме присутствует основное табличное поле, источником данных которого является запрос. В нижней части расположены табличные поля с детальной информацией к текущей строке основного табличного поля.
В данном случае интерес представляют колонки с «Исходящими», «Входящими» письмами и «Делами». Для покупателя "Мальборо" входящих писем 3 шт, причем среди них есть «не прочитанные» (выделение жирным шрифтом). В нижней части на закладке «Переговоры» видна история отношений по конкретной сделке.
Для разработчика полезны кнопки:
«Модуль» - открывает исходный текст и настройки Картриджа
«Кнопка» - открывает исходный текст и настройки последней выполненной кнопки
«Время» - показывает время выполнения последнего запроса.
«Замечание» - запускает диалог оформления замечаний пользователей.
Внутренние механизмы Виртуальной машины обеспечивают сбор данных о времени выполнения всех операций, все нажатия кнопок фиксируются в исторической таблице. Ошибки разработчика протоколируются и оформляются в виде «Замечаний»
В любой момент разработчик может вызвать Консоль запросов, которая позволяет обратиться к истории последних 50-ти выполненных запросов.
Схематично Виртуальную машину можно представить следующим образом:
Фактически универсальный картридж представляет из себя одну обработку.
Практически вся функциональность Картриджа определяется справочником Картридж. Он содержит описания основного и детальных табличных полей; текстов запросов к ним; функциональных кнопок и кнопок отчетов. Картриджи полностью автономны друг от друга. «Стандартные картриджи» обеспечивают взаимодействие программист-пользователь. «Картриджи типового кейса» решают прикладные задачи. На основе любого картриджа можно создать дочку, которая унаследует все свойства своих родителей. Таким образом Картриджи поддерживают механизм наследования и могут перекрывать/дополнять функциональность Картриджей родителей.
Функциональные кнопки в большинстве своем предназначены для создания документов на основе текущих данных основного табличного поля. Нажатие кнопок в реальном контексте текущих данных значительно повышает количество данных, которые можно заполнить «по умолчанию».По сравнению со стандартными механизмами 1С: «При копировании», «ОбработкаЗаполнения» такое решение более эффективно. В целом такое решение обеспечивает уровень заполнения по умолчанию на уровне 95 реквизитов из 100, что существенно снижает энергоемкость ввода данных.
Справочник ВидДокумента содержит описание основных и дополнительных реквизитов документа, что определяет внешний вид документа. Содержит текст обработчиков всех событий, перечень функциональных кнопок и кнопок отчетов. А также содержит схему проведения проводок.
Виртуальная машина имеет несколько стандартных документов-контейнеров: «Заявки», «Сделки», «Заявки на ДС», «Движение ТМЦ», «Движение ДС», «Планы», «Доходы», «Расходы». Мутабельность документа ограничена только типом контейнера, что позволяет в большинстве своем, переопределять виды документов в длинной цепочке бизнес-процессов в один клик.
Дополнительные реквизиты справочников и документов реализуются средствами Виртуальной машины.
Схемы проводок позволяют формировать проводки как для регистров конфигурации, так и для универсальных регистров виртуальной машины. Каждый регистр виртуальной машины имеет измерение «Контур учета», что позволяет неограниченно расширять функциональность прикладного решения без изменения конфигурации 1С.
Справочник БиблиотекаЗапросов содержит тексты всех запросов с параметрами по умолчанию. Доступ к данным реализуется только, через механизм запросов. Не смотря на то, что Виртуальная машина использует возможности 1С по максимуму, прикладное программирование в рамках виртуальной машины использует не больше 5% возможностей платформы. Что существенно снижает трудоемкость разработки и сопровождения. С точки зрения программирования, функциональность Кейсов предполагает разработку простых обработчиков событий. Точнее все программирование сводится к описанию обработчиков событий, реализую таким образом парадигму «Событие – это наше все!»
Не смотря на то, что основная сложность заключена в запросах, удачное сочетание универсальных документов и универсальных регистров привела к существенному упрощению текстов запросов. Простота решений и логичная структура данных Виртуальной машины проявились в синергетическом эффекте, что позволило после рефакторинга сократить количество сторок кода с 80 тыс. до 20 тыс. Виртуальная машина может использоваться как отдельная конфигурация, так и объединяться с типовой.
2.5 Вспомогательные службы Виртуальной машины
Виртуальная машина представляет из себя нечто большее, чем просто инструмент разработчика. Виртуальная машина обеспечивает более эффективное взаимодействие пользователя и разработчика в рамках внедряемого прикладного решения за счет встроенных служебных механизмов, а именно:
1) Управление бизнес-процессами
2) Управление документами пользователя
3) Управление напоминаниями
4) Управление сессиями
5) Управление правами пользователей
6) Управление изменениями Кейсов
7) Управление совместимостью
8) Управление печатью
9) Управление электронной почтой
10) Управление документацией проекта
11) Анализ зависимостей
12) Управление загрузкой экселевских файлов
Системный монитор виртуальной машины позволяет:
1) Перехватывать все SQL запросы и направлять их в указанную консоль запросов
2) Фиксировать все действия пользователей
3) Фиксировать все действия разработчиков
4) Фиксировать все ошибки приложения
5) Фиксировать время выполнения операций
6) Фиксировать время слишком долгих операций
Виртуальная машина позволяет перехватить и передать любой SQL-запрос Кейса в консоль запросов. Виртуальная машина собирает статистику о скорости выполнения запросов, фиксирует ошибки с привязкой к конкретному объекту справочника, документа и т.д. Виртуальная машина сохраняет все действия пользователя связанные с вызовом той или иной функциональности Картриджа, что позволяет проводить функциональный анализ рабочего места пользователя по факту востребованных функций.
Все изменения внесенные пользователем в документ или справочник сохраняются в исторические таблицы с сохранением старого и новых значений.
В состав виртуальной машины входит механизм управления Б/П, управления очередью заданий/напоминаний, что позволяет легко решать задачи оперативного учета вытесняя из эксплуатации экселевские файлы.
В состав «Cтандартных картриджей »входят картриджи, которые обеспечивают взаимодействие с о стандартными механизмами виртуальной машины. К примеру картридж «Почтовый ящик» выглядит следующим образом:
Первый ряд кнопок одинаков для всех картриджей, второй ряд кнопок определяет функциональность самого картриджа. Стандартные механизмы позволяют сортировать, группировать, фильтровать, отбирать по сложному условию любые исходные данные. Событие «ПослеЗагрузки» позволяет реализовать сколь угодно сложное оформление выбранных данных.
Стандартные службы зашиты в структуру Виртуальной машины и не могут быть изменены. Однако «Стандартные картриджи» предполагают возможность адаптации под личные предпочтения конкретного разработчика. Встроенный механизм электронной подписи на основе алгоритма MD5, позволяет фиксировать авторство разработчика.
На данный момент времени работы над созданием конфигурации «Виртуальная машина» близятся к завершению. Результат работы будет выложен в публичный доступ. Интересно было бы получить конструктивные предложения для реализации их в Демо-конфигурации.
