بناء نموذج كائن لمشكلة باستخدام لغة النمذجة UML. بناء نموذج كائن لعملية تجارية موجودة

23.08.2019

الآن لدينا كل المفاهيم اللازمة لوصف عملية بناء نموذج الكائن. تتضمن هذه العملية الخطوات التالية:

· تعريف الأشياء والفئات.

· إعداد قاموس البيانات.

· تحديد التبعيات بين الكائنات.

· تحديد سمات الكائن واتصالاته.

· تنظيم وتبسيط الفصول عند استخدام الميراث.

· مزيد من البحث وتحسين النموذج.

2.2.1. تعريف الطبقات.يتيح تحليل المتطلبات الخارجية لـ PS المصمم تحديد الكائنات وفئات الكائنات المرتبطة بالمشكلة المطبقة التي يجب على هذا النظام حلها. يجب أن تكون جميع الفئات ذات معنى في مجال التطبيق المعني؛ الفئات المرتبطة بتنفيذ الكمبيوتر، مثل القائمة والمكدس وما إلى ذلك. لا ينبغي أن تدار في هذه المرحلة.

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

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

· الطبقات الزائدة:إذا عبرت فئتان أو أكثر عن نفس المعلومات، فيجب الاحتفاظ بواحدة منها فقط؛

· عَرَضِيّ(لا علاقة لها بالمشكلة بشكل مباشر) الطبقات: لكل اسم فئة محتمل، يتم تقييم مدى ضرورته في النظام المستقبلي (وهذا غالبًا ما يكون من الصعب جدًا تقييمه)؛ يتم استبعاد الفئات غير ذات الصلة؛



· غير محددة(من وجهة نظر المشكلة) الطبقات(انظر البند 2.3.1)؛

· صفات: بعض الأسماء تتوافق أكثر مع السمات بدلا من الطبقات؛ تصف هذه الأسماء، كقاعدة عامة، خصائص الكائنات (على سبيل المثال، الاسم والعمر والوزن والعنوان وما إلى ذلك)؛

· عمليات: تتوافق بعض الأسماء مع أسماء العمليات أكثر من ارتباطها بالفئات (على سبيل المثال، من غير المرجح أن تشير phone_call إلى أي فئة)؛

· الأدوار: تحدد بعض الأسماء أسماء الأدوار في نموذج الكائن (على سبيل المثال، المالك، السائق، الرئيس، الموظف؛ كل هذه الأسماء مرتبطة بأدوار في تبعيات الكائنات المختلفة لفئة الشخص)؛

· هياكل التنفيذ: لا ينبغي مقارنة الأسماء المرتبطة بالبرمجة وأجهزة الكمبيوتر بالفئات في هذه المرحلة، لأنها لا تعكس ميزات PS المصممة؛ أمثلة على هذه الأسماء: الروتين الفرعي، العملية، الخوارزمية، المقاطعة، إلخ.

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

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

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

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

يجب عليك بعد ذلك إزالة التبعيات غير الضرورية أو غير الصحيحة باستخدام المعايير التالية:

· التبعيات بين الفئات المستبعدةيجب استبعادها أو إعادة صياغتها فيما يتعلق بالفئات المتبقية (انظر البند 2.3.3)؛

· التبعيات غير ذات الصلةويجب استبعاد تبعيات التنفيذ (انظر البند 2.3.3)؛

· أجراءات:يجب أن تصف التبعية الخصائص الهيكلية لمجال التطبيق، وليس الأحداث غير المهمة (انظر البند 2.3.3)؛

· تبعيات التدريب:يمكن تقسيم معظم التبعيات بين ثلاث فئات أو أكثر إلى عدة تبعيات ثنائية، باستخدام المؤهلات إذا لزم الأمر (انظر القسم 2.3.3)؛ وفي بعض الحالات (النادرة) لا يمكن تنفيذ هذا التحلل؛ على سبيل المثال، الاعتماد الثلاثي "الأستاذ يقوم بتدريس مقرر دراسي في الغرفة 628" لا يمكن تقسيمه إلى ثنائيات دون فقدان المعلومات؛

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

