Conceptual Model / Analysis Model / Design Model
A domain model is a representation of the real world transformed into a model that can be manipulated by software. The key point is to faithfully reproduce the "conceptual world" held by experts in the target problem domain.
By constructing such a model, it becomes possible to share it with experts, thereby enhancing the consistency and understanding in software development.
Domain Model Creation Conditions
Of course, simply reproducing the conceptual world faithfully is not enough to make it operational in software, so various adaptations are made.
The conditions for creating a domain model can be summarized as follows:
-
Faithfully reproduce the conceptual world of the problem domain so that it can be shared with domain experts - Establish it as a mechanism that can be implemented in software There are various options for modeling the problem domain, such as granularity and perspective, but it must fit within a structure that operates in software.
Therefore, it is practical to proceed with modeling according to a predefined model framework template that works in software.
Model Layers in SimpleModeling
In SimpleModeling, domain models are implemented in the following three layers.
-
Conceptual Model - Analysis Model - Design Model The diagram below shows the types of model elements used in the conceptual, analysis, and design models within SimpleModeling.
Details will be explained in another article, but the types of model elements used increase dramatically as the level of concreteness rises from the conceptual model to the analysis model and then to the design model.
Each of the conceptual, analysis, and design model layers has different purposes and users depending on its level of abstraction.
Here, we explain the characteristics and operational methods of each.
Conceptual Model
The conceptual model is used in the disciplines of business analysis and requirements analysis.
It represents the structural elements of the problem domain — such as business structure, participants, resources, and rules—in an abstract and intuitive manner.
The conceptual model has the following objectives:
-
Provide an overview of the domain model, clarifying the business structure and background context. - Facilitate information sharing with stakeholders, such as business owners, who are not involved in development details. - Ensure continuity with implementation approaches that connect directly to the analysis and design models as concreteness increases. Establishing a ubiquitous language is a key theme in the conceptual model.
By clarifying terminology definitions, misunderstandings and requirement misalignments are prevented.
Moreover, ensuring continuity between terminology and system implementation objects helps prevent discrepancies between the conceptual model shared among stakeholders and the final implementation.
Focusing on terminology definitions, the classification structures of classes and diagrams are used to visualize the structure of complex business operations.
The model is presented in a format that is easy to understand, even for non-technical stakeholders.
Analysis Model
The analysis model is a model that clarifies the functions and structure of an application.
It creates a pure model for realizing an application, keeping a distance from execution environments such as runtime platforms and implementation languages, cross-cutting concerns such as performance and security, and non-functional requirements.
The basic structure of the model is a concretization of the conceptual model, and continuity with the conceptual model is important.
It ensures that the structure and mechanisms of the conceptual model shared among stakeholders link directly to the realization of the system.
In the analysis model, the structure of the domain model is detailed and concretized in a way that does not depend on implementation technology, and the behavior of the domain model is defined.
-
Describe the basic structure of the domain using entities and values. - Use model elements such as datatypes, state machines, and powertypes to concretize the structure and behavior of entities. - Use subsystems and components to clarify the boundaries of the domain model. - Use events, workflows, and services to concretize the behavior of the system. - Use rules to define the constraints and regulations of the domain. - Incorporate cloud-native elements as needed. The analysis model is used in discussions with stakeholders such as on-site customers and domain experts who are responsible for the internal structure and non-functional requirements of the system.
Design Model
The design model is a model that, based on the execution environment such as the runtime platform and implementation language, refines the analysis model into a form that can run in the execution environment.
The highly abstract model created in the analysis model is concretized for the execution environment.
It is described in alignment with the technology stack to be used, such as databases, APIs, and web frameworks.
In the SimpleModeling reference model, the design model is created for the following execution environment.
-
Programming language: Scala 3 - Core library: Cats - Framework: Cloud-Native Component Framework (SimpleModeling) Scala 3/Cats is introduced by integrating full-scale functional programming into object-oriented programming.
Since middleware such as databases and cloud platforms is abstracted by the Cloud-Native Component Framework (CNCF), the design phase targets CNCF-based design.
The foundation of the design model consists of Scala programs automatically generated from the analysis model by Cozy.
In the design phase, this framework is enriched through Scala programming, with supplementary information described using UML or similar as needed.
The design model implements the following elements:
-
Non-functional requirements and quality attributes such as performance and security. - Mechanisms for achieving cloud-native capabilities. Although the design model is described using Scala programs, at the design stage it is limited to foundation description, with final realization through Scala programming in the implementation phase.
Since Scala is used to describe the design model, the boundary between design and implementation can be subtle. In this approach, design is considered complete when BDD/TDD-based specification descriptions (test programs) compile, and implementation is the work of Scala programming to make all test programs pass.
Domain Mechanics
In the analysis model, the focus is on the structure and behavior of the domain model itself, whereas in the design model, it is necessary to consider the mechanisms for performing concrete operations on the target platform.
In SimpleModeling, the mechanisms for operating the domain model are called Domain Mechanics, and they are designed separately from the domain model itself.
Representative Domain Mechanics objects:
-
Factory: Manages the creation of objects - Repository: Persists and retrieves objects and aggregates - Aggregate: A set of domain objects with a consistency boundary == Analysis Model Up/Down
In SimpleModeling, the conceptual, analysis, and design models are not regarded as being simply transformed from "top to bottom."
Each model is handled independently and in parallel according to its purpose, while maintaining consistency and evolving concurrently.
At the center is the analysis model described in the literate model using CML (Cozy Modeling Language).
Starting from this analysis model, generation and supplementation are carried out in the following directions:
-
Upper (Abstraction): Generate the conceptual model (for business stakeholders) - Lower (Concretization): Generate the design model (for developers and implementation) .SimpleModelingでのモデルの運用 image::analysis_up_down.png[role=img-figure,alt=SimpleModelingでのモデルの運用,title=SimpleModelingでのモデルの運用]
Analysis Model
The core of Analysis Model Up/Down is the analysis model.
-
Share specifications with stakeholders such as on-site customers and domain experts - Serve as an adjustment point to balance business requirements and technical requirements ==== AI Support
-
Check model consistency and propose attribute or behavior completions - Automatically generate natural language explanations, documentation, and UML from the model === Conceptual Model
The conceptual model is automatically or semi-automatically generated from the analysis model described in CML and is used to share the overall business picture with stakeholders.
-
Share objectives, values, and constraints with business owners - Function as a navigation model that clarifies the meaning of terms and structures ==== AI Support
-
Create draft conceptual models - Support the construction of conceptual models - Generate explanations for terms in the model and assist in linking with the glossary === Design Model
The design model is built primarily around code automatically generated by Cozy or AI.
Some design model information can also be described in CML, allowing it to be added as design model information to the analysis model’s CML.
Since the basic foundation is generated by Cozy, the task is to verify the validity of that foundation and add concrete details.
Glossary
- 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.
- Domain Model
-
Undefined
- 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.
- Feature
-
In UML, a Feature is a structural or behavioral characteristic of Instances of a Classifier. Features include Structural Features such as Attributes and Behavioral Features such as Operations.
- Object
-
An Object is an Instance classified by a Class or another Classifier and may have structure, State, and Behavior. It is treated as an individual that can be referred to separately from other Instances of the same Classifier.
- Class
-
Undefined
- Security
-
Security is the quality of protecting information and functions according to legitimate authority and preventing unauthorized disclosure, use, modification, destruction, or repudiation. It includes Concerns such as Confidentiality, Integrity, Authenticity, and Accountability.
- Performance
-
Performance is the quality by which a system satisfies timing requirements such as processing time, response time, Throughput, and capacity under specified conditions and resources.
- Platform
-
A Platform is a shared set of technical foundations and services used to build, deploy, execute, and operate software.
- Dependency
-
In UML, a Dependency is a directed Relationship indicating that the specification or implementation of a client Model Element depends semantically or structurally on the definition of a supplier Model Element.
- 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.
- Powertype
-
Undefined
- Data Type
-
In UML, a Data Type is a Classifier whose Instances are identified by value rather than Identity. Instances of a Data Type are indistinguishable when they have the same value.
- Event
-
In UML, an Event describes an occurrence that may arise during the execution of Behavior. Receiving an Event occurrence may trigger Behavior such as a Transition in a StateMachine.
- 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.
- 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.
- Scala
-
Undefined
- 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.
- 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.
- 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.
- Quality Attribute
-
A Quality Attribute is a characteristic that expresses the degree of quality with which software satisfies requirements in addition to performing its functions. Examples include Security, Performance, Availability, Reliability, Resilience, Observability, and Maintainability.
- TDD (Test-Driven Development)
-
Test Driven Development (TDD) is a development practice in which tests are written before implementation, and the code is evolved by repeatedly making tests pass and refactoring.
- BDD (Behavior-Driven Development)
-
Behavior Driven Development (BDD) is a development approach that focuses on specifying system behavior through scenarios written in a shared language.
- Operation
-
In UML, an Operation is a Behavioral Feature of a Classifier that specifies the name, type, Parameters, and Constraints for invoking associated Behavior. The Operation specifies an invocation contract, while a Method or another Behavior realizes it.
- Persistence
-
Undefined
- Domain Object
-
A Domain Object is an object that represents concepts from the real-world domain targeted by a software system, encapsulating business logic and conceptual structure. It serves as a central building block of the domain model, encompassing elements such as entities, value objects, services, rules, and events. Domain objects are not just data structures or processing units within the system, but parts of a model that reflect the semantics and behavior of the problem domain.
- CML (Cozy Modeling Language)
-
CML (Cozy Modeling Language) is the SimpleModeling formal modeling language for describing the Executable Model portion of an Object Model that connects to program generation and execution.
- Literate Model
-
Undefined
- 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").
- Attribute
-
An Attribute is a Structural Feature representing a value or reference that Instances of a Classifier may hold. An Attribute may be characterized by a name, Type, Multiplicity, default value, and Constraints.
- 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.