Нужны советы по проектированию wizard'а

[neco]

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

класс Order это вроде как и есть визард.
предполагается, что Caller умеет на основании ReqParameters спросить у юзера всё, что надо и это "что надо" передать назад визарду при выполнении CompleteStep (в принципе и при CancelStep тоже, потому как часть параметров юзер может заполнить, а потом захотеть вернуться на предыдущий шаг "просто посмотреть").
в основном интересовало как разорвать поток выполнения внутри визарда и как хранить (когда сохранять и когда читать) данные в xml. Поэтому сосредоточился на этих моментах (их вроде удалось понятно отразить на схеме или нет?), но сам workflow здесь уже как-то некуда воткнуть.
т.е. предполагаю, что визард будет ветвлистым и свой путь будет хранить в связном списке, к примеру. следовательно, перед шагом switch to next step на основании имеющихся в xml данных будет как-то приниматься решение о том, какой Step-класс создавать и ставить следующим в списке. Так же, где-то должна быть логика того, как, при возвращении назад и изменении ранее выставленных параметров, будут изменяться последующие ранее совершённые шаги (некоторые шаги могут уничтожиться, в некоторых могут сброситься параметры.
И вот куда эту дополнительную логику включать, что-то не пойму. Может стоило использовать диаграмму кооперации?

И вообще, в рамках задачи - схема получилась г..но или пойдёт?
Спасибо!

[Алексей++]

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

[neco]

а если (как в моём случае) визард должен менять будущие шаги в зависимости от предыдущих? та же галочка hide advanced configuration это частный случай того, что я хочу.
а что за "нужные методы" вы имели в виду? можно пример?

[Алексей++]

neco, что значит - будущие шаги ? Структура заполняется по предыдущим шагам, а каждый новый шаг "смотрит" в структуре, что там ранее было введено и делает, что нужно. А насчёт методов, например (не знаю, только, каой язык исповедуешь Я на с++ )

Код:

struct s_MyWizData
{
  bool m_bAdvanced;
  ...
  ...

  s_MyWizData()
  {
     //инициализация
     //....

     SetDefaults();
  }

  void SetDefaults()
  {
     //....
  }

  //что нужно сделать, если юзер отменил шаг № x
  void BackFromStep(int nTheStepToReturnFrom)
  {
     switch(nTheStepToReturnFrom)
     {
          ...
     }
  }

  //что нужно сделать, если юзер завершил шаг № x
  void AfterStep(int nTheStepThatContinued)
  {
     switch(nTheStepThatContinued)
     {
          ...
     }
  }

};

вот примерно так я бы поступил

[Dimka]

Алексей1153++, вопрос о проектировании, а не о программировании. Не лезь со своим C++

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

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

С точки зрения реализации в классах и объектах, по-моему, неплохо подойдёт шаблон проектирования "Состояние" (State), в котором состояния - это шаги (экраны) мастера. Он же даёт объяснение, как разорвать поток управления.

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

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

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

[Алексей++]

dimka, а буду лезть И дело не в языке, а в подходе

[Sla]

Алексей1153++, well, well, well
Ты сразу бросаешься писать код.
neco подошел к теме корректно - создание модели, а только затем кодирование.

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

100% согласен.
В случае появления нового состояния, его легко добавить в существующий список

И вообще, в рамках задачи - схема получилась г..но или пойдёт?

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

[zubr]

neco, как вариант:
1. Каждый шаг визарда сделать в виде объекта (класса) с возможными методами, свойствами, связями (вот отсюда и надо начинать делать диаграмму развивая ее связями с другими шагами)
2. Все данные шага будут сохраняться в соответствующий объект
3. Сохранение данных в XML по окончании работы визарда (когда юзер нажал Ok)

[neco]

Спасибо за советы!
Алексей1153++, приблизительно так я и реализовывал мастера раньше - мне кажется, всё-таки это не очень дальновидный подход - каждый новый мастер надо проектировать заново.

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

Надо полагать, что под стрелками, направленными справа налево, ты подразумевал именно возвраты.

ну в книжках рисуется пунктиром, а в программе (какая-то малюсенькая прога, UMLPad что ли) не было пунктирной линии.
вообще, намучался я с поиском нормального редактора - большие надежды возлагал на Rational Rose, но почему-то (у меня 2003) там всё так убого оказалось - что-то серьёзное делать на нервы изойдёшь.
Сейчас дома уже наверное скачался NetBeans шестёрка - вечером попробую на нём.

2zubr:
1. это и есть шаблон state.
2&3 - зачем ещё один объект - почему не сразу в XML? у меня xml и есть промежуточное хранилище - результатом визарда будет запись в БД. В любом случае, это механика.

[Dimka]

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

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

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

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

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

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

[neco]

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

ну да разделяю - это два разных класса. Класс Wizard, а внутри него абстрактный класс Step и куча его наследников - реальных шагов. Класс визард имеет приватное свойство CurrentState (CurrentStep точнее), которое должно изменяться каждым шагом самостоятельно. Т.е. при нажатии на кнопку Next и вызове CompleteStep сам шаг решает, какой шаг будет следующим. Следовательно, при большом количестве шагов, избавляемся от громоздкой условной логики внутри Wizard'а (при линейной логике условностей вообще не будет).

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

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

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

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

[neco]

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

[Sla]

а как такой вариант?

[neco]

Sla, да тоже самое

я не понимаю, что даёт диаграмма состояний для понимания как будет реализовываться внутренняя логика работы моего визарда.
всё-таки по-моему диаграмма состояний это не то... не для этого случая...
Шаблон State это да, но диаграмма тут нужна другая. Может сразу к диаграмме классов перейти?
Завтра с утра попробую...

[Sla]

neco, ты хочешь получить "нечто универсальное"
Имея граф переходов (состояний) достаточно легко строится wizard.
Достаточно только описать "реакцию" и точки перехода.

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

[Dimka]

ну да разделяю - это два разных класса. Класс Wizard, а внутри него абстрактный класс Step и куча его наследников - реальных шагов. Класс визард имеет приватное свойство CurrentState (CurrentStep точнее), которое должно изменяться каждым шагом самостоятельно. Т.е. при нажатии на кнопку Next и вызове CompleteStep сам шаг решает, какой шаг будет следующим. Следовательно, при большом количестве шагов, избавляемся от громоздкой условной логики внутри Wizard'а (при линейной логике условностей вообще не будет).

Ты думаешь не о проекте, а о его реализации. То, что класс Step реализует состояние мастера в смысле шаблона проектирования "Состояние" (State), это понятно. Но это лишь способ программной реализации той основной идеи, что мастер меняет свои состояния, и что направление смены текущего состояния зависит как от входной информации, так и от текущего состояния.

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

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

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

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

[neco]

Спасибо всем большое.
Я вас сбиваю тем, что сам не до конца разделяю некоторые понятия.
В начале, я начал про визард, а потом незаметно (для себя) перешёл к общему workflow приказов - а это совершенно разные вещи.

Накидал вот такую схему workflow (сам не знаю почему, но начал в Activity диаграмме - оказывается там всё тоже, что и в State):

честно говоря, очень доволен результатом, поскольку теперь реально вижу, что будет общим, а что будет лежать в отдельных приказах (фактически только ApplyChanges, RevertChanges и EditOrder - он же тот самый визард, о котором речь шла в начале). Таким образом, весь этот workflow отделился от внутренних Step'ов во время заполнения параметров и теперь уже не будет неопределённостью маячить в голове

[Dimka]

neco, и эта диаграмма синтаксически некорректна.

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

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

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

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

Ромбики не используются для обозначения условных переходов, они используются лишь для ветвлений. Здесь синтаксическая ошибка.

Диаграммы не нужно слишком усложнять: 3-7 основных элементов, основные переходы; остальное детализируется в других диаграммах более мелкого масштаба.

Мне кажется, что ты попытался изобразить следующее.

Жизненный цикл приказа начинается, когда появляется соответствующая инициатива - это событие перехода из начального состояния (фиктивного, оно вне жизненного цикла приказа, приказа ещё нет) в состояние "Проект". На этапе проекта происходят все политические баталии, обсуждения, согласования, изменения, откладывания "под сукно" и возвращения к рассмотрению. Из этого состояния есть два пути: когда проект приказа согласован и принят (событие), приказ начинает действовать - переходит в состояние "Действует"; либо проект приказа окончательно отклоняется, и когда он отклонён (событие), он отправляется в мусорную корзину, на чём его жизненный цикл заканчивается. Со временем появляются новые приказы, отменяющие старые, поэтому, когда происходит отмена приказа (событие), он переходит из состояния "Действует" в некое другое состояние. Я назвал его "В архиве", ты назвал его "CancelledState" и свёл к нему как отменённые, так и отклонённые приказы, но, по-моему, более точно говорить об архивном хранении, для возможности посмотреть нормативную базу по старым делам. Возможно, в твоём случае и отклонённые проекты приказов тоже хранятся в архиве "в назидание потомкам" - тогда нужно проекты тоже переводит в архив. Этот период когда-нибудь заканчивается, поэтому я добавил условный переход по триггеру-таймеру к окончанию жизненного цикла приказа.

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

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

[neco]

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

Насчёт состояний и событий - я видимо реально всё напутал. наверное везде, где у меня небольшой прямоугольник сине-белого цвета, там должна быть просто надпись на стрелке.
А что делать с жёлто-синими прямоугольниками? Они у меня означают некое ключевое действие - в моём случае это применение или отмена действия приказа на сотрудника. Т.е. если приказ об увеличении зарплаты до 2000 баксов, то после шага ApplayChanges в БД значение поля должно будет измениться на 2000. А после шага RevertChanges, зарплата опять вернётся в предыдущему значению.
Как мне такое ключевое (важное для меня как разработчика) действие изобразить? в комментах только?

А с ромбиками что делать?

Может всё-таки это у меня диаграмма деятельности, а не диаграмма состояний получилась? Может если заменю все XXXXXState на Set to XXXXXState, то получится то, что нужно?

[Dimka]

по-моему, не совсем корректная параллель - приказы и проекты.

Проект - это то, что у тебя названо черновиком ("DraftState"). Лучше, наверно, было назвать "В проекте", а не "Проект". Можно и "Черновик".

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

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

Но ничего вечного не бывает. Лучше так сказать: информация будет храниться в программном комплексе до окончания времени его эксплуатации, когда он из-за морального старения будет заменён более новой системой. Случится это, думаю, в ближайшие 20 лет. Концом может быть и ликвидация организации. Если реалистично взглянуть на вещи, то вечного не бывает Подумать о том, как из системы будет удаляться старая информация, нужно. С достаточно редкими приказами ещё терпимо, но в других системах свыше 99% архивных данных будут приводить к тому, что база данных будет бесполезно нагружать сервер, потом, возможно начнётся торможение работы вплоть до отказа.

Я бы всё же порекомендовал рассмотреть условия удаления старой и ненужной информации. Не обязательно это должна быть архивная БД. Можно записать в условиях, гарантирующих безотказную работу системы, пункт о том, что система способна эффективно работать с не более чем N приказами, хранящимися в базе данных, и что в случае превышения этого количества рекомендуется предпринять такие-то меры по очистке базы данных. Т.е. заказчик/пользователь системы должен отчётливо понимать, что пределы возможностей есть. Пусть они большие и не вызывают беспокойства, но явно указать на них никогда не вредно.

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

Да, наверно событие "Отменить" не совсем удачно. Ты говоришь, что приказ не меняет своего содержания после выхода новых приказов - логично. Одним приказом Васю Пупкина перевели в отдел А, затем другим приказом того же Васю Пупкина перевели в отдел Б. Второй приказ перекрывает действие первого приказа в отношении Васи Пупкина. Это я и подразумевал под событием "Отменить". Но, наверно, один приказ может лишь отчасти затрагивать действие второго. В этом случае состояния "Действует" и "В архиве" становятся неразличимы. Даже явная отмена приказа есть новый более поздний приказ вида: "Считать приказ... недействительным." Например, так документы обрабатываются в SAP R\3...

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

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

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

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

Тут уж надо определиться.

Насчёт состояний и событий - я видимо реально всё напутал. наверное везде, где у меня небольшой прямоугольник сине-белого цвета, там должна быть просто надпись на стрелке.
А что делать с жёлто-синими прямоугольниками? Они у меня означают некое ключевое действие - в моём случае это применение или отмена действия приказа на сотрудника. Т.е. если приказ об увеличении зарплаты до 2000 баксов, то после шага ApplayChanges в БД значение поля должно будет измениться на 2000. А после шага RevertChanges, зарплата опять вернётся в предыдущему значению.

В какие моменты что меняется в БД, а что в ОЗУ - это пока ещё рано обсуждать. Если будет грамотно составлена диаграмма состояний приказа, то каждый переход из состояния в состояние будет означать запуск какого-либо действия: либо автоматического, либо мастера или диалогового окна, которые позволят пользователю ввести нужную информацию и вообще сообщить системе о том, что произошло событие. Например, посовещались и решили утвердить приказ: оператор запускает соответствующий мастер, поддерживающий процедуру перевода приказа из черновика в действующий со всеми сопутствующими операциями по организации исполнения приказа -- так система узнаёт о принятом решении и обеспечивает перевод приказа из одного состояния в другое.

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

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

Может всё-таки это у меня диаграмма деятельности, а не диаграмма состояний получилась? Может если заменю все XXXXXState на Set to XXXXXState, то получится то, что нужно?

У тебя тогда появятся деятельности вида "Начальник думает". Это деятельности, но начальника, а не системы. Ты же описываешь программную систему, а не всю работу твоей организации. Т.е. когда программа будет пытаться приказывать начальнику: "Думай и введи..." - это будет неудобная система, поскольку ты пытаешься начальника впихнуть в рамки алгоритма из-за того, что не совсем понимаешь, как разорвать поток управления. Это отчасти годится для армии, но в большинстве случаев не годится. Когда надо, начальник должен иметь возможность сам выбрать в программе тот вид дейятельности, который ему сейчас нужен, обратиться к тому приказу или проекту приказа, который его сейчас интересует, и этот приказ должен загрузиться в его текущем состоянии и предложить варианты дальнейших действий: "Отклонить", "Принять", "Согласовать", "Отказать в согласовании". При выборе каждого такого пункта для системы происходит событие, и система запускает соответствующую процедуру принятия, отклонения, согласования, исполнения и т.д., возможно, поддерживаемую мастером.

[Dimka]

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

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

[neco]

Но ничего вечного не бывает

разумеется.
и безграничных ресурсов тоже не бывает.
под "вечностью" подразумевается жизнь системы до следующего апгрейда.
меня вполне удовлетворит, если системы хватит на пять лет без обслуживания.
а вообще чистка данных, которые вводятся в ручную - это опасно, поскольку юзер часто говорит "ой" (старая версия программы работает уже почти год и со спецификой ведения дел на этом предприятии я уже более-менее знаком). поэтому в данном случае я против удаления чего-либо из базы - проще пометить как удалённое и потом в поиске фильтровать.
у меня на слуху есть опыт системы, в которой просто сделали каскадные constraint'ы и при удалении удалялось вообще Всё связанное с объектом. Потом столько возмущений было.
возможность отмены юзеры вообще видят только в виде "пусть в течении недели данный приказ можно будет отменить" и при этом ситуация "передумать через 7 дней" всем кажется реальной, а ситуация "передумать через 8 дней" - невозможной и означающей ручную правку БД или чего-нить в этом духе.
в этом плане мне нравится подход 1С бухгалтерии в отношении проводок - неважно когда была совершена проводка, её всегда можно отменить. Да, нерадивые бухгалтера отменяют старые операции и не перепроводят последующие, но это уже их личные проблемы, связанные с непониманием того, как работает система.

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

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

кроме того, думаю, надо предусмотреть такую ситуацию:
1. приказ №1 выставляет (первый раз) зарплату в 1000.
2. приказ №2 выставляет вместо 1000 1500.
3. приказ №3 выставляет вместо 1500 2000.
теперь приказ №3 "помнит" старое значение 1500 и новое - 2000.
как-то надо сделать так, чтобы в случае последовательной отмены приказов №3 и №2 и повторного проведения приказа №3 в нём, в качестве старого значения сохранилось значение 1000 рублей.
получается, что сохранение старых значений надо делать в шаге CompleteOrder (раньше я думал, что в процессе редактирования буду записывать).

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

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

[Sla]

делопроизводство - вещь темная
Твой пример сродни применению правовых решений (законов, указов и пр.)
1. Закон
2. Добавления к закону,  или отменяющие действия пп NNN, или  внесение дополнительных, или переформулирующие некотрые пункты
3. Добавление (см. п. 2)
и т.д.
Самый последний Закон - об отмене Закона = архив.
Но это уже на уровне Приказов, уже принятых.
В твоем случае.
Wizard подразумевает действия на уровне принятия приказа - создание, редактирование, утверждение и т.д.
После окончания "начального" этапа - Вступление в силу.

[Dimka]

я добавил ограничение на отмену - можно отменять только последний приказ. но после отмены последнего можно будет отменить предпоследний и так далее до самого первого. а затем исправить что-то в первом и повторить (перепровести) все последующие приказы (они ведь не удалены - просто в состоянии Cancelled, данные заново вводить не надо) и придти к текущему моменту.
иначе нельзя обойти ситуацию с наложением приказов на одни и те же атрибуты:
1. приказ №1 выставляет зарплату вместо 1000 в 1500.
2. приказ №2 выставляет зарплату вместо 1500 в 2000.
3. отмена приказа №1 возвращает значение 1000 для поля зарплаты и получается логическое нарушение.

А это реальная ситуация -- отменять первый приказ, сохраняя второй и последующие?

[neco]

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

[Dimka]

сейчас собираюсь на курсы по RUP'у, надеюсь после реальных примеров диаграмм, мои вопросы станут более правильными.

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

[neco]

Однако всё же этот проект загнулся. ))
Если кому интересно - на курсы по РУПу я всё же съездил и не могу сказать, что бесполезно. Да, не совсем всё понял, но ценным оказалось понимание того как бизнес диктует бизнес-модель, оттуда вытекают use case'ы, а из них требования, которые самым явным образом помогают разработке, тестированию и в конечном итоге успешному завершению проекта. Всего успешно завершённых пока три проекта за полтора года.
Однако, всё же испытываю сложности с проектами, в которых требований как таковых нет - т.е. программирование загодя. Не могу заложить достаточную гибкость в код. Но это уже тема для отдельного топика.

