Arkitektur Michael Åhs

Transkript

1 Arkitektur Michael Åhs Kalle & Hobbe: En utvecklares drömsystem 1. Vad är arkitektur? 2. Arkitektur i UML Innehåll 3. Utveckla en arkitektur 4. Arkitektur i projektet Del 1 - Vad är Arkitektur? Pattern-Oriented Software Architecture: A software architecture is a description of the subsystems and components of a software system and the relationship between them. Enligt UML: The organizational structure of a system, including its decomposition into parts, their connectivity, interaction and mechanisms and the guiding principles that inform the design of a system. Vad gör en bygg- och systemarkitekt Byggnadsarkitekt Systemarkitekt Bestämmer utseende och Beskriver systemets stil. fysiska infrastruktur och Väljer material. implementationsstruktur. Dimensionerar för Delar upp systemet i hållfastighet. logiska delar Modellerar utrymmen Bestämmer vilka för mänsklig aktivitet. konventioner och riktlinjer Och så vidare som skall följas. Och så vidare. Båda: Identifierar och ger namn åt viktiga delar 1

2 Varför Arkitektur? En arkitektur behövs inte alltid Inte så stort behov för mindre system (jämför med en hundkoja) Dock oumbärligt för större system (jämför med Öresundsbron) För framgångsrika system ökar storleken Kostnaden för att utveckla och underhålla beror i hög grad på arkitekturen. Varför Arkitektur? (2) UML är processoberoende men dess skapare rekommenderar en process som: Drivs av användningsfall ( use-cases ) Är centrerad kring en arkitektur Är iterativ och inkrementell Projektet: När och var? Under vilka aktiviteter? Främst under design Sannolikt har ni redan tänkt på arkitekturen. Man bör tidigt bör skissa på möjliga lösningar. Del 2 - Arkitektur med UML UML diagram ur olika synvinklar (vyer) The 4+1 view model of architecture Diagrammen hjälper till att etablera den gemensamma begreppsapparat och mentala modeller som krävs för effektiv kommunikation. 2

3 The 4+1 view model of architecture Logisk vy Klassdiagram Interaktionsdiagram Implementationsvy Komponentdiagram Användningsfallsvy Processvy Grupperingsvy Tillståndsdiagram Grupperingsdiagram Interaktionsdiagram UML vyer: Användningsfall Systemets beteende ur användarens synvinkel. Beskrivna i tidigare faser Beakta de viktigaste användningsfallen, de som fundamentalt påverkar systemets arkitektur. Innehåll: Användningsfallsdiagram Diagramsuppdelningen är ej absolut UML Vyer: Process-vy Dynamiskt förlopp av signifikant intresse för förståelsen av systemets prestanda och skalbarhet. Exempelvis Processer, trådar Parallellitet och synkronisering Innehåll: Sekvensdiagram, samarbetsdiagram, tillståndsdiagram och aktivitetsdiagram. UML Vyer: Logisk-vy Betydelsefulla klasser, för att tillgodose de funktionella kraven: Strukturerade i paket (t.ex. lager och subsystem) Samarbete mellan dessa Bestämmer programkodens struktur. Innehåll: Klassdiagram 3

4 Klassdiagram Presentation Model Exempel: Tre-lagers arkitektur From Mud to Structure med Lager Organisation med skiktning (Layers). Inte den enda möjligheten. Varianter, t.ex. Relaxed Layers Koppling, t.ex Facade (pull) och Observer (push) Inverted pyramid of resuse Felhantering kräver eftertanke, före. Storage Paket Paket - exempel Lämpar sig för att dela upp systemet i delar. Ej begränsat till klasser Representeras grafiskt av en mapp med tillhörande etikett. Namnet antingen i etiketten eller direkt på mappen. Exempel på nedbrytning av stora strukturer till logiska och hanterbara enheter. 4

5 Paket - notationsvarianter Paket - relationer Math::Number betyder att Number ingår i Math (jämför med C++) Paket - stereotyper Följande stereotyper för paket är definierade som standardelement i UML: <<facade>> Beskriver ett paket som endast är en vå av något annat paket (Design Pattern) <<framework>> Består av samverkande klasser där en del används som mallar för nya klasser (mer i kommande föreläsning) <<model>> Innehåller verksamhets- eller domänmodellen. <<subsystem>> Beskriver ett delsystem i det övergripande systemet. <<system>> Beskriver ett paket som representerar hela det systemet som konstrueras. UML Vyer: Implementationsvy Beskriver de komponenter som ingår i systemet Strukturerade i paket Samarbete mellan dessa Komponent fysiska saker (i bitarnas värld) Innehåller: Komponentdiagram 5

