EA Ontology Categories

This document describes each ontology category defined in innovatordemo-mapping.json, derived from live sample nodes in the Enterprise Architecture (EA) Neo4j database. Descriptions are written from an Enterprise Architecture / Software Architecture perspective.

Diagram

Visual representations of architectural views, business processes, or system structures. Includes BPMN process diagrams (e.g., Fahrzeugreservierungsanfrage, Schäden erfassen), ArchiMate viewpoint diagrams (e.g., Organisationssicht), and requirements diagrams. Diagrams are the primary communication artefact in EA modelling — they provide scoped views onto the underlying model elements without duplicating them.

Process

A top-level BPMN process element representing an end-to-end business process from a single participant's perspective. Examples include Fahrzeug zurückgeben (customer view) and Fahrzeugreservierungsanfrage (end-to-end reservation flow). Processes are the main unit of process documentation and serve as the root container for tasks, events, gateways, and flows.

BusinessService

An externally visible service capability offered by a business actor or role to its environment, modelled at the ArchiMate business layer. Examples: Fahrzeugreservierung, Fahrzeugrückgabe, Informationsdienst. Business services define the contract between the organisation and its customers or partners and are typically realised by one or more business processes or interactions.

BusinessProcess

An ArchiMate business-layer process describing a sequence of business behaviours that produces a defined business outcome. Examples: Abruf von Informationen, Schäden erfassen, Anfrage bearbeiten. Unlike BPMN processes, ArchiMate business processes express structural relationships (realises, uses) with services, objects, and application components rather than detailed control flow.

Task

A BPMN atomic unit of work performed within a process, representing a single step that cannot be decomposed further within that diagram. Examples: Reservierung bestätigen, Rückgabestation ansteuern und zuvor volltanken, Fahrzeug leeren und Schlüssel abgeben. Tasks are the primary executable building blocks of a process model and carry the detailed work descriptions.

GlobalTask

A reusable BPMN task definition that can be referenced from multiple process diagrams, avoiding duplication of common steps. Example: Fahrzeug-ID erfassen. Global tasks promote consistency by centralising the definition of frequently repeated steps across the process landscape.

MaskTask

A BPMN user task that is specifically tied to a UI mask (form) interaction. Examples: Ort und Datum der Anmietung festlegen, Fahrzeugtyp samt Optionen wählen, Persönliche Angaben machen. Mask tasks bridge the gap between process flow and UI design, making the human–system interaction points explicit in the process model.

Event

A generic BPMN event element (start, intermediate, or end) that represents something that happens during process execution. In this model, concrete event instances are predominantly typed (EventDefinition, TimerEventDefinition, Signal) rather than plain events. Events control the lifecycle and routing of process tokens.

BusinessEvent

An ArchiMate business-layer event that triggers or results from business behaviour. Example: Mietanfrage (triggers the vehicle rental process). Business events represent externally visible happenings at the business layer that initiate or conclude value-producing processes.

EventDefinition

A BPMN event definition element that specifies the type and semantics of an event (signal, message, timer, etc.). Examples: Fahrzeug einsatzbereit (signal definition), Rückgabe bestätigt (message definition). Event definitions are reusable artefacts referenced by multiple catch or throw events within a process.

TimerEventDefinition

A BPMN timer event definition that specifies time-based triggering conditions. Examples: Rückgabetermin (the rental return deadline becomes active), Nutzungsende. Timer event definitions drive deadline-based routing and SLA enforcement within process flows.

Gateway

A BPMN routing element that controls branching and merging of the process token flow (exclusive, parallel, inclusive, event-based). Gateways are the primary decision and synchronisation points in a BPMN process model and directly encode the conditional logic of the business rules.

Participant

A BPMN participant (pool) representing an autonomous process actor in a collaboration. Examples: Kunde, Kfz-Vermietung für Privatkunden. Each participant encapsulates its own process and communicates with other participants exclusively through message flows, making organisational boundaries explicit.

LaneSet

A BPMN lane-set container that groups swimlanes within a participant pool. Lane-sets structure the responsibilities within a participant's process across roles or departments, providing visual separation of accountability without changing the flow semantics.

Collaboration

A BPMN collaboration element that depicts the interaction between two or more participants via message flows. Example: Rückgabe (describes the full return interaction between the customer and the rental company). Collaborations are the preferred notation when cross-organisational or cross-system communication sequences need to be documented.

BusinessInteraction

An ArchiMate business-layer behaviour element representing a unit of work performed by two or more business actors in collaboration. Example: Rückgabe (the joint vehicle-return interaction between the renter and the lessor). Business interactions explicitly capture reciprocal behaviour that cannot be attributed to a single actor.

Activity

An ArchiMate or UML activity node representing a higher-level unit of behaviour that may be decomposed into sub-activities or actions. Examples: Fahrzeug reservieren, Kunden erfassen, Verfügbare Fahrzeuge ermitteln. Activities serve as intermediate-granularity work units between business processes and atomic tasks.

ActivityResource

A resource consumed by or assigned to an activity. No populated instances were found in the current model. Typically used to record the human or material resources required to execute an activity, supporting capacity planning and resource management analysis.

ProcessResource

A resource associated with a process. No populated instances were found in the current model. Used to document the resources (people, systems, assets) required for process execution, feeding into resource allocation and process optimisation work.

ProcessMap

A high-level overview diagram linking processes, organisational units, and IT units without enforcing BPMN notational constraints. Examples: Vermietungsprozesse, Unternehmensprozesse einer Autovermietung. Process maps are the communication tool of choice for executive and business stakeholders who need a coherent landscape view rather than detailed flow semantics.

Interruptible

A BPMN interruptible activity region that marks a boundary within an activity diagram where attached boundary events can interrupt execution. Used to explicitly delimit the scope within which exception-handling or compensating events are applicable.

DataTable

