Abstraction and Model Limitations

Suppose a campus route planner must find a path between buildings. A graph can represent buildings as vertices and walkways as edges. If the task is to minimise walking distance, an edge weight can record distance. Wall colours and the make of a nearby vending machine can be omitted because they do not affect that calculation.

Abstraction is selective representation rather than simply deleting as much data as possible. Keeping only building names without connections would remove information essential to route finding. Identify the entities, relationships, values and constraints that the algorithm needs, then explain why each retained feature matters to the output.

One edge between two vertices compresses the details of a physical walkway. It may omit bends, surface quality, congestion or temporary closure. If the recorded weight is an estimated walking time, it may vary by user or time of day. A mathematically optimal answer for the graph need not be the best real journey under omitted conditions.

A model should state its assumptions, such as all represented routes being open and weights being non-negative. Test the representation against cases that challenge those assumptions. A route accessible to one user might include stairs that another cannot use; this is a domain constraint, not merely a cosmetic display preference.

For an accessibility requirement, add relevant edge attributes or exclude unsuitable edges for the requested user. For temporary closures, supply current status and decide how stale data are handled. More detail can improve fit but also increases data collection, maintenance and computational work. Keep detail proportional to the task.

The same real system can have several useful abstractions: a navigation graph, a room-booking timetable and an energy-use model focus on different relationships. Evaluate a proposed abstraction by tracing one input through the intended calculation and asking which facts it needs. Explain a limitation with a specific possible consequence, rather than the vague statement that the model is unrealistic.

Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.