Designing systems with mental modelsتصميم الأنظمة بالنماذج الذهنية

Before you wire anything for a lamp you want to control from a browser, you already carry a picture in your head: the browser talks to something, and that something talks to the lamp. That picture is a mental model, and the first claim of this part is that good design starts there, not with code and not with hardware.

قبل أن توصّل أي سلك لمصباح تريد التحكم فيه من المتصفح، تحمل في ذهنك صورة جاهزة: المتصفح يتحدث مع شيء ما، وذلك الشيء يتحدث مع المصباح. هذه الصورة هي mental model (نموذج ذهني)، والادعاء الأول في هذا الجزء أن التصميم الجيد يبدأ من هنا، لا من الكود ولا من العتاد.

The claim is really about order. You do not jump from the problem straight to a solution; you first build a simplified representation of how the system works, and then derive the solution from it. The tool for building that representation is system thinking: describe the problem as parts, the connections between them, and the levels they sit on. A system seen this way is made of components, each one box with a job, and layers, each one a grouping of things that sit at the same level of abstraction.

الادعاء في حقيقته يتعلق بالترتيب. لا تقفز من المشكلة مباشرة إلى الحل، بل تبني أولًا تمثيلًا مبسطًا لطريقة عمل النظام، ثم تستنتج الحل منه. أداة بناء هذا التمثيل هي system thinking (التفكير النظمي): أن تصف المشكلة على شكل أجزاء، والروابط بينها، والمستويات التي تقع عليها. وsystem (النظام) بهذه النظرة يتكون من components (مكونات)، كل منها صندوق له وظيفة، ومن layers (طبقات)، كل منها تجميع لأشياء تقع على المستوى نفسه من التجريد.

The problem: a lamp, a browser, and a mysterious arrowالمشكلة: مصباح ومتصفح وسهم غامض

Now make it concrete. Draw Chrome on one side, a light bulb on the other, and one double-headed arrow between them. The browser is the client you already know. The lamp is the device. The arrow is where everything interesting hides. A browser tab cannot switch mains power; it can only send and receive messages over a network. So something must sit between the tab and the bulb, receive those messages, and turn them into electricity flowing or not flowing. The rest of this part is an answer to one question: what is inside that arrow?

لنجعل الأمر ملموسًا. ارسم Chrome في جهة، ومصباحًا في الجهة الأخرى، وسهمًا واحدًا مزدوج الاتجاه بينهما. المتصفح هو client (العميل) الذي تعرفه. والمصباح هو device (الجهاز). والسهم هو المكان الذي يختبئ فيه كل ما هو مثير. تبويب المتصفح لا يستطيع أن يفتح أو يقطع كهرباء الشبكة العامة، بل يستطيع فقط أن يرسل الرسائل ويستقبلها عبر شبكة. إذن لا بد من شيء يقع بين التبويب والمصباح، يستقبل تلك الرسائل ويحولها إلى كهرباء تسري أو لا تسري. باقي هذا الجزء هو إجابة عن سؤال واحد: ماذا يوجد داخل ذلك السهم؟

The tempting answer: ad hocالإجابة المغرية: الارتجال ad hoc

The first answer most people give is a part: "use a sensor", "buy a smart plug", "write a script". That is ad-hoc design, a component chosen before anyone has asked what the system actually is. The phrase comes from Latin ad (to) and hoc (this): for this specific purpose, a sense recorded in English from 1879. An ad-hoc design answers the immediate situation without previous planning.

أول إجابة يعطيها معظم الناس هي قطعة: "استخدم حساسًا"، "اشترِ مقبسًا ذكيًا"، "اكتب سكربتًا". هذا هو ad-hoc design (التصميم المرتجل)، أي مكوّن يُختار قبل أن يسأل أحد ما هو النظام فعلًا. أصل العبارة لاتيني: ad (إلى، لـ) وhoc (هذا)، أي لهذا الغرض المحدد، وهو معنى مسجل في الإنجليزية منذ 1879. التصميم المرتجل يجيب عن الموقف العاجل دون تخطيط مسبق.

For one lamp in one room, that can work. Now scale it: 50 lamps, a phone app next to the browser, a monthly energy report. With no named components and no agreed interfaces, each addition is another one-off wire or script, and nothing fits together. Ad-hoc designs may work for small isolated tasks, but they fail to scale or to integrate with larger systems.