A physical database table in a relational database model. Examples: VERLEIHER, TMITARBEITER, TKUNDE. Data tables are the physical storage artefacts derived from the conceptual entity model and are directly deployable to a target RDBMS.

DataColumn

A column within a database table, defining one attribute of the table's schema. Examples: FARBEID, BEZEICHNUNG, ADRESSEID. Data columns carry the type, nullability, and default constraints that govern the physical data representation.

DataView

A database view (virtual table) derived from one or more underlying tables. Examples: VIEW_KUNDE_FAHRZEUG, VIEWKUNDESCHADEN, VBESSERVERDIENER. Views abstract query complexity, enforce access control boundaries, and provide stable interfaces to downstream consumers when the underlying table structure evolves.

DataViewColumn

A column within a database view. Examples: FAHRZEUGID, KENNZEICHEN, ERSTZULASSUNG. View columns define the projected attributes surfaced to consumers of the view, potentially combining, renaming, or computing values from the underlying tables.

DbKey

A primary key definition on a database table. Examples: PKFARBE, PKMODELL, PKVERLEIHER. Database keys uniquely identify records and are the foundation for referential integrity enforcement across the relational schema.

DbForeignKey

A foreign key constraint on a database table enforcing referential integrity between tables. Examples: fkModellAutomarke, fkVerleiherPerson, FKSCHADENFAHRZEUG. Foreign keys are the physical realisation of entity relationships from the conceptual ER model and must be managed carefully during schema migration.

DataType

A named scalar or structured data type used within the model. Examples: Zeitstempel (timestamp with timezone), String, Integer. Shared data type definitions promote consistency across the model and enable type-safe interface contracts between components.

DatatypeDefinition

A container node holding the internal definition of a data type in the modelling tool. These are structural artefacts generated by the EA tool and carry no additional business semantics beyond the associated DataType definition.

UseCase

A UML use-case element representing a bounded, named interaction between an actor and the system that delivers a measurable outcome. Examples: Fahrzeug reservieren, Fahrzeug auschecken, Fahrzeug einchecken. Use cases form the requirements baseline for system scoping and are typically linked to functional requirements and process steps.

Actor

A UML actor representing an external entity (person, system, or organisation) that interacts with the system under design. Examples: Lokaler Agent, Kunde. Actors define the boundary of the system and anchor use cases to their initiating or participating parties.

Stakeholder

An ArchiMate motivation-layer element representing a party with an interest in the architecture. Examples: Kunde, Geschäftsführung, Mitarbeiter Anmietstation. Stakeholders are the owners of drivers and goals and are used to trace motivational concerns through to architectural decisions.

Role

A named function or responsibility assigned to an actor or participant within a process or entity relationship. Examples: Kunde (the driver as contracting party), Automarke (foreign-key role in the model–brand relationship). Roles decouple responsibilities from the concrete actors that fulfil them, enabling flexible assignment and reuse across multiple processes or relationships.

OrgUnit

An organisational unit within the enterprise structure. Examples: MIDauto, Anmietstation, Standorte. Org units anchor processes, roles, and resources to the formal organisational hierarchy and are used to derive responsibility matrices and impact analyses.

Package

A namespace container that groups related model elements. Examples: Prozesse und Kollaborationen, Anforderungen, Entitäten und Sichten. Packages provide the primary structuring mechanism for large EA repositories, controlling visibility, reuse scope, and import/export boundaries.

Structure

A composite data structure definition used in process or mask modelling. Examples: Anschrift, Fahrzeugdaten, km u. Tank. Structures are used to define the shape of data objects exchanged between tasks or displayed on UI masks, bridging process and data modelling.

StructureGroup

A named group of related structure entries within a composite structure. Examples: Kunde, Fahrzeug, Rückgabe. Structure groups provide hierarchical organisation within a structure definition, making complex data layouts readable and maintainable.

StructureEntry

An individual field within a structure group. Examples: Straße, Erstzulassung, Farbe. Structure entries are the leaf-level data items that carry type, cardinality, and business meaning, and they map directly to UI fields or data object attributes.

BusinessObject

An ArchiMate passive business-layer element representing a concept of significance to the business that information is about. Examples: Mietvertrag, Fahrzeug, Kundendaten. Business objects form the information backbone of the business architecture and are the semantic anchors that connect processes, services, and data artefacts.

BusinessFunction

An ArchiMate element grouping business processes by shared capability, resource, or competence. Examples: Fahrzeugverwaltung, Kundenbetreuung, Zahlungsabwicklung. Business functions provide a capability-oriented decomposition of the organisation that is more stable than process structures and directly informs capability heat-map analysis.

BusinessRole

An ArchiMate business role representing a set of responsibilities assigned to a person or team in the execution of business behaviour. Examples: Mieter, Vermieter. Business roles are the interface between the organisational structure and business processes, enabling role-based access control and responsibility assignment matrices (RACI).

BusinessActor

An ArchiMate element representing a concrete business entity (person or organisation) that performs a business role. Examples: Anmietstation, Kunde. Business actors are the real-world parties that fulfil roles; separating actors from roles enables modelling of many-to-many assignments across the enterprise.

BusinessCollaboration

An ArchiMate element representing a temporary or permanent association of business roles cooperating to perform a behaviour. Example: Zurückgeben eines Fahrzeugs (cooperation between the renter and the lessor during the return process). Business collaborations make peer-to-peer interactions at the business layer explicit, complementing the service-consumer hierarchy.

BusinessKnowledgeModel

A DMN business knowledge model encapsulating reusable decision logic. Examples: Selbstbehalt, Wert Fahrzeugzubehör. Business knowledge models represent encapsulated, callable decision logic that can be invoked from decision tables or business processes, promoting consistent application of business rules.

ApplicationService

An ArchiMate application-layer service exposing functionality from an application component to the business layer. Examples: Fahrzeugreservierung, Kundenverwaltung, Prämienbuchung. Application services define the interface contract between IT systems and business processes, enabling the traceability from business requirements through to deployment artefacts.

