Fact-Based Modeling

[gitmikebrown]

Hello,
I took a class at ASU (IFT530). In that class, we had to work out of VS using NORMA. Having done several ER types of work in other courses, I fell in love with NORMA or ORM2 (however it is referred to). I did some research and found something similar, Boston Factengine. Does anyone have any thoughts or opinions about using Factengine? NORMA does a lot, but the Factengine seems like the NORMA program on steroids. Keep in mind I am new to all this.

[mcurland]

Hi Mike,

Thank you for taking an interest in NORMA and ORM. I'm glad you enjoyed the class.

This seems like a discussion of the NY Yankees on a Red Sox board, but I'll at least get my toes wet, even though I really don't want to turn this git discussion into a long product comparison.

The FactEngine product certainly has some features, especially the live FactEngine back end, that NORMA does not. It is also a cloud-based tool and comes with significant costs.

Much of the ORM Solutions work is not on core NORMA and currently has limited distribution. While FactEngine focuses on a cloud hosted (or self-hosted for $$$) data back end, the work I'm doing (not yet in broad release, but feel free to talk to me private) is targeted at more of a full stack application generated from the model. This includes client-side model representation, data transport, generated write of arbitrarily complex model changes to the generated database, standalone client processing of the model elements, client-side model validation, etc. I'm moving rapidly towards this goal (and you can see some pieces on the @ ormsolutions channel on youtube), but am admittedly not to the point of the slick packaging which Victor has in his FactEngine project.

[Huge tangent on ORM, feel free to skip]
I think one main issue that ORM has had over the years is that it is much too database centric. In some ways, the community (and promoters) got stuck on the awesome 5NF databases it is able to produce. There are two problems with this. First, the database code is a small percentage of an application (generally well under 5% in my experience). Second, if you generate the rest of the application off the database then you lose the much more subtle meanings that are represented in the model. Basically, I think if the user can speak model instead of schema then they don't really care what the schema is--as long as the data can be retrieved. Hence, model-centric development needs to replace database-centric development, to the point where how the data is stored becomes more of an afterthought. However, this requires tooling, frameworks and protocols to make models top-level development artifacts that are effectively executable.

There is another school of thought that producing the perfect database (meaning one that fully implements the ORM model) will solve all of the worlds ills. The problem with this approach is that ORM constraints apply to a fully populated model, but can make it incredibly difficult to get to the fully populated stage if fully enforce. For example, given a model with object type A (with a generated id) and two xor subtypes B and C (absorbed into the A table) with a mandatory functional reference from C to B (this is not a complicated model), you are already in a situation where populating A is extremely difficult. Why? You need to get a row in the database to get a generated id you can reference, but a row-level-enforced exclusion constraint on the subtype partition (and all check clauses are row-level, even in a db that supports deferred constraints) means that you can't get an id for an A without knowing its subtype (even though the subtype pattern is satisfied by the end of the transaction). This is crazy complicated by hand, not to mention with an automatically generated imported. Basically, the complexities of enforcing all constraints mean either tons of end-of-transaction triggers (which will not make your db faster) or a db that is almost impossible to populate. This kind of defeats the purpose: the database is there to say 'yes, you can easily store your data in a performant fashion', not 'no', especially before the transaction commits.
[End of huge tangent]

As for the core modeling experience, much of Boston seems to be a direct pull from NORMA. For example, the verbalization specs were published by Dr. Halpin (Terry), but things like verbalization colors are not part of that spec and are clearly pulled by Boston directly from the NORMA tool. NORMA, however (and IMO), has a much cleaner rendering of the ORM elements as published by Terry's specifications than Boston does. There are also some philosophical differences on rule entry. The NORMA rules (formal rule editors are in the Pro version of NORMA) are based on model navigation, not language parsing. This gives a much stronger feedback loop than you will see in a text-based rule system. If you enter the rule in and it verbalizes something that you did not intend then you immediately know if there is an issue. This feedback loop is very important as rules become more complex.

