בגרות במדעי המחשב תכנות באינטרנט 899282/899372 - קיץ 2021 (נבצרים)

מה נדרש: לאחזר רק את העמודה code של המנויים שמקיימים שני תנאים יחד: שכבת גיל "נוער" וגם שיא קטן מ־20 שניות.

רעיון:

פתרון:

SELECT code
FROM AllUsers
WHERE age = 'נוער' AND record < 20;

בדיקה: בנינו טבלה לדוגמה עם 7 מנויים, ובהם: דנה (101, נוער, 18), יוסי (102, נוער, 20), נועה (103, נוער, 25), עומר (104, ילד, 15), רון (105, מבוגר, 19), שירה (106, נוער, 12). השאילתה החזירה את הקודים 101 ו־106 בלבד: יוסי לא נכלל כי 20 אינו קטן מ־20, ועומר ורון לא נכללו כי אינם בשכבת "נוער".

טעות נפוצה: לכתוב OR במקום AND (אז יוחזרו גם כל בני הנוער וגם כל מי ששיאו קטן מ־20), או לכתוב record < '20' עם גרשיים.

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

רעיון: "מספר ... לפי ..." = פונקציית צבירה (count) יחד עם GROUP BY על העמודה שלפיה מחלקים לקבוצות. GROUP BY age מחלק את השורות לקבוצות לפי ערך age, ו־count(*) סופר את השורות בכל קבוצה.

פתרון: התשובה הנכונה היא ד:

Select count(*) from AllUser group by age

למה האחרות שגויות:

בדיקה: על טבלה לדוגמה עם 4 בני נוער, 2 מבוגרים וילד אחד, המשפט ד החזיר שלוש שורות: 1, 2, 4 (מספר אחד לכל שכבת גיל). כדי לראות לאיזו שכבה שייך כל מספר, נוח להוסיף את age לרשימת העמודות:

Select age, count(*) from AllUser group by age

שהחזיר: ילד – 1, מבוגר – 2, נוער – 4. משפט א החזיר את המספר 7 בלבד, ומשפט ב נכשל בשגיאת תחביר.

הערה: בשאלה הטבלה נקראת AllUsers ובאפשרויות נכתב AllUser – זה אינו משפיע על הבחירה.

מה נדרש: לתאר מה הדפדפן מציג – כלומר את הטבלה ש־Response.Write שולח, ולא את קוד ה־HTML.

רעיון: הלולאה עוברת על כל המספרים הדו־ספרתיים 10–99. עבור m דו־ספרתי:

התנאי מתקיים רק כששתי הספרות שוות: 11, 22, ..., 99. לכל מספר כזה נוספת שורה (<tr>) עם תא אחד (<td>).

מעקב (חלקי):

פתרון: המחרוזת שנשלחת לדפדפן (שבירות השורות נוספו לקריאוּת):

<table border = '1'>
<tr><td>11</td></tr>
<tr><td>22</td></tr>
<tr><td>33</td></tr>
<tr><td>44</td></tr>
<tr><td>55</td></tr>
<tr><td>66</td></tr>
<tr><td>77</td></tr>
<tr><td>88</td></tr>
<tr><td>99</td></tr>
</table>

מה יוצג בדפדפן: טבלה עם קווי מסגרת (border = '1'), בעלת עמודה אחת ו־9 שורות:

בדיקה: הפונקציה מפיקה בדיוק 9 שורות, 11 עד 99.

טעות נפוצה: לחשוב ש־m / 10 נותן מספר עשרוני (למשל 1.1). ב־C# חילוק של שני int הוא חילוק שלמים. טעות נוספת: לצייר את כל המספרים בשורה אחת – כל מספר נמצא בתוך <tr> משלו, ולכן בשורה נפרדת.

מה נדרש: להשלים חמישה ביטויים כך שהפונקציה תחזיר true רק למייל שמתחיל באות אנגלית, מסתיים ב־.com או ב־.co.il ומכיל @ אחד בדיוק.

רעיון – ביטוי אחר ביטוי:

פתרון:

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

function isCorrectMail ()
{
     var mail = document.getElementById("mail").value;
     var num = 0;
     if (!((mail.charAt(0) >= 'a' && mail.charAt(0) <= 'z') || (mail.charAt(0) >= 'A' && mail.charAt(0) <= 'Z')))
          return (false);
     if (!(mail.indexOf(".com") == (mail.length - 4)))
          if (!(mail.indexOf(".co.il") == (mail.length - 6)))
               return false;
     for (var i = 1; i < mail.length; i++)
     {
          if (mail.charAt(i) == '@')
               num++;
     }
     return (num == 1);
}

