oder
Loggen Sie sich ein, um 1-Click® einzuschalten.
oder
Mit kostenloser Probeteilnahme bei Amazon Prime. Melden Sie sich während des Bestellvorgangs an.
Jetzt eintauschen
und EUR 0,10 Gutschein erhalten
Eintausch
Alle Angebote
Möchten Sie verkaufen? Hier verkaufen
Jeder kann Kindle Bücher lesen  selbst ohne ein Kindle-Gerät  mit der KOSTENFREIEN Kindle App für Smartphones, Tablets und Computer.
Den Verlag informieren!
Ich möchte dieses Buch auf dem Kindle lesen.

Sie haben keinen Kindle? Hier kaufen oder eine gratis Kindle Lese-App herunterladen.

Just Enough Software Architecture: A Risk-Driven Approach [Englisch] [Gebundene Ausgabe]

George Fairbanks , David Garlan

Statt: EUR 56,61
Jetzt: EUR 56,45 kostenlose Lieferung Siehe Details.
  Alle Preisangaben inkl. MwSt.
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Nur noch 1 auf Lager (mehr ist unterwegs).
Verkauf und Versand durch Amazon. Geschenkverpackung verfügbar.
Lieferung bis Montag, 6. Juli: Wählen Sie an der Kasse Morning-Express. Siehe Details.
‹  Zurück zur Artikelübersicht

Inhaltsverzeichnis

1 Introduction
  
1.1 Partitioning, knowledge, and abstractions
   1.2 Three examples of software architecture
   1.3 Reflections
   1.4 Perspective shift
   1.5 Architects architecting architectures
   1.6 Risk-driven software architecture
   1.7 Architecture for agile developers
   1.8 About this book

I RISK-DRIVEN SOFTWARE ARCHITECTURE
2 Software Architecture

   2.1 What is software architecture?
   2.2 Why is software architecture important?
   2.3 When is architecture important?
   2.4 Presumptive architectures
   2.5 How should software architecture be used?
   2.6 Architecture-indifferent design
   2.7 Architecture-focused design
   2.8 Architecture hoisting
   2.9 Architecture in large organizations
   2.10 Conclusion
   2.11 Further reading

3 Risk-Driven Model
   3.1 What is the risk-driven model?
   3.2 Are you risk-driven now?
   3.3 Risks
   3.4 Techniques
   3.5 Guidance on choosing techniques
   3.6 When to stop
   3.7 Planned and evolutionary design
   3.8 Software development process
   3.9 Understanding process variations
   3.10 The risk-driven model and software processes
   3.11 Application to an agile processes
   3.12 Risk and architectural refactoring
   3.13 Alternatives to the risk-driven model
   3.14 Conclusion
   3.15 Further reading

4 Example: Home Media Player
   4.1 Team communication
   4.2 Integration of COTS components
   4.3 Music metadata format
   4.4 Conclusion

5 Modeling Advice
   5.1 Focus on risks
   5.2 Understand your architecture
   5.3 Distribute architecture skills
   5.4 Make rational architecture choices
   5.5 Avoid Big Design Up Front
   5.6 Avoid top-down design
   5.7 Remaining challenges
   5.8 Features and risk: a story

II ARCHITECTURE MODELING
6 Engineers Use Models
   6.1 Scale and complexity require abstraction
   6.2 Abstractions provide insight and leverage
   6.3 Reasoning about system qualities
  6.4 Models elide details
   6.5 Models can amplify reasoning
   6.6 Question first and model second
   6.7 Conclusion
   6.8 Further reading

7 Conceptual Model of Software Architecture

   7.1 Canonical model structure
   7.2 Domain, design, and code models 
   7.3 Designation and refinement relationships
   7.4 Views of a master model
   7.5 Other ways to organize models
   7.6 Business modeling
   7.7 Use of UML
   7.8 Conclusion
   7.9 Further reading

8 The Domain Model
   8.1 How the domain relates to architecture
   8.2 Concept model
   8.3 Navigation and invariants
   8.4 Snapshots
   8.5 Functionality scenarios
   8.6 Conclusion
   8.7 Further reading

9 The Design Model
   9.1 Design model
   9.2 Boundary model
   9.3 Internals model
   9.4 Quality attributes
   9.5 Walkthrough of Yinzer design
   9.6 Viewtypes
   9.7 Dynamic architecture models
   9.8 Architecture description languages
   9.9 Conclusion
   9.10 Further reading

10 The Code Model
   10.1 Model-code gap
   10.2 Managing consistency
   10.3 Architecturally-evident coding style
   10.4 Expressing design intent in code
   10.5 Model-in-code principle
   10.6 What to express
   10.7 Patterns for expressing design intent in code
   10.8 Walkthrough of an email processing system
   10.9 Conclusion

11 Encapsulation and Partitioning
   11.1 Story at many levels
   11.2 Hierarchy and partitioning
   11.3 Decomposition strategies
   11.4 Effective encapsulation
   11.5 Building an encapsulated interface
   11.6 Conclusion
   11.7 Further reading

12 Model Elements
   12.1 Allocation elements
   12.2 Components
   12.3 Component assemblies
   12.4 Connectors
   12.5 Design decisions
   12.6 Functionality scenarios
   12.7 Invariants (constraints)
   12.8 Modules
   12.9 Ports
   12.10 Quality attributes
   12.11 Quality attribute scenarios
   12.12 Responsibilities
   12.13 Tradeoffs
   12.14 Conclusion

13 Model Relationships
   13.1 Projection (view) relationship
   13.2 Partition relationship
   13.3 Composition relationship
   13.4 Classification relationship
   13.5 Generalization relationship
   13.6 Designation relationship
   13.7 Refinement relationship
   13.8 Binding relationship
   13.9 Dependency relationship
   13.10 Using the relationships
   13.11 Conclusion
   13.12 Further reading

14 Architectural Styles
   14.1 Advantages
   14.2 Platonic vs. embodied styles
   14.3 Constraints and architecture-focused design
   14.4 Patterns vs. styles
   14.5 A catalog of styles
   14.6 Layered style
   14.7 Big ball of mud style
   14.8 Pipe-and-filter style
   14.9 Batch-sequential style
   14.10 Model-centered style
   14.11 Publish-subscribe style
   14.12 Client-server style & N-tier
   14.13 Peer-to-peer style
   14.14 Map-reduce style
   14.15 Mirrored, farm, and rack styles
   14.16 Conclusion
   14.17 Further reading

15 Using Architecture Models
   15.1 Desirable model traits
   15.2 Working with views
   15.3 Improving view quality
   15.4 Improving diagram quality
   15.5 Testing and proving
   15.6 Analyzing architecture models
   15.7 Architectural mismatch
   15.8 Choose your abstraction level
   15.9 Planning for the user interface
   15.10 Prescriptive vs. descriptive models
   15.11 Modeling existing systems
   15.12 Conclusion
   15.13 Further reading

16 Conclusion

   16.1 Challenges
   16.2 Focus on quality attributes
   16.3 Solve problems, not just model them
   16.4 Use constraints as guide rails
   16.5 Use standard architectural abstractions

Glossary

‹  Zurück zur Artikelübersicht