Здравствуйте!
Начинаю осваивать UML вот набросал диаграмку классов для информационной системы регистрации договоров страховой компании... думается мне не совсем точно определил связи. 

Не знаю как определить динамический выбор класса ведь страхуемый может быть как наследником класса "клиент" так и просто набором полей из справочника.

Начинаю осваивать UML вот набросал диаграмку классов для информационной системы регистрации договоров страховой компании... думается мне не совсем точно определил связи.

А в чем конкретно Вы сомневаетесь? Какие связи вызывают у Вас сомнение правильности?

Не знаю как определить динамический выбор класса ведь страхуемый может быть как наследником класса "клиент" так и просто набором полей из справочника.

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

Что такое страхуемый по предметной области? Судя по Вашему описанию в заметках - это по сути страховой случай. Вы пишите страхуемый это или клиент(юридическое или физическое лицо) или имущество клиента, так?

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

1. Стрелки генерализации для страхуемого должны быть в обратную сторону.
2. Композицию замени на агрегацию.

Для начала сойдет и так.

5 копеек не про UML.

1. Если менеджер в жизни нужен для того, чтобы "вести" договор (а не только в виде отметки на память - кто подписал), то одного в модели будет недостаточно. Менеджеры за время действия договора будут меняться. Как минимум, потребуется журнал вида "кто / с  / по ". Как минимум. Ну и аудит спасибо скажет.

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

1. Стрелки генерализации для страхуемого должны быть в обратную сторону.
2. Композицию замени на агрегацию.

Для начала сойдет и так.

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

5 копеек не про UML.

1. Если менеджер в жизни нужен для того, чтобы "вести" договор (а не только в виде отметки на память - кто подписал), то одного в модели будет недостаточно. Менеджеры за время действия договора будут меняться. Как минимум, потребуется журнал вида "кто / с  / по ". Как минимум. Ну и аудит спасибо скажет.

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

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

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

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

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

Что такое страхуемый по предметной области? Судя по Вашему описанию в заметках - это по сути страховой случай. Вы пишите страхуемый это или клиент(юридическое или физическое лицо) или имущество клиента, так?

да верно

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

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

Я бы не стал. Не надо пытаться засунуть действия в ER-диаграмму, фигня получится. Я бы предложил:

1. Если данные подтягиваются откуда-то извне, и затем раскладываются в местное хранилище - лучше изобразить полноценными классами.
2. Если данные в свою систему не сохраняются, а просто устанавливается связь с внешним объектом (хранится только ссылка) - у себя рисуем "свернутый" (без атрибутов) класс и посылаем читателя туда, где этот класс описан. Это избавит от массы потенциальных граблей с актуализацией (в т.ч. на этапе сдачи работы).
2а. Если настолько лаконично, как в п.2, никак нельзя, то в класс включаем только критичные для нас атрибуты, остальное - в виде троеточия. И посылаем.

Как такой подход соотносится с расовой чистотой UML - понятия не имею, тут кто-нибудь подскажет. Но работает.

для договора это просто поля в случае клиента уже заполненные(инфо из базы), в случае справочника пустые... как это показать?

Этого здесь не требуется показывать. Ну, если очень хочется - можно поиграть связями. Показать, например, что физик, юрик и объект связаны с договором в виде [1 - 0..1]. А уж в каком случае и как - это вопрос процессов.

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

На текущей диаграмме отображено множественное наследование - класс страхуемый содержит свойства классов клиент и словари.
Если я правильно понял, классы словари и клиент должны содержать свойства класса страхуемый.
И замени композицию на агрегацию.

На текущей диаграмме отображено множественное наследование - класс страхуемый содержит свойства классов клиент и словари.
Если я правильно понял, классы словари и клиент должны содержать свойства класса страхуемый.
И замени композицию на агрегацию.

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


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

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

Скажите, как в договоре называется то, что подлежит страхованию? Вы уже подтвердили мою мысль, что Вы составляете договор на определенный страховой (или даже несколько?) случай?
Например,

Сидоров Сидор Сидорович
физическое лицо
страхует
садовый домик
от пожара

Кто такой Сидоров С.С.?
Это участник договора о страховании, т.е. Клиент, тот кто
1. несет ответственность за оплату страховки
2. получает деньги в случае удовлетворения страхового случая

При этом это Физическое лицо.
По семантике Клиент - это абстрактный класс, т.е. Клиент.
Физическое лицо и Юридическое лицо - это Клиент. По факту обобщения - уточнения, Клиент конкретизируется или в Юрлицо, или в Физ.лицо, но не как одновременно.

Поэтому никакой композиции между Клиентом и Юридическим и Физическим лицом быть не может.

Далее. Стахователь, Выгодоприобретатель, Страхуемый - это Клиент и это набор обощения, т.е. одновременно некий абстрактный клиент не может быть Страхователем и Выгодоприобретателем. и Т.п. Так что Ваше пояснение "может быть одним и тем же" в данном случае некорректно.

Использование композиции также не очень корректно или совсем некорректно.
1. Продукт - Договор - что это за связь? Каков ее смысл? Можно догадаться, что договор заключается на определенный продукт. Один и тот же продукт может быть предметом разных договоров. Гуд, но при чем тут КОМПОЗИЦИЯ? Идем и изучаем что такое композиция.
А в данном случае просто оставить ассоциацию следует!
2. Менеджер - Договор - опять некорректное использование композиции - оставьте только ассоциацию
3. Договор - Страхователь, Договор - Выгодоприобретатель, Договор - Страхуемый (а почему не страхуемое?) - это не композиции! Даже если Вы пытаетесь таким образом передать идентифицирующую связь принадлежности!
4. Клиент - Юр Лицо, Клиент - Физ лицо - уже говори выше - это не композиция, а обощение
5. Словари - вообще выпадает из общего стиля моделирования предметной области. С тем же успехом можно написать Фигнюшки
6. Страхуемый - ну такой непонятный класс, который одновременно наследует свойства каких-то Словарей и Клиента (в общем-то одушевленного лица, ну или обладающий поведением) - выглядит весьма странно, если не сказать забавно - это явная попутка забежать вперед и навязать некую реализацию.

Мой Вам совет, приведите структуру (пример) разных договоров, будет проще Вам чем-то помочь.



Вообще непонятно, зачем связывать разные по своей роли сущности одни классом Клиент. Посмотрите в словаре, что такое Клиент.

На деле страхуемый, это тот кого страхуют,

на вопрос кого отвечает только одушевленный предмет, т.е.

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

и никак

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

А вот это утверждение может моделироваться

так что это страхуемый наследует атрибуты либо из словаря либо из клиента.

отношением обобщения а именно: Словари - Это Страхуемый или Клиент - это Страхуемый, т.е. страхуемый либо что-то из Фигнушки (смотри мой предыдущий пост) либо все из Клиента

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

Полная каша в голове, при таком рассуждении черные ромбы должны быть прикреплены обратно. Если рассматривать IDEF1x, то между Менеджером, Продуктом и прочими Клиентами и Договором - идентифицирующая связь принадлежности, что означает:
Договор идентифицируется через его отношения с другими сущностями.

А то, что у Вас записано - называется обязательность значения поля, т.е. поле не может быть пустым иметь значение NULL. И контролируется это разными способами, в частности на диаграмме классов - кратностью атрибута

Опять стрелки не в ту сторону! )

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


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

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