בדיקה: מה שמוצג בדפדפן:

הערה למתקדמים: במבנה הנתון יש חולשה – אם המייל קצר מ־4 תווים ואין בו ".com", אז indexOf מחזיר ‎-1, וגם mail.length - 4 שווה ‎-1, ולכן הבדיקה "עוברת". למשל a@b ו־ab@cd מתקבלים כתקינים. אפשר לתקן בתוספת בדיקה שהאורך מספיק, למשל mail.length > 4. חולשה נוספת: indexOf מחזיר את המופע הראשון, ולכן מייל כמו a.com@x.com נדחה אף שהוא מסתיים ב־.com; lastIndexOf היה פותר זאת. זה אינו נדרש בשאלה.

טעות נפוצה: לכתוב ב־[1] mail בלי מירכאות – אז זהו שם של משתנה ולא ה־id של השדה. וב־[5] לכתוב num > 0 – זה מאשר גם מייל עם שני @.

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

רעיון – לפי סדר הפעולות בפונקציה:

פתרון:

(ב־[2] אפשר גם SELECT * – הפונקציה משתמשת רק בעמודות שהיא צריכה.)

הפונקציה המלאה:

protected void PrintTable(string connectionString)
{
     DataSet ds = new DataSet();
     SqlConnection connection = new SqlConnection(connectionString);
     SqlCommand cmd = new SqlCommand();
     cmd.CommandText = " SELECT swimmerName, idNumber, city, gender FROM TableOfSwimmers WHERE style = 'פרפר' ";
     cmd.Connection = connection;
     connection.Open();
     SqlDataAdapter adapter = new SqlDataAdapter(cmd);
     adapter.Fill(ds) ;
     connection.Close();
     string resultStr = "<table>";
     resultStr += "<tr><th> עיר מגורים </th><th>מגדר</th><th> שם </th><th> מספר זיהוי</th></tr>";
     foreach (DataRow dr in ds.Tables[0].Rows)
     {
          resultStr += "<tr>";
          resultStr += "<td>" + dr["city"].ToString() + "</td>";
          resultStr += "<td>" + dr["gender"].ToString() + "</td>";
          resultStr += "<td>" + dr["swimmerName"].ToString() + "</td>";
          resultStr += "<td>" + dr["idNumber"].ToString() + "</td>";
          resultStr += "</tr>";
     }
     resultStr += "</table>";
     Response.Write (resultStr);
}

השאילתה לבדה:

SELECT swimmerName, idNumber, city, gender FROM TableOfSwimmers WHERE style = 'פרפר'

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

<table>
<tr><th> עיר מגורים </th><th>מגדר</th><th> שם </th><th> מספר זיהוי</th></tr>
<tr><td>אשקלון</td><td>זכר</td><td>דוד</td><td>1253</td></tr>
<tr><td>חיפה</td><td>נקבה</td><td>לירון</td><td>5436</td></tr>
<tr><td>קרית שמונה</td><td>נקבה</td><td>יעל</td><td>8564</td></tr>
<tr><td>תל אביב</td><td>זכר</td><td>תומר</td><td>1547</td></tr>
</table>

בדיוק כמו בטבלת הדוגמה.

טעות נפוצה: לשים את WHERE ב־[2] (לפני FROM), או לשכוח את הגרשיים סביב 'פרפר'. וב־[6] לכתוב idNumber בלי מירכאות – האינדקס של dr הוא שם העמודה כמחרוזת.

מה נדרש: לקרוא את שלושת משתני ה־Session ולהפנות (Response.Redirect) לאחד משלושה דפים.

רעיון:

פתרון:

string age = Session["age"].ToString();
string style = Session["style"].ToString();
int record = (int)Session["record"];
if (age == "בוגר" && record < 35 && style == "חתירה")
    Response.Redirect("freeStyle.aspx");
else if (age == "נוער" && record <= 25)
    Response.Redirect("records.aspx");
else
    Response.Redirect("olympic.aspx");

בדיקה:

