Kapitel 21: Softwarearkitektur designprincipper



Relaterede dokumenter
Metode til Komponentbaseret arkitektur og design

Objektorientering. Programkvalitet

System Arkitekt Practitioner

DANSK IT ARKITEKTUR CERTIFICERING

Beskrivelse af indhold i ITOS kurset: Master Class i Kravspecifikation indenfor embeddede systemer

STS Designdokument. STS Designdokument

Curriculum Vitae. Uddannelse: 2001 Civilingeniør fra Danmaks tekniske universitet, fagprofil: styring og regulering.

Underbilag 14 C: Afprøvningsforskrifter til prøver og tests

Struktureret system udvikling Minimodul 2: Kravspecifikation og accepttest

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT

UML til kravspecificering

Revisionsnummer: Udarbejdet af: TS

Problembehandling. Progression

Anvendelse af BPT til manuel test

Informationsmøde vedrørende Proof of concept for en integrationsplatform

DATALOGI 1E. Skriftlig eksamen torsdag den 3. juni 2004

Oversættere / Datalogi 1E

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Hovedopgave MASTER I INFORMATIONSTEKNOLOGI LINIEN I SOFTWAREKONSTRUKTION

Undervisningsbeskrivelse

Indkøb af Software Assurance og licenser til Oracle-software. Bilag 1 Situationsbeskrivelse. 9. oktober 2015 Version 1.0

Idéer til vinduer - fra Silent Gliss

Samlet Funktion Køn Anciennitet Alder

Nedslag 2 Hvad skal vi lære, hvad skal vi lave? Værktøj: Den dynamiske årsplan

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

DEN RØDE TRÅD. Seriøs fodbold for sjov

Praktisk modul: Quality Function Deployment. Forfattere: Rainer Pamminger Wolfgang Wimmer Med bidrag fra: Cristina Rocha

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

ADK 1.0 KRAVSPECIFIKATION

2011 Bentley Systems, Incorporated AECOsim Building Designer V8i. Lars Moth-Poulsen, Bentley Systems

CCS Formål Produktblad December 2015

En teknisk introduktion til NemHandel

Softwarearkitektur i Praksis i Danske Virksomheder. Klaus Marius Hansen Henrik Bærbak Christensen Datalogisk Institut, Aarhus Universitet

Micusto Cloud v2. Micusto Cloud er et fleksibelt, brugervenligt cloudsystem til CMS er, webshop- og intranetsystemer.

Lovkrav vs. udvikling af sundhedsapps

4 Basal Objekt-orienteret Programmering I.

OpenTele3. Michael Christensen! Chef Softwarearkitekt, Alexandra Instituttet,! Koordinator for Softwaregruppen i 4S!

Web services i brug. Anvendelse uden for biblioteksverdenen

Der ønskes udarbejdet en ny malkecentral, som skal være mere effektiv og have et bedre design end den nuværende model, som benyttes af SAC.

Delaflevering. De Digitale Hippier. Indhold. Frank Holdt og Linh Tran

Der er forsøgt skrevet en lille notits hver gang der er lavet noget, dog kan der være nogle ting som ikke er blevet kommenteret.

HØJESTERETS KENDELSE afsagt tirsdag den 17. december 2013

LEVERANCE 1.3. Model for kvalitetssikring

Kølesystemer og varmepumper Systemrutediagrammer samt rørog instrumentdiagrammer Udformning og symboler

IFC Egenskaber. Mohammad Hussain Parsianfar s BYG DTU

Civilstyrelsen. Lex Dania editor Eunomia. Installationsvejledning. Version:

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen

Fjernopkobling. - Vejledning i førstegangs fjernopkobling via en IKKE. Banedanmark pc

Karakterer på 7-trinsskalaen

Komponentbaseret softwareudvikling Acme ADL

Sporbarhed og Rapportering i Quality Center. Kim Stenbo Nielsen NNIT Application Management Services

Tobaks BYEN Boligområde d. 24 April

Michael Bruhn Barfod 1*, Claus Rehfeldt Moshøj +, Rune Larsen *, Jacob Kronbak *, Britta Lyager Degn +

Notat Konceptmodel for SSO ØSY/JESBO/TG

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen

STEDBEVIDST UDVIKLING. Jes Ryttersgaard Kort og Matrikeldtyrelsen

S-Design: Sikkerhed i planlægning og design af nye produktionssystemer. Ole Broberg, DTU. Jette Paulsen, Risø. Tina Weller Nielsen, NFA

OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen

Æstetik på pilgrim.dk

Danske regler for gasmåling efter MID er trådt i kraft

UDFORDRINGER OG POTENTIALER VED SOA I SUNDHEDS-IT MED UDGANGSPUNKT I FMK

Substitutions- og indkomsteffekt ved prisændringer

Ræsonnement og tankegang. DLF-Kursus Frederikshavn Eva Rønn UCC

Procesplan 1. Monofaglig Udviklingsgruppe. Sygeplejerskeuddannelsen. Leverance Ramme Aktør Status Dato. Leverance Ramme Aktør Status Dato

Sesam seminar nr Sesam seminar nr Opbygning af standard bibliotek til PLC / SCADA / MES

