Planes, Trains and Automobiles

Most of us already describe the world by naming things, describing them and saying what they do. A car, a train and an aeroplane are kinds of things. One particular car is a specific thing. It can be red, damaged or full. It can start, stop, carry people and travel somewhere. When we deliberately organise those kinds of things, their qualities, actions and relationships into a shared description, we are doing something with a formal name: building an ontology. In plain English, an ontology is an organised vocabulary and map of a subject.

This article starts from that ordinary use of language and explains three connected ideas from scratch. First, ontology helps us decide what things exist in the part of the world we care about and what our words mean. Second, object-oriented programming, or OOP, gives software a structured way to represent those things as objects with identity, properties, behaviour and relationships. Third, UML, the Unified Modeling Language, gives us standard diagrams for seeing those same ideas from different angles. You do not need to know programming, ontology or UML before reading this article.

The title borrows playfully from the 1987 comedy film Planes, Trains and Automobiles. You do not need to have seen it. We will use only a couple of light references to its chaotic journey as familiar examples of people, vehicles, places, actions and relationships. The real aim is practical: to show how these ideas can help us understand, explain and visualise complicated things clearly, not only in software engineering but in almost any domain we want to model.

1. Ontology: a name for the way we organise what exists

The word ontology sounds far more specialised than the basic idea actually is. In practical terms, an ontology is an organised description of the things that exist in the part of the world we care about, what kinds of things they are, what qualities they can have, what they can do, and how they relate to one another. You can think of it as part dictionary and part map. The dictionary says what our terms mean. The map says how those meanings connect.

We already build informal ontologies every day. If we talk about transport, we distinguish vehicles from passengers, cars from trains, engines from wheels, journeys from destinations, and actions such as driving, boarding or stopping. We may never use the word ontology, but we are still deciding what kinds of things exist in our description and how they fit together.

Language is the easiest way to see this happening. Grammar is not the same thing as ontology, and the mapping is never perfectly one-to-one, but ordinary parts of speech give us useful clues about what may need to be represented:

• Common nouns suggest kinds or categories: vehicle, car, train, aeroplane, engine, passenger.
• Proper nouns or names suggest particular instances: Chicago, Train 401, a named aircraft, or a particular car.
• Adjectives suggest properties or states: red, late, damaged, electric, full.
• Verbs suggest behaviour, actions or events: drive, board, stop, depart, arrive.
• Adverbs add context to behaviour: slowly, safely, repeatedly.
• Numbers and quantifiers suggest constraints: one engine, four wheels, many passengers.

Relational phrases tell us how things connect: a car has an engine; a passenger boards a train; a journey uses a route. Once these meanings are made explicit and organised, we have the beginnings of an ontology. The point is not to create an elaborate philosophical system. The point is to make the meaning of our world clear enough that people, diagrams and software can all talk about the same things consistently.

Image 1. From language to an ontology: words become categories, relationships and a clearer model of the world.

2. From ontology to objects

Object-oriented programming, usually shortened to OOP, grew as a way of representing systems in software using objects. The useful idea comes before the code. OOP asks a very human set of questions: What are the things? What information belongs to each thing? What can each thing do? What other things is it connected to?

A class describes a kind of thing. Vehicle is a class. Car, Train and Aeroplane can also be classes. An object is one actual instance of a class: a particular car, a particular train service, or a specific aircraft. This is close to the linguistic distinction between a common noun and a particular named thing. The class Car describes the kind; one specific car is the object that exists in the world.

Properties describe the state or qualities of an object. A car might have colour, speed, registration and engine type. Behaviours describe what it can do: start, stop, accelerate, steer, carry passengers. Relationships describe how objects are connected: a Car has an Engine; a Passenger occupies a Seat; a Journey follows a Route.

Image 2. OOP concepts with vehicles: inheritance, encapsulation, abstraction and polymorphism as practical modelling ideas.

3. The four core OOP concepts

The four core OOP concepts become much easier to understand when they are tied to ordinary objects rather than code syntax.

Encapsulation

Encapsulation means treating an object as a coherent thing that keeps its internal state and behaviour together. A car contains fuel level, engine temperature, battery state and speed, but a driver normally interacts through safe controls such as start, steer and brake. The object presents a usable boundary around its internal complexity.

Abstraction

Abstraction means showing the features that matter for a particular purpose while hiding detail that does not. A dashboard is a perfect real-world example. The driver sees speed, warning lights and controls, not a live diagram of pistons, wiring, gearbox teeth and fuel injection. The hidden machinery is still real. It is simply outside the level of detail needed by the driver.

Inheritance

Inheritance is a way of expressing an is-a relationship between a general type and a more specialised type. A Car is a Vehicle. A Train is a Vehicle. An Aeroplane is a Vehicle. Shared characteristics can live at the broader Vehicle level, while the specialised types add their own properties and behaviour. For example, Wheeled Vehicle might define a wheel count, while Motorcycle specialises that as 2 wheels and Car commonly as 4.

Polymorphism

Polymorphism means that the same broad operation can make sense across different specialised objects even though each carries it out differently. A Vehicle might be asked to travel or stop. A car travels on roads, a train on rails, and an aeroplane through the air. The common concept lets us reason at the Vehicle level, while each specialised type retains its own implementation and behaviour.

4. Generalisation and specialisation

