{'fraction_non_alphanumeric': 0.025225225225225224, 'fraction_numerical': 0.0036036036036036037, 'mean_word_length': 5.652694610778443, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
The Three‐Layer architectural pattern applied to plug‐in‐based architectures: the Eclipse case

The process of designing a software architecture using different kinds of components is often challenging. Different designs support some quality attributes while damaging others; therefore, trade‐off analysis is needed to make informed decisions. Moreover, analysis made in theory needs to be complemented with observations in practice, especially when using a particular set of technologies to implement the system. In this paper, we present a particular instance of this problem. We study how the Three‐Layer architectural pattern may be developed using plug‐ins. We compare two extreme alternatives according to several representative scenarios and their impact in some quality attributes. Then, we apply this theoretical knowledge to a case study, the implementation of a plug‐in‐based tool for managing architectural knowledge using Eclipse. We report some unexpected difficulties found that forced us to adapt the theoretical solution into an operative architecture. Copyright © 2012 John Wiley & Sons, Ltd.