ApplicationComponent

An ArchiMate modular application unit that encapsulates application behaviour and data. Examples: Buchungssystem, CRM, Benutzerverwaltung. Application components are the primary unit of application decomposition in the information systems architecture and the basis for build, deployment, and change-impact analysis.

TechnologyService

An ArchiMate technology-layer service providing infrastructure capability to applications. Examples: Benutzerverwaltung (identity and access management), Buchungsservice, Fahrzeugverwaltung. Technology services abstract the underlying infrastructure and define the technical interface contracts between the platform layer and the application layer.

Device

An ArchiMate physical computing device that hosts system software and application components. Examples: Vermietungsstation Nbg, Vermietungsstation Stg, Domaincontroller. Devices are the primary unit of infrastructure inventory and are used for deployment mapping, availability analysis, and disaster-recovery planning.

SystemSoftware

An ArchiMate element representing an operating environment (OS, middleware, runtime) that manages and executes application components on a device. Examples: CRM System, MIDwagen Station, MIDwagen Webserver. System software bridges the gap between physical devices and deployed application components in the technology architecture.

CommunicationNetwork

An ArchiMate element representing a physical or logical network connecting devices. Examples: MIDwagen Nbg LAN, MIDwagen Stg LAN, MIDwagen WAN. Communication networks are essential for latency, bandwidth, and security zone analysis and are the foundation for network segmentation and zero-trust architecture design.

NetworkNode

An ArchiMate infrastructure node within a network (router, firewall, server). Examples: Firewall Nbg, Firewall Stg, Mainframe. Network nodes represent the active infrastructure elements that control and route traffic; their placement in the topology directly determines security perimeters and resilience characteristics.

Component

A UML component representing a modular, replaceable system unit with well-defined interfaces. Examples: Kfz-Vermietung für Privatkunden, Fahrzeugverwaltung, Benutzerverwaltung. Components are used in component diagrams to express the high-level software architecture, showing how the system is decomposed and how components communicate through provided and required interfaces.

ConnectorEnd

The endpoint of a UML connector on a structured classifier, representing the specific port or role at which a connection terminates. No populated instances were found in the current model. Connector ends are relevant when modelling detailed composite structures with typed connections.

Path

An ArchiMate path element representing a communication or transportation route between nodes. Example: Rücknahme mit Schadensprüfung (the process path for vehicle return requiring damage inspection). Paths document the conditional routes through a process or infrastructure topology that are activated under specific circumstances.

Location

A physical or logical location relevant to the enterprise. Examples: Außenstelle Stuttgart, Hauptsitz Nürnberg. Locations anchor processes, org units, devices, and facilities to a geographic or logical site, enabling impact analysis, regulatory compliance scoping, and disaster-recovery planning.

Facility

An ArchiMate physical facility element. Example: Vermietungsstation. Facilities represent the physical premises in which business operations are conducted, providing the physical layer of the enterprise architecture below devices and equipment.

Equipment

An ArchiMate physical equipment element. Examples: Waschstraße, Werkstatt. Equipment models the physical machinery and tooling involved in value-creating processes, relevant to asset management and operational architecture analysis.

Capability

An ArchiMate strategic-layer element representing a high-level ability of the enterprise that enables it to achieve outcomes. Examples: Verkauf und Vertrieb, Nachforderungsmanagement, Kunden-Service. Capabilities form the stable reference framework for capability-based planning and are used to map current-state vs. target-state gaps, investment priorities, and outsourcing decisions.

ValueStream

An ArchiMate strategic-layer element representing a sequence of activities that creates value for a stakeholder. Examples: Mietwagen-Pakete entwickeln, Vermarkten und Verkauf von Paketen, Verwaltung von Autovermietungen. Value streams provide a customer-outcome perspective on the business and are used to align capabilities and processes to value delivery.

WorkPackage

An ArchiMate implementation-layer element representing a unit of work in a transformation project. Examples: Projekt Einführung, Projekt Initiation, Projekt Implementierung. Work packages structure the migration roadmap and are the primary elements linking the as-is/to-be architecture gap to a delivery plan with timelines and ownership.

Deliverable

An ArchiMate implementation-layer element representing a precisely defined result produced by a work package. Examples: Online Reservierungsservice, Online Informationsdienst. Deliverables provide the traceable link between project execution and the realisation of architectural capabilities or services.

GoalElement

An ArchiMate motivation-layer goal representing a desired state or outcome for a stakeholder. Examples: Auslastung von Mitarbeitern reduzieren, Wartungskosten reduzieren, Betriebskosten reduzieren. Goals form the top of the motivation hierarchy and drive the derivation of requirements, principles, and courses of action, ensuring architectural decisions remain aligned to business intent.

Outcome

An ArchiMate motivation-layer element representing a measurable end result that a stakeholder wants to achieve. Examples: Online-Reservierungsservices bereitgestellt, Vollständiges Leistungsangebot der Autovermietung. Outcomes differ from goals in that they are concrete and verifiable; they are used as the acceptance criteria for work packages and transformation initiatives.

Assessment

An ArchiMate motivation-layer assessment representing a judgement of the current situation. Examples: Intransparenz bei Beschwerdestatus, Unvollständige und inkonsistente Informationen, Verlust von Bestandskunden. Assessments capture the results of gap analyses, audits, or customer feedback and are used to justify the need for architecture change initiatives.

Driver

An ArchiMate motivation-layer driver representing an internal or external condition that motivates stakeholders to change. Examples: Einnahmen, Kundenzufriedenheit, Kosten. Drivers are the root causes of architectural change; they are connected to stakeholders and assessments to form the full motivational chain underlying transformation decisions.

Principle

