SA 1 - Introduction to Software
Architecture
Een software architect maakt het architecture notebook en geeft een beeld van de architectuur
van het systeem.
What is Software Architecture?
Software architecture bevat de van significante beslissingen over de organisatie van een software
systeem:
• Selectie van de structurele elementen en hun interfaces waaruit een systeem bestaat.
• De samenwerking tussen deze elementen.
• Compositie van deze structurele en gedrags- elementen in grotere subsystemen.
• Architecturale stijl dat de organisatie leidt
Architecturale beslissingen zijn de meest fundamentele beslissingen. Het veranderen hiervan zal
een ripple effect als consequentie hebben.
Products of Software Architecture
Een software architect moet oplossingen vinden voor het implementeren van de:
1. Functional requirements: specificaties over de benodigde functionaliteit voor de gebruiker
organisatie.
2. Non-functional requirements (quality requirements): bv. maintainability, performance etc..
3. Producten (artifacts): Architecturale producten laten zien hoe de requirements gerealiseerd
moeten worden.
Architecture Notebook/Document bevat:
• Non-functional requirements
• Key functional requirements (use case model) OOAD
• Domain class model
• Component model
• Layer model (logical)
• Tier model (physical) SARCH
• Deployment model
• Key scenarios
Een software architect communiceert met de project manager, de ontwikkelaars, analisten en
stakeholders en denkt na over de analyses en het design.
Jet Wardenier 28/12
, SA 2 - Architecture Notebook
Leerdoel: De onderdelen van een architecture notebook beschrijven en herkennen
Een architecture notebook is het meest essentiële artefact van een architect. Tijdens de inception
fase wordt de architecture bedacht en tijdens elaboration wordt hij uitgewerkt.
Inhoud van een Architecture Notebook:
1. Architectural goals
2. Architectural Significant requirements
2.1 Functional
2.2 Non-functional
3. Decisions and Justifications
4. Key abstractions/domain model
5. Software partitioning model
5.1 Logical component model
5.2 Layers model
5.3 Physical Component & Layers
6. Tier model
7. Deployment model
Bij een klein project moet je niet te veel tijd besteden aan het documenteren van de architectuur
maar alle essentiële elementen moeten wel gecommuniceerd worden.
Architectural Goals versus Architectural Requirements
Architecturale goals geven een bepaalde motivatie en onderbouwing voor genomen beslissingen.
Deze zijn vaak afleidbaar van de Requirements.
Het verschil tussen de requirements en de goals is dat de goals definiëren hoe een systeem moet
omgaan met bepaalde veranderingen.
Architecturale goals beantwoorden dit soort vragen:
- Wat is de verwachtte lifespan van een systeem?
- Moet het systeem nieuwe technologische veranderingen aan kunnen, zoals nieuwe versies?
- Hoe vaak moet een systeem zich kunnen aanpassen aan verwachtte verandering?
- Op welke komende veranderingen kunnen we anticiperen en hoe kunnen zorgen dat het
systeem zich makkelijker aan kan
passen?
Dit soort vragen kunnen grote
consequenties hebben op de structuur van
het systeem.
Decisions and Justification
Leg belangrijke beslissingen over de architectuur vast en zorg ervoor dat het team de architectuur
begrijpt en het kan realiseren.
Key abstractions/Domain model
Identificeer de key concepts en abstracties dat het systeem moet gebruiken. De requirements zijn
een goede bron voor het vinden van key abstractions.
Jet Wardenier 28/12
Architecture
Een software architect maakt het architecture notebook en geeft een beeld van de architectuur
van het systeem.
What is Software Architecture?
Software architecture bevat de van significante beslissingen over de organisatie van een software
systeem:
• Selectie van de structurele elementen en hun interfaces waaruit een systeem bestaat.
• De samenwerking tussen deze elementen.
• Compositie van deze structurele en gedrags- elementen in grotere subsystemen.
• Architecturale stijl dat de organisatie leidt
Architecturale beslissingen zijn de meest fundamentele beslissingen. Het veranderen hiervan zal
een ripple effect als consequentie hebben.
Products of Software Architecture
Een software architect moet oplossingen vinden voor het implementeren van de:
1. Functional requirements: specificaties over de benodigde functionaliteit voor de gebruiker
organisatie.
2. Non-functional requirements (quality requirements): bv. maintainability, performance etc..
3. Producten (artifacts): Architecturale producten laten zien hoe de requirements gerealiseerd
moeten worden.
Architecture Notebook/Document bevat:
• Non-functional requirements
• Key functional requirements (use case model) OOAD
• Domain class model
• Component model
• Layer model (logical)
• Tier model (physical) SARCH
• Deployment model
• Key scenarios
Een software architect communiceert met de project manager, de ontwikkelaars, analisten en
stakeholders en denkt na over de analyses en het design.
Jet Wardenier 28/12
, SA 2 - Architecture Notebook
Leerdoel: De onderdelen van een architecture notebook beschrijven en herkennen
Een architecture notebook is het meest essentiële artefact van een architect. Tijdens de inception
fase wordt de architecture bedacht en tijdens elaboration wordt hij uitgewerkt.
Inhoud van een Architecture Notebook:
1. Architectural goals
2. Architectural Significant requirements
2.1 Functional
2.2 Non-functional
3. Decisions and Justifications
4. Key abstractions/domain model
5. Software partitioning model
5.1 Logical component model
5.2 Layers model
5.3 Physical Component & Layers
6. Tier model
7. Deployment model
Bij een klein project moet je niet te veel tijd besteden aan het documenteren van de architectuur
maar alle essentiële elementen moeten wel gecommuniceerd worden.
Architectural Goals versus Architectural Requirements
Architecturale goals geven een bepaalde motivatie en onderbouwing voor genomen beslissingen.
Deze zijn vaak afleidbaar van de Requirements.
Het verschil tussen de requirements en de goals is dat de goals definiëren hoe een systeem moet
omgaan met bepaalde veranderingen.
Architecturale goals beantwoorden dit soort vragen:
- Wat is de verwachtte lifespan van een systeem?
- Moet het systeem nieuwe technologische veranderingen aan kunnen, zoals nieuwe versies?
- Hoe vaak moet een systeem zich kunnen aanpassen aan verwachtte verandering?
- Op welke komende veranderingen kunnen we anticiperen en hoe kunnen zorgen dat het
systeem zich makkelijker aan kan
passen?
Dit soort vragen kunnen grote
consequenties hebben op de structuur van
het systeem.
Decisions and Justification
Leg belangrijke beslissingen over de architectuur vast en zorg ervoor dat het team de architectuur
begrijpt en het kan realiseren.
Key abstractions/Domain model
Identificeer de key concepts en abstracties dat het systeem moet gebruiken. De requirements zijn
een goede bron voor het vinden van key abstractions.
Jet Wardenier 28/12