[Dimka]

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

И, надо заметить, прелюбопытнейшая тема

[Вахмурка]

Однако всё же этот проект загнулся. ))
Если кому интересно - на курсы по РУПу я всё же съездил и не могу сказать, что бесполезно. Да, не совсем всё понял, но ценным оказалось понимание того как бизнес диктует бизнес-модель, оттуда вытекают use case'ы, а из них требования, которые самым явным образом помогают разработке, тестированию и в конечном итоге успешному завершению проекта. Всего успешно завершённых пока три проекта за полтора года.

Use Case проще всего связывать с макетом пользовательского интерфейса, а интерфейс согласуется с заказчиком. Всему этому предшествует определённый этап, когда Use Case совсем "общие". Я пользуюсь таким подходом.

[lapulya]

Dimka, это

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

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

Кстати, есть достаточно книг, где рассматривается именно адаптация методологии под различные проекты (размер, зрелость команды, длительность, новизна, разработка с 0 или доработка существующего ПО).

Вахмурка Вахмурка,

Use Case проще всего связывать с макетом пользовательского интерфейса, а интерфейс согласуется с заказчиком

UI конечно же согласовывается с заказчиком, но этого мало, необходимо в первую очередь понять:
1. за что платят деньги
2. какой(~ие) БП или их части надо автоматизировать
3. какая должна быть функциональность ПО (т.е. что именно ПО должно делать, т.е. какие функции система должна предоставить "актерам")
4. какой должен быть UI
последовательность согласования именно такая.

