Нужно построить диаграммы UML. Начал с модели предметной области и диаграммы пригодности. И конечно много вопросов.
Буду мыслить в слух:
В предметной области нужно выделить произвольный набор понятий, которые важны. На мой взгляд, я выбрал их. Отчёты не брал, так как в
модель предметной области не следует включать объекты отчета, поскольку вся
содержащаяся в них информация получена из других источников. Возникает вопрос: в правильном направление я создал предметную область? И следовательно  диаграмму пригодности? Ну, хоть не всё ли так критично?

А вот сам UML.

А что такое диаграмма пригодности?

Что касается модели предметной области, ну это просто диаграмма классов UML, классы - в данном случае ваши объекты, сущности предметной области и связи между ними.

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

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

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

Мне не понятна указанная связь между Заявкой покупателя и Организацией, а также между Планом проекта и Заявкой покупателя.

И т.д.

А что такое диаграмма пригодности?

Про неё совсем мало знаю. Отталкивался от Темы на http://www.uml2.ru/forum/index.php?topic=3622.0. От туда брал пример.  Так как все выше документы и отчёты буду реализовывать через программу. То я попытался изобразить как будут формироваться документы. Но думаю что я очень ошибся в понятий диаграммы пригодности.
Так же немного подкорректировал модель предметной области.

Так же немного подкорректировал модель предметной области.

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

P.S. Попытки изобразить течение процессов на ER диаграммах, обычно ведут к грустным результатам.

- Доставка может быть только от одного поставщика?

В данном случае, я буду отталкиваться что 1 доставка это 1 поставщик.
Ответы На другие вопросы попытался изобразить на модели. Но не знаю как получилось. Уж очень запутано.

Ответы На другие вопросы попытался изобразить на модели. Но не знаю как получилось. Уж очень запутано.

Доброе утро!

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

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

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

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

3. И наоборот, почему атрибуты товара показаны агрегацией? Разве они могут жить в отрыве от него? Тут более уместна, на мой взгляд, композиция. И даже больше скажу. Я вообще не вижу смысла выделять атрибуты товара как отдельные классы.

4. Последняя мелочь. Не кажется ли вам, что  "количество" - это атрибут, скорее заказа, чем товара?

Доброе утро!

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

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

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

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

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

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

Если не получается слету - лучше начать устранять неопределенность в других местах системы (на других диаграммах). По факту, глядишь, и станет понятнее, что рисовать на этой.

С каких диаграмм лучше начать? А то я что то совсем в "упадке".

С каких диаграмм лучше начать? А то я что то совсем в "упадке".

Я не умею думать диаграммами. И не советовал бы другим. Начать лучше с формирования понимания:
1. Зачем все это нужно. Цели и задачи, которые будут способствовать их достижению.
2. Что там происходит (текущая ситуация, основные процессы, обязательные по тем или иным причинам артефакты).
3. Как контролируется (какие показатели, периодичность).
4. Перспективы развития (что можно усовершенствовать).

При наличии понимания по этим пунктам, рисование любых диаграмм становится делом техники.
Если в виде исходных данных у нас BPMN-картинки, сути это не меняет. Нужно разобраться, что там нарисовано и почему нарисовано именно так. Например, для чего отдельно выделяется "отдел продаж". То-ли кто-то поспешил/перестраховался, то-ли хотели сказать что-то важное.

Иной раз, кажется, что все диаграммы не связанны ни как между собой.

Думаю от того, что вы не видите реального смысла за этими квадратиками и стрелочками:)

Давайте начнем с самой, на мой взгляд, известной диаграммы UML - диаграммы вариантов использования.

У вас куча человечков натыкана куда-попало.
Для начала внесите ясность: слева - акторы которые инициируют варианты использования. Справа - которые участвуют пассивно.

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

И подумайте по поводу экстендов и инклюдов. Я бы сделал без них. Кстати в BPMN схеме нет доставки товара. Откуда она взялась и зачем?

Далее, перейдем к диаграмме классов: Разве сроки, расходы, риски, цена, артикуль, количество - это все классы? Разве это не атрибуты классов?

Ну и класс прайс-лист я бы вообще удалил. А может и класс доставки тоже.

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

Не полностью ответил на вопросы, но после замечаний постараюсь исправиться.

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

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

Что-то я подумал, не стоит отдел продаж пихать в UML. Если это модели будут про менеджера и его работу.

Смысл DPMN показать документооборот при проектной деятельности менеджера, во время которого происходят основные процессы:
Заказ покупателя – предназначается для оформления предварительной договоренности с покупателем  о намерении закупить товары.
План проект – служит для определения конечной картины потребности заказчика.
Счет на оплату – документ служит для регистрации предварительной договоренности о закупке покупателя товара и может быть документом, на формировании которого совершаться оплата, отгрузка или резервирование товара.
Заказ поставщику – служит для документального оформления сделки.
Поступление товаров – Служит для регистрации факта поступления товаров и услуг.
Акт о приемке товара – служит для оформления приемки товаров по качеству, количеству, массе и комплектности в соответствии с правилами приемки товаров и условиями договора.
Накладная – служит при передаче товара от одного лица другому, в нашем случае это менеджер по продажам и покупатель.
Контроль ведётся в виде отчётов.

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