مخططات مادية Physical Diagrams

هناك نوعان من المخططات المادية "physical diagrams" : مخططات  النشر "deployment diagrams" و مخططات المركب "Component diagrams". مخططات  النشر "deployment diagrams" تقوم بإظهار العلاقة المادية بين الأجهزة "hardware" والبرامج "software" في النظام. مخططات المركب "Component diagrams" تقوم بإظهار مكونات البرامج "software components" للنظام ، وكيفية ترابط بعضها مع البعض. هذه العلاقات تسمى التبعيات "dependencies".

متى تستخدم مخططات مادية Physical Diagrams

وتستخدم مخططات مادية "Physical Diagrams" عند الانتهاء من تطوير النظام. وتستخدم أيضا لاعطاء تفاصيل عن المعلومات المادية عن هذا النظام.

كيفية رسم مخططات مادية Physical Diagrams

وفي كثير من الأحيان يتم الجمع بين مخططات النشر "deployment diagrams" و مخططات المركب "Component diagrams" في مخطط مادي واحد "physical diagram". و هذا الجمع بين المخططات ينتج عنه جمع بين ميزات هذه المخططات في مخطط واحد.

و تتضمن مخططات النشر "deployment diagrams" العقد "nodes" والاتصالات "connections". العقدة "node" وعادة ما تمثل قطعة من الأجهزة "hardware " في النظام. الاتصالات "connection" تصور مسار الاتصال المستخدم من قبل الجهاز "hardware" للاتصال وعادة ما يدل على وسيلة مثل حزمة بروتوكولات الإنترنت  TCP/IP.

تحتوي مخططات المركب "Component diagrams" على مركبات  "components" والتبعيات "dependencies". تمثل مركبات "components" الحزمة المادية للوحدة "module" من التعليمات البرمجية. و تبين التبعيات "dependencies" بين المركبات "component" كيف تقوم التغييرات التي أدخلت على مركب "component" واحد بالتاثير على المركبات الأخرى في النظام. يتم تمثيل التبعيات "dependencies" في مخططات المركب "Component diagrams" بخط متقطع بين مركبين أو أكثر. مخططات المركب "Component diagrams" يمكن أن تُظهر أيضا الواجهات التي تستخدمها المركبات للتواصل مع بعضها البعض.

مخططات  النشر "deployment diagrams" و مخططات المركب "Component diagrams" المرسومة أدناه تعطي مستوى عال للوصف المادي لكامل النظام. ويبين الرسم عقدتين "nodes" اللاتان تمثلان الاتصال بين الآلات من خلال حزمة بروتوكولات الإنترنت  TCP/IP. المركب رقم 2 "Component 2" يعتمد على المركب رقم 1 "component 1" ، بحيث ان التغيرات التي تطبق على المركب رقم 2 "Component 2" تؤثر على المركب رقم 1 "Component 1". الرسم يصور أيضا التواصل بين المركب رقم 3 "component 3" مع المركب رقم 1 "component 1". هذا الرسم التخطيطي يعطي للقارئ نظرة سريعة و شاملة للنظام بأكمله.

مخططات النشاط Activity Diagrams

مخططات النشاط "Activity diagrams" تصف سلوك سير العمل للنظام. مخططات النشاط مماثلة لمخططات الحالة "state diagrams" لأن الأنشطة "activities" تمثل حالة القيام بشيء. المخططات تصف حالة الأنشطة من خلال إظهار تسلسل الأنشطة التي تم القيام بها. مخططات النشاط "Activity diagrams" يمكن أن تُظهر الأنشطة المشروطة "conditional" أو المتوازية "parallel".

متى تستخدم مخططات النشاط Activity Diagrams

مخططات النشاط "Activity diagrams" ينبغي أن تستخدم بالتعاون مع تقنيات النمذجة الأخرى مثل مخططات التفاعل "interaction diagrams" ومخططات الحالة   "state diagrams". والسبب الرئيسي لاستخدام مخططات النشاط "Activity diagrams" هو نموذج سير العمل داخل النظام الذي يجري تصميمه. مخططات النشاط "Activity diagrams" مفيدة أيضا بالنسبة إلى : تحليل حالة الاستخدام"use case" عن طريق وصف ماهي الإجراءات "actions" التي نحتاج إلى إجراءها و متى ينبغي أن تحدث ، وصف خوارزمية معقدة متسلسلة و تطبيقات النمذجة مع العمليات المتوازية "parallel processes"

