آلة الحالة UML

تحافظ لغة النمذجة الموحدة (UML) على الشكل العام لمخططات الحالة التقليدية . مخططات حالة UML عبارة عن رسوم بيانية موجهة ، حيث تمثل العقد الحالات، وتمثل الموصلات انتقالات الحالة. على سبيل المثال، يوضح الشكل 1 مخطط حالة UML الخاص بآلة حالة لوحة مفاتيح الحاسوب. في UML، تُمثل الحالات بمستطيلات مستديرة تحمل أسماء الحالات. أما الانتقالات، فتُمثل بأسهم، وتُسمى بأحداث التشغيل، متبوعةً اختياريًا بقائمة الإجراءات المنفذة. يبدأ الانتقال الأولي من الدائرة المصمتة، ويحدد الحالة الافتراضية عند بدء تشغيل النظام. يجب أن يحتوي كل مخطط حالة على هذا الانتقال، والذي لا يُسمى لأنه لا يُشغل بحدث. يمكن أن يرتبط الانتقال الأولي بإجراءات.

الحدث هو شيء يحدث ويؤثر على النظام. وبالتحديد، في مواصفات لغة النمذجة الموحدة (UML) ^{[ 1 ]} ، يشير مصطلح "الحدث" إلى نوع الواقعة وليس إلى أي حالة محددة منها. على سبيل المثال، "ضغطة مفتاح" هو حدث خاص بلوحة المفاتيح، ولكن كل ضغطة على مفتاح ليست حدثًا بحد ذاتها، بل هي حالة محددة من حدث "ضغطة مفتاح". ومن الأحداث الأخرى المهمة للوحة المفاتيح "تشغيل الطاقة"، ولكن تشغيل الطاقة غدًا في تمام الساعة 10:05:36 سيكون مجرد حالة من حدث "تشغيل الطاقة".

يمكن أن يتضمن الحدث معلمات مرتبطة به ، مما يسمح لمثيل الحدث بنقل ليس فقط وقوع حدث مهم، بل أيضًا معلومات كمية تتعلق بهذا الحدث. على سبيل المثال، يتضمن حدث ضغطة المفتاح الناتج عن الضغط على مفتاح في لوحة مفاتيح الكمبيوتر معلمات مرتبطة به تنقل رمز مسح الحرف بالإضافة إلى حالة مفاتيح Shift وCtrl وAlt.

يستمر وجود الحدث بعد وقوعه الفوري، وقد ينقل هذا الحدث إلى آلة حالة واحدة أو أكثر. بمجرد إنشائه، يمر الحدث بدورة معالجة قد تتكون من ثلاث مراحل. أولًا، يُستقبل الحدث ويُوضع في قائمة انتظار المعالجة (مثلًا، يُضاف إلى قائمة انتظار الأحداث ). ثانيًا، يُرسل الحدث إلى آلة الحالة، ليصبح الحدث الحالي. أخيرًا، يُستهلك الحدث عند انتهاء آلة الحالة من معالجته. يصبح الحدث المستهلك غير متاح للمعالجة.

لكل آلة حالة حالةٌ تُحدد استجابتها للأحداث. على سبيل المثال، عند الضغط على مفتاح في لوحة المفاتيح، يكون رمز الحرف الناتج إما حرفًا كبيرًا أو صغيرًا، وذلك بحسب ما إذا كان مفتاح Caps Lock مُفعّلًا أم لا. لذا، يُمكن تقسيم سلوك لوحة المفاتيح إلى حالتين: الحالة "الافتراضية" وحالة "caps Lock". (تحتوي معظم لوحات المفاتيح على مؤشر LED يُشير إلى حالة "caps Lock"). يعتمد سلوك لوحة المفاتيح فقط على جوانب مُحددة من تاريخها، وتحديدًا ما إذا كان مفتاح Caps Lock قد تم الضغط عليه، وليس على عوامل أخرى، مثل عدد المفاتيح الأخرى التي تم الضغط عليها سابقًا أو نوعها. يُمكن للحالة أن تُجرّد جميع تسلسلات الأحداث المُحتملة (وغير ذات الصلة) وتُركز فقط على التسلسلات ذات الصلة.

