Задачата е следната: Да се разработи диаграма на класовете и диаграма на обектите в средата на VS2010. Да се генерира и допише програмен код на C# реализиращ работещо конзолно приложение. Езикова школа поддържа информация за курсистите и преподавателите в учебното заведение. За всеки курсист се съхраняват име, адрес , дата на записване. Преди началото на всеки курс се провеждат серия от 3 теста (писане, четене, разбиране) на избран език, за да се разпределят курсистите в групи. Програмата извежда списък със студентите , резултатите от проведените тестове за съответен език, името на преподавателя проверил тестовете и осреднен резултат: Иван – Английски език [проверил: Иванов] Писане: 10т. Четене: 30т. Разбиране: 20т. среден успех: 20 т. Петър – Немски език [проверил: Петров] Писане: 60т. Четене: 80т. Разбиране:70т. среден успех: 70 т. Задачата първо трябва да се разработи в Altova UModel, въпросът ми е: Класовете трябва да са Студент (име,адрес,дата на запис,среден успех), Преподаватели (име), Английски език (писане,четене,разбиране), Немски език (писане,четене,разбиране) или и средния успех трябва да е клас ?

enum Language LanguageTestEntry ...Language Language ...Teacher Teacher ...int Reading ...int Writing ...int Understanding ...float Average Person ...string Name ...string Address Teacher : Person ...IList<Language> Languages Student : Person ...DateTime SubscriptionDate ...IList<LanguageTestEntry> LanguageTests Ето един хубав модел. Тъй като учителите и учениците са хора (характеризират се с общи атрибути - име и адрес) въвеждаме базов клас персона. Учителите се характеризират с това, че могат да бъдат учители по един или повече езика. От друга страна учениците могат да се явят на изпит по един или повече изпит или повече езици. Следователно трябва да имат един или повече записи от резултатите за съответен език. Всеки такъв запис (LanguageTestEntry) съдържа оценка Език върху който са полагани тестовете, учител, който е провери тестовете, резултати по четене, писане, разбиране -> средната оценка трябва да бъде калкулирано (сетър не се предвижда въобще). Ако имаш въпроси питай. Успех!

enum Language

LanguageTestEntry

...Language Language

...Teacher Teacher

...int Reading

...int Writing

...int Understanding

...float Average

Person

...string Name

...string Address

Teacher : Person

...IList<Language> Languages

Student : Person

...DateTime SubscriptionDate

...IList<LanguageTestEntry> LanguageTests

Благодаря ти много,в твоя модел как трябва да са връзките,от къде на къде? Имам и друг въпрос,не трябва ли да има още един клас - Изпити,ето така

Редактирано 17 декември 201114 г. от Ani Lupanova (преглед на промените)

Благодаря ти много,в твоя модел как трябва да са връзките,от къде на къде? Имам и друг въпрос,не трябва ли да има още един клас - Изпити,ето така

съдейки по идеите на релационните бази няма ли да е по-просто ако Изпит и Дата на изпит са на едно място? Все си мисля че датата на изпита е негова характеристика

съдейки по идеите на релационните бази няма ли да е по-просто ако Изпит и Дата на изпит са на едно място? Все си мисля че датата на изпита е негова характеристика

Няма дата на изпит,а дата на записване на студента. Аз мисля, че сякаш това не е едно и също ... А като цяло, какво ти е мнението за моята диаграма?

Няма дата на изпит,а дата на записване на студента. Аз мисля, че сякаш това не е едно и също ... А като цяло, какво ти е мнението за моята диаграма?

СЪжалявам, не разбирам от UML и обектно програмиране. Просто базирах препоръките си на скромните си познания по релационни бази данни

И след като е атрибут на студента трябва да е част (мисля) от обекта Студент

Да,така е. В студент е!

Благодаря ти много,в твоя модел как трябва да са връзките,от къде на къде?

В OOP принципните връзки са Наследяване (is a), Композиция (has a), Агрегация (contains). При наследяването връзките са еднопосочни от Наследника към Базовия. При композиция не е съвсем така, два обекта може да се композират един друг. Това определено, не е добър дизайн, но е възможен. Агрегацията не е нищо друго освен множествено композиране.

В твоя случай, Студента и Учителя са хора (възката е is a) => наследяват категорията Човек. Студента може да направи тестове по един един или повече езици => Студента агрегира данни за тестовете (ако се приеме, че студента може да се яви на тестовете само за един език, то тогава той ще композира тези данни). Тестовете по даден език, се проверяват от Учител => ТестРезултати обекта ще композира в себе си учителя. Такива са връзките.

