Phase 2: UML Modeling & Diagrams

UML (Unified Modeling Language) accounts for nearly 30% of exam marks. Learn the strict distinction between Static and Dynamic modeling and exact arrow notations.

1. Static (Structural) vs Dynamic (Behavioral) Diagrams

Category	What it Models	Key UML Diagrams
Static (Structural)	The permanent structure, components, and relationships of software at rest (no time execution).	Class Diagram, Package Diagram, Component Diagram, Deployment Diagram.
Dynamic (Behavioral)	How objects interact over time during program execution and state transitions.	Use Case Diagram, Sequence Diagram, Activity Diagram, State Machine Diagram.

2. Class Diagrams: Notation Rules

A Class Diagram box consists of 3 compartments: Class Name, Attributes, and Operations (Methods).

Visibility Modifiers:

+ Public (accessible anywhere)
- Private (accessible only within class)
# Protected (accessible within package and subclasses)
~ Package / Default (accessible within package)

Relationship Arrows (Crucial for Exams):

Inheritance (Generalization):   [Subclass] ───────▷ [Superclass]  (Solid line, Hollow Triangle arrowhead)
Interface Realization:         [Class]    -- -- --▷ [Interface]   (Dashed line, Hollow Triangle arrowhead)
Aggregation (Weak HAS-A):      [Child]    ────────◇ [Parent]      (Solid line, Hollow Diamond)
Composition (Strong PART-OF):  [Child]    ────────◆ [Parent]      (Solid line, Solid/Filled Diamond)
Dependency (USES):             [Client]   -- -- --→ [Supplier]    (Dashed line, Open Arrowhead)
        

💡 Examiner Distinction Tip

Do NOT confuse Generalization (Inheritance: solid line ───▷) with Realization (Interface: dashed line - - -▷). Using a solid line for an interface loses full points!

3. Use Case & Sequence Diagrams

A. Use Case Diagrams

Actors: Stick figures outside the system boundary. Represent roles (users or external systems).
Use Cases: Ovals inside the system rectangle boundary. Represent features.
<<include>>: mandatory sub-routine (e.g., Checkout always includes Authenticate User). Arrow points TO included use case.
<<extend>>: optional conditional feature (e.g., Checkout extended by Apply Discount Coupon). Arrow points TO base use case.

B. Sequence Diagrams (Chronological Interaction)

Lifelines: Vertical dashed lines extending down from object boxes (Time moves top to bottom).
Activation Boxes: Thin rectangles on lifelines indicating when an object is executing code.
Synchronous Message: Solid line with solid arrow `─────►` (caller blocks until response).
Return Message: Dashed line with open arrow `◄- - - -` (returns value).

4. Object Constraint Language (OCL)

OCL is a formal declarative language used to specify constraints on UML models that cannot be shown visually.

Invariant (inv): Must be true for all instances at all times (e.g., context Account inv: self.balance >= 0).
Pre-condition (pre): Must be true before method execution (e.g., context Account::withdraw(amount: Real) pre: amount > 0).
Post-condition (post): Guaranteed true after method execution (e.g., post: self.balance = self.balance@pre - amount).

⚡ Quick Self-Test

Q: In a Use Case Diagram, if Log Error is triggered only when an exception occurs during Process Transaction, is the relationship <<include>> or <<extend>>?

Answer: <<extend>>.
Because logging the error is a conditional, optional execution branch that extends the base Process Transaction use case under specific conditions.