2026
| Date | Kind | Event | Category | Title | Summary |
|---|---|---|---|---|---|
2026-08-31 |
Article |
New |
Literate Modeling treats organizing Stories as Narratives as an important form while also organizing Vision, requirements, decision records, existing specifications, and conventional documents that explain Domain Model concepts, rules, and relationships in natural language as Literate Models with explicit meanings, identities, and mappings to other Model elements. SmartDox is the full-spec primary description language, while Markdown is also allowed. textus-bok turns Literate Models into Knowledge Models and connects them to generative AI, which principally generates, updates, and manages the Object Model. People review the results through the visualizations, differences, and evidence provided by textus-cbd-support, then return approval or findings to the AI. Literate Models also serve as authoritative sources for facts from which requirements specifications, user guides, design explanations, and other purpose-specific documents can be composed. |
||
2026-08-31 |
Glossary |
New |
TermStoryAliases-Term ID: src/main/doxsite/glossary/literate-modeling/story.doxEnglish label: StoryJapanese label: ストーリーScope qualifier: Literate Modeling / semantic content expressed through a NarrativeBare-label linking: explicit-onlyCategory: Literate ModelingStatus: normativeDefinition authority: SimpleModeling BoKA Story is the semantic content of what happens, comprising actors, purposes, situations, events, causality, and outcomes. It is the subject expressed through a Narrative, not a particular manner of telling, document structure, or explanatory order. Story also refers to the plot of entertainment, product explanations, or metaphors for development plans. SimpleModeling limits this term to the semantic content expressed as a Narrative by a Literate Model. The compound term User Story is handled separately as a requirements technique in its own right. Japanese articles and videos introduce the term as ストーリー(story) and subsequently use ストーリー. The ordinary Japanese word 物語 may still be used when context requires it, but it is not automatically associated with this term. A Story is not synonymous with a Narrative. A Story is semantic content; a Narrative is a Literate Model that organizes it from a viewpoint, Purpose, and Context.Multiple Narratives may be constructed from the same Story.Story is not an abbreviation for User Story.NarrativeLiterate ModelUse Case Scenariosrc/main/doxsite/development-process/literate-modeling.doxsrc/main/doxsite/glossary/literate-modeling/narrative.doxdocs/spec/glossary-entry-format.md |
||
2026-08-29 |
Glossary |
New |
TermNarrativeAliases-Term ID: src/main/doxsite/glossary/literate-modeling/narrative.doxEnglish label: NarrativeJapanese label: ナラティブScope qualifier: Literate Modeling / viewpoint-dependent expression of a StoryBare-label linking: context-onlyCategory: Literate ModelingStatus: normativeDefinition authority: SimpleModeling BoKA Narrative is a Literate Model that selects, orders, and explains a Story according to a particular viewpoint, Purpose, and Context, organizing concrete situations and the meaning of change in a comprehensible form. It supports inductive understanding and sharing of the meaning of requirements, decisions, and Behavior between people and generative AI. Narrative is used broadly in literature, business, medicine, and other fields. SimpleModeling limits the term to an expression that has a subject, Purpose, meaning, and identity as a Literate Model and corresponds to design, decisions, or validation. The ordinary Japanese word 物語 is not automatically associated with this term. A Narrative functions as an inductive Model that derives meaning and patterns from concrete situations, events, and outcomes. A formal Model functions deductively by evaluating particular Behavior against generalized structures and rules. SimpleModeling uses the two as complements rather than opposites. A Use Case Scenario is a representative Literate Model and a Narrative that organizes one Story for achieving an Actor’s Goal from the user’s perspective. Narratives are not limited to Use Case Scenarios; they may also include decision histories, failure cases, usage situations, and change histories. Japanese articles and videos introduce the term as ナラティブ(narrative) and subsequently use ナラティブ. When distinguishing it from Story, they explain that a Story is the semantic content of what happens and a Narrative is the Literate Model that organizes it from a viewpoint, Purpose, and Context. A Narrative is not synonymous with a Story. Multiple Narratives may be constructed from the same Story.One Narrative does not necessarily cover every permitted Behavior.A Narrative is not a replacement for a formal Model.Ordinary prose without a Model Purpose or correspondence is not the Model defined by this term.Literate ModelingLiterate ModelStoryUse Case ScenarioExecution Example ModelInductionDeductionsrc/main/doxsite/development-process/literate-modeling.doxsrc/main/doxsite/glossary/literate-modeling/story.doxsrc/main/doxsite/glossary/development-process/use-case-scenario.doxdocs/spec/glossary-entry-format.md |
||
2026-08-29 |
Glossary |
New |
TermLiterate ModelingAliases-Term ID: src/main/doxsite/glossary/literate-modeling/literate-modeling.doxEnglish label: Literate ModelingJapanese label: 文芸モデリングScope qualifier: SimpleModeling / activity and method for constructing Literate ModelsBare-label linking: linkableCategory: Literate ModelingStatus: normativeDefinition authority: SimpleModeling BoKLiterate Modeling is the activity and method of describing subjects, purposes, situations, requirements, decisions, scenarios, intent, assumptions, history, and related information primarily in natural language and in an order and form people can understand, and organizing it as a Literate Model with explicit meanings, identities, and mappings to other Model elements. The term extends to modeling the idea of Donald E. Knuth’s Literate Programming: treating a program and its explanation in one document and presenting them in an order that supports human understanding. Literate Modeling denotes the activity and method; a Literate Model denotes the subject and result described and organized through that activity. In SimpleModeling, Literate Modeling relates natural-language information to Object and Knowledge Models and shares it among human developers, non-developers, and generative AI. Its important subjects include not only purpose-specific documents such as Vision statements and Use Cases, but also conventional documents that explain Domain Model concepts, rules, and relationships in natural language. An important use is supplying Use Case Scenarios directly to generative AI and connecting AI-proposed mappings to executable Models after human review and approval. A CML (Cozy Modeling Language) document is a concrete practice of Literate Modeling because its formal elements express an executable Object Model while natural-language explanation, intent, and assumptions in the same document express Literate Model content. A complete Literate Model is not expected to be expressed in CML. Accumulating natural-language documents alone is not Literate Modeling.Literate Modeling is not the work of attaching explanation to a formal Model afterward.Literate Modeling and a Literate Model are not synonymous; the former is an activity and method, while the latter is its subject and result.Literate ModelLiterate ProgrammingStoryNarrativeUse Case ScenarioCMLsrc/main/doxsite/development-process/literate-modeling.doxsrc/main/doxsite/glossary/literate-modeling/literate-model.doxdocs/spec/glossary-entry-format.md |
||
2026-08-24 |
Article |
New |
A Knowledge Model is a constituent of a SimpleModeling Model that supports defining Models through CML, reviewing a Domain Model, creating and reviewing a Use Case Model, and answering inquiries for Domain understanding. Terms defined in the Glossary map occurrences of the same concept across Object, Knowledge, and Literate Models. Generative AI presents candidates and explanations; people approve their meaning and evidence. |
||
2026-08-21 |
Glossary |
New |
An Embedding is a numerical-vector representation of text, terms, Model Elements, or related content that enables computation of semantic similarity. It is used for similarity search and candidate retrieval. |
||
2026-08-21 |
Glossary |
New |
The Model Context Protocol (MCP) is an open protocol for connecting applications that use generative AI with external data sources and tools and for providing context and capabilities in a standardized form. |
||
2026-08-21 |
Glossary |
New |
An Ontology is an explicit semantic structure of the concepts, classifications, relationships, and constraints in a subject domain, used to interpret knowledge consistently. |
||
2026-08-21 |
Glossary |
Update |
TermKnowledge ModelingAliases-Explicitly added evidence and sources to the scope of Knowledge Modeling and distinguished explicit semantic structures from retrieval and access technologies. Updated Knowledge Modeling as the activity of structuring knowledge shared by people and AI and contributing to a Domain Model together with Object and Literate Models. Knowledge Modeling is the activity of structuring concepts, semantic relationships, classifications, rules, evidence, sources, and related content in a SimpleModeling Model as a Knowledge Model that generative AI can retrieve, explore, relate, and interpret. RDF, ontologies, and Knowledge Graphs carry explicit semantic structure; embeddings and RAG support retrieval of relevant information; and MCP provides access to selected knowledge resources. A BoK is a knowledge resource assembled from documents, terms, Models, and semantic metadata. Generative AI uses these mechanisms to explore Object and Literate Model content and explain it to people. People primarily use the Knowledge Model through interaction with generative AI. The Glossary connects concepts in a Knowledge Model to the same concepts appearing in Object and Literate Models. Knowledge Modeling does not simply replace Business Modeling; it provides a foundation for domain experts, developers, and AI to reference multiple knowledge sources, including business knowledge, identify omissions and contradictions, and update models iteratively. |
||
2026-08-21 |
Glossary |
Update |
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. |
||
2026-08-17 |
Article |
New |
A SimpleModeling Model is composed of Object, Knowledge, and Literate Models, which are combined by purpose into Domain, Use Case, and Application Models. The Object Model contains an Executable Model that defines general structure and Behavior and an Execution Example Model that presents concrete executions such as Interactions. Execution examples provide inductive constraints for design and validation, while current CML targets only the Executable Model. CML, Cozy, and Textus absorb platform-oriented mechanisms so Object Modeling can focus on describing the Domain Model. |
||
2026-08-17 |
Glossary |
New |
TermUse Case ScenarioAliases-Term ID: src/main/doxsite/glossary/development-process/use-case-scenario.doxEnglish label: Use Case ScenarioJapanese label: ユースケースシナリオScope qualifier: Development Process / user-centered Narrative through a Use CaseBare-label linking: linkableCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoK, aligned with Use Case practiceA Use Case Scenario is a Narrative and Literate Model that organizes one Story for achieving an Actor’s Goal from the user’s perspective as events, actions, branches, and successful or failed Outcomes between the Actor and the subject system. A Use Case Scenario is expressed primarily in natural language and shared among developers, non-developers, and generative AI. AI may propose candidate Execution Example and Executable Models from the Scenario, while people review their meaning and mappings. A Use Case Scenario is not itself the formal Execution Example Model describing Interactions among Objects.One Scenario path does not by itself exhaust all Behavior admitted by a Use Case.Use CaseLiterate ModelStoryNarrativeExecution Example ModelInteractionUse Case Realization Modeldocs/journal/2026/08/2026-08-17-simplemodeling-model-components-and-object-model-scope.mddocs/spec/glossary-entry-format.md |
||
2026-08-17 |
Glossary |
New |
TermInteractionAliases-Term ID: src/main/doxsite/glossary/object-foundation/interaction.doxEnglish label: InteractionJapanese label: モデル上の相互作用Japanese short label: 相互作用Scope qualifier: Object Foundation / behavior as ordered participant communicationBare-label linking: explicit-onlyCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, aligned with UML 2.5.1An Interaction is Behavior that describes Messages, Operations, Events, and their ordering among participating Model Elements to achieve a particular purpose. It can represent one example of execution for a particular Scenario. In UML 2.5.1, an Interaction is Behavior describing communication among Lifelines through Messages and Occurrences. A Sequence Diagram is one notation for presenting an Interaction. SimpleModeling treats Interaction as a primary representation of an Execution Example Model. It concretizes a Use Case Scenario as participating Objects, responsibilities, Operations, Events, State Transitions, and successful or failed Outcomes. An approved Interaction may constrain the design and conformance of an Executable Model. Current CML (Cozy Modeling Language) does not directly include Interactions as execution examples in its scope. Reviewed Objects, Services, Operations, Events, StateMachines, and Constraints derived from an Interaction are projected into the CML Executable Model. Interaction is not synonymous with Collaboration, which describes a structure of participant Roles.Interaction is not an Executable Model that exhaustively defines every possible execution.BehaviorCollaborationExecution Example ModelUse Case ScenarioStateMachineOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
Glossary |
New |
TermExecutable ModelAliases-Term ID: src/main/doxsite/glossary/development-process/executable-model.doxEnglish label: Executable ModelJapanese label: 実行可能モデルScope qualifier: SimpleModeling / executable portion of Object ModelBare-label linking: linkableCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKAn Executable Model is an Object Model that defines general structures and rules such as Types, Objects, Relationships, responsibilities, Services, Operations, Events, StateMachines, Behavior, and Constraints and can be connected to program generation and execution. Permitted executions can be derived from its rules. An Executable Model is shared among human developers, programming-language representations, execution foundations, and generative AI. Current CML (Cozy Modeling Language) directly targets only the Executable Model portion of an Object Model. Cozy generates programs, and Textus provides the execution foundation. An Executable Model is distinct from an Execution Example Model that describes only concrete executions.Executable does not require the Model document itself to start as a process; it includes realization through generation or interpretation.Object ModelExecution Example ModelCMLdocs/journal/2026/08/2026-08-17-simplemodeling-model-components-and-object-model-scope.mddocs/spec/glossary-entry-format.md |
||
2026-08-17 |
Glossary |
New |
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. |
||
2026-08-17 |
Glossary |
New |
Use Case Modeling is the activity of constructing a Use Case Model of user and external-party intent toward a system using Actors, Goals, Use Cases, Scenarios, and Outcomes. |
||
2026-08-17 |
Glossary |
New |
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. |
||
2026-08-17 |
Glossary |
New |
TermAggregationAliases-Term ID: src/main/doxsite/glossary/object-foundation/aggregation.doxEnglish label: AggregationJapanese label: 集約関係Japanese short label: 集約Scope qualifier: Object Foundation / shared whole-part relationshipBare-label linking: explicit-onlyCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, aligned with UML 2.5.1 and narrowed for explicit modelingAggregation is a whole-part Association in which a Part is not exclusively Structurally Owned by, or Lifecycle-dependent on, one Whole and may be shared by multiple Wholes. SimpleModeling uses Aggregation only when the Whole and Part, sharing rule, and any additional Lifecycle constraints are made explicit. In UML 2.5.1, Aggregation is a whole-part Relationship represented by the shared Aggregation Kind of an Association End. UML does not define strong general semantics for shared aggregation, so SimpleModeling does not rely on the notation alone and records the Whole/Part roles, sharing, Multiplicity, and Lifecycle constraints in the model. The ordinary word aggregation is also used for collecting information, statistical aggregation, or service aggregation. The term defined here is a modeling whole-part Relationship. Combining data on one screen or collecting API results does not by itself establish Aggregation. Aggregation expresses a shareable whole-part structure on the Object side. It is distinct from collection aggregation or fold operations on the Functional side. When CML (Cozy Modeling Language) describes Aggregation, it makes the Whole and Part Ends, roles, Multiplicity, sharing rule, and required constraints explicit. Aggregation is not used when it adds no semantics beyond an ordinary Association. Scala collections, fields, and references may realize Aggregation, but they may also realize ordinary Associations or Composition. Aggregation is not inferred from language structure alone. Collections, Groups, Schemas, and related simplemodeling-lib constructs may realize an aggregate structure, but using those library Types alone does not establish shareable whole-part semantics. Japanese articles and videos introduce the term as 集約関係（Aggregation） and shorten it to 集約 only while the same modeling context remains established. Ordinary uses of 集約 are not automatically linked. Aggregation is not synonymous with an ordinary Association; it has explicit whole-part semantics.Unlike Composition, Aggregation does not imply exclusive Structural Ownership by one Whole.A collection, calculation, shared display, or API aggregation alone does not establish Aggregation.AssociationCompositionRelationshipStructural OwnershipMultiplicityLifecycleOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
Glossary |
New |
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. |
||
2026-08-17 |
Glossary |
New |
TermExecution Example ModelAliases-Term ID: src/main/doxsite/glossary/development-process/execution-example-model.doxEnglish label: Execution Example ModelJapanese label: 実行例モデルScope qualifier: SimpleModeling / inductive Object Model of concrete executionsBare-label linking: linkableCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKAn Execution Example Model is an Object Model that describes participants, Operations, Events, State Transitions, and Outcomes in a particular Scenario through an Interaction, execution trace, or related representation. It is an inductive Model: concrete examples indicate expected Behavior and may constrain an Executable Model. An approved positive example requires the Executable Model to admit the execution and reach the expected Outcome. A prohibited example may require the Executable Model to reject that execution. Execution Example Models support design, review, and validation of Operation and Event ordering, Preconditions, Postconditions, Outcomes, and State Transitions. Current CML (Cozy Modeling Language) does not include Execution Example Models in its scope. Execution examples relate to Use Case Realization Models and review artifacts stored under src/main/internal-model/, constraining the executable elements projected into CML. One execution example does not exhaustively define all executable Behavior.An Execution Example Model is not the natural-language Use Case Scenario itself; it concretizes the Scenario as formal participants and execution.It is not synonymous with the current CML Executable Model.Object ModelExecutable ModelInteractionUse Case ScenarioUse Case Realization Modeldocs/journal/2026/08/2026-08-17-simplemodeling-model-components-and-object-model-scope.mddocs/journal/2026/08/2026-08-17-use-case-realization-review-and-cml-workflow.mddocs/spec/glossary-entry-format.md |
||
2026-08-17 |
Glossary |
New |
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. |
||
2026-08-17 |
Article |
Update |
Part 4 takes the Model as its subject and composes Capabilities and Aspects through the Domain Model and Use Case Model axes. The Object Model makes the formal structure concrete, while purpose- and concern-selected Views support understanding, evaluating, and applying the complex Model. |
||
2026-08-17 |
Article |
Update |
A Knowledge System collects, organizes, and classifies existing technologies and provides a map for understanding them. A Software Development Methodology selects the needed technologies from that knowledge, defines their roles and use, and guides practice. A SimpleModeling Model is composed of an Object Model for formal structure and execution examples, a Knowledge Model for generative-AI knowledge structures, and a Literate Model for human-readable context and intent. Domain Modeling organizes the three constituents with emphasis on problem-domain meaning, structure, rules, and boundaries. Application Modeling organizes them with emphasis on Use Case realization, Collaborations, Interactions, state transitions, Events, Services, and Operations. Domain Modeling is not entirely static, and Application Modeling does not own every dynamic element. Approved executable formal structures are connected to executable software through CML, Cozy, AI, and Textus as Model Realization. Quality attributes remain cross-cutting design concerns. |
||
2026-08-17 |
Article |
Update |
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, AI, and Textus. |
||
2026-08-17 |
Glossary |
Update |
In UML, a Collaboration is a Classifier describing a structure of participant Roles that perform specialized functions and collectively accomplish desired functionality. |
||
2026-08-17 |
Glossary |
Update |
TermObject ModelAliases-Clarified the Object Model as a general foundation for describing the structure of various models, including Domain Models, rather than as a software-composition model derived from a Domain Model. An Object Model formally represents a subject through Objects, Types, Relationships, responsibilities, Interactions, Services, Operations, Events, StateMachines, Behavior, Constraints, and related elements. It includes both an Executable Model that defines general structures and rules and an Execution Example Model that describes concrete executions such as Interactions. The Executable Model defines permitted structure and Behavior and connects to program generation and execution. It is shared among human developers, programming-language representations, execution foundations, and generative AI. Current CML (Cozy Modeling Language) directly targets only this executable portion. An Execution Example Model describes concrete executions through Interactions or execution traces. It is inductive: examples indicate expected Behavior and may constrain the Executable Model during design, review, and validation. It is currently outside the scope of CML. The Object Model does not by itself represent the whole SimpleModeling Model. It corresponds with the Knowledge and Literate Models, while the Glossary connects the meaning and identity of concepts across all three. ModelExecutable ModelExecution Example ModelInteractionKnowledge ModelLiterate ModelDomain ModelApplication ModelApplication ModelingCML |
||
2026-08-17 |
Glossary |
Update |
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. |
||
2026-08-17 |
Glossary |
Update |
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. |
||
2026-08-17 |
Glossary |
Update |
TermDevelopment MethodAliases-Reflected the three SimpleModeling Model constituents and the separation of Domain, Use Case, and Application Modeling from Model Realization. Clarified a Development Method as a system of models and model transformations and positioned individual technologies such as DDD as components. Also reflected the structure in which a Domain Model spans Object, Knowledge, and Literate Models connected by a Glossary. A Development Method is a conceptual framework composed of models, relationships among models, model transformations, adopted technologies, and decision rules. It defines what is modeled in software development, how models are constructed, and how they are transformed into subsequent artifacts. The SimpleModeling Development Method maintains its constituent Models through Object, Knowledge, and Literate Modeling and organizes the three for particular purposes through Domain, Use Case, and Application Modeling. Use Case Modeling organizes Actors, Goals, Scenarios, and Outcomes. Domain Modeling emphasizes problem-domain meaning, structure, rules, and boundaries. Application Modeling emphasizes the dynamic path from Use Case Scenarios through Use Case Realization Models, Collaborations, and Interactions to StateMachines, Events, Services, and Operations. Approved Executable Models connect to CML, Cozy, AI, and Textus through Model Realization. GoF, PEAA, DDD, CQRS, Knowledge Graphs, and related technologies are selected by role as components of this Development Method. An individual technology is not treated as the complete Development Method. Process Styles and the Development Process define how the Development Method is operated through sequencing and iteration in practical development. This separation allows the same Development Method to be reused across different Process Styles and projects. |
||
2026-08-17 |
Glossary |
Update |
A Software Development Methodology is a coherent system of models, model transformations, technologies, design principles, and decision rules used in software development. It defines what is modeled, how models are constructed, and how they are connected to executable software. In general usage, a Software Development Methodology may also include a Development Process. SimpleModeling separates the Methodology that defines models and model transformations from the Development Process that operates it in practical development. |
||
2026-08-17 |
Glossary |
Update |
TermDomain ModelingAliases-Clarified that the Domain Model produced through Domain Modeling spans Object, Knowledge, and Literate Models, which are connected by a Glossary. Domain Modeling is the activity of organizing problem-domain terminology, concepts, rules, and boundaries into a Domain Model suited to a development purpose. It clarifies what is selected from the relevant reality and which view is used to represent it. SimpleModeling positions Domain Modeling as the activity of organizing the Model Elements required for problem-domain meaning, structure, rules, and boundaries from the Object, Knowledge, and Literate Models. It emphasizes static aspects, but this does not mean that it has no Behavior or State. It complements Application Modeling, which organizes the dynamic realization of Use Cases. The Glossary manages the meaning and identity of terms appearing in the three models and connects them. Domain experts, developers, and AI use the Glossary, Use Cases, Contexts, Bounded Contexts, Ubiquitous Language, and DDD to assess Domain Model validity iteratively. Domain ModelUse Case ModelingApplication ModelingApplication Model |
||
2026-08-17 |
Glossary |
Update |
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. |
||
2026-08-17 |
Glossary |
Update |
Domain-Driven Design is a set of principles, patterns, and practices for understanding a complex problem domain through a Domain Model and connecting business meaning with software design through Ubiquitous Language, Bounded Contexts, Aggregates, and related concepts. |
||
2026-08-17 |
Glossary |
Update |
TermObject ModelingAliases-Limited the current Object Modeling scope in SimpleModeling to Domain Models and placed formal description of other Models outside the present scope. Repositioned Object Modeling from an independent area parallel to Domain Modeling to a common structural foundation for various models, including the formal parts of Domain Models. Object Modeling is the activity of structuring a subject through Objects, Types, Relationships, responsibilities, Collaborations, Constraints, States, and StateMachines. It enables formal descriptions of static and dynamic Model structure, relationships among Model elements, and validity conditions. SimpleModeling currently applies formal Object Model description to Domain Models. Concepts, Relationships, rules, and Constraints that can be formalized are described through Object Model structures. Formal description of other Models is outside the current scope. Object Modeling has two responsibilities: describing the formal structure of its subject Model and assembling the mechanisms required to run that Model on a platform. In SimpleModeling, CML describes formal structure, Cozy generates programs, and Textus supplies the execution foundation, absorbing the latter responsibility. When working with a Domain Model, Object Modeling can therefore focus on formal structures of concepts, Relationships, responsibilities, Constraints, State, and Behavior. GoF, PEAA, Entities, Value Objects, and related technologies support the design of Object structure, responsibility, and collaboration. An Object Model contains an Executable Model that defines general rules and an Execution Example Model that presents concrete executions such as Interactions. Current CML targets only the Executable Model. The Knowledge and Literate Models are separate constituents of the same SimpleModeling Model, and the Glossary connects concepts across all three. |
||
2026-08-17 |
Glossary |
Update |
TermDomain ModelAliases-Clarified the Domain Model as a purpose-specific applied Model that organizes the elements required for problem-domain meaning, structure, rules, and boundaries from the three SimpleModeling Model constituents. Expanded the Domain Model from a model contained only in an Object Model to one spanning Object, Knowledge, and Literate Models, and clarified how a Glossary connects them. A Domain Model represents problem-domain terminology, concepts, rules, relationships, and boundaries as a view suited to a particular development purpose. It is not reality itself, but a representation selected and organized according to purpose and concern. A SimpleModeling Domain Model is an applied Model that selects and organizes the Model Elements required for problem-domain meaning, structure, rules, and boundaries from the Object, Knowledge, and Literate Models. It emphasizes static aspects, but this does not mean that it lacks Behavior or State. It complements the Application Model, which organizes dynamic Use Case realization. The Object Model contains executable formal definitions and concrete execution examples; the Knowledge Model provides structures primarily for generative AI to retrieve, explore, and relate Model content; and the Literate Model expresses Scenarios, decisions, and related information in natural language people can understand. The Glossary connects meaning and identity across the Models. The executable portion of the Object Model expressed in CML has a path to implementation and execution through Cozy and Textus. Domain ModelingApplication ModelApplication Modeling |
||
2026-08-17 |
Glossary |
Update |
TermRelationshipAliases-Term ID: src/main/doxsite/glossary/object-foundation/relationship.doxEnglish label: RelationshipJapanese label: モデル関係Japanese short label: 関係Scope qualifier: Object Foundation / relation among Model ElementsBare-label linking: explicit-onlyCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, aligned with UML 2.5.1A Relationship is a Model Element that represents a semantic or structural connection among Model Elements together with meaning such as its kind, direction, participating ends, roles, and constraints. Its precise semantics are determined by a Relationship kind such as Association, Dependency, Generalization, or Realization. In UML 2.5.1, Relationship is an abstract general concept for relations among Model Elements. Association, Dependency, Generalization, and Realization are concrete Relationships with different semantics. SimpleModeling preserves these distinctions and does not reduce every connection to an Association. The ordinary word relationship can describe a broad connection among people, events, documents, or other things. The modeling Relationship defined here is an identifiable Model Element with a specific Relationship kind and semantics. Ordinary prose uses of relationship are not references to this term. Relationship primarily expresses structure and meaning on the Object side. Functional-side connections such as composability, parameter/result Type correspondence, and effect propagation are distinguished as appropriate Type or function relations. CML (Cozy Modeling Language) describes the most specific applicable Relationship kind. Connecting two elements alone does not determine semantics, so distinctions among Association, Aggregation, Composition, Dependency, Generalization, and related kinds are preserved. Scala fields, inheritance, trait mix-ins, Type bounds, and function parameters may realize different modeling Relationships, but syntax alone does not always uniquely recover the domain Relationship kind. simplemodeling-lib Types and structures may realize modeling Relationships, but a library reference or containment alone does not determine Relationship semantics. The canonical model Relationship and its CML declaration remain the semantic basis. Japanese articles and videos introduce the concept as モデル関係（Relationship） and shorten it to 関係 only while the modeling context remains unambiguous. Ordinary uses of 関係 are not automatically linked. When the concrete kind is known, a specific term such as Association, Aggregation, or Composition is used instead of only the general Relationship label. Relationship does not denote every ordinary use of the word relationship.Relationship and Association are not synonyms; Association is one kind of Relationship.A drawn connection alone does not establish a Relationship kind or its semantics.SimpleModeling does not treat a Relationship as merely a drawn line; it makes the Relationship’s meaning, responsibility ownership, Multiplicity, and validity conditions explicit. AssociationAggregationCompositionRealizationDependencyGeneralizationMultiplicityOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
Glossary |
Update |
Execution Modeling is a legacy SimpleModeling term that combined dynamic Use Case concretization with the connection from Models to implementation and execution. The current methodology separates these concerns into Application Modeling and Model Realization. |
||
2026-08-17 |
Glossary |
Update |
TermModeling Technology SystemAliases-Replaced the peer-level four-area structure of Object, Domain, Execution, and Knowledge with explicit modeling roles, dependencies, and connections among models through a Glossary. A Modeling Technology System organizes modeling technologies by modeling subject, purpose, outputs, and relationships with other models rather than by technology name alone. It not only classifies technologies but also defines the roles and use of technologies adopted by a Development Method. The SimpleModeling Modeling Technology System positions Object, Knowledge, and Literate Modeling as activities that maintain the three Model constituents; Domain, Use Case, and Application Modeling as activities that organize purpose-specific applied Models from those constituents; and Model Realization as the connection from approved Models to executable artifacts. These are not independent areas at the same level; they have distinct roles and dependencies. Domain, Use Case, and Application Models are not additional constituents alongside the three. A Domain Model organizes problem-domain meaning, structure, rules, and boundaries; a Use Case Model organizes Actors, Goals, Scenarios, and Outcomes; and an Application Model organizes Use Case realization and dynamic structure from the three constituents. Quality Attributes are cross-cutting design concerns examined against requirements, constraints, and realization methods. |
||
2026-08-17 |
Glossary |
Update |
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. |
||
2026-08-17 |
Glossary |
Update |
TermAssociationAliases-Term ID: src/main/doxsite/glossary/object-foundation/association.doxEnglish label: AssociationJapanese label: モデル上の関連Japanese short label: 関連Scope qualifier: Object Foundation / Association among typed instancesBare-label linking: explicit-onlyCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, aligned with UML 2.5.1An Association is a modeling Relationship that classifies a set of possible Links among typed Instances and expresses participating Types, Association Ends, roles, Multiplicity, navigation, and related semantics. SimpleModeling uses it to describe domain or structural meaning among Objects separately from implementation references. In UML 2.5.1, an Association is a Relationship that classifies a set of Links, where each Link is a tuple of values referring to typed Objects. An Association End expresses a participating Type, role, Multiplicity, and related properties. Aggregation and Composition are whole-part Relationships represented by the Aggregation Kind of an Association End. The ordinary word association or relation may describe a loose connection among topics, documents, or events. The Association defined here is a Model Element with participating Ends and constraints. Ordinary prose such as related documents or related processing is not a reference to this term. SimpleModeling uses Association as the basic Relationship for expressing domain or structural meaning among Objects. It is not identified with a reference implementation or database foreign key. Association expresses structure on the Object side. It is distinct from functional dependency or function composition; using functions to operate on an Association does not identify those concepts. CML (Cozy Modeling Language) makes Association Ends, roles, Multiplicity, navigation, and required constraints explicit. When whole-part semantics apply, the model uses Aggregation or Composition rather than leaving the meaning as an undifferentiated Association. Scala fields, references, and collections may realize an Association, but do not by themselves fully express its domain meaning, roles, Multiplicity, ownership, or Lifecycle. simplemodeling-lib attributes, collections, schemas, and related structures may realize Associations. The Relationship kind is preserved from the canonical model rather than inferring Association, Aggregation, or Composition from implementation Types alone. Japanese articles and videos introduce the term as 関連（Association）. Because the ordinary word 関連 is not registered as a bare SmartDox auto-link candidate, the glossary uses the qualified canonical label モデル上の関連. The short form is used only after the modeling concept is established. Association is not synonymous with Relationship in general.Association is not synonymous with Aggregation or Composition; whole-part and ownership semantics must be explicit.A program reference or database foreign key alone does not establish a modeling Association.RelationshipAggregationCompositionMultiplicityOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
Glossary |
Update |
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. |
||
2026-08-17 |
Glossary |
Update |
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. |
||
2026-08-17 |
Glossary |
Update |
TermLiterate ModelAliases-Term ID: src/main/doxsite/glossary/literate-modeling/literate-model.doxEnglish label: Literate ModelJapanese label: 文芸モデルScope qualifier: SimpleModeling / natural-language-centered constituent ModelBare-label linking: linkableCategory: Literate ModelingStatus: normativeDefinition authority: SimpleModeling BoKA Literate Model is a natural-language-centered Model that describes a subject, purposes, situations, scenarios, intent, assumptions, decisions, history, and related information in forms people can understand. Conventional documents that explain Domain Model concepts, rules, and relationships are also important constituents. It is shared among human developers, non-developers, and generative AI, and retains as part of the Model information that cannot, or should not, be reduced to an Object Model or Knowledge Model. A Literate Model is not synonymous with a formal Model plus explanatory documentation or with documentation written after implementation. Its natural-language content is itself part of the Model and serves as input to design and realization. A Literate Model records purposes, scenarios, decisions, and usage context that cannot be retained solely in formal structures on the Object or Functional side, and relates them to the formal Model. Current CML (Cozy Modeling Language) is scoped to the executable portion of the Object Model. A complete Literate Model is not expected to be expressed in CML. Only formal elements extracted from and reviewed against a Literate Model are projected into CML. A Use Case Scenario is one kind of Literate Model. Articles, requirements, Stories, decision records, and natural-language documents explaining the Domain Model may also constitute Literate Models when they are related to stable Model meaning and identities and serve as input to design, understanding, or validation. A SimpleModeling Model treats the Literate Model as a constituent alongside the Object and Knowledge Models. SmartDox is the primary descriptive foundation for natural language, structured documents, diagrams, and term references. Glossary identities connect Literate Model content to the Object and Knowledge Models. A Literate Model is not supplemental explanation for an Object Model.A Literate Model is not synonymous with a Knowledge Model that structures semantic relationships for generative AI.Natural-language text alone is not necessarily a Literate Model; it must correspond to Model purpose, meaning, identity, design, or validation.ModelObject ModelKnowledge ModelUse Case ScenarioGlossarydocs/journal/2026/08/2026-08-17-simplemodeling-model-components-and-object-model-scope.mddocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermPersistenceAliases-Term ID: src/main/doxsite/glossary/development-process/persistence.doxEnglish label: PersistenceJapanese label: 永続化Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKPersistence is a platform mechanism that retains required information beyond a program execution or process lifetime and makes it recoverable by later executions. Not applicable. Persistence is a platform realization mechanism, not a term defining UML classification relationships. CML can describe domain structures and constraints that are persisted without making a particular persistence method part of Domain Model meaning. Scala can implement persistence mechanisms, but Scala Types are not identified with persistence formats. The schemas, Data Types, and Value Domains in simplemodeling-lib can provide contracts at persistence boundaries. A separate platform configuration owns the concrete storage mechanism. Japanese videos introduce the term as 永続化(persistence). Persistence is not the identity of a Domain Object itself.A persistence method is not unconditionally embedded in Domain Model meaning.PlatformDomain ModelSchema Data TypeRuntime Data Typesrc/main/doxsite/glossary/development-process/platform.dox/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/schema/Schema.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermTyped ElementAliases-Term ID: src/main/doxsite/glossary/object-foundation/typed-element.doxEnglish label: Typed ElementJapanese label: 型付き要素Category: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKA Typed Element is a model element that references a Type, which constrains the values the element may represent. SimpleModeling adopts UML 2.5.1 TypedElement. Properties, Parameters, and similar elements are Typed Elements, and their Types constrain the values they can represent. CML attributes, operation parameters, results, and similar elements are treated as Typed Elements because they designate Types. CML elements are not identified one-to-one with UML metamodel elements. During realization, a Typed Element’s model Type is mapped to the Type of a Scala field, parameter, result, or similar construct. This is a transformation, not identity between model and Scala Types. In simplemodeling-lib, a Schema.Column has a ValueDomain, which combines a DataType, multiplicity, and constraints. This is one realization corresponding to a Typed Element, not its canonical definition. Japanese articles and videos introduce this term as 型付き要素(typed element) and use it when explaining the UML relationship among Type, Classifier, and Class. A Typed Element is not a Type; it is the element whose values are constrained through a Type reference.A model Typed Element and a Scala variable, parameter, or result are not identical concepts.TypeClassifierClassAttributeOperationOMG Unified Modeling Language 2.5.1/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/schema/Schema.scala/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/schema/DataType.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermCommunicationAliases-Term ID: src/main/doxsite/glossary/development-process/communication.doxEnglish label: CommunicationJapanese label: 通信Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKCommunication is a platform mechanism for exchanging information between distinct execution participants or boundaries according to an agreed protocol and data contract. UML Messages and Communication Diagrams can represent communication, but this term does not mean a particular UML diagram. CML can describe the semantic structures being exchanged. Mechanisms such as transport and retry are separated into the platform side. Scala can implement communication processing, but Scala Types alone do not guarantee protocol compatibility. The Schema, HTTP, and result representations in simplemodeling-lib can support contracts at Communication boundaries. A concrete Communication runtime is a separate realization responsibility. Japanese videos introduce the term as 通信(communication). Communication is not synonymous with Association or Collaboration among Objects.PlatformCollaborationSchema Data Typesrc/main/doxsite/glossary/development-process/platform.dox/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/http/HttpRequest.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermPowertypeAliases-Term ID: src/main/doxsite/glossary/object-foundation/powertype.doxEnglish label: PowertypeJapanese label: パワータイプCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKA Powertype is a Classifier that explicitly defines a classification axis for Classes or Objects together with the classification values available on that axis. In SimpleModeling, Generalization expresses a general-to-specific hierarchy among Classifiers, whereas a Powertype models an axis and its categories, such as customer type or product category. In UML 2.5.1, a Powertype is a Classifier designated by the powertype property of a GeneralizationSet, with its Instances corresponding to the specific Classifiers in that GeneralizationSet. SimpleModeling aligns with this usage while extending it so a classification axis and its categories can remain explicit Model Elements even when every concrete subclass is not modeled. A strict UML mapping uses a GeneralizationSet and Powertype Classifier; a category-value mapping may use an Enumeration or a Profile. In business systems, a Powertype may be implemented in a form resembling a classification code, reference-data table, or enum. A Powertype is not merely a list of code values: it owns the Domain Model meaning of what is classified and by which axis. A display-label list or database master table alone is not a Powertype. On the object side, a Powertype represents a classification axis and its categories for Objects or Classifiers. On the functional side, a closed Powertype may connect to a sum type, enum, and pattern matching so category-specific processing can be checked through Types. Whether an open classification is reduced to a closed enum is a separate realization decision. CML (Cozy Modeling Language) defines Powertype as an Object kind and describes its classification values as Kinds. A classified Class, Entity, or related element may reference a Powertype. The CML Powertype, its relationship to a classified element, and a generated program Type are related but are neither identical nor necessarily mapped one-to-one. A closed Powertype may be realized in Scala as an enum, a sealed trait with case objects, or a generated Type carrying values. The current SimpleModeler generates a Scala class family with enumeration values from Powertype Kinds. Categories may carry logical values, datastore values, and display labels, but the Scala representation is not the canonical definition of Powertype. The current simplemodeling-lib does not define one universal base representing an Object Model Powertype. SimpleModeler owns the model representation and Scala code generation, while simplemodeling-model owns the base contract used by generated code. Schemas, Data Types, and Value Domains from simplemodeling-lib may support value contracts at boundaries, but they do not replace the classification semantics of a Powertype. Japanese articles and videos introduce the term as パワータイプ（Powertype）. Introductory material explains it as “an element that models a classification axis and the categories used on that axis” and contrasts it with Generalization as “Generalization provides a general-to-specific hierarchy; Powertype provides an axis and categories.” The UML GeneralizationSet mechanism is discussed only when a precise metamodel explanation is required. Powertype is not synonymous with Generalization. Generalization is a taxonomic Relationship among Classifiers, while a Powertype is a Classifier representing an axis and its categories.A Powertype is not a kind of Association or Dependency and is not itself treated as a Relationship among Objects.Powertype is not synonymous with an enum, classification code, display-label list, or reference-data table.Powertype is not synonymous with StateMachine. A Powertype describes classification, whereas a StateMachine describes state transitions over time.A CML Powertype and a Scala Type do not necessarily map one-to-one.GeneralizationClassifierClassTypeObjectRelationshipStateMachineCMLOMG Unified Modeling Language 2.5.1src/main/doxsite/domain-modeling/domain-model-elements.doxsrc/main/doxsite/glossary/object-foundation/classifier.doxsrc/main/doxsite/glossary/object-foundation/generalization.doxsrc/main/doxsite/glossary/object-foundation/type.dox/Users/asami/src/dev2025/simple-modeler/src/main/scala/org/simplemodeling/model/MPowertype.scala/Users/asami/src/dev2025/simple-modeler/src/main/scala/org/simplemodeling/model/MPowertypeKind.scala/Users/asami/src/dev2025/simple-modeler/src/main/scala/org/simplemodeling/SimpleModeler/transformers/scala/PowertypeScalaModelTransformer.scala/Users/asami/src/dev2026/simplemodeling-model/src/main/scala/org/simplemodeling/model/powertype/Powertype.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermMonitoringAliases-Term ID: src/main/doxsite/glossary/development-process/monitoring.doxEnglish label: MonitoringJapanese label: 監視Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKMonitoring is an operational activity that continuously collects system states and events, detects deviations from expectations, and notifies people or automated controls. Not applicable. Monitoring is a runtime operational activity, not a classification of UML model elements. CML can provide the meaning of monitored Capabilities, Aspects, States, and Operations. Collection, evaluation, and notification mechanisms are separated into runtime infrastructure. Scala can implement Monitoring, but no particular logging or metrics API defines the canonical concept. Observation, Trace, Resource, Environment, and related facilities in simplemodeling-lib provide implementation contracts for the meaning of Monitoring data. Japanese videos introduce the term as 監視(monitoring). Observability is distinguished as a system property that enables effective Monitoring. Monitoring and Observability are not synonyms. Monitoring is an activity; Observability is the property that makes internal state understandable from external signals.ObservabilityPlatformAspectRuntime Resourcesrc/main/doxsite/glossary/architecture/observability.dox/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/observation/Observation.scala/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/observation/calltree/CallTree.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermModel RealizationAliases-Term ID: src/main/doxsite/glossary/development-process/model-realization.doxEnglish label: Model RealizationJapanese label: モデルの実現Japanese short label: 実現Scope qualifier: Development Process / model-to-executable realization pathBare-label linking: explicit-onlyCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKModel Realization is the development process or realization path that maps a Model’s meaning, formal structure, and contracts to programs and executable artifacts while preserving Traceability. It may include model transformation, program generation, generative-AI completion, integration, and placement on an execution foundation. Model Realization is not itself UML 2.5.1 Realization. A Realization Relationship may be used within a Model Realization path to represent the correspondence between specification and implementation Model Elements. This term is narrower than ordinary statements about realizing an idea or achieving a purpose. It concerns a concrete path that connects model content to implementation and execution and preserves Traceability across that mapping. In the Object-Functional Paradigm, Model Types, Capabilities, Constraints, States, and related elements are mapped to Object-side structure and behavior and to Functional-side Types, functions, results, and Effects. Model Realization is not limited to simple code generation into only one side of the paradigm. In the standard SimpleModeling realization path, CML (Cozy Modeling Language) carries the formal Model description, Cozy performs transformation and program generation, generative AI completes necessary implementation, and Textus provides the execution foundation. This allows Object Modeling to focus on Domain Model structure rather than handcrafting platform mechanisms. Scala is one of the primary implementation targets in SimpleModeling and provides Type representations that connect Object and Functional concerns. Model Realization is not limited to Scala code generation and may also include configuration, Schemas, Tests, Adapters, and Runtime artifacts. simplemodeling-lib provides vocabulary and implementation elements for mapping Model meaning to Scala and Runtime artifacts. The library alone does not own the complete Model Realization path; the path is formed through its collaboration with CML, Cozy, generative AI, and Textus. Japanese articles and videos use モデルの実現（Model Realization） at first occurrence. 実現経路 may be used when emphasizing the path. The short label 実現 is used only after the model-to-implementation-and-execution context has been established. Model Realization is not UML Realization.It does not mean merely publishing an article or diagram or rendering a video.It is not limited to one-to-one automatic program generation.It is not synonymous with Application Modeling. Application Modeling constructs semantic executable structures from Use Cases; Model Realization connects approved structures to programs and an execution foundation.RealizationCMLExecutable SpecificationApplication ModelingApplication ModelModelTraceabilitysrc/main/doxsite/development-process/what-simplemodeling-has-pursued.doxsrc/main/doxsite/development-process/modeling-technology-system.doxsrc/main/doxsite/glossary/development-process/application-modeling.doxsrc/main/doxsite/glossary/object-foundation/realization.doxdocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermInterfaceAliases-Term ID: src/main/doxsite/glossary/object-foundation/interface.doxEnglish label: InterfaceJapanese label: インターフェースCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKAn Interface is a named object-side Type contract that specifies Operations, Responsibilities, and Protocols offered externally by an Object without fixing its internal state or implementation. A Class may provide or realize one or more Interfaces. In UML 2.5.1, an Interface is a Classifier and therefore a Type that specifies a coherent set of externally observable Services. A BehavioredClassifier such as a Class may realize the contract through an InterfaceRealization. SimpleModeling adopts this basic relationship. Programming-language interfaces and traits have different capabilities across languages, including state, default methods, mixins, and type-class roles. A SimpleModeling Interface is an Object Model contract rather than a language syntax construct and is not synonymous with any particular language interface or trait. Interface expresses an object-side contract through subtype polymorphism. Its role differs from a Type Class that adds behavior to an existing Type and from a Trait that composes a reusable partial structure. The current public CML (Cozy Modeling Language) syntax does not yet define a dedicated Interface Object kind. Introducing an external Operation or Responsibility contract into CML requires an explicit Interface representation distinguishable from a Trait that may carry structure or default behavior. Interface and Trait are not treated as synonyms while that dedicated syntax remains unsettled. Scala has no separate interface syntax corresponding directly to Java’s; an object-side Interface is commonly realized by a trait. A Scala trait can also represent a mixin, SimpleModeling Trait, supplementary Capability, or Type Class, so it does not always denote a SimpleModeling Interface. Whether a Scala trait in simplemodeling-lib corresponds to an Object Model Interface depends on whether its contract expresses only an external Responsibility of the Object itself. The implementation form alone does not determine that it is an Interface. Japanese articles and videos introduce the term as インターフェース（Interface）. They may explain that an Interface is used when only the object-side contract is needed, without reducing Type in general to Interface. Interface is not synonymous with Type as a whole, Class, or Trait.Interface does not fix internal state or realization.Interface is not synonymous with Scala trait or Type Class.TypeClassifierClassTraitOperationResponsibilityType ClassOMG Unified Modeling Language 2.5.1Scala 3 Referencedocs/spec/glossary-entry-format.md/Users/asami/src/dev2025/simplemodeling-lib/ai/directive/core/type-modeling.md |
||
2026-08-16 |
Glossary |
New |
TermRealizationAliases-Term ID: src/main/doxsite/glossary/object-foundation/realization.doxEnglish label: RealizationJapanese label: 実現関係Japanese short label: 実現Scope qualifier: Object Foundation / specification-implementation relationshipBare-label linking: explicit-onlyCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, aligned with UML 2.5.1Realization is a directed Abstraction Relationship in which a client Model Element implements or makes concrete the specification supplied by another Model Element and conforms to its contract. It makes the correspondence explicit while preserving the distinct roles of specification and implementation. In UML 2.5.1, Realization is a Dependency that specializes Abstraction. The Supplier represents a specification and the Client represents its implementation. InterfaceRealization is a specialized Realization in which a BehavioredClassifier realizes the contract of an Interface. Ordinary statements such as realizing a goal or implementing a feature do not necessarily denote a Realization Relationship between Model Elements. This term is used when the specification, implementation, and conformance between them are explicit. Both an Object-side Class implementing an Interface contract and a Functional-side implementation satisfying a function contract can be described as specification-implementation correspondences. Type correspondence or function definition alone, however, does not establish UML Realization. CML (Cozy Modeling Language) can explicitly model a Class, Entity, Component, or related element realizing an Interface or contract. The overall path that generates programs and executable artifacts from CML is Model Realization and is distinct from an individual Realization Relationship. A Scala class or object implementing a trait may realize a modeled specification, but the extends syntax alone does not determine the specification-implementation meaning in the Model. Contracts, Interfaces, and implementation Types in simplemodeling-lib may provide evidence of Realization, but not every inheritance or Type-conformance relation in the library is treated as Realization. Japanese articles and videos use 実現関係（Realization） at first occurrence. The short label 実現 is used later only when the specification-implementation Relationship between Model Elements is clear. The ordinary verb 実現する is not automatically linked to this term. Realization is not the Model Realization development process.Realization is not Generalization.Not every Dependency is a Realization.It is not synonymous with the ordinary verb “to realize” or “to implement.”InterfaceDependencyRelationshipModel RealizationTypeClassOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermTraitAliases-Term ID: src/main/doxsite/glossary/object-foundation/trait.doxEnglish label: TraitJapanese label: トレイトCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKA Trait is a SimpleModeling-specific Classifier that defines reusable Features, Responsibilities, Capabilities, and Constraints as a partial model composable into multiple Classes or other Traits. A Trait is an Object Model element for cross-cutting structure and behavior rather than a Domain Model’s conceptual trunk or an independent unit of instantiation. UML 2.5.1 has no distinct Trait metaclass. In a UML Profile mapping, a SimpleModeling Trait is represented by default as an abstract Class carrying a «trait» stereotype, preserving Attributes, Associations, Operations, Constraints, and default Behavior. A contract-only Trait may be reduced to an Interface, but that mapping can lose partial structure or default Behavior. Generalization represents Trait application only when substitutability holds; a profile-specific relationship is required to represent mixin composition precisely. Trait meanings differ across languages. A SimpleModeling Trait is not another name for Scala syntax; it is a Model Element defined in CML. Scala trait is a natural realization target, but not every language-level trait represents a SimpleModeling Trait. On the object side, a Trait separates cross-cutting Capabilities and partial structures from an Object’s conceptual trunk and composes them into Classes. On the functional side, the same Capability may connect to functions, result types, effects, and type classes. A SimpleModeling Trait and a Type Class remain distinct concepts. CML (Cozy Modeling Language) defines Trait as an Object kind. A Trait may describe reusable Attributes, Associations, Operations, Responsibilities, Constraints, and related elements and be composed by Classes or other Traits. A Class’s conceptual Identity or Lifecycle is not moved into a Trait merely for reuse. Scala trait is a primary realization target for a SimpleModeling Trait. Abstract and concrete members and mixin composition can realize partial structure and default Behavior. A generation policy may split one CML Trait across multiple Scala traits or supporting Types, so the mapping is not necessarily one-to-one. The simplemodeling-lib Type Modeling Rule uses abstract class for conceptual trunks, inheritance invariants, state, and constructor semantics and uses trait for supplementary composable Capabilities. This aligns with the intent of SimpleModeling Trait, but implementation traits such as Holders, utilities, and type classes are not all promoted to Model Traits. Japanese articles and videos introduce the term as トレイト（Trait）. Its distinction from Class is explained as "a Class is a conceptual trunk; a Trait is a reusable partial model composed into multiple Classes." Its distinction from Interface is explained as "an Interface is an external contract; a Trait is a partial model that may also carry structure and default Behavior." Trait is not synonymous with Class and is not the primary classification unit for independent Instances.Trait is not synonymous with Interface. A Trait may carry structure, Constraints, and default Behavior.SimpleModeling Trait is not synonymous with Scala trait.Trait is not synonymous with Type Class.TypeClassifierClassInterfaceFeatureResponsibilityCapabilityObject-Functional ParadigmOMG Unified Modeling Language 2.5.1Scala 3 Referencesrc/main/doxsite/literate-modeling/cml-syntax.doxdocs/spec/glossary-entry-format.md/Users/asami/src/dev2025/simplemodeling-lib/ai/directive/core/type-modeling.md |
||
2026-08-16 |
Glossary |
New |
TermScalaAliases-Term ID: src/main/doxsite/glossary/object-functional-programming/scala.doxEnglish label: ScalaJapanese label: ScalaCategory: Object-Functional ProgrammingStatus: normativeDefinition authority: SimpleModeling BoKScala is a programming language that combines object-oriented and functional constructs in one static type system and is a primary realization target for connecting CML model structures to executable programs in SimpleModeling. UML Type, Classifier, and Class are not identical to Scala type, trait, and class. They are mapped when a design model is realized in the implementation language. Scala connects object-side structures such as classes, traits, and enums with functional-side structures such as functions, values, effects, and composition through a shared type system. SimpleModeling uses this property to realize its Object-Functional Paradigm. Cozy maps CML model elements to Scala classes, traits, case classes, enums, function types, and other constructs. This is a meaning-based transformation and is not necessarily one-to-one. This viewpoint treats Scala-specific constructs such as class, trait, case class, enum, opaque type, union type, intersection type, and function type as language constructs used to realize models. These Scala constructs can be mapped to UML and CML Types, Classifiers, and Classes, but they are neither identical concepts nor fixed one-to-one correspondences. simplemodeling-lib is implemented in Scala 3 and provides runtime contracts for Schema Data Types, Runtime Data Types, Value Domains, multiplicity, constraints, and related concepts. The library’s current structure is not the definition of the Scala language. Scala is a proper name and remains Scala in Japanese articles and videos. Its English label is not redundantly repeated at first occurrence. A Scala Type is not identical to a CML model Type.Scala is a realization target, not the authority for SimpleModeling model meaning.TypeClassTraitObject-Functional ParadigmCMLScala 3 Reference/Users/asami/src/dev2025/simplemodeling-lib/build.sbt/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/schema/DataType.scala/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/schema/Schema.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermExecution ControlAliases-Term ID: src/main/doxsite/glossary/development-process/execution-control.doxEnglish label: Execution ControlJapanese label: 実行制御Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKExecution Control is a platform mechanism that coordinates program start, ordering, concurrency, waiting, retry, cancellation, and completion. UML Activities, StateMachines, and Interactions can represent execution order but are not themselves the platform mechanism of Execution Control. CML describes the meaning of Operations, States, Constraints, and Collaborations. Execution control such as threads, jobs, and retry is separated into generation and runtime infrastructure while preserving that meaning. Scala functions, Futures, and effect systems can implement Execution Control, but no particular Scala API is identified with the concept. Process, Consequence, StateMachine, and related facilities in simplemodeling-lib can support Execution Control contracts. Textus and related runtime infrastructure own the overall control strategy. Japanese videos introduce the term as 実行制御(execution control). Execution Control is not a State or StateMachine itself.Execution Control does not replace Domain Model meaning.PlatformStateMachineOperationsrc/main/doxsite/glossary/development-process/platform.dox/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/statemachine/Model.scala/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/process/ShellCommandExecutor.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermRuntime ResourceAliases-Term ID: src/main/doxsite/glossary/development-process/runtime-resource.doxEnglish label: Runtime ResourceJapanese label: 実行リソースCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKA Runtime Resource is a technical resource required by program execution whose acquisition, sharing, use, and release lifecycle is managed by the runtime platform. Not applicable. Runtime Resource does not define the general UML classification of Classifiers or Objects. A CML Domain Model is separated from concrete Runtime Resource acquisition and release. If a domain Resource concept is modeled, its business meaning and identity are defined separately. Scala can implement Resource management through safe acquire-use-release structures, but no particular library form defines the canonical term. simplemodeling-lib includes Types that represent files, URLs, execution environments, and other observed Resources. This is one implementation viewpoint on Runtime Resources, not the whole lifecycle-management concept. Japanese videos avoid the ambiguous label リソース and introduce the term as 実行リソース(runtime resource). A Runtime Resource is not synonymous with a domain Resource Object that has business meaning and identity.A Runtime Resource is not itself a Component.PlatformComponentLifecyclesrc/main/doxsite/glossary/development-process/platform.dox/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/observation/Resource.scala/Users/asami/src/dev2025/simplemodeling-lib/src/main/scala/org/goldenport/observation/Observation.scaladocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermStructural OwnershipAliases-Term ID: src/main/doxsite/glossary/object-foundation/structural-ownership.doxEnglish label: Structural OwnershipJapanese label: 構造上の所有Japanese short label: 所有Scope qualifier: Object Foundation / whole-part structureBare-label linking: explicit-onlyCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, grounded in UML 2.5.1 CompositionStructural Ownership is the meaning, within a whole-part Relationship, that the Whole includes a Part in its structural boundary and is responsible for the Part’s existence, Lifecycle, and Invariants. It denotes semantic responsibility for the Part as part of the Whole, not merely holding a reference to it. UML 2.5.1 has no independent Metaclass named Structural Ownership. SimpleModeling uses this term to make explicit the Composition semantics that the composite Object is responsible for the existence and storage of its Parts and that a Part is included in at most one composite Whole at a time. Ordinary ownership may mean legal title, access rights, data stewardship, or organizational responsibility. Structural Ownership is limited instead to whole-part structure in an Object Model. On the Object side, Structural Ownership identifies the boundary that governs change and Invariants. On the Functional side, reconstruction of immutable values may realize the same meaning, but value containment or function application alone is not called Structural Ownership. CML (Cozy Modeling Language) represents Structural Ownership through Composition. An ordinary Association, field, reference, or Multiplicity alone does not imply Structural Ownership. Scala fields, case classes, collections, and nested Types can implement Structural Ownership, but the Scala Type system alone does not determine the domain ownership boundary. simplemodeling-lib has no single Type that maps one-to-one to Structural Ownership. Collections, Groups, Schemas, and related constructs may be realization elements, while the model’s Composition and Invariants determine the meaning. Japanese articles and videos use 構造上の所有（Structural Ownership） at first occurrence. The short label 所有 is used later only while the whole-part context remains clear. Uses meaning legal ownership, access rights, or responsibility assignment are not automatically linked to this term. Structural Ownership is a meaning; Composition is the Relationship that carries that meaning.It is distinct from Responsibility, State, data stewardship, access rights, and organizational assignment.It is not inferred from a reference, field, foreign key, delete cascade, or visual containment alone.Multiplicity does not imply Structural Ownership.CompositionAssociationAggregationRelationshipLifecycleInvariantResponsibilityOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
New |
TermTransactionAliases-Term ID: src/main/doxsite/glossary/development-process/transaction.doxEnglish label: TransactionJapanese label: トランザクションCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKA Transaction is a platform mechanism that treats multiple state changes as one execution boundary, committing them on completion or restoring a consistent state on failure. Not applicable. Transaction does not define the UML classification of Classes or Objects. CML can describe operation preconditions, postconditions, invariants, and state changes. Concrete Transaction boundaries are designed by separating domain meaning from platform realization. Scala can implement Transaction control, but a language-level function call or exception boundary is not automatically a Transaction boundary. simplemodeling-lib provides contracts for states, constraints, and results, but no single generic Transaction runtime is treated as this term’s canonical definition. Japanese videos introduce the term as トランザクション(transaction). Transaction is not synonymous with Use Case, Operation, or Capability.A domain business unit and a technical Transaction boundary are not necessarily one-to-one.PlatformStateOperationInvariantPreconditionPostconditionsrc/main/doxsite/glossary/development-process/platform.doxsrc/main/doxsite/glossary/object-foundation/invariant.doxdocs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
Update |
TermClassAliases-Term ID: src/main/doxsite/glossary/object-foundation/class.doxEnglish label: ClassJapanese label: クラスCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKA Class is a primary Object Model element that classifies a set of Objects and formally describes their structure, state, behavior, and responsibilities. A Class is a named object-side Type and describes that Type’s model-level realization. In UML 2.5.1, a Class is a Classifier that classifies a set of Objects and specifies Features that characterize their structure and behavior. Class specializes Classifier, and Classifier specializes Type, so a Class is itself a Type. The phrase "model-level realization" in SimpleModeling describes its explanatory role and does not denote a UML Realization relationship. A Class represents an object-side conceptual trunk, intrinsic state, invariants, operations, and lifecycle. Reusable partial structures and Capabilities composed across multiple Classes may be separated into Traits, while externally visible contracts may be separated into Interfaces. The Type induced by a Class can connect to functional contracts such as functions, results, effects, and type classes. The current public CML (Cozy Modeling Language) syntax defines concrete Object kinds such as Entity and Value rather than a generic Class Object kind. These are treated as Class-like Classifiers, while shared partial structures may be separated into Traits. Cozy may realize a Model Class using a combination of Scala abstract classes, classes, case classes, traits, and other constructs according to meaning, so the Model Class and Scala class do not have a one-to-one mapping. A Scala class declaration introduces both a Class and a Type for its instances. Scala Types also include traits, enums, opaque types, function types, union types, intersection types, and other forms, so Type and Class are not synonyms in Scala either. The simplemodeling-lib Type Modeling Rule uses Scala abstract class for a Domain Model’s conceptual trunk, constructor semantics, state, and inheritance invariants, and uses trait for supplementary composable capabilities. These are Scala realization policies and do not change the canonical definition of Class. Japanese articles and videos introduce the term as クラス（Class）. They say that a Class is itself a Type and describes Object structure and behavior, rather than saying that a Class describes a separate Type. Part 5 focuses on its role relative to Type, Interface, and Trait without teaching the complete Classifier hierarchy. Class is not synonymous with Type. It is one kind of object-side Type.Class is not synonymous with Trait. A Class represents a conceptual trunk, while a Trait represents a composable partial structure.Class is not synonymous with Interface or Class Diagram.An Object classified by a Class does not necessarily have persistent Entity identity.TypeClassifierInterfaceTraitObjectClass DiagramOMG Unified Modeling Language 2.5.1Scala 3 Referencedocs/spec/glossary-entry-format.md/Users/asami/src/dev2025/simplemodeling-lib/ai/directive/core/type-modeling.md |
||
2026-08-16 |
Glossary |
Update |
TermClassifierAliases-Term ID: src/main/doxsite/glossary/object-foundation/classifier.doxEnglish label: ClassifierJapanese label: 分類子Category: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, aligned with UML 2.5.1A Classifier is a Type that classifies Instances according to common Features and specifies structural or behavioral characteristics that those Instances may have. SimpleModeling uses it as a common general concept for Class, Interface, Trait, Data Type, and related elements. In UML 2.5.1, Classifier specializes Type and generalizes Class, Interface, DataType, and related concepts. A SimpleModeling Trait is not a standard UML Classifier kind; it is a SimpleModeling Model Element that extends the classification model. In a UML Profile mapping, it is represented by default as an abstract Class carrying a «trait» stereotype. Classifier is used to explain object-side classification structures precisely. Not every Object-Functional Type, such as a function type, union type, intersection type, or type lambda, is treated as a Classifier. CML uses concrete Object kinds such as Entity, Value, Trait, Powertype, and StateMachine. Classifier is a metamodel-level supporting term for explaining their common classification role and need not appear explicitly in ordinary Domain Model descriptions. Scala has no single language construct that maps one-to-one to UML Classifier. Classes, traits, enums, and related declarations introduce Types that classify instances or values, but not every Scala Type is a UML Classifier. The canonical Japanese display is 分類子（Classifier）. Introductory Object Modeling material explains Class, Interface, Trait, and Data Type directly and introduces Classifier only when the UML relationship to Type must be stated precisely. The hierarchy statement "a Classifier classifies Instances and a Class classifies Objects" does not replace the main explanation of Class and Type. Classifier is not synonymous with Class. Class is one kind of Classifier.Classifier is not synonymous with Type as a whole.A SimpleModeling Trait is not treated as a standard UML Classifier kind.A Classifier is not a runtime Object Instance.TypeClassInterfaceTraitData TypeInstanceFeatureOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-16 |
Glossary |
Update |
TermTypeAliases-Term ID: src/main/doxsite/glossary/object-foundation/type.doxEnglish label: TypeJapanese label: 型Category: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKA Type is a semantic contract in the SimpleModeling Object-Functional Paradigm that statically specifies the contexts in which values may be used and the operations, transformations, results, effects, and compositions that apply to those values. In UML 2.5.1, Type is an abstract ModelElement that constrains the values represented by a TypedElement. Classifier specializes Type, and Class, Interface, and DataType specialize Classifier. A UML Class or Interface is therefore itself a Type; it does not stand outside and realize a separate Type. SimpleModeling preserves this relationship while centering its canonical term Type on an Object-Functional semantic contract. In programming languages, Type includes not only types introduced by class declarations but also function types, union types, intersection types, type aliases, applied types, and other forms. Type and Class are therefore not synonyms. In an Object Model, Classes, Interfaces, Traits, and Data Types describe object structure, contracts, reusable partial structures, and value meaning instead of foregrounding abstract Type. On the functional side, Types describe values, functions, results, effects, and composability. A SimpleModeling Type connects these sides and provides a shared contract for realizing an Object Model in a type system such as Scala’s. CML (Cozy Modeling Language) formalizes Object kinds such as Entity, Value, Trait, Powertype, and StateMachine together with Attributes, Associations, Operations, and Constraints. These descriptions participate in Types during realization, but a CML Model Element and a programming-language Type are neither identical nor necessarily mapped one-to-one. In Scala, declarations such as class, trait, enum, and opaque type introduce Types, while the language also expresses function, union, intersection, and applied types and type lambdas. Higher-kinded type constructors and kinds matter at the Scala boundary but are advanced topics outside an Object Model introduction. simplemodeling-lib does not define one universal Type base for an entire Model. It distributes responsibilities according to meaning across Scala abstract classes, classes, traits, case classes, enums, opaque types, function types, Schema Data Types, Runtime Data Types, and other constructs. This is a realization policy for Types, not the canonical definition of Type itself. Japanese articles and videos introduce the term as 型（Type）. Object Model explanations use the concrete terms Class, Interface, Trait, and Data Type, while Type is used for the Object-Functional contract or the Scala realization boundary. Classifier is introduced only when the UML relationship requires precise explanation. Type is not synonymous with Class, Interface, or Trait.A CML Model Element and a Scala Type are neither identical nor necessarily mapped one-to-one.Type Constructor and Kind are related to Type but are not the same concept.ClassifierClassInterfaceTraitData TypeObject-Functional ParadigmCMLOMG Unified Modeling Language 2.5.1Scala 3 Referencedocs/spec/glossary-entry-format.md/Users/asami/src/dev2025/simplemodeling-lib/ai/directive/core/type-modeling.md |
||
2026-08-16 |
Glossary |
Update |
TermCompositionAliases-Term ID: src/main/doxsite/glossary/object-foundation/composition.doxEnglish label: CompositionJapanese label: 合成関係Japanese short label: 合成Scope qualifier: Object Foundation / whole-part relationshipBare-label linking: explicit-onlyCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK, aligned with UML 2.5.1Composition is a strong whole-part Relationship in which the Whole has Structural Ownership of the Part. A Part belongs to at most one composite Whole at a time, and its existence, Lifecycle, and Invariants are managed consistently with the boundary of the Whole. In UML 2.5.1, Composition is a binary Association whose Association End has the Aggregation Kind composite. The composite Object is responsible for the existence and storage of its Parts, and the upper Multiplicity at the composite end is one. SimpleModeling adopts this meaning and uses it to determine domain Lifecycle and Invariant boundaries. Ordinary composition, function composition, and visual or audio compositing are not the whole-part Relationship defined by this term. Composition is also distinct from Aggregation, which may represent a shared Part. Composition establishes a Lifecycle and Invariant boundary on the Object side. It is distinct from function composition on the Functional side, and the shared short label does not make the concepts identical. CML (Cozy Modeling Language) can explicitly describe an Association as Composition. Composition is not inferred merely from shared persistence, field containment, or parent-child presentation. Scala has no language construct that maps one-to-one to Composition. Fields, case classes, collections, and nested Types may help realize it, but do not by themselves express Structural Ownership. Collections, Groups, Schemas, and related simplemodeling-lib constructs may realize a composite structure, but using those Types alone does not establish domain Composition. Japanese articles and videos use 合成関係（Composition） at first occurrence and shorten it to 合成 only while the same whole-part context remains established. Ordinary Japanese usage and functional-programming uses of 合成 are not automatically linked to this term. Composition is not synonymous with Association in general.Shared persistence, parent-child presentation, or a field reference alone does not establish Composition.Multiplicity may constrain a Composition, but does not itself imply Structural Ownership.Composition is distinct from function composition and Aggregation.Structural OwnershipAssociationAggregationRelationshipLifecycleInvariantMultiplicityOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-15 |
Glossary |
New |
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. |
||
2026-08-15 |
Glossary |
New |
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. |
||
2026-08-15 |
Glossary |
New |
A Schema Data Type is a symbolic, declarative description of a Domain Type used in the Value Domain of a Parameter, Field, or similar element. It identifies value meaning and acts as a key for selecting normalization or conversion behavior. |
||
2026-08-15 |
Glossary |
New |
A Runtime Data Type is a Type that realizes the meaning of a Model value as a runtime Scala value. It implements the value, equality, basic validity conditions, and required Operations. |
||
2026-08-15 |
Glossary |
New |
In SimpleModeling, a Universal Identifier is an opaque, value-based operational identifier with a canonical string format that can be referenced across system boundaries. |
||
2026-08-15 |
Glossary |
New |
SimpleModeling Library is a core semantic model library that defines long-lived protocol, datatype, operation, and related meanings shared by generated and handwritten code in model-driven systems. |
||
2026-08-15 |
Glossary |
New |
A Value Domain declaratively describes the semantic domain of values that a Parameter, Attribute, Field, or similar element may take as a combination of Data Type, Multiplicity, and Constraints. |
||
2026-08-15 |
Glossary |
New |
In SimpleModeling, a Canonical Identifier is a stable, opaque Identifier used to correlate Observations, Conclusions, Consequences, Executions, and related subjects across system boundaries. |
||
2026-08-15 |
Glossary |
Update |
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. |
||
2026-08-15 |
Glossary |
Update |
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. |
||
2026-08-15 |
Glossary |
Update |
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. |
||
2026-08-15 |
Glossary |
Update |
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. |
||
2026-08-15 |
Glossary |
Update |
The Object-Functional Paradigm is a design paradigm combining structures based on Object Identity, Responsibility, State, and Collaboration with rigorous computational expression through types, values, functions, and composition. |
||
2026-08-15 |
Glossary |
Update |
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. |
||
2026-08-15 |
Glossary |
Update |
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. |
||
2026-08-15 |
Glossary |
Update |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
A Postcondition is a Constraint that the provider guarantees after an Operation that began with its Preconditions satisfied completes according to its contract. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
A Lifecycle is the range of States and Transitions through which a subject passes, while retaining its Identity, from creation to termination. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
Design by Contract is a design method that specifies an Operation provided by a software element in terms of obligations and guarantees between its caller and provider. The contract is expressed through Preconditions, Postconditions, and Invariants. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
An Instance is a concrete occurrence classified by a Classifier. In UML, an InstanceSpecification is a Model Element representing an Instance in a modeled system, distinguishing the Instance itself from its representation in a Model. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
A Precondition is a Constraint that the caller must satisfy before invoking an Operation under its contract. |
||
2026-08-14 |
Glossary |
New |
Textus is the runtime foundation for operating software realized through SimpleModeling. It provides execution, operational, and integration mechanisms shared by applications. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
A Platform is a shared set of technical foundations and services used to build, deploy, execute, and operate software. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
New |
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. |
||
2026-08-14 |
Glossary |
Update |
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. |
||
2026-08-10 |
Article |
New |
Part 4 takes the Model as its subject and composes Capabilities and Aspects through the Domain Model and Use Case Model axes. The Object Model makes the formal structure concrete, while purpose- and concern-selected Views support understanding, evaluating, and applying the complex Model. |
||
2026-08-03 |
Article |
New |
A Knowledge System collects, organizes, and classifies existing technologies and provides a map for understanding them. A Software Development Methodology selects the needed technologies from that knowledge, defines their roles and use, and guides practice. A SimpleModeling Model is composed of an Object Model for formal structure and execution examples, a Knowledge Model for generative-AI knowledge structures, and a Literate Model for human-readable context and intent. Domain Modeling organizes the three constituents with emphasis on problem-domain meaning, structure, rules, and boundaries. Application Modeling organizes them with emphasis on Use Case realization, Collaborations, Interactions, state transitions, Events, Services, and Operations. Domain Modeling is not entirely static, and Application Modeling does not own every dynamic element. Approved executable formal structures are connected to executable software through CML, Cozy, AI, and Textus as Model Realization. Quality attributes remain cross-cutting design concerns. |
||
2026-07-31 |
Glossary |
New |
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. |
||
2026-07-31 |
Glossary |
New |
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. |
||
2026-07-31 |
Glossary |
Update |
TermProcess StyleAliases-Revised Process Style from an internal element of a Development Method to a replaceable element combined with the method when constructing a Development Process. A Process Style defines the temporal application pattern of a Development Method. Iterative, incremental, waterfall, Agile, and hybrid styles characterize the order, repetition, rhythm, checkpoints, and timing of development activities and work products. SimpleModeling does not include a Process Style within the Development Method itself. Instead, it treats the Process Style as a replaceable element combined with the Development Method when constructing a Development Process. Separating the Methodology from the Process Style increases the reusability of the Methodology. A Process Style can be selected according to project and team context, allowing the same Development Method to be applied in different development settings. SMRP adopts a hybrid Process Style combining RUP and Agile. |
||
2026-07-31 |
Glossary |
Update |
TermDevelopment ProcessAliases-Clarified the Development Process as the mechanism for operating a Development Method in practice through a Process Style, and added its relationship to Agile. A Development Process is the flow of activities, roles, sequencing, iterations, checkpoints, and work products used to operate a Development Method in practical software development. It organizes planning, modeling, implementation, review, testing, release, and feedback according to the project context. SimpleModeling defines a Development Process as a combination of a Development Method and a Process Style. The Development Method defines the system of models and model transformations, while the Process Style defines how that method is applied over time. Agile is one Process Style for structuring a Development Process through iteration, incremental delivery, and short feedback cycles. A project uses the selected Process Style to specify who creates, reviews, and updates each model and work product, and when. Knowledge and work products produced by the process return to the BoK for reuse in subsequent iterations. |
||
2026-07-27 |
Article |
New |
SimpleModeling has built a path from models to executable software through CML, DSLs, Literate Models, Cozy, and Textus. Cozy transforms CML into executable software, while AI fills implementation gaps that Cozy cannot transform completely. Textus runs the resulting software. Meanwhile, people have performed most of the work of constructing a Domain Model from knowledge. With the BoK as a shared foundation for collaboration among domain experts, developers, and AI, the path from Knowledge to Executable Software can be treated as one methodology. |
||
2026-07-27 |
Article |
Update |
SimpleModeling has built a path from models to executable software through CML, DSLs, Literate Models, Cozy, and Textus. Cozy transforms CML into executable software, while AI fills implementation gaps that Cozy cannot transform completely. Textus runs the resulting software. Meanwhile, people have performed most of the work of constructing a Domain Model from knowledge. With the BoK as a shared foundation for collaboration among domain experts, developers, and AI, the path from Knowledge to Executable Software can be treated as one methodology. |
||
2026-07-20 |
Article |
New |
With the arrival of AI, the domain model has become a working abstraction with a realization path to implementation that can directly drive development forward. AI translates domain models into implementations and fills in the necessary implementation details. The primary subject handled by humans therefore shifts from describing implementation step by step to software models representing the target world, responsibilities, execution, and knowledge. Because model quality strongly influences software quality, modeling becomes the new choke point, requiring existing software engineering to be reconstructed as a modeling-centered methodology. |
||
2026-07-13 |
Article |
New |
01.a-invocation-source-lab shows how the same minimal.main.hello selector can be used while switching the Component source between a development directory and a component repository. |
||
2026-07-13 |
Article |
Update |
The 02-component family shows the basic development step from an in-development Textus component project to a packaged artifact. |
||
2026-07-13 |
Article |
Update |
This article uses the 01-minimal family to examine the smallest Textus Component / Service / Operation and how it is invoked on the CNCF engine. |
||
2026-07-13 |
Article |
Update |
Created this article for |
||
2026-07-13 |
Article |
Update |
01.d-component-script is a textus-tutorial 0.1.3 sample for learning the script-style operational form that connects a small management command to a Textus operation contract. |
||
2026-07-13 |
Article |
Update |
This article explains the Textus / Cozy Textus product names, the internal CNCF engine, and the roles of the cozy, cncf, and textus launchers before learning Textus component development with textus-tutorial 0.1.3. |
||
2026-07-06 |
Article |
New |
The 02-component family shows the basic development step from an in-development Textus component project to a packaged artifact. |
||
2026-07-06 |
Article |
Update |
Updated for the |
||
2026-07-06 |
Article |
Update |
Updated for |
||
2026-07-06 |
Article |
Update |
Updated for |
||
2026-06-29 |
Article |
New |
This article uses the 01-minimal family to examine the smallest Textus Component / Service / Operation and how it is invoked on the CNCF engine. |
||
2026-06-22 |
Article |
New |
01.d-component-script is a textus-tutorial 0.1.3 sample for learning the script-style operational form that connects a small management command to a Textus operation contract. |
||
2026-06-15 |
Article |
New |
This article explains the Textus / Cozy Textus product names, the internal CNCF engine, and the roles of the cozy, cncf, and textus launchers before learning Textus component development with textus-tutorial 0.1.3. |
||
2026-06-08 |
Article |
New |
CNCF Job Management manages Command execution state, results, and diagnostics. It handles synchronous execution, synchronous execution with Job tracking, asynchronous execution, and synchronous execution with asynchronous continuation through one model, and it organizes follow-up processing after Event publication as either synchronous or asynchronous subscriptions. |
||
2026-06-01 |
Article |
New |
How SIE links book knowledge with external RDF knowledge spaces. |
||
2026-05-24 |
Article |
New |
Semantic Integration Engine (SIE) does not treat a Book as mere bibliographic metadata. Instead, SIE assigns its own local RDF node identity and attaches open knowledge sources such as Open Library, DBpedia, and Wikidata to build explainable knowledge structures. |
||
2026-05-18 |
Article |
New |
In AI-driven development, one of the central questions is how to achieve non-functional requirements such as Security and Observability. Even observability alone requires many cross-cutting concerns such as distributed tracing, metrics, structured diagnostics, payload protection, and integration with external observability platforms. Delegating these concerns to individually generated implementations rapidly increases generation, review, and operational costs while also destabilizing quality assurance. For this reason, once sufficient structural information is described in the Literate Model, the CML&CNCF model compiler and execution framework establish Security and Observability as cross-cutting runtime behavior. |
||
2026-05-11 |
Article |
New |
SimpleModeling adopts an architecture-centric approach derived from the Unified Process. Architecture is treated not merely as a design artifact, but as the organizing structure that guides requirements, analysis, design, implementation, and operation. By applying architectural viewpoints from the earliest stages, models become more coherent, analyzable, and AI-friendly. |
||
2026-05-04 |
Article |
New |
CNCF authorization evaluates both operation entry points and resource access. Roles, permissions, relations, and ABAC are normalized into capabilities and guards, and evaluated through a unified decision model. |
||
2026-04-27 |
Article |
New |
The knowledge processing model in SimpleModeling is structured as a transformation pipeline: “meaning → structure → definition → behavior → execution → reality.” Context governs the entire pipeline, and reality emerges through the evaluation of effects. |
||
2026-04-20 |
Article |
New |
The SimpleModeling Development Process is composed by selecting and combining Practices such as Use Case Lite, Scrum Solo, Cloud Native CBD, BoK, Cozy Domain Modeling, Code Generation, and DevOps on top of the Essence Kernel. CNCF is positioned as the execution foundation. This article provides a draft definition using Method View, Process Flow View, Work Product View, Role/Agent View, Automation View, and Lifecycle View. |
||
2026-04-13 |
Article |
New |
SimpleModeling integrates literate modeling, DSL, and execution platform to enable AI-driven development processes. This article reconstructs a minimal development workflow based on Essence as a BoK → Cozy → CNCF → SKILL pipeline. |
||
2026-04-06 |
Article |
New |
This is a sample article to give you a quick sense of a literate model using an address model example. For an explanation of what a literate model is, see what-is-literate-model.dox. |
||
2026-03-30 |
Article |
New |
SimpleModeling integrates BoK, literate models, DSL, and execution platforms to extend Harness Engineering into a foundation that governs execution based on meaning. It reduces gaps between specification and implementation and enables consistent quality and reproducibility required in the AI era. |
||
2026-03-23 |
Article |
New |
The Philosophy of 1.5hop+: Meaning-Oriented Concept Neighborhoods |
1.5hop+ is a knowledge graph exploration approach that constructs concept neighborhoods based on semantic structure rather than fixed traversal distance. By leveraging CML/UML metamodel structures, it provides sufficient semantic context for generative AI, balancing accuracy and efficiency. |
|
2026-03-16 |
Article |
New |
In the previous article, we organized the development process for the AI era by positioning the Unified Process as the structural backbone of the process and Component-Based Development as the central structure of development. The Unified Process defines the software development process through three core principles: Iterative & Incremental development, Architecture-Centric design, and Use-Case Driven development. These principles remain valid even in the age of AI. However, in an environment where AI-based code generation has become commonplace, the meaning and role of each principle need to be understood somewhat differently from how they were interpreted in the past. In this article, we revisit the three fundamental principles of the Unified Process as a guide and re-examine the nature of the development process in the AI era. |
||
2026-03-09 |
Article |
New |
In the AI era of software development, the design of system structure becomes more important than the capability of code generation. This article organizes a basic framework for AI-assisted development, using the Unified Process (UP) as the backbone of the process and Component-Based Development (CBD) as the central architectural structure. |
||
2026-03-02 |
Article |
New |
While AI accelerates software development, it has also introduced a new challenge: structural instability. This article revisits the contemporary value of CBD by examining not only its original structural strengths, but also its role in the AI era—through structural constraints that improve generation accuracy, boundaries and specifications that suppress instability, and reusability enhanced by AI. CBD should not be regarded merely as a reuse technique, but rather be re-evaluated as a foundational technology that stabilizes development in an AI-first era. |
||
2026-02-23 |
Article |
New |
CBD Enabled by DSL and Execution Platform: Implementable Component Structure |
This article argues that through the combination of a DSL and an execution platform, CBD becomes an implementable structural reality. By rigorously defining analysis models as a DSL in Cozy and structurally guaranteeing those specifications at runtime through CNCF, components become not merely design concepts but concrete entities that can be registered, discovered, and connected. Furthermore, by integrating a cloud-native architecture centered on CQRS, the externalization of quality attributes, and asynchronous abstraction, CBD is redefined as an executable architectural unit suited for the AI era. |
|
2026-02-16 |
Article |
New |
This article integratively organizes the development process, CBD, DSL, code generation, and execution platform (CNCF)—previously discussed separately—into a single vertical stack. In SimpleModeling, knowledge organized in the BoK is reflected in the literate model, defined structurally as a DSL, and guaranteed by the CNCF execution platform, forming an end-to-end architecture. AI not only supports understanding, structuring, generation, and validation at each layer, but also functions as a mediating device that connects them across layers. When this vertical continuity is established, the natural language world and the implementation technology world are no longer divided, enabling an evolvable development stack that preserves structural integrity. |
||
2026-02-09 |
Article |
New |
This article uses the Unified Process (UP) as a guiding framework to reorganize software development processes and project management in the AI era. In particular, it clarifies how the role of AI changes across the phases of inception, elaboration, construction, and transition. |
||
2026-02-09 |
Glossary |
New |
The phase in which the system is implemented at scale through iterations, based on the architecture baseline established during the elaboration phase.In the AI era, this phase refers to the stage where AI becomes the primary implementation agent, generating large volumes of code and tests with consistent quality under given structures and constraints. |
||
2026-02-09 |
Glossary |
New |
The phase in which the developed software is transitioned into actual operation and delivered to users.In the AI era, it is positioned as a context-update phase that captures insights from usage and operation and feeds them into the next inception phase. |
||
2026-02-09 |
Glossary |
New |
The phase in which the system’s structural backbone is established by advancing analysis and design based on the requirements and directions defined in the inception phase.In the AI era, its most critical role is to refine context, boundaries, and assumptions, eliminating ambiguity and contradiction, and to establish the architecture baseline referenced by the AI. |
||
2026-02-09 |
Glossary |
New |
The phase in which the project’s goals, problem domain, and scope are defined, and the value and feasibility to be validated are clarified.In the AI era, its central role shifts from fixing detailed specifications to defining the outline of the context shared between humans and AI. |
||
2026-02-02 |
Article |
New |
This article examines how the premises of development processes are changing with the advent of generative AI, using the characteristics of the Unified Process as a comparative axis against agile development. In the AI era, not only programs but also natural-language artifacts such as models, specifications, and design documents become primary sources of truth. Under this premise, the Unified Process—designed as a model-centric framework—serves as a valuable reference for rethinking development processes that collaborate with AI. |
||
2026-01-26 |
Article |
New |
SimpleModeling is a development methodology based on component-oriented principles.To make component-oriented development viable, an execution system for components is required in addition to the definition of conceptual models.For this purpose, the Cloud Native Component Framework has been developed as a component framework for cloud applications that run on cloud platforms. In this article, we will explore the execution model of the Cloud Native Component Framework through a HelloWorld example. |
||
2026-01-19 |
Article |
New |
The shortest path to understanding CNCF is to actually run it first. By starting with command execution and moving on to server, client, and custom components, you can confirm that the internal execution model remains the same even when the execution form changes. |
||
2026-01-19 |
Glossary |
New |
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. |
||
2026-01-12 |
Article |
New |
In the AI era of software development, it is essential to cultivate specifications, design, and implementation together without isolating them, allowing continuous movement between these activities. This article organizes a practical SimpleModeling approach centered on executable specifications (Executable Specifications), including up-and-down movement of analysis models and pair analysis / pair design with AI. |
||
2026-01-12 |
Glossary |
New |
Verification is the activity of confirming that an implementation conforms to its specified design or requirements. |
||
2026-01-12 |
Glossary |
New |
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. |
||
2026-01-12 |
Glossary |
New |
Behavior Driven Development (BDD) is a development approach that focuses on specifying system behavior through scenarios written in a shared language. |
||
2026-01-12 |
Glossary |
New |
An executable specification is a specification expressed in a form that can be executed to determine correctness. |
||
2026-01-12 |
Glossary |
New |
Validation is the activity of confirming that a system or product fulfills its intended use and stakeholder requirements. |
||
2026-01-05 |
Article |
New |
This article summarizes the current state of my personal AI-driven development approach, in which ChatGPT and VS Code Codex are used selectively to rapidly iterate through specification, design, implementation, and verification. |