You'll see more movement from NORMA in the next year or so. I went a full five years with an external (not tooling-related) position, and just finished another 5 as a single dad with full custody of 2 very young ones. Basically, August (and onwards) was the first time in a decade that I have been able to devote regular daylight work hours to NORMA and related products and frameworks. You won't see all of the work in the open source tool, but other parts will gradually be publicized and productized.

[Note: I really don't want to turn this into a back-and-forth on NORMA vs Boston features. I honestly don't know enough about the other tool for a deep dive, and I think discussion here should be on the NORMA tool and implementation.]

[crowded-libs]

Agreed regarding NORMA verbalizations and amazing results with AI. I've been testing it out with claude code and getting really good results for DB, code, etc. and it does a great job of dealing with some of the more complex expressions.

[CoreyKaylor]

Haha, forgot to change from my libs account. @mcurland that was me BTW. AI would have been real useful in writing XSLT back in the day. 😉

[mcurland]

AI would have been real useful in writing XSLT back in the day.
I would like to say I would have AI-proofed the tests, but that is getting harder and harder to do. I think getting caught with AI assists on a test should put a student back to the stone age: closed laptop, no phone, pencil and paper. You're reminding me of the good old days when I could turn everyone around for a test and monitor their screens from the front of the room. I miss young eyes.

Seriously, though, I would like to know in more detail how you're using the output with the goal of potentially improving it. As I said on the other thread, I have a plain text verbalizer engine now (except for the button to call it), so it should be easier to get input that AI would like, including using indentation as context. I have full verbalization (and SVG diagrams) generating for a Word report in the NORMA Pro stack, but you're still looking at transferring it to a conversation. Possibly looking at organized outputs that could be fed into a UI conversation would be fairly straightforward. It is certainly lower hanging fruit than getting an LLM to read the ORM inputs.

[CoreyKaylor]

Indentation and grouping helps, but in general it's able to pick up just from consistent naming throughout and the unambiguous way verbalizations work. I've used it to take the verbalization report to organize and format into markdown. To group entitles similar to how Terry would represent his tables in left to right to maximize vertical space. Similar to how you conceptually think of constructors but with underlines, etc. This is just preference though. The real value is what it's able to understand about the domain you're trying to accomplish, iterate on new ideas, show you where your ideas are naive to support various use-cases, etc. After you've collaborated back and forth a few times, AI is great to then run with your changes to generate domain models, service classes, architectural details of your design that go way beyond just data / constraints. For example, I have a mobile application that uses Jetpack Compose and uses a custom redux-like framework I built called "duks" all in Kotlin Multiplatform Mobile. It's able to implement the patterns following that guideline to implement models, actions, reducers, async-actions, service implementations, stubs for all sample data, database tables, table data seeds, UI code, etc. All at a cost on average depending on complexity of around $25-$50 dollars for a very large % of the project to get done. It's all about how you plan and execute with guardrails in the context with AI. Sure, it gets some things wrong but it's easy if you're pairing that with disciplined source control.

If asking me where Norma and AI meet. I'll just list out a few wish list / ideals in my experience using Norma.

• Tie to Visual Studio IMO is a bit of a drag
• Textual DSL for everything you can do with the visual diagram would be AWESOME for productivity
• This textual DSL could very easily tie in to how you collaborate with AI. It would be very easy for it to learn and understand the DSL syntax.
• The diagrams are still very useful, but IMO they should be rendered similar to how mermaid diagrams are, directly from the text dsl.
• This DSL through docs and hints in the specification can give AI very strong context on how to handle the domain.
• The DSL can be extended to model behavior and events in the domain related to entities. As it stands now, ORM is great to understand the domain, but IMO it falls short on how the domain data is constructed and almost encourages a procedural mindset. By extending the domain to include behavior and triggers for when the domain relationships get created, it would be more powerful and encourage better application design. Again, all my opinion, but it's not a new criticism of where ORM falls short either.
• This also makes the overall ORM solution more version control friendly and something you can easily grok from one diff to the next.

Happy to discuss further or with more examples if it would be helpful. Also, it's worth mentioning that NORMA and ORM in general has been a valuable tool my entire career. I break it out when I'm new to a company or starting on something fresh, if only to simply understand the business better. It makes you significantly more prepared to change what you understand deeply. Thanks for all the years of support.