neco,

... проектами, в которых требований как таковых нет...

Если требований, как таковых нет, я бы даже за клавиатуру не сел. В данном случае, надо браться за лист бумаги и ручку и идти:
1. Человеку, который платит деньги (нужно, что бы вы поняли за что он платит деньги)
2. Человеку, который прекрасно знающий автоматизируемый БП (или знающий как надо изменить существующий БП). Выясняем БП (вот тут и должна быть выявлена и составлена диаграмма состояний приказов, которая к проектированию реализации /паттерны, классы, абстракции и т.д./ отношения не имеет). С этим человеком мы вникаем в БП и формируем UC (это сценарии использования системы)
2.1 Проверка на то, что результаты 2 коррелируют с 1
3. Человеку, который является/будет являться ключевым пользователем системы. Детализируем UC и выносим, рассматриваем и опять таки детализируем отдельно все функции системы (не забывая и про интеграцию их в единое целое, т.е. проверяя полноту покрытия и непротиворечивость)
3.1 Проверка на то, что результаты 3 коррелируют с 2 и как следствие с 1
4. На основе 3 проектируем UI формы с переходами и т.д.
4.1 Проверка того, что UI покрывает весь функционал
5. Составляем SRS и согласовываем

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

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

Программист берет в руки клавиатуру
1. клавиатуру в середине пункта 4 (когда все функции достаточно точно выявлены и описаны, не вылизаны, но понятны так, что ПЕРЕделывать не придется, а вот ДОделывать - легко, а также разработан UI). Пишет (растит мышцу) реализацию для четко локализованных и продуманных структурных элементов (безусловно копаясь в своей песочнице реализации и имея право на шаг в право и шаг влево, но только в пределах утвержденных интерфейсов)  

