Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Object and Package Diagrams: Runtime Snapshots and the Dependency Map of a .NET Solution
An object diagram draws concrete instances and links at a given moment and catches multiplicity mistakes in a class diagram, while a package diagram shows dependencies between projects and makes layer violations visible. In this post the snapshot of request #42 exposes a wrong 0..1, and the solution's package diagram is generated from the csproj files so an EF Core dependency leaking into Domain is caught in CI.
From Class Diagram to Code and Back: Domain Model, Design Model and puml-gen
A domain model shows business concepts without types or operations, while a design class diagram shows the C#-level design decisions for the same case; the first is drawn by hand, slices of the second become code, and diagrams generated from code with tools like puml-gen are for observation and drift checks only. The post takes the HR Portal leave module from diagram to EF Core configuration and DDL, then back to PlantUML with puml-gen.
Class Diagrams 2: Association, Aggregation, Composition, Generalization and Dependency — with C# Equivalents
An association is a lasting link and becomes a navigation property in C#; in a composition the part has one owner and is deleted with it, which in EF Core means an owned or complex type or cascade delete; aggregation has no precise meaning in UML 2.5.1. The notation and C# counterpart of six relationships, EF Core's cascade default on required relationships, qualified associations, and why Approval is promoted from an association class to a class of its own.
Class Diagrams 1: Classes, Attributes, Operations, Visibility, Multiplicity and Stereotypes
Every marker in a class diagram is a decision in code: [0..1] is a nullable type, [0..*] a collection, a slash a computed property, an underlined line a static member, and {readOnly} a field that never changes. The three compartments of a class box, attribute and operation syntax, the corners where visibility does not match C#, interfaces, enumerations, data types and stereotypes, and the same diagram in Mermaid.
Use Case Diagrams and Specifications: Actors, include, extend and the Cockburn Template
A use case diagram shows the system from outside: actors are roles, use cases are goals; the include arrow goes from the base to a mandatory step, the extend arrow from a conditional addition to the base. The HR Portal leave module's use case diagram, the Request Leave specification in Cockburn's fully dressed template, mapping use cases to user stories and API endpoints, and the same diagram in Mermaid.
From Requirements to Diagrams: Which Question Does Each Diagram Answer?
Every diagram answers one question: use cases answer who does what, class diagrams which concepts exist, sequence diagrams who calls whom, and state machines which states an object goes through. The requirements of the HR Portal Leave Request module, extracting candidate classes, use cases and guards from nouns, verbs and conditions, choosing the level of detail by audience, and the map of the series.
What Is UML? A Short History, the 14 Diagrams of UML 2.5.1 and Which Ones You Will Actually Use
UML is the OMG's standard modeling language for putting the model scattered through your code into a notation everyone reads the same way; its current version is UML 2.5.1 from 2017, which defines 14 diagrams, 7 structure and 7 behavior. A short history from the method wars, the diagrams people actually use, the difference between model and diagram, and Fowler's sketch, blueprint and programming language modes.