3 software architectuur

Bas Kruiswijk

Amersfoort2 november 2011

Softwarearchitectuur

2© Twynstra Gudde | Universiteit Leiden 2-11-2011



Enterprise-architectuu

r

Software-architectuu

rService-georiënteerdearchitectuur

Individuele systeemscope

Gericht op ontwerp, realisaties en specificatie

Organisatiebrede scope

Gericht op strategie en communicatie

Conceptuelebasis



Softwarearchitectuur begint metsoftware engineering– Software engineering is in de informatica het vakgebied dat

zich bezighoudt met (de totstandkoming van) ‘goede’ software (qua product en proces)

– Wat is ‘goede’ software eigenlijk?– Correct, betrouwbaar, robuust

– Performance

– Gebruikersvriendelijk

– Verifieerbaar

– Onderhoudbaar

– Herbruikbaar

– Portable

– Begrijpelijk

– Interoperabiliteit

– Productiviteit



Software engineering principesTop 3 (?)

– Separation of concerns

– Vanwege de inherente complexiteit van softwaresystemen zorgen dat verschillende aspecten gescheiden kunnen worden aangepakt (bijvoorbeeld functionaliteit en performance)

– Modulariteit

– Reduceer de complexiteit door het totaal op te delen in kleinere, relatief zelfstandige delen die zelfstandig kunnen worden ontworpen, ontwikkeld en geïmplementeerd

– Modules hebben een hoge interne cohesie en een lage externe koppelingsgraad

– Anticiperen op veranderingen

– In het ontwerp, de ontwikkeling en de implementatie van software rekening houden met waarschijnlijke veranderingen



Modules en objectoriëntatie

– Modules– Groepering van functionaliteit en gegevensverzamelingen

– Hoger abstractieniveau dan functies, eenheid van (overigens beperkt) hergebruik

– Min of meer zelfstandig realiseerbaar en implementeerbaar

– Objectoriëntatie– Eigenlijk een programmeerconcept

– Objecten zijn een directere representatie van objecten in de reële wereld

– Objecten combineren structuur (statische aspect) en gedrag (dynamische aspect) in een ontwerp- en programmeerconcept

– Scheiding van interface en implementatie



ObjectoriëntatieScheiding van interface en implementatie

implementatievan hetobject

De van buitenaf zichtbare beschrijving van de functie van

het objecten hoe deze te gebruiken

De van buitenaf niet-zichtbareinterne realisatie van het object

middels werkende software

inte

rface interface

inte

rfaceinterface



Componenten

– Gebaseerd op de concepten van objectoriëntatie

– Gericht op het samenstellen van applicaties uit componenten: component based developement

– Componenten hebben vergeleken met objecten enkele extra eigenschappen

– Distribueerbaar (platformonafhankelijk, koppelbaar aan middleware)

– Op run-time te (de)activeren (disconnectable)

– Bruikbaar (herkenbaar, inspecteerbaar, configureerbaar) door ontwikkeltools om applicaties te assembleren



Services

– In technische zin een doorontwikkeling van objecten componenttechnologie

– Brede adoptie van (internet)standaarden voor webservices

– Platformonafhankelijk

– Basisconcept van (bijna) alle ontwikkelplatforms

– Diensten aan gebruikers staan centraal

– Niet (alleen) de softwareconstructie staat centraal, maar de dienst die geleverd wordt

– Niet (alleen) relevant voor ontwikkelaars, maar ook voor gebruikers / organisaties

– Applicaties worden minder relevant – het gaat om services



Service

Dienstinhoud(implementatie)

Dienstaanvraag(request)

Dienstbeschrijving(interface)

Dienstresultaat(respons)

De van buitenaf zichtbare beschrijving van dienst

De interne realisatie van de dienst middels werkende software

request

respons



Programmeertalen en modulariteit

1e generatiemachine

2e generatieassembler

3e generatiegestructureerd

4e generatieabstract

5e generatiefunctioneel

Modulair Object-georiënteerd

Component-gebaseerd

Service-georiënteerd

C++Java

Visual BasicC#

COBOLC

Oracle formsSQL

LISPProlog

J2EE

.Net



Monolitische en modulaire softwarearchitectuur



Client/Server architectuur

Client

Server

Client

Client

Centraal

Decentraal

Decentraal

Decentraal