في سياق آلات الحالة البرمجية (وخاصةً آلات الحالة المحدودة التقليدية)، يُفهم مصطلح "الحالة" غالبًا على أنه متغير حالة واحد لا يمكنه أن يأخذ إلا عددًا محدودًا من القيم المحددة مسبقًا (مثل قيمتين في حالة لوحة المفاتيح، أو بشكل أعم - نوع من المتغيرات من نوع تعداد في العديد من لغات البرمجة). تكمن فكرة متغير الحالة (ونموذج آلة الحالة المحدودة التقليدي) في أن قيمة متغير الحالة تُحدد بشكل كامل الحالة الحالية للنظام في أي وقت. يُبسط مفهوم الحالة مشكلة تحديد سياق التنفيذ في الكود إلى اختبار متغير الحالة فقط بدلًا من العديد من المتغيرات، مما يُلغي الكثير من المنطق الشرطي.

عمليًا، يصبح تفسير حالة آلة الحالة بأكملها كمتغير حالة واحد غير عملي لجميع آلات الحالة باستثناء البسيطة منها. فحتى لو كان لدينا عدد صحيح واحد من 32 بت في حالة الآلة، فإنه قد يُساهم في أكثر من 4 مليارات حالة مختلفة، مما يؤدي إلى تضخم مُبكر في عدد الحالات . هذا التفسير غير عملي، لذا في آلات الحالة في لغة النمذجة الموحدة (UML)، تُقسّم حالة الآلة عادةً إلى (أ) متغير حالة قابل للتعداد، و(ب) جميع المتغيرات الأخرى التي تُسمى الحالة الموسعة . ويمكن النظر إلى الأمر من زاوية أخرى، وهي تفسير متغير الحالة القابل للتعداد كجانب نوعي، والحالة الموسعة كجوانب كمية للحالة الكلية. في هذا التفسير، لا يعني تغيير المتغير بالضرورة تغييرًا في الجوانب النوعية لسلوك النظام، وبالتالي لا يؤدي إلى تغيير في الحالة. ^{[ 7 ]}

تُسمى آلات الحالة المُدعمة بمتغيرات حالة موسعة بآلات الحالة الموسعة ، وتنتمي آلات حالة UML إلى هذه الفئة. تُمكّن آلات الحالة الموسعة من تطبيق الصيغة الأساسية على مشاكل أكثر تعقيدًا بكثير مما هو عملي بدون تضمين متغيرات الحالة الموسعة. على سبيل المثال، إذا أردنا تطبيق نوع من القيود في آلة الحالة المحدودة (كأن نحدد عدد ضغطات المفاتيح على لوحة المفاتيح بـ 1000)، فبدون متغيرات الحالة الموسعة ، سنحتاج إلى إنشاء ومعالجة 1000 حالة، وهو أمر غير عملي. أما باستخدام آلة الحالة الموسعة، فيمكننا إدخال key_countمتغير يتم تهيئته إلى 1000 ويتم إنقاصه مع كل ضغطة مفتاح دون تغيير متغير الحالة .

يُعد مخطط الحالة من الشكل 2 مثالاً على آلة الحالة الموسعة، حيث تكون الحالة الكاملة للنظام (المسماة الحالة الموسعة ) عبارة عن مزيج من جانب نوعي - متغير الحالة - والجوانب الكمية - متغيرات الحالة الموسعة .

تتمثل الميزة الواضحة لآلات الحالة الموسعة في مرونتها. فعلى سبيل المثال، key_countلن يؤدي تغيير الحد الأقصى لعدد ضغطات المفاتيح من 1000 إلى 10000 ضغطة إلى تعقيد آلة الحالة الموسعة على الإطلاق. التعديل الوحيد المطلوب هو تغيير قيمة التهيئة لمتغير key_countالحالة الموسع أثناء عملية التهيئة.

تأتي هذه المرونة التي تتمتع بها آلات الحالة الموسعة بثمن، وذلك بسبب الترابط المعقد بين الجوانب "النوعية" و"الكمية" للحالة الموسعة. ويحدث هذا الترابط من خلال شروط الحماية المرتبطة بالانتقالات، كما هو موضح في الشكل 2.