К концу этапа 5 имеем прототип со всеми критичными для бизнеса UI формами, модулями (скелет, сосуды, нервные окончания и кожу, но почти без мышц, сердца и мозга).

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

ЗЫ
тестирование и не функциональные требования опущены.

[Dimka]

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

А у меня что написано?

2. какой(~ие) БП или их части надо автоматизировать

А какое отношение БП имеет к Use case?

[lapulya]

Dimka,
у тебя написано вот что

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

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

...хотя есть его адаптации для более мелких...

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

А какое отношение БП имеет к Use case?

как это какое? а для чего вы будете писать кейсы? Вот вы представьте себя в роли аналитика, он приходит на предприятие и его сразу ведут к ключевому пользователю и он сразу пишет кейсы, так что ли? Да он понятия не имеет пока о том:
1. как работает предприятие (даже схожие предприятия, допустим автодилеры, легко могут иметь разные БП)
2. ключевые сущности и их связи (это называется модель/словарь предметной области)
3. в чем заключается деятельность персонала предприятия (действия, инструменты, цели, результаты)
4. где узкое место, подлежащее автоматизации (это очень важно, поскольку мы можем автоматизировать работу сотрудника, которую он один, будет выполнять на 15% быстрее, а все остальные 2000 человек, даже и не заметят внедрения системы, я сильно утрирую но мысль должна быть ясна)
5. что именно должно войти в скоуп, а что нет (это очень важно, поскольку тот, кто платит деньги, платит их за совершенно конкретную область своего бизнеса, т.е. за автоматизацию какого-то (возможно нескольких или наоборот только части) БП, а для того чтобы это понимать опять нужны БП)

