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

MagicDraw, Modelio, EA, VISIO, StarUML, да и VP отличный инструмент.

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

бухгалтер- счет - счет на что формируется - на сферического коня в вакууме?

MagicDraw, Modelio, EA, VISIO, StarUML, да и VP отличный инструмент.

Скачал уже EA, небо и земля по сравнению с тем чем я пользовался.

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

мне она самому не понравилась, но я уже засыпал когда доделывал

клиент и прайс-лист - вам непременно нужно контролировать сколько каких прайс-листов скачал какой клиент? или важно контролировать количество закачек в принципе?

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

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

то же самое..

Заказ - статус заказа - почему такая честь статусу заказа? и почему статус заказа - это материалы

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

Почему нужно знать сколькими материалами управляет администратор? и почему менеджер управляя прайс листами лишен возможности управлять материалами?

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

бухгалтер- счет - счет на что формируется - на сферического коня в вакууме?

Еще вопрос:

В теме примера про ИС Аттестации студентов я нашел вот такой документ
Вопрос: таблицы "Заинтересованные лица", "проблем", "цели", буквы R, P, G (я так понял это requirement, problem, goal)  <== это что за методология?
http://www.uml2.ru/forum/index.php?action=dlattach;topic=1106.0;attach=1179

R - role, в остальном угадали. Это методология UP и просто здравого смысла:)

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

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

то есть номер потребности R1 = Role 1, а не Requirement 1 ? не логично как-то..

UP = unified process ?

нед диаграммой седня подумаю еще

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

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

Заинтересованные лица там как раз не пронумерованы
Вот где я нашел R1:

Ну вот, переделал в ЕА, подубрал что Вам не понравилось..

Вот, сделал ДВИ, помоему выглядит эпично хахаха

Тока думаю надо еще добавить ВИ Мониторинг статуса, а то пользователь не понятно как видит статус..
И еще наверное надо ВИ отправка товара.. но это вроде как выходит за рамки системы, или как?

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

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

про иконикс - я не знаю чо это и причем тут это =)

А про инклюды\не инклюды вот как получается:
В ЕА я не нашел инклюдов и экстендов, там были просиды и инвоуки
Так как я ни в том ни в том особо не разбираюсь, я почитал описание того и другого, дабы определить для себя: искать новый программный продукт, где есть инклюды и экстенды, либо разобраться в том в чем есть.

Так вот описание эстендов и инклюдов, в которых я честно сказать нихера не понял:

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

Отношение включения
Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.
Семантика этого отношения определяется следующим образом. Когда экземпляр первого варианта использования в процессе своего выполнения достигает точки включения в последовательность поведения экземпляра второго варианта использования, экземпляр первого варианта использования выполняет последовательность действий, определяющую поведение экземпляра второго варианта использования, после чего продолжает выполнение действий своего поведения. При этом предполагается, что даже если экземпляр первого варианта использования может иметь несколько включаемых в себя экземпляров других вариантов, выполняемые ими действия должны закончиться к некоторому моменту, после которого должно быть продолжено выполнение прерванных действий экземпляра первого варианта использования в соответствии с заданным для него поведением.
Один вариант использования может быть включен в несколько других вариантов, а также включать в себя другие варианты. Включаемый вариант использования может быть независимым от базового варианта в том смысле, что он предоставляет ему некоторое инкапсулированное поведение, детали реализации которого скрыты и могут быть перераспределены между несколькими включаемыми вариантами использования. Более того, базовый вариант может зависеть только от результатов выполнения включаемого в него поведения, но не от структуры включаемых в него вариантов.
Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой, которая помечается ключевым словом «include» (включает).

И вот описание инвоуков и просидов, которое на английском языке, но я понял его за секунду тем не менее:

Invokes and Precedes relationships are defined by the Open Modeling Language (OML). They are stereotyped Dependency relationships; Invokes indicates that Use Case A, at some point, causes Use Case B to happen, whilst Precedes indicates that Use Case C must complete before Use Case D can begin.

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

о я нашел нужные стрелочки =)
ну они мне все равно не нравятся

А про инклюды\не инклюды вот как получается:
В ЕА я не нашел инклюдов и экстендов, там были просиды и инвоуки
Так как я ни в том ни в том особо не разбираюсь, я почитал описание того и другого, дабы определить для себя: искать новый программный продукт, где есть инклюды и экстенды, либо разобраться в том в чем есть.

о я нашел нужные стрелочки =)
ну они мне все равно не нравятся

Я долго смеялся

Заинтересованные лица там как раз не пронумерованы
Вот где я нашел R1:

уел:) ну значит r - требования потребности (request или requirement)

Вот, сделал ДВИ, помоему выглядит эпично хахаха

Цель ДВИ - дать контекст и общий обзор.
Задача контекста  показать:
- кто будет пользоваться системой - т.е. кто или что вне границы системы
- показать саму границу системы - boundary
- показать цели использования системы внешними сущностями - то есть именнованные в терминах цели пользователя обязанности (отвественности) системы = варианты использования
- возможно как-то структурировать это в целях улучшения отображения