探索软件架构艺术：设计方法与技术

5星 · 超过95%的资源需积分: 9 122 浏览量更新于2024-08-02 收藏 2.73MB PDF 举报

"The Art Of Software Architecture" 是一本由 Stephen T. Albin 撰写的英文书籍，专注于软件架构的设计方法和技术。这本书由 John Wiley & Sons 出版于2003年，共312页，旨在帮助读者了解构建成功软件应用所需的必要步骤。在本书中，作者探讨了软件架构的各个方面，包括： 1. **Introduction to Software Architecture**（软件架构导论）：这一章节可能涵盖了软件架构的基础概念，解释了为什么它在软件开发中扮演着重要角色，并讨论了其对软件项目成功的关键影响。 2. **The Software Product Life Cycle**（软件产品生命周期）：这部分内容可能涉及软件从需求分析、设计、实现、测试到维护的各个阶段，强调了架构在整个生命周期中的作用和决策点。 3. **The Architecture Design Process**（架构设计过程）：此章节可能会介绍如何系统地进行架构设计，包括设计的策略、方法和工具，以及如何管理设计变更。 4. **Introduction to Software Design**（软件设计简介）：这可能是关于基本设计原则和实践的介绍，如抽象、封装和继承，为理解更复杂的架构设计打下基础。 5. **Complexity and Modularity**（复杂性和模块化）：书中可能讨论了如何通过模块化来管理和降低软件的复杂性，以及如何创建可维护和可扩展的组件。 6. **Models and Knowledge Representation**（模型和知识表示）：这一部分可能涵盖建模语言和工具，如UML（统一建模语言），以及如何有效地表达和传达设计知识。 7. **Architecture Representation**（架构表示）：这部分可能深入讲解了不同的架构视图和表示技术，如用例视图、逻辑视图、进程视图和物理视图。 8. **Quality Models and Quality Attributes**（质量模型和质量属性）：可能涉及到非功能需求，如性能、安全性和可靠性，以及如何将这些质量属性纳入架构设计。 9. **Architectural Design Principles**（架构设计原则）：可能列举了一些重要的设计原则，如开放封闭原则（OCP）、单一职责原则（SRP）等，以及如何在实践中应用它们。 10. **Applying Architectural Styles and Patterns**（应用架构风格和模式）：这部分可能会讨论常见的架构风格（如微服务、三层架构）和设计模式，以及它们在解决特定问题上的应用。 11. **Understanding Metamodels**（理解元模型）：元模型是描述模型的语言，这部分可能讲述了元模型的重要性，以及如何使用元模型来规范和标准化设计。 12. **Creating Architectural Descriptions**（创建架构描述）：可能介绍了如何编写架构文档，包括系统组件、接口和依赖关系的详细描述。 13. **Using Architecture Frameworks**（使用架构框架）：这部分可能涉及了如何利用现有的架构框架，如TOGAF（企业架构框架）或 Zachman 框架，来指导和加速设计过程。 14. **Software Architecture Quality**（软件架构质量）：最后，书的结尾部分可能探讨了评估和确保软件架构质量的方法，以及持续改进架构的策略。附录 A 提供了参考文献列表，便于进一步研究，而书中的图表和侧栏内容则可能提供了额外的实例和洞见，以加深对主题的理解。《The Art Of Software Architecture》是一本全面的指南，对于希望提升软件架构知识的专业人士来说，是一份宝贵的资源。通过阅读这本书，读者可以掌握设计高效、可扩展和高质量软件系统的关键技能。

The formality of the language allows different people to interpret a model in a precise way.

The UML is a rich collection of modeling notations for representing many aspects or views of a software

system, including the information and information flow, class structure, and object interactions. The UML

and other modeling languages improve a software engineer's individual capacity to create complex

solutions. Some UML tools today allow for partial code generation from UML models. It is possible that a

language like UML may become a true programming language (either special-purpose or general-purpose)

As we have seen in the brief history above, what begins as a notation for representing software design can

become the next-generation programming language.

Elements of Software Architecture

In this section, I present an overview of software architecture. I explore the definition of software

architecture and the relationship between architecture and systems followed by a discussion of

architectural descriptions. I discuss the relationship between the activities of software architecture and

other software design methods. In the last section of this chapter, I discuss how software application

architecture fits into the context of enterprise architecture.

Components, Connectors, and Qualities

Many authors equate architecture with system quality attributes such as reliability and modifiability and

how those attributes are affected by the physical decomposition of the software system in terms of

components and their arrangements. Different arrangements of components can affect attributes like

reliability and modifiability without necessarily affecting the functionality. Architectural Description

Languages (ADLs) are languages for describing a system at this level of abstraction. An ADL is one view

of the architecture of a software system. To get a more complete or comprehensive understanding of the

architecture requires multiple views.