أرز. 2.36. التبعيات غير الزائدة

بعد إزالة التبعيات الزائدة، تحتاج إلى توضيح دلالات التبعيات المتبقية على النحو التالي:

· التبعيات التي تمت تسميتها بشكل خاطئ:ويجب إعادة تسميتها حتى يصبح معناها واضحًا (انظر البند 2.3.3)؛

· أسماء الأدوار:تحتاج إلى إضافة أسماء الأدوار عند الضرورة؛ يصف اسم الدور الدور الذي تلعبه الفئة المقابلة في تبعية معينة من وجهة نظر فئة أخرى تشارك في تلك التبعية؛ إذا كان اسم الدور واضحًا من اسم الفئة، فيمكن حذفه (انظر القسم 2.3.3)؛

· التصفيات:من خلال إضافة مؤهلات عند الضرورة، فإننا نقدم عناصر السياق، مما يسمح لنا بتحقيق تعريف لا لبس فيه للأشياء؛ تتيح المؤهلات أيضًا تبسيط بعض التبعيات عن طريق تقليل تعددها؛

· التعدد:من الضروري إضافة تسميات لتعدد التبعيات؛ يجب أن نتذكر أن تعدد التبعيات قد يتغير في عملية التحليل الإضافي لمتطلبات النظام؛

· التبعيات غير المحسوبةيجب تحديدها وإضافتها إلى النموذج.

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

السمات تتوافق عادةً مع الأسماء؛ على سبيل المثال، car_color (خاصية الكائن)، cursor_position (حالة الكائن). السمات، كقاعدة عامة، لها تأثير ضئيل على بنية نموذج الكائن.

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

إلى جانب سمات الكائن، من الضروري أيضًا إدخال سمات التبعيات بين الفئات (العلاقات بين الكائنات).

عند تحديد السمات، يتم الاسترشاد بالمعايير التالية:

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

· التصفيات. إذا كانت قيمة إحدى السمات تعتمد على سياق معين، فيجب جعلها مؤهلة (انظر القسم 2.3.4).

· الأسماء. عادة ما يتم مطابقة الأسماء من خلال المؤهلات بشكل أفضل من سمات الكائن؛ في جميع الحالات عندما يسمح الاسم للشخص بالاختيار من كائنات من مجموعة معينة، يجب أن يتم جعله مؤهلاً (انظر القسم 2.3.4).

· معرفات. ترتبط معرفات الكائنات بتنفيذها. في المراحل الأولى من التصميم، لا ينبغي اعتبارها سمات.

· سمات الارتباط. إذا كانت بعض الخصائص لا تميز الكائن نفسه، ولكن اتصاله بكائن آخر (كائنات)، فهذه سمة اتصال، وليست سمة كائن.

· القيم الداخلية. يجب استبعاد السمات التي تحدد الحالة الداخلية للكائن فقط، وغير المرئية خارج الكائن، من الاعتبار.

· تفاصيل غير مهمة. يوصى بحذف السمات التي لا تؤثر على تنفيذ معظم العمليات.

2.2.5. تنظيم النظام الطبقي باستخدام الميراث.بعد ذلك، عليك أن تحاول العثور على فئات فائقة للفئات المقدمة. وهذا مفيد لأنه يوضح بنية النموذج ويجعل التنفيذ اللاحق أسهل. تمت مناقشة المثال في الفقرة 2.3.5.

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

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

علامات وجود كائن مفقود (الفئة):

· عدم التماثل في الروابط والتعميمات (الميراث)؛ لإصلاح الخطأ، تحتاج إلى إضافة الفئات المفقودة؛

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

· تم اكتشاف عملية ليس لها فئة مستهدفة مرضية؛ لإصلاح الخطأ، تحتاج إلى إضافة الفئة المستهدفة المفقودة؛

