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.
There is a hierarchy of goals that guides architectural decisions:
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:
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:
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
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.