Arkitekturdesign Moduler/delsystem
Kursinformation Metodik för programvaruutveckling Föreläsning 5 Martin Höst • Inlämningar i v. 7 – enligt kursprogram: projektdefinition, projektplan, disposition till kravspecifikation, disposition till litteraturstudien, samt svar till de reflekterande frågor som behandlar projektdefinition och projektplan. • Två övningar kvar innan sommaren – V5: arbete med projekt och litteraturstudien – V6: Kravhantering Idag • Designprocessen • Arkitekturdesign – – – – Systemmodeller Kontrollmodeller Design på modulnivå Generiska modeller och referensmodeller • Distribuerade arkitekturer • Design med återanvändning Designprocessen (från kap. 3) • • • • • • Arkitekturdesign – fokus idag Abstrakt specifikation Design av gränssnitt Komponentdesign Design av datastrukturer Design av algoritmer – Metoder – Design för återanvändning Arkitekturdesign • Systemstruktur – Uppdelning i delsystem, specifikation av kommunikation mellan delsystem • Kontrollmodell – Hur kontroll mellan delar av systemet fördelas • Uppdelning i moduler – För varje delsystem Moduler/delsystem • Delssystem “fristående”, moduler delar av delsystem • Gränssnitt / Implementation Varför göra arkitekturdesign? • Åskådliggöra systemet för alla intressenter – underlättar kommunikation • Möjliggöra systemanalys – t ex med avseende på prestanda • Identifiera möjlig återanvändning Arkitekturdesign påverkas t ex av krav på: • Prestanda – Få delsystem, lite kommunikation • Säkerhet mot intrång – Bygg i lager med kritisk information innerst Vad är en bra arkitekturdesign? Och hur uppnår man en sådan? Uppdelning i delsystem • Blockdiagram som visar interaktion mellan delsystem • Tre exempel på viktiga modeller: – ”Repository”-modellen – ”Client-server”-modellen – Abstrakt maskin • Säkerhet vid användande – Samla kritiska delar i ett system • Tillgänglighet – Redundanta komponenter • Underhållbarhet – Delar som är enkla att förstå och ändra Repository-modellen gemensam information ”repository” Delsystem 1 Delsystem 2 … Delsystem n Repository-modellen Fördelar: • Effektivt med mycket data • De som producerar data måste inte veta så mycket om mottagaren • Backup, etc lätt Svårigheter: • Alla delsystem har samma dataform • Vidareutveckling svårt eftersom mycket bygger på en viss datamodell • Olika krav på detta ”Client-server”-modellen ”Client-server”-modellen Presentation Klient 1 Klient 2 … Klient n Nätverk Betj. 1 Betj. 2 … Betj. m ”Client-server”-modellen • Fördelar: – Distribuerad arkitektur – Lätt att lägga till klienter och betjänare • Svårigheter: – Nya enheter måste kanske anpassas – Ingen gemensam datamodell Kontrollmodeller • Centraliserad tilldelning – Call-return – Manager model • Händelsebaserad tilldelning – Broadcast models – Avbrottsstyrda modeller Tunn klient Klient Stor klient Presentation Applikation Klient Tre-lager modell Klient Betjänare: Applikation Datahantering Betjänare: Datahantering Presentation Betjänare: Applikation Abstrakt maskin … ... Nivå 3 Nivå 2 Nivå 1 Design på modulnivå • Objektorienterade modeller • Dataflödesmodeller Betjänare: Datahantering Dataflödesmodell, exempel Ta emot beställning Sök i lager Uppdatera Leverera lager komponent Fördelar/svårigheter Objektorienterad modell Dataflödesmodell Fördelar Svårigheter Välkända Naturliga objekt Intuitivt Återanvändning Bra språk Intuitivt Återanvändning Vidareutveckling enkelt Explicita referenser Behov av lika dataformat [Sommerville, pp. 229-232] • • • • • • Generiska modeller Referensarkitektur Exempel Kompilator Exempel OSI Lexikalisk analys Bygg symboltabell Syntaxanalys Bygg syntaxträd Semantisk analys Kodgenerering Uppgifter • 10.1 • 10.9 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 7 6 5 4 3 2 1 Distribuerade system Viktiga egenskaper • Dela resurser • Öppna • Parallella processer • Skalbara • Feltoleranta • Transparenta Svårigheter • Komplexa • Säkerhet svårt • Svårt underhålla • Oförutsägbara Återanvändning av programvara CORBA (Common Object Request Broker Architecture) Application objects Domain facilities Horizontal CORBA facilities • Återanvändning på applikationsnivå – Förhållandevis vanligt • Återanvändning av komponenter – Svårare Object Request Broker • Återanvändning av funktioner – Förhållandevis vanligt CORBA services Varför återanvändning? • • • • Lägre kostnad Bättre tillförlitlighet Lägre osäkerhet -> lägre risk Effektivare användning av specialister • Mer standardisering (t ex menyer som liknar varandra) • Snabbare utveckling Svårigheter • Högre underhållskostnader • Verktygsstöd inte anpassat efter återanvändning • ”Not-invented-here”-syndromet • Vem ska se till att det finns återanvändbara komponenter? Underhåll av bibliotek dyrt • Svårt att hitta, förstå och anpassa komponenter Utveckling med återanvändning • Utkast till krav • Leta efter återanvändningsbara komponenter • Anpassa krav • Arkitekturdesign • Leta efter återanvändningsbara komponenter • Design av systemet Komponentbaserad utveckling (CBSE) Komponent • Fristående exekverbar enhet • Definierat gränssnitt (men kräver erbjuder inte nödvändigtvis källkod) • Olika abstraktionsnivå – – – – – funktioner grupper av funktioner dataabstraktion ramverk system Utveckling för återanvändning • Komponenter baserade på stabila begrepp inom domänen • Inte visa hur tillstånd representeras • Komponenter ska vara olika och användbara var för sig • Ta hand om undantag • Avvägning mellan användbarhet och återanvändbarhet! Applikationsfamiljer • Specialiseringar för olika operativsystem • Specialiseringar för olika hårdvaruplattformar • Specialiseringar för olika funktionskrav (byggda på samma programvaruplattform) Svårigheter med komponentbaserad utveckling • Inte kontroll över funktionalitet • Problem att få olika COTS att fungera tillsammans • Ingen kontroll över vidareutvecklingen av COTS • Inte alltid bra support från COTStillverkare Platforms in Product Development Not a software specific concept! Black & Decker “Battery Pack, Motor Pack …” Car industri “Peugeot, Fiat, Toyota, etc …” Plattformsbaserad utveckling Produkt 1 Produkt 2 Plattform … Produkt n Questions proposed to be asked about work with software platforms Questions proposed to be asked about work with software platforms • Q1: How is the responsibility and empowerment for the group responsible for the platform defined? • Q2: Describe the stakeholder interaction • Q5: Describe how the architecture is validated. • Q3: Which procedures are used to identify architectural requirements? • Q4: What design process is used? [M. Höst, E. Johansson, A. Norén, L. Bratthall, “Benchmarking of Processes for Managing Product Platforms - a Case Study”, IEE Proceedings – Software, Vol. 159, Issue 5, pp. 137-142, 2002.] Frågor • 14.1 • 14.3 • 14.9 • Q6: Describe how the architecture is distributed. • Q7: Describe how it is ensured that software architecture has its self-evident place in the software development process. • Q8: How is the product-line architecture controlled?
© Copyright 2024