The Art : Resolution of Architectural Factors - UML

One could say the science of architecture is the collection and organization of information about the architectural factors, as in the factor table. The art of architecture is making skillful choices to resolve these factors, in light of tradeoffs, interdependencies, and priorities.

Adept architects have knowledge in a variety of areas (for example, architectural styles and patterns, technologies, products, pitfalls, and trends) and apply this to their decisions.

Recording Architectural Alternatives, Decisions, and Motivation

Ignoring for now principles of architectural decision - making, virtually all architectural methods recommend keeping a record of alternative solutions, decisions, influential factors, and motivations for the noteworthy issues and decisions.

Such records have been called technical memos [Cunningham96], issue cards [HNSOO], and architectural approach documents (SEI architectural proposals), with varying degrees of formality and sophistication. In some methods, these memos are the basis for yet another step of review and refinement.

In the UP, the memos should be recorded in the SAD.

An important aspect of the technical memo is the motivation or rationale. When a future developer or architect needs to modify the system, it is immensely helpful to understand the motivations behind the design, such as why a particular approach to recovery from remote service failure in the NextGen POS was chosen and others rejected, in order to make informed decisions about changing the system.

Explaining the rationale of rejecting the alternatives is important, as during future product evolution, an architect may reconsider these alternatives, or at least want to know what alternatives were considered, and why one was chosen.

A sample technical memo follows that records an architectural decision for the NextGen POS. The exact format is, of course, not important. Keep it simple and just record information that will help the future reader make an informed decision when changing the system.

Priorities

There is a hierarchy of goals that guides architectural decisions:

  1. Inflexible constraints, including safety and legal compliance.
    • The NextGen POS must correctly apply tax policies.
  2. Business goals.
    • Demo of noteworthy features ready for the POSWorld trade show - in Hamburg in 18 months.
    • Has qualities and features attractive to department stores in Europe (for example, multi - currency support and customizable business rules).
  3. All other goals
    • These can often be traced back to directly stated business goals, but are indirect. For example, "easily extendible: can add some unit of functionality> in 10 person weeks" could trace to a business goal of "new release every six months."

In the UP, many of these goals are recorded in the Vision artifact. Mind that the Priority for Success scores in the factor table should reflect the priority of these goals.

There is a distinguishing aspect of decision - making at this level vs. small - scale object design: one has to simultaneously consider more (and often globally influential) goals and their trade - offs. Furthermore, the business goals become central to the technical decisions (or at least they should).

Priorities and Evolution Points: Under - and Over - engineering

Another distinguishing feature of architectural decision - making is prioritization by probability of evolution points points of variability or change that may arise in the future. For example, in NextGen, there is a chance that wireless handheld client terminals will become desirable. Designing for this has a significant impact because of differences in operating systems, user interface, hardware resources, and so forth.

The company could spend a huge amount of money (and increase a variety of risks) to achieve this "future proofing." If it turns out in the future that this was not relevant, doing it would be a very expensive exercise in over - engineering. Note also that future proofing is arguably rarely perfect, since it is speculation: even if the predicted change occurs, some change in the speculated design is likely.

On the other hand, future proofing against the Y2K date problem would have been money very well spent; instead, there was under - engineering with a wickedly expensive result. To decide if early "future - proofing" should be avoided, realistically consider the scenario of deferring the change to the future, when it is called for. How much of the design and code will actually have to change? What will be the effort? Perhaps a close look at the potential change will reveal that what was at first considered a gigantic issue to protect against, is estimated to consume only a few person - weeks of effort.

This is just a hard problem; "Prediction is very difficult, especially if it's about the future" (unverifiably attributed to Niels Bohr).

Basic Architectural Design Principles

The core design principles explored in much of this book that were applicable to small - scale object design are still dominant principles at the large - scale architectural level:

  1. low coupling
  2. high cohesion
  3. protected variation (interfaces, indirection, service lookup, and so forth)

However, the granularity of the components is larger — it is low coupling between applications, subsystems, or process rather than between small objects.

Furthermore, at this larger scale, there are more or different mechanisms to achieve qualities such as low coupling and protected variation. For example, consider this technical memo:

Separation of Concerns and Localization of Impact

