gifts2017

Предметно-ориентированное проектирование (3D) в 1С. Виртуальная машина.

Опубликовал Евгений Пономаренко (Evgen.Ponomarenko) в раздел Программирование - Теория программирования

Проектирование программного обеспечения - это постоянная битва за простоту.

Благодарности

Автору статьи из зазеркалья «Профессия 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, позволяет фиксировать авторство разработчика.

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Павел Алексеенко (qwinter) 03.06.14 11:45
А почему: Проблемно-ориентированное проектирование?
2. Евгений Пономаренко (Evgen.Ponomarenko) 03.06.14 12:28
(1) qwinter,
Абсолютно правильный вопрос! Это не точный перевод с англ. термина Domain-driven design в статье из Википедии. Правильно "Предметно-ориентированное проектирование"
3. Яков Коган (Yashazz) 03.06.14 15:51
Ещё одна бесполезная мечта о сферическом кодинге в вакууме. Автор, вы верите, что хотя бы 5% положений вашей, несомненно, умной, проработанной статьи будут применены на практике?
bulpi; wolfsoft; EdmundoAlvares; +3 Ответить 4
4. Евгений Пономаренко (Evgen.Ponomarenko) 03.06.14 16:19
(3) Yashazz,
На самом деле все было с точностью до наоборот, сначала на практике была доказана эффективность идеи, а уже потом она оформилась в виде статьи после знакомства с книгой "Предметно-ориентированное проектирование". Если вы заметили, мои статьи носят в основном теоретический характер, но это только подготовительный этап. Следующая публикация будет содержать dt-шник с CRM системой. Я думаю что после её публикации здесь пропадет смысл публиковать подобное за деньги http://infostart.ru/public/286088/. По крайней мере Картридж "Холодные звонки" у меня входит в базовую бесплатную версию.

PS. Данная система версии 3.0 радует свыше сотни пользователей на пяти предприятиях. К выпуску готовиться 4.0
5. Евгений Пономаренко (Evgen.Ponomarenko) 03.06.14 16:31
(3) Yashazz,
Вы лучше скажите, какие по вашему мнению идеи кодинга в вакууме наиболее сферичны?
6. Павел (Yimaida) 04.06.14 01:59
Каким образом "Виртуальная машина" (ВМ) позволяет "...неограниченно расширять функциональность прикладного решения без изменения конфигурации 1С." и в то же время "Виртуальная машина может использоваться как отдельная конфигурация, так и объединяться с типовой."?
Статья написана цитатами из википедии и т.п. В одной куче как английские термины так и русские, переопределение устоявшихся понятий в рамках статьи. Если это тест на психологическую устойчивость, то я его прошел. Хотя нет, я не все прочитал, а только урывками (не зачет).
Интересно, а что если прогнать через Виртуальную машину Вашу статью...

P.S. Статью надо упрощать, обилие терминов не объясняет, а лишь усложняет общий смысл. Хуже всего когда в одном месте встречаешь дельные мысли и чушь.
7. Валентин Бомбин (so-quest) 04.06.14 09:39
а еще лучше приложить код. хоть какой-то. так проще понять
8. Антон Рощин (wolfsoft) 04.06.14 10:10
Можно много написать, но в принципе товарищ Yashazz ужё всё сказал в (3). Автору на заметку, в сфере программирования уже достаточное количество времени назад пришло понимание, что создание "идеальных сферических коней" - тупиковый путь. А народная мудрость ещё много лет назад на эту тему говорила "Не торопись выполнять указание командира, может так получится, что через некоторое время всё изменится, и его вообще не надо будет выполнять" - "или ишак сдохнет, или эмир".
PS: Если Элияху Голдратта не читали, рекомендую, толковый товарищ.
9. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 10:25
Тише-тише... не все сразу!
10. Игорь Исхаков (Ish_2) 04.06.14 13:38
Ну , статья полезна прежде всего самому автору.
Евгений систематизировал и упорядочил свой опыт и познания.
Ничего дурного тут нет.

У меня вопрос :
а сама платформа 1с является "виртуальной машиной" для проектирования сложных систем ?
Если нет , то замолкаю.
Если да , то "виртуальная машина" от Евгения есть следующий уровень абстрагирования относительно "платформы 1с".
На мой взгляд, тогда не хватает описания ограничений для применения "виртуальной машины" как общего подхода.
На что налетаем , проще говоря ?
o.nikolaev; lamp; Evgen.Ponomarenko; monkbest; +4 Ответить 4
11. Антон Антонов (monkbest) 04.06.14 13:39
я правильно понял, что виртуальная машина упомянутая в статье это некая конфигурация, которая является неким конструктором, с уже готовыми кусками. Что-то вроде как стандартных подсистем, только помимо готовых блоков в ней есть возможность создавать блоки в режиме предприятия пользователем и настраивать их функционал, не залезая в конфигуратор. Тогда это что-то вроде конфигуратора в режиме предприятия.

И у меня вопрос, а зачем оно нам надо? Ведь сама платформа 1С и есть для нас та самая виртуальная машина. И развитие В.М. берет на себя фирма 1С, развивая платформу, а развитие систем берем на себя мы - Специалисты 1С.

Если я что не так понял, то поправьте меня пожалуйста.
12. Антон Антонов (monkbest) 04.06.14 13:43
(10) Ish_2, во во, у меня те же вопросы возникают))
13. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 15:50
(10) Ish_2,
Ну , статья полезна прежде всего самому автору.
Евгений систематизировал и упорядочил свой опыт и познания.
Ничего дурного тут нет.

Стопудово!!!

У меня вопрос :
а сама платформа 1с является "виртуальной машиной" для проектирования сложных систем ?
Если нет , то замолкаю.

Ответ:ДА!

Если да , то "виртуальная машина" от Евгения есть следующий уровень абстрагирования относительно "платформы 1с".

В точку!

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


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

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

И все же попробую предположить в чем могут быть траблы?
Вы абсолютно правы: Кейс - это абстрактный слой.
Дело в том, что конфигурации - это вотчина поставщика конфигурации и модифицировать её внедренцу не с руки.
Я заложил возможность, того, что Кейсы могут быть продаваться как конфигурации, но скорее всего получится слишком сложно.

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

Проблема миграции данных из конфигурации в конфигурацию решена в обработке ВыгрузкаЗагрузкаДанныхXML82.epf
http://infostart.ru/public/201607/

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

Есть еще одна проблема. Не смотря на то, что структура данных виртуальной машины имеет поддержку совместимости снизу вверх, есть риск упереться в проблему роста, но эта проблема целиком ляжет на мои плечи. Ввиду ограничений по моим ресурсам, меня это напрягает больше всего. По этому я и опубликовал эту статью, по тому, что ограничений не вижу!
Самое сложное в моем случае - это доминирующие стереотипы мышления.
14. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 16:33
(11) monkbest,
я правильно понял, что виртуальная машина упомянутая в статье это некая конфигурация, которая является неким конструктором, с уже готовыми кусками. Что-то вроде как стандартных подсистем, только помимо готовых блоков в ней есть возможность создавать блоки в режиме предприятия пользователем и настраивать их функционал, не залезая в конфигуратор. Тогда это что-то вроде конфигуратора в режиме предприятия.



