Намирам за една от слабостите си прилагането натеория, която познавам в реалните проекти. Една такава теория е проектирането на приложения. Никога не съм проектирал официално заявление, преди да започна да кодирам. Разработвам проста заявка за заем за микрофинансиране за клиент и аз завинаги искам да върша нещата както трябва. Затова се опитвам да проектирам системата преди кодирането. Едно от многото сайтове, на които се обръщам, предполага, че човек пита следните 3 въпроса и работи оттам;
- Какви са входните данни на системата?
- Какви са процесите на системата?
- Какви са резултатите от системата?
Първият и третият въпрос са доста лесниотговори за мен. Въпросът е вторият въпрос. Не че не знам какво трябва да направя системата, но мисля, че не ги посочвам достатъчно добре, както би трябвало да бъде.
- Регистрирайте групи и физически лица
- Предоставяйте заеми на Групи само с физически лица или физически лица
- Създайте график за погасяване на кредита
- Изчислява дневното погасяване в момента на отпускане на кредита
- да следите ежедневните колекции от кредитни служители
- предвиждат ежеседмична прогноза за отпускане на заеми въз основа на групи, които са извършили плащания и нови групи
Ще използвате ли подобни думи, когато заявявате процесите на високо ниво за една система? Знам, че ще трябва да направя няколко прохода, за да прекъсна отделния процес.
Отговори:
1 за отговор № 1Бъдете много предпазливи да правите нещо, само защото това е "добра практика", ако не знаете защо (и лично аз често трябва да "правя" нещо (и не успявам), преди да направя нещо наистина).
Какви са процесите на системата?
Защо да питаме това? Това, което се опитваме да направим, е да започнем да идентифицираме ролите и отговорностите във вашата система - това е първият преход на високо ниво в началото на обектно-ориентирания дизайн.
Какво търсиш: - Възможни (високо ниво) пакети - Възможни класове в тези пакети
Опитайте да го съпоставите с псевдо код на бяла дъска. Например регистрирането на потребители очевидно ще бъде в отделен пакет от проектиране на кредити.
Идеята е, когато идва ново изискванезаедно (да кажем, че бизнесът трябва да добави някакъв нов правилник някъде), трябва да е съвсем ясно къде е тази отговорност и следователно къде да го поставя, да го повлияе върху системата ви и т.н.
Другата част, която върви ръка за ръка с процесите, са данните и структурата. Карта на картата a домейн Модел на бизнес домейна - това е основно това, което ще приложите в бизнес логиката.
Моделиране на домейни:
1 за отговор № 2
Изглежда, че сте в добро начало. Искате да направите списък с всичко, което приложението ви трябва да направи. Тогава може да искате да класирате тези от задължителни за хубаво да имат, по този начин, тъй като крайният срок е по-близо, можете да изпуснете функции, които не си струва.
0 за отговор № 3
Ако не сте особено ограничени до обектно-ориентиран подход за проектиране, предлагам ви да погледнете Диаграми на потока от данни.
Първо, можете да замените тежката формулировка смногослойна диаграма. Второ, има само няколко символа за учене. На трето място, схемата ви позволява да "зоните" в детайлите, за да се осигури подробен дизайн на този процес. Четвърто, диаграмите са проектирани така, че (почти) всеки, който е на произход, може да разбере тяхното представяне (поне до ниво 2).
Ето някои начални точки за вас.
http://en.wikipedia.org/wiki/Data_flow_diagram
http://www.smartdraw.com/resources/tutorials/data-flow-diagrams/
http://www.getahead-direct.com/gwbadfd.htm