📐 Lecture 05 · 70 slides · The biggest exam topic (Question 2)

UML Class Diagrams I

أهم رسم في UML، وبييجي غالباً في Question 2 من الامتحان (20 مارك). هنغطي أنواع العلاقات: Associations, Multiplicity, Generalization, Aggregation, Composition، وكل relations ممكن تيجي.

← All Lectures 🎯 جرب أسئلة الامتحان

Chapters

Slide Exercises

Relation Types

Exam Qs

What is UML?

UML اختصار لـ Unified Modeling Language: لغة رسومية معيارية لنمذجة برمجيات OO.

📖 الخلفية

طوّرها Rumbaugh, Booch, Jacobson، والمعروفين باسم Three Amigos.
أسّسوا Rational Software Corporation، واللي اشترتها IBM بعد كده.
في 1997، بدأت منظمة Object Management Group (OMG) عملية standardization.

📚 أنواع UML Diagrams

🏗️ Static View

Class diagrams — describe classes & relationships.
Component diagrams
Deployment diagrams

🎬 Dynamic View

Sequence diagrams — object interactions.
Communication diagrams
State diagrams (internal behavior)
Activity diagrams

💡 في المحاضرة دي هنركز على Class Diagrams (static structure). Sequence diagrams و State diagrams في محاضرات جاية.

Class Diagram Essentials

5 رموز أساسية: Classes · Attributes · Operations · Associations · Generalizations.

📦 Class Box — 3 أقسام

Rectangle

→

Rectangle

height
width

getArea()
resize()

→

Rectangle

− height: int
− width: int

+ getArea(): int
+ resize(int, int)

اسم الـ class فقط (مستوى مجرد).
Attributes + Operations (مستوى متوسط).
Full signature مع الـ visibility (+ = public, − = private) والـ types (مفيد للـ implementation).

✍️ Operation Signature

operationName(parameterName: parameterType, ...): returnType

مثال: resize(width: int, height: int): void

🔄 Class Diagrams خلال lifecycle

رسومات Class diagram بتختلف حسب المرحلة:

Domain Analysis — مستوى عالي، ومفاهيم business (من غير methods، غالباً attributes بس).
Requirements Specification — بتضيف الـ operations اللي ظهرت من الـ use cases.
Implementation — شبه خريطة مباشرة للكود، وفيها visibility و types و library classes.

بتتطور بشكل iterative مع الوقت.

Associations & Multiplicity

الـ Associations بتربط الـ classes ببعضها. والـ Multiplicity بتوضح كام instance مسموح من كل side.

🔢 Multiplicity Reference

1exactly one

*zero or many

0..1zero or one (optional)

1..*at least one

3..8between 3 and 8 inclusive

0, 3..8either zero, or between 3 and 8

🔗 Many-to-One Example

Employee

* ━━━ worksFor ━━━ 1

Company

A company has many employees (*).
An employee works only for 1 company.
A company can have zero employees (e.g. shell company).
An employee must work for a company (multiplicity 1, not 0..1).

🔗 Many-to-Many Example

Assistant

* ━━━ supervisor ━━━ 1..*

Manager

An assistant can work for many managers (1..*).
A manager can have many (or 0) assistants.
Question: is it possible for assistant to have zero managers temporarily?

⚠️ Avoid Unnecessary 1-to-1

❌ Avoid this

Person

name

1 ━━ 1

PersonInfo

address

✅ Do this

Person

name
email
birthdate
address

لو علاقة الـ 1:1 إلزامية دايماً، خلّيها attribute داخل نفس الـ class بدل ما تعمل relation منفصلة.

Special Associations

Association classes · Reflexive associations · Directionality.

📎 Association Class

أحياناً بيكون فيه attribute يخص العلاقة بين 2 classes، مش الـ classes نفسها.

مثال: grade الطالب في course. الدرجة مش property للـ student لأنه عنده درجات كتير، ومش property للـ course لأنه فيه طلاب كتير. هي property للـ registration.

Student

* ━━ *

CourseSection

↓ Association class

