Wat is software architectuur? 1. Introductie in Software Architectuur. Waarom is software architectuur nodig? 1

Transcriptie

1 Wat is software architectuur? 1 Definitie volgens de IEEE 1471 standaard: Introductie in Software Architectuur Bastiaan Heeren (bhr@ou.nl) i.s.m. Sylvia Stuurman en Lex Bijlsma Open Universiteit 31 oktober 2016, gastcollege MSO, Utrecht The fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. I In termen van deelsystemen I Onderlinge relaties tussen deelsystemen I Relaties tussen deelsystemen en de omgeving I Principes die ten grondslag liggen aan het ontwerp en de evolutie 2 Waarom is software architectuur nodig? 1 Waarom is software architectuur nodig? (2) 1 I Applicaties worden steeds ingewikkelder en gebruiken steeds meer verschillende technologieën Als aan architectuur te weinig aandacht wordt besteed, is: I De code alleen heel moeizaam aan te passen I Kwaliteitskenmerken zoals betrouwbaarheid kunnen niet op codeniveau worden geanalyseerd I De kwaliteit van de software niet vooraf te voorspellen I Het risico van een veranderscenario niet te bepalen I Architectuur geeft vocabulaire voor tijdige discussie over consequenties van vroege ontwerpbeslissingen I De integratie met andere systemen niet zonder meer mogelijk I Het doel van sommige codefragmenten raadselachtig 3 4

2 Overzicht 1 1. Wat is software architectuur? 2. Belanghebbenden en wensen 3. Tactieken en patronen 4. Software architectuur document 5. Applicatie integratie 6. Web services en REST 7. Conclusies Belanghebbenden 2 Bij een systeem zijn tenminste vier partijen betrokken: 1. Klant 2. Eindgebruiker 3. Ontwikkelaars 4. Onderhoudsteam I Partijen hebben niet alleen wensen over wat het systeem kan (functionaliteit), maar ook hoe (kwaliteitskenmerken) I De niet-functionele wensen zijn dikwijls tegenstrijdig I Rol van de architect: Inventariseren en prioriteren van wensen (dit vereist diplomatie, communicatie en onderhandeling) Effecten van een ontwerp kunnen voorspellen (kennis) 5 6 Een voorbeeld 2 Wensen analyseren 2 Gebruik bestaande Oracle Terminologie moet door iedereen op dezelfde manier worden geïnterpreteerd Welke Schaalbaarheid: stakeholders zouden tot 100,000 dezegebruikers belangen kunnen hebben? Uptime: five nines Voorbeeld: wanneer noemen we een programma efficiënt? Throughput Budget: 100,000 euro Beschikbaarheid: 24/7 Responstijd Architect Gebruik huidig ontwikkelteam Klaar voor de toekomst Oplevering: zomer 2017 Geheugengebruik Het ISO kwaliteitsraamwerk biedt een oplossing: I Legt betekenis (redelijk) precies vast Max. responstijd: 0.5 seconde I Definieert 13 karakteristieken I Helpt bij het controleren van volledigheid 7 8

3 Quality in use model (ISO 25010) 2 Product quality model (ISO 25010) 2 effectiveness accuracy and completeness with which users achieve specified goals pleasure degree to which a user obtains pleasure from fulfilling their personal needs context completeness degree to which a product or system can be used with effectiveness, efficiency, freedom from risk and satisfaction in all the specified contexts of use 9 10 Realiseren van wensen 3 Tactieken voor herstelvermogen 3 I Van veel architectuurbeslissingen is door ervaring bekend welke invloed ze hebben op kwaliteitskenmerken van het systeem I Per kwaliteitskenmerk is een collectie tactieken bekend Twee verschillende tactieken zijn niet noodzakelijk compatibel I De architect kiest per kwaliteit een tactiek uit de collectie Opdat een compatibele verzameling ontstaat die zo veel mogelijk wensen realiseert Herstelvermogen (recoverability valt onder reliability): de mate waarin het mogelijk is na een fout het niveau van functioneren te herstellen en de aangetaste gegevens te reconstrueren 1. Stemmen: meerdere processen hetzelfde laten doen 2. Actieve redundantie: eerste antwoord gebruiken 3. Passieve redundantie: componenten stand-by zetten 4. Schaduwdraaien: tijdelijk de antwoorden vergelijken met die van de andere componenten 5. Terugdraaien: momentopname maken van een consistente toestand 11 12

4 Architectuurpatronen 3 Het pipe-filter patroon 3 Patronen leggen good practices vast en beschrijven oplossingen voor terugkerende problemen Architectuurpatronen: I Richten zich op een terugkomend ontwerpprobleem I Leggen bestaande en aangetoonde ontwerpervaringen vast I Leveren een vocabulaire en begrip voor ontwerpprincipes I Helpen om een software architectuur te documenteren I Maken het mogelijk om te redeneren over bepaalde eigenschappen van een softwaresysteem I Geschikte structuur voor systemen die een stream met data produceren of bewerken I Elke bewerkingsstap gebeurt in een filter component I Data wordt met een pipe doorgegeven aan de volgende filter component I Een pipe kan buffering en synchronisatie verzorgen Voorbeeld: PipeUnix shell commando s: Pipe Pipe Source Filter Filter Sink cat file grep SWA sort uniq > out Kenmerken pipe-filter patroon 3 Het event-bus patroon 3 Voordelen: I Extra filter toevoegen is makkelijk I Filters zijn herbruikbaar I Onafhankelijk ontwikkelen en testen van filters I Natuurlijke ondersteuning voor concurrency I Analyseren van de throughput is eenvoudig I Event sources plaatsen berichten op de verschillende kanalen van een event-bus I Event listeners melden zich aan bij kanalen I Listeners worden ingelicht bij plaatsing bericht I Genereren en bezorging van berichten gebeurt asynchroon Source Source Nadelen: I Uniform data formaat kan voor overhead zorgen Channel Channel Bus I Minder geschikt voor interactieve applicaties Listener Listener 15 16

5 Kenmerken event-bus patroon 3 Documenteren van een software architectuur 4 Voordelen: I Toevoegen en verwijderen van sources, listeners en verbindingen is simpel (zelfs dynamisch) I Monitoren en/of loggen van events is makkelijk Nadelen: I Moeilijk aannames te maken over distributie, tijd, volgorde en bezorging van berichten I Schaalbaarheid: de event-bus kan een bottleneck worden I Impliciete communicatie geeft weinig inzicht in het systeem Het architectuurdocument legt de keuzes en doelen vast en dient als communicatiemiddel naar de betrokken partijen I Beschrijf het ontwerp niet in één model, maar vanuit verschillende perspectieven Een perspectief kan weer bestaan uit meerdere views Let op de onderlinge consistentie I Documenteer ook de rationale achter een ontwerpkeuze I Verschillende templates zijn beschikbaar (bijv. van het SEI) I Er zijn coherente verzamelingen van perspectieven (bijv. Kruchten s 4+1 model) Kruchten s 4+1 model 4 Overzicht 5 Eindgebruikers functionaliteit Logical view Programmeurs software management Development view 1. Wat is software architectuur? 2. Belanghebbenden en wensen 3. Tactieken en patronen Scenarios 4. Software architectuur document Process view Physical view 5. Applicatie integratie Systeem integrators performance schaalbaarheid throughput Systeem engineers systeem topologie oplevering installatie 6. Web services en REST 7. Conclusies 19 20

6 Integratie uitdagingen 5 Enterprise Integration Patterns 5 I Verandering nodig in bedrijfspolitiek I Belangrijke positie binnen het bedrijf I Beperkte controle over applicaties packaged software, legacy systems I Weinig integratie standaarden CORBA, XML, web services I Overeenkomende presentatie standaarden impliceren niet zelfde semantiek I Door mix van technologie is integratie complex, ook in onderhoud Boek van Gregor Hohpe en Bobby Woolf I Beschrijft 65 integratiepatronen Voor de catalogus, zie: patterns/messaging/ Integratie patronen 5 Basis concepten messaging 5 1. File transfer Elke applicatie produceert bestanden met gedeelde data voor anderen om in te lezen 2. Shared database Applicaties slaan te delen data op in een gemeenschappelijke database 3. Remote procedure calls Elke applicatie exporteert een aantal procedures voor remote invocation (opstarten, uitwisselen van data) 4. Messaging Elke applicatie verbindt zich met een gezamenlijk messaging systeem I Channels (virtual pipe) I Messages (atomic package) I Pipes and filters I Routing I Transformaties I Endpoints 23 24

7 Messaging patterns (Hohpe en Woolf) 5 Voorbeeld: Message expiration 5 I Hoe kan een zender aangeven wanneer een message is verlopen (en niet langer moet worden afgehandeld)? I Oplossing: specificeer de verlooptijd van een message Voorbeeld: Test message 5 Software compositie 6 I Hoe kun je achterhalen of een component wel goed functioneert en correcte resultaten oplevert? I Hoe stel je kleinere software units samen tot een groter systeem? I Hoe kun je software hergebruiken zonder deze aan te passen? I Oplossing: gebruik test-boodschappen om de werking van componenten te controleren I Sleutel tot succes is de specificatie van duidelijke interfaces Net als bij OO: één verantwoordelijkheid, verbergen van implementatiedetails Wat varieert? Wat ligt vast? I Door de jaren heen zijn diverse technologieën ontstaan om hergebruik te bevorderen I Steeds meer nadruk op hergebruik en standaardisatie 27 28

