Software Architecture and Requirements Engineering

[Faculty of Science Information and Computing Sciences]

Software Architecture and Requirements Engineering Wouter Swierstra Software Project en Game Project

September 18, 2014

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.

[Faculty of Science Information and Computing Sciences] 2

Wat is Software Architectuur?

Wat denken jullie?


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


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) I

De architectuur bepaalt de interactie van componenten, maar niet de implementatie

I

Ieder systeem heeft een architectuur, maar de beschrijving is misschien niet beschikbaar

I

De beschrijving van de architectuur van een systeem is op een hoger niveau dan een beschrijving in termen van klassen en methoden


Waarom praten we over software architectuur?

I

Bij MSO leer je je eigen software te onwerpen.

I

Maar bij een ‘echt’ project gebruik je ook heel veel software dat je niet zelf hebt geschreven.

I

Bij voorbeeld een webshop gebruikt haalt de prijs catalogus uit een bestaande database, moet klant gegevens bijhouden in de bestaande CRM software, enz.

I

Voordat je zelf aan de slag gaat, moet je dus de context van jullie stukje software bedenken.


Een voorbeeld architectuur


Waarom Software Architectuur?

I

Voor je kan beginnen te bouwen, moet je bedenken wat je moet maken (requirements).

I

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.

I

Zo’n architectuur kun je vervolgens vertalen naar een ontwerp en uiteindelijke implementatie.


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


Waarom is Software Architectuur nodig? I

Softwareapplicaties • worden steeds groter • moeten geïntegreerd worden met bestaande omgeving • gebruiken vele (nieuwe) technologieën

I

Het laten samenwerken van verschillende technologieën en disciplines wordt ook wel orkestratie genoemd.

I

Sommige kwaliteitsattributen kunnen niet op het code-niveau gerealiseerd worden


Waarom is Software Architectuur nodig? I

Softwareapplicaties • worden steeds groter • moeten geïntegreerd worden met bestaande omgeving • gebruiken vele (nieuwe) technologieën

I

Het laten samenwerken van verschillende technologieën en disciplines wordt ook wel orkestratie genoemd.

I

Sommige kwaliteitsattributen kunnen niet op het code-niveau gerealiseerd worden


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


Scope en focus: twee dimensies Stel eerst de scope en de focus van een architectuur vast Scope: welke applicaties behoren tot de architectuur? Voorbeelden: I

Enkel systeem of product

I

Systeem familie (Philips Medical Systems)

I

Business unit? Of de hele organisatie?

I

...

Wat is de context waarin je werkt? [Faculty of Science Information and Computing Sciences] 12

Scope en focus: twee dimensies

Wat is de focus van de architectuur? I

Business architectuur business strategy, governance, organisatie, key business processes Business Process Reengineering (BPR): analyse en ontwerp van processen

I

Information technology (IT) architectuur Hardware en software infrastructuur (inclusief databases en middleware)

I

Information architectuur data opslag en data management (steeds belangrijker onderdeel)

I

Application (software) architectuur Gedetailleerde omschrijving afzonderlijke applicaties, interactie, relatie tot bedrijfsprocessen


Scope en focus: twee dimensies

Wat is de focus van de architectuur? I

Business architectuur business strategy, governance, organisatie, key business processes Business Process Reengineering (BPR): analyse en ontwerp van processen

I

Information technology (IT) architectuur Hardware en software infrastructuur (inclusief databases en middleware) I Geen duidelijke grenzen

I

I

Information architectuur I Tezamen vormen deze architecturen de data opslag en data management (steeds belangrijker onderdeel) enterprise architectuur Application (software) architectuur

Gedetailleerde omschrijving afzonderlijke applicaties, interactie, relatie tot bedrijfsprocessen


Software Architectuur als een wetenschap

Mary Shaw’s artikel in 1989: “Larger scale systems require higher level abstractions” Vergelijkbaar met andere engineering disciplines?



Mary Shaw’s artikel in 1989: “Larger scale systems require higher level abstractions” Vergelijkbaar met andere engineering disciplines? I

stakeholders en belangen

I

analyse en validatie

I

verschillende gezichtspunten

I

standaardisatie en hergebruik

I

best practices en certificering

Maar:



Mary Shaw’s artikel in 1989: “Larger scale systems require higher level abstractions” Vergelijkbaar met andere engineering disciplines? I

stakeholders en belangen

I

analyse en validatie

I

reproductie is makkelijk

I

verschillende gezichtspunten

I

I

standaardisatie en hergebruik

parametrisatie en instantiatie

I

best practices en certificering

I

complexiteit is relatief onzichtbaar

Maar:


De architect en de engineer De architect: I

creëert een visie

I

neemt beslissingen

I

behartigt de belangen van de stakeholders

I

beheert de visie

De engineer: I

analyseert precieze en gedetailleerde requirements

I

levert gedetailleerde oplossingen

I

zorgt dat het naar behoren werkt [Faculty of Science Information and Computing Sciences]

15

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.



Minstens vier partijen (IEEE 1471): I

Eindgebruikers

I

Aanschaffende partij (klant)

I

Ontwikkelaars

I

Onderhoudsteam

Welke nog meer?

Waar liggen de belangen van deze partijen? Hoe zit dat voor jullie project?



I

Stakeholders: • Vertegenwoordigers uit alle fasen van het project (ontwikkeling, gebruik en ondersteuning)

I

Belangen: • gerelateerd aan ontwikkeling, uitvoering, gebruik of evolutie van een systeem • functionaliteit, kwaliteitsgebieden, ontwikkelingsproces, kosten, technologie

I

Kostbaar om later kwaliteitsattributen toe te voegen

I

Belangen vaak tegenstrijdig (Twitter: schaalbaarheid ten opzichte van betrouwbaarheid)

I

Prioriteiten aanbrengen! [Faculty of Science Information and Computing Sciences]

18


I

Stakeholders: • Vertegenwoordigers uit alle fasen van het project (ontwikkeling, gebruik en ondersteuning)

I

Belangen: • gerelateerd aan ontwikkeling, uitvoering, gebruik of evolutie van een systeem In een architectuur moet deontwikkelingsproces, juiste balans • functionaliteit, kwaliteitsgebieden, worden in de belangen van de kosten,gevonden technologie

I

stakeholders: Kostbaar om later kwaliteitsattributen toe te voegen

I

Belangen vaak tegenstrijdig (Twitter: schaalbaarheid ten opzichte van betrouwbaarheid)

I

Prioriteiten aanbrengen! [Faculty of Science Information and Computing Sciences]

18

Een voorbeeld Welke stakeholders zouden deze belangen kunnen hebben? Oplevering: 1 januari 2015

Architect

Gebruik bestaande Oracle server


Een voorbeeld

Oplevering: 1 januari 2015

Klaar voor de toekomst

Architect Budget: 100,000 euro



Een voorbeeld Uptime: five nines Beschikbaarheid: 24/7 Oplevering: 1 januari 2015

Gebruik huidig ontwikkelteam





Een voorbeeld

Beschikbaarheid: 24/7 Oplevering: 1 januari 2015

Gebruik huidig ontwikkelteam



Max. responstijd: 0.5 seconde

Schaalbaarheid: tot 100,000 gebruikers Gebruik bestaande Oracle server


Kwaliteitsmodel

Extended ISO Model Reliability maturity fault tolerance recoverability availability degradability

Efficiency time behaviour resource behaviour

Portability adaptability installability conformance replaceability

Functionality suitability accuracy interoperability compliance security traceability

Usability understandability learnability explicitness customisability attractivity clarity helpfulness user-friendliness

Maintainability analysability changeability stability testability manageability reusability


De Sinterklaas valkuil

I I

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)? • ...

I

