🎓 SEM III Exam Prep Syllabus Portal
🏠 Home
📖 2413MJCT303 • Unit III • 6 Hrs

Unit III - Basic and Advanced Structural Modeling

Comprehensive University Exam Preparation Notes, Model Question Answers & Comparison Matrices

🔍
📑 Quick Jump Navigation

📌 Syllabus Topics Covered

6 Hrs Weightage

📖 Comprehensive Theoretical Notes

Exam-Oriented Theory

3.1 & 3.4 Class Diagrams & UML Class Relationships

Class Diagram: The central static structural diagram in UML showing system classes, attributes, operations, and relationships.

Class Notation: A 3-compartment rectangle: Top (Class Name), Middle (Attributes: visibility name: type = default), Bottom (Operations: visibility name(parameters): return_type).

Visibility Modifiers: + Public, - Private, # Protected, ~ Package.

Fundamental Class Relationships:

  • Association (Solid Line): Structural connection between classes with multiplicity (e.g., 1..*).
  • Aggregation (Hollow Diamond on Parent): Weak 'has-a' whole-part relationship where parts can exist independently of the whole (e.g., Department $\diamondsuit$– Professor).
  • Composition (Filled Black Diamond on Parent): Strong 'has-a' whole-part relationship where parts cannot exist without the whole (e.g., House $\blacklozenge$– Room). Lifetimes are tightly bound.
  • Generalization / Inheritance (Solid Line with Hollow Triangle): Subclass inherits from superclass.
  • Dependency (Dashed Arrow $\dashrightarrow$): 'Uses-a' relationship; changes in supplier affect client.
  • Realization (Dashed Line with Hollow Triangle): Class implements an interface contract.

3.2 UML Common Mechanisms & Extensibility

UML provides 4 common mechanisms applied consistently across all diagrams:

  • 1. Specifications: Behind every visual graphical symbol lies a detailed textual specification defining semantic rules and types.
  • 2. Adornments: Textual or graphical decorations added to notations (e.g., multiplicity 1..*, navigability arrows, visibility symbols).
  • 3. Common Divisions:
    • Class vs Object: Class represents abstraction; Object represents concrete runtime instance.
    • Interface vs Implementation: Interface specifies the contract; Class provides implementation.
  • 4. Extensibility Mechanisms:
    • Stereotypes («stereotype»): Extends UML vocabulary (e.g., «entity», «control», «boundary»).
    • Tagged Values ({key = value}): Adds new properties/metadata to model elements (e.g., {author = "Shubham", version = 2.0}).
    • Constraints ({constraint expression}): Enforces semantic rules using OCL (Object Constraint Language) (e.g., {age >= 18}).

3.5 - 3.10 Advanced Classes, Relationships, Packages, and Object Diagrams

Advanced Class Types:

  • Active Class: Has its own thread of execution (notated with double vertical borders).
  • Template / Parameterized Class: Generic class parameterized with types (e.g., List<T> with dashed box in top-right).
  • Utility Class: Contains static helper operations (stereotyped «utility»).

Advanced Relationships: Association Classes (associations containing attributes/methods), Qualified Associations (hashmap key lookup), Reflexive Associations (class associated with itself, e.g., Employee manages Employee).

Packages: Tabbed folder icon grouping related classes to manage large-scale namespace complexity.

Object Diagram: Represents a static snapshot of concrete object instances and links at a specific point in runtime.

🔑 Key Concepts & Examination Keywords

Quick Terminology
Aggregation vs Composition
Aggregation is a weak whole-part relationship where child lives independently; Composition is a strong whole-part where child lifetime is bound to parent.
Stereotype
A UML extensibility mechanism enclosed in guillemets (« ») that extends the semantic vocabulary of modeling elements.
Association Class
A class attached to an association line that holds attributes and operations belonging to the relationship itself.
Object Diagram
A snapshot of the runtime system showing concrete object instances (underlined names) and data attribute values.

🎯 High-Yield Important Examination Questions

8–10 Descriptive Points Each

Q1. Explain all UML Class Relationships: Association, Aggregation, Composition, Generalization, Dependency, and Realization with standard notations and examples.

