דחוף

pichpich

New member
דחוף

יש לי שאלה על הגדרת התפקיד של מנתח מערכות האם מנתח מערכות כשהוא כותב אפיון אמור רק לספר לתוכניתן או למנהל הפיתוח על התליכים שאמורים להתבצע או שהוא מאפיין גם את הפתרון כלומר האם הוא יורד או אמור לרדת לרמת המחלקות והמימוש? האם הוא אמור תמיד לספק למשל את מבנה המחלקות לצורך הפתרון והמידול הנדרש בין על ידי class diagrams או מסמך כלשהו או מה? אני מניח שאני מחפש הגדרת תקפיד מדוייקת על מנתח מערכות.
 

עידו פ

New member
דיברת אבסטרקטית מדי

הסבר - מנתח מערכות אמור לכתוב אפיון מבלי לרדת לפרטים טכניים הרלוונטים לסביבת הפיתוח. היינו, מנתח מערכות שמאפיין את המערכת לפי OOA (שזה Object Oriented Analysis), רגיל להגדיר מחלקות המייצגות את ישויות המידע של המערכת. המחלקות יכילו את המאפיינים של הישויות ואת הקשרים בין הישויות (הכלה, ירושה וכו') ואף ייתכן שהוא יגדיר גם את המתודות (אני אישית לא אוהב לעשות את זה). אך מאחר והמחלקות האלו אינן טכניות הן אינן מחייבות את התוכניתן לגמרי. לדוגמה - המנתח לא אמור להגדיר אם להשתמש עם משתני int או float (אלא אם כן אמר ספציפית שצריך ערך עשרוני וגם אז הוא לא חייב להגדיר float או double), אם לתוכניתן במקרה יותר נוח לממש שדה טלפון ע"י הפרדה בין הקידומת למספר - זה לא אמור לעניין את המנתח, כל עוד הדרישה מתקיימת (נניח - ניתן להדפיס את המספר עם ובלי הקידומת, וניתן להקליד את המספר במלואו ללא המקף). המטרה הסופית של תיק האפיון הינה לספק תוצר אשר ניתן לקחת אותו ולייצר ממנו מערכת. אם המנתח הוא בגישת structured analysis והמערכת כתובה בסביבת OO, יצטרך מישהו (להלן מעצב/ארכיטקט) שיקח את תיק האפיון ויהפוך אותו לתוצר יישים וממודל. במידה והמנתח עובד בגישת OOA, התוצר יהיה יותר קל ליישום - זה הכל ! שים לב להבדל בין האפיון לבין היישום הסופי. האפיון מגדיר שיהיה מסך שבו עושים כך וכך ובודקים כך וכך (ה"מה"). היישום הסופי מגדיר איך המסך מעביר את המידע, איך מבוצעות הבדיקות ואיך המידע נשמר (ה"איך"). אם תהיה זקוק לחידוד נוסף, אתה מוזמן לשאול.
 
למעלה