Если я что не так понял, то поправьте меня пожалуйста.

Все вы правильно поняли.

И у меня вопрос, а зачем оно нам надо? Ведь сама платформа 1С и есть для нас та самая виртуальная машина. И развитие В.М. берет на себя фирма 1С, развивая платформу, а развитие систем берем на себя мы - Специалисты 1С.

Как по мне 1С пошла по пути усложнения, а не упрощения (надувая щеки). У меня ВМ работает и на 8.1,8.2,8.3 разницы большой нет.

А по поводу ограничений:
1) Как только система "затыкается", всегда есть возможность в обработчике события врубить всю мощь платформы 1С.
2) Cтруктура 7-ми универсальных регистров разрабатывалась 3 месяца. Возможны тормоза из-за универсальности, но на практике, скорость проведения и выборок на порядок выше чем у типовых конфигураций.
15. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 16:56
Можно много написать, но в принципе товарищ Yashazz ужё всё сказал в (3).
Автору на заметку, в сфере программирования уже достаточное количество времени назад пришло понимание,
что создание "идеальных сферических коней" - тупиковый путь. А народная мудрость ещё
много лет назад на эту тему говорила "Не торопись выполнять указание командира,
может так получится, что через некоторое время всё изменится, и его вообще не надо будет выполнять
" - "или ишак сдохнет, или эмир".
PS: Если Элияху Голдратта не читали, рекомендую, толковый товарищ.


Жаль, что вы меня практически не знаете, я не любитель изобратеть велосипеды.
Вы даже себе не можете представить насколько я вас понимаю! И с вашими тезисами в целом я согласен.

Но,в данном конкретном случае создание "идеальных сферических коней" было вопросом выживания.
Вы думаете нормальный программист начнет разработку с нуля, если у него на это нет ВЕСКИХ причин?

в 2007 уже имея успешный опыт внедрения УТП и УПП, я попал в очень серьезную переделку.
Было три варианта: лишиться квартиры, быть закопанным в лесу или изобрести "НЕ идеального сферического коня".
Слава богу, меня поддержал мой старый знакомый, помог мне не сойти с ума. Вместе мы разработали с нуля учетную модель
предприятия. В итоге, описание модели вышло в книге Кустова М.Г. "Реальный учет предприятия"

Я вам скажу оптовая торговля продуктами питания - эта тема покруче форекса. А про партионный учет я вообще молчу:
продажа того, чего нет; виртуальные замещения объемов и прочая хрень.
В итоге через год появилась виртуальная машина 1.0

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

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

На самом деле я ПРЕКРАСНО отдаю себе отчет насколько трудно мне будет ДОНЕСТИ свою идею.
И ваши посты тому лишнее подтверждение. Просто так случилось, что ОБСТОЯТЕЛЬСТВА сложились так, кто меня ВЫНЕСЛО
за пределы сферического вакуума. Я там выжил, получил опыт и хочу им поделиться.

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

Когда-то давным давно я написал свой аналог "Снегопат" под досовские Borland-Pascal и Fox-pro. Speedpro назывался ;)
Так вот, ВМ это совершенно другой уровень. "Снегопат" облегчает кодирование, ВМ - проектирование.
16. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 17:08
(7) so-quest,
а еще лучше приложить код. хоть какой-то. так проще понять

Это как раз тот случай, когда код может все только усложнить

Я постараюсь в Демо-конфигурации полностью раскрыть суть.
17. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 17:54
(10) Ish_2,
На что налетаем , проще говоря ?

Гипотетически возможны проблемы с безопасностью, но решается просто установкой ограничений по правам на справочники Виртуальной Машины
18. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 18:00
(6) Yimaida,
Каким образом "Виртуальная машина" (ВМ) позволяет "...неограниченно расширять функциональность прикладного решения без изменения конфигурации 1С." и в то же время "Виртуальная машина может использоваться как отдельная конфигурация, так и объединяться с типовой."?


Основные объекты имеют префикс ВМ.
Справочники типа "Контрагенты","Пользователи","Номенклатура" префиксов не имеют.
Общий модуль вмИнтерфейс обеспечивает вызовы стандартных механизмов типовых конфигураций
Объединение выполняется с помощью "поставки" и инструкции "делай раз, делай два".
19. борян петров (TODD22) 04.06.14 18:18
Кустова М.Г. "Реальный учет предприятия"

Что это за книга такая? Яндекс про неё не слышал....
Ждём вторую публикацию :)
20. Евгений Пономаренко (Evgen.Ponomarenko) 04.06.14 18:38
(19) TODD22,
Она вышла ограниченным тиражом.
21. Павел (Yimaida) 05.06.14 00:27
(15) Евгений, как по мне этот пост в разы информативнее чем сама статья. Т.е. только теперь мне стал понятен реальный путь ВМ. То, что Вы не перешли на личности из-за моего немного резкого комментария добавляет Вам чести. Я вот в институте до определенной поры никак не мог понять почему мне сначала читают 2 месяца лекции и только потом я делаю лабораторные работы. Ведь в жизни все было иначе (сначала был опыт, потом его повторили несколько раз и только потом оформили в теорию с кучей умных фраз и терминов). Когда я это понял, я по другому стал воспринимать эту академическую "воду". Ну вот объясните мне, зачем Вы написали такую "тяжелую" статью? Зачем поменяли местами причину и следствие?

(18) Эти цитаты я привел как пример противоречия. Т.е. я понял, что для работы ВМ надо объединять с типовой конфигурацией (УТ, БП, ЗУП)...
22. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 02:18
(21) Yimaida,
Зачем поменяли местами причину и следствие?

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

Я в такие минуты вспоминаю Ийона Тихого, героя многих произведений фантаста Станислава Лема.
Который ищет в «Космической энциклопедии» информацию о «сепульках», фактически попадая в цикл косвенной рекурсии:

«СЕПУЛЬКИ — важный элемент цивилизации ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКАРИИ».
Я последовал этому совету и прочёл:
«СЕПУЛЬКАРИИ — устройства для сепуления (см.)».
Я поискал «Сепуление»; там значилось:
«СЕПУЛЕНИЕ — занятие ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКИ».


На самом деле программистам порой кажется, что мир иерархичен, так же как их классы в ООП.
Однако, попробуйте объяснить пятилетнему ребенку, что такое Солнце. Если вы будете формально соблюдать принципы причинно-следственных связей и попытаетесь словами объяснить термин "Солнце" вы упретесь в тупик ;))) и в конце-концов ткнете пальцем в небо. Ибо реальный мир это не иерархия - мир это сложные сети.

Ключевой момент, который вам позволил осознать виртуальную машину - это Ваш интерес, который вы проявили и за который я был Вам благодарен. По этому я не мог, как вы сказали "перейти на личность". Вы помогли мне раскрыть суть статьи для Вас. Я не писал "тяжелую" статью, с моей точки зрения - она очень простая )))) такая же очевидная как Сепулькарий для Ардритов с планеты Энтеропия.

На самом деле ваш пост(6) очень интересный.
Если это тест на психологическую устойчивость

