تاريخ UML

بدأ تطوير UML في أكتوبر 1994، عندما بدأ Grady Booch وJim Rumbaugh من شركة Rational Software Corporation العمل معًا لتوحيد أساليب Booch وOMT (تقنية نمذجة الكائنات). تم تطوير كلتا الطريقتين بشكل مستقل عن بعضهما البعض وتم تسميتهما بحق كواحدة من أفضل طرق النهج الموجه للكائنات في تطوير أنظمة البرمجيات. تقرر الجمع بين هاتين الطريقتين، وفي أكتوبر 1995 تم إصدار نسخة تجريبية، والتي كانت تسمى الطريقة الموحدة.

بحلول نهاية عام 1996، أصبح من الواضح أن عددًا من الشركات الكبيرة كانت على استعداد لاعتبار UML بمثابة استراتيجية عمل أساسية. تم إنشاء اتحاد غير ربحي OMG (Object Modeling Group)، والذي وحد الشركات المصنعة للبرامج الرائدة مثل DEC، HP، IBM، Microsoft، Oracle، Rational Software، إلخ. في يناير 1997، تم إصدار UML 1.0. وسرعان ما انضمت شركات مثل IBM وObjectime وPlatinum Technology وSofteam إلى OMG. ونتيجة لهذا التعاون، ظهر UML 1.1. تم اعتماد الإصدار 1.5 في عام 2003. 2004 - الإصدار 2.0 المعتمد

هيكل UML

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

يوفر UML تطوير نماذج تمثيلية لتنظيم التفاعل بين العميل ومطور نظم المعلومات ومجموعات مختلفة من مطوري نظم المعلومات.

أولاً، يرث UML تقنيات من Booch وOMT وOOSE.

وثانيا أنه يغطيهم.

ثالثًا، تجدر الإشارة إلى أن UML هو معيار لغة، وليس معيار عملية.

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

من وجهة النظر الأكثر عمومية، يتكون وصف لغة UML من جزأين متفاعلين، مثل:

دلالات لغة UML. إنه يمثل نموذجًا محددًا يحدد التركيب المجرد ودلالات مفاهيم نمذجة الكائنات في لغة UML.

تدوين UML. إنها تدوين رسومي لتمثيل دلالات لغة UML بشكل مرئي.

مخططات UML

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

يمكن أن يتضمن المشروع الذي تم إنشاؤه باستخدام UML 1.x المخططات التالية (مجمعة وفقًا للغرض منها): هناك مثل هذه المخططات ثمانية:

استخدم الرسم البياني

· مخطط الطبقة

· مخططات السلوك

o مخطط الحالة

س مخطط النشاط

س مخططات التفاعل

§ مخطط تسلسل

§ مخطط التعاون

· مخططات التنفيذ

o مخطط المكونات

س مخطط النشر

3.1. استخدم الرسم البياني

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

يصف وظيفة مرئية للمستخدم،

يمكن أن تمثل مستويات مختلفة من التفاصيل،

يضمن تحقيق هدف محدد مهم للمستخدم.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مع وجهة نظر مفاهيميةيمثل UML وصفًا لمفاهيم المجال. نحن هنا لا نتحدث كثيرًا عن العناصر البرمجية بقدر ما نتحدث عن إنشاء مفردات لمناقشة مجال موضوع معين.

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

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

هناك اختلاف آخر في الرأي يتعلق بمسألة طبيعة UML. أعتقد أن معظم مستخدمي UML، وخاصة المخططين، يرون جوهر UML في مخططاته. ومع ذلك، فإن مؤلفي UML يعتبرون المخططات ثانوية، ويعتبر نموذج UML النموذجي أساسيًا. الرسوم البيانية هي مجرد تمثيل لنموذج metamodel. وجهة النظر هذه منطقية أيضًا للمطورين الذين يستخدمون UML في وضع التصميم وفي وضع لغة البرمجة.

ملخص:تم تحديد 3 طرق لاستخدام UML.

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

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