لمصباح واحد في غرفة واحدة، قد ينجح ذلك. والآن وسّع الأمر: 50 مصباحًا، وتطبيق جوال بجانب المتصفح، وتقرير شهري عن الطاقة. من دون مكونات مسماة ومن دون واجهات متفق عليها، تصبح كل إضافة سلكًا أو سكربتًا آخر لمرة واحدة، ولا يتلاءم شيء مع شيء. قد تنجح التصاميم المرتجلة في المهام الصغيرة المعزولة، لكنها تفشل في التوسع أو في التكامل مع أنظمة أكبر.

The better answer: structured designالإجابة الأفضل: التصميم المنظم

Structured design takes the same lamp but fixes the order of work: questions first, components second, code last. Design becomes a process, not a random walk. Notice what comes out of that process. It is not a sensor, a script or a board: it is a system, a named set of parts with defined connections. Named parts are what let a phone app or a second lamp plug in later without rework, and that is why structured design holds up under complexity, scalability and integration.

Structured design (التصميم المنظم) يأخذ المصباح نفسه لكنه يثبّت ترتيب العمل: الأسئلة أولًا، ثم المكونات، والكود أخيرًا. يصبح التصميم عملية، لا مشيًا عشوائيًا. لاحظ ما الذي يخرج من هذه العملية: ليس حساسًا ولا سكربتًا ولا لوحة، بل نظامًا، أي مجموعة مسماة من الأجزاء بروابط محددة. الأجزاء المسماة هي ما يسمح لتطبيق جوال أو مصباح ثانٍ بأن يُوصل لاحقًا دون إعادة عمل، ولهذا يصمد التصميم المنظم أمام التعقيد والتوسع والتكامل.

The structured process in this lecture is not mysterious. It is four questions, asked in a fixed order, and their highlighted words are the whole vocabulary of system thinking.

العملية المنظمة في هذه المحاضرة ليست غامضة. إنها أربعة أسئلة تُطرح بترتيب ثابت، والكلمات المميزة فيها هي كل مفردات التفكير النظمي.

The order is forced by dependency. You cannot name relationships before you have components to relate, and you cannot group things into layers before you know what the things are. Treat the list as a reusable checklist: your research project architecture section must answer exactly these questions, and so must any exam answer that asks you to design or critique a system. This concept answers the first two for the lamp; the rest of the part answers the other two.

الترتيب تفرضه الاعتمادية. لا يمكنك تسمية العلاقات قبل أن تكون لديك مكونات تربط بينها، ولا يمكنك تجميع الأشياء في طبقات قبل أن تعرف ما هي هذه الأشياء. تعامل مع القائمة كقائمة تحقق قابلة لإعادة الاستخدام: قسم المعمارية في مشروعك البحثي يجب أن يجيب عن هذه الأسئلة بالضبط، وكذلك أي إجابة في الاختبار تطلب منك تصميم نظام أو نقده. هذا المفهوم يجيب عن السؤالين الأولين للمصباح، وباقي الجزء يجيب عن السؤالين الآخرين.

Question one: what is a system?السؤال الأول: ما هو النظام؟

For the lamp, the boundary is the room plus the network, the parts are the browser and the lamp, and the things that happen between them are "switch on" and "how much energy have you used?". Generalize that and you get the definition: a system is an environment in which interactions occur between components. Three ingredients, each one necessary. The environment draws the boundary. The components are the boxes inside it. Each interaction is an arrow.

في حالة المصباح، الحد هو الغرفة مع الشبكة، والأجزاء هي المتصفح والمصباح، وما يحدث بينهما هو "شغّل المصباح" و"كم استهلكت من الطاقة؟". عمّم ذلك تحصل على التعريف: النظام بيئة تحدث فيها تفاعلات بين المكونات. ثلاثة عناصر، كل منها ضروري. البيئة ترسم الحد. والمكونات هي الصناديق داخله. وكل interaction (تفاعل) هو سهم.

Question two: what are the components?السؤال الثاني: ما هي المكونات؟

The lamp is decomposed in two refinement steps, and each step adds one idea. First, separate software from thing: browser and bulb become Application and Device, where the application is everything that is software and the device is the physical lamp. Second, split the application in two. The client is the user-facing interface, the part you touch. The server processes client requests and communicates with the device. That second component is the answer to the mystery of the arrow: it is the thing that sits between the tab and the bulb.

