Operational Image and Model Expansion of SimpleModeling
SimpleModeling proposes a structured development style that begins with analysis models written in CML (Cozy Modeling Language) (Cozy Modeling Language), expands vertically into conceptual and design models, and ultimately supports real-world system operations. This article explains the flow and deployment method for each tier.
3-Tier Model
Our system architecture adopts the following three-tier model.
-
Presentation Tier
-
Application Tier
-
Domain Tier
Each tier is modeled as a subsystem and is typically deployed and operated as a microservice.
However, SimpleModeling is based on Component-Based Development (CBD), and following recent terminology, it leans toward a Modular Monolith approach. Therefore, it is also possible to deploy and operate a microservice that integrates both the application and domain tiers.
Analysis Models
The analysis model consists of the following three sub-models.
-
Domain Model
-
Application Model
-
Use Case Model
The domain model describes the essential structure and rules of the problem domain handled by the system.
The application model describes the application services required to execute use cases, including their responsibilities, operations, and domain state transitions.
The use case model represents the goals of actors and the corresponding behaviors of the system. SimpleModeling adopts a use case–driven approach, positioning this model at the core of its analysis modeling.
The use case model itself is not used directly as an input model for source code generation. Instead, it serves as the basis for creating application and domain models and helps maintain consistency among them.
SimpleModeling remains neutral regarding business analysis and is designed to work with any business analysis methodology.
The central model in such integration is the use case model.
By describing the results of business analysis in CML as use case and domain models within the analysis model, those results can be seamlessly incorporated into application development.
Expansion from Analysis Models
The analysis model expands in two directions—upward and downward—via the analysis model up/down process.
-
Conceptual Model
-
Design Model
Conceptual Model
The conceptual model is used for the following purposes:
-
To give an overview of the problems the application addresses
-
To share information with non-technical stakeholders
Representative artifacts are illustrated in the diagrams.
The use case diagram visualizes the actor-goal list as an object model and is suitable for providing an overview of the entire system.
The class diagram illustrates the relationships between domain objects defined in the glossary.
The component diagram visualizes the relationships among subsystems and components extracted from the application and domain models based on specific criteria. As part of the conceptual model, the intention is to represent not the actual application system structure, but rather the bounded contexts.
Design Models
In the design phase, design models are created based on the analysis model, targeting the following tiers.
-
Domain Tier
-
Application Tier
-
Presentation Tier
Domain Tier
A design model of the domain model is created targeting the domain tier.
When generating the design model from the domain model, the analysis model’s domain model is combined with a design context as input parameters.
The design context defines elements such as execution platform and quality attributes.
Cozy generates a Scala-based design model, which is then further refined by adding detailed implementation.
In principle, components that operate on the domain model are implemented using Component-Based Development (CBD), and these components are finalized as subsystems to be deployed in the domain tier.
Application Tier
Multiple domain subsystems are created from various problem domains, and the application model integrates them into a cohesive application.
As with the domain model, the application model and design context from the analysis model are used as input parameters for Cozy to generate a Scala-based design model, which is then enhanced with implementation details.
The application model is implemented via components using CBD and deployed as subsystems within the application tier.
Presentation Tier
Due to the rapid evolution and trend sensitivity of presentation technologies, SimpleModeling does not directly target this tier but instead defines integration strategies.
Using the application model, use case model, and UI context as input, Cozy generates UI scenarios.
Tasks following UI scenario generation are delegated to the UI development side. AI assistance can be highly effective in this phase of development.
Summary
SimpleModeling places analysis models described in CML at its core and supports the entire software development process by expanding them into conceptual and design models.
By combining model transformations based on use case models with AI-assisted implementation, it aims to bridge the gaps between analysis, design, and implementation, promoting a continuous and comprehensible development style.
References
Glossary
- CML (Cozy Modeling Language)
-
CML is a literate modeling language for describing Cozy models. It is designed as a domain-specific language (DSL) that forms the core of analysis modeling in SimpleModeling. CML allows model elements and their relationships to be described in a narrative style close to natural language, ensuring strong compatibility with AI support and automated generation. Literate models written in CML function as intermediate representations that can be transformed into design models, program code, or technical documentation.
- CBD (Component-Based Development)
-
Component-Based Development (CBD) is a software development approach in which systems are constructed and reused through components that define clear responsibilities, contracts, and interfaces. Components are designed to be independent and replaceable, enabling loosely coupled architectures that improve maintainability and reusability. In the logical model, a component serves as an abstract structural unit defining functionality and contracts; in the physical model, it corresponds to implementation and deployment units.
- Analysis Model Up/Down
-
Analysis Model Up/Down is a bidirectional modeling approach in which the analysis model serves as the central layer, enabling upward derivation into conceptual or design models ("Up") and downward transformation into implementation artifacts such as code or data definitions ("Down").
- UML (Unified Modeling Language)
-
A standardized modeling language for object-oriented analysis and design. It represents system structures and behaviors through diagrams such as class, sequence, and use case diagrams. Serves as the foundational language for UP and CBD.
- 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.