3- وضع لغة البرمجة . يتم تجميع المخططات الرسومية في التعليمات البرمجية، ويصبح UML هو الكود المصدري.

إجابة من السنوات السابقة (دن)

لغة لغة النمذجة الموحدة (UML)يمكن اعتباره نتيجة لتطور طويل وغير مكتمل بعد لمنهجيات النمذجة والتصميم.

وقد سعى هذا التوحيد إلى تحقيق ثلاثة أهداف رئيسية:

· نمذجة النظام، من المفهوم إلى الوحدة القابلة للتنفيذ، باستخدام التقنيات الموجهة للكائنات.

· حل مشاكل القياس في الأنظمة المعقدة.

· إنشاء لغة النمذجة التي يستخدمها كل من البشر وأجهزة الكمبيوتر.

ما هو UML المستخدم؟

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

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

UML هي لغة المواصفات والتعاريف الدقيقة. وبهذا المعنى، تعني نمذجة UML بناء نماذج دقيقة، لا لبس فيها، وكاملة.

UML هي لغة التوثيق.

مخططات UML

يتم تنفيذ تصور تصميم النظام من وجهات نظر مختلفة في UML من خلال الرسوم البيانية - إسقاطات النظام. الرسم التخطيطي هو تمثيل رسومي لمجموعة من العناصر، والتي يتم تصويرها كرسم بياني متصل مع القمم (الكيانات) والحواف (العلاقات).

فيما يلي تعريفات المخططات:

· مخطط الطبقة- رسم تخطيطي هيكلي يوضح العديد من الفئات والواجهات والتعاون والعلاقات فيما بينها؛

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

· استخدم الرسم البياني- مخطط سلوكي يوضح العديد من السوابق والفاعلين، وكذلك العلاقات بينهم؛

· مخطط التفاعل:

س مخطط تسلسل- مخطط سلوكي يوضح التفاعل ويسلط الضوء على التسلسل الزمني للأحداث؛

س مخطط التعاون- مخطط سلوكي يوضح التفاعل ويؤكد التنظيم الهيكلي للكائنات التي ترسل وتستقبل الرسائل؛

· مخطط الحالة- مخطط سلوكي يوضح الآلة ويسلط الضوء على سلوك الكائنات من حيث الترتيب الذي يتم به تلقي الأحداث؛

· الرسم النشاط- مخطط سلوكي يوضح الآلة ويسلط الضوء على انتقالات تدفق التحكم من نشاط إلى آخر؛

· مخطط المكون- رسم تخطيطي يوضح تنظيم مجموعة معينة من المكونات والتبعيات بينها - يشير إلى النوع الإحصائي للنظام؛

· مخطط طوبولوجيا النظام (مخطط النشر)- مخطط هيكلي يوضح العقد والعلاقات بينها.

إجابة السنوات السابقة (المدينة المنورة)

الخيار 1

منهجية تصميم الكائنات في UML (مخططات UML)

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

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

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

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

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

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

يمكن أن يتضمن مخطط الفصل ثلاث فئات مختلفة من العلاقات: التبعية والتعميم والارتباط.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أي كلية هي جزء من جامعة واحدة، وتصفية الجامعة تؤدي إلى تصفية جميع الكليات الموجودة فيها، رغم أنه خلال وجود الجامعة يمكن تصفية وإنشاء كليات فردية.

يمكن أن تحدد الرسوم البيانية للفئة قيود التكامل التي يجب دعمها في قاعدة البيانات المصممة. يسمح UML بطريقتين لتحديد القيود: باللغة الطبيعية وفي OCL (لغة قيود الكائنات).

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

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

فيما يلي أمثلة على الثوابت لتحديد القيود في OCL.

1. التعبير في OCL عن القيد الذي بموجبه يجب على الموظفين الذين تزيد أعمارهم عن 30 عامًا العمل في الأقسام التي بها أعداد أكبر من 5