If you're curious about what setup I'm using. At the moment most of my AI work is done in Visual Studio Code with the RooCode extension. I have an openrouter account with the API key added as part of the setup in Roo. This setup allows you to try out new AI models as they come, or even leverage free ones in some cases. I would suggest you to try it out on a project, maybe even Norma to see where the potential lies. I think you'll be surprised at what it can do with the right instructions and expertise driving the conversation. There are many tools and processes emerging, but IMO this one is the best for flexibility and integrated project experience so far. It's quickly changing every week though.

[mcurland]

Sounds great. I'm always fascinated by how NORMA is used, and the amount of custom tooling being done outside the system.

I'll try to address the bullet points, but I think to really appreciate what you're doing (and how I could help) might work best over Zoom where we can demonstrate and drill down.

Response Summary
There is a lot that I agree with here. AI tools are here to stay, and getting better ways to interact with them can only be beneficial in increasing the value of ORM. I think the main question is whether a textual DSL language targeted to AI is more useful as an input to the tool, or as an output that is intended to be fed into something else. The version control is a bit of a drag once you get into the elements that have fully regenerated ids (relational model, various bridge models) or graphical layout (coordinates, sizes, etc.), but is not as bad when looking at just the core ORM model. However, having a way to compare models in their native presentation (diagrams, properties, verbalization, etc.) would be the preferred approach and be more accessible to a broader audience of modelers (as opposed to coders who use modelling to code).

The plain text verbalization button has been added at https://ormsolutions.com/tools/verbalize, so you can play with that. Options (remove fact type lists, standardize name display, etc.) are also available. (Color and font options are lower priority, I haven't tackled that). Note that this verbalization engine is much more flexible than the one in NORMA. Plain text requires a much different approach for indentation and line management (the html indentation uses CSS), and this is abstracted out in the new system, so other text targets would be much easier to add. It would certainly be easier to extend this tooling to directly produce desired outputs than trying to parse/repurpose other output.

I also would like to see a balance between the AI approach and using AI to quickly learn 'best practice' patterns for different targets. Being able to replicate these patterns deterministically and repeatedly from the model without the AI is preferable, especially for change management as the project gets bigger and starts experiencing feature changes. I mean, the backend for the ORM Viewer (to read/write ORM models on the backend database, not currently posted publicly, handling 72 tables for size reference) has about 10,000 lines of generated relational mapping object model and 22,000 lines to handle imported state changes and exporting json-specified hierarchical queries. Using AI to do the relational data migration would be really useful. The only hand code is in the routing methods, which provides the query json and a single 'write' method that forwards any state change to the generated code. While I'm sure AI could provide suggestions to improve these outputs (especially since they originally target language features from a decade ago), I would then incorporate the suggestions into the generator, not necessarily rely on it directly to reproduce the next iteration of the code from scratch (I personally do not want to check diffs across 32K lines of code).

Response to Bullet Points

Tie to Visual Studio IMO is a bit of a drag

I'm not disagreeing on this, especially the 'exclusively VS' part of it. It is feeling long-in-the-tooth. The original VS decision (2005 timeframe) came down to the DSL toolkit supporting deleting notifications, not just delete. The feature wasn't available in other platforms at the time (notably Eclipse with EMF). Delete closures being available before items were removed from the model enabled incremental validation. Otherwise, any delete would have forced a full reevaluation of the model state, which was simply unacceptable performance wise. We looked at browser-based tech as well, but the platforms simply weren't up to it at the time from multiple perspectives (graphics rendering was weak (VML at best, SVG and even canvas was years away, things like 'use a web page as a server for a different tab' were unimaginable, the browsers didn't scale, debugging was miserable, etc., etc.). Most of these restrictions are not true now. The browsers are highly capable, but the VS frameworks haven't really progressed. BTW, if you want to poke around the model, add 'ormViewer.view' to Chrome's watch window. You'll see a minified object with 'modelSpace' and 'elements' that will show you the model types (the modelSpace part) and actual loaded model. Types are minified, so expand the prototypes under elements to see jfeModel and jfeType properties. This gives you some idea of how this is being loaded. Also, look at the 'jfe' global in the debugger for the framework and extensions. Other parts (like the verbalization) are hiding behind typescript and angular so will be harder to find.