Shaw and Garlan define software architecture abstractly as involving the description of the elements that

compose the system, their interactions, the patterns and principles that guide their composition and design,

and the constraints on those patterns (Shaw, 1996). A system, therefore, is defined in terms of its physical

(implementation) elements or components and their interactions. A system itself is also a component, and

systems can be composed of other systems. Booch considers an object-oriented design to be the

application's architecture (Booch, 1994

). Others consider the architecture to be the global view or the high-

level set of views that are commonly defined in architecture reference models, like the 4 + 1 Model View

or the Reference Model for Open Distributed Processing (RM-ODP).

As defined by the Institute of Electrical and Electronics Engineers (IEEE) Recommended Practice for

Architecture Description of Software-Intensive Systems (IEEE standard 1471–2000), an

architecture

"the fundamental organization of a system embodied in its components, their relationships to each other,

and to the environment, and the principles guiding its design and evolution." This definition is fairly

abstract and applies to systems other than just software.

The term

software architecture

in the context of this book means the observable properties of a software

system (also known as the

form

of the system). It is important to note that the structure of a system

includes its static and dynamic forms. In the sense of object-oriented design, this includes not only the

models of components and classes but also the models of component and object collaborations and the

user-perceivable functions they enable. The term

software architecting

means the process of creating

software architectures. Although the classic definition of architecture includes the processes and the

artifacts, I choose to use the word architecting as defined by Rechtin (Rechtin, 1991

) to differentiate

between the process and the artifacts. Finally, the term software architect refers to an individual who

erforms architectin

roduce architectures.

All of these definitions include some notion of the function and form of a system in terms of components,

their static and dynamic interrelationships and environmental relationships, and the principles and

guidelines for the design, evaluation, and evolution of the components and the system as a whole. All of

these are begging definitions because the definitions are themselves based on abstract, ill-defined concepts.

These concepts and the overall definition of software architecture shall become clear throughout the course

of this book.

Software systems have architectures, regardless of how simple they are in terms of components. However,

an architecture is not a system. In early systems the main attributes of real concern were functionality,

ortability, memory usage, and performance—basically, an architecture with relatively few dimensions of

quality attributes. There was no pressing need for software architectural descriptions. Functionality could

be comprehended by looking at the source code itself or executing the system with some reasonable set of

test data. Portability was achieved by simply using higher-level general-purpose programming languages.

Performance could be comprehended by executing the system or studying the algorithms of the program.

When systems started becoming more complex in terms of function and information, the use of structured

rogramming techniques and data modeling methods helped with the design and comprehension of the

software. It was even possible to start modeling the system abstractly as a hierarchy of functions and a

graph of information structures, which made it possible to reason about some aspects of the correctness of

the program before implementing the specific functions and data structures. Programmers would execute

the system or portions of the system to validate the functions and to identify performance bottlenecks.

They would then correct those functions or make those functions more efficient or refactor the functions if

necessary. Similarly, the programmers would study the system for memory and other resource usage.

As software systems continued to grow in complexity, the structured programming and data modeling

techniques could not scale in terms of number of functions or semantic complexity of data, or in terms of

other attributes like modifiability and reliability that were becoming more important in software systems.

In response, object orientation took over as the dominant programming methodology in new application

development. Object orientation could handle the increasing complexity of information semantics and

functions as well as address quality attributes that were becoming increasingly important: reusability and

modifiability. As you can see, it is not enough to model the system directly in source code and reason

about its properties. How do you evaluate source code for reliability, modifiability, or usability? Even the

use of models such as class hierarchies and object collaboration diagrams are not enough to reason about

the many quality attributes required in today's software systems. We need additional tools and techniques

to design software as the architecture of software grows in complexity.

CIVIL ARCHITECTURE: A METAPHOR FOR SOFTWARE DESIGN

The field of civil architecting has become a popular metaphor for the development of software-intensive

systems. In civil architecture the architect creates a representation of a building's physical structure that is

limited in scale or number of dimensions. The architect identifies the constraints on the design such as the

location and local building laws and integrates structural, business, and aesthetic concerns. The architect is

the client's advocate and is trusted to coordinate all aspects of the building project but does not extend to

all aspects of the project. The architect addresses usage, value, cost, and building risks within the client's

requirements. The architect aids the client in making a build or no-build decision.

Software systems today really are more analogous to urban developments than to individual buildings.

Consider how a software system evolves (albeit in condensed time compared to that of cities). If buildings

evolved as drastically as software, we would see buildings where new floors are added or blocks of floors

are removed, or where additional buildings are appended to the existing one. However, when compared to

cities and especially urban development, we do see analogous evolution such as new housing

developments sprouting up where there were none, new roads being created, many highways being

widened to allow for new traffic requirements, and old neighborhoods being razed and replaced with