Registration

grade

ده مكافئ لـ:

Student

1 ━ *

Registration

grade

* ━ 1

CourseSection

🔄 Reflexive Associations

الـ Class ممكن تربط نفسها بنفسها. مثال: Course:

Course

↩ successor (* to *)
↩ prerequisite (* to *)
↩ isMutuallyExclusiveWith (* to *)

مثال على الـ instances:

CS251 (prerequisite) → CS352 (successor)

➡️ Directionality

الـ Associations افتراضياً bi-directional. تقدر تحدد الـ direction بسهم عند الـ end.

Day

1 ━━→ *

Note

يعني Day بيعرف الـ Notes اللي تخصه، لكن الـ Note ما يعرفش الـ Day بتاعه.

Generalization (Inheritance)

الـ Superclass هو الأب، والـ Subclasses ترث منه. سهم الـ open triangle بيشير ناحية الـ superclass.

🌳 Basic Generalization

Animal

△

discriminator: habitat

AquaticAnimal

LandAnimal

الـ Subclasses بترث الـ attributes والـ operations من الـ superclass.

Generalization Set = تجميع للـ subclasses بناءً على discriminator (معيار التخصص).

🔀 Multiple Discriminators

الـ Animals ممكن يتقسموا بأكتر من معيار: habitat (aquatic/land) و typeOfFood (carnivore/herbivore). عندنا حلين:

Option 1: Higher-level Generalization

Animal → AquaticAnimal → AquaticCarnivore + AquaticHerbivore، ونفس الفكرة مع Land.

⚠️ بيعمل classes كتيرة (4 leaves).

Option 2: Multiple Inheritance

الـ AquaticCarnivore تعمل inherits from both من AquaticAnimal و Carnivore.

⚠️ مش كل اللغات بتدعمها (Java لا، C++ يدعمها).

🚫 Avoid Instances Changing Class

لو الـ instance ممكن يتغير من type لـ type تاني، ما تستخدمش inheritance. استخدم attribute بدالها.

❌ Avoid

Student

△

FullTimeStudent

PartTimeStudent

طالب ممكن يتحول من part-time لـ full-time → مشكلة

✅ Do

Student

name
attendance: enum

الـ attendance كـ attribute يتغير بسهولة

Aggregation vs Composition ⭐

دي علاقات part-whole. الفرق الأساسي بينهم: هل الـ part تقدر تعيش بدون الـ whole؟

💠 Aggregation (Open Diamond ◇)

الـ Aggregation علاقة part-whole، لكن الـ parts تقدر تعيش مستقلة عن الـ whole.

Vehicle

1 ◇━━ *

VehiclePart

الـ Vehicle parts ممكن تيجي من cars مختلفة وتُستخدم تاني (reused).
لو الـ Vehicle اتدمر، الـ parts ممكن تستخدم في Vehicle تاني.

✅ When to use Aggregation:

تقدر تقول إن الـ parts are part of الـ aggregate، أو إن الـ aggregate is composed of الـ parts.
لما شيء يملك أو يتحكم في الـ aggregate، فهو غالباً يملك أو يتحكم في الـ parts كمان.

♦️ Composition (Filled Diamond ◆)

الـ Composition هي strong aggregation. لو الـ aggregate اتدمر، الـ parts اتدمرت معاه. الـ part ما تقدرش تعيش بدون الـ whole.

Building

1 ◆━━ *

Room

الـ Rooms ما تقدرش توجد بدون الـ Building.
لو الـ Building اتهد، الـ Rooms راحت معاه.

⚖️ Aggregation vs Composition — جدول مقارنة

