Благодарности
Автору статьи из зазеркалья «Профессия 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, позволяет фиксировать авторство разработчика.
На данный момент времени работы над созданием конфигурации «Виртуальная машина» близятся к завершению. Результат работы будет выложен в публичный доступ. Интересно было бы получить конструктивные предложения для реализации их в Демо-конфигурации.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
А почему: Проблемно-ориентированное проектирование?
(1) qwinter,
Абсолютно правильный вопрос! Это не точный перевод с англ. термина Domain-driven design в статье из Википедии. Правильно «Предметно-ориентированное проектирование»
Ещё одна бесполезная мечта о сферическом кодинге в вакууме. Автор, вы верите, что хотя бы 5% положений вашей, несомненно, умной, проработанной статьи будут применены на практике?
(3) Yashazz,
На самом деле все было с точностью до наоборот, сначала на практике была доказана эффективность идеи, а уже потом она оформилась в виде статьи после знакомства с книгой «Предметно-ориентированное проектирование». Если вы заметили, мои статьи носят в основном теоретический характер, но это только подготовительный этап. Следующая публикация будет содержать dt-шник с CRM системой. Я думаю что после её публикации здесь пропадет смысл публиковать подобное за деньги . По крайней мере Картридж «Холодные звонки» у меня входит в базовую бесплатную версию.
PS. Данная система версии 3.0 радует свыше сотни пользователей на пяти предприятиях. К выпуску готовиться 4.0
(3) Yashazz,
Вы лучше скажите, какие по вашему мнению идеи кодинга в вакууме наиболее сферичны?
Каким образом «Виртуальная машина» (ВМ) позволяет «…неограниченно расширять функциональность прикладного решения без изменения конфигурации 1С.» и в то же время «Виртуальная машина может использоваться как отдельная конфигурация, так и объединяться с типовой.»?
Статья написана цитатами из википедии и т.п. В одной куче как английские термины так и русские, переопределение устоявшихся понятий в рамках статьи. Если это тест на психологическую устойчивость, то я его прошел. Хотя нет, я не все прочитал, а только урывками (не зачет).
Интересно, а что если прогнать через Виртуальную машину Вашу статью…
P.S. Статью надо упрощать, обилие терминов не объясняет, а лишь усложняет общий смысл. Хуже всего когда в одном месте встречаешь дельные мысли и чушь.
а еще лучше приложить код. хоть какой-то. так проще понять
Можно много написать, но в принципе товарищ Yashazz ужё всё сказал в (3). Автору на заметку, в сфере программирования уже достаточное количество времени назад пришло понимание, что создание «идеальных сферических коней» — тупиковый путь. А народная мудрость ещё много лет назад на эту тему говорила «Не торопись выполнять указание командира, может так получится, что через некоторое время всё изменится, и его вообще не надо будет выполнять» — «или ишак сдохнет, или эмир».
PS: Если Элияху Голдратта не читали, рекомендую, толковый товарищ.
Тише-тише… не все сразу!
Ну , статья полезна прежде всего самому автору.
Евгений систематизировал и упорядочил свой опыт и познания.
Ничего дурного тут нет.
У меня вопрос :
а сама платформа 1с является «виртуальной машиной» для проектирования сложных систем ?
Если нет , то замолкаю.
Если да , то «виртуальная машина» от Евгения есть следующий уровень абстрагирования относительно «платформы 1с».
На мой взгляд, тогда не хватает описания ограничений для применения «виртуальной машины» как общего подхода.
На что налетаем , проще говоря ?
я правильно понял, что виртуальная машина упомянутая в статье это некая конфигурация, которая является неким конструктором, с уже готовыми кусками. Что-то вроде как стандартных подсистем, только помимо готовых блоков в ней есть возможность создавать блоки в режиме предприятия пользователем и настраивать их функционал, не залезая в конфигуратор. Тогда это что-то вроде конфигуратора в режиме предприятия.
И у меня вопрос, а зачем оно нам надо? Ведь сама платформа 1С и есть для нас та самая виртуальная машина. И развитие В.М. берет на себя фирма 1С, развивая платформу, а развитие систем берем на себя мы — Специалисты 1С.
Если я что не так понял, то поправьте меня пожалуйста.
(10) Ish_2, во во, у меня те же вопросы возникают))
(11) monkbest,
я правильно понял, что виртуальная машина упомянутая в статье это некая конфигурация, которая является неким конструктором, с уже готовыми кусками. Что-то вроде как стандартных подсистем, только помимо готовых блоков в ней есть возможность создавать блоки в режиме предприятия пользователем и настраивать их функционал, не залезая в конфигуратор. Тогда это что-то вроде конфигуратора в режиме предприятия.
Все вы правильно поняли.
Как по мне 1С пошла по пути усложнения, а не упрощения (надувая щеки). У меня ВМ работает и на 8.1,8.2,8.3 разницы большой нет.
А по поводу ограничений:
1) Как только система «затыкается», всегда есть возможность в обработчике события врубить всю мощь платформы 1С.
2) Cтруктура 7-ми универсальных регистров разрабатывалась 3 месяца. Возможны тормоза из-за универсальности, но на практике, скорость проведения и выборок на порядок выше чем у типовых конфигураций.
(10) Ish_2,
Гипотетически возможны проблемы с безопасностью, но решается просто установкой ограничений по правам на справочники Виртуальной Машины
(6) Yimaida,
Основные объекты имеют префикс ВМ.
Справочники типа «Контрагенты»,»Пользователи»,»Номенклатура» префиксов не имеют.
Общий модуль вмИнтерфейс обеспечивает вызовы стандартных механизмов типовых конфигураций
Объединение выполняется с помощью «поставки» и инструкции «делай раз, делай два».
Что это за книга такая? Яндекс про неё не слышал….
Ждём вторую публикацию 🙂
(19) TODD22,
Она вышла ограниченным тиражом.
(15) Евгений, как по мне этот пост в разы информативнее чем сама статья. Т.е. только теперь мне стал понятен реальный путь ВМ. То, что Вы не перешли на личности из-за моего немного резкого комментария добавляет Вам чести. Я вот в институте до определенной поры никак не мог понять почему мне сначала читают 2 месяца лекции и только потом я делаю лабораторные работы. Ведь в жизни все было иначе (сначала был опыт, потом его повторили несколько раз и только потом оформили в теорию с кучей умных фраз и терминов). Когда я это понял, я по другому стал воспринимать эту академическую «воду». Ну вот объясните мне, зачем Вы написали такую «тяжелую» статью? Зачем поменяли местами причину и следствие?
(18) Эти цитаты я привел как пример противоречия. Т.е. я понял, что для работы ВМ надо объединять с типовой конфигурацией (УТ, БП, ЗУП)…
Давайте ка тут поподробней, я не оспариваю личную ценность вашей статьи, но вот в этом комментарии утверждение что ERp чушь не хватает конкретики.
Итак вопрос 1 Верно ли утверждение что в ERP(УПП 2.0) нет модели(нескольких моделей) ?
Вопрос 2 Что вы подразумеваете под словом «модель» в конфигурациях 1с ?
Вопрос 3 Все ли, не имеющее модели, это чушь ?
Спасибо
Да я с нетерпением жду «коня», если не сложно, дабы так сказать быть конструктивным, примеры его использования вы описали, весьма интересует решение отличное от шаблонных.
(6) Yimaida,
Соглашусь в одном. Написано много, а понятно едва ли 5%.
Остались не отвеченными вопросы:
1. Как конкретно это расширять? где и что добавлять, чтобы расширить функционал?
2. Это БСП? Будет ли описание технологии внедрения в типовые?
3. Вообще что это?
4. Для чего это?
Статья оставляет слишком много вопросов. Боюсь без конкретного решения… Надобно пощупать ВМ тогда вникать в теорию.
Тоже жду эту легендарную ВМ 🙂
Конвертация данных или СКД произвели качественный скачок в эффективности разработки во многом благодаря абстрагированию различных уровней и уменьшению связности между уровнями, может и тут что-то подобное произойдёт. В любом случае нужно посмотреть «живьём».
Оххх…. Фундаментально. Дочетать не смок, многа букаф (С)
А нельзя ли короткое резюме — про что там столько написано?
(22)Ну вот по-тихонечку статья обрастает комментариями…
Про чушь я имел в виду, наличие в одном месте обилия терминов, которые порой не вяжутся между собой. Т.е. оперировать «умными» терминами на самом деле опасно, т.к. их смысл не всегда явно описан (в литературе и т.п.) и тем более не всегда воспринимается так же как их воспринимает автор (т.к. сказать проекция…). Конечно, при желании, тут тоже можно найти пользу от прочтения, т.к. лишний раз напрягаешь мозг.
Моя основная претензия к статье касается только лишь формы изложения, которая мне сразу напомнила курсовую работу которую оформили на скорую руку. Не понятно где собственные мысли, а где заимствованные. Особенно это режет ухо при обобщениях типа » Если до 21 века смена технологий проходила медленее, чем смена поколений людей, то на сегодня, смена технологий происходит каждые 5 лет» или «Истинное учение гласит (повсеместно, в том числе и в остальных частях этой книги), что предметная область и интерфейс должны быть отделены друг от друга!»
(25) Makushimo,
Справочники вмКартридж, вмКнопки, вмКнопкиОтчетов, вмСобытия, вмБиблиотекаЗапросов, вмВидДокментов
содержат управляющие структуры, тексты обработчиков событий и запросов.
Если судить по решаемым задачам — да! Только появилась гораздо раньше.
Это одна подсистема, внутри которых реализованы спомогательные службы
протокол действий пользователей/разработчиков
диагностика запросов
мониторинг производительности
загрузка из экселя
управление сеансами
управление правами
и т.д.
Однозначно!
Считайте Мета-Конфигуратором (С)33lab
Для существенного повышения производительности труда.
Раньше я любил слушать музыку, когда приходилось много кодить )))
Сейчас уже 3 года не тянет, по тому, что все задачи творческие,
иногда даже накрывает волной от потока не стандартных задач. Раньше такого не было.
Честно говоря, я искренне не понимаю темы фрилансерства, активно обсуждаемой на соседней ветке.
Один обученный человек принципам работы ВМ стоит сотни фрилансеров.
По крайней мере 3 человека за 3 года создали систему, которая выдержала «наезд» крупной фирмы франчайзи с готовым отраслевым решением по УПП.
(30) Yimaida, Говорят, что умными терминами оперирует тот — кто хочет казаться умным. А тот кто хочет что бы его поняли — объясняет простыми словами.
(30) Yimaida,
Понял, учту на будущее… в следующий раз постараюсь быть короче и конкретнее 😉
(13) Для де-юро нужна команда.
(32) awk,
😉 Есть такое мнение.
На самом деле хотелось создать на ИС цикл хорошо структурированных перелинкованных связанных статей. Щас такой идеи уже нет, а привычка осталась. На самом деле я в большей части пишу для себя, собираю вместе разнородную информацию, переосмысливаю. У меня в черновиках лежат десяток статей, даже публиковать не буду. Пойдут на запчасти.
По емкости и содержательности мне очень понравился пост Ish_2 (10) после него мысли «перестроились» на другой лад.
(34) awk,
Для команды нужны деньги.
Для денег — бизнес ангел.
Для бизнес ангела нужна рабочая идея )))
(27) zqzq,
благодаря абстрагированию различных уровней и уменьшению связности между уровнями, может и
тут что-то подобное произойдёт.
Так и происходит. Для меня темы конвертации данных и СКД потеряли актуальность, у меня получилось еще проще.
В СКД 1с смешала механизм извлечения данных и отображение их в одном флаконе, что привело к значительному усложнению механизма.
У меня справочник вмБиблиотекаЗапросов содержит источники данных, а вмКнопкаОтчета содержит очень простую процедуру формирования отчетов, шаблоны таких процедур лежат в справочники вмШаблоны. Результат помещается в отчет.вмОтчет, который обеспечивает мааааасу сервисных функций для пользователя. Программист, имея права, в любой момент времени попадает в соответствующий объект управления вмКартриджа,вмКнопки,вмКнопкиОтчета,вмБиблиотекаЗапросов.
Моя система может использовать СКД, но за последний год ни разу этой возможностью не воспользовался. Ибо все гораздо проще получается.И что самое главное, пользователь ооооочень доволен, ибо СКД-шные навороты его пугают
Мне кажется 1С пошла правильным путем ибо ооооочень не хватает в 1С объекта типа VIEW c параметрами.
Всем огромное спасибо!
Теперь я знаю, что войдет в Демо-конфигурацию
Видимо описание придется разложить на четыре простых статьи
1) Структура Виртуальной машины
2) Очень простой Кейс CRM — системы
3) Описание принципов ABC/XYZ анализа (ну уж больно руки чешуться)
4) Описание вспомогательных служб Виртуальной машины
(вероятно придется разбить на маленькие статейки для удобства обсуждений)
ОК?
Если у кого остались вопросы — готов на них ответить, если мои ответы можно будет уложить в один абзац.
Остальные ответы войдут в цикл статей.
(36) Не вполне.
1. Часть команды можно приобрести за «причастность к идее»
2. Деньги можно достать пожертвованиями и рекламой.
3. Для рабочей идеи надо вынести черновую на обсуждение хотя бы закрытой группы.
(38)
В Демо конфигурацию нужно вложить то что на практике можно взять сразу и использовать.
Например не простой кейс по CRM а продвинутый. Про виртуальную машину вообще не слова. Нужен продукт а не его реализация. Сама по себе виртуальная машина никому на данном этапе не интересна по той причине что не понятно что с ней можно делать. А вот если показать на ней реализованное хорошее рабочее приложение. То это уже может дать импульс к развитию. Опять же люди потянутся.
А если предложить людям развивать просто ВМ ну это тогда надо показать как и что. Но кто этим будет заниматься? Люди все занятые. У всех работа. Сферическую виртуальную машину в вакууме разрабатывать мало кто возьмётся. А вот система CRM на виртуальной машине может быть интересна. Хотя это лишь моё мнение….
Но всё же я бы шёл от продукта. И от того что получит в итоге конечный потребитель. Всё остальное лишь средство.
(40) TODD22,
Я уже это понял )))))))) согласен на все 100%
(39) awk,
2. Деньги можно достать пожертвованиями и рекламой.
3. Для рабочей идеи надо вынести черновую на обсуждение хотя бы закрытой группы.
Вы читаете мои мысли 🙂
более, того в следующей статье я планирую четко описать структуру конфигурации,
чтобы каждый мог определиться, какую тему ему интересно развивать.
Я думал на счет Краудфандинга (по примеру Kickstarter), было бы клево, если бы ИС стал гарантом в этом деле.
Группа создана еще 14.07.2013 23:58
Добро пожаловать!
А вообще мощно было бы замутить бесплатный облачный сервис для нужд здравоохранения на средства фарм-компаний,
вот польза то была! В Израиле такая система позволяет бороться с очередями на прием к врачу.
(42)
Можно проще. Качественный модуль CRM работающий в паре с БП 3.0. Уже было бы интересно и востребовано как мне кажется. И потенциально аудитория большая.
вот польза то была! В Израиле такая система позволяет бороться с очередями на прием к врачу.
Не знаю чем такая система реально помогает бороться. Работал в поликлинике. Делали электронную очередь. Само по себе отсутствие или наличие такого сервиса проблемы очередей не решают. Это как в супермаркете если на кассе сидит один кассир то ты ему хоть супер облачную систему поставь на деньги всех фарм-компаний это ничего не изменит. Кассир так же будет обслуживать одного человека за определённое время.
И есть ещё моменты связанные с психологией людей. Дело в том что когда ты заболел ты не лезешь в интернет в саас сервис и не записываешься на приём. А хочешь что бы тебя приняли именно сегодня и что бы ждать поменьше. А есть ещё экстренные(высокое давление, температура, острые боли, это не считая травм и тд) их нужно принять сразу… так что такая система по сути является электронным расписанием врачей. Но основных проблем не решает. Ещё есть проблема когда люди приходят не в назначенное им время. Записался на 15.00, пришёл в 13 дня и хочет пройти по живой очереди. И таких умных набегает за день 5-6 человек. И это в очень маленьком мед центре…. я представляю какая каша в крупных мед центрах. А если пациенту давать самому возможность записываться то это вообще жесть. У тебя будет записываться в день по 30 человек. А реально приходить из них 2-3… В итоге твоя система будет просто не жизнеспособна.
По большей части проблема очередей в больница продиктована новыми нормативами от минздрава. То есть нужно увеличивать количество врачей которые ведут приём. А они уменьшают время одного приёма. Что бы врач за одну смену принимал больше людей. Вот и представь как они работают… Если реально норматив на приём 5-7 минут у врача травматолога.
(43) TODD22,
Неееее вопрос, если вы поможете с адаптацией, это будет шагом номер 2. Я живу на Украине и у нас актуальна другая конфа. Хотя я смотрю как у нас на фирме используется моя CRM-ка, так она очень даже ничего поживает как отдельная конфигурация.
(44) TODD22,
Это точно, здесь нужна комплексная гос. программа. Но все равно у Израитян, есть чему поучиться. У меня друзья переехали из Израиля в Канаду, говорят здравоохранение там — совок совком. Другой друг работает в Харьковской компании, которая удаленно обслуживает американское здравоохранение — это просто кландайк, 80 человек загружены работой по уши! (причем 90% это загрузка данных)
(28) Evil Beaver,
Очень коротко о ВМ:
1)По назначению — Позволяет увеличить одновременно и скорость и качество внедрений.
2)По аналогам — Можно сказать, что является аналогом БСП, но легче, гибче и проще.
3)По способу управления — Можно сказать, что эта Мета-Конфигуратор, объекты которого хранятся в справочниках
вместе с текстами запросов и обработчиков событий.
(29) Ну, в общем понятно, теперь только осталось дождаться вашего «коня» дабы так сказать проверив его в боевой ситуации,начать исторгать потоки радуги.
(45)
Ну покажи что за CRM. Может и найдутся желающие поучаствовать в адаптации.
(48) AlexSunS,
)))))) Если, бы слышали, что сказал по поводу восторга своих сотрудников работающих в программе руководитель отдела продаж, в узком кругу — известный пошляк 😉
Мне ваше определение больше нравиться )))))
(49) TODD22,
Сейчас CRM обкатывается у нас на фирме. Даст бог, на следующей неделе начнется внедрение в российском филиале.
(У них прайс считается, не от закупочных, а от продажных цен)
Потом я планирую «подарить» конфу другу, он занимается продажей автозапчастей. Потом выложу результаты сюда.
А пока суть да дело — отшлифую виртуальную машинку.
Если интересна тема, можете присоединиться
Планируется ли использование бизнес процессов с возможность конструирования в режиме 1с?
Я так понял в системе один универсальный документ?
(52) apextrofimov,
Да, причем старт бизнес процессов инициирует внутренняя/внешняя сделка. Сделка не может быть закрыта, если не закрыты
все её бизнес-процессы. Концептуально механизм готов, практически реализованы только самые простые его части.
ВМ версии 3.0 обслуживает фирму, которая в первую очередь оказывает услуги населению. Восемь основных информационных потоков
пронизывают 5 различных отделов. В итоге документ «Заявка» реализует около 950 различных схем имея около 120 различных реквизитов.
ВМ версии 4.0 будет содержать специализированный механизм управления Б/П. На эту тему выйдет отдельная статья, черновик готов,
но сейчас мне не хочется отвлекаться от главной темы.
(53) AlexanderKai,
Когда-то в спорах с разработчиком экономической модели Кустовым М.Г. мы пришли к выводу, что теоретически можно обойтись одном документом и одним регистром, то есть свернуть всю модель в точку. Но практически количество накопительных регистров в системе соответствует четырем видам ресурсов:
1. Деньги
2. ТМЦ
3. Обязательства по Деньгам
4. Обязательства по ТМЦ
оборотных регистров три:
1. Доходы
2. Расходы
3. Планы
И один накопительный регистр для отражения Статусов Б/П.
Универсальных контейнеров-документов 7 шт:
1. Заявка
2. Сделка
3. Движение ДС
4. Движение ТМЦ
5. Планы
6. Доходы
7. Расходы
(56)
По поводу регистров согласен, но документ же может быть один. Тем более есть некие схемы проводок. Формы документов как я понял генерируются тоже на основании схем.
То есть я пока не понимаю, зачем было сделано разделение на 7 видов.
p.s. Бухгалтерский учет берут на себя регистры накопления?
И очень интересно как регистры расширяются, допустим если нужна дополнительная аналитика.
(57) AlexanderKai,
То есть я пока не понимаю, зачем было сделано разделение на 7 видов.
Если, интеллектуальные способности позволяют, можно и в один документ «Сделка» все уложить.
Лично меня, слишком высокие уровни абстракции напрягают.
К тому же, такая классификация «включает» мозги в нужном направлении.
Они его расширяют. В принципе все 7 регистров можно уложить в один бухгалтерский, но тогда возможны сильные тормоза.
Все регистры имеют измерение КонтурУчета, которые позволяет конструировать новые уровни оперативного/управленческого учета.
В остальном, регистры статичны, дополнительная аналитика подтягивается через Регистратор с помощью ЛЕВОГО СОЕДИНЕНИЯ
(автор подсистемы «Инструменты разработчика») уже в 2008 году активно внедряла
свою ВМ в крупные холдинги. Но их ВМ являлась собственностью компании и, на сколько мне
известно, не продавалась и не публиковалась.
К стати, «Инструменты разработчика» на сколько я помню распространяется по принципу Donate.
Мне кажется наши разработки могут дополнить друг друга.
такие фундаментальные работы должны как-то выделяться среди прочих на ИС и 1 голос должен быть равен минимум 3-м обычным плюсикам.
Вообще ИМХО на ИС хорошо было-бы как-то делить плюсики по «фундаментальным» работам и прикладным решениям.
(60) MarSeN,
Спасибо, на добром слове 🙂 Но мне кажется, пора переходить к практике и все станет на свои места.
(56) Не ново. Само не взлетит. К подобной системе, как ко всем таким гипер-универсалам, должен прилагаться талантливый, почти гениальный методист-внедренец, чтобы использовать возможности хотя бы наполовину. Иначе, хоть обпишись шаблонов, кейсов, чего угодно — будет бесполезная вещь. Проверено многократно.
Я такой универсальчик, с одним документом и эмуляцией бухрегистров через накопления, наблюдаю давно у одного своего клиента, и скажу вам — кабы не толковые ведущие пользователи, был бы карачун или я бы сидел там постоянно. При быстро меняющемся учёте даже универсал позволяет выкрутиться только с очень нехилым напильником.
(63) С умозаключениями в целом согласен, но в изложенную практику верится слабо — впрочем, вероятно, вопрос везения. Потому что видел я случаи, когда трижды крутая техподдержка и многотомье мануалов ситуацию не спасали никак. Ну и административный ресурс, да. Без него и отличный проект будет мертворожденным, а с ним и кривая конфа заработает «на ура».
Интересная и довольно проработанная идея. Но, увы, принципиальную задачу — победить сложность — не решает, а переводит ее на другой уровень, еще точнее — откладывает на время. До того момента когда много-много связанных кейсов не станут содержать много-много связанных картриджей и контроль над сложностью, в очередной раз, будет утерян. К сожалению, после этой критики какого-то конструктива (типа — а что вы предлагаете делать?) озвучить не смогу, ибо «серебряная пуля» до сих пор не найдена. И данная «виртуальная машина» также не является ею, но как технологию, как направление, которое сможет предложить более эффективное решение ряда реальных проблем, полагаю, использовать ее вполне можно.
Yashazz
(64) Yashazz, Большое спасибо вам за комментарии, они позволили, как мне кажется, раскрыть очень сложную тему.
По крайней мере, на данный момент все цели данной публикации достигнуты.
Та, да… везение в этом деле ключевой вопрос.
Потому что видел я случаи, когда трижды крутая техподдержка и многотомье мануалов ситуацию не спасали никак.
Ну и административный ресурс, да. Без него и отличный проект будет мертворожденным, а с ним и кривая конфа заработает «на ура».
На этот счет у меня есть следующие соображения:
Если говорить о внедрении, то:
Идеальное внедрение = Идеальный продукт + Идеальный заказчик + Идеальный исполнитель.
В реальности мы имеем далеко не идеальный продукт, внедрение которого кривыми ручками Зачазчика/Исполнителя связано с серьезными рисками. Скажем так, что хороший продукт значительно повышает вероятность положительного исхода, но не спасает от кривых ручек Зачазчика&Исполнителя.
Обычно косяки кривой конфы закрываются админ. ресурсом со стороны заказчика. «На ура» в этом случае наблюдается только с высоты птичьего полета. В принципе, хорошие результаты внедрения могут быть обеспечены либо идеальным исполнителем либо идеальным заказчиком. Судя по вашим комментариям вас можно отнести к опытным (идеальным) Исполнителям 😉
По поводу Админ. ресурса хотелось бы сказать, что сам по себе он ничего не решает, но формирует вокруг себя команду и «культуру» управления. У меня бывали случае, когда применение административного ресурса было равносильно ковровым бомбардировкам, когда убивался наповал не только энтузиазм сотрудников, но и включались мощнейшие механизмы скрытого/открытого саботажа со стороны рядовых исполнителей.
Мне больше по душе термин Авторитет. Обычно благодаря его экспертным знаниям, лидерским качествам и опыту все становиться на свои места.
Вам большое спасибо, за ваше авторитетное мнение.
(65) o.nikolaev,
а переводит ее на другой уровень, еще точнее — откладывает на время.
Стопудово!!! Такая проблема существует — она у меня постоянно в фокусе внимания. Для надежности мысленно окрашу её в красный цвет,
чтобы не ушла на задний план.
ЦИТАТА
До того момента когда много-много связанных кейсов не станут содержать много-много
связанных картриджей и контроль над сложностью, в очередной раз, будет утерян.
Я думал на этим, по этому Кейсы не будут связаны, а будут самодостаточны. Картриджи не связаны между собой.
Кроме того, механизм наследования для картриджей будет реализован для галочки. Практика показывает, что
клонирование (типа копирования, с переопределением источников данных) гораздо проще и очевиднее. А вот наследование
видов документов и пользовательских событий, наоборот упрощают проектирование/программирование.
Подробнее расскажу на практическом примере.
ибо «серебряная пуля» до сих пор не найдена.
Ваша конструктивная критика ляжет в основу «антидота» понижающего степень сложности системы.
более эффективное решение ряда реальных проблем, полагаю, использовать ее вполне можно.
И я того же мнения, хооооотя, для начала хотел ограничиться «простым» CRM-кейсом, теперь думаю ограничиться «примитивным»
Спасибо за патроны!!!
Мне больше по душе термин Авторитет. Обычно благодаря его экспертным знаниям, лидерским качествам и опыту все становиться на свои места.
Именно так! Целиком поддерживаю.
Спасибо на добром слове, но в большинстве случаев это была моя жена:
(68) Yashazz,
Коган 😉 Я уже успел заметить, что это у Вас Семейное
(29) про наличие модели в типовых решениях хочу сказать следующее. Помимо автоматизации управленческого учета его всегда приходится мирить с регламентированным и тут все модели сыпятся. Дело в том, что наши законы пишутся не по модели, а хаотично по результатам лобби тех или иных структур. Лобби нельзя систематизировать, каждой отрасли плевать на структуру законов в целом ему нужно пропихнуть свою поправку в законопроект. Отсюда система учета начинает обрастать хреновой тучей отклонений и исключений. Законы пишут не программисты, а политики, поэтому там главное не логичность и структурированность, а достижение собственных интересов с помощью новых формулировок в законе в конкретном частном случае. А программистам потом этот миллион частных случаев собери в единую систему.
Если бы учет регламентировался законами согласно некой общей модели, то типовые решения были бы гораздо структурированей.
В ERP системи надо ужить кучу систем учета и законов: уравленческий учет принятый на предприятии (который всегда обладает уникальными особенностями предприятия), правила бух учета, налоговый учет, трудовой кодекс, куча законов касающихся конкретной сферы деятельности…
В полноценной ERP системе не может при наших законах быть единой модели, это всегда компромис.
(0) спасибо за статью!
только такой фарш знаний, в хорошем смысле слова, сложно воспринимается при чтении.
и без подобного опыта конфигурирования на платформе 1С 8.1,8.2 сложно понять о каком новом ноу-хау идет речь.
личное: если бы не описал свой опыт в статьях
, я бы не понял о каких виртуальных машинах вы пишите, о каких контейнерах.
Вообще платформа 1С уже сегодня позволяет пользователям-бухгалтерам не знать что такое «проводка», но качественно использовать учетную программу, а программистам-разработчикам программировать без изучения основ теории и идей выше рекомендуемых вами книг. Поэтому с точки зрения юзабилити я сам лично искал начинку вашей реализации. Что-то увидел. Побольше примеров хочется 🙂
Неплохая конфигурация получилась в виде контейнеров, подобных вашим — «1С: Конвертация данных».
Переход на платформу 8.3 будет трудоемким, хотя из своего опыта считаю, что если ваша разработка решает задачи клиентов, то не придется переходить.
(70) monkbest,
Вы затронули очень интересную тему!
Это по причине того, что разработчики очень любят в одном документе лепить три галочки учета: «налоговый»,»управленческий»,»бухгалтерский». В реальности информационные потоки могут не совпадать, особенно, когда подключается еще и «оперативный» учет. Работа с моделями позволяет слегка разрулить ситуацию: регламентированный учет отдельно, управленческий отдельно, оперативный отдельно.
С другой стороны вы абсолютно правы — проблема кроется в мутной воде законодательства. В узких кругах уже сформировалось мнение, что реально нужно три налога:
налог с оборота,
налог с з/п (единая социальная страховка),
налог на землю.
Налог на прибыль и НДС — это от лукавого.
Три налога прекрасно ложатся в бизнес модель предприятия, что позволяет объединить не только бухгалтерский и налоговый учет, но и стандартизировать управленческий. Такое упрощение позволит дать мощный стимул экономике, а заодно снизит уровень коррупции.
По большому счету, если взять за основу принцип изложенный в статье с одной стороны и концепцию собственного капитала, как механизм контроля за ресурсами, с другой стороны, то план счетов можно сократить до 20 счетов, что в конечном итоге приведет к тому, что людей понимающих, что реально происходит на предприятии должно увеличиться на порядок.
(15) написали бы это вместо первой части — вышло бы интересней, если утрировать, то сюжет с «погоней и преследованием» захватывает сильнее, чем «ООП и ПОП» 🙂
и еще, вы молодец!
Свою внутреннюю мотивацию мне пришлось выложить под давлением комментариев, ибо это уже слишком личное.
(71) Rustig,
Тема интересная, мысли летают в воздухе… похоже, что придется потратить время и причесать свои мысли по этому поводу в отдельной статье.
Спасибо вам огромное! В свое время запали в душу слова Eugeneer (11,16,17), но потом так и не смог их найти. Мне кажется, что разработчикам нужно делиться не программами, а чистыми идеями. Тогда толковый программист быстро размножит вашу идею по всему миру.
Упор нужно делать не на продажу ПО, а на предоставление качественных услуг.
(но это уже моя интерпритация)
(72)
налог с оборота,
налог с оборота — это о каком обороте идет речь? оборот обязательств или денежных средств? то есть, допустим я дилер (промежуточное звено между заказчиком-покупателем и поставщиком товара), если обязательство поставить товар заказчику возникло в январе — например по договору + оплачен товар заказчиком в январе, товар поставлен мною заказчику в июне согласно договору, закуп мною товара у поставщика оплачен вообще в сентябре, а государство требует оплатить «некий налог с оборота», то каким месяцем налог будет квалифицироваться (начисляться), а может быть кварталом?
(75) Rustig,
Месяц, квартал — это уже вопрос деталей. Но оборот должен оцениваться по движению ДС, ибо с чего платить, если денег еще нет? Брать налоги с обязательств — это от лукавого. К тому же денежный поток легко учитывается. Деньги они либо есть, либо их нет. А фиктивных обязательств я вам нарисую целый вагон и маленькую тележку.
А в каком состоянии проект на сейчас?
(77) CheBurator,
На данный момент времени нам удалось переманить на наше предприятие идеолога учетной системы Кустова М.Г. в статусе зам. директора. Если все пойдет по плану, через год можно будет подвести итоги. На данный момент данная система не является целью, скорее она побочный продукт реструктуризации предприятия. В сентябре закончили картридж «Управления проектами», чтобы можно было системно развивать предприятие в рамках ограниченных финансовых ресурсов.
Евгений, планируете продолжение писать? группа которую вы создали пустая. А тема интересная 🙂
(79) stoptime,
Как это пустая? там 15 человек… не пугайте меня…фууух, а то я грешным делом подумал, что после очередного абдейта группа опустела. Продолжение планируется… но дело в том, что ВМ не является целью, а скорее всего побочным продуктом развития одной фирмы. По этому… планы есть, но они в перспективе. Сейчас занимаемся разработкой сайта на cms wordpress. В диком восторге от простоты решений. Движок wordpress — очень напоминает мою виртуальную машину. Жаль, что здесь не пропустят публикацию по этой теме. Ну разве, что в сравнении с 1С.
Только сравнивать нечего, как по мне, не нужно было 8.3 городить, нужно было сделать конфигурации более управляемыми, а web направление развивать на 8.4… ну или на худой конец 9.0.
(80)
Всегда думал, что вордпресс — это максимум блог с некоторыми интерактивными фишками и что на большее он не потянет.
Уважаемый ТС!
Повторю вопрос, заданный (77) CheBurator, :
А в каком состоянии проект на сейчас (апрель 2016) ?
…ваша группа не пустая, но и не живая…
(82) Snitkovski,
Всем добрый день! на данный момент проект ищет спонсоров 😉 Причем очень активно…А там как повезет. Обещаю как только объявится бизнес-ангел все, кто присоединился к группе получат личное приглашение ))))
(81) AlexanderKai,
Еще как тянет )))) особенно если включить кеширование )))
Читал эту статью несколько лет назад. Очень интересно и не обычно. Тоже люблю экспериментировать.
3.5 года тишина. Интересно — получилось ли что-то. или так осталась сугубо внуреннней разработкой сугубо для внутренних нужд в неотчуждаемом состоянии…?
))) уже 3.5 года прошло? неужели??? как быстро летит время
Можно как-то найти книгу на которую вы ссылались?
Кустов М.Г. «Реальный учет предприятия».
Поисковики ничего о ней не знаю, может где продается, или у вас есть электронный вариант?