2. تحديد القيد بأن كل قسم يجب أن يكون له مدير ولا يجوز تأسيس أي قسم قبل الشركة المقابلة له

3. شرط المتغير الرابع يحدد الحد الأقصى لعدد موظفي الشركة بـ 1000 موظف

الخيار 2

1. نموذج روب. المخططات الأساسية لنموذج RUP.

تعد العملية الموحدة العقلانية (RUP) إحدى منهجيات تطوير البرمجيات الحلزونية. يتم دعم المنهجية بواسطة برنامج Rational، ويتم تحديث المنتج مرتين سنويًا تقريبًا. يتم استخدام لغة النمذجة الموحدة (UML) كلغة نمذجة في قاعدة المعرفة العامة.

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

التطوير التكراري؛

إدارة متطلبات؛

استخدام البنى المعيارية؛

النمذجة المرئية

فحص الجودة؛

تعقب التغيرات.

تسمى التمثيلات الرسومية لنماذج النظام في UML الرسوم البيانية. فيما يتعلق بلغة UML، يتم تعريف الأنواع التالية:

· حالة الاستخدام أو مخطط حالة الاستخدام(استخدم الرسم البياني)

· مخطط الطبقة(مخطط الطبقة)

· مخططات السلوك(مخططات السلوك)

· الرسم التخطيطي للدولة(مخطط الحالة)

· الرسم النشاط(الرسم النشاط)

· مخططات التفاعل(مخططات التفاعل)

· مخطط تسلسل(مخطط تسلسل)

· مخطط التعاون(مخطط التعاون)

· مخططات التنفيذ(مخططات التنفيذ)

· مخطط المكون(مخطط المكونات)

· مخطط النشر(مخطط النشر)

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

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

بالنسبة لمخططات UML، هناك ثلاثة أنواع من الرموز المرئية التي تعتبر مهمة من حيث المعلومات التي تحتوي عليها:

· مجال الاتصالاتوالتي يتم تمثيلها بخطوط مختلفة على المستوى؛

· نص، الموجودة داخل حدود الأشكال الهندسية الفردية؛

· الرموز الرسومية، تم تصويره بالقرب من العناصر المرئية للرسوم البيانية.

· يجب أن يمثل كل رسم بياني تمثيلاً كاملاً لجزء من موضوع النموذج.

· يجب أن تكون الكيانات النموذجية المعروضة في الرسم البياني من نفس المستوى المفاهيمي.

· يجب عرض جميع المعلومات المتعلقة بالكيانات بشكل واضح في الرسم البياني.

· يجب ألا تحتوي الرسوم البيانية على معلومات متضاربة.

· لا ينبغي أن تكون الرسوم البيانية مثقلة بالمعلومات النصية.

· يجب أن يكون كل مخطط مكتفياً ذاتياً من أجل التفسير الصحيح لجميع عناصره.

· عدد أنواع المخططات المطلوبة لوصف نظام معين ليس محددًا بشكل صارم ويتم تحديده بواسطة المطور؛

يجب أن تحتوي نماذج النظام فقط على تلك العناصر التي تم تعريفها

22. تصميم IC [J]

إجابة توني جاهزة

تم تحديث إجابات دينيس كوفاليفيتش

مرحلة التنفيذ

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

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

· الخطط الطموحة أكثر مما ينبغي بدلاً من التوجه الحكيم خطوة بخطوة؛

· عدم الحصول على النصائح الكافية من الممارسين ذوي الخبرة الفعلية في استخدام أنظمة مماثلة في أعمال مماثلة.

مرحلة التشغيل

س الاستخدام اليومي.

تصرف

إجابة السنوات السابقة (المدينة المنورة)

تطبيق.

2.1. إعداد المشاريع الفنية (TP).

ويشكل مستشارو المقاول ومتخصصو تكنولوجيا المعلومات لدى العميل TP؛

يوافق العميل على TP.

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

يتم استخدام مواد TP عند تخطيط وتوثيق العمل.

تكوين TP:

هيكل البيانات المخزنة.

الخوارزميات.

موارد النظام المستخدمة وبنيتها واتصالاتها ؛

واجهة المستخدم.

2.2. تخطيط العمل.

وفقا للضوابط المعتمدة

يقوم مديرو المشاريع للمقاول والعميل بوضع برامج العمل (WP)؛

يوافق العميل والمقاول على خطة الإقامة.

يتم وضع الخطط الفردية لأعضاء فريق العمل.

تكوين RP:

قائمة الأعمال: التكوين والاختبار والقبول (قد تتضمن قائمة الأعمال المواصفات الفنية والمواصفات الفنية)؛

الفترة الزمنية؛

المسؤول عن كل بند من RP.

2.3. تعبئة الكتب المرجعية الأساسية.

مميزات المرحلة:

قد يتطلب من 1 إلى 18 شهرا؛

يتطلب مركزية إدخال المعلومات؛

هو شرط ضروري لتشغيل النظام.

طرق التنفيذ:

تحويل البيانات؛

إدخال البيانات يدويا من قبل المستخدمين (المشغلين).

2.4. الإعداد والاختبار والقبول.

مميزات المرحلة:

الأكثر كثافة في العمل والمسؤولية ؛

يعتمد بشكل كبير على الإعداد الأولي (اللوائح، المواصفات الفنية، المواصفات الفنية، RP)؛

يتطلب انضباطًا صارمًا من جانب المؤدي ومن جانب العميل ؛

مصحوبة بظهور مهام إضافية من العميل؛

يتطلب المرونة من جانب العميل والمقاول للتغلب على حالات الصراع.

2.5. التشغيل التجريبي.

مميزات المرحلة:

يتطلب استجابة سريعة وموثوقة من المؤدي؛

قد يتطلب جهدًا كبيرًا من العميل (عمل مزدوج)؛

لها مدة كبيرة (1-3 أشهر)؛

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

2.6. توثيق.

إعداد التعليمات للمستخدمين؛

وضع لوائح لتفاعل الإدارات داخل النظام؛

وضع الصيغة النهائية للوثائق الفنية؛

تشكيل وثائق أخرى (متفق عليها مسبقًا).

2.7. اكمال المشروع.

الإغلاق القانوني للعلاقات التعاقدية؛

التسويات المالية النهائية؛

اتخاذ القرارات بشأن مزيد من التعاون: إبرام اتفاقيات الدعم الفني ودعم ما بعد الضمان، وتنفيذ مشاريع جديدة.

إعادة تدوير الملكية الفكرية- يتم تنفيذها باستخدام زر الحذف.

إجابة من السنوات السابقة (دن)

مرحلة التنفيذ

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

إذا ظهرت مشاكل في هذه المرحلة، فإنها ترتبط بالأسباب الثلاثة الرئيسية التالية:

نقص الدعم من الموظفين الرئيسيين، خاصة عندما يجب تخصيص ما يكفي من الوقت والطاقة في المراحل الحرجة؛

الخطط الطموحة بشكل مفرط بدلاً من النهج الحكيم خطوة بخطوة؛

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

مرحلة التشغيل

· تفعيل نظام المعلومات

o تشغيل المعدات التقنية للتشغيل التجريبي؛

o وضع البرنامج قيد التشغيل التجريبي؛

o تدريب الموظفين وإصدار الشهادات لهم؛

o إجراء التشغيل التجريبي للمكونات والنظام ككل؛

o التكليف وتوقيع شهادات قبول العمل.

· تشغيل نظام المعلومات

س الاستخدام اليومي.

o دعم البرامج والأجهزة والمشروع بأكمله.

مرحلة الدعم (الصيانة).

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

الإجراءات الأولية الرئيسية استعدادًا لتنظيم صيانة نظام المعلومات هي:

· تحديد المكونات الأكثر أهمية في النظام وتحديد مدى أهمية وقت التوقف عن العمل بالنسبة لها (وهذا سيسمح بتحديد المكونات الأكثر أهمية في نظام المعلومات وتحسين تخصيص الموارد للصيانة)؛