Поэтому, пока не описаны БП предприятия ни один нормальный аналитик не возьмется писать кейсы. Да, и не забывай, что одна из приоритетнейших задач аналитика это полнота покрытия!!! если сразу писать кейсы, то вероятность оставить без внимания часть БП, подлежащего автоматизации, очень сильно возрастает (проверить покрытие без описания БП почти невозможно), да и страссировкой будут проблемы, поскольку они будут отслежены только на нижних уровнях (т.е. на уровнях кейсов и ниже, а все что с верху уже не трассируемо).

На самом деле я еще пытался заострить внимание на том, что работа аналитика и архитектора совершенно разная (хотя это и не значит, что выполнять эти роли не может один и тот же человек). А вот топик стартер на протяжении обсуждения (ну первые 2/3 точно) слил все в одну кучу, поэтому и возникла неразбериха (я про паттерны и т.д.)

[Dimka]

но ты как бы уже говоришь, что это и не руп что ли... (иначе просто противоречие с предыдущей цитатой).

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

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

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

Так что считаю это лирическое отступление пустым флеймом.

Цитировать
А какое отношение БП имеет к Use case?
как это какое? а для чего вы будете писать кейсы? Вот вы представьте себя в роли аналитика, он приходит на предприятие и его сразу ведут к ключевому пользователю и он сразу пишет кейсы, так что ли?

