2026
| Date | Kind | Event | Category | Title | Summary |
|---|---|---|---|---|---|
2026-08-31 |
記事 |
新規 |
文芸モデリングは、ストーリーをナラティブとして構成することを重要な形式としながら、ビジョン、要求、判断記録、既存仕様に加え、ドメイン・モデルの概念、規則、関係を自然言語で説明する従来型ドキュメントも、意味、識別子、モデル要素との対応を持つ文芸モデルとして組織する活動です。SmartDoxをフルスペックの基本記述言語とし、Markdownも利用できます。textus-bokが文芸モデルを知識モデル化して生成AIへ接続し、生成AIがオブジェクト・モデルを主として生成、更新、管理します。人間はtextus-cbd-supportが提供する可視化、差分、根拠によって結果をレビューし、承認または指摘を生成AIへ返します。また、文芸モデルを事実の正本として、要求仕様、ユーザーガイド、設計説明などのドキュメントを目的別に構成できます。 |
||
2026-08-31 |
用語集 |
新規 |
用語ストーリー用語(英)Story別名-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 BoKストーリー(story)とは、主体、目的、状況、出来事、因果、結果から構成される「何が起きるか」という意味内容です。ナラティブとして表現される対象であり、特定の語り方、文書構成、説明順序そのものではありません。 「ストーリー」は、娯楽作品の筋、商品の説明、開発計画の比喩などにも使われます。SimpleModelingでは、文芸モデルがナラティブとして表現する意味内容を指す場合に限定します。複合語の「ユーザーストーリー」は、それ自体の要求技術用語として別に扱います。 日本語の記事と動画では、初出を「ストーリー(story)」とし、以後は「ストーリー」とします。通常語の「物語」は、文脈上必要な場合に使えますが、この用語へ自動的に対応付けません。 ストーリーはナラティブと同義ではありません。ストーリーは意味内容、ナラティブはそれを視点、目的、文脈から構成した文芸モデルです。同じストーリーから複数のナラティブを構成できます。「ストーリー」は「ユーザーストーリー」の略称ではありません。ナラティブ文芸モデルユースケースシナリオsrc/main/doxsite/development-process/literate-modeling.doxsrc/main/doxsite/glossary/literate-modeling/narrative.doxdocs/spec/glossary-entry-format.md |
||
2026-08-29 |
用語集 |
新規 |
用語ナラティブ用語(英)Narrative別名-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 BoKナラティブ(narrative)とは、ストーリーを特定の視点、目的、文脈に基づいて選択、配列、説明し、具体的な状況と変化の意味を理解可能な形に構成した文芸モデルです。要求、判断、振る舞いの意味を帰納的に理解し、人間と生成AIで共有できるようにします。 「ナラティブ」は、文学、ビジネス、医療などで広い意味に使われます。SimpleModelingでは、文芸モデルとして対象、目的、意味、識別子を持ち、設計、判断、検証のいずれかに対応する表現に限定します。通常語の「物語」は、この用語へ自動的に対応付けません。 ナラティブは、具体的な状況、出来事、結果から意味とパターンを捉える帰納的なモデルとして機能します。形式モデルは、一般化した構造と規則から個別の振る舞いを確認する演繹的なモデルとして機能します。SimpleModelingでは両者を対立させず、相補的に利用します。 ユースケース・シナリオは、アクターの目的を達成する一つのストーリーを利用者視点から構成したナラティブであり、文芸モデルの代表例です。ナラティブはユースケース・シナリオだけに限定されず、判断の経緯、障害事例、利用状況、変更履歴なども含み得ます。 日本語の記事と動画では、初出を「ナラティブ(narrative)」とし、以後は「ナラティブ」とします。ストーリーとの差を扱う場合は、ストーリーが「何が起きるか」という意味内容、ナラティブがそれを視点、目的、文脈から構成した文芸モデルであることを示します。 ナラティブはストーリーと同義ではありません。同じストーリーから複数のナラティブを構成できます。一つのナラティブだけで、許されるすべての振る舞いを網羅するとは限りません。ナラティブは形式モデルの代替ではありません。モデルの目的や対応を持たない一般的な文章は、この用語が表すモデルではありません。文芸モデリング文芸モデルストーリーユースケースシナリオ実行例モデル帰納演繹src/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 |
用語集 |
新規 |
用語文芸モデリング用語(英)Literate Modeling別名-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 BoK文芸モデリング（Literate Modeling）とは、対象、目的、状況、要求、判断、シナリオ、意図、前提、履歴などを、自然言語を中心に人間が理解できる順序と形式で記述し、意味、識別子、他のモデル要素との対応を持つ文芸モデルとして組織する活動および方法です。 Donald E. Knuthの文芸プログラミング（Literate Programming）が、プログラムと説明を一つの文書で扱い、人間が理解しやすい順序で記述する考え方を示したことを受け、その考え方をモデリングへ拡張します。文芸モデリングは活動・方法を、文芸モデルはその活動で記述・組織する対象と成果物を表します。 SimpleModelingでは、文芸モデリングによって自然言語情報をオブジェクト・モデルおよび知識モデルへ対応付け、人間の開発者、非開発者、生成AIで共有します。ビジョンやユースケースのような目的別文書だけでなく、ドメイン・モデルの概念、規則、関係を自然言語で説明する従来型ドキュメントも重要な対象です。ユースケースシナリオを生成AIの直接入力として利用し、AIが提案した対応を人間がレビュー・承認して実行可能なモデルへ接続することも、文芸モデリングの重要な利用です。 CML（Cozy Modeling Language）文書は、形式要素として実行可能なオブジェクト・モデルを表しながら、同じ文書の自然言語による説明、意図、前提によって文芸モデルも表すため、文芸モデリングの具体的な実践です。ただし、文芸モデル全体をCMLで表現することは前提にしません。 自然言語の文書を蓄積するだけでは、文芸モデリングになりません。文芸モデリングは、形式モデルへ説明文を後付けする作業ではありません。文芸モデリングと文芸モデルは同義ではありません。前者は活動・方法、後者は対象・成果物です。文芸モデル文芸プログラミングストーリーナラティブユースケースシナリオCozy Modeling Languagesrc/main/doxsite/development-process/literate-modeling.doxsrc/main/doxsite/glossary/literate-modeling/literate-model.doxdocs/spec/glossary-entry-format.md |
||
2026-08-24 |
記事 |
新規 |
知識モデルは、CMLによるモデル定義、ドメイン・モデルのレビュー、ユースケース・モデルの作成とレビュー、ドメイン理解のための問い合わせを支えるSimpleModelingモデルの構成要素です。用語集に定義された用語が、オブジェクト・モデル、知識モデル、文芸モデルに現れる同じ概念を対応付けます。生成AIは候補と説明を提示し、人間は意味と根拠を承認します。 |
||
2026-08-21 |
用語集 |
新規 |
埋め込み（Embedding）とは、文章、用語、モデル要素などを、その意味上の近さを計算できる数値ベクトルへ変換した表現です。類似検索や候補抽出に利用します。 |
||
2026-08-21 |
用語集 |
新規 |
モデル・コンテキスト・プロトコル（Model Context Protocol、MCP）とは、生成AIを利用するアプリケーションと外部のデータ源やツールを接続し、コンテキストと機能を標準化された形で提供するためのオープンプロトコルです。 |
||
2026-08-21 |
用語集 |
新規 |
オントロジー（Ontology）とは、対象領域の概念、分類、関係、制約を明示し、知識を一貫して解釈するための意味構造です。 |
||
2026-08-21 |
用語集 |
更新 |
用語知識モデリング用語(英)Knowledge Modeling別名-知識モデリングの対象へ根拠と出典を明記し、明示的な意味構造と検索・アクセス技術の役割を区別しました。 Knowledge Modelingを、人間とAIが共有する知識を構造化し、Object Modelおよび文芸モデルとともにDomain Modelを構成する活動として更新しました。 Knowledge Modelingとは、SimpleModelingモデルに含まれる概念、意味関係、分類、規則、根拠、出典などを、主として生成AIが参照、探索、関連付け、解釈できる知識モデルとして構造化するモデリング活動です。 RDF、オントロジー、知識グラフは明示的な意味構造を担い、埋め込みとRAGは関連情報の検索を、MCPは選択された知識資源へのアクセスを支えます。BoKは文書、用語、モデル、意味メタデータを組み合わせた知識資源です。生成AIはこれらを介してオブジェクト・モデルおよび文芸モデルの内容を探索し、人間へ説明します。人間は主として生成AIとの対話を介して知識モデルを利用します。 用語集はKnowledge Modelの概念を、Object Modelおよび文芸モデルに現れる同じ概念へ接続します。Knowledge ModelingはBusiness Modelingを単純に置き換えるものではなく、業務知識を含む複数の知識源を、ドメインエキスパート、開発者、AIが共通に参照し、モデルの不足や矛盾を発見して反復的に更新するための基盤です。 |
||
2026-08-21 |
用語集 |
更新 |
知識モデル（Knowledge Model）とは、SimpleModelingモデルに含まれる概念、意味関係、分類、規則、根拠、出典などを、主として生成AIが参照、探索、関連付け、解釈できる形で構造化したモデルです。 |
||
2026-08-17 |
記事 |
新規 |
SimpleModelingモデルは、オブジェクト・モデル、知識モデル、文芸モデルから構成され、この三つから目的別のドメイン・モデル、ユースケース・モデル、アプリケーション・モデルを構成します。そのうちオブジェクト・モデルは、一般的な構造と振る舞いを定義する実行可能モデルと、相互作用などの具体的な実行を示す実行例モデルを含みます。実行例は帰納的な制約として設計と検証に利用し、現行CMLは実行可能モデルだけを対象にします。プラットフォーム向けの機構はCML、Cozy、Textusが吸収するため、オブジェクトモデリングをドメイン・モデルの記述へ集中できます。 |
||
2026-08-17 |
用語集 |
新規 |
用語ユースケースシナリオ用語(英)Use Case Scenario別名-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 practiceユースケース・シナリオ(Use Case Scenario)とは、アクターの目的を達成する一つのストーリーを、アクターと対象システムの間で進む出来事、行為、分岐、成功または失敗の結果として利用者視点から構成したナラティブであり、文芸モデルです。 ユースケースシナリオは自然言語を中心に記述し、開発者、非開発者、生成AIの間で共有します。AIはシナリオから実行例モデルおよび実行可能モデルの候補を提案でき、人間が意味と対応関係をレビューします。 ユースケースシナリオは、オブジェクト間の相互作用を形式的に記述した実行例モデルそのものではありません。シナリオの一経路は、ユースケースが許容するすべての振る舞いを単独で網羅しません。ユースケース文芸モデルストーリーナラティブ実行例モデルモデル上の相互作用ユースケース実現モデルdocs/journal/2026/08/2026-08-17-simplemodeling-model-components-and-object-model-scope.mddocs/spec/glossary-entry-format.md |
||
2026-08-17 |
用語集 |
新規 |
用語モデル上の相互作用用語(英)Interaction別名-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.1モデル上の相互作用（Interaction）とは、特定の目的を達成するために、参加するモデル要素の間で行われるメッセージ、操作、イベント、およびそれらの順序を記述する振る舞いです。特定のシナリオにおける実行の一例を表せます。 UML 2.5.1では、InteractionはLifeline間の通信をMessageやOccurrenceとして記述するBehaviorです。Sequence DiagramなどはInteractionを表す表記です。 SimpleModelingでは、相互作用を実行例モデルの主要な表現として扱います。ユースケースシナリオを、参加するオブジェクト、責務、操作、イベント、状態遷移、成功または失敗の結果へ具体化します。承認された相互作用は、実行可能モデルの設計と適合性を検証する制約条件として利用できます。 現行CML（Cozy Modeling Language）は、実行例としての相互作用を直接のスコープに含みません。相互作用からレビューされたオブジェクト、サービス、操作、イベント、状態機械、制約が、CMLの実行可能モデルへ投影されます。 相互作用は、参加者の役割構造を表す協調と同義ではありません。相互作用は、すべての可能な実行を網羅する実行可能モデルではありません。振る舞い協調実行例モデルユースケースシナリオ状態機械OMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
用語集 |
新規 |
用語実行可能モデル用語(英)Executable Model別名-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 BoK実行可能モデル（Executable Model）とは、型、オブジェクト、関係、責務、サービス、操作、イベント、状態機械、振る舞い、制約などの一般的な構造と規則を定義し、プログラム生成と実行へ接続できるオブジェクト・モデルです。定義した規則から、許容される実行を導けます。 実行可能モデルは、人間の開発者、プログラミング言語上の表現、実行基盤、生成AIの間で共有されます。現行CML（Cozy Modeling Language）が直接対象にするのは、オブジェクト・モデルのうち実行可能モデルだけです。Cozyがプログラムを生成し、Textusが実行基盤を提供します。 実行可能モデルは、具体的な実行例だけを記述する実行例モデルとは異なります。実行可能であることは、モデル文書自体が単独でプロセスとして起動することを意味しません。生成または解釈による実現経路を含みます。オブジェクト・モデル実行例モデルCozy Modeling Languagedocs/journal/2026/08/2026-08-17-simplemodeling-model-components-and-object-model-scope.mddocs/spec/glossary-entry-format.md |
||
2026-08-17 |
用語集 |
新規 |
UPにおけるUse Case Realizationは、ユースケースの振る舞いを、設計モデル内で協調するモデル要素によってどのように実現するかを記述します。ユースケース実現モデルは、ユースケースのシナリオと、それを実現する参加者、責務、相互作用、操作、結果の対応を表すモデルです。 |
||
2026-08-17 |
用語集 |
新規 |
ユースケース・モデリング（Use Case Modeling）とは、Actor、Goal、Use Case、Scenario、Outcomeを用いて、システムに対する利用者や外部主体の意図をユースケース・モデルとして構成する活動です。 |
||
2026-08-17 |
用語集 |
新規 |
アプリケーション・モデリング（Application Modeling）とは、ユースケースをアプリケーションが実現する振る舞いとして具体化し、アプリケーション・モデルを構成する活動です。ユースケースシナリオから、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作への対応を明らかにします。 |
||
2026-08-17 |
用語集 |
新規 |
用語集約関係用語(英)Aggregation別名-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 modeling集約関係（Aggregation）とは、全体と部分を表す関連関係のうち、部分の排他的な構造上の所有やライフサイクル従属を伴わず、部分を複数の全体から共有し得る全体部分関係です。SimpleModelingでは、何を全体および部分とみなすか、共有を許すか、追加のライフサイクル制約があるかを明示した場合にだけ使用します。 UML 2.5.1では、集約関係はAssociation EndのAggregation Kindをsharedとする全体部分関係です。UMLはshared aggregationに一般化された強い意味を定めていないため、SimpleModelingでは、集約という記号だけに意味を委ねず、全体部分の役割、共有、多重度、ライフサイクル制約をモデルに記述します。 一般語の「集約」は、情報を集めること、集計、サービス集約などにも使われます。この用語が表す集約関係は、モデル上の全体部分関係です。データを一画面へ集めることや、複数APIの結果をまとめることだけでは集約関係になりません。 集約関係はオブジェクト側の共有可能な全体部分構造を表します。Functional側のコレクション集約やfoldとは別の概念です。 CML（Cozy Modeling Language）で集約関係を記述する場合、全体端と部分端、役割、多重度、共有可能性、および必要な制約を明示します。意味が通常の関連関係と変わらない場合は集約関係を使いません。 Scalaのコレクション、フィールド、参照は集約関係を実現できますが、それらは通常の関連関係や合成関係にも使われます。言語構造だけから集約関係を推論しません。 simplemodeling-libのCollection、Group、Schemaなどは集約された構造の実現に利用できますが、利用したライブラリ型だけでは共有可能な全体部分という意味は成立しません。 日本語の記事と動画では、初出を「集約関係（Aggregation）」とし、同じモデル関係を扱う文脈が続く場合だけ「集約」と短縮します。一般語の「集約」は用語として自動リンクしません。 集約関係は通常の関連関係と同義ではなく、明示された全体部分の意味を持ちます。集約関係は合成関係と異なり、一つの全体による排他的な構造上の所有を意味しません。コレクション、集計、同時表示、API集約だけでは、集約関係になりません。モデル上の関連合成関係モデル関係構造上の所有多重度ライフサイクルOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
用語集 |
新規 |
アプリケーション・モデル（Application Model）とは、ユースケースをアプリケーションがどのように実現するかを、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作、結果によって表す目的別のモデルです。 |
||
2026-08-17 |
用語集 |
新規 |
用語実行例モデル用語(英)Execution Example Model別名-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 BoK実行例モデル（Execution Example Model）とは、相互作用や実行トレースなどによって、特定のシナリオにおける参加者、操作、イベント、状態遷移、結果を記述するオブジェクト・モデルです。具体例から期待する振る舞いを示す帰納的なモデルであり、実行可能モデルが満たすべき制約条件として利用できます。 承認された正常例は、実行可能モデルがその実行を許容し、期待結果へ到達できることを要求します。禁止例は、その実行を受理しないことを要求できます。実行例モデルは、操作とイベントの順序、事前条件、事後条件、結果、状態遷移の適合性を設計、レビュー、検証するために使います。 現時点のCML（Cozy Modeling Language）は実行例モデルをスコープに含みません。実行例は、ユースケース実現モデルおよびsrc/main/internal-model/に保存するレビュー対象と関係し、CMLへ投影する実行可能な要素を制約します。 一つの実行例は、実行可能な振る舞いを網羅的に定義しません。実行例モデルは、自然言語のユースケースシナリオそのものではありません。シナリオを形式的な参加者と実行へ具体化します。現行CMLの実行可能モデルと同義ではありません。オブジェクト・モデル実行可能モデルモデル上の相互作用ユースケースシナリオユースケース実現モデルdocs/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 |
用語集 |
新規 |
ユースケース・モデル（Use Case Model）とは、利用者や外部主体がシステムを利用する目的と、その目的を達成するシナリオおよび期待する結果を、Actor、Goal、Use Case、Scenario、Outcomeによって表す目的別のモデルです。 |
||
2026-08-17 |
記事 |
更新 |
第4回はModelを主題とし、Domain ModelとUse Case Modelを二つの軸にCapabilityとAspectを構成します。Object Modelを使って形式構造を具体的に説明し、複雑なModelはPurposeとConcernに応じたViewから理解・検証・利用します。 |
||
2026-08-17 |
記事 |
更新 |
Knowledge Systemは既存技術を収集、整理、分類し、理解のための地図を提供します。Software Development Methodologyは、その知識から必要な技術を選び、役割と利用方法を定め、開発実践を導きます。SimpleModelingモデルは、形式構造と実行例を担うObject Model、生成AI向けの知識構造を担うKnowledge Model、人間が理解できる文脈や意図を担うLiterate Modelから構成されます。Domain Modelingは問題領域の意味、構造、規則、境界に重点を置き、Application ModelingはUse Caseの実現、協調、相互作用、状態遷移、Event、Service、Operationに重点を置いて、三つの構成要素を目的別に組織します。Domain Modelingを完全に静的、Application Modelingをすべての動的要素の所有者とはしません。承認済みの実行可能な形式構造は、Model RealizationとしてCML、Cozy、AI、Textusを通じて実行可能ソフトウェアへ接続します。品質属性はモデル全体を横断する設計課題として扱います。 |
||
2026-08-17 |
記事 |
更新 |
SimpleModelingでは、Object、Knowledge、Literateの三つの構成要素からDomain、Use Case、Applicationの各適用モデルを構成します。ユースケースの意図をアプリケーション・モデルへ具体化するApplication Modelingと、承認済みの実行可能モデルをCML(Cozy Modeling Language)、Cozy、AI、Textusによって設計・実装・実行へ接続するModel Realizationを分けて扱います。 |
||
2026-08-17 |
用語集 |
更新 |
UMLにおけるCollaborationは、専門化された機能を担う参加要素のRoleが共同して、目的とする機能を達成する構造を記述するClassifierです。 |
||
2026-08-17 |
用語集 |
更新 |
用語オブジェクト・モデル用語(英)Object Model別名-Object ModelをDomain Modelから導出するソフトウェア構成図ではなく、Domain Modelを含む各種モデルの構造を記述するための汎用的な基盤として明確化しました。 オブジェクト・モデル（Object Model）とは、対象をオブジェクト、型、関係、責務、相互作用、サービス、操作、イベント、状態機械、振る舞い、制約などによって形式的に表すモデルです。一般的な構造と規則を定義する実行可能なモデルと、相互作用などの具体的な実行例を記述するモデルを含みます。 実行可能なモデルは、許容される構造と振る舞いを定義し、プログラム生成と実行へ接続されます。人間の開発者、プログラミング言語上の表現、実行基盤、生成AIの間で共有されます。現行CML（Cozy Modeling Language）が直接対象にするのは、この実行可能な部分だけです。 実行例モデルは、相互作用や実行トレースによって具体的な実行を記述します。具体例から期待する振る舞いを示す帰納的なモデルであり、実行可能なモデルが満たすべき制約条件として、設計、レビュー、検証に利用できます。現時点ではCMLのスコープ外です。 オブジェクト・モデルだけでSimpleModelingモデル全体を表すわけではありません。知識モデルおよび文芸モデルと相互に対応し、用語集が三つのモデルに現れる概念の意味と同一性を接続します。 モデル実行可能モデル実行例モデルモデル上の相互作用知識モデル文芸モデルドメイン・モデルアプリケーション・モデルアプリケーション・モデリングCozy Modeling Language |
||
2026-08-17 |
用語集 |
更新 |
CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。 |
||
2026-08-17 |
用語集 |
更新 |
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。 |
||
2026-08-17 |
用語集 |
更新 |
用語開発メソッド用語(英)Development Method別名-SimpleModelingモデルの三つの構成要素、Domain、Use Case、Applicationの各Modeling、およびModel Realizationの分離を反映しました。 開発メソッドをモデルとモデル変換の体系として明確化し、DDDなどの個別技術を構成要素として位置付けました。また、Domain ModelがObject Model、Knowledge Model、文芸モデルにまたがり、用語集によって接続される構成を反映しました。 開発メソッドとは、ソフトウェアの構造と意味を定義するモデル、モデル間の関係、モデル変換、適用する技術と判断規則から構成される概念的な枠組みです。ソフトウェア開発で何をモデル化し、モデルをどのように構成し、次の成果物へ変換するかを定めます。 SimpleModelingの開発メソッドは、Object、Knowledge、Literateの三つのModelingによってモデル構成要素を整備し、Domain、Use Case、Applicationの各Modelingによって三つを目的別に組織します。Use Case ModelingはActor、Goal、Scenario、Outcomeを整理します。Domain Modelingは問題領域の意味、構造、規則、境界に重点を置き、Application ModelingはUse Case ScenarioからUse Case Realization Model、Collaboration、Interactionを介してStateMachine、Event、Service、Operationへ進む動的側面に重点を置きます。承認済みの実行可能モデルは、Model RealizationとしてCML、Cozy、AI、Textusへ接続します。 GoF、PEAA、DDD、CQRS、Knowledge Graphなどは、この開発メソッドを構成するために役割ごとに選択する技術です。個々の技術を開発メソッド全体とは扱いません。開発メソッドを開発実務でどのような順序と反復によって運用するかは、Process StyleとDevelopment Processで定めます。この分離により、同じDevelopment Methodを異なるProcess Styleやプロジェクトで再利用できます。 |
||
2026-08-17 |
用語集 |
更新 |
Software Development Methodologyとは、ソフトウェア開発で使用するモデル、モデル変換、技術、設計原則、判断規則を一つの体系として定める方法論です。何をモデル化し、モデルをどのように構成し、実行可能ソフトウェアへ接続するかを定義します。 一般的な用法では、Software Development MethodologyがDevelopment Processを含む場合もあります。SimpleModelingでは、モデルとモデル変換を定めるMethodologyと、それを開発実務で運用するDevelopment Processを分離して扱います。 |
||
2026-08-17 |
用語集 |
更新 |
用語ドメイン・モデリング用語(英)Domain Modeling別名-Domain Modelingの成果であるDomain Modelが、Object Model、Knowledge Model、文芸モデルにまたがり、用語集によって接続されることを明確化しました。 Domain Modelingとは、問題領域の用語、概念、規則、境界を、開発目的に応じたDomain Modelとして構成する活動です。対象となるRealityから何を選び、どのViewとして表すかを明確にします。 SimpleModelingでは、Domain Modelingを、オブジェクト・モデル、知識モデル、文芸モデルから、問題領域の意味、構造、規則、境界に必要なモデル要素を組織する活動として位置付けます。静的側面に重点を置きますが、振る舞いや状態を持たないという意味ではありません。ユースケースの動的な実現を中心に組織するApplication Modelingと相補的に扱います。 用語集は、三つのモデルに現れる用語の意味と同一性を管理し、相互に接続します。用語集、Use Case、Context、Bounded Context、Ubiquitous Language、DDDを用いて、ドメインエキスパート、開発者、AIがDomain Modelの妥当性を反復的に確認します。 ドメイン・モデルユースケース・モデリングアプリケーション・モデリングアプリケーション・モデル |
||
2026-08-17 |
用語集 |
更新 |
アスペクト(Aspect)とは、複数のモデル要素や振る舞いを横断して確認する条件、性質、関心事です。品質属性を中心とし、必要に応じて品質属性だけでは表し切れない横断的な条件も含みます。 |
||
2026-08-17 |
用語集 |
更新 |
Domain-Driven Designとは、複雑な問題領域をDomain Modelによって捉え、Ubiquitous Language、Bounded Context、Aggregateなどを用いて、業務上の意味とソフトウェア設計を接続するための原則、パターン、プラクティスの集合です。 |
||
2026-08-17 |
用語集 |
更新 |
用語オブジェクトモデリング用語(英)Object Modeling別名-SimpleModelingにおける現在のオブジェクトモデリングの対象をドメイン・モデルに限定し、それ以外のモデルを対象とする形式記述を現時点のスコープ外としました。 オブジェクトモデリング（Object Modeling）をドメインモデリング（Domain Modeling）と並ぶ独立領域ではなく、ドメイン・モデル（Domain Model）の形式的な部分を含む各種モデルに構造を与える共通基盤として位置付け直しました。 オブジェクトモデリングとは、対象をオブジェクト（Object）、型、関係、責務、協調、制約、状態、状態機械によって構造化する活動です。モデルの静的構造と動的構造、要素間の関係、成立条件を形式的に記述できるようにします。 SimpleModelingが現在、オブジェクト・モデルによる形式記述の対象としているのはドメイン・モデルです。形式化できる概念、関係、規則、制約を、オブジェクト・モデルの構造を用いて記述します。それ以外のモデルを対象とする形式記述は、現時点ではスコープ外です。 オブジェクトモデリングには、対象モデルの形式構造を記述する役割と、そのモデルをプラットフォーム上で動かす仕組みを組み立てる役割があります。SimpleModelingでは、CMLが形式構造を記述し、Cozyがプログラムを自動生成し、Textusが実行基盤を提供することで後者を吸収します。そのため、ドメイン・モデルを扱う場合は、概念、関係、責務、制約、状態、振る舞いという形式構造の記述へ集中できます。 GoF、PEAA、エンティティ（Entity）、バリュー・オブジェクト（Value Object）などは、オブジェクトの構造、責務、協調を設計する技術として利用します。オブジェクト・モデルには、一般的な規則を定義する実行可能モデルと、相互作用などの具体的な実行を示す実行例モデルがあります。現行CMLは実行可能モデルだけを対象とします。知識モデルと文芸モデルは、同じSimpleModelingモデルを構成する別のモデルであり、用語集が三つのモデルの概念を接続します。 |
||
2026-08-17 |
用語集 |
更新 |
用語ドメイン・モデル用語(英)Domain Model別名-SimpleModelingモデルの三つの構成要素から、問題領域の意味、構造、規則、境界に必要な要素を目的別に組織する適用モデルとして明確化しました。 Domain ModelをObject Modelだけに含まれるモデルから、Object Model、Knowledge Model、文芸モデルにまたがるモデルへ拡張し、用語集による接続を明確化しました。 Domain Modelとは、問題領域の用語、概念、規則、関係、境界を、特定の開発目的に応じたViewとして表すモデルです。Realityそのものではなく、目的と関心に基づいて選択し構成した表現です。 SimpleModelingのドメイン・モデルは、オブジェクト・モデル、知識モデル、文芸モデルから、問題領域の意味、構造、規則、境界に必要なモデル要素を選択し、組織した適用モデルです。静的側面に重点を置きますが、振る舞いや状態を持たないという意味ではありません。ユースケースの動的な実現を組織するアプリケーション・モデルと相補的に扱います。 オブジェクト・モデルは実行可能な形式定義と具体的な実行例を持ち、知識モデルは主として生成AIがモデルを参照、探索、関連付けるための構造を持ち、文芸モデルは人間が理解できる自然言語でシナリオや判断などを表します。用語集は各モデルに現れる概念の意味と同一性を接続します。オブジェクト・モデルのうちCMLに記述した実行可能な部分は、CozyとTextusを通じて実装と実行への経路を持ちます。 ドメイン・モデリングアプリケーション・モデルアプリケーション・モデリング |
||
2026-08-17 |
用語集 |
更新 |
用語モデル関係用語(英)Relationship別名-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.1モデル関係（Relationship）とは、複数のモデル要素の間に成り立つ意味上または構造上の結び付きを、種類、方向、参加端、役割、制約などの意味を伴って表すモデル要素です。具体的な意味は、関連関係、依存関係、汎化関係、実現関係などの関係種別によって定まります。 UML 2.5.1では、Relationshipはモデル要素間の関係を表す抽象的な上位概念です。Association、Dependency、Generalization、Realizationなどは、それぞれ異なる意味を持つ具体的な関係です。SimpleModelingはこの区別を維持し、すべての結び付きをAssociationへ縮約しません。 一般語の「関係」は、人、出来事、資料などの間の広い結び付きを表します。この用語が表すモデル関係は、識別可能なモデル要素であり、特定の関係種別と意味を持ちます。一般文中の「関係する」「関係がある」は、この用語への参照ではありません。 モデル関係は主としてオブジェクト側の構造と意味を表します。関数の合成可能性、引数と結果の型対応、作用の伝播など、関数側の結び付きは、適切な型または関数関係として区別します。 CML（Cozy Modeling Language）では、可能な限り具体的な関係種別を記述します。単に二要素を接続するだけでは意味が確定しないため、関連関係、集約関係、合成関係、依存関係、汎化関係などの区別を失わないようにします。 Scalaのフィールド、継承、traitのmix-in、型境界、関数引数などは異なるモデル関係の実現候補ですが、構文だけからドメイン上の関係種別を一意に逆算できるとは限りません。 simplemodeling-libの型や構造はモデル関係の実現に使用できますが、ライブラリ上の参照や包含だけで関係の意味を確定しません。正規のモデル関係とCML上の指定を意味の根拠にします。 日本語の記事と動画では、概念の初出を「モデル関係（Relationship）」とし、モデルの関係を扱っていることが明らかな範囲でのみ「関係」と短縮します。一般語の「関係」は用語として自動リンクしません。具体的な種別が分かっている場合は、上位語の「関係」だけで済ませず、関連関係、集約関係、合成関係などを使います。 モデル関係は、一般日本語の「関係」すべてを表す用語ではありません。モデル関係と関連関係（Association）は同義ではありません。関連関係はモデル関係の一種です。線で接続されていることだけでは、関係種別や意味は確定しません。SimpleModelingでは、関係を線として描くだけでなく、その意味、責務の所有者、Multiplicity、成立条件を明示します。 モデル上の関連集約関係合成関係実現関係依存汎化多重度OMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
用語集 |
更新 |
Execution Modelingは、SimpleModelingの旧文書で、ユースケースの動的な具体化と、モデルから実装・実行への接続をまとめて指していた旧称です。現在の方法論では、この二つをApplication ModelingとModel Realizationに分けます。 |
||
2026-08-17 |
用語集 |
更新 |
用語モデリング技術体系用語(英)Modeling Technology System別名-Object、Domain、Execution、Knowledgeを同列の四領域とする構成を改め、各モデリング活動の役割と依存関係、用語集によるモデル間接続を明確化しました。 Modeling Technology Systemとは、モデリング技術を個別の技術名ではなく、モデル化対象、目的、成果物、ほかのモデルとの関係によって整理する体系です。技術を分類するだけでなく、開発メソッドで採用する技術の役割と利用方法を定めます。 SimpleModelingのModeling Technology Systemは、Object、Knowledge、Literate Modelingを三つのモデル構成要素を整備する活動、Domain、Use Case、Applicationの各Modelingを三つの構成要素から目的別の適用モデルを組織する活動、Model Realizationを承認済みモデルから実行可能成果物への接続として配置します。これらは同じ階層の独立領域ではなく、異なる役割と依存関係を持ちます。 Domain Model、Use Case Model、Application Modelは、三つと並ぶ追加の構成要素ではありません。Domain Modelは問題領域の意味、構造、規則、境界を、Use Case ModelはActor、Goal、Scenario、Outcomeを、Application ModelはUse Caseの実現と動的構造を、三つの構成要素から目的別に組織します。Quality Attributesは特定のモデルに閉じず、要求、制約、実現方法に対して横断的に確認する設計課題です。 |
||
2026-08-17 |
用語集 |
更新 |
ケーパビリティ(Capability)とは、モデルまたはシステムが利用者や対象領域に対して何を可能にするかを表す概念です。実現方法ではなく、提供できる結果や働きに着目します。 |
||
2026-08-17 |
用語集 |
更新 |
用語モデル上の関連用語(英)Association別名-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.1モデル上の関連（Association）とは、型付けされたインスタンス間に成立し得るリンクの集合を分類し、参加する型、関連端、役割、多重度、ナビゲーションなどを表すモデル関係です。SimpleModelingでは、オブジェクト間の業務上または構造上の意味を、単なる実装上の参照から分離して記述します。 UML 2.5.1では、Associationは、型付けされたオブジェクトを参照する値の組であるLinkの集合を分類するRelationshipです。関連端は参加するType、役割、Multiplicityなどを表します。AggregationおよびCompositionは、Association EndのAggregation Kindによって表される全体部分関係です。 一般語の「関連」は、話題、資料、出来事などの緩やかなつながりにも使われます。この用語が表す関連は、参加端と制約を持つモデル要素です。「関連資料」「関連する処理」などの通常表現は、この用語への参照ではありません。 SimpleModelingでは、AssociationをObject間の業務上または構造上の意味を表す基本的な関係として使います。単なる参照実装やデータベース外部キーとは同一視しません。 関連関係はオブジェクト側の構造を表します。関数値の依存や関数合成とは別の概念であり、実装時に関数を使って関連を操作することだけで両者を同一視しません。 CML（Cozy Modeling Language）では、関連端、役割、多重度、ナビゲーション、および必要な制約を明示します。全体部分の意味がある場合は、通常の関連のまま曖昧にせず、集約関係または合成関係として記述します。 Scalaのフィールド、参照、コレクションは関連の実現候補ですが、それだけでは業務上の関連、役割、多重度、所有、ライフサイクルを完全には表しません。 simplemodeling-libの属性、コレクション、スキーマなどは関連構造の実現に利用できます。実装上の型だけから関連、集約、合成を推論せず、正規モデルで指定された関係種別を維持します。 日本語の記事と動画では、初出を「関連（Association）」とします。ただし、SmartDoxの自動リンク候補には一般語の「関連」を登録せず、Glossaryの正規名を「モデル上の関連」とします。概念が確立した範囲でのみ「関連」と短縮し、一般語の「関連」は用語として扱いません。 関連関係はモデル関係（Relationship）一般と同義ではありません。関連関係は集約関係または合成関係と同義ではありません。全体部分と所有の意味は明示する必要があります。プログラム上の参照やデータベース外部キーだけでは、モデル上の関連は確定しません。モデル関係集約関係合成関係多重度OMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-17 |
用語集 |
更新 |
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。 |
||
2026-08-17 |
用語集 |
更新 |
Viewとは、Modelを特定のPurposeとConcernに応じて選択し、理解、判断、検証、利用できる形で投影した表現です。ViewはModelの一部を見せるものであり、元のModelとは別に意味を所有しません。 |
||
2026-08-17 |
用語集 |
更新 |
用語文芸モデル用語(英)Literate Model別名-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 BoK文芸モデル（Literate Model）とは、人間が理解できる自然言語を中心に、対象、目的、状況、シナリオ、意図、前提、判断、経緯などを記述するモデルです。ドメイン・モデルの概念、規則、関係を通常のドキュメントとして説明する従来型文書も、重要な構成要素です。人間の開発者、非開発者、生成AIの間で共有され、オブジェクト・モデルや知識モデルでは表現できない、またはそれらへ還元すべきでない情報も、モデルの一部として保持します。 文芸モデルは、形式モデルへ説明文を添えた文書や、実装後に作るドキュメントと同義ではありません。自然言語で記述された内容そのものがモデル要素であり、設計と実現の入力になります。 文芸モデルは、オブジェクト側と関数側の形式構造だけでは保持できない目的、シナリオ、判断、利用文脈を記述し、形式モデルへ対応付けます。 現行CML（Cozy Modeling Language）のスコープは、オブジェクト・モデルの実行可能な部分です。文芸モデル全体をCMLで表現することは前提にしません。文芸モデルから抽出され、レビューされた形式要素だけがCMLへ投影されます。 ユースケースシナリオは文芸モデルの一種です。記事、要求、ストーリー、判断記録、ドメイン・モデルを自然言語で説明する文書なども、モデルの意味と安定した識別子へ対応付けられ、設計、理解、検証の入力になる場合は文芸モデルを構成できます。 SimpleModelingモデルは、文芸モデルをオブジェクト・モデルおよび知識モデルと並ぶ構成要素として扱います。SmartDoxは、自然言語、構造化文書、図、用語参照を保持する主要な記述基盤です。用語集の識別子によって、文芸モデルの内容をオブジェクト・モデルおよび知識モデルへ接続します。 文芸モデルは、オブジェクト・モデルの補足説明ではありません。文芸モデルは、生成AI向けに意味関係を構造化する知識モデルと同義ではありません。自然言語で書かれているだけでは文芸モデルになりません。モデルの目的、意味、識別子、設計または検証との対応が必要です。モデルオブジェクト・モデル知識モデルユースケースシナリオ用語集docs/journal/2026/08/2026-08-17-simplemodeling-model-components-and-object-model-scope.mddocs/spec/glossary-entry-format.md |
||
2026-08-16 |
用語集 |
新規 |
用語永続化用語(英)Persistence別名-Term ID: src/main/doxsite/glossary/development-process/persistence.doxEnglish label: PersistenceJapanese label: 永続化Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoK永続化とは、プログラムの実行やプロセスの生存期間を越えて必要な情報を保持し、後の実行から復元可能にするプラットフォーム機構です。 Not applicable。永続化はUMLの分類関係を定義する用語ではなく、モデルを実現するプラットフォーム側の機構です。 CMLは永続化対象となるドメイン構造と制約を記述できますが、永続化方式そのものをドメイン・モデルの意味として要求しません。 Scalaは永続化機構の実装言語になり得ますが、Scalaの型と永続化形式を同一視しません。 simplemodeling-libのSchema、Data Type、Value Domainは永続化境界で共有する契約に利用できます。具体的な保存方式は別のプラットフォーム構成が所有します。 日本語の動画では初出を「永続化(persistence)」とします。 永続化はドメイン・オブジェクトの同一性そのものではありません。永続化方式はドメイン・モデルの意味へ無条件に混入させません。プラットフォームドメイン・モデルスキーマ・データ型実行時データ型src/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 |
用語集 |
新規 |
用語型付き要素用語(英)Typed Element別名-Term ID: src/main/doxsite/glossary/object-foundation/typed-element.doxEnglish label: Typed ElementJapanese label: 型付き要素Category: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK型付き要素とは、型を参照し、その要素が表現できる値を参照先の型によって制約されるモデル要素です。 UML 2.5.1のTypedElementを採用します。Property、Parameterなどは型付き要素であり、Typeはそれらが表現できる値を制約します。 CMLの属性、操作の引数、結果などは、型を指定するという意味で型付き要素として扱います。CMLの要素とUMLメタモデル要素を一対一に同一視しません。 実現時には、型付き要素のモデル型をScalaのフィールド、引数、戻り値などの型へ対応付けます。この対応は変換であり、モデル型とScala型の同一性を意味しません。 simplemodeling-libでは、Schema.ColumnがValueDomainを持ち、ValueDomainがDataType、多重度、制約をまとめます。これは型付き要素に対応する実現例であり、型付き要素の正規定義そのものではありません。 日本語の記事と動画では初出を「型付き要素(typed element)」とし、Type、Classifier、ClassのUML上の関係を説明する場合に用います。 型付き要素は型そのものではありません。型を参照して値を制約される側です。モデル上の型付き要素とScalaの変数、引数、戻り値は同一概念ではありません。型分類子クラス属性操作OMG 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 |
用語集 |
新規 |
用語通信用語(英)Communication別名-Term ID: src/main/doxsite/glossary/development-process/communication.doxEnglish label: CommunicationJapanese label: 通信Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoK通信とは、異なる実行主体または実行境界の間で、合意したプロトコルとデータ契約に従って情報を交換するプラットフォーム機構です。 UMLのMessageやCommunication Diagramは通信を表現できますが、この用語は特定のUML図を意味しません。 CMLは交換する意味構造を記述できます。通信方式、転送、再試行などの機構はプラットフォーム側へ分離します。 Scalaは通信処理を実装する言語になり得ますが、Scalaの型だけでプロトコル互換性が保証されるわけではありません。 simplemodeling-libのSchema、HTTP、結果表現は通信境界の契約に利用できます。個別の通信基盤は別の実現責務です。 日本語の動画では初出を「通信(communication)」とします。 通信はオブジェクト間のAssociationやCollaborationと同義ではありません。プラットフォーム協調スキーマ・データ型src/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 |
用語集 |
新規 |
用語パワータイプ用語(英)Powertype別名-Term ID: src/main/doxsite/glossary/object-foundation/powertype.doxEnglish label: PowertypeJapanese label: パワータイプCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKパワータイプ（Powertype）とは、対象となるClassまたはObjectを区分する分類軸と、その軸で利用できる分類値を、明示的なModel Elementとして定義するClassifierです。SimpleModelingでは、GeneralizationがClassifier間の一般・具体の階層を表すのに対し、Powertypeは顧客種別や商品カテゴリのような分類軸と区分をモデル化します。 UML 2.5.1では、PowertypeはGeneralizationSetのpowertypeとして指定されるClassifierであり、そのInstanceがGeneralizationSetに属する具体Classifierへ対応します。SimpleModelingはこの用法に準拠しつつ、具体Subclassをすべて明示しない場合にも、分類軸と区分を独立したModel Elementとして扱えるように拡張します。厳密なUML写像が必要な場合はGeneralizationSetとPowertype Classifierを用い、区分値として扱う場合はEnumerationまたはProfileによる写像を選択します。 業務システムでは、Powertypeは区分コード、種別マスタ、enumと近い形で実装されることがあります。ただしPowertypeはコード値の一覧ではなく、何をどの観点で分類するかというDomain Model上の意味を所有します。表示ラベルやデータベース上のマスタ表だけをPowertypeとは呼びません。 Object側では、PowertypeがObjectまたはClassifierの分類軸と分類値を表します。Functional側では、閉じたPowertypeを直和型、enum、パターン照合などへ接続し、分類値ごとの処理を型で検査できます。開いた分類を閉じたenumへ縮約するかどうかは、実現方針として別に判断します。 CML（Cozy Modeling Language）はPowertypeをObject種別として定義し、分類値をKindとして記述します。ClassやEntityなどの分類対象はPowertypeへの参照を持つことができます。CML上のPowertype、分類対象との関係、生成されるプログラム上のTypeは関連しますが、同一概念でも一対一対応でもありません。 閉じたPowertypeはScalaのenum、sealed traitとcase object、または値を保持する生成Typeとして実現できます。現在のSimpleModelerは、PowertypeのKindから列挙値を持つScalaのクラス・ファミリを生成します。分類値に論理値、保存値、表示ラベルを持たせる場合もありますが、Scala表現はPowertypeの正規定義そのものではありません。 現行のsimplemodeling-libは、Object ModelのPowertype全体を代表する単一の基底を定義していません。Powertypeのモデル表現とScalaコード生成はSimpleModelerが担い、生成コードの基底契約はsimplemodeling-modelが担います。simplemodeling-libのSchema、Data Type、Value Domainは境界上の値契約に利用できますが、Powertypeの分類意味を置き換えません。 日本語の記事と動画では初出を「パワータイプ（Powertype）」とします。入門では「分類軸と、その軸で使う区分をモデル化する要素」と説明し、Generalizationとの違いを「Generalizationは一般・具体の階層、Powertypeは分類軸と区分」と示します。UMLのGeneralizationSetを詳説するのは、厳密なメタモデル説明が必要な場合に限ります。 PowertypeはGeneralizationと同義ではありません。GeneralizationはClassifier間の分類学的Relationshipであり、Powertypeは分類軸と分類値を表すClassifierです。PowertypeはAssociationやDependencyの一種ではなく、それ自体をObject間のRelationshipとして扱いません。Powertypeは単なるenum、区分コード、表示ラベル一覧、マスタ表と同義ではありません。PowertypeはStateMachineと同義ではありません。Powertypeは分類を、StateMachineは時間に伴う状態遷移を記述します。CMLのPowertypeとScalaのTypeは一対一対応とは限りません。汎化分類子クラス型オブジェクトモデル関係状態機械Cozy Modeling LanguageOMG 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 |
用語集 |
新規 |
用語監視用語(英)Monitoring別名-Term ID: src/main/doxsite/glossary/development-process/monitoring.doxEnglish label: MonitoringJapanese label: 監視Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoK監視とは、実行中のシステムから状態と事象を継続的に収集し、期待からの逸脱を検出して人または自動制御へ通知する運用活動です。 Not applicable。監視はUMLモデル要素の分類ではなく、実行時の運用活動です。 CMLは監視対象となるCapability、Aspect、State、Operationなどの意味を提供できます。収集、判定、通知の機構は実行基盤へ分離します。 Scalaは監視処理を実装できますが、ロギングやメトリクスの個別APIを監視の正規定義とはしません。 simplemodeling-libのObservation、Trace、Resource、Environmentなどは監視データの意味を表す実装契約を提供します。 日本語の動画では初出を「監視(monitoring)」とします。可観測性は監視を可能にするシステム側の性質として区別します。 監視と可観測性は同義ではありません。監視は活動、可観測性は内部状態を外部信号から理解できる性質です。可観測性プラットフォームアスペクト実行リソースsrc/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 |
用語集 |
新規 |
用語モデルの実現用語(英)Model Realization別名-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 BoKモデルの実現（Model Realization）とは、Modelが持つ意味、形式的構造、および契約を、追跡可能性を保ちながらプログラムと実行可能成果物へ対応付ける開発プロセスまたは実現経路です。Model変換、プログラム生成、生成AIによる補完、統合、および実行基盤への配置を含み得ます。 モデルの実現は、UML 2.5.1の実現関係（Realization）そのものではありません。モデルの実現経路の一部で、仕様Model Elementと実装Model Elementの対応を表すために実現関係を使用できます。 一般語としての「構想を実現する」「目的を実現する」よりも限定された用語です。モデルの内容を実装と実行へ接続する具体的な経路と、その対応の追跡可能性を対象にします。 Object-Functional Paradigmでは、Model上のType、Capability、Constraint、Stateなどを、Object側の構造と振る舞い、およびFunctional側の型、関数、結果、Effectへ対応付けます。片方のパラダイムだけへの単純なコード生成には限定しません。 SimpleModelingの標準的な実現経路では、CML（Cozy Modeling Language）が形式的なModel記述を担い、Cozyが変換とプログラム生成を担い、生成AIが必要な実装を補完し、Textusが実行基盤を提供します。これにより、Object Modelingはプラットフォーム機構の手作業ではなくDomain Modelの構造記述に集中できます。 ScalaはSimpleModelingにおける主要な実装先の一つであり、Object側とFunctional側を接続する型表現を提供します。ただし、モデルの実現はScalaコード生成だけに限定されず、設定、Schema、Test、Adapter、およびRuntime成果物も含み得ます。 simplemodeling-libは、Modelの意味をScalaとRuntimeへ対応付けるための語彙と実装要素を提供します。ただし、ライブラリ単独がモデルの実現経路全体を所有するわけではなく、CML、Cozy、生成AI、Textusとの連携によって経路が成立します。 日本語の記事と動画では、初出を「モデルの実現（Model Realization）」とします。経路を強調する場合は「実現経路」を使用できます。「実現」とだけ記すのは、Modelから実装と実行へ至る文脈が確立している場合に限ります。 モデルの実現はUMLの実現関係（Realization）ではありません。記事や図の公開、動画のRenderだけを指す用語ではありません。一対一のプログラム自動生成だけには限定されません。Application Modelingと同義ではありません。Application Modelingはユースケースから実行可能な意味構造を構成し、Model Realizationは承認済みの構造をプログラムと実行基盤へ接続します。実現関係Cozy Modeling Language実行可能仕様アプリケーション・モデリングアプリケーション・モデルモデル追跡可能性src/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 |
用語集 |
新規 |
用語インターフェース用語(英)Interface別名-Term ID: src/main/doxsite/glossary/object-foundation/interface.doxEnglish label: InterfaceJapanese label: インターフェースCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKインターフェース（Interface）とは、Objectが外部へ提供するOperation、Responsibility、Protocolを、そのObjectの内部状態や実装を固定せずに定める、Object側の名前付きType契約です。Classは一つ以上のInterfaceを提供または実現できます。 UML 2.5.1では、Interfaceは外部から観察できる一貫したService集合を定めるClassifierであり、Typeの一種です。ClassなどのBehavioredClassifierはInterfaceRealizationによってInterfaceの契約を実現できます。SimpleModelingはこの基本関係を採用します。 プログラミング言語のinterfaceやtraitは、言語ごとに状態、default method、mixin、Type Classなど異なる能力を持ちます。SimpleModelingのInterfaceは言語構文ではなくObject Model上の契約なので、特定言語のinterfaceまたはtraitと同義ではありません。 Interfaceはsubtype polymorphismによるObject側の契約を表します。任意の既存Typeへ後付けで振る舞いを与えるType Classや、再利用可能な部分構造を合成するTraitとは役割が異なります。 現行の公開CML（Cozy Modeling Language）文法には、専用のInterface Object種別がまだ定義されていません。外部OperationまたはResponsibilityの契約をCMLへ導入するときは、構造やdefault behaviorを持つTraitと区別できる明示的なInterface表現を定める必要があります。専用構文が確定するまで、InterfaceとTraitを同義として扱いません。 ScalaにはJavaと同じ独立したinterface構文はなく、Object側のInterfaceは通常traitで実現します。ただしScala traitはmixin、SimpleModeling Trait、補助Capability、Type Classの表現にも使えるため、Scala traitが常にSimpleModeling Interfaceを意味するわけではありません。 simplemodeling-libのScala traitがObject Model上のInterfaceに対応するかどうかは、その契約がObject自身の外部Responsibilityだけを表すかによって判断します。実装形式だけでInterfaceと判定しません。 日本語の記事と動画では初出を「インターフェース（Interface）」とします。「契約だけならInterfaceを使う」と説明できますが、Type一般をInterfaceへ限定しません。 InterfaceはType全体、Class、Traitのいずれとも同義ではありません。Interfaceは内部状態や実現を固定しません。InterfaceはScala traitまたはType Classと同義ではありません。型分類子クラストレイト操作責務型クラスOMG 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 |
用語集 |
新規 |
用語実現関係用語(英)Realization別名-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.1実現関係（Realization）とは、供給側のModel Elementが示す仕様を、依頼側のModel Elementが実装または具体化し、その契約に適合することを表す有向の抽象関係です。仕様と実装の役割を分けたまま、その対応をModel上で明示します。 UML 2.5.1では、RealizationはAbstractionを特殊化した依存関係です。Supplierが仕様を表し、Clientがその実装を表します。InterfaceRealizationは、BehavioredClassifierがInterfaceの契約を実現する特殊な実現関係です。 通常の日本語でいう「目標を実現する」「機能を実現する」は、必ずしもModel Element間の実現関係ではありません。仕様側と実装側、および両者の適合関係が明示される場合に、この用語を使用します。 Object側のInterfaceや契約をClassなどが実装する対応も、Functional側の関数契約を実装が満たす対応も、仕様と実装の関係として記述できます。ただし、型が対応することや関数を定義することだけでUMLの実現関係になるわけではありません。 CML（Cozy Modeling Language）では、Interfaceや契約をClass、Entity、Componentなどが実現する関係をModelとして明示できます。一方、CMLからプログラムと実行可能成果物を生成する経路全体は「モデルの実現」であり、個々の実現関係とは区別します。 Scalaのclassやobjectがtraitを実装することは実現関係の実装候補ですが、extendsという構文だけでModel上の仕様と実装の意味が確定するわけではありません。 simplemodeling-libの契約、Interface、実装型は実現関係の証拠になり得ますが、ライブラリ内のすべての継承や型適合を実現関係として扱いません。 日本語の記事と動画では、初出を「実現関係（Realization）」とします。後続で「実現」と短縮するのは、仕様と実装のModel Element間関係が明確な場合だけです。通常の動詞「実現する」は、この用語へ自動リンクしません。 実現関係はモデルの実現（Model Realization）という開発プロセスではありません。実現関係は汎化関係（Generalization）ではありません。すべての依存関係（Dependency）が実現関係になるわけではありません。通常の動詞「実現する」と同義ではありません。インターフェース依存モデル関係モデルの実現型クラスOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-16 |
用語集 |
新規 |
用語トレイト用語(英)Trait別名-Term ID: src/main/doxsite/glossary/object-foundation/trait.doxEnglish label: TraitJapanese label: トレイトCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKトレイト（Trait）とは、複数のClassまたは他のTraitへ合成できるFeature、Responsibility、Capability、Constraintを、再利用可能な部分モデルとして定義するSimpleModeling固有のClassifierです。TraitはObject ModelのModel Elementであり、Domain Modelの概念的な幹や独立したInstanceの生成単位ではなく、横断的な構造と振る舞いを表します。 UML 2.5.1にはTraitという独立したMetaclassはありません。SimpleModeling TraitをUML Profileへ写像する場合は、原則としてabstract Classに«trait» stereotypeを適用し、Attribute、Association、Operation、Constraint、既定のBehaviorを保持します。Traitが純粋な外部Operation契約だけを持つ場合はInterfaceへ縮約できますが、その写像ではTraitとしての部分構造や既定Behaviorを表せないことがあります。Traitの適用関係をUML Generalizationで表すのはsubstitutabilityが成立する場合に限り、mixinとしての合成を厳密に表す場合はProfile固有の関係を定めます。 Traitは言語ごとに意味が異なります。SimpleModeling TraitはScala構文の別名ではなく、CMLで定義されるModel Elementです。Scala traitは自然な実現先ですが、言語上のtraitすべてがSimpleModeling Traitを表すわけではありません。 Object側では、TraitがObjectの概念的な幹から横断的なCapabilityや部分構造を分離し、Classへ合成します。Functional側では、同じCapabilityを関数、result type、effect、Type Classなどと接続できます。ただしSimpleModeling TraitとType Classは別概念です。 CML（Cozy Modeling Language）はTraitをObject種別として定義可能です。Traitには再利用するAttribute、Association、Operation、Responsibility、Constraintなどを記述し、Classまたは他のTraitから合成して利用します。Classの概念的なIdentityやLifecycleを、単に再利用したいという理由でTraitへ移しません。 Scala traitはSimpleModeling Traitの主要な実現先です。abstract memberとconcrete member、mixin compositionを使って部分構造と既定Behaviorを実現できます。ただし生成方針により、一つのCML Traitが複数のScala traitや補助Typeへ分割される場合があり、一対一対応とは限りません。 simplemodeling-libのType Modeling Ruleは、概念的な幹、inheritance invariant、state、constructor semanticsにabstract classを使用し、補助的で合成可能なCapabilityにtraitを使用します。この規則はSimpleModeling Traitの意図と整合しますが、Holder、utility、Type Classなど実装上のScala traitをすべてModel Traitへ昇格させません。 日本語の記事と動画では初出を「トレイト（Trait）」とします。Classとの違いは「Classは概念的な幹、Traitは複数のClassへ合成する再利用可能な部分モデル」と説明します。Interfaceとの違いは「Interfaceは外部契約、Traitは構造や既定Behaviorも持ち得る部分モデル」と説明します。 TraitはClassと同義ではなく、独立したInstanceの主要な分類単位ではありません。TraitはInterfaceと同義ではありません。Traitは構造、Constraint、既定Behaviorを持ち得ます。SimpleModeling TraitはScala traitと同義ではありません。TraitはType Classと同義ではありません。型分類子クラスインターフェースフィーチャー責務ケーパビリティオブジェクト関数パラダイムOMG 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 |
用語集 |
新規 |
用語Scala別名-Term ID: src/main/doxsite/glossary/object-functional-programming/scala.doxEnglish label: ScalaJapanese label: ScalaCategory: Object-Functional ProgrammingStatus: normativeDefinition authority: SimpleModeling BoKScalaとは、オブジェクト指向と関数型の構成要素を一つの静的型システムで扱うプログラミング言語であり、SimpleModelingではCMLのモデル構造を実行可能なプログラムへ実現する主要な接続先です。 UMLのType、Classifier、ClassとScalaのtype、trait、classは同一概念ではありません。設計モデルから実装言語へ実現するときに対応付けます。 Scalaは、class、trait、enumなどによるオブジェクト側の構造と、関数、値、作用、合成による関数側の構造を、共通の型システムで接続できます。この性質をSimpleModelingのオブジェクト関数パラダイムの実現に利用します。 CMLのモデル要素は、CozyによってScalaのclass、trait、case class、enum、関数型などへ対応付けられます。この対応は意味に基づく変換であり、常に一対一ではありません。 この観点では、Scala固有のclass、trait、case class、enum、opaque type、union type、intersection type、関数型などを、モデルの実現に利用する言語構成要素として扱います。これらのScala構成要素は、UMLやCMLのType、Classifier、Classと対応付けられますが、同一概念でも固定的な一対一対応でもありません。 simplemodeling-libはScala 3で実装され、Schema Data Type、Runtime Data Type、Value Domain、多重度、制約などの実行時契約を提供します。ライブラリの現在の構成をScalaという言語の定義と同一視しません。 Scalaは固有名であるため翻訳せず、記事と動画でもScalaと表記します。初出時にも英語名の重複併記は行いません。 Scala型はCMLのモデル型と同一ではありません。ScalaはSimpleModelingのモデル意味の正本ではなく、その実現先です。型クラストレイトオブジェクト関数パラダイムCozy Modeling LanguageScala 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 |
用語集 |
新規 |
用語実行制御用語(英)Execution Control別名-Term ID: src/main/doxsite/glossary/development-process/execution-control.doxEnglish label: Execution ControlJapanese label: 実行制御Category: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoK実行制御とは、プログラムの開始、順序付け、並行実行、待機、再試行、中止、終了を調整するプラットフォーム機構です。 UMLのActivity、StateMachine、Interactionは実行順序を表現できますが、実行制御というプラットフォーム機構そのものではありません。 CMLはOperation、State、Constraint、Collaborationなどの意味を記述します。スレッド、ジョブ、再試行などの実行制御は、意味を保ったまま生成系と実行基盤へ分離します。 Scalaの関数、Future、Effect Systemなどは実行制御を実装できますが、特定のScala APIをこの概念と同一視しません。 simplemodeling-libのProcess、Consequence、StateMachineなどは実行制御を支える契約に利用できます。実行基盤全体の制御方式はTextusなどの側が所有します。 日本語の動画では初出を「実行制御(execution control)」とします。 実行制御はStateやStateMachineそのものではありません。実行制御はドメイン・モデルの意味を置き換えません。プラットフォーム状態機械操作src/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 |
用語集 |
新規 |
用語実行リソース用語(英)Runtime Resource別名-Term ID: src/main/doxsite/glossary/development-process/runtime-resource.doxEnglish label: Runtime ResourceJapanese label: 実行リソースCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoK実行リソースとは、プログラムの実行に必要で、取得、共有、利用、解放というライフサイクルを実行基盤が管理する技術的資源です。 Not applicable。実行リソースはUMLのClassifierやObjectの一般分類を定める用語ではありません。 CMLのドメイン・モデルは実行リソースの具体的な取得と解放から分離します。ドメイン上のResource概念を表す場合は、その業務上の意味と同一性を別に定義します。 ScalaではResource管理を安全な取得・利用・解放の構造として実装できますが、その特定のライブラリ形式を正規定義にはしません。 simplemodeling-libには、ファイル、URL、実行環境などを観測対象のResourceとして表す型があります。これは実行リソースを記述する一つの実装上の観点であり、ライフサイクル管理全体を意味しません。 日本語の動画では曖昧な「リソース」を避け、初出を「実行リソース(runtime resource)」とします。 実行リソースは、ドメイン上で意味と同一性を持つResource Objectと同義ではありません。実行リソースはComponentそのものではありません。プラットフォームコンポーネントライフサイクルsrc/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 |
用語集 |
新規 |
用語構造上の所有用語(英)Structural Ownership別名-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 Composition構造上の所有（Structural Ownership）とは、全体部分関係において、全体が部分を自らの構造境界に含め、部分の存在、ライフサイクル、および不変条件に責任を持つという意味です。単に部分への参照を保持することではなく、部分を全体の一部として成立させる意味上の責任を表します。 UML 2.5.1にStructural Ownershipという独立したMetaclassはありません。SimpleModelingでは、合成関係（Composition）において合成するオブジェクトが部分の存在と保管に責任を持ち、部分が同時に高々一つの合成された全体に含まれるという意味を、この用語で明示します。 一般語の「所有」には、法的な所有権、アクセス権、データの管理責任、組織上の担当などが含まれ得ます。構造上の所有は、それらではなく、Object Modelの全体部分構造に限定した概念です。 Object側では、構造上の所有が変更と不変条件を管理する境界を示します。Functional側では、Immutableな値を再構築して同じ意味を実現できますが、値の包含や関数の適用そのものを構造上の所有とは呼びません。 CML（Cozy Modeling Language）では、構造上の所有を合成関係として表現します。通常の関連、フィールド、参照、または多重度だけでは構造上の所有を意味しません。 Scalaのフィールド、case class、コレクション、ネストした型は構造上の所有を実装できますが、Scalaの型システムだけではドメイン上の所有境界を確定しません。 simplemodeling-libには構造上の所有と一対一に対応する単一の型はありません。Collection、Group、Schemaなどは実現要素になり得ますが、モデル上の合成関係と不変条件によって意味を確定します。 日本語の記事と動画では、初出を「構造上の所有（Structural Ownership）」とします。その後も全体部分構造の文脈が明確な場合だけ「所有」と短縮します。法的所有、アクセス権、責務分担などの意味で使う「所有」は、この用語へ自動リンクしません。 構造上の所有は意味であり、合成関係（Composition）はその意味を持つ関係です。責務、状態、データ管理、アクセス権、組織上の担当とは異なります。参照、フィールド、外部キー、削除カスケード、画面の包含だけからは推論しません。多重度は構造上の所有を意味しません。合成関係モデル上の関連集約関係モデル関係ライフサイクル不変条件責務OMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-16 |
用語集 |
新規 |
用語トランザクション用語(英)Transaction別名-Term ID: src/main/doxsite/glossary/development-process/transaction.doxEnglish label: TransactionJapanese label: トランザクションCategory: Development ProcessStatus: normativeDefinition authority: SimpleModeling BoKトランザクションとは、複数の状態変更を一つの実行境界として扱い、完了時には変更を確定し、失敗時には整合した状態へ戻せるようにするプラットフォーム機構です。 Not applicable。トランザクションはUMLのClassやObjectの分類を定義する概念ではありません。 CMLは操作の事前条件、事後条件、不変条件や状態変更を記述できます。具体的なトランザクション境界は、ドメイン上の意味とプラットフォーム上の実現を区別して設計します。 Scalaはトランザクション制御を実装できますが、言語の関数呼び出しや例外境界が自動的にトランザクション境界になるわけではありません。 simplemodeling-libは状態、制約、結果を表す契約を提供しますが、単一の汎用トランザクション基盤をこの用語の正規定義とはしません。 日本語の動画では初出を「トランザクション(transaction)」とします。 トランザクションはUse Case、Operation、Capabilityのいずれとも同義ではありません。ドメイン上の業務的なまとまりと技術的トランザクション境界は必ずしも一対一ではありません。プラットフォーム状態操作不変条件事前条件事後条件src/main/doxsite/glossary/development-process/platform.doxsrc/main/doxsite/glossary/object-foundation/invariant.doxdocs/spec/glossary-entry-format.md |
||
2026-08-16 |
用語集 |
更新 |
用語クラス用語(英)Class別名-Term ID: src/main/doxsite/glossary/object-foundation/class.doxEnglish label: ClassJapanese label: クラスCategory: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoKクラス（Class）とは、Objectの集合を分類し、それらのObjectが持つ構造、状態、振る舞い、責務を形式的に記述する、Object Modelの主要なModel Elementです。ClassはObject側の名前付きTypeであり、そのTypeのモデル上の実現を記述します。 UML 2.5.1では、ClassはObjectの集合を分類し、その構造と振る舞いを特徴付けるFeatureを定めるClassifierです。ClassはClassifierの特殊化であり、ClassifierはTypeの特殊化なので、Class自身がTypeです。SimpleModelingでいう「モデル上の実現」は説明上の役割を表し、UMLのRealization関係を意味しません。 ClassはObject側の概念的な幹、固有の状態、Invariant、Operation、Lifecycleを表します。複数のClassへ横断的に合成する部分構造やCapabilityはTraitへ、外部へ示す契約はInterfaceへ分離できます。Classから導かれるTypeは、関数、結果、作用、Type ClassなどのFunctionalな契約と接続できます。 現行の公開CML（Cozy Modeling Language）文法は汎用のClass Object種別ではなく、Entity、Valueなどの具体的なObject種別を定義します。これらをClass相当のClassifierとして扱い、共通する部分構造はTraitとして分離できます。Cozyは意味に応じてScalaのabstract class、class、case class、traitなどを組み合わせて実現するため、Model上のClassとScala classは一対一対応ではありません。 Scalaのclass宣言はClassと、そのInstanceが持つTypeを同時に導入します。ただしScala Typeにはtrait、enum、opaque type、関数型、union type、intersection typeなども含まれるため、ScalaでもTypeとClassは同義ではありません。 simplemodeling-libのType Modeling Ruleは、Domain Modelの概念的な幹、constructor semantics、state、inheritance invariantをScalaのabstract classで表し、補助的で合成可能なCapabilityをtraitで表します。これらはScala実現上の方針であり、Classの正規定義を変更しません。 日本語の記事と動画では初出を「クラス（Class）」とします。「ClassがTypeを記述する」ではなく、「Class自身がTypeであり、Objectの構造と振る舞いを記述する」と説明します。第5回ではClassifier階層を詳説せず、Type、Interface、Traitとの役割の違いを中心に示します。 ClassはTypeと同義ではありません。ClassはObject側のTypeの一種です。ClassはTraitと同義ではありません。Classは概念的な幹を、Traitは合成可能な部分構造を表します。ClassはInterfaceまたはClass Diagramと同義ではありません。Classによって分類されるObjectが、必ずEntityとしての永続的Identityを持つとは限りません。型分類子インターフェーストレイトオブジェクトクラス図OMG 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 |
用語集 |
更新 |
用語分類子用語(英)Classifier別名-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.1分類子（Classifier）とは、共通するFeatureに基づいてInstanceを分類し、それらのInstanceが持ち得る構造または振る舞い上の特徴を定めるTypeです。SimpleModelingではClass、Interface、Trait、Data Typeなどの共通する上位概念として使用します。 UML 2.5.1では、ClassifierはTypeの特殊化であり、Class、Interface、DataTypeなどの上位概念です。SimpleModelingのTraitはUML標準のClassifier種別ではなく、Classifierの意味を拡張するSimpleModeling固有のModel Elementです。UML Profileへ写像する場合は、原則としてabstract Classへ«trait» stereotypeを適用します。 ClassifierはObject側の分類構造を厳密に説明するための概念です。関数型、union type、intersection type、type lambdaなど、すべてのObject-Functional TypeをClassifierとして扱うわけではありません。 CMLではEntity、Value、Trait、Powertype、StateMachineなどの具体的なObject種別を使用します。Classifierはそれらの分類上の共通性を説明するメタモデル上の補助語であり、通常のDomain Model記述で常に明示する語ではありません。 ScalaにUML Classifierと一対一に対応する単一の言語要素はありません。class、trait、enumなどはInstanceや値を分類するTypeを導入しますが、Scala Type全体がUML Classifierであるわけではありません。 日本語では「分類子（Classifier）」を正規表記とします。ただしObject Modeling入門ではClass、Interface、Trait、Data Typeを直接説明し、ClassifierはUML上のTypeとの関係を厳密に示す場合だけ導入します。「ClassifierはInstanceを分類し、ClassはObjectを分類する」という階層説明を、ClassとTypeの主説明の代わりにはしません。 ClassifierはClassと同義ではありません。ClassはClassifierの一種です。ClassifierはType全体と同義ではありません。SimpleModeling TraitをUML標準のClassifier種別として扱いません。Classifierは実行時のObject Instanceではありません。型クラスインターフェーストレイトデータ型インスタンスフィーチャーOMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-16 |
用語集 |
更新 |
用語型用語(英)Type別名-Term ID: src/main/doxsite/glossary/object-foundation/type.doxEnglish label: TypeJapanese label: 型Category: Object FoundationStatus: normativeDefinition authority: SimpleModeling BoK型（Type）とは、値がどの文脈で利用でき、どの操作、変換、結果、作用、合成がその値に対して成立するかを静的に規定する、SimpleModelingのオブジェクト関数パラダイム（Object-Functional Paradigm）における意味契約です。 UML 2.5.1のTypeは、TypedElementが表現できる値を制約する抽象的なModelElementです。ClassifierはTypeの特殊化であり、Class、Interface、DataTypeはClassifierの特殊化です。したがってUMLではClassやInterface自身がTypeであり、Classが別のTypeを外側から実現するという関係ではありません。SimpleModelingはこの関係を維持しつつ、正規用語「型」の中心をObject-Functionalな意味契約に置きます。 プログラミング言語では、class宣言によって導入される型だけでなく、関数型、直和型、交差型、型別名、適用型などもTypeに含まれます。したがってTypeとClassを同義語として扱いません。 Object Modelでは、抽象的なTypeを前面に出すより、Class、Interface、Trait、Data TypeによってObjectの構造、契約、再利用可能な部分構造、値の意味を記述します。関数側では、値、関数、結果、作用、合成可能性をTypeで記述します。SimpleModelingのTypeは両者を接続し、Object ModelをScalaなどの型システムへ実現するための共通契約になります。 CML（Cozy Modeling Language）は、Entity、Value、Trait、Powertype、StateMachineなどのObject種別と、そのAttribute、Association、Operation、Constraintを形式化します。これらの記述は実現時にTypeとして利用されますが、CMLのModel Elementと実装言語のTypeは同一概念でも一対一対応でもありません。 Scalaではclass、trait、enum、opaque typeなどの宣言がTypeを導入し、さらに関数型、union type、intersection type、applied type、type lambdaなどを表現できます。高kindのType ConstructorとKindはScala接続では重要ですが、Object Model入門では発展項目として扱います。 simplemodeling-libはModel全体を代表する単一のType基底を定義しません。意味に応じてScalaのabstract class、class、trait、case class、enum、opaque type、関数型、Schema Data Type、Runtime Data Typeなどへ責務を分けます。これはTypeの実現方針であり、Typeの正規定義そのものではありません。 日本語の記事と動画では初出を「型（Type）」とします。Object Modelの説明ではClass、Interface、Trait、Data Typeを具体語として使い、TypeはObject-Functionalな契約またはScala接続を説明するときに使います。ClassifierはUMLとの関係を厳密に説明する場合だけ補助的に使います。 TypeはClass、Interface、Traitのいずれとも同義ではありません。CMLのModel ElementとScala Typeは同一概念でも一対一対応でもありません。Type ConstructorとKindはTypeと関係しますが、同じ概念ではありません。分類子クラスインターフェーストレイトデータ型オブジェクト関数パラダイムCozy Modeling LanguageOMG 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 |
用語集 |
更新 |
用語合成関係用語(英)Composition別名-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.1合成関係（Composition）とは、全体が部分に対する構造上の所有を担う強い全体部分関係です。部分は同時に高々一つの合成された全体に属し、その存在、ライフサイクル、および不変条件は全体の境界と整合して管理されます。 UML 2.5.1では、合成関係はAssociation EndのAggregation Kindをcompositeとする二項の関連です。合成するオブジェクトは部分の存在と保管に責任を持ち、部分側の上限多重度は一です。SimpleModelingはこの意味を採用し、ドメイン上のライフサイクルと不変条件の境界を判断するために用います。 一般語としての「合成」、関数合成、画像や音声の合成は、この用語が表す全体部分関係ではありません。また、共有され得る部分を表す集約関係（Aggregation）とも区別します。 合成関係は、Object側でライフサイクルと不変条件の境界を定めます。Functional側の関数合成とは別の概念であり、両者を短い表記「合成」だけで同一視しません。 CML（Cozy Modeling Language）では、関連を合成関係として明示して記述できます。永続化時の同時保存、フィールドの包含、または画面上の親子表示だけから合成関係を推論しません。 Scalaには合成関係と一対一に対応する言語要素はありません。フィールド、case class、コレクション、ネストした型は実装候補ですが、それだけでは構造上の所有を表しません。 simplemodeling-libのCollection、Group、Schemaなどは合成された構造の実現に利用できますが、それらの型を使用したことだけでドメイン上の合成関係が成立するわけではありません。 日本語の記事と動画では、初出を「合成関係（Composition）」とし、同じ全体部分関係を扱う文脈が続く場合だけ「合成」と短縮します。通常の日本語や関数型プログラミングにおける「合成」は、この用語へ自動リンクしません。 合成関係は関連（Association）一般と同義ではありません。同時保存、画面の親子関係、フィールド参照だけでは合成関係になりません。多重度（Multiplicity）は合成関係の個数制約を表せますが、それ自体は構造上の所有を意味しません。関数合成や集約関係（Aggregation）とは異なる概念です。構造上の所有モデル上の関連集約関係モデル関係ライフサイクル不変条件多重度OMG Unified Modeling Language 2.5.1docs/spec/glossary-entry-format.md |
||
2026-08-15 |
用語集 |
新規 |
Identifierとは、Identityを持つ対象または相関対象を参照し、他の対象から区別するために使用する値です。IdentifierはIdentityを表現できますが、対象が時間を通じて同じ対象であるというIdentityの意味そのものではありません。 |
||
2026-08-15 |
用語集 |
新規 |
UMLにおけるData Typeは、InstanceがIdentityではなく値によって識別されるClassifierです。Data TypeのInstanceは、同じ値を持つ場合に区別されません。 |
||
2026-08-15 |
用語集 |
新規 |
Schema Data Typeは、Parameter、FieldなどのValue Domainで使用するDomain Typeの記号的で宣言的な記述です。値の意味を識別し、正規化または変換の方式を選択するキーになります。 |
||
2026-08-15 |
用語集 |
新規 |
Runtime Data Typeは、Model上の値の意味を実行時のScala値として表すTypeです。値、等価性、基本的な成立条件、必要なOperationを実装します。 |
||
2026-08-15 |
用語集 |
新規 |
SimpleModelingにおけるUniversal Identifierは、システム境界をまたいで一意に参照できるcanonical string形式を持つ、不透明で値ベースのoperational identifierです。 |
||
2026-08-15 |
用語集 |
新規 |
SimpleModeling Libraryは、Model-driven systemの生成コードと手書きコードが共有する、protocol、datatype、operationなどの長期的な意味を定義するcore semantic model libraryです。 |
||
2026-08-15 |
用語集 |
新規 |
Value Domainは、Parameter、Attribute、Fieldなどが取り得る値の意味領域を、Data Type、Multiplicity、Constraintの組として宣言したものです。 |
||
2026-08-15 |
用語集 |
新規 |
SimpleModelingにおけるCanonical Identifierは、Observation、Conclusion、Consequence、Executionなどをシステム境界をまたいで相関させるための、安定した不透明なIdentifierです。 |
||
2026-08-15 |
用語集 |
更新 |
UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。 |
||
2026-08-15 |
用語集 |
更新 |
UMLにおけるMultiplicityは、下限から上限までの非負整数の包含区間によって、Model ElementのInstanceに許される個数を定める情報です。上限は無制限の場合があります。 |
||
2026-08-15 |
用語集 |
更新 |
Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。 |
||
2026-08-15 |
用語集 |
更新 |
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。 |
||
2026-08-15 |
用語集 |
更新 |
Object-Functional Paradigmとは、ObjectのIdentity、Responsibility、State、Collaborationによる構造化と、型、値、関数、合成による厳密な計算表現を組み合わせる設計パラダイムです。 |
||
2026-08-15 |
用語集 |
更新 |
UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。 |
||
2026-08-15 |
用語集 |
更新 |
Identityとは、値やStateが変化しても、ある対象を他の対象と区別し、時間を通じて同じ対象として追跡するための同一性です。IdentifierはIdentityを表現または参照する値であり、Identityそのものと同義ではありません。 |
||
2026-08-15 |
用語集 |
更新 |
UMLにおけるStateMachineは、Eventの発生によって起動されるTransitionでStateのグラフをたどり、システム要素のevent-driven Behaviorを表すBehaviorです。 |
||
2026-08-14 |
用語集 |
新規 |
Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。 |
||
2026-08-14 |
用語集 |
新規 |
Postconditionとは、Preconditionを満たして開始したOperationが契約どおり完了した後に、提供側が成立を保証するConstraintです。 |
||
2026-08-14 |
用語集 |
新規 |
UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。 |
||
2026-08-14 |
用語集 |
新規 |
UMLにおけるFeatureは、ClassifierのInstanceを特徴付ける構造上または振る舞い上の性質です。AttributeなどのStructural Featureと、OperationなどのBehavioral Featureがあります。 |
||
2026-08-14 |
用語集 |
新規 |
Lifecycleとは、ある対象が生成されてから終了するまでに、Identityを保ちながら通過するStateとTransitionの範囲です。 |
||
2026-08-14 |
用語集 |
新規 |
Securityとは、情報と機能を正当な権限に従って保護し、不正な閲覧、利用、変更、破壊、否認を防ぐ性質です。Confidentiality、Integrity、Authenticity、AccountabilityなどのConcernを含みます。 |
||
2026-08-14 |
用語集 |
新規 |
UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。 |
||
2026-08-14 |
用語集 |
新規 |
Design by Contractは、ソフトウェア要素が提供するOperationを、呼び出し側と提供側の義務および保証として明示する設計方法です。契約をPrecondition、Postcondition、Invariantによって表します。 |
||
2026-08-14 |
用語集 |
新規 |
UMLにおけるGeneralizationは、より一般的なClassifierと、より具体的なClassifierの間の分類学的Relationshipです。具体側のInstanceは一般側のInstanceでもあり、具体側は一般側のFeatureを継承します。 |
||
2026-08-14 |
用語集 |
新規 |
Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。 |
||
2026-08-14 |
用語集 |
新規 |
Instanceとは、Classifierによって分類される具体的な存在です。UMLのInstanceSpecificationは、モデル化されたシステム内のInstanceを表現するModel Elementであり、Instanceそのものとそのモデル上の表現を区別します。 |
||
2026-08-14 |
用語集 |
新規 |
Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。 |
||
2026-08-14 |
用語集 |
新規 |
Reliabilityとは、指定された条件と期間のもとで、システムが要求された機能を一貫して遂行する性質です。Availability、Fault Tolerance、Recoverabilityなどを含む観点から評価します。 |
||
2026-08-14 |
用語集 |
新規 |
Preconditionとは、Operationを契約に従って呼び出す前に、呼び出し側が成立させる必要があるConstraintです。 |
||
2026-08-14 |
用語集 |
新規 |
Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。 |
||
2026-08-14 |
用語集 |
新規 |
UMLにおけるTransitionは、StateMachine内のSource VertexからTarget Vertexへ進む有向関係です。Trigger、Guard、Effectなどによって、いつ遷移し何を実行するかを定めます。 |
||
2026-08-14 |
用語集 |
新規 |
Attributeとは、ClassifierのInstanceが保持し得る値または参照を表すStructural Featureです。Attributeは名前、Type、Multiplicity、既定値、Constraintなどによって特徴付けられます。 |
||
2026-08-14 |
用語集 |
新規 |
UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。 |
||
2026-08-14 |
用語集 |
新規 |
Invariantとは、対象が有効である間、観測可能な安定点で常に成立しなければならないConstraintです。Object、Type、または複数要素からなる構造に適用できます。 |
||
2026-08-14 |
用語集 |
新規 |
Platformとは、ソフトウェアを構築、配置、実行、運用するために共通して利用する技術的な基盤とサービスの集合です。 |
||
2026-08-14 |
用語集 |
新規 |
開発におけるTraceabilityとは、要求、用語、Model Element、設計判断、Test、実装、実行結果の関係を識別子と根拠によってたどれる性質です。 |
||
2026-08-14 |
用語集 |
新規 |
Performanceとは、指定された条件と資源のもとで、システムが処理時間、応答時間、Throughput、容量などの時間的要求を満たす性質です。 |
||
2026-08-14 |
用語集 |
新規 |
UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。 |
||
2026-08-14 |
用語集 |
新規 |
Class Diagramとは、Class、Interface、Data Type、Association、Generalization、Dependencyなどを用いて、Modelの静的構造を示すUML Diagramです。 |
||
2026-08-14 |
用語集 |
更新 |
ドメイン・オブジェクトとは、ソフトウェアシステムが対象とする現実世界の領域（ドメイン）を表現するためのオブジェクトであり、ビジネスロジックや概念的構造を内包します。 これは、エンティティ、バリュー・オブジェクト、サービス、ルール、イベントなどの要素を含む、ドメイン・モデルを構成する中核的な構造です。 ドメイン・オブジェクトは、システム内でのデータ構造や処理の単なる表現ではなく、問題領域の意味や振る舞いを反映するモデルの一部です。 |
||
2026-08-10 |
記事 |
新規 |
第4回はModelを主題とし、Domain ModelとUse Case Modelを二つの軸にCapabilityとAspectを構成します。Object Modelを使って形式構造を具体的に説明し、複雑なModelはPurposeとConcernに応じたViewから理解・検証・利用します。 |
||
2026-08-03 |
記事 |
新規 |
Knowledge Systemは既存技術を収集、整理、分類し、理解のための地図を提供します。Software Development Methodologyは、その知識から必要な技術を選び、役割と利用方法を定め、開発実践を導きます。SimpleModelingモデルは、形式構造と実行例を担うObject Model、生成AI向けの知識構造を担うKnowledge Model、人間が理解できる文脈や意図を担うLiterate Modelから構成されます。Domain Modelingは問題領域の意味、構造、規則、境界に重点を置き、Application ModelingはUse Caseの実現、協調、相互作用、状態遷移、Event、Service、Operationに重点を置いて、三つの構成要素を目的別に組織します。Domain Modelingを完全に静的、Application Modelingをすべての動的要素の所有者とはしません。承認済みの実行可能な形式構造は、Model RealizationとしてCML、Cozy、AI、Textusを通じて実行可能ソフトウェアへ接続します。品質属性はモデル全体を横断する設計課題として扱います。 |
||
2026-07-31 |
用語集 |
新規 |
Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。 |
||
2026-07-31 |
用語集 |
新規 |
Quality Attributeとは、ソフトウェアが機能を実行できることに加えて、どの程度の品質で要求を満たすかを表す特性です。Security、Performance、Availability、Reliability、Resilience、Observability、Maintainabilityなどが含まれます。 |
||
2026-07-31 |
用語集 |
更新 |
用語プロセス・スタイル用語(英)Process Style別名-Process StyleをDevelopment Method内部の要素ではなく、Development Processを構成するときに組み合わせる交換可能な要素として修正しました。 Process Styleとは、Development Methodを時間軸上でどのように適用するかを定める進め方の様式です。反復型、漸進型、ウォーターフォール型、Agile型、ハイブリッド型などがあり、開発活動の順序、繰り返し方、リズム、確認点、成果物を生成するタイミングを特徴付けます。 SimpleModelingでは、Process StyleをDevelopment Methodそのものに含めず、Development Processを構成するときにDevelopment Methodと組み合わせる交換可能な要素として扱います。MethodologyとProcess Styleを分離することで、Methodologyの再利用性を高めます。プロジェクトの性質やチーム体制に応じてProcess Styleを選択し、同じDevelopment Methodを異なる開発実務へ適用できます。SMRPでは、RUPとAgileを組み合わせたハイブリッド型Process Styleを採用しています。 |
||
2026-07-31 |
用語集 |
更新 |
用語開発プロセス用語(英)Development Process別名-開発プロセスを、開発メソッドをProcess Styleによって実務で運用する仕組みとして明確化し、Agileとの関係を補足しました。 開発プロセスとは、開発メソッドをソフトウェア開発の実務で運用するための活動、役割、順序、反復、確認点、成果物の流れです。計画、モデリング、実装、レビュー、テスト、リリース、フィードバックを、プロジェクトの状況に応じて構成します。 SimpleModelingでは、Development ProcessをDevelopment MethodとProcess Styleの組み合わせとして定義します。Development Methodはモデルとモデル変換の体系を定め、Process Styleはそのメソッドを時間軸上でどのように適用するかを定めます。 Agileは、反復、漸進、短いフィードバック周期などによってDevelopment Processを構成するProcess Styleの一つです。プロジェクトでは、選択したProcess Styleに基づいて、誰が、いつ、どのモデルや成果物を作成、確認、更新するかを具体化します。得られた知識と成果物はBoKへ戻し、後続の反復で再利用します。 |
||
2026-07-27 |
記事 |
新規 |
SimpleModelingは、CML、DSL、文芸モデル、Cozy、Textusによって、モデルから実行可能ソフトウェアへの経路を構築してきました。CozyはCMLを実行可能ソフトウェアへ変換し、AIはCozyが変換しきれない実装部分を補完します。Textusは得られたソフトウェアを実行します。一方、知識からドメインモデルを構成する工程は主に人間が担ってきました。BoKを共通基盤としてドメインエキスパート、開発者、AIが協業することで、KnowledgeからExecutable Softwareまでを一つの方法論として扱えます。 |
||
2026-07-27 |
記事 |
更新 |
SimpleModelingは、CML、DSL、文芸モデル、Cozy、Textusによって、モデルから実行可能ソフトウェアへの経路を構築してきました。CozyはCMLを実行可能ソフトウェアへ変換し、AIはCozyが変換しきれない実装部分を補完します。Textusは得られたソフトウェアを実行します。一方、知識からドメインモデルを構成する工程は主に人間が担ってきました。BoKを共通基盤としてドメインエキスパート、開発者、AIが協業することで、KnowledgeからExecutable Softwareまでを一つの方法論として扱えます。 |
||
2026-07-20 |
記事 |
新規 |
AIの登場によって、ドメインモデルは、実装への実現経路を持ち、開発を実際に前へ進めるworking abstractionになりました。AIはドメインモデルを実装へ変換し、実装に必要な詳細を補完します。これにより、人間が主に扱う対象は、実装の逐次記述から、対象世界、責務、実行、知識を表すソフトウェアモデルへ移ります。モデルの品質がソフトウェアの品質を強く左右するため、モデリングが新しいチョークポイントとなり、既存のソフトウェア工学をモデリング中心の方法論として再構成する必要があります。 |
||
2026-07-13 |
記事 |
新規 |
01.a-invocation-source-lab は、同じ minimal.main.hello selector を保ったまま、Component の読み込み元を development directory と component repository で切り替えて確認するサンプルです。 |
||
2026-07-13 |
記事 |
更新 |
02-component 系では、Textus component を開発中 project から packaged artifact へ進める基本手順を確認します。 |
||
2026-07-13 |
記事 |
更新 |
01-minimal 系のサンプルで、Textus component の最小 Component / Service / Operation と、それを CNCF engine 上で呼び出す形を確認します。 |
||
2026-07-13 |
記事 |
更新 |
|
||
2026-07-13 |
記事 |
更新 |
01.d-component-script は、textus-tutorial 0.1.3 の中で、小さな管理コマンドを Textus operation contract に接続する script-style operational form を確認するサンプルです。 |
||
2026-07-13 |
記事 |
更新 |
本記事では、textus-tutorial 0.1.3 を使って Textus component 開発手順を学ぶ前提として、Textus / Cozy Textus、内部エンジンである CNCF、そして cozy / cncf / textus launcher の役割を整理します。 |
||
2026-07-06 |
記事 |
新規 |
02-component 系では、Textus component を開発中 project から packaged artifact へ進める基本手順を確認します。 |
||
2026-07-06 |
記事 |
更新 |
|
||
2026-07-06 |
記事 |
更新 |
|
||
2026-07-06 |
記事 |
更新 |
|
||
2026-06-29 |
記事 |
新規 |
01-minimal 系のサンプルで、Textus component の最小 Component / Service / Operation と、それを CNCF engine 上で呼び出す形を確認します。 |
||
2026-06-22 |
記事 |
新規 |
01.d-component-script は、textus-tutorial 0.1.3 の中で、小さな管理コマンドを Textus operation contract に接続する script-style operational form を確認するサンプルです。 |
||
2026-06-15 |
記事 |
新規 |
本記事では、textus-tutorial 0.1.3 を使って Textus component 開発手順を学ぶ前提として、Textus / Cozy Textus、内部エンジンである CNCF、そして cozy / cncf / textus launcher の役割を整理します。 |
||
2026-06-08 |
記事 |
新規 |
CNCFのJob管理は、Commandの実行状態、結果、診断情報を管理するための仕組みです。 同期実行、Job付き同期実行、非同期実行、同期実行＋非同期継続を同じモデルで扱い、 Event発行後の処理も同期型または非同期型の購読として整理できます。 |
||
2026-06-01 |
記事 |
新規 |
How SIE links book knowledge with external RDF knowledge spaces. |
||
2026-05-24 |
記事 |
新規 |
Semantic Integration Engine (SIE)では、Bookを単なる書誌情報として扱いません。 SIEはローカルなRDFノードを採番し、それに対してOpen Library、DBpedia、Wikidataなどのオープン知識を関連づけることで、 Bookを説明可能な知識構造として管理します。 |
||
2026-05-18 |
記事 |
新規 |
AI駆動開発では、SecurityやObservabilityのような非機能要件をどのように成立させるのかが大きな論点になります。 Observabilityだけを考えても、分散トレース、メトリクス、構造化診断、Payload保護、外部監視基盤連携など、多数の横断的機能が必要になります。 これらを毎回AIへ自然文で指示し、個別実装へ委譲すると、生成コスト・レビューコスト・運用コストが急速に増大し、品質保証も不安定になります。 そのためCML&CNCFでは、文芸モデルへ十分な構造情報を記述すると、モデルコンパイラと実行フレームワークがSecurityやObservabilityを横断的に成立させます。 |
||
2026-05-11 |
記事 |
新規 |
SimpleModelingは、Unified Processに由来するアーキテクチャセントリックなアプローチを採用しています。アーキテクチャは単なる設計成果物ではなく、要求・分析・設計・実装・運用を統合する構造として扱われます。開発初期からアーキテクチャビューを利用することで、モデル全体の整合性・分析容易性・AI適合性を高めます。 |
||
2026-05-04 |
記事 |
新規 |
CNCFの認可は、「操作の入口」と「リソースへのアクセス」の二箇所で評価される。 ロール・パーミッション・リレーション・ABACはすべてCapabilityまたはGuardに正規化され、 最終的に一貫した判定モデルで評価される。 |
||
2026-04-27 |
記事 |
新規 |
SimpleModelingの知識処理モデルは、「意味 → 構造 → 定義 → 振る舞い → 実行 → 現実」という変換パイプラインとして構成されます。Contextはその全体を制御し、Effectの評価によって現実世界に作用が現れます。 |
||
2026-04-20 |
記事 |
新規 |
SimpleModeling Development Processは、Essence Kernelを共通基盤とし、Use Case Lite、Scrum Solo、Cloud Native CBD、BoK、Cozy Domain Modeling、Code Generation、DevOpsなどのPracticeを選択・合成して構成される。実行基盤としてはCNCFを位置づける。本稿では、Method View、Process Flow View、Work Product View、Role/Agent View、Automation View、Lifecycle Viewに分けて、その定義の雛形を示す。 |
||
2026-04-13 |
記事 |
新規 |
SimpleModelingは、文芸モデル・DSL・実行基盤を統合し、AIが直接扱える開発プロセスを実現する。本稿ではEssenceの考え方を踏まえつつ、BoK→Cozy→CNCF→SKILLの流れとして再構成された最小開発プロセスを示す。 |
||
2026-04-06 |
記事 |
新規 |
文芸モデルを、住所モデルの実例でざっくり体感するためのサンプル記事です。 文芸モデルそのものの説明は、what-is-literate-model.doxが参考になります。 |
||
2026-03-30 |
記事 |
新規 |
SimpleModelingは、BoK・文芸モデル・DSL・実行基盤を統合し、Harness Engineeringを「意味に基づいて実行を制御する基盤」へと拡張する。これにより、仕様と実装のズレを抑え、AI時代に求められる一貫した品質と再現性を実現する。 |
||
2026-03-23 |
記事 |
新規 |
1.5hop+は、固定された探索距離ではなく意味構造を基準に概念近傍を構成する知識グラフ探索手法です。CML/UMLメタモデルの構造を利用し、生成AIにとって十分な意味情報を提供することで、精度と効率を両立します。 |
||
2026-03-16 |
記事 |
新規 |
前回の記事では、AI時代の開発プロセスの枠組みとして、Unified Processをプロセスの骨格とし、Component-Based Developmentを開発の中心構造として据えるという整理を行いました。 UPは、反復・漸進 (Iterative & Incremental)、アーキテクチャ中心 (Architecture-Centric)、ユースケース駆動 (Use-Case Driven)という三つの基本原則によってソフトウェア開発プロセスを定義しています。 これらの原則はAI時代においても依然として有効です。 しかしAIによるコード生成が一般化した環境では、それぞれの原則の意味や役割は従来とは少し異なる形で理解する必要があります。 本稿では、Unified Process の三つの基本原則を手がかりに、AI時代における開発プロセスのあり方を改めて整理してみます。 |
||
2026-03-09 |
記事 |
新規 |
AI時代のソフトウェア開発では、コード生成能力よりもシステム構造の設計が重要になります。 本稿では、Unified Process (UP) をプロセスの骨格とし、Component-Based Development (CBD) を中心構造とするAI支援開発の基本的な枠組みを整理します。 |
||
2026-03-02 |
記事 |
新規 |
AIはソフトウェア開発を加速させる一方で、構造の不安定化という新たな課題をもたらしました。 本稿では、CBDがもともと持つ構造的長所に加え、AI時代において、生成精度を高める構造制約、不安定化を抑える境界と仕様、AIによって強化される再利用性という観点から、その現代的な価値を整理します。 CBDは単なる再利用技法ではなく、AIを前提とした開発を安定させる基盤技術として再評価されるべき存在です。 |
||
2026-02-23 |
記事 |
新規 |
本稿では、DSLと実行基盤の組み合わせによってCBDが実装可能な構造として成立することを論じます。 Cozyが分析モデルをDSLとして厳密に定義し、CNCFがその仕様を実行時に構造として保証することで、コンポーネントは単なる設計概念ではなく、登録・発見・接続可能な実体となります。 さらに、CQRSを軸としたクラウド前提アーキテクチャ、品質属性の外部化、非同期抽象化を統合することで、CBDはAI時代に適合した実行可能なアーキテクチャ単位として再定義されます。 |
||
2026-02-16 |
記事 |
新規 |
本稿では、これまで個別に扱ってきた開発プロセス、CBD、DSL、自動生成、実行基盤(CNCF)を一つの縦方向のスタックとして統合的に整理します。 SimpleModelingでは、BoKで整理された知識を文芸モデルへと反映し、その構造をDSLとして定義し、CNCFの実行基盤で保証するという一気通貫の構造を採用しています。 AIは各層において理解・整理・生成・検証を支援するだけでなく、それらを横断的に接続する媒介装置として機能します。 この縦方向の連続性が確立されたとき、自然言語世界と実装技術世界は分断されず、構造を保ったまま進化可能な開発スタックが成立します。 |
||
2026-02-09 |
記事 |
新規 |
本記事では、Unified Process（UP）を補助線として、AI時代におけるソフトウェア開発プロセスとプロジェクト管理の再構成について整理します。 特に、構想・推敲・作成・移行というフェーズ構造を通じて、AIの役割がどのように変化するのかを明らかにします。 |
||
2026-02-09 |
用語集 |
新規 |
推敲フェーズで確定したアーキテクチャ・ベースラインを前提として、イテレーションを回しながらシステムを物量的に実装していくフェーズ。AI時代においては、AIが主要な実装主体となり、与えられた構造と制約に従って大量のコードやテストを一貫した品質で生成する段階を指す。 |
||
2026-02-09 |
用語集 |
新規 |
作成されたソフトウェアを実運用へと移行し、ユーザへの提供や運用開始を行うフェーズ。AI時代においては、運用や利用から得られる知見を文脈情報として回収し、次の構想フェーズへ入力するための文脈更新フェーズとして位置づけられる。 |
||
2026-02-09 |
用語集 |
新規 |
構想フェーズで得られた要求や方針をもとに、分析・設計を進めながらシステムの骨格を固めるフェーズ。AI時代においては、曖昧さや矛盾を取り除き、文脈・境界・前提条件を磨き込み、AIが参照するアーキテクチャ・ベースラインを確定することが最重要となる。 |
||
2026-02-09 |
用語集 |
新規 |
プロジェクトの目的、扱う問題領域、スコープを定め、検証すべき価値や実現可能性を明らかにするフェーズ。AI時代においては、詳細な仕様を確定することよりも、AIと人間が共有すべき文脈の輪郭を定義することが中心的な役割となる。 |
||
2026-02-02 |
記事 |
新規 |
本記事では、Unified Process の特徴点を軸にアジャイル開発との比較を行い、生成AIの登場によって開発プロセスの前提がどのように変化しているのかを考察します。 AI時代においては、プログラムだけでなく、モデルや仕様書、設計文書といった自然言語の成果物が一次情報として扱われるようになります。 この前提のもとで、モデル中心に設計された Unified Process は、AIと協働する開発プロセスを考えるための有力な補助線となります。 |
||
2026-01-26 |
記事 |
新規 |
SimpleModelingはコンポーネント指向をベースとした開発方法論です。コンポーネント指向を成立させるためには、概念的なモデルの定義に加えてコンポーネントの実行系が必要です。この目的でクラウド・プラットフォーム上で動作するクラウド・アプリケーション用のコンポーネント・フレームワークとして開発しているのがCloud Native Component Frameworkです。 本記事ではHelloWorldを通して、Cloud Native Component Frameworkの実行モデルについて見ていきます。 |
||
2026-01-19 |
記事 |
新規 |
CNCF を理解する最短ルートは、まず実際に動かしてみることです。 command から始め、server、client、custom component へと進むことで、実行形態が変わっても内部の実行モデルが変わらないことを確認します。 |
||
2026-01-19 |
用語集 |
新規 |
Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。 |
||
2026-01-12 |
記事 |
新規 |
AI時代のソフトウェア開発では、仕様・設計・実装を分断せず、相互に行き来しながら育てていく開発スタイルが重要になります。 本記事では、動く仕様書（Executable Specification）を軸に、分析モデルのアップダウン、AIとのペア分析・ペア設計を含む SimpleModeling の実践的アプローチを整理します。 |
||
2026-01-12 |
用語集 |
新規 |
Verification(仕様確認)とは、規定された設計仕様や要求仕様に対して、実装が一致しているかを確認する行為である。 |
||
2026-01-12 |
用語集 |
新規 |
Test Driven Development(TDD, テスト駆動開発)とは、実装に先立ってテストを記述し、そのテストを通すことを起点として実装とリファクタリングを繰り返す開発手法である。 |
||
2026-01-12 |
用語集 |
新規 |
Behavior Driven Development(BDD, 振る舞い駆動開発)とは、システムの振る舞いをシナリオとして記述し、関係者間で共有可能な形で仕様を明確化する開発アプローチである。 |
||
2026-01-12 |
用語集 |
新規 |
Executable Specification(動く仕様書)とは、実行可能な形で記述され、実行することで仕様の正否や意味が確定する仕様表現である。 |
||
2026-01-12 |
用語集 |
新規 |
Validation(妥当性確認)とは、システムや機能が利用目的や要求仕様に対して妥当であるかを確認する行為である。 |
||
2026-01-05 |
記事 |
新規 |
ChatGPTとVSCode Codexを使い分けながら、仕様策定・設計・実装・検証を高速に回す「オレ流AI駆動開発」の現在地をまとめます。 |