1. 1 Formal Specifications for Complex Systems (236368) Tirgul Hazara

2. 2 Today: Comments on HW2 (last part) Comments on HW4 Possible solution of HW5 (partial) Answering a question asked by students: Possible solution of Question 2 from Moed B 2007(partial)

3. 3 HW2: Problems with sets “pool = pool'  {car !  office?}” doesn't mean that a car has been taken from the pool: pool' might contain (car !  office?) as well If you say “car!  Rented’ “, it doesn't mean that it’s the only difference between Rented and Rented’ (if not implied by an invariant) In Question 5, some students wanted to add {nil} to the possible offices set, but it’s not allowed to change the definition of a basic set in the middle of a specification. You needed to define a new set, OFFICES  {nil}

4. 4 HW2: Error Treatment Problems ----Error---------- | … office? :OFFICES … ------------------------ | … office?  OFFICES -------------------------- Error treatment won't work if the original schema gives a wrong result without failing : ----ReturnCar---------- ---ErrRet----------- |… car? :CAR …| … ------------------------ -------------------- |… [no condition "car?  Cars"]| car?  Cars … -------------------------- --------------------- impossible!

5. 5 HW4: Temporal Logic General remarks: Equivalence between formulas: show implication in both directions! Whenever you simplify formulas "from inside to outside", you have to justify the equivalence! All the computations are infinite

6. 6 HW4: Temporal Logic (contd) Question 2b: ⃟ ( p S q) is equivalent to ⃟ q Intuition: when q holds in a state s, p S q also holds in s

7. 7 HW4: TLA General remarks: In TLA there are no Z-type powerful invariants. There are statements that can be called "…Invar", but they aren't an additional restriction on the system specified. These are statements that should follow from the specification (theorems of type Spec => []Invar)

8. 8 HW5 –system description: נעיין בתיאור חלקי של מערכת : 1. כל משתמש במערכת יכול להיות במעמד רגיל (regular) או במעמד מיוחד (super). 2. המעבר למצב מיוחד נעשה ע " י שליחת בקשה למנהל המערכת (manager) בערוץ הבקרה (control) ואישור חוזר של המנהל באותו ערוץ ( ערוץ הבקרה ). 3. בסוף השימוש, משתמש במעמד מיוחד יודיע למנהל המערכת בערוץ הבקרה (control) שהוא חוזר למעמד רגיל. שימו לב שהמשתמש יכול לבצע יותר מפעולת שליחה אחת, ו \ או לבצע גם פעולות אחרות, כאשר הוא נמצא במעמד מיוחד. 4. רק כשהמשתמש נמצא במעמד מיוחד הוא רשאי לשלוח נתונים על קו הנתונים (data) שקשור הן למנהל המערכת והן לסביבה. 5. המנהל ידאג כי בו זמנית רק משתמש אחד יהיה במעמד מיוחד. 6. המנהל יכפה כי רק משתמש במעמד מיוחד יוכל לשלוח נתונים. 7. אסור שיהיו " רעשים " ו " האזנות " על קו הבקרה, כלומר, אסור שתהליכים שאינם חלק מהמערכת יכתבו ערכים לקו זה, או יקראו ערכים העוברים בו.

9. 9 HW5 – the task: א. עליכם לכתוב בלוטוס את : 1. תהליך המנהל (manager). על תהליך המנהל לעבוד נכון ללא תלות במספר המשתמשים במערכת. 2. תהליך המשתמש. 3. הרכבה של המנהל עם 3 משתמשים ב. 1. על המפרט שלכם להבטיח כי לא יתכן מצב של קיפאון (dead lock) בהנחה שכל שתמש במעמד מיוחד יחזור להיות משתמש רגיל 2. האם תתכן הרעבה של user במערכת שלכם ? הסבירו. אם כן – רישמו דרישה בלוגיקה טמפוראלית שתמנע את ההרעבה.

