Здравствуйте, Sinix, Вы писали:

S>Есть 2 основных подхода к моделированию предметной области:
S> — предметная область — это автоматизируемый бизнес заказчика (примерно то, что у вас под №2)
S> — предметная область — это область деятельности заказчика (ака DDD). (примерно то, что у вас под №1)

S>Разница очень сильно сказывается на уровне построения модели. В 1-м варианте мы получаем классику — набор требований -> ??? -> диаграмма классов. Во втором всё чуть посложнее:
S>сначала мы разбираемся с областью деятельности заказчика, узнаём основные сущности, связи между ними и прочие особенности предметной области, а затем производим анализ и обработку требований, оперируя исключительно терминами предметной области. На практике этот процесс очень микроитеративен: мы одновременно и формулируем требования на основе модели, и проверяем модель на достаточную детальность/охват.
S>Увы, если полученная модель не будет активно использоваться дальше, толку от неё никакого не будет

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

Про документооборот, это я так для примера привёл первое, что взбрело в голову

У меня есть проект. Там уже собраны требования(около 100 шт) и разработаны UseCase'ы(около 60 штук). Следующий этап Анализ. Начал с анализа существительное/глагол и сразу-же вспомнил о том что "класс анализа должен чётко и однозначно проецировался на некоторое реальное понятие предметной области". А у меня после анализа нескольких страниц текста, всплыли такие понятия как Учётная запись, Действительный/Недействительный пароль, Пользователь и т.п., т.е. понятие имеющие непосредственное отношения к функционировании системы. В то время как в самой предметной области они не используются. Соответственно, сразу встал вопрос правильно-ли я всё понял! Вот я и на примере документооборота и спрашиваю по сути, должны-ли эти понятия всплывать при Анализе, точнее в соответствии с UP в деятельности "Анализ прецедента"
Просто у меня нет ни какого опыта в анализе вообще. Я бы уже сто раз и так написал требуемую систему, но решил упереться и пройти весь путь в соответствии с UP до конца.
Кроме того, немного поразмыслив я задался таким вопросом: Правильно-ли я вообще понимаю суть деятельности "Анализ прецедента"
В моём понимании, суть его такова. Понятия предметной области, их отношения и операции проецируются на разрабатываемую систему и для каждого из этих понятий, отношений и операций в системе есть представитель. Поскольку происходит проецирование с предметной области в систему, то понятия, отношения и операции существующие в реальном мире(предметной области) накладывают ограничения на их представление в системе. Таким образом установив связи эти понятия, а также выяснив их отношения и операции которые над ними выполняют, мы получаем ограничения которым должны удовлетворять представители понятий, отношений и операций внутри разрабатываемой системы. И мы просто изображаем их на диаграммах как класс с его атрибутами и операциями. НО, классом анализа должно быть именно понятие предметной области, а не разрабатываемой системы.