常见的房屋结构有砖混结构、钢筋混凝土结构、框架结构、框剪结构、钢结构等，各种结构有其自身的特点。

按建筑物以其结构类型的不同，可以分为砖木结构、砖混结构、钢筋混凝土结构和钢结构四大类。

--百度百科：建筑结构类型

有的成本低，有的易于构建，有的抗震性好；但，也各有缺点；各有它相对适用的范围

建筑风格，一般认为是一种区域性的或者国际性的建筑物的风格，是对某一建筑师、建筑学校或者历史时期建筑特色的描述。

常见的最重要的建筑风格划分方法是根据地區及时代划分，并且与当时艺术风格的发展方向密切相关。

本分类包含下列18个子分类，共18个子分类。

http://zh.wikipedia.org/wiki/Category:建築風格

http://zh.wikipedia.org/wiki/哥特式建筑 德国 科隆大教堂 被认为完美地结合了所有中世纪 哥特式建筑 和装饰元素

Christopher Wolfgang Alexander  is an architect noted for his theories about design, and for more than 200 building projects in California , Japan , Mexico and around the world. Reasoning that users know more about the buildings they need than any architect could, he produced and validated(与他人共同 ) a " pattern language " designed to empower anyone to design and build at any scale. A pattern language , a term coined by architect Christopher Alexander , is a structured method of describing good design practices within a field of expertise. Advocates of this design approach claim that ordinary people can use it to successfully solve very large, complex design problems.

A. 便于高效沟通-使用简洁的信息，表达丰富的信息

B. 易于识别事物的主要属性，优/缺

C. 可用于指导构建工作

Architecture (Latin architectura, from the Greek ἀρχιτέκτων – arkhitekton, from ἀρχι- "chief" andτέκτων "builder, carpenter, mason") is both the process and product of planning, designing, andconstruction, usually of buildings and other physical structures. Architectural works, in the material form of buildings, are often perceived as cultural symbols and as works of art. Historical civilizations are often identified with their surviving architectural achievements.

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

from: http://msdn.microsoft.com/en-us/library/ee658086.aspx

Microsoft Application Architecture Guide, 2nd Edition

“The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is.”

