šŸŒµOldMartijntje

avans 2-4 sa1 softwarearchitectuur en kwaliteit

5 min read

ID: S202604230903
Status: school
Tags: avans 2-4, avans 2-4 softwarearchitectuur en kwaliteit vak

avans 2-4 sa1 softwarearchitectuur en kwaliteit

ā‡ Les ā‡’

Robins Regels

  • Aanwezigheid:
    • Wees aanwezig in de les, want dat helpt jou. Het is geen leerplicht tho. Als je niet in de les was krijg je wel een mailtje van Robin. Het is beter als je je vooraf afmeld tho.
    • Kom op tijd, want de deur van het lokaal gaat dicht 10m na schooltijd
    • Deur dicht? geen toegang. Je kan tijdens de pauze weer naar binnen. Robin gaat wel regelmatig pauzeren zegt hij.
    • Les verlaten? Alleen tijdens de pauze momenten.
  • Aandacht:
    • Heb aandacht, ga niet andere dingen doen tijdens de les.
    • Wees stil, want dit stoort de medestudenten
    • Toch liever andere dingen doen? verlaat de les in de pauze
    • Aandacht weg? geef dat aan, misschien kan Robin je helpen of een pauze inlassen.
  • Eten en drinken:
    • Drinken mag best, maar geen blinkies
    • Eten mag best, maar ga niet storend lang ritselen met zakjes
    • Ga geen sterk ruikend eten eten zoals pizza
  • Devices:
    • Doe geen koptelefoon op
    • Smartphone gebruik je niet in de les, tenzij het nodig is voor de les. Want dit lijdt jezelf alleen maar af.

Wat er aan bod komt

Sprintreview les van vandaag vervalt, dit wordt tijd om te werken aan de sprint.

Powerpoint systeemanalyse

Het doel van deze les is om het in kaart te brengen van OpenMRS.

Architectural Decision Records.

ISO 42010:2011

Design Patterns - GoF

Ieder software systeem heeft een architectuur

  • met eigenschappen en gedrag
  • met componenten en samenhang
  • voortkomend uit beslissingen
  • die soms onzichtbaar is

System architecture vs Application architecture.

Architectuur analyse

  • Technical Debt

Praktische verkenning

  • Vragen stellen aan een software engineer of architect
  • Documentatie lezen
  • CI/CD pipelines bekijken
  • Code analyseren

AI ondersteuning kan je gebruiken om een bestaande codebase te analyseren. Dit kan je doen met tools zoals deepwiki.org

Praktische verkenning OpenMRS.

Voer een praktische analyse uit.

QA:

  • Welke technologiĆ«n worden gebruikt?
  • Kun je iets zeggen over de applicatie architectuur
  • Kun je iets zeggen over de systeem architectuur
  • Kun je informatie vinden over de ontwerpbeslissingen.

voldoet het

Zorg ervoor dat je tekent, want plaatjes zijn makkelijker op te nemen dan text, denk aan UML, process diagrammen, applicatie overzichten etc.

maak zoveel documentatie van tevoren tot dat degene waarvoor je het schrijft genoeg informatie heeft om het te kunnen snappen.

Soorten visualisaties:

Applicatie integratie

Hoe laat je applicaties en systemen met elkaar praten?

Point to Point Koppeling

  • Snel te realiseren
  • Simpel op het 1e gezicht
  • Niet schaalbaar

Service Oriented Architecture

  • Loose coupling
  • Services en protocollen met duidelijke functies
  • Herbruikbaarheid

Other

  • RESTful service interfaces
  • Message queueing
  • Simple object access protocol

Opdracht

  • de LU1 opdracht is hier te lezen. En hier is de samenvatting.
  • Dit is de 1e sprint opdracht. Dit gaat vooral over het maken van ADRā€™s. Dit moet eigenlijk klaar zijn vandaag, dat wordt m niet. We moeten wel zorgen dus dat sprint 1 en 2 klaar zijn wanneer de 2e sprint voorbij is. Vr 8 mei moet sprint 2 eig al af zijn.

Het wordt wel ff werk aan de winkel door al die vrije dagen.

De sprint inleveringen kunnen we gebruiken voor feedback, dit hoeft maar 1 iemand per groepje te doen.

Architectural Decision Records

Iedere beschrijving (of visualisatie) is vastgelegd op Ć©Ć©n moment in de tijd. De architect die drie jaar geleden de frameworkkeuze maakte, werkt er niet meer. Wat nu?

Je wilt beslissingen kunnen terugberedeneren, want soms verandere dingen, soms voelen dingne niet logisch meer.

Een Architectural Decision Records is een korte documentatie, een soort snapshot.

# Title
 
## Context and Problem Statement
 
## Decision Drivers
 
## Considered Options
 
## Decision Outcome
 
### Consequences
 
### Option 1
Good because {argument}
Neutral, because {argument}
Bad, because {argument}
 
## More information

Dit is geen gestandaardiseerd ding, maar zorg dat je in je project een standaard formaat heeft wat er ongeveer uitziet als het bovenstaande.

Avans example of a good Architectural Decision Records:

---
status: Accepted
date: 2022-11-22
deciders: ZIO

---

# AD: System Decomposition into Logical Layers

## Context and Problem Statement

Which concept is used to decompose the system under construction into logical building blocks?

## Decision Drivers

* Desire to divide the overall system into manageable parts to reduce complexity

* Ability to exchange system parts without affecting others

## Considered Options

1. Layers pattern
2. Pipes-and-filters
3. Workflow

## Decision Outcome

We decided to apply the Layers pattern and neglected other decomposition pattern such as pipes-and-filters or workflow because the system under construction and its capabilities do not suggest an organization by data flow or control flow. Technology is expected to be primary driver of change during system evolution.

### Consequences

* Good, because the Layers pattern provides high flexibility regarding technology selections within the layers (changeability) and enables teams to work on system parts in parallel.
* Bad, because there might be a performance penalty for each level of indirection and some undesired replication of implementation artifacts.

## More Information

* The three decomposition options come from the Cloud Computing Pattern [Distributed Application](https://www.cloudcomputingpatterns.org/distributed_application/).

* The Layers pattern is featured in POSA Volume 1, see <http://www.dre.vanderbilt.edu/~schmidt/POSA-tutorial.pdf>

A follow-on decision will be required to assign logical layers to physical tiers.

References

Graph View

Backlinks