1 / 22

Documenting an Architecture

Documenting an Architecture. 10 pages, half pictures. Why Document?. You can’t build it if it is unknown! History – to provide cyclic improvement Justification Analysis Decisions that were made. Is there a standard for Architecture Documentation?. Uses of the Documents.

rsherwin
Télécharger la présentation

Documenting an Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Documenting an Architecture 10 pages, half pictures

  2. Why Document? • You can’t build it if it is unknown! • History – to provide cyclic improvement • Justification • Analysis • Decisions that were made

  3. Is there a standard for Architecture Documentation?

  4. Uses of the Documents • Documentation should meet the needs of the stakeholders

  5. Stakeholder “Qualities” • What are the qualities or properties of a stakeholder. • Experience – new or seasoned • Novelty • Prescriptive vs. Descriptive • Future architect

  6. Table 9.1 in text • List of typical stakeholders and their main use(s) of the architecture • It’s on page 204

  7. Views • Architecture can’t be displayed in a single view • Complex • Varied • Many aspects • No right set of views

  8. Recall views from CH 2 • Module views • Component and Connector views • Allocation views • Architect needs to think in terms of: • Structured set of implementation units • Elements with runtime behavior • Non-software structures in the Environment

  9. How to choose what views to use • What does the architecture consist of? • What are the needs of the stakeholders? • Build a stakeholder table – table 9.2 • Make a list of possible views • Combine views • Prioritize

  10. Documenting a View • Primary presentation • Element catalog • Context diagram • Variability guide • Architecture background • Consider a separate document for this • Glossary • Other • See pp 207-210

  11. Primary presentation • Contains: • Elements • Relationships • Possible methods • Graphical • Tables • Plain old text

  12. Elements Catalog • Details • Purpose • Roles • Behaviors • Interfaces • Text!

  13. Context • Relation of view to the rest of the architecture

  14. Variability Guide • Discussion of things not yet bound • Guide to developers

  15. Background • Rationale • Analysis results • Assumptions

  16. Other • Management information • Configuration control • Change histories • Requirements traceability

  17. Behavior • Dynamic aspects • UML diagrams • Other formal mechanisms • Petri diagrams • Petri diagrams contrasted with activity diagrams • RM-ODP

  18. Interfaces • Syntactic • Signature – names, parameters, types • Semantics • Meaning • Constraints

  19. Element interface spectemplate in text • Figure 9.2, p 215

  20. Organization • How is it laid out • What is there • Why it is this way

  21. Helpful layout techniques • View catalog • Name • Description of view elements • Description of view purpose • Management information • View template

  22. How to use UML • Authors’ view is section 9.6, pp 218 – 229.

More Related