- Fundamental Organization
- Of a System
- Embodied in Its Components
- Their Relationships to Each Other
- Their Relationships to the Environment
- Principles Governing Its Design
- And Evolution
- Summary
Their Relationships to the Environment
Systems never operate in a vacuum. In some cases, they may be the only software running on the hardware at hand, in which case that hardware is their primary environmental concern. However, most of the time, systems run on top of or as part of some other system.
For example, consider the relationship between a program (a system) and the operating system on which it runs (also a system). Operating systems impose a fundamental organization on the programs they host. This organization is inescapable: The programs are started by the operating system and, to a lesser or greater extent, the operating system monitors and controls the program during execution and through termination. Without some basic agreement between the two, these programs would never run.
Operating systems vary immensely in regard to how much of the fundamental organization of a program they define. In the Unix model, for example, the imposed organization is quite limited. Programs are started by invoking a function with a well-known name (“main”) and set of arguments, so those elements must exist. To be sure, the typical structure of Unix programs encompasses many conventions and APIs. But very little of that is truly required. As a result, Unix successfully and easily supports writing programs of many types, languages, and structures.
The iOS platform, by comparison, is much more opinionated. iOS applications do not have a single entry point but rather a whole set of functions they are expected to respond to. Much of this has to do with the life cycle of these applications. In the Unix model, programs start, run until they’re done with the task at hand, and then exit. On iOS, applications are started, brought to the foreground, moved to the background, stopped to preserve resources, restarted due to user interactions or notifications, and so on. It’s much more complicated!
On Unix, you can use the fundamental organization of an iOS program if you want to. Again, Unix doesn’t impose its organization; the program designer has significant discretion. But on iOS, your application largely needs to be fundamentally organized around a model dictated by iOS. This relationship of the program to the iOS environment becomes a major driver of the program’s architecture.