An ArchiMate motivation-layer element expressing a normative statement that guides architectural decisions. Example: Systeme müssen kundenorientiert sein. Principles translate strategic intent into actionable constraints on the architecture, providing a stable reference point that remains valid across multiple transformation initiatives.

CourseOfAction

An ArchiMate motivation-layer element representing a chosen approach or strategy to address drivers and achieve goals. Example: Online Serviceangebot aufbauen. Courses of action bridge the motivation layer and the implementation layer, describing the strategic direction that work packages and deliverables must realise.

Gap

An ArchiMate implementation-layer element representing the difference between two architectural plateaus that must be resolved. Examples: Gap Baseline-Übergang, Gap Übergang-Ziel. Gaps are the formal artefacts of a gap analysis and drive the definition of the work packages needed to migrate from the current to the target architecture.

Plateau

An ArchiMate implementation-layer element representing a relatively stable state of the architecture at a point in time. Examples: Baseline Architektur (current state), Übergangsarchitektur (interim state), Ziel Architektur (target state). Plateaus provide the temporal framing for migration planning and are the reference states between which gaps are defined.

Product

An ArchiMate business-layer element representing a coherent offering of services and contracts delivered to customers. Example: Mietfahrzeug (a bundle of rental services, insurance, and contract). Products are the customer-facing packaging artefacts that tie together business services and contracts into a commercially meaningful unit.

Contract

An ArchiMate business-layer element representing a formal agreement on rights and obligations. Examples: Mietvertrag, AGB, Versicherung. Contracts are the legal and procedural instruments that govern business relationships; they are modelled to make compliance requirements and obligation chains explicit in the architecture.

Resource

An ArchiMate element representing a strategic asset (human, financial, or informational) used by the enterprise. Examples: Mitarbeiter, IT, Kunden. Resources at the strategy layer provide the link between capability definitions and the concrete assets that enable those capabilities, supporting resource-based strategic planning.

CostCenter

A financial management element representing a unit within the organisation to which costs are allocated. Examples: Kundenservice, Verwaltung, Schadenstelle. Cost centres provide the financial dimension of the enterprise architecture, enabling cost allocation modelling and business case development for architecture initiatives.

Material

A physical material used in the execution of business processes. Examples: Waschkarte, Fahrzeug, Fahrzeugschlüssel. Material elements bridge the digital and physical worlds in the architecture model, relevant for supply chain, asset tracking, and operational process design.

Requirement

A functional or non-functional requirement derived from business goals or stakeholder needs. Examples: Online-Reservierung zur Verfügung stellen, Schlüsselabgabe automatisieren, Die Fahrzeugklasse soll anhand von Beispielen gewählt werden. Requirements form the contractual specification between the business and IT, traceable through use cases, components, and test artefacts.

Term

A glossary term defining a business concept with precise domain meaning. Examples: Fahrer (the driver is also the contracting party in private-customer business), Mietzeitraum, Mindestalter. Terms are the shared vocabulary of the architecture; maintaining them prevents misunderstandings between business and IT stakeholders and ensures unambiguous contract specifications.

Glossary

A container for domain terms and reusable conditions. Example: Glossar (contains domain-relevant concepts and reusable gateway conditions). The glossary serves as the single authoritative reference for business terminology, promoting semantic consistency across all model artefacts.

Meaning

An ArchiMate element representing knowledge or expertise associated with a business object or representation. Example: Outlook Kontakt (the knowledge contained in a vcard representation of customer data). Meaning captures the informational semantics of a representation beyond its physical form, useful for knowledge management and information architecture work.

Catalog

A structured registry of model elements, typically auto-generated by the EA tool. Example: DefaultCatalog. Catalogs provide a queryable inventory of artefacts within a model package, supporting impact analysis and reuse management.

ImpactAnalysis

A cross-cutting analysis artefact that traces the impact of a change across the model. Examples: Mietwagenunternehmen Profilimporte, Fahrzeugreservierungsanfrage. Impact analyses are used during change management to identify all affected elements before a modification is applied, reducing unintended consequences.

ErEntity

A conceptual ER entity representing a significant concept in the business domain. Examples: Person, Ausleihe, Schaden. ER entities are the building blocks of the conceptual data model, capturing the key informational concepts before physical database design concerns are introduced.

EntityAttr

An attribute of an ER entity defining one data property of that concept. Examples: Fahrzeugmodell-ID, Name, Anzahl Sitzplätze. Entity attributes carry the semantic meaning and constraints of the data, forming the basis for column definitions in the subsequent physical schema.

RelationshipKey

A key feature associated with an entity relationship in the ER model. No populated instances were found in the current model. Relationship keys are used when a many-to-many relationship itself carries identifying attributes, as in associative or bridge entities.

ErKey

A primary key definition on an ER entity. Examples: pkModell, pkVerleiher, pkKunde. ER keys provide the unique identity for each entity instance at the conceptual level, driving the physical primary key definitions in the database model.

ErForeignKey

A foreign key reference on an ER entity representing a relationship between two entities at the conceptual level. Examples: fkModellAutomarke, fkVerleiherPerson, fkKundePerson. ER foreign keys capture referential constraints in the domain model before they are realised as physical database constraints.

ViewAttribute

A column-level attribute included in an ER view definition. Examples: Schaden-ID, Datum, Schadenstelle-ID. View attributes define the projected subset of entity attributes that are surfaced through a conceptual ER view, enabling focused presentations of the data model for specific stakeholder groups.

ErFromClause

The FROM clause element within an ER view definition, referencing the source entities included in the view. ER FROM clauses are the query-construction artefacts that specify which entities contribute data to a given conceptual view.

ErModel

The root container for the conceptual entity-relationship model. Example: Konzeptionelles Modell (the domain model created by the information architect as the specification basis for physical database design). The ER model represents the information architecture's conceptual layer and is the authoritative reference for data governance and semantic data integration.

ErView