Aspect	Aggregation ◇	Composition ◆
Symbol	Open (hollow) diamond	Filled (solid) diamond
Part lifecycle	Independent	Tied to whole
If whole destroyed	Parts survive	Parts destroyed
Part can be reused	Yes (in other wholes)	No (one whole only)
Example	Vehicle - VehiclePart · Country - Region	Building - Room · Book - Chapter (if Chapter can't exist alone)

📍 Address: 2 Alternatives

As Composition

Employee

◆━

Address

street
city
country

As Attribute

Employee

address: Address

أبسط لو الـ Address ما عندهاش complexity كبيرة

🔄 Propagation

Mechanism: الـ operation في الـ aggregate بتتنفذ بأن الـ aggregate يعمل perform لنفس الـ operation على الـ parts بتاعته.

مثال: Polygon.draw() بتتنفذ بأن الـ Polygon يطلب من كل LineSegment إنها تعمل draw().

وعكسياً: الـ properties الخاصة بالـ parts ممكن تنتشر للـ aggregate.

Object Diagrams

الـ Object هو instance من class. والـ Link هو instance من association.

🧬 Class vs Object Diagram

	Class Diagram	Object Diagram
Shows	Types and relationships	Specific instances at runtime
Naming	`Employee`	`Pat: Employee` (instance:class)
Underline?	No	Yes (object name underlined)
Generalizations	✓ Shown	❌ Don't appear in object diagrams
Associations	Class-level	Become links between objects

📊 Example Object Diagram

Pat: Employee

Wayne: Employee

━━→

OOCorp: Company

Pat و Wayne instances من Employee.
OOCorp instance من Company.
الـ Links بتعكس علاقة worksFor اللي موجودة في الـ class diagram.

Full Example: Problem Report Tool

أداة CASE tool لتخزين وتتبع الـ problem reports. ده مثال شامل لكل الـ relations.

📋 The Requirements

Employees are either developers or managers (generalization).
Each developer has a manager (1 manager per developer).
Project assigned a manager + a number of developers.
Developer/manager may be assigned to multiple projects or to none (0..*).
Project consists of artifacts (domain analysis, SRS, code, test cases...) — aggregation.
Problem reports can be made on any artifact.
Each report contains: problem description and status.
Each problem can be assigned to someone by the project manager.
Report has history entries (action/update logs) — aggregation.
A special kind of reports: Code/Bug Reports with extra info (location, circumstances, failed tests) — generalization.

📐 The Class Diagram (high-level)

        ┌──────────┐
        │ Employee │ (name: String)
        └────△─────┘
             │
       ┌─────┴──────────┐
   ┌───┴───┐      ┌─────┴────┐
   │Manager│      │Developer │
   └───┬───┘      └────┬─────┘
       │              │   * managed by 1
       │ 1            └───↑─────────────┐
       │  responsibleFor  │            Manager
       │  0..*            │ * assigned 0..*
   ┌───↓──────────┐  ┌──↓──────────┐
   │ Problem Rep. │  │  Project    │ (name)
   │ + status     │  └──◇──────────┘  ← aggregation
   │ + desc       │     │ 1
   │              │     │ 0..*
   └──△───────────┘  ┌──↓─────────┐
      │              │  Artifact  │ ── associated 0..n ──→ Problem Report (label: "About")
   ┌──┴──────────┐   │ +name      │
   │ CodeBugRep. │   │ +status    │
   └─────────────┘   └────────────┘

   Problem Report ◇──── 0..n ───→ History Entry (when: Date, whatDone: String)
                  "History Log"

💡 الـ relations الـ 5 الموجودة في المثال
1. Generalization — الـ Manager والـ Developer بيرثوا من Employee، والـ CodeBugReport بيرث من Problem Report.
2. Associations — مثل Developer managedBy Manager، و Employee assignedTo Project، و Artifact About Problem Report.
3. Aggregation — Project ◇ Artifact، و Problem Report ◇ History Entry.
4. Multiplicities — زي: 1، *، 0..*، 1..*، 0..n.
5. Labels — Managed By، Assigned To، Responsible For، About، History Log.

📝

13 Slide Exercises — Practice

دي التمارين اللي د. الرملي حاططها في السلايدز. لازم تحلهم كلهم، لأن كل تمرين بيختبر concept مختلف.

Ex 1 Shape Class & Square — What relation?

Shape ← Triangle, Square (open-triangle generalization arrow).

الإجابة: Generalization (Inheritance) — الـ Square والـ Triangle بيرثوا من Shape.

Ex 2-4 Account ↔ Client (Bank example)

Class diagram: Account [1] ━━ [0..n] Client +owner

Ex 2: What relation? → Simple Association with multiplicity.
Ex 3: What's true?
- A client can own multiple accounts? True (0..n on client side from account's perspective is the inverse — actually account is 1 to many clients here meaning 1 account has 0..n owners; the question is open to interpretation, but conventional answer follows the diagram).
- An account can be used to access its client? True (bidirectional by default).
- A client can be used to access its account? True.
Ex 4: What's true?
- An account can have multiple owners? True (0..n on client side).
- No account can exist without a client? Depends — if 0..n includes 0, account can exist without clients.
- A client must have an account? True if multiplicity is 1 on account side.

Ex 5 Building ◆━ Room (Composition)

It shows a composition relation? ✓ True (filled diamond).
A building may have no rooms? ✗ False if multiplicity is 1..* (depends on diagram).
A room may exist without a building? ✗ False — composition means parts die with whole.

Ex 6 Employee ━ Address (Plain Association, 1:1)

It shows a composition relation? ✗ False (no diamond shown).
An employee may have no address? ✗ False if multiplicity is 1 (mandatory).
An address may exist without an employee? ✓ True if it's a plain association.

Ex 7 Employee → Manager/Developer, Project assignment

Part 1: Manager [1] managedBy [0..*] Developer (subclasses of Employee).

Employee can be Manager and Developer at the same time? ✗ False (in single inheritance, subclasses are disjoint).
Manager may have no developers assigned? ✓ True (0..* includes 0).
Developer has one and only one manager? ✓ True (multiplicity 1).

Part 2: Employee [1..*] assignedTo [0..*] Project.

Project has at least one employee? ✓ True (1..*).
Every developer must be assigned to a project? ✗ False (0..* on project side means dev can have zero projects).
Manager may have no projects? ✓ True.

Ex 8 Course (Reflexive: successor, prerequisite, mutuallyExclusive)

A course may have any number of prerequisites or none? ✓ True (multiplicity *).
A course may not be taken with any number of courses? ✗ False (it CAN be).
A course may have an association relation with another course? ✓ True — reflexive association.

Ex 9 Book / Volume / Chapter (Aggregation vs Composition)

الـ scenario: الـ Book فيه volumes، والـ volumes فيها chapters. والـ Chapters can be sold alone حتى لو الـ book مش متاح.

Fig 1 (Composition 1:* / 1:*) — ❌ غلط لأن الـ composition معناها إن الـ parts ما تقدرش توجد لوحدها.
Fig 2 (Composition 1..* / 1..*) — ❌ غلط لنفس السبب.
Fig 3 (Aggregation 1..* / 1..*) — ✅ صح لأن الـ parts ممكن توجد مستقلة.

الإجابة: Figure 3 — الـ Aggregation صح لأن الـ chapters والـ volumes ممكن يتباعوا أو يوجدوا بشكل مستقل عن الـ book.

Ex 10 Event/Schedule/Display system — multiple relations

اقرأ الـ diagram بدقة:

CurrentEventDisplay can display both SpecialEvents and RegularEvents? ✓ True — both inherit from Event, and Event is displayed.
CurrentEventDisplay can display multiple events? ✓ True if multiplicity supports it.
Schedule can contain an Announcement? ✗ False — Schedule aggregates Event, not Announcement.
UserInterface can display either events or announcements but not both? ✗ False — different subclasses of UI handle different types.
SpecialEvent should have at least one Date? Depends on multiplicity on Date association.
An Announcement can have a Date? ✗ False — Announcement doesn't connect to Date in the diagram.

Ex 11 Writer ↔ Document (Object diagram match)

Class diagram: Writer [*] ━ [1] Document

الـ multiplicity على ناحية الـ Writer هي *، يعني document واحد ممكن يكون له writers كتير أو ولا واحد.

Figure I: 1 Writer ↔ 1 Document ✓ valid
Figure II: 2 Writers ↔ 1 Document ✓ valid (matches * to 1)
Figure III: 1 Writer ↔ 1 Document ✓ valid

الإجابة: Figure II هي أفضل واحدة لأنها بتوضح * multiplicity. كل الرسومات valid، لكن II بتعرض الـ multiplicity بشكل أوضح.

Ex 12 Person and Body parts (Head, Hand, Leg)

Fig 1 (Aggregation ◇) — ❌ wrong, body parts can't survive without person.
Fig 2 (Composition ◆) — ✅ correct — body parts die with person.
Fig 3 (Generalization) — ❌ very wrong, Head IS-NOT-A Person.

Ex 13 Car & Engine, Wheel (parts can be sold separately)

"Knowing that parts can be sold separately" → Aggregation.

Fig 1 (Aggregation ◇) — ✅ correct.
Fig 2 (Composition ◆) — ❌ wrong, parts die with whole.
Fig 3 (Generalization) — ❌ very wrong, Engine IS-NOT-A Car.

🎯

Exam Question Bank — Lecture 5

4 أسئلة حقيقية من امتحانات الـ MCQ على Class Diagrams. الـ Question 2 في كل امتحان (UML Modeling, 20 marks) بيعتمد على الـ concepts دي.

Question 1 Fall 2021–22 · Q1.07 (also Winter 2021)

Given the class diagram: Advertiser [1] ━━ [*] Account. Which code properly implements it?

Code (a): Advertiser has Set accounts, addAccount() adds & sets owner with null check. Account has setOwner() that calls addAccount if newOwner != null.
Code (b): Advertiser has single Account account field. (Wrong — should be Set.)
Code (c): Advertiser has Set; Account has Set owners (multiple owners!). (Wrong — should be single owner.)

A Code (a)

B Code (b)

C Code (c)

✅ الإجابة الصح: A — Code (a) الـ multiplicity 1 to * معناها: Advertiser واحد ↔ Accounts كتير. الكود الصح:

الـ Advertiser فيه Set<Account> accounts (collection).
الـ Account فيه Advertiser owner (single reference، مش Set).
addAccount و setOwner بيشتغلوا معاً للحفاظ على الـ bidirectional integrity.

B — استخدم Account account (single) في Advertiser بدل Set. غلط لأن كل Advertiser لازم يقدر يمتلك multiple accounts. · C — خلى الـ Account فيه Set من Advertisers (multiple owners). ده many-to-many، مش 1-to-*.

Question 2 Fall 2021–22 · Q1.08 (also Winter 2021)

Which class diagram represents this code?

class Order { OrderStatus status; ArrayList<OrderDetail> details; ... }
class OrderDetail { Product product; }
class Product { String code, name; float unitPrice; }
enum OrderStatus { OPEN, CLOSED; }

A (a) Order ◆[1:*] OrderDetail → Product; Order → OrderStatus

B (b) Order [1:1] OrderDetail

C (c) Order → OrderDetail → Product (without composition)

D (d) Order [*:*] OrderDetail (many-to-many)

✅ الإجابة الصح: A — Composition with 1:*

ArrayList<OrderDetail> = Order has many OrderDetails (multiplicity *).
Order owns OrderDetails completely (composition ◆).
OrderDetail has single Product reference (1:1 association).
Order has OrderStatus enum.

B — 1:1 غلط، لأن الـ ArrayList معناها عناصر متعددة. · C — الـ Order يملك OrderDetails كجزء منه (composition)، مش مجرد association. · D — Many-to-many غلط، لأن الـ OrderDetail بيخص Order واحد فقط.

Question 3 Winter 2023 · Q1.04

Customers of a car sales shop can buy cars. Customers with a bad credit history should pay an extra down payment. Which diagram represents this?

A <<include>> from Bad Credit Customer's "Buy a car" to "Pay extra down payment"

B <<include>> on Customer side

C <<extend>> on Customer side

D <<extend>> from Bad Credit Customer's "Buy a car" to "Pay extra down payment"

✅ الإجابة الصح: D extend = حالة مشروطة (should pay if bad credit). الـ Bad Credit Customer هو الـ actor المختص بالـ extra payment، فالـ extend بيكون على الـ side بتاعه.

A, B — الـ include معناها always. هنا الـ extra payment مش دايماً، هي بس لـ bad credit. · C — الـ extend صح، لكن على ناحية الـ Customer العادي غلط.

Question 4 Winter 2023 · Q1.05

Which class diagram is wrong?

(a) Class A with self-association (regular line with arrowhead).
(b) Class A with self-loop (curve from one end to another, plain).
(c) Class A with self-loop showing generalization arrow (open triangle).
(d) Class A with self-loop showing aggregation diamond.

A (a)

B (b)

C (c)

D (d)

✅ الإجابة الصح: C — Self-generalization is invalid الـ Class ما تقدرش ترث من نفسها — يعني A extends A = infinite loop من ناحية المعنى. ده مستحيل في OO design.

A, B — الـ Reflexive associations صحيحة، مثل Course prerequisite Course. · D — الـ Reflexive aggregation صحيحة، مثل Folder contains subfolders.

Question 5 Slide Ex 9 (practice)

A book has volumes, volumes have chapters. Chapters can be sold alone even without the book. Which is the correct relation?

A Composition (filled diamond)

B Aggregation (open diamond)

C Generalization (open triangle)

D Plain association

✅ الإجابة الصح: B — Aggregation Parts can be sold separately → الـ parts ممكن توجد مستقلة → Aggregation (open diamond ◇). لو Composition، فالـ chapter ما تقدرش توجد بدون الـ book.

A — الـ Composition معناها إن الـ parts ما تقدرش توجد لوحدها، وده عكس المطلوب. · C — الـ Chapter مش نوع من Book. · D — الـ Plain association ما بيعبرش عن علاقة part-whole.

Question 6 Slide Ex 12 (practice)

What's the right relation between Person and body parts (Head, Hand, Leg)?

A Composition (filled diamond)

B Aggregation (open diamond)

C Generalization

D Plain association

✅ الإجابة الصح: A — Composition الـ body parts ما تقدرش تعيش بدون الـ Person. لما الـ Person يموت، الـ body parts ما بتكونش entities مستقلة.

B — الـ Aggregation معناها إن الـ parts مستقلة، وده مش الحالة هنا. · C — الـ Hand مش نوع من Person. · D — ما بيعكسش معنى is part of.

Question 7 Practice on multiplicity

Class diagram: Project [0..*] ━━ [1..*] Employee. Which is true?

A Every project must have at least one employee, every employee must be on at least one project

B Every employee must be on at least one project; a project can exist with zero employees

C Every project must have at least one employee; an employee can exist with zero projects

D Both can exist independently

✅ الإجابة الصح: C الـ multiplicity بتتقرأ على الـ opposite end:

1..* على ناحية الـ Employee → كل project لازم يكون عنده employee واحد أو أكتر.
0..* على ناحية الـ Project → كل employee ممكن يكون مرتبط بـ 0 أو أكتر من المشاريع.

Question 8 Practice (Winter 2023 style)

Which of the following is NOT a valid UML relationship for a class to have with itself?

A Self-association (e.g. Person knows Person)

B Self-generalization (A extends A)

C Self-aggregation (Folder contains Folders)

D Self-composition (Tree contains Tree)

✅ الإجابة الصح: B — Self-generalization الـ Class ما تقدرش ترث من نفسها، لأن معناها infinite loop في الـ inheritance. الباقي valid:

Self-association: Course → Course (prerequisite).
Self-aggregation: Folder → SubFolder.
Self-composition: Tree → SubTree.

📋

Cheat Sheet

كل الرموز والمصطلحات والقواعد في صفحة واحدة.

🎨 UML Symbols

Class

Rectangle بـ 3 أقسام (name / attrs / ops)

public

−

private

protected

━━━

Association (plain line)

━━→

Directed association

━━△

Generalization (open triangle)

◇━━

Aggregation (open diamond)

◆━━

Composition (filled diamond)

🔢 Multiplicity

exactly one

0..1

optional (zero or one)

zero or many

1..*

at least one

N..M

between N and M inclusive

0, 3..8

zero OR (between 3 and 8)

🔗 Relations Decision Tree

"IS-A"

→ Generalization

"HAS-A" + part dies

→ Composition

"HAS-A" + part survives

→ Aggregation

"USES" / "KNOWS"

→ Plain Association

Attribute of relationship

→ Association Class

📐 UML 3 Amigos

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE / Use cases

Founded

Rational Software → IBM

Standardized

OMG, 1997

⚠️ Common Pitfalls

Avoid

Unnecessary 1:1 → use attribute

Avoid

Self-generalization (A extends A)

Avoid

Inheritance when instance can change class → use attribute

Composition only if

Part can't exist without whole

🎯 Reading Multiplicity

Where to read?

On the OPPOSITE end

A [1] ━ [*] B

A has many B's, B has 1 A

A [1..*] ━ [0..*] B

A has 0 or many B's, B has at least 1 A

⚡

Rapid Revision

Flashcards · Common Mistakes · What the doctor loves to ask.

5 UML Class Diagram symbols؟

tap to flip

Classes · Attributes · Operations · Associations · Generalizations

Aggregation vs Composition؟

tap to flip

Open ◇ vs Filled ◆. Composition = part dies with whole.

UML founded by؟

tap to flip

Rumbaugh · Booch · Jacobson (OMG 1997)

Multiplicity 0..1 معناها؟

tap to flip

Optional — zero or one

Multiplicity 1..* معناها؟

tap to flip

At least one (mandatory minimum)

مثال على Reflexive association؟

tap to flip

Course → Course (prerequisite/successor)

مثال على Association Class؟

tap to flip

Student ↔ CourseSection with Registration (grade)

Building و Room: ايه الـ relation؟

tap to flip

Composition ◆ (room can't exist without building)

Car و Engine (engine sold separately): ايه الـ relation؟

tap to flip

Aggregation ◇ (parts can exist alone)

🚨 Common Mistakes

1. خلط Open و Filled diamondOpen ◇ = Aggregation (independent parts). Filled ◆ = Composition (الـ part بتنتهي مع الـ whole). افتكرها: Filled = Final.

2. قراءة Multiplicity من الجانب الغلطالـ multiplicity على side A بتقول كام instance من A لكل instance من B (الـ opposite). لو A [1] ━ [*] B: لكل B واحد، فيه A واحد بس.

3. استخدام Generalization لما Composition هي الصحالـ Hand مش نوع من Person، لكنها جزء من Person. لما تشوف part of → فكر في Aggregation/Composition، مش Generalization.

4. Include vs Extend في Use Cases(جا في Lec 3 بس بيتسأل كتير): Include = استخدام دائم. Extend = أحياناً، بشرط معين (conditional).

5. نسيان الـ Multiplicity على الـ endsأي association لازم لها multiplicity على الـ end (1, *, 0..1, إلخ). لو نسيتها، هتفقد marks في Question 2.

⭐ What Dr. El-Ramly Loves to Ask

🔥 الأسئلة المتكررة على Lec 5

Code ↔ Class Diagram — بيدي Java/C++ code وعليك تختار الـ diagram الصح، أو العكس.
Aggregation vs Composition — بيدي scenario مثل book أو car أو building، وعليك تحدد الـ relation الصح.
Which class diagram is wrong? — الـ self-generalization دايماً غلط.
Multiplicity questions — تفسير diagram معطى مثل manager-developer أو project-employee.
Question 2 (UML Modeling) — 20+ مارك على بناء use case diagram + class diagram + sequence diagram + state diagram لنظام معين. ركز عليه لأنه بيتكرر في كل امتحان final.

🎯 آخر نصيحة للـ Question 2: ابدأ بـ actors، بعدين use cases، بعدين class diagram فيها كل الـ classes اللي اتذكرت في الـ requirements، مع multiplicities وأسماء relations واضحة.