构建优秀软件架构：设计方法与技术

3星 · 超过75%的资源需积分: 10 67 浏览量更新于2024-07-22 1 收藏 4.79MB PDF 举报

"《软件体系结构的艺术》是斯蒂芬·阿尔宾撰写的一本关于构建高效软件体系结构的著作，适合架构师阅读。书中详细介绍了软件设计的方法和技术，旨在帮助读者掌握创建成功软件应用的必要步骤。" 在本书中，作者深入探讨了以下几个关键知识点： 1. **软件体系结构介绍**：第一章引导读者进入软件体系结构的世界，阐述其重要性，以及它如何影响软件系统的整体质量和性能。 2. **软件产品生命周期**：第二章详细讨论了软件从需求分析、设计、开发、测试到维护的完整生命周期，强调了在不同阶段体系结构的角色。 3. **架构设计过程**：第三章讲解了如何进行架构设计，包括设计决策、评估和权衡，以及如何将这些过程与项目管理相结合。 4. **软件设计基础**：第四章回顾了软件设计的基本原则，如抽象、封装和继承，为后续章节奠定了基础。 5. **复杂性和模块化**：第五章探讨了如何通过模块化来管理和降低软件复杂性，以及模块化在软件设计中的应用。 6. **模型和知识表示**：第六章讨论了使用模型来理解和表达软件系统，包括UML等建模语言，以及它们在传达系统设计意图中的作用。 7. **体系结构表示**：第七章介绍了各种表示方法，如组件图、部署图和用例图，用于清晰地展示软件架构。 8. **质量模型和质量属性**：第八章涵盖了软件质量的重要方面，如性能、可扩展性、安全性和可靠性，并解释了如何在设计阶段考虑这些属性。 9. **架构设计原则**：第九章列举并解释了指导架构设计的核心原则，如开放封闭原则、单一职责原则等。 10. **应用架构风格和模式**：第十章介绍了常见的架构风格（如微服务、面向服务架构等）和设计模式，以及如何根据项目需求选择合适的模式。 11. **理解元模型**：第十一章讨论了元模型的概念，它是描述其他模型的模型，有助于标准化和重用设计元素。 12. **创建架构描述**：第十二章提供了创建详细且可理解的软件架构描述的技巧和最佳实践。 13. **使用架构框架**：第十三章讨论了如何利用架构框架（如TOGAF、FEAF等）来加速设计过程并确保一致性。 14. **软件架构质量**：第十四章重点关注如何评估和保证软件架构的质量，以及在整个软件开发过程中如何持续改进。书后还附有参考文献、索引、图形列表和边栏内容，为读者提供了深入研究和进一步学习的资源。《软件体系结构的艺术》提供了一套全面的方法论，帮助读者掌握设计和实施高效软件架构的关键技能。通过学习这些知识，架构师能够更好地应对日益复杂的软件挑战，创建出更稳定、可扩展且易于维护的软件系统。

Specialized languages improve productivity by allowing the developer to think in terms of the abstractions of a specific

technology (which is a simpler domain to comprehend) rather than by using the same general-purpose language for all

programming problems. If a programmer had to understand how the data was stored in files and how the files were

indexed, the problem would become much more complex. Of course, specialized languages introduce complexities of

their own. The industry addresses this by developing guidelines and design patterns for the effective use of a

particular technology. In relational databases, the theory of normal forms was developed to help programmers design

databases with certain quality attributes. Other examples of specialized languages are Web presentation technologies

such as Active Server Pages (ASP), Java Server Pages (JSP), and Hypertext Preprocessor (PHP), and data

representation and transformation languages such as Hypertext Markup Language (HTML), eXtensible Markup

Language (XML), and eXtensible Stylesheet Language Transformations (XSLT).

Modeling Languages and Notations

Modeling languages and design notations emerged as methods for improving software design quality. It is argued that

an expressive modeling notation can expand our capability to design software much like mathematics allows us to

reason about more complex things than our minds would normally be capable of without such a language. The entity

relationship diagram (ERD), for example, is a powerful modeling language and notation that allows a software

engineer to design and communicate expressive data models. Without such a language, it would be difficult to think

about the information design of a system, and without a notation to represent the diagrams, it would be difficult to

communicate those designs to others. 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 Architectur e

Description of Software-Intensive Systems (IEEE standard 1471–2000), an architecture is "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

performs architecting to produce 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, a n

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

usage, and performance—basically, an architecture with relatively few dimensions of quality attributes. There was n o

pressing need for software architectural descriptions. Functionality could be comprehended by looking at the sourc e

code itself or executing the system with some reasonable set of test data. Portability was achieved by simply usin g

higher-level general-purpose programming languages. Performance could be comprehended by executing the syste m

or studying the algorithms of the program .

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

programming 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 things being compared simply don't equate, and this is where we need

to be careful and avoid the fallacy 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 properties. 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 per 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 performance. 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 system, the less

important. The software architecture team must ultimately 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 software 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 processes 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 perceived need that has not been proven.

剩余285页未读，继续阅读

wllove99

粉丝: 0
资源: 4

构建优秀软件架构：设计方法与技术

软件体系结构 课程PPT等资料

软件体系结构的艺术

软件体系结构(PDF)

数字设计和计算机体系结构.pdf

arm基本体系结构.pdf

汇编语言:基于64位armv8体系结构.pdf

使用raspberry pi学习计算机体系结构.pdf

软件体系结构第3版pdf

英特尔64和 ia-32 体系结构的软件开发人员手册合集.pdf

董威软件设计与体系结构pdf

最新资源

软件体系结构课程PPT等资料