Another basic principle applied during architectural analysis is to achieve a separation of concerns. It is also applicable at the scale of small objects, but achieves prominence during architectural analysis.

Cross - cutting concerns are those with a wide application or influence in the system, such as data persistence or security. One could design persistence support in the NextGen application such that each object (that contained application logic code) itself also communicated with a database to save its data. This would weave the concern of persistence in with the concern of application logic, in the source code of the classes - so too with security. Cohesion drops and coupling rises.

In contrast, designing for a separation of concerns factors out persistence support and security support into separate "things" (there are very different mechanisms for this separation). An object with application logic just has application logic, not persistence or security logic. Similarly, a persistence subsystem focuses on the concern of persistence, not security. A security subsystem doesn't do persistence.

Separation of concerns is a large - scale way of thinking about low coupling and high cohesion at an architectural level. It also applies to small - scale objects, because its absence results in incohesive objects that have multiple areas of responsibility. But it is especially an architectural issue because the concerns are broad, and the solutions involve major, fundamental design choices.

There are several large - scale techniques to achieve a separation of concerns:

  1. Modularize the concern into a separate component (for example, subsystem) and invoke its services.
    • This is the most common approach. For example, in the NextGensystem, the persistence support could be factored into a subsystem called the persistence service. Via a facade, it can offer a publicinterface of services to other components. Layered architectures also illustrate this separation of concerns.

  2. Use decorators.
    • This is the second most common approach; first popularized in the Microsoft Transaction Service, and afterwards with EJB servers. In this approach, the concern (such as security) is decorated onto other objects with a Decorator object that wraps the inner object and interposes the service. The Decorator is called a container in EJB terminology. For example, in the NextGen POS system, security control to remote services such as the HR system can be achieved with an EJB container that adds security checks in the outer Decorator, around the application logic of the inner object.

  3. Use post - compilers and aspect - oriented technologies.
    • For example, with EJB entity beans one can add persistence support to classes such as Sale.One specifies in a property descriptor file the persistence characteristics of the Sale class. Then, a post - compiler (by which I mean another compiler that executes after the "regular" compiler) will add the necessary persistence support in a modified Sale class (modifying just the bytecode) or subclass. The developer continues to see the original class as a "clean" application - logic - only class. Another variation is aspect - oriented technologies such as Aspect, which similarly support post - compilation weaving in of cross-cutting concerns into the code, in a manner that is transparent to the developer. These approaches maintain the illusion of separation during development work, and weave in the concern before execution.

Promotion of Architectural Patterns

An exploration of architectural patterns and how they could apply (or misapply) to the NextGen case study is out of scope in this introductory text. However, a few pointers:

Probably the most common mechanism to achieve low coupling, protected variation, and a separation of concerns at the architectural level is the Layers pattern, which has been introduced a previous chapter. This is an example of the most common separation technique - modularizing concerns into separate components or layers. There is a large and growing body of written architectural patterns. Studying these is the fastest way I know of to learn architectural solutions. Please see the recommended readings.

Summary of Themes iniArchitectural Analysis

The first theme to note is that "architectural" concerns are especially related to non - functional requirements, and include an awareness of the business or market context of the application. At the same time, the functional requirements (for example, processing sales) cannot be ignored; they provide the context within which these concerns must be resolved. Further, identification of their variability is architecturally significant.

A second theme is that architectural concerns involve system - level, large - scale, and broad problems whose resolution usually involves large - scale or fundamental design decisions; for example, the choice of - or even use of - an application server.

A third theme in architectural analysis is interdependencies and trade - offs. For example, improved security may affect performance or usability, and most choices affect cost.

A fourth theme in architecture analysis is the generation and evaluation of alternative solutions. A skilled architect can offer design solutions that involve building new software, and also suggest solutions (or partial solutions) using commercial or publicly available software and hardware. For example, recovery in a remote server of the NextGen POS can be achieved through designing and programming "watchdog" processes, or perhaps through clustering, replication. and fail - over services offered by some operating system and hardware components. Good architects know third - party hardware and software products.

The opening definition of architectural concerns provides the framework for how to think about the subject of architecture: identifying the issues with large - scale or system - level implications, and resolving them.

Definition : Architectural analysis is concerned with the identification and resolution of the system's non - functional requirements in the context of the functional requirements


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics