Operational Image and Model Expansion of SimpleModeling
SimpleModeling constructs Domain, Use Case, and Application Models from the Object, Knowledge, and Literate constituents. It distinguishes Application Modeling, which concretizes Use Case intent into an Application Model, from Model Realization, which connects an approved Executable Model to design, implementation, and execution through CML (Cozy Modeling Language) (Cozy Modeling Language), Cozy, AI, and Textus.
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 current SimpleModeling Model is composed of Object, Knowledge, and Literate Models. Analysis organizes the following three purpose-specific applied Models from those constituents.
The domain model describes the essential structure and rules of the problem domain handled by the system.
The Application Model describes the participants, responsibilities, Collaborations, Interactions, application Services, Operations, Events, and StateMachines required to realize Use Cases.
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.
Application Modeling constructs a reviewable Use Case Realization Model from a Use Case Scenario expressed as a Literate Model. Collaboration represents the structure of participants, roles, and responsibilities, while Interaction represents a concrete execution example. AI proposes mappings to Services, Operations, Events, and StateMachines, and humans approve their meaning and correspondence.
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.
Business-analysis results are organized into Use Case, Domain, and Application Models. The human-approved executable Object Model portion is expressed in CML (Cozy Modeling Language) and connected to 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
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
Application Modeling is distinct from Model Realization, which transforms an approved Model into software. The former concretizes Use Case intent into a reviewable Application Model. The latter expresses its executable portion in CML and uses Cozy and AI to transform it into design models, programs, and tests that run on Textus.
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.
A design model is generated from the approved executable structure of the Domain Model expressed in CML together with a design context.
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. The Application Model selects the elements required for Use Case realization and makes them collaborate as an application.
As with the Domain Model, the human-approved executable portion of the Application Model is expressed in CML and supplied to Cozy with a design context. Cozy generates a Scala-based design model, while AI and developers complete the parts not covered by transformation.
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 constructs purpose-specific applied Models from Object, Knowledge, and Literate Models. It preserves traceability across analysis, design, and implementation by separating Application Modeling, which derives an Application Model from Use Case intent, from Model Realization, which connects an approved executable Model to software and execution through CML, Cozy, AI, and Textus.
It makes the path from Use Case Scenarios through Use Case Realization Models, Collaborations, and Interactions to Services, Operations, Events, and StateMachines reviewable, combining AI proposals with human approval.
References
Glossary
- 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.
- 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.
- Realization
-
Undefined
- 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.
- Application Modeling
-
Application Modeling is the activity of concretizing Use Cases as application behavior and constructing an Application Model. It clarifies the mappings from Use Case Scenarios to participants, Roles, responsibilities, Collaborations, Interactions, state transitions, Events, Services, and Operations.
- 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.
- Textus
-
Textus is the runtime foundation for operating software realized through SimpleModeling. It provides execution, operational, and integration mechanisms shared by applications.
- Use Case
-
In UML, a Use Case is a Model Element that specifies a set of Actions performed by a subject to yield an observable result of value to an Actor or other stakeholder.
- 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.
- Executable Model
-
Undefined
- Application Model
-
An Application Model is a purpose-specific Model describing how an application realizes Use Cases through participants, Roles, responsibilities, Collaborations, Interactions, state transitions, Events, Services, Operations, and Outcomes.
- 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.
- Object Model
-
Undefined
- Knowledge Model
-
A Knowledge Model structures the concepts, semantic relationships, classifications, rules, evidence, sources, and related knowledge in a SimpleModeling Model primarily so that generative AI can retrieve, explore, relate, and interpret them.
- Literate Model
-
Undefined
- Domain Model
-
Undefined
- Use Case Model
-
A Use Case Model is a purpose-specific Model that represents why users or external parties use a system and the Scenarios and expected Outcomes through which their Goals are achieved, using Actors, Goals, Use Cases, Scenarios, and Outcomes.
- Collaboration
-
In UML, a Collaboration is a Classifier describing a structure of participant Roles that perform specialized functions and collectively accomplish desired functionality.
- 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.
- 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.
- 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.
- 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.
- 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.
- Use Case Realization Model
-
In UP, a Use Case Realization describes how the behavior of a Use Case is realized by collaborating Model elements in a Design Model. A Use Case Realization Model represents the mappings between a Use Case Scenario and the participants, responsibilities, Interactions, Operations, and Outcomes that realize it.
- Use Case Scenario
-
Undefined
- Interaction
-
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").
- 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.
- 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.
- Class Diagram
-
A Class Diagram is a UML Diagram that presents the static structure of a Model using Classes, Interfaces, Data Types, Associations, Generalizations, Dependencies, and related elements.
- Class
-
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.
- Test
-
A Test is an activity and specification that executes or evaluates a subject under stated conditions and compares observed results with expected results or Constraints to check conformance to requirements or contracts.
- 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.
- 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.
- Scala
-
Undefined
- Traceability
-
Development Traceability is the property of being able to follow relationships among requirements, terms, Model Elements, design decisions, Tests, implementation, and execution results through identifiers and evidence.