· تحديد مهام الصيانة وتقسيمها إلى داخلية، يحلها قسم الخدمة، وخارجية، تحلها منظمات خدمية متخصصة (وبالتالي يتم تحديد واضح لمجموعة المهام المنجزة وتقسيم المسؤوليات).

· تحليل الموارد الداخلية والخارجية المتاحة اللازمة لتنظيم الصيانة في إطار المهام الموصوفة وتقسيم الاختصاص (المعايير الرئيسية للتحليل: توافر الضمان على المعدات، وحالة صندوق الإصلاح، ومؤهلات الموظفين)؛

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

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

تصرف

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

تمت تغطية هذا الموضوع بتفصيل كبير على http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 وعلى http://www.rus-lib.ru/book/38/men/21 /2.3 .html

23. تصميم IC [J]

معلومات ذات صله.

تعريف مماثل لتلك أدناه.

لغة- نظام العلامات الذي يخدم:

• وسيلة للتواصل البشري والنشاط العقلي.
• وسيلة للتعبير عن الوعي الذاتي للشخص؛
• وسيلة لتخزين ونقل المعلومات.

تتضمن اللغة مجموعة من العلامات (المفردات) وقواعد استخدامها وتفسيرها (القواعد).

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

عند وصف لغة اصطناعية رسمية، وهو ما رأيناه بالفعل في أمثلة وصف لغات البرمجة، كقاعدة عامة، يتم وصف هذه العناصر على النحو التالي:

1. بناء الجملةأي تحديد قواعد بناء بنيات اللغة؛
2. دلالاتأي تعريف القواعد التي بموجبها تكتسب هياكل اللغة المعنى الدلالي؛
3. التداوليةأي تحديد قواعد استخدام بنيات اللغة لتحقيق الأهداف التي نحتاجها.

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

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

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

تاريخ موجز لـ UML

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

بناءً على طلب مجموعة إدارة الكائنات (OMG)، وهي المنظمة المسؤولة عن اعتماد المعايير في مجال تقنيات الكائنات وقواعد البيانات، تم حل المشكلة الملحة المتمثلة في التوحيد والتوحيد القياسي من قبل مؤلفي أساليب OO الثلاثة الأكثر شيوعًا - G قام بوتش ود. رامبو وأ. جاكوبسون، بتضافر جهودهم، بإنشاء إصدار UML 1.1، الذي تمت الموافقة عليه من قبل OMG في عام 1997 كمعيار.

UML هي لغة

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

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

قاموس UML

ويتم تمثيل النموذج على شكل كيانات والعلاقات فيما بينها والتي تظهر في الرسوم البيانية.

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

علاقةإظهار الروابط المختلفة بين الكيانات. يتم تعريف أنواع العلاقات التالية في UML:

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

المخططات.يوفر UML المخططات التالية:

• الرسوم البيانية التي تصف سلوك النظام:
• مخططات الدولة
• مخططات النشاط,
• المخططات الكائنية,
• مخططات التسلسل,
• مخططات التعاون؛
• مخططات تصف التنفيذ المادي للنظام:
• المخططات المكونة؛
• مخططات النشر.

عرض التحكم بالنموذج. الحزم.

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

ما يقدمه UML.

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

وآخر شيء...

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

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

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

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

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

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

يؤدي استخدام UML إلى حل المشكلة الثالثة: النموذج الواضح يجعل الاتصال أسهل.

يتم تصميم بعض ميزات النظام بشكل أفضل من خلال النص، والبعض الآخر من الناحية الرسومية. في الواقع، يوجد في جميع الأنظمة المثيرة للاهتمام هياكل لا يمكن تمثيلها باستخدام لغة البرمجة وحدها. UML هي لغة رسومية تسمح لنا بحل المشكلة الثانية التي تم تحديدها.

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

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