· تم العثور على عدة تبعيات بنفس الأسماء والأغراض. لإصلاح الخطأ، تحتاج إلى تعميم وإضافة الفئة الفائقة المفقودة.

علامات وجود فئة غير ضرورية (زائدة عن الحاجة):

· عدم وجود السمات والعمليات والتبعيات لفئة معينة. لتصحيح الخطأ، عليك أن تفكر فيما إذا كان ينبغي استبعاد مثل هذه الفئة.

علامات التبعيات المفقودة:

· لا توجد مسارات للوصول إلى العمليات. لإصلاح الخطأ، تحتاج إلى إضافة تبعيات جديدة توفر القدرة على خدمة الطلبات المقابلة.

علامات التبعيات غير الضرورية (الزائدة عن الحاجة):

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

· لا توجد عمليات كافية تعبر التبعية؛ لتصحيح الخطأ، عليك أن تفكر فيما إذا كان ينبغي استبعاد مثل هذه التبعية.

علامات وضع التبعية غير السليم:

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

علامات وضع السمة غير الصحيحة:

· ليست هناك حاجة للوصول إلى كائن من خلال قيم إحدى سماته؛ لإصلاح الخطأ، عليك أن تفكر فيما إذا كنت بحاجة إلى تقديم تبعية مؤهلة.

للحصول على أمثلة للتطبيق العملي للخصائص الموصوفة، انظر الفقرة 2.3.6.

مثال لنموذج الكائن

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

2.3.1. تعريف الكائنات والفئات.في البند 1.3، تمت صياغة المهمة ويظهر رسم تخطيطي لشبكة الخدمة المصرفية (الشكل 1.3). من خلال تحليل بيان المشكلة هذا، من الممكن تحديد الفئات المحتملة من خلال مطابقتها مع الأسماء المذكورة في صياغتها الأولية؛ ينتج عن هذا القائمة التالية لأسماء الفئات المحتملة (بالترتيب الأبجدي):

نقوم بدراسة هذه القائمة مع استبعاد أسماء الفئات منها وفقًا لتوصيات الفقرة 2.2.1:

· فئات زائدة عن الحاجة: من الواضح أن العميل والمستخدم يعنيان نفس المفهوم؛ فمن الطبيعي بالنسبة للنظام المصرفي أن يترك فئة العملاء؛

· فئات غير ذات صلة: هذه الفئة هي فئة السعر (لا ترتبط مباشرة بتشغيل الشبكة المصرفية)؛

· فئات غير محددة: هذه الفئات هي خدمة حفظ السجلات والتحقق من الأمان (هذه الخدمات جزء من النشر)، والنظام (في حالتنا ليس من الواضح ما هو هذا)، والشبكة المصرفية (سيخدم PS بأكمله الشبكة المصرفية)؛

· صفات: بيانات المعاملات، وبيانات الحساب، والمال (بمعنى الأموال الحقيقية المقدمة للعميل عن طريق أمين الصندوق أو ماكينة الصراف الآلي، أو المقبولة من قبل أمين الصندوق)، والإيصال (الصادر إلى العميل مع المال) من الطبيعي أن يكون له سمات؛

· هياكل التنفيذأسماء صريحة مثل Software_software و Access؛ يجب أيضًا استبعادهم من قائمة أسماء الفئات المحتملة.

بعد إزالة جميع الأسماء غير الضرورية للفئات المحتملة، نحصل على القائمة التالية من الفئات التي تشكل النظام المصرفي المصمم (هذه الفئات معروضة في الشكل 2.5):

2.3.2. إعداد قاموس البيانات.فيما يلي جزء من قاموس البيانات الذي يحتوي على تعريفات للفئات المستخدمة في المشروع.

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

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

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

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