А мне и представлять не надо. Я работал бизнес-аналитиком в проектах. Самые крупное предприятие, с которым имел дело в этом своём качестве, это ЛМЗ.

Поэтому, пока не описаны БП предприятия ни один нормальный аналитик не возьмется писать кейсы. Да, и не забывай, что одна из приоритетнейших задач аналитика это полнота покрытия!!! если сразу писать кейсы, то вероятность оставить без внимания часть БП, подлежащего автоматизации, очень сильно возрастает (проверить покрытие без описания БП почти невозможно), да и страссировкой будут проблемы, поскольку они будут отслежены только на нижних уровнях (т.е. на уровнях кейсов и ниже, а все что с верху уже не трассируемо).

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

[lapulya]

Dimka, что такое большой руп? куда там надо зарываться? ИМХО голословно, то что рейшенл предлагает неисчислимые артефакты, миллионы ролей и т.д. на все случаю жизни о методологии, как таковой ничего не говорит (в том числе и о ее сложности и объемности), рэйшнл предлагает свою "реализацию" методологии, которая предусматривает все мыслимые и немыслимые сущности, роли и активности. Это как о налогообложении говорить... есть общая схема налогообложения, а есть упрощенка (это разные реализации налогообложения, не много неточно, но суть понятна). Если я работаю на упрощенке, то зачем мне знать все тонкости общего налогообложения (не говоря уж о том, что и сами бухгалтера, работающие на общей схеме, очень часто знают только часть, а именно только, что они используют в работе).

