Со всеми удобствами…

Удобно ли, когда замок входной двери сам защёлкивается? Казалось бы да.

Не надо лишний раз лезть за ключом, когда выходишь. Но лишний ли?

Вспомните историю инженера Щукина из 12 стульев. А самим в подобном

положении не доводилось оказаться? Такова цена удобств…

Казалось бы, причём тут Лужков? Ой, я имел в виду учётные системы :)

 предлагаемые по умолчанию данные

Умолчания

Как удобно, когда система сама предлагает пользователю данные, решения, целые фрагменты текста. Остаётся только кликнуть на ОК! Но!

Если бы предлагаемые по умолчанию данные, решения, фрагменты не требовали, кроме нажатия ОК, никаких других действий, то система вполне могла бы хотя бы в этом месте обойтись без пользователя вообще. То, что пользователь должен на ОК кликнуть, означает, что он готов взять на себя ответственность за подтверждение предлагаемых системой данных. Но тут возникает вопрос — а какова цена этих «удобств»? Экономим нажатие кнопок?

Экономим на крохах, теряем на ворохах.

Смысл подтверждения именно во взятии ответственности. Если пользователь, убаюканный «удобствами», не удосужился задуматься над тем, что он подтверждает, то что мы сэкономили? Так может пусть он ручками забьет требуемые данные или хотя бы осознанно (без предлагаемого умолчания) выберет их из списка. И никакие дополнительнительные  «А Вы действительно уверены?» не помогут — их он перещёлкнет ещё более автоматически.

Цена ошибки — жизнь.

Мне доводилось разрабатывать банковские системы. Заказчик ясно понимал цену ошибки. В начале 90-х или в общении с Юкосом это вполне могла быть жизнь. От меня сознательно требовали отсутствия  всяких умолчаний. И даже повторного ввода данных, как при подтверждении пароля. Так спрашивается, а что, цена ошибки в других учётных системах снизилась настолько, что пользователя держат просто клавиши плющить? Последние годы мне чаще приходилось разрабатывать учётные системы в других областях бизнеса. Заказчик не так щепетильно относился к защите от ошибок. «Поставьте здесь по умолчанию такое-то значение, как правило требуется именно оно». А потом с удивлением обнаруживается, что пользователи, особенно начинающие, даже не удосуживаются взглянуть на соответствие умолчания реальным требованиям учёта. И все данные остаются по умолчанию, хотя это явно ошибочно.

«Как правило»… А ну как исключение? Как правило, я тоже из дому выходил, проверив наличия ключа…

Редактирование

Наученный высокими требованиями «защиты от дурака» в банковских системах, я взял за правило открывать отдельную форму создания/редактирования любой учётной записи.

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

«А нам удобно редактировать прямо в гриде (ячейках таблицы)». Удобно  так удобно. Потом оказывается, что в таблице, которую разом на экране не разместишь (требуется прокрутка), через раз просто промахиваются мимо строки. А главное, не понимают, в какой момент сохраняются данные. Когда переходят на другую ячейку? Или строку? Или вообще закрывают форму? И бегут к администратору БД – исправьте, пожалуйста, мы тут ошиблись. Ну как, удобно вам???

О модальности экранных форм

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

«Модальные формы нарушают права человека!» В смысле пользователя.

Типа, надоело в этой форме работать, открою-ка я другую, может там поинтересней окажется. Вот, собственно, такое право безответственного скакания с формы на форму и ограничивают. Учётная система — это не портал развлекательных сайтов. Сюда люди приходят работать. Но я это пишу не для того, чтоб поморализировать или защитить права работодателя от прав работника. Не завершив регистрацию учётных данных в одной форме, пользователь может открыть и начать работать в другой, которая содержит данные, логически связанные с незакрытой. Или, пройдя по меню, оказаться в той же форме, но, естественно, в новом её экземпляре. С новым экземпляром данных. И самое ужасное, что с  тем же самым, редактирование которого он не закончил на предыдущей открытой. А дальше конфликт неизбежен. Программно защитить данные от разрушения при параллельном редактировании их в разных формах — не вопрос. Вопрос в том, понимает ли пользователь, какой вариант редакции данных в конечном счёте окажется в базе.

Ответ — безусловно нет. Так и не надо его на подобные ошибки провоцировать! А чтоб пользователю не надо было искать необходимую информацию на других формах системы, формы надо проектировать так, чтоб вся необходимая для принятия решений информация была у него перед глазами в данной форме. Ну максимум — на закладках или всплывающих окнах данной формы. Кстати, такой подход к модальности открывает прямой путь к созданию WorkFlow — управлению работой пользователя. Когда система если не управляет, то хотя бы направляет пользователя к выполнению тех операций в учётной системе, которые от него требуются в данный момент.

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

Декомпозиция при анализе и моделировании предметной области

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

Что такое инкапсуляция

Инкапсуляция — наряду с полиморфизмом и наследованием один из трёх китов ООП. Суть его заключается в сокрытии внутренней кухни. Сокрытии не в смысле закрытия доступа, хотя в коммерчески тиражируемых библиотеках классов это широко распространено. А в первую очередь в смещении акцентов с реализации этой самой внутренней кухни на формальное описание её свойств. То есть не собственно её, а того, что она реализует.
Это соответственно предъявляет к формальному описанию повышенные требования, поскольку инкапсуляция как бы гарантирует полноту описания без необходимости во внутренней кухне копаться. В приложении к предлагаемому подходу множественности нотаций описания бизнес-процессов, инкапсуляция подразумевает возможность использования объектов некой нотации, абстрагируясь от внутренней кухни данных объектов, которая, возможно, описана в совершенно другой нотации и доступна при декомпозиции данных объектов.

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

