|
|
|
 |
ÆÇ¸Å°¡ |
92,300¿ø ¡æ 92,300¿ø 0% |
|
 |
¸¶Àϸ®Áö |
3% 2,770¿ø |
|
 |
¹ßÇàÀÏ |
2002-09-30 | Áß·®: 1.89 lbs | »çÀÌÁî: 9.54*6.48*1.26
|
 |
ISBN |
0201703726 | 9780201703726
|
 |
±âŸÁ¤º¸ |
¿ø¼ | 560ÂÊ
| $ 74.99
| HardCover
|
|
 |
¿¹»óÃâ°íÀÏ
|
±ÝÀÏ °¡´É (±Ù¹«ÀϱâÁØ) |
 |
¹è¼Ûºñ |
¹«·á¹è¼Û
|
| |
|
|
|
|
|
 |
| ÇÁ·Î±×·¡¹Ö
|
|
|
|
|
|
|
| |
ÇÁ·Î±×·¡¹Ö ºÐ¾ß º£½ºÆ®(¿ù) |
|
| |
|
| |
ÇÁ·Î±×·¡¹Ö ºÐ¾ß º£½ºÆ®(ÁÖ) |
|
| |
|
| |
ÇÁ·Î±×·¡¹Ö ºÐ¾ß ½Å°£ |
|
| |
|
 |
 |
For all but the most trivial software systems, you must pay close attention to its architecture—the conceptual glue that holds every phase of a project together for its many stakeholders. Without an architecture that is appropriate for the problem being solved, the project will at the very least stumble along, or most likely, fail. Even with a superb architecture, if it is not well understood and well communicated—in other words, well documented—the project cannot be considered a complete success.
Although architecture is now widely recognized as a critical element in software development, there has been little guidance independent of language or notation about how to capture it. Based on the authors' extensive experience, Documenting Software Architecture, helps you to decide what information to document and then, with guidelines and examples (in various notations, including UML), shows you how to express an architecture in a form that everyone can understand. If you go to the trouble to create a strong architecture, you must also be prepared to describe it in enough detail, without ambiguity, and to organize it so that others can quickly find the information they need.
As a guide for practitioners, the book covers:
* Seven rules for sound documentation * The uses of software architecture documentation, including goals and strategies * Architectural views and styles, with general introductions and specific examples * Documenting software interfaces and software behavior * Templates for capturing and organizing the information to generate a coherent package
"This book is of immense value. It should save you months of trials and errors, lots of undeserved hassle, and many costly mistakes that could potentially jeopardize the whole endeavor. It will become an important reference on the shelf of the software architect."—From the Foreword by Philippe Kruchten, Rational Software Canada
|
|
|
 |
Paul Clements is a senior member of the technical staff at the SEI, where he works on software architecture and product line engineering. He is the author of five books and more than three dozen papers on these and other topics.
Len Bass is a senior member of the technical staff at the Software Engineering Institute (SEI). He has written or edited five books and numerous papers on software engineering and other topics. He has extensive experience in architecting real-world development projects.
Robert L. Nord, a member of the software architecture program at SCR, designs and evaluates software architectures for large-scale industrial systems. Dr. Nord, currently the Siemens industrial resident affiliate at the Software Engineering Institute (SEI) in Pittsburgh, is working on methods for architecture trade-off analysis and product-line practices. His other interests include transitioning software design practices, improving architecture practices using software architecture improvement groups, and architecture-based development.
|
|
|
|
|
 |
|
ÇÑÁ¤µµ¼ ¹Ý°ª¼¼ÀÏ!
2005-2008 °Äľî¿öµå ¼±Á¤µµ¼ ¹Ý°ª¼¼ÀÏ! - ´ÊÀ¸¸é Áö´Â°Å´Ù!
2009-06-30 ~ Á¾·áÀϽà ¹ÌÁ¤ |
|
À§Ç³´ç´ç ÇÁ·Î±×·¡¸Ó¸¦ À§ÇÑ °ÄÄ ÆÐŰÁö12Á¾!
À§Ç³´ç´ç ÇÁ·Î±×·¡¸Ó¸¦ À§ÇÑ °ÄÄ ÆÐŰÁö12Á¾!
2010-01-25 ~ Á¾·áÀϽà ¹ÌÁ¤ |
|
|
|
|
|
|
|
|
|