A named query or projection defined over an ER model, providing a specific perspective on the entities. Example: View_Kunde_Schaden. ER views are the conceptual equivalents of database views, enabling reusable, named access patterns over the entity model without physical database artefacts.

GeneralizationSet

A UML generalisation set defining the rules governing a generalisation hierarchy (complete/incomplete, disjoint/overlapping). Example: wer ist alles eine Person? (Person as generalisation of Kunde and Verleiher). Generalisation sets make inheritance constraints explicit and drive the choice of physical database mapping strategy (table-per-class, table-per-hierarchy, etc.).

FromClause

The FROM clause element within a physical database view definition. FROM clauses record which tables or other views are joined to produce the view result and are the implementation-level counterpart of the ErFromClause.

CombinedColumn

A column in a combined (UNION-based) database view that aggregates values from multiple SELECT branches. Examples: NAME, ADRESSE. Combined columns are used when a view merges structurally similar data from multiple source tables into a unified column definition.

CombinedView

A database view constructed from a UNION of multiple SELECT statements, unifying data from several source tables. Example: CVPERSON (combines Kunde and Verleiher through their shared Person attributes). Combined views are the physical realisation of generalisation hierarchies in a relational database and are critical for applications that need a single access point to polymorphic data.

SubselectFromClause

A FROM clause element within a subselect that is part of a combined database view. Subselect FROM clauses are the fine-grained structural artefacts of the physical view definition, capturing the source table references within each branch of a UNION view.

CheckConstraint

A database constraint that enforces a boolean predicate on column values. Examples: checkFahrzeugID, prüfe Fahrzeug-ID. Check constraints implement business rules directly in the database engine, providing a last line of defence against invalid data independent of application-layer validation.

SiblingConstraint

A constraint enforcing disjointness between sibling tables in a table-per-subclass mapping strategy. Examples: Person_wer ist alles eine Person?, PERSON_WER_IST_ALLES_ EINE_PERSON. Sibling constraints are the physical enforcement of the disjoint rule defined in the corresponding GeneralizationSet, ensuring that a row cannot simultaneously appear in two exclusive sibling tables.

Schema

A database schema grouping tables, views, and other database objects within a named namespace. Examples: CarRentalSchema, dbo. Schemas provide the primary organisational and security boundary within a database, controlling object ownership, access rights, and deployment scope.

DatabaseModel

The root container for a physical database model targeting a specific RDBMS platform. Examples: Datenbankmodell - Oracle, Datenbankmodell - SQLServer. Database models capture the full physical schema specification — tables, keys, constraints, views, and stored procedures — for a specific database technology, serving as the blueprint for DBA deployment.

StoredProcedure

A named, compiled procedural unit stored and executed within the database engine. Example: INSERTMITARBEITER. Stored procedures encapsulate complex data manipulation logic close to the data, reducing network round-trips and centralising business-rule enforcement at the database tier.

DbUser

A named database principal with granted privileges to access database objects. Examples: admin, customer. DB users are the identity artefacts for database-level access control and are the basis for privilege assignment and least-privilege security analysis.

DbRoles

A package grouping the role definitions of a database model. Examples: DB-Rollen. DB roles packages provide the organisational structure for managing database security artefacts within the EA model, mirroring the role-based access control hierarchy of the target RDBMS.

DbTypes

A package grouping the semantic data type definitions of a database model. Examples: Datentypen. DB types packages centralise the type catalogue for the physical schema, ensuring consistent use of domain-specific data types (e.g., timestamps, identifiers) across all tables and views.

DbPrivilege

A specific privilege granted to a database user or role. No populated instances were found in the current model. DB privileges document the fine-grained access rights assigned at the object level, supporting security audit and least-privilege reviews.

SystemModel

A top-level container for a coherent system model within the EA repository. Examples: Unternehmensarchitekturmodell mit ArchiMate, Mietwagenunternehmen, Softwaremodell. System models are the primary organisational boundaries within the EA repository, grouping all artefacts that belong to a specific subject area, domain, or modelling paradigm.

DataObject

A BPMN data object representing information that flows through a process or is produced/consumed by a task. Examples: Vertrag zur Fahrzeug-ID, Rückgabedaten, Kundendaten. Data objects make the information perspective of a process explicit, tracing where data is created, read, updated, and deleted across the process flow.

Datastore

A BPMN datastore or UML activity node representing a persistent data storage accessible from process tasks. Examples: Vertrag zur Fahrzeug-ID (contract database record), named datastores in activity diagrams. Datastores identify the persistence boundaries within a process and are the link between the process model and the underlying data architecture.

OpaqueAction

A UML opaque action representing a generic, implementation-defined action within an activity diagram. Opaque actions are placeholders for low-level implementation steps whose semantics are defined outside the UML model (e.g., in code), used when a more specific action type is not available or needed.

Decision

A DMN decision table or a UML decision node controlling flow branching in an activity diagram. Examples (DMN): Überziehungsstrafe, Fehlendes Zubehör, Abrechnung erstellen. Decisions externalise business rules from process code into an explicit, versioned, and testable form, enabling business-side governance of rule changes.

MaskField

A field definition within a UI mask (form), representing a single user-input or display element. Examples: Zweiter Fahrer?, Kindersitz?, Navigationssystem. Mask fields bridge the process model and the UI specification, making the data entry points in mask tasks explicit and traceable to the underlying data model.

Mask

A UI mask (form) definition grouping mask fields into a coherent screen. Examples: Fahrzeugtypauswahl, Persönliche Angaben, Anmietungsanfrage. Masks are the UI artefacts attached to mask tasks in the BPMN process and serve as the specification input for frontend development.

Lifeline

A UML sequence diagram lifeline representing the participation of an instance over time. Lifelines are the vertical axes of sequence diagrams, anchoring message exchanges to their sending and receiving instances, and are generated automatically as part of interaction modelling.

MessageOccurrence

