You are using a framework and you want to know if its architecture is compatible with your application needs. You want to understand how the framework elements are structured and how they relate.
Using or evolving a framework impacts the framework as a whole. The awareness of the full implications of any change to the framework requires a sound notion of the framework’s architecture and how its elements, which map the domain concepts, relate with one another. You need to understand its architecture.
How do you learn about the framework’s architecture, its components and internal relationships?
Framework maturity. A matured framework is likely to be better structured, being easier to identify its main architectural elements.
Documentation. If there is existing documentation that explains the overall architecture, it can be a great understanding aid.
Tools. These can complement the lack of overview documentation, by reverse- engineering the architectural information.
Look into the documentation or any existing reverse-engineered design information and search for instances of architectural patterns [BMR96]. Usually present in a more mature framework, these can indicate its main architectural style.
Browse through the DESIGN INTERNALS [AD07] to identify the main architectural concepts and its relationships. If you need more detail, look for architectural primitives [ZA05]. These can give an incremental view of the overall architecture by identifying interfacing ports between framework components and later, by aggregation, lead to defining a known architectural pattern or structure.
Preserve all the information gathered, adopting a KNOWLEDGE KEEPING strategy.
High-level awareness. There is an awareness of all the framework internal components and how they relate. You can piece together all the framework’s parts to see if it fits your application needs.
Shallowness. Despite being comprehensive, there is no grasp of how the components that relate to each other, interoperate, or how they function internally. You need to further UNDERSTAND THE DESIGN INTERNALS , to be able to know more about their behaviour.
A framework is an architectural abstraction. An architectural abstraction identifies and names composition of elements with a certain structure and functionality. This facilitates communication about designs. A framework provides a set of abstractions that are useful when discussing and describing a domain [JN99]. When a white-box framework is used, it is necessary to understand the concepts and architectural style of the framework in order to develop applications that conform to the framework. Many errors can be avoided and the application can be constructed more efficiently if the framework user understands its strategies and styles. In a matured framework, during design stage, a suitable architectural style was adopted and usually these are known domain-specific architectural patterns.
In [SG96], Shaw and Garlan, first introduce the notion of software architectural styles as a family of systems in terms of a pattern or structural organization. More specifically, it determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined.
In [BRM96], Buschmann et al. presents a pattern catalogue of architectural styles based on the work of Shaw and Garlan and introduces a software design classification system consisting of architectural patterns, design patterns and idioms, covering different perspectives and different abstraction levels.
In [ZA05], Zdun and Avgeriou propose to remedy the problem of modelling architectural patterns through identifying and representing a number of “architectural primitives” that can act as the participants in the solution that patterns convey. According to the authors, these “primitives” are the fundamental modelling elements in representing a pattern and also they are the smallest units that make sense at the architectural level of abstraction (e.g., specialized components, connectors, ports, interfaces). Their approach relies on the assumption that architectural patterns contain a number of architectural primitives that are recurring participants in several other patterns.