Как закодировать диаграмму классов UML, которая имеет классы ассоциации

       0..*                    1..*
+-------+                       +--------+      
|Invoice|_______________________|Products|
+-------+           |           +--------+
|inID   |           |           |proID   |
|inDate |           |           | Qty    |
+-------+           |           | Price  |
                    |           +--------+
               +-----------+
               |LineProduct|
               +-----------+
               | Qty       |
               | salePrice |
               +-----------+

Правильно ли это кодирование для приведенной выше диаграммы классов?

Class Invoice 
{
 inID:int;
 inDate:Date;
}

Class LineProduct 
{
 Qty:int;
 salePrice:int;
 //inID:int;  <-- this is what I did but I am wrong 
 //prodID:int; <-- this is what I did but I am wrong 
}

Class Products
{
 prodID:int;
 Qty:int;
 Price:int;
}

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

invoiceTable.saveInvoice(invoice:Invoice);
lineproductTable.saveLine( product instance 1 );
lineproductTable.saveLine( product instance 2 );

теперь снова другая путаница, что таблица линейных продуктов будет иметь столбцы inID и proID, но как передать объект, который будет иметь inID и prod ID?

PS: Извините, я застрял в низкой репутации, я не мог опубликовать изображение и объяснить свое замешательство.


class diagram uml
person f4r4    schedule 02.02.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я думаю, что вы были правы в первую очередь.

//inID:int;  <-- this is what I did but I am wrong 
//prodID:int; <-- this is what I did but I am wrong

Раскомментируйте эти строки. Это единственный способ связать продукт со счетом-фактурой.

person Kelly S. French    schedule 02.02.2012
comment
Обратите внимание, что UML не обязательно должен иметь прямое сопоставление с точными классами, но, похоже, это одна денормализация, обеспечивающая работу ссылок. Я хотел бы подчеркнуть, что существуют также проблемы с навигацией, если вы знаете только о счете-фактуре или продукте, у них нет ссылок или методов для поиска взаимосвязей. - person Ted Johnson; 03.02.2012
comment
@ Тед Джонсон, я в замешательстве! LineProduct - это класс ассоциации, так что мой код класса правильный? - person f4r4; 03.02.2012
comment
Кроме того, на вашей диаграмме явно указаны кратности для inID и prodID. Таким образом, вы, вероятно, захотите объявить их как массивы целых чисел в своем коде и убедиться, что хотя бы один экземпляр Product постоянно присутствует в массиве prodID. - person Epicurus; 03.02.2012
comment
Если LineProduct предназначен для представления одной строки в счете-фактуре, тогда LineProduct не нужны массивы; НО это поднимает вопрос о том, как вы собираетесь собирать все линейные продукты для одного счета-фактуры? Объект Invoice должен иметь массив LineProducts, иначе вам пришлось бы немедленно записывать все LineProducts в базу данных и выполнять запросы каждый раз, когда вы хотите манипулировать списком. Подумайте о ком-то, добавляющем к счету-фактуре до того, как счет-фактура будет завершен. - person Kelly S. French; 03.02.2012
comment
да, то, что вы сказали, было правильным в отношении массива LineProduct, поскольку вы сказали, что я согласен с тем, что //немедленная запись в базу данных// является плохим методом. В моих предыдущих проектах форма счета-фактуры отправляет экземпляр счета-фактуры и ‹arraylist›LineProducts в классы invoiceDB, LineProductDB. Поскольку invoiceDB получает экземпляр счета-фактуры, его легко вставить в таблицу базы данных счетов-фактур. Когда дело доходит до массива LineProduct, я использую foreach и разделяю массив, затем в конце массива 1 на 1 экземпляры lineProduct будут вставлены в таблицу базы данных lineProduct. - person f4r4; 03.02.2012