Так и было задумано )))))) Вы его прошли, но попались в ловушку. Я приношу свои извинения, не со зла я.
Просто мои попытки объяснить окружающим меня программистам суть идеи всегда "проваливались". Причем у идеи есть соавтор,
который столкнулся с той же проблемой. Хотя взять и обучить с "нуля" программиста с чужого франча оказалось очень простой задачей.
Если бы вы слышали как он "плевался" после этого, на своих бывших учителей, которые ему за его же деньги "запарили" мозг!

Хуже всего когда в одном месте встречаешь дельные мысли и чушь

эхе-хе-хе... Чушью я считаю ERP 2.0, УПП можно простить, но ERP - это просто монстр ибо при таком размере в нем нет модели! Система проектирования прикладных решений СППР - тоже чушь... ибо это оцифровка другой чуши "PMBOK_4th_edition_Russian_full_opt.pdf"
У меня прекрасно функции СППР уживаются в ВМ занимая 10% кода )))

Концепция МФСО "ConceptMFSO.pdf" в целом хороша, но в параграфах 102-110 "КОНЦЕПЦИЯ КАПИТАЛА И ПОДДЕРЖАНИЯ КАПИТАЛА" содержится откровенная ДЕЗА! Но за статью на эту тему даже браться не хочу ибо ЗАКЛЮЮТ на***рен.))) Как нить попозже...

Т.е. я понял, что для работы ВМ надо объединять с типовой конфигурацией (УТ, БП, ЗУП)

Возможны оба варианта: и объединения и автономной конфигурации.
23. Alex Gaiduk (AlexSunS) 05.06.14 02:49
Чушью я считаю ERP 2.0, УПП можно простить, но ERP - это просто монстр ибо при таком размере в нем нет модели!


Давайте ка тут поподробней, я не оспариваю личную ценность вашей статьи, но вот в этом комментарии утверждение что ERp чушь не хватает конкретики.
Итак вопрос 1 Верно ли утверждение что в ERP(УПП 2.0) нет модели(нескольких моделей) ?
Вопрос 2 Что вы подразумеваете под словом "модель" в конфигурациях 1с ?
Вопрос 3 Все ли, не имеющее модели, это чушь ?

Спасибо
24. Alex Gaiduk (AlexSunS) 05.06.14 03:05
Да я с нетерпением жду "коня", если не сложно, дабы так сказать быть конструктивным, примеры его использования вы описали, весьма интересует решение отличное от шаблонных.
25. Максим Кузнецов (Makushimo) 05.06.14 09:41
(6) Yimaida,
Соглашусь в одном. Написано много, а понятно едва ли 5%.
Остались не отвеченными вопросы:
1. Как конкретно это расширять? где и что добавлять, чтобы расширить функционал?
2. Это БСП? Будет ли описание технологии внедрения в типовые?
3. Вообще что это?
4. Для чего это?
26. Борис (soap) 05.06.14 10:26
Статья оставляет слишком много вопросов. Боюсь без конкретного решения... Надобно пощупать ВМ тогда вникать в теорию.
Evgen.Ponomarenko; +1 Ответить
27. ффф ыыы (zqzq) 05.06.14 10:40
Тоже жду эту легендарную ВМ :)

Конвертация данных или СКД произвели качественный скачок в эффективности разработки во многом благодаря абстрагированию различных уровней и уменьшению связности между уровнями, может и тут что-то подобное произойдёт. В любом случае нужно посмотреть "живьём".
28. Андрей Овсянкин (Evil Beaver) 05.06.14 11:20
Оххх.... Фундаментально. Дочетать не смок, многа букаф (С)
А нельзя ли короткое резюме - про что там столько написано?
29. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 11:45
(23) AlexSunS,
Давайте ка тут поподробней, я не оспариваю личную ценность вашей статьи, но вот в
этом комментарии утверждение что ERp чушь не хватает конкретики.
Итак вопрос 1 Верно ли утверждение что в ERP(УПП 2.0) нет модели(нескольких моделей) ?
Вопрос 2 Что вы подразумеваете под словом "модель" в конфигурациях 1с ?
Вопрос 3 Все ли, не имеющее модели, это чушь &


Ибо использование мной слова "чушь" было провокацией ;)) с одной стороны и крик души с другой.

Итак вопрос 1 Верно ли утверждение что в ERP(УПП 2.0) нет модели

Нет Единой модели, нет стержня. Нет Идеи исходящей от главного Архитектора системы.

(нескольких моделей) ?

В ERP(УПП 2.0) есть много моделей, точнее зоопарк физических и логических моделей.
В свое время в начале 2000 годов я участвовал в разработке полномасштабной ERP системы.
У нас схемами моделей были обклеены все ровные поверхности.
Мы тогда использовали в основном нотацию IDEF1x. Только сейчас я понимаю, что главная
экономическая модель должна была умещаться на листе формата А4 и быть стержнем всей системы.

ЦИТАТА Вопрос 2 Что вы подразумеваете под словом "модель" в конфигурациях 1с ?
В свое время Лука Пачоли в своей книге "Трактат о счетах и записях" заложил методику современной Бухгалтерии.
Это был прорыв на то время. Сейчас, благодаря автоматизации его принцип двойной записи во многом потерял актуальность.
Ибо автоматическая проводка никогда не нарушит Баланс. Современный мир стал сложнее, что привело к тому,
что большая часть ресурсов учитывается на забалансе.

Когда мы с Кустовым М.Г. начали разрабатывать с "нуля" новую конфигурацию,
мы начали с разработки новой учетной модели предприятия. За основу взяли уравнение "собственного" капитала.
Очень грубое описание: (подробее опишу отдельно)
Собственный капитал (СК) = Наличные Активы +/- Обязательства
Наличные Активы и Обязательства делятся на Денежные и Материальные
Приращение Собственного капитала - это разница между Начальным СК и Конечным СК
При проверке достоверности учетной модели конкретного предприятия должно соблюдаться равенство:

Приращение/Убыль СК = Все доходы - Все расходы.

Если равенство нарушено - управленческий учет на таком предприятии можно считать не достоверным.

Данный подход позволил сделать вывод о том, что для задач учета необходимо и достаточно 6 регистров:
Деньги
ТМЦ
Обязательства по Деньгам
Обязательства по ТМЦ
Доходы
Расходы.


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

Хотя нельзя сказать, что в моей системе используется Одна модель. Есть единый стержень, на который нанизываются
другие полезные модели учета более низкого уровня, например http://infostart.ru/public/277570/

Вопрос 3 Все ли, не имеющее модели, это чушь &

Нет, чушь - это слово провокатор.



30. Павел (Yimaida) 05.06.14 12:12
(22)Ну вот по-тихонечку статья обрастает комментариями...
Про чушь я имел в виду, наличие в одном месте обилия терминов, которые порой не вяжутся между собой. Т.е. оперировать "умными" терминами на самом деле опасно, т.к. их смысл не всегда явно описан (в литературе и т.п.) и тем более не всегда воспринимается так же как их воспринимает автор (т.к. сказать проекция...). Конечно, при желании, тут тоже можно найти пользу от прочтения, т.к. лишний раз напрягаешь мозг.
Моя основная претензия к статье касается только лишь формы изложения, которая мне сразу напомнила курсовую работу которую оформили на скорую руку. Не понятно где собственные мысли, а где заимствованные. Особенно это режет ухо при обобщениях типа " Если до 21 века смена технологий проходила медленее, чем смена поколений людей, то на сегодня, смена технологий происходит каждые 5 лет" или "Истинное учение гласит (повсеместно, в том числе и в остальных частях этой книги), что предметная область и интерфейс должны быть отделены друг от друга!"
31. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 12:17
(25) Makushimo,
1. Как конкретно это расширять? где и что добавлять, чтобы расширить функционал