Cash_terminal - المحطة التي يقوم أمين الصندوق من خلالها بإجراء المعاملات للعملاء. عندما يقبل أمين الصندوق الأموال والشيكات ويصدرها، تقوم محطة نقطة البيع بطباعة الإيصالات. تتفاعل محطة نقاط البيع مع كمبيوتر البنك للتحقق من المعاملات ونشرها.

العميل هو صاحب حساب مصرفي واحد أو أكثر. قد يتكون العميل من فرد أو أكثر أو منظمة. يتم التعامل مع نفس الشخص الذي لديه حساب في بنك آخر كعميل مختلف.

Bank_computer هو جهاز كمبيوتر مملوك لبنك يتفاعل مع شبكة أجهزة الصراف الآلي (ATM) ومحطات النقد الخاصة بالبنك. قد يكون لدى البنك شبكة حاسوبية داخلية خاصة به لمعالجة الفواتير، ولكننا هنا نفكر فقط في حاسوب البنك الذي يتصل بشبكة الصراف الآلي.

الكونسورتيوم عبارة عن رابطة من البنوك التي تضمن تشغيل شبكة أجهزة الصراف الآلي (ATM). تنقل الشبكة المعاملات المصرفية إلى الكونسورتيوم.

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

الحساب - حساب مصرفي واحد يتم من خلاله إجراء الترحيلات. يمكن أن تكون الحسابات من أنواع مختلفة؛ يمكن أن يكون للعميل عدة حسابات.

Central_computer - جهاز كمبيوتر مملوك لاتحاد يقوم بتوزيع المعاملات ونتائجها بين أجهزة الصراف الآلي (ATMs) وأجهزة الكمبيوتر المصرفية. يتحقق الكمبيوتر المركزي من رموز البنك ولكنه لا يقوم بالنشر.

2.3.3. تعريف التبعيات.وبعد توصيات الفقرة 2.2.3، نميز بين الصريح والضمني عبارات الفعلمن البيان الأولي للمشكلة واعتبرها أسماء التبعيات المحتملة. من صياغة مشكلة الشبكة المصرفية (انظر القسم 1.3)، يمكن استخلاص التعبيرات التالية:

عبارات الفعل (الصريحة والضمنية):

الشبكة المصرفية يشملالصرافين وأجهزة الصراف الآلي

التحالف يوزعنتائج المعاملات عبر أجهزة الصراف الآلي

بنك يملككمبيوتر البنك

كمبيوتر البنك يدعمحسابات

بنك يملكمحطات النقدية

محطة النقدية يتفاعلمع كمبيوتر البنك

أمين الصندوق يدخلالترحيل إلى الفاتورة

أجهزة الصراف الآلي يتفاعلمع الكمبيوتر المركزي أثناء الأسلاك

كمبيوتر مركزي يتفاعلمع كمبيوتر البنك

ماكينة الصراف الآلي يقبلبطاقة

ماكينة الصراف الآلي يتواصلمع المستخدم

ماكينة الصراف الآلي مشاكلنقدي

ماكينة الصراف الآلي مطبوعاتإيصالات

نظام ينظمالوصول المشترك

بنك يوفربرمجة

التحالف يضمالبنوك

التحالف يملكالكمبيوتر المركزي

نظام يوفرتسجيل

نظام يوفرأمان

العملاء يملكبطاقات

بطاقة يوفر الوصولإلى الحساب

في البنك يخدمالصرافين

ثم نستبعد التبعيات غير الضرورية أو غير الصحيحة باستخدام المعايير الموضحة في الفقرة 2.2.3:

· التبعيات بين الفئات المستبعدة:يتم استبعاد التبعيات التالية: الشبكة المصرفية يشملالصرافون وأجهزة الصراف الآلي (باستثناء فئة الشبكة المصرفية)، وأجهزة الصراف الآلي مطبوعاتالإيصالات (باستثناء فئة الإيصال)، وأجهزة الصراف الآلي مشاكلنقدًا (تم استبعاد أموال الفئة)، System.out يوفرتسجيل المعاملات (تم استبعاد فئة خدمة حفظ السجل)، System.out يوفرأمان إدارة الحساب (تم استبعاد فئة Security_service)، البنوك يمدالبرمجيات (تم استبعاد فئة البرمجيات_البرمجيات)؛

