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 starts with particular, inspectable cases and derives a model intended to hold beyond them. The cases may be a storyboard of named objects changing through a software scenario or sentences stating individual facts in a domain expert's language. The modeler identifies recurring kinds, relations, constraints or operations, expresses them as a general model, and checks whether that model still represents the cases from which it was drawn. This is a direction of construction and feedback, not a particular diagram notation.[1][2][3]
Story Driven Modeling (SDM) and Fully Communication Oriented Information Modeling (FCO-IM) exhibit this shared direction in unlike ways. SDM begins with sample use-case stories and object-structure snapshots, derives class structure, then specifies general operations with story diagrams. FCO-IM starts with concrete, verbalized fact expressions, classifies them into fact types and an information grammar, and supports reading back the expressions. The shared identity is not that their models are interchangeable: one addresses software object behavior, the other communication about an information domain.[1][2][3]
The label here is a synthesized family name. It does not imply that SDM or FCO-IM authors adopted a common branded method. Nor does an example collection prove that a derived rule covers every possible case. The point is to make the source-to-generalization mapping reviewable and to expose omissions when further examples challenge it.[1][2]
Structural Signature¶
Sig role-phrases: modeling target → represented particular cases → case-to-model abstraction → reusable general model → check-back against cases.
- Modeling target. There must be some domain or system for which more than a list of observations is needed. In SDM the target is a software system's object structure and behavior; in FCO-IM it is the information communicated about a universe of discourse. This target fixes what the model must preserve.[1][2]
- Represented particular cases. The starting cases have enough named detail for someone to inspect. SDM's sample scenarios show successive object snapshots; FCO-IM's fact expressions name students, projects and preferences. A generic class name supplied before any case is not performing this role.[1][2]
- Case-to-model abstraction. The modeler maps particulars to reusable kinds and rules. SDM groups objects with common properties into classes and derives general operations; FCO-IM sorts expressions into fact types and analyzes roles. This step must be reasoned, not equated with copying the case into a template.[1][2]
- General model. A class diagram, story diagram or information grammar speaks about situations beyond the original named cases. The model therefore makes commitments the cases alone did not make, and those commitments need further scrutiny.[1][2]
- Check-back. The derived structure is compared with its originating cases. SDM describes executable model validation and prototype inspection; FCO-IM permits fact expressions to be read back or regenerated from an information grammar. The check is method-specific and limited to what the selected cases exercise.[1][3][4]
The first four roles distinguish modeling from example collection. The fifth turns the examples into a continuing constraint on the model rather than a discarded prelude. Different methodologies may add other stages; these roles alone do not claim to reproduce their full procedures.
What It Is Not¶
It is not an example appended after an abstract model is already finished. An illustration may help teach a schema, but it did not supply the case-to-model derivation. Conversely, a pile of concrete cases without classifying, specifying or generalizing them is not yet a model.[1][2]
It is not Story Driven Modeling or FCO-IM under another name. Those are distinctive, historically located methods with different representations and further steps. SDM distinguishes sample storyboards from story diagrams specifying the general case; FCO-IM models communicated facts and their verbalizations, not merely any object diagram.[1][2]
It is not a guarantee of complete or correct induction. A model may reproduce all elicited examples while missing a constraint, an exception or a possible configuration that no one supplied. The examples support elicitation and checking, not universal proof.[1][2]
It is not automatically behavior-driven development. BDD can use examples as executable behavior specifications, but an example only falls under this entry when it also helps derive or revise a general model. The live BDD entry remains a narrower software-practice identity rather than an alias here.
Scope of Application¶
The pattern applies when modelers can obtain representative cases before deciding the full abstract vocabulary. In scenario-oriented software development, customer-recognizable stories can reveal objects, links and state changes. SDM formalizes this with storyboards, class diagrams and story diagrams for general behavior, and reports an application to Paderborn bus-route information software.[1]
In conceptual information modeling, the raw material may instead be communicated elementary facts. FCO-IM's school-project example begins with verbalizations such as a student's project preference. Grouping such expressions by type and analyzing their roles yields an information grammar, not yet necessarily a relational implementation schema.[2][3]
The method has an important limit when cases are scarce, atypical or disputed. A single storyboard need not expose every possible object-state transition, and a sample fact population need not settle every uniqueness or totality constraint. The modeler must seek counterexamples or ask further questions rather than silently treating the first cases as exhaustive.[1][2]
Clarity¶
“Example-first” names the order of modeling moves, not the order in which every finished artifact will be displayed. A published method may show the polished class diagram before its motivating story for exposition. To identify this abstraction, ask what evidence actually generated or challenged the model's kinds and rules.[1][2]
The difference between a particular and a generalization is explicit in both sources. A storyboard describes one sample evolution of objects; a story diagram specifies operations for a general case. “Peter Johnson prefers project P101” is one fact expression; a Preferences fact-type expression has roles that can accept other students, ranks and projects.[1][2]
The check-back also has two forms. SDM can validate behavior through an executable specification or prototype; FCO-IM can compare regenerated fact expressions with expert communication. Neither check means that every possible behavior or fact has been covered. It asks whether specified examples survived abstraction in the intended way.[1][3][4]
Manages Complexity¶
Starting from named cases postpones some of the vocabulary burden. A nontechnical participant may more readily spot a wrong trip scenario or school-project statement than critique an abstract class hierarchy or fact-type grammar. The examples thus provide a concrete surface for discussion while the modeler extracts reusable structure.[1][2]
The general model then compresses many possible cases into classes, roles or rules. Instead of documenting every bus-route object configuration separately, SDM defines classes and operations. Instead of writing a separate schema line for every student preference, FCO-IM expresses a reusable Preferences fact type. The gain is accompanied by a risk: compression can erase a distinction the expert meant to keep.[1][2]
Keeping cases available for check-back helps detect such erasure. But the savings are not free: eliciting more cases and maintaining them as the model changes costs review time. The modeler's task is to seek cases that challenge the current generalization, not merely accumulate many near-duplicates.
Abstract Reasoning¶
First identify the intended modeling target and ask for cases stated in its native terms. Are these actual or plausible instances that an expert can evaluate, and do they exhibit the behavior or facts the model is meant to account for? A generic “customer” symbol without a concrete transaction might be too thin to reveal missing relationships.[1][2]
Next mark each move from case to model. Which objects became classes, which predicates became fact types, which observed transitions became general operations, and which constraints were elicited separately rather than inferred from the sample? This trace makes it possible to challenge a generalization without denying the source example.[1][2]
Finally perform two tests: check that the general model can represent the initiating cases, and look for a new case that exposes whether it overgeneralized or omitted a condition. Passing the first test is necessary for faithful derivation, not sufficient for complete coverage. The distinction between a sample storyboard and a general story diagram makes this especially visible.[1][4]
Knowledge Transfer¶
The transfer from SDM to FCO-IM is a transfer of roles, not syntax. An SDM snapshot sequence and an FCO-IM fact expression are unlike artifacts, yet both can be expert-inspectable particulars from which a reusable structure is developed. Their check-back mechanisms likewise differ—prototype execution versus expression read-back—while preserving the common obligation to relate a general model to the supplied cases.[1][2][4]
The approach can inform adjacent modeling practices, but this entry does not automatically subsume all “specification by example” workflows. If cases are executable acceptance criteria without any derivation of general domain or behavior structure, the overlap may be pedagogical or procedural rather than the same modeling identity. One must show the case-to-model mapping.
The higher-order operation is live prime Abstraction: retaining purpose-relevant structure while dropping particular detail. Example-First Modeling adds a computer-science-specific construction cycle and check-back discipline. The prime supplies a proposed DAG prerequisite; it does not erase the domain-specific method.[1][2]
Examples¶
Paderborn bus-route storyboards¶
In their SDM report, Zündorf, Schürr and Winter develop a bus-route information system. Sample use-case stories are expressed as sequences of object-structure snapshots. Objects with shared properties and links inform a class diagram; further story diagrams express operations for the general case. The authors describe validation through executable specification and prototype inspection. A single journey is therefore a source and test of the model, not the whole route algorithm.[1]
Mapped back: modeling target = bus-route software; particular cases = sample trip and object snapshots; case-to-model abstraction = identifying classes, relations and operation patterns; general model = class plus story diagrams; check-back = exercising prototype behavior against the sample scenario.
School project preference facts¶
The FCO-IM author book uses concrete school-project communications, including “The first preference of student Peter Johnson is project P101.” Its information grammar analyzes that expression into a Preferences fact type with places for ordinal number, student and project. The named expression is a case; the fact-type expression is reusable for other students and projects. Reading back or regenerating fact expressions supplies a check that the grammar preserves the intended communication.[2][3][4]
Mapped back: modeling target = school-project information as communicated; particular cases = named student/project fact expressions; case-to-model abstraction = sorting facts into types and identifying roles; general model = FCO-IM information grammar; check-back = read-back or regeneration of the source expressions.
Boundary: a post-hoc illustration¶
Suppose a modeler fixes all classes and constraints first, then writes a named student example solely for a slide. The case may illustrate the result but did not produce or check its generalization. Without a case-led derivation or check-back, it is not enough to call the work example-first modeling.
Structural Tensions¶
T1 — Expert-legible particulars versus coverage of general behavior. A small number of named cases can be discussed and corrected readily, but they leave many situations untested. Adding cases improves chances of challenging the emerging rule, while increasing elicitation and maintenance cost; replacing cases with only a general rule improves compactness but weakens expert inspection. Diagnostic: Which plausible unseen case would most strongly challenge the current model, and can the stakeholder still judge that case's representation?[1][2]
T2 — Fidelity to source wording versus useful abstraction. Preserving the source fact expression or object detail makes the model easier to check against the originating case. Preserving every incidental feature, however, prevents useful generalization; discarding too much prevents a faithful read-back or explanation of the case. Diagnostic: Which detail must survive for the expert to recognize the original fact or scenario, and which detail is merely accidental to this one instance?[1][2][4]
Structural–Framed Character¶
Example-First Modeling is structural with a practice-framed entry point. Evaluative weight: the identity is a case-to-general-model sequence, not a claim that this process is always better than schema-first design. Human-practice dependence: people or tools select and inspect cases; expert judgment matters when deciding what a fact means and whether a read-back is faithful. Institutional origin: SDM and FCO-IM are named methods from particular research communities, but the shared structural pattern is recognized from their operations rather than granted by a professional label. Vocabulary travel: “example” can mean test, illustration or elicitation artifact; only an example used in derivation and check-back plays the role here. Import versus recognition: the family name imports no prescribed notation into either source; it recognizes a recurring modeling direction across different notations.[1][2]
Its character: a domain-specific case-to-model construction and check-back method, despite its portable abstraction skeleton. Its output is a formal or semi-formal model of software behavior or domain information, not just any learning from experience.
Structural Core vs. Domain Accent¶
The live prime Abstraction captures the broad move from richer particulars to a purpose-relevant representation; that operation is a proposed strict prerequisite here. The more portable pattern “begin with examples, infer a rule, then test it” might warrant a separate higher-order identity, but this is an unadmitted future-prime question rather than a hidden prime or a reason to expand this node beyond modeling.[1][2]
The domain accent is constitutive: cases must be represented in a way that can feed classes, fact types, constraints or general operations, and the result must be a model with a check-back path. SDM's object diagrams and executable story diagrams differ from FCO-IM's verbalized facts and information grammar; those distinctions prevent this entry from collapsing into vague “learn from examples” prose.[1][2][3]
Instantiates / Related Primes¶
This entry presupposes Abstraction. Case-to-model derivation requires abstracting reusable structure from particulars.
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.Both source methods begin with represented examples and derive types, relations or operations that apply beyond them. Such derivation requires the selection and retention of purpose-relevant structure described by live prime Abstraction. The edge asserts a structural prerequisite, not an is-a relation or a canonical change.
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
Not to Be Confused With¶
A storyboard is one source artifact, not the general story diagram that specifies operations. A fact expression is one instance-level utterance, not the fact type or information grammar abstracted from it. A domain model is a possible result, not necessarily evidence of an example-first process. An acceptance test may check software behavior without having helped construct a general model. A post-hoc example may explain a design without constraining it. Finally, successful reproduction of the initial cases is not proof that every future case has been modeled correctly.[1][2][4]
References¶
[1] Albert Zündorf, Andy Schürr and Andreas J. Winter, “Story Driven Modeling” (1999), §§1–2 (Story Boarding, Deriving the Static Class Structure, Deriving Dynamic Operations, Validating the Model), §3 (Paderborn BusRoute case), §4. Original author report. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z ↩27 ↩28 ↩29 ↩30
[2] Guido Bakema, Jan Pieter Zwart and Harm van der Lek, Fully Communication Oriented Information Modeling (2002), Chapter 2 “Modeling the Communication,” §§2.3, 2.5, pp. 22, 41–42 (Peter Johnson/project P101 expressions and Preferences fact type). Original author book. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z ↩27
[3] Jan Pieter Zwart, Marco Engelbart and Stijn Hoppenbrouwers, Fact Oriented Modeling with FCO-IM, §§1.3, 3.1–3.5 (collecting concrete facts, verbalizing, sorting, reading back). Publisher's author-book description and detailed contents. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g
[4] Fazat Nur Azizah and colleagues, “Measurement of the Quality of an FCO-IM Conceptual Data Model,” §2 and Figure 3 (regeneration of sample expressions from the information grammar). Original methods paper. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g