Maak duidelijk waar je prioriteiten liggen.


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: I I I I I

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 [Faculty of Science Information and Computing Sciences] 22

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: I I I I I

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 [Faculty of Science Information and Computing Sciences] 22

Beschrijven van architecturen

Er is meestal niet sprake van één architectuur. Verschillende stakeholders willen verschillende informatie: I

Hoe moet ik het bouwen?

I

Hoe veel gaat het kosten?

I

Waar wordt het gedeployed?


Beschrijven van architecturen Definitie: A viewpoint addresses one or more concerns of a stakeholder I

Viewpoints • ontwikkelaars, maintainers, eindgebruikers, project managers, service engineers, auditors, andere architecten

I

Reference models • Zachman, Kruchten’s 4+1 model

I

Talen om architecturen te beschrijven: • • • •

plaatjes natuurlijke taal formele talen (MIL, ADL) UML [Faculty of Science Information and Computing Sciences]

24

Modellen

I I

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

I

Elk model kan op verschillende niveaus worden uitgedrukt (algemeen versus gedetailleerd)

I

Een view is een projectie van een model waarbij irrelevante entiteiten zijn weggelaten (vanuit een bepaald perspectief gezien)


Modellen

I I

Een model is een versimpeling van de werkelijkheid Functies van een model: • visualiseren van het systeem • van het systeem beschrijf een systeem Eén specificeren model is nooit voldoende: • templates bouwen (generatie) aan de hand van meerdere (onafhankelijke) modellen documenteren beslissingen en•met meerdere views

I

Elk model kan op verschillende niveaus worden uitgedrukt (algemeen versus gedetailleerd)

I

Een view is een projectie van een model waarbij irrelevante entiteiten zijn weggelaten (vanuit een bepaald perspectief gezien)


Vijf views (Kruchten) I

Use case view voor eindgebruikers en testers, use case/activiteit diagrammen

I

Design view voor eindgebruikers, functionele requirements, class/object/component diagrammen

I

Interaction view control-flow (concurrency/synchronization, performance, schaalbaarheid, throughput, interactie/state diagrammen

I

Implementation view bouwen en releasen van fysieke systeem, configuratie management, artifact diagrammen

I

Deployment view hardware topologie, distributie, installatie, deployment diagrammen [Faculty of Science Information and Computing Sciences]

26

Welke view is voor mij belangrijk?

Dat hangt af van het soort systeem: I

hard real-time systemen ⇒ dynamische processen zijn belangrijk

I

data-intensieve systemen ⇒ views m.b.t. statisch ontwerp

I

... De keuze van modellen bepalen ook het wereldbeeld!


Architecturen en hergebruik Een architectuur kan worden hergebruikt: I

Architectural styles en architectural patterns

I

(Commerciële) frameworks Bijvoorbeeld Struts framework voor web-applicaties met MVC pattern

I

Platformen voor infrastructurele ondersteuning Bijvoorbeeld J2EE


Architecturen en hergebruik Een architectuur kan worden hergebruikt: I

Architectural styles en architectural patterns

I

(Commerciële) frameworks Bijvoorbeeld Struts framework voor web-applicaties met MVC pattern

I

Platformen voor infrastructurele ondersteuning Bijvoorbeeld J2EE

Wat is nodig voor hergebruik? I

Architectuur standaarden met duidelijke component-rollen

I

Standaarden voor een specifiek domein of een specifieke technologie [Faculty of Science Information and Computing Sciences]

28

Hergebruik: een voorbeeld

Familie van soortgelijke systemen I Commonality versus variability I Feature model: requirements voor

producten in een product line I Common components or framework

(voor commonality) I Application-specific extensions

(voor variability) I Domain engineering versus application

engineering


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. I

Bij het ontwikkelen zijn vaak legacy systemen betrokken

I

Reverse engineering: achterliggende structuur onderzoeken

I

Re-engineering: software aanpassen Issues:

I

• Is er documentatie (en is deze up-to-date)? • Is het architectuur model te achterhalen? • (Betrouwbare) transformaties, refactorings [Faculty of Science Information and Computing Sciences] 30

Uitdagingen

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


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


Herhaling van een aantal concepten

I

Een stakeholder is een ieder met een belang in de totstandkoming van een software systeem • Klant, eindgebruiker, ontwikkelaars, onderhoudsteam, enz.

I

Een belang is een interesse in de ontwikkeling, het uitvoeren of de evolutie van een systeem • functionaliteit, kwaliteitsgebieden, ontwikkelproces, kosten, technologie, etc.

I

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 [Faculty of Science Information and Computing Sciences]

32

Balanceren van belangen

I

I

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

I

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


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?


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) [Faculty of Science Information and Computing Sciences] 35

Elicitatie

I

Begrijpen probleem begint bij begrijpen domein

I

Domein is impliciet (in hoofden gebruikers): maak het expliciet Veel complicaties:

I

• • • • • • • •

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)


Natuurlijke taal is gevaarlijk

I

“Alle gebruikers hebben hetzelfde controle-veld”

I

Hebben ze allemaal dezelfde waarde in dat veld?

I

Hebben waarden voor iedereen dezelfde vorm?

I

Of is er een enkel veld voor alle gebruikers samen?


Soorten requirements

Er zijn drie soorten requirements te onderscheiden: I

Functionele: wat moet het systeem doen?

I

Niet-functionele: met welke kwaliteitseisen moet een systeem functioneren?

I

Constraints: binnen welke grenzen moet het systeem gerealiseerd worden?

Soms wordt er onderscheid gemaakt tussen technical constraints en business constraints [Faculty of Science Information and Computing Sciences] 38

Requirements achterhalen

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


Technieken

I

Ondervragen:

I

Task analysis –

I

Scenario-gebaseerde analyse:

I

Ethnography:

I

Formulieren en document analyse

I

Bestaand systeem bestuderen

I

Prototyping

I

Domeinanalyse

I

Eigen inzicht volgen

I

Crowdsourcing

interview, brainstorm sessies, questionnaire deeltaken onderscheiden hardop denken, use case analysis

actief observeren


Welke techniek moet je kiezen?

I

Afhankelijk van situatie, natuurlijk.

I

Gebruik verschillende technieken (en vergelijk de uitkomsten).

I

Gebruik vooral directe lijnen: de uiteindelijke gebruikers, geen surrogaatgebruikers, geen intermediairs.

I

Een stuk of vier onafhankelijke bronnen van informatie is veelal voldoende.

Het belangrijkste is dat je gestructureerd aan de slag gaat.


Requirements specificeren Definitie: Requirements specification: rigorous modeling of requirements, to provide formal definitions for various aspects of the system Document met specificaties moet: I

precies zijn (startpunt voor architectuur en ontwerp)

I

voor iedereen leesbaar en begrijpbaar zijn


Requirements specificeren Definitie: Requirements specification: rigorous modeling of requirements, to provide formal definitions for various aspects of the system Document met specificaties moet: I

precies zijn (startpunt voor architectuur en ontwerp)

I

voor iedereen leesbaar en begrijpbaar zijn

Bij voorkeur: • • • • • 42

correct niet-ambigu volledig consistent begrijpelijk

• • • • •

geprioriteerd controleerbaar aanpasbaar traceerbaar [Faculty of Science realistisch Information and Computing Sciences]

Requirements specificeren

Technieken: I

Entity-Relationship (E-R) modeling

I

Structured Analysis and Design Technique (SADT)

I

Eindige toestandsautomaten

I

Use cases

I

UML


De 7 zonden (van de analist)

I

Ruis

I

Weglating

I

Overspecificatie (naast het wat ook het hoe)

I

Tegenspraken

I

Ambiguïteit

I

Vooruitverwijzingen

I

Wishful thinking


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 I

I

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


45

Hoe eerder de fout, hoe hoger de prijs

I

Vroege fouten in software ontwikkeling hebben de meeste invloed