· التبعيات غير ذات الصلة والتبعيات ذات الصلة بالتنفيذ:التبعية "النظام" ينظميتم استبعاد الوصول المشترك" باعتباره متعلقًا بالتنفيذ؛

· أجراءاتيتم وصفها بواسطة تبعيات مثل "ATM يقبلبطاقة "و" أجهزة الصراف الآلي يتواصلمع المستخدم"؛ نستبعد هذه التبعيات؛

· تبعيات التدريب:إدمان "أمين الصندوق" يدخلالنشر على الحساب" ينقسم إلى تبعيتين ثنائيتين هما "Cashier يدخلالأسلاك" و"الأسلاك يعود الىالحساب". التبعية "أجهزة الصراف الآلي". يتفاعلمع الكمبيوتر المركزي أثناء توصيل الأسلاك" يتم توسيعه إلى "أجهزة الصراف الآلي". يتفاعلمع الكمبيوتر المركزي" و"الأسلاك إبتدئ بماكينة الصراف الآلي"؛

· التبعيات المشتقة:التبعية "اتحاد" يوزعأجهزة الصراف الآلي هي نتيجة لتبعيات الكونسورتيوم يملك"الكمبيوتر المركزي" و"أجهزة الصراف الآلي". يتفاعلمع جهاز كمبيوتر مركزي."

عن طريق إزالة التبعيات الزائدة، نحصل على قائمة التبعيات التالية:

بنك يملككمبيوتر البنك

كمبيوتر البنك يدعمحسابات

بنك يملكمحطات النقدية

محطة النقدية يتفاعلمع كمبيوتر البنك

أمين الصندوق يدخلالأسلاك

الأسلاك يعود الىحساب

أجهزة الصراف الآلي يتفاعلمع الكمبيوتر المركزي

الأسلاك يبدأمع أجهزة الصراف الآلي

كمبيوتر مركزي يتفاعلمع كمبيوتر البنك

التحالف يضمالبنوك

التحالف يملكالكمبيوتر المركزي

العملاء يملكبطاقات

بطاقة يوفر الوصولإلى الحساب

في البنك يخدمالصرافين

دعونا نوضح دلالات التبعيات المتبقية على النحو التالي:

· دعونا إعادة تسميةالتبعيات المسماة بشكل غير صحيح حتى يصبح معناها أكثر وضوحًا؛ لذلك التبعية Computer_bank يدعميعد استبدال الحسابات بالتبعية للبنك أكثر ملاءمة يحملحسابات.

· أسماء الأدوارلا يجوز استخدامها، لأنها واضحة من أسماء الفئات المشاركة في التبعية، مثل تبعية ماكينة الصراف الآلي يتفاعلمع جهاز كمبيوتر مركزي

· التبعيات غير المحسوبة:الأسلاك يبدأمن Cash_terminal، العملاء يملكالحسابات، النشر مسجليجب إضافة البطاقة إلى النموذج.

بمجرد توضيح التبعيات، يمكن تجميع نسخة أولية من مخطط الكائن. بالنسبة للمشكلة قيد النظر، سيكون لها النموذج الموضح في الشكل. 2.37.

أرز. 2.37. الإصدار الأول من المخطط الكائني للشبكة المصرفية

2.3.4. توضيح السمة.بتطبيق المعايير الواردة في البند 2.2.4 نحصل على:

تحتوي البطاقة على رمز البنك ورمز البطاقة؛ يمكن اعتبارها سمات لكائنات فئة البطاقة، ولكن من الملائم استخدامها كمؤهلات، حيث يضمن رمز البنك اختيار البنك، مما يقلل من تعدد العلاقة بين الكونسورتيوم والبنك؛ لاستخدام مماثل لـcard_code، تحتاج إلى إضافة تبعية البنك مشاكلالبطاقات، والتي سيكون مؤهلها هو رمز_البطاقة.

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

2.3.5. تنظيم النظام الطبقي باستخدام الميراث.في المثال قيد النظر، من الطبيعي تحديد الفئات الفائقة للكائنات التي تحدد المحطات الطرفية المختلفة: Cash_terminal وATM (ATM)، وللكائنات التي تحدد المعاملات: Cashier_transaction وremote_transaction (من ماكينة الصراف الآلي).

وبعد إجراء التغييرات المناسبة، نحصل على المخطط الكائني الموضح في الشكل. 2.39.

أرز. 2.38. مخطط كائن لشبكة مصرفية بعد تحديد السمات وإضافة المؤهلات

أرز. 2.39. مخطط كائن للخدمات المصرفية مع مراعاة الميراث

2.3.6. مزيد من التحسين للنموذج.تعمل البطاقة في كيانين: كوحدة تسجيل في البنك (دفتر الحسابات الجاري)، والتي توفر للعميل إمكانية الوصول إلى حساباته، وكبنية بيانات تعمل بها أجهزة الصراف الآلي. لذلك، من الملائم تقسيم فئة البطاقة إلى فئتين: Registration_card وcard؛ توفر الأولى من هذه الفئات للعميل إمكانية الوصول إلى حساباته المصرفية، والثانية تحدد بنية البيانات التي تعمل بها أجهزة الصراف الآلي.

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

من الطبيعي الجمع بين فئة البنك وفئة الكمبيوتر_البنك وفئة الكونسورتيوم وفئة الكمبيوتر_المركزي.

أرز. 2.40. المنظر النهائي للمخطط الكائني للشبكة المصرفية

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

عزل النظم الفرعية

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

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

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

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

النظام الفرعيهي مجموعة من الكائنات والأنظمة الفرعية التي توفر بعض الوظائف وتتفاعل مع بعضها البعض وفقًا لواجهاتها. واجهة النظام الفرعييمثل مجموعة فرعيةالجمع بين واجهات جميع الكائنات والأنظمة الفرعية التي يتكون منها هذا النظام الفرعي. قد يتضمن النظام الفرعي واحدًا أو أكثر من الكائنات و/أو الأنظمة الفرعية المترابطة.

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

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

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

أرز. 2.41. رسم تخطيطي لكائن الشبكة المصرفية، والذي يشير إلى الواجهة مع بيئة النظام

أرز. 2.42. رسم تخطيطي لكائن الشبكة المصرفية وبيئة نظامها

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

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

واجهة الكائنيتم تعريفه من خلال واجهة الفئة المقابلة ويتم تحديده من خلال قائمة التوقيعات الخاصة بالعمليات العامة (الطرق). واجهة النظام الفرعييتم تعريفه من خلال واجهات الكائنات المكونة له وأنظمته الفرعية على النحو التالي: يمكن تضمين العملية في واجهة النظام الفرعي إذا كان هذا النظام الفرعي يحتوي على كائن (نظام فرعي) تحتوي واجهته على هذه العملية. يتم وصف الواجهات بلغة وصف الواجهة IDL (لغة تعريف الواجهة).

يتم تحديد جميع قدرات معالجة البيانات داخل النظام الفرعي (أي في كل مكون مدرج في تركيبته) من خلال مجموعة من الواجهات الخاصة بمكوناته، والتي تحدد البيئة الداخلية للنظام الفرعي.

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

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

أرز. 2.43. رسم تخطيطي لكائن الشبكة المصرفية بعد تسليط الضوء على النظام الفرعي للبنك

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

التبعيات بين الفئات (الكائنات)

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

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

أرز. 2.6. التبعيات بين الطبقات

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

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

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


