Здравствуйте, уважаемые проектировщики!

Ситуация:
Я новичок в проектировании ПО, до сего момента только читал PEAA и GOF и практиковался на реализации некоторых паттернов. Недавно у меня появилась возможность почувствовать себя в роли проектировщика в создании небольшой системы учета заказов одной компании. Сейчас занимаюсь рисованием UML диаграмм, одна из которых (диаграмма деятельности+"плавательные дорожки") описывает алгоритм движения заказа по этапам, различные сценарии взаимодействия пользователей системы с заказом в зависимости от его типа и текущего этапа, условия перехода от этапа к этапу и так далее. В этой диаграмме я опустил мелкие ветвления, которые не важны для процесса в целом, но тем не менее корректируют небольшие участки алгоритма внутри этапов. В любом случае у каждого этапа всегда одинаковые входы и выходы.

Мои идеи:
1. В силу того, что логика всего процесса от составления заявки на оказание услуги до момента успешного оказания услуги будет впоследствии меняться и дополняться, у меня есть желание сосредоточить этот алгоритм в одном пакете классов, отделив его от более мелких алгоритмов внутри этапов.
2. Ветвления алгоритма, важные для процесса в целом, определяют несколько типичных сценариев протекания этого алгоритма. У меня таких сценариев получилось пять, но в будущем будет больше: до 10-15.
3. Логическую последовательность этапов и условия переходов от одного этапа к другому я предполагаю зашить в класс «бизнес-процесс». Все мои сценарии зашить в маленькие классы-стратегии (паттерн Стратегия), описывающие конкретную последовательность этапов. Каждый этап зашить в свой класс «этап» и в нем уже реализовывать всю логику взаимодействия объектов домена в пределах этапа.
4. идеи есть еще, но пока ограничусь этими.

Проблема:
1. Не изобретаю ли я велосипед? Если да – то ткните в нос типовым решением.
2. Стоит ли сосредотачивать логику бизнес-процесса в одном месте?
3. Декомпозицию логики бизнес-процесса на классы «бизнес-процесс», «сценарий» и «этап» я кратко описал – насколько она плоха/хороша и в каких ситуациях может себя повести (может, сейчас все просто, пока система мала)?

Очень надеюсь на конструктивную критику. Если появятся вопросы, могу снабдить пояснения UML диаграммами.

Вообще ЮМЛ не создан для моделирования БП так таковых. Он создан для моделирания\проектирования ПО.
Если хотите моделировать БП, то используйте IDEF0, ARIS, BPMN

Если мы говрим о моделировании логики работы ПО, то делаем так:
1. Рисуем ДВИ, потом каждый ВИ расписываем в виде сценария и(или) ДП\ДД
2. Рисуем ДК для каждого слоя ПО
3. Если нужно детализируем методы класов в виде ДД. Если нужно показать взаимодействие м\у классами, то используем ДП\ДКооп

Пока хватит.

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

В вашем случае наверное помимо БП, сценария и этапа, могут быть и такие аспекты, как владелец, входы, выходы, ресурсы и управление, цель процесса, события, сигналы ....

Для описания поведения наверное имеет смысл рассматривать диаграммы состояний (например жизненый цикл и т.п.)

Если мы говрим о моделировании логики работы ПО, то делаем так:
1. Рисуем ДВИ, потом каждый ВИ расписываем в виде сценария и(или) ДП\ДД

Я как раз так и сделал ранее. Сценарии прорисовались.

2. Рисуем ДК для каждого слоя ПО

А вот тут я и сел. У меня проблема не смоделировать бизнес-процесс (он достался мне как неизменяемая данность), а зашить этот бизнес-процесс в конкретные классы.

В моем предыдущем сообщении я несколько сумбурно даже сам себе представлял описанную декомпозицию - поэтому и обратился за советом. Поразмыслив, я пришел к немногим более простому решению:
1. Мой бизнес процесс (БП) - это последовательность множества заранее известных этапов взаимодействия сущностей БП (менеджеры, руководители, клиенты, заказы, поставщики, заявки, автомобили, грузы и так далее).
2. БП имеет несколько сценариев развития. Каждый сценарий - это уникальная последовательность этапов. Сценарии - воплощение паттерна Стратегия
3. На каждом этапе сущности БП обладают определенным поведением и имеют определенные ограничения. (Поясню: например, после того, как фуры пересекли границу и прошли таможенный контроль, и уже едут домой, менеджер не может их опять завести на таможню (предполагается, что границу пересекаем один раз) )
4. Для тех объектов, чье поведение меняется в зависимости от этапа (всего три таких класса: менеджер, груз и заказ), пишутся отдельные классы в которых реализовано их поведение в зависимости от этапа - реализация паттерна Состояние. По одному классу состояния на каждый этап и каждый класс, меняющийся от этапа к этапу.
5. В итоге наши "изменчивые" объекты будут переходить от этапа к этапу так, как это прописано в выбранном сценарии, а поведение в зависимости от этапа будет подхватываться из объектов-состояний. Общий алгоритм БП будет сосредоточен в классах-состояниях.

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

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

ссылки у вас битые или не работающие

Ссылки рабочие. Скорее всего у вас что-то с браузером. Можно правым кликом по ссылке скопировать адрес и потом вставить его в адресную строку.
Да даже если и так не получится, "паттерн стратегия" (англ. Strategy) и "паттерн состояние" (англ. State) моментально ищутся гуглом.

Скорее всего у вас что-то с браузером.

Браузер - Опера 9.51. Дома сработало, на работе не сработало. Возможно- проблемы в прокси либо в провайдере инетуслуг. Но... уже не актуально.

В общем я не вижу проблем в Вашей реализации.