يُفكَّك المصباح في خطوتي تنقيح، وكل خطوة تضيف فكرة واحدة. أولًا، افصل البرمجيات عن الشيء المادي: يصبح المتصفح والمصباح تطبيقًا (Application) وجهازًا (Device)، حيث التطبيق هو كل ما هو برمجي، والجهاز هو المصباح المادي. ثانيًا، قسّم التطبيق إلى قسمين. العميل هو الواجهة المواجهة للمستخدم، أي الجزء الذي تلمسه. وserver (الخادم) يعالج طلبات العميل ويتواصل مع الجهاز. هذا المكون الثاني هو حل لغز السهم: إنه الشيء الذي يقع بين التبويب والمصباح.

Read the visual left to right: the click starts at the client, the server relays it, and only when the path reaches the device does the lamp glow. No box can be skipped.

اقرأ الشكل من اليسار إلى اليمين: تبدأ النقرة عند العميل، ويمررها الخادم، ولا يتوهج المصباح إلا حين يصل المسار إلى الجهاز. لا يمكن تخطي أي صندوق.

Why split the application: offloadingلماذا نقسم التطبيق: نقل المعالجة offloading

Why not let the browser do everything? Because a browser tab is a poor place to keep things. It is not running while the tab is closed, so it cannot record energy readings around the clock, and a phone and a laptop would each hold their own copy of the lamp state. The server is always on and shared, so it can do both.

لماذا لا ندع المتصفح يفعل كل شيء؟ لأن تبويب المتصفح مكان سيئ لحفظ الأشياء. فهو لا يعمل حين يكون التبويب مغلقًا، لذلك لا يستطيع تسجيل قراءات الطاقة على مدار الساعة، كما أن الجوال والحاسوب المحمول سيحتفظ كل منهما بنسخته الخاصة من حالة المصباح. أما الخادم فهو يعمل دائمًا ومشترك، لذلك يستطيع القيام بالأمرين.

That is offloading: the client hands functions it cannot or should not perform to the server, because the server has the processing and storage. The server hosts those functions as services, such as "set the lamp state" and "read energy use", and the client simply calls them. Deciding what to offload, and to where, is exactly what the task mapping later in the lecture varies: a task can run on the device, at the edge, in the fog or in the cloud.

هذا هو offloading (نقل المعالجة): يسلّم العميل الوظائف التي لا يستطيع أو لا ينبغي أن يؤديها إلى الخادم، لأن الخادم يملك المعالجة والتخزين. يستضيف الخادم تلك الوظائف كخدمات، مثل "اضبط حالة المصباح" و"اقرأ استهلاك الطاقة"، والعميل يستدعيها فقط. وتحديد ما الذي يُنقل وإلى أين هو بالضبط ما يتغير في توزيع المهام (task mapping) لاحقًا في المحاضرة: يمكن أن تعمل المهمة على الجهاز، أو عند الحافة، أو في الضباب، أو في السحابة.

Question three asks what connects the components. Start concrete: between client and server the lamp needs at least two exchanges, "set the state" and "read the energy".

السؤال الثالث يسأل عما يربط المكونات. ابدأ بشيء ملموس: بين العميل والخادم يحتاج المصباح إلى تبادلين على الأقل، "اضبط الحالة" و"اقرأ الطاقة".

Each exchange is one interaction, and the relationship is the whole set of them. In set notation, an interaction d is an element of a relationship R. That framing is useful because it tells you how to specify a relationship: list its interactions, and then say what every one of them has in common.

كل تبادل هو تفاعل واحد، والعلاقة هي مجموعتها كلها. بلغة المجموعات، التفاعل d عنصر في العلاقة R. هذه الصياغة مفيدة لأنها تخبرك كيف تحدد علاقة: اذكر تفاعلاتها، ثم قل ما المشترك بينها جميعًا.

What they have in common splits into two halves. The protocol is the grammar both sides agree on: message format, order and meaning. For the Web that is HTTP, with its message format, methods, headers and status codes. The interface is the list of operations the server offers: the endpoints, each a method plus a path, that a client may call. Neither half is enough on its own. A shared language with nothing to ask for is useless, and a menu of operations nobody can phrase is equally useless.

ما تشترك فيه ينقسم إلى نصفين. protocol (البروتوكول) هو القواعد اللغوية التي يتفق عليها الطرفان: صيغة الرسالة وترتيبها ومعناها. في الويب هذا هو HTTP، بصيغة رسائله وطرقه (methods) وترويساته (headers) ورموز حالته (status codes). وinterface (الواجهة) هي قائمة العمليات التي يقدمها الخادم: نقاط النهاية (endpoints)، كل منها طريقة مع مسار، التي يحق للعميل استدعاؤها. ولا يكفي أي نصف وحده. لغة مشتركة بلا شيء تطلبه عديمة الفائدة، وقائمة عمليات لا يستطيع أحد صياغة طلبها عديمة الفائدة بالقدر نفسه.

