Modeling notations and methods

Software systems are described on paper, or on a screen, long before and long after they exist in code. Modeling notations and methods are the formal languages, diagram conventions, and structured techniques used to represent a system’s structure, behavior, and data independently of any particular implementation. A notation gives that representation a shared, unambiguous vocabulary; a method gives the process of producing it a repeatable structure.

General-purpose modeling languages

The Unified Modeling Language (UML) is the best known general-purpose notation for object-oriented systems, with distinct diagram types for structure, such as class diagrams, and behavior, such as sequence diagrams. Systems Modeling Language (SysML) extends the same family of ideas to systems engineering more broadly, covering hardware and processes alongside software. ArchiMate targets a different layer again, modeling the relationships between business processes, applications, and infrastructure across an entire enterprise, often within the frame set by The Open Group Architecture Framework (TOGAF). Business Process Model and Notation (BPMN) is narrower still, focused specifically on the flow of a business process from start to finish.

Data and graph notations

Some notations exist specifically to describe data and its relationships. An entity relationship diagram (ERD) models the entities in a system and the relationships between them, and is a common output of data modeling, the broader activity of defining a system’s data structures ahead of implementation. GraphML, Graph Modelling Language (GML), and Trivial Graph Format (TGF) are file formats for representing graphs of nodes and edges in a form that both humans and tools can read. Vega takes a different angle: rather than modeling a system, it’s a grammar for describing data visualizations declaratively.

Modeling as a practice

A notation is only as useful as the process that produces and maintains it. Model-driven architecture (MDA) treats a formal model as the primary artifact, generating source code from it rather than writing code by hand. A Class-Responsibility-Collaboration (CRC) card is a lightweight, physical alternative: a single index card per class, used in a workshop setting to discover responsibilities and collaborations before any formal diagram is drawn. Story-driven modeling and event storming take a similar workshop-based approach, building up a model of a domain through facilitated group sessions rather than a single author’s diagram. Diagramming and diagrams-as-code sit underneath all of these, covering the general practice of producing diagrams and the tooling that lets them be generated from version-controlled source rather than drawn by hand.

Risk Analysis and Assessment Modeling language (RAAML) applies the same modeling instinct to a narrower purpose: representing risks, hazards, and their causal relationships in a structured, analyzable form.

See also