[http://www.pearsonhighered.com/educator/academic/product/0,3110,0321127420,00.html]

In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common recurring themes when explaining architecture.

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”

[http://www.pearsonhighered.com/educator/academic/product/0,4096,0321154959,00.html]

In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman 

Systems should be designed with consideration for the user, the system (the IT infrastructure), and the business goals. For each of these areas, you should outline key scenarios and identify important quality attributes (for example, reliability or scalability) and key areas of satisfaction and dissatisfaction. Where possible, develop and consider metrics that measure success in each of these areas.

Application architecture seeks to build a bridge between business requirements and technical requirements by understanding use cases, and then finding ways to implement those use cases in the software. The goal of architecture is to identify the requirements that affect the structure of the application. Good architecture reduces the business risks associated with building a technical solution. A good design is sufficiently flexible to be able to handle the natural drift that will occur over time in hardware and software technology, as well as in user scenarios and requirements. An architect must consider the overall effect of design decisions, the inherent tradeoffs between quality attributes (such as performance and security), and the tradeoffs required to address user, system, and business requirements.

Keep in mind that the architecture should:

• Expose the structure of the system but hide the implementation details.
• Realize all of the use cases and scenarios.
• Try to address the requirements of various stakeholders.
• Handle both functional and quality requirements.

Architectural Information in the UP Artifacts

• The architectural factors (for example, in a factor table) are recorded in the Supplementary Specification.

• The architectural decisions are recorded in the SAD. This includes the technical memos and descriptions of the architectural views.

  
  

Figure 1

The following table lists the major areas of focus and the corresponding architectural styles.

Figure 13.4. Common layers in an information system logical architecture.(From AUP 3)

Architectural analysis can be viewed as a specialization of requirements analysis, with a focus on requirements that strongly influence the "architecture." For example, identifying the need for a highly-secure system.

The essence of architectural analysis is to identify factors that should influence the architecture, understand their variability and priority, and resolve them. The difficult part is knowing what questions to ask, weighing the trade-offs, and knowing the many ways to resolve an architecturally significant factor, ranging from benign neglect, to fancy designs, to third-party products.

A good architect earns her salary by having the experience to know what questions to ask and choosing skillful means to resolve the factors.

Definition

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

33.3. Architectural Analysis

Architectural analysis is concerned with the identification and resolution of the system's  non-functional requirements (for example, security), in the context of the functional requirements (for example, processing sales). It includes identifying variation points and the most probable evolution points.

In the UP, the term encompasses both architectural investigation (identification) and architectural design (resolution). Here are some examples of the many issues to be identified and resolved at an architectural level:

• How do reliability and fault-tolerance requirements affect the design?

  • For example, in the NextGen POS, for what remote services (e.g., tax calculator) will fail-over to local services be allowed? Why? Do they provide exactly the same services locally as remotely, or are there differences?

• How do the licensing costs of purchased subcomponents affect profitability?

  • For example, the producer of the excellent database server, Clueless, wants 2% of each NextGen POS sale, if their product is used as a subcomponent. Using their product will speed development (and time to market) because it is robust and provides many services, and many developers know it, but at a price. Should the team instead use the less robust, open sourceYourSQL database server? At what risk? How does it restrict the ability to charge for the NextGen product?

• How do the adaptability and configurability requirements affect the design?

  • For example, most retailers have variations in business rules they want represented in their POS applications. What are the variations? What is the "best" way to design for them? What is the criteria for best? Can NextGen make more money by requiring customized programming for each customer (and how much effort will that be?), or with a solution that allows the customer to add the customization easily themselves? Should "more money" be the goal in the short-run?

• How does brand name and branding affect the architecture?

  • A little-known story is that Microsoft's Windows XP was not originally named "Windows XP." The name was a relatively last-minute change from the marketing department. You may appreciate that the operating system name is displayed in many places, both as raw text and as a graphic image. Because the Microsoft architects did not identify a name change as a likelyevolution point, there was no Protected Variation solution for this point, such as the label existing in only one place in a configuration file. Therefore, at the last minute, a small team scoured the millions of lines of source code and image files, and made hundreds of changes.

  • Similarly, how should potential changes to the brand name of the NextGen product and related logos, icons, and so forth affect its architecture?

• How do the adaptability and configurability requirements affect the design?

  • For example, most retailers have variations in business rules they want represented in their POS applications. What are the variations? What is the "best" way to design for them? What is the criteria for best? Can Next Gen make more money by requiring customized programming for each customer (and how much effort will that be?), or with a solution that allows the customer to add the customization easily themselves? Should "more money" be the goal in the short-run?

Why is architectural analysis important? It's useful to:

• reduce the risk of missing something centrally important in the design of the systems

• avoid applying excessive effort to low priority issues

• help align the product with business goals

  
  

  from AUP-v3-c33

33.1. Process: When Do We Start Architectural Analysis?

In the UP, architectural analysis should start even before the first development iteration, as architectural issues need to be identified and resolved in early development work. Failure to do so is a high risk. For example, deferring an architecturally-significant factor such as "must be internationalized to support English, Chinese, and Hindi" or "must handle 500 concurrent transactions with on-average one-second response time" until late in development is a recipe for pain and suffering.

However, since the UP is iterative and evolutionarynot the waterfallwe start programming and testing in early iterations before all the architectural analysis is complete. Analysis and early development proceed hand-in-hand.

But this important topic was deferred until this point of the book so that fundamentals of OOA/D could be first presented.

33.2. Definition: Variation and Evolution Points

First, two points of change in a software system (first introduced in the Protected Variations pattern) are worth reiterating:

• variation point Variations in the existing current system or requirements, such as the multiple tax calculator interfaces that must be supported.

• evolution point Speculative points of variation that may arise in the future, but which are not present in the existing requirements.

As will be seen, variation and evolution points are recurring key elements in architectural analysis.

33.4. Common Steps in Architectural Analysis

There are several methods of architectural analysis. Common to most of these is some variation of the following steps:

33.5. The Science: Identification and Analysis of Architectural Factors

Architectural Factors

Any and all of the FURPS+ requirements may have a significant influence on the architecture of a system, ranging from reliability, to schedule, to skills, and to cost constraints. For example, a case of tight schedule with limited skills and sufficient money probably favors buying or outsourcing to specialists, rather than building all components in-house.

5.4. What are the Types and Categories of Requirements?

In the UP, requirements are categorized according to the FURPS+ model [Grady92], a useful mnemonic with the following meaning:^[1]

^[1]  There are several systems of requirements categorization and quality attributes published in books and by standards organizations, such as ISO 9126 (which is similar to the FURPS+ list), and several from the Software Engineering Institute (SEI); any can be used on a UP project.

• Functional features, capabilities, security.

• Usability human factors, help, documentation.

• Reliability frequency of failure, recoverability, predictability.

• Performance response times, throughput, accuracy, availability, resource usage.

• Supportability adaptability, maintainability, internationalization, configurability.

The "+" in FURPS+ indicates ancillary and sub-factors, such as:

• Implementation resource limitations, languages and tools, hardware, ...

• Interface constraints imposed by interfacing with external systems.

• Operations system management in its operational setting.

• Packaging for example, a physical box.

• Legal licensing and so forth.

33.7. The Art: Resolution of Architectural Factors

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 trade-offs, 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

33.8. Summary of Themes in Architectural 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 ofor even use ofan 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.

A common technique for refining the design over time, until it satisfies all of the requirements and adheres to all of the constraints, is an iterative technique consisting of the five major stages shown in Figure 1.

Figure 1

Create your architecture with this evolution in mind so that it will be able to adapt to requirements that are not fully known at the start of the design process.

Consider the following questions as you create an architectural design

• What are the foundational parts of the architecture that represent the greatest risk if you get them wrong?
• What are the parts of the architecture that are most likely to change, or whose design you can delay until later with little impact?
• What are your key assumptions, and how will you test them?
• What conditions may require you to refactor the design?

Do not attempt to over engineer the architecture, and do not make assumptions that you cannot verify. Instead, keep your options open for future change. There will be aspects of your design that you must fix early in the process, which may represent significant cost if redesign is required. Identify these areas quickly and invest the time necessary to get them right. 

• Build to change instead of building to last. Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this.
• Use models and visualizations as a communication and collaboration tool. Efficient communication of the design, the decisions you make, and ongoing changes to the design, is critical to good architecture. Use models, views, and other visualizations of the architecture to communicate and share your design efficiently with all the stakeholders, and to enable rapid communication of changes to the design.
• Identify key engineering decisions.  understand the key engineering decisions and the areas where mistakes are most often made. Invest in getting these key decisions right the first time so that the design is more flexible and less likely to be broken by changes.

Consider using an incremental and iterative approach to refining your architecture. Start with a baseline architecture to get the big picture right, and then evolve candidate architectures as you iteratively test and improve your architecture. Do not try to get it all right the first time—design just as much as you can in order to start testing the design against requirements and assumptions. Iteratively add details to the design over multiple passes to make sure that you get the big decisions right first, and then focus on the details. A common pitfall is to dive into the details too quickly and get the big decisions wrong by making incorrect assumptions, or by failing to evaluate your architecture effectively. When testing your architecture, consider the following questions:

• What assumptions have I made in this architecture?
• What explicit or implied requirements is this architecture meeting?
• What are the key risks with this architectural approach?
• What countermeasures are in place to mitigate key risks?
• In what ways is this architecture an improvement over the baseline or the last candidate architecture? 

http://msdn.microsoft.com/en-us/library/ee658086.aspx

Microsoft Application Architecture Guide, 2nd Edition


Software Architecture and Design
Chapter 1: What is Software Architecture?
Chapter 2: Key Principles of Software Architecture
Chapter 3: Architectural Patterns and Styles
Chapter 4: A Technique for Architecture and Design

https://en.wikipedia.org/wiki/Architecture

AIS77 Alexander, C., Ishikawa, S. , and Silverstein, M. 1977. A Pattern LanguageTowns-Building-Construction. Oxford University Press.

http://en.wikipedia.org/wiki/Christopher_Alexander

33.10. Recommended Resources

There is a growing body of architecture-related patterns, and general software architecture advice. Suggestions:

• Beyond Software Architecture [Hohman03]. This useful guide, from someone experienced as both architect and product manager, brings a business-oriented emphasis to architecture. Hohman shares his experience with important issues seldom covered, such as the impact of the business model, licensing, and upgrades on the software architecture.

• Patterns of Enterprise Application Architecture [Fowler02].

• Software Architecture in Practice [BCK98].

• Pattern-Oriented Software Architecture, both volumes.

• Pattern Languages of Program Design, all volumes. Each volume has a section on architecture-related patterns.