The relationship we deliberately ignoreالعلاقة التي نتجاهلها عن قصد

There is a second arrow in the lamp system, between server and device, and the lecture is blunt about it: it is not our concern. That is a design decision, not laziness. You may assume the server runs on a microcontroller board wired to the lamp. Inside that board, the program calls a hardware library; the library switches a pin; the pin drives a relay; the relay switches the lamp. That chain is a separate, lower-level relationship with its own protocol and its own interface.

يوجد سهم ثانٍ في نظام المصباح، بين الخادم والجهاز، والمحاضرة صريحة بشأنه: إنه ليس من شأننا. وهذا قرار تصميمي، لا كسل. يمكنك أن تفترض أن الخادم يعمل على لوحة متحكم دقيق (microcontroller) موصولة بالمصباح. داخل تلك اللوحة، يستدعي البرنامج مكتبة عتاد، والمكتبة تبدّل طرفًا (pin)، والطرف يشغّل مرحّلًا (relay)، والمرحّل يشغّل المصباح أو يطفئه. هذه السلسلة علاقة منفصلة ذات مستوى أدنى، لها بروتوكولها الخاص وواجهتها الخاصة.

The web client never sees any of it. It sees only the interface the server exposes. This is the payoff of defining a relationship by protocol and interface: each side can ignore the other side's internals, which is abstraction doing its job. Swap the relay for a smart bulb and the client does not change at all.

عميل الويب لا يرى شيئًا من ذلك. إنه يرى فقط الواجهة التي يعرضها الخادم. وهذه هي فائدة تعريف العلاقة بالبروتوكول والواجهة: كل طرف يستطيع تجاهل التفاصيل الداخلية للطرف الآخر، وهذا هو التجريد يؤدي عمله. استبدل المرحّل بمصباح ذكي ولن يتغير العميل إطلاقًا.

A relationship is a set of interactions, so the next step in specifying the lamp is to write that set down. It has two members, and each is a pair: a request from the client and a reply from the server. The client always speaks first.

العلاقة مجموعة من التفاعلات، لذا فالخطوة التالية في تحديد المصباح هي كتابة تلك المجموعة. لها عنصران، وكل منهما زوج: طلب من العميل ورد من الخادم. العميل يتكلم أولًا دائمًا.

In the visual, each interaction is a request drawn toward the server followed by a reply drawn back to the client, and the meter inside the server fills once the kilowatt-hour reply lands. The device sits behind the server, never talking to the client directly, exactly as the previous concept required.

في الشكل، كل تفاعل هو طلب مرسوم باتجاه الخادم يتبعه رد مرسوم عائدًا إلى العميل، ويمتلئ العداد داخل الخادم حين يصل الرد بالكيلوواط ساعة. الجهاز يقع خلف الخادم، ولا يتحدث مع العميل مباشرة أبدًا، تمامًا كما اشترط المفهوم السابق.

One design detail matters more than it looks. Set_on_off should carry the value you want (on, or off), not mean "toggle". If the network drops the reply and the client sends the request again, a toggle flips the lamp back, while "set on" twice still leaves it on. Hold on to that thought: the next concept gives the property a name and shows that HTTP builds it into its methods.

تفصيل تصميمي واحد أهم مما يبدو. ينبغي أن يحمل Set_on_off القيمة التي تريدها (تشغيل أو إطفاء)، لا أن يعني "اقلب الحالة" (toggle). إذا أسقطت الشبكة الرد وأرسل العميل الطلب مرة أخرى، فإن القلب يعيد المصباح إلى حالته السابقة، بينما "شغّل" مرتين يُبقيه مشتغلًا. احتفظ بهذه الفكرة: المفهوم التالي يعطي هذه الخاصية اسمًا ويبين أن HTTP يبنيها في طرقه.

What the energy reply actually meansماذا يعني رد الطاقة فعلًا

The read interaction returns energy, and that is where many students slip. A watt measures power, which is a rate: how fast energy is being used. A watt-hour measures energy: power kept up for a length of time. A kilowatt-hour is 1 kW (1,000 W) used for one hour, and the usual appliance formula is wattage times hours, divided by 1000.

تفاعل القراءة يعيد طاقة، وهنا يخطئ كثير من الطلاب. الواط يقيس القدرة، وهي معدل: مدى سرعة استهلاك الطاقة. والواط ساعة يقيس الطاقة: قدرة مستمرة لمدة من الزمن. والكيلوواط ساعة هو 1 kW (1,000 W) مستهلكة لمدة ساعة واحدة، والمعادلة المعتادة للأجهزة هي القدرة بالواط مضروبة في عدد الساعات، مقسومة على 1000.

So far the interactions are abstract. On the Web they become concrete: set becomes HTTP PUT, and read becomes HTTP GET. The arrows carrying them are the protocol, HTTP, and the set and read operations exposed on the server edge are the interface, a Web API. The formula from earlier now has a real instance.

حتى الآن التفاعلات مجردة. على الويب تصبح ملموسة: الضبط يصبح HTTP PUT، والقراءة تصبح HTTP GET. الأسهم التي تحملها هي البروتوكول، HTTP، وعمليتا الضبط والقراءة المعروضتان على حافة الخادم هما الواجهة، أي Web API. المعادلة السابقة صار لها الآن مثال حقيقي.

In the visual, the PUT and GET lines are the protocol, and the two sockets they seat into, set and read, are the interface. Only when both halves meet does the relationship work.

في الشكل، خطا PUT وGET هما البروتوكول، والمقبسان اللذان يستقران فيهما، الضبط والقراءة، هما الواجهة. لا تعمل العلاقة إلا حين يلتقي النصفان.

The actual messagesالرسائل الفعلية

Here is what the two interactions could look like on the wire. Host and paths are illustrative.

هكذا يمكن أن يبدو التفاعلان على السلك. المضيف (Host) والمسارات للتوضيح فقط.

The 204 No Content reply is the HTTP form of the abstract ok: RFC 9110 defines it as the server having fulfilled the request with no additional content to send.

الرد 204 No Content هو صيغة HTTP للـ ok المجرد: يعرّفه RFC 9110 بأن الخادم نفّذ الطلب ولا يوجد محتوى إضافي ليرسله.

Why GET fits read: safeلماذا يناسب GET القراءة: آمن safe

RFC 9110 calls a method safe when its semantics are essentially read-only: the client does not request, and does not expect, any state change on the server. Reading energy changes nothing, so GET is the natural fit. RFC 9205 adds a practical reason: implementations can and do retry GET requests that fail, so GET handling should not change application state.

يسمي RFC 9110 الطريقة آمنة (safe) حين تكون دلالتها للقراءة فقط في جوهرها: العميل لا يطلب، ولا يتوقع، أي تغيير في حالة الخادم. قراءة الطاقة لا تغير شيئًا، لذا فإن GET هو الخيار الطبيعي. ويضيف RFC 9205 سببًا عمليًا: التطبيقات تستطيع أن تعيد، وهي تعيد فعلًا، طلبات GET التي تفشل، لذا لا ينبغي أن تغير معالجة GET حالة التطبيق.

Why PUT fits set: idempotentلماذا يناسب PUT الضبط: متساوي الأثر idempotent

Recall the toggle problem from the interaction list. HTTP has a name for the property that solves it. A method is idempotent when the intended effect of several identical requests is the same as the effect of one. PUT, DELETE and the safe methods are idempotent. PUT asks for the target resource to be created or replaced with the state enclosed in the request, so sending {"on": true} twice still leaves the lamp on.

تذكّر مشكلة القلب (toggle) من قائمة التفاعلات. لدى HTTP اسم للخاصية التي تحلها. تكون الطريقة متساوية الأثر (idempotent) حين يكون الأثر المقصود لعدة طلبات متطابقة هو نفس أثر طلب واحد. PUT وDELETE والطرق الآمنة كلها متساوية الأثر. يطلب PUT أن يُنشأ المورد المستهدف أو يُستبدل بالحالة المرفقة في الطلب، لذا فإن إرسال {"on": true} مرتين يُبقي المصباح مشتغلًا.

This matters on real links. RFC 9110 says an idempotent request can be repeated automatically if the connection fails before the client reads the response, while a client should not automatically retry a non-idempotent request unless it knows the request is actually idempotent, or that the original request was never applied. Edge devices often sit on flaky wireless links, so this choice decides whether a retry is harmless or a bug.

