Object Modeling as a Structural Foundation
In general, an Object Model has two broad responsibilities. One is to describe the concepts, relationships, responsibilities, constraints, state, and behavior of the target Model formally. The other is to assemble mechanisms such as persistence, transactions, communication, and execution control that are required to run that Model on a platform.
SimpleModeling currently applies formal Object Model description to Domain Models. The combination of SimpleModeling, CML (Cozy Modeling Language), Cozy, and Textus absorbs the general second responsibility—platform-oriented mechanisms—through program generation and the execution foundation. People and AI can therefore concentrate on the first responsibility: formally describing the Domain Model.
A SimpleModeling Model is composed of Object, Knowledge, and Literate Models that express different aspects of the same subject. The Object Model is formal, the Knowledge Model primarily enables generative AI to understand the Model, and the Literate Model is centered on natural language people can understand. These three constituents are combined according to purpose to form Domain, Use Case, and Application Models. Part 5 focuses on the role of the Object Model within this whole.
Article at a Glance
Part 5 at a glance: the Object Model is one of the Object, Knowledge, and Literate constituents of a SimpleModeling Model. Current CML covers the Executable Model, while Execution Example Models such as Interactions constrain design, review, and validation. 
Position in the Series
Part 4 organized a Model through Domain Model and Use Case Model axes and explained how purpose- and concern-selected Views are used to work with it. It centered the Object Model when explaining formal structure but did not yet develop its individual structuring techniques.
Part 5 explains the role of the Object Model within the whole Model, the distinction between Executable and Execution Example Models, and how SimpleModeling, CML, Cozy, and Textus delegate platform mechanisms to generation and execution infrastructure so Domain Model description can remain the focus.
Previous article: 📄 Model Structure and the Use of Views
General Roles of an Object Model and SimpleModeling’s Scope
The first responsibility is to select subjects requiring identity as Objects and make their meaning, identity, classes and types, responsibilities, relationships, and validity conditions explicit as Model structure. The second responsibility is to assemble persistence, transaction, communication, resource-management, and execution-control mechanisms for running that Model on a platform.
SimpleModeling currently applies formal Object Model description to Domain Models. Formal description of other Models is out of scope at this time. CML describes Domain Model structure, Cozy generates programs, and Textus supplies the execution foundation, delegating platform-oriented mechanisms to this combination so that modeling can focus on the Domain Model.
From Object-Oriented Programming to a SimpleModeling Object Model
Object-oriented programming implements program structure and Behavior through classes, interfaces, objects, methods, inheritance, and related constructs. A SimpleModeling Object Model makes explicit the Model meaning that must be preserved before realization as those implementation elements.
| オブジェクト指向プログラミングの実装要素 | SimpleModelingで加わる意味 |
|---|---|
A Class describes object-side structure, while Type is a semantic contract connecting values, Operations, results, effects, and composability. CML Model Elements do not map one-to-one to Scala classes, traits, case classes, enums, or function types. |
|
Field / reference |
A reference is given meaning as Classification, Structural Ownership, or another Relationship. Generalization and Powertype, Composition, Association, Dependency, and Multiplicity preserve Model intent not evident from code connectivity alone. |
Method / service call |
An Operation is understood through responsibility and contract: which Object owns each decision and rule. A method is one realization of that meaning. |
State field / enum / callback |
When transitions carry domain meaning, States, Events, Operations, and transition conditions are connected as a StateMachine, the foundation of the Dynamic Model. |
Framework annotation / infrastructure code |
Persistence, transactions, communication, and related mechanisms are kept out of the Domain Model and delegated to generation and execution through CML, Cozy, and Textus. |
Entities, Values, Events, Services, responsibilities, and Constraints are Model Elements and roles used to describe an Object Model in CML. Cozy generates programs from CML, realizing model-driven development in SimpleModeling. Part 5 provides an overview of their meaning and connections without expanding into individual notations or design patterns.
Collaboration Bridges Use Case Scenarios and CML
In an object-oriented program, Use Case processing may appear as an application-service method or a sequence of calls. SimpleModeling first concretizes the Literate Model's Use Case Scenario as an execution example comprising participating Objects, responsibilities, Interactions, Operation order, Events, and State transitions. This Collaboration connects the Use Case to the Object Model.
An execution example is not converted directly into CML. AI proposes mappings to executable Services, Operations, Events, StateMachines, and related elements, while people approve the meaning and correspondence. The component cbd-support supports component-based development by managing evidence, differences, and Traceability; a skill uses that support to apply only approved changes to CML. This intermediate correspondence is being developed as a Use Case Realization Model.
ConfirmOrder as a Compact Example
In a “confirm an order” Scenario, Order owns confirmation eligibility and its State transition, inventory reservation and payment authorization collaborate, and the successful Outcome is represented by an OrderConfirmed Event. CML describes the approved mapping as Services, Operations, Entities, Events, and StateMachines, while Cozy generates routine connection code.
A Capability represents what a Model or system makes possible for a user or problem domain. An Aspect represents a Concern—such as Performance, Reliability, or Security—examined across multiple Model Elements or behaviors. A Service is one kind of Capability, and a Quality Attribute is one kind of Aspect. cbd-support retains these and the small remainder outside those primary forms as internal Model representations. Developers do not manipulate them directly; they examine mappings to Use Cases, Object Model elements, and quality conditions during approval review.
Views Select What a Purpose Requires
A complex Model is difficult to understand all at once. A View selects the elements, Relationships, Behavior, quality, evidence, and context required to answer a Purpose and Concern and presents them for understanding, reasoning, evaluation, or use. Selection starts from the question to answer rather than partitioning the Model into a fixed set of Views.
| Purpose and Concern | Selected elements |
|---|---|
Understand formal structure |
Classes, Types, Attributes, Relationships, Multiplicity, and Structural Ownership |
Evaluate a lifecycle |
States, Transitions, Events, Operations, and Constraints |
Examine Use Case concretization |
Scenario, participating Objects, responsibilities, Operation order, and successful and failed Outcomes |
Explain meaning and rationale |
Glossary terms, formal structure, knowledge evidence, context, and intent |
A Class Diagram is one representation that may be selected to examine formal structure. A View does not own meaning independently. Meaning and identity remain in the source Model and Glossary so that the same elements can be related across different Views.
Relationship to Other Models
Object, Knowledge, and Literate Models are the three constituents of a SimpleModeling Model. They express different aspects of the same subject and correspond to form the whole. They are not themselves Views; a View selects and presents the Model Elements required from the three according to Purpose and Concern.
A Use Case Scenario, which is a kind of Literate Model, expresses an Actor’s Goal, events, branches, and Outcomes in natural language. Application Modeling constructs a Use Case Realization Model from the Scenario: a Collaboration describes participants, Roles, and responsibilities, while an Interaction describes a concrete execution example. Their mappings lead to executable Objects, Services, Operations, Events, StateMachines, and Constraints. The Knowledge Model is used primarily by generative AI to explore relationships across the three Models and explain them to people.
From Object Model to CML and Execution
Current CML describes the Executable Model portion of an Object Model through Classes, Types, Attributes, Relationships, Constraints, States, Operations, Events, Services, StateMachines, and related elements. Execution Example Models such as Interactions are outside CML's scope. Application Modeling preserves Traceability from an approved Use Case Realization to executable elements; subsequent Model Realization connects CML to Cozy, AI, and Textus to produce Code, Tests, Documentation, and executable artifacts while retaining constraints supplied by execution examples.
Working with Object Models through AI
AI can propose execution examples such as Interactions from Use Case Scenarios in the Literate Model and map them to candidate executable Objects, Types, Relationships, responsibilities, Constraints, and StateMachines. The Knowledge Model enables generative AI to explore Model concepts and semantic relationships, identify possible duplication or conflict, and explain the Model to people. Canonical Glossary terms and identities trace the Literate Model, execution examples, and CML Executable Model.
People who understand the Purpose and reality still decide Object boundaries, identity, lifecycle, responsibility ownership, and the business correctness of invariants. Do not turn every noun found by AI directly into an Object or type; select them according to the responsibilities and reasons for change required by the Use Cases.
Next
This article organized Objects, Types, Relationships, responsibilities, Constraints, State, Behavior, and Collaboration as formal structures supporting Domain, Use Case, and Application Models. The next article turns to Knowledge Modeling and examines how a Knowledge Model is organized so that generative AI can discover, relate, and explain Model concepts, classifications, semantic relationships, and evidence.
References
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.
- Object Model
-
Undefined
- 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.
- 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.
- 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.
- 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.
- 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.
- Persistence
-
Undefined
- Communication
-
Undefined
- State
-
In UML, a State models a situation during which an invariant condition holds. The current State of an Object may determine accepted Events and Operations, applicable Constraints, and possible next Transitions.
- 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.
- Execution Control
-
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.
- 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.
- Transaction
-
Undefined
- Domain 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.
- 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.
- 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.
- Literate Model
-
Undefined
- Executable Model
-
Undefined
- Execution Example Model
-
Undefined
- validation
-
Validation is the activity of confirming that a system or product fulfills its intended use and stakeholder requirements.
- 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.
- Class
-
Undefined
- Identity
-
Identity is the sameness by which a subject is distinguished from others and tracked as the same subject over time even when its values or State change. An Identifier is a value that represents or refers to Identity; it is not the Identity itself.
- Type
-
Undefined
- Interface
-
Undefined
- 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.
- Scala
-
Undefined
- 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.
- Powertype
-
Undefined
- Generalization
-
In UML, a Generalization is a taxonomic Relationship between a more general Classifier and a more specific Classifier. Every Instance of the specific Classifier is also an Instance of the general Classifier, and the specific Classifier inherits the Features of the general Classifier.
- Multiplicity
-
In UML, Multiplicity specifies the allowable cardinalities for Instances of a Model Element as an inclusive interval of non-negative integers from a lower bound to an upper bound, which may be unlimited.
- Structural Ownership
-
Undefined
- Relationship
-
Undefined
- Association
-
Undefined
- Composition
-
Undefined
- 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.
- Use Case Scenario
-
Undefined
- Collaboration
-
In UML, a Collaboration is a Classifier describing a structure of participant Roles that perform specialized functions and collectively accomplish desired functionality.
- 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.
- 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.
- Realization
-
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.
- 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.
- Aspect
-
An Aspect is a condition, property, or Concern examined across multiple Model Elements or behaviors. It centers on Quality Attributes and may include cross-cutting conditions that are not adequately expressed by a Quality Attribute alone.
- 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.
- Capability
-
A Capability describes what a Model or system makes possible for a user or problem domain. It focuses on the result or function provided rather than prescribing how it is realized.
- Reliability
-
Reliability is the quality by which a system consistently performs required functions under specified conditions for a specified period. It is evaluated through concerns including Availability, Fault Tolerance, and Recoverability.
- 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.
- 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.
- Lifecycle
-
A Lifecycle is the range of States and Transitions through which a subject passes, while retaining its Identity, from creation to termination.
- Transition
-
In UML, a Transition is a directed Relationship from a source Vertex to a target Vertex in a StateMachine. Triggers, Guards, Effects, and related elements specify when the Transition occurs and what it performs.
- 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.
- 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.
- 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.
- Interaction
-
Undefined
- 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.
- Object Modeling
-
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.
- Platform
-
A Platform is a shared set of technical foundations and services used to build, deploy, execute, and operate software.
- Identifier
-
An Identifier is a value used to refer to a subject with Identity or to a correlation subject and distinguish it from others. An Identifier may represent Identity, but it is not itself the meaning by which the subject remains the same over time.
- Invariant
-
An Invariant is a Constraint that must hold at every observable stable point while a subject is valid. It may apply to an Object, a Type, or a structure composed of multiple elements.
- Knowledge Modeling
-
Undefined