טעות נפוצה: להשוות את Session["record"] ישירות למספר (Session["record"] < 35) – זה לא עובר הידור, כי הערך הוא object; צריך המרה ל־int. טעות נוספת: לכתוב שלושה if נפרדים בלי else – אז "כל שחיין אחר" אינו מוגדר נכון.

מה נדרש: (1) להסביר למה המונה לא גדל; (2) לכתוב מחדש את הפונקציה כך שתספור את הלחיצות.

הסבר: פרוטוקול HTTP הוא חסר מצב (stateless). בכל בקשה לדף – גם בכל לחיצה על הכפתור (postback) – השרת יוצר עצם חדש של הדף, מריץ את Page_Load, שולח את ה־HTML ללקוח ומשמיד את העצם. לכן המשתנה num, שהוא תכונה של עצם הדף, אינו שומר את ערכו בין הבקשות. בנוסף, השורה num=0; מאפסת אותו בכל טעינה. התוצאה: בטעינה הראשונה מוצג 0, ואחרי כל לחיצה מוצג 1 – ולא 2, 3, ...

רעיון לתיקון: לשמור את המונה במקום שנשמר בין בקשות של אותו משתמש – משתנה Session. בטעינה הראשונה (לא postback) מאתחלים ל־0; בכל postback מגדילים ב־1; ובסוף מעתיקים ל־num כדי ש־<%=num %> יציג אותו.

פתרון: (בקוד הדף הפונקציה נקראת Page_Load – זה השם ש־ASP.NET מפעיל אוטומטית בטעינת הדף, ולכן נשאיר אותו.)

    public int num;
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!Page.IsPostBack || Session["num"] == null)
            Session["num"] = 0;
        else
            Session["num"] = (int)Session["num"] + 1;
        num = (int)Session["num"];
    }

הבדיקה Session["num"] == null מגינה מקריסה אם ה־Session פג תוקף בין לחיצות (המרה (int) של null נכשלת).

בדיקה: הדמינו טעינה ראשונה ואחריה 3 לחיצות, כשבכל בקשה נוצר עצם דף חדש: הקוד המקורי הציג 0 1 1 1, והקוד המתוקן הציג 0 1 2 3.

הערה: אפשר לשמור את המונה גם ב־ViewState. לא כדאי להשתמש ב־Application – הוא משותף לכל המשתמשים, ואז לחיצות של משתמשים שונים יצטברו יחד.

טעות נפוצה: להשאיר את num=0 ורק להעביר את num++ למקום אחר – כל עוד הערך נשמר רק בתכונה של הדף, הוא נמחק בסוף כל בקשה.

מה נדרש: לקבוע אם ייתכן מעבר ל־Page2.aspx עם סיסמה שגויה.

נימוק: Response.Redirect("Page2.aspx") נמצא רק בענף else if (ds.Tables[0].Rows[0]["password"].Equals(Request.Form["password"])), כלומר רק כשהשם קיים בטבלה וגם הסיסמה השמורה שווה לסיסמה שנשלחה. אם הסיסמה שגויה – או שהשם לא קיים (הפניה ל־Page1.aspx), או שמגיעים ל־else האחרון, שבו אין הפניה כלל.

תשובה: ההיגד נכון.

בדיקה: Direct על טבלה עם המשתמשים dana/1234 ו־yossi/abcd:

נימוק: ההפניה ל־Page1.aspx מתבצעת רק בתנאי ds.Tables[0].Rows.Count == 0, כלומר כשאין בטבלה משתמש עם ה־id שהוקלד. אם ה־id נכון, השאילתה מחזירה שורה אחת, ולכן התנאי לא מתקיים. כשהסיסמה שגויה גם התנאי השני לא מתקיים, ומבוצע ה־else האחרון: Session["Key"] = 1; – בלי שום הפניה. המשתמש נשאר בדף הכניסה.

תשובה: ההיגד לא נכון.

בדיקה: dana עם סיסמה 9999 – אין הפניה ו־Key = 1.

נימוק: כאשר ה־id קיים בטבלה והסיסמה שגויה, שני התנאים הראשונים אינם מתקיימים, ומבוצעת השורה Session["Key"] = 1;. כלומר דווקא במקרה של סיסמה שגויה (למשתמש קיים) Key מקבל את הערך 1. (רק אם גם ה־id אינו קיים, Key מקבל 0 – אבל אז הבעיה היא שם המשתמש, לא רק הסיסמה.)