شروط الحماية (أو ببساطة الحواجز) هي تعبيرات منطقية تُقيّم ديناميكيًا بناءً على قيمة متغيرات الحالة الموسعة ومعاملات الأحداث . تؤثر شروط الحماية على سلوك آلة الحالة من خلال تمكين الإجراءات أو الانتقالات فقط عندما تكون قيمتها صحيحة (TRUE)، وتعطيلها عندما تكون قيمتها خاطئة (FALSE). في تدوين UML، تُعرض شروط الحماية بين قوسين مربعين (كما [key_count == 0]في الشكل 2 على سبيل المثال).

إن الحاجة إلى الحواجز هي النتيجة المباشرة لإضافة متغيرات الحالة الموسعة للذاكرة إلى نموذج آلة الحالة. عند استخدامها باعتدال، تُشكل متغيرات الحالة الموسعة والحواجز آلية فعّالة تُبسط التصميمات. من ناحية أخرى، من السهل إساءة استخدام متغيرات الحالة الموسعة والحواجز. ^{[ 8 ]}

عند إرسال حدث ما ، تستجيب آلة الحالة بتنفيذ إجراءات ، مثل تغيير متغير، أو إجراء عمليات إدخال/إخراج، أو استدعاء دالة، أو إنشاء حدث آخر، أو الانتقال إلى حالة أخرى. وتكون جميع قيم المعلمات المرتبطة بالحدث الحالي متاحة لجميع الإجراءات الناتجة مباشرةً عن هذا الحدث.

يُطلق على الانتقال من حالة إلى أخرى اسم انتقال الحالة ، ويُسمى الحدث الذي يُسببه الحدث المُحفِّز، أو ببساطة المُحفِّز . في مثال لوحة المفاتيح، إذا كانت لوحة المفاتيح في الحالة "الافتراضية" عند الضغط على مفتاح CapsLock، فستدخل لوحة المفاتيح في حالة "caps_locked". أما إذا كانت لوحة المفاتيح بالفعل في حالة "caps_locked"، فإن الضغط على مفتاح CapsLock سيؤدي إلى انتقال مختلف، من حالة "caps_locked" إلى الحالة "الافتراضية". في كلتا الحالتين، يُعد الضغط على مفتاح CapsLock هو الحدث المُحفِّز.

في آلات الحالة الموسعة ، يمكن أن يتضمن الانتقال شرطًا ، ما يعني أن الانتقال لا يُفعّل إلا إذا كانت قيمة الشرط صحيحة. يمكن أن تتضمن الحالة عدة انتقالات استجابةً لنفس المحفز، طالما أن شروطها غير متداخلة؛ إلا أن هذا الوضع قد يُسبب مشاكل في تسلسل تقييم الشروط عند حدوث المحفز المشترك. لا تُحدد مواصفات لغة النمذجة الموحدة (UML) ^{[ 1 ]} ترتيبًا معينًا عمدًا؛ بل تُلقي UML عبء تصميم الشروط على عاتق المصمم بحيث لا يُؤثر ترتيب تقييمها. عمليًا، يعني هذا أن تعابير الشروط يجب ألا يكون لها أي آثار جانبية، أو على الأقل أي آثار تُغير تقييم الشروط الأخرى التي لها نفس المحفز.

تفترض جميع نماذج آلات الحالة، بما في ذلك آلات الحالة في لغة النمذجة الموحدة (UML)، أن آلة الحالة تُكمل معالجة كل حدث قبل أن تبدأ بمعالجة الحدث التالي. يُطلق على نموذج التنفيذ هذا اسم " التنفيذ حتى الإكمال " أو RTC.

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

مع ذلك، تجدر الإشارة إلى أن تقنية التحكم في الوقت الحقيقي (RTC) لا تعني بالضرورة أن آلة الحالة يجب أن تحتكر وحدة المعالجة المركزية حتى اكتمال خطوة التحكم في الوقت الحقيقي. ^{[ 1 ]} ينطبق قيد الاستباق فقط على سياق مهمة آلة الحالة المشغولة بالفعل بمعالجة الأحداث. في بيئة متعددة المهام ، يمكن أن تعمل مهام أخرى (غير مرتبطة بسياق مهمة آلة الحالة المشغولة)، مما قد يؤدي إلى مقاطعة آلة الحالة قيد التنفيذ حاليًا. طالما أن آلات الحالة الأخرى لا تتشارك المتغيرات أو الموارد الأخرى فيما بينها، فلا توجد مخاطر تزامن .

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

