Combined Views

The basic principle of documenting an architecture as a set of separate views brings a divide-and-conquer advantage to the task of documentation, but if the views were irrevocably different, with no relationship to one another, nobody would be able to understand the system as a whole. Managing how views are related is an important part of the architect's job, and documenting it is an important part of the documentation that applies beyond views, as we see in Section 10.3, which explains how to recognize when elements in two different views represent the same entity within the system or when the second element is a transformation of the first.

Sometimes, the most convenient way to show a strong relationship between two views is to collapse them into a single combined view. Combinations can be among views or among styles. The choice of whether to combine a particular set of views or styles is partially dependent on the importance, persistence, and ongoing usefulness of the resulting new view or style. Defining a new style imposes certain obligations with respect to the documentation. A new style must be documented in the same fashion as one of the styles we have described in this book. Creating these materials is important if the style is used throughout a particular system and multiple stakeholders need to be familiar with it. Sometimes, however, a combined view is created for a single, short-term purpose: to do analysis or communicating, for example. For these short-term purposes, creating the required documentation for a new style is burdensome overhead. To differentiate these two cases of combined views, we introduce the terms hybrid style, and overlay.

DEFINITION

A combined view is a view that contains elements and relationships that come from two or more other views.

DEFINITION

A hybrid style is the combination of two or more existing styles. It introduces the same documentation obligations as any of the styles introduced earlier in this book. In addition, the mapping between the styles that constitute the hybrid must also be documented. Hybrid styles, when applied to a particular system, produce views.

So now an architect has three ways to establish a mapping between otherwise standalone styles or views:

DEFINITION

An overlay is a combination of the primary presentations of two or more views. It is intended for short-term use. An overlay has the same documentation requirements as a primary presentation ofanimtext4 a normal view; for example, a key must be provided. But an overlay introduces no additional documentation obligations beyond those of a primary presentation and a definition of the mapping among the constituent views.

6.3.1 When to Combine Views

Producing a useful combined view depends on understanding the mapping among the constitutent views or styles. A combined view can be produced from different views of the same overarching viewtype. For example, the modules defined in a module uses view can be mapped to layers described in a layered diagram because both belong to the module viewtype. A combined view also can be produced from views of different viewtypes. For example, layers of a layered style, which belongs to the module viewtype, can be mapped to processes in the communicating-processes style, which belong to the C&C viewtype.

The styles we have presented in this book are each intended to deal with a small set of coherent and common concerns. In order to accomplish many of the uses of an architectural description, an architect must understand concerns from several of these "atomic" styles. During a performance analysis, for example, both the set of responsibilities from a view based on a module viewtype style and the synchronization behavior of the processes derived from those modules provide important information. The set of responsibilities are useful in order to derive the resource requirements. These two sets of information combine to enable a schedulability analysis. When the architecture is being communicated to stakeholders, multiple views are necessary to provide sufficient information to enable complete understanding. When the architectural documentation serves as a blueprint, the developer must understand the prescriptions included in various views in order to correctly implement the system. Keeping these concerns separate facilitates clarity of presentation and enhances understanding.

ADVICE

Many Separate Views or a Few Combined Ones?

  • When considering a combined view, make sure that the mapping among the constituents is clear and straightforward. Otherwise, these views are probably not good candidates to be combined, as the result will be a complex and confusing view. In this case, it would be better to manage the mapping in a tablein the documentation that applies beyond viewsthat relates the views while keeping them separate. A mapping table has the space to make the complex relationships among the constituents clear and complete.

  • Large systems tend to require more views. In large systems, it is important to keep concerns separate, as the impact of an error caused by mixing concerns is much greater than in a small system. Also the relationships among views in large systems tend to be more complicated, which, according to the first rule of thumb, argues for maintaining separate views. Furthermore, reasoning about the properties of the system is simplified when it is clear where in the documentation the input into the reasoning framework can be found. Consequently, the larger the system, the more it makes sense to keep views distinct.

  • Too many different concepts clutter up combined views. Keys and the plethora of relations shown in the primary presentation all become difficult to understand. Before committing to a combined view, sketch it to see whether it passes the "elevator speech" test: Could you explain the idea behind it to someone in the time it takes to ride an elevator up a dozen or so floors?

  • Different groups of workers need different types of information. Make your choice of views responsive to the needs of your stakeholders. Before committing to a combined view, make sure that there is a stakeholder "market" for it.

  • Tool support influences the choice and number of views. The cost of maintaining multiple views is partially a function of the sophistication of the available tool support. If your tool understands how a change in one view should be reflected in another view, it is not necessary to manage this change manually. The more sophisticated the tool support, the more views can be supported.

  • If the the mapping is clear and straightforward, the combined view won't be overly complex, a consumer group for the combined view has been identified, and is the same group as for the constituent views, it makes sense to adopt the combined view in place of the separate constituents.

On the other hand, the developer incurs the mental overhead of having to use separate documents and keeping the relationships among them straight. Such a developer might grumble, with some justification, that the information needed to do his or her particular job is scattered over several places. Additionally, there is a cost for maintaining multiple views. Multiple views tend to get out of synch as they evolve, and a change to one now precipitates a change to three documents: the two affected views and the mapping between them. Hyperlinking the documents helps, but the developer still has to visit all the places and make appropriate adaptations. Thus, there are good reasons to keep the number of views to a minimum.

The set of views used for a system, then, is the result of a trade-off between the clarity of many views, each of which has a small number of concepts, and the reduced cost associated with having a small number of views, each dealing with multiple concepts.

Use caution in combining views. Remember, views that can be mapped to one another should be so mapped, whether or not you create a hybrid or an overlay to do it. At a minimum, simply produce the mapping prescribed in Section 10.3, and leave the views separate.

6.3.2 Types of Mapping

In a many-to-one mapping (see Figure 6.12), multiple elements in one view are mapped to a single element in another view. Modules are frequently mapped to processes in this fashion. The mapping should make clear which module maps to which process.

Figure 6.12. Many-to-one mapping. Multiple elements from one view can be mapped to a single element of another view. As shown here, two modules from a decomposition view are designed to run in a single process, shown in the communicating-processes view.

In a one-to-many mapping (see Figure 6.13), a single element can be mapped from one view to multiple elements in another view. For example, a communications module may be mapped to multiple processes in an n-tier client-server style.

Figure 6.13. One-to-many mapping. An element of one view can be mapped to multiple elements in another view. Although the architect must make it clear, this normally implies that the complete functionality of element 1 is replicated when mapped to Elements 2 and 3 of View B. This mapping may mean that several instances of Element 1 are created or that a functionality is used by several elements of View B.

A one-to-many mapping could denote replication, as shown in Figure 6.13, or a splitting of elements, whereby parts of the functionality of element 1 of view A map to element 2 of view B, and the rest of the functionality of element 1 maps to element 3. In this case, it must be clear which parts of the split element map to which elements of view B. The split functionality might introduce additional dependencies among the parts. These dependencies introduce additional relationships between elements 2 and 3, which may not have been considered.

As much as we would like to have a one-to-many or a many-to-one mapping, it is more likely that a many-to-many mapping occurs, with a set of elements in one view mapping to a set of elements in another. Here, element splitting abounds. These mappings reflect the inherent complexity in relating two views to each other, each of which was crafted to show a few important aspects that in many ways might be orthogonal.

At this point, the first rule of thumb given previously applies: A complex mapping suggests keeping the views apart and maintaining their mapping separately. However, given compelling reasons to override this rule and produce a combined view, you can make your task easier by redrawing the constituent views first to split the elements into carefully defined pieces that will then map to their counterparts straightforwardly.

6.3.3 Elements, Relations, and Properties

In hybrid styles, elements and relations of the constituent styles can "melt" into new element types with new properties; in overlays, elements and relations are put together in a view without changing the type. Therefore, hybrid styles require the definition of the resulting element and relation types, but overlays do not.

Hybrid Style

The element types of a hybrid style often include a composite of the element types of the constitutents. So, for example, if the combined view is a mapping from a layered style to a communicating-processes stylea common practicethe element type could be layered process, and this type would need to be defined as the element of the hybrid style.

The relations of a hybrid view are derived from the relations of the constituent styles and the mapping among the styles. Not all relations of the constituent styles need be shown.

Deriving relations in a hybrid view can result in the definition of connectors. Using again the hybrid of a layered style and a communicating-processes style, the allowed-to-use relation between layers defines a connector type between the processes. This connector ensures the correct communication pattern between layered processes.

Properties of the elements and the relations of a hybrid style will usually be a subset of the properties of the elements and the relations of the constituent styles, along with the properties that derive from the mapping. Which properties need to be shown in a mapping depend on which aspect of the architecture will be documented or analyzed. If the mapping is used to analyze performance, all performance-related properties from elements and relations of all the views that are mapped need to be available.

Overlay

In an overlay, the elements and the relations keep the types as defined in their constituent styles. Usually, an overlay view shows only a subset of the combined elements and relations with a mapping added. What is included in the view depends on what the overlay is intended to present. The same is true for the properties of elements and relations. What is included depends on what should be uncovered.

6.3.4 Documenting Combined Views

Figure 6.12 showed how multiple modules might map to a single process. Figure 6.14 shows how that mapping might be documented using a combined view.

Figure 6.14. Multiple elements from one view can be mapped to a single element of another view. Here module Elements 1 and 2 from a module view are designed to run in a single processElement 3shown in the communicating-processes view. The resulting combined view shows all three elements, of the module and communicating-processes views, and their containment relation.

In Figure 6.13, we showed how an element of one view mapped to more than one element of a second view. In Figure 6.15, we show how to represent this as a hybrid view. If elements 2, 3, and 4, for example, are components of a C&C view and element 1 is the functionality to store and to retrieve data within a component, designed as a class in a decomposition view, mapping element 1 onto elements 2 and 3 makes those elements "persistent components." In fact, element 1 of the decomposition view became a property of an element in the hybrid view. As you can see, hybrid views can be very useful as long as you do not try to overload them with too many mappings.

Figure 6.15. In this example, mapping Element 1 of View A onto Elements 2 and 3 of View B resulted in a new type of element, depicted as a new shape. This required the definition of a new type in a style.

6.3.5 Examples of Combined Views

N-Tier Client-Server

In Chapter 4, n-tier client-server was discussed as a component-and-connector style. In some contexts, however, the term refers to a combination of that style with the deployment stylein other words, a hybrid style.

DEFINITION

A tier is a mechanism for system partitioning. Usually applied to client-server-based systems, where the various parts (tiers) of the system (user interface, database, business application logic, etc.) execute on different platforms.

The n-tier client-server architecture, a mainstay of business and Internet data processing systems, was created as the natural descendant of mainframe systems supporting scores of users on dumb terminals. Later, those terminals were replaced by PCs, which inherited some of the systems' processing responsibilities, such as user interface management. This freed the mainframe to do more work and therefore support more users. Two-tier systems divided functionality between the computation necessary to support users with graphical user interfaces on the PCs, or clients, and the computation necessary to store and compute data as necessary on more powerful machines, or servers.

The three-tier architecture that emerged in the 1990s to overcome the limitations of the two-tier architecture features a middle tier between the user interface, or client, and the data management, or server, components. This middle tier, where process management resides and business rules are executed, provides a further separation of concerns in the overall system, making it easier to change these things in isolation. The three-tier design features better performance than a two-tier system and thus can support more users.

The three-tier system also provides high flexibility by making it straightforward to reassign processing responsibilitiesthat is, move softwarefrom tier to tier to enhance performance. For example, an underutilized middle tier might be assigned to handle database staging, queuing, transaction management, distributed database integrity, and the like. Also, software on different tiers can be developed in different languages, using different development environments. The segregation to different machines helps enforce modularity of the software and strict adherence to interfaces.

It should be clear by now that in this context we are talking about an architectural style in which a hardware configuration is inextricably bound up with a division of software functionality into tiers that communicate in the client-server fashion. Figure 6.16 illustrates this. The essence of n-tier systems is the ability to move software from platform to platform to enhance performance, failure recovery, functionality, or scalability.

Figure 6.16. A three-tier system showing it to be an overlay between a client-server view and a deployment view

6.3.6 Other Examples

Figure 2.11 shows an overlay that combines the module decomposition and layered styles. Figure 6.1 shows an overlay combining the shared-data and pipe-and-filter views.

Related

Категории