Справочники вмКартридж, вмКнопки, вмКнопкиОтчетов, вмСобытия, вмБиблиотекаЗапросов, вмВидДокментов
содержат управляющие структуры, тексты обработчиков событий и запросов.

2. Это БСП?

Если судить по решаемым задачам - да! Только появилась гораздо раньше.
Это одна подсистема, внутри которых реализованы спомогательные службы
протокол действий пользователей/разработчиков
диагностика запросов
мониторинг производительности
загрузка из экселя
управление сеансами
управление правами
и т.д.

2.1 Будет ли описание технологии внедрения в типовые?

Однозначно!

3. Вообще что это?

Считайте Мета-Конфигуратором (С)33lab
4. Для чего это?

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

Честно говоря, я искренне не понимаю темы фрилансерства, активно обсуждаемой на соседней ветке.
Один обученный человек принципам работы ВМ стоит сотни фрилансеров.

По крайней мере 3 человека за 3 года создали систему, которая выдержала "наезд" крупной фирмы франчайзи с готовым отраслевым решением по УПП.
32. Василий Казьмин (awk) 05.06.14 12:18
(30) Yimaida, Говорят, что умными терминами оперирует тот - кто хочет казаться умным. А тот кто хочет что бы его поняли - объясняет простыми словами.
33. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 12:19
(30) Yimaida,
Понял, учту на будущее... в следующий раз постараюсь быть короче и конкретнее ;)
34. Василий Казьмин (awk) 05.06.14 12:23
(13) Evgen.Ponomarenko, Для де-юро нужна команда.
35. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 12:32
(32) awk,
;) Есть такое мнение.
На самом деле хотелось создать на ИС цикл хорошо структурированных перелинкованных связанных статей. Щас такой идеи уже нет, а привычка осталась. На самом деле я в большей части пишу для себя, собираю вместе разнородную информацию, переосмысливаю. У меня в черновиках лежат десяток статей, даже публиковать не буду. Пойдут на запчасти.

По емкости и содержательности мне очень понравился пост Ish_2 (10) после него мысли "перестроились" на другой лад.
36. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 12:34
(34) awk,
Для команды нужны деньги.
Для денег - бизнес ангел.
Для бизнес ангела нужна рабочая идея )))
37. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 13:17
(27) zqzq,
Конвертация данных или СКД произвели качественный скачок в эффективности разработки во многом
благодаря абстрагированию различных уровней и уменьшению связности между уровнями, может и
тут что-то подобное произойдёт.


Так и происходит. Для меня темы конвертации данных и СКД потеряли актуальность, у меня получилось еще проще.
В СКД 1с смешала механизм извлечения данных и отображение их в одном флаконе, что привело к значительному усложнению механизма.
У меня справочник вмБиблиотекаЗапросов содержит источники данных, а вмКнопкаОтчета содержит очень простую процедуру формирования отчетов, шаблоны таких процедур лежат в справочники вмШаблоны. Результат помещается в отчет.вмОтчет, который обеспечивает мааааасу сервисных функций для пользователя. Программист, имея права, в любой момент времени попадает в соответствующий объект управления вмКартриджа,вмКнопки,вмКнопкиОтчета,вмБиблиотекаЗапросов.
Моя система может использовать СКД, но за последний год ни разу этой возможностью не воспользовался. Ибо все гораздо проще получается.И что самое главное, пользователь ооооочень доволен, ибо СКД-шные навороты его пугают

Мне кажется 1С пошла правильным путем http://v8.1c.ru/o7/201401query/index.htm ибо ооооочень не хватает в 1С объекта типа VIEW c параметрами.
38. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 13:19
Всем огромное спасибо!
Теперь я знаю, что войдет в Демо-конфигурацию
Видимо описание придется разложить на четыре простых статьи
1) Структура Виртуальной машины
2) Очень простой Кейс CRM - системы
3) Описание принципов ABC/XYZ анализа (ну уж больно руки чешуться)
4) Описание вспомогательных служб Виртуальной машины
(вероятно придется разбить на маленькие статейки для удобства обсуждений)

ОК?

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


39. Василий Казьмин (awk) 05.06.14 14:13
(36) Evgen.Ponomarenko, Не вполне.

1. Часть команды можно приобрести за "причастность к идее"
2. Деньги можно достать пожертвованиями и рекламой.
3. Для рабочей идеи надо вынести черновую на обсуждение хотя бы закрытой группы.
40. борян петров (TODD22) 05.06.14 15:55
(38) Evgen.Ponomarenko,
Теперь я знаю, что войдет в Демо-конфигурацию

В Демо конфигурацию нужно вложить то что на практике можно взять сразу и использовать.
Например не простой кейс по CRM а продвинутый. Про виртуальную машину вообще не слова. Нужен продукт а не его реализация. Сама по себе виртуальная машина никому на данном этапе не интересна по той причине что не понятно что с ней можно делать. А вот если показать на ней реализованное хорошее рабочее приложение. То это уже может дать импульс к развитию. Опять же люди потянутся.
А если предложить людям развивать просто ВМ ну это тогда надо показать как и что. Но кто этим будет заниматься? Люди все занятые. У всех работа. Сферическую виртуальную машину в вакууме разрабатывать мало кто возьмётся. А вот система CRM на виртуальной машине может быть интересна. Хотя это лишь моё мнение....
Но всё же я бы шёл от продукта. И от того что получит в итоге конечный потребитель. Всё остальное лишь средство.
Evil Beaver; Evgen.Ponomarenko; +2 Ответить 1
41. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 16:50
(40) TODD22,
Я уже это понял )))))))) согласен на все 100%
42. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 17:00
(39) awk,
1. Часть команды можно приобрести за "причастность к идее"
2. Деньги можно достать пожертвованиями и рекламой.
3. Для рабочей идеи надо вынести черновую на обсуждение хотя бы закрытой группы.


Вы читаете мои мысли :)
1. Часть команды можно приобрести за "причастность к идее"

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

2. Деньги можно достать пожертвованиями и рекламой.

Я думал на счет Краудфандинга (по примеру Kickstarter), было бы клево, если бы ИС стал гарантом в этом деле.

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

http://infostart.ru/community/groups/1116/
Группа создана еще 14.07.2013 23:58
Добро пожаловать!

А вообще мощно было бы замутить бесплатный облачный сервис для нужд здравоохранения на средства фарм-компаний,
вот польза то была! В Израиле такая система позволяет бороться с очередями на прием к врачу.
43. борян петров (TODD22) 05.06.14 18:56
(42) Evgen.Ponomarenko,
А вообще мощно было бы замутить бесплатный облачный сервис для нужд здравоохранения на средства фарм-компаний, вот польза то была! В Израиле такая система позволяет бороться с очередями на прием к врачу.