ومع ذلك ، فإن مخططات النشاط "Activity diagrams" لا تحل محل مخططات التفاعل "interaction diagrams" ومخططات الحالة   "state diagrams". مخططات النشاط "Activity diagrams" لا تعطي تفاصيل حول كيفية تصرف  الكائنات "objects" أو كيف تعاونها.

كيفية رسم مخططات النشاط Activity Diagrams

تُظهر لنا مخططات النشاط "Activity diagrams" تدفق  الأنشطة من خلال النظام. تتم قراءة المخططات من الأعلى إلى الأسفل ، ولها فروع "branches" و شوكات "forks" لوصف الظروف "conditions" والأنشطة الموازية "parallel activities". و تستخدم  الشوكة "fork" عندما تحدث أنشطة متعددة في نفس الوقت. ويبين الرسم البياني أدناه الشوكة "fork" بعد النشاط 1 "activity 1".

هذا يشير إلى أن كل من النشاط عدد 2 "activity 2" و النشاط عدد 3 "activity 3" يتم حدوث في نفس الوقت. بعد النشاط عدد 2 يوجد تفرع "branch". التفرع يصف ما هي الأنشطة التي ستُجرى على أساس مجموعة من الشروط. و تنتهي كل الفروع في بعض النقاط بالدمج "merge" ليشير إلى نهاية السلوك المشروط الذي ابتدأ في هذا الفرع. ويجب بعد دمج جميع الأنشطة المتوازية ضمها بربط "join" قبل الانتقال إلى حالة النشاط النهائي.

وفيما يلي مخطط النشاط "Activity diagram"  اللازم لمعالجة الطلب "order". ويبين المخطط  تدفق الإجراءات "actions" عند سير عمل النظام. بمجرد استلام الطلب "receive order" تنقسم الأنشطة إلى مجموعتين من الأنشطة المتوازية. احد الجوانب  يملأ ويرسل "fills and sends" في حين أن الآخر يعالج الفواتير. على جانب الملأ والارسال "fills and sends" أسلوب التسليم يكون بشروط. اعتمادا على الشروط سيقوم النظام بالنشاط المسمى بالتسليم الليلي "Overnight Delivery" او نشاط التسليم العادي "Regular Delivery". و في النهاية سيتم الجمع بين الأنشطة المتوازية لإغلاق النظام.

مخططات الحالة State Diagrams

وتستخدم مخططات الحالة "State Diagrams" لوصف سلوك النظام.مخططات الحالة State Diagrams تصف كل من الحالة المحتملة للكائن "object" عند حدوث الحالة. كل رسم بياني يمثل عادة كائنات "objects" لفئة واحدة وتتبع الحالات المختلفة للكائنات من خلال النظام.

متى تستخدم مخططات الحالة State Diagrams

تستخدم مخططات الحالة "State Diagrams" لوصف سلوك الكائن "object" من خلال استخدام العديد من حالات الاستخدام "use cases" للنظام. تستخدم مخططات الحالة "State Diagrams" فقط للفئات "classes" عندما يكون من الضروري فهم سلوك الكائن "object" من خلال النظام بأكمله. ليست كل الفئات "classes" تحتاج إلى مخططات الحالة "State Diagrams" و مخططات الحالة ليست مفيدة لوصف التعاون لجميع الكائنات في حالة الاستخدام. مخططات الحالة "State Diagrams" هي الأخرى مجتمعة مع غيرها من المخططات مثل مخططات التفاعل “Interaction Diagrams” و  مخططات الانشطة “activity Diagrams”.

كيفية رسم مخططات الحالة State Diagrams

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

جميع مخططات الحالة "state diagrams" تبدأ مع الحالة المبدئية "initial state" للكائن. هذه هي حالة الكائن عندما يتم إنشاؤه. بعد الحالة المبدئية يبدأ الكائن  بتغيير الحالات. الشروط "Conditions" تعتمد على الأنشطة لتحديد الحالة القادمة التي سيتحول لها الكائن.

