| Lesson 7 | Logical View |
| Objective | Define the purpose and function of the logical view |
Logical View: Purpose, Function, and Modern Domain Modeling
The logical view constitutes UML's most comprehensive perspective, encompassing six diagram types modeling conceptual design from multiple complementary angles—domain structure through class diagrams, runtime snapshots via object diagrams, message flows using sequence and communication diagrams, lifecycle behavior through state machines, and workflow processes with activity diagrams. This multi-diagram richness enables modeling every aspect of software solution independently of implementation technology—the word "logical" signifies conceptual design abstraction rather than physical realization. Understanding the logical view's purpose and function requires examining both its constituent diagrams and why Domain-Driven Design significantly enhanced logical modeling through tactical patterns (entities, value objects, aggregates, domain events) providing richer vocabulary than basic UML classes. Contemporary practice selectively applies logical view diagrams where formal notation serves needs—complex domain models requiring precise relationship specification, architectural patterns needing documentation, interaction protocols demanding temporal clarity—while using Event Storming for collaborative domain discovery, executable BDD scenarios for behavior validation, and architecture-as-code for living documentation synchronized with implementation rather than comprehensive upfront logical modeling across all diagram types.
Purpose of the Logical View
The logical view's purpose centers on capturing conceptual design—domain concepts, their relationships, and behavioral semantics—independent of implementation decisions. This technology neutrality proves valuable during analysis when understanding problem domain matters more than selecting frameworks, databases, or deployment platforms. A banking domain model identifying Account, Transaction, Customer entities and their relationships (Account has Transactions, Customer owns Accounts) applies regardless whether implementation uses Java or C++, Oracle or PostgreSQL, monolith or microservices. Deferring implementation decisions until understanding domain thoroughly prevents premature technical commitments constraining design options.
The logical view supports progressive elaboration throughout software lifecycle. **Analysis** produces domain model identifying business concepts relevant to problem—e-commerce: Product, Order, ShoppingCart; healthcare: Patient, Diagnosis, Treatment. **Design** refines model adding solution concepts—design patterns (Factory, Strategy, Observer), technical services (logging, caching, security), architectural layers (presentation, business, persistence). **Implementation** further elaborates with technology-specific details—framework base classes, database mapping annotations, exception types. This incremental refinement enables starting simple and adding complexity only as understanding deepens, avoiding comprehensive modeling paralysis.
Function: Six Complementary Diagram Types
**Class diagrams** form the logical view's foundation, modeling domain structure through classes (types defining attributes and operations), associations (semantic relationships enabling communication), aggregation and composition (whole-part relationships), generalization (inheritance hierarchies), and dependencies (usage relationships). Class diagrams serve multiple functions: conceptual domain model during analysis, detailed design specification, code generation source, reverse engineering target. The same diagram notation spans abstraction levels—analysis-level domain concepts ("Order has OrderItems") refine into design-level implementation details (Order class with addItem() operation and items collection attribute). This versatility explains class diagrams' ubiquity—nearly every object-oriented project uses them, even teams abandoning other UML diagrams.
**Object diagrams** illustrate specific instance configurations at particular moments—snapshots showing concrete objects and their runtime relationships. While class diagrams model abstractions (Customer class can have many instances), object diagrams show specifics (customer "Alice" with customerId=12345 related to order "ORD-789"). Object diagrams clarify complex class diagrams by providing concrete examples—design pattern documentation often includes object diagrams demonstrating pattern application scenarios. However, object diagrams saw limited practical adoption—most teams sketch informal instance examples during whiteboard discussions rather than creating formal object diagrams in modeling tools.
**Sequence diagrams** model object interactions emphasizing temporal ordering—messages arranged vertically by time showing who calls what when. These diagrams excel at documenting interaction protocols where precise message sequencing matters: authentication flows (client requests token, server validates credentials, server returns JWT), distributed transactions (coordinator sends prepare, participants vote, coordinator commits or aborts), error recovery sequences (detect failure, notify observers, rollback state, retry operation). Sequence diagrams survived UML's agile reckoning better than most diagram types because they address genuine need—complex temporal protocols resist clear explanation through prose alone.
// Sequence Diagram: OAuth Authentication Flow
User Client App Auth Server Resource Server
│ │ │ │
│ 1. Request │ │ │
├───────────────>│ │ │
│ │ 2. Redirect │ │
│ ├─────────────>│ │
│ │ │ │
│ 3. Login │ │ │
├───────────────────────────────>│ │
│ │ │ │
│ │ 4. Auth Code│ │
│<───────────────────────────────┤ │
│ │ │ │
│ 5. Code │ │ │
├───────────────>│ │ │
│ │ 6. Token Req │ │
│ ├─────────────>│ │
│ │ │ │
│ │ 7. JWT │ │
│ │<─────────────┤ │
│ │ │ │
│ │ 8. API Request + JWT │
│ ├──────────────────────────────>│
│ │ │ │
│ │ 9. Validate JWT │
│ │ │<───────────────┤
│ │ │ │
│ │ 10. Protected Resource │
│ │<──────────────────────────────┤
// Temporal precision justifies formal sequence diagram
// Prose description would be ambiguous and error-prone
**Communication diagrams** (formerly collaboration diagrams) show interactions emphasizing structural organization over temporal sequence. Where sequence diagrams arrange messages vertically by time, communication diagrams arrange objects spatially by structural relationships, numbering messages to indicate ordering. Communication diagrams suit scenarios where relationship topology matters more than precise temporal sequence—showing how objects in composite structure collaborate, documenting design pattern implementations emphasizing object roles. However, most teams found sequence diagrams more intuitive, making communication diagrams the least-used interaction diagram type.
**State machine diagrams** model entity lifecycle—states an object occupies and event-triggered transitions between states. These diagrams excel at modeling stateful behavior where correctness depends on explicit state management: order processing (states: Draft, Submitted, Confirmed, Shipped, Delivered; transitions: submit, confirm, ship, deliver), connection protocols (Disconnected, Connecting, Connected, Disconnecting), device control (Off, Initializing, Ready, Processing, Error). State machines specify transition guards (conditions enabling transition), actions (operations executed during transition), and entry/exit behaviors (operations when entering/leaving states). This formalism enables detecting illegal state transitions at design time rather than discovering them through runtime failures.
// State Machine: Order Lifecycle
[Customer submits]
┌────────┐ ──────────────> ┌──────────┐
│ Draft │ │Submitted │
└────────┘ └──────────┘
^ │
│ [Cancel] │ [Payment confirmed]
│ v
│ ┌──────────┐
│ │Confirmed │
│ └──────────┘
│ │
│ │ [Inventory allocated]
│ v
│ ┌──────────┐
└──────────────────────│ Shipped │
[Delivery fails] └──────────┘
│
│ [Delivered successfully]
v
┌──────────┐
│Delivered │
└──────────┘
// Guards ensure valid transitions:
// - Cannot ship unconfirmed order
// - Cannot deliver unshipped order
// - Can cancel only before shipping
**Activity diagrams** model workflows and business processes using flowchart-like notation enhanced for concurrency, object flows, and exception handling. Activities represent actions, decision nodes show conditional branching, fork/join nodes express parallel flows, swimlanes assign activities to responsible actors. Activity diagrams suit business process documentation (order fulfillment workflow, loan approval process), algorithm specification (search procedures, validation routines), and concurrent workflow modeling (parallel build steps, distributed processing). However, Business Process Model and Notation (BPMN) largely replaced UML activity diagrams for business process modeling, offering business-specific notation richer than UML's general-purpose constructs.
Domain-Driven Design Enhancement
**Domain-Driven Design** (Eric Evans, 2003) significantly enhanced logical view expressiveness through tactical patterns providing richer domain modeling vocabulary than basic UML classes and associations. **Entities** possess identity persisting over time regardless of attribute changes—Customer with customerId remains same customer despite address updates. **Value Objects** lack identity, defined entirely by attributes—Money(100, USD) equals any other Money(100, USD). **Aggregates** establish consistency boundaries grouping related entities under single root controlling access—Order aggregate contains OrderItems with Order as root enforcing business invariants across both. **Domain Events** capture significant occurrences—OrderPlaced, PaymentProcessed, InventoryReserved—enabling event-driven architecture. **Repositories** abstract persistence providing collection interface hiding database mechanics—OrderRepository.findById(orderId).
DDD patterns express naturally in UML class diagrams using stereotypes. «Entity» classes have identity attributes. «ValueObject» classes are immutable with value-based equality. «Aggregate» boundaries shown through composition relationships. «DomainEvent» classes capture state changes. «Repository» classes provide persistence interfaces. This stereotype-based extension demonstrates UML's extensibility—domain-specific vocabulary layered atop core notation without modifying metamodel. Modern teams practicing DDD commonly use class diagrams documenting tactical design while relying on Event Storming for strategic modeling (bounded contexts, context mapping, ubiquitous language).
// DDD Tactical Patterns in UML Class Diagram
«Entity»
class Order {
- orderId: OrderId // Identity (immutable)
- customerId: CustomerId
- items: List<OrderItem>
- status: OrderStatus
- total: Money
+ placeOrder(): void
+ addItem(item: OrderItem): void
+ removeItem(itemId: OrderItemId): void
+ calculateTotal(): Money
// Invariant: Order must have at least one item
// Invariant: Total equals sum of item prices
}
«ValueObject»
class Money {
- amount: BigDecimal
- currency: Currency
+ add(other: Money): Money
+ multiply(factor: BigDecimal): Money
+ equals(other: Money): Boolean
// Immutable: operations return new instances
// Equality: by value, not reference
}
«ValueObject»
class OrderId {
- value: UUID
// Immutable identifier
}
«Entity»
class OrderItem {
- itemId: OrderItemId // Identity within aggregate
- productId: ProductId
- quantity: Integer
- price: Money
+ changeQuantity(newQuantity: Integer): void
}
«Aggregate»
Order "1" *-- "*" OrderItem // Composition: items owned by Order
Order "1" -- "1" Money // Order has total as value object
«DomainEvent»
class OrderPlaced {
- orderId: OrderId
- customerId: CustomerId
- timestamp: Instant
- items: List<OrderItemSnapshot>
}
«Repository»
interface OrderRepository {
+ save(order: Order): void
+ findById(orderId: OrderId): Optional<Order>
+ findByCustomer(customerId: CustomerId): List<Order>
}
// DDD patterns provide:
// - Clear identity semantics (Entity vs ValueObject)
// - Consistency boundaries (Aggregate)
// - Event-driven behavior (DomainEvent)
// - Persistence abstraction (Repository)
What Modern Practice Replaced
**Event Storming** (Alberto Brandolini, 2013) largely replaced comprehensive logical view modeling for domain discovery and strategic design. Teams gather at long wall with unlimited colored sticky notes: orange for domain events (OrderPlaced, PaymentFailed), blue for commands triggering events (PlaceOrder, ProcessPayment), yellow for aggregates (Order, Payment), pink for external systems, purple for business policies, red for pain points and questions. Facilitators guide temporal event ordering on timeline, surfacing complexity, conflicts, and bounded context boundaries through collaborative discussion. Event Storming excels at strategic domain modeling—identifying aggregate boundaries, discovering ubiquitous language, exposing organizational silos, revealing missing concepts—that upfront UML class diagrams struggle to uncover.
Event Storming and UML logical view complement rather than compete. Event Storming provides collaborative discovery methodology UML lacks—workshop format engaging diverse stakeholders (developers, domain experts, product owners) where solitary UML modeling excludes non-technical participants. After Event Storming surfaces domain structure, teams translate discoveries into UML class diagrams documenting tactical design—aggregates become classes with composition relationships, domain events become event classes, commands become operations. This hybrid approach combines Event Storming's collaborative discovery with UML's precise documentation.
**Architecture Decision Records** (ADRs) and executable specifications address documentation drift plaguing static logical view diagrams. ADRs capture architectural decisions as versioned markdown documents explaining context, decision, and consequences—living documentation evolving with system rather than becoming obsolete artifacts. **BDD scenarios** in Gherkin provide executable behavior specifications validated through automated testing, ensuring logical view behavioral documentation stays synchronized with implementation. Tools generating class diagrams from code (IDE diagram viewers, PlantUML from source annotations) create living structural documentation automatically reflecting current code state rather than manual diagrams diverging from reality.
Selective Modern Application
Modern teams apply class diagrams selectively where complex domain models require precise specification. **Domain-Driven Design contexts** with intricate aggregate structures, value objects, and entity relationships benefit from explicit class diagrams documenting tactical patterns. **Framework extension points** requiring interface compliance document expected structure through class diagrams. **Legacy system documentation** reverse-engineers class diagrams from code providing architectural maps. **Regulatory compliance** projects create class diagrams satisfying traceability requirements. Simple CRUD applications skip class diagrams entirely—database schema provides sufficient documentation.
Sequence diagrams document complex interaction protocols resisting clear prose explanation. **Authentication and authorization flows** (OAuth, SAML, JWT validation) show precise message sequencing preventing security vulnerabilities. **Distributed transactions** (two-phase commit, saga patterns) clarify coordinator-participant interactions. **Error recovery protocols** (retry logic, circuit breakers, fallback handling) make temporal dependencies explicit. **Integration patterns** (API choreography, event-driven workflows) document cross-service interactions. Teams create sequence diagrams for these scenarios while skipping them for straightforward request-response interactions.
State machine diagrams model systems where correctness depends on explicit state management and illegal state transitions cause failures. **Order processing workflows** with complex state transitions (draft, submitted, confirmed, shipped, delivered, cancelled, refunded) benefit from state machine precision. **Connection protocols** (TCP, WebSocket) specify connection lifecycle formally. **Device control systems** (embedded firmware, industrial automation) require state machine specifications for safety certification. Simple entities with trivial state (active/inactive flags) don't justify formal state machines.
Modern Tooling
**PlantUML** supports all logical view diagram types through text-based DSL enabling version control and automated generation. Class diagrams, sequence diagrams, state machines, and activity diagrams all expressible in concise syntax compiled to images during build. This diagrams-as-code approach integrates logical view documentation into development workflow—diagrams version controlled with code, updated through pull requests, generated in CI/CD pipelines, embedded in Markdown documentation.
**Mermaid.js** renders logical view diagrams directly in browsers from Markdown syntax. GitHub, GitLab, and documentation sites natively support Mermaid, making logical view diagrams accessible without external tools. The syntax prioritizes readability over UML specification compliance—`Customer--|>Person: inherits` for generalization—enabling developers to create diagrams without deep UML knowledge while maintaining semantic clarity.
**Structurizr** and similar architecture-as-code tools generate logical view diagrams from code structure or DSL definitions. Define architecture once in code, generate multiple diagram views automatically. This automation addresses documentation drift—diagrams always reflect current architecture because generated from authoritative source. The approach works particularly well for component and deployment views, with experimental support for dynamic logical view generation.
Integration with Agile Development
Agile teams practice "just enough" logical view modeling—creating diagrams where value exceeds overhead rather than comprehensive coverage. **Sprint planning** might sketch class diagrams for complex features requiring team alignment. **Refinement sessions** create sequence diagrams for intricate workflows needing shared understanding. **Architecture decisions** document key design patterns through class diagrams in ADRs. **Retrospectives** update state machines when workflow complexity emerges. This incremental, value-driven modeling contrasts with upfront comprehensive logical view creation that waterfall methodologies prescribed.
Modern logical view evolves continuously rather than existing as static upfront specification. **Initial modeling** creates just enough design to start coding. **Emergent complexity** triggers diagram updates when assumptions prove incorrect. **Refactoring** adjusts logical view reflecting structural changes. **Knowledge capture** adds diagrams when team members need shared understanding. This evolutionary approach matches agile's embrace of change rather than fighting it through rigid upfront documentation.
Conclusion
The logical view's purpose—modeling conceptual design through complementary diagram perspectives—remains fundamentally sound. Its six diagram types address genuine needs: class diagrams document structure, sequence diagrams clarify temporal protocols, state machines specify lifecycle behavior, activity diagrams model workflows. Domain-Driven Design enhanced logical view expressiveness through tactical patterns providing richer vocabulary than basic UML. However, contemporary practice evolved how logical view serves: Event Storming provides collaborative domain discovery UML's solitary modeling lacks. BDD scenarios offer executable validation preventing documentation drift. Architecture-as-code generates living documentation synchronized with implementation. PlantUML and Mermaid democratize diagram creation through text-based tooling. Modern selective application creates class diagrams for complex domains, sequence diagrams for intricate protocols, state machines for stateful entities—using diagrams where formal precision provides value rather than attempting comprehensive coverage across all types. Understanding logical view's diagram types, purposes, and modern alternatives enables informed architectural documentation decisions matching contemporary workflows. The logical view concepts—structural abstraction, behavioral specification, interaction modeling—persist across all approaches, demonstrating enduring value even as specific techniques evolve from heavyweight CASE tools toward lightweight, version-controlled, collaborative modeling integrated with agile development practices.
In the next lesson, the component view for modeling units of software according to function will be discussed.