Model Structure and the Use of Views

Part 4 at a glance: Domain Model and Use Case Model provide two axes for organizing a Model and composing Capabilities and Aspects. The Object Model is the explanatory focus for formal structure, while purpose-selected Views are used to work with the complex Model.

Part 3 organized the relationship of the Object, Knowledge, and Literate Models to the Domain Model. Part 4 takes Model structure as its subject, reads Domain Model and Use Case Model as two axes, and explains how purpose-specific Views are used to work with that complex structure. The Object Model is central to the explanation of formal structure, while the relationship to the three Models is connected after the two axes and View System have been established.

Part 4 centers Model structure and the use of Views. It uses the Object Model to explain formal structure, organizes Domain Model and Use Case Model as two axes, and later relates them to the Object, Knowledge, and Literate Models. It distinguishes Application Modeling, which organizes Use Case realization as dynamic structure, from Model Realization, which connects approved Models to implementation and execution.

Previous article: 📄 Modeling Technology System

Reality includes the current state, historical development, future possibilities, tacit rules, exceptions, multiple interpretations, and unobserved facts. A Model represents the subset required by the Purpose and Concerns of its Bounded Context.

Information included in and omitted from a Model is determined by its Purpose and Concerns. Recording excluded scope, assumptions, and granularity makes the selection reviewable. The Model boundary represents the range of questions that the Model addresses.

A Bounded Context is the domain-side semantic boundary within which language, meaning, rules, and responsibilities remain coherent. It selects the required scope from Reality, normalizes language, organizes concepts and rules, and distills them into a Model that can connect to execution.

Bounded Context represents the domain-side semantic boundary. Execution Context represents the platform-side environment of runtime, resource, transaction, security, and deployment conditions under which a Model executes.

Purpose states the decision, communication, transformation, or execution for which a model will be used. Even for the same business subject, different information is needed for a model that aligns terminology, one that validates business rules, one that implements state transitions, and one that analyzes operational failures.

A Concern is a question or interest that the model must address to fulfill its Purpose. “Who owns this rule?”, “Which state transitions are permitted?”, “What evidence supports this decision?”, and “Can processing continue during a failure?” are different Concerns. Listing Concerns makes both model content and validation conditions concrete.

A Perspective is the position and selection rule used to examine a subject. It can reflect stakeholder positions such as user, domain practitioner, developer, or operator, as well as contrasts such as present versus future, structure versus behavior, concept versus implementation, and whole versus detail.

A Viewpoint is a reusable set of conventions for repeatedly constructing, interpreting, and evaluating a kind of View. It defines the Concerns addressed, model kinds, notations, analysis methods, and consistency rules. A Perspective supplies where the subject is viewed from; a Viewpoint makes the rules for producing and reading a View reusable.

This distinction aligns with ISO 42010:2022, in which an Architecture View addresses specific Concerns and an Architecture Viewpoint establishes conventions for constructing, interpreting, and using Views. SimpleModeling extends that idea beyond Architecture to modeling activities in general.

Constructing the Model and constructing a View have different roles. Model construction selects and transforms what a Bounded Context needs from Reality and organizes it into a structure of meanings, identities, rules, and behavior. When working with the Model, a Perspective and Viewpoint select what must be examined and expose it as a View.

Model construction and View selection record the selected information together with exclusions, assumptions, granularity, time horizon, and selection rules. These records support evaluation of the Model boundary and the Views required for the current Purpose. Omissions and contradictions found through a View are reflected in the Model structure and the understanding of Reality as needed.

A Model carries concepts, relationships, rules, constraints, and the state changes, Commands, Events, Workflows, Policies, Calculations, and Decisions required by its Bounded Context. It is used as a working abstraction connected to implementation, evaluation, knowledge, and operation.

As capabilities accumulate, the number of relationships among concepts, behavior, constraints, and qualities in the Model also increases. A diagram containing too much information makes the abstraction required for a Purpose harder to identify. Purpose- and concern-selected Views delimit the subject of examination.

SimpleModeling treats Domain Model and Use Case Model as two axes of Model composition. The Domain Model supplies an axis of meaning through concepts, relationships, rules, and decisions; the Use Case Model supplies an axis of intent through Actors, Goals, Scenarios, and Outcomes. The two peer, orthogonal axes compose and examine elements of the same Model from different directions. This article centers the Object Model in the explanation to make formal structure concrete and clarify continuity with UP.

The two axes compose Capability and Aspect as explicit Model elements. A Capability states what the Model can do and organizes Commands, Events, Workflows, Policies, Decisions, and related behavior into one identifiable unit. An Aspect states the conditions under which that Capability holds and overlays quality conditions such as Performance, Observability, Security, and Reliability. As conditions on a Capability, Aspects are designed and evaluated together with that Capability.

A Glossary manages the names, meanings, boundaries, synonyms, and identifiers of the Ubiquitous Language and supplies the same vocabulary and IDs to both the Domain Model and Use Case Model. This vocabulary and these IDs trace conceptual identity across narrative text, formal Model elements, multiple Views, tests, and implementation.

Shared IDs preserve conceptual identity when display names change or when different Views expose different information. The Glossary is the semantic backbone connecting the Domain and Use Case Model axes, Model elements, and the View System.

A View is an inspectable representation used to extract the elements, relationships, behavior, and qualities required by a Purpose and set of Concerns when understanding, evaluating, or applying a complex Model. Diagrams, prose, tables, CML, glossaries, Knowledge Graphs, and execution traces can serve as its representation. The meaning and identity of a View refer to the Model and Glossary.

A Domain View exposes the Ubiquitous Language, concepts, relationships, rules, and boundaries required by a Purpose from the Domain Model meaning axis. It serves as a semantic reference among Views by mapping Actors, Goals, Capabilities, states, Events, and quality-related subjects to the same elements of the Model.

Each View exposes the abstraction required by its Purpose and maps names, identifiers, rules, and boundaries to the Domain View and Glossary. These mappings trace the part of the same Model addressed by each View.

A Use Case View follows an Actor’s Goal through Scenarios and connects the Capabilities supplied by the Model to observable Outcomes and exceptions. The Domain View shows what subjects mean, while the Use Case View shows for whom an outcome is achieved and how Model capabilities are used. The Use Case View is positioned as a peer of the other Views.

Quality-attribute Views expose cross-cutting conditions such as Reliability, Performance, Security, Operability, Observability, and Evolvability, organized by Concern. They overlay the Domain and Use Case Views to examine the load, failure, authorization, operational, and change conditions under which Capabilities remain effective.

The connection between a Use Case View and the wider development process is established by the information structure of its underlying Use Case Model. A Use Case Model preserves Actors, Goals, Scenarios, and Outcomes as one narrative with a Use Case ID. Outcomes map to Capabilities and implementation, Scenarios and Outcomes to acceptance criteria and test cases, Actors and Scenarios to manuals, and the Use Case ID to development-process work units and progress management.

For example, an order-confirmation narrative identified as UC-ORDER-01 connects its natural-language Goal and Scenarios to Capability, Code, Acceptance, Test, Manual, and Development Process artifacts. These mappings provide an axis for tracing changes across development. The Use Case Model supports both requirements explanation and direct mapping from narrative to implementation artifacts.

A View Catalog is an open set that expands according to the purposes for examining a Model. In addition to Domain and Use Case Views, it can register quality-attribute Views such as Performance, Observability, Security, Reliability, Availability, and Testability. Purpose and Concerns select the required Viewpoint, whose conventions construct the View from the Model.

Views are constructed by selecting those required by the Purpose. For View Groups and Viewpoints, only the required intersections are materialized as Views.

SimpleModeling is built on the UP (Unified Process) and inherits its 4+1 Views—Logical, Process, Development, Deployment, and Scenario—as five selectable Architecture View Groups. A View Group is a family of architectural concerns; the concrete Views within each Group are selected according to Purpose.

The SimpleModeling extension is that Viewpoints such as Domain, Performance, and Observability can cut across multiple View Groups. A Performance Viewpoint can, for example, construct the purpose-required Performance Views of the Logical, Process, Deployment, or other Groups and combine them as a Composite Performance View. This preserves the UP structure while extending it into a View System that traces Domain and quality-attribute Concerns across Groups.

Domain, Use Case, Application, and quality-attribute Views can be composed as complementary Views of the same Model. A Domain View emphasizes problem-domain meaning, structure, rules, and boundaries, while an Application View emphasizes Use Case realization, Collaborations, Interactions, state transitions, Events, Services, and Operations. Each addresses different Concerns.

Concepts, boundaries, rules, and identifiers shared by multiple Views have explicit correspondences. A Glossary connects names and meanings, while mappings and reference links identify relationships among Model elements. Items without a correspondence identify areas for re-examining the understanding of Reality, View-selection conditions, or Model representation.

SimpleModeling evaluates the quality of Models and Views using four criteria: Clarity, Consistency, Validity, and Accuracy.

Tools and AI can broadly support checks for clarity and consistency. Validity and accuracy require users who hold the Purpose, domain experts, observations, and execution results. SimpleModeling distinguishes making structures precise from guaranteeing correctness with respect to Reality.

These four qualities are criteria for evaluating Models and Views. Quality-attribute Views expose properties such as Reliability and Security that the Model must realize. Evaluation criteria and the quality attributes being visualized have separate roles.

Models and Views are updated iteratively. Reality is distilled into a Model according to the Purpose and Concerns of a Bounded Context; Views are constructed according to Perspectives and Viewpoints; and scenarios, reviews, tests, and execution results evaluate them. Omissions and contradictions are reflected in the Views, Model, Bounded Context boundary, Concerns, View-selection rules, and the understanding of Reality.

Through this loop, a Model functions as a working abstraction updated by knowledge and execution results.

Part 4 takes the Model as its subject and centers the Object Model when explaining formal structure. The later section organizes the three SimpleModeling Model constituents, the purpose-specific Domain, Use Case, and Application Models built from them, and the realization path.

Domain Modeling organizes the meaning, structure, rules, and boundaries required by a Purpose and set of Concerns from the three constituents as a Domain Model. Use Case Modeling organizes Actors, Goals, Scenarios, and Outcomes as a Use Case Model. Application Modeling organizes the dynamic structures needed for Use Case realization as an Application Model. Shared Object Model elements and Glossary IDs map these applied Models and their Views to each other.

Application Modeling constructs a Use Case Realization Model from a Use Case Scenario in the Literate Model and maps it through Collaborations and Interactions to StateMachines, Events, Services, and Operations. Domain Modeling emphasizes static aspects and Application Modeling emphasizes dynamic aspects, but they are not treated as completely exclusive categories.

Model Realization connects approved executable formal structures to CML, implementation, tests, and runtime environments. Gaps found in reviews, tests, and execution are reflected in Object-centered structures, Knowledge Model evidence, Literate Model context and intent, the Bounded Context, the Application Model, and View selection.

AI infers unspecified Purpose, Concerns, Perspective, and granularity from a request. Users state these selection conditions and compare them with those applied by the AI. Generated results are reviewed together with the question that each View was constructed to address.

When the Bounded Context, Purpose, Concerns, Perspective, Viewpoint, exclusions, and requested View are explicit, AI can explore the Model under those selection conditions and present candidate abstractions and correspondences as a View. People review the validity of the selection for the Purpose and its accuracy with respect to Reality. The review covers the generated result, the Model of the referenced Bounded Context, and the constructed View.

This article organized Model structure and the use of Views, using the Object Model as the center of the formal-structure explanation. Purpose-specific Domain, Use Case, and Application Models are composed from Object, Knowledge, and Literate contributions, and the complex Model is handled through Views that inherit and extend UP 4+1. Application Modeling organizes dynamic Use Case realization, while Model Realization connects approved Models to implementation and execution. The next article examines the Object Modeling techniques of Objects, Types, Constraints, responsibilities, and Collaborations.