التبعيات بين الفئات تتوافق مع التبعيات بين كائنات هذه الفئات. يوضح الشكل 2.8 التبعيات بين الكائنات في المثال الأول من الشكل 2.6؛ يوضح الشكل 2.9 التبعيات بين الكائنات للأمثلة الموضحة في الشكل 2.7.

أرز. 2.7. مزيد من الأمثلة على التبعيات. التسميات


أرز. 2.8. التبعيات بين الكائنات

لاحظ أنه عند تصوير التبعيات بين الكائنات، فإننا، كقاعدة عامة، نعرف عدد الكائنات ولا نحتاج إلى تسميات مثل "عدة"، "اثنان أو أكثر"، "ليس بالضرورة".

عند تصميم النظام، يكون الأمر أكثر ملاءمة للعمل ليس مع الكائنات، ولكن مع الفئات.

أرز. 2.9. المزيد من التبعيات المعقدة بين الكائنات

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

الآن لدينا كل المفاهيم اللازمة لوصف عملية بناء نموذج الكائن. تتضمن هذه العملية الخطوات التالية:

  • تعريف الكائنات والفئات؛
  • إعداد قاموس البيانات؛
  • تحديد التبعيات بين الكائنات.
  • تحديد سمات الكائن والعلاقات؛
  • تنظيم وتبسيط الفصول عند استخدام الميراث؛
  • مزيد من البحث وتحسين النموذج.

بناء نموذج كائن لمشكلة باستخدام لغة النمذجة UML.

يتم العمل في StarUML

مهلة:

2 – 3 دروس

للدفاع عن عملك، يجب عليك تقديم مشروع تم إنشاؤه في حزمة Rational Rose، بما في ذلك ثلاثة أنواع من الرسوم البيانية: حالات الاستخدام، والفئات (الواجهة، والبيانات) والتسلسلات لكل وظيفة.

مهمة نموذجية:

ومن الضروري التأكد من تخزين المعلومات التالية في قاعدة البيانات:

- بيانات الطالب

س الاسم الكامل.،

س عنوان،

س تفاصيل جواز السفر،

س رقم السجل,

س تاريخ الميلاد،

س مجموعة)؛

- معلومات عن التخصصات

س اسم التخصص،

س الشفرة؛

- معلومات حول المجموعات

س تخصص،

س سنة القبول،

س رقم المجموعة.

التأكد من إصدار وثيقة "قائمة المجموعة" التي تحتوي على الحقول التالية:

· رقم سري،

· الاسم الكامل.،

· رقم السجل.


أمر العمل

يتم تنفيذ بناء نموذج الكائن في حزمة Rational Rose. للقيام بذلك، دعونا إنشاء مشروع فارغ. يجب أن تبدأ عملك بمخطط حالة الاستخدام. تم بناؤه في المنطقة الرئيسية لقسم عرض حالة الاستخدام، كما هو موضح في الشكل 9.

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

يظهر الرسم التخطيطي المبني في الشكل. 10.


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



يعرض الرسم التخطيطي للفئة التي تم إنشاؤها جميع أشكال التطبيق المستقبلي وعلاقاتها.

يجب عليك إدخال الحقول الرئيسية وإنشاء اتصال (من قائمة سياق السهم - التعددية).

المرحلة التالية من بناء نموذج كائن هي إنشاء مخططات تسلسلية. يتم إنشاء مخططات تسلسلية لكل حالة استخدام في مخطط حالة الاستخدام. لإضافة مخطط تسلسل إلى حالة استخدام، تحتاج إلى تحديده في الشجرة واستدعاء قائمة السياق الموجودة عليه (NewàSequence Diagram) كما هو موضح في الشكل. 13.

يظهر في الشكل مثال لمخطط تسلسلي لسابقة "الحفاظ على قائمة التخصصات". 14.

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

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


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


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

فوائد نموذج الكائن

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


