מבוא לתכנות מערכות תרגיל בית מספר )ADT( 3 סמסטר חורף תאריך פרסום: תאריך הגשה: 23: , משקל התרגיל: 10% מהציון הסופי )תקף( מתרגל אחראי:

תמליל

1 מבוא לתכנות מערכות תרגיל בית מספר )ADT( 3 סמסטר חורף תאריך פרסום: תאריך הגשה: 23: , משקל התרגיל: 10% מהציון הסופי )תקף( מתרגל אחראי: תאמר מור )tamer.mour+mtmex3@gmail.com( הערות כלליות שימו לב: לא יינתנו דחיות במועד התרגיל. תכננו את הזמן בהתאם. לשאלות בנוגע לתרגיל יש לפנות לסדנאות של אחד מהמתרגלים, או לפנות במייל למתרגל האחראי על התרגיל. לפני שליחת שאלה נא וודאו שהיא לא נענתה כבר ב F.A.Q ושהתשובה אינה ברורה ממסמך זה, מהדוגמא או מהבדיקות שפורסמו עם התרגיל. קראו מסמך זה עד סופו ועיברו על הדוגמא שפורסמה לפני תחילת הפתרון. חובה להתעדכן בעמוד ה F.A.Q של התרגיל העתקות קוד בין סטודנטים יטופלו בחומרה! 1 לנוחויותכם, השינויים שבוצעו לאחר פרסום הגיליון מסומנים בצהוב שינוי אחרון )מסומן בסגול( : PM :52

2 2 חלק יבש 2.1 בחירת מבני נתונים לפניכם מספר דוגמאות אשר דורשות שימוש במבני נתונים. עליכם להחליט איזה מבנה נתונים בסיסיים שנלמדו בקורס )רשימה, מילון, קבוצה, גרף ותור עדיפויות( הוא המתאים ביותר לכל דוגמא. הסבירו מדוע הוא מתאים יותר מן האחרים. מתרגלים עצלנים במת"ם אוהבים לשחזר תרגילי בית. כדי להימנע ממצב בו משחזרים תרגיל בית שהופיע רק לאחרונה, נרצה לשמור את התרגילים שנכתבו בעבר במבנה נתונים שיאפשר לנו לשלוף את תרגיל הבית הישן ביותר במערכת, ולהכניס למערכת תרגילי בית חדשים שנכתבו. )כל קשר בין סעיף זה למציאות הינו מקרי בהחלט(. במהלך מימוש מקשר )linker( חדש שיעבוד עם,gcc הועלה הצורך לתחזק מבנה שיכיל בתוכו את קבצי הקוד בסביבת העבודה, ויתאר את קשרי התלות ביניהם, כדי שנוכל לדעת איזה קבצים לקמפל ובאיזה סדר, וכדי שנוכל לזהות מצב בו קיים מעגל תלויות בין הקבצים. מפתחי אפליקצית תקשורת חדשה רוצים להשתמש במבני נתונים שיכיל בתוכו את אנשי הקשר של כל משתמש, ויאפשר שליפת מספר טלפון של משתמש מסוים לפי שמו. סוכן נדל"ן רוצה לשמור מאגר של כל הנכסים אותם הוא מנסה למכור כרגע, באופן שיתאפשר לו לעבוד יותר על הנכסים שתקועים אצלו כבר זמן רב. )1 )2 )3 )4 2.2 תכנות גנרי ברצוננו לממש אלגוריתם מיון מיזוג sort( )merge המקבל מערך של איברים, וממיין אותו. 1( כתבו את הפונקציה,mergeSort המקבלת מערך של עצמים מטיפוס לא ידוע, וממיינת אותו. על הפונקציות להתאים לעצמים מכל סוג שהוא. השתמשו בפונקציות עזר אם צריך. שימו לב כי הפונקציה לא תחזיר מערך חדש, אלא היא תמיין את המערך בקלט. כלומר, לפונקציה לא יהיה ערך החזרה. 2( הסבירו בקצרה מה התפקיד והטיפוס של כל פרמטר שיש לשלוח לפונקציה הראשית ולפונקציות העזר שכתבתם. רשימות מקושרות נתון מבנה פשוט של רשימה מקושרת של מספרים שלמים :(int) typedef struct node_t* Node; struct node_t { int n; Node next; }; כתבו את הפונקציה.listOperator קלט: שתי רשימות מקושרות, ואופרטור בינארי על מספרים שלמים )פונקציה המקבלת שני מספרים שלמים ומחזירה מספר שלם(. פלט: אם שתי הרשימות לא באותו אורך, הפונקציה מחזירה.NULL אחרת, הפונקציה תחזיר רשימה חדשה, בה האיבר ה i מחזיק את התוצאה של הפעלת האופרטור על האיבר ה i ברשימה הראשונה, ועל האיבר ה i ברשימה השניה )בסדר הזה(. לדוגמא, אם הקלט הוא אופרטור החיבור ושתי הרשימות הנ"ל: הפלט יהיה: 2. כתבו את הפונקציה maxelements שמשתמשת בפונקציה.listOperator

3 קלט: מערך של רשימות מקושרות באותו גודל, וגודל המערך. פלט: רשימה מקושרת, אשר מכילה בתא ה i את האיבר ה i המקסימלי מבין כל הרשימות במערך הקלט. לדוגמא, אם הקלט הוא כנ"ל: הפלט יהיה: הערות: ניתן להשתמש בפונקציות עזר על מנת לפשט את הפתרון. יש להימנע משכפול קוד וליצור קוד גנרי כראוי. הניחו כי קיימת הפונקציה destroylist(node) void אשר משחררת את כל הזיכרון עבור רשימה מקושרת נתונה ( מלבד פנוקציה זו יש לממש את כל הפונקציות אשר אתם משתמשים בהן(. התייחסו למצביע ל NULL כאל רשימה ריקה.

4 3 חלק רטוב 3.1 מימוש Generic Data Type GDT עבור מילון ממוין בחלק זה נממש תחילה ADT גנרי עבור מילון ממוין. קובץ המנשק map_mtm.h נמצא בתיקיית התרגיל על שרת ה stud. עליכם לכתוב את הקובץ map_mtm.c המממש את מבנה הנתונים המתואר. מאחר והמילון הממוין )מעתה נגיד רק 'מילון'( גנרי, יש לאתחל אותו עם מספר מצביעים לפונקציות אשר יגדירו את אופן הטיפול בעצמים המאוחסנים בו. על מנת לאפשר למשתמשים במילון לעבור על איבריו, לכל מילון מוגדר איטרטור פנימי )יחיד( אשר בעזרתו יכול המשתמש לעבור על כל איברי המילון. האיטרציה על איברי המילון צריכה להבטיח למשתמש מעבר על האיברים בסדר עולה מהמפתח הקטן למפתח הגדול לפי פונקצית השוואת המפתחות המסופקת בעת יצירת מילון חדש. פונקצית ההשוואה אמורה להחזיר 0 אם שני המפתחות שהיא מקבלת שווים, 1 אם המפתח הראשון גדול מהשני, ו 1 אחרת )בדומה ל.)strcmp כדי לבדוק את התנהגות מבנה הנתונים, מסופקת לכם תוכנית קצרה בקובץ.map_example_test.c בנוסף, עליכם לכתוב בדיקת יחידה מקיפה יותר למילון, יפורט בחלק 3.3. פעולות mapcreate יצירת מילון ממוין חדש, בפעולה זו מוגדרות לרשימה הפעולות בעזרתן ניתן להעתיק, לשחרר מפתחות 1. וערכים, ולהשוות מפתחות. mapdestroy מחיקת מילון קיים תוך שחרור מסודר של כל הזיכרון שבשימוש. 2. mapcopy העתקת מילון קיים לעותק חדש, כולל העתקת האיברים )מפתחות וערכים(. 3. mapgetsize החזרת מספר המפתחות במילון. 4..false אם המפתח הנתון קיים במילון, true תחזיר mapcontains 5. mapput שינוי ערך של מפתח קיים/ הוספת זוג מפתחערך חדש למילון. 6. mapget החזרת הערך הממופה למפתח הנתון. 7. mapremove מחיקת מפתח מהמילון. 8. mapgetfirst החזרת האיטרטור הפנימי לתחילת המילון והחזרת המפתח הראשון mapgetnext קידום האיטרטור הפנימי והחזרת המפתח המוצבע על ידו. 11. mapclear ריקון המילון ממפתחות. לכל פקודה ייתכנו שגיאות שונות. ניתן למצוא את השגיאות האפשריות לכל פקודה בתיעוד בקובץ.map_mtm.h במקרה של כמה שגיאות אפשריות יש להחזיר את ערך השגיאה שהוגדר ראשון בקובץ המנשק הנתון הגבלות על המימוש על המימוש שלכם לעמוד במגבלות הבאות: אין הגבלה על מספר האיברים במילון. במקרה של שגיאה יש לשמור על שלמות מבנה הנתונים ולוודא שאין דליפות זיכרון.

5 3.2 מימוש משחק PokemonGo בחלק הזה אנו נממש גרסא ממכרת יותר של המשחק הפופלרי.PokemonGo תיאור כללי פוקימונים )Pokemons( פוקימונים הם ייצורים שמשמשים ככלי משחק. ישנם מינים )species( רבים של פוקימונים. כל מין של פוקימונים ממופה לסוג אחד או יותר של פוקימונים. רשימת המינים וסוגיהם נקראת.Pokedex סוגי הפוקימונים האפשריים הם: Bug Electric * Fairy * Fire ** Flying ** Ghost Grass Ground Ice * Normal Poison ** Psychic Rock * Water * )משמעות הכוכביות תובהר בהמשך(. ניתן להניח שמיני הפוקימונים הם מחרוזות בגדול 10 תווים לכל היותר. לכל פוקימון עוצמה Power( )CP: Combat מספר שלם חיובי, נקודות חיים Points( )HP: Health מספר ממשי בין 0 ל 100, ו רמה )Level( מספר שלם חיובי. חנות ופריטים במשחק ישנו חנות.)store( הסחר במשחק מתבצע במטבע ה.Pokecoin לכל פריט שנמכר בחנות יש סוג )שיקוי או סוכריה(, ערך, כמות במלאי, ומחיר. המחיר של כל פריט הוא פונקציה של הסוג והערך. בחנות נמכרים שני סוגים של פריטים: o שיקוי )Potion( לריפוי פוקימונים )הגדלת ה HP לפי הערך(. מחיר יחידת ערך אחת הוא Pokecoin אחד )לדוגמא, שיקוי בערך 20 יימכר ב,Pokecoins 20 ושימוש בו עבור פוקימון מסויים יגדיל את ה HP של אותו פוקימון ב 20, אך ה HP לא יעבור את ה 100 בכל מקרה(. Pokecoin לפי הערך(. מחיר יחידת ערך אחת הוא שני CP לאימון פוקימונים )הגדלת ה )Candy( סוכריה o )סוכריה בערך 20 תימכר ב,Pokecoins 40 ושימוש בה עבור פוקימון מסויים יגדיל את ה CP של אותו פוקימון ב 20(. כל פריט ניתן לשימוש פעם אחת בלבד מאמני פוקימונים Trainers( )Pokemon המשחק מורכב משחקנים, אשר נקראים מאמני פוקימונים. כל מאמן מזוהה ע"י שם ייחודי, וברשותו פוקימונים ופריטים )ראו למטה(. לכל מאמן ניסיון )XP( מספר ממשי חיובי, המאותחל ל 1. מאמנים יכולים לצוד פוקימונים, וכך הם יכולים לאסוף אותם. כדי שנוכל לגשת לפוקימונים של מאמנים, נצמיד לכל פוקימון לא חופשי )פוקימון ששייך למאמן כלשהו( מספר זיהוי ייחודי ID( )Pokemon לו מבין כל הפוקימונים של אותו מאמן. מספרי הזיהוי יינתנו לכל פוקימון בעת צידתו, באופן עולה, החל מ 1 )לפוקימון הראשון של כל מאמן ניתן את מספר הזיהוי 1, לשני 2, וכו'(. העולם העולם מורכב מאוסף של מקומות.)locations( לכל מקום x מוגדר אוסף של מקומות קרובים, כלומר מקומות שניתן להגיע אליהם ממקום x בפעולה אחת. כל מאמן מתחיל את המשחק בנקודת התחלה מסויימת, ויכול לטייל ברחבי העולם ממקום למקום. הפוקימונים החופשיים נמצאים ברחבי העולם. בפרט, עבור כל מקום מוגדרת רשימה של פוקימונים. בכל רגע נתון, הפוקימון העומד בראש הרשימה הינו הפוקימון הנמצא באותו מקום. ברגע שמגיע מאמן, וצד )ראו בהמשך( פוקימון זה, הפוקימון יהפוך להיות שייך למאמן, וייעלם מהמקום ממנו נלקח.

6 ציד פוקימונים ציד מתרחש בשני המקרים הבאים: o בעת הוספת מאמן חדש למשחק במקום התחלתי כלשהו, המאמן צד את הפוקימון הנמצא במקום זה. o בעת מעבר של מאמן ממקום למקום אחר, המאמן צד את הפוקימון הנמצא במקומו החדש. פוקימון ניצוד כשהוא ברמה התחלתית 1, ובהתחלה יהיו לו.HP 100 לעומת זאת, ערך ה CP ההתחלתי הוא תלוי מין, והוא מצויין בקובץ ה Pokedex המסופק בעת אתחול המשחק. ציד של פוקימון רגיל אחד מזכה את המאמן ב.Pokecoins 10 אם אחד מסוגי הפוקימון הינו סוג בעל שתי כוכביות )ראו למעלה(, המאמן יזוכה ב,Pokecoins 30 אחרת, אם אחד מסוגי הפוקימון הינו סוג בעל כוכבית אחת, המאמן יזוכה ב.)Pokecoins 30 כפל הטבות" במובן שאם לפוקימון יש גם סוג * וגם סוג **, המאמן יזוכה רק ב )"אין Pokecoins 20 התפתחויות פוקימון יכול להתפתח ממין מסוים למין אחר ברגע שהגיע לרמה מסויימת. ההתפתחויות האפשריות מצויינות בקובץ קלט המסופק בעת אתחול המשחק. כאשר פוקימון מתפתח, ערך ה CP שלו מתעדכן בהתאם למינו החדש, תוך שמירה על השיפור בעוצמה הנוצרה ע"י שימוש קודם בסוכריות. למשל, נניח שבבעלותנו פוקימון בעל ערך CP התחלתי 150, שגדל )ע"י שימוש בסוכריות( ל 250. CP אם פוקימון זה יתפתח למין בעל ערך CP התחלתי 400, ערך ה CP של פוקימון זה יגדל להיות ) (. 500 קרבות מאמנים מתחרים ביניהם ב קרבות פוקימונים. בקרב פוקימונים משתתפים שני מאמנים. כל מאמן בוחר פוקימון משלו לקרב. יהיו HP 1, CP 1, XP 1, Level 1 הנתונים של המאמן הראשון והפוקימון שלו, ו HP 2, CP 2, XP 2, Level 2 הנתונים של המאמן השני והפוקימון שלו. נגדיר Δ 1 XP 2 CP 2 (1 + HP ) Δ 2 XP 1 CP 1 (1 + HP ) הקרב גורם לשינויים הבאים בערכים אלה: Level 1 = Level 1 + Level 1 + Level 2 Level 4 2 = Level 2 + Level 1 + Level 2 4 HP 1 = HP 1 Δ 1 HP 2 = HP 2 Δ 2 XP 1 = XP 1 + Δ 2 XP 10 2 = XP 2 + Δ 1 10 בסיום כל קרב, כל פוקימון שהגיע לאפס נקודות חיים מת, ונמחק מהמשחק. בנוסף, אם ישנה אפשרות לבצע התפתחות של אחד\שני הפוקימונים, ההתפתחויות מבוצעות התוכנית התוכנית אשר תיקרא,pokemon_go_mtm תופעל משורת הפקודה באופן הבא: pokemon_go_mtm p <pokedex_filename> e <evolutions_filename> l <locations_filename> [i <input_file>] [o <output_file>] שלושת הפרמטרים הראשונים הינם שמם של קבצי הקלט הבאים: :pokedex o הקובץ מכיל בכל שורה שלוש או יותר מילים המופרדות ע"י רווח: מין הפוקימון, ערך ה CP ההתחלתי שלו, ורשימה של סוגי הפוקימון. :evolutions o הקובץ מכיל בכל שורה שלוש מילים המופרדות ע"י רווח: מין הפקימון לפני ההתפתחות, מין הפוקימון אחרי ההתפתחות, והרמה הדרושה לביצוע ההתפתחות. :locations o הקובץ מכיל בכל שורה מילה אחת או יותר המופרדות ע"י רווח ונקודהפסיק: המילה הראשונה היא תמיד שם המקום. אחרי השם, תבוא רשימת הפוקימונים הנמצאים במקום זה לפי הסדר מהראשון לאחרון מופרדים ע"י רווח )ייתכן שהרשימה תהיה ריקה(. אחרי רשימת הפוקימונים )או מיד אחרי השם אם המקום ריק מפוקימונים( יופיע סימן נקודהפסיק );(, ואחריו תבוא רשימת המקומות שניתן להגיע אליהם מהמקום המצויין בתחילת השורה. שימו לב שגם הרשימה הזו יכולה להיות ריקה, ושאם זה המצב, אז לא יופיע סימן הנקודהפסיק )ראו דוגמא לקובץ זה בתיקייה המצורפת(. ניתן להניח כי שלושת קבצי הקלט הנ"ל הינם תקינים מבחינת מבנה ותוכן )למשל: כל מין של פוקימונים שמצויין ב location נמצא ב,pokedex אין כפילויות ב pokedex או ב,evolutions וכו'(. תוכלו למצוא דוגמאות לקבצי הקלט בתיקיית התרגיל. כמו כן, ניתן להניח גם שבשלושת קבצי הקלט, אורך שורה מוגבל ל 250 תווים.

7 שימוש בפרמטר "i" יגרום למערכת לקבל הוראות מהקובץ.<input_file> אחרת, המערכת תקבל הוראות מערוץ הקלט הסטנדרטי input(.)standard גם פה ניתן להניח שאורך שורת פקודה אינו ארוך מ 250 תווים. שימוש בפרמטר "o" יגרום למערכת לשלוח את הפלט שהיא מפיקה לקובץ ששמו.<output_file> אחרת, המערכת תשלח את הפלט לערוץ הפלט הסטנדרטי output(.)standard שימו לב ששני הפרמטרים האחרונים הם, רשות. שימוש ב" i " או "o" ללא העברת שמות הקבצים, או העברת ארגומנטים אחרים מלבד הנ"ל אינו חוקי! במקרים אלו יש לדווח על השגיאה המתאימה באמצעות mtmprinterrormessage עם פרמטר מתאים ולצאת מהתוכנית. שינוי סדר הארגומנטים )למשל, קודם "o" ואז "i"( אינו חוקי. לעומת זאת, שימוש ב o בלי להשתמש ב i )ולהפך( הינו חוקי לחלוטין. במקרה שמבנה הפרמטרים לתוכנית אינו תקין יש לדווח על שגיאה מסוג.MTM_INVALID_COMMAND_LINE_PARAMETERS אם הפרמטרים תקינים אך פתיחת אחד הקבצים נכשלת יש לדווח על.MTM_CANNOT_OPEN_FILE הקלט לתוכנית בין אם מערוץ הקלט הסטנדרטי ובין אם מקובץ, הקלט מורכב מסדרת שורות טקסט, כאשר בכל שורה תהיה פקודה אחת. ייתכנו שורות ריקות שלא יכילו פקודות כלשהן. במידה והקלט הוא מערוץ הקלט הסטנדרטי נסיים את התוכנית ע"י שילוב המקשים.)EOF( ctrl+d אחרת התוכנית תסיים את ריצתה ברגע שתגמור לקרוא את הקלט מהקובץ. ניתן להניח כי הקלט תקין מבחינה סינטקטית )כלומר, הפקודות מאויתות נכון ומספר הפרמטרים לכל פקודה תקין(. כלומר כל שורת קלט היא אחת משני הסוגים הבאים: <command> <subcommand> [<arg1> <arg2>...] שורה המכילה פקודה חוקית )ייתכנו רווחים וטאבים בתחילת השורה(. 1. שורה ריקה )שורה שאינה מכילה כלל תווים או לחילופין מכילה רק רווחים וטאבים(. 2. מבנה שורת הפקודה הוא כדלקמן: כאשר <command> הוא שם הפקודה, <subcommand> הוא שם תת הפקודה ו <arg2> <arg1> היא רשימת הפרמטרים לפקודה. אורך רשימת הפרמטרים יכול להשתנות מפקודה לפקודה וייתכנו פרמטרים אופציונאליים אשר לא תמיד יופיעו. בין כל זוג מילים יופיע תו רווח/טאב אחד לפחות אך ייתכנו מספר רווחים/טאבים בין כל זוג מילים טיפול בשגיאות במקרה של שגיאות, על PokemonGo להחזיר ערך שגיאה מתאים לתכנית הראשית, והתוכנית תדווח על השגיאה בעזרת הפונקציה.mtmPrintErrorMessage במקרה שיש כמה שגיאות אפשריות יש לדווח על השגיאה החשובה ביותר כאשר סדר הוא הסדר בו מופיעות השגיאות בהגדרתם בקובץ.print_utils.h במקרה של כישלון באתחול המערכת בגלל מבנה שורת פקודה לקוי, תקלה בפתיחת קבצי הקלט/פלט או תקלה בהקצאת זיכרון יש לדווח על השגיאה המתאימה ולצאת מהמערכת תוך שחרור מסודר ומפורש של כל הזיכרון והמשאבים האחרים. מאחר וברצוננו להשתמש בADT הראשי )PokemonGo( בעתיד, חובה לוודא כי במקרה של שגיאה כלשהי )מלבד שגיאת )MTM_OUT_OF_MEMORY המערכת נשמרת במצב תקין. כלומר לאחר גילוי שגיאה מצב המערכת יהיה כאילו לא בוצעה פקודה כלשהי. הטיפול בשגיאות צריך להתבצע על ידי החזרת קוד שגיאה מתאים מ, PokemonGo והדפסת המידע אודות השגיאה צריכה להתבצע מהתוכנית המשתמשת ב PokemonGo וזאת על מנת לאפשר גמישות בדיווח ההודעות בעתיד.