You can see in the orm/verbalize page a very fast model load (and it is much faster from a database instead of the XML), high fidelity SVG graphics, etc. The library I'm using (my own JavaScript Fact Engine, aka JFE) handles any model, but was basically designed as a platform to reimplement the ORM tool. It is a much stronger framework than DSL--things like delete closure aren't even an issue because I have full state change representations showed both before/after states, so can consider the entirety of a change instead of an atomic modification like with DSL. I have basic gestures running in an 'editable' version of the posted tool (moving shapes, adding constraints, undo/redo, etc.), but there are no supporting tool windows, and no live model validation.

The challenge of moving off (or at least complementing) VS is that the codebase for the editor is far from trivial. Each of the tool windows needs to be rewritten, but there are also hundreds of complex validation rules with non-trivial sequencing interactions that need to be redefined. The issue is beyond just rewriting: the complexity has really reached a point where adding new rules is really hard, so I need the rules to be fully declarative with a compiler to not only produce but also sequence individual rules but also what I call rule frames (finish all of ORM, then do Relational on top of if, etc.). Some other issues in VS are that cross-model code generation is not readily supported, control of when the generators run (a performance issue), and that I'm hitting absolute limits of what the XSLT code generators can do (I hope you never have to experience 'stylesheet too complex' errors when you add one xsl:variable tag to a .NET stylesheet).

Importation of the formal derivation rules, dynamic rules and join paths into the browser system was a significant part of the verbalization work, but was also necessary to start automatically mapping these to the JFE rules engine. With this data in place I'll be able to add rules (in an ORM model describing ORM) that will be auto-generated and enforced on the tool. The primary focus for the next 6-12 months will be model execution (of any model, not just ones for the ORM tool models), including constraints and and rules. Of course, there is metadata beyond NORMA that is needed to implement constraints because it isn't obvious what action should be taken. For example, on an exclusion constraint when conflicting data is added, do you: throw, remove the conflicting facts, or allow the data to be entered but create an error state? There are subvariants of these as well (for example, remove conflicts automatically unless two conflicting states are asserted in the same transaction, then throw). Basically, constraints can be treated as directives to repair data, not just block it.

So, back to VS vs. other: other platforms are front-and-center work items for development of model execution. These will import/update from NORMA files. An executable model also provides a path to get the NORMA validation rules running declaratively on any supported platform. At this point I would be able to turn back to fully implementing an editor on the web viewer, but I need to prioritize the model execution first (and treat it as a prerequisite). For now, the editing will be in NORMA and other JavaScript-based targets (browser, VSCode, etc.) will be used for execution and to add sophistication to the code generators (cross-model interactions, etc.). I'll have incremental update support though, so changes can be propagated.

Textual DSL for everything you can do with the visual diagram would be AWESOME for productivity

I'd have to hear more on why this is more productive, unless you're considering git-style change tracking. First off, the visual diagram is really only a view on the model. It is not the model itself. There is also additional meta information associated with the individual shapes that is unique to that shape, not the underlying model, and there is additional meta data on the underlying model that is not displayed in the shapes.

I'm not disagreeing that a textual representation (beyond the verbalization) might be useful to produce, but I think with extensions (relational, hierarchical, JFE mappings, custom properties, code generation hints, etc. that are not in the core model) and the inherent complexities in the system it gets messier than might be desirable.

I'm not trying to defend the NORMA XML as optimal to read outside the tool. That was never the goal. The goal was to make a general format that could be used by any extension using a standard loader engine. There are only a handful of patterns (containers with no ids, elements with an id attribute, elements with a ref attribute, elements with both id and ref attributes). Other folks reading the file were supposed to use the object model. This isn't necessarily how history has played out, with plenty of folks trying to read the XML directly without the NORMA loader. This has also hindered my ability to change the XML.