أهم ما يميز آلات الحالة في لغة النمذجة الموحدة (UML) عن آلات الحالة المحدودة التقليدية هو إدخال حالات متداخلة هرميًا (ولهذا السبب تُسمى مخططات الحالة أيضًا بآلات الحالة الهرمية ، أو HSM ). وتتلخص دلالات تداخل الحالات فيما يلي (انظر الشكل 3): إذا كان النظام في حالة متداخلة، مثل "النتيجة" (وتُسمى الحالة الفرعية )، فإنه يكون ضمنيًا في الحالة المحيطة "تشغيل" (وتُسمى الحالة العليا ). ستحاول آلة الحالة هذه معالجة أي حدث في سياق الحالة الفرعية، التي تُمثل المستوى الأدنى من التسلسل الهرمي. مع ذلك، إذا لم تُحدد الحالة الفرعية "النتيجة" كيفية معالجة الحدث، فلن يتم تجاهل الحدث تلقائيًا كما هو الحال في آلة الحالة "المسطحة" التقليدية؛ بل سيتم التعامل معه تلقائيًا في سياق المستوى الأعلى للحالة العليا "تشغيل". هذا هو المقصود بوجود النظام في الحالة "النتيجة" وكذلك "تشغيل". بالطبع، لا يقتصر تداخل الحالات على مستوى واحد فقط، والقاعدة البسيطة لمعالجة الأحداث تنطبق بشكل متكرر على أي مستوى من التداخل.

تُسمى الحالات التي تحتوي على حالات أخرى حالات مركبة ؛ وعلى العكس، تُسمى الحالات التي لا تحتوي على بنية داخلية حالات بسيطة . تُسمى الحالة المتداخلة حالة فرعية مباشرة عندما لا تحتويها أي حالة أخرى؛ وإلا، يُشار إليها باسم حالة فرعية متداخلة بشكل متعدٍ .

نظرًا لأن البنية الداخلية للحالة المركبة قد تكون معقدة للغاية، يمكن اعتبار أي آلة حالة هرمية بمثابة بنية داخلية لحالة مركبة (أعلى مستوى). ومن الملائم من الناحية المفاهيمية تعريف حالة مركبة واحدة على أنها الجذر النهائي لتسلسل آلة الحالة. في مواصفات لغة النمذجة الموحدة (UML)، تحتوي كل آلة حالة على منطقة (الجذر المجرد لكل تسلسل هرمي لآلة الحالة)، ^{[ 9 ]} والتي تضم جميع العناصر الأخرى لآلة الحالة بأكملها. ويُعدّ التمثيل الرسومي لهذه المنطقة الشاملة اختياريًا.

كما تلاحظ، صُممت دلالات تفكيك الحالة الهرمي لتسهيل إعادة استخدام السلوك. لا تحتاج الحالات الفرعية (الحالات المتداخلة) إلا إلى تحديد الاختلافات عن الحالات العليا (الحالات الحاوية). يمكن للحالة الفرعية أن ترث بسهولة ^{[ 6 ]} السلوك المشترك من حالتها العليا (أو حالاتها العليا) بمجرد تجاهل الأحداث المشتركة، والتي تتولى الحالات ذات المستوى الأعلى معالجتها تلقائيًا. بعبارة أخرى، يُمكّن تداخل الحالة الهرمي من البرمجة بالاختلاف . ^{[ 10 ]}

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

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

يمكن أن يشمل التحليل باستخدام تفكيك الحالة الهرمي تطبيق عملية "أو الحصرية" على أي حالة معينة. على سبيل المثال، إذا كان النظام في الحالة العليا "تشغيل" (الشكل 3)، فقد يكون أيضًا في الحالة الفرعية "المعامل 1" أو الحالة الفرعية "المعامل 2" أو الحالة الفرعية "تم إدخال العملية" أو الحالة الفرعية "النتيجة". وهذا من شأنه أن يؤدي إلى وصف الحالة العليا "تشغيل" بأنها حالة "أو".