Можно проще. Качественный модуль CRM работающий в паре с БП 3.0. Уже было бы интересно и востребовано как мне кажется. И потенциально аудитория большая.
44. борян петров (TODD22) 05.06.14 19:24
А вообще мощно было бы замутить бесплатный облачный сервис для нужд здравоохранения на средства фарм-компаний,
вот польза то была! В Израиле такая система позволяет бороться с очередями на прием к врачу.

Не знаю чем такая система реально помогает бороться. Работал в поликлинике. Делали электронную очередь. Само по себе отсутствие или наличие такого сервиса проблемы очередей не решают. Это как в супермаркете если на кассе сидит один кассир то ты ему хоть супер облачную систему поставь на деньги всех фарм-компаний это ничего не изменит. Кассир так же будет обслуживать одного человека за определённое время.
И есть ещё моменты связанные с психологией людей. Дело в том что когда ты заболел ты не лезешь в интернет в саас сервис и не записываешься на приём. А хочешь что бы тебя приняли именно сегодня и что бы ждать поменьше. А есть ещё экстренные(высокое давление, температура, острые боли, это не считая травм и тд) их нужно принять сразу... так что такая система по сути является электронным расписанием врачей. Но основных проблем не решает. Ещё есть проблема когда люди приходят не в назначенное им время. Записался на 15.00, пришёл в 13 дня и хочет пройти по живой очереди. И таких умных набегает за день 5-6 человек. И это в очень маленьком мед центре.... я представляю какая каша в крупных мед центрах. А если пациенту давать самому возможность записываться то это вообще жесть. У тебя будет записываться в день по 30 человек. А реально приходить из них 2-3... В итоге твоя система будет просто не жизнеспособна.
По большей части проблема очередей в больница продиктована новыми нормативами от минздрава. То есть нужно увеличивать количество врачей которые ведут приём. А они уменьшают время одного приёма. Что бы врач за одну смену принимал больше людей. Вот и представь как они работают... Если реально норматив на приём 5-7 минут у врача травматолога.
45. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 21:28
(43) TODD22,
Неееее вопрос, если вы поможете с адаптацией, это будет шагом номер 2. Я живу на Украине и у нас актуальна другая конфа. Хотя я смотрю как у нас на фирме используется моя CRM-ка, так она очень даже ничего поживает как отдельная конфигурация.
46. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 21:55
(44) TODD22,
Не знаю чем такая система реально помогает бороться. Работал в поликлинике. Делали электронную очередь. Само по себе отсутствие или наличие такого сервиса проблемы очередей не решают.
Это точно, здесь нужна комплексная гос. программа. Но все равно у Израитян, есть чему поучиться. У меня друзья переехали из Израиля в Канаду, говорят здравоохранение там - совок совком. Другой друг работает в Харьковской компании, которая удаленно обслуживает американское здравоохранение - это просто кландайк, 80 человек загружены работой по уши! (причем 90% это загрузка данных)
47. Евгений Пономаренко (Evgen.Ponomarenko) 05.06.14 22:24
(28) Evil Beaver,
А нельзя ли короткое резюме - про что там столько написано?


Очень коротко о ВМ:
1)По назначению - Позволяет увеличить одновременно и скорость и качество внедрений.
2)По аналогам - Можно сказать, что является аналогом БСП, но легче, гибче и проще.
3)По способу управления - Можно сказать, что эта Мета-Конфигуратор, объекты которого хранятся в справочниках
вместе с текстами запросов и обработчиков событий.
48. Alex Gaiduk (AlexSunS) 06.06.14 06:22
(29) Evgen.Ponomarenko, Ну, в общем понятно, теперь только осталось дождаться вашего "коня" дабы так сказать проверив его в боевой ситуации,начать исторгать потоки радуги.
49. борян петров (TODD22) 06.06.14 06:58
(45) Evgen.Ponomarenko,
Неееее вопрос, если вы поможете с адаптацией, это будет шагом номер 2. Я живу на Украине и у нас актуальна другая конфа. Хотя я смотрю как у нас на фирме используется моя CRM-ка, так она очень даже ничего поживает как отдельная конфигурация.

Ну покажи что за CRM. Может и найдутся желающие поучаствовать в адаптации.
50. Евгений Пономаренко (Evgen.Ponomarenko) 06.06.14 10:01
(48) AlexSunS,
начать исторгать потоки радуги.

)))))) Если, бы слышали, что сказал по поводу восторга своих сотрудников работающих в программе руководитель отдела продаж, в узком кругу - известный пошляк ;)

Мне ваше определение больше нравиться )))))
51. Евгений Пономаренко (Evgen.Ponomarenko) 06.06.14 10:09
(49) TODD22,
Ну покажи что за CRM. Может и найдутся желающие поучаствовать в адаптации.


Сейчас CRM обкатывается у нас на фирме. Даст бог, на следующей неделе начнется внедрение в российском филиале.
(У них прайс считается, не от закупочных, а от продажных цен)
Потом я планирую "подарить" конфу другу, он занимается продажей автозапчастей. Потом выложу результаты сюда.

А пока суть да дело - отшлифую виртуальную машинку.

Если интересна тема, можете присоединиться http://infostart.ru/community/groups/1116/
52. apextrofimov (trand) 06.06.14 15:23
Планируется ли использование бизнес процессов с возможность конструирования в режиме 1с?
53. Александр Топольский (AlexanderKai) 09.06.14 13:02
Я так понял в системе один универсальный документ?
54. Евгений Пономаренко (Evgen.Ponomarenko) 09.06.14 13:59
Я приношу свои извинения всем тем, на чьи вопросы я не успеваю отвечать в режиме он-лайн.
Пока, был на даче, куда-то пропал из комментариев очень важный вопрос:

Хорошо, что я его скопировал себе для детального ответа.

Добрый день, Евгений! Прошу прощения если задаю вопрос на который Вы уже отвечали, но как
Вы собираетесь продавать разработку? Например, компания в которой работает tormozit
(автор подсистемы "Инструменты разработчика") уже в 2008 году активно внедряла
свою ВМ в крупные холдинги. Но их ВМ являлась собственностью компании и, на сколько мне
известно, не продавалась и не публиковалась. Вы же обнародовали свои идеи. Правильно ли я
понимаю, что Ваша разработка подобно Рарусу будет продаваться с ключами защиты и т.д. и т.п.?
На сколько будет открыт код?
Так же из опыта работы в ВМ могу сказать, что достаточно долго приходиться учить человека
работать в ВМ. А время - деньги. С одной стороны конечно неплохо привязать клиента установив
ВМ в которой кроме тебя никто ничего не понимает. Но ведь это не наш метод ;)


0) По поводу Идей. Мне почему-то вспоминается сказка "Золотой ключик, или приключения Буратино"
там, где Мальвина пытается обучить Буратино основам математики:

— Теперь сядьте, положите руки перед собой. Не горбитесь,
— сказала девочка и взяла кусочек мела. -- Мы займемся
арифметикой... У вас в кармане два яблока...
Буратино хитро подмигнул:
— Врете, ни одного...
— Я говорю, — терпеливо повторила девочка, — предположим,
что у вас в кармане два яблока. Некто взял у вас одно яблоко.
Сколько у вас осталось яблок?
— Два.
— Подумайте хорошенько.
Буратино сморщился, — так здорово подумал.
— Два...
— Почему?
— Я же не отдам Некту яблоко, хоть он дерись!


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

Я не боюсь конкуренции, ибо ориентирован на продажу услуг, а не инструмента.
По крайней мере, мой 20-летний опыт разработчика показал, что 95% моего дохода - это качественные услуги.
5% и много лет ущло на достижение ложных целей, типа "американского счастья".

Для профессионального разработчика не составляет труда скопировать Идею, по этому я излагаю Их в чистом виде,
чтобы облегчить Им труд. К примеру познать "изнутри" по коду быстрое преобразование Фурье не возможно, а основываясь
на идее можно строить другие, более полезные алгоритмы: цифровые фильтры, фазовые анализаторы, mp3 в конце-концов.

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

2) Почему ВМ машина поставляется бесплатно?
10 человеко-лет уже оплачены заказчиками, которые получили свои Кейсы. ВМ машина их не интересует. Кейсы конкретных заказчиков не продаются, так как с одной стороны являются коммерческой тайной заказчика, с другой стороны Кейсы не применимы на других предприятиях,
ибо сделаны под заказ.

3) Защита от копирования не предусматривается, хотя пилотные работы по внедрению ключа защиты http://specinfosystems.com.ua/short_descr02.php
велись. Программный код ВМ будет открыт и распространяться свободно по идейным соображениям. Лицензионное соглашение будет запрещать распространение модифицированного кода ВМ машины, но приглашать авторов полезных доработок к сотрудничеству.
Бесплатные Кейсы могут быть изменены автором, при условии сохранения ссылок на предыдущих авторов.

4) По поводу обучения. Принципы ВМ очень просты и 80% техник осваиваются за 16 часов. Другое дело, если у программиста отсутствует системное мышление и "многомерное" виденье, обучить его создавать Кейсы с нуля не получиться и за три года. У меня был опыт.
Когда стало ясно, что фирма растет быстрее, чем я успеваю её автоматизировать, мне дали помощника.
Но с ооооочень низкой зарплатой, пришлось взять выпускника института прошедшего курсы 1С-профессионал и 1С-специалист.
Благодаря его "глупым" вопросам конструктор стал очень простым и очевидным. Однако, мне так и не удалось его обучить искусству проектирования.
Зато его навыки полученные им в театральном кружке были весьма полезны. Принципы ВМ - очень просты,
сложнее экономические модели заложенные в Кейсах.


5)
С одной стороны конечно неплохо привязать клиента установив
ВМ в которой кроме тебя никто ничего не понимает. Но ведь это не наш метод ;)

Стопудово! В идеале, цель проекта предполагает целую армию обученных разработчиков.
А я бы взял на себя функцию координатора проекта, разработчика курсов и формирования фундамента Базы знаний.
so-quest; hulio; Liris; Ish_2; Franco; MarSeN; +6 Ответить
55. Евгений Пономаренко (Evgen.Ponomarenko) 09.06.14 14:00
(52) apextrofimov,
Планируется ли использование бизнес процессов с возможность конструирования в режиме 1с?

Да, причем старт бизнес процессов инициирует внутренняя/внешняя сделка. Сделка не может быть закрыта, если не закрыты
все её бизнес-процессы. Концептуально механизм готов, практически реализованы только самые простые его части.
ВМ версии 3.0 обслуживает фирму, которая в первую очередь оказывает услуги населению. Восемь основных информационных потоков
пронизывают 5 различных отделов. В итоге документ "Заявка" реализует около 950 различных схем имея около 120 различных реквизитов.
ВМ версии 4.0 будет содержать специализированный механизм управления Б/П. На эту тему выйдет отдельная статья, черновик готов,
но сейчас мне не хочется отвлекаться от главной темы.
56. Евгений Пономаренко (Evgen.Ponomarenko) 09.06.14 14:16
(53) AlexanderKai,
Когда-то в спорах с разработчиком экономической модели Кустовым М.Г. мы пришли к выводу, что теоретически можно обойтись одном документом и одним регистром, то есть свернуть всю модель в точку. Но практически количество накопительных регистров в системе соответствует четырем видам ресурсов:
1. Деньги
2. ТМЦ
3. Обязательства по Деньгам
4. Обязательства по ТМЦ

оборотных регистров три:
1. Доходы
2. Расходы
3. Планы

И один накопительный регистр для отражения Статусов Б/П.

Универсальных контейнеров-документов 7 шт:
1. Заявка
2. Сделка
3. Движение ДС
4. Движение ТМЦ
5. Планы
6. Доходы
7. Расходы
57. Александр Топольский (AlexanderKai) 09.06.14 15:36
(56) Evgen.Ponomarenko,
По поводу регистров согласен, но документ же может быть один. Тем более есть некие схемы проводок. Формы документов как я понял генерируются тоже на основании схем.
То есть я пока не понимаю, зачем было сделано разделение на 7 видов.

p.s. Бухгалтерский учет берут на себя регистры накопления?
И очень интересно как регистры расширяются, допустим если нужна дополнительная аналитика.
58. Евгений Пономаренко (Evgen.Ponomarenko) 09.06.14 20:02
(57) AlexanderKai,
По поводу регистров согласен, но документ же может быть один. Тем более есть некие схемы проводок. Формы документов как я понял генерируются тоже на основании схем.
То есть я пока не понимаю, зачем было сделано разделение на 7 видов.

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

p.s. Бухгалтерский учет берут на себя регистры накопления?

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

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

Все регистры имеют измерение КонтурУчета, которые позволяет конструировать новые уровни оперативного/управленческого учета.
В остальном, регистры статичны, дополнительная аналитика подтягивается через Регистратор с помощью ЛЕВОГО СОЕДИНЕНИЯ
59. Евгений Пономаренко (Evgen.Ponomarenko) 09.06.14 23:11
Например, компания в которой работает tormozit
(автор подсистемы "Инструменты разработчика") уже в 2008 году активно внедряла
свою ВМ в крупные холдинги. Но их ВМ являлась собственностью компании и, на сколько мне
известно, не продавалась и не публиковалась.

К стати, "Инструменты разработчика" на сколько я помню распространяется по принципу Donate.
Мне кажется наши разработки могут дополнить друг друга.
60. Сергей Марченко (MarSeN) 09.06.14 23:27
такие фундаментальные работы должны как-то выделяться среди прочих на ИС и 1 голос должен быть равен минимум 3-м обычным плюсикам.
Вообще ИМХО на ИС хорошо было-бы как-то делить плюсики по "фундаментальным" работам и прикладным решениям.
61. Евгений Пономаренко (Evgen.Ponomarenko) 09.06.14 23:40
(60) MarSeN,
Спасибо, на добром слове :) Но мне кажется, пора переходить к практике и все станет на свои места.
62. Яков Коган (Yashazz) 10.06.14 21:39
(56) Не ново. Само не взлетит. К подобной системе, как ко всем таким гипер-универсалам, должен прилагаться талантливый, почти гениальный методист-внедренец, чтобы использовать возможности хотя бы наполовину. Иначе, хоть обпишись шаблонов, кейсов, чего угодно - будет бесполезная вещь. Проверено многократно.

