האתר הישראלי להנדסת תכנה

דף ראשי | מפת האתר | רשימת מושגים | מקורות נוספים | אודות
שליטה כוונת אירועים פירוק מודולרי

שליטה כוונת אירועים - המשך

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

יתרונו של מודל השידור-לכל הוא ביכולתו לאפשר למערכת להתפתח ללא מאמץ. שילוב תת-מערכת חדשה הוא פשוט ונוח, ומתבצע על ידי רישומה עבור האירועים שבאחריותה, ורישום תתי-המערכות הקיימות עבור האירועים שהיא מייצרת. היות ותתי-המערכות משגרות אירועים למערכת מבלי להכיר את תת-המערכות המטפלות, אין גם כל הגבלה על מיקומן של אותן תתי-מערכות. הדבר מאפשר ביזור יעיל של המערכת באופן שקוף לתתי-המערכות עצמן.

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

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

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



ארכיטקטורה זו נמצאת בשימוש רק במערכות זמן-אמת "קשות", בהן זמן התגובה לאירוע הוא קריטי. עם זאת, ניתן לשלב את המודל הזה עם מודל שליטה מרכזית. המנהל דואג להפעלתה השוטפת של המערכת, ושגרות הפסק נכנסות לפעולה רק במקרים המחייבים תגובה מיידית.

שליטה כוונת אירועים לתחילת הדף פירוק מודולרי
©איתן 2003. כל הזכויות שמורות למערכת המידע איתן