I

Dus met name fouten tijdens RE kosten veel om te herstellen

I

Besteed daarom veel aandacht aan de verificatie en validatie van de reqs


Requirements onderhandeling

I

Door vele stakeholders en verschillende interesses moet er doorgaans worden onderhandeld.

I

Classificeer/prioriteer requirements

I

Welke requirements delven het onderspit?


MoSCoW

I

Must haves - zonder deze geen zinnig systeem

I

Should haves - willen we graag

I

Could have - alleen als we tijd hebben

I

Won’t haves - doen we niet


Use cases

I

Use cases zijn een techniek om de functionele requirements te specificeren (”wat moet het systeem doen?”)

I

Contract met stakeholders over het gedrag van een systeem

I

Beschrijft hoe een systeem reageert (onder verschillende condities) op een verzoek van een stakeholder (de primary actor)

I

Feitelijk een tekstuele beschrijving van een scenario


Een voorbeeld Use case: Withdraw cash from ATM Level: User goal 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 50


Enige adviezen

I

Maak use cases makkelijk te lezen, gebruik een actieve vorm (tegenwoordige tijd), beschrijf een actor die zijn doel succesvol bereikt

I

Gebruik sub-use cases waar dit mogelijk is

I

Laat de GUI buiten beschouwing

I

Een actor is niet gelijk aan een rol in een organisatie: een actor interacteert met het systeem

I

Gebruik UML use-case diagrammen voor actor/use-case of use-case/use-case relaties. Gebruik tekst om een use-case te specificeren.

I

Het is moeilijk maar belangrijk om alle use cases bij te houden [Faculty of Science Information and Computing Sciences]

51

Requirements

Valkuilen functionele requirements (S. Lilly): I

Onduidelijke of inconsistente systeem grenzen (scope)

I

Bekeken vanuit het systeem i.p.v. een actor

I

Inconsistente actor namen

I

“Spiderweb” actor-to-use case relaties

I

Lange, te veel, of verwarrende use cases (niet meer te begrijpen door de klant)


Valkuilen

I

”Shopping cart” mentaliteit.

I

De ”alle requirements zijn even belangrijk” argumentatie

I

Use case beschrijvingen die te technisch (of te ingewikkeld) zijn zodat ze niet door de stakeholders gelezen worden


Valkuilen

I

”Shopping cart” mentaliteit.

I

De ”alle requirements zijn even belangrijk” argumentatie

I

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.


Quality Requirements

I I

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

I

Specificeer quality requirements aan de hand van een software quality model: • Raamwerk voor discussies • Om volledigheid te controleren


ISO 9126 (vervangen door ISO/IEC 25010)

I I

Het internationale standaard kwaliteitsmodel Onderverdeling in factoren: • • • • • •

I

Functionality Reliability Usability Efficiency Maintainability Portability

Deze zijn weer onderverdeeld in sub-karakteristieken: Maintainability = {Stability, Analyzability, Changeability, Testability}

I

Deze bestaan weer uit attributen: • Moet gemeten of geverifiëerd kunnen worden • Niet beschreven in de standaard [Faculty of Science Information and Computing Sciences]

55

Adviezen

I

I

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”

I

Maak verbanden tussen de quality requirements en de use cases • ”De ATM valideert een PIN binnen 1 seconde”


Change scenarios Gebruik change scenarios voor niet-functionele aspecten van een systeem I I

Laten zich moeilijk beschrijven door een use case Vooral attributen uit Maintainability en Portability, zoals bijvoorbeeld Changeability en Adaptability


Change scenarios Gebruik change scenarios voor niet-functionele aspecten van een systeem I I

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”


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


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

technische: platform, hergebruik bestaand systeem, voldoen aan standaard

I

financiële: budget

I

organisatie: bedrijfsprocessen, beschikbaarheid klant

I

tijd: deadline [Faculty of Science Information and Computing Sciences]

58

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


Voldoen aan kwaliteits requirements

Definitie: An architectural tactic is an established and proven approach you can use to help achieve a particular quality property. I

De kwaliteits requirements sturen de beslissingen op architectuurniveau

I

Een beslissing (op architectuurniveau) die de kwaliteit van het product beïnvloedt wordt ook wel een tactic genoemd.

I

Gerelateerde tactics worden samengevoegd in architectural patterns: dit zijn schema’s om de structuur van het hele systeem te organiseren [Faculty of Science Information and Computing Sciences]

60

Voorbeeld: tactics voor recoverability I

Voting • tussen verschillende processes die dezelfde taak uitvoeren • detecteert processor fouten (geen algoritmische)

I

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”

I

Passive redundancy • bij een fout overschakelen naar een klaarstaande back-up • vaak gebruikt bij databases

I

Rollback • consistente toestanden onthouden als antwoord op specifieke verzoeken • bijvoorbeeld bij het installeren van software [Faculty of Science Information and Computing Sciences]

61

Voorbeeld: tactics voor changeability

I

Maintain semantic coherence • Hoge cohesie binnen een module, loose coupling naar andere modules

I

Hide information • Specificeer duidelijke interfaces (met verantwoordelijkheden) en onderhoud deze als het programma evolueert

I

Use an intermediary • Data repository koppelt producers en consumers los • Design patterns zoals Facade, Mediator en Proxy vertalen syntax • Brokers verbergen identiteit


Voorbeeld: tactics voor security

I

Authentication • Beinvloed usability negatief

I

Encryption • Beinvloed performance en misschien usability negatief

I

N.B. beide bestaan in vele smaken


Voorbeeld: tactics voor availability

I

Fault detection • Ping, heartbeat, exceptions

I

Fault recovery • voting/polling, active redundancy (hot restart), passive redundancy (warm restart), rollback, spare

I

Fault prevention • transactions, checksums

I

Availability kan ook profiteren van Security tactics zoals authenticatie en intrusion detection.


Architectuur patronen Observatie: veel systemen hebben een soortgelijke oplossingsstructuur: I

Wat zijn de overeenkomsten?

I

Waarin verschillen ze?

I

Wanneer kan de oplossing worden gebruikt?

I

Hoe kan de oplossing (op maat) worden toegepast?


Architectuur patronen Observatie: veel systemen hebben een soortgelijke oplossingsstructuur: I

Wat zijn de overeenkomsten?

I

Waarin verschillen ze?

I

Wanneer kan de oplossing worden gebruikt?

I

Hoe kan de oplossing (op maat) worden toegepast?

An architectural pattern is a proven structural organization schema for software systems. I

A set of predefined subsystems and their responsibilities

I

Rules and guidelines for organizing the relationships between them

Voorbeeld: MVC 65


Karakteristieken van patronen

I

Een patroon richt zich op een terugkomend ontwerpprobleem

I

Een patroon legt bestaande en aangetoonde ontwerpervaringen vast

I

Patronen leveren een vocabulaire en begrip voor ontwerpprincipes

I

Patronen zijn een middel om een software architectuur te documenteren

I

Patronen helpen om software te ontwikkelen dat aan bepaalde eigenschappen voldoet


Schema van een patroon

Een patroon bestaat (minstens) uit de volgende onderdelen: I I

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

I

Oplossing: een bewezen oplossing voor het probleem • Structuur met componenten en relaties (statisch) • Run-time gedrag (dynamisch)


Verschil met design patterns

I

Een design pattern beschrijft een schema om een subsysteem of component van een software systeem te verbeteren • Voorbeelden: Observer, Strategy, Abstract Factory, Proxy

I

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


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 I

Elke laag levert diensten aan de (volgende) bovenliggende laag

I

Om een dienst te implementeren mogen diensten uit de (volgende) onderliggende laag worden gebruikt

I

Service requests gebruiken vaak synchronous procedure calls


Layers patroon – voorbeelden

Voorbeeld: netwerk protocollen I

ISO Open Systems Interconnect 7-layer model

I

TCP/IP (versimpelde versie van het OSI model) [Faculty of Science Information and Computing Sciences]

70


Voorbeelden: I

Applicatie: FTP en HTTP

I

Transport: TCP

I

Netwerk: IP

Voorbeeld: netwerk protocollen I

ISO Open Systems Interconnect 7-layer model

I

TCP/IP (versimpelde versie van het OSI model) [Faculty of Science Information and Computing Sciences]

70


Meer voorbeelden van gelaagde architecturen: I

Virtuele machines (bijvoorbeeld de JVM) JVM gebruikt diensten van het onderliggende OS

I

APIs C standaard library gebruikt Unix system calls

I

Informatiesystemen client/server, lagen in webapplicaties

I

Operating systems microkernel architecturen (Windows NT, 2000, XP)


Layers patroon – analyse

I

Meest stabiele abstracties in de onderste laag

I

Lokale aanpassingen (en toevoegingen) in één laag

I

De diensten van een laag kunnen op verschillende manieren worden geïmplementeerd (conform Bridge design pattern: dynamische link tussen abstractie en implementatie)

I

Lagen kunnen onafhankelijk ontwikkeld worden

I

Een abstracte service interface definiëren is niet makkelijk

I

Mogelijke performance overhead door het herhaaldelijk transformeren van data

I

Onderste lagen verrichten wellicht onnodig werk


Client-server patroon

I

Een server component biedt diensten aan (aan meerdere clients)

I

Een client component gebruikt diensten van server componenten Requests gaan vaak over proces en machine grenzen heen

I

• inter-proces communicatie mechanisme • gelaagde architectuur I

Een server is permanent actief en in afwachting op een request


Client-server patroon

I

Een server component biedt diensten aan (aan meerdere clients)

I

Een client component gebruikt diensten van server componenten Requests gaan vaak over proces en machine grenzen heen

I

• inter-proces communicatie mechanisme Voorbeelden: • gelaagde architectuur I

I Remote DB access Een server is permanent actief en in I een Remote file systems afwachting op request I Multi-tier informatiesystemen I

73

Web applicaties


Client-server patroon – analyse

I I

Requests vaak in verschillende threads afgehandeld Inter-proces communicatie zorgt voor overhead • Marshallen van requests en data • Netwerk verkeer

I

Transparantie in gedistribueerde systemen • Soorten transparantie: access, location, platform, failure

I

Toevoegen tussenliggende laag voor specifiek doel • Caching, security, load balancing

I

Soms zijn callback functies noodzakelijk • Event notification • Transitie naar het peer-to-peer model


Client-server patroon – analyse

Client en server componenten gaan vaak sessies aan. Moet de server wel of geen state bijhouden? I

Stateless servers: • Session state wordt beheerd door de client • State meezenden met iedere request

I

Stateful servers: • Session state wordt beheerd door de server • State wordt geassocieerd met een client-id

Overwegingen: transacties, foutafhandeling, schaalbaarheid


Master-slave patroon

I

Het Master-Slave patroon bevordert fout-tolerantie en parallellisatie

I

Een master component verdeelt werk onder identieke slave componenten en berekent een eindantwoord uit de antwoorden van de slave componenten

I

Voorbeelden: • Process control • Embedded systemen • Grootschalige parallelle berekeningen • Fout-tolerante systemen [Faculty of Science Information and Computing Sciences]

76

Master-slave patroon – voorbeeld


Master-slave patroon – analyse

I

”Divide and conquer” model

I

Als de master component faalt dan faalt het systeem

I

Coördinatie en het eigenlijke werk zijn gescheiden

I

Slave componenten zijn gescheiden (geen gedeelde state)

I

Slave componenten kunnen parallel opereren

I

De latency in de communicatie tussen de componenten kan problematisch zijn (bijvoorbeeld in hard real-time systemen)

I

Probleem moet op te splitsen zijn


Master-slave patroon – analyse

I

”Divide and conquer” model

I

Als de master component faalt dan faalt het systeem

I

Coördinatie en het eigenlijke werk zijn gescheiden SlaveToepassingsgebieden: componenten zijn gescheiden (geen gedeelde state) I grote fout-tolerantie Slave componenten kunnen parallel opereren

I I I

I parallelle berekeningen De latency in de communicatie tussen de componenten kan I nauwkeurigheid van eenin berekening problematisch zijn (bijvoorbeeld hard real-time systemen)

I

Probleem moet op te splitsen zijn


Pipe-filter patroon

I

Geschikte structuur voor systemen die een stream met data produceren

I

Elke bewerkingsstap gebeurt in een filter component

I

Data wordt met een pipe doorgegeven aan de volgende filter component

I

Een pipe kan buffering en synchronisatie verzorgen


Pipe-filter patroon

I

Geschikte structuur voor systemen die een stream met data produceren

Elke bewerkingsstap gebeurt in een filter component Voorbeelden: I Data wordt met een pipe doorgegeven aan de volgende I filter component Compilers I

I

Een buffering en synchronisatie verzorgen Unixpipe shellkan commands cat file | grep SWA | sort | uniq > out


Pipe-filter patroon – compiler


Pipe-filter patroon – analyse

I I

Een nieuwe filter component toevoegen is makkelijk Filters zijn herbruikbaar • Kunnen onafhankelijk ontwikkeld worden • Transformeren van data kan voor extra overhead zorgen

I I

Invoer mogelijk uit verschillende bronnen (idem uitvoer) Natuurlijke ondersteuning voor concurrency • Throughput en deadlock analyses zijn simpel

I

Filters delen geen state

I

Minder geschikt voor interactieve applicaties


Broker patroon

I

I

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

I

Server meldt zijn capabilities (diensten en karakteristieken) aan bij een broker

I

Client vraagt dienst aan bij een broker

I

Broker zoekt dienst op in zijn registry en stuurt request vervolgens door [Faculty of Science Information and Computing Sciences]

82

Broker patroon – analyse

I

Dynamische veranderingen, toevoegen of verwijderen van diensten, en verplaatsen van objecten is makkelijk

I

Distributie is transparant voor de ontwikkelaar

I

Standaarden nodig om diensten te beschrijven

I

Bridges kunnen helpen om de implementatie te verbergen wanneer twee brokers samen moeten werken Voorbeelden:

I

• CORBA (Common Object Request Broker Architecture) bevordert samenwerking tussen heterogene object-georiënteerde systemen. • Web services


Broker patroon – voorbeeld


Broker patroon – IDL

I

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


Broker patroon – IDL

I

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

I

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


Broker patroon – web services

I

UDDI • Universal Discovery, Description and Integration • Repository met organisaties die web services aanbieden

I

WSDL • Web Service Description Language • Om de interface van een web service te definiëren

I

SOAP • Simple Object Access Protocol • Transport protocol voor XML berichten

I

XML • Extendible Markup Language • Taal voor het beschrijven van structuren [Faculty of Science Information and Computing Sciences]

86

Peer-to-peer patroon I

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

I

Client en server zijn typisch multi-threaded

I

Diensten kunnen impliciet zijn (bijvoorbeeld door middel van een stream)

I

Soms nodig om meerdere clients in te lichten (bijvoorbeeld met het event-bus patroon) Voorbeelden:

I

• Multi-user applicaties (drawing board) • P2P file sharing [Faculty of Science Information and Computing Sciences] 87

Peer-to-peer patroon – analyse

I

Weinig administratieve overhead

I

Zelforganiserend

I

Schaalbaar en ongevoelig voor falende peers

I

Dynamische configuratie

I

Geen garantie kwaliteit diensten

I

Security is lastig


Event-bus patroon I

Event sources plaatsen berichten op de verschillende kanalen van een event bus

I

Event listeners melden zich aan bij kanalen

I

Listeners worden ingelicht bij plaatsing bericht

I

Genereren en inlichting van berichten gebeurt asynchroon

I

Kanalen kunnen impliciet zijn (bijvoorbeeld event patronen)


Event-bus patroon – voorbeeld Voorbeelden: I

Monitoren van processen

I

Trading systemen

I

Software ontwikkelomgeving


Event-bus patroon – analyse

I

Toevoegen en verwijderen van publishers, subscribers en verbindingen is simpel (zelfs dynamisch)

I

Moeilijk aannames te maken over distributie, tijd, volgorde en bezorging van berichten

I

Schaalbaarheid (event-bus kan bottleneck worden)

I

Impliciete communicatie geeft weinig inzicht in het systeem


Model-view-controller patroon Splitst interactieve applicaties in drie componenten: I

Model: core functionaliteit en data

I

Views: toont informatie aan de gebruiker

I

Controllers: verwerkt invoer van de gebruiker


Model-view-controller patroon – analyse

I

Meerdere views van een model mogelijk

I

Het model is onafhankelijk van het aantal en soort GUIs

I

De “look and feel” is makkelijk aan te passen

I

Consistentie via notificaties (bijvoorbeeld met het Observer design pattern) Voorbeelden:

I

• Smalltalk • Web presentaties (zie hoofdstuk over “Enterprise application architecture”) • Document-View architectuur van Windows applicaties


Model-view-controller patroon – voorbeeld


Blackboard patroon

I

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

I

Alle componenten hebben toegang tot een gedeelde data store (het blackboard)

I

Componenten produceren nieuwe data objecten en plaatsen deze op het blackboard

I

Componenten zoeken naar bepaalde data op het blackboard (bijvoorbeeld met pattern matching) [Faculty of Science Information and Computing Sciences]

95

Blackboard patroon – analyse

I

Processen moeten overeenstemming bereiken over de structuur van de gedeelde data space

I

Makkelijk om nieuwe applicaties toe te voegen

I

Structuur data space uitbreiden is simpel

I

Structuur data space aanpassen is lastig

I

Synchronisatie en toegangsprivileges niet standaard ondersteund [Faculty of Science Information and Computing Sciences]

96

Interpreter patroon

I

Een gedeelte van de functionaliteit van een systeem wordt gerealiseerd door een component dat programma’s interpreteert die geschreven zijn in een dedicated taal

I

Geïnterpreteerde programma’s zijn makkelijk te vervangen

I

Problemen: stability, security, performance

Voorbeelden: I

Regel-gebaseerde systemen

I

Web scripting (bijvoorbeeld JavaScript)

I

Postscript [Faculty of Science Information and Computing Sciences]

97

Bedrijfsapplicaties

Vertonen veel overeenkomsten: I

Persistente data

I

Groot volume data

I

Gelijktijdige toegang

I

Ingewikkelde user interfaces

I

Integratie met andere applicaties (conceptual dissonance)

I

Bedrijfslogica


Voorbeelden van bedrijfsapplicaties B2C online retailer I

Heel veel gebruikers, schaalbaarheid

I

Iedereen moet toegang hebben




I


Verwerken van lease overeenkomsten I

Ingewikkelde bedrijfslogica

I

Geavanceerde presentatie gegevens

I

Ingewikkelde afhandeling transacties (uren)




I


Verwerken van lease overeenkomsten I

Ingewikkelde bedrijfslogica

I

Geavanceerde presentatie gegevens

I

Ingewikkelde afhandeling transacties (uren)

Expense tracking systeem voor een klein bedrijf [Faculty of Science Information and Computing Sciences] 99

De drie hoofdlagen

Het Layers architectuur patroon toegepast op bedrijfsapplicaties I

Presentation logic • Interactie met gebruiker • Command-line, rich client of web interface

I

Domain logic • Validatie van invoer en berekenen van resultaten

I

Data source logic • Communicatie met database en andere applicaties


Voorbeeld: Java EE multi-tier architectuur Vier lagen op drie machines I

Client applicatie componenten

I

Applets

I

Servlets en JSP componenten

I

Enterprise JavaBeans componenten

client tier + web tier = presentation layer business tier = domain logic + data source logic [Faculty of Science Information and Computing Sciences] 101

Servlets and JSP

Presentation logic in de Java EE architectuur: I

Servlets bevatten Java code om HTML te genereren • vergelijkbaar met CGI scripts • draaien allemaal op dezelfde JVM (geen opstart kosten)

I

JSP pagina’s mixen code (logica) met HTML (presentatie) • lijkt op PHP

I

Of applets/Java applicaties voor een rich client


Enterprise JavaBeans

Enterprise JavaBeans (EJB) zijn herbruikbare componenten I

Gedistribueerd: communicatie met RMI of CORBA

I

Voor entiteiten (database objecten) en sessies (communicatie met clients)

I

Transacties, beveiliging, persistentie, enzovoort door container


Java EE server en containers


Patterns of Enterprise Application Architecture Boek van Martin Fowler I

Beschrijft ongeveer 40 patronen

I

Voorbeelden in Java en C#

Voor een catalogus, zie: http://martinfowler.com/eaaCatalog/


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...


Transaction Script patroon (domain logic) Organizes business logic by procedures where each procedure handles a single request from the presentation

I

Transactie heeft een welgedefinieerd eindpunt

I

Afhandeling op een alles-of-niets basis

I

Roept meestal de database direct aan

I

Kan worden georganiseerd als een aparte klasse volgens het Command design pattern

I

Evaluatie: simpel en makkelijk, maar risico van (code) duplicatie tussen transacties


Domain Model patroon (domain logic)

An object model of the domain that incorporates both behavior and data

I I

Kan apart worden ontwikkeld en getest Verschillend van een database model • Multi-valued attributen, inheritance, design patterns • Synchronisatie met een database is lastig

I

Risico: buitensporig grote domeinobjecten


Table Module patroon (domain logic) A single instance that handles the business logic for all rows in a database table or view

I

Niet één object per order, maar een object om alle orders af te handelen

I

Data en gedrag samengebracht (zoals in OO)

I

Makkelijk te mappen naar een database

I

Werkt bijzonder goed in combinatie met SQL

Eén instantie voor een tabel: I

Inheritance kan worden gebruikt

I

Ondersteuning in Microsoft COM en .NET (Record Set) [Faculty of Science Information and Computing Sciences]

109

Web presentatie

I

Web-browser-gebaseerde interfaces hebben vele voordelen: • Geen client software hoeft te worden geïnstalleerd • Overal toegankelijk • Bekende benadering voor user interfaces

I

Web server interpreteert de URL van een request en geeft de controle aan het geschikte programma

I

Twee soorten: server-side scripts en server pages


Server-side scripts Scripts zijn programma’s in algemene high-level programmeertalen I

Verkrijgen data door het ontleden van een HTTP request • Voorbeeld: CGI scripts I I

kan in verschillende talen worden geschreven Perl is populair vanwege zijn reguliere-expressie ontleder

• Voorbeeld: Java servlets I

automatisch ontleden http request

I

Output door normale stream operaties

I

Programmeervaardigheden nodig: minder geschikt voor grafische ontwerpers [Faculty of Science Information and Computing Sciences]

111

Server pages

I

Geeft een pagina terug in HTML

I

Bevat fragmenten met code

I

Voorbeelden: PHP, ASP, JSP

I

Werkt het beste als de resultaten niet (of weinig) verwerkt hoeven te worden

Nadeel: rommelige fragmenten, scoping lastig


Server pages <% Subjects s = new Subjects(); %> Click on any of these subjects: <% Iterator all = s.getAll(); while (all.hasNext()) { String url = (String) all.next(); %>
.jsp"> <%= url%>
<%}%> [Faculty of Science Information and Computing Sciences] 113

Model View Controller patroon (pres. logic) Splits user interface interaction into three distinct roles Hier toegepast op web presentaties I

Model: representeert informatie over het domein • meestal binnen een domeinmodel

I

View: toont het domein in een user interface • een (gegenereerde) HTML pagina

I

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 [Faculty of Science Information and Computing Sciences]

114

Transform View patroon (presentation logic)

A view that processes domain data element by element and transforms it into HTML

I

Een Template View is georganiseerd rond het soort uitvoer

I

Een Transform View is georganiseerd rond de verschillende vertalingen van de elementen Meestal uitgeprogrammeerd in XSLT

I

• XSLT is een functionele taal voor het transformeren van XML (waaronder XHTML)



Rubber Soul <artist>The Beatles Drive My Car Norwegian Wood ...



Rubber Soul <artist>The Beatles Drive My Car Norwegian Wood ...

<xsl:template match="album"> <xsl:apply-templates/> <xsl:template match="album/title">
<xsl:apply-templates/>
<xsl:template match="artist">
Artist: <xsl:apply-templates/>

116

Concurrency

I

Zeer lastig om te testen

I

Moeilijk om erover te redeneren

I

De meeste problemen met concurrency in bedrijfsapplicatie kunnen worden voorkomen door transacties te gebruiken

I

Offline concurrency: interacties die niet door een database transactie kunnen worden afgehandeld


Locking strategieën Optimistic locking: alle gebruikers kunnen vrij bestanden lezen en aanpassen I

Concurrency control ontdekt conflicten wanneer veranderingen worden gecommit

I

Werkt als conflicten relatief zeldzaam zijn (en niet te pijnlijk)

I

Automatische merges zijn soms mogelijk

Pessimistic locking: als een bestand door iemand bekeken wordt dan kan niemand anders het aanpassen I

Voorkomt conflicten in plaats van deze op te lossen

I

Belemmert vooruitgang [Faculty of Science Information and Computing Sciences]

118

Locking strategieën Optimistic locking: alle gebruikers kunnen vrij bestanden lezen en aanpassen I

Concurrency control ontdekt conflicten wanneer veranderingen worden gecommit

I

Werkt als conflicten relatief zeldzaam zijn (en niet te pijnlijk)

Automatische zijnstrategieën soms mogelijk Recent winnenmerges lock-free aan populariteit, zoals het software transactional memory model Pessimistic locking: als een bestand door iemand bekeken wordt dan kan niemand anders het aanpassen I

I

Voorkomt conflicten in plaats van deze op te lossen

I

Belemmert vooruitgang [Faculty of Science Information and Computing Sciences]

118

Transactions

A transaction is a bounded sequence of work with well-defined beginning and end points

Software transacties moeten ACID zijn: I

Atomic

I

Consistent

I

Isolated

I

Durable


Session state

I

Veel client interacties zijn inherent stateful • Voorbeeld: boodschappenmandje

I

Stateful server is erg inefficiënt: de toestand van alle gebruikers sessies moet worden onthouden

I

Session state is verschillend van persistente data zoals opgeslagen in een database

• één object per gebruiker nodig

• Bestaat tijdens een enkele transactie • Hoeft niet consistent te zijn (bijvoorbeeld tijdens editten)


Client Session State patroon

Stores session state on the client (rich-client applications) Drie standaard manieren met een HTML interface: I URL parameters • http://www.barnesandnoble.com/index.asp?userid=uF7IWlCAnh • Alle links op een pagina krijgen de toestand als een parameter • Nadeel: codering zichtbaar voor gebruiker I

Hidden fields •

I

Cookies • controversieel, kunnen uitgeschakeld worden


Distributie strategieën

Afgeraden om een applicatie verdelen door verschillende componenten op verschillende nodes te plaatsen I

Remote procedure calls zijn vele malen langzamer [Faculty of Science Information and Computing Sciences]

122

Remote Facade patroon Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network.

I

De verfijnde objecten bevatten domeinlogica

I

De remote facade vervangt de getters en setters van de individuele objecten door een samengestelde getter/setter [Faculty of Science Information and Computing Sciences]

123

Describing and Evaluating Software Architectures


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): I

Legt de basis van het ontwerp

I

Formuleert regels en principes waaraan het ontwerp moet voldoen




I


Architectuur is een zorgvuldige opdeling van het geheel in onderdelen I Met specifieke relaties tussen de onderdelen I Zorgt dat onafhankelijke groepen effectief kunnen samenwerken I Onderdelen kunnen onafhankelijk worden gebouwd, zodanig dat de

delen uiteindelijk ook met succes als een geheel samenwerken [Faculty of Science Information and Computing Sciences] 125



I


Architectuur is een zorgvuldige opdeling van het geheel in onderdelen Het architectuur document vertelt ontwikkelaars hoe dit I Met specifieke relaties tussen de onderdelen bereiktkunnen kan worden I Zorgt dat onafhankelijke groepen effectief samenwerken I Onderdelen kunnen onafhankelijk worden gebouwd, zodanig dat de

delen uiteindelijk ook met succes als een geheel samenwerken [Faculty of Science Information and Computing Sciences] 125

Architectuur voor kwaliteit

I

Architectuur bevat het maken van engineering choices die de kwaliteitsattributen bepalen • Individuele doelen kunnen worden bereikt met tactieken

I I

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)


Basiskwesties bij het beschrijven Schrijf het document vanuit de lezer: I

Een document wordt maar één keer geschreven, maar meerdere malen gelezen

I

Wie is het bedoelde publiek? Wat moeten/willen ze weten?


Basiskwesties bij het beschrijven Schrijf het document vanuit de lezer: I

Een document wordt maar één keer geschreven, maar meerdere malen gelezen

I

Wie is het bedoelde publiek? Wat moeten/willen ze weten?

Advies: voorkom I

(bijna) herhalingen

I

ambiguïteiten

I

notatie zonder uitleg

I

chaotische organisatie

I

ongedocumenteerde beslissingen

I

documentatie die niet up-to-date is

Waarom?


Software architectuur als een discipline I

Inspiratie van andere engineering domeinen (construction, electronics)

I

Zijn industriestandaarden voor het opslaan en representeren van informatie mogelijk?

In de Italiaanse renaissance kostte het architecten 150 jaar voordat ze vanuit een 3-dimensionaal perspectief konden tekenen. 128


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






Engine Type : TU5JP4

Belangen en views Engine capacity : 1578 Max. Power hp (rpm) : 110(5800) Max. Torque Nm (rpm) : 142(4000)