תשובה: ההיגד לא נכון.

בדיקה: dana עם סיסמה 9999 – Key = 1.

נימוק: "כניסה ישירה" היא הקלדת הכתובת Page2.aspx בדפדפן בלי לעבור דרך טופס הכניסה. הערך 2 נשמר ב־Session["Key"] של המשתמש רק אחרי שם משתמש וסיסמה נכונים, וה־Session נשמר בשרת לכל משתמש בנפרד – המשתמש אינו יכול לשנות אותו. לכן אם בדף Page2.aspx בודקים את הערך בטעינת הדף, אפשר לחסום מי שלא עבר כניסה:

protected void Page_Load(object sender, EventArgs e)
{
    if (Session["Key"] == null || (int)Session["Key"] != 2)
        Response.Redirect("Login.aspx");
}

(Login.aspx – שם הדף שבו נמצא טופס הכניסה; השם לא ניתן בשאלה.)

תשובה: ההיגד נכון.

בדיקה: כניסה ל־Page2 בלי Key ← הפניה ל־Login.aspx; עם Key = 1 ← הפניה ל־Login.aspx; עם Key = 2 ← הדף מוצג.

טעות נפוצה: לחשוב שהמשתנה עצמו "חוסם" – Session רק שומר מידע. החסימה נעשית על ידי קוד הבדיקה בדף Page2.aspx.

מה נדרש: להציג לכל משתמש הודעה עם המספר הסידורי שלו – המשתמש הראשון שנכנס לאתר הוא 1, השני 2 וכן הלאה.

ניתוח הקוד הנתון: Application["myCount"] משותף לכל המשתמשים וסופר כמה משתמשים נכנסו. Session["firstlog"] מבטיח שכל משתמש ייספר פעם אחת בלבד (גם אם ירענן את הדף). אבל הפונקציה אינה כותבת דבר ל־Response, ולכן ההודעה אינה מוצגת.

רעיון:

פתרון בסיסי (זה מה שהשאלה דורשת בעיקר – להוסיף כתיבה ל־Response עם הערך של המונה, מיד אחרי ההגדלה ועוד לפני UnLock):

protected void Page_Load(object sender, EventArgs e)
{
         if (Session["firstlog"] == null)
         {
              Application.Lock();
              if (Application["myCount"] == null)
                  Application["myCount"] = 0;
              Application["myCount"] = (int)Application["myCount"]+ 1;
              Response.Write("ברוך הבא. הינך המשתמש ה־" + Application["myCount"] + ".");
              Application.UnLock();
              Session["firstlog"] = "true";
         }
}

כך כל משתמש חדש רואה בכניסתו הראשונה את המספר שלו. עם ארבעה ביקורים (משתמש 1, 2, שוב 1, 3) מתקבלות ההודעות "המשתמש ה־1", "המשתמש ה־2", (אין הודעה – משתמש 1 כבר נספר), "המשתמש ה־3". החיסרון: ברענון הדף ההודעה כבר לא מוצגת.

פתרון מלא יותר – שומרים את המספר ב־Session ומציגים בכל טעינה:

protected void Page_Load(object sender, EventArgs e)
{
         if (Session["firstlog"] == null)
         {
              Application.Lock();
              if (Application["myCount"] == null)
                  Application["myCount"] = 0;
              Application["myCount"] = (int)Application["myCount"]+ 1;
              Session["userNum"] = (int)Application["myCount"];
              Application.UnLock();
              Session["firstlog"] = "true";
         }
         Response.Write("ברוך הבא. הינך המשתמש ה־" + Session["userNum"] + ".");
}

בדיקה: הדמינו שלושה משתמשים בסדר הביקורים: 1, 2, 1, 3, 2, 1 (כל אחד עם Session משלו ו־Application משותף). ההודעות שהתקבלו: המשתמש ה־1, ה־2, ה־1, ה־3, ה־2, ה־1 – כל משתמש רואה תמיד את המספר שלו, ו־myCount = 3 בסוף.

טעות נפוצה: לכתוב Response.Write(... + Application["myCount"]) מחוץ ל־if – אז משתמש שחוזר לדף יראה את מספר המשתמשים הכולל ולא את המספר שלו. וגם לקרוא את המונה אחרי UnLock – משתמש אחר עלול להגדיל אותו בינתיים.