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

На всякий случай тот же файл в сети: www.kemtt.ru/Model_v_0_1.doc

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

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

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

Может пока не стоит говорить о решении.

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

Вот пока меня интересует правильно ли я начал. Стоит ли продолжать в том же духе или сразу что-то подкорректировать или даже начать заново совсем по другому.

А что такое domain?

или попросту сформировать требуемую модель данных или диаграмму классов предметной области?

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

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

Изменился и состав пользователей (реструктуризация фирмы). Кроме того как же быть со скрытой целью

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

???Вот пока меня интересует правильно ли я начал. Стоит ли продолжать в том же духе или сразу что-то подкорректировать или даже начать заново совсем по другому.

да может и правильно, если цель понятна, а может и не правильно. Нужны критерии. А пока проблема только в том, что система устарела морально. Но может система дополнительно не делает того ЧТО нужно (да у вас это есть). Но я и говорю у вас там столько проблем, может ну его  - взять и начать с главного? Или отбросить то, что есть? И начать все постепенно с нуля.... Можно пойти наоборот - прописать все процессы как они делаются (раз), как они должны делаться (два) и отсюда предложить что менять, но поскольку по идее вы будете делать систему с нуля (другая платформа, другая БД, другой функционал) если смылс изучать как есть, может сразу делать модель того, как должно быть?

А что такое domain?

предметная область, либо в моем контексте - диаграмма классов предметной области.

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

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

С историей мне вот не понятно. Чтобы вычислять сумму долга, необходимо вести историю по датам, когда "приходили" деньги (а такие изменения могу быть внесены задним числом); а занесение всех "важных" действий актёров, т.н. мониторинг пользователей, как раз надо, думаю, вести в реальном времени. А?

Мне как раз эта тема досталась по курсовому... интересно будет посмотреть решение ))