Arkitektrollen
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
Vad är en arkitektur?
• Något stort: som beskriver struktur,
komponenter, gränssnitt
• Något litet: som beskriver genomgående
egenskaper
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
• Begränsningar
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
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)
Not
only
one
way
to
do
it...
Write from the point of view of the readers...
Stakeholder
Requirements engineers
Architects/Designers
Architects/Designers
Designers
Developers
Testers and Integrators
Managers
New software engineers
Quality assurance team
7
Use of the architect document
Negotiate and make tradeoffs among
requirements
Resolve quality issues (e.g. performance,
maintainability etc.)
A tool to structure and analyze the system
Design modules according to interfaces
Get better understanding of the general product
Specify black-box behavior for system testing
Create teams that can work in parallel with
e.g. different modules. Plan and allocate
resources.
To get a quick view of what the system is doing
Make sure that implementation corresponds
to architecture.
When to document?
Initial
design
Design
iterations
After implementation
(consistent with code?)
design
Time
implementation
requirements
8
System
Overview
Different
structural
Views
What to document?
Development
time elements
Cryptographic
Module
Run-time
elements
Deployment
time elements
Server
On different machines?
´CPUs?
Client
Classes? Packages?
Modules? Functions?
9
Different sub-systems?
Objects?
One machine?
System
Overview
Different
structural
Views
View
diagram
View
description
What to document?Catalog with detailed
A
Packet
Handler
Mapping
between views
Description of all
relations / dependencies
10
description of all
elements (modules,
subsystems)
Encryption /
Decryption
B
Session
Handler
Detailed description of
interfaces.
System
Overview


What
to document?
Views give structural information
Need to describe behavior
Different
structural
Views
View
diagram
View
description
Mapping
between views
Behavior
11
Sequence
Diagram
State
Charts
System
Overview
Different
structural
Views
View
diagram
View
description
What to document?
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.
Mapping
between views
Behavior
Rationale
12
In general
 Why a decision was made
 What the implication is to change it