10 MarksUML Class RelationshipsCore
▼
📝 Detailed Examination Answer (10-Point Model):
  1. Association Relationship Notation: Represented by a solid line connecting two classes, indicating a structural relationship where objects know about each other, annotated with roles and multiplicity.
  2. Multiplicity Notations: Specifies instance cardinality bounds: `1` (exactly one), `0..1` (zero or one), `*` or `0..*` (zero or more), `1..*` (one or more), `n..m` (specific range).
  3. Navigability in Association: An open arrowhead indicates unidirectional navigation (Class A can access Class B, but Class B cannot access Class A); no arrowheads implies bidirectional access.
  4. Aggregation (Weak Whole-Part): Represented by a hollow diamond at the aggregate whole end; indicates a shared relationship where parts can exist independently if the whole is destroyed (e.g., Team $\diamondsuit$– Player).
  5. Composition (Strong Whole-Part): Represented by a solid filled black diamond; indicates exclusive ownership where child parts are destroyed when the parent whole is deleted (e.g., Order $\blacklozenge$– OrderLineItem).
  6. Generalization / Inheritance: Represented by a solid line with a hollow triangle pointing to the superclass; models taxonomy and inheritance (Subclass IS-A Superclass).
  7. Dependency Relationship: Represented by a dashed line with an open arrow ($\dashrightarrow$); indicates a transient 'uses-a' relationship where changing the supplier class may affect the client class.
  8. Realization Relationship: Represented by a dashed line with a hollow triangle; indicates a class implementing the contract specified by an abstract interface.
  9. Association Class Concept: A class connected via a dashed line to an association link, used to store attributes belonging to the relationship itself (e.g., `Grade` in Student-Course enrollment).
  10. Summary Diagrammatic Rules for Exams: Ensure clear depiction of line styles (solid vs dashed) and arrowhead shapes (open, hollow triangle, hollow diamond, filled diamond).

Q2. Describe the 4 Common Mechanisms of UML and explain Extensibility Mechanisms (Stereotypes, Tagged Values, Constraints) in detail.

10 MarksUML Common Mechanisms
▼
📝 Detailed Examination Answer (10-Point Model):
  1. Foundation of UML Architecture: UML is designed to be consistent, extensible, and mathematically sound across all diagrams through 4 unifying common mechanisms.
  2. Mechanism 1: Specifications: Every visual graphical icon in UML is backed by an underlying formal semantic specification describing attributes, types, visibility, and constraints.
  3. Mechanism 2: Adornments: Graphical and textual decorations added to basic symbols to enrich meaning (e.g., multiplicity strings, visibility signs `+,-,#`, navigability arrows).
  4. Mechanism 3: Common Divisions (Class vs Object): Distinguishes between abstract classifiers (Class, Component, Node) and concrete runtime instances (Object, Artifact, Device) notated with underlined names.
  5. Common Divisions (Interface vs Implementation): Distinguishes between the contractual public specification (Interface) and the concrete realization that executes the behavior (Class).
  6. Mechanism 4: Extensibility Mechanisms Overview: Allows software engineers to customize and extend UML vocabulary without modifying the core metamodel definition.
  7. Stereotypes (« »): Extends UML vocabulary by creating new modeling building blocks derived from existing ones, written inside guillemets (e.g., `«entity»`, `«control»`, `«interface»`).
  8. Tagged Values ({key = value}): Extends properties of model elements by attaching arbitrary key-value metadata strings (e.g., `{version = 1.2, author = 'DevTeam'}`).
  9. Constraints ({OCL Rule}): Extends semantic behavior by enforcing boolean conditions or invariants written in natural language or Object Constraint Language (e.g., `{salary >= 0}`).
  10. Creating UML Profiles: Bundling custom stereotypes, tagged values, and constraints forms a domain-specific UML Profile (e.g., UML Profile for Spring Boot, SysML for Aerospace).

Q3. Explain the structure and purpose of Object Diagrams. Compare Class Diagrams and Object Diagrams with examples.