1. يتيح لك نموذج الكائن الاستخدام الكامل للقدرات التعبيرية للبرمجة الكائنية والموجهة للكائنات. يلاحظ ستروستروب، "ليس من الواضح دائمًا كيفية الاستفادة الكاملة من لغة مثل C++. يمكن تحقيق تحسينات كبيرة في الكفاءة وجودة التعليمات البرمجية ببساطة عن طريق استخدام C++ باعتبارها "C محسنة" مع عناصر تجريد البيانات. ومع ذلك، هناك الكثير من A التقدم الكبير هو إدخال التسلسل الهرمي للفئات في عملية التصميم، وهذا ما يسمى التصميم الموجه للكائنات، وهذا هو المكان الذي تظهر فيه فوائد C++ بشكل أفضل. لقد أظهرت التجربة أنه عند استخدام لغات مثل Smalltalk وObject Pascal وC++ وCLOS وAda خارج نموذج الكائن، يتم تجاهل أقوى ميزاتها أو إساءة تطبيقها.
2. يؤدي استخدام النهج القائم على الكائنات إلى زيادة كبيرة في مستوى توحيد التطوير وإعادة استخدام ليس فقط البرامج، ولكن أيضًا المشاريع، مما يؤدي في النهاية إلى خلق بيئة تطوير. غالبًا ما تكون الأنظمة الموجهة للكائنات أكثر إحكاما من نظيراتها غير الموجهة للكائنات. وهذا لا يعني فقط تخفيض في حجم كود البرنامج، بل أيضا تخفيض في تكلفة المشروع، وذلك بسبب استخدام التطويرات السابقة، مما يعطي مكسبا في التكلفة والوقت
3. يؤدي استخدام النموذج الكائني إلى بناء أنظمة تعتمد على أوصاف وسيطة مستقرة، مما يبسط عملية إجراء التغييرات. وهذا يمنح النظام الفرصة للتطور تدريجياً ولا يؤدي إلى إعادة صياغته بالكامل حتى في حالة حدوث تغييرات كبيرة في المتطلبات الأولية.
4. يقلل نموذج الكائن من مخاطر تطوير أنظمة معقدة، ويرجع ذلك أساسًا إلى أن عملية التكامل تمتد على مدار فترة التطوير بأكملها بدلاً من أن تصبح حدثًا لمرة واحدة. يتكون نهج الكائن من سلسلة من خطوات التصميم المدروسة جيدًا، والتي كما يقلل من درجة المخاطرة ويزيد من الثقة في صحة القرارات المتخذة.
5. النموذج الكائني موجه نحو الإدراك البشري للعالم، أو، على حد تعبير روبسون، "كثير من الأشخاص الذين ليس لديهم أي فكرة عن كيفية عمل الكمبيوتر يجدون النهج الكائني في التعامل مع الأنظمة أمرًا طبيعيًا تمامًا".

تطبيق نظام يمثل مجموعة من الكائنات المترابطة. ويتميز كل كائن بمجموعة من الخصائص، التي تحدد قيمها حالة الكائن، ومجموعة العمليات التي يمكن تطبيقها على هذا الكائن.

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

وبالتالي، فإن كل كائن له واجهة محددة بدقة، أي. مجموعة من العمليات العامة التي يمكن تطبيقها على هذا الكائن. جميع الكائنات من نفس الفئة لها نفس الواجهة.

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

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

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

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

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

تسلسل الأحداث يسمى البرنامج النصي. بعد تطوير السيناريوهات وتحليلها، يتم تحديد الكائنات التي تولد وتستقبل كل حدث سيناريو.

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

تتضمن عملية بناء نموذج الكائن الخطوات التالية:

تعريف الأشياء والفئات.

إعداد قاموس البيانات:

تحديد التبعيات بين الكائنات.

تحديد خصائص الأشياء والاتصالات؛

تنظيم وتبسيط الفصول عند استخدام الميراث؛

مزيد من البحث وتحسين النموذج.