8 ניתן להניח כי לא קיימות שגיאות נוספות מלבד אלו המפורטות לכל פקודה )ושגיאות MTM_OUT_OF_MEMORY להתרחש בכל נקודה בתוכנית כתלות במימוש(. היכולות בכל מקרה, לא ניתן להשתמש ב exit לשם יציאה לאחר שגיאה ומאחר ופונקציה זו מקשה על שינויים עתידיים בקוד ופוגעת בקריאותו.

9 3.2.5 פקודות על המערכת להכיר את הפקודות הבאות: trainer add <name> <budget> <start_point> 1. הוספת מאמן תיאור הפעולה: פקודה זו מוסיפה מאמן פוקימונים חדש למערכת. מאחר שבעת הוספתו, המאמן מנסה לצוד פוקימון במקומו ההתחלתי, נרצה להדפיס את תוצאות הניסיון הזה. אנא השתמשו בפונקציות ההדפסה המסופקות לכם ב print_utils.h כדי להדפיס את תוצאות ניסיון הציד )נמצא/ לא נמצא פוקימון(. תוכלו גם למצוא דוגמא להדפסה כזו בקבצי דוגמאות של קלטפלט המצורפים. פרמטרים: <name> שם המאמן הייחודי. לא יתכנו שני מאמנים בעלי שם זהה. <budget> מספר ה Pokecoins ההתחלתי של המאמן החדש. <start_point> שם המקום בו יתחיל המאמן החדש את המשחק. שגיאות: MTM_TRAINER_ALREADY_EXISTS כבר קיים מאמן בעל שם זהה במערכת. MTM_INVALID_ARGUMENT התקציב הנתון אינו מספר שלם אישלילי. MTM_LOCATION_DOES_NOT_EXIST לא קיים בעולם מקום בעל שם זה. trainer go <name> <location> 2. הגעה למקום וניסיון ציד תיאור הפעולה: בביצוע פקודה זו, המאמן הנתון מגיע למקום המצויין ומנסה לצוד את הפוקימון הנמצא שם )אנו מניחים שאם קיים פוקימון במקום, הציד הוא תמיד מוצלח(. אנא השתמשו בפונקציות ההדפסה המסופקות לכם ב print_utils.h כדי להדפיס את תוצאות ניסיון הציד )נמצא/ לא נמצא פוקימון(. תוכלו גם למצוא דוגמא להדפסה כזו בקבצי דוגמאות של קלטפלט המצורפים. פרמטרים: <name> שם המאמן. <location> שם המקום אליו מגיע המאמן. שגיאות: MTM_TRAINER_DOES_NOT_EXISTS לא קיים במערכת מאמן בעל שם זה. MTM_LOCATION_DOES_NOT_EXISTS לא קיים בעולם מקום בעל שם זה. MTM_TRAINER_ALREADY_IN_LOCATION המאמן כבר נמצא ביעד המצויין. MTM_LOCATION_IS_NOT_REACHABLE לא ניתן להגיע מהמקום בו נמצא המאמן למקום המצויין. store add <item> <value> <quantity> 3. הוספת פריטים לחנות תיאור הפעולה: פקודה זו מוסיפה פריטים למלאי החנות של המשחק.

10 פרמטרים:.) candy או potion ( סוג הפריטים <item> <value> ערך הפריטים. <quantity> כמות הפריטים. <item> אינו אחד משני המחרוזות החוקיות, או ש quantity או value אינם מספרים שגיאות: MTM_INVALID_ARGUMENT שלמים חיובייים. trainer purchase <name> <item> <value> 4. קניית פריט תיאור הפעולה: פקודה זו מבצעת קניה של פריט מהחנות ע"י מאמן. פרמטרים: <name> שם המאמן..) candy או potion ( סוג הפריט אותו מעוניין לקנות המאמן <item> <value> ערך הפריט אותו מעוניין לקנות המאמן. שגיאות: MTM_TRAINER_DOES_NOT_EXIST לא קיים במערכת מאמן בעל שם זה. <item> MTM_INVALID_ARGUMENT אינו אחד משני המחרוזות החוקיות, או ש value אינו מספר שלם חיובי. MTM_BUDGET_IS_NOT_SUFFICIENT אין ברשות המאמן התקציב הדרוש לקניית הפריט. MTM_ITEM_OUT_OF_STOCK לא קיים במלאי החנות פריט זה בערך המצויין. battle fight <trainer1> <trainer2> <pokemon1> <pokemon2> 5. דוקרב תיאור הפעולה: פקודה זו מבצעת דוקרב בין שני פוקימונים של שני מאמנים שונים. אנא השתמשו בפונקציות ההדפסה המסופקות לכם ב print_utils.h כדי להדפיס את תוצאות הקרב. תוכלו גם למצוא דוגמא להדפסה כזו בקבצי דוגמאות של קלט פלט המצורפים. פרמטרים: <trainer1> שמו של המאמן הראשון. <trainer2> שמו של המאמן השני. <pokemon1> מספרו היחודי של הפוקימון של המאמן הראשון. <pokemon2> מספרו היחודי של הפוקימון של המאמן השני. שגיאות: MTM_TRAINER_DOES_NOT_EXIST אחד או שני המאמנים לא נמצאים במערכת. MTM_POKEMON_DOES_NOT_EXIST אחד או שני הפוקימונים לא נמצאים במערכת. MTM_INVALID_ARGUMENT הועברו שני שמות מאמנים זהים. pokemon heal <trainer> <pokemon_id> 6. ריפוי פוקימון תיאור הפעולה: פקודה זו משתמשת בשיקוי שברשות המאמן כדי לרפא את אחד הפוקימונים שלו. כדי להימנע מבזבוז שיקויים יקרים עבור ריפויים פשוטים, נבחר את השיקוי בעל הערך הנמוך ביותר, שיגרום לקבלת 100. HP אם אין שיקוי כזה, אז נבחר את

11 השיקוי בעל הערך המקסימלי שברשות המאמן. במקרה בו לפוקימון כבר יש 100, HP ו/או אין ברשות המאמן שיקויים, תוחזר השגיאה המתאימה )לפי הפירוט למטה(. פרמטרים: <trainer> שמו של המאמן. <pokemon> מספרו היחודי של הפוקימון. שגיאות: MTM_TRAINER_DOES_NOT_EXIST המאמן לא נמצא במערכת. MTM_POKEMON_DOES_NOT_EXIST הפוקימון לא נמצא במערכת. MTM_NO_AVAILABLE_ITEM_FOUND אין ברשות המאמן שיקויים. MTM_HP_IS_AT_MAX לפוקימון הנתון יש מקסימום נקודות חיים )100(. pokemon train <trainer> <pokemon_id> 7. אימון פוקימון תיאור הפעולה: פקודה זו משתמשת בסוכריה בעלת הערך הגבוה ביותר שברשות המאמן כדי לאמן את אחד הפוקימונים שלו. פרמטרים: <trainer> שמו של המאמן. <pokemon> מספרו היחודי של הפוקימון. שגיאות: MTM_TRAINER_DOES_NOT_EXIST המאמן לא נמצא במערכת. MTM_POKEMON_DOES_NOT_EXIST הפוקימון לא נמצא במערכת. MTM_NO_AVAILABLE_ITEM_FOUND אין ברשות המאמן סוכריות. report trainer <trainer> 8. הצגת פרטי מאמן תיאור הפעולה: פקודה זו מדפיסה את פרטי המאמן הנתון. הפריטים שברשות המאמן יודפסו בסדר הבא: בהתחלה כל הסוכריות, לפי הערך )בסדר עולה(, ואז כל השיקויים לפי ערך )בסדר עולה(. הפוקימונים יודפסו לפי מספר הזיהוי )בסדר עולה(. לצורך מימוש פעולה זו אנא השתמשו בפונקציות ההדפסה המסופקות לכם ב.print_utils.h תוכלו גם למצוא דוגמא להדפסה כזו בקבצי דוגמאות של קלטפלט המצורפים. פרמטרים: <trainer> שמו של המאמן. שגיאות: MTM_TRAINER_DOES_NOT_EXIST המאמן לא נמצא במערכת. report locations 9. הצגת מפת העולם תיאור הפעולה: פקודה זו מדפיסה את רשימת המקומות בעולם לפי סדר לקסיקוגרפי עולה, יחד עם הפוקימונים הנמצאים כרגע בכל אחד מהמקומות. לצורך מימוש פעולה זו אנא השתמשו בפונקציות ההדפסה המסופקות לכם ב.print_utils.h תוכלו גם למצוא דוגמא להדפסה כזו בקבצי דוגמאות של קלטפלט המצורפים. פרמטרים: אין. שגיאות: אין.

12 report stock 10. הצגת המלאי בחנות תיאור הפעולה: פקודה זו מדפיסה את רשימת הפריטים הנמצאים כרגע במלאי החנות, לפי אותו סדר הדרוש בהדפסת פרטי מאמן )לפי ערך, סוכריות תחילה(. לצורך מימוש פעולה זו אנא השתמשו בפונקציות ההדפסה המסופקות לכם ב.print_utils.h תוכלו גם למצוא דוגמא להדפסה כזו בקבצי דוגמאות של קלטפלט המצורפים. פרמטרים: אין. שגיאות: אין הגבלות על המימוש על המימוש שלכם לעמוד במגבלות הבאות: אין חסם על גודל הרשומות במערכת מכל סוג שהוא. את כל ההדפסות לפלט יש לבצע באמצעות מחרוזות המתקבלות באמצעות פונקציות הפלט המסופקות בקובץ.print_utils.h ניתן למצוא את אופן השימוש בפונקציות בקובץ זה. המימוש של הפונקציות המוגדרות שם נמצא בספריה libmtm.a )אתם לא צריכים לממש את הפונקציות אלא רק לקשר את הספריה(. לכל המחרוזות הנשמרות במערכת יש להקצות את גודל הזיכרון הדרוש וללא זיכרון מיותר. לצורך מימוש מבני הנתונים נתונים לכם מימושים של רשימה,)List( מילון (Map) וקבוצה )Set( אשר המנשקים שלהם מוגדרים בקבצים h. ומימושם נמצא בספריה המצורפת לתרגיל. o לכל מבני הנתונים בתרגיל יש לבחור האם להשתמש ברשימה, בקבוצה או מילון בהתאם לנלמד בקורס. הבהרה: כדי שלא יהיו תלויות בין התרגילים קיים קובץ h שנקרא map.h שבאמצעותו תקשרו את התוכנית שלכם למימוש עובד של רשימה בספריה שנצרף לכם )אין צורך להשתמש ב map _mtm שמימשתם בחלק 3.1(. המימוש חייב לציית לכללי כתיבת הקוד המופיעים תחת.Course Material / Code Conventions אי עמידה בכללים אלו תגרור הורדת נקודות. על המימוש שלכם לעבור ללא שגיאות זיכרון )גישות לא חוקיות וכדומה( וללא דליפות זיכרון. המערכת צריכה לעבוד על.Stud/T2 אין לשנות את הקבצים שסופקו לכם. קבצים אלו אינם מוגשים ונשתמש בקבצים המקוריים לבדיקת הקוד הסופי. יש לכתוב את הקוד בפונקציות קצרות וברורות. מימוש כל המערכת )מלבד התוכנית הראשית( צריך להיעשות ע"י חלוקה לADT שונים. נצפה לחלוקה נוחה של המערכת כך שניתן יהיה להכניס שינויים בקלות יחסית ולהשתמש בטיפוסי הנתונים השונים עבור תוכנות דומות. ניתן לכתוב את חלק ניתוח הקלט )הקורא לפעולות הADT ( הראשי ללא חלוקה לADTs.

13 3.2.7 הנחות מאחר והתוכנית הראשית תשמש את התוכנה זמנית, ניתן להניח את ההנחות הבאות בשלב ניתוח הקלט: המחרוזות לפקודות במנשק הטקסט אינן מכילות רווחים. ניתן להניח שמספר הפרמטרים לכל פקודה נכון. ניתן להניח שיתנו רק שמות חוקיים של פקודות. לכל פרמטר מספרי ניתן להניח שאכן יסופק מספר שלם, עם זאת אין להניח שהמספר בטווח החוקי. אסור להסתמך על הנחות אלו )ותחת הרגלי עבודה נכונים הנחות אלה רלוונטיות רק לחלק ניתוח הקלט. על PokemonGo ADT אין הן אמורות להשפיע כלל על חלק זה של התרגיל(. 3.3 בדיקות יחידה כאמור על המימוש להיות מורכב מטיפוסי נתונים מופשטים. עליכם לספק לכל אחד מה ADT אותם תכתבו בדיקות יחידה. בדיקת יחידה היא קוד אשר מוודא את נכונות ה ADT וניתן להרצה בקלות כך שבמקרה של באג בקוד, הבדיקה תיכשל ויהיה קל לאתר את הבאג. עליכם לממש בדיקת יחידה דומה לכל ה ADT שתגישו. למשל עבור PokemonTrainer עליכם לספק את הקובץ אשר בודק בצורה אוטומטית את ה ADT. pokemon_trainer_test.c בנוסף עליכם ליצור בדיקת יחידה עבור המילון שמימשתם בסעיף 3.1 להלן מספר דגשים לגבי כתיבת בדיקות יחידה: אין להוסיף פונקציות למנשק של ה ADT כדי לאפשר עוד בדיקות. ניתן להסתפק בבדיקות אותן ניתן לבצע בעזרת המנשק הקיים. אין צורך לבדוק פקודות קלט/פלט באמצעות בדיקות היחידה למעט מקרים טריוויאליים )לדוגמא עודף/מחסור בפלט/קלט(. הקפידו לבדוק את התנהגות הפונקציה גם במצבי שגיאות ולא רק בעבור קלט מוצלח. הקפידו על איכות הקוד גם בבדיקות היחידה הבדיקות צריכות להיות קצרות, מחולקות לפונקציות וקריאות, כך שבמקרה של כישלון יהיה קל למצוא את מקור התקלה. מומלץ לחלק את הבדיקות כך שלכל פונקציה קיימת פונקציה הבודקת אותה. o בקובץ הנמצאת המילון, עבור המסופקת הבדיקה על הסתכלו יחידה בדיקת להיראות צריכה כיצד לראות כדי.map_example_test.c המלצה: כתיבת בדיקות לוקחת זמן אך מקלה משמעות את תחזוקת הקוד בהמשך ועל צמצום הזמן הדרוש למציאת תקלות בתוכנית. מומלץ לכתוב את הבדיקות במקביל לכתיבת הקוד, כך למשל לפני שאתם כותבים פונקציה מסוימת הכינו כבר את הפונקציה הבודקת אותה. את כתיבת הבדיקות כדאי לעשות כאשר חושבים כיצד ניתן "להכשיל" את הקוד ובכך לוודא את איכות הקוד במקרי קצה. כתיבת כל הבדיקות לאחר סיום התרגיל תהיה מעיקה משמעותית ותתבצע לאחר השלב בו הבדיקות יוכלו לעזור בפועל.

14 Makefile 3.4 עליכם לספק Makefile כמו שנלמד בקורס עבור בניית הקוד של תרגיל זה. הכלל הראשון בMakefile יקרא pokemon_go_mtm ויבנה את התוכנית pokemon_go_mtm המתוארת בסעיף 3.2. בנוסף יופיע כלל בשם tests אשר יבנה את בדיקות היחידה. לכל בדיקת יחידה )למשל )map_test.c תיבנה תכנית בשם מתאים )במקרה זה )map_test אשר תאפשר את הרצת הבדיקה. יש להניח שהקבצים מסודרים במבנה הבא: כל בדיקות היחידה נמצאות תחת תיקיה בשם tests וכל שאר הקבצים בתיקיה בה נמצא הMakefile. יש לכתוב את הקובץ כפי שנלמד וללא שכפולי טקסט. 3.5 הידור, קישור ובדיקה התרגיל ייבדק על שרת stud/t2 ועליו לעבור הידור בעזרת הפקודה הבאה: gcc std=c99 o pokemon_go_mtm Wall pedanticerrors Werror DNDEBUG *.c L. lmtm lm משמעות הפקודה: קביעת התקן לשפה להיות C99 :" std=c99" pokemon_go_mtm" o ": הגדרת שם הקובץ המהודר :" Wall" דווח על כל האזהרות :" pedanticerrors" דווח על סגנון קוד שאינו עומד בתקן הנבחר כעל שגיאה :" Werror" התייחס לאזהרות כאלה שגיאות )הקוד חייב לעבור ללא אזהרות( :" DNDEBUG" מוסיף את השורה NDEBUG" "#define בתחילת כל יחידת קומפילציה. מתג זה יגרום לכך שהמאקרו assert )אם בשימוש( לא יפריע ולא יופעל בריצת התוכנית. o "c.*": בחירת כל קבצי הקוד על התרגיל להיות מורכב בקבצי c וקבצי h בלבד )אשר נכללים באמצעות פקודות.)include שימו o הקבצים להיות בספרית השורש של הקובץ zip אשר תגישו. בנוסף עליכם לוודא שתרגיל מתקמפל עם הקבצים אשר מסופקים על ידינו. אין להגיש קבצים אלה! o ".L ": גורם לgcc לחפש ספריות בתיקיה הנוכחית. :" lmtm" קישור לספריה שמסופקת לכם ע"י הצוות. :" lm" קישור לספריה math.h הסטנדרטית )יתכן שתשתמשו בה לצורך חישובים מתמטיים(. כל שעל לב התרגיל ייבדק בדיקה יבשה ובדיקה רטובה. הבדיקה היבשה כוללת מעבר על הקוד ובודקת את איכות הקוד )שכפולי קוד, קוד מבולגן, קוד לא ברור, שימוש בטכניקות "רעות"(. הבדיקה הרטובה כוללת את הידור התכנית המוגשת והרצתה במגוון בדיקות אוטומטיות. ע"מ להצליח בבדיקה שכזו על התוכנית לעבור הידור, לרוץ את הבדיקה בשלמות ולעבור השוואה של קבצי הפלט עם קבצי הפלט המצופים. ההשוואה תתבצע בעזרת הפקודה diff המחזירה את ההבדלים בין זוג קבצים או אינה מדפיסה כלום במקרה של זהות בין הקבצים. ע"מ לבדוק את תכניתכם מסופקים שלושה קבצי בדיקה שכאלו עם הפלט המצופה שלהם. את הקבצים ניתן למצוא תחת ספרית הקורס בstud בכתובת הבאה: העתיקו קבצים אלה לספרית העבודה שלכם. לבדיקת הפתרון שלכם ניתן להריץ את הפקודות הבאות ~mtm/public/1617a/ex3/ (mtm_love < test1.in >! tmpout) >&! tmperr diff expout1 tmpout diff experr1 tmperr

15 אם אין הבדלים הפקודות לא ידפיסו כלום, אחרת יודפסו ההבדלים. לשם צפייה בהבדלים בממשק גרפי ובצורה קריאה יותר ניתן להיעזר בsdiff או kompare )שתי התוכנות דורשות ממשק גרפי(. שימו לב שעל התוכנית שלכם לעבור גם עבור קלט/פלט סטנדרטי וגם עבור שימוש בקבצים כפי שהוגדר קודם. התכנית שלכם תיבדק עם בדיקות נוספות! הבדיקות המסופקות מכסות רק חלק בסיסי מהמקרים האפשריים. בדיקת הקוד מהווה חלק מהתרגיל! תרגיל אשר אינו עובר בדיקות יקבל 0 בבדיקה הרטובה. לא יהיה הנחות בנושא זה! כתבו בדיקות נוספות בעצמכם בהתאם למפרט. וודאו את נכונות התכנית שלכם במקרים כללים ובמקרי קצה. מומלץ לחשוב על הבדיקות כבר בזמן כתיבת הקוד. נסו ליצור הרבה בדיקות קצרות ולא בדיקה אחת גדולה כישלון בבדיקות קצרות עוזר לאתר את התקלה. וודאו את נכונות הקוד גם לאחר שינויים קטנים אשר אינם נראים משמעותיים ולפני ההגשה. עליכם לוודא שהרצה זו מסתיימת בהצלחה וללא דליפות זיכרון או גישות לא חוקיות לזיכרון. כדי לוודא שאין דליפות זיכרון ניתן להשתמש בvalgrind. זהו כלי אשר מותקן בstud ומיועד בין היתר למציאת דליפות זיכרון.

16 4 הגשה 4.1 הגשה יבשה יש להגיש לתא הקורס את פתרון החלק היבש של התרגיל מודפס משני צדי הדף. אין צורך להגיש את הקוד מודפס. 4.2 הגשה רטובה את ההגשה הרטובה יש לבצע דרך אתר הקורס, תחת.Assignments Exercise 3 Electronic submission הקפידו על הדברים הבאים: יש להגיש את קבצי הקוד והmakefile מכווצים לקובץ zip )ולא שום סוג כיווץ אחר( כאשר כל הקבצים עבור הפתרון מופיעים בתיקיית השורש בתוך קובץ הzip, אילו כל בדיקות היחידה )כולל בדיקת היחידה עבור הרשימה מהרטוב הראשון( נמצאות תחת התיקייה tests בתוך קובץ הzip ותיקיה בשם map_mtm שבתוכה יהיה המימוש עבור החלק הראשון של התרגיל הרטוב. אין להגיש אף קובץ מלבד קבצי h וקבצי c אשר כתבתם בעצמכם ואת הmakefile אשר נדרשתם לעשות. יש להגיש את בדיקות היחידה שכתבתם לכל,ADT למשל עבור ADT בשם foo אשר מורכב בשני קבצים שהם foo.h ו foo.c יש להגיש קובץ בשם foo_test.c המכיל בדיקות עבור.foo הקפידו על שמות נכונים ועקביים לקבצי הבדיקה עדי להימנע מבעיות עם הבודק האוטומטי. ע"מ לבטח את עצמכם נגד תקלות בהגשה האוטומטית: o שימרו את קוד האישור עבור ההגשה. עדיף לשלוח גם לשותף. o שימרו עותק של התרגיל על חשבון הstud שלכם לפני ההגשה האלקטרונית ואל תשנו אותו לאחריה )שינוי הקובץ יגרור שינוי חתימת העדכון האחרון(. o כל אמצעי אחר לא יחשב הוכחה לקיום הקוד לפני ההגשה. ניתן להגיש את התרגיל מספר פעמים, רק ההגשה האחרונה נחשבת.

17 דגשים ורמזים הקפידו על כללי הזהב הבאים כדי להקל על העבודה: הקוד תמיד מתקמפל בכל שלב של העבודה, ניתן לקמפל את הקוד ללא שגיאות או ללהגיע למצב זה בכמה שניות עבודה. כל הקוד שנכתב נבדק מאחר והקוד תמיד ניתן להרצה, ודאו בכל הרצה שכל הבדיקות עוברות. הקפידו להיות במצב שבו ע"י לחיצת כפתור ניתן להריץ בדיקה אוטומטית לכל הקוד שכבר נכתב. דבר זה יחסוך זמן דיבוג יקר. אם לא נתונות לכם בדיקות, כתבו אותם בזמן כתיבת הקוד עצמו. יש להקפיד על תכנון נכון של התוכנית וכתיבה נכונה ב C. מומלץ להגדיר פונקציות עזר להמרת ADT אחד לאחר )למשל list לset ולהפך( כדי לנצל את חזקות הADTs. זכרו כי אין דרישות סיבוכיות, לכן שאפו לקוד פשוט וקריא על פני קוד "יעיל". קוד מסורבל ללא צורך אמיתי ייאבד נקודות. יש להקפיד להשתמש בפונקציות שניתנו לכם ליצירת מחרוזות, ולהקפיד שהפונקציות שאתם כותבים היוצרות מחרוזות, ייצרו אותם כך שתעברו את הטסטים המסופקים. טעות קלה של אפילו תו רווח יחיד תכשיל בדיקה שלמה. הנכם רשאים להניח כי לא קיימות שגיאות נוספות מלבד אלו שפורטו. מומלץ להשתמש במאקרו assert המוגדר בקובץ assert.h כפי שהוסבר בתרגול מס' 2. במקרה של הסתבכות עם באג קשה: בודדו את הבאג ושחזרו אותו בעזרת קבצי בדיקה )קובץ + main קובץ קלט( קטנים ככל הניתן. ניתן לעשות זאת ע"י מחיקת חלק מהשורות בקוד ובדיקה אם הבאג מתרחש, והמשך בהתאם. שיטה זו פותרת כמעט כל באג אפשרי, וברוב המקרים ביעילות. ניתן להשתמש ב"דיבאגר" או הדפסות זמניות כדי לבדוק את מצב התכנית בכל שלב. לפחות אחת משתי האפשרויות האלה היא חובה ע"מ להצליח ב"דיבוג" הקוד. 5 6 סקריפט הבדיקה הסופית לנוחיותכם, פורסם סקריפט בדיקה שבודק אם קובץ ההגשה שלכם תקין במחינת מבנה, ושהקבצים הרלוונטים שכתבתם עוברים את הבדיקות לדוגמא שפירסמנו עם התרגיל. שימו לב שסקריפט זה לא בודק שהקבצים עוברים את בדיקות היחידה שאתם כתבתם, או אם ה makefile שכתבתם הוא תקין. 7 שינויים, עדכונים והודעות בנוגע לתרגיל כל ההודעות הנוגעות לתרגיל ימצאו באתר של הקורס בכתובת בעמוד ה FAQ. עמוד זה יכיל הבהרות וכן שאלות ותשובות נפוצות. רק הודעות דחופות תשלחנה בדואר. עליכם לעקוב אחר האתר והעדכונים שיפורסמו בו. בהצלחה!