m1 demands - sagioto/forum GitHub Wiki

סדנה בפרוייקט הנדסת תוכנה מטלה 1 חלק 2 – מימוש גירסא 1 חלק 2 של גירסא 1 עוסק בהקמת מערכת הפורום ובמימוש שירותים (פונקציונליות) בסיסיים. השירותים הם:

1. אתחול
2. כניסה (entry) של אורח לפורום.
3. רישום (registration) חבר לפורום.
4. התחברות (login), והתנתקות (logout) מהפורום (לחברים).
5. צפייה(viewing) ברשימת תתי-הפורומים בפורום, ובנושאיהם.
6. פרסום (publish) הודעה בתת-פורום.
7. צפייה בהודעות של תת-פורום.

הדרישות הנכללות בגירסא זו: מאפיינים ואילוצי נכונות: לא בגירסא: 1.ג,ד,ה; 2.ג,ד; 5.ג; 7. כן בגירסא: 2 אילוצי נכונות שנוספו על ידי הקבוצה. אילוצים נוספים: א. משתתף (משתמש) של הפורום יכול להיות מרוחק ממקום הפורום. ב. משתתף (משתמש) של הפורום מקבל שירותי פורום בעזרת אפליקציה
טכסטואלית (command line) שרצה על המחשב שלו באופן לוקלי,
ומתקשרת עם אפליקציית הפורום. דרישות לא פונקציונליות: רק דרישות קיבול-1,2 נכללות בגירסא 1.

הנחייות למימוש הגירסא:

1. הקבוצה יוצרת מסמך דרישות עבור הגירסא – הנגזר ממסמך הדרישות הכללי, ובהתאם לתוכן הגירסא. למסמך זה, יש להוסיף את תוצרי התכנון שכבר נבנו על ידי הקבוצה בחלק התכנון של גירסא 1.

2. מנהל הגירסא ממנה tester חדש עבור חלק המימוש של הגירסא.

3. צוות הפיתוח דן בארכיטקטורה של המערכת, כפי שמתחייב מדרישות הגירסא.

4. מנהל הגירסא, יחד עם צוות הפיתוח, מחליט מהו המבנה של "מכונת מבחני היחידה", כך שתאפשר regression tests. כלומר, שלאחר כל שינוי בקוד, יבדקו כל הטסטים הקודמים. כדאי לארגן את מבחני היחידה בחבילות (test suits).

5. חלוקת עבודה: א. ארבעת חברי הקבוצה הנימנים עם צוות הפיתוח יחלקו את העבודה ביניהם באופן שיוצהר בתחילת מסמך התכנון של הגירסא. מומלץ לחלק את העבודה בין מרכיב השרת ומרכיב הלקוח. מנהל הגירסא יפקח על החלוקה, וכן על עבודת ה- tester. ה-tester לא יכול להיות אחד המתכננים! ב. צוות השרת יפרסם מימשק (interface), בהתבסס על סיפורי השימוש שכבר פותחו. מומלץ לקרוא על תבנית העיצוב facade.

6. מימוש מרכיב השרת:
   א. לפי הפונקציונאליות של הגירסא, החלטה על שיטות של המחלקות הנכללות בדיאגראמת המחלקות של הגירסא. את השיטות המתוכננות עבור כל מחלקה מפרטים באופן מילולי (אין צורך לשרטט בדיאגראמה). רצוי גם עם הסבר מילולי קצר לכל שיטה. רצוי גם להחליט מי (איזו מחלקה) אחראי על כל סיפור שימוש. ב. לכל סיפור שימוש, יש לספק Sequence Diagram (SD) אחד או יותר, המדגים תסריט של סיפור השימוש. לכל SD – יש לייצר מבחן (או מבחני) יחידה (לדאוג לדווח במבחן היחידה איזה SD הוא מממש). ג. מימוש ומבחני יחידה – לפי סדר שהצוות בוחר. ד. מכונת הטסטים: יש לארגן את הטסטים בחבילות (אפשר לפי סיפורי שימוש, אפשר לפי מבנה האפליקציה, אפשר גם וגם – רק שיובהר בתיאור מכונת הטסטים), ולהפעיל את מכונת הטסטים לאחר כל שינוי (regression testing). ה. לבסוף, לצרף הערכה של ה-test coverage של הגירסא: איך נבחרו הנתונים לטסטים? האם יש כיסוי של כל מסלולי החישוב?

7. מימוש מרכיב הלקוח: א. מימוש טקסטואלי (command line) לדיאגראמת המצבים של הלקוח. ב. מימוש רכיב התקשורת למרכיב השרת ובדיקת תפקודו. ג. אינטגרציה עם מרכיב השרת.

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

9. סיום הגירסא: תיקון מסמך הגירסא כלהלן: א. עידכון דיאגראמות המחלקות של הגירסא על פי העיצוב: ציון התלות בין מחלקות (visibility, navigation). תלויות בין מחלקות מראים באמצעות כיווניות של קשרים בדיאגראמת הניתוח. לא צריך להוסיף שיטות לדיאגראמות. כדאי לשים לב לכך שבשלב המימוש נוספות מחלקות מימוש שאין להן ביטוי במודלים של המערכת. מחלקות כאלו הן, למשל, מחלקות של אוספים (collections), ומחלקות עזר כמו factories ו-utillities. ב. דיאגראמת חבילות המראה את תת-הרכיבים של מרכיב האפליקציה, והתלויות ביניהם. ג. סיפורי שימוש ומבחני הקבלה (רק בטקסט) וה-SDs עבורם. ד. דיאגראמת המצבים המתארת את פעולת מרכיב הלקוח.
   ה. הסבר איך המודל השתנה בעקבות המימוש.

דיון קבוצתי: אחד מחברי הצוות מתבקש להכין סקירה (כ-10 דקות) של: תבנית העיצוב Observer:

1. הסבר של הבעיה בה התבנית מטפלת, כולל דוגמאות
2. הפיתרון המוצע
3. מדוע פותר
4. נקודות חולשה