Maxim

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

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

מה דעתכם? (זה לא עיצוב סופי, הכל ברמה של קונספט)

1	2
3	4
5	6
7	8
9	10

 

את ההשראה קיבלתי מחולצות האלה:

מקווה שמשהו יכול להתאים ;-)

If .Net project contains embedded resources, we can extract them at run-time (for internal-in-program usage or to save as files). Embedded resource can be attached file of any type (popular types: texts, images, sounds).

For example, .Net project contains embedded "License Agreement" text file:

File properties:

This code shows how to load embedded text file into string "license":

public void ExtractResources()
{

Stream sin = Assembly.GetExecutingAssembly().GetManifestResourceStream("SegevSystems.Setup.Files.LICENSE AGREEMENT.TXT");
StreamReader r = new StreamReader(sin);

string license = r.ReadToEnd();

r.Close();
r.Dispose();

sin.Close();
sin.Dispose();

}

// "SegevSystems.Setup.Files" represents namespace where resources are located

This code shows how to save all embedded resources into files:

public void ExtractResources()
{

try
{

Assembly a = Assembly.GetExecutingAssembly();
string[] contents = a.GetManifestResourceNames();

for (int i = 0; i < contents.Length; i++)
{

using (Stream s = a.GetManifestResourceStream(contents[i]))
{

using (BufferedStream b = new BufferedStream(s))
{

string filePath = string.Format("c:\\temp\\{0}", contents[i].Replace("SegevSystems.Setup.Files.", string.Empty));

if (File.Exists(filePath)) File.Delete(filePath);

using (FileStream f = new FileStream(filePath, FileMode.CreateNew))
{

int _res;
while ((_res = b.ReadByte()) >= 0)
{

f.WriteByte((byte) _res);

}
f.Close();

}
b.Close();

}
s.Close();

}

}

}
catch (Exception ex)
{

Debug.WriteLine(string.Format("Error while resource read/write: {0}", ex.Message));

}

}

Hope that this post was helpful :)

 
1. I'm glad and happy for MS invitation to Tech-Ed 2008.

2. If every company will have (hire) managers like Steve Ballmer it will be like Microsoft.

3. Have a nice weekend :)

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

פיתוח תוכנה במודל השכבות

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

מודל זה מוכר בשמות "רב שכבתי" (Multitier Architecture) או N-שכבתי (N-Tier), או תלת-שכבתי (ראו דוגמאות בהמשך).

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

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

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

צורה מקובלת לחלוקה של שכבות:

מהסוף:

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

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

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

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

(בד"כ נהוג לבצע חלוקה לפי שלש שכבות 3-tier, לא כולל את השכבה התחתונה - שכבת התעבורה)

הערות:

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

- סדר ההופעה של השכבות, כמות ומגוון יכול להשתנות מפרויקט לפרויקט.

- ישנם פרויקטים רבים שבהם לא ניתן להפריד את השכבות, למשל שכבת BL (Business Logic) קשה מאוד להפריד משכבת הUI (User Interface) מסיבות שונות.

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

דוגמא לפרויקט אמיתי שבו יישמתי סוג של חלוקה לשכבות.

סכמה מופשטת של חלוקת השכבות בפרויקט:

עץ הפרויקטים בנוי משני חלקים עיקריים:
תיקיה Components - רכיבים, מכילה פרויקטים (ספריות DLL) שהם כללים מסוג Reusable Components, אשר "הושאלו" מפרויקטים אחרים. רכיבים אלה הנם פקדים או מחלקות עם קוד שניתן להשתמש בו בפרויקט זה ("רכיבי תוכנה לשימוש חוזר" הנו נושא מעניין ואולי אכתוב על כך פוסט בעתיד).
תיקיה News Arts - אפליקציה, מכילה פרויקטים (ספריות DLL ופרויקט EXE) אשר שייכים ל- News Arts.

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

כיתוב generic בחלק מן המודולים אומר שמודול זה נמצא בשימוש בפרויקטים נוספים (reusable software component).

יתרונות השימוש במודל השכבות:

::: שימוש ברכיבי תוכנה הניתנים לשימוש חוזר או יצירה של מודולים שיהיה ניתן להשתמש בהם בפרויקטים אחרים בעתיד

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

::: תחזוקה קלה יותר ושיתוף מספר מפתחים בפרויקט אחד (למשל: כל מפתח יעבוד על פיתוח של שכבה מסוימת)

::: יישום שיטת תכנות "מונחת אספקטים" במודל השכבות הנו קל יותר

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

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

עבר מול הווה

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

אציין מספר תחומים שבהם חל שינוי תפיסתי בשנים האחרונות:

(לפני שאכנס לנושא הממשקים אני רוצה לתת סקירה קצרה על ההתפתחות בשיטות הפיתוח/תכנות)

תכנות מודולארי ← תכנות מונחה עצמים

בעשרים שנים האחרונות חל מעבר משיטת פיתוח פרוצדוראלית (מודולארית) לשיטת פיתוח בתכנות מונחה עצמים; לשיטה האחרונה יתרונות בולטים על פני הראשונה.

תכנות מודולארי

מתודולוגיה לפיתוח תוכנה, שהמימוש שלה החל בתחילת שנות השישים, בשפות תכנות כדוגמת ALGOL ו-PL/I ונמשך לאחר מכן בשפות התכנות C ו־Pascal. היא הייתה התפתחות של שיטות הקידוד שקדמו לה, שבהן תוכנית מחשב (למשל בשפת קובול) הייתה כתובה כמקשה אחת, כאשר כל המשתנים פתוחים לכל חלקי הקוד, ובקרת הזרימה נעשתה בעיקר באמצעות פקודת go to.

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

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

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

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

תיאור מופשט:

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

תכנות מונחה עצמים

מתוך ויקיפדיה:

תכנות מונחה עצמים או לעיתים תכנות מוכוון עצמים (באנגלית: Object-Oriented Programming, או בקיצור OOP) - פרדיגמה תכנותית המשתמשת ב-"עצמים" לשם תכנון תוכניות מחשב ויישומים. הפרדיגמה מבוססת על מספר טכניקות ובהן הורשה, מודולאריות, פולימורפיזם וככמוס. טכניקות אלה שימשו בפיתוח תוכנה החל מתחילת שנות ה-80 ואילך, אך השימוש בפרדיגמה בשלמותה החל רק בשנות ה-90. רוב שפות התכנות המודרניות תומכות בתכנות מונחה עצמים.

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

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

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

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

תיאור מופשט:

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

תכנות מונחה עצמים ← תכנות מונחה אספקטים

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

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

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

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

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

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

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

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

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

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

ממשק טקסטואלי

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

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

מערכות הפעלה טקסטואליות (עם מסך מחשב - "oscilloscope") הראשונות: