Modeling Technology System

Part 3 at a glance: the methodological relationship in which one Domain region overlaps adjacent Object, Knowledge, and Literate Models, while a Glossary ring connects the mixed-color overlaps to form one Domain Model View according to purpose and concern.

Part 1 explained that AI makes the Domain Model a working abstraction with a realization path to implementation, making modeling the new choke point of development. Part 2 examined how SimpleModeling has constructed a path from Knowledge to Executable Software through CML, Cozy, AI, and Textus.

Part 3 determines what is modeled along that path and where existing software-engineering technologies are placed. It defines the roles and dependencies of later Object, Knowledge, and Literate Modeling, the purpose-specific Domain, Use Case, and Application Modeling activities, and Model Realization.

Previous article: 📄 What SimpleModeling Has Pursued

Organizing existing technologies and defining a development approach are different activities.

SimpleModeling is a Software Development Methodology. Rather than covering every technology in a knowledge system, it selects technologies needed for modeling-centered development and defines their roles and realization path.

The relationship from a Knowledge System to a Methodology therefore is not a sequence of four equal stages—collect, organize, select, and practice. The Knowledge System supplies candidate technologies and a map for understanding them; the Methodology decides what to adopt, what role to assign, and how to use it. A Development Process then defines how a project operates the transformations and decisions established by the Methodology. Separating process styles such as Agile, Iterative, and Staged from the Methodology itself allows the same methodology to be applied across different projects.

Earlier SimpleModeling treated a Domain Model as part of an Object Model. The current Domain Model, which also uses Knowledge Modeling and a Literate Model, does not bundle three whole models. In the diagram, Object, Knowledge, and Literate Models appear as three adjacent ellipses, with one Domain region overlaid at their center. Its overlap with the Object Model contributes formal structure; the overlap with the Knowledge Model contributes knowledge structure and evidence; and the overlap with the Literate Model contributes natural-language context, intent, and free-form structure. Reading these overlaps as one View of the problem domain according to purpose and concern yields the Domain Model.

The mixed colors in the overlaps are not decorative. By combining the color of each source model with that of the Domain region, they distinguish what each model contributes to the Domain Model. The non-overlapping areas show that the whole of each model is not incorporated into the Domain Model.

An Application Model is likewise not a fourth constituent. It is a purpose-specific Model that organizes the elements required from the Object, Knowledge, and Literate Models according to the Purpose and Concerns of realizing a Use Case through participants, responsibilities, Collaborations, Interactions, state transitions, Events, Services, and Operations.

Application Modeling constructs a Use Case Realization Model from a Use Case Scenario in the Literate Model. A Collaboration describes the structure of participants, Roles, and responsibilities, while an Interaction provides a concrete execution example. Their mappings lead to StateMachines, Events, Services, and Operations, and the executable portion connects to CML. This semantic construction and review constitute Application Modeling; the subsequent path from CML to programs and an execution foundation is Model Realization.

The overlaps between one Domain region and the Object, Knowledge, and Literate Models represent concepts from the same problem domain in different forms. If concept meaning or identity diverges across the overlaps, they cannot be read as one Domain Model View.

The Glossary manages term names, meanings, boundaries, synonyms, and identifiers. By mapping concepts appearing in each overlap to shared terms, it connects concept identity and meaning across formal structures, knowledge structures, and literate narratives. The infographic depicts the Glossary as a ring rather than an arrow or a later process step because this connection surrounds the three overlaps simultaneously and keeps them coherent as one View.

The three models, their overlaps with the Domain region, and their connection through the Glossary are not established once in a fixed order. Omissions and contradictions found while structuring objects, organizing knowledge, explaining through documents, or concretizing execution are returned to the Glossary and each model, and the View is iteratively updated against its purpose and concern.

This 2D composition contains no convergence arrows from the three models to a Domain Model. The Domain Model is not another box produced at the end of a transformation sequence; it is the overlaps of one Domain region with the three models, understood as one problem-domain View.

Practical software requires not only business functions but also quality attributes such as Security, Observability, Performance, Resiliency, and Availability. Quality attributes are not assigned to one particular Model. They are cross-cutting design concerns examined against requirements and constraints identified in the Object, Knowledge, Literate, Domain, and Application Models.

In SimpleModeling, Domain Logic and application-specific policies are application responsibilities, while common mechanisms such as authentication, instrumentation, failure handling, and execution control are primarily Textus responsibilities. Instead of repeatedly implementing the same mechanisms in every application, the model clarifies the required quality levels and specific constraints, while the execution platform provides the common parts of their realization.

Through this separation, modeling extends beyond functional descriptions and connects to software that can be operated in practice. Later articles examine how individual quality attributes are modeled and realized through Textus.

The Modeling Technology System does more than classify technologies. It establishes the following design decisions adopted by SimpleModeling.

Software engineering provides many existing technologies with different subjects and purposes. SimpleModeling does not build its methodology by starting from one particular technology. It first establishes a framework of model composition, roles, dependencies, and a realization path, and then selects and positions the supporting technologies needed by each part of that framework.

For example, GoF and PEAA support responsibility and Collaboration design in Object Modeling, while DDD supports problem-domain concepts and boundaries in Domain Modeling. Use Case Realization, Interaction, and StateMachines map scenarios to dynamic structures in Application Modeling. CQRS and Saga are positioned at the boundary between Application Modeling and Model Realization, separating model meaning from implementation technique. Knowledge Graphs and RDF structure knowledge referenced by generative AI in Knowledge Modeling.

A technology may contribute to more than one role. The important point is not to lock each technology into one box, but to state which part of which model it supports and for what purpose.

Defining model roles and relationships is not enough if models remain separated from implementation. Within the Domain Model View, SimpleModeling expresses the formal structure contributed by the overlap between the Domain region and the Object Model in CML as a machine-processable structure. Cozy transforms CML into executable software, AI fills implementation gaps that Cozy cannot transform completely, and Textus runs the resulting software.

A Domain Model View formed from the overlaps of one Domain region with the Object, Knowledge, and Literate Models determines what must be clarified on the abstraction side. CML, Cozy, AI, and Textus connect structures formalized through the overlap with the Object Model to implementation and execution. The Modeling Technology System places this 2D model composition and the single realization path within one methodology.

This connection also includes the realization of quality attributes. Applications retain Domain Logic and their specific requirements, while Textus provides mechanisms for quality attributes shared across applications. This incorporates the operational qualities required in the path from models to executable software.

This article does not define the detailed techniques of each area. It defines the classification principle shared by the methodology, the responsibility of each area, the viewpoint for selecting technologies, and the connection to the realization path.

A Model is not Reality itself; it is constructed as a View according to Purpose and Concern. The next article covers this theory as View-Based Modeling. Later articles examine the Object, Knowledge, and Literate constituents, followed by Domain, Use Case, and Application Modeling and Model Realization.

SimpleModeling does not redefine every technology from scratch. It selects existing software engineering technologies as components needed for modeling-centered development and places them within model roles, dependencies, and a realization path.

This system makes it possible to understand what a technology is meant to clarify and where it belongs in development before studying every detail. Practitioners can use Textus tools and frameworks while building actual systems and learn the background and details of each technology through that work.

The Modeling Technology System has organized the relationship in which one Domain region overlaps the Object, Knowledge, and Literate Models, while a Glossary ring connects the mixed-color overlaps so that they can be read as one Domain Model View according to purpose and concern. It has not yet explained the common principle for selecting information from the same subject and deciding what scope to represent as a model.

The next article introduces View-Based Modeling and explains how a model is constructed not as Reality itself, but as a View based on purpose, concern, and Perspective.