10. 10 HW5: partial solution Process manager [data, control] () : noexit:= control ! REQUEST ? id ; control ! ACK ! id; manager_gard [data, control] (id) [] i ; manager [data, control] WHERE Process manager_gard [data, control] (id) : noexit:= data ! id ? msg ; manager_gard [data, control] (id) [] control ! RELEASE ! id; manager [data, control] [] i; manager_gard [data, control] (id) endproc which user sent the request?

11. 11 מפרטים פורמאליים - תירגול שחר דג HW5: partial solution(contd.) process user [data, control] (id) : noexit := control ! REQUEST ! id ; control ! ACK ! id ; superuser [data, control](id) [] i ; user [data, control] (id) WHERE process superuser [data, control] (id) : noexit := control ! RELEASE ! id ; user [data, control] (id) [] data ! id ! msg ; superuser [data, control] (id) [] i; superuser [data, control] (id) endproc We assume that no user fakes its id.

12. 12 מפרטים פורמאליים - תירגול שחר דג HW5: the system hide (control) in ( manager[data, control] || ( user[data, control] (1) ||| user[data, control] (2) ||| user[data, control](3) ) ) Notice that full synchronization of the users will lead to deadlock! The communication protocol is: 1.The user requests the permission to send (on the control line, with it’s id) 2.The manager grants the permission (on the control line; only the requesting user can get it by it’s id) 3.The user sends (id +) data on the data line and the manager ensures that only the correct user will transmit. 4.When done sending, the user returns the special permission back to the manager on the control line.

13. 13 Q.2 from moed B 2007 נתון תהליך BUF[ IN, OUT ] המקבל ערך בשער IN ושומר אותו עד להוצאתו בשער OUT(ובינתיים אינו יכול לקבל ערך נוסף) עבור כל השאלה מתקיים כי קבלת ערכים מתבצעת אך ורק דרך שער IN והצעת ערכים מתבצעת אך ורק דרך שער OUT א. רשמו תהליך THREE[ IN, OUT ] של תור עם עד שלושה ערכים כהרכבה של שלושה תהליכי BUF. על THREE למנוע כל אפשרות של הכנסת איבר מבחוץ שלא דרך השער IN והוצאת איבר שלא דרך השער OUT. עליכם להבטיח כי גם אם בתור מאוכסן איבר בודד, בסופו של דבר, ניתן יהיה לקרוא אותו מהתור. ב. נתון תהליך משתמש ראשון U1[ IN, OUT ] היכול בכל רגע נתון גם לקרוא ערכים וגם לכתוב ערכים מ THREE ונתון תהליך משתמש שני U2[ IN ] היכול רק לקרוא ערכים מ THREE. רישמו הרכבה של מערכת עם תהליך THREE אחד, שני תהליכים מסוג U1 ותהליך בודד מסוג U2 (אין צורך לממש את התהליכים U1 ו U2), כך שכל תהליך יוכל לבצע בפועל את כל הפעולות שלו.

14. 14 Q.2 from moed B 2007 (contd.) ג. רשמו גרסא חדשה של התהליך מ (א) NEWTHREE, שמתנהג כמו THREE, אך כאשר התור 'מלא' (יש בו שלושה ערכים), יאפשר הכנסה של ערך חדש, שיבוא במקום הערך האחרון שהוכנס. גם על גרסא זו להיות הרכבה של שלשה תהליכים המחזיקים (כל אחד) ערך בודד. (שימו לב כי "הדריסה" היא רק של הערך האחרון שהוכנס). עבור סעיף זה, התהליכים יכולים להיות שונים זה מזה, ויש לרשום את מימושם. ד. נניח שני פתרונות ל (ג), try1 ו try2, כשכל טענת LTL הנכונה לגבי try1 מתקיימת גם לגבי try2, ולהיפך, אך לא כך לגבי טענות CTL*. מה הם יחסי השקילות בין try1 ו try2 לגבי סוגי השקילות השונים שהוגדרו לתהליכי LOTOS? נמקו במדוייק. לכל סוג של שקילות, האפשרויות הינן: חייב להתקיים, בטוח שלא מתקיים, אין מספיק מידע.