Architecture-Centric in SimpleModeling
This article explains how SimpleModeling reinterprets the Unified Process (UP) principle of Architecture-Centric development for the AI era. Architecture is no longer treated merely as a design artifact, but as a framework that stabilizes modeling, implementation, execution, knowledge management, and operation across the development lifecycle.
AI-Era Reinterpretation
In an architecture-centric process, architecture is not merely a design artifact. Requirements, analysis models, design models, deployment structures, and operational structures are interpreted and refined through architectural viewpoints.
This becomes increasingly important in the AI era because generative AI systems behave more reliably when structures, contexts, responsibilities, and viewpoints are explicitly defined.
Architecture is also refined iteratively throughout development. Each iteration incrementally refines conceptual models, implementation structures, execution environments, and operational knowledge under a coherent architectural framework.
SimpleModeling Reference Profile
The SimpleModeling Reference Profile (SMRP) defines multiple architectures that support development.
The Standard Profile of SimpleModeling adopts all architectures defined in the Reference Profile. In practice, users can customize, replace, or extend individual architectures according to the requirements of their projects.
The following sections describe representative architectures used in SimpleModeling.
-
3-Tier Reference Architecture
-
Literate Architecture
-
Knowledge Architecture
-
Process Architecture
4+1 View Model
SimpleModeling inherits the 4+1 View Model proposed by Philippe Kruchten for the Unified Process, interpreting it as a multi-view modeling framework that connects human-readable narratives (SmartDox) and structured design models (Cozy). Each view corresponds to a distinct concern of the system.
| View | Focus | Typical Model |
|---|---|---|
Use-Case View |
User goals, scenarios |
UseCase, Scenario |
Logical View |
Domain concepts, relationships |
Entity, Value, Rule |
Process View |
Behavior, concurrency, workflow |
|
Development View |
Components, modules, interfaces |
|
Physical View |
Deployment and runtime topology |
Deployment, Node |
The โ+1โ Use-Case View serves as the entry point that connects user intentions to system architecture. Together, these views form a consistent architectural baseline.
Related articles are listed below.
3-Tier Reference Architecture
In the SimpleModeling Reference Profile, the architectural baseline is structured around three subsystemsโPresentation, Application, and Domainโrepresenting a modernized interpretation of the classic 3-tier architecture. This structure provides a stable foundation for modeling, code generation, and deployment.
| Subsystem | Responsibility | Main Model |
|---|---|---|
Presentation |
UI, API, and user interaction |
View, Controller, APIComponent |
Application |
Use-case coordination, process control |
Service, UseCase, Workflow |
Domain |
Business logic and core knowledge |
Entity, Value, Rule, DomainEvent |
This layered structure aligns with the Logical, Development, and Physical Views of the 4+1 model, making the entire system architecture more analyzable, evolvable, and automatable.
Related articles are listed below.
Execution Architecture
SimpleModeling defines execution architectures that stabilize runtime behavior, execution boundaries, and operational structures.
-
CNCF (Cloud Native Component Framework) Runtime Architecture: standardizes lifecycle, services, selectors, and execution contexts.
-
CQRS + Job Architecture: stabilizes synchronous and asynchronous execution boundaries.
-
Form API / Static Form App Architecture: standardizes UI execution and transition structures.
Related articles are listed below.
Literate Architecture
SimpleModeling extends the architecture-centric concept into a literate architecture: each architectural decision, model, and viewpoint is documented in human-readable SmartDox form and linked to Cozy source models. This makes architecture both executable and explainable.
Related articles are listed below.
-
๐ AI-Driven Program Generation โ Possibilities and Challenges
-
๐ Error:/domain-modeling/simple-object.dox
Knowledge Architecture
SimpleModeling defines knowledge architectures that stabilize the structure, representation, and circulation of knowledge.
-
Literate Model / SmartDox Architecture: organizes knowledge into semi-structured documents.
-
Vocabulary / Glossary / BoK (Body of Knowledge) Architecture: stabilizes terminology and semantic spaces.
Related articles are listed below.
-
๐ AI Knowledge Creation Architecture: Toward a Next-Generation SECI Model
-
๐ KnowledgeGraph Explorer: Exploring the SimpleModeling Knowledge Graph
-
๐ Semantic Integration Engine: A BoK Integration Demo for the AI Era
-
๐ Integration between the Semantic Integration Engine and ChatGPT
-
๐ Integration between the Semantic Integration Engine and VSCode
-
๐ The Philosophy of 1.5hop+: Meaning-Oriented Concept Neighborhoods
Process Architecture
SimpleModeling defines process architectures that stabilize development activities and artifact flows.
-
Process / Activity / Skill Architecture: defines development order, responsibilities, and artifact flows.
Related articles are listed below.
Architectural Mechanisms
SimpleModeling also defines architectural mechanisms that stabilize, constrain, and support architectures. These mechanisms are not architectures themselves, but foundational structures that make architecture-centric development practical and stable.
-
Type System: constrains structures and data relationships.
-
Executable Specification: constrains behavior through laws and executable rules.
-
DSL (Domain Specific Language) / Grammar: constrains modeling and description spaces.
-
Vocabulary / Glossary: stabilizes terminology and semantic consistency.
Articles related to architectural mechanisms are listed below.
Harness Engineering
From the perspective of Harness Engineering, the architectures and architectural mechanisms defined in the SimpleModeling Reference Profile can be interpreted collectively as a development harness system. By structuring execution, knowledge, and process boundaries through architecture, development becomes more stable and reproducible.
This becomes increasingly important in the AI era because generative AI systems behave more reliably when development environments are explicitly structured.
SUMMARY
In SimpleModeling, architecture-centric development means aligning models, execution structures, knowledge structures, and processes under a coherent architectural framework. The SimpleModeling Reference Profile provides a reusable architectural baseline that connects conceptual understanding and executable systems.
References
In Site
-
๐ SimpleModeling Development Process with Essence Framework
-
๐ Object-Oriented Analysis and Design Course for Cloud Applications
-
๐ Operational Image and Model Expansion of SimpleModeling
-
๐ CBD Enabled by DSL and Execution Platform: Implementable Component Structure
-
๐ Understanding the CNCF Execution Model Through HelloWorld
-
๐ AI-Driven Program Generation โ Possibilities and Challenges
-
๐ AI Knowledge Creation Architecture: Toward a Next-Generation SECI Model
-
๐ KnowledgeGraph Explorer: Exploring the SimpleModeling Knowledge Graph
-
๐ Semantic Integration Engine: A BoK Integration Demo for the AI Era
-
๐ Integration between the Semantic Integration Engine and ChatGPT
-
๐ Integration between the Semantic Integration Engine and VSCode
-
๐ The Philosophy of 1.5hop+: Meaning-Oriented Concept Neighborhoods
Glossary
- UP (Unified Process)
-
A process model based on UML, characterized by iterative, use-caseโdriven, and architecture-centric development. It has derivatives such as the Rational Unified Process (RUP) and provides a foundation for practicing Component-Based Development (CBD).
- SimpleModeling
-
SimpleModeling is a modeling-centered software development methodology and technology system for constructing a Domain Model from Knowledge, formalizing it in CML, realizing it as executable software through Cozy and AI, and running it on Textus.
- SimpleModeling Reference Profile (SMRP)
-
This is the reference profile of SimpleModeling. To concretely illustrate Literate Model-Driven Development with SimpleModeling, a reference profile is defined.
- Model
-
A Model is an abstraction that represents a subject according to a particular Purpose and Concern so that it can be understood, reasoned about, evaluated, or constructed. It is not the subject itself; it preserves the elements, relationships, and meanings required for its purpose.
- View
-
A View is a representation that projects selected parts of a Model according to a particular Purpose and Concern so they can be understood, reasoned about, evaluated, or used. A View presents part of a Model and does not own meaning independently of the source Model.
- Execution Architecture
-
A technical and runtime foundation supporting the development system, separating model and execution layers.
- Cozy
-
Cozy is the SimpleModeling toolchain that analyzes Models expressed in CML and other DSLs and transforms them into realization artifacts such as programs, configuration, and documentation.
- Behavior
-
In UML, Behavior is a specification of how its context Behaviored Classifier changes State over time. It may define possible executions, emergent Behavior, or a selected example of execution.
- Activity
-
A concrete action or task performed within an Activity Space to move an Alpha to a more advanced state, typically producing or refining Work Products.
- StateMachine
-
In UML, a StateMachine is a Behavior that expresses the event-driven Behavior of a system element by traversing a graph of States through Transitions triggered by Event occurrences.
- Interface
-
Undefined
- Component
-
A software construct that encapsulates well-defined responsibilities, contracts, and dependencies as a reusable and replaceable unit. In the logical model, it serves as an abstract structural unit; in the physical model, it corresponds to an implementation or deployment unit.
- Responsibility
-
A Responsibility is an obligation stating what an Object or Role must know, decide, perform, or protect. It assigns ownership of rules and Behavior, not merely structural information.
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework (CNCF) is a framework for executing cloud application components using a single, consistent execution model. Centered on the structure of Component, Service, and Operation, it enables the same Operation to be reused across different execution forms such as command, server (REST / OpenAPI), client, and script. By centralizing quality attributes required for cloud applicationsโsuch as logging, error handling, configuration, and deploymentโwithin the framework, components can focus on implementing domain logic. CNCF is designed as an execution foundation for literate model-driven development and AI-assisted development, separating what is executed from how it is invoked.
- Lifecycle
-
A Lifecycle is the range of States and Transitions through which a subject passes, while retaining its Identity, from creation to termination.
- Literate Model
-
Undefined
- Glossary
-
A Glossary is a knowledge resource that manages the names, meanings, boundaries, synonyms, and identifiers of terms used in a subject domain. It provides a common foundation for participants to use the same terms with the same meanings.
- BoK (Body of Knowledge)
-
At SimpleModeling, the core knowledge system for contextual sharing is called the BoK (Body of Knowledge). The goal of building a BoK is to enable knowledge sharing, education, AI support, automation, and decision-making assistance.
- Type
-
Undefined
- Constraint
-
In UML, a Constraint is a condition or restriction expressed in natural language or a machine-readable language to declare part of the Semantics of one or more Model Elements. Its evaluation yields a Boolean value and has no side effects.
- DSL (Domain Specific Language)
-
A DSL (Domain-Specific Language) is a language designed for a particular domain, enabling direct and concise expression of the domainโs concepts and structures. Compared to general-purpose programming languages (GPLs), DSLs offer a higher level of abstraction tailored for domain-specific problem solving and automation.