If you decided to create some abstractions to explain the architecture of existing software, it is unlikely that you would end up with the standard set of architecture abstractions (components, connectors, ports, roles, etc.) The standard set of architecture abstractions seeks to point future software development in the right direction, and so it is prescriptive in that it encourages encapsulation and clear channels of communication.
When we document existing systems, we are simply describing them as they are. Consequently, there are some challenges when we try to simply describe software that does not conform to our ideals. Much of what we find is beautifully designed, but not everything. We will have trouble with systems that have no internal subdivisions and are a bowl of object soup. We will have trouble with “glue code” that expediently interconnects other systems and is often written in terse scripting languages. Above all, we will have trouble with frameworks because while our abstractions encourage encapsulation with components and narrow interfaces defined in ports, frameworks often reveal their implementations through inheritance hierarchies and have wide and poorly defined interfaces.
Note to Kevin and Ciera, if you are reading this: we still need to write that paper on the framework definition language, which would be the first step towards reconciling architecture abstractions and frameworks.
Rhino Research is devoted to improving the state of software practice. We do this by using our industrial and academic roots to give you the freshest and most practical advice in classes and during consulting engagements.
We have taught classes for many kinds of clients, ranging from regular information technology shops, to huge internet shops, to NASA.
subscribe via RSS