6 Komponenter - grafisk notation Komponenter Vanligt (och tillåtet) att man ersätter den med andra grafiska symboler UML komponenter!= Vanliga komponenter Komponentinstanser existerar på noder Modelleras Filer: källkod, exekverbara, dokument Databaser och tabeller Delar i dynamiskt kopplat system Komponenter - stereotyper Följande stereotyper för paket är definierade som standardelement i UML: <<document>> Denna komponent representerar ett dokument. <<executable>> En komponent som kommer kunna exekveras i en nod. <<file>> Representerar ett dokument som innehåller källkod eller data. <<library>> Representerar ett statiskt eller dynamiskt objektbibliotek. <<table>> Representerar en databastabell. UML Vyer: Grupperings-vy Beskriver systemets hårdvara (den fysiska världen). Topologi och noder Distribution, leverans och installation. Innehåller: Grupperings ( Deployment ) -diagram 6

7 Grupperingsdiagram Nod representeras av en låda Såsom objekt har noder klasser och instanser. Relationer mellan noder är oftast associationer och beroende. Del 3 Utveckla en Arkitektur En fullständig arkitektur för ett exempelsystem, en Internetbutik. Skapa en bra arkitektur är väldig svårt, görs aldrig i ett enda steg (big bang utveckling). :Internet Utvecklingssteg: 1. Krav (Icke funktionella och Funktionella) 2. Gruppering 3. Logisk och implementation Struktur, samarbete och komponenter Icke funktionella krav Identifiera icke funktionella kraven som styr systemets egenskaper Exempelvis: tillgänglighet (när och var kunder vill handla) effektivitet För kund (svarstid för produktsidor) För kundtjänst (order per minut) integritet (betald order får ej försvinna) Funktionella krav Identifiera av de viktiga användningsfallen Kritisk funktionalitet, stor påverkan på arkitekturen 7

8 Gruppering Centraliserat mönster Ta fram grupperingsdiagram för systemet Som det se ut när det är klart :Client User More clients System Tre möjliga alternativ (grupperingsmönster) Centraliserat mönster Distribuerat mönster Decentraliserat mönster :Server User System Vilken lösning? Function Model Distribuerat mönster Decentraliserat mönster :Client User System More clients Function Model :Server User System Function Model 8

9 Vald gruppering Logisk vy Möjliga strukturalternativ (arkitekturmönster) Layers Call-Return Pipes and Filters Vilken lösning? Call-and-Return: Objektorienterad Pipes and Filters Objects Encapsulate representations Provide s for services Connectors Call-return Service inovocation Välkänt mönster och naturligt i språk såsom Java, dock 9

10 Presentation Domain Model Remote Access Vald logisk struktur En kombination av Layers och Call-Return. Notera hur högre paket får vara direkt beroende av Storage. Anledning? Implementationsvy: Komponenter Ta fram komponenter och beskriv beroenden och både logisk och fysik placering. Logisk komponentplacering Storage Komponenter (2) Utforska kritiska förlopp Ta fram komponenter och beskriv beroenden och både logisk och fysik placering Fysik komponent placering De kritiska förloppen Vilka delar och hur samarbetar de för att uppnå kraven? <<executable>> 10

11 Utforska kritiska förlopp (2) Utforska kritiska förlopp (3) Kundtjänst har liknande men ändå annorlunda behov. Hur hantera? 3: create(row) Del 4 - Arkitektur i projektet Ett kort förslag på arbetsgång Betrakta systemet så som det ska se ut när det är klart. Ta fram ett grupperingsdiagram som beskriver detta läge. Strukturera systemet i skikt och delsystem (logiska vyn) parallellt med dess komponenter (implementationsvyn). Beskriv flöden för kritiska förlopp. Beskriv koppling till befintliga ramverk. Kommande föreläsning Innehållet på Ramverksföreläsningen är ej ännu bestämt. Kontakta mig med önskemål och förslag: michael@creatus.se Tack så mycket! 11