Software Architecture as a Combination of Patterns

T he computer science community has introduced design patterns as a means of capturing and documenting solutions to common software problems [1, 2]. An important aspect is the combination of patterns. In " Design Patterns " [1], the authors discuss how patterns dovetail and intertwine in good software. Nevertheless, combining patterns into a good overall architecture has received less attention than the individual patterns. In much of the literature, each pattern is often presented separately along with a discussion of how it fits into a resulting class diagram. This assumes that the class diagram exists when you present your patterns. In this article, we present not only how different patterns are used in software architecture, but also how we evolved the architecture by successively integrating more patterns to deal with particular design problems. We present the individual patterns, their interaction, and the questions that arise when they are combined. The example we use is a software subsystem of a new generation of surveillance radar constructed by Ericsson Microwave Systems (EMW) in Mölndal, Sweden. This subsystem contains the modules that handle tracking, communication with external devices, threat evaluation , etc. A major problem with the software of an earlier radar system was that the modules were too interdependent. If you wanted to use only one part for a new product, you often had to include all modules even though the functionality was not needed. When the new architecture was constructed , one premise was to maximize reuse. The main reason was the business situation for the surveillance radar system. The trend was that each customer bought a small series but still required considerable tailoring to his or her needs. To encourage reuse, the different components had to be made more independent and flexible. A function had to be coupled to as few other components as possible, and direct dependencies had to be eliminated or minimized. An important guideline in the architectural design was the requirement for mod-ifiability. The following sources of modifications were especially considered: 1. Replacement of hardware and operating system. 2. Different customers' functional requirements. In the following, we first discuss how the system was made adaptable to new hardware and software, and then how it was designed to accommodate changes in customer requirements in general and requirements for presentation and control in particular. To facilitate future changes of hardware and operating system, a layered architecture was introduced. The …