A UML message occurrence specification marking the point on a lifeline where a message is sent or received. Message occurrences are the structural anchors for messages within a sequence diagram, enabling precise positioning of communication events on the time axis.

ExecutionOccurrence

A UML execution occurrence specification representing an active period on a lifeline. Execution occurrences visually indicate when a classifier instance is executing a behaviour, providing the temporal context for understanding message exchanges in a sequence diagram.

ActionExecution

A UML action execution specification describing the execution of a specific action within a lifeline's active period. Action executions provide finer-grained decomposition of execution occurrences, linking the sequence diagram view to specific operations in the behaviour model.

CallEvent

A UML call event representing the receipt of a call to an operation. Call events trigger the activation of an execution occurrence on a lifeline and are used to model synchronous operation invocation in sequence and state machine diagrams.

CallMessage

A UML synchronous call message in a sequence diagram representing the invocation of an operation on a target lifeline. Call messages are the primary communication artefact in synchronous interaction models and carry the operation name and parameter data.

ReplyMessage

A UML reply message returning a result from a previously received call message. Reply messages complete the synchronous request-response pair and carry the return value of the invoked operation back to the calling lifeline.

CreateMessage

A UML create message representing the instantiation of a new object (lifeline) during a sequence interaction. Example: createMessage. Create messages make object creation events explicit in the interaction model, relevant for lifecycle and object collaboration analysis.

Message

A BPMN message or UML message representing information transmitted between participants or lifelines. Examples: Schlüssel (physisch) (a physical key handed over between participants), Bestätigung (return confirmation). Messages are the information flow artefacts that cross participant or component boundaries and carry the communication contracts between interacting parties.

CallBehaviorAction

A UML call behavior action invoking a separately defined behaviour (e.g., a sub-activity or operation) from within an activity diagram. Examples: KundeNeu. Call behavior actions promote modular decomposition of activity diagrams by delegating complex sub-steps to named, reusable behaviour definitions.

AcceptEventAction

A UML accept event action representing a point in an activity where the flow waits for and accepts an external event. Examples: abbrechen. Accept event actions model exception or external-trigger handling within activity flows, important for documenting boundary events and user cancellation paths.

OutputPin

A UML output pin on an action providing a data token to downstream actions in an activity. Examples: Fuhrpark, result. Output pins make the data produced by an action explicit and typed, enabling strict data-flow modelling in UML activity diagrams.

InputPin

A UML input pin on an action consuming a data token from upstream actions. Examples: Von_Bis, Fuhrpark. Input pins document the data dependencies of an action, enabling automatic derivation of data-flow ordering constraints in the activity model.

ParameterNode

A UML activity parameter node representing an input to or output from a top-level activity. Examples: zeitspanne, fuhrpark. Parameter nodes define the interface of a reusable activity, analogous to method parameters, and are the mechanism by which activities receive and return data in the call behavior action pattern.

InputData

A DMN input data element representing an external data source that feeds into a decision. Examples: Mietvertragsdaten, Rückgabeprotokoll, Fahrzeug. Input data elements make the data dependencies of decisions explicit and traceable to their source data objects, essential for decision governance and data lineage analysis.

State

A UML state in a state machine representing a condition or situation in the life of an object. Examples: verfügbar, blockiert, ausgemustert (vehicle states); Reserviert, Abgeholt, Zurückgegeben (contract lifecycle states). States are the key artefacts of object lifecycle modelling, documenting the full set of valid conditions and the transitions between them.

StateMachine

A UML state machine diagram defining the complete lifecycle of a classifier. Examples: Fahrzeug_Impl, Kunde. State machines are the definitive specification of object lifecycle behaviour and serve as the basis for validating process completeness, implementing object status management, and defining event-driven integration contracts.

Region

A UML state machine region representing an orthogonal or sequential sub-state container within a composite state or state machine. Regions model concurrent or alternative sub-behaviour within a state, used when an object can be simultaneously in multiple orthogonal sub-states.

Partition

A UML activity partition (swimlane) grouping actions within an activity diagram by responsibility. Examples: Kunde, Vermietungssystem. Partitions make the assignment of activities to organisational roles or systems explicit in the activity diagram, enabling direct traceability from activity steps to the responsible actor or component.

MergeNode

A UML merge node in an activity diagram that joins multiple alternative incoming flows into a single outgoing flow without synchronisation. Merge nodes are the flow-control counterpart of decision nodes, reuniting the divergent paths created by an exclusive (XOR) branch.

InitialState

A UML initial pseudostate marking the entry point of a state machine or activity. Initial states define the default starting condition of an object's lifecycle or the default entry point of an activity, and every well-formed state machine must contain exactly one.

FinalState

A UML final state representing the termination of a state machine, activity, or flow. Examples: final (activity end), Vorgang abgeschlossen (contract lifecycle end). Final states document the completion conditions of a lifecycle or flow, and their descriptions often capture the postconditions that must hold when the behaviour terminates.

FlowFinal

A UML flow final node in an activity diagram terminating a specific flow token without ending the entire activity. Flow finals are used to model the early termination of one path in a parallel or alternative flow while the activity as a whole continues executing.

Interaction

A UML interaction defining a sequence of message exchanges between lifelines. Example: Fahrzeug reservieren. Interactions are the root containers of sequence diagram content and provide a named, reusable specification of a communication scenario that can be referenced from activity diagrams or use case specifications.

Signal

A BPMN signal element used for broadcast-style inter-process communication, where one process throws a signal and one or more processes catch it. Examples: Fahrzeug einsatzbereit, Fahrzeugrückgabe nachbereiten. Signals decouple the sender and receiver in event-driven process architectures, enabling publish-subscribe integration patterns between processes.

Trigger

A UML trigger specifying the event that causes a transition in a state machine. Triggers are the event specifications attached to state transitions; without them, transitions would fire unconditionally. They form the event-handling vocabulary of the state machine.