وفيما يلي مثال على رسم تخطيطي للحالة قد تبدو وكأنها لكائن الطلب "Order object". عندما يدخل الكائن "object" الى حالةالفحص "Checking" سيُنفذ النشاط افحص العنصر "check items". بعد الانتهاء النشاط الكائن يتحول الى الحالة الموالية بالاعتماد على الشرط: كل العناصر متوفرة "all items available" او الشرط : عنصر غير متوفر "an item is not available". إذا كان الشرط هو عنصر غير متوفر سيتم إلغاء الأمر "canceled". إذا كانت جميع العناصر متاحة سيتم إرسال الطلب "dispatching". عندما ينتقل الكائن الى الحالة: إيفاد "Dispatching" فان النشاط المسمى: الشروع في التسليم "initiate delivery" سيتم تنفيذه. بعد هذا النشاط سيكمل الكائن "object" الانتقال مرة أخرى إلى الحالة: سلمت "Delivered".

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

ويبين الرسم البياني أدناه الحالة الممتاز "super-state". كل من حالة التدقيق "Checking" و حالة الإيفاد "Dispatching" يمكن ان يمروا بالحالة إلغاء "Canceled" ، لذلك يظهر الانتقال من الحالة الممتاز "super-state" المسمات بنشط "Active" إلى الحالة المسمات إلغاء "Cancel". على النقيض من ذلك ، فإن الحالة إيفاد "Dispatching" يمكنها فقط الانتقال إلى الحالة المسلمة 

"Delivered" ، لهذا نظهر سهم فقط من الحالة إيفاد "Dispatching"  الى الحالة سلمت "Delivered".

مخططات التفاعل Interaction Diagrams

نموذج مخططات التفاعل "Interaction Diagrams" هو سلوك حالات الاستخدام "use cases" مع وصف طريقة تفاعل مجموعات من الكائنات "objects" لإكمال المهمة. يوجد نوعين من مخططات التفاعل وهم مخططات التسلسل "sequence diagrams" و مخططات التعاون "collaboration diagrams". ويهدف هذا المثال فقط الى اعطاء مقدمة للغة النمذجة الموحدة “Unified Modeling Language — UML” و  مخططات التفاعل "Interaction Diagrams".

متى تستخدم مخططات التفاعل Interaction Diagrams

وتستخدم مخططات التفاعل "Interaction Diagrams"  عندما تريد وضع نموذج لسلوك كائنات متعددة "several objects" في حالة استخدامها "use case". وهي تبين كيف يمكن للكائنات "objects" ان تتعاون لتحقيق سلوك معين.  مخططات التفاعل "Interaction Diagrams" لا يمكنها ان تعطي وصف عميق للسلوك. إذا كنت تريد أن ترى ما تقوم به كائنات معينة للعديد من حالات الاستخدام فعليك باستخدام مخطط الحالة "state diagram".

كيفية رسم مخططات التفاعل Interaction Diagrams

مخططات تسلسل "sequence diagrams" و مخططات التعاون "collaboration diagrams" يمكن استخدامهما على حد سواء لوصف التفاعل بين الكائنات  "objects" في حالة استخدامهم "use case". مخططات التسلسل "sequence diagrams" يظهرون بشكل عام تسلسل الأحداث التي تحدث. مخططات التعاون "collaboration diagrams" تصف كيفية ترابط الكائنات بشكل ثابت. كل من المخططات بسيطة نسبيا للاستخلاص وتحتوي على عناصر مماثلة.

مخططات تسلسل sequence diagrams

مخططات التسلسل "Sequence diagrams" تشرح سلوك الكائنات "objects" في حالة استخدامها "use case" مع وصف الكائنات "objects" والرسائل المُمررة بينهم. تتم قراءة المخططات من اليسار إلى اليمين وتنازليا. يوضح المثال التالي كائن الفئة "object of class" يبداء سلوكه عن طريق إرسال رسالة إلى كائن الفئة الاخر. تُمرر الرسائل بين الكائنات المختلفة الى ان يتلقى كائن الفئة 

"object of class" الرسالة النهائية.

أدناه هو مثال أكثر تعقيدا. تمثل المستطيلات العمودية الزرقاء المضيئة نشاط الكائنات "objects"  بينما تمثل الخطوط المتقطعة الخضراء العمودية حياة الكائن " the life of the object". المستطيلات الخضراء العمودية تمثل متى يتحصل كائن معين على السيطرة. و يمثيل هدا المربع   عملية  إتلاف الكائن. كما تبين هذه المخططات حالات الرسائل التي يتم إرسالها إلى كائن آخر. يتم سرد الحالة "[condition]" بين معقفين [] بجانب الرسالة. على سبيل المثال  الحالة "[condition]" لابد ان يتم تغطيتها قبل ان يقوم كائن الفئة 2 "object:class2" من إرسال الرسالة "message()" لكائن الفئة 3 "object:class3".