malls. Two separate urban areas eventually merge and become indistinguishable. This is more like what is

going on in software development today. Of course, with all metaphors there are areas where the two

thin

s bein

com

ared sim

don't e

uate, and this is where we need to be careful and avoid the fallac

by analogy.

Architectural Description

Architecting is the specification of a system that, when constructed, will exhibit required properties. In

other words, architecting is the creation of descriptions of a system that are suitable for evaluation and

serve as plans for implementation. The description of a system must include the specification of quality

attributes and the description of the design in terms of software structures that will implement those

roperties. However, mapping quality attributes requirements to software structures is not easy; there is a

large chasm between the two. How do you transform the requirement that a system handle 100 requests

er second into a set of servlets, Enterprise Java Beans (EJBs), and relational database tables?

The process of creating an architectural description requires intermediate models that help to bridge this

chasm. This is the role of design methodologies. Commonly, functional and information requirements are

mapped to implementation-independent data models and functional models. For example, use case models

and application domain object models (both analysis models) serve as intermediate models. They

formulate the requirements in terms of concepts closer to the implementation space but still expressed in

terms of the problem space.

Depending on the methodology, the functional model and information model are mapped to some logical

component model taking into consideration other required quality attributes such as modifiability and

erformance. The resulting models show more clearly the relationship between function and data and other

nonfunctional quality attribute requirements. This model is closer to the solution space of computational

elements and is further from the semantic space of the problem. However, it is still expressed in

implementation-independent terms. In object-oriented terms, this would be another object model (class

diagrams, object collaboration diagrams, and sequence diagrams in UML) that still contains the essence of

the problem domain objects but transformed to an idealized computing object.

The computational view starts to show the shape of the architecture since the computational elements

embody not only functional and information requirements but also the nonfunctional requirements. It is

within this type of model that architectural styles are applied. Architectural styles are generalized

computational models that are devoid of specific application domain functionality. Examples of

architectural styles are n-tier client/server, pipes and filters, and distributed objects. The information and

functional models do not take into account the architectural style (or should attempt to limit the number of

constraints that might affect the selection of architectural styles). It is quite possible that the objects in the

computational model no longer resemble their analytical counterparts. This is where the complexity of

software architecting lies, and it is at this point where the form of the solution appears to depart from the

description of the problem. This is why a clear formulation of the problem is so important. Without it, it is

easy for software engineers who are focusing on the internals of the software system to lose sight of the

overall problem being addressed.

The computational model may be influenced by available technologies and possibly by technology

requirements. For example, the enterprise platform may be chosen in advance. It is common for an

organization to adopt a platform such as Microsoft XML Web Services platform (.NET) or Java 2

Enterprise Edition (J2EE) before a full abstraction of the computational model of the system is complete.

For better or for worse, the software architect must design within these constraints. A model of the

technology (sometimes referred to as a physical architecture) maps the computational model to physical

components such as ASP, JSP, Enterprise JavaBeans (EJBs), Component Object Model (COM) objects,

database entities, and XML documents.

The mapping of elements between models must also be pspecified as well as the rationale for each model.

The rationale captures why a decision was made given many competing choices. The larger the software

system, the more formal or systematic the models, traces, and rationales should probably be. The smaller

the s

stem, the less im

ortant. The software architecture team must ultimatel

determine how much is

actually modeled and specified and how formal or informal to be. It is these activities that form the core

set of activities that the architect should perform.

Software Architecture versus Software Design Methodologies

How does software architecting differ from software design methodologies such as object orientation?

Software architecting is a relatively new metaphor in software design and really encompasses design

methodologies such as object orientation as well as analysis methodologies. The software architect today is

a combination of roles such as systems analyst, systems designer, and software engineer. But architecting

is more than just a reallocation of functions: The different aspects of architecting may still be performed by

specialists but are now commonly falling under the orchestration of the

chief architect

. The concept of

architecting in software is meant to subsume the activities of analysis and design into a larger, more

coherent design framework. In addition, the demands of applications today are different than they were

even 10 years ago when object orientation was becoming the established design paradigm. Applications

tend to be larger, more integrated, and implemented by using a wide variety of technologies. Organizations

are realizing that the high cost of software development needs to be brought under some control and that

many of the promises or claims of methodologies have still not helped with this cost.

If architecting subsumes analysis and design, what makes it different than analysis and design? For

example, why is architecting different than object-oriented analysis and design? In many ways it is the

same but the scope of the analysis and design efforts is bigger. We are recognizing that object models such

as class diagrams are still not expressive enough to capture all aspects of a system and that we need to

integrate other methodologies and models into a coherent whole. This integration of methodologies and

models is one thing that distinguishes software architecting from particular analysis and design techniques.

Just as the software development community claimed the name

software engineering

in an attempt to raise

