реализация понятий документ, проводка

[neco]

как реализуют такие понятия?
документ внешне выражается так:
1. открыл бланк
2. забил данные
3. сохранил
4. может быть потом удалил

как это по идее должно выглядеть внутри:
1. открыл бланк
    а. некий шаблон извлекается и помещается перед пользователем;
    б. шаблон должен содержать фиксированные и доступные для редактирования поля;
2. забил данные
    а. шаблон должен быть интерактивным - т.е. изменение каких-то данных должно влиять на доступность каких-то других полей (к примеру, опции от выбора которых вообще может зависеть вся оставшаяся часть документа или же, другой пример, - комбик, выбирая в котором Отдел, в другом фильтруется список утверждающих лиц для отдела);
    б. шаблон не должен быть фиксированно запрограммированным - должен быть редактор шаблонов, который бы позволял создавать документы любого назначения;
3. сохранил
    а. данные из шаблона неким образом сохраняются в хранилище и помещаются на хард копию (версия для печати) в виде оформленного документа; во время редактирования внешний вид особо значения не имеет - там важно удобство, а вот на выходе он должен иметь строго документальную форму;
4. может быть потом удалил
    а. документ должен иметь возможность быть удалённым. следовательно, все изменения в хранилище должны быть как-то связаны, с тем чтобы их откатить;

примеры из практики:
1. приказ о приёме человека на работу - открыли форму; заполнили имя, должность, зарплату и т.п.; сохранили (сохранилось в базу); бланк понесли шефу, он подписал, вернулись на рабочее место - пометили приказ как подписанный (до этого момента можно какое-нибудь ограничение вводить - типа нельзя ещё один приказ на него делать); если шеф не подписал - удаляем приказ, чел удаляется из базы;
2. приказ об изменении зарплаты - нашли человека; открыли для него форму изменения зарплаты; изменили зарплату - на выходе получили бланк для подписи у начальника; сохранили - зарплата в базе изменилась; начальник подписал бумажку - оставили, не подписал - приказ надо удалить из базы, чтобы зарплата стала прежней;
3. приказ о назначении отпуска - нашли человека; открыли для него форму отпусков; проставили там, что надо; на выходе получили бланк для подписи у начальника (попутно в график рабочего времени попадают данные из приказа); дальше по обычной схеме;

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

[Dimka]

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

как реализуют такие понятия?
документ внешне выражается так:
1. открыл бланк
2. забил данные
3. сохранил
4. может быть потом удалил

Это не совсем понятия, это просто декомпозиция операций.

как это по идее должно выглядеть внутри:
1. открыл бланк
    а. некий шаблон извлекается и помещается перед пользователем;
    б. шаблон должен содержать фиксированные и доступные для редактирования поля;
2. забил данные
    а. шаблон должен быть интерактивным - т.е. изменение каких-то данных должно влиять на доступность каких-то других полей (к примеру, опции от выбора которых вообще может зависеть вся оставшаяся часть документа или же, другой пример, - комбик, выбирая в котором Отдел, в другом фильтруется список утверждающих лиц для отдела);
    б. шаблон не должен быть фиксированно запрограммированным - должен быть редактор шаблонов, который бы позволял создавать документы любого назначения;
3. сохранил
    а. данные из шаблона неким образом сохраняются в хранилище и помещаются на хард копию (версия для печати) в виде оформленного документа; во время редактирования внешний вид особо значения не имеет - там важно удобство, а вот на выходе он должен иметь строго документальную форму;
4. может быть потом удалил
    а. документ должен иметь возможность быть удалённым. следовательно, все изменения в хранилище должны быть как-то связаны, с тем чтобы их откатить;

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

Что такое "Открыть документ" в предметной области? Скорее всего, ничего (если только, быть может, снятие грифа секретности). А значит не должно быть такой операции и на уровне программной реализации. Я понимаю, что почти в любой программе есть пункт меню "Open...", но, по-моему, это неудачное название. Точнее это "Open..." означает выбор файла на диске и загрузка его в ОЗУ -- сугубо техническая задача, никак не относящася к предметной области.

А в целом запрос не очень понятный. Что нужно-то? Обеспечить трассировку требований до реализации?

[neco]

во втором блоке

1. открыл бланк
    а. некий шаблон извлекается и помещается перед пользователем;
    б. шаблон должен содержать фиксированные и доступные для редактирования поля;

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

А в целом запрос не очень понятный

спасибо, что пытаетесь помочь - я попробую внести ясность.
я не могу решить как реализовывать (по-правильному) такое несложное, вроде бы, действие как приказ.
ранее я свои приказы реализовал так
1. создал объект/класс/понятие/сущность "приказ"
2. в нём лежали объекты "диалог". Диалог служил для запроса данных от пользователя, он содержал список типизированных полей, которые визуально могли быть тектовыми полями или комбиками. Пользователь заполнял их и нажимал "Ок" - тогда все введённые значения сохранялись в коллекцию переменных на уровне приказа и диалог закрывался.
3. каждый диалог имел наборы sql-команд - До и После диалога. Каждая команда имела параметры и перед тем как выполнить команду производился поиск одноимённых элементов в коллекции переменных и среди параметров. Если были совпадения, то значения переменных присваивались sql-параметрам. После этого sql-команда выполнялась. Если это был select, то всё, что вернулось помещалось опять же в коллекцию. Диалоги тоже умели видоизменяться в зависимости от переменных из коллекции. Таким образом была возможность выполнить любую последовательность действий в базе данных, часть параметров запрашивая у пользователя, часть извлекая самостоятельно.
4. во время выполнения приказа начиналась транзакция, которая тянулась всё время выполнения приказа и если юзер на последнем диалоге нажимал Ok, то всё хозяйство коммитилось и переменные выливались в шаблон Excel файла, который был вещественным результатом приказа.

новые приказы могли создаваться по месту - без участия разработчика

всё это работает в принципе и по сей день, однако, есть ряд непреодолимых трудностей при такой схеме:
1. система базируется на транзакциях - а не всякая БД поддерживает savepoint'ы для того, чтобы можно было сделать что-то типа визарда с кнопками "далее" и "назад"
2. практически невозможно удалить приказ

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

а ключевой вопрос - как правильно реализовать систему "юзер издаёт приказ, изменения производятся в БД"?

[Вад]

Я правильно понимаю, что жизненный цикл приказа выглядит как цепочка состояний? Есть черновик (необязательное состояние), есть приказ, находящийся на рассмотрении, есть утверждённый и есть отклонённый (как вариант, возврат к черновику или "на рассмотрении"?).
Потому что воможна ситуация, когда, скажем, в приказе ошибка, и шеф не подпишет - что тогда с приказом делать?
В общем, как мне кажется, нужно выделить состояния у документа и работать с ними, в рамках отдельной транзакции изменяя состояние.

[Dimka]

neco, ты опять влезаешь в детали реализации. Начни лучше с описания предметной области. Что такое приказ? Что в нём должно быть (наверняка, некое действие и его исполнитель как минимум, а то и несколько действий и исполнителей, а также могут быть сроки и т.п.).

С Вадом согласен.

[neco]

2Вад:
По жизненному циклу приказа, Вы меня поняли правильно.
Но только в ответ на это предложение

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

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

к примеру, есть Работник и у него поле Отдел.
1. Создаём приказ на перевод из одного отдела в другой - берём данные по сотруднику и позволяем пользователю их изменить.(state=draft)
2. Приказ готов - пользователь хочет распечатать и отнести шефу. При этом (в зависимости от типа приказа) изменения либо должны стать видны другим пользователям (примениться к БД), либо нет (сохраниться где-то внутри приказа и ждать)
3-а. Приказ утверждён. Приказ становится утверждённым (если он не был применён в предыдущем пункте к БД - то применяется)
3-б. Приказ отменён. Приказ откатывается (если он был применён - необходимо всё вернуть назад)
4. возможный случай - когда спохватились и надо приказ удалить (бумажку порвать можно, а в БД как?) - при реализации пункта (3-а) в общем-то те же действия.

Вопрос - как внутри объекта Приказ хранить виртуальные изменения, которые потом можно применить к объекту Работник или, если уже было применено, эти изменения вернуть назад?

2dimka

neco, ты опять влезаешь в детали реализации.

но ведь меня именно реализация и интересует...

Начни лучше с описания предметной области. Что такое приказ? Что в нём должно быть (наверняка, некое действие и его исполнитель как минимум, а то и несколько действий и исполнителей, а также могут быть сроки и т.п.).

Ммм...
не вполне понимаю о чём речь - можно пример описания предметной области чего-нибудь?

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

[Вад]

А, то есть, ты хочешь определить способ, которым изменяется состояние объекта "работник" при вступлении в силу того или иного приказа? Мне кажется, стоит типизировать приказы: перевод, увольнение, повышение, что там ещё может быть. Для возможности отката достаточно, на мой взгляд, хранить всю серию приказов и в приказе иметь тип совершённого действия и информацию о нём (например, если перевели - то откуда и куда). Тогда откат будет осуществляться применением обратной операции к сущности. Если какой-то приказ удаляется - наверное, необходимо производить откат его действия. Как-то так

[neco]

спасибо за диалог - в его процессе я начинаю понимать положение всё лучше и лучше.

на данный момент в таблице emp столько вот полей:

SELECT a.id, a.first_name, a.last_name, a.patronymic, a.company_id,
       a.position_id, a.payment_type_id, a.schedule_id, a.money,
       a.currency_id, a.time_cell_id, a.driver_category_id, a.ila_start,
       a.ila_end, a.ila_probation_end, a.insurance_id,
       a.education_status_id, a.family_status_id, a.military_status_id,
       a.sex_id, a.birthday, a.note, a.file_id, a.live_location_id,
       a.job_town_id, a.last_vacation_date, a.vacation_days, a.bonus_id,
       a.passport_number, a.producerk, a.give_date, a.expire_date,
       a.rnn, a.sik, a.nationality_id, a.citizenship_id, a.homephone,
       a.workphone, a.mobilephone, a.email, a.is_seasonly, a.is_expat,
       a.visa_type_id, a.visa_start, a.visa_expire, a.arrival_on,
       a.departure_off, a.tco_wa_eff, a.tco_wa_end, a.fired_date
  FROM emp a

ещё есть связанные таблицы, которые содержат поле emp_id (образование, менеджера, местоположения, семья, контакты, timesheet) - т.е. довольно много и жёстко кодировать приказы мне как-то не хотелось. понятно, что можно их как-то сгруппировать, но всё-таки нет уверенности, что всё так и будет оставаться - а если сегодня мы жёстко внутри что-то пропишем, а завтра нас попросят добавить ещё какое-то поле в старый приказ - что тогда случится со старыми, уже изданными, приказами? как они будут откатываться? хотелось бы, чтобы информация внутри приказа была самодостаточной для самоудаления - чтобы сам приказ не производил жёстко запрограммированных действий над сущностями...

что-то назревает какая-то идея с типа-плагинами - приказ бы состоял из библиотеки, xml и xsl файла. Библиотека бы отвечала за действия над объектом и диалогом с пользователем. Xml хранил бы изменения и информацию для отмены (типа журнал приказа - библиотека всё в него должна скидывать) и хранился бы для каждого отдбельного приказа свой, а xsl определял бы внешний вид xml'а...
только вот изменения библиотек тут как-то не очень смотрятся - можно конечно новые версии библиотек заводить. Т.е. каждая библиотека умеет гонять приказ туда-обратно и при прогоне "туда" пишет в xml версию, а потом для отката ищется именно эта библиотека.

туманности какие-то есть - продолжаю думать. если мысли (отличные от "this is all shit. good bye!") есть, пожалуйста, подкиньте, ладно?

[Вад]

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

[Dimka]

neco, судя по симптомам, подходит шаблон проектирования (design pattern) Команда (Сommand) + сопутсвующие шаблоны хранения состояний и организации транзакций. Книжку Гаммы с товарищами "Шаблоны проектирования" читал? Каждый приказ (как объект) будет содержать информацию о проведении изменений в состоянии объекта воздействия (скажем, работника). При помощи вспомогательных решений можно организовать временное хранение прежних или ещё неутверждённых состояний объекта воздействия. Структура БД должна соответствовать структуре используемых объектов и отношений между ними (если это возможно, иначе придётся городить неочевидные абстракции, что ухудшит сопровождаемость системы в будущем).

Далее, как Вад сказал, на каждый тип воздействия заводится описывающий его класс объектов -- разновидностей приказа. Можно выстроить иерархию наследования свойств приказов.

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

но ведь меня именно реализация и интересует...

Реализация в программной системе модели предметной области. Если ты этой модели не знаешь, то что же ты реализуешь?! Предметную область ты знаешь, но только явно её не выделил.

не вполне понимаю о чём речь - можно пример описания предметной области чего-нибудь?

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

Спонтанно придуманная модель. Допустим, полив клумбы под окном:

Сущности:

клумба, пенсионерка, погода.

Поведение:

Погода меняется по своим внутренним законам, оповещая об изменении своего состояния всех заинтересованных: в нашем случае клумбу и пенсионерку. (Либо шаблон проектирования "Обозреватель", либо шаблон проектирования "Доска объявлений" -- на усмотрение разработчика.) Состояние погоды сложное... Допустим: время года (зима, весна, лето, осень), температура (холодно, тепло, жарко), осадки (есть, нет).

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

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

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

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

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

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

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

[neco]

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

объектно-ориентированный анализ и шаблоны изучаю по сайту http://ooad.asf.ru - там есть шаблоны из упомянутой книжки. самой книжки у меня нет, но есть "рефакторинг с использованием шаблонов" Кериевски.
хочу текущий проект провести с ОО анализом, но к сожалению на том сайте очень мало примеров разных моделей (особенно интересует переход от use case к design model). искал вот примеры и обнаружил данную ветку форума.

[Dimka]

neco, тут посмотри: https://club.shelek.ru/viewfiles.php?id=20

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

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

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