8 Trends in software systemen 6 Voordelen van software hergebruik 6 Hergebruik wordt steeds belangrijker: 1. Software systemen worden steeds groter Voorbeeld: Windows NT (1991, 1.8M SLOC), Windows XP (45M SLOC), Windows Visa nog eens 40% groter 2. Software moet met steeds meer variatie kunnen omgaan Variabiliteit is bepalend voor de complexiteit Voorbeeld: de Linux Kernel heeft (> 10,000) configuratie opties 3. Steeds vaker late binding tussen componenten Voordeel van late binding : je hoeft compile-time weinig te weten over andere componenten. Loose coupling is een goed ontwerpprincipe, maar kan ten koste gaan van efficiëntie en betrouwbaarheid Sommerville noemt: I Meer betrouwbaar (beter getest, langer in gebruik) I Vermindert risico bij het ontwikkelen van nieuwe software Het integreren van componenten wordt wel vaak onderschat I Effectief hergebruik van specialistische domeinkennis Voorbeeld: een database I Bevordert standaardisatie I Versnelt het ontwikkelproces Spectrum van architecturale specialisatie 6 Software componenten 6 A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard. [Heineman] Uit Garlands artikel (2009): Architectural Mismatch: why reuse is still so hard A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition. [Szyperski] 31 32

9 Waarom CORBA is mislukt 6 Service georiënteerde architecturen 6 I Te ingewikkelde standaard met complexe APIs I Opvallend lastig om een niet-triviaal systeem te maken met deze APIs I Standaard was (technisch) onvolwassen en daardoor onmogelijk juist te implementeren I Design by committee: gebaseerd op onbewezen technieken, gepushed vanuit commerciële partijen I (Stricte) firewalls blokkeren CORBA berichtverkeer I Simpele alternatieven kwamen beschikbaar, in het bijzonder Enterprise JavaBeans (EJB) I Logische vervolgstap op componenttechnologieën voor het ontwikkelen van applicatie integratie middleware I Oplossing voor het interoperabiliteitsprobleem op Internet-schaal I Beëindigt een jarenlange middleware-strijd tussen commerciële partijen CORBA JEE voor Java Microsofts DCOM I Focus ligt op interoperabiliteit en pragmatische ondersteuning van de diversiteit in systemen I Web services: verzameling applicatie integratie standaarden Voordelen van SOA 6 Web services 6 1. Hergebruik van services in meerdere applicaties 2. Efficiëntie: creëren van nieuwe services en combineren van bestaande services Focus op gedeelde data, niet de onderliggende implementatie 3. Lage technologie koppeling, onafhankelijkheid van de executie omgeving 4. Splitsen van verantwoordelijkheden Ook business versus technologie Web services is een verzameling integratie-technologie standaarden die de requirements van een service-georiënteerde architectuur kunnen bewerkstelligen De vier basis functies: I Geschikte services vinden (UDDI, directory) I Achter de interface van een service komen (WSDL) I Een service aanroepen (SOAP) I Extra functionaliteit gebruiken, zoals security (WS-* standaarden) Web services zijn gebaseerd op XML 35 36

10 Twee stijlen van service compositie 6 Twee stijlen van service compositie (2) 6 Orchestration Choreography send Service A reply Service B Service A Service B receive invoke Composite Service Service C Service D Service C Service D Orchestration Choreography WS-BPEL is de belangrijkste standaard voor orchestration I Business Process Execution Language I XML gebaseerd I Een orchestration is zelf ook weer een dienst De REST architectuurstijl 6 REST en HTTP 6 I REST: Representational State Transfer (Fielding, 2000) I Gebaseerd op de belangrijkste ontwerpprincipes van het World Wide Web: 1. Minimale latency 2. Maximale schaalbaarheid 3. Onafhankelijke componenten (loose coupling) I Populaire benadering om web services te implementeren I Centrale concept is een resource (ROA) I Fielding was nauw betrokken bij specificatie van HTTP I REST is een architectuurstijl: HTTP is een veel striktere invulling van die stijl I De REST principes beschrijven het ontwerp van HTTP (a posteriori) I REST is het web zoals het is bedoeld I Gerelateerd aan Hypertext Transfer Protocol (HTTP) en Uniform Resource Identifiers (URIs) 39 40

11 Constraints voor de ontwerpruimte 6 Constraint 1: Client- 6 I Een architectuurstijl beperkt de ontwerpruimte door constraints op te leggen I Met goed gekozen constraints kunnen specifieke doelen worden bereikt I De REST stijl heeft zes constraints I Het startpunt is de zogenaamde null style waar alle denkbare ontwerpen onder vallen I Nadruk van constraints ligt op de connectors, niet op de processing componenten request response Constraint 2: Stateless communicatie 6 Constraint 3: Caching 6 request response request response resource/document cache 43 44

12 Constraint 4: Uniforme interface 6 Constraint 5: Layered system 6 orb gateway orb request response resource/document proxy proxy WAIS cache connector connector Constraint 6: Code on demand (optional) 6 Competenties van een architect 7.js.js gateway proxy orb.js I Communiceren met belanghebbenden Begrijpen van hun wensen Instemming met prioritering verwerven I Abstraheren en modelleren Relevante perspectieven en viewpoints selecteren Produceren van modellen (o.a. UML, ArchiMate) en views.js.js.js resource/document JavaScript resource JavaScript engine cache I Creëren van een architectuur Met behulp van geschikte tactieken en patronen I Bewaken van de architectuur Voorkomen dat deze tijdens de constructiefase uit het oog wordt verloren connector connector 47 48

13 Meer weten?