Arkitektrollen. Ansvar och uppgifter Architecture notebook Mycket intensivt elaboration – inception Mål: en stabil arkitektur i slutet på elaboration.

En presentation över ämnet: "Arkitektrollen. Ansvar och uppgifter Architecture notebook Mycket intensivt elaboration – inception Mål: en stabil arkitektur i slutet på elaboration."— Presentationens avskrift:

1 Arkitektrollen

2 Ansvar och uppgifter Architecture notebook Mycket intensivt elaboration – inception Mål: en stabil arkitektur i slutet på elaboration Samarbetar med alla under projektets gång Hitta viktiga frågor Forska fram att det kommer att fungera

3 Vad är en arkitektur? Något stort: som beskriver struktur, komponenter, gränssnitt Något litet: som beskriver genomgående egenskaper

4 Architecture Notebook Uppdateras flitigt, revideras vid projektslut Dokumenterar och motiverar designbeslut på hög nivå Mål: Framtida behov, på vilken sikt? Signifikanta krav: Om uppfyllda så är arkitekturen stabil, se Guidance > Guidelines > Identify Common Architectural Mechanisms GuidanceGuidelines Begränsningar

5 Architecture Notebook, forts Key abstractions: Saker som systemet hanterar, saker som beskriver systemet Architectural mechanisms: – Analys: Namn, attribut – Design: Valda teknikner – Implementation: Exempelkod, Designmönster

6 Architecture Notebook, forts Lager, gemensamma tekniker: – Användarnas organisation – en bra start – Systemets olika förmågor (skills, capabilities) – Sekretessnivåer – Variationspunkter Komponenter Externa gränssnitt Återanvänding (köpa/göra)

7 7 Not only one way to do it... Write from the point of view of the readers... Stakeholder Use of the architect document Requirements engineers Negotiate and make tradeoffs among requirements Architects/Designers Resolve quality issues (e.g. performance, maintainability etc.) Architects/Designers A tool to structure and analyze the system Designers Design modules according to interfaces Developers Get better understanding of the general product Testers and Integrators Specify black-box behavior for system testing Managers Create teams that can work in parallel with e.g. different modules. Plan and allocate resources. New software engineers To get a quick view of what the system is doing Quality assurance team Make sure that implementation corresponds to architecture.

8 8 When to document? Time implementation design requirements Initial design Design iterations After implementation (consistent with code?)

9 9 What to document? Development time elements Run-time elements Deployment time elements Cryptographic Module Client Server On different machines? ´CPUs? One machine? Different sub-systems? Objects? Classes? Packages? Modules? Functions? Different structural Views System Overview

10 10 What to document? Different structural Views View diagram Encryption / Decryption Packet Handler Session Handler View description Catalog with detailed description of all elements (modules, subsystems) A B Detailed description of interfaces. Description of all relations / dependencies Mapping between views System Overview

11 11 What to document? Different structural Views View diagram View description Mapping between views Behavior  Views give structural information  Need to describe behavior Sequence Diagram State Charts System Overview

12 12 What to document? Different structural Views View diagram View description Mapping between views Behavior Rationale System Overview Why the architecture is the way it is  Rationales for views, interfaces, etc.  Architecture implication due to certain requirements  Expected effect when changing requirements or adding new ones  Constraints for the developer when implementing the solution  Design alternatives that were rejected and the rational for doing so. In general  Why a decision was made  What the implication is to change it