the bar of current development practices, so has the software engineering community adopted the term

oftware architecture

to say that we recognize that many aspects of software development really resemble

systems architecting and urban planning. This is most evident in the adoption of pattern languages for

software design. Originally a concept developed by Christopher Alexander, pattern languages are reusable

elements of architecture wisdom for designing and constructing cities, buildings, houses, and so on, down

to the smallest details, such as the placement of chairs in a room to satisfy certain desired qualities of

living (Alexander, 1979).

So to identify a new profession called software architecting is to make a statement that we recognize that

software development is really not scientific but rather more closely resembles the craft guilds of the

Middle Ages. This is not to say that we do not strive for a scientific underpinning to what we do as

software developers, but that we are realistic about the state of the art in software design. To claim the title

is also to make the statement that we recognize that software development is really not a homogeneous

activity relegated to a single specialty (programming) but involves many specialties and different

technologies. Even though these technologies are all software, they really require different expertise and

design methods. Therefore, we recognize that software architecting involves interdisciplinary software

engineering methodologies from object-oriented analysis to functional decomposition; from object-

oriented programming to relational database design and XML schema design, and even user interface and

usability design.

Types of Architecture

In the IT industry, the term

architecture

is used to refer to several things. From an enterprise point of view,

there are four types of architecture:

Business architecture

Information technology (IT) architecture

Information architecture

Application (software) architecture

Collectively, these architectures are referred to as

enterprise architecture

. A business or business process

architecture defines the business strategy, governance, organization, and key business processes within an

enterprise. The field of business process reengineering (BPR) focuses on the analysis and design of

business processes, not necessarily represented in an IT system. The IT architecture defines the hardware

and software building blocks that make up the overall information system of the organization. The

business architecture is mapped to the IT architecture. The IT architecture should enable achievement of

the business goals using a software infrastructure that supports the procurement, development, and

deployment of core mission-critical business applications. The purpose of the IT architecture is to enable a

company to manage its IT investment in a way that meets its business needs by providing a foundation

upon which data and application architectures can be built. This includes hardware and a software

infrastructure including database and middleware technologies. New IT technologies enable business

rocesses and capabilities that would otherwise not be possible. The Web is an example.

The data architecture of an organization includes logical and physical data assets and data management

resources. Information is becoming one of the most important assets a company has in achieving its

objectives, and the IT architecture must support it. Application architecture serves as the blueprint for

individual applications systems, their interactions, and their relationships to the business processes of the

organization. The application architecture is commonly built on top of and utilizes the services of the IT

architecture. The distinction between what is an element of the application architecture, data architecture,

and IT architecture can be blurred. As application-specific features become necessary for other

applications, they can be migrated into the IT architecture. Applications are typically integrated using the

IT infrastructure. It is common in enterprise development, both in one-off systems and in commercial

systems, that elements of the data architecture and IT architecture are incorporated into the application

architecture. Sometimes this is for reasons of development efficiency, but it can have an impact on how

easily a customer can deploy, integrate, and manage the system.

A software application is a computer program or set of programs that uses existing technologies to solve

some end-user problem such as the automation of an existing business process. Enterprise business

applications are largely information processing applications (as opposed to a video game, which performs

a lot of real-time simulation but is not a heavy information processor). Some applications are created for a

erceived need that has not been proven. This is called

greenfield development

, and the purpose is

typically to tap into new markets and often requires some technical innovation as well as creation of new

approaches to solving business problems. What makes this challenging is that the new approach may not

have been feasible without technology. For example, applications that perform analytics on customer

rofile data would not have been economically feasible as a manual business process.

Application architecting is more than the specification of the internal physical structure of the software. It

involves creating models of the problem in order to simplify and understand the problem and creating

implementation-independent models of the solution that address those problems, for example, creating

business process workflows and reviewing these with the end users. It also involves user interface and

interaction design. The way the system works should map to how users perceive the system's architecture.

Users do not need to know the internal structure; they just need to understand how certain elements work

together so that they can reasonably predict the application's behavior.

Summary

In this chapter I presented a brief history of software development, in particular the evolution of software

engineering and how a craft of software architecture has emerged as an important aspect of software

development. There are several observations we can make about software architecture:

stems have architectures, but architectures are not s

stems.

剩余272页未读，继续阅读

triumphyuan

粉丝: 2
资源: 6

探索软件架构艺术：设计方法与技术

Wiley - The Art of Software Architecture--Design Methods and Techniques.chm

The Art of Software Architecture

The Art of Software Architecture—Design Methods and Techniques

The Art Of Software Architecture

The art of software architecture

the art of software architecture.

软件体系结构的艺术英文版[The Art of Software Architecture Design Methods and Techniques]

The Art of Hardware Architecture

The art of software testing

the art of software security assessment

最新资源