المخطط التالي يبين بداية مخطط التسلسل "Sequence diagram"  لوضع الأمر. الكائن an Order Entry Window يقوم بإنشاء و إرسال رسالة إلى an Order لإعداد الامر. نلاحظ ان أسماء الكائنات "objects" تليها نقطتان فوق بعضهما. أسماء الفئات "classes" التي تنتمي إليها الكائنات "objects" لا يجب أن يتم سردها. لكن النقطتان مطلوب وجودهما للدلالة على أنه يوجد اسم يتبع هذا الكائن objectName:className نظام التسمية.

بعد ما يتحقق الكائن  Order من معرفة ما اذا كان هذا البند هو في التخزين و إذا كان تحقق من وجود الشرط  [InStock] فسيقوم بإرسال رسالة ليتم خلق تسليم جديد لهذا البند.

المخططات التالية تضيف رسالة مشروطة اخرى إلى كائن الأمر "Order object". إذا كان هذا البند هو [OutOfStock] يرسل رسالة إلى الكائن Order Entry Window تفيد أن الكائن "object" اصبح خارج التخزين.

هذا الرسم البياني يبين تسلسل بسيط للرسائل التي يتم تمريرها بين الكائنات لإكمال حالة الاستخدام لطلب عنصر.

مخططات التعاون "collaboration diagrams"

مخططات التعاون "Collaboration diagrams" هي أيضا من السهل نسبيا رسمها. انها تشير الى العلاقة بين الكائنات "objects" وترتيب تمرير الرسائل بينها. يتم سرد الكائنات كرموز و أسهم تبين عملية تمرير الرسائل بينها. الأرقام بجانب الرسائل تسمى أرقام التسلسل "sequence numbers". وكما يوحي اسمها ، انها تشير الى تسلسل الرسائل حسب عملية تمريرها في ما بين الكائنات "objects". هناك العديد من ترقيمات التسلسل المقبولة في مخططات لغة النمذجة الموحدة "UML" . شكل الارقام البسيطة 1 ، 2 ، 3... ويمكن استخدام الشكل ، كما في المثال أدناه ، أو في المخططات الأكثر تفصيلا وتعقيدا: 1, 1.1 ,1.2, 1.2.1...

المثال التالي يوضح مخطط تعاون "collaboration diagram" بسيط من أجل وضع حالة استخدام امر "order use case". هذه المرة أسماء الكائنات "objects" تظهر بعد النقطتين ، مثل :Order Entry Window عوضا عن التسمية التقليدية objectName:className .هذه المرة يظهر اسم الفئة لإثبات أن كل الكائنات لتلك الفئة سوف تتصرف بنفس الطريقة.

إذا كنت ترى خطأ أو لديك أسئلة لا تتردد في وضع تعليق

مخطط الفئة Class Diagram

مخطط الفئة "Class Diagram" يستخدم على نطاق واسع لوصف أنواع الكائنات "objects" الموجودة في النظام و علاقاتها ببعضها. نموذج مخطط الفئة "Class diagrams model" ، هيكل الفئات "class structure" و المحتويات "contents" يستخدمون عناصر التصميم مثل الفئات "classes"، والحزم "packages" والكائنات "objects". مخططات الفئة "Class diagrams" يصف لنا ثلاثة منظورات مختلفة عند تصميم النظام و هم: منظور المفاهيمي "conceptual" ، و منظور المواصفات "specification"، و منظور التطبيق "implementation". هذه المنظورات تصبح واضحة عندما يتم إنشاء المخطط و تساعد بقدر كبير في عملية التصميم. ويهدف هذا المثال الى وضع تقديم للغة النمذجة الموحدة “Unified Modeling Language — UML” و مخططات الفئة "Class diagrams".

وتتألف الفئات من ثلاثة أشياء : اسم "name" والصفات "attributes"، والعمليات "operations". هذا مثال على الفئة "class" أدناه.

