In the intricate realm of aircraft systems design, abstraction is the process of simplifying complex realities by focusing on the higher-level structure and behavior, while ignoring the finer details unless they're absolutely necessary. Abstraction allows object modelers, like yourself, to conceptualize and design aircraft systems by understanding and representing only the necessary details at any given level of the design.
- Cohesion and Coupling: Evaluative Metrics:
Two foundational metrics for assessing object quality in system design are cohesion and coupling:
- Cohesion deals with how closely the responsibilities of a particular module or component are related to each other.
- Coupling pertains to the degree of direct knowledge or dependency that one module has over another.
- Abstraction's Role in Assessing Object Quality:
- Ensuring High Cohesion through Abstraction:
Abstraction helps in defining clear boundaries around components by focusing on their core responsibilities. In aircraft systems:
- At a high level, you might abstract systems like "Navigation," "Propulsion," or "Communication."
- When delving deeper into the "Navigation" system, you might have sub-components like "GPS Module," "Altimeter," and "Auto-pilot Controller."
Each of these components and sub-components should have a clearly defined and singular purpose, ensuring high cohesion. A well-abstracted "GPS Module," for instance, should solely focus on tasks related to GPS, such as fetching coordinates, and not mix concerns like communication or propulsion.
- Minimizing Coupling through Abstraction:
Abstraction allows object modelers to define interfaces or service contracts between components. This ensures that components communicate or interact only through well-defined pathways, reducing the chances of unintended dependencies.
- For instance, the "Auto-pilot Controller" might need data from the "GPS Module." Through abstraction, you can ensure that the controller accesses only what's necessary (like the current coordinates) and remains oblivious to the inner workings of the GPS Module, thus minimizing coupling.
- This is particularly vital in aircraft systems, where changes in one module (say, an upgrade to the GPS hardware) shouldn't necessitate changes in another module (like the "Auto-pilot Controller"), ensuring system safety and reliability.
- Layered Abstractions for Object Quality Assessment:
Abstraction can often be multi-layered, especially in complex domains like aircraft systems. At the top-most layer, you might be dealing with entire systems, at the next, sub-systems, and further down, specific modules or classes.
- By ensuring high cohesion and low coupling at every layer of abstraction, you can establish a cascading effect of quality. It ensures that the system as a whole, and in its individual parts, is robust, maintainable, and adaptable to changes.
In the challenging and critical domain of aircraft systems design, abstraction plays a pivotal role in shaping the quality of object design. By fostering high cohesion within components and minimizing coupling between them, abstraction not only ensures that each component is optimal in its function but also guarantees that the overarching system remains modular and maintainable. The combined use of cohesion and coupling metrics, within the framework of abstraction, is instrumental in crafting aircraft systems that are both robust in function and resilient to change.
A particular strength of modeling is that it reveals our assumptions. Without reading thousands of lines of code, we can
- measure communication traffic,
- evaluate quality by assessing coupling and cohesion, and
- test our models before we write faulty code.
Modeling accomplishes these objectives by raising the level of abstraction. Back in the 1980's and 1990's we wrote Assembler code, just one level above machine language. Then we moved to third-generation languages such as COBOL and PL/I (Programming Language One)
The assembly programmers of the time thought COBOL just couldn't do what Assembler could do and would eventually go away.
They insisted that to write applications, you had to know how the machine really works. How many of you (other than game programmers) write any Assembler today, let alone develop systems with it?
Compare that with the hundreds of millions of lines of COBOL code are in production today and the problems it caused prior to Y2K.
The Assembler programmers were missing an essential fact in their machine code. That is, the only reason to write code is to solve a problem.
The machine and the languages are tools to solve a problem, not the end itself. Still today, when our focus is forced onto the technology (Java versus C++, JSP versus ASP, NodeJS versus C#) and away from the
problem, we risk losing sight of our real purpose and the factors that define true success, and that is not whether the code is finished,
but does the application do what we need it to do and can it survive the inevitable changes?
UML is an attempt to express in precise, familiar, and consistent language everything needed to
generate complete, stable, maintainable systems. UML is a level of abstraction above the
current programming languages, just as PL/I was a level above Assembler.