1

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 15:30:46 »

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

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


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

2

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 14:10:52 »

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

3

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 14:07:18 »

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

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

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

да верно

4

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 14:03:36 »

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

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

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

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

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

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

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

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

5

Примеры / Диаграмма классов - подкорректируйте\ подскажите

« : 10 Июля 2014, 19:23:25 »

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

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