مخططات الفئة "Class diagrams" أيضا تقوم بعرض العلاقات مثل الاحتواء "containment" ، و الوراثة "inheritance"، و التجميع  "associations" و اشياء اخرى ،  هذا مثال على وجود علاقة ترابطية "associative relationship" :

وعلاقة الارتباط "association relationship" هي العلاقة الأكثر شيوعا في مخطط الفئة "Class Diagram" . الارتباط "association" يوضح العلاقة بين نماذج الفئات "instances of classes". على سبيل المثال ، فئة الطلب "class Order" ترتبط مع فئة العملاء "class Customer". تعدد الارتباطات "multiplicity of the association" يدل على عدد من الكائنات "objects" التي يمكن أن تشارك في العلاقة. على سبيل المثال ، يمكن أن يرتبط كائن الطلب "Order object" بعميل واحد فقط ، ولكن يمكن أن يرتبط  عميل واحد  بطلبات كثيرة.

علاقة أخرى مشتركة في مخططات الفئة "class diagrams" و هي التعميم "generalization". ويستخدم التعميم عندما يكون لدين فئتين متشابهتين ، ولكن توجد بعض الاختلافات. انظروا إلى التعميم "generalization" التالي :

في هذا المثال الفئة الشركة العميلة "Corporate Customer" و فئة العميل الفردي "Personal Customer" لديهم بعض التشابه مثل الاسم والعنوان ، ولكن كل فئة لديها بعض من الصفات "attributes" الخاصة بها والعمليات "operations". فئة العميل "class Customer" هو شكل عام لفئة العملاء على حد السواء  الشركة العميلة "Corporate Customer" والعميل الفردي "Personal Customer" .وهذا ما يسمح للمصممين بمجرد استخدام لفئة العملاء "Customer class" ولا يحتاجون إلى عرض لكل نوع من أنواع العملاء.

متى يكون استخدام : مخطط الفئة "Class Diagram"

وتستخدم مخططات الفئة "Class diagrams" تقريبا في جميع تصاميم برامج كائنية التوجه "Object Oriented software". و تستخدم لوصف فئات النظام "Classes of the system" وعلاقاتهم مع بعضهم البعض.

كيفية رسم : مخططات الفئة "Class Diagrams"

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

قبل رسم مخطط الفئة “Class Diagram“ يجب ان تاخذ بعين الاعتبار وجهات النظر الثلاثة المختلفة للنظام التى سيقدمها المخطط ؛منظور المفاهيمي "conceptual" ، و منظور المواصفات "specification"، و منظور التطبيق "implementation". حاول عدم التركيز على منظور واحد ، ومحاولة معرفة كيفية عملهم جميعا مع بعضهم البعض.

عند تصميم الفئات  خذ بعين الاعتبار ما هم الصفات "attributes" والعمليات "operations" التي لديهم. ثم حاول تحديد حالات الفئات "instances of the classe" التي سوف تتفاعل مع بعضها البعض. هذه هي الخطوات الأولى لكثير من الخطوات ستكوّن مخطط الفئة "class diagram". ومع ذلك ، فقط باستخدام هذه التقنيات الأساسية يمكن لأي احد أن يضع رؤية شاملة لمنظومة البرمجيات "software system".

ويهدف هذا المثال فقط الى تقديم لغة النمذجة الموحدة "UML" وحالات الاستخدام "use cases".

مخططات حالة الاستخدام Use Case Diagram

حالة الاستخدام "use case" هي عبارة عن مجموعة من السيناريوهات التي تصف التفاعل بين المستخدم والنظام. يعرض مخطط حالة الاستخدام “Use Case Diagram“ العلاقة بين الجهات الفاعلة “actors” وحالات الاستخدام”use cases”. المكونان الرئيسيان  لمخطط حالة الاستخدام “Use Case Diagram“ هما حالات استخدام "use cases" والجهات الفاعلة "actors".

الجهة الفاعل "actor" تمثل المستخدم أو نظام آخر الذي سيتفاعل مع النظام الذي قمت بنمذجته. حالة استخدام "use case" عبارة عن رؤية خارجية للنظام بحيث تستعرض بعض الإجراءات التي يمكن ان يقوم بها المستخدم لإكمال المهمة.

متى تستخدم : مخططات حالات الاستخدام “Use Cases Diagrams“