A view is a representation a set of :system Max. Speed (withof Manual gearbox) 193 km/h elements and the Max. Speedwith (with automatic relationships associated 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 ... 129


IEEE 1471 ANSI/IEEE Standaard 1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems I

Een model van architectuurbeschrijvingen in hun context

I

Resultaat van consensus

I

Toepasbaar op systemen waarin software een belangrijke rol speelt

I

Richt zich alleen op de organisatie van een beschrijving, niet op het systeem zelf of de werkelijke modellen


IEEE 1471 ANSI/IEEE Standaard 1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems I

Een model van architectuurbeschrijvingen in hun context

I

Resultaat van consensus

I

Toepasbaar op systemen waarin software een belangrijke rol speelt

I

Richt zich alleen op de organisatie van een beschrijving, niet op het systeem zelf of de werkelijke modellen

I

Geen specifieke talen, viewpoints, viewtypes of modellen

I

Geen formele criteria om consistentie te toetsen [Faculty of Science Information and Computing Sciences]

130

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 [Faculty of Science Information and Computing Sciences]

131

Concepten van IEEE 1471


IEEE 1471 in de praktijk I

Metagegevens • Datum, auteurs, change history, samenvatting, woordenlijst

I

Stakeholders en hun belangen • Stakeholders: gebruiker, klant, ontwikkelaar, onderhoudsteam (minimaal) • Belangen: doel/missie, appropriateness, feasibility, risico’s, maintainability, deployability, evolvability (minimaal)

I

Consistentie • Consistentie analyse tussen views, documenteren van bekende inconsistenties

I

Rationale • Motivering van de ontstane architectuur en zijn beschrijving • Beschrijving van verworpen alternatieven en gemaakte keuzes (in verband brengen met requirements) [Faculty of Science Information and Computing Sciences]

133

IEEE 1471 in de praktijk Selectie van viewpoints, gedefinieerd door:

(*) is optioneel

I

Naam van viewpoint

I

Bedoeld voor welke stakeholders

I

Omvat welke belangen

I

Taal, modelleer techniek, analytische methodes (welke concepten herkennen de stakeholders?)

I

Bij een library viewpoint, referentie naar de bron

I

Toetsing op consistentie en compleetheid∗

I

Evaluatie en analyse technieken∗

I

Heuristieken, tips, etc.∗

I

Rationale [Faculty of Science Information and Computing Sciences]

134

Voorbeelden van viewpoints Maintenance viewpoint: I Bedoeld voor onderhoud engineers I Waar nieuwe functionaliteit toevoegen? Welke interfaces

implementeren? Hoe een component te compileren (en te linken)? I In welke vorm?




Operations viewpoint: I Bedoeld voor operators I Hoe het systeem installeren en configureren op echte computers? Hoe

de executie monitoren? Hoe af te breken in geval van nood? I In welke vorm?




Operations viewpoint: I Bedoeld voor operators I Hoe het systeem installeren en configureren op echte computers? Hoe

de executie monitoren? Hoe af te breken in geval van nood? I In welke vorm?

Management viewpoint: I Bedoeld voor decision makers I Welke functionaliteit biedt het systeem? Wat zijn de kosten van

introductie binnen de organisatie? Wat zijn de risico’s? I In welke vorm? 135


Zachman Framework – www.zifa.com


Zachman Framework – www.zifa.com What? entity/ relation

How? Where? function/ node/ arg link

Who? agent/ work

When? time/ cycle

Why? end/ means

Scope Planner Enterprise model Owner System model Designer Technology model Builder Components Subcontractor Working system [Faculty of Science Information and Computing Sciences] 137

Het Kruchten ”4+1” model Een praktische verzameling viewpoints voor software architecturen I I I

Philippe Kruchten, Rational (1995) Ontstaan in grootschalige projecten Georiënteerd op OO systemen


Het Kruchten ”4+1” model Een praktische verzameling viewpoints voor software architecturen

I

Philippe Kruchten, Rational (1995) Ontstaan in grootschalige projecten Georiënteerd op OO systemen

I

Opgegaan in het Rational Unified Process (RUP)

I

views corresponderen met soorten UML diagrammen

I

RUP introduceert licht afwijkende terminologie

I I


Het Kruchten ”4+1” model Doel van de scenario’s I

Analyseer en demonstreer volledigheid en consistentie tussen de vier views

I

Zoek relevante architectuur concepten

View correspondence I

Een aantal richtlijnen om van één view naar een andere te gaan (bijvoorbeeld een class mappen op een proces)

Praktische observaties

139

I

4+1 biedt bruikbare, ietwat technische, viewpoints

I

Accent op development

I

Ook toepasbaar op bestaande systemen


Viewtypes A viewtype is a category of views, containing similar elements and relationships. A viewtype defines the element types and relationship types, used to describe the architecture of a software system from a particular perspective [Clements et al.] Alle views behoren tot één van de volgende drie viewtypes: I

Module viewtype documenteert de belangrijkste units of implementation van een systeem

I

Connector viewtype documenteert de units of execution van een systeem

I

Allocation viewtype documenteert de relaties tussen de software van een systeem en zijn ontwikkelen executieomgeving [Faculty of Science Information and Computing Sciences]

140

Module viewtype Documenteert de structuur van de implementatie eenheden (d.w.z., software units met welgedefinieerde interfaces) I

Elementen: modules (classes, packages) • verantwoordelijkheden • zichtbare interfaces • implementatie informatie (zoals code bestanden)

I

Relaties: part-of, depends-on, is-a

I

Voorbeelden: Kruchten’s logical view, Kruchten’s development view

I

Notatie: UML class diagram, UML package diagram

Kritiek: UML class diagrams bieden een view van al deze relaties tegelijkertijd, en daarmee wordt het nut beperkt [Faculty of Science Information and Computing Sciences] 141

Connector viewtype Definieert modellen bestaande uit elementen met een runtime voorkomen I

Elementen: runtime componenten: processen, objecten, clients, servers, data stores, filters

I

Elementen: connectors pathways of interaction: communication links, protocollen, information flows, procedure calls, asynchrone berichten, pipes

I

Relaties: attachment (connector/component)

I

Voorbeelden: Kruchten’s process view

I

Notatie: UML 2.0 component diagram, UML-RT diagram, data flow diagram [Faculty of Science Information and Computing Sciences]

142

Allocation viewtype Documenteert de interactie van hardware, file systemen, en team structuren met de software architectuur I

Deployment stijl • Elementen: processen van de connector viewtype, processor, geheugen, disk, netwerk • Relaties: allocated-to, migrates-to

I

Implementatie stijl • Elementen: modules, bestanden, directories • Relaties: allocated-to, containment

I

Werkverdeling stijl • Elementen: modules, bedrijven, teams, personen • Relaties: allocated-to

I

Voorbeelden: Kruchten’s physical view, UML deployment diagram, UML artifact diagram


143

Evalueren van architecturen Winst: I

Kostenbesparend door vroege detectie van fouten en problemen

I

Minder risico op rampproject of miskoop

I

Meer begrip en documentatie van systemen

I

Verduidelijking prioriteiten van de requirements

I

Organizational learning

Kosten: I

reviewers (tijd)

I

ontwikkelteam (tijd en focus)

I

overige stakeholders (tijd) [Faculty of Science Information and Computing Sciences]

144

Evalueren van architecturen Winst: I

Kostenbesparend door vroege detectie van fouten en problemen Evaluatie is noodzakelijk omdat het

I

I

Minder risico rampproject of miskoop vakgebied nogopsteeds een ”ambacht” is zonder duidelijke regels. Het motto is: Meer begrip en documentatie van systemen ”leren door te doen” Verduidelijking prioriteiten van de requirements

I

Organizational learning

I

Kosten:

Evalueren: I

Wanneer?

I

Wie?

I

reviewers (tijd)

I

Wat?

I

ontwikkelteam (tijd en focus)

I

Hoe?

I

overige stakeholders (tijd) [Faculty of Science Information and Computing Sciences]

144

Wanneer?

Verschillende tijdstippen: I

Regelmatig, als onderdeel van iteratief architectuur proces

I

Vroeg, om zo de koers van het project te valideren

I

”Toll gate”, een check voor het werkelijke bouwen begint (of voordat een leverancier wordt geselecteerd)

I

Achteraf (too late), om architectuur problemen op te lossen


Wanneer?

Verschillende tijdstippen: I

Regelmatig, als onderdeel van iteratief architectuur proces

I

Vroeg, om zo de koers van het project te valideren

I

”Toll gate”, een check voor het werkelijke bouwen begint (of voordat een leverancier wordt geselecteerd)

I

Achteraf (too late), om architectuur problemen op te lossen

Afwegingen: I

Formeel t.o.v. informeel

I

Gepland t.o.v. ongepland [Faculty of Science Information and Computing Sciences]

145

Wie?

Mogelijkheden: I

Het ontwikkelteam zelf

I

Andere groep uit dezelfde organisatie

I

Externe reviewers, bij voorkeur zonder een belang in de uitkomst van de evaluatie


Wie?

Mogelijkheden: I

Het ontwikkelteam zelf

I

Andere groep uit dezelfde organisatie

I

Externe reviewers, bij voorkeur zonder een belang in de uitkomst van de evaluatie

Afwegingen: I

Domeinkennis en ervaring

I

Competitie, partijdigheid


Wat? Mogelijkheden: I

Architectuur proces

I

Architectuur beschrijving

I

Algemene architectuur eigenschappen (zoals bijvoorbeeld compleetheid)

I

Specifieke kwaliteitsgebieden

I

Toekomstige veranderingen en hun impact


Wat? Mogelijkheden: I

Architectuur proces

I

Architectuur beschrijving

I

Algemene architectuur eigenschappen (zoals bijvoorbeeld compleetheid)

I

Specifieke kwaliteitsgebieden

I

Toekomstige veranderingen en hun impact

Belangrijk: I

Doel van de evaluatie moet duidelijk zijn!

I

Selecteer het juist review team voor het doel [Faculty of Science Information and Computing Sciences]

147

Hoe? Ondervragingstechnieken: I

Genereer discussies met kwalitatieve vragen

I

Vragenlijsten

I

Checklists

I

Scenario’s

Meettechnieken: I

Produceer kwantitatieve antwoorden op specifieke vragen

I

Gebruik metrieken

I

Simulaties, prototypes

I

Formele analyses [Faculty of Science Information and Computing Sciences]

148

Methoden voor evaluatie

1. Reviewen van de architectuurbeschrijving en het proces 2. Scenario-gebaseerde analyse 3. Architecture Tradeoff Analysis Method (ATAM)

Vele andere methoden zijn beschreven in de literatuur


Reviewen architectuurbeschrijving en proces Focus: I

Voldoet de architectuurbeschrijving aan de standaarden (voor een bepaalde situatie)?

I

Impliciet: hebben de architecten de juiste activiteiten doorlopen?


Reviewen architectuurbeschrijving en proces Focus: I

Voldoet de architectuurbeschrijving aan de standaarden (voor een bepaalde situatie)?

I

Impliciet: hebben de architecten de juiste activiteiten doorlopen?

Methode: I Bepaal het hoofddoel I Verzamel relevante documenten I Lees en becommentarieer I Analyseer aan de hand van het IEEE 1471 framework I Voor sommige documenten en modellen bestaan specifieke checklists I Neem commentaar eventueel door met relevante partijen I Rapporteer observaties, risico’s en voorgestelde verbeteringen [Faculty of Science Information and Computing Sciences] 150

Reviewen architectuurbeschrijving en proces Controle vragen: I Zijn alle stakeholders in aanmerking genomen?

151

I

Zijn de belangrijkste requirements geïdentificeerd?

I

Zijn de kwaliteitsaspecten overwogen en geselecteerd?

I

Welke belangen zijn geïdentificeerd?

I

Welke viewpoints zijn gedefiniëerd?

I

Is er een rationale voor de viewpoints?

I

Hoe zijn de views gedocumenteerd? Met welke modelleertechniek of taal?

I

Wat is de kwaliteit van het model en document wat betreft leesbaarheid, organisatie, terminologie?

I

Is er een rationale voor de gekozen oplossing?

I

Hoe zijn de documenten beheerd?

I

Zijn de modellen consistent?


Scenario-gebaseerde analyse Scenarios are brief narratives of expected or anticipated use of a system from both development and end-user viewpoints


Scenario-gebaseerde analyse Scenarios are brief narratives of expected or anticipated use of a system from both development and end-user viewpoints Focus: I Identificeer relevante scenario’s (events/situaties in de levensloop van een systeem) en bestudeer de impact op het systeem (en de architectuur) I

Gebruik use cases en change scenarios

Algemene methode: I Bepaal het doel I Ontdek en classificeer scenario’s I Stel de architectuurbeschrijving vast I Bepaal de impact van de scenario’s (en de interactie) I Uiteindelijke evaluatie [Faculty of Science Information and Computing Sciences] 152

Scenario-gebaseerde analyse Verschillende doelen: 1. Identificeren van grote risico’s • Realistische scenario’s met een grote impact • Zoektocht naar scenario’s die niet door de architectuur worden behandeld • Identificeer sensitivity en tradeoff punten



A sensitivity point is an architectural decision involving one or more architectural components and/or connections, that is critical for achieving a particular quality attribute response measure A trade-off point is an architectural decision that affects more than one attribute and is a sensitivity point for more than one attribute. [Faculty of Science Information and Computing Sciences] 153

Scenario-gebaseerde analyse Verschillende doelen: 1. Identificeren van grote risico’s • Realistische scenario’s met een grote impact

Voorbeeld trade-offnaar point: de mate vandoor encryptie • Zoektocht scenario’s die niet de architectuur aanpassenworden kan security behandelden performance significant beïnvloeden, in tegengestelde richting • Identificeer sensitivity en tradeoff punten A sensitivity point is an architectural decision involving one or more architectural components and/or connections, that is critical for achieving a particular quality attribute response measure A trade-off point is an architectural decision that affects more than one attribute and is a sensitivity point for more than one attribute. [Faculty of Science Information and Computing Sciences] 153


2. Valideren van kwaliteitsdoelstellingen • Typisch voor maintainability en modifiability • Change scenarios die waarschijnlijk nodig zijn (in een bepaalde periode) • Schat de kosten van een verandering



2. Valideren van kwaliteitsdoelstellingen • Typisch voor maintainability en modifiability • Change scenarios die waarschijnlijk nodig zijn (in een bepaalde periode) • Schat de kosten van een verandering

3. Kiezen tussen alternatieve architecturen • Vergelijk de scores van verschillende kandidaten • Sorteer op minimalisatie risico’s, en geschatte onderhoudskosten [Faculty of Science Information and Computing Sciences] 153

Architecture Tradeoff Analysis Method

ATAM is a scenario-based standardized evaluation method, which focuses on tradeoffs between quality goals [Kazman et al.]

Drie partijen moeten meewerken: I

Het evaluatie team (externen van het project, 3–5 man)

I

Decision makers van het project (inclusief de architect)

I

Stakeholders (ontwikkelaars, test team, gebruikers, enzovoort)


Architecture Tradeoff Analysis Method

ATAM is a scenario-based standardized evaluation method, which focuses on tradeoffs between quality goals [Kazman et al.]

Drie Deliverables: partijen moeten meewerken: I I I

I evaluatie Kwaliteitsteam requirements termen van scenario’s Het (externeninvan het project, 3–5 man) I Mapping van architectuurbeslissingen op kwaliteits Decision makers van het project (inclusief de architect) requirements Stakeholders (ontwikkelaars, test team, gebruikers, I Verzameling geïdentificeerde sensitivity en tradeoff enzovoort) punten I

Verzameling gevonden risico’s en risicogebieden [Faculty of Science Information and Computing Sciences]

154

Architecture Tradeoff Analysis Method (ATAM) De stappen: 1. Presenteer ATAM (leider evaluatieteam) 2. Presenteer business drivers (beslissingsbevoegden) 3. Presenteer architectuur (hoofd architect) 4. Identificeer architectuur benaderingen en gebruikte patronen (architect) 5. Genereer een quality attribute utility tree 6. Analyseer de architectuurbenaderingen 7. Brainstormen en prioriteiten aanbrengen bij scenario’s (alle stakeholders) 8. Analyseer de architectuurbenaderingen (wederom) 9. Presenteer resultaten [Faculty of Science Information and Computing Sciences] 155

Voorbeeld utility tree Prioritering in 2 dimensies: I

Belang voor succes van het systeem

I

Moeilijkheidsgraad


Software Architecture and Requirements Engineering

Recommend Documents

<xsl:apply-templates/>