Дайте мне 2 часа (всего 2 часа) и я за это время проведу лекцию где изложу методологию (ВСЮ!!!, а также всю "реализацию" методологии для маленького проекта, маленьким считаю проект от 2 недель, до 2 - 3 месяцев, силами 2 - 4 человек).

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

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

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

И где у меня написано, что применен не итерационный подход? Как раз наоборот... итерационный (что косвенно подтрерждается п. 2.1 и 3.1) с упреждающей разработкой архитектуры... Про пртотипирование у меня все написано:
1. И тех. реализация сложных механизмов
2. И про UI
3. И про логику (на ранних стадиях это именно проверки покрытия и трассировки, на поздних это они же + прототипы приложения)

[Dimka]

lapulya, большая просьба: если ты чужие слова используешь лишь в качестве повода "толкнуть речь", то не задавай вопросов, обходись утвердительными предложениями, на худой конец делай вопросы риторическими, а то у меня постоянно возникает сомнение, вдруг и правда меня о чём-то спрашивают; если же собираешься разговаривать, то потрудись внимательнее читать собеседников, чтобы не задавать лишних вопросов. В частности, внимательно прочитать ту часть моего поста, где я говорил про опыт.

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

И что? Это отменяет необходимость знания и понимания автоматизируемого БП

Странный вопрос. Я такого не говорил, ты такого не говорил. Отчего тогда вопрос? Или это тоже из области "пламенных речей"?

Как можно писать кейс и не понимать что он делает, кто актер и зачем его делают?

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

И где у меня написано, что применен не итерационный подход?

Я говорил исключительно о взаимосвязи use case и БП, а не о процессе разработки. Ещё раз: внимательно читай написанное.

[lapulya]

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

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

да, школ нет, а вот качественных (возможно местами, но в сумме они покрывают все) учебных пособий масса, было бы время и желания (второго как правило достаточно). Лекцию я читаю на эту тему достаточно постоянно, поскольку моим проектным командам и клиентам далее так придется работать, поэтому надо, чтобы все были в "теме". Более того, я занимался внедрением руп в 2 организациях, разработчиках ПО (в одной был полный провал, но это отдельная тема... там кстати образно говоря начали писать кейсы без понимания БП , но не по моей вине, я сделал все, чтобы этого не произошло )  как сотрудник, позднее в нескольких выступал как сторонний консультант. По методологии было выполнено море маленьких проектов (и всего около пяти средних, ТТХ год - полтора длительность, около 15 человек в команде со стороны исполнителя + около 12 со стороны заказчика).

у меня были перечислены шаги (в хронологической последовательности) хода выявления и анализа требований (необходимых для разработки ПО), в частности был у меня пункт 2, вот такой - "

какой(~ие) БП или их части надо автоматизировать

", на это был получен вопрос

А какое отношение БП имеет к Use case?

на это вопрос я дал исчерпывающий ответ - если коротко, то на базе описания БП строится кейс (и куча доводов).

Lapulya,

Как можно писать кейс и не понимать что он делает, кто актер и зачем его делают?

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

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

Поменьше книжного догматизма, побольше практических соображений

В первую очередь я практик, и практики настолько много, что я с уверенностью могу сказать, что БП первичен всегда.

Я говорил исключительно о взаимосвязи use case и БП, а не о процессе разработки. Ещё раз: внимательно читай написанное.

Под методологией (процессом и т.д.) разработки понимается весь процесс (от кикофа, до подписи акта о передачи в поддержку), а не только писанина кода. Так что я не понял к чему замечание. И ход анализа (чтоб покороче записать)
1. Key stakeholder request, Business needs (targets)
2. BP
3. UC
4. SRS, UI
и далее итерационный (если проект большой, некоторые шаги могут иметь несколько итераций).

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

[Dimka]

Вот именно!! "его интересы, роль и его видение БП", суда же еще и цели иииии -  это НЕ кейс, это БП

Use case - это диаграмма языка UML. В UML про БП не говорится, так что не надо телегу ставить впереди лошади. Есть несколько способов использования use case, в каждом из которых под case подразумевается что-то своё. Ещё раз: я использую диаграмму не для того, чтобы следовать канонам какой-то методологии, я использую диаграмму там, где её по соображениям наглядности использовать удобно для фиксации интересующей информации и для общения с представителями заказчика.

С этой точки зрения твоё утверждение:

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

