Página inicialGruposDiscussãoMaisZeitgeist
Pesquise No Site
Este site usa cookies para fornecer nossos serviços, melhorar o desempenho, para análises e (se não estiver conectado) para publicidade. Ao usar o LibraryThing, você reconhece que leu e entendeu nossos Termos de Serviço e Política de Privacidade . Seu uso do site e dos serviços está sujeito a essas políticas e termos.

Resultados do Google Livros

Clique em uma foto para ir ao Google Livros

Carregando...

Documenting Software Architectures: Views and Beyond

de Paul Clements

MembrosResenhasPopularidadeAvaliação médiaConversas
1852146,791 (3.21)Nenhum(a)
“This new edition is brighter, shinier, more complete, more pragmatic, more focused than the previous one, and I wouldn’t have thought it possible to improve on the original. As the field of software architecture has grown over these past decades, there is much more to be said, much more that we know, and much more that we can reflect upon of what’s worked and what hasn’t—and the authors here do all that, and more.” —From the Foreword by Grady Booch, IBM Fellow Software architecture—the conceptual glue that holds every phase of a project together for its many stakeholders—is widely recognized as a critical element in modern software development. Practitioners have increasingly discovered that close attention to a software system’s architecture pays valuable dividends. Without an architecture that is appropriate for the problem being solved, a project will stumble along or, most likely, fail. Even with a superb architecture, if that architecture is not well understood or well communicated the project is unlikely to succeed. Documenting Software Architectures, Second Edition, provides the most complete and current guidance, independent of language or notation, on how to capture an architecture in a commonly understandable form. Drawing on their extensive experience, the authors first help you decide what information to document, and then, with guidelines and examples (in various notations, including UML), show you how to express an architecture so that others can successfully build, use, and maintain a system from it. The book features rules for sound documentation, the goals and strategies of documentation, architectural views and styles, documentation for software interfaces and software behavior, and templates for capturing and organizing information to generate a coherent package. New and improved in this second edition: Coverage of architectural styles such as service-oriented architectures, multi-tier architectures, and data models Guidance for documentation in an Agile development environment Deeper treatment of documentation of rationale, reflecting best industrial practices Improved templates, reflecting years of use and feedback, and more documentation layout options A new, comprehensive example (available online), featuring documentation of a Web-based service-oriented system Reference guides for three important architecture documentation languages: UML, AADL, and SySML… (mais)
Nenhum(a)
Carregando...

Registre-se no LibraryThing tpara descobrir se gostará deste livro.

Ainda não há conversas na Discussão sobre este livro.

Exibindo 2 de 2
All software projects have architecture, but not all have formal Architecture. This is a book for projects of the latter sort. Although the text had gems scattered throughout, much of what was presented was much too formal for the more agile and informal environment I work.

My recommendation is that most people will get the most value by skimming the prologue, especially sections P.2.2 and uses and audiences for architecture documentation, section P.4 on architecture styles, and P.5 on rules for sound documentation[1]. Flip through the chapters on the different view types and read the description of those that feel most relevant (skip the text about the examples and just look at the diagrams). Read chapter 7 on documenting software interfaces. Skim chapter 8 on documenting behavior. Read chapter 11 on reviewing an architecture document.

You won't find all of the gems this way, but you'll get a better value for your time investment than if you were to read the whole thing.

[1] In sum:
1. Write documentation from the reader's point of view
2. Avoid unnecessary repetition
3. Avoid ambiguity
4. Use a standard organization
5. Record rationale
6. Keep documentation current but not too current
7. Review documentation for fitness of purpose. ( )
  eri_kars | Jul 10, 2022 |
Much, much better than the first edition. Unlike that version, this one has real world applicability. ( )
  dehora | Jul 23, 2019 |
Exibindo 2 de 2
sem resenhas | adicionar uma resenha
Você deve entrar para editar os dados de Conhecimento Comum.
Para mais ajuda veja a página de ajuda do Conhecimento Compartilhado.
Título canônico
Título original
Títulos alternativos
Data da publicação original
Pessoas/Personagens
Lugares importantes
Eventos importantes
Filmes relacionados
Epígrafe
Dedicatória
Primeiras palavras
Citações
Últimas palavras
Aviso de desambiguação
Editores da Publicação
Autores Resenhistas (normalmente na contracapa do livro)
Idioma original
CDD/MDS canônico
LCC Canônico

Referências a esta obra em recursos externos.

Wikipédia em inglês (2)

“This new edition is brighter, shinier, more complete, more pragmatic, more focused than the previous one, and I wouldn’t have thought it possible to improve on the original. As the field of software architecture has grown over these past decades, there is much more to be said, much more that we know, and much more that we can reflect upon of what’s worked and what hasn’t—and the authors here do all that, and more.” —From the Foreword by Grady Booch, IBM Fellow Software architecture—the conceptual glue that holds every phase of a project together for its many stakeholders—is widely recognized as a critical element in modern software development. Practitioners have increasingly discovered that close attention to a software system’s architecture pays valuable dividends. Without an architecture that is appropriate for the problem being solved, a project will stumble along or, most likely, fail. Even with a superb architecture, if that architecture is not well understood or well communicated the project is unlikely to succeed. Documenting Software Architectures, Second Edition, provides the most complete and current guidance, independent of language or notation, on how to capture an architecture in a commonly understandable form. Drawing on their extensive experience, the authors first help you decide what information to document, and then, with guidelines and examples (in various notations, including UML), show you how to express an architecture so that others can successfully build, use, and maintain a system from it. The book features rules for sound documentation, the goals and strategies of documentation, architectural views and styles, documentation for software interfaces and software behavior, and templates for capturing and organizing information to generate a coherent package. New and improved in this second edition: Coverage of architectural styles such as service-oriented architectures, multi-tier architectures, and data models Guidance for documentation in an Agile development environment Deeper treatment of documentation of rationale, reflecting best industrial practices Improved templates, reflecting years of use and feedback, and more documentation layout options A new, comprehensive example (available online), featuring documentation of a Web-based service-oriented system Reference guides for three important architecture documentation languages: UML, AADL, and SySML

Não foram encontradas descrições de bibliotecas.

Descrição do livro
Resumo em haiku

Current Discussions

Nenhum(a)

Capas populares

Links rápidos

Avaliação

Média: (3.21)
0.5
1 1
1.5
2 2
2.5
3 5
3.5
4 5
4.5
5 1

É você?

Torne-se um autor do LibraryThing.

 

Sobre | Contato | LibraryThing.com | Privacidade/Termos | Ajuda/Perguntas Frequentes | Blog | Loja | APIs | TinyCat | Bibliotecas Históricas | Os primeiros revisores | Conhecimento Comum | 204,229,707 livros! | Barra superior: Sempre visível