ChangeEvent

A UML change event representing a state change in an object or data condition that triggers a state transition. Example: Fahrzeugrueckgabe (the vehicle return event). Change events model data-condition-driven triggers, as opposed to call events (operation invocations) or time events (timer expirations).

ExtensionPoint

A UML use-case extension point marking a location in a base use case where extending use cases can insert additional behaviour. Examples: Authentifizierung, Fahrzeugzustand prüfen. Extension points document the variability and optionality of a use case, enabling clean separation of core and optional/conditional behaviour.

Representation

An ArchiMate element representing a perceptual form of information carried by a business object. Examples: vcard, Anfrageformular, Rechnung. Representations make the physical or digital form of business information explicit, linking the abstract business object to its concrete instantiations (documents, forms, digital files) that flow between actors.

Constraint

A UML constraint element expressing a boolean condition that must hold within the model. Constraints are the formal specification mechanism for invariants, pre/postconditions, and guard conditions, and are used wherever rigorous correctness requirements must be documented alongside structural or behavioural model elements.

Expression

A named logical expression used as a guard condition in process flows. Examples: keine Vollkasko (the customer has no fully comprehensive insurance), unter 25 (the driver is under 25). Expressions externalise conditional logic from BPMN sequence flows into named, reusable, and governable artefacts.

Value

An ArchiMate value element representing the benefit or worth delivered to a stakeholder. Examples: Innovative Mietwagen-Pakete, Erschliessung von Kundengruppen, Erwartungserfüllung der Produkte. Values articulate the business rationale for architectural investments and are linked to products and services to make the value proposition of the architecture explicit.

Risk

An ArchiMate risk element representing a potential negative event with associated probability and impact. Example: Zahlungsausfall. Risks anchor the risk management layer of the EA model, linking threat events, vulnerabilities, and loss events to the affected business services and processes.

ThreatEvent

An ArchiMate element representing a specific event that exploits a vulnerability to cause a loss. Example: Abbuchung nicht erfolgreich. Threat events are the concrete realisation of risks and link the abstract risk category to the specific failure scenario that the control measures must prevent or mitigate.

LossEvent

An ArchiMate element representing the actual harmful outcome when a threat event occurs. Example: es kommt kein Geld. Loss events capture the business impact of a materialised risk, connecting the risk model to the financial and operational consequences documented in the business case for security controls.

Vulnerability

An ArchiMate element representing a weakness that can be exploited by a threat. Example: Zuverlässigkeit des Kunden/Bezahlvorgangs kann nicht gewährleistet werden. Vulnerabilities document the root-cause weaknesses in processes, systems, or controls that risk management activities must address.

ControlMeasure

An ArchiMate element representing a countermeasure that reduces the probability or impact of a risk. Example: Zahlungsausfälle nachverfolgen. Control measures are the actionable risk-treatment artefacts linked to vulnerabilities and control objectives, forming the operational security architecture layer.

ControlObjective

An ArchiMate element representing the desired outcome that a set of control measures is intended to achieve. Example: Verluste vermeiden. Control objectives provide the strategic framing for individual control measures, enabling alignment of security architecture decisions with enterprise risk appetite and compliance requirements.

Chance

An ArchiMate element representing a positive opportunity that could benefit the enterprise. Example: Kundenkreditkarte vermitteln. Chances are the positive counterparts of risks and are used in opportunity-oriented architecture analyses to identify beneficial scenarios that the architecture should enable or exploit.

JavaClass

A UML class or Java class representing a data type or implementation class in the software design model. Examples: Kunde, Fahrrad, Kundenkarte (domain model); Hashtable, Exception (library classes). Java classes are the primary unit of object-oriented design and the bridge between the platform-independent domain model and the implementation.

JavaMethod

A method or operation defined on a Java class or interface. Examples: bucheFahrzeug, getExtrasFuerFahrzeug, setUnblockiert. Java methods define the behavioural interface of a class and are the implementation-level realisations of business operations documented in the higher-level service and process models.

JavaInterface

A Java interface defining a contract (set of method signatures) that implementing classes must fulfil. Examples: Collection, Fahrzeug, Buchung. Interfaces are the dependency-inversion artefacts that enable loose coupling between components; their presence in the EA model supports interface governance and impact analysis for API changes.

JavaParameter

A parameter of a Java method or operation. Examples: fahrzeugID, Von_Bis, Fuhrpark. Parameters carry the typed input and output data contracts of operations, and their documentation in the EA model enables method-level traceability to data objects and business concepts.

JavaProperty

A persistent or transient property of a Java class. Examples: vorname, geburtstag, datum_von. Java properties are the implementation counterpart of entity attributes and ER entity fields; documenting them in the EA model provides end-to-end traceability from the business data model through the physical schema to the code.

JavaPackage

A Java package or library grouping related classes and interfaces. Examples: java.util, de.mid.carrentaldemo. Java packages define the modularisation structure of the codebase and are the unit of dependency management, build organisation, and access control in the software architecture.

JavaPrimitive

A Java primitive type (Boolean, Integer, String, etc.). Java primitives are the lowest-level data type building blocks referenced throughout the class model; their explicit modelling enables strict type consistency analysis between the conceptual data model and the implementation.

JavaEnumeration

A Java enumeration type defining a fixed set of named constants. Examples: Versicherungsart, Anrede. Enumerations externalise closed value sets from code into named, documented, and versioned model artefacts, enabling business-side governance of valid values.

Constructor

A UML constructor operation that creates an instance of a class. Example: Neu. Constructors document the initialisation contracts of classes, including the parameters required for valid instantiation, and support the modelling of object-creation scenarios in sequence diagrams.

Port

A UML port representing a named interaction point on a component or class through which it communicates with its environment. Examples: Fahrzeug, Kunde. Ports make the provided and required interfaces of a component explicit and are the foundation for component-based architecture, enabling structured composition and interface-contract governance.