تُقدّم مخططات حالة UML أيضًا التفكيك التكميلي AND. ويعني هذا التفكيك أن الحالة المركبة يمكن أن تحتوي على منطقتين متعامدتين أو أكثر (متعامدة تعني متوافقة ومستقلة في هذا السياق)، وأن التواجد في مثل هذه الحالة المركبة يستلزم التواجد في جميع مناطقها المتعامدة في آن واحد. ^{[ 11 ]}

تُعالج المناطق المتعامدة مشكلة الزيادة التوافقية المتكررة في عدد الحالات عندما ينقسم سلوك النظام إلى أجزاء مستقلة ونشطة في آنٍ واحد. على سبيل المثال، بالإضافة إلى لوحة المفاتيح الرئيسية، تحتوي لوحة مفاتيح الحاسوب على لوحة مفاتيح رقمية مستقلة. من المناقشة السابقة، تذكر حالتي لوحة المفاتيح الرئيسية اللتين تم تحديدهما: "افتراضي" و"قفل الأحرف الكبيرة" (انظر الشكل 1). يمكن أن تكون لوحة المفاتيح الرقمية أيضًا في حالتين - "أرقام" و"أسهم" - اعتمادًا على ما إذا كان قفل الأرقام نشطًا أم لا. وبالتالي، فإن فضاء الحالة الكامل للوحة المفاتيح في التفكيك القياسي هو حاصل الضرب الديكارتي للمكونين (لوحة المفاتيح الرئيسية ولوحة المفاتيح الرقمية) ويتكون من أربع حالات: "افتراضي - أرقام"، و"افتراضي - أسهم"، و"قفل الأحرف الكبيرة - أرقام"، و"قفل الأحرف الكبيرة - أسهم". ومع ذلك، سيكون هذا تمثيلًا غير طبيعي لأن سلوك لوحة المفاتيح الرقمية لا يعتمد على حالة لوحة المفاتيح الرئيسية والعكس صحيح. يسمح استخدام المناطق المتعامدة بتجنب خلط السلوكيات المستقلة كحاصل ضرب ديكارتي، وبدلاً من ذلك، ببقائها منفصلة، ​​كما هو موضح في الشكل 4.

لاحظ أنه إذا كانت المناطق المتعامدة مستقلة تمامًا عن بعضها البعض، فإن تعقيدها المُجمّع يكون جمعيًا فقط، مما يعني أن عدد الحالات المستقلة اللازمة لنمذجة النظام هو ببساطة مجموع k + l + m + ... ، حيث يُمثل k و l و m و ... عدد حالات OR في كل منطقة متعامدة. مع ذلك، فإن الحالة العامة للاعتماد المتبادل، من ناحية أخرى، تُؤدي إلى تعقيد ضربي، لذا فإن عدد الحالات اللازمة بشكل عام هو حاصل ضرب k × l × m × ...

في معظم الحالات الواقعية، تكون المناطق المتعامدة متعامدة تقريبًا فقط (أي ليست مستقلة تمامًا). لذلك، توفر مخططات حالة UML عدة طرق للتواصل بين هذه المناطق ومزامنة سلوكياتها. ولعل أهم ميزة من بين هذه الآليات المتنوعة (والمعقدة أحيانًا) هي قدرة المناطق المتعامدة على تنسيق سلوكياتها من خلال إرسال أحداث إلى بعضها البعض.

على الرغم من أن المناطق المتعامدة تشير إلى استقلالية التنفيذ (مما يسمح بمستويات متفاوتة من التزامن)، فإن مواصفات لغة النمذجة الموحدة (UML) لا تشترط تخصيص مسار تنفيذ منفصل لكل منطقة متعامدة (مع إمكانية القيام بذلك عند الرغبة). في الواقع، في أغلب الأحيان، تُنفَّذ المناطق المتعامدة ضمن نفس مسار التنفيذ. ^{[ 12 ]} ولا تشترط مواصفات لغة النمذجة الموحدة (UML) سوى ألا يعتمد المصمم على أي ترتيب محدد لإرسال أحداث معينة إلى المناطق المتعامدة ذات الصلة.