Generalisation and specialisation are not usually counted as two extra OOP pillars. They describe how types are organised. Generalisation moves upward from the specific to the broad: Electric Car to Car to Vehicle. Specialisation moves downward from the broad to the specific: Vehicle to Train to Freight Train.

This movement is one of the most useful ideas in modelling. Moving upward asks, What do these things have in common? Moving downward asks, What makes this type different? A good model moves between both levels. Too much generalisation becomes vague. Too much specialisation produces a forest of tiny categories. The useful level depends on the question being asked.

5. UML: drawing different views of the same world

UML, the Unified Modeling Language, is a family of diagram types developed for modelling systems. For our purposes, its value is not that it belongs to software engineering. Its value is that it gives us a compact visual language for structure, behaviour, interaction and change. We do not need every UML diagram. A handful cover most real-world modelling needs.

Class and object diagrams

A class diagram is the natural visual bridge from ontology into an object model. It shows types such as Vehicle, Passenger, Engine and Journey, along with important properties, behaviours and relationships. It can also show inheritance, so Car, Train and Aeroplane can all sit beneath Vehicle.

An object diagram moves from the type to the actual instance. If a class diagram says that a Car can have a driver and passengers, an object diagram might show one specific car at one specific moment, with a particular driver and passenger. The class is the description of a kind of thing; the object is the instantiated thing that actually exists in the modelled world.

Multiplicity makes relationships precise. A Car might have exactly 1 engine. A Passenger may have 0..* pieces of luggage. A Train may have 1..* carriages. A Journey has 1 origin and 1 destination. The notation is compact, but the question is ordinary: how many of these can be related to how many of those?

Image 3. Class, object and multiplicity: types, instances and how many things can relate.

Use case diagrams

Use case diagrams describe a system from the outside. They focus on actors and goals rather than internal structure. A Passenger might want to book a ticket, check a departure, board a vehicle, collect luggage or request a refund. This is useful because it keeps the model connected to what people are actually trying to accomplish.

Image 4. A use case diagram: modelling goals from the passenger’s point of view.

Sequence and activity diagrams

A sequence diagram shows who or what interacts, and in what order. A Passenger requests a ticket, a Ticketing Service checks availability, a Payment Service confirms payment, and a ticket is issued. The vertical direction represents time. Sequence diagrams are particularly good when the order of messages or interactions matters.

An activity diagram describes flow. It can show actions, decisions, branches and alternative paths: choose a service, buy a ticket, board, travel, arrive. If a service is cancelled, the flow may branch to rebooking or refund. Activity diagrams are closer to a flowchart and are useful for understanding processes rather than objects.

Image 5. Sequence and activity diagrams: one journey shown as interactions over time and as a flow of actions.

Component diagrams

A component diagram steps back and shows major parts and dependencies. A vehicle might be represented through engine, braking, steering, electrical and cabin systems. A railway service might be shown through ticketing, scheduling, signalling and rolling-stock components. The aim is not to expose every nut and bolt, but to show the main building blocks and how they depend on one another.

Image 6. One world, different modelling lenses: components, ontology, object models and UML views.

6. One world, several useful lenses

The most important idea is that ontology, OOP and UML are not competing descriptions. They operate at different levels. The ontology establishes the vocabulary and meaning of the subject we are describing. Object-oriented thinking organises that vocabulary into things with identity, state, behaviour and relationships. UML then gives us different visual views of that model.

The same domain can therefore be understood in several ways. A class diagram answers what kinds of things exist and how are they related? A use case diagram asks what are people trying to achieve? A sequence diagram asks who interacts with whom, and in what order? An activity diagram asks what happens next? A component diagram asks what are the major parts? Each view hides some detail so that another kind of structure becomes easier to see.

This is modelling at its most useful. We are not trying to turn reality into code. We are choosing a language and a picture that make one part of reality easier to think about, communicate and change.

These same ideas also matter when we work with AI. If we can name the important things, define their relationships, distinguish general rules from specialised cases, and make desired and undesired behaviour explicit, we can communicate a much clearer model of what we want. Part 2 will take that next step and look at how ontology, object thinking and visual models can help us specify context, constraints and behaviour for AI systems.

7. Language, OOP and UML at a glance

Ontology gives us a shared vocabulary and map of meaning. OOP gives us the object model. UML gives us the pictures.

Language clue	Ontological meaning	OOP term	Useful UML expression
Common noun	Kind or category of thing	Class / type	Class in a class diagram
Proper noun or named thing	Particular thing	Object / instance	Object diagram instance
Adjective	Quality or state	Attribute / property	Attribute on a class or object
Verb	Action, behaviour or event	Operation / behaviour	Operation, activity or message
Adverb	Manner or context of action	Constraint / parameter / state context	Note, constraint or activity detail
Is a	Type hierarchy	Inheritance / generalisation	Generalisation arrow
Has a / uses	Relationship between things	Association / aggregation / composition	Association line and symbols
One, many, optional	Quantity in a relationship	Multiplicity / cardinality	1, 0..1, *, 1..*
Goal	What an actor wants to achieve	Use case	Use case diagram
Interaction over time	Ordered communication	Message / interaction	Sequence diagram
Process and decisions	Flow and branching	Activity / workflow	Activity diagram
Major part of a system	Structural building block	Component	Component diagram