ITUnit

A process-map level IT element representing an application component or system in a high-level landscape view. Examples: Benutzerverwaltung, Fahrzeugverwaltung, Online-Portal. IT units bridge the gap between the business process landscape and the detailed ArchiMate application architecture, providing a simplified IT footprint for executive communication.

Grouping

An ArchiMate grouping element that visually clusters elements sharing a common characteristic without implying a structural relationship. Examples: Application Components und Services, Externe Infrastructure Services. Groupings are the informal clustering mechanism in ArchiMate, used when the classification does not warrant a formal structural relationship such as composition or aggregation.

Artifact

An ArchiMate technology-layer artefact representing a physical piece of information used or produced by the technology layer (database record, file, deployment unit). Examples: Fahrzeug, Kunde, Verleiher. Artefacts are the data-at-rest representation in the technology architecture and document where and how information is physically stored and managed by infrastructure components.

Model

A top-level semantic container for a subject-area or domain model within the EA tool. Examples: Fachliches Modell (business analyst's domain model), Business Layer (ArchiMate business architecture), Application Layer (ArchiMate application architecture). Models provide the coarsest-grained structuring boundary in the repository, analogous to a bounded context in domain-driven design, separating concerns and enabling parallel modelling by different architecture teams.

Viewpoints

A container element grouping the defined ArchiMate viewpoint references used within the model. Example: Views. Viewpoints define the stakeholder-specific lenses through which the architecture is communicated; grouping them in a dedicated package enables systematic viewpoint management and governance.

Error

A BPMN error element representing a named error condition that can be thrown and caught within a process. Example: Person erfüllt nicht die Vorgaben (the potential customer does not meet minimum requirements). Error elements make exception paths explicit in the process model, documenting the error name and context so that error-handling flows are consistently and unambiguously specified.

ComplexRelation

A base EA-internal node type used by Enterprise Architect to reify relationship instances as first-class graph nodes. Instances include generic associations and aggregations (e.g., association, aggregation). Complex relations have no direct equivalent in standard modelling notations; they are an EA tool artefact that enables properties and diagrams to be attached to a relationship, and they are resolved transparently during import to produce direct typed relationships in the local knowledge graph.

ComplexRelationFlow

A subtype of ComplexRelation representing a directed flow or transition edge in a BPMN or activity diagram. Subtypes include: sequence flows (sequenceFlow), control flow edges (controlFlow), object flow edges (objectFlow), message flow edges (messageFlow), generic flows (flow), and state machine transitions (transition). These nodes are resolved during import to produce direct flows_to relationships between the source and target process elements.

ComplexRelationTrigger

A subtype of ComplexRelation representing an ArchiMate triggering relationship between two behaviour elements. Subtype: Auslösen (triggering). Triggering relationships indicate that one behaviour causes another to initiate; they are semantically stronger than association and express temporal causality between processes or events.

ComplexRelationAssociation

A subtype of ComplexRelation representing a structural or semantic relationship that is not a flow. Subtypes include: Assoziation (association), Realisierung (realization), and Zuweisung (assignment). These cover the full range of non-flow ArchiMate and UML relationships (service realisation, role-actor assignment, element association) and are imported as typed directed edges in the local knowledge graph.

EA Relationship Types

This section describes each relationship type used in the knowledge graph imported from the Enterprise Architect repository. Relationships reflect structural and semantic links between model elements across all architectural layers.

depicts

A directed link from a Diagram to a model element, expressing that the element is visualised in that diagram. Examples: the Architekturvision diagram depicts the Kunde stakeholder; the Wertstromsicht diagram depicts the same Kunde in a value-stream context. A single element may appear in many diagrams simultaneously, and a single diagram depicts many elements — the relationship provides the full cross-reference between the visual and structural layers of the model. It is the primary artefact for impact analysis at the diagram level: when an element changes, all diagrams that depict it are candidates for review and update.

contains

A directed structural link expressing that one model element owns or encompasses another. This covers two distinct architectural semantics that are unified under a single edge name:

Together, these two uses of contains form the two structural axes of the knowledge graph: the containment hierarchy and the realisation hierarchy.

flows_to

A directed behavioural link expressing that control, data, or a message passes from one element to another. In the knowledge graph this edge is produced by resolving EA's reified relationship nodes (ComplexRelation), and covers sequence flows between BPMN tasks, control flow edges in activity diagrams, object flow edges, message flows across BPMN participants, state machine transitions, and ArchiMate triggering and association relationships. Examples: a sequence flow edge from Reservierung bestätigen flows to the next task in the reservation process; an association from Kunde flows to Vollständiges Leistungsangebot der Autovermietung. The flows_to edge is the workhorse of process and behaviour traversal in the graph, enabling path-finding queries such as "what chain of steps connects this event to that outcome?"

triggers

A directed link from an ImpactAnalysis diagram to the model element that is its starting point. Examples: the impact analysis Mietwagenunternehmen Profilimporte triggers the Mietwagenunternehmen system model; Fahrzeugreservierungsanfrage (impact analysis) triggers the Fahrzeugreservierungsanfrage process. The triggers edge makes the entry point of every impact analysis explicitly navigable in the graph, enabling queries such as "which impact analyses cover this service?" and "what change propagation scope is defined for this process?"

connects_to

A directed link from a model element to a reified relationship node (ComplexRelation), expressing that the element is the source of that relationship. The reified node in turn carries a flows_to edge to the target element, forming the two-hop path source -[connects_to]-> ComplexRelation -[flows_to]-> target. Examples: Kunde connects to an association ComplexRelation node; Auslastung von Mitarbeitern reduzieren connects to aggregation and association nodes pointing to various goal elements. connects_to provides the outgoing adjacency index for all relationship types that EA represents as first-class nodes — querying it on any element yields its full set of outgoing typed relationships before they are resolved to their final targets.