Имам и друг въпрос,не трябва ли да има още един клас - Изпити,ето така

Какво е според теб предназначението на този клас Изпити? Според мен, не се връзва никак в картинката (поне според така зададеното условие).

Успех!

П.П. Пропъртито Студент е излишно в класа Тест.

П.П.П. UML диаграмата има за задача само да опише взаимовръзките между обектите, а не да представи схемата по която те ще се персистват (записват в бази данни, файлове и т.н.). Това (персистването) е тема на друга бира

....

П.П.П. UML диаграмата има за задача само да опише взаимовръзките между обектите, а не да представи схемата по която те ще се персистват (записват в бази данни, файлове и т.н.). Това (персистването) е тема на друга бира

Дарки, това май последното е за мен. Аз не разбирам от ООП, само се опитах да си представя релациите между обектите като релации между таблици в база. ЗНам че е доста неточно, но ако нямам основа хептен не мога да го разбера

П.П. Само не отваряй тема за хибернейт, щото такива негови бози съм виждал че ми настръхна косата

Дарки, това май последното е за мен. Аз не разбирам от ООП, само се опитах да си представя релациите между обектите като релации между таблици в база. ЗНам че е доста неточно, но ако нямам основа хептен не мога да го разбера

П.П. Само не отваряй тема за хибернейт, щото такива негови бози съм виждал че ми настръхна косата

Добавянето на този послепис беше провокирано от излишното пропърти Студент в класа Тест. Такива евентуално се добавят, като с цел навигация и то най-вече ако се използват фреймуърки, като Hibernate/NHibernate и EntityFramework. Да се слагат такива в UML диаграмата е грешно, защото това не описва натурата на връзката, а описва подход към персистването, което както казахме е друг проблем. С други думи опитвам се да подбутна потребителя, да мисли в правилната насока. По никакъв начин не критикувам твое изказване!

П.П. То проблема не в Hibernate-а (макар, че и той си има бая трески за дялане), а в задклавиатурното устройство - в дизайнера демек

Добавянето на този послепис беше провокирано от излишното пропърти Студент в класа Тест. Такива евентуално се добавят, като с цел навигация и то най-вече ако се използват фреймуърки, като Hibernate/NHibernate и EntityFramework. Да се слагат такива в UML диаграмата е грешно, защото това не описва натурата на връзката, а описва подход към персистването, което както казахме е друг проблем. С други думи опитвам се да подбутна потребителя, да мисли в правилната насока. По никакъв начин не критикувам твое изказване!

П.П. То проблема не в Hibernate-а (макар, че и той си има бая трески за дялане), а в задклавиатурното устройство - в дизайнера демек

Мисля че в главата ми започва да се оформя идея за това, което пишеш. Само че колкото и пъти да съм се опитвал да боря обектно програмиране съм го зарязвал и съм си карал с моето просто, функционално такова

А за хибернейта си е така, именно там е зарито кучето

П.П. Пропъртито Студент е излишно в класа Тест.

Защо Студент да е излишно,нали пише,че в резултатите се извежда списък с имена ?

Защо Студент да е излишно,нали пише,че в резултатите се извежда списък с имена ?

Гледай сега какво пише в задачата:

Задачата е следната:

...

Програмата извежда списък със студентите , резултатите от проведените тестове за съответен език, името на преподавателя проверил тестовете и осреднен резултат:

...

Цялата тази информация се съдържа в класа Студент или директно както са името на студента и неговия адрес или се съдържа индиректно в композирания/агрегиран клас Тест.

Алгоритъма за извеждане на данни, значи е такъв:

Завъртаме цикъл по списъка със студентите положили изпити, като името се взима от полето Студент.Име на текущия студент, останалите данни се взимат от полетата Студент.Тест.Език, Студент.Тест.Преподавател, Студент.Тест.Четене, Студент.Тест.Писане, Студент.Тест.Разбиране, Студент.Тест.СреднаОценка. Измъкнахме всички данни за един ред от репорта, а никъде не ни потрябва полето Студент.Тест.Студент => това поле си е чиста и ненужна тавтология и няма място в модела. С други думи, смислово - ТестовитеРезултати са атрибут на Студента, а не обратното!

Успех!

Ясно,сега вече разбрах. Благодаря ти много!