UML هي لغة تصميم مرئي، ويمكن ترجمة النماذج التي تم إنشاؤها باستخدامها مباشرة إلى لغات برمجة IS المختلفة.

عند تطوير IS، هناك عناصر مثل:

• متطلبات النظام؛
• وصف العمارة.
• مشروع؛
• مصدر؛
• خطط المشروع؛
• الاختبارات؛
• النماذج الأولية؛
• الإصدارات، الخ.

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

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

أين يتم استخدام UML؟

لغة UML مخصصة في المقام الأول لتطوير نظم المعلومات. استخدامه فعال بشكل خاص في المجالات التالية:

• نظم المعلومات على مستوى المؤسسة؛
• الخدمات المصرفية والمالية؛
• الاتصالات السلكية واللاسلكية.
• ينقل؛
• صناعة الدفاع والطيران والملاحة الفضائية.
• بيع بالتجزئة؛
• الالكترونيات الطبية.
• العلم؛
• أنظمة الويب الموزعة.

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

النموذج المفاهيمي UML

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

كتل بناء UML

تتضمن مفردات UML ثلاثة أنواع من اللبنات الأساسية:

• الجواهر.
• علاقة؛
• الرسوم البيانية.

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

هناك أربعة أنواع من الكيانات في UML:

• الهيكلي؛
• سلوكية؛
• التجمع؛
• تعليق توضيحي.

الكيانات هي الكتل الأساسية الموجهة للكائنات في اللغة. بمساعدتهم، يمكنك إنشاء النماذج الصحيحة. هناك سبعة أنواع من الكيانات الهيكلية:

• فصل
• واجهه المستخدم
• تعاون
• حالة الاستخدام
• فئة نشطة
• عنصر
• العقدة

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

الأشياء السلوكية هي المكونات الديناميكية لنموذج UML. هذه هي أفعال اللغة: وهي تصف سلوك النموذج في الزمان والمكان. هناك نوعان رئيسيان فقط من الكيانات السلوكية:

• تفاعل
• آلة الدولة

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

كيانات التجميع هي الأجزاء التنظيمية لنموذج UML. هذه هي الكتل التي يمكن تقسيم النموذج إليها. لا يوجد سوى كيان تجميع أساسي واحد، وهو حقيبة بلاستيكية.

الحزم هي كيانات التجميع الأساسية التي يمكن استخدامها لتنظيم نموذج UML. وهناك أيضًا اختلافات في الحزم، مثل الأطر والنماذج والأنظمة الفرعية.

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

يحدد UML أربعة أنواع من العلاقات:

• مدمن؛
• منظمة؛
• تعميم؛
• تطبيق.

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

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

• الرسوم البيانية الطبقة.
• المخططات الكائنية؛
• استخدام الرسوم البيانية الحالة؛
• مخططات التسلسل؛
• مخططات التعاون؛
• مخططات الحالة
• مخططات النشاط؛
• المخططات المكونة؛
• مخططات النشر.

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

قواعد لغة UML

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

تحتوي لغة UML على قواعد دلالية تسمح لك بتعريف ما يلي بشكل صحيح لا لبس فيه:

• أسماءوالتي يمكن إعطاؤها للكيانات والعلاقات والرسوم البيانية؛
• نِطَاق(السياق الذي يكون للاسم فيه بعض المعنى)؛
• الرؤية(عندما تكون الأسماء مرئية ويمكن استخدامها بواسطة عناصر أخرى)؛
• نزاهة(كيف يجب أن ترتبط العناصر ببعضها البعض بشكل صحيح ومتسق)؛
• أداء(مما يعني تنفيذ أو محاكاة بعض النماذج الديناميكية).

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

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

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

آليات UML العامة

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

• المواصفات (المواصفات)؛
• الإضافات (الزينة)؛
• الانقسامات المشتركة
• آليات التوسعة.

بنيان

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

العمارة هي مجموعة من القرارات الهامة المتعلقة بما يلي:

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

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

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

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

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

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

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

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