يمكن أن تحتوي كل حالة في مخطط حالة UML على إجراءات دخول اختيارية ، تُنفذ عند الدخول إلى حالة ما، بالإضافة إلى إجراءات خروج اختيارية ، تُنفذ عند الخروج من حالة ما. ترتبط إجراءات الدخول والخروج بالحالات، وليس بالانتقالات. وبغض النظر عن كيفية الدخول إلى حالة ما أو الخروج منها، سيتم تنفيذ جميع إجراءات الدخول والخروج الخاصة بها. وبسبب هذه الخاصية، تتصرف مخططات الحالة مثل آلات مور . في تدوين UML لإجراءات الدخول والخروج من الحالة، يتم وضع الكلمة المحجوزة "entry" (أو "exit") في خانة الحالة أسفل خانة الاسم مباشرةً، متبوعةً بشرطة مائلة وقائمة الإجراءات الاختيارية (انظر الشكل 5).

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

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

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

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

ليس من المستغرب أن يكون هذا الترتيب مماثلاً لترتيب استدعاء دوال البناء في الأصناف. يبدأ بناء الصنف دائمًا من جذر التسلسل الهرمي للأصناف، ويستمر عبر جميع مستويات الوراثة وصولًا إلى الصنف الذي يتم إنشاء نسخة منه. أما تنفيذ إجراءات الخروج، والتي تُقابل استدعاء دوال التدمير، فيتم بترتيب عكسي تمامًا (من الأسفل إلى الأعلى).

في كثير من الأحيان، يتسبب حدث ما في تنفيذ بعض الإجراءات الداخلية فقط، دون أن يؤدي إلى تغيير في الحالة (انتقال الحالة). في هذه الحالة، تشمل جميع الإجراءات المنفذة الانتقال الداخلي . على سبيل المثال، عند الكتابة على لوحة المفاتيح، تستجيب اللوحة بتوليد رموز أحرف مختلفة. ومع ذلك، ما لم يتم الضغط على مفتاح Caps Lock، فإن حالة لوحة المفاتيح لا تتغير (لا يحدث انتقال للحالة). في لغة النمذجة الموحدة (UML)، يجب نمذجة هذه الحالة باستخدام الانتقالات الداخلية، كما هو موضح في الشكل 6. يتبع ترميز UML للانتقالات الداخلية الصيغة العامة المستخدمة لإجراءات الخروج (أو الدخول)، باستثناء أنه بدلاً من كلمة دخول (أو خروج)، يتم تسمية الانتقال الداخلي بالحدث المُحفِّز (على سبيل المثال، انظر إلى الانتقال الداخلي الذي تم تشغيله بواسطة حدث ANY_KEY في الشكل 6).

في غياب إجراءات الدخول والخروج، تكون الانتقالات الداخلية مطابقةً للانتقالات الذاتية (الانتقالات التي تكون فيها الحالة المستهدفة هي نفسها الحالة المصدرية). في الواقع، في آلة ميلي الكلاسيكية ، ترتبط الإجراءات حصريًا بانتقالات الحالة، لذا فإن الطريقة الوحيدة لتنفيذ الإجراءات دون تغيير الحالة هي من خلال انتقال ذاتي (موضح كحلقة موجهة في الشكل 1 من أعلى هذه المقالة). مع ذلك، في وجود إجراءات الدخول والخروج، كما هو الحال في مخططات حالة UML، يتضمن الانتقال الذاتي تنفيذ إجراءات الدخول والخروج، وبالتالي فهو يختلف اختلافًا جوهريًا عن الانتقال الداخلي.

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