Подходы

Понятие «бизнес-процесс» — многогранное, и, как следствие, существует множество подходов к описанию бизнес-процессов, воплощающихся в различных нотациях.

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

Документный подход –

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

Оторванность от природы предметной области — это одновременно и достоинство этого подхода и недостаток. Недостаток состоит, в первую очередь, в том, что реинжиниринг даже отдельных участков бизнеса влечет за собой радикальное изменение состава документов и их жизненных циклов, и, как следствие, требует переписывание многих описаний бизнес-процессов и создание основанной на них программной системы почти с нуля. Достоинством же является наличие на рынке большого числа оболочек программных систем, ориентированных на документный подход, таких как 1С и Navision, значительно снижающих трудозатраты на разработку прикладного ПО. Кроме того, привычная и хорошо формализованная терминология документного подхода упрощает проектное обследование (интервьюирование, согласование) по сравнению с подходами, требующими более высокого уровня абстракции.

Ресурсный подход –

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

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

Поточный подход –

предлагает взгляд на бизнес-процессы, как на потоки работ (заданий) исполнителей.

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

Датацентристский подход –

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

Суть подхода заключается в выделении в модели объектов учета специальных объектов типа «процесс», обладающих обязательным набором атрибутов (время начала/конца, исполнитель) и связями с объектами, которыми данный процесс манипулирует.

«ДОступный» подход –

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

В конечном счете, все, что исполнитель в какой-то момент может сделать с объектом учета, именно это он _должен_ сделать.

Совместимость описаний

Уровни детализации: декомпозиция и агрегирование.

Очевидно, что в зависимости от назначения описания бизнес-процессов, требования к детализации совершенно различные.

«Большому боссу» требуется картина «крупными мазками». В его понимании бизнес-процессы – это скорее направления бизнеса, чем реальные процессы, привязанные к временной шкале. Стрелки, изображаемые на диаграммах бизнес-процессов этого уровня детализации, служат исключительно эстетическим целям и никаких реальных связей не отражают. Для тим-лидера кодеров наоборот требуется максимальная детализация описаний – кто в какой момент какие манипуляции может и/или должен совершить. Между этими граничными (минимальным и максимальным) уровнями детализации лежит целый спектр уровней детализации, который используется аналитиком для согласования требований заказчика на разных уровнях организационной структуры.

Множественность нотаций

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

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

Обеспечение совместимости

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

В качестве минимальной меры обеспечения совместимости предлагается введение регламентов, требующие от аналитика соблюдать некоторые формальные правила при переходе от одного уровня детализации к другому и от одной нотации к другой. Однако в силу семантической неоднозначности (омонимии) ныне применяемых нотаций (IDEF0,IDEF3,EPC), такие правила либо не общезначимы, либо настолько громоздки, что сами служат источником ошибок. Программная поддержка таких правил могла бы развиваться в двух направлениях – программный контроль полноты и непротиворечивости описаний и автоматизация генерации прототипа описания в иной нотации или на ином уровне детализации. Очевидно, что прототип, порожденный для более детального уровня с менее детального (в частности само описание на менее детальном уровне) требует доработки вручную. Возникает соображение, что обратное преобразование (с более детального на менее) может быть произведено автоматически. Однако это соображение весьма сомнительно, поскольку правила агрегирования в таком случае должны различать (или порождать) основные элементы от детальных. Особый интерес представляет объектно-ориентированная программная поддержка, обеспечивающая инкапсуляцию на каждом уровне детализации элементов описания в разных нотациях и множественное наследование различных типовых решений.

Предложение

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

Приводимые ниже рассуждения строятся «снизу-вверх», однако, поддержанные программным механизмом автоматизации декомпозиции, могут использоваться при описании бизнес-процессов в обратном направлении («сверху-вниз»).

Классом объектов учета будем называть некоторую выделенную сущность (база класса) и произвольную совокупность сущностей, связанных с базой, в том числе и опосредованно. Объектом будем называть элемент базы в совокупности со всеми связанными элементами всех сущностей класса. Состояние объекта определяется некоторым предикатом над выделенным набором атрибутов всех сущностей класса и, возможно, значениями предикатов других состояний данного объекта. Таким образом, каждый объект может находиться или не находиться в некоторых состояниях. В общем случае объект может находиться более чем в одном состоянии, но возможно включить в предикат состояния предикаты всех остальных состояний, если потребуется единственность состояния объекта в каждый момент. Построим ориентированный граф, вершинами которого будут являться состояния, а ребрами – допустимые переходы из одного состояния в другое. Припишем каждому ребру роли (совокупности ролей). Не вдаваясь в прочие технические детали, полученный граф будет являться описанием бизнес-процессов, преобразующим модель данных в соответствии с правами доступа пользователей.

Представляется возможным на основании предложенной нотации породить более традиционные – IDEF, EPC, USE-CASE, WorkFlow и т.п. А главное, наряду со схемой базы данных, из описания бизнес-процесса в такой нотации можно сгенерировать прототипы экранных форм пользовательского интерфейса.