电子书免费下载 Documenting Software Architecture

For all but the most trivial software systems, you cannot hope to succeed without paying careful attention to its architecture: the way the system is decomposed into constituent parts and the ways those parts interact with

each other. Without an architecture that is appropriate for the problem being solved the project will fail. Even with a superb architecture, if it is not well understood and well communicated -- in other words, well documented

-- the project will fail. Not may fail. Will fail.

Accordingly, software architecture is at the center of a frenzy of attention these days. A new book about it seems to pop out monthly. In response to industrial need, universities are adding software architecture to their software

engineering curricula. It’s now common for “software architect” to be a defined position in organizations, and professional practice groups for software architects are emerging. It has been the subject of major international

conferences and workshops. The purveyors of the Unified Modeling Language promote their product by calling it “the standard notation for software architecture” (a claim that may say at least as much about the pervasive-

ness of architecture as about UML). The Software Engineering Institute maintains a bibliography of journal and conference papers about software architecture and its population is approaching 1000.

Rather surprisingly, there is a dearth of practical guidance available that is independent of language or notation for how to capture an architecture. To be sure, piles of books exist about how to use a particular language --again, UML comes to mind -- but what an architect really needs is guidance in which architecture is the first-class citizen, with and language is relegated more appropriately to a supporting role.

Documenting Software Architecture 下载地址