يُعقّد تداخل الحالات، بالإضافة إلى إجراءات الدخول والخروج، دلالات انتقال الحالة في آلات الحالة الهرمية (HSMs) بشكل كبير مقارنةً بآلات الحالة المحدودة التقليدية (FSMs). عند التعامل مع الحالات المتداخلة هرميًا والمناطق المتعامدة ، قد يكون مصطلح " الحالة الحالية" مُربكًا. في آلة الحالة الهرمية، يمكن أن تكون أكثر من حالة نشطة في الوقت نفسه. إذا كانت آلة الحالة في حالة طرفية مُضمنة في حالة مركبة (والتي قد تكون بدورها مُضمنة في حالة مركبة أعلى مستوى، وهكذا)، فإن جميع الحالات المركبة التي تحتوي على الحالة الطرفية، سواءً بشكل مباشر أو غير مباشر، تكون نشطة أيضًا. علاوة على ذلك، نظرًا لأن بعض الحالات المركبة في هذا التسلسل الهرمي قد تحتوي على مناطق متعامدة، فإن الحالة النشطة الحالية تُمثَّل في الواقع بشجرة من الحالات تبدأ بالمنطقة الوحيدة في الجذر وصولًا إلى الحالات البسيطة الفردية في الأوراق. يُشير مُواصفات لغة النمذجة الموحدة (UML) إلى شجرة الحالة هذه باسم "تكوين الحالة". ^{[ 1 ]}

في لغة النمذجة الموحدة (UML)، يمكن لانتقال الحالة أن يربط أي حالتين مباشرةً. تُسمى هاتان الحالتان، اللتان قد تكونان مركبتين، المصدر الرئيسي والهدف الرئيسي للانتقال. يوضح الشكل 7 مثالًا بسيطًا لانتقال الحالة، ويشرح أدوار الحالات فيه. تنص مواصفات UML على أن إجراء انتقال الحالة يتضمن تنفيذ الإجراءات بالتسلسل المحدد مسبقًا التالي (انظر القسم 14.2.3.9.6 من لغة النمذجة الموحدة الصادرة عن مجموعة إدارة الكائنات (OMG UML) ^{[ 1 ]} ):

1. قم بتقييم شرط الحماية المرتبط بالانتقال وقم بتنفيذ الخطوات التالية فقط إذا تم تقييم شرط الحماية إلى TRUE.
2. الخروج من إعدادات حالة المصدر.
3. نفّذ الإجراءات المرتبطة بالانتقال.
4. أدخل تكوين الحالة المستهدفة.

يسهل تفسير تسلسل الانتقال في الحالة البسيطة التي يكون فيها كل من المصدر الرئيسي والهدف الرئيسي متداخلين في نفس المستوى. على سبيل المثال، يؤدي الانتقال T1 الموضح في الشكل 7 إلى تقييم الشرط g()؛ متبوعًا بتسلسل الإجراءات: a(); b(); t(); c(); d();و e()؛ بافتراض أن الشرط g()يُقيّم إلى القيمة TRUE.

مع ذلك، في الحالة العامة لحالات المصدر والهدف المتداخلة في مستويات مختلفة من التسلسل الهرمي للحالات، قد لا يكون من الواضح فورًا عدد مستويات التداخل التي يجب الخروج منها. تنص مواصفات UML ^{[ 1 ]} على أن الانتقال يتضمن الخروج من جميع الحالات المتداخلة بدءًا من الحالة النشطة الحالية (والتي قد تكون حالة فرعية مباشرة أو متعدية لحالة المصدر الرئيسية) وصولًا إلى حالة السلف المشترك الأدنى (LCA) لحالتي المصدر والهدف الرئيسيتين، ولكن دون تضمينها. وكما يشير الاسم، فإن حالة السلف المشترك الأدنى هي أدنى حالة مركبة تمثل في الوقت نفسه حالة فائقة (سلفًا) لكل من حالتي المصدر والهدف. وكما ذُكر سابقًا، يكون ترتيب تنفيذ إجراءات الخروج دائمًا من الحالة الأكثر تداخلًا (الحالة النشطة الحالية) صعودًا في التسلسل الهرمي إلى حالة السلف المشترك الأدنى، ولكن دون الخروج منها. على سبيل المثال، حالة السلف المشترك الأدنى (s1,s2) للحالتين "s1" و"s2" الموضحة في الشكل 7 هي الحالة "s".