Я такой универсальчик, с одним документом и эмуляцией бухрегистров через накопления, наблюдаю давно у одного своего клиента, и скажу вам - кабы не толковые ведущие пользователи, был бы карачун или я бы сидел там постоянно. При быстро меняющемся учёте даже универсал позволяет выкрутиться только с очень нехилым напильником.
63. Евгений Пономаренко (Evgen.Ponomarenko) 10.06.14 23:30
(62) Yashazz,
Теперь мне понятен ваш скептицизм.
Не ново. Само не взлетит.

Ну разве плохо будет, если таки взлетит?
Чего-то вспомнился миф о "Дедале и Икаре":
Но люди запомнили этот первый полёт, и с тех пор в их душах жила мечта о покорении воздуха, о просторных небесных дорогах.


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

Или оооочень качественные методические материалы, и серьёзная техподдержка.

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

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

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


Неее... обычно применяется не один, а 12-13. От Эмуляции бухрегистров - бог миловал, оперативный/управленческий учет имеет другие задачи.

кабы не толковые ведущие пользователи

У меня путевые пользователи обучают не путевых. Внедрение идет само-собой, без внешнего напряжения. Если взять 12 балов за 100%, то при внедрении штормит не выше 1-2 балов. Если внедрение проходит без сучка и задоринки - это высший пилотаж, если кратковременно превышает 6 балов - это залет. К слову на других проектах, если регулярно штормит в 10 баллов, через 9 месяцев половина бухов уходит в декрет. Если 12 балов штормит 1 месяц - кирдык проекту.

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

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

На последнем внедрении я 3 месяца потратил на автоматизацию планирования, накопив опыт - провел совещание.
Руководство само признало, что погорячилось с задачами (но время оплатило), решили финансовое планирование оставить в экселе, зато весь учет загнали в систему. И все рады и счастливы. Если честно сказать, то планирование очень плохо ложиться на накопительные регистры, зато учетные задачи - просто идеально. По этому Планирование улеглось в один оборотный регистр.
64. Яков Коган (Yashazz) 15.06.14 13:10
(63) С умозаключениями в целом согласен, но в изложенную практику верится слабо - впрочем, вероятно, вопрос везения. Потому что видел я случаи, когда трижды крутая техподдержка и многотомье мануалов ситуацию не спасали никак. Ну и административный ресурс, да. Без него и отличный проект будет мертворожденным, а с ним и кривая конфа заработает "на ура".
Evgen.Ponomarenko; +1 Ответить 1
65. Олег Николаев (o.nikolaev) 15.06.14 14:51
Интересная и довольно проработанная идея. Но, увы, принципиальную задачу - победить сложность - не решает, а переводит ее на другой уровень, еще точнее - откладывает на время. До того момента когда много-много связанных кейсов не станут содержать много-много связанных картриджей и контроль над сложностью, в очередной раз, будет утерян. К сожалению, после этой критики какого-то конструктива (типа - а что вы предлагаете делать?) озвучить не смогу, ибо "серебряная пуля" до сих пор не найдена. И данная "виртуальная машина" также не является ею, но как технологию, как направление, которое сможет предложить более эффективное решение ряда реальных проблем, полагаю, использовать ее вполне можно.
Evgen.Ponomarenko; +1 Ответить 1
66. Евгений Пономаренко (Evgen.Ponomarenko) 16.06.14 17:03
Yashazz
(64) Yashazz, Большое спасибо вам за комментарии, они позволили, как мне кажется, раскрыть очень сложную тему.
По крайней мере, на данный момент все цели данной публикации достигнуты.
(63) С умозаключениями в целом согласен, но в изложенную практику верится слабо - впрочем, вероятно, вопрос везения.
Та, да... везение в этом деле ключевой вопрос.

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

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

В реальности мы имеем далеко не идеальный продукт, внедрение которого кривыми ручками Зачазчика/Исполнителя связано с серьезными рисками. Скажем так, что хороший продукт значительно повышает вероятность положительного исхода, но не спасает от кривых ручек Зачазчика&Исполнителя.

Обычно косяки кривой конфы закрываются админ. ресурсом со стороны заказчика. "На ура" в этом случае наблюдается только с высоты птичьего полета. В принципе, хорошие результаты внедрения могут быть обеспечены либо идеальным исполнителем либо идеальным заказчиком. Судя по вашим комментариям вас можно отнести к опытным (идеальным) Исполнителям ;)

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

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

Вам большое спасибо, за ваше авторитетное мнение.
67. Евгений Пономаренко (Evgen.Ponomarenko) 16.06.14 17:08
(65) o.nikolaev,

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


Стопудово!!! Такая проблема существует - она у меня постоянно в фокусе внимания. Для надежности мысленно окрашу её в красный цвет,
чтобы не ушла на задний план.

ЦИТАТА
До того момента когда много-много связанных кейсов не станут содержать много-много
связанных картриджей и контроль над сложностью, в очередной раз, будет утерян.

Я думал на этим, по этому Кейсы не будут связаны, а будут самодостаточны. Картриджи не связаны между собой.
Кроме того, механизм наследования для картриджей будет реализован для галочки. Практика показывает, что
клонирование (типа копирования, с переопределением источников данных) гораздо проще и очевиднее. А вот наследование
видов документов и пользовательских событий, наоборот упрощают проектирование/программирование.
Подробнее расскажу на практическом примере.


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

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


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


И я того же мнения, хооооотя, для начала хотел ограничиться "простым" CRM-кейсом, теперь думаю ограничиться "примитивным"

Спасибо за патроны!!!
68. Яков Коган (Yashazz) 17.06.14 09:40
По поводу Админ. ресурса хотелось бы сказать, что сам по себе он ничего не решает, но формирует вокруг себя команду и "культуру" управления. У меня бывали случае, когда применение административного ресурса было равносильно ковровым бомбардировкам, когда убивался наповал не только энтузиазм сотрудников, но и включались мощнейшие механизмы скрытого/открытого саботажа со стороны рядовых исполнителей.

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

Именно так! Целиком поддерживаю.

Судя по вашим комментариям вас можно отнести к опытным (идеальным) Исполнителям ;)
Спасибо на добром слове, но в большинстве случаев это была моя жена: http://infostart.ru/profile/41675/
69. Евгений Пономаренко (Evgen.Ponomarenko) 17.06.14 10:26
(68) Yashazz,
Коган ;) Я уже успел заметить, что это у Вас Семейное
70. Антон Антонов (monkbest) 27.06.14 17:06
(29) Evgen.Ponomarenko, про наличие модели в типовых решениях хочу сказать следующее. Помимо автоматизации управленческого учета его всегда приходится мирить с регламентированным и тут все модели сыпятся. Дело в том, что наши законы пишутся не по модели, а хаотично по результатам лобби тех или иных структур. Лобби нельзя систематизировать, каждой отрасли плевать на структуру законов в целом ему нужно пропихнуть свою поправку в законопроект. Отсюда система учета начинает обрастать хреновой тучей отклонений и исключений. Законы пишут не программисты, а политики, поэтому там главное не логичность и структурированность, а достижение собственных интересов с помощью новых формулировок в законе в конкретном частном случае. А программистам потом этот миллион частных случаев собери в единую систему.

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

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

