Example-First Modeling¶
Deriving a reusable conceptual or behavior model from concrete cases and checking the result against those cases.
Core Idea¶
Example-first modeling derives a reusable conceptual or behavior model from particular cases. A scenario with named objects or a sentence expressing one concrete fact gives an expert something inspectable; the modeler then extracts classes, fact types or general operations and checks whether the resulting model still accounts for the original case. The label is a synthesis across methods, not the historical name of a single school.[ref-51fc01947127][ref-d19bca1d3f71]
The direction matters. An example added after a schema is finished may illustrate it, but did not guide the abstraction. Conversely, a case list without reusable model content has not completed the modeling move. The initiating examples constrain the model, yet reproducing a finite sample cannot prove coverage of every future case.[ref-51fc01947127][ref-d19bca1d3f71]
Scope of Application¶
In Story Driven Modeling, a sample use-case scenario is pictured as successive object-structure snapshots. The method derives static class structure and then general operations expressed by story diagrams, which are distinct from sample storyboards. The original authors' Paderborn bus-route case shows this path and describes validation through executable specification and prototype behavior.[^ref-51fc01947127]
In FCO-IM, the starting artifacts are elementary facts communicated by domain experts. The school-project case includes “The first preference of student Peter Johnson is project P101.” Sorting and analyzing such statements yields a Preferences fact type and information grammar with roles for a rank, student and project. The grammar can be read back or used to regenerate example expressions for checking.[ref-d19bca1d3f71][ref-ff030e1538cd][^ref-92c13b05ac69]
These are unlike modeling targets—software object behavior versus communicated information. Both instantiate the same case-to-general-model-to-check-back structure, without implying that their diagrams or validation procedures are interchangeable.
Clarity¶
A storyboard records a particular sample evolution, while a story diagram specifies behavior for the general case. A named student preference is one fact expression, while a fact type accepts other values in the same roles. Confusing each pair makes one example look like a complete model.[ref-51fc01947127][ref-d19bca1d3f71]
This entry is not an alias for the live Domain Model, Data Model or Behavior-Driven Development entries. The first two can be outputs of modeling; BDD is a narrower practice of behavior examples and executable specifications. The identity here is the derivation of general model content from cases with a check-back obligation.
Manages Complexity¶
Concrete cases are often easier for participants to inspect than an abstract diagram. Generalizing them then avoids writing every possible situation separately: classes and operations represent many object configurations; a fact type represents many student-project preferences. The danger is that simplification may discard a distinction the case was meant to preserve.[ref-51fc01947127][ref-d19bca1d3f71]
Checking the model against the cases can expose that loss, but more example coverage requires elicitation and maintenance effort. A strong next case is one that might break the current rule, not merely another copy of a familiar one.
Abstract Reasoning¶
Identify the modeling target and the concrete cases first. Trace which details become classes, roles, constraints or general operations and which are deliberately omitted. Then check whether the model can represent the initiating cases and seek a new case that challenges its apparent scope. Passing the first check is not a completeness proof.[ref-51fc01947127][ref-92c13b05ac69]
For a proposed instance, ask: Did the case actually contribute to the model, or was it added only for explanation? Is there a reusable output beyond the named case? Can the expert still recognize the original meaning in the generalized representation?
Knowledge Transfer¶
The transferable roles are particular case, abstraction into reusable model, and check-back, not a common syntax. SDM uses object snapshots and executable story diagrams; FCO-IM uses verbalized facts and an information grammar. Live prime Abstraction is a proposed DAG prerequisite because case-to-model derivation retains purpose-relevant structure while dropping incidental detail.[ref-51fc01947127][ref-d19bca1d3f71]
The broader skeleton “start with examples, infer a rule and test it” is an unadmitted future-prime question. This node remains domain-specific because its output is a conceptual or behavior model with traceable cases, not just any learning from experience.
[^ref-51fc01947127]: Albert Zündorf, Andy Schürr and Andreas J. Winter, “Story Driven Modeling” (1999), §§1–3 and §4. Original author report. [^ref-d19bca1d3f71]: Guido Bakema, Jan Pieter Zwart and Harm van der Lek, Fully Communication Oriented Information Modeling (2002), Chapter 2, §§2.3, 2.5, pp. 22, 41–42. Original author book. [^ref-ff030e1538cd]: Jan Pieter Zwart, Marco Engelbart and Stijn Hoppenbrouwers, Fact Oriented Modeling with FCO-IM, §§3.1–3.5. Publisher's author-book description and detailed contents. [^ref-92c13b05ac69]: Fazat Nur Azizah and colleagues, “Measurement of the Quality of an FCO-IM Conceptual Data Model,” §2 and Figure 3. Original methods paper.
Relationships to Other Abstractions¶
Current abstraction Example-First Modeling Domain-specific
Parents (1) — more general patterns this builds on
-
Example-First Modeling presupposes Abstraction Prime
Case-to-model derivation requires abstracting reusable structure from particulars.
Hierarchy path (1) — routes to 1 parentless root
- Example-First Modeling → Abstraction
Neighborhood in Abstraction Space¶
Example-First Modeling sits in a sparse region of the domain-specific corpus (76th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Codes, Matrices & Combinatorial Problems (30 abstractions)
Nearest neighbors
- Formal Model — 0.84
- Data Model — 0.83
- Machine-Learning Model — 0.83
- Metadata modeling — 0.83
- Context model — 0.82
Computed from structural-signature embeddings · 2026-10-08