يبدأ الدخول إلى تكوين الحالة المستهدفة من المستوى الذي توقفت عنده إجراءات الخروج (أي من داخل تحليل دورة حياة النظام). وكما ذُكر سابقًا، يجب تنفيذ إجراءات الدخول بدءًا من أعلى مستوى حالة وصولًا إلى التسلسل الهرمي للحالات، ثم نزولًا إلى الحالة المستهدفة الرئيسية. إذا كانت الحالة المستهدفة الرئيسية مركبة، فإن دلالات لغة النمذجة الموحدة (UML) تنص على "التعمق" في آلتها الفرعية بشكل متكرر باستخدام الانتقالات الأولية المحلية. لا يتم الدخول إلى تكوين الحالة المستهدفة بالكامل إلا بعد الوصول إلى حالة طرفية لا تحتوي على انتقالات أولية.

قبل UML 2، ^{[ 1 ]} كان مفهوم الانتقال الوحيد المستخدم هو الانتقال الخارجي ، حيث يتم الخروج دائمًا من المصدر الرئيسي للانتقال والدخول دائمًا إلى الهدف الرئيسي. حافظ UML 2 على مفهوم "الانتقال الخارجي" للتوافق مع الإصدارات السابقة، ولكنه قدم أيضًا نوعًا جديدًا من الانتقال يُسمى الانتقال المحلي (انظر القسم 14.2.3.4.4 من لغة النمذجة الموحدة (UML) ^{[ 1 ]} ). بالنسبة للعديد من بنى الانتقال، يكون الانتقالان الخارجي والمحلي متطابقين فعليًا. ومع ذلك، لا يتسبب الانتقال المحلي في الخروج من حالة المصدر الرئيسي والعودة إليها إذا كانت حالة الهدف الرئيسية حالة فرعية من حالة المصدر الرئيسي. بالإضافة إلى ذلك، لا يتسبب انتقال الحالة المحلية في الخروج من حالة الهدف الرئيسية والعودة إليها إذا كانت حالة الهدف الرئيسية حالة عليا من حالة المصدر الرئيسي.

يوضح الشكل 8 مقارنة بين الانتقالات المحلية (أ) والخارجية (ب). في الصف العلوي، نرى حالة المصدر الرئيسي الذي يحتوي على الهدف الرئيسي. لا يتسبب الانتقال المحلي في الخروج من المصدر، بينما يتسبب الانتقال الخارجي في الخروج من المصدر ثم العودة إليه. في الصف السفلي من الشكل 8، نرى حالة الهدف الرئيسي الذي يحتوي على المصدر الرئيسي. لا يتسبب الانتقال المحلي في الدخول إلى الهدف، بينما يتسبب الانتقال الخارجي في الخروج من الهدف ثم العودة إليه.

أحيانًا، يقع حدث ما في وقت غير مناسب، عندما تكون آلة الحالة في حالة لا تسمح لها بالتعامل معه. في كثير من الحالات، تسمح طبيعة الحدث بتأجيله (ضمن حدود معينة) إلى أن يدخل النظام في حالة أخرى يكون فيها أكثر استعدادًا للتعامل مع الحدث الأصلي.

توفر آلات الحالة في لغة النمذجة الموحدة (UML) آلية خاصة لتأجيل الأحداث في الحالات. في كل حالة، يمكنك تضمين شرط [event list]/defer. إذا وقع حدثٌ في قائمة الأحداث المؤجلة للحالة الحالية، فسيتم حفظه (تأجيله) للمعالجة لاحقًا حتى يتم الدخول إلى حالة لا تحتوي على هذا الحدث في قائمة أحداثها المؤجلة. عند الدخول إلى مثل هذه الحالة، ستستدعي آلة الحالة في لغة النمذجة الموحدة (UML) تلقائيًا أي أحداث محفوظة لم تعد مؤجلة، ثم ستستهلكها أو تتجاهلها. من الممكن أن تحتوي حالة رئيسية على انتقال مُعرَّف على حدث مؤجل بواسطة حالة فرعية. بما يتوافق مع جوانب أخرى في مواصفات آلات الحالة في لغة النمذجة الموحدة (UML)، فإن الحالة الفرعية لها الأولوية على الحالة الرئيسية، وسيتم تأجيل الحدث ولن يتم تنفيذ انتقال الحالة الرئيسية. في حالة المناطق المتعامدة حيث تؤجل إحدى المناطق حدثًا وتستهلكه منطقة أخرى، فإن المستهلك له الأولوية ويتم استهلاك الحدث وليس تأجيله.