עקרונות 7 של המודל multilayer

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

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

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

אז נראה את שכבות המודל הזה ואת עקרונותיו.

שכבת הפיתוח

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

2. יישומים לשימוש במכשירים מרובים.  יש לקחת בחשבון שמשתמשים ירצו לגשת למידע ממכשירים שולחניים או ממגוון מכשירים ניידים דרך האינטרנט, ולכן על פיתוח לשקול עקרון זה. למרות שלא קל לחזות את התפתחות הגאדג'טים הידועים, לפחות יש להתייחס למומחיות של הפרויקט למטרות הזנה והורדת נתונים, כמו במקרה של תהליך קדסטרלי, שימוש בציוד GPS ובמחשבי כף יד עם יישומי GIS. / CAD עם יכולות הזנת נתונים מינימאליות בטבלה, ושימוש בנתוני רסטר / וקטור. מכיוון שהתמחות העסקית מגוונת, יש צורך להיות מודעים להתקדמות הטכנולוגיות.

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

שכבת התהליך

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

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

שכבת המשתמש

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

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

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