Advances in Computer Architecture - by Glenford J. Myers is probably an old book in computer terms - the second edition was published in 1982 (first edition in 1978) and I was expecting it to be a curio. But I found it interesting because it was focused on Computer Architecture in terms of “viewing a system as a set of levels of abstraction.” And I use the ‘abstraction’ word a little too often, making this book relevant to my studies.
Given a set of abstractions, then look at the function boundary that the architecture deals with and the interface that it provides to the user. Myers also identifies that some Architecture levels are hard to show on a level diagram because they require vertical rather than horizontal cuts.
Abstraction layers overlap because they deal with different use cases and different users. If we only horizontally layered abstractions then we could make the case for overly tight coupling and too many layers. If we accept vertical, horizontal, diagonal and ‘other’ cuts then we are more likely to concentrate on creating abstraction layers that make it easier for the user to solve problems rather than for the implementor of the abstraction layer.
“Computer Architecture is the abstraction or definition of a physical system as seen by a machine-language programmer or a compiler writer” pg 6On page 17 Myers discusses The Semantic Gap. In the book Myers is concerned about large Semantic Gaps between programming concepts and operating system implementation because either the application writer has to write code to bridge that gap which can make the applications more error prone or longer to write.
We often turn to libraries to help us plug these semantic gaps when writing applications.
The remainder of the book is a discussion of different architectures looking at how they support the writing of applications and the overlap between the abstractions required to model the system and the implementation in different machines and processors.
I found the final chapter relevant to my work when automating applications and constructing abstraction layers to make the automated execution easier to write and maintain. The final chapter lists some goals and tools for consideration by the architect:
- Strive for Conceptual Integrity
- Strive for Orthogonality
- Know your audience
- Optimize for usage
- Design for Extensibility
- Strive for implementation independence
- Avoid a Technology Dependent Design
- Do a formal description of the architecture
- Be a compiler periodically
- Prove a mapping from language to machine
- Avoid Committee Decision Making
voidor a domain object. Either do return Page Objects or use Navigation Objects - this principle doesn’t mean ‘get it right’ it means ‘decide’.
We can do this by refactoring our code - based on experiences of using it to automate the application. Coding to interfaces can also help.
Don’t make it easy to implement, make it easy to understand.
This also helps orthogonality because we will put functions in the interfaces that we use rather than where they are easiest to add.
This boosts flexibility and allows abstraction implementations to be used for Performance Testing, STtress Testing, adhoc Exploration, and defensive checking in Continuous Integration.
Automating and Testing a REST API I show an example of using RestAssured where the actual use or RestAssured is isolated in a ‘messaging’ abstraction that would be easy to re-implement in another HTTP library. My @Test abstractions were independent of the implementation.
I want my abstraction layers to synchronise effectively on application state, rather than rely on timing from a single test environment.
I want my assertions and synchronisation to work cross browser and not be limited to only running on Chrome or Firefox.
35 years old, its not like it was written 000’s of years ago).
I don’t think this book is for everyone I rattled through it because the indepth discussions of the different machines didn’t seem as relevant on this read through as the general concepts.
Myers does have other books that are still very relevant.
- Software Reliability
- Composite Structured Design
- Reliable Software through Composite Design