هذا مهم على الروابط الحقيقية. يقول RFC 9110 إن الطلب متساوي الأثر يمكن تكراره تلقائيًا إذا فشل الاتصال قبل أن يقرأ العميل الرد، بينما لا ينبغي للعميل أن يعيد تلقائيًا طلبًا غير متساوي الأثر إلا إذا كان يعلم أن الطلب متساوي الأثر فعلًا، أو أن الطلب الأصلي لم يُطبَّق أبدًا. أجهزة الحافة كثيرًا ما تكون على روابط لاسلكية غير مستقرة، لذا فهذا الاختيار يحدد ما إذا كانت إعادة المحاولة غير ضارة أم خطأً برمجيًا.

Question four asks for the layers. For this system the answer is a single layer, the one where processing and storage happen: the server layer. Answering it forces you to notice that the word "server" has been doing two jobs.

السؤال الرابع يطلب الطبقات. في هذا النظام الإجابة طبقة واحدة، هي التي تحدث فيها المعالجة والتخزين: server layer (طبقة الخادم). والإجابة عنه تجبرك على ملاحظة أن كلمة "خادم" (server) كانت تؤدي وظيفتين.

The server component is the program, for example the Python or C code that answers requests for the lamp state. The server layer is that program together with everything it needs to run: the processor executing it, the network carrying requests, the memory holding the current state, and the disk keeping energy history. The component is what you write; the layer is what you must provision.

مكون الخادم هو البرنامج، مثلًا كود Python أو C الذي يجيب عن طلبات حالة المصباح. وطبقة الخادم هي ذلك البرنامج مع كل ما يحتاجه ليعمل: المعالج الذي ينفذه، والشبكة التي تحمل الطلبات، والذاكرة التي تحفظ الحالة الحالية، والقرص الذي يحتفظ بسجل الطاقة. المكون هو ما تكتبه، والطبقة هي ما يجب أن توفّره.

The visual starts with just the program lit, which is the component. The resources rise beneath it and the outline closes around all five: that outline is the layer.

يبدأ الشكل والبرنامج وحده مضاء، وهو المكون. ثم ترتفع الموارد تحته ويُغلق الإطار حول العناصر الخمسة كلها: ذلك الإطار هو الطبقة.

The modern names for the server layerالأسماء الحديثة لطبقة الخادم

Now the question the whole course answers: what do we call this layer today? Cloud, fog or edge, depending on where it is placed. Close the lamp story with that in mind. If the program runs on a board next to the lamp, the layer sits on the device side of the continuum (mist, or edge on a nearby gateway). If it runs in a distant data center, it is the cloud.

والآن السؤال الذي يجيب عنه المقرر كله: ماذا نسمي هذه الطبقة اليوم؟ Cloud (سحابة) أو fog (ضباب) أو edge (حافة)، بحسب المكان الذي توضع فيه. اختم قصة المصباح بهذه الفكرة. إذا كان البرنامج يعمل على لوحة بجانب المصباح، فالطبقة تقع في جهة الجهاز من الامتداد (mist، أو الحافة إن كانت على بوابة قريبة gateway). وإذا كان يعمل في مركز بيانات بعيد، فهي السحابة.

The standard definitions line up with the layer you just built. NIST defines cloud computing as on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications and services, that can be rapidly provisioned and released: the same resources as the server layer, pooled at scale. NIST also describes fog computing as a layered model for access to a shared continuum of scalable computing resources, built from fog nodes that sit between smart end devices and centralized cloud services. Cloud, fog and edge together form the edge-to-cloud (E2C) continuum that the rest of the lecture studies.

التعريفات المعيارية تتطابق مع الطبقة التي بنيتها للتو. يعرّف NIST الحوسبة السحابية بأنها وصول عبر الشبكة عند الطلب إلى مجمّع مشترك من موارد الحوسبة القابلة للتهيئة، مثل الشبكات والخوادم والتخزين والتطبيقات والخدمات، يمكن توفيرها وتحريرها بسرعة: أي الموارد نفسها التي في طبقة الخادم، مجمّعة على نطاق واسع. ويصف NIST أيضًا حوسبة الضباب بأنها نموذج طبقي للوصول إلى امتداد مشترك من موارد الحوسبة القابلة للتوسع، مبني من عُقد ضباب (fog nodes) تقع بين الأجهزة الطرفية الذكية وخدمات السحابة المركزية. السحابة والضباب والحافة معًا تشكل edge-to-cloud (E2C) continuum (امتداد الحافة إلى السحابة) الذي يدرسه باقي المحاضرة.