This textual DSL could very easily tie in to how you collaborate with AI. It would be very easy for it to learn and understand the DSL syntax.

I think there are two issues here: First, does the AI read a DSL better than a populated metamodel. Second, is this an input or an output issue? DSL is great if it is correctly entered, but miserable if not. A major benefit of the current structure is that partial states are readily saved (with validation errors attached, of course). This is typically much harder to do when conforming to a syntax instead of a meta model. That said, I am not opposed to being able to produce this description of the model and even import it. I have, however, worked in similar systems before and usually found that it is a lot easier to look at a diagram instead of trying to visualize what a textual representation of that diagram looks like. Trying to produce an ORM model and diagram using text seriously alters the experience--and not in a good way, IMO.

One project for the web tooling (bumped by the verbalization, so it wasn't far down on the list) is to put together a diff display to compare two models. I already have StateChange objects ubiquitous in the framework (undo/redo stack is a bunch of StateChanges, StateChange JSON is sent to the generated back end to import through the generate relational mapping layer into the generated database, etc.) I also have a helper to automatically produce proxy object models: input a FactBase (current state), StateChange (modifications), and one or more starting objects to get a proxied object to navigate the object model reflecting the changes. All of the existing code (diagram rendering, verbalization, etc.) can now be use to look at the modified model state. Although I haven't done it yet, this is a much more user-friendly way of showing model changes that looking at a text diff that says "17.3 changed to 16.2"

The diagrams are still very useful, but IMO they should be rendered similar to how mermaid diagrams are, directly from the text dsl.

Similar comments as before. Looking at any textual structure that represents a graphical view is much hard than just looking at the view. The majority of data in an ORM diagram is also not in the diagram, it is in the underlying model. A FactTypeShape is not a FactType, so now you're also in the business of textually referencing a FactType from a FactTypeShape (which may have a partially populated meta model, so the identifier is the only reliable way to reference it).

Again, this isn't a hard 'this is not useful'. I think it is useful in some situations, but I think the populated metamodel (in XML, JSON, etc.) is probably more widely useful.

(Skipping a couple)

The DSL can be extended to model behavior and events in the domain related to entities. As it stands now, ORM is great to understand the domain, but IMO it falls short on how the domain data is constructed and almost encourages a procedural mindset. By extending the domain to include behavior and triggers for when the domain relationships get created, it would be more powerful and encourage better application design. Again, all my opinion, but it's not a new criticism of where ORM falls short either.

Without the NORMA Pro derivation rule editors you don't see much of this, but formal derivation rules and dynamic rules (dealing with adding and removing facts and objects in response to other model changes) is part of the expanded system. These are entered by navigating through the model (plus some markup), but are verbalized back in text, giving a strong feedback loop. An FBM (fact-based modeling) standards working group that was active a while (like a decade) ago also specified 'event fact types' that could be watched and formally trigger other dynamic rules. I believe the primary difference is that these were never preserved beyond the end of transaction. These could be used pick up things like time ticks and other external triggers.

This also makes the overall ORM solution more version control friendly and something you can easily grok from one diff to the next.

It would certainly be easier to text-diff for git. However, this also assumes the user is familiar with both git and the DSL. This is true for developers using ORM, but there are a lot of modelers in our community who are not hard core coders like we are. Being able to see the before/after state in side-by-side with full context (verbalization, rendered graphic, etc.) is even better. With the plain-text verbalizer we can even use a standard text diff engine to highlight differences (show the normal before/after verbalization, plus the highlighted text diffs).

[CoreyKaylor]

Out of curiosity, I had AI come up with a hypothetical DSL for ORM. Here's what it came up with. Obviously, it would require some tweaking, but it's not awful.

Object-Role Modeling DSL

Introduction

This document defines a textual Domain-Specific Language (DSL) for Object-Role Modeling (ORM). ORM is a fact-oriented modeling approach that focuses on modeling the domain in terms of objects playing roles in relationships, with constraints applied to those roles and relationships. This DSL provides a terse yet comprehensive way to express ORM concepts and constraints.

Unlike traditional entity-relationship modeling, ORM focuses on facts and the constraints on those facts. This makes it particularly well-suited for capturing complex business rules and constraints in a domain model. The DSL defined here aims to provide a textual representation that is both human-readable and precise enough to be potentially machine-processable.

Basic Syntax

Entity Types

EntityType: Name

Fact Types (Relationships)

Binary fact type:

EntityType1 Predicate EntityType2

Ternary or higher fact type:

FactType: EntityType1, EntityType2, EntityType3 [, ...]

Value Types

ValueType: Name [: DataType]

Constraints

Mandatory Role Constraint

Specifies that an entity must play a particular role:

EntityType1 must Predicate EntityType2

Uniqueness Constraint

Specifies that a relationship is unique in one direction:

EntityType1 uniquely Predicate EntityType2

Combined mandatory and uniqueness (exactly one):

EntityType1 exactly-1 Predicate EntityType2

Natural Verbalization

The DSL supports natural verbalization of constraints to make them more readable:

Combined Uniqueness and Mandatory Role

EntityType1 has exactly-1 unique ValueType

This is equivalent to:

EntityType1 has ValueType
EntityType1 exactly-1 has ValueType
ValueType uniquely identifies EntityType1

Bidirectional Predicates

Predicates can be expressed from both sides of a relationship using a slash:

EntityType1 owns / is owned by EntityType2

This defines the relationship from both perspectives, with the first verbalization favoring the entity on the left, and the second verbalization favoring the entity on the right.

Value Constraint

Restricts the allowed values for a value type:

ValueType values {value1, value2, ...}

Or using a range or condition:

ValueType values {x | condition}

Subset Constraint

Specifies that one relationship is a subset of another:

(EntityType1 Predicate1 EntityType2) ⊆ (EntityType1 Predicate2 EntityType3)

Equality Constraint

Specifies that two relationships must have the same population:

(EntityType1 Predicate1 EntityType2) = (EntityType1 Predicate2 EntityType3)

Exclusion Constraint

Specifies that two relationships must not overlap:

(EntityType1 Predicate1 EntityType2) ⊕ (EntityType1 Predicate2 EntityType3)

Ring Constraints

Constraints on relationships where the same entity type plays both roles:

EntityType1 Predicate EntityType1 [irreflexive|asymmetric|intransitive|acyclic|symmetric|transitive]

Frequency Constraint

Specifies the allowed number of instances:

EntityType1 Predicate EntityType2 [min..max]

Shorthand notations:

EntityType1 at-least-n Predicate EntityType2  # min..∞
EntityType1 at-most-n Predicate EntityType2   # 0..max
EntityType1 exactly-n Predicate EntityType2   # n..n
EntityType1 may Predicate EntityType2         # 0..∞

Subtyping

Specifies that one entity type is a subtype of another:

EntityType1 isa EntityType2

External Uniqueness Constraint

Specifies that a combination of roles from different relationships uniquely identifies an entity:

unique(EntityType1(role1), EntityType2(role2))

Derived Fact Types

Specifies that a fact type can be derived from other fact types:

EntityType1 derivedPredicate EntityType2 :- 
  EntityType1 Predicate1 EntityType3 and 
  EntityType3 Predicate2 EntityType2

Examples

Example 1: Basic Constraints

# Entity and Value Types
EntityType: Person
ValueType: Gender : String
ValueType: Age : Integer

# Fact Types with Constraints
Person has Gender
Person must have exactly-1 Gender
Gender values {"Male", "Female", "Non-binary", "Other"}

Person has Age
Person must have exactly-1 Age
Age values {x | x >= 0 && x <= 120}

Example 2: Relationships and Constraints

# Entity Types
EntityType: Student
EntityType: Course
EntityType: Professor

# Fact Types with Constraints
Student enrolledIn Course
Student must enrolledIn at-least-1 Course
Course must have at-least-1 Student

Professor teaches / is taught by Course
Course exactly-1 is taught by Professor
Professor may teach many Course

# Subset Constraint
(Student assistsIn Course) ⊆ (Student enrolledIn Course)

Example 3: Ring Constraints and Derived Facts

# Entity Types
EntityType: Person
EntityType: Project

# Ring Fact Types with Constraints
Person parentOf Person [irreflexive, asymmetric, acyclic]
Person friendOf Person [irreflexive, symmetric]
Person managerOf Person [irreflexive, asymmetric, acyclic]
Person mentorOf Person [irreflexive, asymmetric, acyclic]

# Derived Fact Types
Person ancestorOf Person :- 
  Person parentOf Person or
  (Person parentOf Person2 and Person2 ancestorOf Person)

Person colleagueOf Person :- 
  Person worksOn / is worked on by Project and
  Person2 worksOn / is worked on by Project and
  Person != Person2

# Subset Constraint
(Person mentorOf Person2) ⊆ (Person colleagueOf Person2)

# External Uniqueness
Person worksOn / is worked on by Project
Person hasRole RoleType on Project
unique(Person(worksOn / is worked on by), Project, RoleType)

Complete Example: University Academic System

# Entity Types
EntityType: Person
EntityType: Student
EntityType: UndergraduateStudent
EntityType: GraduateStudent
EntityType: Faculty
EntityType: Professor
EntityType: AssistantProfessor
EntityType: AssociateProfessor
EntityType: Staff
EntityType: Department
EntityType: Course
EntityType: Section
EntityType: Program
EntityType: Degree
EntityType: Enrollment
EntityType: Assignment
EntityType: Submission
EntityType: Grade
EntityType: Transcript
EntityType: Classroom
EntityType: Building
EntityType: ResearchProject
EntityType: Publication
EntityType: Committee
EntityType: Event
EntityType: Scholarship
EntityType: FinancialAid

# Value Types
ValueType: UUID
ValueType: Email : String
ValueType: EnrollmentStatus : String
ValueType: CourseLevel : String
ValueType: GradeValue : String
ValueType: DegreeType : String
ValueType: Gender : String
ValueType: AcademicRank : String
ValueType: SemesterTerm : String
ValueType: PaymentStatus : String

# Subtyping
Student isa Person
UndergraduateStudent isa Student
GraduateStudent isa Student
Faculty isa Person
Professor isa Faculty
AssistantProfessor isa Professor
AssociateProfessor isa Professor
Staff isa Person

# Person & User Management
Person has exactly-1 unique Email

Person has FirstName
Person exactly-1 has FirstName

Person has LastName
Person exactly-1 has LastName

Person has BirthDate
Person exactly-1 has BirthDate

Person has Gender
Person exactly-1 has Gender
Gender values {"MALE", "FEMALE", "NON_BINARY", "OTHER", "PREFER_NOT_TO_SAY"}

Person has Address
Person exactly-1 has Address

# Student Information
Student has exactly-1 unique StudentID

Student has EnrollmentStatus
Student exactly-1 has EnrollmentStatus
EnrollmentStatus values {"ACTIVE", "GRADUATED", "ON_LEAVE", "WITHDRAWN", "SUSPENDED"}

Student has AdmissionDate
Student exactly-1 has AdmissionDate

Student enrolledIn / has enrolled Program
Student at-least-1 enrolledIn Program
Program may have many enrolled Student

Student has Transcript
Student exactly-1 has Transcript
Transcript exactly-1 belongsTo Student

# Faculty Information
Faculty has exactly-1 unique FacultyID

Faculty has AcademicRank
Faculty exactly-1 has AcademicRank
AcademicRank values {"LECTURER", "ASSISTANT_PROFESSOR", "ASSOCIATE_PROFESSOR", "FULL_PROFESSOR", "EMERITUS"}

Faculty has HireDate
Faculty exactly-1 has HireDate

Faculty belongsTo Department
Faculty exactly-1 belongsTo Department
Department may have many Faculty

Faculty supervises GraduateStudent
GraduateStudent exactly-1 supervisedBy Faculty
Faculty may supervise many GraduateStudent

# Course Management
Course has exactly-1 unique CourseCode

Course has Title
Course exactly-1 has Title

Course has Description
Course exactly-1 has Description

Course has Credits
Course exactly-1 has Credits

Course has CourseLevel
Course exactly-1 has CourseLevel
CourseLevel values {"INTRODUCTORY", "INTERMEDIATE", "ADVANCED", "GRADUATE"}

Course offeredBy Department
Course exactly-1 offeredBy Department
Department may offer many Course

Course hasPrerequisite Course
Course may hasPrerequisite many Course

# Section Management
Section has SectionNumber
Section exactly-1 has SectionNumber

Section has Semester
Section exactly-1 has Semester

Section has Year
Section exactly-1 has Year

Section has Capacity
Section exactly-1 has Capacity

Section sectionOf Course
Section exactly-1 sectionOf Course
Course may have many Section

Section taughtBy Faculty
Section exactly-1 taughtBy Faculty
Faculty may teach many Section

Section scheduledIn Classroom
Section exactly-1 scheduledIn Classroom
Classroom may host many Section

# Enrollment & Grading
Enrollment links Student to Section
Enrollment exactly-1 has EnrolledStudent(Student)
Enrollment exactly-1 has EnrolledSection(Section)
Enrollment exactly-1 has EnrollmentDate

Enrollment has Grade
Grade exactly-1 belongsTo Enrollment
Grade has GradeValue
GradeValue values {"A", "A-", "B+", "B", "B-", "C+", "C", "C-", "D+", "D", "F", "W", "I"}

# Assignment & Submission
Assignment belongsTo Section
Assignment exactly-1 belongsTo Section
Section may have many Assignment

Assignment has DueDate
Assignment exactly-1 has DueDate

Submission submittedFor Assignment
Submission exactly-1 submittedFor Assignment
Assignment may have many Submission

Submission submittedBy Student
Submission exactly-1 submittedBy Student
Student may have many Submission

Submission has SubmissionDate
Submission exactly-1 has SubmissionDate

Submission has Grade
Submission exactly-1 has Grade

# Program & Degree
Program offeredBy Department
Program exactly-1 offeredBy Department
Department may offer many Program

Program leadsTo Degree
Program exactly-1 leadsTo Degree
Degree may be offeredThrough many Program

Program requires Course
Program at-least-1 requires Course
Course may be requiredBy many Program

Degree has DegreeType
Degree exactly-1 has DegreeType
DegreeType values {"ASSOCIATE", "BACHELOR", "MASTER", "DOCTORATE"}

# Research & Publication
ResearchProject ledBy Faculty
ResearchProject exactly-1 ledBy Faculty
Faculty may lead many ResearchProject

ResearchProject involves Student
ResearchProject may involve many Student
Student may participateIn many ResearchProject

Publication writtenBy Person
Publication at-least-1 writtenBy Person
Person may author many Publication

Publication relatedTo ResearchProject
Publication may be relatedTo ResearchProject
ResearchProject may have many Publication

# Constraints
(Course hasLevel "GRADUATE") ⊕ (Course hasLevel "INTRODUCTORY")

(Student enrolledIn Course) ⊆ (Student satisfiesPrerequisites Course)

unique(Enrollment(links), Student, Section)

# Derived Fact Types
Student completedCourse Course :-
  Student enrolledIn Section and
  Section sectionOf Course and
  Enrollment(Student, Section).Grade.Value != "F" and
  Enrollment(Student, Section).Grade.Value != "W" and
  Enrollment(Student, Section).Grade.Value != "I"

Student eligibleForGraduation :-
  Student enrolledIn / has enrolled Program and
  Program requires Course and
  Student completedCourse Course for all required Course

# Derived Metrics
Student GPA(calculation) :-
  Student has Enrollment and
  Enrollment has Grade and
  weightedAverage(Grade.GradeValue)

Department studentCount(count) :-
  Department offers Program and
  Student enrolledIn / has enrolled Program

Faculty teachingLoad(count) :-
  Faculty teaches Section and
  Section has Credits

This DSL provides a concise yet powerful way to express Object-Role models with various constraint types. It can be extended as needed to capture additional constraint types or domain-specific requirements.