Skip to content

Software Engineering Principles and Patterns

Graduate / PhD course on principled software design, architecture, patterns, anti-patterns, smells, refactoring, and automated software transformation.

Instructor: Morteza Zakeri
Course philosophy: design decisions must be explainable, testable, and evolvable.

Why this course?

A design pattern is not a recipe to apply mechanically. A principle is not a slogan. An architecture is not a diagram. At graduate level, software design is studied as a sequence of constrained decisions whose consequences can be observed in maintainability, changeability, testability, understandability, performance, security, and development cost.

This course studies those decisions at three connected levels:

  • Principles & architecture

    Information hiding, modularity, cohesion/coupling, SOLID/GRASP, dependency direction, boundaries, architecture tactics, and trade-off analysis.

  • Patterns, smells & evolution

    GoF and architectural patterns, pattern languages, anti-patterns, design smells, refactoring, and refactoring to patterns.

  • Automation & research

    Static analysis, graph representations, pattern/smell detection, search-based refactoring, program transformation, ML/RL/LLM-assisted design, and empirical evaluation.

Course thesis

Good software design is not the maximum number of patterns. It is the minimum structure that makes the important changes easy, the important qualities measurable, and the design intent recoverable.

The course repeatedly asks four questions:

  1. What design problem are we solving?
  2. What forces and quality attributes constrain the solution?
  3. What evidence supports this design or transformation?
  4. How can part of the reasoning be automated without losing semantic correctness?

Intellectual trajectory

graph LR
  A[Principles] --> B[Architecture]
  B --> C[Patterns]
  C --> D[Anti-patterns & Smells]
  D --> E[Refactoring]
  E --> F[Refactoring to Patterns]
  F --> G[Automated Detection]
  G --> H[Automated Transformation]
  H --> I[Empirical Evaluation]

What students will do

By the end of the course, students should be able to move comfortably between source code, design models, dependency graphs, architecture descriptions, and research evidence. Typical work includes:

  • critiquing a design using explicit principles rather than taste;
  • recognizing both appropriate and inappropriate uses of patterns;
  • diagnosing design and architecture smells;
  • planning a behavior-preserving refactoring path toward a pattern;
  • mining structural/semantic evidence for pattern instances;
  • designing an automated refactoring or recommendation technique;
  • evaluating a technique on real software with defensible metrics and baselines;
  • writing a compact research report and reproducibility package.

Graduate-level expectation

The course assumes students can already program and understand object-oriented design. Class time is used for design reasoning, comparative analysis, research discussion, and automation—not introductory programming instruction.

Quick access

Suggested course rhythm

Each topic follows a recurring cycle:

Read → Model → Debate → Implement → Measure → Reflect

A lecture introduces concepts and trade-offs; a seminar or lab exposes failure modes; an assignment asks for justified application; and the research project asks whether a part of the process can be detected, recommended, transformed, or evaluated automatically.