ETA Danmark CE mærkning og nationale krav for byggevarer

Bilag 2 Kundens IT-miljø

imo-learn MOVED BY LEARNING

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation

De 7 trin til en LinkedIn Virksomhedsside, der skaber resultater

Transkript:

Kapitel 21: Softwarearkitektur designprincipper Miriam Tang Jacob Jensen Lars Christensen Jacob Atzen Onsdag 9/3

Dagens program Definitioner Analyseværktøjer Designprocessen Raffinering Afrunding

Design af Softwarekomponentinfrastrukturer Infrastruktur: Den grundlæggende struktur og services i et system Softwarekomponentinfrastruktur: En struktur og en samling komponenter Mål: At designe en infrastruktur, der understøtter en mængde af applikationer

Softwarearkitektur Softwarearkitekturen for et program er programmets struktur, dette omfatter softwarekomponenter, de eksternt synlige egenskaber ved komponenterne og sammenhængen imellem disse. En komponent er en logisk sammenhængende samling funktionalitet Softwarearkitektur: En specifik softwarekomponentinfrastruktur med tilknyttede designregler

Funktionelle krav Der skal være både abstrakte og konkrete krav Abstrakte krav identificeres og kategoriseres ud fra den basale anvendelse af komponentinfrastrukturen Use cases konkretiserer, verificerer og afdækker yderligere krav Eksempel: Abstrakt: Der skal være en af piloten regulerbar motor i en fly- simulator Use case afdækker at der mangler en reguleringsmetode for piloten Konkret: Lav regulator metode

Kvalitets krav Skal ligesom funktionelle krav eksistere i abstrakt og konkret form Må ikke blive for abstrakte Eksempel: For abstrakt: Systemet skal være sikkert Tilpas abstrakt: Systemet skal være sikkert mod aflytning Konkret: Det skal ikke være muligt at aflytte bestemt kommunikationskanal Funktionelle krav må ikke blive for konkrete Kvalitetskrav må ikke blive for abstrakte.

Arkitektoniske Drivers Vigtigste krav fungerer som "Drivers" for design Driver identifikation: Funktionelle, kvalitets og forretningskrav Formålet med systemet Drivers er abstrakte (ikke knyttet til specifik funktionalitet) Et design skal kunne tilfredsstille drivers Eksempel: Formålet med en fly- simulator er at træne piloter Dette kræver at simulatoren kan lave real- tids simulationer

Opdeling af komponent infrastruktur Delmængder af funktionalitet skal opdeles i komponenter der interagerer Hjælp: Arkitektoniske stilarter Arkitektoniske drivers bestemmer valget af stilart Eksempel: Real- tids simulation / Bus stilarten Stilarter er abstrakte (beskriver ikke specifik funktionalitet) Stilarter er udgangspunkt for den konkrete opdeling af komponent infrastrukturen

Grundlæggende designproces Quality Requirements Architectural Drivers Basic Style Tailored Style Software Architecture Functional Requirements Functional Blocks

Udbygget designproces Quality Requirements Architectural Drivers Basic Style Tailored Style Software Architecture Shared Services Functional Requirements Functional Blocks Final Application Other Functions Deployed Components

Identifikation af komponentinfrastruktur og komponenter Grundmængden af applikationer skal være designet delvist Interaktion mellem komponenter og delte services skal designes Iterativ designproces Definer delte services Itererer gennem opdelingerne af funktionalitet og raffinerer softwarekomponentinfrastrukturen og komponenterne Softwarekomponentinfrastruktur og komponenter designes sideløbende

Softwaretemplate Beskriver fællestræk Designelement: Del af komponentinfrastruktur eller komponent Beskriver interaktion mellem komponenter og infrastruktur Identificerer placering af ansvar Templates er typebaserede Forfines igennem nedarvning

Softwaretemplate Design af infrastruktur: Alle komponenter og deres ansvar skal være identificeret Iterativ proces, hvori identificeret ansvar løbende fordeles til elementer i templaten Under hvert trin af forfiningsproces skal hvert software element undersøges igen Analyser kvalitetsegenskabers krav til hele systemet Slutresultat: et antal softwaretemplates der beskriver de interfaces der bruges i interaktion mellem komponentinfrastruktur og komponenter

Perspektiver Perspektiver gør det muligt at besvare spørgsmål om systemer udviklet omkring en bestemt komponentinfrastruktur Er deadlocks mulige? Kan performancemål overholdes? Kan ønskede ændringer foretages?

Perspektiver Kruchtens perspektiver: Logisk Samtidighed Implementation Idriftsættelse

Afrunding Identificér krav til funktionalitet og kvalitet eksplicit både på højt niveau og konkret Identificer arkitektur drivers Vælg en arkitekturstil, der bedst muligt tilgodeser arkitektur driverne Opdel funktionalitet på en måde, der understøtter kvalitetskravene Brug samtidigheds- og anvendelsessynsvinkler til at identificere funktionalitet, der ikke tidligere er overvejet Verificer vha. konkrete og funktionelle krav Identificer den passende komponentmodel Iterer mhp. at raffinere designelementerne