وتستخدم حالات الاستخدام "Use cases" في كل المشاريع تقريبا. وتساعد في الكشف عن الاحتياجات والتخطيط للمشروع. وينبغي خلال المرحلة الأولى من المشروع التعريف بمعظم حالات الاستخدام ، ولكن ، بما ان المشروع لا يزال متواصل فسيظهر لك المزيد.

كيفية رسم : مخططات حالات الاستخدام “Use Cases Diagrams“

حالات الاستخدام "Use cases" هو مخطط للغة النمذجة الموحدة “Unified Modeling Language — UML” سهل الرسم نسبيا ، هذا مثال مبسط للغاية. ويهدف هذا المثال فقط الى تقديم حالات الاستخدام "Use cases" و لغة النمذجة الموحدة “Unified Modeling Language — UML”:

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

• تصفح الكتالوج "catalog" واختيار العناصر.


• استدعاء مندوب المبيعات.


• عرض معلومات الشحن.


• عرض معلومات الدفع.


• تلقي رقم الموافقة "conformation number"  من مندوب المبيعات.

هذه الخطوات ستولد مخطط حالة استخدام "use case diagram" البسيط هذا:

هذا المثال يظهر الزبون كجهة فاعلة "actor" لأن الزبون هو الذي يستخدم نظام وضع الطلبات "ordering system". المخطط يأخذ الخطوات البسيطة المذكورة أعلاه ، و يظهرها على اساس إجراءات يمكن للعميل او الزبون ان ينفذها. ويمكن أيضا أن يدرج مندوب مبيعات في مخطط حالة الاستخدام “Use Case Diagram“ هذا لأن البائع  أيضا يتفاعل مع نظام وضع الطلبات"ordering system".

من هذا المخطط البسيط لنضام وضع الطلبات "ordering system" يمكن بسهولة ان نشتق المتطلبات.

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

أنواع مخططات لغة النمذجة الموحدة Unified Modeling Language Diagrams — UML

كل مخطط  للغة النمذجة الموحد تم تصميمه بطريقة  تسمح للمطورين والعملاء عرض أنظمة البرامج من وجهات نظر مختلفة وبدرجات متفاوتة من التجريد. مخططات لغة النمذجة الموحدة "UML diagrams" عادة ما تخلق بأدوات النمذجة البصرية منها ما يلي :

مخطط حالة الاستخدام "Use Case Diagram" يعرض العلاقة بين الجهات الفاعلة "actors" وحالات الاستخدام"use cases".

مخطط الفئة "Class Diagram" : نماذج هيكل الفئة "class structure" ومحتوياتها تستخدم عناصر التصميم مثل الفئات "classes"، والحزم والكائنات "objects". ويعرض أيضا علاقات مثل الاحتواء "containment" ، التوريث "inheritance" ، و التجميع "associations" وغيرها.

مخطط التفاعل "Interaction Diagrams"

• مخطط التسلسل "Sequence Diagram" يعرض التسلسل الزمني للكائنات "objects" المشاركة في التفاعل "interaction". و هذا يتألف من البعد العمودي "الوقت" والبعد الأفقي "الكائنات المختلفة -- different objects".


• مخطط التعاون "Collaboration Diagram" يعرض التفاعل المنظم حول الكائنات "objects" وعلاقاتها مع بعضها البعض. تستخدم الأرقام لإظهار  تسلسل الرسائل.

مخطط الحالة "State Diagram" يعرض تسلسل الحالات التي يمر من خلالها كائن التفاعل "object of an interaction" في حياته في عملية الاستجابة لمحفزات وردت سابقا ، جنبا إلى جنب مع ردودها والإجراءات.

مخطط النشاطات "Activity Diagram" يعرض المخططات المميزة لمخطط الحالة "state diagram" ، بحيث ان معظم الحالات  هي حالات العمل "action states" ومعظم الانتقالات يتم تشغيلها بواسطة انهاء الإجراءات في مصدر الحالات. هذا المخطط يركز على التدفقات المدفوعة من المعالجات الداخلية "internal processing".

المخططات المادية "Physical Diagrams"

• مخطط المركب "Component Diagram" يعرض المستوى المرتفع لهيكل حزمة الشفرة نفسها " packaged structure of the code". بالاعتماد على المركبات "components" التي ظهرت ، بما في ذلك مركبات شفرة المصدر "source code components" والمكونات البرمجية الثنائية "binary code components" ، والمكونات القابلة للتنفيذ "executable components".