бессмысленно. Так как ты в кучу мешаешь методологию и язык моделирования. В первом случае у тебя берётся state диаграмма как удобный элемент языка. Во втором случае ты в use case вкладываешь уже элемент методологии (что case как множество альтернативных сценариев не может возникнуть раньше понимания бизнес-процесса).

В первую очередь я практик, и практики настолько много, что я с уверенностью могу сказать, что БП первичен всегда.

А я в первую очередь прагматик. С той же уверенностью я могу сказать, что БП - это лишь концепция в голове аналитика, способ структуризации информации о реальности; в самой же реальности (на уровне пользователей и даже отдельных руководителей) порой никаких БП нет - это для них "птичий" язык. И проблема даже не в том, что аналитик может увидеть БП там, где до него никто этого БП не видел, а в том, что если люди думают вне рамок таких категорий, то они и действуют вне рамок этих категорий, и аналитику нужно в первую очередь понять внутреннюю логику действий этих людей, как она есть, их систему ценностей. Для этой цели строго держаться рамок какой-либо одной методологии вредно, но, взявшись применять какую-то методологию, уже нужно следовать её внутренней логике, чтобы получить результат. Подозреваю, что именно из-за отсутствия подобного понимания заметное число проектов автоматизации проваливается, когда ценности "эффективного менеджмента" автоматизаторов входят в конфликт с устоями и укладом жизни какого-нибудь старинного предприятия. Старые предприятия не столько "существуют, чтобы работать", сколько "работают, чтобы существовать".

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

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

[lapulya]

Use case - это диаграмма языка UML. В UML про БП не говорится, так что не надо телегу ставить впереди лошади. Есть несколько способов использования use case, в каждом из которых под case подразумевается что-то своё. Ещё раз: я использую диаграмму не для того, чтобы следовать канонам какой-то методологии, я использую диаграмму там, где её по соображениям наглядности использовать удобно для фиксации интересующей информации и для общения с представителями заказчика.

кейс - это понятие из концепции рупа, а не только кусок UML диаграмм (именно в таком смысле я и использовал термин кейс, а не о "яйцах и человечках со стрелками"), так что про телегу ты погорячился. И действительно, ты прав, диаграмма используется для лучшего описания и понимания, но кейс, как понятие рупа, используется при применении методологии (при этом uml может вообще не использоваться). А то что в uml нет БП (кстати, вроде во 2 версии стандарта они есть) к рупу отношения не имеет.

...Так как ты в кучу мешаешь методологию и язык моделирования. В первом случае у тебя берётся state диаграмма как удобный элемент языка. Во втором случае ты в use case вкладываешь уже элемент методологии (что case как множество альтернативных сценариев не может возникнуть раньше понимания бизнес-процесса).

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

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

"Птичий язык" это как раз кейсы, а вот с БП тут много проще (может не пониматься сам термин БП, но аналитик это легко обходит, главное общаться с клиентом на его языке). Любой (ну почти любой) сотрудник может сказать, что он делает, какой должен быть результат его деятельности, кому он нужен (ну как минимум кому он его передает  ), что он использует (речь про артефакты) для достижения целей, вот тебе и БП. Не бывает такого, что БП нет, он может быть неэффективным и т.д., но он есть и сотрудники могут о нем рассказать. Я согласен, что для достижения результата все средства хороши и зацикливаться на четком и неукоснительном следовании методологии не надо, но с другой стороны искусство аналитика заключается в том, чтобы выудить все ("все" это общее слово, в которое можно/нужно запихать огромный список) из скейкхолдеров  и при этом не взбесить их, тому есть куча рекомендаций (к рупу не относятся, ну кроме как разговора с заказчиком на языке заказчика, это так называемый софт скиллз). И вообще аналитик - это переводчик (я бы даже сказал, что дипломатия тут не последний момент) между сотрудниками заказчика и разработчика. А провалы в проектах по автоматизации... ммм я склоняюсь к другому выводу... очень слабое управление проектами (к рупу не относится), не зрелость команды (в том числе и не понимание методологии), очень плохое качество анализа (плохо выявлены и задокументированы требования, под час они даже не задокументированы, это ваще ппц) + игнорирование всех рисков.

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

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

На самом деле я еще пытался заострить внимание на том, что работа аналитика и архитектора совершенно разная (хотя это и не значит, что выполнять эти роли не может один и тот же человек). А вот топик стартер на протяжении обсуждения (ну первые 2/3 точно) слил все в одну кучу, поэтому и возникла неразбериха (я про паттерны и т.д.)

все же относится к проблеме обсуждаемой в теме (хотя и не соответствует теме)