التحليل: النمذجة المنطقية للعمليات (الجزء الثاني)
يغطي هذا الوحدة حالات الاستخدام، مخططات الأنشطة، ونمذجة إجراءات العمل (BPMN) لتمثيل وظائف النظام ومنطقه.
Analysis: Logical Modeling of Processes (Part-2)
This module covers Use Cases, Activity Diagrams, and Business Process Modeling (BPMN) to represent system functionality and logic.
أهداف التعلم
- شرح حالات الاستخدام ومخططاتها وكيفية استخدامها لنمذجة وظائف النظام.
- توضيح مخططات الأنشطة لتمثيل منطق النظام.
- شرح كيفية تمثيل إجراءات العمل باستخدام مخططات إجراءات العمل (BPMN).
- Explain use cases and use case diagrams and how they can be used to model system functionality.
- Demonstrate activity diagrams for system logic.
- Explain how to represent business processes with business process diagrams.
1 حالات الاستخدام والممثلون
1 Use Cases and Actors
حالة الاستخدام تصف ما يفعله النظام، والممثل هو من يتفاعل معه؛ تماماً كالنص المسرحي والممثلين.
A Use Case describes what the system does, and an actor is who interacts with it; just like a script and actors in a play.
تُظهر حالة الاستخدام (Use Case) سلوك النظام أو وظائفه في ظل ظروف مختلفة استجابةً لطلبات المستخدمين. تُصاغ عادةً كعبارة فعلية في الزمن المضارع (مثل: إدخال بيانات المبيعات).
يتكون نموذج حالة الاستخدام من الممثلين (Actors) وحالات الاستخدام. الممثل هو كيان خارجي يتفاعل مع النظام، ويُمثل دوراً وليس فرداً بعينه (يمكن لفرد واحد أن يلعب أدواراً متعددة).
يتم تمثيل حدود النظام بمربع يضم جميع حالات الاستخدام، بينما يبقى الممثلون خارج هذه الحدود.
A Use Case shows the behavior or functionality of a system under various conditions as it responds to user requests. It is stated as a present-tense verb phrase (e.g., Enter Sales Data).
A use case model consists of Actors and use cases. An actor is an external entity that interacts with the system, representing a role, not an individual (one individual may play many roles).
The system boundary is represented as a box including all relevant use cases, with actors placed outside.
تُعد نمذجة حالات الاستخدام عملية تكرارية تتطلب تعاوناً مستمراً بين المحللين والمستخدمين.
تساعد الأسئلة الموجهة (مثل: ما هي المهام الرئيسية لكل ممثل؟ هل سيقرأ أو يُحدث معلومات؟) في تحديد حالات الاستخدام بدقة.
على الرغم من ارتباطها بالتصميم الموجه للكائنات (OOAD)، إلا أنها تُستخدم أيضاً في المناهج التقليدية كبديل أو مكمل لمخططات تدفق البيانات (DFDs).
Use case modeling is an iterative process requiring continuous collaboration between analysts and users.
Guiding questions (e.g., What are the main tasks performed by each actor? Will they read or update info?) help identify use cases accurately.
Although associated with Object-Oriented Analysis and Design (OOAD), it can also be used within traditional approaches as an alternative or complement to Data Flow Diagrams (DFDs).
لماذا نعتبر الممثل (Actor) دوراً وليس فرداً محدداً؟ Why is an Actor considered a role rather than a specific individual?
لأن النظام يهتم بنوع التفاعل والصلاحيات المرتبطة بالدور. يمكن لشخص واحد (مثل 'أحمد') أن يكون 'طالباً' و'موظف تسجيل' في نفس الوقت، وكل دور يتفاعل مع النظام بطريقة مختلفة.
Because the system cares about the type of interaction and permissions associated with the role. One person (e.g., 'Ahmed') can be both a 'Student' and a 'Registration Clerk', interacting with the system differently in each role.
2 علاقات حالات الاستخدام: الامتداد والتضمين
2 Use Case Relationships: Extend and Include
التضمين (Include) هو خطوة إجبارية متكررة، بينما الامتداد (Extend) هو خطوة اختيارية أو استثنائية.
Include is a mandatory, reusable step, while Extend is an optional or exceptional step.
ترتبط حالات الاستخدام ببعضها البعض باستخدام الأسهم لتمثيل علاقات معينة:
- علاقة الامتداد (Extend): ارتباط يضيف سلوكيات أو إجراءات جديدة لحالة استخدام أخرى. يُشار إليها بسهم منقط يتجه نحو حالة الاستخدام التي تم تمديدها (الأصلية)، مع علامة
<<extend>>. - علاقة التضمين (Include): ارتباط تستخدم فيه حالة استخدام وظائف موجودة في حالة استخدام أخرى (إعادة استخدام). يُشار إليها بسهم منقط يتجه نحو حالة الاستخدام المُستخدَمة (المُضمَّنة)، مع علامة
<<include>>.
Use cases are connected to each other with arrows to represent specific relationships:
- Extend Relationship: An association where one use case adds new behaviors or actions to another. Shown as a dotted-line arrow pointing toward the use case that has been extended (the base), labeled with
<<extend>>. - Include Relationship: An association where one use case uses the functionality contained in another (reuse). Shown as a dotted-line arrow pointing toward the use case that is being used (the included one), labeled with
<<include>>.
يُستخدم التضمين (Include) لتقليل التكرار؛ فإذا كانت عدة حالات استخدام تتطلب 'التحقق من الهوية'، يتم فصلها كحالة استخدام مضمنة.
أما الامتداد (Extend) فيُستخدم لمعالجة الحالات الاستثنائية أو الخيارات الإضافية التي لا تحدث دائماً، مما يحافظ على بساطة حالة الاستخدام الأساسية.
Include is used to reduce redundancy; if multiple use cases require 'User Authentication', it is factored out into an included use case.
Extend is used to handle exceptions or optional features that don't always occur, keeping the base use case simple and focused on the main success scenario.
| Extend Relationship | Include Relationship | |
|---|---|---|
| الغرض الأساسيPrimary Purpose | إضافة سلوكيات استثنائية أو اختياريةAdd exceptional or optional behaviors | إعادة استخدام وظائف مشتركةReuse common functionality |
| اتجاه السهمArrow Direction | يشير نحو حالة الاستخدام الأساسية (المُمدَّدة)Points toward the base (extended) use case | يشير نحو حالة الاستخدام الفرعية (المُضمَّنة)Points toward the sub (included) use case |
| الإلزاميةMandatory Execution | اختياري (يحدث تحت شروط معينة)Optional (happens under certain conditions) | إلزامي (جزء لا يتجزأ من التدفق)Mandatory (integral part of the flow) |
في أي اتجاه يشير السهم في علاقة الامتداد (Extend) ولماذا؟ In which direction does the arrow point in an Extend relationship and why?
يشير السهم من حالة الاستخدام الممتدة (الفرعية) إلى حالة الاستخدام الأساسية. لأن الحالة الأساسية مكتملة بحد ذاتها ولا تعتمد على الامتداد، بينما الامتداد يعتمد على الأساسية ليضيف إليها.
The arrow points from the extending (child) use case TO the base use case. This is because the base use case is complete on its own and doesn't know about the extension, while the extension depends on the base to add behavior.
3 حالات الاستخدام المكتوبة (قالب Cockburn)
3 Written Use Cases (Cockburn Template)
المخططات لا تكفي؛ نحتاج إلى نص مكتوب يفصل الشروط المسبقة، الضمانات، والسيناريوهات.
Diagrams aren't enough; we need written text detailing preconditions, guarantees, and scenarios.
أسماء حالات الاستخدام في المخطط لا توفر معلومات كافية للتحليل والتصميم. لذلك، تُكتب محتويات حالة الاستخدام بنص بسيط. يوصي Cockburn (2001) بقالب محدد يتضمن:
- المستوى (Level): منظور الوصف (من عالي المستوى إلى مفصل جداً).
- أصحاب المصلحة (Stakeholder): الأشخاص المهتمون بالنظام.
- الشروط المسبقة (Preconditions): ما يجب أن يكون صحيحاً قبل البدء.
- الضمان الأدنى (Minimal guarantee): أقل ما يُوعد به أصحاب المصلحة.
- ضمان النجاح (Success guarantee): ما يجب أن تفعله الحالة لإرضاء أصحاب المصلحة.
- المُحفز (Trigger): الحدث الذي يبدأ الحالة.
- الامتداد (Extension): السلوكيات التي تتبع الاستثناءات لسيناريو النجاح الرئيسي.
Use case names in a diagram alone do not provide enough information for analysis and design. Thus, contents are written in simple text. Cockburn (2001) recommends a template including:
- Level: Perspective of the description (high-level to detailed).
- Stakeholder: People with a vested interest.
- Preconditions: Things that must be true before starting.
- Minimal guarantee: The least amount promised to stakeholders.
- Success guarantee: What the use case must do effectively to satisfy stakeholders.
- Trigger: Event that initiates the use case.
- Extension: Behaviors following exceptions to the main success scenario.
يضمن هذا القالب عدم إغفال أي تفاصيل حرجة أثناء مرحلة التحليل.
الشروط المسبقة تمنع النظام من تنفيذ عمليات غير صالحة، بينما تحدد الضمانات (الدنيا والنجاح) حالة النظام بعد انتهاء حالة الاستخدام، سواء نجحت العملية أم فشلت، مما يسهل كتابة حالات الاختبار (Test Cases) لاحقاً.
This template ensures no critical details are missed during analysis.
Preconditions prevent the system from executing invalid operations, while guarantees (minimal and success) define the system's state after the use case ends, whether it succeeds or fails. This heavily facilitates writing Test Cases later in the lifecycle.
ما الفرق بين الضمان الأدنى (Minimal guarantee) وضمان النجاح (Success guarantee)؟ What is the difference between a Minimal guarantee and a Success guarantee?
الضمان الأدنى هو ما يلتزم به النظام حتى في حالة فشل العملية (مثل: عدم فقدان البيانات، أو تسجيل الخطأ). ضمان النجاح هو النتيجة النهائية المطلوبة عند اكتمال العملية بنجاح (مثل: إتمام عملية الدفع وتحديث الرصيد).
The minimal guarantee is what the system promises even if the use case fails (e.g., no data corruption, logging the error). The success guarantee is the desired outcome when the use case completes successfully (e.g., payment processed and balance updated).
4 مخططات الأنشطة (Activity Diagrams)
4 Activity Diagrams
مخطط النشاط يشبه المخطط الانسيابي (Flowchart)؛ يوضح تسلسل الأنشطة والمنطق الشرطي لإنجاز عملية ما.
An Activity Diagram is like a flowchart; it shows the sequence of activities and conditional logic to accomplish a process.
يُظهر مخطط النشاط المنطق الشرطي لتسلسل أنشطة النظام (يدوية أو آلية) اللازمة لإنجاز إجراء عمل. يُستخدم لتصوير تدفق التحكم، المساعدة في تحليل حالات الاستخدام، ونمذجة سير العمل.
الرموز الأساسية:
- النشاط (Activity): مستطيل بزوايا دائرية.
- البداية (Start): دائرة ممتلئة.
- النهاية (End): دائرة ممتلئة محاطة بدائرة أخرى.
- التفرع (Branch): معين (سهم وارد وسهمان صادران للقرارات الشرطية).
- الدمج (Merge): معين (سهمان واردان وسهم صادر لجمع المسارات).
- التشعب (Fork): خط أفقي (سهم وارد وسهمان صادران للأنشطة المتوازية).
- الالتقاء (Join): خط أفقي (سهمان واردان وسهم صادر لدمج الأنشطة المتوازية).
تُستخدم مسارات السباحة (Swimlanes) كأعمدة لتمثيل الوحدات التنظيمية المسؤولة عن أنشطة معينة.
An Activity Diagram shows the conditional logic for the sequence of system activities (manual or automated) needed to accomplish a business process. It depicts flow of control, helps in use case analysis, and models workflows.
Basic Notations:
- Activity: Rounded rectangle.
- Start: Filled circle.
- End: Filled circle surrounded by another circle.
- Branch: Diamond (1 incoming, 2 outgoing arrows for decisions).
- Merge: Diamond (2 incoming, 1 outgoing arrow to join paths).
- Fork: Horizontal line (1 incoming, 2 outgoing arrows for parallel activities).
- Join: Horizontal line (2 incoming, 1 outgoing arrow to merge parallel activities).
Swimlanes are columns representing organizational units responsible for certain activities.
يعتمد تفسير مصطلح 'النشاط' على المنظور: على المستوى المفاهيمي، النشاط هو 'مهمة' (Task)، بينما على مستوى التنفيذ، النشاط هو 'طريقة' (Method) في فئة (Class).
التمييز بين Branch/Merge (للمسارات الشرطية المتبادلة) و Fork/Join (للمسارات المتوازية المتزامنة) أمر بالغ الأهمية لتمثيل منطق النظام بدقة.
The interpretation of 'activity' depends on the perspective: at a conceptual level, it is a 'task'; at an implementation level, it is a 'method' in a class.
Distinguishing between Branch/Merge (for mutually exclusive conditional paths) and Fork/Join (for concurrent parallel paths) is critical for accurately representing system logic.
متى نستخدم التفرع (Branch) ومتى نستخدم التشعب (Fork)؟ When do we use a Branch versus a Fork?
نستخدم التفرع (Branch) عندما يكون هناك قرار شرطي (إما هذا المسار أو ذاك، حصرياً). ونستخدم التشعب (Fork) عندما نريد تنفيذ عدة أنشطة في نفس الوقت (بالتوازي).
We use a Branch for a conditional decision (mutually exclusive paths - either A OR B). We use a Fork when we want to execute multiple activities at the same time (parallel execution - both A AND B).
5 نمذجة إجراءات العمل (BPMN)
5 Business Process Modeling (BPMN)
BPMN هي لغة قياسية معقدة لتمثيل إجراءات العمل، تستخدم بوابات (Gateways) للتحكم في تدفق العمليات.
BPMN is a complex standard language for representing business processes, using Gateways to control process flow.
إجراء العمل هو طريقة قياسية لإنجاز مهمة ضرورية لعمل المؤسسة. أنشأت مجموعة إدارة الكائنات (OMG) نموذج تدوين إجراءات العمل (BPMN). وهو أكثر تعقيداً من مخططات تدفق البيانات (DFDs).
المفاهيم الأربعة الأساسية هي:
- الحدث (Event): محفز يبدأ العملية (دائرة رقيقة للبداية، سميكة للنهاية).
- النشاط (Activity): إجراء يجب أن يتم (مستطيل بزوايا دائرية).
- التدفق (Flow): سهم يوضح التسلسل.
- البوابة (Gateway): نقطة اتخاذ قرار (معين).
أنواع البوابات:
- XOR (حصري): معين بداخله 'X'. يُتبع مسار واحد فقط.
- AND (واو العطف): معين بداخله '+'. تُتبع جميع المسارات بالتوازي.
- OR (أو): معين بداخله 'O'. يُتبع مسار واحد على الأقل، وربما عدة مسارات.
A business process is a standard method for accomplishing a task necessary for an organization. The Object Management Group (OMG) established Business Process Modeling Notation (BPMN). It is much more complicated than DFDs.
The four basic concepts are:
- Event: A trigger initiating a process (thin circle for start, thick for end).
- Activity: An action that must take place (rounded rectangle).
- Flow: An arrow showing sequence.
- Gateway: A decision point (diamond).
Types of Gateways:
- XOR (Exclusive OR): Diamond with an 'X'. Only ONE path can be followed.
- AND: Diamond with a '+'. ALL paths are followed in parallel.
- OR: Diamond with an 'O'. AT LEAST ONE path must be followed, but many/all can be engaged.
تكمن قوة BPMN في قدرتها على سد الفجوة بين تصميم الأعمال وتنفيذ تكنولوجيا المعلومات.
البوابات (Gateways) توفر تحكماً دقيقاً جداً في التوجيه مقارنة بمخططات الأنشطة العادية. بوابة OR تتطلب تقييماً معقداً لأنها قد تتصرف كـ XOR أو AND بناءً على البيانات المتوفرة وقت التشغيل.
The power of BPMN lies in its ability to bridge the gap between business design and IT implementation.
Gateways provide highly granular routing control compared to standard activity diagrams. The OR gateway requires complex evaluation because it can behave like an XOR or an AND depending on runtime data.
| XOR Gateway | AND Gateway | OR Gateway | |
|---|---|---|---|
| الرمزSymbol | معين بداخله XDiamond with 'X' | معين بداخله +Diamond with '+' | معين بداخله ODiamond with 'O' |
| سلوك المساراتPath Behavior | مسار واحد فقطExactly ONE path | جميع المسارات بالتوازيALL paths in parallel | مسار واحد على الأقل (ربما أكثر)AT LEAST ONE path (maybe more) |
ما هو الفرق الرئيسي بين بوابة XOR وبوابة OR في BPMN؟ What is the main difference between an XOR gateway and an OR gateway in BPMN?
في بوابة XOR، يُسمح بمسار واحد فقط (إما أ أو ب). في بوابة OR، يجب اختيار مسار واحد على الأقل، ولكن يمكن اختيار مسارات متعددة في نفس الوقت (أ، أو ب، أو كلاهما).
In an XOR gateway, strictly ONLY ONE path can be taken (either A or B). In an OR gateway, AT LEAST ONE path must be taken, but multiple paths can be taken simultaneously (A, or B, or both).