• تخطيط النشر "Deployment Diagram" يعرض التكوين "configuration" لعناصر التجهيز وقت التشغيل "run-time processing" ومكونات البرامج "software components" ، والعمليات "processes"، والكائنات "objects" التي تعمل فيها. حالات مكونات البرامج "Software component instances" تقدم مظاهر وقت التشغيل لوحدات التعليمات البرمجية "code units".

ما هي لغة النمذجة الموحدة Unified Modeling Language؟

لغة النمذجة الموحدة "Unified Modeling Language -- UML" هي لغة قياسية لتحديد ، تصور ، بناء ، وتوثيق الأعمال لبرمجيات الأنظمة ، فضلا عن نماذج الأعمال التجارية وغيرها من النظم المختلفة عن البرمجيات. لغة النمذجة الموحدة تمثل مجموعة من أفضل التطبيقات الهندسية التي ثبت نجاحها في نمذجة النظم الضخمة والمعقدة. و لغة النمذجة الموحدة  "UML" هي جزء هام لتطوير البرمجة الكائنية التوجه "object oriented software" و عملية تطوير البرمجيات "software development". لغة النمذجة الموحدة تستخدم الرموز الرسومية في الغالب للتعبير عن طريقة  تصميم مشاريع البرامج. يساعد فريق العمل في المشروع الذي يستخدم لغة النمذجة الموحدة في التواصل ، استكشاف إمكانات التصاميم ، والتحقق من صحة التصميم الهندسي للبرنامج.

أهداف لغة النمذجة الموحدة UML

الأهداف الرئيسية للغة النمذجة الموحدة هي :

1. تزويد المستخدمين بلغة نمذجة بصرية تعبيرية جاهزة للاستعمال بحيث يتمكنون من تطوير وتبادل النماذج التعبيرية.


2. توفر قابلية التمدد وآليات التخصيص ، لتوسيع المفاهيم الأساسية للمشروع.


3. تكون مستقل عن لغات البرمجة الخاصة وعمليات التطوير.


4. توفير مناهج أو القواعد أساسية لفهم لغة النمذجة "modeling language".


5. تشجيع نمو كائنية توجه أدوات السوق "object-oriented tools market".


6. دعم أعلى مستوى تطوير المفاهيم "development concepts" مثل التعاون "collaborations"، و منصات العمل "frameworks"، و القوالب "patterns" و المركبات "components".


7. دمج أفضل الممارسات.

لماذا تستخدم لغة النمذجة الموحدة UML

و بناءا على استراتيجية  زيادة اهمية البرامج للعديد من الشركات ، فمجال الصناعة سعى  بالبحث عن تقنيات لجعل إنتاج البرمجيات أوتوماتيكي، مع تحسين النوعية والضغط على التكلفة والوقت لزيدة القدرة التنافسية في السوق. وتشمل هذه التقنيات تقنية المركبات "component technology"، والبرمجة المرئية "visual programming"، و القوالب "patterns" ومنصات العمل  "frameworks". الشركات تسعى أيضا إلى تقنيات لإدارة تعقيدات الأنظمة لأنها في زيادة من حيث الحجم و المدى. وعلى وجه الخصوص ، فهي تعترف بالحاجة إلى حل المشاكل الهندسية المتكررة ، مثل التوزيع المادي "physical distribution"، التزامن "concurrency"،  التكرار "replication"،  الأمن ، الموازنة "load balancing" و الاحتمال الخطأ "fault tolerance". بالإضافة إلى ذلك ، قد أدى تطور شبكة الويب العالمية ، مما جعل بعض الأمور أكثر بساطة ، في زيادت المشاكل الهندسية. وقد تم تصميم لغة النمذجة الموحدة "UML" للاستجابة لهذه الاحتياجات.

ما هي هندسة البرمجيات software engineering؟

في الواقع انه من الصعب جدا تحديد معنى هندسة البرمجيات "software engineering". فهي تستخدم كل من الهندسة والعلوم في محاولة لإدخال تحسينات في مجال تكنولوجيا البرمجيات "software technology". مختلف الناس لديهم تعريفات مختلفة لمصطلح هندسة البرمجيات اعتمادا على الميادين التي يعملون فيها.

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

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

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

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