В полноценной ERP системе не может при наших законах быть единой модели, это всегда компромис.
71. г. Казань Рустем Гумеров (Rustig) 27.06.14 20:03
(0) спасибо за статью!
только такой фарш знаний, в хорошем смысле слова, сложно воспринимается при чтении.
и без подобного опыта конфигурирования на платформе 1С 8.1,8.2 сложно понять о каком новом ноу-хау идет речь.
личное: если бы не описал свой опыт в статьях
http://infostart.ru/public/195627/
http://infostart.ru/public/120169/, я бы не понял о каких виртуальных машинах вы пишите, о каких контейнерах.
Вообще платформа 1С уже сегодня позволяет пользователям-бухгалтерам не знать что такое "проводка", но качественно использовать учетную программу, а программистам-разработчикам программировать без изучения основ теории и идей выше рекомендуемых вами книг. Поэтому с точки зрения юзабилити я сам лично искал начинку вашей реализации. Что-то увидел. Побольше примеров хочется :)
Неплохая конфигурация получилась в виде контейнеров, подобных вашим - "1С: Конвертация данных".
Переход на платформу 8.3 будет трудоемким, хотя из своего опыта считаю, что если ваша разработка решает задачи клиентов, то не придется переходить.
72. Евгений Пономаренко (Evgen.Ponomarenko) 27.06.14 23:44
(70) monkbest,
Вы затронули очень интересную тему!
Помимо автоматизации управленческого учета его всегда приходится мирить с регламентированным и тут все модели сыпятся.

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

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


Налог на прибыль и НДС - это от лукавого.

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

По большому счету, если взять за основу принцип изложенный в статье CVP - анализ как инструмент принятия управленческих решений с одной стороны и концепцию собственного капитала, как механизм контроля за ресурсами, с другой стороны, то план счетов можно сократить до 20 счетов, что в конечном итоге приведет к тому, что людей понимающих, что реально происходит на предприятии должно увеличиться на порядок.
73. г. Казань Рустем Гумеров (Rustig) 28.06.14 00:01
(15) Evgen.Ponomarenko, написали бы это вместо первой части - вышло бы интересней, если утрировать, то сюжет с "погоней и преследованием" захватывает сильнее, чем "ООП и ПОП" :)
и еще, вы молодец!
74. Евгений Пономаренко (Evgen.Ponomarenko) 28.06.14 10:38
(15) Evgen.Ponomarenko, написали бы это вместо первой части - вышло бы интересней, если утрировать, то сюжет с "погоней и преследованием" захватывает сильнее, чем "ООП и ПОП" :)

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

(71) Rustig,

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


Спасибо вам огромное! В свое время запали в душу слова Eugeneer (11,16,17), но потом так и не смог их найти. Мне кажется, что разработчикам нужно делиться не программами, а чистыми идеями. Тогда толковый программист быстро размножит вашу идею по всему миру.
Упор нужно делать не на продажу ПО, а на предоставление качественных услуг.
(но это уже моя интерпритация)
75. г. Казань Рустем Гумеров (Rustig) 28.06.14 23:18
(72) Evgen.Ponomarenko,
С другой стороны вы абсолютно правы - проблема кроется в мутной воде законодательства. В узких кругах уже сформировалось мнение, что реально нужно три налога:
налог с оборота,

налог с оборота - это о каком обороте идет речь? оборот обязательств или денежных средств? то есть, допустим я дилер (промежуточное звено между заказчиком-покупателем и поставщиком товара), если обязательство поставить товар заказчику возникло в январе - например по договору + оплачен товар заказчиком в январе, товар поставлен мною заказчику в июне согласно договору, закуп мною товара у поставщика оплачен вообще в сентябре, а государство требует оплатить "некий налог с оборота", то каким месяцем налог будет квалифицироваться (начисляться), а может быть кварталом?
76. Евгений Пономаренко (Evgen.Ponomarenko) 28.06.14 23:58
(75) Rustig,
Месяц, квартал - это уже вопрос деталей. Но оборот должен оцениваться по движению ДС, ибо с чего платить, если денег еще нет? Брать налоги с обязательств - это от лукавого. К тому же денежный поток легко учитывается. Деньги они либо есть, либо их нет. А фиктивных обязательств я вам нарисую целый вагон и маленькую тележку.
77. Сергей (Che) Коцюра (CheBurator) 18.10.14 03:18
А в каком состоянии проект на сейчас?
78. Евгений Пономаренко (Evgen.Ponomarenko) 09.11.14 22:05
(77) CheBurator,
На данный момент времени нам удалось переманить на наше предприятие идеолога учетной системы Кустова М.Г. в статусе зам. директора. Если все пойдет по плану, через год можно будет подвести итоги. На данный момент данная система не является целью, скорее она побочный продукт реструктуризации предприятия. В сентябре закончили картридж "Управления проектами", чтобы можно было системно развивать предприятие в рамках ограниченных финансовых ресурсов.
79. Петр Чечин (stoptime) 17.11.14 18:40
Евгений, планируете продолжение писать? группа которую вы создали пустая. А тема интересная :)
80. Евгений Пономаренко (Evgen.Ponomarenko) 17.11.14 20:11
(79) stoptime,
Как это пустая? там 15 человек... не пугайте меня...фууух, а то я грешным делом подумал, что после очередного абдейта группа опустела. Продолжение планируется... но дело в том, что ВМ не является целью, а скорее всего побочным продуктом развития одной фирмы. По этому... планы есть, но они в перспективе. Сейчас занимаемся разработкой сайта на cms wordpress. В диком восторге от простоты решений. Движок wordpress - очень напоминает мою виртуальную машину. Жаль, что здесь не пропустят публикацию по этой теме. Ну разве, что в сравнении с 1С.
Только сравнивать нечего, как по мне, не нужно было 8.3 городить, нужно было сделать конфигурации более управляемыми, а web направление развивать на 8.4... ну или на худой конец 9.0.
81. Александр Топольский (AlexanderKai) 02.04.15 10:13
(80) Evgen.Ponomarenko,
Всегда думал, что вордпресс - это максимум блог с некоторыми интерактивными фишками и что на большее он не потянет.
82. Alexei Snitkovski (Snitkovski) 17.04.16 11:29
Уважаемый ТС!
Повторю вопрос, заданный (77) CheBurator, :

А в каком состоянии проект на сейчас (апрель 2016) ?

...ваша группа не пустая, но и не живая...
83. Евгений Пономаренко (Evgen.Ponomarenko) 19.04.16 22:08
(82) Snitkovski,
Всем добрый день! на данный момент проект ищет спонсоров ;) Причем очень активно...А там как повезет. Обещаю как только объявится бизнес-ангел все, кто присоединился к группе получат личное приглашение ))))
84. Евгений Пономаренко (Evgen.Ponomarenko) 19.04.16 22:09
(81) AlexanderKai,
Еще как тянет )))) особенно если включить кеширование )))
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа