In this lesson, we will discuss patterns, their relationship with tactics and how you can document your architecture. Architectural patterns are common architectural structures which are well understood and documented. They describe the high level structure and behavior of software systems as the solution to multiple system requirements. Where aesthetics are design decisions that improve individual quality attribute concerns. In soccer, a coach can use several well known patterns to support his strategy. A 4-3-3 lineup is a common soccer pattern that is well known. Each pattern describes a problem which occurs over and over again in a certain environment. And then describes the core of the solution to that problem in such a way that you can use the solution a million times over. Architectural patterns contain the major components and connectors of the system to be built. They are chosen in response to early design decisions. Including decisions about how to satisfy functional and nonfunctional requirements such as quality attributes. Architectural patterns provide the major structures in which multiple design decisions are realized. There is a close relationship between architectural patterns and tactics. Tactics are the architectural building blocks from which architectural patterns are created. Patterns are composed of tactics similar to how soccer formations are composed of individual tactics such as the wide defender, the sweeper, or the central striker. The selection of tactics helps to determine the architectural patterns that will be used which then leads to further selection of tactics. We see that patterns, while they maybe largely composed of tactics, also provide a starting for incorporation of new tactics to support other quality attributes or to customize the pattern to a specific problem and context. Every design uses multiple tactics and understanding what attributes are achieved by them, what their side effects are, and the risks of not choosing other tactics is essential to architecture design. There is a difference between architectural patterns and design patterns. Architectural patterns can be used at the beginning of coarse grained design when specifying the fundamental structure of an application. They have a broader scope, support system less on design decisions, and have system wide consequences. The component types and architectural patterns are subsystems or modules. Layers, pipes and filters, blackboard, broker and modern view controller or MVC are examples of architectural patterns. Design patterns are applicable towards the end of coarse grain design, when refining and extending the fundamental architecture of a software system. They are applicable is the detailed design stage for specifying local design aspects. The component types and design patterns are classes or templates. Examples are the generic templates for list iterators or algorithms that implement search and sort functions or specialized classes like a singleton class, a decorator or an observer. In race car design the architectural pattern decides, if you put an engine in the front, middle or back of the car. While the engine design pattern would make a decision about a v6 or v8 engine with or without turbo chargers. Some patterns exist both as design patterns and as architectural patterns, but are applied in a different way with different purposes. Examples are the publisher subscribe pattern and the MVC or model view controller pattern. An architectural pattern establishes a relation between a context, a problem, and a solution. A context is a situation giving rise to a problem like developing software systems with a flexible user interface, transforming data flows in real time or processing events in sensor networks. The context is often described as a particular system or architecture style like data flow, virtual machines, data centric, service oriented, event based, or real time systems. The problem is the recurring problem arising in that context. The description of the problem includes requirements that the solution must fulfill. Constraints that must be considered or desirable properties. Those often include the quality attributes to be met. The solution is a solution with a particular structure, such as components and their relationships, and the behavior and interactions between these components. The solution for our patron is determined and defined by four elements, the components types, the relations between these components, the topological layout, and the set of semantic constraints. The components types can be clients, server, broker, layer, publisher subscriber etc. The relations between these component types describe the relationship, such as notifies or is allowed to use, and interaction methods such as, let it count an event [INAUDIBLE]. The particular topology of the architecture structure defines the rules and guidelines for organizing the relationships between the components. And the set of semantic constraints covers the details of topology. The component behavior and the interaction mechanisms. Applying patterns is not an all or nothing proposition. In may cases software architects change things in the patterns, according to the trade offs they make for the specific case they are working on. This results in many different versions of a specific pattern. Modem view presenter for example, is a derivative of the modem view controller pattern, where the view cannot directly retrieve information from the modem, but all data has to go through the presenter. Patterns can also be combined or tactics can be edit to solve specific existing problems. To document the architecture you have made for your specific project, we use both static and dynamic views on the system. The static view shows an overview of the different components of the system and how they are connected to each other. We use a UML component diagram to visualize this view. If we want to show how the different components related to hardware, we use an undeployment telegram to make clear where each component resides on the physical hardware. To document the dynamic behavior of the system, we use UNM sequence diagrams. The sequence diagrams visualize the different steps that the system takes when executing a specific scenario. They show the interaction between the different components and often may the architecture a lot easier to understands. In most cases you will have one component diagram, one deployment diagram, but multiple sequence diagrams. There should be enough sequence diagrams to make the architecture clear for someone who is new to it. Veterans can be categorized in many different ways. And different sources of pattern catalogs often use a different structure. Some sources structure the patterns based on application domain, such as security or data processing systems. Other sources structure them on the type of pattern, such as patterns that divide the system into modules or into components and connectors. This sometimes makes it hard to find the patterns you need. In this lesson we explained what an architectural pattern is. How it relates to tactics and how you can document the instantiation of the pattern to your problem.
