Software Architecture and Requirements Engineering

Maat: px
Weergave met pagina beginnen:

Download "Software Architecture and Requirements Engineering"

Transcriptie

1 Software Architecture and Requirements Engineering Wouter Swierstra Software Project en Game Project September 18, 2014

2 Credits Deze slides zijn gebaseerd op die van de cursus Software Architectuur van de Open Universiteit Nederland, die weer waren gebaseerd op de cursus Software Architectuur van de Universiteit Utrecht. Lex Bijlsma en Bastiaan Heeren hebben de meeste slides gemaakt. Aanpassingen achteraf zijn van Jurriaan Hage en Wouter Swierstra. Deze zijn veelal gebaseerd op slides bij het boek Software Engineering van Hans van Vliet. 2

3 Wat is Software Architectuur? Wat denken jullie? 3

4 The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system s lifetime; and, in the end, architecture boils down to whatever the important stuff is. Martin Fowler s definition of Software Architecture 4

5 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 Software Architecture (IEEE 1471) De architectuur bepaalt de interactie van componenten, maar niet de implementatie Ieder systeem heeft een architectuur, maar de beschrijving is misschien niet beschikbaar De beschrijving van de architectuur van een systeem is op een hoger niveau dan een beschrijving in termen van klassen en methoden 5

6 Waarom praten we over software architectuur? Bij MSO leer je je eigen software te onwerpen. Maar bij een echt project gebruik je ook heel veel software dat je niet zelf hebt geschreven. Bij voorbeeld een webshop gebruikt haalt de prijs catalogus uit een bestaande database, moet klant gegevens bijhouden in de bestaande CRM software, enz. Voordat je zelf aan de slag gaat, moet je dus de context van jullie stukje software bedenken. 6

7 Een voorbeeld architectuur 7

8 Waarom Software Architectuur? Voor je kan beginnen te bouwen, moet je bedenken wat je moet maken (requirements). Voor je op klasse niveau kan specificeren hoe de implementatie eruit moet zien, is het nuttig om op een hoger niveau na te denken hoe je dit wil realiseren. Zo n architectuur kun je vervolgens vertalen naar een ontwerp en uiteindelijke implementatie. 8

9 Cyclus van een softwaresysteem Software architectuur verbindt (requirements) analyse en realisatie Kan incrementeel gedefinieerd worden Inschatten kwaliteitsaspecten voor realisatie Moet stabiel zijn voor het ontwikkelen begint Maakt de evolutie van een systeem mogelijk 9

10 Waarom is Software Architectuur nodig? Softwareapplicaties worden steeds groter moeten geïntegreerd worden met bestaande omgeving gebruiken vele (nieuwe) technologieën Het laten samenwerken van verschillende technologieën en disciplines wordt ook wel orkestratie genoemd. Sommige kwaliteitsattributen kunnen niet op het code-niveau gerealiseerd worden 10

11 Waarom is Software Architectuur nodig? Softwareapplicaties worden steeds groter moeten geïntegreerd worden met bestaande omgeving gebruiken vele (nieuwe) technologieën Het laten samenwerken van verschillende technologieën en disciplines wordt ook wel orkestratie genoemd. Sommige kwaliteitsattributen kunnen niet op het code-niveau gerealiseerd worden 10

12 Waarom is een architectuurbeschrijving nodig? 1. Communicatie onderling en met belanghebbende partijen voor begrip, communicatie, onderhandeling en consensus 2. Documenteert vroege ontwerpbeslissingen Basis voor de werkverdeling (work-breakdown) Middel om kwaliteitsattributen te evalueren (eerste moment om systeemeigenschappen te voorspellen) 3. Herbruikbare abstractie van een systeem grootschalig hergebruik (product line) componenten en services 11

13 Scope en focus: twee dimensies Stel eerst de scope en de focus van een architectuur vast Scope: welke applicaties behoren tot de architectuur? Voorbeelden: Enkel systeem of product Systeem familie (Philips Medical Systems) Business unit? Of de hele organisatie?... Wat is de context waarin je werkt? 12

14 Scope en focus: twee dimensies Wat is de focus van de architectuur? Business architectuur business strategy, governance, organisatie, key business processes Business Process Reengineering (BPR): analyse en ontwerp van processen Information technology (IT) architectuur Hardware en software infrastructuur (inclusief databases en middleware) Information architectuur data opslag en data management (steeds belangrijker onderdeel) Application (software) architectuur Gedetailleerde omschrijving afzonderlijke applicaties, interactie, relatie tot bedrijfsprocessen 13

15 Scope en focus: twee dimensies Wat is de focus van de architectuur? Business architectuur business strategy, governance, organisatie, key business processes Business Process Reengineering (BPR): analyse en ontwerp van processen Information technology (IT) architectuur Hardware en software infrastructuur (inclusief databases en middleware) Geen duidelijke grenzen Information architectuur Tezamen vormen deze architecturen de enterprise architectuur Application (software) architectuur data opslag en data management (steeds belangrijker onderdeel) Gedetailleerde omschrijving afzonderlijke applicaties, interactie, relatie tot bedrijfsprocessen 13

16 Software Architectuur als een wetenschap Mary Shaw s artikel in 1989: Larger scale systems require higher level abstractions Vergelijkbaar met andere engineering disciplines? 14

17 Software Architectuur als een wetenschap Mary Shaw s artikel in 1989: Larger scale systems require higher level abstractions Vergelijkbaar met andere engineering disciplines? stakeholders en belangen analyse en validatie verschillende gezichtspunten standaardisatie en hergebruik best practices en certificering Maar: 14

18 Software Architectuur als een wetenschap Mary Shaw s artikel in 1989: Larger scale systems require higher level abstractions Vergelijkbaar met andere engineering disciplines? stakeholders en belangen analyse en validatie verschillende gezichtspunten standaardisatie en hergebruik best practices en certificering Maar: reproductie is makkelijk parametrisatie en instantiatie complexiteit is relatief onzichtbaar 14

19 De architect en de engineer De architect: creëert een visie neemt beslissingen behartigt de belangen van de stakeholders beheert de visie De engineer: analyseert precieze en gedetailleerde requirements levert gedetailleerde oplossingen zorgt dat het naar behoren werkt 15

20 Stakeholders en belangen Definities (Rozanski en Woods): A stakeholder in a software architecture is a person, group, or entity with an interst in or concerns about the realization of the architecture. A concern about an architecture is a requirement, an objective, an intention, or an aspiration a stakeholder has for that architecture. 16

21 Stakeholders en belangen Minstens vier partijen (IEEE 1471): Eindgebruikers Aanschaffende partij (klant) Ontwikkelaars Onderhoudsteam Welke nog meer? Waar liggen de belangen van deze partijen? Hoe zit dat voor jullie project? 17

22 Stakeholders en belangen Stakeholders: Vertegenwoordigers uit alle fasen van het project (ontwikkeling, gebruik en ondersteuning) Belangen: gerelateerd aan ontwikkeling, uitvoering, gebruik of evolutie van een systeem functionaliteit, kwaliteitsgebieden, ontwikkelingsproces, kosten, technologie Kostbaar om later kwaliteitsattributen toe te voegen Belangen vaak tegenstrijdig (Twitter: schaalbaarheid ten opzichte van betrouwbaarheid) Prioriteiten aanbrengen! 18

23 Stakeholders en belangen Stakeholders: Vertegenwoordigers uit alle fasen van het project (ontwikkeling, gebruik en ondersteuning) Belangen: gerelateerd aan ontwikkeling, uitvoering, gebruik of evolutie van een systeem functionaliteit, In een architectuur kwaliteitsgebieden, moet de ontwikkelingsproces, juiste balans kosten, gevonden technologie worden in de belangen van de stakeholders: Kostbaar om later kwaliteitsattributen toe te voegen Belangen vaak tegenstrijdig (Twitter: schaalbaarheid ten opzichte van betrouwbaarheid) Prioriteiten aanbrengen! 18

24 Een voorbeeld Oplevering: 1 januari 2015 Welke stakeholders zouden deze belangen kunnen hebben? Architect Gebruik bestaande Oracle server 19

25 Een voorbeeld Oplevering: 1 januari 2015 Klaar voor de toekomst Budget: 100,000 euro Architect Gebruik bestaande Oracle server 19

26 Een voorbeeld Uptime: five nines Oplevering: 1 januari 2015 Beschikbaarheid: 24/7 Gebruik huidig ontwikkelteam Klaar voor de toekomst Budget: 100,000 euro Architect Gebruik bestaande Oracle server 19

27 Een voorbeeld Oplevering: 1 januari 2015 Beschikbaarheid: 24/7 Gebruik huidig ontwikkelteam Klaar voor de toekomst Budget: 100,000 euro Architect Max. responstijd: 0.5 seconde Schaalbaarheid: tot 100,000 gebruikers Gebruik bestaande Oracle server 19

28 Kwaliteitsmodel Reliability maturity fault tolerance recoverability availability degradability Functionality suitability accuracy interoperability compliance security traceability Extended ISO Model Efficiency time behaviour resource behaviour Usability understandability learnability explicitness customisability attractivity clarity helpfulness user-friendliness Portability adaptability installability conformance replaceability Maintainability analysability changeability stability testability manageability reusability 20

29 De Sinterklaas valkuil Quality attributes zijn geen verlanglijstje... Iemand houd een geweer tegen je hoofd en dwingt je te kiezen: snel of betrouwbaar? veel features (functionality) of mooie code (maintainability)?... Maak duidelijk waar je prioriteiten liggen. 21

30 Quality Assurance De prioriteiten van je kwaliteitsattributen beinvloeden je keuze voor een bepaalde architectuur. Je kan op verschillende manieren toetsen of jouw keuze van architectuur de juiste is: Pas specifieke maatregelen toe (in het ontwerp, de technologie of het proces) Architectural prototypes Reviews (bijvoorbeeld door een expert) Assessment methodes Automatische analyse (geschikte modellen en beschrijvingen) Niet alle eigenschappen kunnen in een vroeg stadium (of automatisch) geanalyseerd worden 22

31 Quality Assurance De prioriteiten van je kwaliteitsattributen beinvloeden je keuze voor een bepaalde architectuur. Je kan op verschillende manieren toetsen of jouw keuze van architectuur de juiste is: Pas specifieke maatregelen toe (in het ontwerp, de technologie of het proces) Architectural prototypes Reviews (bijvoorbeeld door een expert) Assessment methodes Automatische analyse (geschikte modellen en beschrijvingen) Niet alle eigenschappen kunnen in een vroeg stadium (of automatisch) geanalyseerd worden 22

32 Beschrijven van architecturen Er is meestal niet sprake van één architectuur. Verschillende stakeholders willen verschillende informatie: Hoe moet ik het bouwen? Hoe veel gaat het kosten? Waar wordt het gedeployed? 23

33 Beschrijven van architecturen Definitie: A viewpoint addresses one or more concerns of a stakeholder Viewpoints ontwikkelaars, maintainers, eindgebruikers, project managers, service engineers, auditors, andere architecten Reference models Zachman, Kruchten s 4+1 model Talen om architecturen te beschrijven: plaatjes natuurlijke taal formele talen (MIL, ADL) UML 24

34 Modellen Een model is een versimpeling van de werkelijkheid Functies van een model: visualiseren van het systeem specificeren van het systeem templates bouwen (generatie) documenteren beslissingen Elk model kan op verschillende niveaus worden uitgedrukt (algemeen versus gedetailleerd) Een view is een projectie van een model waarbij irrelevante entiteiten zijn weggelaten (vanuit een bepaald perspectief gezien) 25

35 Modellen Een model is een versimpeling van de werkelijkheid Functies van een model: visualiseren van het systeem Eén specificeren model is nooit van het voldoende: systeem beschrijf een systeem aan templates de hand van bouwen meerdere (generatie) (onafhankelijke) modellen en met documenteren meerdere views beslissingen Elk model kan op verschillende niveaus worden uitgedrukt (algemeen versus gedetailleerd) Een view is een projectie van een model waarbij irrelevante entiteiten zijn weggelaten (vanuit een bepaald perspectief gezien) 25

36 Vijf views (Kruchten) Use case view voor eindgebruikers en testers, use case/activiteit diagrammen Design view voor eindgebruikers, functionele requirements, class/object/component diagrammen Interaction view control-flow (concurrency/synchronization, performance, schaalbaarheid, throughput, interactie/state diagrammen Implementation view bouwen en releasen van fysieke systeem, configuratie management, artifact diagrammen Deployment view hardware topologie, distributie, installatie, deployment diagrammen 26

37 Welke view is voor mij belangrijk? Dat hangt af van het soort systeem: hard real-time systemen dynamische processen zijn belangrijk data-intensieve systemen views m.b.t. statisch ontwerp... De keuze van modellen bepalen ook het wereldbeeld! 27

38 Architecturen en hergebruik Een architectuur kan worden hergebruikt: Architectural styles en architectural patterns (Commerciële) frameworks Bijvoorbeeld Struts framework voor web-applicaties met MVC pattern Platformen voor infrastructurele ondersteuning Bijvoorbeeld J2EE 28

39 Architecturen en hergebruik Een architectuur kan worden hergebruikt: Architectural styles en architectural patterns (Commerciële) frameworks Bijvoorbeeld Struts framework voor web-applicaties met MVC pattern Platformen voor infrastructurele ondersteuning Bijvoorbeeld J2EE Wat is nodig voor hergebruik? Architectuur standaarden met duidelijke component-rollen Standaarden voor een specifiek domein of een specifieke technologie 28

40 Hergebruik: een voorbeeld Familie van soortgelijke systemen Commonality versus variability Feature model: requirements voor producten in een product line Common components or framework (voor commonality) Application-specific extensions (voor variability) Domain engineering versus application engineering 29

41 Re(verse) Engineering Veel projecten beginnen niet van nul. Definitie: A legacy system is an existing computer system or application program which continues to be used because the user (typically an organization) does not want to replace or redesign it. 30 Bij het ontwikkelen zijn vaak legacy systemen betrokken Reverse engineering: achterliggende structuur onderzoeken Re-engineering: software aanpassen Issues: Is er documentatie (en is deze up-to-date)? Is het architectuur model te achterhalen? (Betrouwbare) transformaties, refactorings

42 Uitdagingen Wat zijn de belangrijkste uitdagingen van de 21e eeuw op het gebied van software engineering? 31

43 Uitdagingen Wat zijn de belangrijkste uitdagingen van de 21e eeuw op het gebied van software engineering? Sommerville noemt er drie: 1. The legacy challenge 2. The heterogeneity challenge 3. The delivery challenge Software architectuur speelt een centrale rol bij al deze uitdagingen 31

44 Herhaling van een aantal concepten Een stakeholder is een ieder met een belang in de totstandkoming van een software systeem Klant, eindgebruiker, ontwikkelaars, onderhoudsteam, enz. Een belang is een interesse in de ontwikkeling, het uitvoeren of de evolutie van een systeem functionaliteit, kwaliteitsgebieden, ontwikkelproces, kosten, technologie, etc. Belangen van stakeholders zijn vaak tegenstrijdig Performance versus beveiliging, aanpasbaarheid versus low budget Vaak opgelost door ontwikkelaars (zonder het te documenteren) Maak prioriteiten van belangen expliciet 32

45 Balanceren van belangen Een architectuur is het eerste artefact dat het mogelijk maakt om de prioriteiten van tegenstrijdige belangen te analyseren. Van standaard architecturen is vaak bekend welke effecten ze hebben op de kwaliteitsattributen van een systeem Architectuurpatronen vergemakkelijken de communicatie Beslissingen op het architectuurniveau kunnen vroeg geanalyseerd worden (voordat de implementatie start) om te bepalen wat de gevolgen zijn voor de kwaliteitsattributen van het systeem. De architectuur kan later nauwelijks nog worden aangepast 33

46 Hoe komt een architectuur tot stand? Jouw architectuur heeft heel veel invloed op je verdere keuzes tijdens het ontwikkelen. Hoe weet je wat voor jouw project de juiste keuze is? 34

47 Requirements Engineering Definitie: A software requirement is a condition or capacity needed by a user to solve a problem or achieve an objective Requirements engineering is een cyclisch proces (versiebeheer!): 1. achterhalen requirements (elicitation) 2. formaliseren requirements (specification) 3. controleren requirements (validation en verification) 4. onderhandelen over de requirements (negotiation) 35

48 Elicitatie Begrijpen probleem begint bij begrijpen domein Domein is impliciet (in hoofden gebruikers): maak het expliciet Veel complicaties: veel kennis is moeilijk te achterhalen verschillende achtergronden (van mensen iha) hoe mensen zeggen dat ze werken en hoe ze werken een klein verschil kan grote gevolgen hebben mensen zijn beperkt rationeel vooroordelen oneerlijkheid cognitieve beperkingen (met name geheugen) 36

49 Natuurlijke taal is gevaarlijk Alle gebruikers hebben hetzelfde controle-veld Hebben ze allemaal dezelfde waarde in dat veld? Hebben waarden voor iedereen dezelfde vorm? Of is er een enkel veld voor alle gebruikers samen? 37

50 Soorten requirements Er zijn drie soorten requirements te onderscheiden: Functionele: wat moet het systeem doen? Niet-functionele: met welke kwaliteitseisen moet een systeem functioneren? Constraints: binnen welke grenzen moet het systeem gerealiseerd worden? Soms wordt er onderscheid gemaakt tussen technical constraints en business constraints 38

51 Requirements achterhalen Definitie: Requirements elicitation: the activities involved in discovering the requirements of the system 39

52 Technieken Ondervragen: interview, brainstorm sessies, questionnaire Task analysis deeltaken onderscheiden Scenario-gebaseerde analyse: hardop denken, use case analysis Ethnography: actief observeren Formulieren en document analyse Bestaand systeem bestuderen Prototyping Domeinanalyse Eigen inzicht volgen Crowdsourcing 40

53 Welke techniek moet je kiezen? Afhankelijk van situatie, natuurlijk. Gebruik verschillende technieken (en vergelijk de uitkomsten). Gebruik vooral directe lijnen: de uiteindelijke gebruikers, geen surrogaatgebruikers, geen intermediairs. Een stuk of vier onafhankelijke bronnen van informatie is veelal voldoende. Het belangrijkste is dat je gestructureerd aan de slag gaat. 41

54 Requirements specificeren Definitie: Requirements specification: rigorous modeling of requirements, to provide formal definitions for various aspects of the system Document met specificaties moet: precies zijn (startpunt voor architectuur en ontwerp) voor iedereen leesbaar en begrijpbaar zijn 42

55 Requirements specificeren Definitie: Requirements specification: rigorous modeling of requirements, to provide formal definitions for various aspects of the system Document met specificaties moet: precies zijn (startpunt voor architectuur en ontwerp) voor iedereen leesbaar en begrijpbaar zijn 42 Bij voorkeur: correct niet-ambigu volledig consistent begrijpelijk geprioriteerd controleerbaar aanpasbaar traceerbaar realistisch

56 Requirements specificeren Technieken: Entity-Relationship (E-R) modeling Structured Analysis and Design Technique (SADT) Eindige toestandsautomaten Use cases UML 43

57 De 7 zonden (van de analist) Ruis Weglating Overspecificatie (naast het wat ook het hoe) Tegenspraken Ambiguïteit Vooruitverwijzingen Wishful thinking 44

58 Requirements Validation Definities: Requirements validation is concerned with checking the requirements document for consistency, completeness, and accuracy Requirements verification is a mathematical analysis, possibly automated, of formal specifications for consistency 45 Voor validatie is interactie met de gebruiker nodig: het requirements document kan een correcte weergave zijn van de verkeerde requirements Mogelijke technieken voor validatie: Reviews (doorlezen, checklists, discussies) Prototyping Animaties

59 Hoe eerder de fout, hoe hoger de prijs Vroege fouten in software ontwikkeling hebben de meeste invloed Dus met name fouten tijdens RE kosten veel om te herstellen Besteed daarom veel aandacht aan de verificatie en validatie van de reqs 46

60 Requirements onderhandeling Door vele stakeholders en verschillende interesses moet er doorgaans worden onderhandeld. Classificeer/prioriteer requirements Welke requirements delven het onderspit? 47

61 MoSCoW Must haves - zonder deze geen zinnig systeem Should haves - willen we graag Could have - alleen als we tijd hebben Won t haves - doen we niet 48

62 Use cases Use cases zijn een techniek om de functionele requirements te specificeren ( wat moet het systeem doen? ) Contract met stakeholders over het gedrag van een systeem Beschrijft hoe een systeem reageert (onder verschillende condities) op een verzoek van een stakeholder (de primary actor) Feitelijk een tekstuele beschrijving van een scenario 49

63 Een voorbeeld Use case: Withdraw cash from ATM Level: User goal 50 Primary actor: Account holder Description: 1. Customer enters ATM card 2. ATM reads the bank ID, account number, encrypted PIN from the card, validates the bank ID and account number with the main banking system 3. Customer enters PIN. The ATM validates it against the encrypted PIN from the card. 4. Customer selects Withdraw cash and withdrawal amount 5. ATM notifies main banking system of customer account and amount, and receives bank acknowledgement 6. ATM delivers cash, card, and a receipt 7. ATM logs the transaction

64 Enige adviezen Maak use cases makkelijk te lezen, gebruik een actieve vorm (tegenwoordige tijd), beschrijf een actor die zijn doel succesvol bereikt Gebruik sub-use cases waar dit mogelijk is Laat de GUI buiten beschouwing Een actor is niet gelijk aan een rol in een organisatie: een actor interacteert met het systeem Gebruik UML use-case diagrammen voor actor/use-case of use-case/use-case relaties. Gebruik tekst om een use-case te specificeren. Het is moeilijk maar belangrijk om alle use cases bij te houden 51

65 Requirements Valkuilen functionele requirements (S. Lilly): Onduidelijke of inconsistente systeem grenzen (scope) Bekeken vanuit het systeem i.p.v. een actor Inconsistente actor namen Spiderweb actor-to-use case relaties Lange, te veel, of verwarrende use cases (niet meer te begrijpen door de klant) 52

66 Valkuilen Shopping cart mentaliteit. De alle requirements zijn even belangrijk argumentatie Use case beschrijvingen die te technisch (of te ingewikkeld) zijn zodat ze niet door de stakeholders gelezen worden 53

67 Valkuilen Shopping cart mentaliteit. De alle requirements zijn even belangrijk argumentatie Use case beschrijvingen die te technisch (of te ingewikkeld) zijn zodat ze niet door de stakeholders gelezen worden Voor elke requirement die na afloop van het project niet aantoonbaar geleverd is, knip ik één van je vingers eraf. 53

68 Quality Requirements Ook wel de niet-functionele requirements Zeer belangrijk bij het ontwerpen van een architectuur Vergelijk de architectuur van een kerncentrale systeem met dat van een computerspel Specificeer quality requirements aan de hand van een software quality model: Raamwerk voor discussies Om volledigheid te controleren 54

69 ISO 9126 (vervangen door ISO/IEC 25010) Het internationale standaard kwaliteitsmodel Onderverdeling in factoren: Functionality Reliability Usability Efficiency Maintainability Portability Deze zijn weer onderverdeeld in sub-karakteristieken: Maintainability = {Stability, Analyzability, Changeability, Testability} Deze bestaan weer uit attributen: Moet gemeten of geverifiëerd kunnen worden Niet beschreven in de standaard 55

70 Adviezen Niet alle 32 kwaliteitsattributen zijn even belangrijk (prioriteiten aanbrengen!) Zorg dat de quality requirements meetbaar zijn: Niet: Het systeem moet goed functioneren Wel: De responstijd bij interactief gebruik is minder dan 200 ms Maak verbanden tussen de quality requirements en de use cases De ATM valideert een PIN binnen 1 seconde 56

71 Change scenarios Gebruik change scenarios voor niet-functionele aspecten van een systeem Laten zich moeilijk beschrijven door een use case Vooral attributen uit Maintainability en Portability, zoals bijvoorbeeld Changeability en Adaptability 57

72 Change scenarios Gebruik change scenarios voor niet-functionele aspecten van een systeem Laten zich moeilijk beschrijven door een use case Vooral attributen uit Maintainability en Portability, zoals bijvoorbeeld Changeability en Adaptability Niet: Het systeem moet erg aanpasbaar zijn Wel: De software moet installeerbaar zijn op alle Windows en Unix platforms zonder de source code aan te passen Niet: Het systeem moet makkelijk te veranderen zijn Wel: Binnen 1 maand kan de functionaliteit van de ATM worden uitgebreid zodat gebruikers geld kunnen overmaken van een spaarrekening naar een lopende rekening 57

73 Constraints Constraints beperken de oplossingsruimte: de overige requirements specificeren het doel Zeer belangrijk! Soorten constraints: 58

74 Constraints Constraints beperken de oplossingsruimte: de overige requirements specificeren het doel Zeer belangrijk! Soorten constraints: technische: platform, hergebruik bestaand systeem, voldoen aan standaard financiële: budget organisatie: bedrijfsprocessen, beschikbaarheid klant tijd: deadline 58

75 Specificeren requirements 1. Bestudeer de stakeholders, de belangen en de scope 2. Definieer de functionele requirements Bijvoorbeeld aan de hand van use cases 3. Definieer de kwaliteits (niet-functionele) requirements Werk deze verder uit met use cases en change scenarios 4. Formuleer de constraints 59

76 Voldoen aan kwaliteits requirements Definitie: An architectural tactic is an established and proven approach you can use to help achieve a particular quality property. De kwaliteits requirements sturen de beslissingen op architectuurniveau Een beslissing (op architectuurniveau) die de kwaliteit van het product beïnvloedt wordt ook wel een tactic genoemd. Gerelateerde tactics worden samengevoegd in architectural patterns: dit zijn schema s om de structuur van het hele systeem te organiseren 60

77 Voorbeeld: tactics voor recoverability 61 Voting tussen verschillende processes die dezelfde taak uitvoeren detecteert processor fouten (geen algoritmische) Hot restart redundante componenten reageren parallel de eerste die reageert wordt gebruikt (de rest wordt genegeerd) creëert netwerk dat ongevoelig is voor single path failures Passive redundancy bij een fout overschakelen naar een klaarstaande back-up vaak gebruikt bij databases Rollback consistente toestanden onthouden als antwoord op specifieke verzoeken bijvoorbeeld bij het installeren van software

78 Voorbeeld: tactics voor changeability Maintain semantic coherence Hoge cohesie binnen een module, loose coupling naar andere modules Hide information Specificeer duidelijke interfaces (met verantwoordelijkheden) en onderhoud deze als het programma evolueert Use an intermediary Data repository koppelt producers en consumers los Design patterns zoals Facade, Mediator en Proxy vertalen syntax Brokers verbergen identiteit 62

79 Voorbeeld: tactics voor security Authentication Beinvloed usability negatief Encryption Beinvloed performance en misschien usability negatief N.B. beide bestaan in vele smaken 63

80 Voorbeeld: tactics voor availability Fault detection Ping, heartbeat, exceptions Fault recovery voting/polling, active redundancy (hot restart), passive redundancy (warm restart), rollback, spare Fault prevention transactions, checksums Availability kan ook profiteren van Security tactics zoals authenticatie en intrusion detection. 64

81 Architectuur patronen Observatie: veel systemen hebben een soortgelijke oplossingsstructuur: Wat zijn de overeenkomsten? Waarin verschillen ze? Wanneer kan de oplossing worden gebruikt? Hoe kan de oplossing (op maat) worden toegepast? 65

82 Architectuur patronen Observatie: veel systemen hebben een soortgelijke oplossingsstructuur: Wat zijn de overeenkomsten? Waarin verschillen ze? Wanneer kan de oplossing worden gebruikt? Hoe kan de oplossing (op maat) worden toegepast? 65 An architectural pattern is a proven structural organization schema for software systems. A set of predefined subsystems and their responsibilities Rules and guidelines for organizing the relationships between them Voorbeeld: MVC

83 Karakteristieken van patronen Een patroon richt zich op een terugkomend ontwerpprobleem Een patroon legt bestaande en aangetoonde ontwerpervaringen vast Patronen leveren een vocabulaire en begrip voor ontwerpprincipes Patronen zijn een middel om een software architectuur te documenteren Patronen helpen om software te ontwikkelen dat aan bepaalde eigenschappen voldoet 66

84 Schema van een patroon Een patroon bestaat (minstens) uit de volgende onderdelen: Context: een situatie die tot een probleem leidt Probleem: het terugkomende probleem Requirements waaraan de oplossing moet voldoen Constraints waar rekening mee moet worden gehouden Wenselijke eigenschappen van de oplossing Oplossing: een bewezen oplossing voor het probleem Structuur met componenten en relaties (statisch) Run-time gedrag (dynamisch) 67

85 Verschil met design patterns Een design pattern beschrijft een schema om een subsysteem of component van een software systeem te verbeteren Voorbeelden: Observer, Strategy, Abstract Factory, Proxy Design patterns zijn kleinschaliger vergeleken met architectuur patronen Beïnvloeden niet de fundamentele structuur van een systeem Betreffen slechts een enkele subsysteem Helpen een architectuur patroon te implementeren 68

86 Layers patroon The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction Elke laag levert diensten aan de (volgende) bovenliggende laag Om een dienst te implementeren mogen diensten uit de (volgende) onderliggende laag worden gebruikt Service requests gebruiken vaak synchronous procedure calls 69

87 Layers patroon voorbeelden Voorbeeld: netwerk protocollen ISO Open Systems Interconnect 7-layer model TCP/IP (versimpelde versie van het OSI model) 70

88 Layers patroon voorbeelden Voorbeelden: Applicatie: FTP en HTTP Transport: TCP Netwerk: IP Voorbeeld: netwerk protocollen ISO Open Systems Interconnect 7-layer model TCP/IP (versimpelde versie van het OSI model) 70

89 Layers patroon voorbeelden Meer voorbeelden van gelaagde architecturen: Virtuele machines (bijvoorbeeld de JVM) JVM gebruikt diensten van het onderliggende OS APIs C standaard library gebruikt Unix system calls Informatiesystemen client/server, lagen in webapplicaties Operating systems microkernel architecturen (Windows NT, 2000, XP) 71

90 Layers patroon analyse Meest stabiele abstracties in de onderste laag Lokale aanpassingen (en toevoegingen) in één laag De diensten van een laag kunnen op verschillende manieren worden geïmplementeerd (conform Bridge design pattern: dynamische link tussen abstractie en implementatie) Lagen kunnen onafhankelijk ontwikkeld worden Een abstracte service interface definiëren is niet makkelijk Mogelijke performance overhead door het herhaaldelijk transformeren van data Onderste lagen verrichten wellicht onnodig werk 72

91 Client-server patroon Een server component biedt diensten aan (aan meerdere clients) Een client component gebruikt diensten van server componenten Requests gaan vaak over proces en machine grenzen heen inter-proces communicatie mechanisme gelaagde architectuur Een server is permanent actief en in afwachting op een request 73

92 Client-server patroon 73 Een server component biedt diensten aan (aan meerdere clients) Een client component gebruikt diensten van server componenten Requests gaan vaak over proces en machine grenzen heen inter-proces communicatie mechanisme gelaagde Voorbeelden: architectuur Een server is permanent Remote DB actief access en in afwachting op een Remote request file systems Multi-tier informatiesystemen Web applicaties

93 Client-server patroon analyse Requests vaak in verschillende threads afgehandeld Inter-proces communicatie zorgt voor overhead Marshallen van requests en data Netwerk verkeer Transparantie in gedistribueerde systemen Soorten transparantie: access, location, platform, failure Toevoegen tussenliggende laag voor specifiek doel Caching, security, load balancing Soms zijn callback functies noodzakelijk Event notification Transitie naar het peer-to-peer model 74

94 Client-server patroon analyse Client en server componenten gaan vaak sessies aan. Moet de server wel of geen state bijhouden? Stateless servers: Session state wordt beheerd door de client State meezenden met iedere request Stateful servers: Session state wordt beheerd door de server State wordt geassocieerd met een client-id Overwegingen: transacties, foutafhandeling, schaalbaarheid 75

95 Master-slave patroon Het Master-Slave patroon bevordert fout-tolerantie en parallellisatie Een master component verdeelt werk onder identieke slave componenten en berekent een eindantwoord uit de antwoorden van de slave componenten Voorbeelden: Process control Embedded systemen Grootschalige parallelle berekeningen Fout-tolerante systemen 76

96 Master-slave patroon voorbeeld 77

97 Master-slave patroon analyse Divide and conquer model Als de master component faalt dan faalt het systeem Coördinatie en het eigenlijke werk zijn gescheiden Slave componenten zijn gescheiden (geen gedeelde state) Slave componenten kunnen parallel opereren De latency in de communicatie tussen de componenten kan problematisch zijn (bijvoorbeeld in hard real-time systemen) Probleem moet op te splitsen zijn 78

98 Master-slave patroon analyse Divide and conquer model Als de master component faalt dan faalt het systeem Coördinatie en het eigenlijke werk zijn gescheiden SlaveToepassingsgebieden: componenten zijn gescheiden (geen gedeelde state) Slave componenten grote fout-tolerantie kunnen parallel opereren De latencyparallelle in de communicatie berekeningentussen de componenten kan problematisch nauwkeurigheid zijn (bijvoorbeeld van eeninberekening hard real-time systemen) Probleem moet op te splitsen zijn 78

99 Pipe-filter patroon Geschikte structuur voor systemen die een stream met data produceren Elke bewerkingsstap gebeurt in een filter component Data wordt met een pipe doorgegeven aan de volgende filter component Een pipe kan buffering en synchronisatie verzorgen 79

100 Pipe-filter patroon Geschikte structuur voor systemen die een stream met data produceren Elke bewerkingsstap gebeurt in een filter component Voorbeelden: Data wordt met een pipe doorgegeven aan de volgende filter Compilers component Een Unixpipe shellkan commands buffering en synchronisatie verzorgen cat file grep SWA sort uniq > out 79

101 Pipe-filter patroon compiler 80

102 Pipe-filter patroon analyse Een nieuwe filter component toevoegen is makkelijk Filters zijn herbruikbaar Kunnen onafhankelijk ontwikkeld worden Transformeren van data kan voor extra overhead zorgen Invoer mogelijk uit verschillende bronnen (idem uitvoer) Natuurlijke ondersteuning voor concurrency Throughput en deadlock analyses zijn simpel Filters delen geen state Minder geschikt voor interactieve applicaties 81

103 Broker patroon Structureren van gedistribueerde systemen met ontkoppelde componenten die interacteren met remote service invocations Een broker component is verantwoordelijk voor het coördineren van de communicatie Doorsturen van requests, opsturen resultaten en excepties Server meldt zijn capabilities (diensten en karakteristieken) aan bij een broker Client vraagt dienst aan bij een broker Broker zoekt dienst op in zijn registry en stuurt request vervolgens door 82

104 Broker patroon analyse Dynamische veranderingen, toevoegen of verwijderen van diensten, en verplaatsen van objecten is makkelijk Distributie is transparant voor de ontwikkelaar Standaarden nodig om diensten te beschrijven Bridges kunnen helpen om de implementatie te verbergen wanneer twee brokers samen moeten werken Voorbeelden: CORBA (Common Object Request Broker Architecture) bevordert samenwerking tussen heterogene object-georiënteerde systemen. Web services 83

105 Broker patroon voorbeeld 84

106 Broker patroon IDL Een Interface Definition Language (IDL) bevat een tekstuele beschrijving van aangeboden diensten Voorbeelden: CORBA IDL, Microsoft.NET CIL, WSDL Kan voor elke programmeertaal worden geïmplementeerd 85

107 Broker patroon IDL Een Interface Definition Language (IDL) bevat een tekstuele beschrijving van aangeboden diensten Voorbeelden: CORBA IDL, Microsoft.NET CIL, WSDL Kan voor elke programmeertaal worden geïmplementeerd Het alternatief is een binaire standaard Voorbeeld: Microsoft OLE Bevat een tabel met pointers naar implementaties van methodes Client kan methode indirect aanroepen via een pointer Support nodig van de programmeertaal 85

108 Broker patroon web services UDDI Universal Discovery, Description and Integration Repository met organisaties die web services aanbieden WSDL Web Service Description Language Om de interface van een web service te definiëren SOAP Simple Object Access Protocol Transport protocol voor XML berichten XML Extendible Markup Language Taal voor het beschrijven van structuren 86

109 Peer-to-peer patroon Symmetrisch client-server model Client vraagt dienst aan bij server Server licht client in bij bepaalde events Component kan client of server of beide zijn Kunnen dynamisch van rol veranderen Client en server zijn typisch multi-threaded Diensten kunnen impliciet zijn (bijvoorbeeld door middel van een stream) Soms nodig om meerdere clients in te lichten (bijvoorbeeld met het event-bus patroon) Voorbeelden: Multi-user applicaties (drawing board) P2P file sharing 87

110 Peer-to-peer patroon analyse Weinig administratieve overhead Zelforganiserend Schaalbaar en ongevoelig voor falende peers Dynamische configuratie Geen garantie kwaliteit diensten Security is lastig 88

111 Event-bus patroon Event sources plaatsen berichten op de verschillende kanalen van een event bus Event listeners melden zich aan bij kanalen Listeners worden ingelicht bij plaatsing bericht Genereren en inlichting van berichten gebeurt asynchroon Kanalen kunnen impliciet zijn (bijvoorbeeld event patronen) 89

112 Event-bus patroon voorbeeld Voorbeelden: Monitoren van processen Trading systemen Software ontwikkelomgeving 90

113 Event-bus patroon analyse Toevoegen en verwijderen van publishers, subscribers en verbindingen is simpel (zelfs dynamisch) Moeilijk aannames te maken over distributie, tijd, volgorde en bezorging van berichten Schaalbaarheid (event-bus kan bottleneck worden) Impliciete communicatie geeft weinig inzicht in het systeem 91

114 Model-view-controller patroon Splitst interactieve applicaties in drie componenten: Model: core functionaliteit en data Views: toont informatie aan de gebruiker Controllers: verwerkt invoer van de gebruiker 92

115 Model-view-controller patroon analyse Meerdere views van een model mogelijk Het model is onafhankelijk van het aantal en soort GUIs De look and feel is makkelijk aan te passen Consistentie via notificaties (bijvoorbeeld met het Observer design pattern) Voorbeelden: Smalltalk Web presentaties (zie hoofdstuk over Enterprise application architecture ) Document-View architectuur van Windows applicaties 93

116 Model-view-controller patroon voorbeeld 94

117 Blackboard patroon Geschikt voor problemen waarvoor geen deterministische oplossingsstrategieën bekend zijn Gespecialiseerde subsystemen gebruiken kennis om een (gedeeltelijke) oplossing te vinden (of te benaderen) Voorbeelden: spraakherkenning, detectie onderzeeërs, infereren van 3D structuur van een molecuul Alle componenten hebben toegang tot een gedeelde data store (het blackboard) Componenten produceren nieuwe data objecten en plaatsen deze op het blackboard Componenten zoeken naar bepaalde data op het blackboard (bijvoorbeeld met pattern matching) 95

118 Blackboard patroon analyse Processen moeten overeenstemming bereiken over de structuur van de gedeelde data space Makkelijk om nieuwe applicaties toe te voegen Structuur data space uitbreiden is simpel Structuur data space aanpassen is lastig Synchronisatie en toegangsprivileges niet standaard ondersteund 96

119 Interpreter patroon Een gedeelte van de functionaliteit van een systeem wordt gerealiseerd door een component dat programma s interpreteert die geschreven zijn in een dedicated taal Geïnterpreteerde programma s zijn makkelijk te vervangen Problemen: stability, security, performance Voorbeelden: Regel-gebaseerde systemen Web scripting (bijvoorbeeld JavaScript) Postscript 97

120 Bedrijfsapplicaties Vertonen veel overeenkomsten: Persistente data Groot volume data Gelijktijdige toegang Ingewikkelde user interfaces Integratie met andere applicaties (conceptual dissonance) Bedrijfslogica 98

121 Voorbeelden van bedrijfsapplicaties B2C online retailer Heel veel gebruikers, schaalbaarheid Iedereen moet toegang hebben 99

122 Voorbeelden van bedrijfsapplicaties B2C online retailer Heel veel gebruikers, schaalbaarheid Iedereen moet toegang hebben Verwerken van lease overeenkomsten Ingewikkelde bedrijfslogica Geavanceerde presentatie gegevens Ingewikkelde afhandeling transacties (uren) 99

123 Voorbeelden van bedrijfsapplicaties B2C online retailer Heel veel gebruikers, schaalbaarheid Iedereen moet toegang hebben Verwerken van lease overeenkomsten Ingewikkelde bedrijfslogica Geavanceerde presentatie gegevens Ingewikkelde afhandeling transacties (uren) Expense tracking systeem voor een klein bedrijf 99

124 De drie hoofdlagen Het Layers architectuur patroon toegepast op bedrijfsapplicaties Presentation logic Interactie met gebruiker Command-line, rich client of web interface Domain logic Validatie van invoer en berekenen van resultaten Data source logic Communicatie met database en andere applicaties 100

125 Voorbeeld: Java EE multi-tier architectuur Client applicatie componenten Applets Servlets en JSP componenten Enterprise JavaBeans componenten Vier lagen op drie machines client tier + web tier = presentation layer business tier = domain logic + data source logic 101

126 Servlets and JSP Presentation logic in de Java EE architectuur: Servlets bevatten Java code om HTML te genereren vergelijkbaar met CGI scripts draaien allemaal op dezelfde JVM (geen opstart kosten) JSP pagina s mixen code (logica) met HTML (presentatie) lijkt op PHP Of applets/java applicaties voor een rich client 102

127 Enterprise JavaBeans Enterprise JavaBeans (EJB) zijn herbruikbare componenten Gedistribueerd: communicatie met RMI of CORBA Voor entiteiten (database objecten) en sessies (communicatie met clients) Transacties, beveiliging, persistentie, enzovoort door container 103

128 Java EE server en containers 104

129 Patterns of Enterprise Application Architecture Boek van Martin Fowler Beschrijft ongeveer 40 patronen Voorbeelden in Java en C# Voor een catalogus, zie: 105

130 Domain logic Waar komt de domeinlogica terecht? 1. Het Transaction Script patroon 2. Het Domain Model patroon 3. Het Table Module patroon Een korte beschrijving van deze patronen volgt

131 Transaction Script patroon (domain logic) Organizes business logic by procedures where each procedure handles a single request from the presentation Transactie heeft een welgedefinieerd eindpunt Afhandeling op een alles-of-niets basis Roept meestal de database direct aan Kan worden georganiseerd als een aparte klasse volgens het Command design pattern Evaluatie: simpel en makkelijk, maar risico van (code) duplicatie tussen transacties 107

132 Domain Model patroon (domain logic) An object model of the domain that incorporates both behavior and data Kan apart worden ontwikkeld en getest Verschillend van een database model Multi-valued attributen, inheritance, design patterns Synchronisatie met een database is lastig Risico: buitensporig grote domeinobjecten 108

133 Table Module patroon (domain logic) A single instance that handles the business logic for all rows in a database table or view Niet één object per order, maar een object om alle orders af te handelen Data en gedrag samengebracht (zoals in OO) Makkelijk te mappen naar een database Werkt bijzonder goed in combinatie met SQL Eén instantie voor een tabel: 109 Inheritance kan worden gebruikt Ondersteuning in Microsoft COM en.net (Record Set)

134 Web presentatie Web-browser-gebaseerde interfaces hebben vele voordelen: Geen client software hoeft te worden geïnstalleerd Overal toegankelijk Bekende benadering voor user interfaces Web server interpreteert de URL van een request en geeft de controle aan het geschikte programma Twee soorten: server-side scripts en server pages 110

135 Server-side scripts Scripts zijn programma s in algemene high-level programmeertalen Verkrijgen data door het ontleden van een HTTP request Voorbeeld: CGI scripts kan in verschillende talen worden geschreven Perl is populair vanwege zijn reguliere-expressie ontleder Voorbeeld: Java servlets automatisch ontleden http request Output door normale stream operaties Programmeervaardigheden nodig: minder geschikt voor grafische ontwerpers 111

136 Server pages Geeft een pagina terug in HTML Bevat fragmenten met code Voorbeelden: PHP, ASP, JSP Werkt het beste als de resultaten niet (of weinig) verwerkt hoeven te worden Nadeel: rommelige fragmenten, scoping lastig 112

137 Server pages 113 <body> <% Subjects s = new Subjects(); %> Click on any of these subjects: <% Iterator all = s.getall(); while (all.hasnext()) { String url = (String) all.next(); %> <p> <a href = "http://<%= url%>.jsp"> <%= url%> </a> </p> <%}%>

138 Model View Controller patroon (pres. logic) Splits user interface interaction into three distinct roles Hier toegepast op web presentaties Model: representeert informatie over het domein meestal binnen een domeinmodel View: toont het domein in een user interface een (gegenereerde) HTML pagina Controller: verwerkt invoer van de gebruiker, past het model aan Scripts voor het interpreteren van invoer, server pages voor het formatteren van het antwoord In stand-alone applicaties is er vaak geen onderscheid tussen view and controller 114

139 Transform View patroon (presentation logic) A view that processes domain data element by element and transforms it into HTML Een Template View is georganiseerd rond het soort uitvoer Een Transform View is georganiseerd rond de verschillende vertalingen van de elementen Meestal uitgeprogrammeerd in XSLT XSLT is een functionele taal voor het transformeren van XML (waaronder XHTML) 115

140 Transform View patroon (presentation logic) <album> <title>rubber Soul</title> <artist>the Beatles</artist> <tracks> <track> <title> Drive My Car </title> </track> <track> <title> Norwegian Wood </title> </track>... </tracks> </album> 116

141 Transform View patroon (presentation logic) <album> <title>rubber Soul</title> <artist>the Beatles</artist> <tracks> <track> <title> Drive My Car </title> </track> <track> <title> Norwegian Wood </title> </track>... </tracks> </album> <xsl:template match="album"> <html> <body bgcolor="white"> <xsl:apply-templates/> </body> <html> </xsl:template> <xsl:template match="album/title"> <h1> <xsl:apply-templates/> </h1> </xsl:template> <xsl:template match="artist"> <p> <b>artist: </b> <xsl:apply-templates/> </p> </xsl:template> 116

142 Concurrency Zeer lastig om te testen Moeilijk om erover te redeneren De meeste problemen met concurrency in bedrijfsapplicatie kunnen worden voorkomen door transacties te gebruiken Offline concurrency: interacties die niet door een database transactie kunnen worden afgehandeld 117

143 Locking strategieën Optimistic locking: alle gebruikers kunnen vrij bestanden lezen en aanpassen Concurrency control ontdekt conflicten wanneer veranderingen worden gecommit Werkt als conflicten relatief zeldzaam zijn (en niet te pijnlijk) Automatische merges zijn soms mogelijk Pessimistic locking: als een bestand door iemand bekeken wordt dan kan niemand anders het aanpassen 118 Voorkomt conflicten in plaats van deze op te lossen Belemmert vooruitgang

144 Locking strategieën Optimistic locking: alle gebruikers kunnen vrij bestanden lezen en aanpassen Concurrency control ontdekt conflicten wanneer veranderingen worden gecommit Werkt als conflicten relatief zeldzaam zijn (en niet te pijnlijk) Automatische Recent winnenmerges lock-free zijnstrategieën soms mogelijk aan populariteit, zoals het software transactional memory model Pessimistic locking: als een bestand door iemand bekeken wordt dan kan niemand anders het aanpassen Voorkomt conflicten in plaats van deze op te lossen Belemmert vooruitgang 118

145 Transactions A transaction is a bounded sequence of work with well-defined beginning and end points Software transacties moeten ACID zijn: Atomic Consistent Isolated Durable 119

146 Session state Veel client interacties zijn inherent stateful Voorbeeld: boodschappenmandje Stateful server is erg inefficiënt: de toestand van alle gebruikers sessies moet worden onthouden één object per gebruiker nodig Session state is verschillend van persistente data zoals opgeslagen in een database Bestaat tijdens een enkele transactie Hoeft niet consistent te zijn (bijvoorbeeld tijdens editten) 120

147 Client Session State patroon Stores session state on the client (rich-client applications) Drie standaard manieren met een HTML interface: URL parameters Alle links op een pagina krijgen de toestand als een parameter Nadeel: codering zichtbaar voor gebruiker Hidden fields <input type="hidden"> Cookies controversieel, kunnen uitgeschakeld worden 121

148 Distributie strategieën Afgeraden om een applicatie verdelen door verschillende componenten op verschillende nodes te plaatsen Remote procedure calls zijn vele malen langzamer 122

149 Remote Facade patroon Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network. De verfijnde objecten bevatten domeinlogica De remote facade vervangt de getters en setters van de individuele objecten door een samengestelde getter/setter 123

150 Describing and Evaluating Software Architectures 124

151 Architectuur voor samenwerking Bij het ontwerpen van de architectuur wordt voor het eerst de nadruk gelegd op de voorgestelde oplossing (in plaats van het probleemdomein): Legt de basis van het ontwerp Formuleert regels en principes waaraan het ontwerp moet voldoen 125

152 Architectuur voor samenwerking Bij het ontwerpen van de architectuur wordt voor het eerst de nadruk gelegd op de voorgestelde oplossing (in plaats van het probleemdomein): Legt de basis van het ontwerp Formuleert regels en principes waaraan het ontwerp moet voldoen Architectuur is een zorgvuldige opdeling van het geheel in onderdelen Met specifieke relaties tussen de onderdelen Zorgt dat onafhankelijke groepen effectief kunnen samenwerken Onderdelen kunnen onafhankelijk worden gebouwd, zodanig dat de delen uiteindelijk ook met succes als een geheel samenwerken 125

153 Architectuur voor samenwerking Bij het ontwerpen van de architectuur wordt voor het eerst de nadruk gelegd op de voorgestelde oplossing (in plaats van het probleemdomein): Legt de basis van het ontwerp Formuleert regels en principes waaraan het ontwerp moet voldoen Architectuur is een zorgvuldige opdeling van het geheel in onderdelen Het architectuur document Met specifieke relaties tussen de onderdelen vertelt ontwikkelaars hoe dit Zorgt dat onafhankelijke groepen effectief bereikt kunnen kan worden samenwerken Onderdelen kunnen onafhankelijk worden gebouwd, zodanig dat de delen uiteindelijk ook met succes als een geheel samenwerken 125

154 Architectuur voor kwaliteit Architectuur bevat het maken van engineering choices die de kwaliteitsattributen bepalen Individuele doelen kunnen worden bereikt met tactieken Het architectuur document legt de keuzes en doelen vast Een architectuurontwerp balanceert de belangen van vele verschillende stakeholders: Niet één beste oplossing: belangen zijn vaak tegenstrijdig Het architectuur document moet de verschillende belangen behandelen Om vroegtijdig oplossing te kunnen valideren (door klant) 126

155 Basiskwesties bij het beschrijven Schrijf het document vanuit de lezer: Een document wordt maar één keer geschreven, maar meerdere malen gelezen Wie is het bedoelde publiek? Wat moeten/willen ze weten? 127

156 Basiskwesties bij het beschrijven Schrijf het document vanuit de lezer: Een document wordt maar één keer geschreven, maar meerdere malen gelezen Wie is het bedoelde publiek? Wat moeten/willen ze weten? 127 Advies: voorkom (bijna) herhalingen ambiguïteiten notatie zonder uitleg chaotische organisatie ongedocumenteerde beslissingen documentatie die niet up-to-date is Waarom?

157 Software architectuur als een discipline Inspiratie van andere engineering domeinen (construction, electronics) Zijn industriestandaarden voor het opslaan en representeren van informatie mogelijk? 128 In de Italiaanse renaissance kostte het architecten 150 jaar voordat ze vanuit een 3-dimensionaal perspectief konden tekenen.

158 Belangen en views A view is a representation of a set of system elements and the relationships associated with them 129

159 Belangen en views A view is a representation of a set of system elements and the relationships associated with them 129

160 Belangen en views A view is a representation of a set of system elements and the relationships associated with them 129

161 129 Belangen en views Engine Type : TU5JP4 Engine capacity : 1578 Max. Power hp (rpm) : 110(5800) Max. Torque Nm (rpm) : 142(4000) A view is a representation Max. Speed (withof Manual a set gearbox) of : system 193 km/h elements and the relationships associated Max. Speed (with automatic them gearbox) : 189 km/h Compression ratio : 5/10 Fuel system : Injection Number of valves : 16 Number of cylinder : 4 cylinder in line Fuel tank capacity: 50 liters Fuel consumption (Manual gearbox) : 6.6/100(lit/km) Fuel consumption (automatic gearbox) : 7.3/100 (lit/km) Net weight (Manual gearbox) : 1069 kg Net weight (automatic gearbox) : 1099 kg Gross weight (loaded & full fuel tank, Manual gearbox) : 1567 kg Gross weight (loaded & full fuel tank, automatic gearbox) : 1597 kg Front suspension : Independent, Mac pherson, torsion spring Rear suspension : Beam, torsion bar & support bar Front shock absorber : Hydraulic+ gaseous Rear shock absorber : Hydraulic...

162 IEEE 1471 ANSI/IEEE Standaard : Recommended Practice for Architectural Description of Software-Intensive Systems Een model van architectuurbeschrijvingen in hun context Resultaat van consensus Toepasbaar op systemen waarin software een belangrijke rol speelt Richt zich alleen op de organisatie van een beschrijving, niet op het systeem zelf of de werkelijke modellen 130

163 IEEE 1471 ANSI/IEEE Standaard : Recommended Practice for Architectural Description of Software-Intensive Systems Een model van architectuurbeschrijvingen in hun context Resultaat van consensus Toepasbaar op systemen waarin software een belangrijke rol speelt Richt zich alleen op de organisatie van een beschrijving, niet op het systeem zelf of de werkelijke modellen Geen specifieke talen, viewpoints, viewtypes of modellen Geen formele criteria om consistentie te toetsen 130

164 Concepten van IEEE 1471 Stakeholder Concern View Viewpoint Model Rationale Library viewpoint Person or organization with an interest in the system Interest of stakeholder Part of an architecture description Definition of a view (contents, models to use, related to stakeholders and concerns) Piece of (structured) information in a particular representation/language Explanation/motivation for the architecture description (why?) Viewpoint that is to be used in different architecture descriptions 131

165 Concepten van IEEE

166 IEEE 1471 in de praktijk Metagegevens Datum, auteurs, change history, samenvatting, woordenlijst Stakeholders en hun belangen Stakeholders: gebruiker, klant, ontwikkelaar, onderhoudsteam (minimaal) Belangen: doel/missie, appropriateness, feasibility, risico s, maintainability, deployability, evolvability (minimaal) Consistentie Consistentie analyse tussen views, documenteren van bekende inconsistenties Rationale Motivering van de ontstane architectuur en zijn beschrijving Beschrijving van verworpen alternatieven en gemaakte keuzes (in verband brengen met requirements) 133

167 IEEE 1471 in de praktijk Selectie van viewpoints, gedefinieerd door: (*) is optioneel Naam van viewpoint Bedoeld voor welke stakeholders Omvat welke belangen Taal, modelleer techniek, analytische methodes (welke concepten herkennen de stakeholders?) Bij een library viewpoint, referentie naar de bron Toetsing op consistentie en compleetheid Evaluatie en analyse technieken Heuristieken, tips, etc. Rationale 134

168 Voorbeelden van viewpoints Maintenance viewpoint: Bedoeld voor onderhoud engineers Waar nieuwe functionaliteit toevoegen? Welke interfaces implementeren? Hoe een component te compileren (en te linken)? In welke vorm? 135

169 Voorbeelden van viewpoints Maintenance viewpoint: Bedoeld voor onderhoud engineers Waar nieuwe functionaliteit toevoegen? Welke interfaces implementeren? Hoe een component te compileren (en te linken)? In welke vorm? Operations viewpoint: Bedoeld voor operators Hoe het systeem installeren en configureren op echte computers? Hoe de executie monitoren? Hoe af te breken in geval van nood? In welke vorm? 135

170 Voorbeelden van viewpoints Maintenance viewpoint: Bedoeld voor onderhoud engineers Waar nieuwe functionaliteit toevoegen? Welke interfaces implementeren? Hoe een component te compileren (en te linken)? In welke vorm? Operations viewpoint: Bedoeld voor operators Hoe het systeem installeren en configureren op echte computers? Hoe de executie monitoren? Hoe af te breken in geval van nood? In welke vorm? Management viewpoint: Bedoeld voor decision makers Welke functionaliteit biedt het systeem? Wat zijn de kosten van introductie binnen de organisatie? Wat zijn de risico s? 135 In welke vorm?

171 Zachman Framework 136

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture Software architecture IM0203 TERUGKOPPELING PROEFTENTAMEN Vraag 1 Vraag 1a Veel van de in het werkboek besproken patterns kunnen ingezet worden voor het referentiesysteem. We lopen de patterns hier stuk

Nadere informatie

Zelftest Java EE Architectuur

Zelftest Java EE Architectuur Zelftest Java EE Architectuur Document: n1218test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA EE ARCHITECTUUR Nota:

Nadere informatie

Zelftest Java concepten

Zelftest Java concepten Zelftest Java concepten Document: n0838test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA CONCEPTEN Om de voorkennis nodig

Nadere informatie

Informatiearchitectuur

Informatiearchitectuur Informatiearchitectuur Onderwerpen Waarom is architectuur (nu) zo belangrijk? Wat is informatiearchitectuur? Ontwikkelingen in de tijd Structuur applicaties Applicatie-integratie Webservices Praktijkvoorbeeld

Nadere informatie

Cursus Software Architecture (T32311 en T32811)

Cursus Software Architecture (T32311 en T32811) Software Architecture, T 32311 en T32811 Cursus Software Architecture (T32311 en T32811) Dit tentamen bestaat uit 3 vragen, waarbij vraag 1 en vraag 3 elk uit 2 deelvragen bestaan. Voor dit tentamen kunt

Nadere informatie

Capita Selecta Design Patterns voor administratieve applicaties

Capita Selecta Design Patterns voor administratieve applicaties Capita Selecta voor administratieve applicaties Bij afstudeerproject: Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder 26 augustus 2006 Inhoud 26

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

Distributed Systems Architectures

Distributed Systems Architectures Distributed Systems Architectures Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 12 Slide 1 Topics covered Multiprocessor architectures Client-server architectures Distributed object architectures

Nadere informatie

Enterprisearchitectuur

Enterprisearchitectuur Les 2 Enterprisearchitectuur Enterprisearchitectuur ITarchitectuur Servicegeoriënteerde architectuur Conceptuele basis Organisatiebrede scope Gericht op strategie en communicatie Individuele systeemscope

Nadere informatie

SOA Security. en de rol van de auditor... ISACA Roundtable 2 juni 2008. Arthur Donkers, 1Secure BV arthur@1secure.nl

SOA Security. en de rol van de auditor... ISACA Roundtable 2 juni 2008. Arthur Donkers, 1Secure BV arthur@1secure.nl SOA Security en de rol van de auditor... ISACA Roundtable 2 juni 2008 Arthur Donkers, 1Secure BV arthur@1secure.nl 1 SOA Web 2.0, web services en service oriented architecture (SOA) is tegenwoordig de

Nadere informatie

The OSI Reference Model

The OSI Reference Model Telematica Applicatielaag Hoofdstuk 16, 17 Applicatielaag 4Bevat alle toepassingen die van het netwerk gebruik maken n E-mail n Elektronisch nieuws n WWW n EDI (Electronic Data Interchange) n Napster,

Nadere informatie

6-4-2015. Je kunt de presentaties downloaden op: www.gelsing.info. Docent: Marcel Gelsing. Les 1

6-4-2015. Je kunt de presentaties downloaden op: www.gelsing.info. Docent: Marcel Gelsing. Les 1 Les 1 Docent: Marcel Gelsing Je kunt de presentaties downloaden op: www.gelsing.info 1 Maak een (verbeter)voorstel voor Enterprise Architectuur, waarbij u zowel de mogelijkheden als de beperkingen van

Nadere informatie

Weblogic 10.3 vs IAS 10.1.3

Weblogic 10.3 vs IAS 10.1.3 Vision ~ Knowledge ~ Results Weblogic 10.3 vs IAS 10.1.3 OGh Fusion Middleware/ SOA Dag 19 Mei 2010, Het Oude Tolhuys Edwin Biemond email edwin.biemond@whitehorses.nl Web http://blogs.whitehorses.nl/,

Nadere informatie

Meer inzicht in een gelaagde architectuur

Meer inzicht in een gelaagde architectuur 22 Methodology Leo Pruijt is als hogeschooldocent verbonden aan het lectoraat Architectuur van Digitale Informatiesystemen aan de Hogeschool Utrecht. Lagenmodellen vormen een belangrijk onderdeel van de

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

Verantwoording van het Logica In Lagen referentiemodel

Verantwoording van het Logica In Lagen referentiemodel Verantwoording van het Logica In Lagen referentiemodel Bijlage bij Meer inzicht in gelaagde architectuur - Deel 1: Uitleg, terminologie en methoden [Pruijt10]. Leo Pruijt, Lectoraat Architectuur van Digitale

Nadere informatie

Base24 database suite

Base24 database suite Base24 database suite Introductie De Base24 database suite is een zeer geavanceerde database oplossing die ontworpen is voor de management, opslag, inzage en uitwisseling van medische informatie zoals

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

Portals & Open Source

Portals & Open Source Portals & Open Source OGh Jaarcongres 2003 Zeist, 7 october R.V.L.P. Schaaf Agenda Introductie Begrippenkader en standaards Open Source portals Onder de loep: Imbrium Praktijk case Open Source in uw organisatie?

Nadere informatie

Zelftest Informatica-terminologie

Zelftest Informatica-terminologie Zelftest Informatica-terminologie Document: n0947test.fm 01/07/2015 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is een zelf-test, waarmee u

Nadere informatie

Softwareproductkwaliteit

Softwareproductkwaliteit informatie / maand jaar softwarekwaliteit Overdruk Softwareproductkwaliteit Florijn & Greefhorst informatie 0101 1 Softwareproductkwaliteit Ervaringen en ontwikkelingen Met de groeiende interesse voor

Nadere informatie

Thinking of development

Thinking of development Thinking of development Databases Arjan Scherpenisse HKU / Miraclethings Agenda voor vandaag Opdracht tussenstand State diagram / Observer pattern Bret Victor Databases 2/42 Opdracht tussenstand Slides

Nadere informatie

Integratie in de praktijk

Integratie in de praktijk Integratie in de praktijk Werken als integratie consultant bij KLM Werken als integratie consultant bij KLM T. Lansbergen A. Kwekel Hogeschool Rotterdam 13/10/2015 Agenda Introductie - Organisatie Use

Nadere informatie

Applicatie-Architecturen

Applicatie-Architecturen Applicatie-Architecturen joost.vennekens@kuleuven.be http://www.cs.kuleuven.be/~joost/dn/ Onderwerp Programming in the large! ( programming in the small)! Bijvoorbeeld: KU Leuven Veel verschillende functionaliteit

Nadere informatie

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Extended ISO 9126: 2001 Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium Zelftest OOAD/UML Document: N0767Test.fm 30/08/2010 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is gebaseerd op de inhoud van onze cursus OO

Nadere informatie

Business Architectuur vanuit de Business

Business Architectuur vanuit de Business Business Architectuur vanuit de Business CGI GROUP INC. All rights reserved Jaap Schekkerman _experience the commitment TM Organization Facilities Processes Business & Informatie Architectuur, kun je vanuit

Nadere informatie

Software Mobiliteit. UAMS - 6 maart 2001. Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac.

Software Mobiliteit. UAMS - 6 maart 2001. Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac. Software Mobiliteit Theo D'Hondt Lab voor Pogrammeerkunde Vrije Universiteit Brussel http://prog.vub.ac.be/~tjdhondt p. 1 Overzicht Stelling Objecttechnologie Distributie Mobiliteit Evolutie Besluit p.

Nadere informatie

High Performance Computing

High Performance Computing High Performance Computing Kristian Rietveld (krietvel@liacs.nl, kamer 138) Groep Computer Systems - Embedded systems - Specifieke software mappen op specfieke hardware. - Hardware synthesis. - Real-time

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Technische Specificaties nieuwe Unix Applikaties

Technische Specificaties nieuwe Unix Applikaties Technische Specificaties nieuwe Unix Applikaties In 2010 werden 7 Unix servers geconsolideerd naar een nieuwe Unix omgeving, waar gebruik gemaakt wordt van srp s (vergelijkbaar met zone, of container).

Nadere informatie

Parasoft toepassingen

Parasoft toepassingen Testen op basis van OSB en Digikoppeling Voor de bestaande Overheid Service Bus en de nieuwe standaard Digikoppeling zijn verschillende test- omgevingen opgezet. Hiermee kan het asynchrone berichtenverkeer

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving

Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder Stand van zaken 17 Maart 2007 Inhoud Probleemgebied afstudeerproject Oplossingsgebied afstudeerproject

Nadere informatie

Trends en best-practices in (software) architectuur

Trends en best-practices in (software) architectuur Trends en best-practices in (software) architectuur Gert Florijn gflorijn@cibit.nl CIBIT Adviseurs Opleiders! Sinds 1988; multidisciplinair, onafhankelijk! CIBIT SERC ICT Adviseurs! ICT architectuur, software

Nadere informatie

Pijlers van Beheer. Bram van der Vos www.axisintoict.nl ict@axisinto.nl

Pijlers van Beheer. Bram van der Vos www.axisintoict.nl ict@axisinto.nl Welkom Pijlers van Beheer Bram van der Vos www.axisintoict.nl ict@axisinto.nl Waarom doe je Beheer Business perspectief Stabiliteit Security Enablen voor gebruikers Ondersteuning Technisch Perspectief

Nadere informatie

Tim Mallezie Architectuur van besturingssystemen: Vraag A2.

Tim Mallezie Architectuur van besturingssystemen: Vraag A2. Procesbeheer: kenmerken van moderne besturingssystemen. 1. Bespreek de (drie) meest typische kenmerken van moderne besturingssystemen. 2. In hoeverre beantwoorden UNIX, Linux en Windows NT hieraan? Geef

Nadere informatie

Technisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april 2009. Versie 2.1.0

Technisch ontwerp. Projectteam 6. Project Web Essentials 02 april 2009. Versie 2.1.0 Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie 2.1.0 Teamleden: Armin

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

Nadere informatie

Software-architectuur in vogelvlucht

Software-architectuur in vogelvlucht Software- is een relatief jonge discipline die bij veel bedrijven nog een duidelijke plaats moet krijgen. Een praktisch probleem is het gebrek aan een uniforme standaard voor de precieze invulling van

Nadere informatie

Webtesten onder schaarste

Webtesten onder schaarste Testnet najaarsevenement 2005 B e y o n d t h e o r d i n a r y Webtesten onder schaarste Vincent Staal ORDINA NV Ringwade 1 Postbus 7101 3430 JC Nieuwegein Tel: 030 6637000 Fax: 030 6637099 www.ordina.nl

Nadere informatie

Model driven Application Delivery

Model driven Application Delivery Model driven Application Delivery Fast. Flexible. Future-proof. How Agis streamlines health procurement using Mendix Model driven Application Platform Mendix in a nutshell Mendix delivers the tools and

Nadere informatie

Business Rules: het scheiden van kennis en processen 17 september 2014

Business Rules: het scheiden van kennis en processen 17 september 2014 Business Rules: het scheiden van kennis en processen 17 september 2014 Business rules scheiden kennis van processen 1 Agenda 18:30-18:40 Opening 18:40-19:15 Het scheiden van kennis en processen Peter Nobels,

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

Workflows voor SharePoint met forms en data K2 VOOR SHAREPOINT

Workflows voor SharePoint met forms en data K2 VOOR SHAREPOINT Slimmer samenwerken met SharePoint Workflows voor SharePoint met forms en data K2 VOOR SHAREPOINT Workflows, forms, reports en data WAAROM KIEZEN VOOR K2? Of u nu workflows moet maken voor items in SharePoint

Nadere informatie

Application interface. service. Application function / interaction

Application interface. service. Application function / interaction Les 5 Het belangrijkste structurele concept in de applicatielaag is de applicatiecomponent. Dit concept wordt gebruikt om elke structurele entiteit in de applicatielaag te modelleren: softwarecomponenten

Nadere informatie

ONTWERP VAN GEDISTRIBUEERDE SOFTWARE ACADEMIEJAAR 2009-2010 1 STE EXAMENPERIODE, 15 JANUARI 2010, 14U 17U30 VRAAG 1: INLEIDENDE BEGRIPPEN[20 MIN]

ONTWERP VAN GEDISTRIBUEERDE SOFTWARE ACADEMIEJAAR 2009-2010 1 STE EXAMENPERIODE, 15 JANUARI 2010, 14U 17U30 VRAAG 1: INLEIDENDE BEGRIPPEN[20 MIN] ONTWERP VAN GEDISTRIBUEERDE SOFTWARE ACADEMIEJAAR 2009-2010 1 STE EXAMENPERIODE, 15 JANUARI 2010, 14U 17U30 Naam :.. Richting :.. Opmerkingen vooraf : - werk verzorgd en duidelijk, zodat er geen dubbelzinnigheden

Nadere informatie

Continuous Delivery. Sander Aernouts

Continuous Delivery. Sander Aernouts Continuous Delivery Sander Aernouts Info Support in een notendop Maatwerk softwareontwikkeling van bedrijfskritische kantoorapplicaties Business Intelligence oplossingen Managed IT Services Eigen Kenniscentrum

Nadere informatie

Nederlandse samenvatting (Dutch summary)

Nederlandse samenvatting (Dutch summary) Nederlandse samenvatting (Dutch summary) Ditproefschriftpresenteerteen raamwerk voorhetontwikkelenvanparallellestreaming applicaties voor heterogene architecturen met meerdere rekeneenheden op een chip.

Nadere informatie

Enterprise Portfolio Management

Enterprise Portfolio Management Enterprise Portfolio Management Strategische besluitvorming vanuit integraal overzicht op alle portfolio s 22 Mei 2014 Jan-Willem Boere Vind goud in uw organisatie met Enterprise Portfolio Management 2

Nadere informatie

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag.

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Voorbeeldproject Een Haagse SOA Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Aanleiding Vanuit de visie

Nadere informatie

Vergelijking Sun certificering voor Enterprise architect voor J2EE en het CPP Gecertificeerd softwarearchitect van de Open Universiteit Nederland

Vergelijking Sun certificering voor Enterprise architect voor J2EE en het CPP Gecertificeerd softwarearchitect van de Open Universiteit Nederland Vergelijking Sun certificering voor Enterprise architect voor J2EE en het CPP Gecertificeerd softwarearchitect van de Open Universiteit Nederland Inleiding Het Certified Professional Program Gecertificeerd

Nadere informatie

Waarom Cloud? Waarom nu? Marc Gruben April 2015

Waarom Cloud? Waarom nu? Marc Gruben April 2015 Waarom Cloud? Waarom nu? Marc Gruben April 2015 Waarom Daarom Cloud? Cloud! Waarom Daarom nu? nu! Marc Gruben April 2015 Wie ben ik? Informatie analist Project/development manager Developer/architect Wie

Nadere informatie

Belangrijkste ideeën/concepten uit OS, incl. proces

Belangrijkste ideeën/concepten uit OS, incl. proces Operating System Overview (Hfst 2) Wat is een OS? Wat was een OS? Evolutie van OS. OS als virtuele machine OS als beheerder van hulpbronnen (resources) Belangrijkste ideeën/concepten uit OS, incl. proces

Nadere informatie

SuperOffice Systeemvereisten

SuperOffice Systeemvereisten Minimale systeemvereisten voor SuperOffice CRM De minimale systeemvereisten voor SuperOffice CRM zijn tevens afhankelijk van het besturingssysteem en de services/applicaties die op het systeem actief zijn.

Nadere informatie

Wat is Interaction Design?

Wat is Interaction Design? Wat is Interaction Design? Wat is interaction design? Designing interactive products to support the way people communicate and interact in their everyday and working lives. Preece, Sharp and Rogers (2015)

Nadere informatie

Functionele beschrijving: scannen naar Exact Globe.

Functionele beschrijving: scannen naar Exact Globe. Functionele beschrijving: scannen naar Exact Globe. Algemeen Met de KYOCERA scannen naar Exact Globe beschikt u over een efficiënte oplossing om uw documenten te scannen naar Exact Globe. Met deze oplossing

Nadere informatie

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman Requirements Traceability Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman 22 Mei 2008 Werkgroep Traceability Doel van de werkgroep: Aanbieden van hulpmiddelen

Nadere informatie

Gebruik van cryptografie voor veilige jquery/rest webapplicaties. Frans van Buul Inter Access

Gebruik van cryptografie voor veilige jquery/rest webapplicaties. Frans van Buul Inter Access Gebruik van cryptografie voor veilige jquery/rest webapplicaties Frans van Buul Inter Access 1 Frans van Buul frans.van.buul@interaccess.nl 2 De Uitdaging Rijke en veilige webapplicaties Een onveilig en

Nadere informatie

High Availability & Disaster Recovery

High Availability & Disaster Recovery Disaster Recovery Problematiek en denkpistes voor oplossingen Cevi Usernamiddag 8 december 2009 9 december 2009 Cevi bedrijfspresentatie High Availability & Disaster Recovery Een theoretische benadering

Nadere informatie

Praktijkcasus Identity management. Bert Dondertman 14 september 2010

Praktijkcasus Identity management. Bert Dondertman 14 september 2010 Praktijkcasus Identity management Bert Dondertman 14 september 2010 Agenda Praktijkcasus: Waarom? Hoe? Score op de diverse dimensies OGh IAM presentatie juli 2010 2 Waarom? Centraal klantportaal waar mogelijkheden

Nadere informatie

Variability in Multi-tenant SaaS Applications:

Variability in Multi-tenant SaaS Applications: Variability in Multi-tenant SaaS Applications: Gastcollege voor het vak Product Software Jaap Kabbedijk, MSc. Universiteit Utrecht, Nederland 1 Wat gaan we behandelen? Introductie Uitleg ontwikkeling SaaS

Nadere informatie

Functionele beschrijving: scannen naar UNIT4 DocumentManager

Functionele beschrijving: scannen naar UNIT4 DocumentManager Functionele beschrijving: scannen naar UNIT4 DocumentManager Algemeen Met de KYOCERA Scannen naar UNIT4 DocumentManager beschikt u over een efficiënte oplossing om uw documenten te scannen naar UNIT4 DocumentManager

Nadere informatie

Product Quality Management, onze toekomst René Tuinhout

Product Quality Management, onze toekomst René Tuinhout Product Quality Management, onze toekomst René Tuinhout Agenda No. 2 1 Tijdsindeling Binnen TestNet is gesproken over Product Kwaliteit (in 2011 en tijdens de Summerschool 2012). Een TestNet-werkgroep

Nadere informatie

Clean code improves test quality

Clean code improves test quality Clean code improves test quality Michel Kroon, Senior Consultant, SIG TestNet Voorjaarsevenement 30 juni 2008 Arent Janszoon Ernststraat 595-H NL-1082 LD Amsterdam info@sig.nl www.sig.nl De Software Improvement

Nadere informatie

Teststrategie met behulp van heuristieken

Teststrategie met behulp van heuristieken Workshop TestNet Teststrategie met behulp van heuristieken www.improveqs.nl (info@improveqs.nl) Versie 2.0 1 Acknowledgements Met dank aan: Ruud Cox voor de vele discussies over dit onderwerp Fiona Charles

Nadere informatie

Workflow Management MIS 3TI 2010-2011

Workflow Management MIS 3TI 2010-2011 Workflow Management MIS 3TI 2010-2011 Een scenario CREATE ORDER PRE-PROCESSINGORDER PROCESSING PRODUCTION SHIPPING Work Collection of tasks that have to be executed sequentially or in parallel, by at least

Nadere informatie

ECTS fiche. Module info. Evaluatie. Gespreide evaluatie OPLEIDING. Handelswetenschappen en bedrijfskunde HBO Informatica

ECTS fiche. Module info. Evaluatie. Gespreide evaluatie OPLEIDING. Handelswetenschappen en bedrijfskunde HBO Informatica ECTS fiche Module info OPLEIDING STUDIEGEBIED AFDELING MODULE MODULENAAM Programmeren 5 MODULECODE B STUDIEPUNTEN 10 VRIJSTELLING MOGELIJK ja Handelswetenschappen en bedrijfskunde HBO Informatica Evaluatie

Nadere informatie

Software Engineering (I00094) College 2: Requirements-engineering. Marko van Eekelen marko@cs.ru.nl kamer HG02.074

Software Engineering (I00094) College 2: Requirements-engineering. Marko van Eekelen marko@cs.ru.nl kamer HG02.074 Software Engineering (I00094) College 2: Requirements-engineering Marko van Eekelen marko@cs.ru.nl kamer HG02.074 1 Inhoud 1. 6 feb: Het systeemontwikkelproces 2. 13 feb: Requirements-analyse 3. 6 mar:

Nadere informatie

Product marketing met

Product marketing met Product marketing met Michiel Klaren, Natasja Paulssen 2007-11-22 Complexiteit van de Content Management Chain Hoe het was (2002) Meer dan 9,000 uitwisselingen nodig voor verzamelen content van catalogus

Nadere informatie

High Performance Computing

High Performance Computing High Performance Computing Kristian Rietveld (krietvel@liacs.nl, kamer 138) Groep Computer Systems High-Performance Computing Optimizing compilers (generieke codes, maar ook specifieke rekenkernels). Parallel

Nadere informatie

ArchiMate voor kennismodellen van NORA en haar dochters. Marc Lankhorst 16 oktober 2013

ArchiMate voor kennismodellen van NORA en haar dochters. Marc Lankhorst 16 oktober 2013 ArchiMate voor kennismodellen van NORA en haar dochters Marc Lankhorst 16 oktober 2013 Agenda 13:00 introductie ArchiMate-status en -ontwikkelingen en NORA-kennismodel 14:00 parallelle workshops rond de

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

De architect: in spagaat tussen mensen en technische details. Illustratie met een simpel voorbeeld

De architect: in spagaat tussen mensen en technische details. Illustratie met een simpel voorbeeld De architect: in spagaat tussen mensen en technische details Illustratie met een simpel voorbeeld Illustratie van stap voor stap naar een architectuur aan de hand van een voorbeeld Overview Exercise Assistant:

Nadere informatie

Systeem modellen. Topics covered

Systeem modellen. Topics covered Systeem modellen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 1 Topics covered Context models Behavioural models Data models Object models CASE workbenches Ian Sommerville 2004

Nadere informatie

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk.

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk. Planningsfase 1. Afspraken maken over doelstelling en randvoorwaarden De doelstelling van het project: De doelstelling van het project: het maken van het gewenste product. De doelstelling van de student:

Nadere informatie

Gimme Five! Op weg naar TYPO3 5.0 'Phoenix'

Gimme Five! Op weg naar TYPO3 5.0 'Phoenix' Gimme Five! Op weg naar TYPO3 5.0 'Phoenix' Waarom TYPO3 5.0? Waarom TYPO3 5.0? Enkele redenen: Waarom TYPO3 5.0? Enkele redenen: Complexiteit De TYPO3 Core architectuur heeft zijn limiet bereikt en is

Nadere informatie

Congres Architectuur in de Zorg

Congres Architectuur in de Zorg Congres Architectuur in de Zorg De architect, coach voor een goed zorgsysteem De rol van methoden en modellen in Zorg Informatie Architectuur Nieuwegein, 21 juni 2012 21-06-12 De architect, coach voor

Nadere informatie

Stephanie van Dijck De integrale aanpak maakt complexiteit hanteerbaar

Stephanie van Dijck De integrale aanpak maakt complexiteit hanteerbaar Titel, samenvatting en biografie Stephanie van Dijck De integrale aanpak maakt complexiteit hanteerbaar Samenvatting: Nieuwe projecten nemen toe in complexiteit: afhankelijkheden tussen software componenten,

Nadere informatie

INFITT01 - Internettechnologie WEEK 8

INFITT01 - Internettechnologie WEEK 8 INFITT01 - Internettechnologie WEEK 8 Programma Databases (JDBC, JNDI, ORM, JPA) MVC & Spring/Struts EJB Databases Veel web applicaties moeten informatie over langere tijd op kunnen slaan. Een voor de

Nadere informatie

Single sign on kan dé oplossing zijn

Single sign on kan dé oplossing zijn Whitepaper Single sign on kan dé oplossing zijn door Martijn Bellaard Martijn Bellaard is lead architect bij TriOpSys en expert op het gebied van security. De doorsnee ICT-omgeving is langzaam gegroeid

Nadere informatie

Cerussa FIN Pre-requirements

Cerussa FIN Pre-requirements Pre-requirements Inhoudstafel A. Algemeen... 3 B. Type installaties... 3 C. Hardware en software vereisten... 4 1. PC Clients... 4 2. Terminal Server Clients (Thin Clients)... 4 3. Server... 4 D. Operating

Nadere informatie

Interactief, real time security management

Interactief, real time security management P2000 en P2000LE SECURITY MANAGEMENT SYSTEEM Interactief, real time security management P2000 Security Management Systeem Schaalbaar, intuïtief en eenvoudig in gebruik Het Johnson Controls P2000 security

Nadere informatie

Configureren van een VPN L2TP/IPSEC verbinding. In combinatie met:

Configureren van een VPN L2TP/IPSEC verbinding. In combinatie met: Configureren van een VPN L2TP/IPSEC verbinding In combinatie met: Inhoudsopgave 1. Voorbereiding.... 3 2. Domaincontroller installeren en configuren.... 4 3. VPN Server Installeren en Configureren... 7

Nadere informatie

The Power of N. Novell File Management Products. Dupaco Cafe. Anthony Priestman Sr. Solution Architect Novell Inc.

The Power of N. Novell File Management Products. Dupaco Cafe. Anthony Priestman Sr. Solution Architect Novell Inc. The Power of N Novell File Management Products Dupaco Cafe Anthony Priestman Sr. Solution Architect Novell Inc. Twentieth Century Fox Data Governance Beheren en monitoren van toegang File Management Zoek

Nadere informatie

Webapplicatie-generatie NIOC 2013

Webapplicatie-generatie NIOC 2013 Webapplicatie-generatie NIOC 2013 Eddy Luursema, Misja Nabben, Arnoud van Bers Research Group Model Based Information Systems Presentation Introduction M-BIS Data intensive systems Requirements Generation

Nadere informatie

It s CMMI Jim, but not as we know it! CMMI toegepast op een Compliance organisatie Door Jasper Doornbos Improvement Focus

It s CMMI Jim, but not as we know it! CMMI toegepast op een Compliance organisatie Door Jasper Doornbos Improvement Focus It s CMMI Jim, but not as we know it! CMMI toegepast op een Compliance organisatie Door Jasper Doornbos Improvement Focus Inhoud Compliance vakgebied en organisatie CMMI software en systems engineering

Nadere informatie

The End of an Architectural Era

The End of an Architectural Era The End of an Architectural Era M. Stonebraker, S. Madden, D. J. Abadi, S. Harizopoulos, N. Hachem, P. Helland Jorn Van Loock Inleiding Oorsprong relationele DBMS IBM System R (1974) DB2 Sybase SQL Server

Nadere informatie

Configureren van een VPN L2TP/IPSEC verbinding

Configureren van een VPN L2TP/IPSEC verbinding Configureren van een VPN L2TP/IPSEC verbinding Inhoudsopgave 1. Voorbereiding.... 3 2. Domain Controller Installeren... 4 3. VPN Configuren... 7 4. Port forwarding.... 10 5. Externe Clients verbinding

Nadere informatie

Windows Server 2003 EoS. GGZ Nederland

Windows Server 2003 EoS. GGZ Nederland Windows Server 2003 EoS GGZ Nederland Inleiding Inleiding Op 14 juli 2015 gaat Windows Server 2003 uit Extended Support. Dat betekent dat er geen nieuwe updates, patches of security releases worden uitgebracht.

Nadere informatie

Automatisch Testen. Customer Business Lunch. 6 november 2014. Netherlands Germany Switzerland Serbia

Automatisch Testen. Customer Business Lunch. 6 november 2014. Netherlands Germany Switzerland Serbia Automatisch Testen Netherlands Germany Switzerland Serbia Customer Business Lunch 6 november 2014 3 Vraag? Doen wij al aan automatisch testen? 4 Agenda Automatisch testen Waarom? Mogelijkheden Demo Conclusie

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

Invantive Producer. Als integriteit en compliance noodzakelijk is. Maar niks extra mag kosten.

Invantive Producer. Als integriteit en compliance noodzakelijk is. Maar niks extra mag kosten. Invantive Producer Als integriteit en compliance noodzakelijk is. Maar niks extra mag kosten. Agenda Invantive Visie De Invantive Benadering Het Invantive Resultaat Invantive Producer Praktijkvoorbeelden

Nadere informatie

Kikkers en Heilige Koeien UvAConext & standaarden voor het primaire onderwijs en onderzoek proces

Kikkers en Heilige Koeien UvAConext & standaarden voor het primaire onderwijs en onderzoek proces Kikkers en Heilige Koeien UvAConext & standaarden voor het primaire onderwijs en onderzoek proces SURF Seminar September 2015 Frank Benneker, ICTS Universiteit van Amsterdam Perspectief ICTS & OO dienstverlening

Nadere informatie

Dell SonicWALL product guide

Dell SonicWALL product guide Dell SonicWALL product guide TZ Series Dell SonicWALL SMB solutions: TZ Series at-a-glance De Dell SonicWALL TZ Serie bevat de instapmodellen van de Dell SonicWALL fi rewalls. De serie bestaat uit drie

Nadere informatie

Software Design Document

Software Design Document Software Design Document Mathieu Reymond, Arno Moonens December 2014 Inhoudsopgave 1 Versiegeschiedenis 2 2 Definities 3 3 Introductie 4 3.1 Doel en Scope............................. 4 4 Logica 5 4.1

Nadere informatie

Object Oriented Programming

Object Oriented Programming Object Oriented Programming voor webapplicaties Door Edwin Vlieg Waarom OOP? Basis uitleg over OOP Design Patterns ActiveRecord Model View Controller Extra informatie Vragen OOP Object Oriented Programming

Nadere informatie