10 MarksObject Diagrams
▼
📝 Detailed Examination Answer (10-Point Model):
  1. Definition of Object Diagram: An Object Diagram represents a static snapshot of runtime object instances, attribute values, and links at a specific discrete moment in system execution.
  2. Instance Notation Syntax: Represented by a rectangle with an underlined name compartment: `instanceName : ClassName` or anonymous `: ClassName` or `instanceName`.
  3. Attribute Values Compartment: Contains the concrete assigned runtime values of attributes formatted as `attributeName : type = value` (e.g., `empId : int = 101`).
  4. Links vs Associations: Connections between objects are called Links (instances of associations), represented by solid lines without multiplicity numbers.
  5. Verification of Class Diagrams: Object diagrams serve as concrete test scenarios to validate whether a proposed Class Diagram can support actual real-world business configurations.
  6. Modeling Dynamic System States: Particularly valuable for modeling complex recursive structures (e.g., Composite Design Pattern, Binary Trees, recursive org charts).
  7. Modeling Snapshot Execution: Captures pre-condition and post-condition object states before and after a complex transaction method executes.
  8. Anonymous Objects: Used when the specific instance identifier is unimportant and only the runtime class type and attribute values need demonstration.
  9. Multiplicity Validation: Proves that specific object link instances satisfy the multiplicity rules (e.g., verifying a Department actually holds 5 Professors).
  10. Academic Exam Tip: Always underline object and instance names in object diagrams to distinguish them from class diagrams.

⚖️ Comprehensive Comparison & Difference Tables

8+ Comparison Criteria

📊 Aggregation vs Composition Relationships

Comparison ParameterAggregation (Shared)Composition (Composite)
Relationship StrengthWeak 'has-a' whole-part relationship.Strong 'has-a' whole-part relationship.
UML Graphical NotationHollow diamond ($\diamondsuit$) at the parent aggregate end.Filled solid black diamond ($lacklozenge$) at the parent composite end.
Lifecycle DependencyPart can exist independently of the whole.Part lifetime is strictly bound to the parent whole.
Deletion CascadeDeleting the parent whole does NOT delete the parts.Deleting the parent whole automatically deletes all child parts.
Exclusivity / SharingA part can be shared across multiple aggregate wholes.A part belongs exclusively to exactly ONE composite parent.
Multiplicity ConstraintParent multiplicity can be `0..*` or `1..*`.Parent multiplicity is strictly `1` (or `0..1`).
Real-World ExampleDepartment $\diamondsuit$– Professor (Professors exist without department).House $lacklozenge$– Room (Rooms cannot exist without the House).
Memory Management AnalogyPointer / reference passing (shallow lifecycle).Nested object allocation / memory deletion cascade (deep lifecycle).

📊 Class Diagram vs Object Diagram

Comparison ParameterClass DiagramObject Diagram
Nature of ViewStatic structural schema / blueprint of the system.Static snapshot of concrete runtime instances at a specific time.
Core ElementsClasses, Interfaces, Packages.Objects (Instances) and Links.
Name Compartment SyntaxPlain text: `ClassName` (not underlined).Underlined text: `instanceName : ClassName`.
Data RepresentationDeclares attribute names and types without specific values.Shows specific assigned attribute values (`balance = 5000`).
Relationship NotationAssociations with multiplicity strings (`1..*`, `0..1`).Concrete Links without multiplicity numbers.
Abstraction LevelHigh level of abstraction covering all possible system states.Low level of abstraction showing a single discrete state instance.
Temporal DimensionTime-invariant; represents permanent structural rules.Time-variant; represents system state at time $t$.
Primary Engineering RoleSystem design, code generation, and schema construction.Testing, debugging, validating class diagram multiplicity rules.

⚡ Quick Pre-Exam Revision Summary

5-Minute Recap
💡 Core Takeaways & High-Yield Summary
  • Class notation: 3 compartments (Name, Attributes, Operations). Visibility: `+` (public), `-` (private), `#` (protected), `~` (package).
  • Relationships: Association (solid line), Aggregation (hollow diamond), Composition (filled diamond), Generalization (hollow triangle), Dependency (dashed arrow), Realization (dashed hollow triangle).
  • Extensibility mechanisms: Stereotypes (`« »`), Tagged Values (`{key=val}`), Constraints (`{OCL}`).
  • Aggregation is weak whole-part (independent lifetime); Composition is strong whole-part (cascading lifetime).
  • Object diagrams represent runtime instance snapshots; object names MUST be underlined.
← Previous: Unit II
Next: Unit IV →