Gedistribueerde drie- en meerlaagsesoftwarearchitectuur

Presentatie

Businesslogica

Data

Presentatie

Processervices

Data

Samengestelde services

Basisservices



Integratie van applicatieontwikkelingen in de tijd geplaatst (1)

Applicatie1

Applicatie2

Applicatie3 Applicatie

4

Client

Server

Client

Server

Client

Server

Generieke faciliteitenDoorgaans bulkuitwisseling

Corporate databases

1:1 Interfaces Gemeenschappelijkedatabases

specifiek

generiek




Business-logica

Generieke middleware Synchroon (services)

Asynchroon (berichten)

Presentatie

Data

Business-logica

Presentatie

Data

Business-logica

Presentatie

Data

Middleware(generieke servicebus)

Business-logica

Middleware

Presentatie

Data

Business-logica

Presentatie

Data

Webservices(technologie neutraal)

Middleware

Berichtuitwisselinggebaseerd op webservice-standaarden (SOAP)

Technologische oforganisatorische

grens

specifiek

generiek




Business-logica

Presentatie

Data

Business-logica

Data

Business-logica

Data

Portaal voor geïntegreerdewerkprocesondersteuning

Orkestratie

Business-logica

Presentatie

Data

Business-logica

Presentatie

Data

Business-logica

Presentatie

Data

Portaal voor geïntegreerdetoegang en authenticatie

PortaalAuthenticatie, single sign-on

personalisatielook-and-feel

PortaalAuthenticatie, single sign-on

Personalisatie

specifiek

generiek



Andere benadering m.b.t. softwarearchitectuur

– 4+1 View model (Kruchten, UML)

– Design patterns

– Model Driven Architecture



Het 4+1 View-model

– In het 4+1 View-model worden vier views onderkend die samen de architectuur van een systeem beschrijven. Elke view geeft daarbij weer wat, bezien vanuit het perspectief van een bepaalde belanghebbende, fundamenteel is.

Logical view

Process view

Component view

Physical view

Use cases



The 4+1 Views

– Logical view– Logische opbouw van het systeem

– Objecten en hun onderlinge relaties

– Component view– Wijze waarop de objecten (in de logical view) zijn samengesteld tot componenten of zijn

gecombineerd tot services

– Process view– De ‘runtime’-componenten, de ‘executables’

– De onderdelen waaruit de te implementeren applicatie bestaat

– Physical view– De benodigde hardware en andere fysieke componenten om het systeem daadwerkelijk te

kunnen laten werken

– De vijfde view (de +1-view)– Illustreert de samenhang vanuit de invalshoek van het beoogde gebruik van het systeem in de

vorm van ‘use cases’



Design patterns

– Geïntroduceerd door ‘The gang of four’: Gamma, Helms, Johnson,’ Vlissides, in ‘Design Patterns, Elements of Reusable Object-Oriented Software’

– Herbruikbare oplossingen, templates voor ontwerpproblemen

– Ervaring en kennis van ‘goede’ architectuuroplossingen herbruikbaar gemaakt

– Goed gedocumenteerd

– Doel, wanneer gebruiken, voorbeeld van gebruik etc.

– Bijvoorbeeld

– Scheiding van presentatie, interactie en logica (model-view-controller of Observer pattern)

– Verbergen van een verzameling interfaces (Facade pattern)



Model Driven Architecture

– Architectuurbenadering gericht op interoperabiliteit

– Genereren van model tot implementatie (Extreme Non-Programming)

– Platform Independent Model– Modelleert functionaliteit en gedrag, zonder technologische

beperkingen

– Gebruikmakend van gangbare middleware features

– Extra details toegevoegd om vertaling naar Platform Specific Model mogelijk te maken

– Platform Specific Model– Toepassing van een profile op het Platform Independent Model,

om dit sterk geautomatiseerd te kunnen vertalen naar Platform Specific Model

– Uiteindelijk automatisch genereren van software uit het model

Computation IndependentModel

Platform IndependentModel

Platform SpecificModel

mapping

mapping



Alle intellectuele eigendomsrechten met betrekking tot deze presentatie berusten bij Twynstra Gudde. Niets uit deze presentatie mag worden verveelvoudigd of openbaar gemaakt zonder schriftelijke toestemming van Twynstra Gudde.

Bas [email protected]

www.twynstragudde.nl